This fixes a vector CTOR insertion issue when we try to insert after
a PHI node.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
2020-10-09 Richard Biener
* tree-vect-slp.c (vect_create_constant_vectors): Properly insert
after PHIs.
* gcc.dg/vect/bb-slp-phis-
PowerPC: Map long double built-in functions if IEEE 128-bit long double.
This patch is revised from the first version of the patch posted. It uses the
names that are not in the user's namespace (i.e. __sinieee128 instead of
sinf128) that Joseph Myers suggested.
This patch goes through the built-
Dear Joseph,
On Thu, Oct 8, 2020 at 1:36 PM Joseph Myers wrote:
>
> This documentation doesn't seem sufficient to use the macros. Do they
> expand to (narrow) string literals? To an unquoted sequence of
> characters? I think from the implementation that the answer is strings
> (so, in particul
On Linux/x86_64,
214d514fafcd78cd54e4a4aa9ae08c89abf9cc57 is the first bad commit
commit 214d514fafcd78cd54e4a4aa9ae08c89abf9cc57
Author: Aldy Hernandez
Date: Thu Oct 8 11:15:23 2020 +0200
Fix PR97315 (part 1 of 2)
caused
FAIL: gcc.dg/pr97315-1.c (test for excess errors)
with GCC config
Here we're trying to push into a::c in order to instantiate t, but
were building a TYPENAME_TYPE for it because a isn't open yet. Don't
do that when we know we're trying to enter the scope.
Tested x86_64-pc-linux-gnu, applying to trunk and 10.
gcc/cp/ChangeLog:
PR c++/96805
PR c
On 07/10/20 12:10 -0400, Patrick Palka via Libstdc++ wrote:
On Wed, 30 Sep 2020, Patrick Palka wrote:
This rewrites ranges::construct_at in terms of std::construct_at so
that we can piggy back on the compiler's existing support for
recognizing placement new within std::construct_at during const
In the testcase below, we're ICEing during constexpr evaluation of the
CONSTRUCTOR {.data={{}, [1 ... 7]={}}} of type 'vector'. The apparently
unique thing about this CONSTRUCTOR is that it has a RANGE_EXPR index
whose corresponding sub-aggregate initializer doesn't satisfy
reduced_constant_expres
On Thu, Oct 08, 2020 at 11:21:26AM +0100, Alex Coplan wrote:
> Ping. The kernel is still broken on AArch64.
You *cannot* fix a correctness bug with a combine addition. So please
fix the target bug first.
I haven't had time to look at your patch yet, sorry.
Segher
On Oct 8, 2020, Richard Biener wrote:
> OK with a minor nit, see below
>> I'm a little unhappy with the duplication of the CASE_MATHFN* sequence,
>> that ought to be kept in sync, , and considered turning that whole
>> sequence into a #define used in both places, but that would bloat the
>> pat
On 10/8/20 3:18 PM, Martin Sebor wrote:
On 10/7/20 3:01 PM, Jason Merrill wrote:
On 10/7/20 4:11 PM, Martin Sebor wrote:
...
For the various member functions, please include the comments
with the definition as well as the in-class declaration.
Only one access_ref member function is defined
Hi Richard!
On 2020-10-08T13:34:02+0200, Richard Biener wrote:
> It might be interesting to work on adding sth like
> dg-warning to look for -fopt-info-{optimized,missing} so
> we could directly annotate (not) vectorized loops instead of
> relying on fragile counts.
I'm maybe (likely?) misunders
I eventually consider your last remark about using weak symbols to
inject libbacktrace calls when _GLIBCXX_DEBUG_BACKTRACE is defined.
libstdc++: [_GLIBCXX_DEBUG] Integrate libbacktrace
Add _GLIBCXX_DEBUG_BACKTRACE macro to ask for a backtrace on
_GLIBCXX_DEBUG
assertions using
On Linux/x86_64,
181702ef8ab76afbf5d2cd4d7bc0cef613397d6e is the first bad commit
commit 181702ef8ab76afbf5d2cd4d7bc0cef613397d6e
Author: Richard Biener
Date: Tue Oct 6 15:47:15 2020 +0200
SLP vectorize multiple BBs at once
caused
FAIL: gcc.c-torture/execute/loop-13.c -O3 -fomit-frame-
On 10/7/20 3:01 PM, Jason Merrill wrote:
On 10/7/20 4:11 PM, Martin Sebor wrote:
...
For the various member functions, please include the comments
with the definition as well as the in-class declaration.
Only one access_ref member function is defined out-of-line:
offset_bounded(). I've adj
Using the tokenizer to sniff for an initial line marker for
preprocessed input is a little brittle, particularly with
-fdirectives-only. If there is no marker we'll happily munch initial
comments. This patch directly sniffs the buffer. This is safe
because the initial line marker was machine ge
On Thu, 2020-10-08 at 09:36 +1030, Alan Modra via Gcc-patches wrote:
> Implement more two insn constants. rotate_and_mask_constant covers
> 64-bit constants that can be formed by rotating a 16-bit signed
> constant, rotating a 16-bit signed constant masked on left or right
> (rldicl and rldicr), r
Dear all,
the present PR turned out to be fixable rather easily, once Paul had the
idea to add another attempt of simplification of elemental intrinsics
for array-valued arguments. There was some fallout which required only
small adjustments, see commit message below.
Regtested cleanly on x86_64
On Thu, 2020-10-08 at 09:27 +1030, Alan Modra via Gcc-patches wrote:
> The aim of this patch is to make rtx_costs for SETs closer to
> insn_cost for SETs. One visible effect on powerpc code is increased
> if-conversion.
>
> * config/rs6000/rs6000.c (rs6000_rtx_costs): Reduce cost of SET
>
On Linux/x86_64,
532e882f8872b1b4437e3a0fa8c61d2af2d999d4 is the first bad commit
commit 532e882f8872b1b4437e3a0fa8c61d2af2d999d4
Author: Richard Biener
Date: Thu Oct 8 11:53:51 2020 +0200
adjust BB vectorization dump scanning
caused
FAIL: gcc.dg/vect/bb-slp-pr78205.c -flto -ffat-lto-obj
On Linux/x86_64,
dae673abd37d400408959497e50fe1f3fbef5533 is the first bad commit
commit dae673abd37d400408959497e50fe1f3fbef5533
Author: Richard Biener
Date: Wed Oct 7 10:42:12 2020 +0200
tree-optimization/97307 - improve sinking of loads
caused
FAIL: gcc.dg/vect/pr65947-3.c -flto -ffat
On Thu, 8 Oct 2020, JeanHeyd Meneide via Gcc-patches wrote:
> * gcc/doc/cpp.texi: Document new predefined macro.
This documentation doesn't seem sufficient to use the macros. Do they
expand to (narrow) string literals? To an unquoted sequence of
characters? I think from the implement
Hi all,
I'd like to backport this patch to the GCC 9 branch to implement these
Armv8.5-a intrinsics that should have been there.
The backport is fairly simple.
Bootstrapped and tested on aarch64-none-linux-gnu.
Pushing to GCC 9 branch.
This patch implements the ACLE intrinsics to access the FRI
On Okt 08 2020, korel ka via Gcc-patches wrote:
> diff --git a/libstdc++-v3/include/bits/stl_iterator.h
> b/libstdc++-v3/include/bits/stl_iterator.h
> index 2259f7c..13d5dbb 100644
> --- a/libstdc++-v3/include/bits/stl_iterator.h
> +++ b/libstdc++-v3/include/bits/stl_iterator.h
> @@ -625,8 +650,2
On 07/10/20 18:15 -0700, Thomas Rodgers wrote:
@@ -500,6 +576,40 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
}
#endif
+#if __cplusplus > 201703L && _GLIBCXX_USE_CXX11_ABI
+ basic_istringstream(ios_base::openmode __mode, const allocator_type& __a)
+ : __istream_type(), _M_stringbuf(__mode |
std::iterator considered as deprecated since C++17 and shouldn't be in use.
This patch marks std::iterator as deprecated using deprecated
attribute, and replace its usages with the required member types
inside each class.
libstdc++-v3/include/bits/ChangeLog:
stl_iterator_base_types.h: Add
在 2020/10/8 22:56, Jason Merrill 写道:
> On 10/7/20 10:52 PM, Liu Hao via Gcc-patches wrote:
>> [Please CC me as I am not subscribed to this list.]
>
> Hmm, why isn't the mingw implementation used for all programs? That would
> avoid the bug.
>
I am afraid the libstdc++ implementation has to be
On Mon, 2020-10-05 at 11:52 -0700, Carl Love wrote:
> Will, Segher:
>
> This patch adds support for converting to/from 128-bit integers and
> 128-bit decimal floating point formats using the new P10 instructions
> dcffixqq and dctfixqq. The new instructions are only used on P10 HW,
> otherwise th
On 10/8/20 5:08 PM, Jakub Jelinek wrote:
On Thu, Oct 08, 2020 at 04:55:07PM +0200, Aldy Hernandez via Gcc-patches wrote:
Yes, for max == 0 aka [0, 0] I wanted:
1) if mini == -1, i.e. the DEFINED_VALUE_AT_ZERO == 2 VALUE is -1, return [-1,
-1]
2) if maxi == prec, i.e. DEFINED_VALUE_AT_ZERO ==
On Thu, Oct 08, 2020 at 04:55:07PM +0200, Aldy Hernandez via Gcc-patches wrote:
> > Yes, for max == 0 aka [0, 0] I wanted:
> > 1) if mini == -1, i.e. the DEFINED_VALUE_AT_ZERO == 2 VALUE is -1, return
> > [-1, -1]
> > 2) if maxi == prec, i.e. DEFINED_VALUE_AT_ZERO == 2 VALUE is prec, return
> > [
Ping for the C parts.
On Mon, Sep 28, 2020 at 02:15:41PM -0400, Marek Polacek via Gcc-patches wrote:
> On Tue, Sep 22, 2020 at 04:07:41PM -0400, Jason Merrill wrote:
> > On 9/22/20 1:29 PM, Marek Polacek wrote:
> > > Ping.
> >
> > The C++ change is OK.
>
> Ping for the C parts.
>
> > > On Tue,
On 10/7/20 10:52 PM, Liu Hao via Gcc-patches wrote:
[Please CC me as I am not subscribed to this list.]
[This patch is only a draft and has not been tested at all.]
Some details have been discussed in [1]. mingw-w64 has got an implementation
[2] [3] for static libraries, but it takes a
destru
On 10/8/20 4:39 PM, Jakub Jelinek wrote:
On Thu, Oct 08, 2020 at 04:28:37PM +0200, Aldy Hernandez wrote:
On 10/8/20 3:54 PM, Jakub Jelinek wrote:
On Thu, Oct 08, 2020 at 12:22:11PM +0200, Jakub Jelinek via Gcc-patches wrote:
Perhaps another way out of this would be document and enforce that
On Mon, 2020-10-05 at 11:52 -0700, Carl Love wrote:
> Will, Segher:
>
> Patch 4 adds the vector 128-bit integer shift instruction support for
> the V1TI type.
>
> The changes from the previous version include:
>
> Fixed up the change log entry issues noted by Will.
>
> Regression tests reran on
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555225.html
On 9/30/20 6:14 PM, Martin Sebor wrote:
-Wstring-compare triggers under the same strict conditions as
the strcmp/strncmp call is folded into a constant: only when
all the uses of the result are [in]equality expressions with
These three distributions all require 0 < S where S is the sum of the
weights. When the sum is zero there's an undefined FP division by zero.
Add assertions to help users diagnose the problem.
libstdc++-v3/ChangeLog:
PR libstdc++/82584
* include/bits/random.tcc
(discrete_d
On Thu, Oct 08, 2020 at 04:28:37PM +0200, Aldy Hernandez wrote:
> On 10/8/20 3:54 PM, Jakub Jelinek wrote:
> > On Thu, Oct 08, 2020 at 12:22:11PM +0200, Jakub Jelinek via Gcc-patches
> > wrote:
> > > Perhaps another way out of this would be document and enforce that
> > > __builtin_c[lt]z{,l,ll} e
On 10/8/20 3:54 PM, Jakub Jelinek wrote:
On Thu, Oct 08, 2020 at 12:22:11PM +0200, Jakub Jelinek via Gcc-patches wrote:
Perhaps another way out of this would be document and enforce that
__builtin_c[lt]z{,l,ll} etc calls are undefined at zero, but C[TL]Z ifn
calls are defined there based on *
On 05/10/20 22:35 +0300, Ville Voutilainen via Libstdc++ wrote:
On Mon, 5 Oct 2020 at 01:15, Ville Voutilainen
wrote:
The patch is borked, doesn't pass tests, fixing...
Unborked, ok for trunk if full testsuite passes?
Assuming it has passed by now, OK. Thanks.
On Mon, 2020-10-05 at 11:52 -0700, Carl Love wrote:
> Will, Segher:
>
> Add support for converting to/from 128-bit integers and 128-bit
> decimal floating point formats.
>
> The updates from the previous version of the patch:
>
> Just a fix for the change log per Will's comments.
>
> No regres
On Thu, 8 Oct 2020 at 16:08, Dennis Zhang wrote:
>
> Hi Christophe,
>
> On 08/10/2020 14:14, Christophe Lyon wrote:
> > Hi,
> >
> >
> > On Tue, 6 Oct 2020 at 15:37, Dennis Zhang via Gcc-patches
> > wrote:
> >>
> >> On 9/16/20 4:00 PM, Dennis Zhang wrote:
> >>> Hi all,
> >>>
> >>> This patch enabl
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 05 October 2020 10:58
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] arm: [MVE] Add missing __arm_vcvtnq_u32_f32 intrinsic
> (PR 96914)
>
> __arm_vcvtnq_u32_f32 was missing from arm_mve.h,
Hi Christophe,
On 08/10/2020 14:14, Christophe Lyon wrote:
Hi,
On Tue, 6 Oct 2020 at 15:37, Dennis Zhang via Gcc-patches
wrote:
On 9/16/20 4:00 PM, Dennis Zhang wrote:
Hi all,
This patch enables SIMD modes for MVE auto-vectorization.
In this patch, the integer and float MVE SIMD modes are
On Thu, 8 Oct 2020, Jan Hubicka wrote:
> Hi,
> as discussed on IRC, I am testing the attached patch to disable TBAA for
> some uses of call_may_clobber_ref_p.
>
> OK if testing passes?
OK.
Thanks,
Richard.
> Honza
>
> gcc/ChangeLog:
>
> 2020-10-08 Jan Hubicka
>
> * tree-nrv.c (dest
On Thu, Oct 08, 2020 at 12:22:11PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Perhaps another way out of this would be document and enforce that
> __builtin_c[lt]z{,l,ll} etc calls are undefined at zero, but C[TL]Z ifn
> calls are defined there based on *_DEFINED_VALUE_AT_ZERO (*) == 2
The foll
Hi,
as discussed on IRC, I am testing the attached patch to disable TBAA for
some uses of call_may_clobber_ref_p.
OK if testing passes?
Honza
gcc/ChangeLog:
2020-10-08 Jan Hubicka
* tree-nrv.c (dest_safe_for_nrv_p): Disable tbaa in
call_may_clobber_ref_p and ref_maybe_used_
On 08/10/20 00:45 +0100, Jonathan Wakely wrote:
libstdc++-v3/ChangeLog:
* include/bits/random.h (__detail::_Mod): Avoid divide by zero.
*
testsuite/26_numerics/random/linear_congruential_engine/operators/call.cc:
New test.
That didn't work properly in all cases. Here'
The new constructors that C++11 added to std::ios_base::failure were
missing for the old ABI. This adds them, but just ignores the
std::error_code argument (because there's nowhere to store it).
This also adds a code() member, which should be provided by the
std::system_error base class, but that
On 10/8/20 2:49 PM, Jakub Jelinek wrote:
On Thu, Oct 08, 2020 at 11:46:36AM +0200, Aldy Hernandez via Gcc-patches wrote:
This was a pasto by yours truly while porting the __builtin code from
vr_values::extract_range_basic.
I've tested Andrew's patch, and pushed it.
Note for next time, I th
Hi,
On Tue, 6 Oct 2020 at 15:37, Dennis Zhang via Gcc-patches
wrote:
>
> On 9/16/20 4:00 PM, Dennis Zhang wrote:
> > Hi all,
> >
> > This patch enables SIMD modes for MVE auto-vectorization.
> > In this patch, the integer and float MVE SIMD modes are returned by
> > arm_preferred_simd_mode (TARG
On Thu, 8 Oct 2020, Jakub Jelinek wrote:
> On Thu, Oct 08, 2020 at 11:46:36AM +0200, Aldy Hernandez via Gcc-patches
> wrote:
> > This was a pasto by yours truly while porting the __builtin code from
> > vr_values::extract_range_basic.
> >
> > I've tested Andrew's patch, and pushed it.
>
> Note
Hi Jakub,
> On Thu, Oct 08, 2020 at 11:37:24AM +, Wilco Dijkstra via Gcc-patches
> wrote:
>> Which optimizations does it enable that aren't possible if the value is
>> defined?
>
> See bugzilla. Note other compilers heavily optimize on those builtins
> undefined at value zero.
You mean the
On Thu, Oct 08, 2020 at 11:46:36AM +0200, Aldy Hernandez via Gcc-patches wrote:
> This was a pasto by yours truly while porting the __builtin code from
> vr_values::extract_range_basic.
>
> I've tested Andrew's patch, and pushed it.
Note for next time, I think you should use --author when committ
This work from Martin Liska was motivated by gcc.dg/vect/bb-slp-22.c
which shows how poorly we currently BB vectorize code like
a0 = in[0] + 23;
a1 = in[1] + 142;
a2 = in[2] + 2;
a3 = in[3] + 31;
if (x > y)
{
b[0] = a0;
b[1] = a1;
b[2] = a2;
b[3] = a3;
}
This fixes bad placement of sunk loads.
Bootstrapped / tested on x86_64-unknown-linux-gnu, pushed.
2020-10-08 Richard Biener
PR tree-optimization/97330
* tree-ssa-sink.c (statement_sink_location): Avoid skipping
PHIs when they dominate the insert location.
* g
On Fri, Oct 2, 2020 at 5:51 AM H.J. Lu wrote:
>
> On Wed, Sep 23, 2020 at 10:58 AM H.J. Lu wrote:
> >
> > For sources which can't use any vector instructions, and
> > cannot be included for compiler intrinsics:
> >
> > $ echo "#include " | gcc -S -O2 -mno-sse -mno-mmx -x c -
> > In file include
Dear GCC,
This patch adds macros to the general preprocessor that allow
users to understand what the execution and wide execution charsets
are, which are used for "bark" and L"meow" literals in C-family
languages.
The goal of this is to enable individuals in capable languages
like C and
On Wed, Oct 7, 2020 at 7:15 PM Alexandre Oliva wrote:
>
> On Oct 6, 2020, Richard Biener wrote:
>
> > So how about that mathfn_type helper instead of hard-wring this logic
> > in sincos()?
>
> Like this?
>
> Regstrapped on x86_64-linux-gnu. Ok to install?
OK with a minor nit, see below
> I'm
On Thu, Oct 08, 2020 at 11:37:24AM +, Wilco Dijkstra via Gcc-patches wrote:
> Which optimizations does it enable that aren't possible if the value is
> defined?
See bugzilla. Note other compilers heavily optimize on those builtins
undefined at value zero.
> > We just should make sure that w
Hi Jakub,
> Having it undefined allows optimizations, and has been that way for years.
Which optimizations does it enable that aren't possible if the value is defined?
> We just should make sure that we optimize code like x ? __builtin_c[lt]z (x)
> : 32;
> etc. properly (and I believe we do).
This adjusts BB vectorization testcases to look for the number of
SLP subgraphs vectorized rather than for the number of basic blocks
we've found opportunities in because followup patches will play
with the granularity we work on, vectorizing multiple basic blocks
at a time.
Together with this, be
I'm going to install the following tested patch.
Thanks,
Martin
gcc/ChangeLog:
* dbgcnt.def (DEBUG_COUNTER): Add ipa_mod_ref debug counter.
* tree-ssa-alias.c (modref_may_conflict): Handle the counter.
---
gcc/dbgcnt.def | 1 +
gcc/tree-ssa-alias.c | 4
2 files chang
Btw for PowerPC is 0..32:
https://www.ibm.com/support/knowledgecenter/ssw_aix_72/assembler/idalangref_cntlzw_instrs.html
Wilco
On Thu, Oct 08, 2020 at 11:22:34AM +, Wilco Dijkstra wrote:
> >> I think a better way forward would be to make the builtin_clz/ctz more
> >> defined.
> >> Having undefined values is a source of unnecessary bugs given practically
> >> all
> >> modern targets return the number of bits for the z
Hi Jakub,
>> I think a better way forward would be to make the builtin_clz/ctz more
>> defined.
>> Having undefined values is a source of unnecessary bugs given practically all
>> modern targets return the number of bits for the zero input - it is
>> relatively
>> easy to ensure this on the few
Excerpts from Maciej W. Rozycki's message of October 7, 2020 9:45 pm:
> Correct MIPS I assembly build errors in switchcontext.S:
>
> .../libphobos/libdruntime/config/mips/switchcontext.S: Assembler messages:
> .../libphobos/libdruntime/config/mips/switchcontext.S:50: Error: opcode not
> supported
On Thu, Oct 08, 2020 at 11:04:01AM +, Wilco Dijkstra wrote:
> > Perhaps another way out of this would be document and enforce that
> > __builtin_c[lt]z{,l,ll} etc calls are undefined at zero, but C[TL]Z ifn
> > calls are defined there based on *_DEFINED_VALUE_AT_ZERO (*) == 2, and then
> > we w
Hi Jakub,
> Perhaps another way out of this would be document and enforce that
> __builtin_c[lt]z{,l,ll} etc calls are undefined at zero, but C[TL]Z ifn
> calls are defined there based on *_DEFINED_VALUE_AT_ZERO (*) == 2, and then
> we would need to make sure that e.g. in simplify_count_trailing_z
Hi,
> I am quoting my analysis from the PR. Could an aarch64 expert
> pontificate here?
>
> This test is checking the final assembly for a specific sequence. I
> don't speak aarch64 assembly, but the IL is different coming out of evrp.
The code currently generated is incorrect - you really ne
On Thu, Oct 08, 2020 at 12:22:11PM +0200, Jakub Jelinek via Gcc-patches wrote:
> We have several enhancement reports in bugzilla from Gabriel Ravier on this
> topic I think.
See e.g. PR94801, PR94793, PR95863 on the topic.
Jakub
Ping. The kernel is still broken on AArch64.
On 30/09/2020 11:39, Alex Coplan via Gcc-patches wrote:
> Currently, make_extraction() identifies where we can emit an ASHIFT of
> an extend in place of an extraction, but fails to make the corresponding
> canonicalization/simplification when presented
On Thu, Oct 08, 2020 at 11:58:21AM +0200, Aldy Hernandez via Gcc-patches wrote:
> I am quoting my analysis from the PR. Could an aarch64 expert pontificate
> here?
>
> This test is checking the final assembly for a specific sequence. I don't
> speak aarch64 assembly, but the IL is different comi
On 08/10/2020 10:07, Christophe Lyon via Gcc-patches wrote:
> On Tue, 6 Oct 2020 at 18:02, Richard Earnshaw
> wrote:
>>
>> On 29/09/2020 20:50, Christophe Lyon via Gcc-patches wrote:
>>> When mi_delta is > 255 and -mpure-code is used, we cannot load delta
>>> from code memory (like we do without -
I am quoting my analysis from the PR. Could an aarch64 expert
pontificate here?
This test is checking the final assembly for a specific sequence. I
don't speak aarch64 assembly, but the IL is different coming out of evrp.
The first culprit is this difference in the mergephi1 dump:
_9 =
This was a pasto by yours truly while porting the __builtin code from
vr_values::extract_range_basic.
I've tested Andrew's patch, and pushed it.
Aldy
gcc/ChangeLog:
PR tree-optimization/97325
* gimple-range.cc (gimple_ranger::range_of_builtin_call):
Handle
Bootstrapped and regtested on s390x-redhat-linux. OK for master?
The vector copysign pattern incorrectly assumes that vector
if_then_else operates on bits, not on elements. This can theoretically
mislead the optimizers. Fix by changing it to use bitwise operations,
like commit 2930bb321794 ("PR
This fixes the second testcase in the PR.
I've tested Andrew's patch and pushed it.
Aldy
gcc/ChangeLog:
PR tree-optimization/97315
* range-op.cc (value_range_with_overflow): Change any
non-overflow calculation in which both bounds are
overflo
On Thu, Oct 8, 2020 at 10:22 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> The arm target hook for divmod wasn't prepared to handle constants passed to
> the function.
>
> Fixed thusly, bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?
>
> 2020-10-08 Jakub Jelinek
>
>
This fixes the first testcase in the PR by removing the trap and instead
annotating the listing.
I've tested Andrew's patch and pushed it.
Aldy
Fix PR97315 (part 1 of 2)
gcc/ChangeLog:
PR tree-optimization/97315
* gimple-ssa-evrp.c (hybrid_folder::choose_value
Hi!
The arm target hook for divmod wasn't prepared to handle constants passed to
the function.
Fixed thusly, bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?
2020-10-08 Jakub Jelinek
PR target/97322
* config/arm/arm.c (arm_expand_divmod_libfunc): Pass mode inste
Hi!
The following testcase FAILs, because we don't mark the child OpenMP function
as cfun->calls_alloca when it does call alloca. When optimizing, during DCE we
reset those flags and recompute them again, but with -O0 DCE is not performed.
Fixed by calling notice_special_calls when moving insns
On Tue, 6 Oct 2020 at 18:02, Richard Earnshaw
wrote:
>
> On 29/09/2020 20:50, Christophe Lyon via Gcc-patches wrote:
> > When mi_delta is > 255 and -mpure-code is used, we cannot load delta
> > from code memory (like we do without -mpure-code).
> >
> > This patch builds the value of mi_delta into
libgomp and libatomic might be in use during the build. Thus, ar commands
will failed to add new objetcs to it as the file is considered busy.
Deleting it and recreating it with both architectures fixes that.
libatomic/Changelog:
2020-08-17 Clement Chigot
* config/t-aix: Deleting libatomic befor
Knowing if --enable-libstdcxx-filesystem-ts has been passed to the configure in
the AIX config Makefile would require a lot of change in libstdc++ Makefiles.
Thus,
it's easier to ignore errors when retrieving objects and check their existence
before adding them.
libstdc++/Changelog:
2020-09-22 Cl
Hi,
Using this patch, when using GOMP_DEBUG=1 and launching a kernel in
GOMP_OFFLOAD_run (used by the omp implementation), we see the kernel launch
dimensions:
...
GOMP_OFFLOAD_run: kernel main$_omp_fn$0: \
launch [(teams: 1), 1, 1] [(lanes: 32), (threads: 1), 1]
...
Build on x86_64-linux w
On Thu, 8 Oct 2020, Jan Hubicka wrote:
> Hi,
> this is fix I am testing (it solved the testcase)
LGTM
> gcc/ChangeLog:
>
> 2020-10-08 Jan Hubicka
>
> * ipa-modref.c (get_access): Fix handling of offsets.
> * tree-ssa-alias.c (modref_may_conflict): Watch for overflows.
>
> diff
Hi,
this is fix I am testing (it solved the testcase)
gcc/ChangeLog:
2020-10-08 Jan Hubicka
* ipa-modref.c (get_access): Fix handling of offsets.
* tree-ssa-alias.c (modref_may_conflict): Watch for overflows.
diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index a5fa33a35de.
86 matches
Mail list logo
