Re: [PATCH] fold-const: Avoid (cast) ((cast2) x p+ y) folding for -fsanitize=alignment [PR98206]

On December 30, 2020 10:30:33 AM GMT+01:00, Jakub Jelinek wrote: >Hi! > >The following testcase is diagnosed by UBSan as invalid, even when it >is >valid. >We have a derived type Base2 at offset 1 with alignment 1 and do: >(const Derived &) ((const Base2 *) this + -1) >but the folder before ubsan

Re: [PATCH] reassoc: Optimize x > 0x1fff || y > 0x1fff into (x | y) > 0x1fff [PR56719]

On December 30, 2020 10:18:52 AM GMT+01:00, Jakub Jelinek wrote: >Hi! > >The following patch adds an optimization mentioned in PR56719 #c8. >We already have the x != 0 && y != 0 && z != 0 into (x | y | z) != 0 >and x != -1 && y != -1 && y != -1 into (x & y & z) != -1 >optimizations, this patch ju

Re: [PATCH] i386: Remove unnecessary clobbers from combine splitters.

Hi Uros, On Wed, Dec 30, 2020 at 05:44:50PM +0100, Uros Bizjak via Gcc-patches wrote: > There is no need for combine splitters to emit insn patterns with clobbers, > the pass is smart enough to add clobbers to patterns as necessary. Nice. Just one thing: in principle the splitters can be used ou

Re: [PATCH] i386: Remove unnecessary clobbers from combine splitters.

On Thu, Dec 31, 2020 at 9:40 AM Segher Boessenkool wrote: > > Hi Uros, > > On Wed, Dec 30, 2020 at 05:44:50PM +0100, Uros Bizjak via Gcc-patches wrote: > > There is no need for combine splitters to emit insn patterns with clobbers, > > the pass is smart enough to add clobbers to patterns as necess

Re: Fix VxWorks xfail filters on pthread-init-?.c

On Dec 29, 2020, Mike Stump wrote: > On Dec 22, 2020, at 1:34 PM, Alexandre Oliva wrote: >> Match xfail on kernel instead of rtp mode. >> >> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. >> Ok to install? > Ok. Thanks > Longer term, would be nice to fix includes the

[PATCH] wide-int: Fix wi::to_mpz [PR98474]

