[Bug target/120687] RISC-V: very poor vector code gen for LMbench bw_mem test case

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org,
   ||rdapp at gcc dot gnu.org
 Target||riscv64-unknown-linux-gnu

--- Comment #1 from Peter Bergner  ---
Compiled with -O3 -march=rv64gcv

[Bug target/120687] RISC-V: very poor vector code gen for LMbench bw_mem test case

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

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
I similarly see this generates ~200 lines of assembly for aarch64 compared to
~20 with Clang so I'd mark it as target-independent.
I think I remember a bug in the past about the need for loop rerolling
functionality in the vectoriser

[Bug target/120687] RISC-V: very poor vector code gen for LMbench bw_mem test case

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

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

--- Comment #3 from Robin Dapp  ---
Yeah, for 8 elements we still have a mode but beyond 8 we at least cannot do a
segment access anymore.  Then we try with even/odd or interleaved permutations.
 I kind of wonder why the cost model doesn't reject them, that's probably the
saner thing to do for now.

On x86 at least, not vectorizing such a loop was the  more performant way last
I checked.

[Bug middle-end/120631] [16 Regression] ICE: in decimal_integer_string, at real.cc:2342 when mixing _BitInt() and _Decimal constants

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2025-06-17
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Jakub Jelinek  ---
Created attachment 61655
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61655&action=edit
gcc16-pr120631.patch

Untested fix.

[Bug c/120658] OPTIMIZATION: STRING HANDLING: wrong results under exotic conditions.

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Eric Botcazou  ---
Compiling with -fsanitize=address -g yields:

TO_BASE( (uint)x1i, 10 ): 4287654321 
=
==11341==ERROR: AddressSanitizer: stack-use-after-scope on address
0x7fca89d000d6 at pc 0x7fca8be9ef7c bp 0x7ffeeb477d40 sp 0x7ffeeb477500
READ of size 11 at 0x7fca89d000d6 thread T0
#0 0x7fca8be9ef7b  (/usr/lib64/libasan.so.8+0x9ef7b) (BuildId:
4ee117fa2a132af1da9f17a0a5fe1f888398d50f)
#1 0x7fca8becac3a in vprintf (/usr/lib64/libasan.so.8+0xcac3a) (BuildId:
4ee117fa2a132af1da9f17a0a5fe1f888398d50f)
#2 0x7fca8becc82e in printf (/usr/lib64/libasan.so.8+0xcc82e) (BuildId:
4ee117fa2a132af1da9f17a0a5fe1f888398d50f)
#3 0x401198 in main /home/eric/bin_dec_conversion.c:159
#4 0x7fca8ba40e6b in __libc_start_call_main (/lib64/libc.so.6+0x40e6b)
(BuildId: 8cd6cc55dddb025d49c90d45e7ace66d04f55c4a)
#5 0x7fca8ba40f34 in __libc_start_main_alias_1 (/lib64/libc.so.6+0x40f34)
(BuildId: 8cd6cc55dddb025d49c90d45e7ace66d04f55c4a)
#6 0x400ac0 in _start ../sysdeps/x86_64/start.S:115

Address 0x7fca89d000d6 is located in stack of thread T0 at offset 214 in frame
#0 0x400ccc in main /home/eric/bin_dec_conversion.c:140

  This frame has 11 object(s):
[32, 36) 'x1i' (line 142)
[48, 56) 'start1' (line 141)
[80, 88) 'end1' (line 141)
[112, 145) ''
[192, 225) '' <== Memory access at offset 214 is inside this
variable
[272, 305) ''
[352, 385) ''
[432, 465) ''
[512, 545) ''
[592, 848) 'chbuf256' (line 144)
[912, 1169) 'chbuf257' (line 146)
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-scope
(/usr/lib64/libasan.so.8+0x9ef7b) (BuildId:
4ee117fa2a132af1da9f17a0a5fe1f888398d50f) 
Shadow bytes around the buggy address:
  0x7fca89cffe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fca89cffe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fca89cfff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fca89cfff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fca89d0: f1 f1 f1 f1 04 f2 00 f2 f2 f2 00 f2 f2 f2 00 00
=>0x7fca89d00080: 00 00 01 f2 f2 f2 f2 f2 f8 f8[f8]f8 f8 f2 f2 f2
  0x7fca89d00100: f2 f2 00 00 00 00 01 f2 f2 f2 f2 f2 00 00 00 00
  0x7fca89d00180: 01 f2 f2 f2 f2 f2 00 00 00 00 01 f2 f2 f2 f2 f2
  0x7fca89d00200: 00 00 00 00 01 f2 f2 f2 f2 f2 00 00 00 00 00 00
  0x7fca89d00280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fca89d00300: 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 f2 f2
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb

In other words, there is a buffer overflow in the code caused by the compound
literal nested in the TO_BASE macro.

[Bug c++/120686] New: ICE on a lambda that uses parameter pack capture and parameter pack indexing in decltype return type

[e.siga at proton dot me via Gcc-bugs]

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

Bug ID: 120686
   Summary: ICE on a lambda that uses parameter pack capture and
parameter pack indexing in decltype return type
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: e.siga at proton dot me
  Target Milestone: ---

template
struct constant {};

template
auto fast_tuple(Args... args)
{
return
[...args = args]

(constant)
-> decltype(args...[I])
{
return args...[I];
};
}

int main()
{
auto r = fast_tuple(1, 2.0);
auto &&ll = r(constant<0>{});
}

==

https://godbolt.org/z/Y44sT6qdr

Unfortunately I couldn't minimize this code snippet more:
* If you change the return type of the lambda (-> decltype(args...[I])), it
stops crashing
* If you remove constant and start using non-deduced index, it stops
crashing

Somehow the synergy of these features causes the crash

[Bug c++/120686] ICE on a lambda that uses parameter pack capture and parameter pack indexing in decltype return type

[e.siga at proton dot me via Gcc-bugs]

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

--- Comment #1 from Egor Bychin  ---
FYI: clang has a similar issue
https://github.com/llvm/llvm-project/issues/144540

[Bug ada/120665] assertion failure on container Aggregate aspect

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

[Bug target/120687] New: RISC-V: very poor vector code gen for LMbench bw_mem test case

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

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

Bug ID: 120687
   Summary: RISC-V: very poor vector code gen for LMbench bw_mem
test case
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

We've seen some VERY poor vector code gen for the bw_mem test case in LMbench
for certain numbers of loads in the loop.  I have extracted a simple test case
that shows the issue.  For smallish numbers of loads, I get what I would
generally expect:

linux%~:PR$ cat bw_mem_8.c
int
frd (int *p, int *lastone)
{
  int sum = 0;
  for (; p <= lastone; p += 8)
sum += p[0] + p[1] + p[2] + p[3] + p[4] + p[5] + p[6] + p[7];
  return sum;
}
linux%~$ riscv64-unknown-linux-gnu-gcc -S -O3 -march=rv64gcv bw_mem_8.c
linux%~$ cat bw_mem_8.s
[snip] looking at just main loop body...
.L3:
vsetvli a5,a4,e32,m1,tu,ma
vlseg8e32.v v8,(a0)
sllia3,a5,5
sub a4,a4,a5
add a0,a0,a3
vadd.vv v1,v9,v8
vadd.vv v1,v1,v10
vadd.vv v1,v1,v11
vadd.vv v1,v1,v12
vadd.vv v1,v1,v13
vadd.vv v1,v1,v14
vadd.vv v1,v1,v15
vadd.vv v2,v1,v2
bne a4,zero,.L3
[snip]

