[Bug tree-optimization/120080] [16 regression] ICE when building llvm-20.1.3 (find_bit_tests, at tree-switch-conversion.cc:1799) since r16-347-g1381a5114788a2

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/120081] lsplit is not always working

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-05-05
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  We give up at

  if (!iv->no_overflow)
return NULL_TREE; 

for the { n, +, 1 } IV.  So this is a niter analysis issue (though
iv->no_overflow is a bit of a 2nd class citizen)

[Bug fortran/120107] [15/16 regression] -fc-prototypes for ISO_FORTRAN_ENV generates duplicate typedefs

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.2
 Status|UNCONFIRMED |NEW
Summary|-fc-prototypes for  |[15/16 regression]
   |ISO_FORTRAN_ENV generates   |-fc-prototypes for
   |duplicate typedefs  |ISO_FORTRAN_ENV generates
   ||duplicate typedefs
 Ever confirmed|0   |1
   Last reconfirmed||2025-05-05

--- Comment #1 from Sam James  ---
$ diff -u <(gfortran-14 -fc-prototypes -c a.f90) <(gfortran-15 -fc-prototypes
-c a.f90)
--- /dev/fd/63  2025-05-05 08:14:56.053129049 +0100
+++ /dev/fd/62  2025-05-05 08:14:56.056129085 +0100
@@ -11,6 +11,24 @@
 #define __GFORTRAN_LONG_DOUBLE_COMPLEX long double _Complex
 #endif

+typedef struct event_type {
+} event_type;
+
+typedef struct lock_type {
+} lock_type;
+
+typedef struct team_type {
+} team_type;
+
+typedef struct event_type {
+} event_type;
+
+typedef struct lock_type {
+} lock_type;
+
+typedef struct team_type {
+} team_type;
+

 #ifdef __cplusplus
 }

[Bug testsuite/120084] FAIL: gcc-dg-lto-pr60779-01.exe scan-ltrans-tree-dump-times optimized "divdc3" 1

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

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug c++/113773] coroutines: promise deconstructed twice if throwing from return object

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|WAITING |REOPENED

--- Comment #5 from Iain Sandoe  ---

With the proposed resolution to CWG 2563, the final return object (from the
ramp) can, in some corner cases (such as the example here), be constructed
after the coroutine frame is destroyed.  This means that the flag signalling
that we have passed await_resume() from the initial suspend expression is no
longer available for this purpose, and we will need to find an alternate
solution.

(so back ports have also been suspended).

[Bug ada/120104] assertion failure on Finalizable aspect with abstract primitive

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

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

Eric Botcazou  changed:

   What|Removed |Added

   Target Milestone|--- |16.0
 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
Summary|Assertion failure on use of |assertion failure on
   |finalizable aspect  |Finalizable aspect with
   ||abstract primitive
   Last reconfirmed||2025-05-05
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
This works as expected with GCC 15.1 though.

[Bug testsuite/120084] FAIL: gcc-dg-lto-pr60779-01.exe scan-ltrans-tree-dump-times optimized "divdc3" 1

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

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

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

https://gcc.gnu.org/g:7eeb28717b27d5e3786387b35859bbc5d78ed6b6

commit r16-382-g7eeb28717b27d5e3786387b35859bbc5d78ed6b6
Author: Richard Biener 
Date:   Mon May 5 09:14:13 2025 +0200

testsuite/120084 - adjust gcc.dg/lto/pr60779_0.c

Require the linker plugin so functions are properly detected as
unused when inlined.

PR testsuite/120084
* gcc.dg/lto/pr60779_0.c: Require linker-plugin.

[Bug ada/120104] [15/16 regression] assertion failure on Finalizable aspect with abstract primitive

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|16.0|15.2
   Keywords||ice-checking
Summary|assertion failure on|[15/16 regression]
   |Finalizable aspect with |assertion failure on
   |abstract primitive  |Finalizable aspect with
   ||abstract primitive

--- Comment #2 from Sam James  ---
I get an assertion failure w/ 11 ("Assert_Failure failed precondition from
einfo-entities.ads:3296"), 12..14 are fine, then 15/16 have it too.

(All of my GCCs are built w/ --enable-checking=yes,extra,rtl.)

[Bug testsuite/120084] FAIL: gcc-dg-lto-pr60779-01.exe scan-ltrans-tree-dump-times optimized "divdc3" 1

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug testsuite/120085] FAIL: gcc.dg/lto/modref-2 c_lto_modref-2_0.o-c_lto_modref-2_0.o link, -O2 -flto-partition=max -flto -fno-ipa-sra

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||testsuite-fail

--- Comment #1 from Richard Biener  ---
/* { dg-extra-ld-options { -lm } } */

probably fixes it, but not sure whether that's the appropriate way of adding a
possible libm dependence.  OTOH - what could go wrong?

Feel free to push if that works.

[Bug tree-optimization/120089] [15/16 regression] GCC miscompiles VK-GL-CTS (on aarch64) with -O3 since r15-7533-g589d79e6268b05

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

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

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 #24 from Richard Biener  ---
I will have a look.

[Bug target/120090] [16 Regression] gcc.target/i386/avx512bw-pr103750-2.c

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-05-05
 Ever confirmed|0   |1
   Keywords||needs-bisection

--- Comment #1 from Richard Biener  ---
Confirmed, I've also seen those.

[Bug gcov-profile/120086] FAIL: gcc.misc-tests/gcov-29.c

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

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

--- Comment #7 from Richard Biener  ---
Possibly using %llu and (unsigned long long) casts on the value would be a good
fix.

[Bug target/120091] [16 Regression] FAIL: gcc.target/i386/pr119919.c

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
Summary|FAIL:   |[16 Regression] FAIL:
   |gcc.target/i386/pr119919.c  |gcc.target/i386/pr119919.c
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |16.0
   Last reconfirmed||2025-05-05
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed, I've also seen this.

[Bug middle-end/120093] [16 Regression] FAIL: gcc.dg/vect/pr101145.c

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2025-05-05
   Target Milestone|--- |16.0
 Target||x86_64-*-*
   Keywords||needs-bisection,
   ||testsuite-fail
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Confirmed, I've also seen this.

[Bug target/119919] 7% exchange2 regression between g:6390fc86995fbd5239497cb9e1797a3af51d3936 and g:f72a2d221539cede358f2487b94bc370c6fc44b5

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

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

Sam James  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=120091

