[Bug libstdc++/121097] hypot uses __promoted_t even when __cpp_fold_expressions is not defined

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
--- a/libstdc++-v3/include/ext/type_traits.h
+++ b/libstdc++-v3/include/ext/type_traits.h
@@ -269,6 +269,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
   typedef __typeof__(_Tp2() + _Up2() + _Vp2() + _Wp2()) __type;
 };
+
+#ifdef __glibcxx_hypot // C++ >= 17 && HOSTED
+  // __promoted_t is needed by the 3-arg std::hypot so define it inefficiently
+  // for C++17 compilers that don't define __cpp_fold_expressions (PR 121097).
+  template
+using __promoted_t = typename __promote_3<_Tp1, _Tp2, _Tp3>::__type;
+#endif
+
 #endif

 _GLIBCXX_END_NAMESPACE_VERSION

[Bug libstdc++/121097] hypot uses __promoted_t even when __cpp_fold_expressions is not defined

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Arthur O'Dwyer from comment #1)
> Er, PC-Lint 2.0 with a config file that *we* made to roughly emulate GCC 10,
> apparently. I can't blame PC-Lint itself for the weird setting of these
> macros. :)

Don't do that then? or change your config file to fix it?

[Bug libstdc++/121097] hypot uses __promoted_t even when __cpp_fold_expressions is not defined

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Arthur O'Dwyer  ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Arthur O'Dwyer from comment #1)
> > Er, PC-Lint 2.0 with a config file that *we* made
> 
> Don't do that then? or change your config file to fix it?

I considered repeating the sentences "Now, we're also stuck on libstdc++ 11.4,
so we're going to have to work around this on our end anyway (by manually
-D__cpp_fold_expressions=201603 on our PC-Lint command line). But IMHO you
should still want to harmonize these macros on your end" from my original
post... but I thought to myself, "Nah, that would waste the reader's time, to
read that twice."

[Bug rtl-optimization/121098] target macro HARDREG_PRE_REGNOS is NOT documented

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-07-15

--- Comment #1 from Eric Botcazou  ---
Yes, the interface with back-ends would need to be reworked.

[Bug target/121095] [15/16 Regression] Possibly unnecessary PRE pass on aarch64 for fpmr

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|enhancement |normal
Summary|Possibly unnecessary PRE|[15/16 Regression] Possibly
   |pass on aarch64 for fpmr|unnecessary PRE pass on
   ||aarch64 for fpmr
   Target Milestone|--- |15.2
   Keywords||memory-hog