If I double the number of loads and update the loop increment to match, I see:
linux%~$ cat bw_mem_16.c
int
frd (int *p, int *lastone)
{
  int sum = 0;
  for (; p <= lastone; p += 16)
sum += p[0] + p[1] + p[2] + p[3] + p[4] + p[5] + p[6] + p[7]
   + p[8] + p[9] + p[10] + p[11] + p[12] + p[13] + p[14] + p[15];
  return sum;
}
linux%~$ riscv64-unknown-linux-gnu-gcc -S -O3 -march=rv64gcv bw_mem_16.c
linux%~$ cat bw_mem_16.s
[snip] looking at just main loop body...
.L4:
add s4,a4,a3
addis2,s4,16
vle32.v v11,0(s2)
vmv1r.v v0,v2
vle32.v v13,0(s4)
addis1,s4,32
vle32.v v19,0(s1)
addis0,s4,48
vcompress.vmv21,v11,v0
vmv1r.v v0,v1
vle32.v v10,0(s0)
addis5,s4,64
vcompress.vmv20,v11,v0
vmv1r.v v0,v2
vle32.v v18,0(s5)
addit2,s4,80
vcompress.vmv11,v13,v0
vmv1r.v v0,v1
vle32.v v9,0(t2)
vslideup.vi v11,v21,2
vcompress.vmv15,v13,v0
vmv1r.v v0,v2
addit0,s4,96
vslideup.vi v15,v20,2
vcompress.vmv13,v19,v0
vmv1r.v v0,v1
vle32.v v14,0(t0)
addit6,s4,112
vcompress.vmv21,v19,v0
vmv1r.v v0,v2
vle32.v v8,0(t6)
addit5,s4,128
vcompress.vmv20,v10,v0
vmv1r.v v0,v1
vle32.v v17,0(t5)
[snip] ...this goes on for many pages!
vcompress.vmv8,v7,v0
vslideup.vi v10,v9,2
vcompress.vmv7,v6,v0
vadd.vv v3,v3,v12
vcompress.vmv6,v5,v0
vslideup.vi v8,v7,2
vadd.vv v3,v3,v10
vcompress.vmv7,v4,v0
vcompress.vmv5,v24,v0
vadd.vv v3,v3,v8
vslideup.vi v6,v7,2
vcompress.vmv7,v22,v0
vcompress.vmv4,v20,v0
vadd.vv v3,v3,v6
vslideup.vi v5,v7,2
vcompress.vmv6,v18,v0
vadd.vv v3,v3,v5
vslideup.vi v4,v6,2
vadd.vv v3,v3,v4
vle32.v v4,0(sp)
vadd.vv v3,v4,v3
vse32.v v3,0(sp)
bne a3,s3,.L4
[snip] end of main loop.

Counting the number of insns in the loop, I'm seeing over 20 times the number
of instructions in this loop over the 8 element test case!

The original bw_mem test case in LMbench does 128 loads within the loop which
just exacerbates the issue even more.


I'm marking this as a target bug for now until we know more...

[Bug modula2/120673] Mutually dependent types crash the compiler

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

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

--- Comment #2 from Gaius Mulley  ---
Created attachment 61654
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61654&action=edit
Proposed fix which detects cyclic type dependencies

This patch fixes an ICE which will occur if cyclic dependent types
are used when declaring a variable.  This patch detects the
cyclic dependency and issues an error message for each outstanding
component.

[Bug fortran/120637] Memory leak in finalization gfortran 9.5-16.0

[antony at cosmologist dot info via Gcc-bugs]

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

--- Comment #2 from Antony Lewis  ---
Gemini and o3-pro, after some iteration, think this bug is due to reusing stale
cache pointers, which seems plausible to me and fits the erratic behaviour. 
FWIW there is description and possible workaround at

https://github.com/cmbant/gcc/pull/2

Personally, as a total gcc-nonexpert, it's not clear to me why this cache is
needed at all: for allocatables, there should never be two ways to access the
same instance via allocatable references, so would have though the problematic
(incorrect) "return" could simplify be removed along with the other reuse
caching, since the finalization tree should never repeat frees if the logic is
consistent. Was this a workaround for earlier finalization logic bugs?

[Bug target/120683] vector_loop generates poor codes on memset/memcpy

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

Summary|vector_loop generates   |vector_loop generates poor
   |horrible prologue and   |codes on memset/memcpy
   |epilogue on memset/memcpy   |

--- Comment #2 from H.J. Lu  ---
ix86_expand_set_or_cpymem has:

  /* For now vector-version of memset is generated only for memory zeroing, as
 creating of promoted vector value is very cheap in this case.  */
  if (issetmem && alg == vector_loop && val_exp != const0_rtx)
alg = unrolled_loop;

ix86_expand_vector_init_duplicate can handle variable and non-zero value.

[Bug tree-optimization/120661] [16 regression] compiler hang at -O{s,2,3} on x86_64-linux-gnu

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Andrew Macleod :

https://gcc.gnu.org/g:9244ea4bf556381d3f7fb66154dc8944ebeb005c

commit r16-1550-g9244ea4bf556381d3f7fb66154dc8944ebeb005c
Author: Andrew MacLeod 
Date:   Mon Jun 16 15:41:47 2025 -0400

Snap subrange boundries to bitmask constraints.

Ensure all subrange endpoints conform to the bitmask.

PR tree-optimization/120661
gcc/
* value-range.cc (irange::snap): New.
(irange::snap_subranges): New.
(irange::set_range_from_bitmask): Call snap_subranges.
* value-range.h (snap, snap_subranges): New prototypes.

gcc/testsuite/
* gcc.dg/pr120661-1.c: New.
* gcc.dg/pr120661-2.c: New.

[Bug tree-optimization/120661] [16 regression] compiler hang at -O{s,2,3} on x86_64-linux-gnu

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Macleod  ---
Hopefully that should fix it.

[Bug target/117974] RISC-V: VSETVL hoisting across branch

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

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

Vineet Gupta  changed:

   What|Removed |Added

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

--- Comment #10 from Vineet Gupta  ---
Fixed with

commit 1c5e99ce8744c166d82cb96bbb2d58392b5fb8d7
Author: Edwin Lu 
Date:   Tue Jun 10 13:26:42 2025 -0700

RISC-V: Prevent speculative vsetvl insn scheduling

The instruction scheduler appears to be speculatively hoisting vsetvl
insns outside of their basic block without checking for data
dependencies. This resulted in a situation where the following occurs

vsetvli a5,a1,e32,m1,tu,ma
vle32.v v2,0(a0)
sub a1,a1,a5 <-- a1 potentially set to 0
sh2add  a0,a5,a0
vfmacc.vv   v1,v2,v2
vsetvli a5,a1,e32,m1,tu,ma <-- incompatible vinfo. update vl to 0
beq a1,zero,.L12 <-- check if avl is 0

This patch would essentially delay the vsetvl update to after the branch
to prevent unnecessarily updating the vinfo at the end of a basic block.

PR/117974

[Bug ipa/120693] ICE: during GIMPLE pass: modref

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-checking
Summary|[16 Regression] ICE: during |ICE: during GIMPLE pass:
   |GIMPLE pass: modref |modref

--- Comment #1 from Andrew Pinski  ---
/* We assume that containment was tested earlier.  */
  gcc_checking_assert (!contains (a) && !a.contains (*this));