--- Comment #7 from Sam James  ---
(In reply to Rainer Orth from comment #5)
> The new test FAILs on 32-bit x86 (both Solaris and Linux):
> 
> FAIL: gcc.target/i386/pr119919.c scan-tree-dump vect "loop vectorized using
> 8 byte vectors"

-> PR120091

[Bug c/120109] New: ICE in expand_builtin_init_trampoline with __builtin_init_trampoline using __FILE__ as 3rd argument

[mario.rodriguezb1 at um dot es via Gcc-bugs]

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

Bug ID: 120109
   Summary: ICE in expand_builtin_init_trampoline with
__builtin_init_trampoline using __FILE__ as 3rd
argument
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mario.rodriguezb1 at um dot es
  Target Milestone: ---

Using __builtin_init_trampoline with __FILE__ as the third argument causes an
internal compiler error.

```
#include 
#include 
int main(void)
{
int x;
__builtin_init_trampoline (&x, &x, __FILE__);
}
```

Stack dump

```
prueba.cpp:6:5: internal compiler error: in expand_builtin_init_trampoline, at
builtins.cc:5697
6 | __builtin_init_trampoline (&x, &x, __FILE__);
  | ^~~~
0x6ee935 expand_builtin_init_trampoline
.././../gcc-13-source/gcc/builtins.cc:5697
0x97e49f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
.././../gcc-13-source/gcc/expr.cc:11865
0x87e056 expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
.././../gcc-13-source/gcc/expr.h:310
0x87e056 expand_call_stmt
.././../gcc-13-source/gcc/cfgexpand.cc:2831
0x87e056 expand_gimple_stmt_1
.././../gcc-13-source/gcc/cfgexpand.cc:3880
0x87e056 expand_gimple_stmt
.././../gcc-13-source/gcc/cfgexpand.cc:4044
0x882977 expand_gimple_basic_block
.././../gcc-13-source/gcc/cfgexpand.cc:6106
0x8845e6 execute
.././../gcc-13-source/gcc/cfgexpand.cc:6841
```


It happens since 4.5.3 until current version, to reproduce:

https://gcc.godbolt.org/z/oYoaWEWjE

[Bug ada/120110] New: Instantiation error record aggregate must use (), not []

[p.p11 at orange dot fr via Gcc-bugs]

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

Bug ID: 120110
   Summary: Instantiation error record aggregate must use (), not
[]
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p.p11 at orange dot fr
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 61308
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61308&action=edit
Reproducer test_20250501_genagg.zip

My instantiation of a generic package with a body including a container
aggregate using [...] provoques a weird error:

% gcc -c -gnat2022 -gnatv test_20250501_genagg.adb  
GNAT 14.2.0
Copyright 1992-2024, Free Software Foundation, Inc.
Compiling: test_20250501_genagg.adb
Source file time stamp: 2025-05-05 07:36:53
Compiled at: 2025-05-05 09:38:57
 7.package NP is new Test_20250501_genagg_P (H);
   |
>>> error: instantiation error at test_20250501_genagg_p.adb:10
>>> error: record aggregate must use (), not []

Whereas compilation of generic package is ok:
% gcc -c -gnat2022 -gnatl test_20250501_genagg_p.adb
GNAT 14.2.0
Copyright 1992-2024, Free Software Foundation, Inc.
Compiling: test_20250501_genagg_p.adb
Source file time stamp: 2025-05-05 07:36:07
Compiled at: 2025-05-05 09:41:10
 1. with ada.Containers.Vectors;
 2. with ada.Strings.Wide_Wide_Unbounded;
 3. with Test_20250501_genagg_b;
 4. package body Test_20250501_genagg_P is
 5.procedure Agg (S : Wide_Wide_String) is
 6.   use type
ada.Strings.Wide_Wide_Unbounded.Unbounded_Wide_Wide_String;
 7.   A : Test_20250501_genagg_b.My_C.Vector;
 8.begin
 9.   A.append ("3.14");
10.   A := ["2.0" , Test_20250501_genagg_b.get_r("5.0" & S), "3.0"];
11.end Agg;
12. end Test_20250501_genagg_P;
Compiling: test_20250501_genagg_p.ads
Source file time stamp: 2025-05-05 07:36:07
Compiled at: 2025-05-05 09:41:10
 1. with Test_20250501_genagg_b;
 2. generic
 3.   type E is new Test_20250501_genagg_b.K.Object with private;
 4. package Test_20250501_genagg_P is
 5.
 6.procedure Agg(S : Wide_Wide_String) ;
 7.
 8. end;
 12 lines: No errors

The error is misleading.
In attachement the complete source codes.

[Bug target/120090] [16 Regression] gcc.target/i386/avx512bw-pr103750-2.c since r16-160

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||jakub at gcc dot gnu.org,
   ||pinskia at gcc dot gnu.org
Summary|[16 Regression] |[16 Regression]
   |gcc.target/i386/avx512bw-pr |gcc.target/i386/avx512bw-pr
   |103750-2.c  |103750-2.c since r16-160

--- Comment #2 from Jakub Jelinek  ---
Started with r16-160-ge6f89d78c1a7528e93458278e35d365544a18c26

[Bug ada/120110] Instantiation error record aggregate must use (), not []

[p.p11 at orange dot fr via Gcc-bugs]

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

--- Comment #1 from Pascal Pignard  ---
Created attachment 61309
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61309&action=edit
Reproducer with the offending line not in comment test_20250501_genagg-2.zip

[Bug middle-end/120095] [12/13/14/15 regression] ICE in convert_mode_scalar when casting double (*)(double) to int (*)(float) and calling it with a large argument and fabsf

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
  /* If this is not a builtin function, the function type through which the
 call is made may be different from the type of the function.  */
  if (!builtin_p)
CALL_EXPR_FN (exp)
  = fold_convert (build_pointer_type (gimple_call_fntype (stmt)),
  CALL_EXPR_FN (exp));

is probably one issue.  Maybe we should do

  builtin_p = gimple_call_builtin_p (stmt);

instead of

  builtin_p = decl && fndecl_built_in_p (decl);

where we fail to verify the function signature against that of the builtin.

Note that even with unconditionally converting we ICE, so expand_assignment
goes wrong at some point, not expecting the integer return type.  It does
so in expand_expr_real_1:

tree fndecl = get_callee_fndecl (exp), attr;
..
/* Check for a built-in function.  */
if (fndecl && fndecl_built_in_p (fndecl))
  {
gcc_assert (DECL_BUILT_IN_CLASS (fndecl) != BUILT_IN_FRONTEND);
return expand_builtin (exp, target, subtarget, tmode, ignore);

where we then eventually get into the "verification" builtin expansion
does.  It only checks we have a REAL_TYPE as argument (not whether it is
of the correct mode).  And it doesn't check the return type.

In get_callee_fndecl STRIP_NOPS strips the conversion of the function type
as useless because the pointer types have the same mode.

[Bug ada/120104] assertion failure on Finalizable aspect with abstract primitive

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Botcazou  ---
Fixing.

[Bug c++/118392] "-w" fails to fully inhibit "'void a::b()' has not been declared within a" warning

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

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

Simon Martin  changed:

   What|Removed |Added

  Known to work||16.0
   Target Milestone|--- |16.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Simon Martin  ---
Fixed in GCC 16; won't backport.

[Bug ada/120104] assertion failure on Finalizable aspect with abstract primitive

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

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

--- Comment #5 from Eric Botcazou  ---
The Finalizable aspect is new in GCC 15 and later.

[Bug middle-end/112877] TARGET_PROMOTE_PROTOTYPES is not honored consistently, should maybe not apply to builtins

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

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

--- Comment #10 from GCC Commits  ---
The trunk branch has been updated by Thomas Schwinge :

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

commit r16-385-gc9982eec2d3edc5306291d4628f08825ba46d483
Author: Thomas Schwinge 
Date:   Mon May 5 10:21:35 2025 +0200

vect-simd-clone-1[6-8][cd].c: Expect in-branch clones for x86: Fix target
selector syntax

Fix-up for commit f9f81d5017adc5d860b24f67aeb89b4e79c7ebdb
"vect-simd-clone-1[6-8][cd].c: Expect in-branch clones for x86", where we
lost
the relevant testing, for example, for x86_64, or GCN:

 PASS: gcc.dg/vect/vect-simd-clone-16c.c (test for excess errors)
 UNSUPPORTED: gcc.dg/vect/vect-simd-clone-16c.c -flto -ffat-lto-objects
 PASS: gcc.dg/vect/vect-simd-clone-16c.c execution test
-PASS: gcc.dg/vect/vect-simd-clone-16c.c scan-tree-dump-times vect
"[\\n\\r] [^\\n]* = foo\\.simdclone" 0

 PASS: gcc.dg/vect/vect-simd-clone-16d.c (test for excess errors)
 UNSUPPORTED: gcc.dg/vect/vect-simd-clone-16d.c -flto -ffat-lto-objects
 PASS: gcc.dg/vect/vect-simd-clone-16d.c execution test
-PASS: gcc.dg/vect/vect-simd-clone-16d.c scan-tree-dump-times vect
"[\\n\\r] [^\\n]* = foo\\.simdclone" 0

 PASS: gcc.dg/vect/vect-simd-clone-17c.c (test for excess errors)
 UNSUPPORTED: gcc.dg/vect/vect-simd-clone-17c.c -flto -ffat-lto-objects
 PASS: gcc.dg/vect/vect-simd-clone-17c.c execution test
-PASS: gcc.dg/vect/vect-simd-clone-17c.c scan-tree-dump-times vect
"[\\n\\r] [^\\n]* = foo\\.simdclone" 0

 PASS: gcc.dg/vect/vect-simd-clone-17d.c (test for excess errors)
 UNSUPPORTED: gcc.dg/vect/vect-simd-clone-17d.c -flto -ffat-lto-objects
 PASS: gcc.dg/vect/vect-simd-clone-17d.c execution test
-PASS: gcc.dg/vect/vect-simd-clone-17d.c scan-tree-dump-times vect
"[\\n\\r] [^\\n]* = foo\\.simdclone" 0

 PASS: gcc.dg/vect/vect-simd-clone-18c.c (test for excess errors)
 UNSUPPORTED: gcc.dg/vect/vect-simd-clone-18c.c -flto -ffat-lto-objects
 PASS: gcc.dg/vect/vect-simd-clone-18c.c execution test
-PASS: gcc.dg/vect/vect-simd-clone-18c.c scan-tree-dump-times vect
"[\\n\\r] [^\\n]* = foo\\.simdclone" 0

 PASS: gcc.dg/vect/vect-simd-clone-18d.c (test for excess errors)
 UNSUPPORTED: gcc.dg/vect/vect-simd-clone-18d.c -flto -ffat-lto-objects
 PASS: gcc.dg/vect/vect-simd-clone-18d.c execution test
-PASS: gcc.dg/vect/vect-simd-clone-18d.c scan-tree-dump-times vect
"[\\n\\r] [^\\n]* = foo\\.simdclone" 0

..., which this commit restores.

PR middle-end/112877
gcc/testsuite/
* gcc.dg/vect/vect-simd-clone-16c.c: Fix target selector syntax.
* gcc.dg/vect/vect-simd-clone-16d.c: Likewise.
* gcc.dg/vect/vect-simd-clone-17c.c: Likewise.
* gcc.dg/vect/vect-simd-clone-17d.c: Likewise.
* gcc.dg/vect/vect-simd-clone-18c.c: Likewise.
* gcc.dg/vect/vect-simd-clone-18d.c: Likewise.

[Bug testsuite/116163] RFE: add a linting tool for DejaGnu tests

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

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

--- Comment #20 from Thomas Schwinge  ---
Another one: verify target selector syntax (as used with 'target', 'xfail'
keywords).  For example:

"vect-simd-clone-1[6-8][cd].c: Expect in-branch clones for x86: Fix target
selector syntax".

[Bug c++/119437] [12/13/14/15/16 regression] ICE in build_base_path, at cp/class.cc:302

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Simon Martin :

https://gcc.gnu.org/g:20c2fc676050ebfcd62af50dad08cd2d2736d1e8

commit r16-386-g20c2fc676050ebfcd62af50dad08cd2d2736d1e8
Author: Simon Martin 
Date:   Mon May 5 10:37:52 2025 +0200

c++: Remove obsolete prototype

I noticed while investigating PR c++/119437 that r8-2724-g88b811bd290630
removed parsing_default_capturing_generic_lambda_in_template but not its
prototype in cp-tree.h.

This patch fixes this.

gcc/cp/ChangeLog:

* cp-tree.h (parsing_default_capturing_generic_lambda_in_template):
Remove obsolete prototype.

[Bug c++/117042] [12/13/14/15/16 Regression] internal compiler error: Segmentation fault in tsubst(tree_node*, tree_node*, int, tree_node*)

[mcccs at gmx dot com via Gcc-bugs]

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

mcccs at gmx dot com changed:

   What|Removed |Added

 CC||mcccs at gmx dot com

--- Comment #2 from mcccs at gmx dot com ---
Bisection points at r12-6080-gab85331c58223e

[Bug preprocessor/120061] [14 Regression] libqt6webengine fails static_assert (__LINE__ == 470, ...)

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #18 from rguenther at suse dot de  ---
On Mon, 5 May 2025, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061
> 
> --- Comment #15 from Jakub Jelinek  ---
> Created attachment 61328
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61328&action=edit
> gcc14-pr120061.patch
> 
> Untested 14 branch version of the patch which fixes all 3 tests (though none
> included, I think we'd need some hacks because even a file with 327676 empty
> lines plus two non-empty feels too long, not talking about 9503676 empty lines
> + two non-empty.

Can we generate the "main" testcase with TCL?  IIRC there used to
be a harness where test.c was accompanied by test.exp?

[Bug target/113939] Switch m68k to LRA

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #7 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #6) 
> I suggest we switch m68k to LRA, so we can close this bug report. Plus file
> bug reports for the issues with M2, Fortran and JIT.

JIT works with "--disable-werror", Objective-C and Objective-C++ work as well.

I will verify now that the M2 issue is related to enabling LRA.

[Bug preprocessor/120061] [14 Regression] libqt6webengine fails static_assert (__LINE__ == 470, ...)

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

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

--- Comment #19 from Jakub Jelinek  ---
I'll try to use gcc/testsuite/gcc.dg/plugin/location-overflow-test* framework
for reproducer.

[Bug c++/120123] New: Implicit this is not used in a requires clause in nested lambdas

[valentin at tolmer dot fr via Gcc-bugs]

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

Bug ID: 120123
   Summary: Implicit this is not used in a requires clause in
nested lambdas
   Product: gcc
   Version: 15.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valentin at tolmer dot fr
  Target Milestone: ---

Minimal example: https://godbolt.org/z/GxW6hjj5e

```
struct H {
void member(int) {}
void call() {
[this]() {
[this](const auto& v)
requires requires { /*this->*/member(v); }
{ return member(v); }(0);
};
}
};
```
$ g++ -std=c++23 -fconcepts-diagnostics-depth=10
: In lambda function:
:7:34: error: no match for call to
'(H::call()) (int)'
5 | [this](const auto& v)
  | ~ 
6 | requires requires { /*this->*/member(v); }
  | ~~
7 | { return member(v); }(0);
  | ~^~~
:5:18: note: there is 1 candidate
5 | [this](const auto& v)
  |  ^
:5:13: note: candidate 1: 'template
H::call()'
5 | [this](const auto& v)
  | ^
:5:13: note: template argument deduction/substitution failed:
:5:13: note: constraints not satisfied
: In substitution of 'template
H::call() [with auto:1 = int]':
:7:34:   required from here
5 | [this](const auto& v)
  | ~ 
6 | requires requires { /*this->*/member(v); }
  | ~~
7 | { return member(v); }(0);
  | ~^~~
:5:13:   required by the constraints of 'template
H::call()'
:6:26:   in requirements  [with auto:1 = int]
:6:53: note: the required expression 'H::member(v)' is invalid, because
6 | requires requires { /*this->*/member(v); }
  |   ~~^~~
:6:53: error: cannot call member function 'void H::member(int)' without
object
Compiler returned: 1

Uncommenting the /*this->*/ in the requires clause makes the code compile.
Removing the outer lambda makes the code compile. Clang accepts the code.

>From cppreference, "Requirements may refer to the template parameters that are
in scope, to the parameters of parameter-list, and to any other declarations
that are visible from the enclosing context." It doesn't specify whether "this"
should be implicitly used or not, but it is at least surprising and the
behavior differs from the body.

[Bug c++/120123] [11/12/13/14/15 Regression] Implicit this is not used in a requires clause in nested lambdas

[valentin at tolmer dot fr via Gcc-bugs]

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

--- Comment #1 from Valentin Tolmer  ---
Note that the code compiles with gcc 11.2, but starts breaking with gcc 11.3

[Bug c++/120124] New: "g++: fatal error: Killed signal..." when reporting error involving very complex lambda type

[whiteredredcat at gmail dot com via Gcc-bugs]

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

Bug ID: 120124
   Summary: "g++: fatal error: Killed signal..." when reporting
error involving very complex lambda type
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: whiteredredcat at gmail dot com
  Target Milestone: ---

Created attachment 61333
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61333&action=edit
pre-processed bug file.

g++ crashes when trying to print an error involving an extremely long type,
constructed with lambdas. If there is no error, g++ successfully compiles the
file. clang++ successfully reports the error, with no delay.

I suspect the problem is that g++ always prints the full type name no matter
how complex, and lambdas allow me to construct a problematically long type name
fast enough that I don't run into the template recursion limit first.

The error and command is below:
```
$~/patches/gcc-compile/built/bin/g++ --std=c++23 bug.cpp -save-temps
g++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
```
I must wait a long time before getting the above error. 

my gcc version from g++ -v
```
Using built-in specs.
COLLECT_GCC=/home/plum/patches/gcc-compile/built/bin/g++
COLLECT_LTO_WRAPPER=/home/plum/patches/gcc-compile/built/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/plum/patches/gcc-compile/../gcc/configure
--prefix=/home/plum/patches/gcc-compile/built --enable-language=c,c++ :
(reconfigured) /home/plum/patches/gcc-compile/../gcc/configure
--prefix=/home/plum/patches/gcc-compile/built --enable-language=c,c++
--enable-languages=c,c++,fortran,lto,objc --no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250506 (experimental) (GCC) 
``


bug.cpp
```
struct foo_tag {};

template struct foo {
using tag = foo_tag;
T run;
};

template concept isFoo = requires(T a) {a.run();};

//function to construct very complex type with lambda
template auto complexify(T a) requires isFoo {
if constexpr (i > 0) {
return complexify(foo{ [a]{
return 1+a.run();
}});
} else return a;
}

//base case
template auto complexify(int a) {
return complexify(foo{ [a]{
return a;
}});
}

int main() {
auto a = complexify<100>(1);
int result = a.run(1); //<-- this times out because it is an error
//int result = a.run(); //<-- this compiles fine

return result;  
}
// vim: ts=2 sw=2
```

Attached is the a-bug.ii file.

[Bug tree-optimization/120031] Fails to pattern match ctz from DeBruijn

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from Richard Biener  ---
There is CTZ detection in tree-ssa-forwprop.cc already which checks for
this very same pattern I think - optimize_count_trailing_zeroes, but that
is confused by the sign conversion from the - (int) val, it expects -val
only.

[Bug tree-optimization/120031] Fails to pattern match ctz from DeBruijn

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

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

--- Comment #3 from Richard Biener  ---
diff --git a/gcc/match.pd b/gcc/match.pd
index 2a63e4c7ddb..6edd7deb6c2 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -11298,7 +11298,7 @@ and,
in the top 5 or 6 bits.  This is then indexed into a table which maps it
to the number of trailing zeroes.  */
 (match (ctz_table_index @1 @2 @3)
-  (rshift (mult (bit_and:c (negate @1) @1) INTEGER_CST@2) INTEGER_CST@3))
+  (rshift (mult (bit_and:c (nop_convert? (negate (nop_convert? @1))) @1)
INTEGER_CST@2) INTEGER_CST@3))

 (match (cond_expr_convert_p @0 @2 @3 @6)
  (cond (simple_comparison@6 @0 @1) (convert@4 @2) (convert@5 @3))


fixes this case but I wonder whether we should simply transform
(unsigned)-(signed)x to -x?  Yes, we lose the fact that x is not
(unsigned)INT_MIN, but so what.

[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()

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

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

--- Comment #16 from Jerry DeLisle  ---
Patch submitted here:

https://gcc.gnu.org/pipermail/fortran/2025-May/062094.html

[Bug target/120034] Fails to recognize bzhi consistently

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2025-05-06

--- Comment #4 from Andrew Pinski  ---
.

[Bug middle-end/120021] Offloading vs. C++ 'std::initializer_list'

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-05-06
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #4 from Andrew Pinski  ---
.

[Bug gcov-profile/120086] FAIL: gcc.misc-tests/gcov-29.c

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2025-05-06

--- Comment #8 from Andrew Pinski  ---
.

[Bug c++/120123] [12/13/14/15 Regression] Implicit this is not used in a requires clause in nested lambdas

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||67491
Summary|[11/12/13/14/15 Regression] |[12/13/14/15 Regression]
   |Implicit this is not used   |Implicit this is not used
   |in a requires clause in |in a requires clause in
   |nested lambdas  |nested lambdas
   Target Milestone|--- |12.5
   Keywords||rejects-valid
  Known to work||11.2.0
  Known to fail||11.3.0, 12.1.0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug target/120000] Unoptimal structure copy loop

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-05-06
 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug tree-optimization/120031] Fails to pattern match ctz from DeBruijn

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-05-06
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
 Confirmed.

[Bug tree-optimization/120032] Fails to pattern match clz from DeBruijn

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
 Ever confirmed|0   |1
   Last reconfirmed||2025-05-06

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug modula2/120117] New: ICE when attempting to obtain the MAX of an aliased set type.

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

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

Bug ID: 120117
   Summary: ICE when attempting to obtain the MAX of an aliased
set type.
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

Consider the following code:

$ cat highbit.mod
MODULE highbit ;

FROM libc IMPORT printf ;

TYPE
   set = BITSET ;

CONST
   HighBit = MAX (set) ;

BEGIN
   printf ("the MAX (set) = %d\n", HighBit)
END highbit.



$ gm2 highbit.mod 
cc1gm2: internal compiler error: in libc_abort, at m2/mc-boot-ch/Glibc.c:173
0x2e96741 internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:517
0x2e632f4 fancy_abort(char const*, int, char const*)
../../gcc/diagnostic.cc:1748
0x546a4c libc_abort
../../gcc/m2/mc-boot-ch/Glibc.c:173
0x53bf70 M2RTS_HALT
m2/gm2-libs-boot/M2RTS.c:476
0x537e21 Indexing_GetIndice
m2/gm2-libs-boot/Indexing.c:385
0x49ff55 GetQF
m2/gm2-compiler-boot/M2Quads.c:5651
0x4b31fe M2Quads_SubQuad
m2/gm2-compiler-boot/M2Quads.c:17304
0x48220d RemoveQuad
m2/gm2-compiler-boot/M2GenGCC.c:4795
0x4821ad FoldBecomes
m2/gm2-compiler-boot/M2GenGCC.c:4767
0x48ebf6 M2GenGCC_ResolveConstantExpressions
m2/gm2-compiler-boot/M2GenGCC.c:10831
0x47cbae M2GCCDeclare_FoldConstants
m2/gm2-compiler-boot/M2GCCDeclare.c:8551
0x463872 M2BasicBlock_ForeachBasicBlockDo
m2/gm2-compiler-boot/M2BasicBlock.c:500
0x474e03 DeclareTypesConstantsProceduresInRange
m2/gm2-compiler-boot/M2GCCDeclare.c:4443
0x4c53e0 M2Scope_ForeachScopeBlockDo3
m2/gm2-compiler-boot/M2Scope.c:703
0x47502e DeclareTypesConstantsProcedures
m2/gm2-compiler-boot/M2GCCDeclare.c:4545
0x475254 StartDeclareModuleScopeSeparate
m2/gm2-compiler-boot/M2GCCDeclare.c:4636
0x475498 StartDeclareModuleScope
m2/gm2-compiler-boot/M2GCCDeclare.c:4714
0x47cbeb M2GCCDeclare_StartDeclareScope
m2/gm2-compiler-boot/M2GCCDeclare.c:8577
0x46a4b1 DoModuleDeclare
m2/gm2-compiler-boot/M2Code.c:264
0x46aa61 M2Code_Code
m2/gm2-compiler-boot/M2Code.c:470

[Bug modula2/120117] ICE when attempting to obtain the MAX of an aliased set type.

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #1 from Gaius Mulley  ---
Confirmed.

[Bug ipa/120048] [14/15/16 Regression] ICE on valid code at -O{s,2} with "-fno-tree-vrp -fno-tree-fre" on x86_64-linux-gnu: in type, at value-range.h:982 since r16-244-gce489c870bf28e

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

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

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

https://gcc.gnu.org/g:7f285b7ad7cb89a9b29b52e0d25a7666dc9bd645

commit r16-391-g7f285b7ad7cb89a9b29b52e0d25a7666dc9bd645
Author: Andrew MacLeod 
Date:   Fri May 2 15:48:08 2025 -0400

Allow IPA_CP to handle UNDEFINED as VARYING.

When applying a bitmask to reflect ranges, it is sometimes deferred and
this can result in an UNDEFINED result.  IPA is not expecting this, and
add a check for it, and convert to VARYING if encountered.

PR tree-optimization/120048
gcc/
* ipa-cp.cc (ipcp_store_vr_results): Check for UNDEFINED.

gcc/testsuite/
* gcc.dg/pr120048.c: New.

[Bug modula2/120117] ICE when attempting to obtain the MAX of an aliased set type.

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

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

--- Comment #2 from Gaius Mulley  ---
Created attachment 61320
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61320&action=edit
Proposed fix which skips the aliased type and does not remove the same quad
twice

The ICE occurred because of a bug in M2GenGCC.mod:FoldBecomes which attempted
to remove the same quadruple twice.  Thereafter cc1gm2 generated an erroneous
error type error as PCSymBuild did not skip an aliased set type.  The type of
the const was set incorrectly (as a set type) rather than the type of the set
element.

The unpopulated ChangeLog entry follows:

gcc/m2/ChangeLog:

* gm2-compiler/M2GenGCC.mod:
* gm2-compiler/PCSymBuild.mod:
* gm2-compiler/SymbolTable.mod:

gcc/testsuite/ChangeLog:

* gm2/pim/pass/highbit.mod: New test.
* gm2/pim/pass/highbit2.mod: New test.

[Bug target/120090] [16 Regression] gcc.target/i386/avx512bw-pr103750-2.c since r16-160

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

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

--- Comment #5 from Andrew Pinski  ---

before:(and:SI (subreg:SI (unspec:QI [
(mem:V8HI (reg/f:SI 98 [ pi128.0_1 ]) [0 *pi128.0_1+0 S16
A128])
(reg:V8HI 110 [ _16 ])
(const_int 0 [0])
] UNSPEC_UNSIGNED_PCMP) 0)
(const_int 255 [0xff]))
after:(and:DI (clobber:DI (const_int 0 [0]))
(const_int 255 [0xff]))


clobber means we can't do it ...

[Bug c/120118] New: ICE in c and c++ in cpp_spell_token with unterminated macro stringification inside #pragma message

[mario.rodriguezb1 at um dot es via Gcc-bugs]

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

Bug ID: 120118
   Summary: ICE in c and c++ in cpp_spell_token with unterminated
macro stringification inside #pragma message
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mario.rodriguezb1 at um dot es
  Target Milestone: ---

It fails when #pragma message is ended in next after a line break, it happens
in C and C++.

```
#define F(X) #X
#pragma message F(
)
```

Stack dump

```
prueba.cpp:3:1: internal compiler error: unspellable token PRAGMA_EOL
3 | )
  | ^
0x7f5ea2 c_cpp_diagnostic(cpp_reader*, cpp_diagnostic_level,
cpp_warning_reason, rich_location*, char const*, __va_list_tag (*) [1])
.././../gcc-13-source/gcc/c-family/c-common.cc:6710
0x1b1214b cpp_diagnostic_at
.././../gcc-13-source/libcpp/errors.cc:67
0x1b1214b cpp_diagnostic
.././../gcc-13-source/libcpp/errors.cc:82
0x1b12276 cpp_error(cpp_reader*, cpp_diagnostic_level, char const*, ...)
.././../gcc-13-source/libcpp/errors.cc:96
0x1b1c5c1 cpp_spell_token(cpp_reader*, cpp_token const*, unsigned char*, bool)
.././../gcc-13-source/libcpp/lex.cc:4426
0x1b25df2 stringify_arg
.././../gcc-13-source/libcpp/macro.cc:904
0x1b27fa9 replace_args
.././../gcc-13-source/libcpp/macro.cc:1933
0x1b27fa9 enter_macro_context
.././../gcc-13-source/libcpp/macro.cc:1483
0x1b28700 cpp_get_token_1
.././../gcc-13-source/libcpp/macro.cc:3018
0x80b15e c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
.././../gcc-13-source/gcc/c-family/c-lex.cc:499
0x782e3f c_lex_one_token
.././../gcc-13-source/gcc/c/c-parser.cc:294
0x786fbc c_parser_peek_token(c_parser*)
.././../gcc-13-source/gcc/c/c-parser.cc:498
0x786fbc pragma_lex(tree_node**, unsigned int*)
.././../gcc-13-source/gcc/c/c-parser.cc:13339
0x816580 handle_pragma_message
.././../gcc-13-source/gcc/c-family/c-pragma.cc:1380
0x78dbd7 c_parser_pragma
.././../gcc-13-source/gcc/c/c-parser.cc:13323
0x7b65e5 c_parser_external_declaration
.././../gcc-13-source/gcc/c/c-parser.cc:1906
0x7b6f93 c_parser_translation_unit
.././../gcc-13-source/gcc/c/c-parser.cc:1779
0x7b6f93 c_parse_file()
.././../gcc-13-source/gcc/c/c-parser.cc:24632
0x814561 c_common_parse_file()
.././../gcc-13-source/gcc/c-family/c-opts.cc:1248
```

It happens since 4.4.7

To reproduce quickly

https://gcc.godbolt.org/z/KsbYdoPhc

[Bug target/119966] [16 regression] pru: Invalid register in RTL expression starting with r16-160-ge6f89d78c1a752

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

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

--- Comment #8 from Dimitar Dimitrov  ---
Posted https://gcc.gnu.org/pipermail/gcc-patches/2025-May/682657.html . I'm
trying to setup gcc testing environment for big endian target, in order to
check Richard's comment:

> But we would have to skip:
> ...
> because the BYTES_BIG_ENDIAN test would fail for paradoxical subregs.

[Bug target/120090] [16 Regression] gcc.target/i386/avx512bw-pr103750-2.c since r16-160

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> before:(and:SI (subreg:SI (unspec:QI [
> (mem:V8HI (reg/f:SI 98 [ pi128.0_1 ]) [0 *pi128.0_1+0 S16
> A128])
> (reg:V8HI 110 [ _16 ])
> (const_int 0 [0])
> ] UNSPEC_UNSIGNED_PCMP) 0)
> (const_int 255 [0xff]))
> after:(and:DI (clobber:DI (const_int 0 [0]))
> (const_int 255 [0xff]))
> 
> 
> clobber means we can't do it ...

Instead of rtl_hooks.gen_lowpart_no_emit return NULL, combine's gen_lowpart
returns a clobber. 

This fixes the issue at hand:
```
diff --git a/gcc/simplify-rtx.cc b/gcc/simplify-rtx.cc
index 7bcbe11370f..ea730c4d9aa 100644
--- a/gcc/simplify-rtx.cc
+++ b/gcc/simplify-rtx.cc
@@ -1716,7 +1716,7 @@ simplify_context::simplify_unary_operation_1 (rtx_code
code, machine_mode mode,
  && INTVAL (XEXP (op, 1)) > 0)
{
  rtx tem = rtl_hooks.gen_lowpart_no_emit (mode, XEXP (op, 0));
- if (tem)
+ if (tem && GET_CODE (tem) != CLOBBER)
return simplify_gen_binary (AND, mode, tem, XEXP (op, 1));
}


```

But nowhere in simplify-rtx.cc checks that gen_lowpart_no_emit will return
CLOBBER. Or should we wrap gen_lowpart_for_combine and return NULL when it is a
clobber ...

Still deciding.

[Bug preprocessor/120118] ICE in c and c++ in cpp_spell_token with unterminated macro stringification inside #pragma message

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup.

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

[Bug preprocessor/79516] [12/13/14/15/16 Regression] ICE: unspellable token PRAGMA_EOL

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||mario.rodriguezb1 at um dot es

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

[Bug c++/120112] -Weffc++ -Wmismatched-tags -Wrestrict -Wsystem-headers leads to internal_error

[joo.peter at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Joó Péter  ---
Created attachment 61317
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61317&action=edit
freport-bug2.txt.gz

[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0

[bc-info at styx dot cabel.net via Gcc-bugs]

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

--- Comment #4 from Iouri Kharon  ---
(In reply to Sam James from comment #3)
> (In reply to Iouri Kharon from comment #2)
> > In addition, a bug in ld-2.44 was found :). See
> > https://savannah.gnu.org/patch/index.php?10520
> 
> Could you file that on the sourceware bugzilla? I don't think anyone looks
> at savannah for binutils (didn't even know a page was there).

https://sourceware.org/bugzilla/show_bug.cgi?id=32942

[Bug testsuite/120085] FAIL: gcc.dg/lto/modref-2 c_lto_modref-2_0.o-c_lto_modref-2_0.o link, -O2 -flto-partition=max -flto -fno-ipa-sra

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #3 from John David Anglin  ---
Fixed.

[Bug c++/119916] [15/16 Regression] folly (2025.04.14.00 and earlier): coroutine tests fail with GCC 15 since r15-3153-g68ee624bc52ba1

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

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

--- Comment #19 from Jason Merrill  ---
(In reply to Jason Merrill from comment #14)
> It's frustrating that apparently EWG got to see an example but it isn't
> preserved anywhere.

Ah, seems like this is it:
https://github.com/GorNishanov/await/blob/master/2023_Issaquah/cwg2563-response.md

[Bug preprocessor/120118] ICE in c and c++ in cpp_spell_token with unterminated macro stringification inside #pragma message

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |---
   Last reconfirmed||2025-05-05
 Status|RESOLVED|NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Actually this is not a dup but definitely related.

[Bug target/120090] [16 Regression] gcc.target/i386/avx512bw-pr103750-2.c since r16-160

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #6)
> 
> But nowhere in simplify-rtx.cc checks that gen_lowpart_no_emit will return
> CLOBBER. Or should we wrap gen_lowpart_for_combine and return NULL when it
> is a clobber ...
> 

That is this:
```
diff --git a/gcc/combine.cc b/gcc/combine.cc
index 67cf0447607..366886020e7 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -458,6 +458,7 @@ static rtx simplify_shift_const (rtx, enum rtx_code,
machine_mode, rtx,
 int);
 static int recog_for_combine (rtx *, rtx_insn *, rtx *, unsigned = 0, unsigned
= 0);
 static rtx gen_lowpart_for_combine (machine_mode, rtx);
+static rtx gen_lowpart_for_combine_no_emit (machine_mode, rtx);
 static enum rtx_code simplify_compare_const (enum rtx_code, machine_mode,
 rtx *, rtx *);
 static enum rtx_code simplify_comparison (enum rtx_code, rtx *, rtx *);
@@ -491,7 +492,7 @@ static rtx gen_lowpart_or_truncate (machine_mode, rtx);

 /* Our implementation of gen_lowpart never emits a new pseudo.  */
 #undef RTL_HOOKS_GEN_LOWPART_NO_EMIT
-#define RTL_HOOKS_GEN_LOWPART_NO_EMIT  gen_lowpart_for_combine
+#define RTL_HOOKS_GEN_LOWPART_NO_EMIT  gen_lowpart_for_combine_no_emit

 #undef RTL_HOOKS_REG_NONZERO_REG_BITS
 #define RTL_HOOKS_REG_NONZERO_REG_BITS reg_nonzero_bits_for_combine
@@ -11890,6 +11891,16 @@ gen_lowpart_for_combine (machine_mode omode, rtx x)
  fail:
   return gen_rtx_CLOBBER (omode, const0_rtx);
 }