Hi! The following testcase is miscompiled, because niter analysis miscomputes the number of iterations to 0. The problem is that niter analysis uses mpz_t (wonder why, wouldn't widest_int do the same job?) and when wi::to_mpz is called e.g. on the TYPE_MAX_VALUE of __uint128_t, it initializes the

[PATCH] match.pd: Add (-(X < 0) | 1) * X -> abs (X) etc. simplifications [PR94785]

Hi! The following patch adds two simplifications to recognize idioms for ABS_EXPR resp. ABSU_EXPR. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2020-12-31 Jakub Jelinek PR tree-optimization/94785 * match.pd ((-(X < 0) | 1) * X -> abs (X)): New simplifi

[PATCH] match.pd: Add clz(X) == 0 -> (int)X < 0 etc. simpifications [PR94802]

Hi! The following patch adds some clz simplifications. If clz is 0, then the MSB of the argument is set, and if clz is prec-1, then the argument is 1. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2020-12-31 Jakub Jelinek PR tree-optimization/94802 * m

Re: [PATCH] wide-int: Fix wi::to_mpz [PR98474]

On December 31, 2020 10:31:00 AM GMT+01:00, Jakub Jelinek wrote: >Hi! > >The following testcase is miscompiled, because niter analysis >miscomputes >the number of iterations to 0. >The problem is that niter analysis uses mpz_t (wonder why, wouldn't >widest_int do the same job?) The mpz use preda

Re: [PATCH] match.pd: Add (-(X < 0) | 1) * X -> abs (X) etc. simplifications [PR94785]

On December 31, 2020 10:34:34 AM GMT+01:00, Jakub Jelinek wrote: >Hi! > >The following patch adds two simplifications to recognize idioms >for ABS_EXPR resp. ABSU_EXPR. > >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Ok. Richard. >2020-12-31 Jakub Jelinek > >

Re: [PATCH] match.pd: Add clz(X) == 0 -> (int)X < 0 etc. simpifications [PR94802]

On December 31, 2020 10:37:46 AM GMT+01:00, Jakub Jelinek wrote: >Hi! > >The following patch adds some clz simplifications. If >clz is 0, then the MSB of the argument is set, and if clz is prec-1, >then >the argument is 1. > >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Re: [PATCH] sccvn: Consider def BB in rpo_vn_valueize [PR98464]

On December 31, 2020 8:02:37 AM GMT+01:00, "Kewen.Lin" wrote: >Hi, > >As PR98464 shows, this patch is to make rpo_vn_valueize >consider the definition basic block of name, to sync >with what we do in function eliminate_stmt. > >Bootstrapped/regtested on powerpc64le-linux-gnu P9. > >Full SPEC2017

Re: libgo patch committed: Update to Go1.16beta1 release

I'm getting this error in ia64: ../../../libgo/go/internal/cpu/cpu.go:123:9: error: reference to undefined name 'doinit' 123 | doinit() | ^ make[4]: *** [internal/cpu.lo] Error 1 Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69

Re: libgo patch committed: Update to Go1.16beta1 release

On 12/31/20 11:12 AM, Andreas Schwab wrote: > I'm getting this error in ia64: > > ../../../libgo/go/internal/cpu/cpu.go:123:9: error: reference to undefined > name 'doinit' > 123 | doinit() > | ^ > make[4]: *** [internal/cpu.lo] Error 1 > > Andreas. > also on x32, or wi

Re: libgo patch committed: Update to Go1.16beta1 release

On 12/31/20 11:36 AM, Matthias Klose wrote: > On 12/31/20 11:12 AM, Andreas Schwab wrote: >> I'm getting this error in ia64: >> >> ../../../libgo/go/internal/cpu/cpu.go:123:9: error: reference to undefined >> name 'doinit' >> 123 | doinit() >> | ^ >> make[4]: *** [internal/

Re: libgo patch committed: Update to Go1.16beta1 release

On Dez 31 2020, Andreas Schwab wrote: > I'm getting this error in ia64: > > ../../../libgo/go/internal/cpu/cpu.go:123:9: error: reference to undefined > name 'doinit' > 123 | doinit() > | ^ > make[4]: *** [internal/cpu.lo] Error 1 ../../../libgo/go/golang.org/x/sys/cpu/cp

Re: [PATCH] i386: Remove unnecessary clobbers from combine splitters.

Hi! On Thu, Dec 31, 2020 at 09:54:01AM +0100, Uros Bizjak wrote: > On Thu, Dec 31, 2020 at 9:40 AM Segher Boessenkool > wrote: > > Nice. Just one thing: in principle the splitters can be used outside of > > combine, too? This can lead to insns that do not recog() then? Is > > there anything th

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

On Wed, 30 Dec 2020 at 05:41, Jeff Law wrote: > > > On 12/23/20 9:01 AM, abebeos wrote: > > > > > > On Sun, 13 Dec 2020 at 20:14, abebeos > +abeb...@gmail.com > > > wrote: > > > > > > > > On Fri, 11 Dec 2020 at 20:32, Jeff Law >

Re: [PATCH] i386: Remove unnecessary clobbers from combine splitters.

On Thu, Dec 31, 2020 at 1:29 PM Segher Boessenkool wrote: > > Hi! > > On Thu, Dec 31, 2020 at 09:54:01AM +0100, Uros Bizjak wrote: > > On Thu, Dec 31, 2020 at 9:40 AM Segher Boessenkool > > wrote: > > > Nice. Just one thing: in principle the splitters can be used outside of > > > combine, too?

Re: libgo patch committed: Update to Go1.16beta1 release

On 12/31/20 12:14 AM, Ian Lance Taylor via Gcc-patches wrote: > I've committed a patch to update libgo to the Go 1.16beta1 release. > > This patch does not include support for the new //go:embed directive > that will be available in Go 1.16.1 (https://golang.org/issue/41191) > Support for that req

[PATCH] vect: Fix bogus alignment assumption in alias checks [PR94994]

This PR is about a case in which the vectoriser was feeding incorrect alignment information to tree-data-ref.c, leading to incorrect runtime alias checks. The alignment was taken from the TREE_TYPE of the DR_REF, which in this case was a COMPONENT_REF with a normally-aligned type. However, the un

[PATCH] recog: Fix a constrain_operands corner case [PR97144]

aarch64's *add3_poly_1 has a pattern with the constraints: "=...,r,&r" "...,0,rk" "...,Uai,Uat" i.e. the penultimate alternative requires operands 0 and 1 to match, but the final alternative does not allow them to match. The register allocators dealt with this correctly, and so used differ

[PATCH] vect: Avoid generating out-of-range shifts [PR98302]

In this testcase we end up with: unsigned long long x = ...; char y = (char) (x << 37); The overwidening pattern realised that only the low 8 bits of x << 37 are needed, but then tried to turn that into: unsigned long long x = ...; char y = (char) x << 37; which gives an out-of-range sh

Re: [PATCH] recog: Fix a constrain_operands corner case [PR97144]

On Thu, Dec 31, 2020 at 7:57 AM Richard Sandiford via Gcc-patches wrote: > > aarch64's *add3_poly_1 has a pattern with the constraints: > > "=...,r,&r" > "...,0,rk" > "...,Uai,Uat" > > i.e. the penultimate alternative requires operands 0 and 1 to match, > but the final alternative does not a

[pushed] genmodes: Update GET_MODE_MASK when changing NUNITS [PR98214]

The static GET_MODE_MASKs for SVE vectors are based on the static precisions, which in turn are based on 128-bit SVE. The precisions are later updated based on -msve-vector-bits (usually to become variable length), but the GET_MODE_MASK stayed the same. This caused combine to fold: (*_extract:D

Re: [PATCH] recog: Fix a constrain_operands corner case [PR97144]

"H.J. Lu" writes: > On Thu, Dec 31, 2020 at 7:57 AM Richard Sandiford via Gcc-patches > wrote: >> >> aarch64's *add3_poly_1 has a pattern with the constraints: >> >> "=...,r,&r" >> "...,0,rk" >> "...,Uai,Uat" >> >> i.e. the penultimate alternative requires operands 0 and 1 to match, >> but

Re: [PATCH] recog: Fix a constrain_operands corner case [PR97144]

On Thu, Dec 31, 2020 at 8:21 AM Richard Sandiford wrote: > > "H.J. Lu" writes: > > On Thu, Dec 31, 2020 at 7:57 AM Richard Sandiford via Gcc-patches > > wrote: > >> > >> aarch64's *add3_poly_1 has a pattern with the constraints: > >> > >> "=...,r,&r" > >> "...,0,rk" > >> "...,Uai,Uat" > >>

Re: [PATCH] i386: Remove unnecessary clobbers from combine splitters.

Segher Boessenkool writes: > It isn't likely that any other pass would try to create this pattern, > but this isn't guaranteed, and such other passes do not necessarily do > the add-the-clobber (that is specific to combine, even!) Maybe fwprop > could create this insn, or something like Richard's

Re: [PATCH] vect: Fix bogus alignment assumption in alias checks [PR94994]

On December 31, 2020 4:51:26 PM GMT+01:00, Richard Sandiford wrote: >This PR is about a case in which the vectoriser was feeding >incorrect alignment information to tree-data-ref.c, leading >to incorrect runtime alias checks. The alignment was taken >from the TREE_TYPE of the DR_REF, which in th

Re: [PATCH] vect: Avoid generating out-of-range shifts [PR98302]

On December 31, 2020 5:06:36 PM GMT+01:00, Richard Sandiford wrote: >In this testcase we end up with: > > unsigned long long x = ...; > char y = (char) (x << 37); > >The overwidening pattern realised that only the low 8 bits >of x << 37 are needed, but then tried to turn that into: > > unsigne

Re: [PATCH] i386: Remove unnecessary clobbers from combine splitters.

On Thu, Dec 31, 2020 at 04:39:52PM +, Richard Sandiford wrote: > Segher Boessenkool writes: > > It isn't likely that any other pass would try to create this pattern, > > but this isn't guaranteed, and such other passes do not necessarily do > > the add-the-clobber (that is specific to combine,

Re: libgo patch committed: Update to Go1.16beta1 release

Hi Ian, > I've committed a patch to update libgo to the Go 1.16beta1 release. > > This patch does not include support for the new //go:embed directive > that will be available in Go 1.16.1 (https://golang.org/issue/41191) > Support for that requires compiler changes, which will come later. > > As

[PATCH] MIPS: Fix PR target/98491

An invalid use of MSA_SUPPORTED_MODE_P is causing ICE on mips64el with -mmsa. The detailed analysis is posted on bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98491 The attached patch fixes this issue by handling the special case of MSA_SUPPORTED_MODE_P explicitly. Please keep me in CC

Re: [PATCH] MIPS: Fix PR target/98491 (ChangeLog)

On 2021-01-01 07:29 +0800, Xi Ruoyao wrote: > An invalid use of MSA_SUPPORTED_MODE_P is causing ICE on mips64el with -mmsa. > The detailed analysis is posted on bugzilla: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98491 > > The attached patch fixes this issue by handling the special case of

Re: V3 [PATCH 5/5] gnulib: Support variables from the top level Makefile

On Sat, 19 Dec 2020, H.J. Lu via Gcc-patches wrote: > Work around what appears to be a GNU make bug handling MAKEFLAGS > values defined in terms of make variables, as is the case for CC and > friends when we are called from the top level Makefile. This description, and the comment in Makefile.am

Re: [C PATCH] qualifiers of pointers to arrays in C2X [PR 98397]

On Mon, 21 Dec 2020, Uecker, Martin wrote: > diff --git a/gcc/testsuite/gcc.dg/c2x-qual-1.c > b/gcc/testsuite/gcc.dg/c2x-qual-1.c > new file mode 100644 > index 000..058a840e04c > --- /dev/null > +++ b/gcc/testsuite/gcc.dg/c2x-qual-1.c > @@ -0,0 +1,12 @@ > +/* Test that qualifiers are not

Re: V3 [PATCH 5/5] gnulib: Support variables from the top level Makefile

On Thu, Dec 31, 2020 at 3:50 PM Joseph Myers wrote: > > On Sat, 19 Dec 2020, H.J. Lu via Gcc-patches wrote: > > > Work around what appears to be a GNU make bug handling MAKEFLAGS > > values defined in terms of make variables, as is the case for CC and > > friends when we are called from the top le