[Bug ipa/120693] ICE: during GIMPLE pass: modref

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Andrew Pinski  ---
Yes it is a dup.

*** This bug has been marked as a duplicate of bug 116296 ***

[Bug ipa/116296] [12/13/14/15/16 Regression] internal compiler error: in merge, at ipa-modref-tree.cc:176 at -O3 since r12-4227-g44b61586d8640b

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ewlu at rivosinc dot com

--- Comment #6 from Andrew Pinski  ---
*** Bug 120693 has been marked as a duplicate of this bug. ***

[Bug c++/116418] [12 Regression] statement expressions as initializer for decltype auto breaks in templates with optimization turned on and debug info turned on due to gstatement-frontiers

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

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

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

https://gcc.gnu.org/g:2230c7a505d88ac5fa6f85d7da5fb3a2e09a4cba

commit r12-11202-g2230c7a505d88ac5fa6f85d7da5fb3a2e09a4cba
Author: Patrick Palka 
Date:   Thu Sep 12 12:45:03 2024 -0400

c++: decltype(auto) deduction of statement-expression [PR116418]

r8-7538 for PR84968 made strip_typedefs_expr diagnose STATEMENT_LIST
so that we reject statement-expressions in noexcept-specifiers to
match our behavior in template arguments (which the parser diagnoses
directly).

Later r11-7452 made decltype(auto) deduction canonicalize the expression
(as an implementation detail) which in turn calls strip_typedefs_expr,
and so ever since we inadvertently reject decltype(auto) deduction of a
statement-expression.

This patch just removes the diagnostic in strip_typedefs_expr and instead
treats statement-expressions similar to lambda-expressions.  The function
doesn't seem like the right place for such a diagnostic and so it seems
easier to just accept rather than try to reject them in a suitable place.

PR c++/116418

gcc/cp/ChangeLog:

* tree.cc (strip_typedefs_expr) : Replace
this error path with ...
: ... this, returning the original tree.

gcc/testsuite/ChangeLog:

* g++.dg/eh/pr84968.C: No longer expect an ahead of time diagnostic
for the statement-expresssion.  Instantiate the template and expect
an incomplete type error instead.
* g++.dg/ext/stmtexpr26.C: New test.

Reviewed-by: Jason Merrill 
(cherry picked from commit 12bdcc3d7970860b9d66ed4dea203bde8fd68d4d)

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 116418 Summary: [12 Regression] statement expressions as initializer for 
decltype auto breaks in templates with optimization turned on and debug info 
turned on due to gstatement-frontiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116418

   What|Removed |Added

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

[Bug c/120691] New: _Decimal128 arithmetic error under FE_UPWARD

[madams846 at hotmail dot com via Gcc-bugs]

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

Bug ID: 120691
   Summary: _Decimal128 arithmetic error under FE_UPWARD
   Product: gcc
   Version: 13.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: madams846 at hotmail dot com
  Target Milestone: ---

The program

#include   
#include 
_Decimal128x2 =   1  ;
int   main()   {
fesetround( FE_UPWARD );
_Decimal128   x1 =  9825 ;
printf(" x1/x2   %DDf  ",  x1 / x2  );
return   0 ;
}

compiled with   gcc  program.c  -lm -ldfp

produces output   x1/x2   9.825000on my system.  Same result for any
optimization level.  

The same program produces correct output  " x1/x2   0.982500 "  without  
fesetround  or with type double constants  1.0  9825.0  or with other
decimal types _Decimal64 _Decimal32.  The same program with other x1 values
9823 or 9826 also produces correct output.

This bug arose in a larger program that converts floating points to
multi-integers for computations then back from integers to floating points, and
that larger program is supposed to work for any float type and any rounding
mode.

(The sample program above declares x2 as a global so that printf will work on
my system, reported.)

My system:  gcc version 13.3.0-6ubuntu2~24.04, ldfp version 1.0.16-1ubuntu2,
libc6 version 2.39-0ubuntu8.4, installed on Ubuntu 24.04.2 LTS (GNU/Linux
6.6.87.1-microsoft-standard-WSL2 x86_64) running in WSL 5.10.102.1 on Windows
11 Home 24H2 OS build 26100.4351, on a Dell PC 64-bit 11th Gen Intel(R)
Core(TM) i5-1135G7 @ 2.40GHz .  

Thanks.

[Bug c++/120692] New: Copying of adjacent fields can be merged

[hiraditya at msn dot com via Gcc-bugs]

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

Bug ID: 120692
   Summary: Copying of adjacent fields can be merged
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hiraditya at msn dot com
  Target Milestone: ---