+
+static rtx
+gen_lowpart_for_combine_no_emit (machine_mode omode, rtx x)
+{
+  rtx tem = gen_lowpart_for_combine (omode, x);
+  if (!tem || GET_CODE (tem) == CLOBBER)
+return NULL_RTX;
+  return tem;
+}
+
 ^L
 /* Try to simplify a comparison between OP0 and a constant OP1,
where CODE is the comparison code that will be tested, into a

```

[Bug c++/120112] -Weffc++ -Wmismatched-tags -Wrestrict -Wsystem-headers leads to internal_error

[joo.peter at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Joó Péter  ---
I found an other warning combination which provides the same internal_error
call stack.

It needs these warnings, both of them, together:
-Wmismatched-tags -Wnamespaces

Also, I created a small bash script which reproduces the problem, from scratch:

   rm -fR $HOME/gcc_bug_120112
   mkdir  $HOME/gcc_bug_120112
   cd $HOME/gcc_bug_120112

   git clone 'https://github.com/boostorg/boost.git' .
   git checkout 'boost-1.88.0'
   git submodule update --init --force --recursive --jobs=8192

   g++ -I$HOME/gcc_bug_120112 -c
/home/p/gcc_bug_120112/libs/icl/test/ex_boost_party_/ex_boost_party.cpp -o
/dev/null -Wmismatched-tags -Wnamespaces

The internal_error call stack for the above single gcc command is this:

$HOME/gcc_bug_120112/libs/icl/test/ex_boost_party_/ex_boost_party.cpp: In
substitution of ‘template struct boost::icl::map::on_total_absorbable [with Type = boost::icl::map]’:
   
$HOME/gcc_bug_120112/libs/icl/test/ex_boost_party_/ex_boost_party.cpp:132:1:  
required from here
 132 | }
 | ^
   
$HOME/gcc_bug_120112/libs/icl/test/ex_boost_party_/ex_boost_party.cpp:132:1:
internal compiler error: Segmentation fault
0x21a57ea internal_error(char const*, ...)
   ???:0
0x8d90cf tsubst(tree_node*, tree_node*, int, tree_node*)
   ???:0
0x8e2d3f tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
   ???:0
0x8e3042 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
   ???:0
0x8ce6c0 most_specialized_partial_spec(tree_node*, int, bool)
   ???:0
0x889980 class_decl_loc_t::diag_mismatched_tags(tree_node*)
   ???:0
0x88ae44 class_decl_loc_t::diag_mismatched_tags()
   ???:0
0x9cd0f5 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.

Tested with gcc versions: 14.2.1 and 15.1.0

Also, I attached the -freport-bug's output as 'freport-bug2.txt.gz'.

[Bug ipa/119973] [15 Regression] Wrong code at -O1 -fipa-pta

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||15.1.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to work||15.1.1

--- Comment #11 from Richard Biener  ---
Fixed.

[Bug preprocessor/120061] [14 Regression] libqt6webengine fails static_assert (__LINE__ == 470, ...)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #61311|0   |1
is obsolete||

--- Comment #11 from Jakub Jelinek  ---
Created attachment 61318
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61318&action=edit
gcc14-pr116047.patch.xz

Fixed up PR116047 testcase in patch form.

[Bug preprocessor/120061] [14 Regression] libqt6webengine fails static_assert (__LINE__ == 470, ...)

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

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

--- Comment #12 from Jakub Jelinek  ---
Created attachment 61319
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61319&action=edit
gcc14-pr120061.patch.xz

Testcase for this PR (which worked before r14-11679-g8a884140c2bcb7 and doesn't
work after it on the 14 branch).

[Bug ipa/120006] [15 Regression] wrong code with -O2 -fipa-pta on util-linux's mount

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||15.1.1
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Priority|P3  |P2

--- Comment #20 from Richard Biener  ---
Fixed.  While the issue is latent I'm currently not considering to push it to
older branches.

[Bug ipa/68331] [meta-bug] fipa-pta issues

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

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

Bug 120006 Summary: [15 Regression] wrong code with -O2 -fipa-pta on 
util-linux's mount
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120006

   What|Removed |Added

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

[Bug testsuite/120085] FAIL: gcc.dg/lto/modref-2 c_lto_modref-2_0.o-c_lto_modref-2_0.o link, -O2 -flto-partition=max -flto -fno-ipa-sra

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

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

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

https://gcc.gnu.org/g:7fae8dca82abf714a055ff505df51a4c8b43c211

commit r16-388-g7fae8dca82abf714a055ff505df51a4c8b43c211
Author: John David Anglin 
Date:   Mon May 5 09:30:45 2025 -0400

testsuite: Link gcc.dg/lto/modref-2_0 with libm

2025-05-05  John David Anglin  

gcc/testsuite/ChangeLog:

PR testsuite/120085
* gcc.dg/lto/modref-2_0.c: Link test with libm.

[Bug target/120090] [16 Regression] gcc.target/i386/avx512bw-pr103750-2.c since r16-160

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

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 61321
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61321&action=edit
reduced test which show the kmov

This removes the other functions and leaves one which shows the issue.

[Bug target/120119] [15/16 Regression] GCC 15.1.0 ICEs (segfaults) compiling VK-GL-CTS on aarch64/musl target

[mcccs at gmx dot com via Gcc-bugs]

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

mcccs at gmx dot com changed:

   What|Removed |Added

 CC||mcccs at gmx dot com

--- Comment #3 from mcccs at gmx dot com ---
Bisecting ...

[Bug c/120120] New: gcc-16: performance regression with -O3 compared to gcc-15

[manuel.lauss at googlemail dot com via Gcc-bugs]

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

Bug ID: 120120
   Summary: gcc-16: performance regression with -O3 compared to
gcc-15
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manuel.lauss at googlemail dot com
  Target Milestone: ---

Created attachment 61325
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61325&action=edit
example code taking the perf hit at O3

On some code I use, I noticed a large performance regression in gcc-16,
starting at around 21.04.2025.  I've attached sample C code which according to
perf takes almost all processing time.

Happens with "-O3 -march=znver5 -mtune=znver5 -pipe", at -O2 both -15 and -16
are equally slow.

Perf stats:
gcc-15:
Performance counter stats for './sanplay -2 RAM.SAN':

  6,33 msec task-clock:u #0,949 CPUs
utilized 
   808  page-faults:u#  127,589 K/sec   
85.738.923  instructions:u   #3,10  insn per
cycle
  #0,06  stalled cycles per
insn   
27.659.116  cycles:u #4,368 GHz 
 4.788.925  stalled-cycles-frontend:u#   17,31% frontend
cycles idle  
 8.000.727  branches:u   #1,263 G/sec   
   275.954  branch-misses:u  #3,45% of all
branches   

gcc-16:
 Performance counter stats for './sanplay -2 /home/mano/games/Outlaws/RAM.SAN':

 13,02 msec task-clock:u #0,974 CPUs
utilized 

   314.392.362  instructions:u   #4,97  insn per
cycle
  #0,02  stalled cycles per
insn   
63.277.723  cycles:u #4,861 GHz 
 5.510.316  stalled-cycles-frontend:u#8,71% frontend
cycles idle  
53.730.810  branches:u   #4,127 G/sec   
   305.375  branch-misses:u  #0,57% of all
branches   

The amount of instructions executed is 3.6x higher; on a larger example file
it's up to 4.5x instructions executed; this is not zen5 specific but happens on
a haswell as well. At -O2 both gcc-15 and gcc-16 have identical performance.

Full source is at https://github.com/mlauss2/sandec
Demo file can be grabbed from
https://samples.mplayerhq.hu/game-formats/la-san/outlaws/ram.san

I'll do a bisection next.

Thanks!
  Manuel

[Bug c++/120121] New: Comparison of integer expressions of different signedness not detected

[stefano.d at posteo dot de via Gcc-bugs]

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

Bug ID: 120121
   Summary: Comparison of integer expressions of different
signedness not detected
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefano.d at posteo dot de
  Target Milestone: ---

Created attachment 61326
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61326&action=edit
Not detected comparison of different signedness

There is a not detected integer promotion when two variables are multiplied and
the result is not stored into a variable.

This compiles with -Wall -O1 -Wextra -Wshadow -Weffc++ -Wno-long-long -pedantic
-pedantic-errors -std=c++14

```
#include 

bool square_less_than_method_A(uint16_t a, uint64_t b) {
// a * a does integer promotion
return (a * a < b);
}

int main(int, char**) {
return 0;
}
```

See also: https://godbolt.org/z/jz8Ka8asn

When the result is assigned into a variable, GCC detects the comparison of
integer expressions of different signedness:

```
#include 

bool square_less_than_method_B(uint16_t a, uint64_t b) {
const auto a_squared = a * a;
return a_squared < b;
}

int main(int, char**) {
return 0;
}
```

The error is correctly reported:

```
: In function 'bool square_less_than_method_B(uint16_t, uint64_t)':
:5:22: warning: comparison of integer expressions of different
signedness: 'const int' and 'uint64_t' {aka 'long unsigned int'}
[-Wsign-compare]
5 | return a_squared < b;
  |~~^~~
```

See also: https://godbolt.org/z/dfY749vdd

[Bug preprocessor/120061] [14 Regression] libqt6webengine fails static_assert (__LINE__ == 470, ...)

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

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

--- Comment #8 from Richard Biener  ---
I have put the files to reprodce at

https://drive.google.com/file/d/11teWjw2MngqeqtT83raZ_5dsh0hDrZCL

untar it in a temporary directory, set ROOT to that directory.

Enter the
home/abuild/rpmbuild/BUILD/qt6-webengine-6.9.0-build/qtwebengine-everywhere-src-6.9.0/build/src/core/RelWithDebInfo/x86_64
subdirectory and
execute (for me it worked to have CXX /path/to/gcc/xg++ -B /path/to/gcc)

$(CXX) -MD -MF obj/content/browser/browser/browser_interface_binders.o.d
-DUSE_UDEV -DUSE_AURA=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD -DTOOLKIT_QT
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES
-D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_NONE -D_GLIBCXX_ASSERTIONS=1
-DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DCONTENT_IMPLEMENTATION
-DV8_USE_EXTERNAL_STARTUP_DATA -DSK_ENABLE_SKSL
-DSK_UNTIL_CRBUG_1187654_IS_FIXED
-DSK_USER_CONFIG_HEADER=\"../../skia/config/SkUserConfig.h\"
-DSK_WIN_FONTMGR_NO_SIMULATIONS -DSK_DISABLE_LEGACY_INIT_DECODERS
-DSK_DISABLE_LEGACY_BACKEND_TEXTURE_FUNCS
-DSK_DISABLE_LEGACY_TEXTURE_INFO_FUNCS
-DSK_DISABLE_LEGACY_BACKEND_SEMAPHORE_FUNCS -DSK_DISABLE_LEGACY_GRAPHITE_IMAGES
-DSK_DISABLE_LEGACY_DAWN_TEXTURE_INFO_FUNCS
-DSK_DISABLE_LEGACY_DAWN_BACKEND_TEXTURE_FUNCS -DSK_CODEC_DECODES_JPEG
-DSK_ENCODE_JPEG -DSK_ENCODE_PNG -DSK_ENCODE_WEBP -DSK_GANESH
-DSK_GPU_WORKAROUNDS_HEADER=\"gpu/config/gpu_driver_bug_workaround_autogen.h\"
-DSK_GL -DSK_VULKAN=1 -DSK_GRAPHITE -DVK_USE_PLATFORM_XCB_KHR -DCHROMIUM
-DLIBYUV_DISABLE_NEON -DLIBYUV_DISABLE_SVE -DLIBYUV_DISABLE_SME
-DLIBYUV_DISABLE_LSX -DLIBYUV_DISABLE_LASX -DUSING_SYSTEM_ICU=1
-DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC -DGOOGLE_PROTOBUF_NO_RTTI
-DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER
-DGOOGLE_PROTOBUF_INTERNAL_DONATE_STEAL_INLINE=0 -DHAVE_PTHREAD
-DLEVELDB_PLATFORM_CHROMIUM=1 -DCRASHPAD_ZLIB_SOURCE_EXTERNAL
-DUSE_SYSTEM_ZLIB=1 -DWEBRTC_CHROMIUM_BUILD -DWEBRTC_POSIX -DWEBRTC_LINUX
-DABSL_ALLOCATOR_NOTHROW=1 -DWEBRTC_USE_X11 -DWEBRTC_USE_PIPEWIRE
-DWEBRTC_USE_GIO -DLOGGING_INSIDE_WEBRTC
-DV8_ARRAY_BUFFER_INTERNAL_FIELD_COUNT=0
-DV8_ARRAY_BUFFER_VIEW_INTERNAL_FIELD_COUNT=0
-DV8_PROMISE_INTERNAL_FIELD_COUNT=0 -DV8_COMPRESS_POINTERS
-DV8_COMPRESS_POINTERS_IN_SHARED_CAGE -DV8_31BIT_SMIS_ON_64BIT_ARCH
-DV8_ENABLE_SANDBOX -DV8_DEPRECATION_WARNINGS -DV8_USE_PERFETTO
-DV8_HAVE_TARGET_OS -DV8_TARGET_OS_LINUX -DCPPGC_CAGED_HEAP
-DCPPGC_YOUNG_GENERATION -DCPPGC_POINTER_COMPRESSION -DCPPGC_ENABLE_LARGER_CAGE
-DCPPGC_SLIM_WRITE_BARRIER -DLIBGAV1_MAX_BITDEPTH=10
-DLIBGAV1_THREADPOOL_USE_STD_MUTEX -DLIBGAV1_ENABLE_LOGGING=0 -DLIBGAV1_PUBLIC=
-DVK_NO_PROTOTYPES -DUSE_VULKAN_XCB -DSQLITE_OMIT_ANALYZE
-DSQLITE_OMIT_AUTOINIT -DSQLITE_OMIT_AUTOMATIC_INDEX -DSQLITE_OMIT_AUTORESET
-DSQLITE_OMIT_COMPILEOPTION_DIAGS -DSQLITE_OMIT_EXPLAIN -DSQLITE_OMIT_GET_TABLE
-DSQLITE_OMIT_INTROSPECTION_PRAGMAS -DSQLITE_DEFAULT_LOOKASIDE=0,0
-DSQLITE_OMIT_LOOKASIDE -DSQLITE_OMIT_TCL_VARIABLE -DSQLITE_OMIT_REINDEX
-DSQLITE_OMIT_TRACE -DSQLITE_OMIT_UPSERT -DSQLITE_OMIT_WINDOWFUNC
-DSQLITE_ENABLE_FTS3 -DSQLITE_DISABLE_FTS3_UNICODE
-DSQLITE_DISABLE_FTS4_DEFERRED -DSQLITE_ENABLE_ICU -DSQLITE_SECURE_DELETE
-DSQLITE_THREADSAFE=1 -DSQLITE_MAX_WORKER_THREADS=0
-DSQLITE_MAX_MMAP_SIZE=268435456 -DSQLITE_DEFAULT_FILE_PERMISSIONS=0600
-DSQLITE_DEFAULT_LOCKING_MODE=1 -DSQLITE_DEFAULT_MEMSTATUS=1
-DSQLITE_DEFAULT_PAGE_SIZE=4096 -DSQLITE_DEFAULT_PCACHE_INITSZ=0
-DSQLITE_LIKE_DOESNT_MATCH_BLOBS -DSQLITE_OMIT_DEPRECATED
-DSQLITE_OMIT_PROGRESS_CALLBACK -DSQLITE_OMIT_SHARED_CACHE -DSQLITE_USE_ALLOCA
-DSQLITE_OMIT_DECLTYPE -DSQLITE_OMIT_JSON -DSQLITE_OMIT_LOAD_EXTENSION
-DSQLITE_HAVE_ISNAN -DSQLITE_HAVE_SQLITE3R -DSQLITE_ENABLE_DBPAGE_VTAB
-DSQLITE_ENABLE_BATCH_ATOMIC_WRITE -DSQLITE_TEMP_STORE=3
-DSQLITE_ENABLE_LOCKING_STYLE=0 -Igen -I../../../../../src/3rdparty/chromium
-I../../../../../src/3rdparty/chromium/third_party/perfetto/include
-Igen/third_party/perfetto/build_config -Igen/third_party/perfetto
-I../../../../../src/3rdparty/chromium/net/third_party/quiche/overrides
-I../../../../../src/3rdparty/chromium/net/third_party/quiche/src/quiche/common/platform/default
-I../../../../../src/3rdparty/chromium/net/third_party/quiche/src
-I../../../../../src/3rdparty/chromium/third_party/skia -Igen/third_party/skia
-I../../../../../src/3rdparty/chromium/third_party/wuffs/src/release/c
-I../../../../../src/3rdparty/chromium/third_party/vulkan/include
-I../../../../../src/3rdparty/chromium/third_party/vulkan-headers/src/include
-I../../../../../src/3rdparty/chromium/third_party/libyuv/include
-I../../../../../src/3rdparty/chromium/third_party/khronos
-I../../../../../src/3rdparty/chromium/gpu -Igen/third_party/dawn/include
-I../../../../../src/3rdparty/chromium/third_party/dawn/include
-I../../../../../src/3rdparty/chromium/base/allocator/partition_allocator/src
-Igen/base/allocator/partition_allocator/src
-I../../../../../src/3rdparty/chro

[Bug fortran/120111] New: program with bad format that compiles and runs

[john.harper at vuw dot ac.nz via Gcc-bugs]

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

Bug ID: 120111
   Summary: program with bad format that compiles and runs
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

Created attachment 61310
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61310&action=edit
test program with a bad format

The attached program has a bad format string but it compiled and ran.
Run-time output with gfortran 15.1.0 with -Wall -Wextra options
```
6*7 = 42
```

[Bug target/120067] RISC-V: x264 sub4x4_dct high icount

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

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

--- Comment #3 from Paul-Antoine Arras  ---
(In reply to rdapp.gcc from comment #2)
> There is indeed a problem with =zvl that we have been discussing in the 
> patchwork sync call for a while already.  The issue is that we're handling
> VLS 
> modes as VLA modes in certain situations resulting in unfortunate codegen. 
> The 
> vector extracts (slidedowns) are one example of it.

I guess this is related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119361#c2 then.
Is there anything I could do to help with that?

[Bug tree-optimization/120080] [16 regression] ICE when building llvm-20.1.3 (find_bit_tests, at tree-switch-conversion.cc:1799) since r16-347-g1381a5114788a2

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

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

--- Comment #7 from Sam James  ---
pipewire and a few other things hit this too, but I'll test any patch against
this rather than filing dupes for now.

[Bug preprocessor/120061] [14 Regression] libqt6webengine fails static_assert (__LINE__ == 470, ...)

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

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 61311
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61311&action=edit
gcc14-pr116047.patch.xz

The PR116047 testcase in patch form, which shows that not doing the decrement
at least in some cases is right.  But as this reproducer shows, in other cases
it is not.

[Bug preprocessor/120061] [14 Regression] libqt6webengine fails static_assert (__LINE__ == 470, ...)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
One interesting data point is that the first
  if (decrement && LINEMAPS_ORDINARY_USED (pfile->line_table))
{
  const line_map_ordinary *map
= LINEMAPS_LAST_ORDINARY_MAP (pfile->line_table);
  if (map && map->start_location == pfile->line_table->highest_location)
decrement = false;
}
where decrement = false; happens on the chromium testcase here is with
loc 0x6269, map->start_location 0x626a, so very soon after
LINE_MAP_MAX_LOCATION_WITH_COLS, i.e. very close after we've stopped tracking
columns, while in the PR116047 testcase map->start_location is 0x53a0, so
very soon after
LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES.
Perhaps the 2 cases behave differently here.

[Bug ada/120104] assertion failure on Finalizable aspect for tagged record type

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

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

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

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

commit r16-387-ge67758cd816978a519d751b618043a8957d67e0e
Author: Eric Botcazou 
Date:   Mon May 5 12:58:58 2025 +0200

Ada: Fix assertion failure on Finalizable aspect for tagged record type

This is a (benign) assertion failure on the mainline for the new
Finalizable
aspect put on a tagged record type when not all the primitives are
declared.
This compiles and runs on the 15 branch because assertions are disabled.

gcc/ada/
PR ada/120104
* exp_ch3.adb (Expand_Freeze_Record_Type): For a controlled tagged
type, freeze only the controlled primitives that are present.

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

[Bug middle-end/120093] [16 Regression] FAIL: gcc.dg/vect/pr101145.c

[mcccs at gmx dot com via Gcc-bugs]

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

mcccs at gmx dot com changed:

   What|Removed |Added

 CC||mcccs at gmx dot com

--- Comment #2 from mcccs at gmx dot com ---
Bisect bad commit: r16-101-g132d01d96ea9d6

[Bug ada/120104] assertion failure on Finalizable aspect for tagged record type

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

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

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

https://gcc.gnu.org/g:37c312486186ed9dc2561b2e341fd81f4f1627ec

commit r15-9620-g37c312486186ed9dc2561b2e341fd81f4f1627ec
Author: Eric Botcazou 
Date:   Mon May 5 12:58:58 2025 +0200

Ada: Fix assertion failure on Finalizable aspect for tagged record type

This is a (benign) assertion failure on the mainline for the new
Finalizable
aspect put on a tagged record type when not all the primitives are
declared.
This compiles and runs on the 15 branch because assertions are disabled.

gcc/ada/
PR ada/120104
* exp_ch3.adb (Expand_Freeze_Record_Type): For a controlled tagged
type, freeze only the controlled primitives that are present.

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

[Bug ada/120104] assertion failure on Finalizable aspect for tagged record type

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #9 from Eric Botcazou  ---
Thanks for reporting the problem.

[Bug c++/120112] New: -Weffc++ -Wmismatched-tags -Wrestrict -Wsystem-headers leads to internal_error

[joo.peter at gmail dot com via Gcc-bugs]

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

Bug ID: 120112
   Summary: -Weffc++ -Wmismatched-tags -Wrestrict -Wsystem-headers
leads to internal_error
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joo.peter at gmail dot com
  Target Milestone: ---

Created attachment 61312
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61312&action=edit
uncompressed size: 5MB

The minimal example is this main.cpp:


#include 
#include 
#include 

using namespace std;
using namespace boost::posix_time;
using namespace boost::icl;

interval_map> f()
{
interval_map> x;
return x;
}

The compilation command which triggers the problem:


1) using godbolt's gcc 15.1.0:
   -Weffc++ -Wmismatched-tags -Wrestrict -Wsystem-headers
   live demo: https://godbolt.org/z/3Pxn81dT5

2) step-by-step reproduction in my arch linux using gcc 14.2.1:
   cd $HOME
   mkdir ./gcc_bug
   cd./gcc_bug
   git clone 'https://github.com/boostorg/boost.git' .
   git checkout 'boost-1.87.0'
   git submodule update --init --force --recursive --jobs=8192
   g++ -I $HOME/gcc_bug -c
$HOME/gcc_bug/libs/icl/test/ex_boost_party_/ex_boost_party.cpp -o /dev/null
-Weffc++ -Wmismatched-tags -Wrestrict -Wsystem-headers -Wtautological-compare

The internal_error in gcc's output is this:


/opt/compiler-explorer/gcc-15.1.0/include/c++/15.1.0/debug/debug.h:61:12:
warning: '__gnu_debug::_Safe_iterator<_Iterator, _Sequence, _Category>'
declared with a mismatched class-key 'struct' [-Wmismatched-tags]
   61 | struct _Safe_iterator;
  |^~
/opt/compiler-explorer/gcc-15.1.0/include/c++/15.1.0/debug/debug.h:61:12:
note: replace the class-key with 'class'
   
/opt/compiler-explorer/gcc-15.1.0/include/c++/15.1.0/bits/stl_iterator.h:2986:11:
note: '__gnu_debug::_Safe_iterator<_Iterator, _Sequence, _Category>' first
declared as 'class' here
 2986 | class _Safe_iterator;
  |   ^~
: In substitution of 'template struct
boost::icl::map::on_total_absorbable [with Type =
boost::icl::map]':
:13:1:   required from here
   13 | }
  | ^
:13:1: internal compiler error: Segmentation fault
0x2287465 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x22989b6 internal_error(char const*, ...)
???:0
0x9ab902 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x9b2467 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0x9b2701 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0x9ab51b tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x99eb8f most_specialized_partial_spec(tree_node*, int, bool)
???:0
0x92aa3c class_decl_loc_t::diag_mismatched_tags(tree_node*)
???:0
0x930f63 class_decl_loc_t::diag_mismatched_tags()
???:0
0x981f15 c_parse_file()
???:0
0xa8b739 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 note that removing either warning will make the error disappear.
I repeat, if I remove either:
-Weffc++
OR
-Wmismatched-tags
OR
-Wrestrict
OR
-Wsystem-headers
OR
-Wtautological-compare
then the bug disappears.
There can be other factors too. Se even though these reproduction steps seem
precise and exact, but maybe they could seem fragile by others. Maybe it is a
Heisenbug, I really don't know what is going on, what warning flag, code line,
or other factor is the culprit here.

I used the -freport-bug too, attached as freport-bug.txt.gz, as the text says.

[Bug target/120019] [16 regression] PR 111657 change broke Solaris/x86 bootstrap

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

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #9 from Uroš Bizjak  ---
> (In reply to Uroš Bizjak from comment #8)
>> Created attachment 61306 [details]
>> Simplified patch

I meant to get to this today.  Thanks for beating me to it.

> Rainer, can you please test this patch on your target?

I've successfully bootstrapped with this patch on i386-pc-solaris2.11,
no regressions.

[Bug target/120019] [16 regression] PR 111657 change broke Solaris/x86 bootstrap

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

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
[...]
> I've successfully bootstrapped with this patch on i386-pc-solaris2.11,
> no regressions.

I meant to say: with both as and gas.

[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0

[bc-info at styx dot cabel.net via Gcc-bugs]

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

Iouri Kharon  changed:

   What|Removed |Added

  Attachment #61272|0   |1
is obsolete||

--- Comment #2 from Iouri Kharon  ---
Created attachment 61313
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61313&action=edit
A small patch for temporary(?) fix for this (and several similar) problems.

Another situation leading to GPF in cc1/cc1plus was found. I'm attaching a
common patch (it includes all previous cases, so the previous patch should be
removed).
In addition, a bug in ld-2.44 was found :). See
https://savannah.gnu.org/patch/index.php?10520

[Bug tree-optimization/119977] [16 regression] Bootstrap comparison failure with -march=znver4 -ggdb3 and bootstrap-lto since r16-152-g4f7b3c24112016

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

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

--- Comment #18 from Sam James  ---
Made a little bit of progress. I have it semi-standalone but it needs headers
from the same directory. 

* Script to reproduce the comparison failure on trunk:
https://gcc.gnu.org/bugzilla/attachment.cgi?id=61229
* Script I've been reducing & bisected the difference with:
https://gcc.gnu.org/bugzilla/attachment.cgi?id=61314
* It is GC-related. Setting different `--param ggc-min-expand=
--param=ggc-min-heapsize=` makes it work.
* Reduction is therefore very painful and slow.
* Bisection was done with a hacked up `contrib/compare-lto` to always fail so
that the stage2-*, stage3-* layout was retained (happens when a failure
happens, couldn't easily replicate that otherwise) then using the gccs from
stage2+stage3.
* Bisecting between basepoints/gcc-15 and trunk for a difference in a constant
source file (reduced gimple-match-6.cc from r16-152-g4f7b3c24112016) yields
r15-7652-ga2755339c6c983.

 i.e. From r15-7652-ga2755339c6c983, stage2 gcc with `-march=znver4 -O2 -ggdb3
-fno-checking` produces different results from stage3 gcc w/ `-march=znver4 -O2
-ggdb3 -fchecking=1` with `.gnu.lto_.decls.1` changing size.

 If it is that commit, that would mean it's the same as our downstream reported
issue in i386.o (which I haven't yet reproduced w/ vanilla sources with no
default changes etc).

 (Previously, `.gnu.lto_.jmpfuncs.1` was changing, but I couldn't reproduce
that with a certain reduction, so changed it to make progress rather than
restarting.)

I'll try reproduce / confirm the bisect result next and get a tarball to share.

[Bug tree-optimization/119977] [16 regression] Bootstrap comparison failure with -march=znver4 -ggdb3 and bootstrap-lto since r16-152-g4f7b3c24112016

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

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

--- Comment #17 from Sam James  ---
Created attachment 61314
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61314&action=edit
compare.sh

[Bug c++/120113] New: Attempting to multiversion a function on AVX512 produces nonsensical results

[krzysio.kurek at wp dot pl via Gcc-bugs]

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

Bug ID: 120113
   Summary: Attempting to multiversion a function on AVX512
produces nonsensical results
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krzysio.kurek at wp dot pl
  Target Milestone: ---

Given the following code:
```
[[gnu::target("default")]]
bool compressAvailable()
{
return false;
}

[[gnu::target("avx512vbmi2")]]
bool compressAvailable()
{
return true;
}

int main()
{
compressAvailable();
}
```
The program will always unconditionally return false, as gcc fails to create a
resolve function and does not create a call to ifunc, and inlines the default
target version. If instead of avx512vbmi2 avx512f is passed, the ifunc is
generated as expected and the inlining is gone.

Furthermore, if 3 versions of the function are specified, i.e.:
```
[[gnu::target("default")]]
bool compressAvailable()
{
return false;
}

[[gnu::target("avx512f")]]
bool compressAvailable()
{
return false;
}

[[gnu::target("avx512vbmi2")]]
bool compressAvailable()
{
return true;
}

int main()
{
compressAvailable();
}
```
finally a sane error appears:
```
: In function '_Z17compressAvailablev.resolver':
:14:6: error: ISA 'avx512vbmi2' is not supported in 'target' attribute,
use 'arch=' syntax
   14 | bool compressAvailable()
  |  ^
Compiler returned: 1
```

[Bug libstdc++/120114] New: Format width is not correctly handled for chrono formatting

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

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

Bug ID: 120114
   Summary: Format width is not correctly handled for chrono
formatting
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkaminsk at gcc dot gnu.org
  Target Milestone: ---

Field width is not correctly computed when Unicode characters are included in
chrono-spec:
```
using namespace std::chrono_literals;
auto date = 2025y/std::chrono::May/05d;
auto res = std::format("{:+<13%F\U0001f921}", date);
// 2025-05-05🤡, should have 1 '+' of padding
std::cout << res << std::endl;
res = std::format("{:+<15%F\U0001f921}", date);
// 2025-05-05🤡+, should have 3 '+' of padding
std::cout << res << std::endl;
auto wres = std::format(L"{:+<13%F\U0001f921}", date);
// 2025-05-05🤡++, should have 1 '+' of padding
wres = std::format(L"{:+<15%F\U0001f921}", date);
// 2025-05-05🤡, should have 3 '+' of padding
```
See: https://godbolt.org/z/d3x5Gq83h

[Bug tree-optimization/120089] [15/16 regression] GCC miscompiles VK-GL-CTS (on aarch64) with -O3 since r15-7533-g589d79e6268b05

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

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

--- Comment #25 from Richard Biener  ---
At least on x86_64 before r15-7533-g589d79e6268b05 we failed to vectorize this:

t.c:17:12: note:   examining phi: _33 = PHI <0(20), _42(17)>
t.c:9:1: missed:   not vectorized: relevant phi not supported: _33 = PHI
<0(20), _42(17)> 
t.c:17:12: missed:  bad operation or unsupported loop bound
t.c:17:12: note:  * Analysis failed with vector mode V2DI

(this is the PHI that misses the SLP discovery)

t.c:17:12: missed:can't vectorize early exit because the target doesn't
support flag setting vector comparisons.
t.c:17:12: note:   unsupported SLP instance starting from: if (patt_37 != 0)
t.c:17:12: missed:  unsupported SLP instances
t.c:17:12: note:  * Analysis failed with vector mode V8QI

(unsupported ptest)

So the issue was previously latent.  I did not yet spot the actual issue,
the vectorization looks correct to my eyes...

Note the main exit is the exit to the __builtin_trap().


With SSE4 we exit the main vector loop after 3 vector iterations via the early
exit (to the non-trap)

(gdb) p data
$20 = {d = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 
19, 20, 21, 22, 23, 0 }}

movq%xmm3, %rdx
movd%xmm1, %eax

both IVs are 12 which I think is correct, but then the destination pointer
seems mishandled - that somehow gets taken from the original scalar IV
and thus it doesn't have VF == 4 imposed.  Seems like a missed early-exit
forced-live IV, but it's an address IV.

[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0

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

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

--- Comment #3 from Sam James  ---
(In reply to Iouri Kharon from comment #2)
> In addition, a bug in ld-2.44 was found :). See
> https://savannah.gnu.org/patch/index.php?10520

Could you file that on the sourceware bugzilla? I don't think anyone looks at
savannah for binutils (didn't even know a page was there).

[Bug rust/119641] narrowing Warning during bootstrap in Rust::BIR::PlaceDB::lookup_or_add_variable

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

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

--- Comment #5 from Thomas Schwinge  ---
I'm confirming that all but one '-Wnarrowing' are resolved.  Only this one
remains:

[...]/gcc/rust/checks/errors/borrowck/rust-borrow-checker-diagnostics.cc:
In member function 'const Rust::BIR::Loan&
Rust::BIR::BorrowCheckerDiagnostics::get_loan(Rust::Polonius::Loan)':
   
[...]/gcc/rust/checks/errors/borrowck/rust-borrow-checker-diagnostics.cc:145:46:
warning: narrowing conversion of 'loan' from 'Rust::Polonius::Loan' {aka 'long
unsigned int'} to 'uint32_t' {aka 'unsigned int'} [-Wnarrowing]
  145 |   return bir_function.place_db.get_loans ()[{loan}];
  |  ^~~~

[Bug tree-optimization/120089] [15/16 regression] GCC miscompiles VK-GL-CTS (on aarch64) with -O3 since r15-7533-g589d79e6268b05

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

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

--- Comment #26 from Richard Biener  ---
An the issue that we are not marking this as LOOP_VINFO_EARLY_BREAKS_LIVE_IVS
is because we do not consider it an induction as we get

  {(type *) &data.d, +, (sizetype) _5 + 8}_2

and STEP is neither a constant nor an SSA name.  This is because we have
two increments in the loop body:

 [local count: 477815112]:
# _33 = PHI <0(20), _42(17)>
# nextVertexPtr_9 = PHI <&data.d(20), nextVertexPtr_41(17)>
# vertexIdx_7 = PHI <0(20), vertexIdx_40(17)>
_27 = _33 * 8;
_26 = origVertices_16(D) + _27;
_29 = MEM  [(char * {ref-all})_26];
MEM  [(char * {ref-all})nextVertexPtr_9] = _29;
nextVertexPtr_38 = nextVertexPtr_9 + 8;   <--- here
vertexIdx_40 = vertexIdx_7 + 1;
if (vertexCount_11 > vertexIdx_40)
  goto ; [89.00%]
else
  goto ; [11.00%]

 [local count: 425255450]:
nextVertexPtr_41 = nextVertexPtr_38 + _5; <--- here
_42 = (long unsigned int) vertexIdx_40;
if (_42 > t_10(D))
  goto ; [0.00%]
else
  goto ; [100.00%]

as a result from unswitching and not hoisting the resulting invariant
(_5 + 8).

That we "fail" to consider this a vectorizable IV required live for
early-break vectorization is bad.  What is worse is that we fail to
then reject vectorizing instead of simply doing the wrong thing.

We can fix this by analyzing all PHIs to be "live" for early break,
resulting in

t.c:17:12: note:   init: phi relevant? nextVertexPtr_9 = PHI <&data.d(20),
nextVertexPtr_41(17)>   
t.c:17:12: note:   vec_stmt_relevant_p: induction forced for early break.
t.c:17:12: note:   vec_stmt_relevant_p: stmt live but not relevant.
...
t.c:17:12: note:   vect_is_simple_use: operand nextVertexPtr_9 = PHI
<&data.d(20), nextVertexPtr_41(17)>, type of def: unknown
t.c:17:12: missed:   Unsupported pattern.
t.c:21:23: missed:   not vectorized: unsupported use in stmt.
t.c:17:12: missed:  unexpected pattern.

since we don't handle this PHI.

[Bug middle-end/120115] New: ICE in quick_grow_cleared with -fdisable-tree-switchlower1 -fdisable-tree-switchlower2

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

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

Bug ID: 120115
   Summary: ICE in quick_grow_cleared with
-fdisable-tree-switchlower1
-fdisable-tree-switchlower2
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 61315
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61315&action=edit
Path.cpp.ii.xz

I'm not sure if this is valid to be trying or not.

To workaround PR120080, I tried -fdisable-tree-switchlower1
-fdisable-tree-switchlower2 and hit this:
```
$ g++ -m32 ./lib/Support/CMakeFiles/LLVMSupport.dir/Path.cpp.ii -c
-fdisable-tree-switchlower1 -fdisable-tree-switchlower2 -O1
cc1plus: note: disable pass tree-switchlower1 for functions in the range of [0,
4294967295]
cc1plus: note: disable pass tree-switchlower2 for functions in the range of [0,
4294967295]
during RTL pass: expand
In file included from
/var/tmp/portage.notmp/portage/llvm-core/llvm-20.1.4/work/llvm/lib/Support/Path.cpp:1199:
In function ‘bool llvm::sys::fs::is_local_impl(statfs&)’,
inlined from ‘std::error_code llvm::sys::fs::is_local(const llvm::Twine&,
bool&)’ at
/var/tmp/portage.notmp/portage/llvm-core/llvm-20.1.4/work/llvm/lib/Support/Unix/Path.inc:563:25:
/var/tmp/portage.notmp/portage/llvm-core/llvm-20.1.4/work/llvm/lib/Support/Unix/Path.inc:488:3:
internal compiler error: in quick_grow_cleared, at vec.h:1443
  488 |   switch ((uint32_t)Vfs.f_type) {
  |   ^~
0x5c39613c2c3f internal_error(char const*, ...)
   
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./gcc/diagnostic-global-context.cc:517
0x5c39613a4534 fancy_abort(char const*, int, char const*)
   
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./gcc/diagnostic.cc:1748
0x5c39601c117a vec::quick_grow_cleared(unsigned
int)
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./gcc/vec.h:1443
0x5c39601c117a vec::safe_grow_cleared(unsigned int,
bool)
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./gcc/vec.h:2155
0x5c39621f9de6 emit_case_dispatch_table
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./gcc/stmt.cc:802
0x5c3961e47e1b expand_case(gswitch*)
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./gcc/stmt.cc:1032
0x5c3961abbff8 expand_gimple_stmt
   
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./gcc/cfgexpand.cc:4364
0x5c3961abbff8 expand_gimple_basic_block
   
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./gcc/cfgexpand.cc:6427
0x5c3961a16dd7 execute
   
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./gcc/cfgexpand.cc:7176
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.
```

---

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/16/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
93f36c1b921e531fd4cdc6aee7af55e1d6eb9d39' --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
--enable-host-bind-now --enable-default-ssp --disable-fixincludes
--with-gxx-libcxx-include-dir=/usr/include/c++/v1 --enable-linker-build-id
--with-build-config='bootstrap-O3 boot

[Bug rtl-optimization/120116] New: Huge memory use with -fdisable-tree-switchlower1 -fdisable-tree-switchlower2

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

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

Bug ID: 120116
   Summary: Huge memory use with -fdisable-tree-switchlower1
-fdisable-tree-switchlower2
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: memory-hog
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 61316
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61316&action=edit
regcomp.c.i.xz

When trying to workaround PR120080 (and also hitting PR120115) with
-fdisable-tree-switchlower1 -fdisable-tree-switchlower2, I also OOMed on
another file:
```
$ gcc -c ./lib/Support/CMakeFiles/LLVMSupport.dir/regcomp.c.i -O2
-fdisable-tree-switchlower1 -fdisable-tree-switchlower2
cc1: note: disable pass tree-switchlower1 for functions in the range of [0,
4294967295]
cc1: note: disable pass tree-switchlower2 for functions in the range of [0,
4294967295]
# OOM with >50GB RAM use
```

```

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/16/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
93f36c1b921e531fd4cdc6aee7af55e1d6eb9d39' --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
--enable-host-bind-now --enable-default-ssp --disable-fixincludes
--with-gxx-libcxx-include-dir=/usr/include/c++/v1 --enable-linker-build-id
--with-build-config='bootstrap-O3 bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250504 (experimental)
064cac730f88dc71c6da578f9ae5b8e092ab6cd4 (Gentoo Hardened 16.0. p, commit
93f36c1b921e531fd4cdc6aee7af55e1d6eb9d39)
```

[Bug target/119698] gen_il-main: raised PROGRAM_ERROR : finalize/adjust raised exception

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

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

John David Anglin  changed:

   What|Removed |Added

  Component|ada |target
Version|15.0|12.4.1
 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #17 from John David Anglin  ---
I believe this bug is fixed by the following commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8b26ee407613cdbfc3fb2095c09ae28b4642fd63

This change enables generation of GNU stack notes in gcc-12.  As
similar commit was done for gcc-13.

At some point, binutils changed the default for making the stack
executable.  This broke nested function support and gnat in gcc-12
and gcc-13.  The fix is to enable generation of GNU stack notes
for these releases.

The broken Debian packages need to be replaced with new builds.

[Bug ada/120104] assertion failure on Finalizable aspect with abstract primitive

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

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

Eric Botcazou  changed:

   What|Removed |Added

Summary|[15/16 regression]  |assertion failure on
   |assertion failure on|Finalizable aspect with
   |Finalizable aspect with |abstract primitive
   |abstract primitive  |
   Target Milestone|15.2|16.0

--- Comment #3 from Eric Botcazou  ---
Yes, but we do not configure releases with assertions for a reason.

[Bug ada/120104] assertion failure on Finalizable aspect with abstract primitive

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #4 from Sam James  ---
Yes, I was triaging it the way we do the rest of the compiler. If Ada does it
differently, fine. But it's notable that it goes away for a range.

[Bug ipa/120048] [14/15/16 Regression] ICE on valid code at -O{s,2} with "-fno-tree-vrp -fno-tree-fre" on x86_64-linux-gnu: in type, at value-range.h:982 since r16-244-gce489c870bf28e

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

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

--- Comment #10 from Martin Jambor  ---
The workaround looks reasonable to me.

[Bug c/120109] [12/13/14/15 regression] ICE in expand_builtin_init_trampoline with __builtin_init_trampoline using __FILE__ as 3rd argument

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

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

Sam James  changed:

   What|Removed |Added

Summary|ICE in  |[12/13/14/15 regression]
   |expand_builtin_init_trampol |ICE in
   |ine with|expand_builtin_init_trampol
   |__builtin_init_trampoline   |ine with
   |using __FILE__ as 3rd   |__builtin_init_trampoline
   |argument|using __FILE__ as 3rd
   ||argument
  Known to fail||16.0, 4.5.3
  Known to work||4.4.7
   Target Milestone|--- |12.5