> +
> +struct S {
> + int : 31;
> +#if __BITINT_MAXWIDTH__ >= 129
> + _BitInt(129) b : 129;
> +#else
> + _BitInt(63) b : 63;
> +#endif
> +} s;
> +
> +void
> +foo (int a)
> +{
> + s.b <<= a;
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
On Fri, Mar 15, 2024 at 11:31 AM Thomas Neumann
wrote:
>
> Original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
> Given that this is a regression, is this okay for gcc 13 and mainline?
It does look straightforward but I hope Jason or Florian can provide the ACK.
Thanks,
https://gcc.gnu.org/g:6a55e39bdb1fdb570730c08413ebbe744e493411
commit r14-9565-g6a55e39bdb1fdb570730c08413ebbe744e493411
Author: Richard Biener
Date: Tue Mar 19 15:25:16 2024 +0100
middle-end/113396 - int128 array index and value-ranges
The following fixes bogus truncation
On Wed, 20 Mar 2024, Hao Liu OS wrote:
> Hi Richard,
>
> As mentioned in the comments of PR114322 (which has been fixed by PR114151
> r14-9540-ge0e9499a), this patch is to cover the case.
>
> Bootstrapped and regression tested on aarch64-linux-gnu, OK for trunk?
>
> gcc/testsuite/ChangeLog:
>
On Tue, 19 Mar 2024, Jakub Jelinek wrote:
> On Tue, Mar 19, 2024 at 03:47:37PM +0100, Richard Biener wrote:
> > The following fixes bogus truncation of a value-range for an int128
> > array index when computing the maximum extent for a variable array
> > reference. Instea
The following fixes bogus truncation of a value-range for an int128
array index when computing the maximum extent for a variable array
reference. Instead of possibly slowing things down by using
widest_int the following makes sure the range bounds fit within
the constraints offset_int were
When SRA analyzes BIT_FIELD_REFs it handles writes and not byte
aligned reads differently from byte aligned reads. Instead of
trying to create replacements for the loaded portion the former
cases try to replace the base object while keeping the wrapping
BIT_FIELD_REFs. This breaks when we have
https://gcc.gnu.org/g:e0e9499aeffdaca88f0f29334384aa5f710a81a4
commit r14-9540-ge0e9499aeffdaca88f0f29334384aa5f710a81a4
Author: Richard Biener
Date: Tue Mar 19 12:24:08 2024 +0100
tree-optimization/114151 - revert PR114074 fix
The following reverts the chrec_fold_multiply fix
The following reverts the chrec_fold_multiply fix and only keeps
handling of constant overflow which keeps the original testcase
fixed. A better solution might involve ranger improvements or
tracking of assumptions during SCEV analysis similar to what niter
analysis does.
Bootstrapped and tested
On Tue, 19 Mar 2024, Jakub Jelinek wrote:
> On Tue, Mar 19, 2024 at 12:54:47PM +0100, Richard Biener wrote:
> > Works for me, but would
> >
> > #undef vec_step
> >
> > work or is it really a keyword in the clang side?
>
> No, it is really keyword.
> #
4-03-08 09:07:29.484624793 +0100
> +++ gcc/system.h 2024-03-19 11:39:18.122700551 +0100
> @@ -1302,6 +1302,12 @@ void gcc_stablesort_r (void *, size_t, s
> #define NULL nullptr
> #endif
>
> +/* Workaround clang on PowerPC which has vec_step as reserved keyword
> + rather t
https://gcc.gnu.org/g:94c3508c5a14d1948fe3bffa9e16c6f3d9c2836a
commit r14-9533-g94c3508c5a14d1948fe3bffa9e16c6f3d9c2836a
Author: Richard Biener
Date: Mon Mar 18 12:39:03 2024 +0100
tree-optimization/114375 - disallow SLP discovery of permuted mask loads
We cannot currently handle
We cannot currently handle permutations of mask loads in code generation
or permute optimization. But we simply drop any permutation on the
floor, so the following instead rejects the SLP build rather than
producing wrong-code. I've also made sure to reject them in
vectorizable_load for
On Mon, Mar 18, 2024 at 12:56 PM Martin Uecker wrote:
>
> Am Montag, dem 18.03.2024 um 11:55 +0100 schrieb Martin Uecker:
> > Am Montag, dem 18.03.2024 um 09:26 +0100 schrieb Richard Biener:
> > > On Mon, Mar 18, 2024 at 8:03 AM Martin Uecker wrote:
> > >
&
On Mon, Mar 18, 2024 at 8:03 AM Martin Uecker wrote:
>
>
> Hi,
>
> can you please take a quick look at this? This is intended to align
> the C standard with existing practice with respect to aliasing by
> removing the special rules for "objects with no declared type" and
> making it fully
On Fri, Mar 15, 2024 at 5:36 PM Andrew Stubbs wrote:
>
> On 15/03/2024 13:56, Tobias Burnus wrote:
> > Hi Andrew,
> >
> > Andrew Stubbs wrote:
> >> This is more-or-less what I was planning to do myself, but as I want
> >> to include all the other features that get parametrized in gcn.cc,
> >>
e, "__FINITE_MATH_ONLY__=%d",
> flag_finite_math_only);
> +
> + if (STRICT_ALIGNMENT)
> +cpp_define (pfile, "__STRICT_ALIGNMENT__");
> }
>
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
> Am 16.03.2024 um 08:24 schrieb Jakub Jelinek :
>
> Hi!
>
> The c23-stdarg-6.c testcase I've added recently apparently works fine with
> -O0 but aborts with -O1 and higher on x86_64-linux.
> The problem is in setup of incoming varargs.
>
> Like function.cc before r14-9249 even
> Am 16.03.2024 um 08:11 schrieb Jakub Jelinek :
>
> Hi!
>
> The verifier requires BIT_FIELD_REFs with INTEGRAL_TYPE_P first operand
> to have mode precision. In most cases for the large/huge _BitInt bitfield
> stores the code uses bitfield representatives, which are typically arrays
> of
On Fri, Mar 15, 2024 at 12:24 PM Andrew Stubbs wrote:
>
> On 15/03/2024 07:35, Richard Biener wrote:
> > On Fri, Mar 15, 2024 at 4:35 AM Hongtao Liu wrote:
> >>
> >> On Thu, Mar 14, 2024 at 11:42 PM Andrew Stubbs wrote:
> >>>
> >>> Don
dg-skip-if "" { ! run_expensive_tests } { "*" } { "-O0" "-O2" } } */
> +/* { dg-skip-if "" { ! run_expensive_tests } { "-flto" } { "" } } */
> +
> +enum E { E22 = 22 } e = E22;
> +
> +_BitInt (5)
> +foo (v
On Fri, Mar 15, 2024 at 6:20 AM Andi Kleen wrote:
>
> Andrew Pinski writes:
>
> > On Thu, Mar 14, 2024 at 9:36 PM Andi Kleen wrote:
> >>
> >>
> >> musttail support for C/C++
> >>
> >> https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643867.html
> >>
> >>
> >> Support constexpr for asm
On Fri, Mar 15, 2024 at 4:35 AM Hongtao Liu wrote:
>
> On Thu, Mar 14, 2024 at 11:42 PM Andrew Stubbs wrote:
> >
> > Don't enable excess lanes when inverting vector bit-masks smaller than the
> > integer mode. This is yet another case of wrong-code due to mishandling
> > of oversized bitmasks.
)
> + return false;
> +}
> + else
> +{
> + if (SSA_NAME_RANGE_INFO (t1))
> + {
> + if (!SSA_NAME_RANGE_INFO (t2))
> + return false;
> + Value_Range r1 (TREE_TYPE (t1));
> + Value_Range r2 (TREE_TYPE (t2));
> +
On Thu, 14 Mar 2024, Jakub Jelinek wrote:
> On Thu, Mar 14, 2024 at 09:59:12AM +0100, Richard Biener wrote:
> > On Thu, 14 Mar 2024, Jakub Jelinek wrote:
> >
> > > On Thu, Mar 14, 2024 at 09:48:45AM +0100, Richard Biener wrote:
> > > > Ugh. OK, but I wonder w
On Thu, Mar 14, 2024 at 11:14 AM Tejas Belagod wrote:
>
>
> Ping.
>
> Thanks,
> Tejas.
>
> On 3/13/24 6:07 PM, Tejas Belagod wrote:
> > Ping!
> >
> > On 3/7/24 4:14 PM, Tejas Belagod wrote:
> >> This patch fixes a bug where vect_recog_abd_pattern called
> >> vect_convert_output
> >> with the
On Thu, 14 Mar 2024, Jakub Jelinek wrote:
> On Thu, Mar 14, 2024 at 09:48:45AM +0100, Richard Biener wrote:
> > Ugh. OK, but I wonder whether we might want to simply delay
> > fixing the CFG for inserts before returns-twice? Would that make
> > things less ugly?
>
>
y)
> +{
> + foo (1);
> + return bar (y);
> +}
> +
> +_BitInt(325)
> +qux (int x, _BitInt(575) y)
> +{
> + if (x == 25)
> +x = foo (2);
> + else if (x == 42)
> +x = foo (foo (3));
> + return bar (y);
> +}
> +
> +void
> +corge (int x, _BitInt(575) y, _BitInt(325) *z)
> +{
> + void *q[] = { &, &, &, & };
> + if (x == 25)
> +{
> +l1:
> + x = foo (2);
> +}
> + else if (x == 42)
> +{
> +l2:
> + x = foo (foo (3));
> +}
> +l3:
> + *z = bar (y);
> + if (x < 4)
> +goto *q[x & 3];
> +}
> +
> +_BitInt(325)
> +freddy (int x, _BitInt(575) y)
> +{
> + bar (y);
> + ++y;
> + if (x == 25)
> +x = foo (2);
> + else if (x == 42)
> +x = foo (foo (3));
> + return bar (y);
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
;
> + *iter = gsi_for_stmt (stmt);
> }
>else
> gsi_insert_before (iter, g, GSI_SAME_STMT);
> @@ -1075,6 +1087,7 @@ gsi_safe_insert_seq_before (gimple_stmt_
> if (g == l)
> break;
> }
> + *iter = gsi_for_stmt (stmt);
> }
>
On Wed, Mar 13, 2024 at 9:27 PM Jeff Law wrote:
>
>
>
> On 3/13/24 4:22 AM, Richard Biener wrote:
>
> >
> > ... this hunk is OK (please test and split it out separatley). In the
> > spirit of
> > moving the stmt the least amount (in this case not
On Wed, Mar 13, 2024 at 3:39 PM Joe Ramsay wrote:
>
> This optimisation does not honour signed zeros, so should not be
> enabled except with -fno-signed-zeros.
>
> OK for master? I do not have commit rights for GCC, so if the patch
> is fine would someone be able to commit for me? The bug is
> Am 13.03.2024 um 16:45 schrieb Jonathan Wakely :
>
> Every year I have to scroll down further and further to the useful part,
> and I'm getting too old to spend my time doing that! :)
>
> I suggested this on IRC and iains agreed. What do others think?
It feels a bit odd. Can we use html
https://gcc.gnu.org/g:86287e0990987d435ba7dfcf9dffbdb3c7ce074d
commit 86287e0990987d435ba7dfcf9dffbdb3c7ce074d
Author: Richard Biener
Date: Wed Mar 13 14:13:00 2024 +0100
Add single-lane SLP support to .GOMP_SIMD_LANE vectorization
The following adds support for single-lane SLP
> } */
> +/* { dg-final { scan-assembler-times "\tbswap\t%\[er]" 2 { target ia32 } } }
> */
> +
> +void
> +foo (unsigned long long x, unsigned char *y)
> +{
> + y[0] = x >> 56;
> + y[1] = x >> 48;
> + y[2] = x >> 40;
> + y[3] = x >&g
On Wed, Mar 13, 2024 at 10:02 AM Ajit Agarwal wrote:
>
> Hello All:
>
> Currently, code sinking will sink code at the use points with loop having same
> nesting depth. The following patch improves code sinking by placing the sunk
> code in immediate dominator with same loop nest depth.
>
>
On Wed, 13 Mar 2024, Jan Hubicka wrote:
> > On Tue, 12 Mar 2024, Jakub Jelinek wrote:
> >
> > > On Tue, Mar 12, 2024 at 05:21:58PM +0100, Jakub Jelinek wrote:
> > > > On Tue, Mar 12, 2024 at 10:46:42AM +0100, Jan Hubicka wrote:
> > > > > I am sorry for delaying this. I made the variant that
256
> +struct S { _BitInt(257) : 257; _BitInt(256) b : 182; } s;
> +
> +__attribute__((noipa)) _BitInt(256)
> +foo (void)
> +{
> + return s.b;
> +}
> +#endif
> +
> +int
> +main ()
> +{
> +#if __BITINT_MAXWIDTH__ >= 256
> + s.b = 1414262180967678524960294186228886540125217087586381431
On Tue, 12 Mar 2024, Jakub Jelinek wrote:
> On Tue, Mar 12, 2024 at 02:31:28PM +0100, Richard Biener wrote:
> > Ah, yeah, I see :/
> >
> > > So, the intention of edge_before_returns_twice_call is just that
> > > it in the common case just finds the non-EDGE_ABN
On Tue, 12 Mar 2024, Jakub Jelinek wrote:
> On Tue, Mar 12, 2024 at 05:21:58PM +0100, Jakub Jelinek wrote:
> > On Tue, Mar 12, 2024 at 10:46:42AM +0100, Jan Hubicka wrote:
> > > I am sorry for delaying this. I made the variant that simply compares
> > > value range of functions and prevents
https://gcc.gnu.org/g:73dac51b32575f980289c073969c6d825963d076
commit r14-9440-g73dac51b32575f980289c073969c6d825963d076
Author: Richard Biener
Date: Tue Mar 12 14:00:05 2024 +0100
tree-optimization/114121 - chrec_fold_{plus,multiply} and recursion
The following addresses endless
The following addresses endless recursion in the
chrec_fold_{plus,multiply} functions when handling sign-conversions.
We only need to apply tricks when we'd fail (there's a chrec in the
converted operand) and we need to make sure to not turn the other
operand into something worse (for the
gt; +{
> + if (x == 25)
> +x = foo (2);
> + else if (x == 42)
> +x = foo (foo (3));
> + *y = bar (*p);
> +}
> +
> +void
> +corge (int x, int *y)
> +{
> + void *q[] = { &, &, &, & };
> + if (x == 25)
> +{
> +l1:
> + x = foo (2);
> +}
> + else if (x == 42)
> +{
> +l2:
> + x = foo (foo (3));
> +}
> +l3:
> + *y = bar (*p);
> + if (x < 4)
> +goto *q[x & 3];
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
On Tue, 12 Mar 2024, Jakub Jelinek wrote:
> On Tue, Mar 12, 2024 at 01:47:53PM +0100, Richard Biener wrote:
> > > Admittedly the above is the ugliest part of the patch IMHO.
> > > It isn't needed in all cases, but e.g. for the pr112709-2.c (qux) case
> > > we have
On Tue, 12 Mar 2024, Jakub Jelinek wrote:
> On Tue, Mar 12, 2024 at 11:42:03AM +0100, Richard Biener wrote:
> > > +static edge
> > > +edge_before_returns_twice_call (basic_block bb)
> > > +{
> > > + gimple_stmt_iterator gsi = gsi_start_nondebu
42;
> + return s;
> +}
> +
> +void
> +baz (struct S *p)
> +{
> + foo (1);
> + *p = bar (0);
> +}
> +
> +void
> +qux (int x, struct S *p)
> +{
> + if (x == 25)
> +x = foo (2);
> + else if (x == 42)
> +x = foo (foo (3));
> + *p = bar (x);
> +}
> +
> +void
> +corge (int x, struct S *p)
> +{
> + void *q[] = { &, &, &, & };
> + if (x == 25)
> +{
> +l1:
> + x = foo (2);
> +}
> + else if (x == 42)
> +{
> +l2:
> + x = foo (foo (3));
> +}
> +l3:
> + *p = bar (x);
> + if (x < 4)
> +goto *q[x & 3];
> +}
> --- gcc/testsuite/gcc.dg/ubsan/pr112709-2.c.jj2024-03-11
> 16:55:37.000378840 +0100
> +++ gcc/testsuite/gcc.dg/ubsan/pr112709-2.c 2024-03-11 17:13:37.517599492
> +0100
> @@ -0,0 +1,50 @@
> +/* PR sanitizer/112709 */
> +/* { dg-do compile } */
> +/* { dg-options "-fsanitize=undefined -O2" } */
> +
> +struct S { char c[1024]; } *p;
> +int foo (int);
> +
> +__attribute__((returns_twice, noipa)) int
> +bar (struct S x)
> +{
> + (void) x.c[0];
> + return 0;
> +}
> +
> +void
> +baz (int *y)
> +{
> + foo (1);
> + *y = bar (*p);
> +}
> +
> +void
> +qux (int x, int *y)
> +{
> + if (x == 25)
> +x = foo (2);
> + else if (x == 42)
> +x = foo (foo (3));
> + *y = bar (*p);
> +}
> +
> +void
> +corge (int x, int *y)
> +{
> + void *q[] = { &, &, &, & };
> + if (x == 25)
> +{
> +l1:
> + x = foo (2);
> +}
> + else if (x == 42)
> +{
> +l2:
> + x = foo (foo (3));
> +}
> +l3:
> + *y = bar (*p);
> + if (x < 4)
> +goto *q[x & 3];
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
> + if (x < 4)
> +goto *q[x & 3];
> +}
> --- gcc/testsuite/g++.dg/asan/pr69276.C.jj2020-01-14 20:02:46.691611212
> +0100
> +++ gcc/testsuite/g++.dg/asan/pr69276.C 2024-03-12 09:09:05.901446463
> +0100
> @@ -35,4 +35,5 @@ int main()
> }
>
> /* { dg-output "ERROR: AddressSanitizer: heap-buffer-overflow.*(\n|\r\n|\r)"
> } */
> -/* { dg-output "#0 0x\[0-9a-f\]+ +in A::A()" } */
> +/* { dg-output "#0 0x\[0-9a-f\]+ +in (A::A\\\(\\\)|vnull::operator
> vec\\\(\\\).*(\n|\r\n|\r)" } */
> +/* { dg-output "#1 0x\[0-9a-f\]+ +in A::A\\\(\\\))" } */
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
+/* PR tree-optimization/114293 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -w" } */
> +
> +int
> +foo (int x)
> +{
> + __builtin_memset (, 5, -1);
> + return __builtin_strlen ((char *) );
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
https://gcc.gnu.org/g:c0c57246d5b47459bdb488734bc2c004a92668b5
commit r14-9435-gc0c57246d5b47459bdb488734bc2c004a92668b5
Author: Richard Biener
Date: Mon Mar 11 14:58:57 2024 +0100
tree-optimization/114297 - SLP reduction with early break fix
The following makes sure to pass
The following makes sure to pass in the SLP node for the live stmts
we are generating the reduction epilogue for to
vect_create_epilog_for_reduction. This follows the previous fix for
the non-SLP path.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
PR
relevant stmt not supported: _3 = *_2;
>
> so I think the tests need to require vect_hw_misalign. This is what
> this patch does.
>
> Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11.
>
> Ok for trunk?
OK.
Thanks,
Richard.
> Rainer
>
>
--
Richard
2;
> /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
> missed: unsupported vect permute { 1 0 3 2 5 4 }
> /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
> missed: unsupported load permutation
> /vol/gcc/src/hg/master/local/gcc/tests
On Mon, 11 Mar 2024, Jakub Jelinek wrote:
> On Mon, Mar 11, 2024 at 11:31:51AM +0100, Richard Biener wrote:
> > On Mon, 11 Mar 2024, Jakub Jelinek wrote:
> >
> > > On Sat, Mar 09, 2024 at 12:25:42PM +0100, Richard Biener wrote:
> > > > Ideally
On Mon, 11 Mar 2024, Jakub Jelinek wrote:
> On Sat, Mar 09, 2024 at 12:25:42PM +0100, Richard Biener wrote:
> > Ideally we?d clear TREE_ADDRESSABLE but set DECL_NOT_GIMPLE_REG,
> > I think the analysis where we check the base would be a more
> > appropriate place to enfor
https://gcc.gnu.org/g:119f5ae0455f02568159eafa9008a555605e7d71
commit r14-9425-g119f5ae0455f02568159eafa9008a555605e7d71
Author: Richard Biener
Date: Mon Mar 11 09:35:07 2024 +0100
middle-end/114299 - missing error recovery from gimplify failure
When internal_get_tmp_var fails
When internal_get_tmp_var fails to gimplify the value the temporary
SSA name is supposed to be initialized with we can leak SSA names
with a NULL SSA_NAME_DEF_STMT into the IL. That's bad, so recover
from this by instead returning a decl in that case.
Bootstrapped and tested on
BitInt(64) b = *(_BitInt(64) *) __builtin_memmove (, p, sizeof
> (_BitInt(64)));
> +}
> +
> +#if __BITINT_MAXWIDTH__ >= 128
> +void
> +bar (void *p)
> +{
> + _BitInt(128) b = *(_BitInt(128) *) __builtin_memmove (, p, sizeof
> (_BitInt(128)));
> +}
> +#endif
>
On Mon, Mar 11, 2024 at 8:46 AM Richard Biener
wrote:
>
> On Sun, Mar 10, 2024 at 10:09 PM Jeff Law wrote:
> >
> >
> >
> > On 3/10/24 3:05 PM, Andrew Pinski wrote:
> > > On Sun, Mar 10, 2024 at 2:04 PM Jeff Law wrote:
> > >>
> > >&
On Sun, Mar 10, 2024 at 10:09 PM Jeff Law wrote:
>
>
>
> On 3/10/24 3:05 PM, Andrew Pinski wrote:
> > On Sun, Mar 10, 2024 at 2:04 PM Jeff Law wrote:
> >>
> >> Here's a potential approach to fixing PR92539, a P2 -Warray-bounds false
> >> positive triggered by loop unrolling.
> >>
> >> As I
On Sat, Mar 9, 2024 at 10:10 AM Alexandre Oliva wrote:
>
>
> The earlier patch for PR112938 arranged for volatile parms to be made
> indirect in internal strub wrapped bodies.
>
> The first problem that remained, more evident, was that the indirected
> parameter remained volatile, despite the
On Fri, Mar 8, 2024 at 6:50 PM Ken Matsui wrote:
>
> On Thu, Mar 7, 2024 at 10:49 PM Richard Biener
> wrote:
> >
> > On Thu, Mar 7, 2024 at 8:29 PM Ken Matsui wrote:
> > >
> > > On Tue, Mar 5, 2024 at 7:58 AM Richard Biener
> > > wrote:
> >
> Am 10.03.2024 um 11:02 schrieb Li, Pan2 :
>
> Committed, thanks Richard.
You might want to investigate why you get mask and not Len for a particular
stmt. mixing will cause variable length vectorization to fail.
> Pan
>
> -Original Message-----
> From: R
> Am 10.03.2024 um 04:14 schrieb pan2...@intel.com:
>
> From: Pan Li
>
> This patch would like to fix one ICE in vectorizable_store when both the
> loop_masks and loop_lens are enabled. The ICE looks like below when build
> with "-march=rv64gcv -O3".
>
> during GIMPLE pass: vect
> test.c:
> Am 09.03.2024 um 09:28 schrieb Jakub Jelinek :
>
> Hi!
>
> The following testcase ICEs, because update-address-taken subpass of
> fre5 rewrites
> _BitInt(128) b;
> vector(16) unsigned char _3;
>
> [local count: 1073741824]:
> _3 = MEM [(char * {ref-all})p_2(D)];
> MEM [(char *
> Am 09.03.2024 um 09:36 schrieb Jakub Jelinek :
>
> Hi!
>
> Before the recent PR111267 r14-8319 fwprop changes, fwprop would never try
> to propagate what was not considered PROFITABLE, where the profitable part
> actually was partly about profitability, partly about very good reasons
> not
On Fri, Mar 8, 2024 at 2:59 PM Richard Biener
wrote:
>
> On Fri, Mar 8, 2024 at 1:04 AM wrote:
> >
> > From: Pan Li
> >
> > This patch would like to fix one ICE in vectorizable_store for both the
> > loop_masks and loop_lens. The ICE looks like
On Fri, Mar 8, 2024 at 1:04 AM wrote:
>
> From: Pan Li
>
> This patch would like to fix one ICE in vectorizable_store for both the
> loop_masks and loop_lens. The ICE looks like below with "-march=rv64gcv -O3".
>
> during GIMPLE pass: vect
> test.c: In function ‘d’:
> test.c:6:6: internal
https://gcc.gnu.org/g:018ddc86b928514d7dfee024dcdeb204d5dcdd61
commit r14-9391-g018ddc86b928514d7dfee024dcdeb204d5dcdd61
Author: Richard Biener
Date: Fri Mar 8 13:27:12 2024 +0100
tree-optimization/114269 - 434.zeusmp regression after SCEV analysis fix
The following addresses
On Fri, 8 Mar 2024, Ren? Rebe wrote:
>
> > On Mar 7, 2024, at 20:08, Richard Biener wrote:
> >
> >> Am 07.03.2024 um 19:09 schrieb Ren? Rebe :
> >>
> >> Hey there,
> >>
> >> I saw the deprecation of ia64*-*-* scrolling by [1].
&
The following addresses a performance regression caused by the recent
SCEV analysis fix with regard to folding multiplications and undefined
behavior on overflow. We do not handle (T) { a, +, b } * c but can
treat sign-conversions from unsigned by performing the multiplication
in the unsigned
> + return AI();
> +}
> +}
> +
> +N1::N2::N3::AB ab;
> +
> +N1::N2::N3::AB &
> +N1::N2::N3::AB::bleh()
> +{
> + return ab;
> +}
> +
> +N1::N2::N3::AC::AC(int)
> +{
> +}
> +
> +void
> +N1::N2::N3::AC::m1(R::S)
> +{
> +}
> +
> +#ifndef SHARED
> +int
> +main()
> +{
> +}
> +#endif
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
RN (j)));
> +&& (asm_noperands (PATTERN (j))
> +> 0));
> edge e2 = find_edge (cur_bb, e->dest);
> if (e2)
> e2->flags
The testcase only XFAILs on targets where int has an alignment
of sizeof(int). Align the respective array this way to make it
XFAIL consistenlty.
Tested on x86_64-unknown-linux-gnu and cris-elf. Pushed.
PR testsuite/108355
* gcc.dg/tree-ssa/ssa-fre-104.c: Align e.
---
https://gcc.gnu.org/g:0bd04d9ae2d5447fd11fa43db20371140e955eff
commit r14-9382-g0bd04d9ae2d5447fd11fa43db20371140e955eff
Author: Richard Biener
Date: Fri Mar 8 08:26:15 2024 +0100
testsuite/108355 - make gcc.dg/tree-ssa/ssa-fre-104.c properly XFAIL
The testcase only XFAILs
On Thu, 7 Mar 2024, Richard Sandiford wrote:
> Sorry, still catching up on email, but:
>
> Richard Biener writes:
> > We have optimize_vectors_before_lowering_p but we shouldn't even there
> > turn supported into not supported ops and as said, what's supported or
>
> Am 07.03.2024 um 19:09 schrieb René Rebe :
>
> Hey there,
>
> I saw the deprecation of ia64*-*-* scrolling by [1].
>
> Which surprised me, as (minor bugs aside) gcc ia64*-*-linux just works for us
> and
> we still actively support it as part of our T2 System Development Environment
>
On Thu, Mar 7, 2024 at 8:29 PM Ken Matsui wrote:
>
> On Tue, Mar 5, 2024 at 7:58 AM Richard Biener
> wrote:
> >
> > On Tue, Mar 5, 2024 at 1:51 PM Ken Matsui wrote:
> > >
> > > On Tue, Mar 5, 2024 at 12:38 AM Richard Biener
> > > wrote:
> >
https://gcc.gnu.org/g:e2bef5c639ab5a1b519b738cf67a03b85432d5dd
commit e2bef5c639ab5a1b519b738cf67a03b85432d5dd
Author: Richard Biener
Date: Thu Mar 7 15:36:00 2024 +0100
Fix last commit WRT patterns
* tree-vect-slp.cc (vect_analyze_slp): Look at the pattern
https://gcc.gnu.org/g:fa45f8f652fc050336ea80783c5b195b5bc1f40e
commit fa45f8f652fc050336ea80783c5b195b5bc1f40e
Author: Richard Biener
Date: Thu Mar 7 15:13:33 2024 +0100
Handle unused-only-live stmts in SLP discovery
The following adds SLP discovery for roots that are only live
On Thu, Mar 7, 2024 at 1:25 PM Robin Dapp wrote:
>
> Attached v2 combines the checks.
>
> Bootstrapped and regtested on x86 an power10, aarch64 still running.
> Regtested on riscv64.
LGTM.
> Regards
> Robin
>
>
> Subject: [PATCH v2] vect: Do not peel epilogue for partial vectors.
>
>
On Thu, 7 Mar 2024, Jakub Jelinek wrote:
> On Thu, Mar 07, 2024 at 11:11:35AM +0100, Uros Bizjak wrote:
> > > Since you CCed me - looking at the code I wonder why we fatally fail.
> > > The following might also fix the issue and preserve more of the
> > > rest of the flow of the function.
> > >
>
On Thu, 7 Mar 2024, Uros Bizjak wrote:
> On Thu, Mar 7, 2024 at 10:56?AM Richard Biener wrote:
> >
> > On Thu, 7 Mar 2024, Uros Bizjak wrote:
> >
> > > The compiler, configured with --enable-checking=yes,rtl,extra ICEs with:
> > >
> > > internal c
On Thu, 7 Mar 2024, Uros Bizjak wrote:
> The compiler, configured with --enable-checking=yes,rtl,extra ICEs with:
>
> internal compiler error: RTL check: expected elt 0 type 'e' or 'u',
> have 'E' (rtx unspec) in try_combine, at combine.cc:3237
>
> This is
>
> 3236 /* Just replace
cc1_plugin;
> >
> >
> > diff --git a/libcc1/libcp1plugin.cc b/libcc1/libcp1plugin.cc
> > index 0eff7c68d29..da68c5d0ac1 100644
> > --- a/libcc1/libcp1plugin.cc
> > +++ b/libcc1/libcp1plugin.cc
> > @@ -33,6 +33,7 @@
> > #undef PACKAGE_VERSION
> &g
+ bar ("");
> + asm goto ("" : : : : l2);
> + asm ("");
> +l2:
> + goto l1;
> +}
> +
> +void
> +qux (void)
> +{
> + asm goto ("" : : : : l1);
> + bar ("");
> + goto l1;
> +l1:
> + baz ("");
> +}
> +
> +void
> +corge (void)
> +{
> + asm goto ("" : : : : l1);
> + baz ("");
> +l2:
> + return;
> +l1:
> + bar ("");
> + goto l2;
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
; +++ gcc/testsuite/gcc.dg/pr105533.c 2024-03-06 16:03:26.226084751 +0100
> @@ -0,0 +1,9 @@
> +/* PR middle-end/105533 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +long long
> +foo (long long x, long long y)
> +{
> + return ((x < 0) & (y !=
On Wed, Mar 6, 2024 at 9:21 PM Robin Dapp wrote:
>
> Hi,
>
> r14-7036-gcbf569486b2dec added an epilogue vectorization guard for early
> break but PR114196 shows that we also run into the problem without early
> break. Therefore remove early break from the conditions.
>
> gcc/ChangeLog:
>
>
21,7 @@ ao_ref_init_from_vn_reference (ao_ref *r
> if (maybe_eq (op->off, -1))
> max_size = -1;
> else
> - offset += op->off << LOG2_BITS_PER_UNIT;
> + offset += op->off * BITS_PER_UNIT;
> break;
>
>
; {
> sint64_t mul = a * b;
>
> return mul >= (sint64_t)INT32_MIN && mul <= (sint64_t)INT32_MAX ?
> (sint32_t)mul : INT32_MAX + ((x ^ y) < 0);
> }
>
> uint32_t sat_udiv (uint32_t a, uint32_t b)
> {
> return a / b; // never overflow
> }
>
> sint32
On Wed, Mar 6, 2024 at 10:56 PM Morten Linderud wrote:
>
> I've made an attempt at patching this issue as it produces unreproducible
> unreproducible binaries for Golang. I don't know C/C++ and it's my first gcc
> patch so please bear with me :)
I think this is a very fragile area - see
https://gcc.gnu.org/g:d1b89155e4bc4f42a06a36b64208216e5d37e779
commit d1b89155e4bc4f42a06a36b64208216e5d37e779
Author: Richard Biener
Date: Wed Mar 6 15:13:05 2024 +0100
Avoid bogus SLP outer loop vectorization
This fixes the check for multiple types which go wrong I think
On Wed, 6 Mar 2024, Jakub Jelinek wrote:
> On Wed, Mar 06, 2024 at 11:45:42AM +0100, Richard Biener wrote:
> > OK, though feel free to add ARG_UNUSED to 'captures' as well.
>
> Ok, done below.
>
> > I think the INTEGRAL_TYPE_P should be redundant - the pattern
>
On Wed, 6 Mar 2024, Andrew Stubbs wrote:
> On 06/03/2024 12:09, Thomas Schwinge wrote:
> > Hi!
> >
> > On 2024-02-21T17:32:13+0100, Richard Biener wrote:
> >> Am 21.02.2024 um 13:34 schrieb Thomas Schwinge :
> >>> [...] per my work on <https://gcc.gn
https://gcc.gnu.org/g:89c443a7e9a0780a52a698fb02d4f5173e025918
commit r14-9335-g89c443a7e9a0780a52a698fb02d4f5173e025918
Author: Richard Biener
Date: Wed Mar 6 10:31:02 2024 +0100
tree-optimization/114239 - rework reduction epilogue driving
The following reworks
The following reworks vectorizable_live_operation to pass the
live stmt to vect_create_epilog_for_reduction also for early breaks
and a peeled main exit. This is to be able to figure the scalar
definition to replace. This reverts the PR114192 fix as it is
subsumed by this cleanup.
Bootstrapped
41.274541636 +0100
> +++ gcc/testsuite/gcc.dg/tree-ssa/pr114009.c 2024-03-05 15:16:09.056589675
> +0100
> @@ -0,0 +1,24 @@
> +/* PR tree-optimization/114009 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-optimized" } */
> +/* { dg-final { scan-tree-
The following makes sure to strip type conversions added by
build_fold_addr_expr before placing the result in a call argument.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/114246
* tree-ssa-dse.cc (increment_start_addr): Strip useless
https://gcc.gnu.org/g:3a910114fdb2aa76495c4c748acf6b9c7fbecc89
commit r14-9331-g3a910114fdb2aa76495c4c748acf6b9c7fbecc89
Author: Richard Biener
Date: Wed Mar 6 09:25:15 2024 +0100
tree-optimization/114249 - ICE with BB reduction vectorization
When we scrap the last def of an odd
https://gcc.gnu.org/g:0249744a9fe0775c2c895727aeebec4c59fd5f95
commit r14-9330-g0249744a9fe0775c2c895727aeebec4c59fd5f95
Author: Richard Biener
Date: Wed Mar 6 09:02:31 2024 +0100
tree-optimization/114246 - invalid call argument from DSE
The following makes sure to strip type
When we scrap the last def of an odd lane numbered BB reduction
we can end up recording a pattern def which will later wreck
code generation. The following puts this logic where it better
belongs, avoiding this issue.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR
On Tue, Mar 5, 2024 at 1:51 PM Ken Matsui wrote:
>
> On Tue, Mar 5, 2024 at 12:38 AM Richard Biener
> wrote:
> >
> > On Mon, Mar 4, 2024 at 9:40 PM Ken Matsui wrote:
> > >
> > > (x - y) CMP 0 is equivalent to x CMP y where x and y are signed
> > >
901 - 1000 of 28319 matches
Mail list logo