Saw this on X(https://x.com/joseph_h_garvin/status/1934705584705843340)
Assigning adjacent field of struct can be merged as a copy but clang does not
recognize it when the data types are different.

Repro:

```cpp
#include 

struct handle {
void* data; // Replacing it with int data works.
int index;
};

void remove(handle* p, int idx, int& end)
{
auto& item = p[idx];
auto& last = p[end];
item = last;
--end;
}

void remove2(handle* p, int idx, int& end)
{
auto& item = p[idx];
auto& last = p[end];
item.data = last.data;
item.index = last.index;
--end;
}
```

$ clang -O2
```asm
remove(handle*, int, int&):
ldrsw   x8, [x2]
ldr q0, [x0, x8, lsl #4]
str q0, [x0, w1, sxtw #4]
ldr w8, [x2]
sub w8, w8, #1
str w8, [x2]
ret

remove2(handle*, int, int&):
ldrsw   x8, [x2]
add x9, x0, w1, sxtw #4
add x8, x0, x8, lsl #4
ldr w10, [x8, #8]
ldr x8, [x8]
str w10, [x9, #8]
ldr w10, [x2]
str x8, [x9]
sub w8, w10, #1
str w8, [x2]
ret
```

https://godbolt.org/z/61avd145T

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

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

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

--- Comment #52 from John David Anglin  ---
Created attachment 61656
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61656&action=edit
Patch

The attached modification to the v18 patch to gcc/ada/s-oscons-tmplt.c
fixes the gnat endian issue handling the __timespec64 struct.  Tested
on hppa-unknown-linux-gnu.

[Bug ipa/120693] New: [16 Regression] ICE: during GIMPLE pass: modref

[ewlu at rivosinc dot com via Gcc-bugs]

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

Bug ID: 120693
   Summary: [16 Regression] ICE: during GIMPLE pass: modref
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ewlu at rivosinc dot com
  Target Milestone: ---

Testcase:
extern _Bool a[][1];
void b(short c, long d[][11]) {
  for (long e = 0; e < 1; e += -3184629396648244933)
a[e][e] = c ? d[e][e] : 0;
}

Godbolt: https://godbolt.org/z/ff9v3388j

Found while fuzzing for riscv64. 
riscv command/backtrace:
$
/scratch/ewlu/daily-upstream-build/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
-I/scratch/ewlu/ci/compiler-fuzz-ci/csmith-build/include -fsigned-char
-fno-strict-aliasing -fwrapv -O3 red.c -o rv64gcv.out -w -frepo
rt-bug
during GIMPLE pass: modref
red.c: In function 'b':
red.c:2:6: internal compiler error: in merge, at ipa-modref-tree.cc:176
2 | void b(short c, long d[][11]) {
  |  ^
0x2e17566 internal_error(char const*, ...)
../../../gcc/gcc/diagnostic-global-context.cc:517
0xd0f517 fancy_abort(char const*, int, char const*)
../../../gcc/gcc/diagnostic.cc:1803
0xb60725 modref_access_node::merge(modref_access_node const&, bool)
../../../gcc/gcc/ipa-modref-tree.cc:176
0x1224c14 modref_access_node::try_merge_with(vec*&, unsigned long)
../../../gcc/gcc/ipa-modref-tree.cc:457
0x122684e modref_access_node::insert(vec*&, modref_access_node, unsigned long, bool)
../../../gcc/gcc/ipa-modref-tree.cc:562
0x12215d2 modref_ref_node::insert_access(modref_access_node, unsigned
long, bool)
../../../gcc/gcc/ipa-modref-tree.h:194
0x12215d2 modref_tree::insert(unsigned int, unsigned int, unsigned int,
int, int, modref_access_node, bool)
../../../gcc/gcc/ipa-modref-tree.h:444
0x12137a3 modref_tree::insert(tree_node*, int, int, modref_access_node
const&, bool)
../../../gcc/gcc/ipa-modref-tree.h:471
0x12137a3 record_access
../../../gcc/gcc/ipa-modref.cc:1086
0x12141e9 analyze_load
../../../gcc/gcc/ipa-modref.cc:1721
0x11503d4 walk_stmt_load_store_addr_ops(gimple*, void*, bool (*)(gimple*,
tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*,
void*), bool (*)(gimple*, tree_node*, tree_node*, void*))
../../../gcc/gcc/gimple-walk.cc:825
0x121a90d analyze_stmt
../../../gcc/gcc/ipa-modref.cc:1801
0x121c1cf analyze
../../../gcc/gcc/ipa-modref.cc:1914
0x121c1cf analyze_function
../../../gcc/gcc/ipa-modref.cc:3241
0x121d99e execute
../../../gcc/gcc/ipa-modref.cc:4262
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.

Found via fuzzer

[Bug c++/116418] [12 Regression] statement expressions as initializer for decltype auto breaks in templates with optimization turned on and debug info turned on due to gstatement-frontiers

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #15 from Patrick Palka  ---
Fixed for 12.5 as well

[Bug c++/84075] [12/13/14/15/16 Regression] Template parameter not resolved: invalid application of ‘sizeof’ to incomplete type ‘boost::serialization::U’

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

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

Patrick Palka  changed:

   What|Removed |Added

  Known to work|14.1.0, 15.0|
Summary|[12/13 Regression] Template |[12/13/14/15/16 Regression]
   |parameter not resolved: |Template parameter not
   |invalid application of  |resolved: invalid
   |‘sizeof’ to incomplete type |application of ‘sizeof’ to
   |‘boost::serialization::U’   |incomplete type
   ||‘boost::serialization::U’
  Known to fail||14.1.0, 15.0

--- Comment #18 from Patrick Palka  ---
While GCC 14+ accepts the reduced testcase, the undeduced testcase is still
rejected so I don't think we can consider this fixed there.

[Bug c++/84075] [12/13/14/15/16 Regression] Template parameter not resolved: invalid application of ‘sizeof’ to incomplete type ‘boost::serialization::U’

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/108848] [12 Regression] template keyword incorrectly required to access template class static member of non-dependent expression using member syntax in dependent context

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|12.5|13.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Patrick Palka  ---
Fixed for GCC 13+, the patch is not suitable for backporting

[Bug target/120689] [12/13/14/15/16 Regression] Codegen optimization regression passing struct in register in gcc 10+ on x86-64 since r10-577

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

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

--- Comment #3 from Jakub Jelinek  ---
So, can't we just keep cris doing what it wants and not penalize other arches
because of that?
Like:
--- gcc/function.cc.jj  2025-05-20 08:14:06.105410349 +0200
+++ gcc/function.cc 2025-06-17 20:03:03.457413807 +0200
@@ -2937,7 +2937,7 @@ assign_parm_setup_block (struct assign_p
   if (stack_parm == 0)
 {
   HOST_WIDE_INT parm_align
-   = (STRICT_ALIGNMENT
+   = ((STRICT_ALIGNMENT || BITS_PER_WORD <= MAX_SUPPORTED_STACK_ALIGNMENT)
   ? MAX (DECL_ALIGN (parm), BITS_PER_WORD) : DECL_ALIGN (parm));

   SET_DECL_ALIGN (parm, parm_align);

[Bug middle-end/120694] New: endless compile in ranger at expand

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

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

Bug ID: 120694
   Summary: endless compile in ranger at expand
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: liuhongt at gcc dot gnu.org
  Target Milestone: ---

cat test.c

#include

typedef struct Symmetry
{
  int **GFSym;
} SymmetryGHex;

void *SetupGH (int convlevel, int maxdim, int numvars)
{
  int i, j;
  SymmetryGHex *myGH;

  myGH = (SymmetryGHex *) malloc (sizeof (SymmetryGHex));
  if (myGH)
{
  myGH->GFSym = (int **) malloc (numvars * sizeof (int *));

  for (i = 0; i < numvars; i++)
{
  myGH->GFSym[i] = (int *) malloc (2 * maxdim * sizeof (int));

  for (j = 0; j < 2 * maxdim; j++)
{
  myGH->GFSym[i][j] = -41;
}
}
}

  return (myGH);
}

with -O2 -march=x86-64-v3 -ftree-vectorize -fpeel-loops -ftracer on x86
platform

[Bug middle-end/120694] endless compile in ranger at expand

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

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

--- Comment #1 from Hongtao Liu  ---
stuck in the loop of ranger_cache::propagate_cache for niters.5_40

[Bug middle-end/120694] endless compile in ranger at expand

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

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

Sam James  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Sam James  ---
Could you retry on trunk? This might be a dupe of bug 120661.

*** This bug has been marked as a duplicate of bug 120661 ***

[Bug cobol/119933] cobol builds on loongarch64-linux-gnu with test failures

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||chenglulu at loongson dot cn,
   ||xry111 at gcc dot gnu.org

--- Comment #2 from Xi Ruoyao  ---
(In reply to Simon Sobisch from comment #1)
> Is there an environment setup to compile current master (gcc-16)?

If you have a cfarm account you can use cfarm400.cfarm.net or
cfarm401.cfarm.net.

[Bug tree-optimization/120661] [16 regression] compiler hang at -O{s,2,3} on x86_64-linux-gnu

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

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

Sam James  changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org

--- Comment #9 from Sam James  ---
*** Bug 120694 has been marked as a duplicate of this bug. ***

[Bug libstdc++/120680] [nvptx] Linker errors with absent weak symbol 'zoneinfo_dir_override'

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

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from Tobias Burnus  ---
Actually, it turned out that two Linux distros' nvptx-tools were too old - and
newer 'ld' of nvptx-tool hand weak symbols sufficiently for this too link.
(The update request has been passed on.)

→ https://github.com/SourceryTools/nvptx-tools for the current version

[Early August 2024 seems to be new enough, early June is too old and the latest
of September 2024 unsurprisingly also works fine.]

[Bug c/120658] OPTIMIZATION: STRING HANDLING: wrong results under exotic conditions.

[newbie-02 at gmx dot de via Gcc-bugs]

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

--- Comment #4 from newbie-02  ---
@Eric Botcazou: whow, thank you! 
( despite I understand the analysis details as well as Chinese. )  
One additional question: can you propose how to do better, how to avoid such
fails? Were programming rules violated here?

[Bug middle-end/117811] [12 Regression] bad code for conditional right shift with autovec and neon since r12-897-gde56f95afaaa22

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

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

--- Comment #33 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Earnshaw
:

https://gcc.gnu.org/g:80b11a66973e6e5a33d0bd43ab2a97df5b7accd9

commit r12-11200-g80b11a66973e6e5a33d0bd43ab2a97df5b7accd9
Author: Richard Earnshaw 
Date:   Thu Mar 20 14:42:59 2025 +

opcodes: fix wrong code in expand_binop_directly [PR117811]

If expand_binop_directly fails to add a REG_EQUAL note it tries to
unwind and restart.  But it can unwind too far if expand_binop changed
some of the operands before calling it.  We don't need to unwind that
far anyway since we should end up taking exactly the same route next
time, just without a target rtx.

To fix this we remove LAST from the argument list and let the callers
(all in expand_binop) do their own unwinding if the call fails.
Instead we unwind just as far as the entry to expand_binop_directly
and recurse within this function instead of all the way back up.

gcc/ChangeLog:

PR middle-end/117811
* optabs.cc (expand_binop_directly): Remove LAST as an argument,
instead record the last insn on entry.  Only delete insns if
we need to restart and restart by calling ourself, not
expand_binop.
(expand_binop): Update callers to expand_binop_directly.  If it
fails to expand the operation, delete back to LAST.

gcc/testsuite:

PR middle-end/117811
* gcc.dg/torture/pr117811.c: New test.

(cherry picked from commit 7679b826840c58343d72d05922355b646db4bdcc)

[Bug modula2/120673] Mutually dependent types crash the compiler

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

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

Gaius Mulley  changed:

   What|Removed |Added

   Last reconfirmed||2025-06-17
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Gaius Mulley  ---
Confirmed thanks for the bug report.

[Bug tree-optimization/120677] [15/16 regression] ICE on valid code at -O{2,3} on x86_64-linux-gnu: verify_flow_info failed since r15-5850

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Jakub Jelinek
:

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

commit r15-9841-gf3dcc49945ea9ba0355d5c87686c0ed99e7c233d
Author: Jakub Jelinek 
Date:   Tue Jun 17 13:20:11 2025 +0200

crc: Fix up ICE from optimize_crc_loop [PR120677]

The following testcase ICEs, because optimize_crc_loop inserts a call
statement before labels instead of after labels.

Fixed thusly (plus fixed other issues noticed around it).

2025-06-17  Jakub Jelinek  

PR tree-optimization/120677
* gimple-crc-optimization.cc (crc_optimization::optimize_crc_loop):
Insert before gsi_after_labels instead of gsi_start_bb.  Use
gimple_bb (output_crc) instead of output_crc->bb.  Formatting fix.

* gcc.c-torture/execute/pr120677.c: New test.

(cherry picked from commit 75ffef5c6fa4e6e9576285e0403c06728309ae3e)

[Bug tree-optimization/120677] [15/16 regression] ICE on valid code at -O{2,3} on x86_64-linux-gnu: verify_flow_info failed since r15-5850

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Fixed for 15.2 and 16+.

[Bug tree-optimization/120677] [15/16 regression] ICE on valid code at -O{2,3} on x86_64-linux-gnu: verify_flow_info failed since r15-5850

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

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

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

https://gcc.gnu.org/g:75ffef5c6fa4e6e9576285e0403c06728309ae3e

commit r16-1538-g75ffef5c6fa4e6e9576285e0403c06728309ae3e
Author: Jakub Jelinek 
Date:   Tue Jun 17 13:20:11 2025 +0200

crc: Fix up ICE from optimize_crc_loop [PR120677]

The following testcase ICEs, because optimize_crc_loop inserts a call
statement before labels instead of after labels.

Fixed thusly (plus fixed other issues noticed around it).

2025-06-17  Jakub Jelinek  

PR tree-optimization/120677
* gimple-crc-optimization.cc (crc_optimization::optimize_crc_loop):
Insert before gsi_after_labels instead of gsi_start_bb.  Use
gimple_bb (output_crc) instead of output_crc->bb.  Formatting fix.

* gcc.c-torture/execute/pr120677.c: New test.

[Bug target/120683] vector_loop/unrolled_loop generates poor codes on memset/memcpy

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

Summary|vector_loop generates poor  |vector_loop/unrolled_loop
   |codes on memset/memcpy  |generates poor codes on
   ||memset/memcpy

--- Comment #3 from H.J. Lu  ---
unrolled_loop generates:

[hjl@gnu-tgl-3 pr120683]$ cat x.c
void
foo (char *dest)
{
  __builtin_memset (dest, 0, 61);
}
[hjl@gnu-tgl-3 pr120683]$ make x.s
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/ -O2
-minline-all-stringops
-mmemset-strategy=unrolled_loop:256:noalign,libcall:-1:noalign -mno-sse -S x.c
[hjl@gnu-tgl-3 pr120683]$ cat x.s
.file   "x.c"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
xorl%eax, %eax
.L2:
movl%eax, %edx
movq$0, (%rdi,%rdx)
movq$0, 8(%rdi,%rdx)
movq$0, 16(%rdi,%rdx)
movq$0, 24(%rdi,%rdx)
addl$32, %eax
jc  .L2 <<<<<<<< Why is this needed?
movb$0, 28(%rdi,%rax)
andq$0, (%rdi,%rax)
andq$0, 8(%rdi,%rax)
andq$0, 16(%rdi,%rax)
andl$0, 24(%rdi,%rax)
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
    .ident  "GCC: (GNU) 16.0.0 20250617 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-tgl-3 pr120683]$

[Bug c++/120685] [12/13/14/15/16 Regression] GCC Crashes After C++23 auto(t) Warning Instead of Graceful Error

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|GCC Crashes After C++23 |[12/13/14/15/16 Regression]
   |auto(t) Warning Instead of  |GCC Crashes After C++23
   |Graceful Error  |auto(t) Warning Instead of
   ||Graceful Error
   Priority|P3  |P2
   Last reconfirmed||2025-06-17
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |12.5
   Keywords||ice-on-invalid-code

--- Comment #1 from Marek Polacek  ---
Started with r12-5386:

commit 93810fd673654db9ff16170624a6d36449eab241
Author: Marek Polacek 
Date:   Wed Nov 3 11:04:22 2021 -0400

c++: Implement C++23 P0849R8 - auto(x) [PR103049]

[Bug modula2/120673] Mutually dependent types crash the compiler

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

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

commit r16-1546-gfba2f08152375e2c1c167ec921a0197e4c07efc6
Author: Gaius Mulley 
Date:   Tue Jun 17 17:41:21 2025 +0100

PR modula2/120673: Mutually dependent types crash the compiler

This patch fixes an ICE which will occur if cyclic dependent types
are used when declaring a variable.  This patch detects the
cyclic dependency and issues an error message for each outstanding
component.

gcc/m2/ChangeLog:

PR modula2/120673
* gm2-compiler/M2GCCDeclare.mod (ErrorDepList): New
global variable set containing every errant dependency symbol.
(mystop): Remove.
(EmitCircularDependancyError): Replace with ...
(EmitCircularDependencyError): ... this.
(AssertAllTypesDeclared): Rewrite.
(DoVariableDeclaration): Ditto.
(TypeDependentsDeclared): New procedure function.
(PrepareGCCVarDeclaration): Ditto.
(DeclareVariable): Remove assert.
(DeclareLocalVariable): Ditto.
(Constructor): Initialize ErrorDepList.
* gm2-compiler/M2MetaError.mod (doErrorScopeProc): Rewrite
and ensure that a symbol with a module scope does not lookup
from a definition module.
* gm2-compiler/P2SymBuild.mod (BuildType): Rewrite so that
a synonym type is created using the token refering to the name
on the lhs.

gcc/testsuite/ChangeLog:

PR modula2/120673
* gm2/pim/fail/badmodvar.mod: New test.
* gm2/pim/fail/cyclictypes.mod: New test.
* gm2/pim/fail/cyclictypes2.mod: New test.
* gm2/pim/fail/cyclictypes4.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug c++/120689] New: Codegen optimization regression passing struct in register in gcc 10+ on x86-64.

[amohr at amohr dot org via Gcc-bugs]

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

Bug ID: 120689
   Summary: Codegen optimization regression passing struct in
register in gcc 10+ on x86-64.
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amohr at amohr dot org
  Target Milestone: ---

struct s { char a, b, c; };

void t2(s);

void t1(s x) {
t2(x);
}

GCC 9.5 on x86-64 at -O3 generates:

t1(s):
jmp t2(s)

GCC 10.1 (and newer) at -O3 generates:

t1(s):
mov edx, edi
mov eax, edi
movzx   edi, dil
shr eax, 16
and edx, 65280
or  rdx, rdi
movzx   edi, al
sal rdi, 16
or  rdi, rdx
jmp t2(s)

I tested all newer major versions thru 15 & trunk, and they do similarly.

[Bug fortran/120690] New: Faster short testing of gfortran

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

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

Bug ID: 120690
   Summary: Faster short testing of gfortran
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jvdelisle at gcc dot gnu.org
  Target Milestone: ---

I am putting together a python script to enable the gfortran maintainers to do
quicker testing of the gfortran.dg testing. I though I would open this PR so we
can track review and features. I home we can simple put it in contrib. I will
post it here when I get something working.

[Bug fortran/120690] Faster short testing of gfortran

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2025-06-17

[Bug target/115893] AVR documentation in x86_64 build

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P3  |P5

[Bug target/120688] New: [16 Regression] RISC-V: Miscompile at -O3 since r15-579-ga9251ab3c91

[ewlu at rivosinc dot com via Gcc-bugs]

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

Bug ID: 120688
   Summary: [16 Regression] RISC-V: Miscompile at -O3 since
r15-579-ga9251ab3c91
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ewlu at rivosinc dot com
  Target Milestone: ---

Testcase:
char p;
int *volatile ad;
int ag = 6;
const int at() {
  int ci;
  int cj;
  char *ck = &p;
  ad = &cj;
  *ck = ad != &ci;
  return 0;
}
int main() {
  at();
  for (int i = 0;;) {
if (ag)
  break;
  }
  ++p;
  __builtin_printf("%d\n", p);
}

Commands:
# -O3
> /scratch/ewlu/daily-upstream-build/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -O3 ./runtime-bisect/red.c -o user-config.out -fsigned-char 
> -fno-strict-aliasing -fwrapv 
> QEMU_CPU=rv64,vlen=128,rvv_ta_all_1s=true,rvv_ma_all_1s=true,v=true,vext_spec=v1.0,zve32f=true,zve64f=true
>  timeout --verbose -k 0.1 4 
> /scratch/ewlu/daily-upstream-build/build-gcv/bin/qemu-riscv64 user-config.out 
> 1
1

# -O2
> /scratch/ewlu/daily-upstream-build/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -O2 ./runtime-bisect/red.c -o user-config.out -fsigned-char 
> -fno-strict-aliasing -fwrapv 
> QEMU_CPU=rv64,vlen=128,rvv_ta_all_1s=true,rvv_ma_all_1s=true,v=true,vext_spec=v1.0,zve32f=true,zve64f=true
>  timeout --verbose -k 0.1 4 
> /scratch/ewlu/daily-upstream-build/build-gcv/bin/qemu-riscv64 user-config.out 
> 1
2

Found via fuzzer

[Bug ada/120665] assertion failure on problematic container aggregate

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Eric Botcazou :

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

commit r16-1547-gf577a9eb3c80594e46498d10b7eaacff47fe2286
Author: Eric Botcazou 
Date:   Tue Jun 17 18:55:39 2025 +0200

Ada: Fix assertion failure on problematic container aggregate

This is an assertion failure on code using a container aggregate in the
primitives referenced by the Aggregate aspect, which cannot work.

gcc/ada/
PR ada/120665
* sem_aggr.adb (Resolve_Container_Aggregate): Use robust guards.

gcc/testsuite/
* gnat.dg/specs/aggr8.ads: New test.

[Bug ada/120665] assertion failure on problematic container aggregate

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
.

[Bug target/120689] Codegen optimization regression passing struct in register in gcc 10+ on x86-64.

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |target

--- Comment #1 from Andrew Pinski  ---
This might be a dup.

[Bug target/120681] PowerPC GCC turns off pc-relative addressing on power10 when -mcmodel=large is used

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

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

--- Comment #2 from Segher Boessenkool  ---
What is this testcase meant to test?  The only thing it *does* test is if this
trivial piece of code compiles at all (it doesn't test if the code generated is
correct, or anything else about it!)

It just test that the compiler a) does not throw an error, which it *should
have done in the status quo, silently turning off a user-specified setting is
nasty; and b) (a subset of a) really) that it doesn't ICE.

[Bug target/120681] PowerPC GCC turns off pc-relative addressing on power10 when -mcmodel=large is used

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

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

--- Comment #3 from Sam James  ---
(In reply to Segher Boessenkool from comment #2)

I think it's supposed to demonstrate the problem, not go into the testsuite
as-is.

[Bug target/120689] Codegen optimization regression passing struct in register in gcc 10+ on x86-64.

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

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

--- Comment #2 from Jakub Jelinek  ---
This changed with r10-577-g325437b2a329715da7be4de792af052c19a0ac7b

[Bug target/120689] [12/13/14/15/16 Regression] Codegen optimization regression passing struct in register in gcc 10+ on x86-64 since r10-577

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Priority|P3  |P2
Summary|Codegen optimization|[12/13/14/15/16 Regression]
   |regression passing struct   |Codegen optimization
   |in register in gcc 10+ on   |regression passing struct
   |x86-64. |in register in gcc 10+ on
   ||x86-64 since r10-577
   Target Milestone|--- |12.5

[Bug target/113027] aarch64 is missing vec_set and vec_extract for structure modes

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

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

--- Comment #2 from GCC Commits  ---
The trunk branch has been updated by Richard Sandiford :

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

commit r16-1537-ga63b97e918b8592d0f6af94c5355efc82a49e06d
Author: Richard Sandiford 
Date:   Tue Jun 17 11:43:51 2025 +0100

aarch64: Add vec_set/extract for tuple modes [PR113027]

We generated inefficient code for bitfield references to Advanced
SIMD structure modes.  In RTL, these modes are just extra-long
vectors, and so inserting and extracting an element is simply
a vec_set or vec_extract operation.

For the record, I don't think these modes should ever become fully
fledged vector modes.  We shouldn't provide add, etc. for them.
But vec_set and vec_extract are the vector equivalent of insv
and extv.  From that point of view, they seem closer to moves
than to arithmetic.

gcc/
PR target/113027
* config/aarch64/aarch64-protos.h
(aarch64_decompose_vec_struct_index):
Declare.
* config/aarch64/aarch64.cc (aarch64_decompose_vec_struct_index):
New
function.
* config/aarch64/iterators.md (VEL, Vel): Add Advanced SIMD
structure modes.
* config/aarch64/aarch64-simd.md (vec_set)
(vec_extract): New patterns.

gcc/testsuite/
PR target/113027
* gcc.target/aarch64/pr113027-1.c: New test.
* gcc.target/aarch64/pr113027-2.c: Likewise.
* gcc.target/aarch64/pr113027-3.c: Likewise.
* gcc.target/aarch64/pr113027-4.c: Likewise.
* gcc.target/aarch64/pr113027-5.c: Likewise.
* gcc.target/aarch64/pr113027-6.c: Likewise.
* gcc.target/aarch64/pr113027-7.c: Likewise.

[Bug middle-end/117811] [12 Regression] bad code for conditional right shift with autovec and neon since r12-897-gde56f95afaaa22

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

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #35 from Richard Earnshaw  ---
Fixed on all active branches

[Bug c/120658] OPTIMIZATION: STRING HANDLING: wrong results under exotic conditions.

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

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

--- Comment #5 from Eric Botcazou  ---
> One additional question: can you propose how to do better, how to avoid such
> fails? Were programming rules violated here?

Declare a character buffer with the right size (TO_BASE_N) and pass it to
my_to_base instead of passing the broken compound literal.

[Bug cobol/120621] COBOL isn't built with STRICT_WARN

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

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 61653
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61653&action=edit
gcc16-pr120621.patch

So, I think we want something like this patch + deal with the remaining 481
-Werror=format* errors (357 format-diag, 40 format-extra-args, 1
format-zero-length and 83 format= ones).

[Bug testsuite/52641] Test cases fail for 16-bit int targets

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

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

--- Comment #37 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Earnshaw
:

https://gcc.gnu.org/g:448750aff5b000fbc79183f3ef316d71a6a1701b

commit r12-11201-g448750aff5b000fbc79183f3ef316d71a6a1701b
Author: Georg-Johann Lay 
Date:   Thu Jun 12 10:07:37 2025 +0200

Fix test case for PR117811 which failed for int < 32 bit.

PR middle-end/117811
PR testsuite/52641
gcc/testsuite/
* gcc.dg/torture/pr117811.c: Fix for int < 32 bit.

(cherry picked from commit 07f229c2d7ee6b604e5a86092e675d5d36c1ba4e)

[Bug middle-end/117811] [12 Regression] bad code for conditional right shift with autovec and neon since r12-897-gde56f95afaaa22

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

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

--- Comment #34 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Earnshaw
:

https://gcc.gnu.org/g:448750aff5b000fbc79183f3ef316d71a6a1701b

commit r12-11201-g448750aff5b000fbc79183f3ef316d71a6a1701b
Author: Georg-Johann Lay 
Date:   Thu Jun 12 10:07:37 2025 +0200

Fix test case for PR117811 which failed for int < 32 bit.

PR middle-end/117811
PR testsuite/52641
gcc/testsuite/
* gcc.dg/torture/pr117811.c: Fix for int < 32 bit.

(cherry picked from commit 07f229c2d7ee6b604e5a86092e675d5d36c1ba4e)

[Bug c/120658] OPTIMIZATION: STRING HANDLING: wrong results under exotic conditions.

[newbie-02 at gmx dot de via Gcc-bugs]

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

--- Comment #6 from newbie-02  ---
@Eric Botcazou: :-) :-) :-)  **applause**