--- Comment #3 from Andrew Pinski  ---
(In reply to lucier from comment #2)
> My take, without having any serious knowledge of what's going on, is:
> 
> If a C function doesn't involve (set, read, manipulate, ...) FP8 values or
> the fpmr register in any way, then this PRE pass shouldn't be run, because
> this PRE pass only deals with the fpmr register, and I don't see how any
> relevant code can be affected by, or can affect, the fpmr register if no FP8
> manipulations are involved in a routine.
> 
> And I suggest that this should be true even if the architecture supports FP8
> arithmetic in general.
> 
> I am ignorant of the details of what's going on here, so my expectation may
> very well be incorrect.

I have not looked into this far enough to say if this is possible or not. But
the first step is disable it if the arch does not support FP8 in the first
place. The next step is to look to see if it is possible to see if FPMR is ever
used/alive or not.

Note the simple patch should take care of over 90% of the cases that people
will run into; it is only for future architectures where this could come into
play. 

I might take a look at the TARGET_FP8 case but not this week and most likely
not for GCC 16 either; it is definitely less important at that point.

[Bug modula2/120389] Assigning a CHAR to an INTEGER crashes the compiler

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #9 from Gaius Mulley  ---
Closing.

[Bug target/121095] Possibly unnecessary PRE pass on aarch64 for fpmr

[lucier at math dot purdue.edu via Gcc-bugs]

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

--- Comment #2 from lucier at math dot purdue.edu ---
My take, without having any serious knowledge of what's going on, is:

If a C function doesn't involve (set, read, manipulate, ...) FP8 values or the
fpmr register in any way, then this PRE pass shouldn't be run, because this PRE
pass only deals with the fpmr register, and I don't see how any relevant code
can be affected by, or can affect, the fpmr register if no FP8 manipulations
are involved in a routine.

And I suggest that this should be true even if the architecture supports FP8
arithmetic in general.

I am ignorant of the details of what's going on here, so my expectation may
very well be incorrect.

This PRE pass wasn't run on this example function because more than 128MB of
memory would have been needed, but when building the Gambit Scheme system there
are many relatively large routines where this PRE pass is run.

In another large file where this PRE pass was run, the dump file contained:

PRE GCSE of ___H___num, 31567 basic blocks, 2524104 bytes needed, 0 substs, 0
insns created

Does "0 substs, 0 insns created" mean that running the pass had no effect on
the code?

Brad

[Bug libstdc++/119962] : __maybe_present_t misses initialization

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:0828600f586e75a2056a4fc7eb0a340c363d6c66

commit r16-2271-g0828600f586e75a2056a4fc7eb0a340c363d6c66
Author: Patrick Palka 
Date:   Tue Jul 15 15:17:23 2025 -0400

libstdc++: Add missing initializers for __maybe_present_t members
[PR119962]

Data members of type __maybe_present_t where the conditionally present
type might be an aggregate or fundamental type need to be explicitly
value-initialized (rather than implicitly default-initialized), so that
default-initialization of the containing class always results in an
completely initialized object.

PR libstdc++/119962

libstdc++-v3/ChangeLog:

* include/std/ranges (join_view::_Iterator::_M_outer): Initialize.
(lazy_split_view::_OuterIter::_M_current): Initialize.
(join_with_view::_Iterator::_M_outer_it): Initialize.
* testsuite/std/ranges/adaptors/join.cc (test15): New test.
* testsuite/std/ranges/adaptors/join_with/1.cc (test05): New test.
* testsuite/std/ranges/adaptors/lazy_split.cc (test13): New test.

Reviewed-by: Tomasz KamiÅski 
Reviewed-by: Jonathan Wakely 

[Bug tree-optimization/121091] ICE in tree_to_uhwi, at tree.cc:6660 with SVE switch choosing predicate values

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

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

--- Comment #5 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689666.html

[Bug middle-end/120378] Support narrowing clip idiom

[ewlu at rivosinc dot com via Gcc-bugs]

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

--- Comment #7 from Edwin Lu  ---
Progress update:
After discussing with Vineet and Robin, the optab for generating vnclipu does
exist through IFN_SAT_TRUNC, which can be seen in a couple of the saturating
arithmetic testcases Pan has been working on. The current patterns do support
matching on gimple min/max truncates

  _3 = in_12(D) + _2;
  _4 = *_3;
  _5 = MIN_EXPR <_4, 255>;
  iftmp.0_8 = (uint8_t) _5;
  _6 = out_13(D) + _1;
  *_6 = iftmp.0_8;

https://godbolt.org/z/q7j1T9bxf

I'm currently working through adding a pattern in match.pd to recognize the
sequence x264 generates and am encountering a problem in the generated
gimple-match-4.cc. 

>   _4 = *_3;
>   x.0_12 = (unsigned int) _4;
>   _38 = -x.0_12;
>   _15 = (int) _38;
>   _16 = _15 >> 31;
>   _29 = x.0_12 > 255;
>   _17 = _29 ? _16 : _4;
>   _18 = (unsigned char) _17;

Right now, I'm doing
 (match (unsigned_integer_sat_trunc @0)
  /* SAT_U_TRUNC = X & (NT)(-1) ? (-X) >> 31 : X

 The gimple representation uses X > (NT)(-1) instead of
 using & so match on gt instead of bit_and.  */
  (cond^ (gt @0 INTEGER_CST@1)
 (rshift:s (convert? (negate @0)) INTEGER_CST@2)
 @0)

which tries to check if the statement `_4 = *_3;` and `x.0_12 = (unsigned int)
_4;` are equivalent when trying to evaluate the else statement.

[Bug c++/121089] [13/14/15/16 Regression] internal compiler error: Segmentation fault splay_tree_foreach with enum and invalid underlying type

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||13.1.0
  Known to work||12.4.0
Summary|internal compiler error:|[13/14/15/16 Regression]
   |Segmentation fault  |internal compiler error:
   |splay_tree_foreach since|Segmentation fault
   |13.1|splay_tree_foreach with
   ||enum and invalid underlying
   ||type
   Target Milestone|--- |13.5

[Bug c++/121089] [13/14/15/16 Regression] internal compiler error: Segmentation fault splay_tree_foreach with enum class and invalid underlying type

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
.

[Bug c++/121089] internal compiler error: Segmentation fault splay_tree_foreach since 13.1

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||error-recovery

--- Comment #1 from Andrew Pinski  ---
Reduced to:
```
enum class e1 : auto
{
  kSwap = 0,
};
void f( const e1& mutation)
{
  switch (mutation) {
case e1::kSwap: ;
  };
}
```

[Bug c/82134] warn_unused_result triggers on empty structs even when they are used

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

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

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

https://gcc.gnu.org/g:32ff6f4728e4021ff33fb1da6eb3bafe3ea5a15e

commit r16-2280-g32ff6f4728e4021ff33fb1da6eb3bafe3ea5a15e
Author: Jeremy Rifkin 
Date:   Tue Jul 15 18:17:01 2025 -0400

c, c++: Fix unused result for empty types [PR82134]

Hi,
This fixes PR c/82134 which concerns gcc emitting an incorrect unused
result diagnostic for empty types. This diagnostic is emitted from
tree-cfg.cc because of a couple code paths which attempt to avoid
copying empty types, resulting in GIMPLE that isn't using the returned
value of a call. To fix this I've added suppress_warning in three locations
and a corresponding check in do_warn_unused_result.

Cheers,
Jeremy

PR c/82134

gcc/cp/ChangeLog:

* call.cc (build_call_a): Add suppress_warning
* cp-gimplify.cc (cp_gimplify_expr): Add suppress_warning

gcc/ChangeLog:

* gimplify.cc (gimplify_modify_expr): Add suppress_warning
* tree-cfg.cc (do_warn_unused_result): Check warning_suppressed_p

gcc/testsuite/ChangeLog:

* c-c++-common/attr-warn-unused-result-2.c: New test.

Signed-off-by: Jeremy Rifkin 

[Bug target/93738] [13/14/15/16 regression] test case gcc.target/powerpc/20050603-3.c fails

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

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

Kishan Parmar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #11 from Kishan Parmar  ---
The issue is actually in the combine pass, not the reload pass.

In the combine pass, GCC tries to merge three instructions shift, AND, and OR
into a single rotate-and-insert instruction. This works by recognizing a
specific pattern. However, this pattern is failing to match in some cases, and
we end up with two separate instructions: one for rotate and another for
insert.

When a function has a primitive-type argument (like int, unsigned int), the
incoming argument is typically in DI mode. Later in the RTL, GCC uses a subreg
to extract the 32 bits, resulting in an SI mode operand.

Previously, before r9-3594 patch, combine would often see subregs of hard
registers (e.g., subreg:SI (reg:DI ...) directly referencing hardware
registers).
However, after patch, which intentionally introduces extra pseudo-to-pseudo
moves for parameter and return registers to improve register allocation the
situation changed. Now we often have a subreg of a pseudo register, IN BE it is
being transformed into a zero_extract expression. and GCC is failing there to
match pattern.

[Bug c/121081] [16 Regression] ICE on x86_64-linux-gnu: in composite_type, at c/c-typeck.cc:1011 with visibility attribute on atomic

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |16.0
   Last reconfirmed||2025-07-16
   Keywords||ice-on-valid-code,
   ||needs-bisection
Summary|ICE on x86_64-linux-gnu: in |[16 Regression] ICE on
   |composite_type, at  |x86_64-linux-gnu: in
   |c/c-typeck.cc:1011 with |composite_type, at
   |visibility attribute on |c/c-typeck.cc:1011 with
   |atomic  |visibility attribute on
   ||atomic

--- Comment #1 from Andrew Pinski  ---
Confirmed. A regression from 15.

[Bug target/121099] New: GCC doesn't optimize `_mm_set_ps()` very well

[lh_mouse at 126 dot com via Gcc-bugs]

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

Bug ID: 121099
   Summary: GCC doesn't optimize `_mm_set_ps()` very well
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

For this 4-way comparison function:
(https://gcc.godbolt.org/z/sY4vdcjdq)
```
// Returns (angles are in degrees)
// - 0b1110 for   0 -  45 where x > y > 0 > -x
// - 0b for  45 -  90 where y > x > 0 > -x
// - 0b0111 for  90 - 135 where y > -x > 0 > x
// - 0b0011 for 135 - 180 where -x > y > 0 > x
// - 0b0001 for 180 - 225 where -x > 0 > y > x
// - 0b for 225 - 270 where -x > 0 > x > y
// - 0b1000 for 270 - 315 where x > 0 > -x > y
// - 0b1100 for 315 - 360 where x > 0 > y > -x
int
octant_of_angle(float y, float x)
  {
__m128 ps = _mm_cmpgt_ps(_mm_set_ps(x, x, y, y), _mm_set_ps(0, -y, 0, x));
return _mm_movemask_ps(ps);
  }
```

GCC emits 8 instructions for the two `_mm_set_ps()` intrins:
```
vunpcklps   xmm2, xmm0, xmm0
vxorps  xmm0, xmm0, XMMWORD PTR .LC0[rip]
vxorps  xmm4, xmm4, xmm4
vunpcklps   xmm3, xmm1, xmm1
vunpcklps   xmm1, xmm1, xmm4
vunpcklps   xmm0, xmm0, xmm4
vmovlhpsxmm2, xmm2, xmm3
vmovlhpsxmm1, xmm1, xmm0
```

while Clang only emits 3:
```
vshufps xmm2, xmm0, xmm1, 0
vxorps  xmm0, xmm0, xmmword ptr [rip + .LCPI0_0]
vinsertps   xmm0, xmm1, xmm0, 42
```

[Bug target/121099] GCC doesn't optimize `_mm_set_ps()` very well

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug fortran/121060] ICE when argument is associate name created from type-bound operator result

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

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

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

https://gcc.gnu.org/g:82e912344d28cf1a69e5f8e047203ea7eb625302

commit r16-2282-g82e912344d28cf1a69e5f8e047203ea7eb625302
Author: Paul Thomas 
Date:   Wed Jul 16 06:16:57 2025 +0100

Fortran: Fix ICE in ASSOCIATE with user defined operator [PR121060]

2025-07-16  Paul Thomas  

gcc/fortran
PR fortran/121060
* interface.cc (matching_typebound_op): Defer determination of
specific procedure until resolution by returning NULL.

gcc/testsuite/
PR fortran/121060
* gfortran.dg/associate_75.f90: New test.

[Bug c/121102] ICE at O2: in make_ssa_name_fn, at tree-ssanames.cc:355

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

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

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 120898 ***

[Bug c/120898] ICE at -O2 calling function with old-style definition taking a VLA parameter

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||bic60176 at gmail dot com

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

[Bug c/121103] New: ICE at O2: in single_succ_edge, at basic-block.h:332

[bic60176 at gmail dot com via Gcc-bugs]

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

Bug ID: 121103
   Summary: ICE at O2: in single_succ_edge, at basic-block.h:332
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bic60176 at gmail dot com
  Target Milestone: ---

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

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

console:
during GIMPLE pass: local-fnsummary
: In function 'h':
:38:1: internal compiler error: in single_succ_edge, at
basic-block.h:332
   38 | }
  | ^
0x253d385 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x255f066 internal_error(char const*, ...)
???:0
0xa011e4 fancy_abort(char const*, int, char const*)
???:0
0xecc581 compute_fn_summary(cgraph_node*, bool)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

[Bug c/121102] New: ICE at O2: in make_ssa_name_fn, at tree-ssanames.cc:355

[bic60176 at gmail dot com via Gcc-bugs]

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

Bug ID: 121102
   Summary: ICE at O2: in make_ssa_name_fn, at
tree-ssanames.cc:355
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bic60176 at gmail dot com
  Target Milestone: ---

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

Compiler explorer: https://godbolt.org/z/fqb8bsT6x

console: 
: In function 'bar':
:8:7: warning: old-style function definition [-Wold-style-definition]
8 |   int bar(c) int c[1][va_arg(a, int)];
  |   ^~~
during GIMPLE pass: einline
: In function 'foo':
:10:11: internal compiler error: in make_ssa_name_fn, at
tree-ssanames.cc:355
   10 |   int r = bar(b);
  |   ^~
0x253d385 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x255f066 internal_error(char const*, ...)
???:0
0xa011e4 fancy_abort(char const*, int, char const*)
???:0
0x122b074 copy_tree_body_r(tree_node**, int*, void*)
???:0
0x152b46c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x152b668 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x1228172 remap_type(tree_node*, copy_body_data*)
???:0
0x1228172 remap_type(tree_node*, copy_body_data*)
???:0
0x1237091 optimize_inline_calls(tree_node*)
???:0
0x23b1f91 early_inliner(function*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

[Bug tree-optimization/121103] [15/16 Regression] ICE at O2: in single_succ_edge, at basic-block.h:332

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
Summary|ICE at O2: in   |[15/16 Regression] ICE at
   |single_succ_edge, at|O2: in single_succ_edge, at
   |basic-block.h:332   |basic-block.h:332
   Target Milestone|--- |15.2

[Bug c/121104] New: ICE at O2: verify_gimple_in_cfg(function*, bool, bool)

[bic60176 at gmail dot com via Gcc-bugs]

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

Bug ID: 121104
   Summary: ICE at O2: verify_gimple_in_cfg(function*, bool, bool)
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bic60176 at gmail dot com
  Target Milestone: ---

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

Compiler Explorer: https://godbolt.org/z/9xEq5bdjf

console:
: In function 'bar':
:12:15: error: type mismatch in 'imagpart_expr' reference
   12 | unsigned long bar(unsigned long *p, unsigned long *q) {
  |   ^~~
long unsigned int

int

_44 = IMAGPART_EXPR <_74>;
:12:15: error: type mismatch in 'imagpart_expr' reference
long unsigned int

int

_34 = IMAGPART_EXPR <_73>;
:12:15: error: type mismatch in 'imagpart_expr' reference
long unsigned int

int

_24 = IMAGPART_EXPR <_72>;
during GIMPLE pass: widening_mul
:12:15: internal compiler error: verify_gimple failed
0x253d385 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x255f066 internal_error(char const*, ...)
???:0
0x11ee76e verify_gimple_in_cfg(function*, bool, bool)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

[Bug target/121105] New: `svfloat32x4_t{}` does not zero the registers

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

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

Bug ID: 121105
   Summary: `svfloat32x4_t{}` does not zero the registers
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
#include "arm_sve.h"

svfloat32x4_t e() {
  return svfloat32x4_t{};
}

```

I thought this would cause z0-z3 to be zero. But rather it stays in undefined
state.

[Bug tree-optimization/121104] ICE at O2: verify_gimple_in_cfg(function*, bool, bool)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||needs-bisection
   Target Milestone|--- |14.4
  Known to work||13.4.0
  Known to fail||14.1.0
   Last reconfirmed||2025-07-16

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

[Bug c++/121089] [13/14/15/16 Regression] internal compiler error: Segmentation fault splay_tree_foreach with enum class and invalid underlying type

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug debug/121093] Missed location of inlined function

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

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

--- Comment #1 from Richard Biener  ---
we don't elide inlined_function_outer_scope_p IIRC, so not sure why this would
happen?  But the flow of conditions is a bit odd:

   /* When not generating debug info we can eliminate info on unused
  variables.  */
   else if (!flag_auto_profile
&& debug_info_level == DINFO_LEVEL_NONE
&& !optinfo_wants_inlining_info_p ())
 {
   /* Even for -g0 don't prune outer scopes from inlined functions,
  otherwise late diagnostics from such functions will not be
  emitted or suppressed properly.  */
   if (inlined_function_outer_scope_p (scope))
 {
   gcc_assert (TREE_CODE (BLOCK_ORIGIN (scope)) == FUNCTION_DECL);
   unused = false;
 }
 }
   else if (BLOCK_VARS (scope) || BLOCK_NUM_NONLOCALIZED_VARS (scope))
 unused = false;
   /* See if this block is important for representation of inlined
  function.  Inlined functions are always represented by block
  with block_ultimate_origin being set to FUNCTION_DECL and
  DECL_SOURCE_LOCATION set, unless they expand to nothing...  */
   else if (inlined_function_outer_scope_p (scope))
 unused = false;

[Bug target/121096] [16 Regression] ICE: in store_by_pieces, at expr.cc:1847 with -Os -mtune=... -mstringop-strategy=vector_loop

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |16.0
   Keywords||needs-bisection

[Bug target/121096] [16 Regression] ICE: in store_by_pieces, at expr.cc:1847 with -Os -mtune=k8 -mvpclmulqdq -mstringop-strategy=vector_loop

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #1 from Zdenek Sojka  ---
Created attachment 61879
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61879&action=edit
testcase with less compiler flags

$ x86_64-pc-linux-gnu-gcc -Os -mstringop-strategy=unrolled_loop -mtune=btver2
testcase2.c 
during RTL pass: expand
testcase2.c: In function 'foo':
testcase2.c:6:24: internal compiler error: in store_by_pieces, at expr.cc:1847
6 | _BitInt(512) a = b >> 507;
  |  ~~^~
...

[Bug sanitizer/121079] ICE on x86_64-linux-gnu: tree check: expected tree that contains 'common' structure, have 'integer_cst' in copy_list, at tree.cc:1508

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug middle-end/113264] ICE with attribute copy and attribute no_sanitize_address on the original decl

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jiangchangwu at smail dot 
nju.edu.
   ||cn

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

[Bug c/121100] New: ICE: Segmentation fault at contains_struct_check

[bic60176 at gmail dot com via Gcc-bugs]

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

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

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

Compiler Explorer: https://godbolt.org/z/46MoEsvoz

console:
:2:12: error: parameter 'n' has just a forward declaration
2 | void f(int n; int (*(*b)(void))[n]) { sizeof(*(*b)(); int n, int n; int
(*(*b)(void))[n]) { sizeof(*(*b)()); }
  |^
: In function 'f':
:2:53: error: expected ')' before ';' token
2 | void f(int n; int (*(*b)(void))[n]) { sizeof(*(*b)(); int n, int n; int
(*(*b)(void))[n]) { sizeof(*(*b)()); }
  | ~   ^
  | )
:2:90: error: expected ';' before '{' token
2 | void f(int n; int (*(*b)(void))[n]) { sizeof(*(*b)(); int n, int n; int
(*(*b)(void))[n]) { sizeof(*(*b)()); }
  |
 ^~
  |
 ;
: In function 'g':
:6:22: error: 'a' undeclared (first use in this function)
6 | void g(void) { f(1, &a); }
  |  ^
:6:22: note: each undeclared identifier is reported only once for each
function it appears in
:6:18: error: passing argument 1 of 'f' makes pointer from integer
without a cast [-Wint-conversion]
6 | void g(void) { f(1, &a); }
  |  ^
  |  |
  |  int
:2:23: note: expected 'int (* (*)(void))[n]' but argument is of type
'int'
2 | void f(int n; int (*(*b)(void))[n]) { sizeof(*(*b)(); int n, int n; int
(*(*b)(void))[n]) { sizeof(*(*b)()); }
  |   ^~~~
:6:16: error: too many arguments to function 'f'; expected 1, have 2
6 | void g(void) { f(1, &a); }
  |^~~
:2:6: note: declared here
2 | void f(int n; int (*(*b)(void))[n]) { sizeof(*(*b)(); int n, int n; int
(*(*b)(void))[n]) { sizeof(*(*b)()); }
  |  ^
: In function 'f':
:6:1: error: expected declaration or statement at end of input
6 | void g(void) { f(1, &a); }
  | ^~~~
:2:6: internal compiler error: Segmentation fault
2 | void f(int n; int (*(*b)(void))[n]) { sizeof(*(*b)(); int n, int n; int
(*(*b)(void))[n]) { sizeof(*(*b)()); }
  |  ^
0x253d385 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x255f066 internal_error(char const*, ...)
???:0
0xa45707 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
???:0
0x152b46c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xe26480 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
???:0
0xe2679e walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
???:0
0xe269d5 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
???:0
0xe2685d walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
???:0
0xe269d5 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
???:0
0x12641b8 lower_nested_functions(tree_node*)
???:0
0xc24894 cgraph_node::analyze()
???:0
0xc27e31 symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

[Bug target/121099] GCC doesn't optimize `_mm_set_ps()` very well

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #1 from LIU Hao  ---
Given `y` in XMM0 and `x` in XMM1, `_mm_set_ps(x, x, y, y)` is clearly just
`vshufps xmm2, xmm0, xmm1, 0` no matter what.

[Bug c/121101] New: ICE at O2: in copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1113

[bic60176 at gmail dot com via Gcc-bugs]

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

Bug ID: 121101
   Summary: ICE at O2: in copy_reference_ops_from_ref, at
tree-ssa-sccvn.cc:1113
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bic60176 at gmail dot com
  Target Milestone: ---

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

Compiler Explorer: https://godbolt.org/z/9abjbvbrn

console:
during GIMPLE pass: fre
: In function 'get_free':
:25:1: internal compiler error: in copy_reference_ops_from_ref, at
tree-ssa-sccvn.cc:1113
   25 | }
  | ^
0x253d385 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x255f066 internal_error(char const*, ...)
???:0
0xa011e4 fancy_abort(char const*, int, char const*)
???:0
0x13d1436 vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool, tree_node**, tree_node*, bool)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

[Bug c/121101] __builtin_assoc_barrier vs function types

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-07-16
  Component|tree-optimization   |c
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|ICE at O2: in   |__builtin_assoc_barrier vs
   |copy_reference_ops_from_ref |function types
   |, at tree-ssa-sccvn.cc:1113 |

--- Comment #1 from Andrew Pinski  ---
typedef void (*ftype)(void );
void f(void);
ftype get_free(void) { return __builtin_assoc_barrier(f); }

[Bug testsuite/121078] [16 regression] gcc.dg/aru-2.c etc. FAIL

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |WAITING

[Bug testsuite/121078] [16 regression] gcc.dg/aru-2.c etc. FAIL

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

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com
   Last reconfirmed||2025-07-16

--- Comment #1 from H.J. Lu  ---
Please try

https://patchwork.sourceware.org/project/gcc/list/?series=49715

[Bug c/121106] New: ICE at O2: in expand_fn_using_insn, at internal-fn.cc:268

[bic60176 at gmail dot com via Gcc-bugs]

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

Bug ID: 121106
   Summary: ICE at O2: in expand_fn_using_insn, at
internal-fn.cc:268
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bic60176 at gmail dot com
  Target Milestone: ---

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

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

console:
during RTL pass: expand
: In function 'bar.avx':
:2:82: internal compiler error: in expand_fn_using_insn, at
internal-fn.cc:268
2 | int __attribute__((target_clones("default,avx"))) bar(unsigned short x)
{ return __builtin_parityll(x); }
  |
 ^
0x253d385 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x255f066 internal_error(char const*, ...)
???:0
0xa011e4 fancy_abort(char const*, int, char const*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

[Bug c/121107] New: ICE at O2: in try_make_edge_direct_simple_call, at ipa-prop.cc:4052

[bic60176 at gmail dot com via Gcc-bugs]

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

Bug ID: 121107
   Summary: ICE at O2: in try_make_edge_direct_simple_call, at
ipa-prop.cc:4052
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bic60176 at gmail dot com
  Target Milestone: ---

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

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

console:
during IPA pass: inline
:14:1: internal compiler error: in try_make_edge_direct_simple_call, at
ipa-prop.cc:4052
   14 | void emit_insn_after_noloc(void) {
emit_pattern_after_noloc(make_insn_raw); }
  | ^~~~
0x253d385 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x255f066 internal_error(char const*, ...)
???:0
0xa011e4 fancy_abort(char const*, int, char const*)
???:0
0xf13fc3 ipa_propagate_indirect_call_infos(cgraph_edge*, vec*)
???:0
0xedcfac inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

[Bug target/121108] New: [16 Regression] ICE: in setmem_epilogue_gen_val, at config/i386/i386-expand.cc:8438 with -mstringop-strategy=rep_4byte

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 121108
   Summary: [16 Regression] ICE: in setmem_epilogue_gen_val, at
config/i386/i386-expand.cc:8438 with
-mstringop-strategy=rep_4byte
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -mstringop-strategy=rep_4byte testcase.c 
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:2:14: internal compiler error: in setmem_epilogue_gen_val, at
config/i386/i386-expand.cc:8438
2 | void foo() { __builtin_memset(x, 0, 847); }
  |  ^~~
0x2b98781 internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:517
0xe053ff fancy_abort(char const*, int, char const*)
/repo/gcc-trunk/gcc/diagnostic.cc:1818
0x951e79 setmem_epilogue_gen_val
/repo/gcc-trunk/gcc/config/i386/i386-expand.cc:8438
0x110d67e op_by_pieces_d::run()
/repo/gcc-trunk/gcc/expr.cc:1530
0x110dd38 store_by_pieces(rtx_def*, unsigned long, rtx_def* (*)(void*, void*,
long, fixed_size_mode), void*, unsigned int, bool, memop_ret)
/repo/gcc-trunk/gcc/expr.cc:1854
0x1b3f9f0 expand_setmem_epilogue
/repo/gcc-trunk/gcc/config/i386/i386-expand.cc:8493
0x1b3f9f0 ix86_expand_set_or_cpymem(rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, bool)
/repo/gcc-trunk/gcc/config/i386/i386-expand.cc:9940
0x2358581 gen_setmemsi(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*, rtx_def*, rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/config/i386/i386.md:26059
0x143a6d5 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*) const
/repo/gcc-trunk/gcc/recog.h:472
0x143a6d5 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
/repo/gcc-trunk/gcc/optabs.cc:8237
0x143f138 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/repo/gcc-trunk/gcc/optabs.cc:8257
0x110e706 set_storage_via_setmem(rtx_def*, rtx_def*, rtx_def*, unsigned int,
unsigned int, long, unsigned long, unsigned long, unsigned long)
/repo/gcc-trunk/gcc/expr.cc:4043
0x112414d clear_storage_hints(rtx_def*, rtx_def*, block_op_methods, unsigned
int, long, unsigned long, unsigned long, unsigned long, unsigned int)
/repo/gcc-trunk/gcc/expr.cc:3908
0xfa53f0 expand_builtin_memset_args
/repo/gcc-trunk/gcc/builtins.cc:4768
0xfad75c expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/repo/gcc-trunk/gcc/builtins.cc:8265
0x111b68e expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.cc:12535
0xfdc6c0 expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
/repo/gcc-trunk/gcc/expr.h:323
0xfdc6c0 expand_call_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:3204
0xfdc6c0 expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.cc:4276
0xfdc6c0 expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:4423
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.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-20250716055051-r16-2280-g32ff6f4728e402-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-20250716055051-r16-2280-g32ff6f4728e402-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250716 (experimental) (GCC)

[Bug middle-end/121106] [14/15/16 Regression] ICE at O2: in expand_fn_using_insn, at internal-fn.cc:268

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Known to fail||14.1.0
  Known to work||13.4.0
   Keywords||ice-on-valid-code
Summary|ICE at O2: in   |[14/15/16 Regression] ICE
   |expand_fn_using_insn, at|at O2: in
   |internal-fn.cc:268  |expand_fn_using_insn, at
   ||internal-fn.cc:268
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-07-16
   Target Milestone|--- |14.4

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

What is happening is without -mpopcnt, the paritydi2 pattern is enabled
So the builtin_parity is being turned into the internal function PARITY which
seems correct. But then target_clones comes along and clones the functions for
the target clones that include avx and avx turns on popcnt so the paritydi2
pattern is NOW disable but the internal function is there already ...

[Bug ipa/121107] [13/14/15/16 Regression] ICE at O2 (target_clone vs indirect inlining): in try_make_edge_direct_simple_call, at ipa-prop.cc:4052

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||12.1.0
   Last reconfirmed||2025-07-16
Summary|ICE at O2 (target_clone vs  |[13/14/15/16 Regression]
   |indirect inlining): in  |ICE at O2 (target_clone vs
   |try_make_edge_direct_simple |indirect inlining): in
   |_call, at ipa-prop.cc:4052  |try_make_edge_direct_simple
   ||_call, at ipa-prop.cc:4052
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to work||11.4.0
   Target Milestone|--- |13.5

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

[Bug target/121076] New: PPCLE: Inefficient implementation of __builtin_bswap16

[jens.seifert at de dot ibm.com via Gcc-bugs]

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

Bug ID: 121076
   Summary: PPCLE: Inefficient implementation of __builtin_bswap16
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.seifert at de dot ibm.com
  Target Milestone: ---

unsigned short swap(unsigned short in)
{
return __builtin_bswap16(in);
}

Returns:
swap(unsigned short):
rlwinm 10,3,8,16,23
rlwinm 9,3,24,24,31
or 9,9,10
rlwinm 3,9,0,0x
blr

Expected something like:
rotlwi  4, 3, 24
rlwimi 4, 3, 8, 0, 23
clrldi  3, 4, 48

[Bug c++/121083] New: internal compiler error: in process_init_constructor_record, at cp/typeck2.cc:1796 in 15.1 and trunk

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

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

Bug ID: 121083
   Summary: internal compiler error: in
process_init_constructor_record, at cp/typeck2.cc:1796
in 15.1 and trunk
   Product: gcc
   Version: 16.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: ---

ICE in:

Program

```
struct Xint
{
  int x;
  const int * y;
};

int main(){

const char * p;
Xint * p = new Xint[3] ({6,[2]=20});
}
```

Stack dump

```
:11:39: internal compiler error: in process_init_constructor_record, at
cp/typeck2.cc:1796
   11 | Xint * p = new Xint[3] ({6,[2]=20});
  |   ^
0x2879ca5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x289b986 internal_error(char const*, ...)
???:0
0xaf3494 fancy_abort(char const*, int, char const*)
???:0
0xc2b2b0 build_new(unsigned long, vec**,
tree_node*, tree_node*, vec**, int, int)
???:0
0xd20193 c_parse_file()
???:0
0xe8a449 c_common_parse_file()
???:0
```

To quickly reproduce:

https://godbolt.org/z/1fn1nh47q

[Bug gcov-profile/121084] New: [GCOV] Loops containing goto cause incorrect coverage statistics.

[njuwy at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 121084
   Summary: [GCOV] Loops containing goto cause incorrect coverage
statistics.
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: njuwy at smail dot nju.edu.cn
  Target Milestone: ---

gcc version:
gcc version 16.0.0 20250704 (experimental) (GCC) 

option:
--coverage -std=c2x

$ cat test.c
int main(void) {
int i = 0;
while (i < 2) {
++i;
if (i == 1) {
goto loop_start;
}
loop_start:
continue;
}
return 0;
}


$ cat test.c.gcov
3:1:int main(void) {
1:2:int i = 0;
3:3:while (i < 2) {
2:4:++i;
2:5:if (i == 1) {
1:6:goto loop_start;
-:7:}
1:8:loop_start:
2:9:continue;
-:   10:}
1:   11:return 0;
-:   12:}


cov of line 1 and line 8 should be 1 (main() was only executed once) and 2.
respectvely.

[Bug c++/121085] New: internal compiler error: Segmentation fault since 12.1

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

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

Bug ID: 121085
   Summary: internal compiler error: Segmentation fault since 12.1
   Product: gcc
   Version: 16.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: ---

ICE in:

Program:

```
#include 
int main()
{
  std::reference_wrapper e{};
}
```

Stack dump

```
/opt/compiler-explorer/gcc-trunk-20250715/include/c++/16.0.0/bits/refwrap.h:335:53:
internal compiler error: Segmentation fault
  335 | =
decltype(reference_wrapper::_S_fun(std::declval<_Up>()))>
  |   
~^
0x2879ca5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x289b986 internal_error(char const*, ...)
???:0
0xd556bd tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd55c14 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd841bc instantiate_class_template(tree_node*)
???:0
0xbc2b22 start_decl_1(tree_node*, bool)
???:0
0xbe3781 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
???:0
0xd20193 c_parse_file()
???:0
0xe8a449 c_common_parse_file()
???:0
```

To quickly reproduce:

https://godbolt.org/z/5hfeoT7f6

[Bug target/120941] [16 Regression] 24-40% slowdown of 519.lbm_r on Zen2 and 470.lbm on Zen5 since r16-1644-gaba3b9d3a48a07

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

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

--- Comment #24 from H.J. Lu  ---
(In reply to Filip Kastl from comment #23)
>  testcase.c 
> enum { ST, SB, ET, EB, WT, WB }
> LBM_initializeGrid() {
>   double *grid;
>   grid[ST] = grid[SB] = grid[ET] = grid[EB] =
>   grid[WT] = grid[WB] = 1.0 / 36.0;
> }
>  
> 
> Compile with -Ofast -march=znver2 -c -fdump-rtl-all.  In the dump, you
> should find:
> 
> 
> Replace:
>  
> (insn 5 2 7 2 (set (reg:V2DF 101)
> (vec_duplicate:V2DF (mem/u/c:DF (symbol_ref/u:DI ("*.LC1") [flags
> 0x2]) [0  S8 A64]))) "testcase.c":5:16 7168 {vec_dupv2df}
>  (expr_list:REG_EQUAL (const_vector:V2DF [
> (const_double:DF
> 2.7776235801354687282582744956016540527344e-2
> [0x0.e38e38e38e38ep-5]) repeated x2
> ])
> (nil)))
>  
> with:
>  
> (insn 5 2 7 2 (set (reg:V2DF 101)
> (subreg:V2DF (reg:V4DF 104) 0)) "testcase.c":5:16 2429
> {movv2df_internal}
>  (expr_list:REG_EQUAL (const_vector:V2DF [
> (const_double:DF
> 2.7776235801354687282582744956016540527344e-2
> [0x0.e38e38e38e38ep-5]) repeated x2
> ])
> (nil)))
>  
> deferring rescan insn with uid = 5.
>  
> Replace:
>  
> (insn 8 7 10 2 (set (reg:V4DF 103)
> (vec_duplicate:V4DF (mem/u/c:DF (symbol_ref/u:DI ("*.LC1") [flags
> 0x2]) [0  S8 A64]))) "testcase.c":4:12 9260 {vec_dupv4df}
>  (expr_list:REG_EQUAL (const_vector:V4DF [
> (const_double:DF
> 2.7776235801354687282582744956016540527344e-2
> [0x0.e38e38e38e38ep-5]) repeated x4
> ])
> (nil)))
>  
> with:
>  
> (insn 8 7 10 2 (set (reg:V4DF 103)
> (reg:V4DF 104)) "testcase.c":4:12 2428 {movv4df_internal}
>  (expr_list:REG_EQUAL (const_vector:V4DF [
> (const_double:DF
> 2.7776235801354687282582744956016540527344e-2
> [0x0.e38e38e38e38ep-5]) repeated x4
> ])
> (nil)))
> --
> 
> Works even on the current master (r16-2091-g20407a41e84044).  I got this
> from machine reducing the source files using cvise.

Why is it bad for znver2?

[Bug gcov-profile/121082] New: [GCOV] Anonymous structure initialization combined with return statement leads to incorrect coverage count

[njuwy at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 121082
   Summary: [GCOV] Anonymous structure initialization combined
with return statement leads to incorrect coverage
count
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: njuwy at smail dot nju.edu.cn
  Target Milestone: ---

gcc version:
gcc version 16.0.0 20250704 (experimental) (GCC) 

option:
--coverage -std=c2x

$ cat test.c
typedef struct {
float x;
float y;
} Point;
Point transform(Point a, Point b) {
return (Point){.x = a.x * 2 + b.x / 3,
   .y = b.y * 3 - a.y / 2,
};
}
int main() {
Point p1 = {1.5f, 2.0f};
Point p2 = {4.0f, 6.0f};
Point result1 = transform(p1, p2);
Point result2 = (Point){.x = p1.x * 2 + p2.x / 3,
.y = p2.y * 3 - p1.y / 2,
};
}


$ cat test.c.gcov
-:1:typedef struct {
-:2:float x;
-:3:float y;
-:4:} Point;
1:5:Point transform(Point a, Point b) {
2:6:return (Point){.x = a.x * 2 + b.x / 3,
1:7:   .y = b.y * 3 - a.y / 2,
-:8:};
-:9:}
1:   10:int main() {
1:   11:Point p1 = {1.5f, 2.0f};
1:   12:Point p2 = {4.0f, 6.0f};
1:   13:Point result1 = transform(p1, p2);
1:   14:Point result2 = (Point){.x = p1.x * 2 + p2.x / 3,
1:   15:.y = p2.y * 3 - p1.y / 2,
-:   16:};
-:   17:}


coverage statistics of line 6 and 14 should be consistent as 1.

[Bug target/120941] [16 Regression] 24-40% slowdown of 519.lbm_r on Zen2 and 470.lbm on Zen5 since r16-1644-gaba3b9d3a48a07

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

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

--- Comment #23 from Filip Kastl  ---
 testcase.c 
enum { ST, SB, ET, EB, WT, WB }
LBM_initializeGrid() {
  double *grid;
  grid[ST] = grid[SB] = grid[ET] = grid[EB] =
  grid[WT] = grid[WB] = 1.0 / 36.0;
}
 

Compile with -Ofast -march=znver2 -c -fdump-rtl-all.  In the dump, you should
find:


Replace:

(insn 5 2 7 2 (set (reg:V2DF 101)
(vec_duplicate:V2DF (mem/u/c:DF (symbol_ref/u:DI ("*.LC1") [flags 0x2])
[0  S8 A64]))) "testcase.c":5:16 7168 {vec_dupv2df}
 (expr_list:REG_EQUAL (const_vector:V2DF [
(const_double:DF
2.7776235801354687282582744956016540527344e-2
[0x0.e38e38e38e38ep-5]) repeated x2
])
(nil)))

with:

(insn 5 2 7 2 (set (reg:V2DF 101)
(subreg:V2DF (reg:V4DF 104) 0)) "testcase.c":5:16 2429
{movv2df_internal}
 (expr_list:REG_EQUAL (const_vector:V2DF [
(const_double:DF
2.7776235801354687282582744956016540527344e-2
[0x0.e38e38e38e38ep-5]) repeated x2
])
(nil)))

deferring rescan insn with uid = 5.

Replace:

(insn 8 7 10 2 (set (reg:V4DF 103)
(vec_duplicate:V4DF (mem/u/c:DF (symbol_ref/u:DI ("*.LC1") [flags 0x2])
[0  S8 A64]))) "testcase.c":4:12 9260 {vec_dupv4df}
 (expr_list:REG_EQUAL (const_vector:V4DF [
(const_double:DF
2.7776235801354687282582744956016540527344e-2
[0x0.e38e38e38e38ep-5]) repeated x4
])
(nil)))

with:

(insn 8 7 10 2 (set (reg:V4DF 103)
(reg:V4DF 104)) "testcase.c":4:12 2428 {movv4df_internal}
 (expr_list:REG_EQUAL (const_vector:V4DF [
(const_double:DF
2.7776235801354687282582744956016540527344e-2
[0x0.e38e38e38e38ep-5]) repeated x4
])
(nil)))
--

Works even on the current master (r16-2091-g20407a41e84044).  I got this from
machine reducing the source files using cvise.

[Bug middle-end/120614] 525.x264_r is ~30% slower with AutoFDO

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #20 from Jan Hubicka  ---
> We were also looking at the profile count issues with CSE/ICF like
> optimisations.
> https://lists.llvm.org/pipermail/llvm-dev/2020-November/146694.html looks like
> the way to go.

CSE should be safe if debug statements were working, since we optimize
out the code, but keep debug statement.  For my testing I am currently
disabling ICF.  I am not quite sure what to do about ICF optimized
functions. For direct calls they will show up as worng call targets with
-Wauto-profile.  Jakub extened dwarf to handle some replacements so
correct function show up which can be useful here, but to be able to
read back profile to pre-ICF code we would need to know right locations
that are lost at merging time.

I would first track easier issues and see how far we get.  We may have
-ffor-auto-profile which disables few auto-profile unfriendly
optimizations for example.

[Bug debug/121045] [16 Regression] FAIL: g++.dg/torture/pr58552.C caused by r16-2197-g385d9937f0e23c

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

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #2 from Rainer Orth  ---
On Solaris (both SPARC and x86, 32 and 64-bit), I also see

+FAIL: c-c++-common/torture/pr116156-1.c   -O1  (test for excess errors)
+FAIL: c-c++-common/torture/pr116156-1.c   -O2  (test for excess errors)
+FAIL: c-c++-common/torture/pr116156-1.c   -O2 -flto  (test for excess errors)
+FAIL: c-c++-common/torture/pr116156-1.c   -O2 -flto -flto-partition=none 
(test for excess errors)
+FAIL: c-c++-common/torture/pr116156-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
+FAIL: c-c++-common/torture/pr116156-1.c   -O3 -g  (test for excess errors)
+FAIL: c-c++-common/torture/pr116156-1.c   -Os  (test for excess errors)

with the same error.

[Bug target/120986] ICE when expanding svdot_lane_fpm intrinsic with compile time know FPMR

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

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

--- Comment #7 from Alex Coplan  ---
(In reply to Spencer Abson from comment #6)
> > The insn is recognised if +fp8dot4 is added, so I suspect the gating of 
> > this insn is also wrong in the backend.
> 
> Yeah, I suspect the issue is that:
> 
>   "TARGET_SSVE_FP8DOT4 && !(mode == VNx8HFmode &&
> !TARGET_SSVE_FP8DOT2)"
> 
> Relies on TARGET_SSVE_FPDOT2 implying TARGET_SSVE_FP8DOT4.  This is true
> architecturally, but was relaxed in
> https://inbox.sourceware.org/gcc-patches/7bcbb211-2658-f517-e189-
> a23e6b984...@e124511.cambridge.arm.com/.

Indeed, the relaxation was r15-7480-g299a8e2dc667e795991bc439d2cad5ea5bd379e2,
for the record.

[Bug libstdc++/96710] __int128 vs

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:57b9afc9dad76f529969c548214b65dfe43652a7

commit r16-2253-g57b9afc9dad76f529969c548214b65dfe43652a7
Author: Jonathan Wakely 
Date:   Fri May 16 13:33:23 2025 +0100

libstdc++: Ensure std::hash<__int128> is defined [PR96710]

This is a follow-up to r16-2190-g4faa42ac0dee2c which ensures that
std::hash is always enabled for signed and unsigned __int128. The
standard requires std::hash to be enabled for all arithmetic types.

libstdc++-v3/ChangeLog:

PR libstdc++/96710
* include/bits/functional_hash.h (hash<__int128>): Define for
strict modes.
(hash): Likewise.
* testsuite/20_util/hash/int128.cc: New test.

Reviewed-by: Tomasz KamiÅski 

[Bug libstdc++/121024] ranges::destroy and ranges::destroy_n do not end lifetime of trivial types

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r16-2256-ga63b663c7bf77e38d90cebe993a3de8a548f8d66
Author: Jonathan Wakely 
Date:   Thu Jul 10 14:12:44 2025 +0100

libstdc++: Ensure that ranges::destroy destroys in constexpr [PR121024]

The new test is currently marked as XFAIL because PR c++/102284 means
that GCC doesn't notice that the lifetimes have ended.

libstdc++-v3/ChangeLog:

PR libstdc++/121024
* include/bits/ranges_uninitialized.h (ranges::destroy): Do not
optimize away trivial destructors during constant evaluation.
(ranges::destroy_n): Likewise.
* testsuite/20_util/specialized_algorithms/destroy/121024.cc:
New test.

Reviewed-by: Tomasz KamiÅski 

[Bug c++/102284] Can access object outside of its lifetime during constant evaluation

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

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r16-2256-ga63b663c7bf77e38d90cebe993a3de8a548f8d66
Author: Jonathan Wakely 
Date:   Thu Jul 10 14:12:44 2025 +0100

libstdc++: Ensure that ranges::destroy destroys in constexpr [PR121024]

The new test is currently marked as XFAIL because PR c++/102284 means
that GCC doesn't notice that the lifetimes have ended.

libstdc++-v3/ChangeLog:

PR libstdc++/121024
* include/bits/ranges_uninitialized.h (ranges::destroy): Do not
optimize away trivial destructors during constant evaluation.
(ranges::destroy_n): Likewise.
* testsuite/20_util/specialized_algorithms/destroy/121024.cc:
New test.

Reviewed-by: Tomasz KamiÅski 

[Bug target/120941] [16 Regression] 24-40% slowdown of 519.lbm_r on Zen2 and 470.lbm on Zen5 since r16-1644-gaba3b9d3a48a07

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

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

--- Comment #25 from Filip Kastl  ---
(In reply to H.J. Lu from comment #24)
> Why is it bad for znver2?

Oh, I thought we are trying to figure that out.  Spilling because of register
pressure, as richi suggested in comment 3, is the best guess we currently have.

I'll see if I can confirm that there is some extra spilling.

[Bug middle-end/120614] 525.x264_r is ~30% slower with AutoFDO

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

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

--- Comment #19 from kugan at gcc dot gnu.org ---
I did the spec2017 runs few days ago and the .gcov files looks OK. I can see
them with dump_gcov.

I am seeing hot/cold blocks switched in __material_mod_MOD_mat_updatee/13 of
fotonik3d_r (see the values in comment 17). This looks odd.

We were also looking at the profile count issues with CSE/ICF like
optimisations.
https://lists.llvm.org/pipermail/llvm-dev/2020-November/146694.html looks like
the way to go.

[Bug c/121081] New: ICE on x86_64-linux-gnu: in composite_type, at c/c-typeck.cc:1011 with visibility attribute on atomic

[jiangchangwu at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 121081
   Summary: ICE on x86_64-linux-gnu: in composite_type, at
c/c-typeck.cc:1011 with visibility attribute on atomic
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiangchangwu at smail dot nju.edu.cn
  Target Milestone: ---

Compiler Explorer: https://gcc.godbolt.org/z/G1xooYr5v

***
gcc version:
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++ --prefix=/home/software/gcc-trunk --enable-coverage
--disable-werror --enable-checking=yes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 16.0.0 20250613 (experimental) (GCC)

***
Program:
$ cat mutant.c
int *_Atomic __attribute__((visibility(""))) a;
_Atomic(int *) a __attribute__(());

***
Command Lines:
$ gcc mutant.c
mutant.c:1:1: warning: 'visibility' attribute ignored on non-class types
[-Wattributes]
1 | int *_Atomic __attribute__((visibility(""))) a;
  | ^~~
mutant.c:2:1: internal compiler error: in composite_type, at c/c-typeck.cc:1011
2 | _Atomic(int *) a __attribute__(());
  | ^~~
0x5554b38 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x54d2d0a fancy_abort(char const*, int, char const*)
../../gcc/gcc/diagnostic.cc:1803
0xf55b93 composite_type(tree_node*, tree_node*)
../../gcc/gcc/c/c-typeck.cc:1011
0xee0751 merge_decls
../../gcc/gcc/c/c-decl.cc:2800
0xee4bf2 duplicate_decls
../../gcc/gcc/c/c-decl.cc:3187
0xee5e48 pushdecl(tree_node*)
../../gcc/gcc/c/c-decl.cc:3376
0xef1a66 start_decl(c_declarator*, c_declspecs*, bool, tree_node*, bool,
unsigned long*)
../../gcc/gcc/c/c-decl.cc:5755
0xff9933 c_parser_declaration_or_fndef
../../gcc/gcc/c/c-parser.cc:2957
0xff59fd c_parser_external_declaration
../../gcc/gcc/c/c-parser.cc:2155
0xff4ea2 c_parser_translation_unit
../../gcc/gcc/c/c-parser.cc:2009
0x10a17ee c_parse_file()
../../gcc/gcc/c/c-parser.cc:30153
0x11d7aeb c_common_parse_file()
../../gcc/gcc/c-family/c-opts.cc:1385
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.

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

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

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

--- Comment #10 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Andre Vehreschild
:

https://gcc.gnu.org/g:1cb95b3006dd615a03d3e4bade5605532c4ab65e

commit r15-9978-g1cb95b3006dd615a03d3e4bade5605532c4ab65e
Author: Andre Vehreschild 
Date:   Wed Jun 25 14:46:16 2025 +0200

Fortran: Ensure finalizers are created correctly [PR120637]

Finalize_component freeed an expression that it used to remember which
components in which context it had finalized already.  While it makes
sense to free the copy of the expression, if it is unused, it causes
issues, when comparing to a non existent expression. This is now
detected by returning true, when the expression has been used.

PR fortran/120637

gcc/fortran/ChangeLog:

* class.cc (finalize_component): Return true, when a finalizable
component was detect and do not free it.

gcc/testsuite/ChangeLog:

* gfortran.dg/asan/finalize_1.f90: New test.

(cherry picked from commit d1f05661fa6c8a6ea6f59ad365a84469100e425e)

[Bug c++/121086] New: Raw Segmentation fault with virtual static unsigned since version 3.4.6

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

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

Bug ID: 121086
   Summary: Raw Segmentation fault with virtual static unsigned
since version 3.4.6
   Product: gcc
   Version: 16.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: ---

ICE in:

Program

```
template 
inline int f(T a, T & b) {
union U {
virtual static unsigned int: 22;
};
}
```

Stack dump 

```
In function 'int f(T, T&)':
Segmentation fault
4 | virtual static unsigned int: 22;
  |  ^~
0x2879ca5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x289b986 internal_error(char const*, ...)
???:0
0x28dcfa3 pretty_printer::format(text_info&)
???:0
0x28797e6 diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x2879ca5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x289b380 error_at(rich_location*, char const*, ...)
???:0
0xbd7ed2 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
???:0
0xbfd70f grokbitfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
tree_node*, tree_node*)
???:0
0xd20193 c_parse_file()
???:0
0xe8a449 c_common_parse_file()
???:0
```

To quickly reproduce:

https://godbolt.org/z/sbhhshd16

[Bug c++/121087] New: internal compiler error: Segmentation fault initialize_vtbl_ptrs since 14.1

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

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

Bug ID: 121087
   Summary: internal compiler error: Segmentation fault
initialize_vtbl_ptrs since 14.1
   Product: gcc
   Version: 16.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: ---

ICE in:

Program

```
struct foo{
foo(const this&) : array{ 0 } {};
  };
```

Stack dump

```
:2:33: internal compiler error: Segmentation fault
2 | foo(const this&) : array{ 0 } {};
  | ^
0x2879ca5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x289b986 internal_error(char const*, ...)
???:0
0xc20905 initialize_vtbl_ptrs(tree_node*)
???:0
0xc2da3f emit_mem_initializers(tree_node*)
???:0
0xd20193 c_parse_file()
???:0
0xe8a449 c_common_parse_file()
???:0
```

To quickly reproduce:

https://godbolt.org/z/P3d87a65q

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

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #11 from Andre Vehreschild  ---
Backported to gcc-15.

[Bug target/121073] [16 Regression] RISC-V: ICE during RTL pass: avlprop insn does not satisfy its constraints

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

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

--- Comment #2 from Robin Dapp  ---
Yes, the issue is that Wdm was a memory constraint before, giving reload more
freedom.  In the case here we have a real mask operand that only the strided
alternatives support.  Need to think of another solution.

[Bug c++/121088] New: internal compiler error: Segmentation fault finish_static_data_member_decl since 12.1

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

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

Bug ID: 121088
   Summary: internal compiler error: Segmentation fault
finish_static_data_member_decl since 12.1
   Product: gcc
   Version: 16.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: ---

ICE maybe related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121085:

Program:

```
template 
struct PointerMutator1
{
template 
static
auto TestMemberAccess(U*) -> decltype(
(static_cast(0))->operator=(42)
);
static const auto Value = decltype(TestMemberAccess(0))::value;
};
int main() {
PointerMutator1::Value
}
```

Stack dump 

```
:10:65: internal compiler error: Segmentation fault
   10 | static const auto Value =
decltype(TestMemberAccess(0))::value;
  |~^~~
0x2879ca5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x289b986 internal_error(char const*, ...)
???:0
0xd556bd tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd782d9 instantiate_decl(tree_node*, bool, bool)
???:0
0xbf3387 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int,
cp_decomp*)
???:0
0xc03be3 finish_static_data_member_decl(tree_node*, tree_node*, bool,
tree_node*, int)
???:0
0xd845d8 instantiate_class_template(tree_node*)
???:0
0xd20193 c_parse_file()
???:0
0xe8a449 c_common_parse_file()
???:0
```

To quickly reproduce:

https://godbolt.org/z/rzq3Eqnrr

[Bug c++/121089] New: internal compiler error: Segmentation fault splay_tree_foreach since 13.1

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

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

Bug ID: 121089
   Summary: internal compiler error: Segmentation fault
splay_tree_foreach since 13.1
   Product: gcc
   Version: 16.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: ---

ICE in:

Program

```
#include 
enum class Mutation : auto
{
  kSwap = 0,
};
std::ostream& operator<<(std::ostream& os, const Mutation& mutation)
{
  switch (mutation) {
case Mutation::kSwap: return os << "kSwap";
  };
}
```

Stack dump

```
:10:3: internal compiler error: Segmentation fault
   10 |   };
  |   ^
