[Bug rtl-optimization/116244] [15 Regression] reload ICE building libstdc++ for coldfire

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116244

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Any progress on this?
Should it be P1 when it only affects non-primary/secondary target?

[Bug tree-optimization/118669] Misaligned store after vectorization without using misaligned type with SVE

[rguenther at suse dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669

--- Comment #8 from rguenther at suse dot de  ---
On Mon, 27 Jan 2025, rsandifo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669
> 
> Richard Sandiford  changed:
> 
>What|Removed |Added
> 
>Keywords|wrong-code  |internal-improvement
>Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
> gnu.org
>  Status|NEW |ASSIGNED
> 
> --- Comment #7 from Richard Sandiford  ---
> diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
> index c0550acf6b2..06cd6e42355 100644
> --- a/gcc/tree-vect-stmts.cc
> +++ b/gcc/tree-vect-stmts.cc
> @@ -9908,7 +9908,8 @@ vectorizable_store (vec_info *vinfo,
> = fold_build2 (MEM_REF, vectype, dataref_ptr,
>dataref_offset ? dataref_offset
>   : build_int_cst (ref_type, 0));
> - if (alignment_support_scheme == dr_aligned)
> + if (alignment_support_scheme == dr_aligned
> + && align >= TYPE_ALIGN_UNIT (vectype))
> ;
>   else
> TREE_TYPE (data_ref)
> 
> seems to fix it.  (Loads will need similar treatment.)
> 
> The justification is that preferred_vector_alignment requests element 
> alignment
> for SVE, even though the vector mode itself has 128-bit alignment.  In that
> context, dr_aligned means that element alignment has been reached.

Hmm, indeed.  We support "alignment" different from mode/type alignment.
But we're also using 'dr_aligned' to indicate there cannot be a fault
when accessing the vector which would be not sufficient either in this
case.  So I think there's a deeper issue with this misunderstanding of
what 'dr_alignment' meands.

> It looks like a long-standing issue, so I suppose it should wait for GCC 16.

Not sure - this is definitely wrong-code.

[Bug tree-optimization/118650] `(even + unknown) & 1` is not optimized to just `unknown & 1` at gimple level

[rsandifo at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118650

Richard Sandiford  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #5 from Richard Sandiford  ---
(In reply to Richard Biener from comment #4)
> maybe also a thing for SSA backprop?  Eliminating ops that only affect bits
> masked by &?  Or ops that only affect bits added by |?
Yeah, did get some way to implementing that a while back, but it didn't seem to
trigger very often, so I gave up on it :)  Maybe worth trying again…

[Bug middle-end/115913] [12/13/14/15 Regression] ICE with pragma GCC pop_options with diagnostic since r11-1141

[lhyatt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115913

Lewis Hyatt  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2025-January
   ||/674568.html
   Keywords||patch

--- Comment #11 from Lewis Hyatt  ---
Here is a patch to skip CL_WARNING options from the check:
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674568.html

[Bug middle-end/118643] [15 Regression] Crash at -O3 during RTL pass: expand since r15-7171

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118643

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:52366356fe7b638f66c4011b8a61fb6c22b08087

commit r15-7226-g52366356fe7b638f66c4011b8a61fb6c22b08087
Author: Richard Biener 
Date:   Mon Jan 27 11:28:47 2025 +0100

middle-end/118643 - ICE with out-of-bound decl access

When RTL expansion of an out-of-bound access of a register falls
back to a BIT_FIELD_REF we have to ensure that's valid.  The
following avoids negative offsets by expanding through a stack
temporary.

PR middle-end/118643
* expr.cc (expand_expr_real_1): Avoid falling back to BIT_FIELD_REF
expansion for negative offset.

* gcc.dg/pr118643.c: New testcase.

[Bug tree-optimization/112859] [12/13/14/15 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-2097-g9f34b780b0461e

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112859

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:04ba1300407f106a6dd10d346f58a51d87e6d43e

commit r15-7225-g04ba1300407f106a6dd10d346f58a51d87e6d43e
Author: Richard Biener 
Date:   Thu Jan 23 13:10:17 2025 +0100

tree-optimization/112859 - bogus loop distribution

When we get a zero distance vector we still have to check for the
situation of a common inner loop with zero distance.  But we can
still allow a zero distance for the loop we distribute
(gcc.dg/tree-ssa/ldist-33.c is such a case).  This is because
zero distances in non-outermost loops are a misrepresentation
of dependence by dependence analysis.

Note that test coverage of loop distribution of loop nests is
very low.

PR tree-optimization/112859
PR tree-optimization/115347
* tree-loop-distribution.cc
(loop_distribution::pg_add_dependence_edges): For a zero
distance vector still make sure to not have an inner
loop with zero distance.

* gcc.dg/torture/pr112859.c: New testcase.
* gcc.dg/torture/pr115347.c: Likewise.

[Bug tree-optimization/115347] [12/13/14/15 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-2097

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115347

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:04ba1300407f106a6dd10d346f58a51d87e6d43e

commit r15-7225-g04ba1300407f106a6dd10d346f58a51d87e6d43e
Author: Richard Biener 
Date:   Thu Jan 23 13:10:17 2025 +0100

tree-optimization/112859 - bogus loop distribution

When we get a zero distance vector we still have to check for the
situation of a common inner loop with zero distance.  But we can
still allow a zero distance for the loop we distribute
(gcc.dg/tree-ssa/ldist-33.c is such a case).  This is because
zero distances in non-outermost loops are a misrepresentation
of dependence by dependence analysis.

Note that test coverage of loop distribution of loop nests is
very low.

PR tree-optimization/112859
PR tree-optimization/115347
* tree-loop-distribution.cc
(loop_distribution::pg_add_dependence_edges): For a zero
distance vector still make sure to not have an inner
loop with zero distance.

* gcc.dg/torture/pr112859.c: New testcase.
* gcc.dg/torture/pr115347.c: Likewise.

[Bug middle-end/118643] [15 Regression] Crash at -O3 during RTL pass: expand since r15-7171

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118643

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Richard Biener  ---
Fixed - I do wonder why this doesn't fail on branches, we still have the same

V foo (V v)
{
  V _2;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  _2 = MEM[(V *)&v + -1B];
  return _2;

there upon RTL expansion.  Ah, it's because tree_could_trap_p now uses
bit_field_offset, the very problem is on branches as well (maybe it's no
problem after all).

[Bug libstdc++/118563] [15 regression] libstdc++ incompatible ABI change on riscv64

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118563

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Andreas Schwab :

https://gcc.gnu.org/g:c6977f765838a5ca8d321d916221a7368622bdd9

commit r15-7228-gc6977f765838a5ca8d321d916221a7368622bdd9
Author: Andreas Schwab 
Date:   Tue Jan 21 23:50:15 2025 +0100

libstdc++: correct symbol version of typeinfo for bfloat16_t on RISC-V

RISC-V only gained support for bfloat16_t after gcc 14.  Passes
libstdc++/check_abi on {x86_64,aarch64,ppc64le,riscv64,s390x}-suse-linux.

PR libstdc++/118563
* testsuite/util/testsuite_abi.cc (check_version): Add
CXXABI_1.3.16.
* config/abi/pre/gnu.ver (CXXABI_1.3.14) [__riscv]: Exclude
typeinfo for bfloat16_t.
(CXXABI_1.3.16) [__riscv]: Add it here.

[Bug libstdc++/118563] [15 regression] libstdc++ incompatible ABI change on riscv64

[schwab--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118563

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Andreas Schwab  ---
Fixed.

[Bug tree-optimization/114052] [12/13/14/15 Regression] Wrong code at -O2 for well-defined infinite loop since r8-5245

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #13 from Richard Biener  ---
On trunk the testcase now works - because of the cunroll side-effect change we
go from

size: 6-1, last_iteration: 6-1
  Loop size: 6
  Estimated size after unrolling: 6
t2.c:1:5: optimized: loop with 1 iterations completely unrolled (header
execution count 10233758)

to

size: 6-1, last_iteration: 6-1
  Loop size: 6
  Estimated size after unrolling: 10-2
Not unrolling loop 1: size would grow.

and we only allow unrolling if the size doesn't grow because there's a call
in the body.  We'd need a new testcase there.


For the issue at hand (not trying to handle other cases we don't have a
testcase for), copying parts of the
tree-ssa-loop-im.cc:fill_always_executed_in_1
handling works (irreducible inner loop and exit not copied).

diff --git a/gcc/tree-ssa-loop-niter.cc b/gcc/tree-ssa-loop-niter.cc
index b71eb67fbc7..0615fb307d9 100644
--- a/gcc/tree-ssa-loop-niter.cc
+++ b/gcc/tree-ssa-loop-niter.cc
@@ -4378,11 +4378,28 @@ infer_loop_bounds_from_undefined (class loop *loop,
basic_block *bbs)
   gimple_stmt_iterator bsi;
   basic_block bb;
   bool reliable;
+  class loop *inn_loop = loop;

   for (i = 0; i < loop->num_nodes; i++)
 {
   bb = bbs[i];

+  if (!flow_bb_inside_loop_p (inn_loop, bb))
+   {
+ /* When we are leaving a possibly infinite inner loop
+we have to stop processing.  */
+ if (!finite_loop_p (inn_loop))
+   break;
+ /* If the loop was finite we can continue with processing
+the loop we exited to.  */
+ inn_loop = bb->loop_father;
+   }
+
+  if (bb->loop_father->header == bb)
+   /* Record that we enter into a subloop since it might not
+  be finite.  */
+   inn_loop = bb->loop_father;
+
   /* If BB is not executed in each iteration of the loop, we cannot
 use the operations in it to infer reliable upper bound on the
 # of iterations of the loop.  However, we can use it as a guess. 
@@ -4812,7 +4829,7 @@ estimate_numbers_of_iterations (class loop *loop)
  diagnose those loops with -Waggressive-loop-optimizations.  */
   number_of_latch_executions (loop);

-  basic_block *body = get_loop_body (loop);
+  basic_block *body = get_loop_body_in_dom_order (loop);
   auto_vec exits = get_loop_exit_edges (loop, body);
   likely_exit = single_likely_exit (loop, exits);
   FOR_EACH_VEC_ELT (exits, i, ex)

[Bug tree-optimization/118653] [14/15 Regression] ice in vectorizable_live_operation, at tree-vect-loop.cc:11573 since r14-5106-g95cfa2cdd1b525

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118653

--- Comment #16 from Richard Biener  ---
OK, so this also shows (latent) wrong-debug.  While the vectorizer changes the
iteration space it does not adjust scalar compute that's supposed to be dead,
but DCE might end up deriving wrong debug stmts from this.

[Bug rtl-optimization/116073] [15 regression] invalid rtl sharing compiling compiling FileSystem.mod caused by ext-dce

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116073

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #3 from Gaius Mulley  ---
> Created attachment 60272
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60272&action=edit
> Proposed patch to correct offset and return type to/from lseek
>
> FWIIW I wonder if the bug might be related to the correction in libc.def for
> lseek to use SYSTEM.COFF_T (rather than SYSTEM.CSSIZE_T)?  These changes
> commenced when fixing -Wodr violations PR 118010 and PR 118183.  It appears
> doModeChange is missing the change to COFF_T; patch proposed:

I noticed that this is part of already committed

commit 2531cb1d20d9c5b8a5390816a10a018c59506250
Author: Gaius Mulley 
Date:   Sat Jan 25 18:22:35 2025 +

PR modula2/118010 libc.def lseek procedure off_t bugfix

However, bootstrapping both i386-pc-solaris2.11 and
sparc-sun-solaris2.11 with that commit included shows a regression
that's probably related:

+FAIL: gm2/isolib/run/pass/seqappend.mod execution,  -O 
+FAIL: gm2/isolib/run/pass/seqappend.mod execution,  -O -g 
+FAIL: gm2/isolib/run/pass/seqappend.mod execution,  -O3 -fomit-frame-pointer 
+FAIL: gm2/isolib/run/pass/seqappend.mod execution,  -O3 -fomit-frame-pointer
-finline-functions 
+FAIL: gm2/isolib/run/pass/seqappend.mod execution,  -Os 
+FAIL: gm2/isolib/run/pass/seqappend.mod execution,  -g 

on 32-bit sparc and x86 (64-bit is fine).  The test fails with

short read occurred: 10...
append test failed

[Bug c++/118655] [14/15 Regression] std::is_bounded_array::value returns true for zero-size arrays

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118655

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 CC||jakub at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #3 from Jakub Jelinek  ---
Then it is a regression since
r14-6624-g8843cff6c98cb0789a1ec6f51be6c5122fc1b5e9
which started using the trait introduced in
r14-6371-gea0a0e6bf1470e48cc5f337bc1be40c40ac8e5ed

[Bug c++/118528] [15 Regression] Template argument deduction failure with RAW_DATA_CST

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118528

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Jakub Jelinek  ---
Fixed.

[Bug target/117850] GCC emits DUP, UMULL instead of UMULL2

[Spencer.Abson at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117850

Spencer Abson  changed:

   What|Removed |Added

 CC||Spencer.Abson at arm dot com

--- Comment #6 from Spencer Abson  ---
Hi all, this is something I'm looking into and plan to work on this week.

Thanks

[Bug target/118501] [14 regression] aarch64: ICE in simplify_context::simplify_subreg

[doko at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118501

--- Comment #13 from Matthias Klose  ---
the backport requires some more work:

../../src/gcc/config/aarch64/aarch64.md:7255:13: error: 'force_lowpart_subreg'
was not declared in this scope; did you mean 'lowpart_subreg'?
 7255 |   rtx op1 = force_lowpart_subreg (mode, operands[1],
mode);
  | ^~~~
  | lowpart_subreg

[Bug rtl-optimization/118638] [14/15 Regression] Miscompile with -Os and -O0/1/2/3 since r14-4810

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118638

--- Comment #12 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #11)
> Slightly more reduced
> __attribute__((noipa)) int
> foo (int x)
> {
>   int a = x != -3, b, c;
>   a *= 3;
>   b = 2 * x - 9;
>   a = a + b;
>   a = ~a;
>   c = a & 1;
>   return -c;
> }

That is extremely obfuscated equivalent to just return x != -3 ? -1 : 0;
and GCC 13 and earlier at -Os used to be able to figure that out during
combine.

[Bug fortran/115265] Generic function for constructor not invoked for same-name derived type with procedure pointer component

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115265

Paul Thomas  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2025-01-27
 Status|UNCONFIRMED |NEW
 CC||pault at gcc dot gnu.org

--- Comment #1 from Paul Thomas  ---
Hi Matthew,

As you said, this PR was indeed fixed by the patch for PR109066. Thanks
pointing it out.

I have prepared a deja-gnuified verion of your testcase, which I will push to
15-branch at the end of play today.

Best regards

Paul

[Bug fortran/115265] Generic function for constructor not invoked for same-name derived type with procedure pointer component

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115265

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
Created attachment 60289
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60289&action=edit
Testcase for mainline

Here it is.

Paul

[Bug tree-optimization/118634] [15 Regression] missed optimization leading to maybe-uninitialized warning

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118634

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
The warning started with r15-5646-gd1cf0d7a0f27fdd55302785f19f07d1c3f162ba5

[Bug c++/118655] [14/15 Regression] std::is_bounded_array::value returns true for zero-size arrays

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118655

--- Comment #4 from Jakub Jelinek  ---
Created attachment 60288
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60288&action=edit
gcc15-pr118655.patch

Untested fix.  Unsure whether we want to backport this to 14.3 or not.

[Bug c++/118491] [15 Regression] coroutines: ICE when co_awaiting l-value awaitable from range-based loop.

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118491

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
In -std=gnu++{11,14,17,20} modes perhaps -fno-range-for-ext-temps could work
around it.
But in -std=c++23/-std=gnu++23 that is an error, C++23 requires the extension
of the range for temporaries.

[Bug c++/118491] [15 Regression] coroutines: ICE when co_awaiting l-value awaitable from range-based loop.

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118491

--- Comment #6 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #3)
> So it's technically not a regression if GCC 14 didn't implement C++23 [range
> for] changes.

It is technically still a regression, range for loops written in the
pre-P2718R0 era better shouldn't rely on the lifetime of temporaries being
extended and they could have worked fine in coroutines.

[Bug tree-optimization/118637] [12/13/14 Regression] gcc fails to optimize unsigned division by 2 to shift right by 1

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118637

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[12/13/14/15 Regression]|[12/13/14 Regression] gcc
   |gcc fails to optimize   |fails to optimize unsigned
   |unsigned division by 2 to   |division by 2 to shift
   |shift right by 1|right by 1

--- Comment #8 from Jakub Jelinek  ---
Fixed on the trunk.  I think we don't want to backport though.
And the non-regression part deferred for GCC 16.

[Bug rtl-optimization/118638] [14/15 Regression] Miscompile with -Os and -O0/1/2/3 since r14-4810-ge28869670c9879

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118638

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
Slightly more reduced
__attribute__((noipa)) int
foo (int x)
{
  int a = x != -3, b, c;
  a *= 3;
  b = 2 * x - 9;
  a = a + b;
  a = ~a;
  c = a & 1;
  return -c;
}

int
main ()
{
  if (foo (0) != -1)
__builtin_abort ();
}

[Bug rtl-optimization/118662] [14/15 regression] -ftree-slp-vectorize with -mavx causes incorrect math since r14-9316-g7890836de20912

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662

--- Comment #14 from GCC Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:343e1083eb9f57e05c0caba195f118ef2e95cc40

commit r15-7227-g343e1083eb9f57e05c0caba195f118ef2e95cc40
Author: Richard Biener 
Date:   Mon Jan 27 10:49:51 2025 +0100

rtl-optimization/118662 - wrong combination of vector sign-extends

The following fixes an issue in the RTL combiner where we correctly
combine two vector sign-extends with a vector load

Trying 7, 9 -> 10:
7: r106:V4QI=[r119:DI]
  REG_DEAD r119:DI
9: r108:V4HI=sign_extend(vec_select(r106:V4QI#0,parallel))
   10: r109:V4SI=sign_extend(vec_select(r108:V4HI#0,parallel))
  REG_DEAD r108:V4HI

to

modifying insn i2 9: r109:V4SI=sign_extend([r119:DI])

but since r106 is used we wrongly materialize it using a subreg:

modifying insn i310: r106:V4QI=r109:V4SI#0

which of course does not work for modes with more than one component,
specifically vector and complex modes.

PR rtl-optimization/118662
* combine.cc (try_combine): When re-materializing a load
from an extended reg by a lowpart subreg make sure we're
not dealing with vector or complex modes.

* gcc.dg/torture/pr118662.c: New testcase.

[Bug target/118669] Misaligned store after vectorization without using misaligned type with SVE

[rsandifo at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669

--- Comment #6 from Richard Sandiford  ---
(In reply to rguent...@suse.de from comment #5)
> On Mon, 27 Jan 2025, rsandifo at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669
> > 
> > --- Comment #4 from Richard Sandiford  ---
> > Just to be sure I understand: is the PR simply about making the RTL
> > representation of the memory more correct?  Or is it about generating 
> > different
> > code?
> 
> I'm not sure - it depends on the alignment of VNx4SI(?), if it is
> 4 bytes then the RTL wrongly specifies 128bit alignment.  If it is
> 128bit then the generated GIMPLE from the vectorizer is wrong
> (but not exactly sure why).
> 
> The question is really where we make things wrong from which
> information.
We're producing the code that I'd expect.  VNx4SI does have 128-bit alignment,
but that's for the sake of LDR and STR.  LD1W and ST1W operate on individual
32-bit elements for alignment purposes.

So yeah, the 128-bit alignment on the MEM is clearly wrong from a
representational perspective, but I wasn't sure whether changing that to 32 was
enough to resolve the PR.

[Bug target/118669] Misaligned store after vectorization without using misaligned type with SVE

[rsandifo at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669

Richard Sandiford  changed:

   What|Removed |Added

   Keywords|wrong-code  |internal-improvement
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #7 from Richard Sandiford  ---
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index c0550acf6b2..06cd6e42355 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -9908,7 +9908,8 @@ vectorizable_store (vec_info *vinfo,
= fold_build2 (MEM_REF, vectype, dataref_ptr,
   dataref_offset ? dataref_offset
  : build_int_cst (ref_type, 0));
- if (alignment_support_scheme == dr_aligned)
+ if (alignment_support_scheme == dr_aligned
+ && align >= TYPE_ALIGN_UNIT (vectype))
;
  else
TREE_TYPE (data_ref)

seems to fix it.  (Loads will need similar treatment.)

The justification is that preferred_vector_alignment requests element alignment
for SVE, even though the vector mode itself has 128-bit alignment.  In that
context, dr_aligned means that element alignment has been reached.

It looks like a long-standing issue, so I suppose it should wait for GCC 16.

[Bug tree-optimization/115347] [12/13/14 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-2097

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115347

Richard Biener  changed:

   What|Removed |Added

Summary|[12/13/14/15 Regression]|[12/13/14 Regression] wrong
   |wrong code at -O3 on|code at -O3 on
   |x86_64-linux-gnu since  |x86_64-linux-gnu since
   |r12-2097|r12-2097
  Known to work||15.0
  Known to fail||14.2.0

--- Comment #8 from Richard Biener  ---
Fixed (or worked around) for GCC 15 for now.  Might regress some valid cases.

[Bug tree-optimization/112859] [12/13/14 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-2097-g9f34b780b0461e

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112859

Richard Biener  changed:

   What|Removed |Added

Summary|[12/13/14/15 Regression]|[12/13/14 Regression] wrong
   |wrong code at -O3 on|code at -O3 on
   |x86_64-linux-gnu since  |x86_64-linux-gnu since
   |r12-2097-g9f34b780b0461e|r12-2097-g9f34b780b0461e
  Known to work||15.0
  Known to fail||14.2.0

--- Comment #6 from Richard Biener  ---
Worked around for GCC 15.

[Bug target/118501] [14 regression] aarch64: ICE in simplify_context::simplify_subreg

[rearnsha at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118501

--- Comment #14 from Richard Earnshaw  ---
(In reply to Matthias Klose from comment #13)
> the backport requires some more work:
> 
> ../../src/gcc/config/aarch64/aarch64.md:7255:13: error:
> 'force_lowpart_subreg' was not declared in this scope; did you mean
> 'lowpart_subreg'?
>  7255 |   rtx op1 = force_lowpart_subreg (mode, operands[1],
> mode);
>   | ^~~~
>   | lowpart_subreg

force_lowpart_subreg is a new function in gcc-15 (explow.cc).  But it's a
trivial piece of code that could easily be backported.  It doesn't change any
existing code to add it to gcc-14.

[Bug tree-optimization/117892] [15 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: in single_succ_edge, at basic-block.h:332 since r15-5336-gcee7d080d5c2a5

[jamborm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117892

Martin Jambor  changed:

   What|Removed |Added

  Component|ipa |tree-optimization
   Assignee|hubicka at gcc dot gnu.org |jamborm at gcc dot 
gnu.org
 CC||jamborm at gcc dot gnu.org

--- Comment #7 from Martin Jambor  ---
I'm about to test a patch.

[Bug tree-optimization/118669] Misaligned store after vectorization without using misaligned type with SVE

[rsandifo at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669

Richard Sandiford  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|ASSIGNED|UNCONFIRMED
   Assignee|rsandifo at gcc dot gnu.org|unassigned at gcc dot 
gnu.org

--- Comment #9 from Richard Sandiford  ---
Probably best if I unassign myself then, because I don't really see where the
wrong code is.

[Bug tree-optimization/118653] [14/15 Regression] ice in vectorizable_live_operation, at tree-vect-loop.cc:11573 since r14-5106-g95cfa2cdd1b525

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118653

--- Comment #17 from GCC Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:6a510dea7f3b047d0650a48e558a4911973930eb

commit r15-7229-g6a510dea7f3b047d0650a48e558a4911973930eb
Author: Richard Biener 
Date:   Mon Jan 27 12:53:21 2025 +0100

tree-optimization/118653 - ICE in vectorizable_live_operation

The checking code didn't take into account debug uses.

PR tree-optimization/118653
* tree-vect-loop.cc (vectorizable_live_operation): Also allow
out-of-loop debug uses.

* gcc.dg/vect/pr118653.c: New testcase.

[Bug rtl-optimization/116244] [15 Regression] reload ICE building libstdc++ for coldfire

[law at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116244

--- Comment #8 from Jeffrey A. Law  ---
The failure is limited to reload which I don't think is used by any primary
target.  On the other hand it trips building glibc, which makes it more
important in mind.  On the whole I don't think it's P1 worthy though.  Still on
my list though.

[Bug sarif-replay/117670] installation of sarif-replay doesn't honor prefix and suffixes

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117670

David Malcolm  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #3 from David Malcolm  ---
I believe this was fixed by the above patch; marking as resolved.  Please
reopen if I messed up.

[Bug target/80881] Implement Windows native TLS

[tanksherman27 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

Julian Waters  changed:

   What|Removed |Added

  Attachment #60160|0   |1
is obsolete||

--- Comment #96 from Julian Waters  ---
Created attachment 60287
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60287&action=edit
Latest TLS

Changed to hard error on broken @secrel32 support. Do help me check if the
configure patch is ok. If it is, it's probably finally ready for integration

[Bug middle-end/118490] [15 Regression] ICE Indefinite recursion transforming exp-log with -frounding-math since r15-5116-ge232dc3bb5c3e8

[ktkachov at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118490

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Should be fixed by Soumya's commit.

[Bug c++/118574] [15 regression] Crashes with coroutines in KDE Plasma

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Is KDE Plasma built with -std=gnu++20 or -std=gnu++17?
Perhaps as a workaround -fno-range-for-ext-temps option could help.
If it is built with -std=c++23/gnu++23 or later, that won't work though.

[Bug target/118669] Misaligned store after vectorization without using misaligned type with SVE

[rsandifo at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669

--- Comment #4 from Richard Sandiford  ---
Just to be sure I understand: is the PR simply about making the RTL
representation of the memory more correct?  Or is it about generating different
code?

[Bug fortran/118640] [15 Regression] cp2k ICE in gfc_conv_expr_present since r15-5347

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118640

Paul Thomas  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #6 from Paul Thomas  ---
Thanks again for the reduction, Jakub. Fortunately this was an 'obvious' fix.

Fixed.

Paul

[Bug target/118669] Misaligned store after vectorization without using misaligned type with SVE

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669

Richard Biener  changed:

   What|Removed |Added

   Keywords|internal-improvement|wrong-code
Summary|Misaligned store after  |Misaligned store after
   |after vectorization without |vectorization without using
   |using misaligned type with  |misaligned type with SVE
   |SVE |
 CC||rsandifo at gcc dot gnu.org,
   ||tnfchris at gcc dot gnu.org
  Component|tree-optimization   |target
 Target||aarch64

--- Comment #3 from Richard Biener  ---
If you dump GIMPLE with -gimple you see the alignment used.

  __MEM  ((int *)vectp_a.7_40) =
vect_vec_iv_.6_37;
  vectp_a.7_43 = vectp_a.7_40 + POLY_INT_CST [16ul, 16ul];
  __MEM  ((int *)vectp_a.7_43) = _39;

indeed since no alignment is specified, it's natural alignment.  The SVE
loop is correct:

  .MASK_STORE (vectp_a.12_59, _Literal (int *) 32, _61, vect_vec_iv_.11_54);

t.c:4:21: note:   === vect_analyze_data_refs_alignment ===
t.c:4:21: note:   recording new base alignment for a_8(D)
  alignment:4 
  misalignment: 0
  based on: *_3 = j_13;
t.c:4:21: note:   vect_compute_data_ref_alignment:
t.c:4:21: missed:   misalign = 0 bytes of ref *_3

so it seems the target says '4' is "aligned" rather than using
dr_unalign_supported?

This looks like a target issue to me.

[Bug middle-end/118643] [15 Regression] Crash at -O3 during RTL pass: expand since r15-7171

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118643

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Priority|P3  |P1
 Status|NEW |ASSIGNED

--- Comment #7 from Richard Biener  ---
The bogus BIT_FIELD_REF is built from

#0  0x01d3a091 in make_node (code=BIT_FIELD_REF)
at /space/rguenther/src/gcc/gcc/tree.cc:1217
#1  0x01d496ce in build3 (code=BIT_FIELD_REF, 
tt=, arg0=, 
arg1=, arg2=)
at /space/rguenther/src/gcc/gcc/tree.cc:5211
#2  0x013053f0 in expand_expr_real_1 (exp=, 
target=0x76cabc60, tmode=E_V4SImode, modifier=EXPAND_NORMAL, 
alt_rtl=0x7fffcf38, inner_reference_p=false)
at /space/rguenther/src/gcc/gcc/expr.cc:11808
#3  0x012fa625 in expand_expr_real (exp=, 
target=0x76cabc60, tmode=E_V4SImode, modifier=EXPAND_NORMAL, 
alt_rtl=0x7fffcf38, inner_reference_p=false)
at /space/rguenther/src/gcc/gcc/expr.cc:9521
#4  0x012eead8 in store_expr (exp=, 
target=0x76cabc60, call_param_p=0, nontemporal=false, reverse=false)
at /space/rguenther/src/gcc/gcc/expr.cc:6771
#5  0x012ecf53 in expand_assignment (to=, 
from=, nontemporal=false)
at /space/rguenther/src/gcc/gcc/expr.cc:6492

expanding

vect__24.107_874 = MEM  [(int *)&f + -12B];

which is the fallback of

/* Handle expansion of non-aliased memory with non-BLKmode.  That
   might end up in a register.  */
if (mem_ref_refers_to_non_mem_p (exp))
  {
poly_int64 offset = mem_ref_offset (exp).force_shwi ();
base = TREE_OPERAND (base, 0);
poly_uint64 type_size;
if (known_eq (offset, 0)
&& !reverse
&& poly_int_tree_p (TYPE_SIZE (type), &type_size)
&& known_eq (GET_MODE_BITSIZE (DECL_MODE (base)), type_size))
  return expand_expr (build1 (VIEW_CONVERT_EXPR, type, base),
  target, tmode, modifier);
if (TYPE_MODE (type) == BLKmode)
  {
temp = assign_stack_temp (DECL_MODE (base),
  GET_MODE_SIZE (DECL_MODE (base)));
store_expr (base, temp, 0, false, false);
temp = adjust_address (temp, BLKmode, offset);
set_mem_size (temp, int_size_in_bytes (type));
return temp;
  }
exp = build3 (BIT_FIELD_REF, type, base, TYPE_SIZE (type),
  bitsize_int (offset * BITS_PER_UNIT));
REF_REVERSE_STORAGE_ORDER (exp) = reverse;
return expand_expr (exp, target, tmode, modifier);

we possibly want to guard offset and fall back to a stack temporary like
with the following which fixes the ICE.

diff --git a/gcc/expr.cc b/gcc/expr.cc
index a310b2d9131..4bfcde54523 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -11796,13 +11796,15 @@ expand_expr_real_1 (tree exp, rtx target,
machine_mode tmode,
&& known_eq (GET_MODE_BITSIZE (DECL_MODE (base)), type_size))
  return expand_expr (build1 (VIEW_CONVERT_EXPR, type, base),
  target, tmode, modifier);
-   if (TYPE_MODE (type) == BLKmode)
+   if (TYPE_MODE (type) == BLKmode
+   || maybe_lt (offset, 0))
  {
temp = assign_stack_temp (DECL_MODE (base),
  GET_MODE_SIZE (DECL_MODE (base)));
store_expr (base, temp, 0, false, false);
-   temp = adjust_address (temp, BLKmode, offset);
-   set_mem_size (temp, int_size_in_bytes (type));
+   temp = adjust_address (temp, TYPE_MODE (type), offset);
+   if (TYPE_MODE (type) == BLKmode)
+ set_mem_size (temp, int_size_in_bytes (type));
return temp;
  }
exp = build3 (BIT_FIELD_REF, type, base, TYPE_SIZE (type),

[Bug target/118662] [14/15 regression] -ftree-slp-vectorize with -mavx causes incorrect math since r14-9316-g7890836de20912

[ubizjak at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662

--- Comment #10 from Uroš Bizjak  ---
Before combine pass we have (_.297r.ud_dce):

(insn 7 4 9 2 (set (reg:V4QI 106 [ MEM  [(type1
*)num_13(D)] ])
(mem:V4QI (reg/v/f:DI 105 [ num ]) [0 MEM 
[(type1 *)num_13(D)]+0 S4 A8])) "pr118662.c":9:39 1668 {*movv4qi_internal}
 (expr_list:REG_DEAD (reg/v/f:DI 105 [ num ])
(nil)))
...
(insn 19 17 38 2 (set (reg:SI 116)
(zero_extend:SI (vec_select:QI (reg:V4QI 106 [ MEM  [(type1 *)num_13(D)] ])
(parallel [
(const_int 3 [0x3])
] "pr118662.c":12:8 1990 {*pextrb_zext}
 (expr_list:REG_DEAD (reg:V4QI 106 [ MEM  [(type1
*)num_13(D)] ])
(nil)))

but combine changes this to (_.298r.combine):

(insn 9 7 10 2 (set (reg:V4SI 108 [ vect_patt_34.8_47 ])
(sign_extend:V4SI (mem:V4QI (reg:DI 118) [0 MEM 
[(type1 *)num_13(D)]+0 S4 A8]))) 7795 {*sse4_1_sign_extendv4qiv4si2_1}
 (expr_list:REG_DEAD (reg:DI 118)
(nil)))
(insn 10 9 11 2 (set (reg:V4QI 106 [ MEM  [(type1
*)num_13(D)] ])
(subreg:V4QI (reg:V4SI 108 [ vect_patt_34.8_47 ]) 0)) 1668
{*movv4qi_internal}
 (nil))
...
(insn 19 17 38 2 (set (reg:SI 116)
(zero_extend:SI (vec_select:QI (reg:V4QI 106 [ MEM  [(type1 *)num_13(D)] ])
(parallel [
(const_int 3 [0x3])
] "pr118662.c":12:8 1990 {*pextrb_zext}
 (expr_list:REG_DEAD (reg:V4QI 106 [ MEM  [(type1
*)num_13(D)] ])
(nil)))

It is not correct to make a V4QImode lowpart of V4SImode register that holds
SImode sign-extended original QImode values.

[Bug rtl-optimization/118662] [14/15 regression] -ftree-slp-vectorize with -mavx causes incorrect math since r14-9316-g7890836de20912

[ubizjak at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662

Uroš Bizjak  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org
  Component|target  |rtl-optimization

--- Comment #11 from Uroš Bizjak  ---
Instruction combiner problem, CC added.

[Bug rtl-optimization/118662] [14/15 regression] -ftree-slp-vectorize with -mavx causes incorrect math since r14-9316-g7890836de20912

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #13 from Richard Biener  ---
This subreg is created via

  /* Check for a case where we loaded from memory in a narrow mode and
 then sign extended it, but we need both registers.  In that case,
 we have a PARALLEL with both loads from the same memory location.
 We can split this into a load from memory followed by a register-register
 copy.  This saves at least one insn, more if register allocation can
 eliminate the copy.

 We cannot do this if the destination of the first assignment is a
 condition code register.  We eliminate this case by making sure
 the SET_DEST and SET_SRC have the same mode.

 We cannot do this if the destination of the second assignment is
 a register that we have already assumed is zero-extended.  Similarly
 for a SUBREG of such a register.  */

  else if (i1 && insn_code_number < 0 && asm_noperands (newpat) < 0
...
  SUBST (SET_SRC (newpat),
 gen_lowpart (GET_MODE (SET_SRC (newpat)), ni2dest));

I have a patch.

[Bug target/118663] [15 Regression] ICE: in rs6000_emit_move, at config/rs6000/rs6000.cc:11091 during libgcc build - caused by r15-7008-g9f009e8865cda0

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug fortran/118640] [15 Regression] cp2k ICE in gfc_conv_expr_present since r15-5347

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118640

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:3600b1ff14a459e84bb40bdfea7cd8d2ffd73d8d

commit r15-7224-g3600b1ff14a459e84bb40bdfea7cd8d2ffd73d8d
Author: Paul Thomas 
Date:   Mon Jan 27 09:55:26 2025 +

Fortran: ICE in gfc_conv_expr_present w. defined assignment [PR118640]

2025-01-27  Paul Thomas  

gcc/fortran
PR fortran/118640
* resolve.cc (generate_component_assignments): Make sure that
the rhs temporary does not pick up the optional attribute from
the lhs.

gcc/testsuite/
PR fortran/118640
* gfortran.dg/pr118640.f90: New test.

[Bug tree-optimization/118650] `(even + unknown) & 1` is not optimized to just `unknown & 1` at gimple level

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118650

--- Comment #4 from Richard Biener  ---
maybe also a thing for SSA backprop?  Eliminating ops that only affect bits
masked by &?  Or ops that only affect bits added by |?

[Bug rtl-optimization/115835] [15 regression] FAIL: gcc.target/s390/section-anchors.c since r15-1579-g792f97b44ffc5e

[stefansf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115835

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |stefansf at gcc dot 
gnu.org

--- Comment #4 from Stefan Schulze Frielinghaus  
---
Yeah you are right, I somehow missed that. Will take care of it.

[Bug tree-optimization/118637] [12/13/14/15 Regression] gcc fails to optimize unsigned division by 2 to shift right by 1

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118637

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:92a5c5100c25190622ca86b63586a598952546bf

commit r15-7223-g92a5c5100c25190622ca86b63586a598952546bf
Author: Jakub Jelinek 
Date:   Mon Jan 27 10:22:28 2025 +0100

match.pd: Canonicalize unsigned division by power of two into right shift
[PR118637]

We already do this canonicalization in
simplify_using_ranges::simplify_div_or_mod_using_ranges, but that means
that it is not done at -O1 or when vrp is otherwise disabled, and that
it can be done too late in some cases when e.g. the r8-2064
"X / C1 op C2 into a simple range test." optimization triggers first.
Note, for unsigned modulo we already have
 (simplify
  (mod @0 (convert? (power_of_two_cand@1 @2)))
  (if ((TYPE_UNSIGNED (type) || tree_expr_nonnegative_p (@0))
...
optimization which duplicates what
simplify_using_ranges::simplify_div_or_mod_using_ranges
does in case ranges aren't needed.

For GCC 16 I think we should improve the niters pattern recognition
and handle even what r8-2064 comes with, after all as I've tried to show
in the PR the user could have written it that way.
I've guarded this optimization on #if GIMPLE just in case this would stand
in any way to the various divmult etc. simplification, guess that can be
lifted for GCC 16 too.  In the modulo case we also handle
unsigned % (power_of_two << n), but not really sure if we could do that
for the division, because unsigned / (power_of_two << n) is not simple
unsigned >> (log2 (power_of_two) + n), one can shift the bit out and then
it becomes just 0.

2025-01-27  Jakub Jelinek  

PR tree-optimization/118637
* match.pd: Canonicalize unsigned division by power of two to
right shift.

* gcc.dg/tree-ssa/pr118637.c: New test.

[Bug tree-optimization/118660] [14/15 Regression] VRP gets in the way sometimes

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118660

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.3

[Bug tree-optimization/118657] Missed optimization (unreachable branch could be pruned after taking into account the possible values of a constexpr lookup table)

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118657

--- Comment #10 from Richard Biener  ---
There's a VRP bug (with a patch from Jakub) that made VRP for array[i] with
constant initializer compute a range of the load based on the range of 'i'
(but obviously that can be expensive).

[Bug tree-optimization/118653] [14/15 Regression] ice in vectorizable_live_operation, at tree-vect-loop.cc:11573 since r14-5106-g95cfa2cdd1b525

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118653

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Priority|P3  |P2

--- Comment #15 from Richard Biener  ---
Mine.

[Bug rtl-optimization/118662] [14/15 regression] -ftree-slp-vectorize with -mavx causes incorrect math since r14-9316-g7890836de20912

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to fail||14.1.0
 Target|X86_64  |x86_64-*-*
  Known to work||13.3.0

--- Comment #12 from Richard Biener  ---
We combine

Trying 7, 9 -> 10:
7: r106:V4QI=[r119:DI]
  REG_DEAD r119:DI
9: r108:V4HI=sign_extend(vec_select(r106:V4QI#0,parallel))
   10: r109:V4SI=sign_extend(vec_select(r108:V4HI#0,parallel))
  REG_DEAD r108:V4HI

to

modifying insn i2 9: r109:V4SI=sign_extend([r119:DI])
modifying insn i310: r106:V4QI=r109:V4SI#0

where i3 is problematic.  r106 is no longer computed correctly (while
a QImode subreg of a SImode reg that's sign-extended from a QImode val
is a no-op round-trip the same is of course not true for vector modes).

[Bug target/118669] Misaligned store after vectorization without using misaligned type with SVE

[rguenther at suse dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669

--- Comment #5 from rguenther at suse dot de  ---
On Mon, 27 Jan 2025, rsandifo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669
> 
> --- Comment #4 from Richard Sandiford  ---
> Just to be sure I understand: is the PR simply about making the RTL
> representation of the memory more correct?  Or is it about generating 
> different
> code?

I'm not sure - it depends on the alignment of VNx4SI(?), if it is
4 bytes then the RTL wrongly specifies 128bit alignment.  If it is
128bit then the generated GIMPLE from the vectorizer is wrong
(but not exactly sure why).

The question is really where we make things wrong from which
information.

[Bug c++/118574] [15 regression] Crashes with coroutines in KDE Plasma

[sjames at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574

--- Comment #2 from Sam James  ---
(In reply to Jakub Jelinek from comment #1)
> Is KDE Plasma built with -std=gnu++20 or -std=gnu++17?

-std=gnu++20

> Perhaps as a workaround -fno-range-for-ext-temps option could help.
> If it is built with -std=c++23/gnu++23 or later, that won't work though.

Let me try.

Meanwhile, here's a backtrace for completeness:
```
t
#0  __pthread_kill_implementation (threadid=, signo=11,
no_tid=0) at pthread_kill.c:44
#1  __pthread_kill_internal (threadid=, signo=11) at
pthread_kill.c:89
#2  __GI___pthread_kill (threadid=, signo=signo@entry=11) at
pthread_kill.c:100
#3  0x7f3930e20706 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
#4  0x7f3934bc759d in KCrash::defaultCrashHandler (sig=11) at
/usr/src/debug/kde-frameworks/kcrash-6.10.0/kcrash-6.10.0/src/kcrash.cpp:596
#5  0x7f3930e20840 in  () at /usr/lib64/libc.so.6
#6  std::__atomic_base::load (this=0x55ff1a0eda4004,
__m=std::memory_order::relaxed) at
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/atomic_base.h:500
#7  QAtomicOps::loadRelaxed (_q_value=) at
/usr/include/qt6/QtCore/qatomic_cxx11.h:202
#8  QBasicAtomicInteger::loadRelaxed (this=0x55ff1a0eda4004) at
/usr/include/qt6/QtCore/qbasicatomic.h:36
#9  QWeakPointer::internalData (this=0x55ff1a1b409f) at
/usr/include/qt6/QtCore/qsharedpointer_impl.h:752
#10 QPointer::data (this=0x55ff1a1b409f) at
/usr/include/qt6/QtCore/qpointer.h:75
#11 comparesEqual (lhs=...,
rhs=0x55ff1a0efe70) at /usr/include/qt6/QtCore/qpointer.h:103
#12 operator== (lhs=...,
rhs=: ) at
/usr/include/qt6/QtCore/qpointer.h:104
#13 Kirigami::Platform::PlatformThemePrivate::color (this=,
theme=0x55ff1a0efe70, color=Kirigami::Platform::PlatformThemeData::TextColor)
at
/usr/src/debug/kde-frameworks/kirigami-6.10.0/kirigami-6.10.0/src/platform/platformtheme.cpp:281
#14 Kirigami::Platform::PlatformTheme::textColor (this=0x55ff1a0efe70) at
/usr/src/debug/kde-frameworks/kirigami-6.10.0/kirigami-6.10.0/src/platform/platformtheme.cpp:465
#15 0x7f38e40f0cc5 in Icon::loadFromTheme (this=0x55ff1a0ea650,
iconName=...) at
/usr/src/debug/kde-frameworks/kirigami-6.10.0/kirigami-6.10.0/src/primitives/icon.cpp:642
#16 Icon::findIcon (this=this@entry=0x55ff1a0ea650, size=...) at
/usr/src/debug/kde-frameworks/kirigami-6.10.0/kirigami-6.10.0/src/primitives/icon.cpp:533
#17 0x7f38e40f4a68 in Icon::updatePolish (this=0x55ff1a0ea650) at
/usr/src/debug/kde-frameworks/kirigami-6.10.0/kirigami-6.10.0/src/primitives/icon.cpp:376
#18 0x7f393366c47c in QQuickWindowPrivate::polishItems
(this=0x55ff189d64c0)
at
/usr/src/debug/dev-qt/qtdeclarative-6.8.1/qtdeclarative-everywhere-src-6.8.1/src/quick/items/qquickwindow.cpp:348
#19 0x7f393339fd28 in QSGThreadedRenderLoop::polishAndSync
(this=this@entry=0x55ff17a4e270, w=w@entry=0x55ff1cae3640,
inExpose=inExpose@entry=true)
at
/usr/src/debug/dev-qt/qtdeclarative-6.8.1/qtdeclarative-everywhere-src-6.8.1/src/quick/scenegraph/qsgthreadedrenderloop.cpp:1636
#20 0x7f39333ad825 in QSGThreadedRenderLoop::handleExposure
(this=0x55ff17a4e270, window=)
at
/usr/src/debug/dev-qt/qtdeclarative-6.8.1/qtdeclarative-everywhere-src-6.8.1/src/quick/scenegraph/qsgthreadedrenderloop.cpp:1337
#21 0x7f3931f5c3b8 in QWindow::event (this=0x55ff190f7050,
ev=0x7fff214f3480) at
/usr/src/debug/dev-qt/qtbase-6.8.1/qtbase-everywhere-src-6.8.1/src/gui/kernel/qwindow.cpp:2691
#22 0x7f39343946ff in QApplicationPrivate::notify_helper
(this=0x55ff1723dab0, receiver=0x55ff190f7050, e=0x7fff214f3480)
at
/usr/src/debug/dev-qt/qtbase-6.8.1/qtbase-everywhere-src-6.8.1/src/widgets/kernel/qapplication.cpp:3296
#23 0x7f3931948df8 in QCoreApplication::notifyInternal2
(receiver=0x55ff190f7050, event=0x7fff214f3480)
at
/usr/src/debug/dev-qt/qtbase-6.8.1/qtbase-everywhere-src-6.8.1/src/corelib/kernel/qcoreapplication.cpp:1168
#24 0x7f3931ee8577 in QGuiApplicationPrivate::processExposeEvent
(e=)
at
/usr/src/debug/dev-qt/qtbase-6.8.1/qtbase-everywhere-src-6.8.1/src/gui/kernel/qguiapplication.cpp:3464
#25 0x7f3931f606da in QWindowSystemInterface::sendWindowSystemEvents
(flags=...)
at
/usr/src/debug/dev-qt/qtbase-6.8.1/qtbase-everywhere-src-6.8.1/src/gui/kernel/qwindowsysteminterface.cpp:1114
#26 0x7f393257dab4 in userEventSourceDispatch (source=)
at
/usr/src/debug/dev-qt/qtbase-6.8.1/qtbase-everywhere-src-6.8.1/src/gui/platform/unix/qeventdispatcher_glib.cpp:38
#27 0x7f39304a8017 in g_main_dispatch (context=0x7f3918000f30) at
../glib-2.82.4/glib/gmain.c:3357
#28 0x7f39304a92e8 in g_main_context_dispatch_unlocked
(context=0x7f3918000f30) at ../glib-2.82.4/glib/gmain.c:4208
#29 g_main_context_iterate_unlocked (context=context@entry=0x7f3918000f30,
block=block@entry=1, dispatch=dispatch@entry=1, self=) at
../glib-2.82.4/glib/gmain.c:4273
#30 0x7f39304a93c8 in g_main_context_iteration (context=0x7f3918000f30,
may_block=1) at ../glib-2.82.4/glib/gmain.c:4338
#31 0x7f3931

[Bug tree-optimization/117892] [15 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: in single_succ_edge, at basic-block.h:332 since r15-5336-gcee7d080d5c2a5

[jamborm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117892

--- Comment #8 from Martin Jambor  ---
I have proposed a patch to address this on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6zfjce03l@virgil.suse.cz/T/#u

[Bug target/118663] [15 Regression] ICE: in rs6000_emit_move, at config/rs6000/rs6000.cc:11091 during libgcc build - caused by r15-7008-g9f009e8865cda0

[bergner at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663

--- Comment #9 from Peter Bergner  ---
(In reply to Vladimir Makarov from comment #8)
> (In reply to Peter Bergner from comment #6)
> > (In reply to Segher Boessenkool from comment #5)
> > > I cannot get the testcase to fail at all.  Please give a failing command
> > > line?
> > 
> > I just used -O2 -mcpu=601.  I noticed this passes with -mcpu=602.
> 
> I've reproduced the crash.  I'll try to fix it as soon as possible, probably
> tomorrow.

Thanks for having a look.  A simpler and cleaner test case that shows the
problem is:

extern void bar (void);
void
foo (_Decimal32 *dst, _Decimal32 src)
{
  bar ();
  *dst = src;
}

[Bug c++/118632] [15 Regression] 0 vs nullptr mixup as default argument of dependently typed NTTP since r15-2761

[jason at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118632

Jason Merrill  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Status|NEW |ASSIGNED

[Bug rtl-optimization/118638] [14/15 Regression] Miscompile with -Os and -O0/1/2/3 since r14-4810

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118638

--- Comment #13 from Jakub Jelinek  ---
The wrong combination is the
Trying 9, 10 -> 17:
9: r107:SI=flags:CCZ!=0
  REG_DEAD flags:CCZ
   10: r107:SI=r107:SI*0x2+r107:SI
   17: {r111:SI=sign_extract(r107:SI,0x1,0);clobber flags:CC;}
  REG_DEAD r107:SI
  REG_UNUSED flags:CC
Failed to match this instruction:
(parallel [
(set (reg:SI 111 [ _10 ])
(mult:SI (ne:SI (reg:CCZ 17 flags)
(const_int 0 [0]))
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
])
one (while it failed, as can be seen, the attempted expression is not
equivalent to the
original ones and we then split it and match the two split parts).

[Bug target/102018] gcc.dg/torture/pr82692.c execution fails on arm cortex-m7

[clyon at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102018

--- Comment #6 from Christophe Lyon  ---
Looking at dumps when compiling for cortex-m7 and cortex-m55, I  noticed a
difference in the first gimple trace (pr82692.c.007t.gimple).

For m7, we have:
_1 = x u> 0.0;
_2 = ~_1;
_3 = x u<= 1.0e+0;
_4 = ~_3;
_5 = _2 | _4;
if (_5 != 0) goto ; else goto ;
:
D.6238 = x * 2.0e+0;
return D.6238;
:
D.6238 = x * x;
return D.6238;


For m55, we have:
_1 = x u> 0.0;
_2 = ~_1;
if (_2 != 0) goto ; else goto ;
:
_3 = x u<= 1.0e+0;
_4 = ~_3;
if (_4 != 0) goto ; else goto ;
:
D.6617 = x * 2.0e+0;
return D.6617;
:
D.6617 = x * x;
return D.6617;

So for m55 (where the test passes), we have two FP comparisons, whereas for m7
we have only one comparison, on a boolean (_5 != 0), I suspect that's why we
later have a CCFP vs CCFPE.

[Bug rtl-optimization/118662] [14 regression] -ftree-slp-vectorize with -mavx causes incorrect math since r14-9316-g7890836de20912

[ubizjak at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662

--- Comment #16 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #15)
> One possible improvement would be to move QImode value to %xmm1 and
V4QImode

[Bug middle-end/116845] gcc.dg/pr109393.c test fails on ilp32 targets (and maybe others)

[konstantinos.eleftheriou at vrull dot eu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116845

--- Comment #9 from Konstantinos Eleftheriou  ---
This is optimized in x86 using -m32 during "combine", the problem is that the
test cases check for the optimization in GIMPLE. But, this isn't the case for
AArch64 using ILP32, which isn't optimized at all.

Given this example:
```
int foo(int *a, int j)
{
  int k = j - 1;
  return a[j - 1] == a[k];
}

```

The generated RTL for accessing the index in `a[j-1]` is:
```
(insn 10 9 11 2 (set (reg:SI 117)
(const_int 1073741823 [0x3fff])) {*movsi_aarch64}
 (nil))
(insn 11 10 12 2 (set (reg:SI 116)
(plus:SI (reg/v:SI 114 [ j ])
(reg:SI 117))) {*addsi3_aarch64}
 (expr_list:REG_DEAD (reg:SI 117)
(expr_list:REG_EQUAL (plus:SI (reg/v:SI 114 [ j ])
(const_int 1073741823 [0x3fff]))
(nil
(insn 12 11 14 2 (set (reg:SI 120)
(ashift:SI (reg:SI 116)
(const_int 2 [0x2]))) {*aarch64_ashl_sisd_or_int_si3}
 (expr_list:REG_DEAD (reg:SI 116)
(nil)))

```

The generated RTL for accessing the index in `a[k]` is:
```
(insn 16 15 17 2 (set (reg:SI 122)
(plus:SI (reg/v:SI 114 [ j ])
(const_int -1 [0x]))) {*addsi3_aarch64}
 (expr_list:REG_DEAD (reg/v:SI 114 [ j ])
(nil)))
(insn 17 16 19 2 (set (reg:SI 125)
(ashift:SI (reg:SI 122)
(const_int 2 [0x2]))) {*aarch64_ashl_sisd_or_int_si3}
 (expr_list:REG_DEAD (reg:SI 122)
(nil)))

```

"Combine" successfuly matches the first case to an instruction in the backend,
after performing a split, giving this result:
```
(set (reg:SI 116)
(ashift:SI (reg/v:SI 114 [ j ])
(const_int 2 [0x2])))
(set (reg:SI 120)
(plus:SI (reg:SI 116)
(const_int -4 [0xfffc])))

```

But, fails to do the same for the second case, given that the split is
performed only when there are more than 2 instructions involved.

This leads to having the expressions `4j - 4` in the first case and `4(j-1)` in
the second one, which are not treated as equal.

Any ideas on where we should handle this? Any feedback would be appreciated.

[Bug rtl-optimization/118662] [14 regression] -ftree-slp-vectorize with -mavx causes incorrect math since r14-9316-g7890836de20912

[ubizjak at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662

--- Comment #15 from Uroš Bizjak  ---
The testcase now generates (-O2 -ftree-slp-vectorize -fno-vect-cost-model
-msse4):

addup:
pmovsxbd(%rdi), %xmm0
movd(%rdi), %xmm1
movdqa  %xmm0, %xmm2
pextrb  $3, %xmm1, %edx
...

One possible improvement would be to move QImode value to %xmm1 and sign-extend
to %xmm0 from %xmm1. Something like:

addup:
movd(%rdi), %xmm1
pmovsxbd%xmm1, %xmm0
movdqa  %xmm0, %xmm2
pextrb  $3, %xmm1, %edx
...

This would save memory read.

[Bug libstdc++/118185] ranges::clamp doesn't perfectly forward its projected arguments

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118185

--- Comment #2 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:d121d1e1dd874731a648086772e6c40e34fa5de9

commit r14-11251-gd121d1e1dd874731a648086772e6c40e34fa5de9
Author: Giuseppe D'Angelo 
Date:   Sun Jan 19 16:30:20 2025 +0100

libstdc++: perfectly forward std::ranges::clamp arguments

As reported in PR118185, std::ranges::clamp does not correctly forward
the projected value to the comparator. Add the missing forward.

libstdc++-v3/ChangeLog:

PR libstdc++/118185
PR libstdc++/100249
* include/bits/ranges_algo.h (__clamp_fn): Correctly forward the
projected value to the comparator.
* testsuite/25_algorithms/clamp/118185.cc: New test.

Signed-off-by: Giuseppe D'Angelo 
Reviewed-by: Patrick Palka 
Reviewed-by: Jonathan Wakely 
(cherry picked from commit b342614139c0a981b369176980663941b9c27f39)

[Bug libstdc++/100249] missing forwarding std::__invoke result in ranges::is_permutation and ranges::clamp

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100249

--- Comment #16 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:d121d1e1dd874731a648086772e6c40e34fa5de9

commit r14-11251-gd121d1e1dd874731a648086772e6c40e34fa5de9
Author: Giuseppe D'Angelo 
Date:   Sun Jan 19 16:30:20 2025 +0100

libstdc++: perfectly forward std::ranges::clamp arguments

As reported in PR118185, std::ranges::clamp does not correctly forward
the projected value to the comparator. Add the missing forward.

libstdc++-v3/ChangeLog:

PR libstdc++/118185
PR libstdc++/100249
* include/bits/ranges_algo.h (__clamp_fn): Correctly forward the
projected value to the comparator.
* testsuite/25_algorithms/clamp/118185.cc: New test.

Signed-off-by: Giuseppe D'Angelo 
Reviewed-by: Patrick Palka 
Reviewed-by: Jonathan Wakely 
(cherry picked from commit b342614139c0a981b369176980663941b9c27f39)

[Bug c++/107522] ICE in parameter_mapping_equivalent_p on trunk

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107522

--- Comment #4 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:0af8fc22338ef0dd09c9b469aafb19262aa8eeb9

commit r14-11250-g0af8fc22338ef0dd09c9b469aafb19262aa8eeb9
Author: Patrick Palka 
Date:   Thu Jan 16 16:40:08 2025 -0500

c++: explicit spec of constrained member tmpl [PR107522]

When defining a explicit specialization of a constrained member template
(of a class template) such as f and g in the below testcase, the
DECL_TEMPLATE_PARMS of the corresponding TEMPLATE_DECL are partially
instantiated, whereas its associated constraints are carried over
from the original template and thus are in terms of the original
DECL_TEMPLATE_PARMS.  So during normalization for such an explicit
specialization we need to consider the (parameters of) the most general
template, since that's what the constraints are in terms of and since we
always use the full set of template arguments during satisfaction.

PR c++/107522

gcc/cp/ChangeLog:

* constraint.cc (get_normalized_constraints_from_decl): Use the
most general template for an explicit specialization of a
member template.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-explicit-spec7.C: New test.

Reviewed-by: Jason Merrill 
(cherry picked from commit 62daa81308c6c187059fcad98377146e30725fa5)

[Bug c++/107522] ICE in parameter_mapping_equivalent_p on trunk

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107522

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |14.3
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 14.3 / 15.

[Bug c++/116524] FAIL: g++.dg/modules/permissive-error-1.C -std=c++17 (internal compiler error: Segmentation fault)

[danglin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116524

John David Anglin  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from John David Anglin  ---
Fixed on trunk.

[Bug fortran/103284] ICE in get_unique_type_string, at fortran/class.c:502

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103284

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
Created attachment 60292
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60292&action=edit
Hackish fix

Confirmed.

This hackish patch fixes the ICE and emits:

pr103284-z1.f90:6:15:

6 |   class(t) :: x
  |   1
Error: CLASS variable 'x' at (1) must be dummy, allocatable or pointer


However, the fix could also be pushed to copy_ts_from_selector_to_associate
if that is a better place.

An expert's opinion in the area of ASSOCIATE is highly welcome.

[Bug c++/118673] New: [14/15 regression] LLVM's libMLIR miscompiled since r14-1705-g2764335bd336f2

[sjames at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118673

Bug ID: 118673
   Summary: [14/15 regression] LLVM's libMLIR miscompiled since
r14-1705-g2764335bd336f2
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 60293
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60293&action=edit
IntegerDotProductOps.cpp.ii.gz

Originally reported in LLVM over at
https://github.com/llvm/llvm-project/issues/124410.

I don't have a standalone runtime testcase though.

The relevant snippet is:
```
template 
static SmallVector, 1>
getIntegerDotProductCapabilities(Operation *op) {
  // Requires the the DotProduct capability and capabilities that depend on
  // exact op types.
  static const auto dotProductCap = spirv::Capability::DotProduct;
  static const auto dotProductInput4x8BitPackedCap =
  spirv::Capability::DotProductInput4x8BitPacked;
  static const auto dotProductInput4x8BitCap =
  spirv::Capability::DotProductInput4x8Bit;
  static const auto dotProductInputAllCap =
  spirv::Capability::DotProductInputAll;

  SmallVector, 1> capabilities = {dotProductCap};

  Type factorTy = op->getOperand(0).getType();
  StringAttr packedVectorFormatAttrName =
  IntegerDotProductOpTy::getFormatAttrName(op->getName());
  if (auto intTy = llvm::dyn_cast(factorTy)) {
auto formatAttr = llvm::cast(
op->getAttr(packedVectorFormatAttrName));
if (formatAttr.getValue() ==
spirv::PackedVectorFormat::PackedVectorFormat4x8Bit)
  capabilities.push_back(dotProductInput4x8BitPackedCap);

return capabilities;
  }

  auto vecTy = llvm::cast(factorTy);
  if (vecTy.getElementTypeBitWidth() == 8) {
capabilities.push_back(dotProductInput4x8BitCap);
return capabilities;
  }

  capabilities.push_back(dotProductInputAllCap);
  return capabilities;
}

SmallVector, 1> UDotAccSatOp::getCapabilities() { 
  return getIntegerDotProductCapabilities(*this);
}
```

Before/after r14-1705-g2764335bd336f2, the only difference (with some prints
added) is:
```
│  Disassembly of section
.text._ZN4mlir5spirvL30getIntegerDotProductExtensionsEv:
│
│   :
│  mlir::spirv::getIntegerDotProductExtensions():
│ - lea0x10(%rdi),%rdx
│ - lea0x0(%rip),%rcx
│ - R_X86_64_PC32  
.rodata._ZZN4mlir5spirvL30getIntegerDotProductExtensionsEvE9extension-0x4
│ + lea-0xc(%rsp),%rdx
│ + lea0x10(%rdi),%rcx
│   mov%rdi,%rax
│   movabs $0x10001,%rsi
│ - mov%rdx,(%rdi)
│ - mov%rcx,0x10(%rdi)
│ + mov%rcx,(%rdi)
│ + mov%rdx,0x10(%rdi)
│   movq   $0x1,0x18(%rdi)
│   mov  
```

The file was built with:
```
$ g++ -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-I/home/sam/llvm/llvm-project/build-bad-after/tools/mlir/lib/Dialect/SPIRV/IR
-I/home/sam/llvm/llvm-project/mlir/lib/Dialect/SPIRV/IR
-I/home/sam/llvm/llvm-project/build-bad-after/tools/mlir/include
-I/home/sam/llvm/llvm-project/mlir/include
-I/home/sam/llvm/llvm-project/build-bad-after/include
-I/home/sam/llvm/llvm-project/llvm/include -fPIC -fno-semantic-interposition
-fvisibility-inlines-hidden -Werror=date-time -fno-lifetime-dse -Wall -Wextra
-Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough
-Wno-maybe-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-redundant-move
-Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor
-Wsuggest-override -Wno-comment -Wno-misleading-indentation
-Wctad-maybe-unsupported -ffunction-sections -fdata-sections -Wundef -Os
-DNDEBUG -std=c++17  -fno-exceptions -funwind-tables -fno-rtti -MD -MT
tools/mlir/lib/Dialect/SPIRV/IR/CMakeFiles/obj.MLIRSPIRVDialect.dir/IntegerDotProductOps.cpp.o
-MF CMakeFiles/obj.MLIRSPIRVDialect.dir/IntegerDotProductOps.cpp.o.d -o
CMakeFiles/obj.MLIRSPIRVDialect.dir/IntegerDotProductOps.cpp.o -c
/home/sam/llvm/llvm-project/mlir/lib/Dialect/SPIRV/IR/IntegerDotProductOps.cpp
-save-temps
```

[Bug c++/118673] [14/15 regression] LLVM's libMLIR miscompiled since r14-1705-g2764335bd336f2

[sjames at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118673

--- Comment #1 from Sam James  ---
If I drop the prints I added to getIntegerDotProductCapabilities, the
difference goes back to:
```
│  Disassembly of section .text._ZN4mlir5spirv6SDotOp15getCapabilitiesEv:
│
│   :
│  mlir::spirv::SDotOp::getCapabilities():
│   push   %r14
│ - lea0x0(%rip),%rax
│ - R_X86_64_PC32  
.rodata._ZZN4mlir5spirvL32getIntegerDotProductCapabilitiesINS0_6SDotOpEEEN4llvm11SmallVectorINS3_8ArrayRefINS0_10CapabilityEEELj1EEEPNS_9OperationEE13dotProductCap-0x4
│   mov$0x1,%edx
│   push   %r13
│   push   %r12
│   push   %rbp
│   push   %rbx
│   mov%rdi,%rbx
│ - sub$0x10,%rsp
│ + sub$0x20,%rsp
│   mov(%rsi),%r13
│ - mov%rsp,%r12
│ - mov%rax,(%rsp)
│ - movq   $0x1,0x8(%rsp)
│ + lea0x10(%rsp),%r12
│ + lea0xc(%rsp),%rax
│ + movl   $0x1783,0xc(%rsp)
│   mov%r12,%rsi
│ - call   36 
│ + mov%rax,0x10(%rsp)
│ + movq   $0x1,0x18(%rsp)
│ + call   3f 
[...]
```

But it clearly affects the loads of the constants, anyway.

[Bug c++/118673] [14/15 regression] LLVM's libMLIR miscompiled since r14-1705-g2764335bd336f2

[sjames at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118673

--- Comment #2 from Sam James  ---
The difference is visible with `g++ IntegerDotProductOps.cpp.ii -Os
-fno-exceptions -fno-rtti -c`.

[Bug c++/118673] [14/15 regression] LLVM's libMLIR miscompiled since r14-1705-g2764335bd336f2

[sjames at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118673

--- Comment #4 from Sam James  ---
Created attachment 60295
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60295&action=edit
006t.gimple-diff.xz (+ is bad)

[Bug c++/118671] [15 regression] ICE in output_constructor_regular_field at, varasm.cc since r15-7089

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118671

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #2 from Jakub Jelinek  ---
Created attachment 60296
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60296&action=edit
gcc15-pr118671.patch

Untested fix.

[Bug c++/118673] [14/15 regression] LLVM's libMLIR miscompiled since r14-1705-g2764335bd336f2

[sjames at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118673

--- Comment #3 from Sam James  ---
Created attachment 60294
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60294&action=edit
005t.original-diff.xz (+ is bad)

[Bug fortran/108454] ICE in gfc_trans_common, at fortran/trans-common.cc:1385

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108454

--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> The code crashing gfortran may actually be valid.

I set a breakpoint in parse.cc:7386
Breakpoint 1, gfc_parse_file () at ../../gcc-trunk/gcc/fortran/parse.cc:7386
7386  gfc_resolve (gfc_current_ns);
(gdb) l
7381}
7382
7383  /* Handle the non-program units.  */
7384  gfc_current_ns->code = s.head;
7385
7386  gfc_resolve (gfc_current_ns);
7387
7388  /* Fix the implicit_pure attribute for those procedures who should
7389 not have it.  */
7390  while (gfc_fix_implicit_pure (gfc_current_ns))
(gdb) call gfc_dump_parse_tree (gfc_current_ns, stdout)

This gives a sane dump.

Now repeating this call after the gfc_resolve in line 7386, the debugged
f951 segfaults.

Program received signal SIGSEGV, Segmentation fault.
0x00eb8aa3 in show_common (st=0x4aae700)
at ../../gcc-trunk/gcc/fortran/dump-parse-tree.cc:1388
1388  fprintf (dumpfile, "%s", s->name);
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(gfc_dump_parse_tree(gfc_namespace*, _IO_FILE*)) will be abandoned.
When the function is done executing, GDB will silently stop.

It looks like the resolution corrupts the namespace.

If one references the variable 't' in the subroutine (e.g., print *,t),
there is no such problem.

[Bug c++/118673] [14/15 regression] LLVM's libMLIR miscompiled since r14-1705-g2764335bd336f2

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118673

--- Comment #5 from Andrew Pinski  ---
mlir::spirv::getIntegerDotProductExtensions:
-TARGET_EXPR >>
-  (const Extension &) &extension }>, ._M_len=1}> >>;
+TARGET_EXPR >>;
+const struct ArrayRef * D.1250733;
+<<< Unknown tree: expr_stmt
+  (void) (D.1250733 = D.1250732) >>>;
+TARGET_EXPR ;
+const Extension * D.1250735;
+<<< Unknown tree: expr_stmt
+  (void) (D.1250735 = (void) TARGET_EXPR ;, (const
Extension *) &D.1250692;) >>>;
+goto ;
+:;
+<>>
+  (const Extension &) NON_LVALUE_EXPR  ) >>>;, 
--D.1250734; >;
+<<< Unknown tree: expr_stmt
+  (void)  ++D.1250733 >>>;
+<<< Unknown tree: expr_stmt
+  (void)  ++D.1250735 >>>;
+:;
+if (D.1250734 >= 0) goto ; else goto ;
+:;
+D.1250732>, ._M_len=1}> >>;

[Bug rtl-optimization/116073] [15 regression] invalid rtl sharing compiling compiling FileSystem.mod caused by ext-dce

[gaius at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116073

Gaius Mulley  changed:

   What|Removed |Added

  Attachment #60272|0   |1
is obsolete||

--- Comment #5 from Gaius Mulley  ---
Created attachment 60298
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60298&action=edit
Proposed fix for 32 bit

Apologies for the breakage.  Here is a proposed fix which changes the default
size of COFF_T to the same as CSSIZE_T.  Bootstrapped successfully on x86_64,
x86_32, aarch64 and ppc64le gnu/linux (and no regression failures).

[Bug c/118674] New: ICE: Segmentation fault

[bic60176 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118674

Bug ID: 118674
   Summary: ICE: Segmentation fault
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bic60176 at gmail dot com
  Target Milestone: ---

Created attachment 60297
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60297&action=edit
testcase

Compiler Explorer: https://godbolt.org/z/7e35Y7ajn

console:
:2:17: warning: '__VA_ARGS__' can only appear in the expansion of a C99
variadic macro
2 | #define A(mode, __VA_ARGS__, ...) __attribute__ ((access (mode)))
  | ^
:2:30: error: duplicate macro parameter '__VA_ARGS__'
2 | #define A(mode, __VA_ARGS__, ...) __attribute__ ((access (mode)))
  |  ^~~
:1: internal compiler error: Segmentation fault
1 | 
0x25ebea5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2602ca6 internal_error(char const*, ...)
???:0
0x269db3e _cpp_create_definition
???:0
0x267da98 _cpp_handle_directive
???:0
0x2694778 _cpp_lex_token
???:0
0xb1a0fa c_lex_with_flags(tree_node**, unsigned long*, unsigned char*, int)
???:0
0xab0229 c_parse_file()
???:0
0xb2eda9 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

[Bug c++/118673] [14/15 regression] LLVM's libMLIR miscompiled since r14-1705-g2764335bd336f2

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118673

--- Comment #6 from Andrew Pinski  ---
the main issue can be shown by (still need includes for SmallVector/ArrayRef):
```
enum class Extension : unsigned {
  SPV_KHR_integer_dot_product = 17
};
[[gnu::noinline]]
llvm::SmallVector, 1>
getIntegerDotProductExtensions() {
  static const auto extension = Extension::SPV_KHR_integer_dot_product;
  return {extension};
}

int main()
{
  auto t = getIntegerDotProductExtensions();
  __builtin_printf("size = %d\n", t.size());
  __builtin_printf("capacity = %d\n", t.capacity());
  __builtin_printf("size = %d\n", t[0].size());
  if (t[0][0] != Extension::SPV_KHR_integer_dot_product)
__builtin_abort();
}
```

I am still trying to just get to that but so far it looks like a temporary
leaves scope and that messes up things. But I could be wrong about a temporary
being not there.

[Bug c/118674] ICE: Segmentation fault

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118674

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2025-01-27

--- Comment #1 from Marek Polacek  ---
Started with r263600:

commit 729a01f72ca6c1bd106cb2285187191c3568201b
Author: Nathan Sidwell 
Date:   Thu Aug 16 19:18:42 2018 +

[PATCH] Macro definition parameter parsing

[Bug c/118674] [12/13/14/15 Regression] ICE: Segmentation fault

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118674

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |12.5
Summary|ICE: Segmentation fault |[12/13/14/15 Regression]
   ||ICE: Segmentation fault
   Keywords||error-recovery
   Priority|P3  |P5

[Bug c++/115769] Implement CWG 2867 - Order of initialization for structured bindings

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115769

--- Comment #13 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:f4d772356725ba7fd5e17835607d967d90cdcdaa

commit r15-7231-gf4d772356725ba7fd5e17835607d967d90cdcdaa
Author: Jakub Jelinek 
Date:   Mon Jan 27 17:17:17 2025 +0100

c++: Handle CWG2867 even in namespace scope structured bindings in header
modules [PR115769]

The following patch implements the module streaming of the new
STATIC_INIT_DECOMP_BASE_P and STATIC_INIT_DECOMP_NONBASE_P flags.  As I
think
namespace scope structured bindings in the header modules will be pretty
rare,
I've tried to stream something extra only when they actually appear, in
that
case it streams extra INTEGER_CSTs which mark end of
STATIC_INIT_DECOMP_*BASE_P (0), start of STATIC_INIT_DECOMP_BASE_P for
static_aggregates (1), start of STATIC_INIT_DECOMP_NONBASE_P for
static_aggregates (2) and ditto for tls_aggregates (3 and 4).
The patch also copies with just small tweaks the testcases from the
namespace scope structured binding CWG2867 patch.

2025-01-27  Jakub Jelinek  

PR c++/115769
gcc/cp/
* module.cc (module_state::write_inits): Verify
STATIC_INIT_DECOMP_{,NON}BASE_P flags and stream changes in those
out.
(module_state::read_inits): Stream those flags in.
gcc/testsuite/
* g++.dg/modules/dr2867-1_a.H: New test.
* g++.dg/modules/dr2867-1_b.C: New test.
* g++.dg/modules/dr2867-2_a.H: New test.
* g++.dg/modules/dr2867-2_b.C: New test.
* g++.dg/modules/dr2867-3_a.H: New test.
* g++.dg/modules/dr2867-3_b.C: New test.
* g++.dg/modules/dr2867-4_a.H: New test.
* g++.dg/modules/dr2867-4_b.C: New test.

[Bug c++/118671] [15 regression] ICE in output_constructor_regular_field at, varasm.cc

[sjames at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118671

Sam James  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |15.0
   Keywords||ice-on-valid-code

[Bug c++/118671] New: [15 regression] ICE in output_constructor_regular_field at, varasm.cc

[enrico.seiler+gccbugs at outlook dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118671

Bug ID: 118671
   Summary: [15 regression] ICE in
output_constructor_regular_field at, varasm.cc
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: enrico.seiler+gccbugs at outlook dot com
  Target Milestone: ---

The following results in an ICE:

```
#include 
#include 

std::vector> a{1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
  1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
  1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
  1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
  1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1};
```

Reduced version without includes:

```
namespace std {

template  struct initializer_list {
private:
  int *_M_array;
  unsigned long _M_len;
};

struct in_place_t {} in_place;

struct optional {
  constexpr optional(int __t) : optional(in_place, __t) {}
  template 
  constexpr optional(in_place_t, _Args... __args) : _M_value(__args...) {}

  int _M_value;
};

struct vector {
  vector(initializer_list);
};

} // namespace std

std::vector a{1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
  1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
  1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
  1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
  1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
  1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1};
```

Compiler Explorer: https://godbolt.org/z/Eja9To1nP

test.cpp:24:74: internal compiler error: in output_constructor_regular_field,
at varasm.cc:5800
   24 |   1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1};
  |
 ^
0x28bba41 internal_error(char const*, ...)
diagnostic-global-context.cc:517
0xab3e27 fancy_abort(char const*, int, char const*)
diagnostic.cc:1722
0x9d71b6 output_constructor_regular_field
varasm.cc:5800
0x9d71b6 output_constructor
varasm.cc:6117
0x181c6c5 assemble_variable_contents
varasm.cc:2440
0x18224ad assemble_variable(tree_node*, int, int, int)
varasm.cc:2619
0x1826b89 varpool_node::assemble_decl()
varpool.cc:596
0xefab33 output_in_order
cgraphunit.cc:2209
0xefab33 symbol_table::compile()
cgraphunit.cc:2415
0xefdb27 symbol_table::compile()
cgraphunit.cc:2329
0xefdb27 symbol_table::finalize_compilation_unit()
cgraphunit.cc:2603

I have not bisected, but I can point to a range:

Last known working:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=e9bd9d427a9b1c080426b0b16d3704673cbf
First known fail:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=06b78732f7ce424ab7d8c619f1ea90936fedff51

[Bug c++/116841] [14 Regression] spurious -Warray-bounds=1 warning when resizing + memcpy-ing into vector

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116841

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
Trunk still emits the warning using gcc 14 preprocessed sources so I suppose it
was a libstdc++ change that fixed this on trunk.

[Bug target/118663] [15 Regression] ICE: in rs6000_emit_move, at config/rs6000/rs6000.cc:11091 during libgcc build - caused by r15-7008-g9f009e8865cda0

[vmakarov at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663

--- Comment #8 from Vladimir Makarov  ---
(In reply to Peter Bergner from comment #6)
> (In reply to Segher Boessenkool from comment #5)
> > I cannot get the testcase to fail at all.  Please give a failing command
> > line?
> 
> I just used -O2 -mcpu=601.  I noticed this passes with -mcpu=602.

I've reproduced the crash.  I'll try to fix it as soon as possible, probably
tomorrow.

[Bug middle-end/116845] gcc.dg/pr109393.c test fails on ilp32 targets (and maybe others)

[sjames at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116845

--- Comment #10 from Sam James  ---
(In reply to Konstantinos Eleftheriou from comment #9)
> But, this isn't the case for AArch64 using ILP32, which isn't optimized at 
> all.

We've just deprecated that, mind (doesn't negate that it could affect other
targets, I just wouldn't focus on it for arm64 ilp32).

[Bug c++/94404] [meta-bug] C++ core issues

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
Bug 94404 depends on bug 115769, which changed state.

Bug 115769 Summary: Implement CWG 2867 - Order of initialization for structured 
bindings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115769

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug rtl-optimization/118638] [14/15 Regression] Miscompile with -Os and -O0/1/2/3 since r14-4810

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118638

--- Comment #15 from Jakub Jelinek  ---
So the bug is in
  else if (GET_CODE (inner) == MULT
   && CONST_INT_P (XEXP (inner, 1))
   && pos_rtx == 0 && pos == 0)
{
  /* We're extracting the least significant bits of an rtx
 (mult X (const_int 2^C)), where LEN > C.  Extract the
 least significant (LEN - C) bits of X, giving an rtx
 whose mode is MODE, then multiply it by 2^C.  */
  const HOST_WIDE_INT shift_amt = exact_log2 (INTVAL (XEXP (inner, 1)));
  if (IN_RANGE (shift_amt, 1, len - 1))
{
  new_rtx = make_extraction (mode, XEXP (inner, 0),
 0, 0, len - shift_amt,
 unsignedp, in_dest, in_compare);
  if (new_rtx)
return gen_rtx_MULT (mode, new_rtx, XEXP (inner, 1));
}
}
in combine.cc (make_extraction).
len is 1, it is multiplication by const_int 3, so shift_amt is -1.
And the reason it triggers is that it violates the IN_RANGE requirements:
Note the LOWER bound *is* evaluated twice, and LOWER must not be greater than
UPPER.
Here LOWER is 1, UPPER is 0, so LOWER is greater than UPPER.
This bug has been introduced in PR96998 r11-4563.

[Bug c++/118661] [12/13/14/15 regression] Reading volatile qualified std::nullptr_t should be valid in a constant expression

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118661

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P2
   Keywords|needs-bisection |
 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
(In reply to Andrew Pinski from comment #3)
> Confirmed. Note I think there is 2 different changes which caused this.
> 
> That is a change in 8 caused use to reject:
> ```
> typedef decltype(nullptr) tt;
> constexpr volatile tt n{};
> constexpr tt m=n;
> ```

Since my r9-4793:

commit 3c393a2c012f7f5f1c3df7d6d7b17a9cf992af17
Author: Marek Polacek 
Date:   Tue Dec 11 18:53:03 2018 +

PR c++/86608 - reading constexpr volatile variable.


> But it was not until GCC 9 we (correctly) rejected:
> ```
> constexpr volatile int n1{};
> constexpr short m1=n1;
> ```

Same change.

[Bug fortran/110993] Possibly bogus diagnostic on renamed interface import

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110993

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:9104472b645f76a212af9f9c58378500f9ba937e

commit r15-7234-g9104472b645f76a212af9f9c58378500f9ba937e
Author: Harald Anlauf 
Date:   Sun Jan 26 22:56:57 2025 +0100

Fortran: fix bogus diagnostics on renamed interface import [PR110993]

PR fortran/110993

gcc/fortran/ChangeLog:

* frontend-passes.cc (check_externals_procedure): Do not compare
interfaces of a non-bind(C) procedure against a bind(C) global one.
(check_against_globals): Use local name from rename-on-use in the
search for interfaces.

gcc/testsuite/ChangeLog:

* gfortran.dg/use_rename_14.f90: New test.

[Bug c++/115769] Implement CWG 2867 - Order of initialization for structured bindings

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115769

--- Comment #12 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:ad8e6a4ada0a7ed73ac99404ff2b41ed9dc5e940

commit r15-7230-gad8e6a4ada0a7ed73ac99404ff2b41ed9dc5e940
Author: Jakub Jelinek 
Date:   Mon Jan 27 16:45:56 2025 +0100

c++: Implement for namespace statics CWG 2867 - Order of initialization for
structured bindings [PR115769]

The following patch adds CWG 2867 support for namespace locals.

Those vars are just pushed into {static,tls}_aggregates chain, then
pruned from those lists, separated by priority and finally emitted into
the corresponding dynamic initialization functions.
The patch adds two flags used on the TREE_LIST nodes in those lists,
one marks the structured binding base variable and/or associated ref
extended temps, another marks the vars initialized using get methods.
The flags are preserved across the pruning, for splitting into by priority
all associated decls of a structured binding using tuple* are forced
into the same priority as the first one, and finally when actually emitting
code, CLEANUP_POINT_EXPRs are disabled in the base initializer(s) and
code from the bases and non-bases together is wrapped into a single
CLEANUP_POINT_EXPR.

2025-01-27  Jakub Jelinek  

PR c++/115769
gcc/cp/
* cp-tree.h (STATIC_INIT_DECOMP_BASE_P): Define.
(STATIC_INIT_DECOMP_NONBASE_P): Define.
* decl.cc (cp_finish_decl): Mark nodes in {static,tls}_aggregates
emitted for namespace scope structured bindings with
STATIC_INIT_DECOMP_{,NON}BASE_P flags when needed.
* decl2.cc (decomp_handle_one_var, decomp_finalize_var_list): New
functions.
(emit_partial_init_fini_fn): Use them.
(prune_vars_needing_no_initialization): Assert
STATIC_INIT_DECOMP_*BASE_P is not set on DECL_EXTERNAL vars to be
pruned out.
(partition_vars_for_init_fini): Use same priority for
consecutive STATIC_INIT_DECOMP_*BASE_P vars and propagate
those flags to new TREE_LISTs when possible.  Formatting fix.
(handle_tls_init): Use decomp_handle_one_var and
decomp_finalize_var_list functions.
gcc/testsuite/
* g++.dg/DRs/dr2867-5.C: New test.
* g++.dg/DRs/dr2867-6.C: New test.
* g++.dg/DRs/dr2867-7.C: New test.
* g++.dg/DRs/dr2867-8.C: New test.

[Bug c++/118671] [15 regression] ICE in output_constructor_regular_field at, varasm.cc

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118671

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P1
   Last reconfirmed||2025-01-27
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Started with r15-7089:

commit f31d49d65412d03d2cf91dd3b8b7281815c6d03b
Author: Jakub Jelinek 
Date:   Tue Jan 21 09:15:53 2025 +0100

c++: Speed up compilation of large char array initializers when not using
#embed

[Bug rtl-optimization/118662] [14 regression] -ftree-slp-vectorize with -mavx causes incorrect math since r14-9316-g7890836de20912

[rguenther at suse dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662

--- Comment #17 from rguenther at suse dot de  ---
> Am 27.01.2025 um 17:38 schrieb ubizjak at gmail dot com 
> :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662
> 
> --- Comment #15 from Uroš Bizjak  ---
> The testcase now generates (-O2 -ftree-slp-vectorize -fno-vect-cost-model
> -msse4):
> 
> addup:
>pmovsxbd(%rdi), %xmm0
>movd(%rdi), %xmm1
>movdqa  %xmm0, %xmm2
>pextrb  $3, %xmm1, %edx
>...
> 
> One possible improvement would be to move QImode value to %xmm1 and 
> sign-extend
> to %xmm0 from %xmm1. Something like:
> 
> addup:
>movd(%rdi), %xmm1
>pmovsxbd%xmm1, %xmm0
>movdqa  %xmm0, %xmm2
>pextrb  $3, %xmm1, %edx
>...
> 
> This would save memory read.

IIRC there are a few bugreports that we tend to Duplikate Memory loads into
instructions that can handle memory operands.

> 
> --
> You are receiving this mail because:
> You are the assignee for the bug.
> You are on the CC list for the bug.

[Bug rtl-optimization/118638] [14/15 Regression] Miscompile with -Os and -O0/1/2/3 since r14-4810

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118638

--- Comment #14 from Jakub Jelinek  ---
make_compound_operation_int incorrectly turns
(ashiftrt:SI (ashift:SI (mult:SI (reg:SI 107 [ a_5 ])
(const_int 3 [0x3]))
(const_int 31 [0x1f]))
(const_int 31 [0x1f]))
into
(mult:SI (sign_extract:SI (reg:SI 107 [ a_5 ])
(const_int 2 [0x2])
(const_int 0 [0]))
(const_int 3 [0x3]))
Result of the original is -1 or 0, while the result of the latter is -3 or 0
(and testing a different bit than it should).
Given multiplication by 3 which is 2 * a_5 + a_5 where former is even and the
latter maybe odd, it is actually equivalent to just (sign_extract:SI (reg:SI
107 [ a_5 ]) (const_int 1 [0x1]) (const_int 0 [0])).

[Bug c++/116524] FAIL: g++.dg/modules/permissive-error-1.C -std=c++17 (internal compiler error: Segmentation fault)

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116524

--- Comment #3 from GCC Commits  ---
The master branch has been updated by John David Anglin :

https://gcc.gnu.org/g:9d450dee7112635a541c5a34268d54f63da48f71

commit r15-7233-g9d450dee7112635a541c5a34268d54f63da48f71
Author: John David Anglin 
Date:   Mon Jan 27 12:39:00 2025 -0500

c++: Use mapped reads and writes when munmap and msync are available

Module support is broken when MAPPED_READING and MAPPED_WRITING
are defined to 0.  This causes internal compiler errors in the
permissive-error-1.C and permissive-error-2.C tests.

HP-UX 11.11 doesn't define _POSIX_MAPPED_FILES but it does have
munmap and msync.  Testing indicates support is sufficient for
c++ modules, so use checks for these functions instead of
_POSIX_MAPPED_FILES check.

2025-01-27  John David Anglin  

gcc/ChangeLog:

PR c++/116524
* configure.ac: Check for munmap and msync.
* configure: Regenerate.
* config.in: Regenerate.

gcc/cp/ChangeLog:
* module.cc: Test HAVE_MUNMAP and HAVE_MSYNC instead of
_POSIX_MAPPED_FILES > 0.