[Bug target/113027] aarch64 is missing vec_set and vec_extract for structure modes

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

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

Richard Sandiford  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Sandiford  ---
Fixed.

[Bug c++/120678] __is_trivially_destructible should take 1 arg, not -1

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

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

--- Comment #1 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r16-1540-gac62ff8ed0531ae5ffac4e5bf1dad2d60957b5a9
Author: Jason Merrill 
Date:   Tue Jun 17 02:41:38 2025 -0400

c++: correct __is_trivially_destructible nargs [PR120678]

I missed adjusting the number of args when copying the
IS_TRIVIALLY_CONSTRUCTIBLE line to create IS_TRIVIALLY_DESTRUCTIBLE.

PR c++/120678

gcc/cp/ChangeLog:

* cp-trait.def (IS_TRIVIALLY_DESTRUCTIBLE): Fix nargs.

[Bug c++/120678] __is_trivially_destructible should take 1 arg, not -1

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Fixed, thanks.

[Bug c++/120696] New: ICE: tree check: accessed elt 2 of 'tree_vec' with 1 elts in tsubst, at cp/pt.cc:16758

[rush102333 at gmail dot com via Gcc-bugs]

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

Bug ID: 120696
   Summary: ICE: tree check: accessed elt 2 of 'tree_vec' with 1