0x2879ca5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x289b986 internal_error(char const*, ...)
???:0
0x29a7820 splay_tree_foreach
???:0
0xe56b88 c_switch_covers_all_cases_p(splay_tree_s*, tree_node*)
???:0
0xbc0ee3 pop_switch()
???:0
0xd9e180 finish_switch_stmt(tree_node*)
???:0
0xd20193 c_parse_file()
???:0
0xe8a449 c_common_parse_file()
???:0
```

To quickly reproduce:

https://godbolt.org/z/YecfzYMnh

[Bug c++/121090] New: internal compiler error: error reporting routines re-entered. diagnostic_context::finish() in 15.1 and trunk only

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

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

Bug ID: 121090
   Summary: internal compiler error: error reporting routines
re-entered. diagnostic_context::finish() in 15.1 and
trunk only
   Product: gcc
   Version: 16.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: ---

ICE in:

Program

```
#include 
#include 

class Rotter : public  std::vector, public std::string {

public:
Rotter() {
emplace_back([] { return 42; });
}
};
```

Stack dump

```
internal compiler error: error reporting routines re-entered.
0x2879b8e diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x2879ca5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x289b986 internal_error(char const*, ...)
???:0
0xaf3494 fancy_abort(char const*, int, char const*)
???:0
0x28790bb diagnostic_context::finish()
???:0
0x2879407 diagnostic_context::action_after_output(diagnostic_t)
???:0
0x2879a77 diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x2879ca5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x289b986 internal_error(char const*, ...)
???:0
0xaf3494 fancy_abort(char const*, int, char const*)
???:0
0xbb6612 cxx_pretty_printer::direct_abstract_declarator(tree_node*)
???:0
0xbb55c0 cxx_pretty_printer::type_id(tree_node*)
???:0
0xbb765e pp_cxx_parameter_mapping(cxx_pretty_printer*, tree_node*)
???:0
0xc172b3 maybe_print_single_constraint_context(diagnostic_text_output_format&,
tree_node*)
???:0
0x2899038 diagnostic_text_output_format::on_report_diagnostic(diagnostic_info
const&, diagnostic_t)
???:0
0x28797f6 diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x2879ca5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2899e5f inform(unsigned long, char const*, ...)
???:0
0xb82bf8 diagnose_constraints(unsigned long, tree_node*, tree_node*)
???:0
0xd812e4 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
```

To quickly reproduce:

https://godbolt.org/z/bKKonjKEc

[Bug c++/63164] unnecessary calls to __dynamic_cast

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

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

--- Comment #17 from Jason Merrill  ---
As I commented at

https://inbox.sourceware.org/gcc-patches/75ff8af8-af03-42fa-b68b-e6c16a34c...@redhat.com/

we could optimize the dynamic_cast to type_info::operator== instead of vtable
comparison.

[Bug c++/63164] unnecessary calls to __dynamic_cast

[tdebock at DRWUK dot com via Gcc-bugs]

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

--- Comment #18 from Thomas de Bock  ---
(In reply to Jason Merrill from comment #17)
> As I commented at
> 
> https://inbox.sourceware.org/gcc-patches/75ff8af8-af03-42fa-b68b-
> e6c16a34c...@redhat.com/
> 
> we could optimize the dynamic_cast to type_info::operator== instead of
> vtable comparison.

I agree having dynamic_cast be optimized to type_info::operator== when it can
(and when optimizations are enabled) would be good. Like I said though I also
think having an optimal optimization that just checks vtables ptrs is important
to have available behind some compiler flags as well.

[Bug debug/121093] New: Missed location of inlined function

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

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

Bug ID: 121093
   Summary: Missed location of inlined function
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

In this testcase
static int p1(int a)
{
return a+1;
}
static int p2(int a)
{
return a+2;
}
int p3 (int a)
{
return p1(p2(a));
}

We optimize the two additions into +3.   At optimized dump we have:

int p3 (int a)
{
  int _3;

   [local count: 1073741824]:
  [m.c:11:2] # DEBUG BEGIN_STMT
  [m.c:11:9] # DEBUG a => [m.c:7:10] a_2(D) + 2
  [m.c:1:12] # DEBUG INLINE_ENTRY p1
  [m.c:3:2] # DEBUG BEGIN_STMT
  [m.c:3:10] _3 = a_2(D) + 3;
  [m.c:11:9 discrim 1] # DEBUG a => NULL
  [m.c:11:9 discrim 3] return _3;

}


notice that p1 is present a INLINE_ENRY and corresponding debug stmt with
location m.c:3, but p2 is gone. It is taken away by clear_unused_block_pointer
since after combining the computations we no longer see an non-debug statement
associated with it.

auto-fdo would be happier if we output also location for m.c:7 and it would
make it possible to breakpoint in p2.

[Bug c++/63164] unnecessary calls to __dynamic_cast

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

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

--- Comment #19 from Jakub Jelinek  ---
(In reply to Jason Merrill from comment #17)
> As I commented at
> 
> https://inbox.sourceware.org/gcc-patches/75ff8af8-af03-42fa-b68b-
> e6c16a34c...@redhat.com/
> 
> we could optimize the dynamic_cast to type_info::operator== instead of
> vtable comparison.

That is what I was suggesting in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164#c12
Just I think one can use dynamic_cast even without including .
So, one possibility is only optimize if  has been included, another
is trying to do what it would otherwise do (the safer variant thereof) inline;
most likely not for -Os because it will be larger, maybe in both cases.  I
think even doing the slowest variant of operator== will be still much faster
than dynamic_cast.

[Bug target/121073] [16 Regression] RISC-V: ICE during RTL pass: avlprop insn does not satisfy its constraints

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

[Bug target/120986] ICE when expanding svdot_lane_fpm intrinsic with compile time know FPMR

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

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

Alex Coplan  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #8 from Alex Coplan  ---
Patches posted:
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689613.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689614.html

[Bug c++/88982] ICE in tsubst_pack_expansion, at cp/pt.c:12221

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

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

--- Comment #6 from MARIO RODRIGUEZ BEJAR  ---
Shall i open a separate bug?

[Bug target/121075] [16 Regression] RISC-V: ICE during GIMPLE pass: vect segmentation fault with -flto

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed with -O3 -march=rv64gcv  -fwrapv -fwhole-program -fsigned-char

(gdb) p *rgc
$9 = {max_nscalars_per_iter = 0, factor = 0, type = , compare_type =
, controls = {m_vec = 0x6279750 = {0x76c46dc8}}, 
  bias_adjusted_ctrl = }
(gdb) p debug_tree (0x76c46dc8)
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76e4a1f8 precision:64 min  max >

def_stmt GIMPLE_NOP
version:102>

so something goes wrong with the rgroup_controls.  The 2nd one would be

(gdb) p (*(*controls).m_vec)[1]
$15 = (rgroup_controls &) @0x6268f60: {max_nscalars_per_iter = 1, factor = 1,
type = , compare_type = , controls = {
m_vec = 0x627acd0 = {0x76c46948, 0x76c46990}}, bias_adjusted_ctrl =
}

which at least has a type.  I guess vect_verify_loop_lens should have rejected
this, but that doesn't look at the controls at all.

[Bug tree-optimization/121091] ICE in tree_to_uhwi, at tree.cc:6660 with SVE switch choosing predicate values

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

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

--- Comment #2 from Andrew Pinski  ---
  # pg_3 = PHI 


So not a POLY_INT_CST but rather a VECTOR_CST that does not have a constant
size.

[Bug libstdc++/108409] std::chrono::current_zone() doesn't work on AIX

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Target|*-*aix* *-*-mingw*  |*-*aix*
Summary|std::chrono::current_zone() |std::chrono::current_zone()
   |doesn't work on AIX or  |doesn't work on AIX
   |Windows |

--- Comment #9 from Jonathan Wakely  ---
It should work for Windows now

[Bug target/120986] ICE when expanding svdot_lane_fpm intrinsic with compile time know FPMR

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

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

--- Comment #9 from Alex Coplan  ---
I'm now going to be away until Mon 4th August, so won't be able to post the
re-spun patches until then (although they are ready to go and have passed
testing).

[Bug libstdc++/121097] hypot uses __promoted_t even when __cpp_fold_expressions is not defined

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #6 from Jonathan Wakely  ---
Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689674.html

[Bug c++/121086] anonymous static virtual bitfield causes ICE while printing out diagnostic

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

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

--- Comment #2 from Andrew Pinski  ---
So I think it is trying to print out the field name but since this is an
anonymous bitfield, it is crashing.

[Bug c++/121083] internal compiler error: in process_init_constructor_record, at cp/typeck2.cc:1796 in 15.1 and trunk

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

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

--- Comment #1 from Andrew Pinski  ---
Reduced:
```
struct Xint
{
  int x;
};
auto x = new Xint[3]({[0]=20});
```

[Bug c++/121083] [13/14/15/16 Regression] internal compiler error: in process_init_constructor_record, at cp/typeck2.cc:1796 with -std=c++20

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
 Ever confirmed|0   |1
Summary|internal compiler error: in |[13/14/15/16 Regression]
   |process_init_constructor_re |internal compiler error: in
   |cord, at cp/typeck2.cc:1796 |process_init_constructor_re
   |in 15.1 and trunk with  |cord, at cp/typeck2.cc:1796
   |-std=c++20  |with -std=c++20
  Known to fail||11.1.0, 14.3.0
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |13.5
   Last reconfirmed||2025-07-15

--- Comment #2 from Andrew Pinski  ---
GCC 10 and before had:
:5:30: error: parenthesized initializer in array new

My testcase has no errors before the ICE.

[Bug c++/121086] anonymous static virtual bitfield causes ICE while printing out diagnostic

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||3.4.6
   Last reconfirmed||2025-07-15
   Keywords||diagnostic
Summary|Raw Segmentation fault with |anonymous static virtual
   |virtual static unsigned |bitfield causes ICE while
   |since version 3.4.6 |printing out diagnostic
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed. Reduced down to:
```
struct U {
  virtual static int :0;
};
```

[Bug c/44677] Warn for variables incremented but not used (+=, ++)

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

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

--- Comment #30 from Jakub Jelinek  ---
(In reply to Vincent Lefèvre from comment #28)
> It seems that to get -Wunused-but-set-parameter=3 implicitly, one needs
> -Wextra (contrary to -Wunused-but-set-variable=3). So the condition
> 
>   -Wunused or -Wall or -Wunused -Wextra or -Wall -Wextra
> 
> (which includes the -Wunused alone) seems to be valid only for the
> unused-but-set-variable case.

Sure, -Wunused-but-set-parameter* has always been only with -Wunused -Wextra
(where -Wunused is enabled by -Wall), while -Wunused-but-set-variable* just by
-Wunused.
Nothing changed on that.

The docs document that:
This @option{-Wunused-but-set-parameter=3} warning is also enabled by
@option{-Wunused} together with @option{-Wextra}.
vs.
This @option{-Wunused-but-set-variable=3} warning is also enabled by
@option{-Wunused}, which is enabled by @option{-Wall}.

[Bug c/44677] Warn for variables incremented but not used (+=, ++)

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

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

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

https://gcc.gnu.org/g:35b19980046fc57d9d6851b8f4349bd22de3fa03

commit r16-2270-g35b19980046fc57d9d6851b8f4349bd22de3fa03
Author: Jason Merrill 
Date:   Mon Jul 14 18:29:17 2025 -0400

c++: don't mark void exprs as read [PR44677]

In Jakub's patch for PR44677 he added code to prevent mark_exp_read on
e.g. (void)++i from marking i as read, but it seems to me that we can
generalize that to avoid looking any farther into any void expression;
you can't read a void value, and an explicit cast will have already called
mark_exp_read on its operand in convert_to_void.

For testing I added an assert to catch places where we were trying to mark
void expressions as read, and fix a few that it found.  But there were
several other places (such as check_return_expr) where we could have a void
expression but always calling mark_exp_read makes sense, so I dropped the
assert from the final commit.

PR c++/44677

gcc/cp/ChangeLog:

* cp-gimplify.cc (cp_fold) [CLEANUP_POINT_EXPR]: Don't force
rvalue.
[COMPOUND_EXPR]: Likewise.
* cvt.cc (convert_to_void): Call mark_exp_read later.
* expr.cc (mark_use): Turn off read_p for any void argument.
(mark_exp_read): Return early for void argument.

[Bug tree-optimization/121091] ICE in tree_to_uhwi, at tree.cc:6660 with SVE switch choosing predicate values

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

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

[Bug libstdc++/121097] hypot uses __promoted_t even when __cpp_fold_expressions is not defined

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Arthur O'Dwyer  ---
Er, PC-Lint 2.0 with a config file that *we* made to roughly emulate GCC 10,
apparently. I can't blame PC-Lint itself for the weird setting of these macros.
:)

[Bug libstdc++/121097] hypot uses __promoted_t even when __cpp_fold_expressions is not defined

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

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

--- Comment #5 from Jonathan Wakely  ---
Sure, we could do, but I'm not convinced it's a real issue, only a hypothetical
one. Your config seems self-inflicted, due to an incomplete emulation of GCC 10
(which did define __cpp_fold_expressions).

[Bug tree-optimization/119921] ICE building SVE ACLE in varasm with switch

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #7 from Andrew Pinski  ---
So I just noticed this bug report after posting a patch to fix PR 121091. Since
there is a patch for the other one closing this one as a dup.

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

[Bug libstdc++/121097] New: hypot uses __promoted_t even when __cpp_fold_expressions is not defined

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Bug ID: 121097
   Summary: hypot uses __promoted_t even when
__cpp_fold_expressions is not defined
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

libstdc++'s  defines __gnu_cxx::__promoted_t if and only if
__cpp_fold_expressions is defined by the compiler:

#if __cpp_fold_expressions
  template
using __promoted_t = decltype((typename __promote<_Tp>::__type(0) +
...));

But libstdc++'s  tries to use that functionality on all compilers whose
__cplusplus claims C++17 support:

#ifdef __cpp_lib_hypot // C++ >= 17 && HOSTED
[...]
  template
__gnu_cxx::__promoted_t<_Tp, _Up, _Vp>
hypot(_Tp __x, _Up __y, _Vp __z)

Therefore there is an obscure subset of compiler implementations -- those that
set __cplusplus to 201703 but don't define __cpp_fold_expressions -- for which
libstdc++'s  produces this error spew:

/usr/include/c++/11/cmath:1880 error 5649: no template named '__promoted_t' in 
namespace '__gnu_cxx'
/usr/include/c++/11/cmath:1883 error 5649: no template named '__promoted_t' in 
namespace '__gnu_cxx'
/usr/include/c++/11/cmath:1884 error 40: undeclared identifier '__type'

The example in front of me right now is PCLint 2.0 (November 2022). Now, we're
also stuck on libstdc++ 11.4, so we're going to have to work around this on our
end anyway (by manually -D__cpp_fold_expressions=201603 on our PC-Lint command
line). But IMHO you should still want to harmonize these macros on your end:
either define your __promoted_t more liberally in , or else
define the three-argument hypot() more conservatively in .

[Bug c++/120577] [14/15/16 Regression] Another crash with [[no_unique_address]] and constexpr functions

[nikolasklauser at berlin dot de via Gcc-bugs]

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

--- Comment #7 from Nikolas Klauser  ---
The patch fixes the non-reduced reproducer as well. Thanks!

[Bug rtl-optimization/121098] New: target macro HARDREG_PRE_REGNOS is NOT documented

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

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

Bug ID: 121098
   Summary: target macro HARDREG_PRE_REGNOS is NOT documented
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: documentation, internal-improvement
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: andrew.carlotti at arm dot com
  Target Milestone: ---

The target macro HARDREG_PRE_REGNOS in the internals manual was added with
r15-6789-ge7f98d9603808b but it was NOT documented.

I do think this should have been a target hook rather than a target macro. Even
the macro name should have started with TARGET_ :).

[Bug sarif-replay/120792] sarif-replay's sarif output doesn't faithfully round-trip all the data

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

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

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

https://gcc.gnu.org/g:2a521eee58da7c0d0f2262181b804aa148e60aaf

commit r16-2274-g2a521eee58da7c0d0f2262181b804aa148e60aaf
Author: David Malcolm 
Date:   Tue Jul 15 16:19:42 2025 -0400

libgdiagnostics: add diagnostic_message_buffer [PR120792]

This patch extends libgdiagnostics to provide a way to capture
the pp tokens making up a message string, so that SARIF and
HTML sinks can retain information such as event IDs and URLs.
As well as richer output, this improves the round-tripping of such
information through sarif-replay.

This also allows diagnostic messages to be built up in pieces,
with a drop-in replacement for fprintf, which I've found useful when
attempting to port "ld" to use libgdiagnostics.

gcc/ChangeLog:
PR sarif-replay/120792
* auto-obstack.h: New file, based on material taken from
pretty-print.cc.
* diagnostic-digraphs.h
(diagnostics::digraphs::digraph::set_description): New.
(diagnostics::digraphs::node::set_label): New.
* doc/libgdiagnostics/topics/compatibility.rst: Add
LIBGDIAGNOSTICS_ABI_4.
* doc/libgdiagnostics/topics/diagnostics.rst
(diagnostic_finish_via_msg_buf): Document new entrypoint.
* doc/libgdiagnostics/topics/execution-paths.rst
(diagnostic_execution_path_add_event_via_msg_buf): Document new
entrypoint.
* doc/libgdiagnostics/topics/index.rst: Add message-buffers.rst.
* doc/libgdiagnostics/topics/message-buffers.rst: New file.
* doc/libgdiagnostics/topics/message-formatting.rst: Add note
about message buffers.
* doc/libgdiagnostics/topics/physical-locations.rst
(diagnostic_add_location_with_label_via_msg_buf): Add.
* doc/libgdiagnostics/tutorial/07-execution-paths.rst: Link to
next section.
* doc/libgdiagnostics/tutorial/08-message-buffers.rst: New file.
* doc/libgdiagnostics/tutorial/index.rst: Add
08-message-buffers.rst.
* libgdiagnostics++.h (libgdiagnostics::message_buffer): New
class.
(libgdiagnostics::execution_path::add_event_via_msg_buf): New.
(libgdiagnostics::diagnostic::add_location_with_label): New.
(libgdiagnostics::diagnostic::finish_via_msg_buf): New.
(libgdiagnostics::graph::set_description): New overload.
(libgdiagnostics::graph::add_edge): New overload.
(libgdiagnostics::node::set_label): New overload.
* libgdiagnostics-private.h
(private_diagnostic_execution_path_add_event_2): Drop decl.
(private_diagnostic_execution_path_add_event_3): New decl.
* libgdiagnostics.cc:  Include "pretty-print-format-impl.h",
"pretty-print-markup.h", and "auto-obstack.h".
(class copying_token_printer): New.
(struct diagnostic_message_buffer): New.
(class pp_element_message_buffer): New.
(libgdiagnostics_path_event::libgdiagnostics_path_event): Replace
params "gmsgid" and "args" with "msg_buf".
(libgdiagnostics_path_event::print_desc): Reimplement using
pp_element_message_buffer to replay m_msg_buf into "pp".
(libgdiagnostics_path_event::m_desc_uncolored): Drop field.
(libgdiagnostics_path_event::m_desc_colored): Drop field.
(libgdiagnostics_path_event::msg_buf): New field.
(diagnostic_execution_path::add_event_va): Reimplement.
(diagnostic_execution_path::add_event_via_msg_buf): New.
(diagnostic::add_location_with_label): New overload, using
msg_buf.
(diagnostic_manager::emit): Reimplement with...
(diagnostic_manager::emit_va): ...this.
(diagnostic_manager::emit_msg_buf): New.
(FAIL_IF_NULL): Rename "p" to "ptr_arg".
(diagnostic_finish_va): Update to use diagnostic_manager::emit_va.
(diagnostic_graph::add_node_with_id): Rename "id" to "node_id".
(diagnostic_graph_add_node): Likewise.
(diagnostic_graph_add_edge): Rename "id" to "edge_id".
(diagnostic_graph_get_node_by_id): Rename "id" to "node_id".
(diagnostic_graph_get_edge_by_id): Rename "id" to "edge_id".
(private_diagnostic_execution_path_add_event_2): Delete.
(diagnostic_message_buffer_new): New public entrypoint.
(diagnostic_message_buffer_release): Likewise.
(diagnostic_message_buffer_append_str): Likewise.
(diagnostic_message_buffer_append_text): Likewise.
(diagnostic_message_buffer_append_byte): Likewise.
(diagnostic_message_buffer_append_

[Bug target/120941] [16 Regression] 24-40% slowdown of 519.lbm_r on Zen2 and 470.lbm on Zen5 since r16-1644-gaba3b9d3a48a07

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #26 from rguenther at suse dot de  ---
On Tue, 15 Jul 2025, pheeck at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
> 
> --- Comment #25 from Filip Kastl  ---
> (In reply to H.J. Lu from comment #24)
> > Why is it bad for znver2?
> 
> Oh, I thought we are trying to figure that out.  Spilling because of register
> pressure, as richi suggested in comment 3, is the best guess we currently 
> have.
> 
> I'll see if I can confirm that there is some extra spilling.

For the testcase you reduced to, sanitized a bit:

enum { ST, SB, ET, EB, WT, WB }
LBM_initializeGrid(double *grid) {
  grid[ST] = grid[SB] = grid[ET] = grid[EB] =
  grid[WT] = grid[WB] = 1.0 / 36.0;
}

this is

LBM_initializeGrid:
.LFB0:
.cfi_startproc
vmovddup.LC1(%rip), %xmm0
vmovupd %xmm0, 32(%rdi)
vbroadcastsd.LC1(%rip), %ymm0
vmovupd %ymm0, (%rdi)
vzeroupper
ret

vs.

LBM_initializeGrid:
.LFB0:
.cfi_startproc
vbroadcastsd.LC1(%rip), %ymm0
vmovupd %xmm0, 32(%rdi)
vmovupd %ymm0, (%rdi)
vzeroupper
ret

the latter (new) version is better.  I would expect that if the 
two uses are far apart you get extra spilling as I said.  I'd
have restricted the optimization to uses within a single basic block
for example.  If we'd have a tunable/--param for that you could
see if that helps the regressions.

[Bug target/120920] RISC-V: Possible optimization of bswap when zbb is enabled

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

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

--- Comment #2 from Jeffrey A. Law  ---
Dusan posted a patch here, but I'm not convinced it's correct.  Also note the
patch failed its own test:

https://patchwork.sourceware.org/project/gcc/patch/pr3pr08mb5738ed049e790435a3b5a8aebe...@pr3pr08mb5738.eurprd08.prod.outlook.com/

[Bug fortran/104428] [13/14/15/16 Regression] ICE in gfc_trans_omp_declare_variant, at fortran/trans-openmp.cc:7648 since r12-4409-g724ee5a0093da443

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Kwok Yeung :

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

commit r16-2263-ga05c4f4ee48f76e518dbd2a96e5083f4df833df7
Author: Kwok Cheung Yeung 
Date:   Tue Jul 15 15:26:26 2025 +0100

openmp, fortran: Fix ICE when the procedure name cannot be found in declare
variant directives [PR104428]

The result of searching for the procedure name symbol should be checked in
case the symbol cannot be found to avoid a null dereference.

gcc/fortran/

PR fortran/104428
* trans-openmp.cc (gfc_trans_omp_declare_variant): Check that
proc_st
is non-NULL before dereferencing.  Add line number to error
message.

gcc/testsuite/

PR fortran/104428
* gfortran.dg/gomp/pr104428.f90: New.

[Bug tree-optimization/121091] ICE in tree_to_uhwi, at tree.cc:6660 with SVE switch choosing predicate values

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||10.1.0, 10.5.0, 16.0

--- Comment #3 from Andrew Pinski  ---
The switch conversion pass was missed when SVE support was added.

[Bug c++/63164] unnecessary calls to __dynamic_cast

[tdebock at DRWUK dot com via Gcc-bugs]

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

--- Comment #16 from Thomas de Bock  ---
(In reply to Jakub Jelinek from comment #15)
> Sure, but that is the only way how to make the optimization reliable.
> If the a local type (i.e. mangled for RTTI with * character at the start),
> it can just do the name pointer comparison (or perhaps compare the type_info
> address?).
> Adding an optimization that works only sometimes doesn't look right.

Even with the implementation of the optimization comparing the type_info
addresses, it won't work for all cases. I don't see how the above explained
dlopen with RTLD_LOCAL case is any different for comparing type_info addresses
rather than vtable addresses, I believe this is why type_info::operator== falls
back to:
 return __name[0] != '*' && __builtin_strcmp (__name, __arg.name()) == 0;
after the comparison of type_info name ptrs fails. Substitution with
type_info::operator== may work in cases where RTTI is merged but vtables are
not, but this does not include the case where neither is merged, and with it
being slower than the vtable comparison, I believe substituting __dynamic_cast
with a vtable comparison is still something that should be available.

[Bug c/44677] Warn for variables incremented but not used (+=, ++)

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

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

--- Comment #27 from Jakub Jelinek  ---
Nothing changed in what options imply -Wunused-but-set-variable or
-Wunused-but-set-parameter, just that those 2 options now mean the =3 level and
users can explicitly use say -Wunused-but-set-variable=1 etc. to restore
previous behavior.