elts in tsubst, at cp/pt.cc:16758
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rush102333 at gmail dot com
  Target Milestone: ---

$cat test_75.cpp
namespace Deduction {
template 
struct X0;
template 
class X0;

template 
struct X0 {
  static const unsigned value = 0;
};

typedef int __attribute__((matrix_type(2, 3))) int2;

int array0[X0::value == 0 ? 1 : -1];
}


$g++ -fsyntax-only test_75.cpp
:5:7: error: partial specialization 'class Deduction::X0' does not
specialize any template arguments; to define the primary template, remove the
template argument list
5 | class X0;
  |   ^
:3:8: note: primary template here
3 | struct X0;
  |^~
:8:46: warning: ignoring attributes applied to dependent type 'T'
without an associated declaration [-Wattributes]
8 | struct X0 {
  |  ^
:12:48: warning: 'matrix_type' attribute directive ignored
[-Wattributes]
   12 | typedef int __attribute__((matrix_type(2, 3))) int2;
  |^~~~
: In instantiation of 'struct Deduction::X0':
:14:20:   required from here
   14 | int array0[X0::value == 0 ? 1 : -1];
  |^~
:8:49: internal compiler error: tree check: accessed elt 2 of
'tree_vec' with 1 elts in tsubst, at cp/pt.cc:16758
8 | struct X0 {
  | ^
0x2835bc5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2857356 internal_error(char const*, ...)
???:0
0x9edccf tree_vec_elt_check_failed(int, int, char const*, int, char const*)
???:0
0xb5fa96 tree_vec_elt_check(tree_node*, int, char const*, int, char const*)
???:0
0xd3ce34 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd573b9 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0xd3bdeb tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd3c8a4 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd6af19 instantiate_class_template(tree_node*)
???:0
0xd06cb3 c_parse_file()
???:0
0xe6e799 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.


Please see https://godbolt.org/z/7E5jYnKxK

[Bug c++/120695] New: internal compiler error: in import_export_decl, at cp/decl2.cc:3569

[rush102333 at gmail dot com via Gcc-bugs]

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

Bug ID: 120695
   Summary: internal compiler error: in import_export_decl, at
cp/decl2.cc:3569
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rush102333 at gmail dot com
  Target Milestone: ---

$cat test_10608.cpp
template struct A {
  static const bool x;
  enum { force_instantiation =! &x};
};

int g;

template
const bool A<1024LL>::x = (g = 1024LL, false);



$g++ -fsyntax-only test_10608.cpp
:9:23: error: template parameters not deducible in partial
specialization: [-Wtemplate-body]
9 | const bool A<1024LL>::x = (g = 1024LL, false);
  |   ^
:9:23: note: 'I'
:9:46: internal compiler error: in import_export_decl, at
cp/decl2.cc:3569
9 | const bool A<1024LL>::x = (g = 1024LL, false);
  |  ^
0x2833015 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x28547a6 internal_error(char const*, ...)
???:0
0xae00bc fancy_abort(char const*, int, char const*)
???:0
0xbeebdf c_parse_final_cleanups()
???:0
0xe6db88 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.



https://godbolt.org/z/sxKeEWMWE

[Bug target/120697] [16 regression] Bootstrap fails in ix86_expand_prologue

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |16.0
   Keywords||build, ice-on-valid-code
 CC||hjl.tools at gmail dot com,
   ||lili.cui at intel dot com

[Bug middle-end/120631] [16 Regression] ICE: in decimal_integer_string, at real.cc:2342 when mixing _BitInt() and _Decimal constants

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

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

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

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

commit r16-1555-gf3002d664d1137844c714645a841a48ab57d0eaa
Author: Jakub Jelinek 
Date:   Wed Jun 18 08:07:22 2025 +0200

dfp, real: Fix up FLOAT_EXPR/FIX_TRUNC_EXPR constant folding between dfp
and large _BitInt [PR120631]

The following testcase shows that while at runtime we handle conversions
between _Decimal{64,128} and large _BitInt correctly, at compile time we
mishandle them in both directions, in one direction we end up in ICE in
decimal_from_integer callee because the char buffer is too short for the
needed number of decimal digits, in the conversion of dfp to large _BitInt
we return 0 in the wide_int.

The following patch fixes the ICE by using larger buffer (XALLOCAVEC
allocated, it will be never larger than 65536 / 3 bytes) in the larger
_BitInt case, and the other direction by setting exponent to exp % 19
and instead multiplying the result by needed powers of 10^19 (10^19 chosen
as largest power of ten that can fit into UHWI).

2025-06-18  Jakub Jelinek  

PR middle-end/120631
* real.cc (decimal_from_integer): Add digits argument, if larger
than
256, use XALLOCAVEC allocated buffer.
(real_from_integer): Pass val_in's precision divided by 3 to
decimal_from_integer.
* dfp.cc (decimal_real_to_integer): For precision > 128 if finite
and exponent is large, decrease exponent and multiply resulting
wide_int by powers of 10^19.

* gcc.dg/dfp/bitint-9.c: New test.

[Bug middle-end/120694] endless compile in ranger at expand

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

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

--- Comment #3 from Hongtao Liu  ---
(In reply to Sam James from comment #2)
> Could you retry on trunk? This might be a dupe of bug 120661.
> 
> *** This bug has been marked as a duplicate of bug 120661 ***

Yes, it's fixed by r16-1550-g9244ea4bf556381d3f7fb66154dc8944ebeb005c

[Bug target/120697] New: [16 regression] Bootstrap fails in ix86_expand_prologue

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

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

Bug ID: 120697
   Summary: [16 regression] Bootstrap fails in
ix86_expand_prologue
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

```
$ /var/tmp/portage/sys-devel/gcc-16.0./work/build/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-16.0./work/build/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/../lib
-B/usr/x86_64-pc-linux-gnu/lib/ .libs/adler32.i -O1
/var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./zlib/adler32.c: In
function ‘adler32_z’:
/var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./zlib/adler32.c:63:7:
warning: old-style function definition [-Wold-style-definition]
   63 | uLong ZEXPORT adler32_z(adler, buf, len)
  |   ^
/var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./zlib/adler32.c: In
function ‘adler32’:
/var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./zlib/adler32.c:134:7:
warning: old-style function definition [-Wold-style-definition]
  134 | uLong ZEXPORT adler32(adler, buf, len)
  |   ^~~
/var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./zlib/adler32.c: In
function ‘adler32_combine_’:
/var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./zlib/adler32.c:143:14:
warning: old-style function definition [-Wold-style-definition]
  143 | local uLong adler32_combine_(adler1, adler2, len2)
  |  ^~~~
/var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./zlib/adler32.c: In
function ‘adler32_combine’:
/var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./zlib/adler32.c:172:7:
warning: old-style function definition [-Wold-style-definition]
  172 | uLong ZEXPORT adler32_combine(adler1, adler2, len2)
  |   ^~~
/var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./zlib/adler32.c: In
function ‘adler32_combine64’:
/var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./zlib/adler32.c:180:7:
warning: old-style function definition [-Wold-style-definition]
  180 | uLong ZEXPORT adler32_combine64(adler1, adler2, len2)
  |   ^
during RTL pass: pro_and_epilogue
/var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./zlib/adler32.c: In
function ‘adler32_z’:
/var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./zlib/adler32.c:131:1:
internal compiler error: in ix86_expand_prologue, at config/i386/i386.cc:9380
  131 | }
  | ^
0x7f2ea78035c6 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f2ea7803675 __libc_start_main_impl
../csu/libc-start.c:360
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.
```

---

```
Reading specs from
/var/tmp/portage/sys-devel/gcc-16.0./work/build/./gcc/specs
COLLECT_GCC=/var/tmp/portage/sys-devel/gcc-16.0./work/build/./gcc/xgcc
COLLECT_LTO_WRAPPER=/var/tmp/portage/sys-devel/gcc-16.0./work/build/./gcc/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/16
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/16/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/16/include/g++-v16
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/16/python
--enable-libphobos --enable-objc-gc
--enable-languages=c,c++,d,objc,obj-c++,fortran,ada,cobol,m2,rust
--enable-obsolete --enable-secureplt --disable-werror --with-system-zlib
--enable-nls --without-included-gettext --disable-libunwind-exceptions
--enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo Hardened 16.0. p, commit
98a884c00e745bc079561290d535fab134afc7fb' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-offload-defaulted
--enable-offload-targets=nvptx-none --enable-libgomp --disable-libssp
--enable-libada --disable-cet --disable-systemtap --enable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --with-isl
--disable-isl-version-check --enable-default-pie --enable-host-pie
--

[Bug target/120697] [16 regression] Bootstrap fails in ix86_expand_prologue

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

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

--- Comment #2 from Sam James  ---
Created attachment 61657
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61657&action=edit
adler32.i.xz

[Bug target/120697] [16 regression] Bootstrap fails in ix86_expand_prologue

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

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

--- Comment #1 from Sam James  ---
-fno-shrink-wrap is fine.

[Bug target/120697] [16 regression] Bootstrap fails in ix86_expand_prologue

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2025-06-18

--- Comment #3 from Sam James  ---
I think stage1 may be miscompiled. Let me get more instructions to repro.

[Bug target/120697] [16 regression] Bootstrap fails in ix86_expand_prologue

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #4 from H.J. Lu  ---
It bootstraps for me without --with-build-config='bootstrap-O3 bootstrap-lto'.
Does it work with --with-build-config='bootstrap-O3' or
--with-build-config='bootstrap-lto'?

[Bug target/120697] [16 regression] Bootstrap fails in ix86_expand_prologue

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

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

Hongtao Liu  changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org

--- Comment #5 from Hongtao Liu  ---
9380  gcc_assert (!crtl->shrink_wrapped_separate);

It hits this assert which is added by the patch, maybe this assert is not
needed.

[Bug target/120697] [16 regression] Bootstrap fails in ix86_expand_prologue

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

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

--- Comment #6 from Hongtao Liu  ---
(In reply to Hongtao Liu from comment #5)
> 9380  gcc_assert (!crtl->shrink_wrapped_separate);
> 
> It hits this assert which is added by the patch, maybe this assert is not
> needed.

I mean it's added by r16-1551-g2c30f828e45078, and it also bootstraps for me,
so it needs specific config to reproduce the issue?