[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 #17 from kugan at gcc dot gnu.org ---
fotonik3d_r regresses -20% compared to base (no PGO).

Base perf
33.19%  fotonik3d_r_pea  fotonik3d_r_peak.mytest-64  [.]
leapfrog_.constprop.0
23.76%  fotonik3d_r_pea  fotonik3d_r_peak.mytest-64  [.]
__material_mod_MOD_mat_updatee
21.46%  fotonik3d_r_pea  fotonik3d_r_peak.mytest-64  [.]
__upml_mod_MOD_upml_updatee_simple
20.31%  fotonik3d_r_pea  fotonik3d_r_peak.mytest-64  [.]
__update_mod_MOD_updateh
 0.09%  fotonik3d_r_pea  fotonik3d_r_peak.mytest-64  [.]
__power_mod_MOD_power_interh.lto_priv.0


AutoFDP perf
32.48%  fotonik3d_r_pea  fotonik3d_r_peak.mytest-64  [.]
__material_mod_MOD_mat_updatee
30.12%  fotonik3d_r_pea  fotonik3d_r_peak.mytest-64  [.]
leapfrog_.constprop.0
21.09%  fotonik3d_r_pea  fotonik3d_r_peak.mytest-64  [.]
__upml_mod_MOD_upml_updatee_simple
15.38%  fotonik3d_r_pea  fotonik3d_r_peak.mytest-64  [.]
__update_mod_MOD_updateh


Here is __material_mod_MOD_mat_updatee profile diff
__material_mod_MOD_mat_updatee/13 bb 37 fdo 10604090 (hot) afdo 0 (auto FDO)
(cold) scaled 0 diff -10604090, -100.00%
__material_mod_MOD_mat_updatee/13 bb 36 fdo 10604090 (hot) afdo 0 (auto FDO)
(cold) scaled 0 diff -10604090, -100.00%
__material_mod_MOD_mat_updatee/13 bb 33 fdo 10604090 (hot) afdo 0 (auto FDO)
(cold) scaled 0 diff -10604090, -100.00%
__material_mod_MOD_mat_updatee/13 bb 22 fdo 89300 (cold) afdo 4600494 (auto
FDO) (hot) scaled 5214809 diff 5125509, +5739.65%
__material_mod_MOD_mat_updatee/13 bb 27 fdo 89110 (cold) afdo 151215 (auto FDO)
(hot) scaled 171407 diff 82297, +92.35%
__material_mod_MOD_mat_updatee/13 bb 26 fdo 89110 (cold) afdo 151215 (auto FDO)
(hot) scaled 171407 diff 82297, +92.35%
__material_mod_MOD_mat_updatee/13 bb 23 fdo 89110 (cold) afdo 1779 (auto FDO)
(cold) scaled 2017 diff -87093, -97.74%
__material_mod_MOD_mat_updatee/13 bb 4 fdo 22800 (cold) afdo 67602 (auto FDO)
(cold) scaled 76629 diff 53829, +236.09%
__material_mod_MOD_mat_updatee/13 bb 30 fdo 22800 (cold) afdo 22691145 (auto
FDO) (hot) scaled 25721148 diff 25698348, +112712.05%
__material_mod_MOD_mat_updatee/13 bb 13 fdo 22800 (cold) afdo 1165245 (auto
FDO) (hot) scaled 1320843 diff 1298043, +5693.17%
__material_mod_MOD_mat_updatee/13 bb 9 fdo 22610 (cold) afdo 26685 (auto FDO)
(cold) scaled 30248 diff 7638, +33.78%
__material_mod_MOD_mat_updatee/13 bb 8 fdo 22610 (cold) afdo 26705 (auto FDO)
(cold) scaled 30271 diff 7661, +33.88%
__material_mod_MOD_mat_updatee/13 bb 5 fdo 22610 (cold) afdo 40917 (auto FDO)
(cold) scaled 46381 diff 23771, +105.13%
__material_mod_MOD_mat_updatee/13 bb 39 fdo 22610 (cold) afdo 18092430 (auto
FDO) (hot) scaled 20508355 diff 20485745, +90604.80%
__material_mod_MOD_mat_updatee/13 bb 38 fdo 22610 (cold) afdo 18092430 (auto
FDO) (hot) scaled 20508355 diff 20485745, +90604.80%
__material_mod_MOD_mat_updatee/13 bb 31 fdo 22610 (cold) afdo 18092430 (auto
FDO) (hot) scaled 20508355 diff 20485745, +90604.80%
__material_mod_MOD_mat_updatee/13 bb 18 fdo 22610 (cold) afdo 40917 (auto FDO)
(cold) scaled 46381 diff 23771, +105.13%
__material_mod_MOD_mat_updatee/13 bb 17 fdo 22610 (cold) afdo 40917 (auto FDO)
(cold) scaled 46381 diff 23771, +105.13%
__material_mod_MOD_mat_updatee/13 bb 14 fdo 22610 (cold) afdo 40917 (auto FDO)
(cold) scaled 46381 diff 23771, +105.13%
__material_mod_MOD_mat_updatee/13 bb 41 fdo 190 (cold) afdo 0 (auto FDO) (cold)
scaled 0 diff -190, -100.00%
__material_mod_MOD_mat_updatee/13 bb 40 fdo 190 (cold) afdo 0 (auto FDO) (cold)
scaled 0 diff -190, -100.00%
__material_mod_MOD_mat_updatee/13 bb 3 fdo 190 (cold) afdo 40917 (auto FDO)
(cold) scaled 46381 diff 46191, +24311.05%
__material_mod_MOD_mat_updatee/13 bb 29 fdo 190 (cold) afdo 4598715 (auto FDO)
(hot) scaled 5212792 diff 5212602, +2743474.74%
__material_mod_MOD_mat_updatee/13 bb 28 fdo 190 (cold) afdo 4598715 (auto FDO)
(hot) scaled 5212792 diff 5212602, +2743474.74%
__material_mod_MOD_mat_updatee/13 bb 21 fdo 190 (cold) afdo 4449279 (auto FDO)
(hot) scaled 5043402 diff 5043212, +2654322.11%
__material_mod_MOD_mat_updatee/13 bb 20 fdo 190 (cold) afdo 4449279 (auto FDO)
(hot) scaled 5043402 diff 5043212, +2654322.11%
__material_mod_MOD_mat_updatee/13 bb 2 fdo 190 (cold) afdo 4463511 (auto FDO)
(hot) scaled 5059534 diff 5059344, +2662812.63%
__material_mod_MOD_mat_updatee/13 bb 19 fdo 190 (cold) afdo 1124328 (auto FDO)
(hot) scaled 1274462 diff 1274272, +670669.47%
__material_mod_MOD_mat_updatee/13 bb 12 fdo 190 (cold) afdo 1124328 (auto FDO)
(hot) scaled 1274462 diff 1274272, +670669.47%
__material_mod_MOD_mat_updatee/13 bb 11 fdo 190 (cold) afdo 4449279 (auto FDO)
(hot) scaled 5043402 diff 5043212, +2654322.11%
__material_mod_MOD_mat_updatee/13 bb 10 fdo 190 (cold) afdo 26685 (auto FDO)
(cold) scaled 30248 diff 30058, +15820.00%
__material_mod_MOD_mat_updatee/13 bb 1 fdo 190 (cold) afdo 0 (auto FDO) (cold)
scaled 0 diff -190, -100.00%
__material_mod_MOD_mat_updatee/13 bb 0 fdo 190 (cold

[Bug ipa/120987] [13/14/15/16 regression] gdb build with lto triggers use after free since r12-5541-g2cadaa1f134bec

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

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

--- Comment #24 from Tom de Vries  ---
Created attachment 61858
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61858&action=edit
debug patch

Using this patch (on top of current trunk), I get the following in
a-test-2.c.092i.inline:
...
Considering gdb_exception::gdb_exception(gdb_exception&&)/482 with 15 size
 to be inlined into void throw_exception(gdb_exception&&)/487 in test-2.c:28
 Estimated badness is -0.002532, frequency 1.00.
 Called 0 (precise) times
flags from gdb_exception::gdb_exception(gdb_exception&&)/482:  nothrow
flags from void throw_exception(gdb_exception&&)/487:  noreturn
merged flags for void throw_exception(gdb_exception&&)/487:  noreturn nothrow
IGNORE_STORES: 1
  Parm map:  -1 0
Updated mod-ref summary for void throw_exception(gdb_exception&&)/487
  loads:
  Base 0: alias set 0
Ref 0: alias set 0
  access: Parm 0 param offset:0 offset:0 size:64 max_size:128
  stores:
  Side effects
  Try dse
  parm 0 flags: no_direct_clobber no_direct_escape no_indirect_escape
...

Without the "Minor ipa-modref tweaks" change we have instead:
...
Considering gdb_exception::gdb_exception(gdb_exception&&)/482 with 15 size
 to be inlined into void throw_exception(gdb_exception&&)/487 in test-2.c:28
 Estimated badness is -0.002532, frequency 1.00.
 Called 0 (precise) times
flags from gdb_exception::gdb_exception(gdb_exception&&)/482:  nothrow
merged flags for void throw_exception(gdb_exception&&)/487:  nothrow
IGNORE_STORES: 0
  Parm map:  -1 0
Updated mod-ref summary for void throw_exception(gdb_exception&&)/487
  loads:
  Base 0: alias set 0
Ref 0: alias set 0
  access: Parm 0 param offset:0 offset:0 size:64 max_size:128
  stores:
Every base
  Side effects
  Nondeterministic
  Try dse
  parm 0 flags: no_direct_escape
... 

I think that the change that the commit brought is not unreasonable:
throw_exception is noreturn before inlining, and should be so after inlining.

It seems wrong to me that we propagate the nothrow flag from the gdb_exception
constructor to throw_exception.  That already happened before the commit.

[Bug target/120870] [16 regression] CPython miscompiled with preserve_none and CFLAGS="-O2 -march=znver2 -ggdb3"

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

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

--- Comment #18 from Sam James  ---
(In reply to H.J. Lu from comment #17)
> Created attachment 61837 [details]
> A patch
> 
> Please try this.  No idea why it works for me.

`./configure --with-tail-call-interp CFLAGS="-O2 -march=znver2 -ggdb3"` works
for me with that patch on trunk.

[Bug target/120870] [16 regression] CPython miscompiled with preserve_none and CFLAGS="-O2 -march=znver2 -ggdb3"

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

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

--- Comment #19 from Sam James  ---
(In reply to Sam James from comment #18)
> (In reply to H.J. Lu from comment #17)
> > Created attachment 61837 [details]
> > A patch
> > 
> > Please try this.  No idea why it works for me.
> 
> `./configure --with-tail-call-interp CFLAGS="-O2 -march=znver2 -ggdb3"`
> works for me with that patch on trunk.

Your 15 backport patch for preserve_none fails both with and without your
tuning patch, though.

I will spend a bit of time trying to get a testcase but the code is complex and
I'm not optimistic I will get one.

Ken Jin, do you have time to look?

You know the code a lot better than me trying to learn CPython internals very
quickly. Even a large standalone (single source file) executable testcase is
really helpful. If not (which is fine), I'll slowly start hacking chunks out of
it and pray.

[Bug bootstrap/119430] profiledbootstrap fails on armv7a-unknown-linux-gnueabhif (crashes in elists__append_elmt during stagefeedback)

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

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

--- Comment #20 from Sam James  ---
You're a star, it works! I'll try it in the usual packaging environment next.

[Bug libstdc++/121053] std::visit is not SFINAE-friendly

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

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

Tomasz Kamiński  changed:

   What|Removed |Added

 CC||tkaminsk at gcc dot gnu.org

--- Comment #3 from Jason Merrill  ---
The first form is SFINAE because computing its return type can fail; I don't
see anything that allows SFINAE for the second form, but perhaps I'm just
unfamiliar with library conventions.

--- Comment #4 from Tomasz Kamiński  ---
I believe that the following `Constrains`
https://eel.is/c++draft/variant#visit-2 implies that Variant has single
accessible `variant` specialization base.

[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 #16 from kugan at gcc dot gnu.org ---
I ran spec2017 again with recent gcc and SPE based autofdo (with local patches
to enable SPE based profiling support for autofdo tools). I am seeing following
compared PGO:

621.wrf_s -23%
549.fotonik3d_r -21%
525.x264_r -17%
644.nab_s -14%
603.bwaves_s -13%
625.x264_s -12%
623.xalancbmk_s -12%
600.perlbench_s -11%
500.perlbench_r -10%

[Bug libstdc++/121061] New: extents/mdspan constructor is ILL-FORMED for IntegrLike with mutable conversions

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

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

Bug ID: 121061
   Summary: extents/mdspan constructor is ILL-FORMED for
IntegrLike with mutable conversions
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkaminsk at gcc dot gnu.org
  Target Milestone: ---

For the following code:
```
template
class IntLike
{
public:
  explicit
  IntLike(int i)
  : _M_i(i)
  { }

  IntLike() = delete;
  IntLike(const IntLike&) = delete;
  IntLike(IntLike&&) = delete;

  const IntLike&
  operator=(const IntLike&) = delete;

  const IntLike&
  operator=(IntLike&&) = delete;

  constexpr
  operator int() const noexcept
requires (Const)
  { return _M_i; }

  constexpr
  operator int() noexcept
requires (!Const)
  { return _M_i; }

private:
  int _M_i;
};
```
The static assertion fails incorrectly: 
static_assert(!std::is_constructible_v,
std::array, 1>>);.
It should be eliminated by https://eel.is/c++draft/mdspan.extents#cons-9.1.

We emit the ill-formed error from corresponding cosntructor:
std::array, 1> a1{IntLike(1)};
std::extents e1(a1);

See: https://godbolt.org/z/6GnqnascY

[Bug target/120870] [16 regression] CPython miscompiled with preserve_none and CFLAGS="-O2 -march=znver2 -ggdb3"

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

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

--- Comment #20 from H.J. Lu  ---
(In reply to Sam James from comment #19)
> (In reply to Sam James from comment #18)
> > (In reply to H.J. Lu from comment #17)
> > > Created attachment 61837 [details]
> > > A patch
> > > 
> > > Please try this.  No idea why it works for me.
> > 
> > `./configure --with-tail-call-interp CFLAGS="-O2 -march=znver2 -ggdb3"`
> > works for me with that patch on trunk.
> 
> Your 15 backport patch for preserve_none fails both with and without your
> tuning patch, though.
> 

Does it fail only with -march=znver2? It may be a latent bug.

[Bug libstdc++/121061] extents/mdspan constructor is ILL-FORMED for IntegrLike with mutable conversions

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

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

--- Comment #1 from Tomasz Kamiński  ---
This is due incorrect constrain on corresponding constructor:
   template<__mdspan::__valid_index_type _OIndexType, size_t _Nm>
requires (_Nm == rank() || _Nm == rank_dynamic())
constexpr explicit(_Nm != rank_dynamic())
extents(span<_OIndexType, _Nm> __exts) noexcept
: _M_exts(span(__exts))
{ }
We check `__mdspan::__valid_index_type<_OtherIndex, index_type>`, while we we
should check `__mdspan::__valid_index_type`,
i.e.:
  template
requires 
 __mdspan::__valid_index_type
 (_Nm == rank() || _Nm == rank_dynamic())
constexpr explicit(_Nm != rank_dynamic())
extents(span<_OIndexType, _Nm> __exts) noexcept
: _M_exts(span(__exts))
{ }
Similary for the array constructor, and the constructors of mdspan.

[Bug libstdc++/121061] extents/mdspan constructor is ILL-FORMED for IntegrLike with mutable conversions

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

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

Tomasz Kamiński  changed:

   What|Removed |Added

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

--- Comment #2 from Tomasz Kamiński  ---
Related to above, the following is ill-formed:
```
class IntLike
{
public:
  explicit
  IntLike(int i)
  : _M_i(i)
  { }


  constexpr
  operator int() && noexcept
  { return _M_i; }


private:
  int _M_i;
};


IntLike il(1);
static_assert(std::is_constructible_v,
IntLike>);
std::extents e1(std::move(il));
```
See: https://godbolt.org/z/hnd6zbde5

This is because, we do not move the index in constructor:
  template<__mdspan::__valid_index_type... _OIndexTypes>
requires (sizeof...(_OIndexTypes) == rank()
  || sizeof...(_OIndexTypes) == rank_dynamic())
constexpr explicit extents(_OIndexTypes... __exts) noexcept
: _M_exts(span(
initializer_list{_S_storage::_S_int_cast(__exts)...}))
{ }
`__exts` should be moved here, and _S_int_cast needs to be changed to be
forwarding.

This affects also operators() and mdspan/extents constructors.

[Bug ipa/120987] [13/14/15/16 regression] gdb build with lto triggers use after free since r12-5541-g2cadaa1f134bec

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #25 from rguenther at suse dot de  ---
On Sat, 12 Jul 2025, vries at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
> 
> --- Comment #22 from Tom de Vries  ---
> FYI, I've submitted a workaround for gdb that disables -fipa-modref for 
> release
> gcc 12.0 - 16.0 (
> https://sourceware.org/pipermail/gdb-patches/2025-July/219213.html ), assuming
> that his will be fixed in 16.1.

It's usually better to place a noipa attribute on a select function
where the issue shows up than disabling a whole pass which might
lead to other latent bugs pop up here and there given test coverage
with -fno-ipa-* or -fno-tree-* is very weak.

[Bug tree-optimization/121049] [16 regression] timezone-data miscompiled with -O3 -march=x86-64-v4 -mtune=znver4 since r16-2088-ge9079e4f43d135

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #11 from rguenther at suse dot de  ---
On Sun, 13 Jul 2025, sjames at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121049
> 
> --- Comment #9 from Sam James  ---
> Yes, I tried to go further but the compiler hangs with the needed param before
> that commit for a large part of the range.

Probably related to PR120927 then.

[Bug tree-optimization/121059] [15/16 regression] ICE when building imagemagick-7.1.1-47 (vect_get_loop_mask, at tree-vect-loop.cc:10960)

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #6 from rguenther at suse dot de  ---
On Mon, 14 Jul 2025, pinskia at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121059
> 
> Andrew Pinski  changed:
> 
>What|Removed |Added
> 
>  Ever confirmed|0   |1
>   Known to work||14.3.0
>  Status|UNCONFIRMED |NEW
>   Known to fail||15.1.0
>Last reconfirmed||2025-07-14
>Keywords||needs-bisection
> 
> --- Comment #5 from Andrew Pinski  ---
> (In reply to Sam James from comment #4)
> > (In reply to Sam James from comment #2)
> > > Created attachment 61857 [details]
> > > reduced.i
> > > 
> > > bisecting
> > 
> > r16-2088-ge9079e4f43d135 but given my luck with going back further in the
> > other bug, I won't bother here
> 
> `-O3 -march=x86-64-v4 --param vect-partial-vector-usage=1` ICEs for GCC 15.1.0
> also. But works in GCC 14.3.0.

It's good we get some more coverage for masked epilogue vect now, but
yeah - this was expected to some extent ...

[Bug target/121051] RVV intrinsics: unnecessary spilling and bad register allocation

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

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

--- Comment #1 from Andrew Pinski  ---
This looks like the normal subreg issue with the RA. There is a few others out
there ...

[Bug tree-optimization/121049] [16 regression] timezone-data miscompiled with -O3 -march=x86-64-v4 -mtune=znver4 since r16-2088-ge9079e4f43d135

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Sam James from comment #7)
> r16-2088-ge9079e4f43d135

This looks like it just exposed the issue with a costing model change in the
backend.

[Bug ada/121058] New: GNAT bug when identically named generic function instantiations return Implicit_Dereference types

[dennis at przytarski dot com via Gcc-bugs]

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

Bug ID: 121058
   Summary: GNAT bug when identically named generic function
instantiations return Implicit_Dereference types
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dennis at przytarski dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

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

When experimenting with the Implicit_Dereference aspect, I ran into the
following GNAT bug:

gnatmake: "" compilation error
+===GNAT BUG DETECTED==+
| 16.0.0 20250713 (experimental) (x86_64-linux-gnu) GCC error: |
| in build_component_ref, at ada/gcc-interface/utils2.cc:2314  |
| Error detected at example.adb:68:18  |

This bug occurs when multiple instantiations of a generic function with the
same name (here Get) return types that use the Implicit_Dereference aspect,
causing the compiler to crash when accessing values through these functions.
Renaming one of the instantiated functions avoids the crash.

The reproducer is rather lengthy.

[Bug tree-optimization/121049] [16 regression] timezone-data miscompiled with -O3 -march=x86-64-v4 -mtune=znver4 since r16-2088-ge9079e4f43d135

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

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

--- Comment #9 from Sam James  ---
Yes, I tried to go further but the compiler hangs with the needed param before
that commit for a large part of the range.

[Bug target/120866] [16 Regression] pdp11-aout, powerpc-ibm-aix7.1 and powerpc-ibm-aix7.2 crosscompilers fail to build

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug fortran/121043] [16 Regression] Tests of OpenCoarray fail to pass, works on 15.1.1 20250712

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

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #3 from Jerry DeLisle  ---
There are a series of patches involved here.

The first failure occurs at:

commit 1be1970f97d05a07851cd826132fcf466827ebe5
Author: Andre Vehreschild 
Date:   Fri Mar 14 14:20:18 2025 +0100

Fortran: Unify handling of STAT= and ERRMSG= optional arguments [PR87939]

The failure is:

  Start 23: sync_team
23/88 Test #23: sync_team
.***Failed  Required regular
expression not found. Regex=[Test passed.
]  0.47 sec

After the following patch, the tests hang ...

commit 8f4ee36bd5248cd244f65282167e3a13a3c98bc2
Author: Andre Vehreschild 
Date:   Mon Apr 7 09:36:24 2025 +0200

Fortran: Improve F2018 TEAM handling [PR87326, PR87556, PR88254, PR103896]

Improve the implementation of F2018 TEAM handling routines. Add
runtime-functions to caf_single to allow testing.

PR fortran/87326
PR fortran/87556
PR fortran/88254
PR fortran/103796

... here:

Test project /home/jerry/dev/opencoarrays-clean
  Start  1: initialize_mpi
 1/88 Test  #1: initialize_mpi   
Passed0.42 sec
  Start  2: register
 2/88 Test  #2: register ..  
Passed0.42 sec
  Start  3: register_vector
 3/88 Test  #3: register_vector ...  
Passed0.42 sec
  Start  4: register_alloc_vector
^Cmake: *** [Makefile:71: test] Interrupt

... and this blocks testing of the new -lcaf_shmem patches that are in review.

[Bug target/120866] [16 Regression] pdp11-aout, powerpc-ibm-aix7.1 and powerpc-ibm-aix7.2 crosscompilers fail to build since r16-1738

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

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

--- Comment #9 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:4d7baa94a48c27030c8ffcfaf3dd187be09903a9

commit r16-2221-g4d7baa94a48c27030c8ffcfaf3dd187be09903a9
Author: Andrew Pinski 
Date:   Sun Jul 13 11:56:03 2025 -0700

tree: Add include to tm_p.h to tree.cc [PR120866]

After r16-1738-g0337e3c2743ca0, a call to ASM_GENERATE_INTERNAL_LABEL
was done without including tm_p.h. This does not break most targets
as ASM_GENERATE_INTERNAL_LABEL macro function does not call target
specific functions from it; mostly just sprintf. It does however
break pdp11-aout and powerpc-aix* because those two call a target
specific function to do create the internal label.

Pushed as obvious after a build of gcc for pdp11-aout and x86_64-linux-gnu.

PR middle-end/120866
gcc/ChangeLog:

* tree.cc: Add include to tm_p.h.

Signed-off-by: Andrew Pinski 

[Bug c++/118904] [modules] ICE with std::source_location::current in inline function

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

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

Bug 120866 Summary: [16 Regression] pdp11-aout, powerpc-ibm-aix7.1 and 
powerpc-ibm-aix7.2 crosscompilers fail to build since r16-1738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120866

   What|Removed |Added

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

[Bug target/120866] [16 Regression] pdp11-aout, powerpc-ibm-aix7.1 and powerpc-ibm-aix7.2 crosscompilers fail to build since r16-1738

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
Fixed.

[Bug fortran/121043] [16 Regression] Tests of OpenCoarray fail to pass, works on 15.1.1 20250712

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

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

--- Comment #4 from Jerry DeLisle  ---
The log from the first failure:

23/88 Testing: sync_team
23/88 Test: sync_team
Command: "/usr/bin/bash" "/home/jerry/dev/opencoarrays-clean/bin/cafrun" "-np"
"8"
"/home/jerry/dev/opencoarrays-clean/bin/OpenCoarrays-2.10.2-32-g3d0fa68-tests/sync_team"
Directory: /home/jerry/dev/opencoarrays-clean
"sync_team" start time: Jul 13 11:13 PDT
Output:
--
OpenCoarrays internal error on image 1: SYNC TEAM called on team different from
current, or ancestor, or child
OpenCoarrays internal error on image 2: SYNC TEAM called on team different from
current, or ancestor, or child
OpenCoarrays internal error on image 2: SYNC TEAM called on team different from
current, or ancestor, or child
OpenCoarrays internal error on image 3: SYNC TEAM called on team different from
current, or ancestor, or child
OpenCoarrays internal error on image 4: SYNC TEAM called on team different from
current, or ancestor, or child
OpenCoarrays internal error on image 4: SYNC TEAM called on team different from
current, or ancestor, or child
OpenCoarrays internal error on image 1: SYNC TEAM called on team different from
current, or ancestor, or child
OpenCoarrays internal error on image 3: SYNC TEAM called on team different from
current, or ancestor, or child
Error: Command:
   `/usr/lib64/mpich/bin/mpiexec -n 8
/home/jerry/dev/opencoarrays-clean/bin/OpenCoarrays-2.10.2-32-g3d0fa68-tests/sync_team`
failed to run.

Test time =   0.47 sec
--
Test Fail Reason:
Required regular expression not found. Regex=[Test passed.
]
"sync_team" end time: Jul 13 11:13 PDT
"sync_team" time elapsed: 00:00:00
--

[Bug tree-optimization/121035] [15/16 Regression] ICE on valid code at -O{2,3} with "-fno-tree-dce -fno-tree-dse -fno-expensive-optimizations -fno-ssa-phiopt" on x86_64-linux-gnu: Segmentation fault

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

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

Andrew Pinski  changed:

   What|Removed |Added

Version|unknown |15.1.0
Summary|ICE on valid code at|[15/16 Regression] ICE on
   |-O{2,3} with "-fno-tree-dce |valid code at -O{2,3} with
   |-fno-tree-dse   |"-fno-tree-dce
   |-fno-expensive-optimization |-fno-tree-dse
   |s -fno-ssa-phiopt" on   |-fno-expensive-optimization
   |x86_64-linux-gnu:   |s -fno-ssa-phiopt" on
   |Segmentation fault  |x86_64-linux-gnu:
   ||Segmentation fault
   Target Milestone|--- |15.2

[Bug fortran/121043] [16 Regression] Tests of OpenCoarray fail to pass, works on 15.1.1 20250712

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

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

--- Comment #5 from Jerry DeLisle  ---
I assume the first failure was fixed by the second patch. There is no log entry
for that test. I had to terminate it. I have let it run for over 30 minutes
before doing so. 

The test is being run with two images and the source code courtesy OpenCoarrays
is:

register_alloc_vector.f90

program register3
  implicit none
  integer, parameter :: invalid_rank=-2
  integer :: np=invalid_rank,array_size=10
  integer,allocatable :: array(:)[:]

  np = num_images()
  allocate(array(array_size)[*],source=this_image())

  block
logical :: res = .true.
if(this_image() == 1) then
  if(size(array) /= array_size) error stop "Test failed."
endif
print *, this_image()
deallocate(array)

if(allocated(array)) error stop "Test failed."
if(this_image() == 1) print *,"Test passed."
  end block

end program

[Bug tree-optimization/121035] [15/16 Regression] ICE on valid code at -O{2,3} with "-fno-tree-dce -fno-tree-dse -fno-expensive-optimizations -fno-ssa-phiopt" on x86_64-linux-gnu: Segmentation fault

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/121035] [15/16 Regression] ICE on valid code at -O{2,3} with "-fno-tree-dce -fno-tree-dse -fno-expensive-optimizations -fno-ssa-phiopt" on x86_64-linux-gnu: Segmentation fault

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 61855
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61855&action=edit
gimple testcase

so don't need to depend on options; just -O2 -fgimple is enough to reproduce
it.

[Bug fortran/121043] [16 Regression] Tests of OpenCoarray fail to pass, works on 15.1.1 20250712

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

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

--- Comment #6 from Jerry DeLisle  ---
I narrowed it down.

I modified with some convenient prints:

program register3
  implicit none
  integer, parameter :: invalid_rank=-2
  integer :: np=invalid_rank,array_size=10
  integer,allocatable :: array(:)[:]

  np = num_images()
  allocate(array(array_size)[*],source=this_image())

  block
logical :: res = .true.
if(this_image() == 1) then
  if(size(array) /= array_size) error stop "Test failed."
endif
print *, this_image(), "before deallocate"
deallocate(array)
print *, this_image(), "after deallocate"

!if(allocated(array)) print *, "Test failed." ! It's hanging on the
'allocated'
if(this_image() == 1) print *,"Test passed."
  end block

end program

$ ../opencoarrays-clean/bin/caf register_alloc_vector.f90 
$ ../opencoarrays-clean/bin/cafrun -np 2 ./a.out 
   1 before deallocate
   2 before deallocate
   1 after deallocate
 Test passed.
   2 after deallocate

Uncomment that one line and it hangs.

[Bug target/111814] [SH] __builtin_nan* returns signalling NaNs instead of quiet NaNs and vice versa

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

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

--- Comment #16 from Matthias Klose  ---
the Debian SH porters asked about it. yes, I can backport it locally, but I'd
like to avoid it.

[Bug libstdc++/121052] New: Audit all uses of the nonnull attribute in libstdc++

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

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

Bug ID: 121052
   Summary: Audit all uses of the nonnull attribute in libstdc++
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Depends on: 110617
  Target Milestone: ---

Many of our uses of the nonnull attribute are probably bugs, e.g.

  polymorphic_allocator(memory_resource* __r) noexcept
  __attribute__((__nonnull__))
  : _M_resource(__r)
  { _GLIBCXX_DEBUG_ASSERT(__r); }

This debug assertion never fails in optimized builds, because the nonnull
attribute tells the compiler that __r is not null, so the assertion is
optimized out as dead code.

The attribute should be removed here, even though it gives useful diagnostic in
some cases.

Some uses are OK, e.g. polymorphic_allocator::deallocate:

  void
  deallocate(_Tp* __p, size_t __n) noexcept
  __attribute__((__nonnull__))
  { _M_resource->deallocate(__p, __n * sizeof(_Tp), alignof(_Tp)); }

I don't think the attribute affects codegen here, because we do the same thing
(call a virtual function) unconditionally. So the attribute might provide
useful warnings here, and does no harm.

Likewise for polymorphic_allocator::construct and
polymorphic_allocator::destroy:

  template
__attribute__((__nonnull__))
void
destroy(_Up* __p)
{ __p->~_Up(); }

If we supported Clang's diagnose_if attribute we would want to replace most
uses of nonnull with that (because they we would get warnings or even errors
when the compiler can prove there's a bug, but would not remove useful
assertions when the pointer value is not a compile-time constant).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110617
[Bug 110617] RFE: Add a diagnostic-only variant of nonnull attribute

[Bug middle-end/110617] RFE: Add a diagnostic-only variant of nonnull attribute

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79459
   Last reconfirmed||2025-07-13
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #13 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #2)
> >But sometimes we want only the effect for diagnostic,
> 
> I think that is a bad idea.

I disagree, it's needed.

In the C++ standard library there are loads of functions which have
preconditions on pointer arguments being non-null, so we put
__glibcxx_assert(ptr != nullptr) in the function body, e.g. the
polymorphinc_allocator(memory_resource*) constructor. This diagnoses undefined
behaviour and so helps users find bugs in their code.

But learning of those bugs during development is far better than aborting at
runtime after the code is deployed. So we have [[gnu::nonnull]] on that
constructor, so that users are warned at compile-time if they pass null
pointers. But now the assertion in the constructor body is optimized away,
because 

Users should not have to use -fisolate-erroneous-paths-attribute (which would
replace the __glibcxx_assert with a less descriptive trap) or
-fno-delete-null-pointer-checks (which pessimizes correct code, e.g. when using
the 'new' operator). Most users don't even know those options exist, nor that
they might be useful for libstdc++ code.

So libstdc++ just needs to remove the attribute, and users won't get warned at
compile time.

A diagnostic-only version of nonnull is wanted.

The diagnose_if attribute (Bug 79459) would be a more general solution that
would solve this problem.

[Bug c++/86878] G++ should warn about invalid alignments passed to allocation functions

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2024-01-09 00:00:00 |2025-7-13
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79459

--- Comment #4 from Jonathan Wakely  ---
I'll look at adopting Martin's prototype patch, but I'll also note that if we
supported Clang's diagnose_if attribute, then we could put that on the aligned
allocation functions to diagnose bad alignments.

I still think it would be better if that was implied by __alloc_align__ though.
If we're saying the value is an alignment, then it needs to be a valid
alignment. I can't see any situation where you would want to use
__alloc_align__ and not want to warn about passing bad values.

[Bug libstdc++/121053] New: std::visit is not SFINAE-friendly

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

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

Bug ID: 121053
   Summary: std::visit is not SFINAE-friendly
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

I don't think this is required by the standard, but it works for the std::visit
case, just not std::visit


#include 

template
concept visitable = requires(Visitor& vis, Variant& var) {
  std::visit(vis, var);
};

template
concept r_visitable = requires(Visitor& vis, Variant& var) {
  std::visit(vis, var);
};

struct visitor { template int operator()(const T&) { return 1; } };

struct AmbiguousBase : std::variant, std::variant {};


Compiled with -std=gnu++20:

static_assert( ! visitable );
static_assert( ! r_visitable );visit.cc:18:16:
error: static assertion failed
   18 | static_assert( ! r_visitable );
  |^~~

[Bug target/111814] [SH] __builtin_nan* returns signalling NaNs instead of quiet NaNs and vice versa

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

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

--- Comment #15 from Oleg Endo  ---
(In reply to Matthias Klose from comment #14)
> ping about the backport?

Is it urgent?

[Bug target/121051] New: RVV intrinsics: unnecessary spilling and bad register allocation

[camel-cdr at protonmail dot com via Gcc-bugs]

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

Bug ID: 121051
   Summary: RVV intrinsics: unnecessary spilling and bad register
allocation
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: camel-cdr at protonmail dot com
  Target Milestone: ---

GCC seems to have a lot of problems doing register allocation of RVV intrinsics
for slightly more complicated code.
I've noticed for quite some time now that GCC codegen for RVV intrinsics is
often a lot worse then LLVM, because it generates redundant spills and moves.

I now have a good code example to illustrate the problem:


vuint16m8_t
trans8x8_vslide(vuint16m8_t v)
{
size_t VL = __riscv_vsetvlmax_e64m4();
vbool16_t modd  = __riscv_vreinterpret_b16(
__riscv_vmv_v_x_u8m1(0b10101010,
__riscv_vsetvlmax_e8m1()));
vbool16_t meven = __riscv_vmnot(modd, VL);
vbool16_t m;

vuint64m4_t v4l = __riscv_vreinterpret_u64m4(__riscv_vget_u16m4(v, 0));
vuint64m4_t v4h = __riscv_vreinterpret_u64m4(__riscv_vget_u16m4(v, 1));
vuint64m4_t v4lt = v4l;
m = modd;
v4l = __riscv_vslide1up_mu(m, v4l, v4h, 0, VL);
m = meven;
v4h = __riscv_vslide1down_mu(m, v4h, v4lt, 0, VL);

vuint32m2_t v2ll = __riscv_vreinterpret_u32m2(__riscv_vget_u64m2(v4l,
0));
vuint32m2_t v2lh = __riscv_vreinterpret_u32m2(__riscv_vget_u64m2(v4l,
1));
vuint32m2_t v2hl = __riscv_vreinterpret_u32m2(__riscv_vget_u64m2(v4h,
0));
vuint32m2_t v2hh = __riscv_vreinterpret_u32m2(__riscv_vget_u64m2(v4h,
1));
vuint32m2_t v2llt = v2lh, v2hlt = v2hh;
v2lh = __riscv_vslide1down_mu(m, v2lh, v2ll, 0, VL);
v2hh = __riscv_vslide1down_mu(m, v2hh, v2hl, 0, VL);
m = modd;
v2ll = __riscv_vslide1up_mu(m, v2ll, v2llt, 0, VL);
v2hl = __riscv_vslide1up_mu(m, v2hl, v2hlt, 0, VL);

vuint16m1_t v1lll = __riscv_vreinterpret_u16m1(__riscv_vget_u32m1(v2ll,
0));
vuint16m1_t v1llh = __riscv_vreinterpret_u16m1(__riscv_vget_u32m1(v2ll,
1));
vuint16m1_t v1lhl = __riscv_vreinterpret_u16m1(__riscv_vget_u32m1(v2lh,
0));
vuint16m1_t v1lhh = __riscv_vreinterpret_u16m1(__riscv_vget_u32m1(v2lh,
1));
vuint16m1_t v1hll = __riscv_vreinterpret_u16m1(__riscv_vget_u32m1(v2hl,
0));
vuint16m1_t v1hlh = __riscv_vreinterpret_u16m1(__riscv_vget_u32m1(v2hl,
1));
vuint16m1_t v1hhl = __riscv_vreinterpret_u16m1(__riscv_vget_u32m1(v2hh,
0));
vuint16m1_t v1hhh = __riscv_vreinterpret_u16m1(__riscv_vget_u32m1(v2hh,
1));
vuint16m1_t v1lllt = v1lll, v1lhlt = v1lhl, v1hllt = v1hll, v1hhlt =
v1hhl;
v1lll = __riscv_vslide1up_mu(m, v1lll, v1llh, 0, VL);
v1lhl = __riscv_vslide1up_mu(m, v1lhl, v1lhh, 0, VL);
v1hll = __riscv_vslide1up_mu(m, v1hll, v1hlh, 0, VL);
v1hhl = __riscv_vslide1up_mu(m, v1hhl, v1hhh, 0, VL);
m = meven;
v1llh = __riscv_vslide1down_mu(m, v1llh, v1lllt, 0, VL);
v1lhh = __riscv_vslide1down_mu(m, v1lhh, v1lhlt, 0, VL);
v1hlh = __riscv_vslide1down_mu(m, v1hlh, v1hllt, 0, VL);
v1hhh = __riscv_vslide1down_mu(m, v1hhh, v1hhlt, 0, VL);

return __riscv_vcreate_v_u16m1_u16m8(
v1lll, v1llh, v1lhl, v1lhh,
v1hll, v1hlh, v1hhl, v1hhh);
}

The above code is a port of an assembly function that transposes 8x8 matrices
stored across 8 vector registers:
https://github.com/camel-cdr/rvv-bench/blob/65a8dec6f238a45f22b26d02638471bfe68461c5/bench/trans8x8.S.inc#L291

This seems to currently be the best method for implementing such a transpose,
GCC however fails to produce acceptable assembly code:
https://godbolt.org/z/KM7ejn9f9

It spills 12 vector registers, while the assembly version only clobbers 12
vector registers. There are also a lot of redundant moves and in total more
than
3x more instructions where generated (117 vs 32).

[Bug target/121047] Possible hardware issue with Raptor Lake processors for code that gcc may generate

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #3 from Xi Ruoyao  ---
(In reply to Thomas Koenig from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > This is most likely a won't fix. Do you if there is an errata issued for
> > this yet?
> 
> I haven't seen anything that addresses that. This may or may not be
> covered by
> 
> https://community.intel.com/t5/Blogs/Tech-Innovation/Client/Intel-Core-13th-
> and-14th-Gen-Desktop-Instability-Root-Cause/post/1633239
> 
> but this only talks about "instability", which can mean anything.

This one just wrecks havoc and GCC can do nothing, because we cannot prevent it
simply by avoiding some specific code pattern.  Still I don't know if you refer
to this one or a new hardware bug.

[Bug c++/86568] -Wnonnull warnings should highlight the relevant argument not the closing parenthesis

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2020-06-03 00:00:00 |2025-7-13

--- Comment #13 from Jonathan Wakely  ---
For the comment 0 testcase trunk prints this:

null.cc: In function 'int main()':
null.cc:9:4: warning: argument 2 null where non-null expected [-Wnonnull]
9 |   f(0, 0);
  |   ~^~
null.cc:1:6: note: in a call to function 'void f(void*, void*)' declared
'nonnull'
1 | void f(void*, void*) __attribute__((nonnull(2)));
  |  ^
null.cc:10:8: warning: argument 1 null where non-null expected [-Wnonnull]
   10 |   A().f(0, 0);
  |   ~^~
null.cc:4:8: note: in a call to function 'void A::f(void*, void*)' declared
'nonnull'
4 |   void f(void*, void*) __attribute__((nonnull(2)));
  |^


Which is ... different, I guess. It just highlights the entire function call
now, but still not the parameter.

[Bug target/111814] [SH] __builtin_nan* returns signalling NaNs instead of quiet NaNs and vice versa

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

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #14 from Matthias Klose  ---
ping about the backport?

[Bug target/120995] [15 regression] [RISC-V] ICE: unrecognizable insn UNSPEC_COMPARE_AND_SWAP with rv64gc_zabha_zacas

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Jeff Law :

https://gcc.gnu.org/g:8f93b00a241a242677a901812f1a12e8960a5dc2

commit r15-9962-g8f93b00a241a242677a901812f1a12e8960a5dc2
Author: Andreas Schwab 
Date:   Tue Jul 8 07:32:17 2025 -0600

[PATCH] riscv: allow zero in zacas subword atomic cas

gcc:
PR target/120995
* config/riscv/sync.md (zacas_atomic_cas_value_strong):
Allow op3 to be zero.

gcc/testsuite:
PR target/120995
* gcc.target/riscv/amo/zabha-zacas-atomic-cas.c: New test.

(cherry picked from commit 3fd638a9e5497dfdf00f1783d6e704af03fb44b0)

[Bug target/120995] [15 regression] [RISC-V] ICE: unrecognizable insn UNSPEC_COMPARE_AND_SWAP with rv64gc_zabha_zacas

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
Cherry-picked over to the gcc-15 branch which should resolve this issue there
too.

[Bug target/120763] [meta-bug] Tracker for bugs to visit during weekly RISC-V meeting

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

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

Bug 120995 Summary: [15 regression] [RISC-V] ICE: unrecognizable insn 
UNSPEC_COMPARE_AND_SWAP with rv64gc_zabha_zacas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120995

   What|Removed |Added

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

[Bug libstdc++/121054] New: std::bitset<0>("zero") should throw std::invalid_argument

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

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

Bug ID: 121054
   Summary: std::bitset<0>("zero") should throw
std::invalid_argument
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

The standard requires that all of the bitset constructors taking a string
check the whole string from [0,n) for invalid characters, not just the first N
characters.

So for bitset<0>("x") and bitset<1>("xx", 2) it should throw, but
bitset<1>("xx", 1) should not (because the 1 says to only use that many
characters from the string).

[Bug libstdc++/121052] Audit all uses of the nonnull attribute in libstdc++

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> Many of our uses of the nonnull attribute are probably bugs, e.g.
> 
>   polymorphic_allocator(memory_resource* __r) noexcept
>   __attribute__((__nonnull__))
>   : _M_resource(__r)
>   { _GLIBCXX_DEBUG_ASSERT(__r); }
> 
> This debug assertion never fails in optimized builds, because the nonnull
> attribute tells the compiler that __r is not null, so the assertion is
> optimized out as dead code.

Maybe my thinking here was that builds using _GLIBCXX_DEBUG are more likely to
be done with -O0 and in that case, the attribute would not remove the
assertion. So it can still find bugs in user code sometimes.

[Bug target/120356] [15 Regression] RISC-V: Miscompile at -O[23] since r15-6881-g7b815107f40

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

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Jeff Law :

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

commit r15-9963-gd8f2b4f1781ca02d3f74cc88467f97c2d68b471e
Author: Alexey Merzlyakov 
Date:   Wed Jul 2 11:29:00 2025 -0600

[PATCH] [RISC-V] Fix shift type for RVV interleaved stepped patterns
[PR120356]

It corrects the shift type of interleaved stepped patterns for const vector
expanding in LRA. The shift instruction was initially LSHIFTRT, and it
seems
still should be the same type for both LRA and other cases.

PR target/120356

gcc/ChangeLog:

* config/riscv/riscv-v.cc
(expand_const_vector_interleaved_stepped_npatterns):
Fix ASHIFT to LSHIFTRT insn.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr120356.c: New test.

(cherry picked from commit 9c1ed63e4c6b0f80dd47ce421dd7d80d52c38fd3)

[Bug target/120356] [15 Regression] RISC-V: Miscompile at -O[23] since r15-6881-g7b815107f40

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #10 from Jeffrey A. Law  ---
Cherry-picked after finding the right location for the change -- things got
refactored in the gcc-16 era so it required a bit of searching for the right
place to apply Alexey's change.

[Bug target/120763] [meta-bug] Tracker for bugs to visit during weekly RISC-V meeting

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

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

Bug 120356 Summary: [15 Regression] RISC-V: Miscompile at -O[23] since 
r15-6881-g7b815107f40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120356

   What|Removed |Added

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

[Bug c++/121055] New: [15/16 Regression] __is_invocable built-in doesn't match std::invoke for rvalue-ref qualified member function

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

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

Bug ID: 121055
   Summary: [15/16 Regression] __is_invocable built-in doesn't
match std::invoke for rvalue-ref qualified member
function
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

struct F
{
  void operator()() && { }
};

template
void test(T t)
{
  auto pmf = &T::operator();
  if constexpr (std::is_invocable_v>)
std::invoke(pmf, std::ref(t));
}

int main()
{
  F f;
  test(f);
}


This compiles successfully with GCC 14 or with Clang+libstdc++, but fails with
GCC 15 and GCC 16 because is_invocable_v uses the new __is_invocable built-in.
The GCC built-in incorrectly returns true, so we try to do the std::invoke
call, which is ill-formed:

invoke.cc: In instantiation of 'void test(T) [with T = F]':
invoke.cc:19:7:   required from here
   19 |   test(f);
  |   ^~~
invoke.cc:13:16: error: no matching function for call to 'invoke(void (F::*&)()
&&, std::reference_wrapper)'
   13 | std::invoke(pmf, std::ref(t));
  | ~~~^~
invoke.cc:13:16: note: there is 1 candidate
In file included from invoke.cc:1:
/home/jwakely/gcc/16/include/c++/16.0.0/functional:121:5: note: candidate 1:
'template std::invoke_result_t<_Callable,
_Args ...> std::invoke(_Callable&&, _Args&& ...)'
  121 | invoke(_Callable&& __fn, _Args&&... __args)
  | ^~
/home/jwakely/gcc/16/include/c++/16.0.0/functional:121:5: note: template
argument deduction/substitution failed:
In file included from /home/jwakely/gcc/16/include/c++/16.0.0/bits/move.h:37,
 from
/home/jwakely/gcc/16/include/c++/16.0.0/bits/stl_function.h:60,
 from /home/jwakely/gcc/16/include/c++/16.0.0/functional:51:
/home/jwakely/gcc/16/include/c++/16.0.0/type_traits: In substitution of
'template using std::invoke_result_t = typename
std::invoke_result::type [with _Fn = void (F::*&)() &&; _Args =
{std::reference_wrapper}]':
/home/jwakely/gcc/16/include/c++/16.0.0/functional:121:5:   required by
substitution of 'template
std::invoke_result_t<_Callable, _Args ...> std::invoke(_Callable&&, _Args&&
...) [with _Callable = void (F::*&)() &&; _Args = {std::reference_wrapper}]'
invoke.cc:13:16:   required from 'void test(T) [with T = F]'
   13 | std::invoke(pmf, std::ref(t));
  | ~~~^~
invoke.cc:19:7:   required from here
   19 |   test(f);
  |   ^~~
/home/jwakely/gcc/16/include/c++/16.0.0/type_traits:3360:11: error: no type
named 'type' in 'struct std::invoke_result >'
 3360 | using invoke_result_t = typename invoke_result<_Fn,
_Args...>::type;
  |   ^~~


The built-in should not say it's invocable.

[Bug libstdc++/121053] std::visit is not SFINAE-friendly

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jason Merrill  ---
Ah, because there's no constraint on

  template
constexpr _Res
visit(_Visitor&& __visitor, _Variants&&... __variants)

...which seems to conform to https://eel.is/c++draft/variant#visit
I'd think that making it SFINAE like the other form would require a change to
the standard.

[Bug libstdc++/121053] std::visit is not SFINAE-friendly

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

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

--- Comment #2 from Jonathan Wakely  ---
Neither form is constrained in the standard. With libstdc++ std::visit is
SFINAE-friendly and std::visit is not. With libc++ both are SFINAE-friendly.

[Bug tree-optimization/121059] New: [16 regression] ICE when building imagemagick-7.1.1-47 (vect_get_loop_mask, at tree-vect-loop.cc:10960)

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

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

Bug ID: 121059
   Summary: [16 regression] ICE when building imagemagick-7.1.1-47
(vect_get_loop_mask, at tree-vect-loop.cc:10960)
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 61856
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61856&action=edit
png_la-png.i.xz

```
$ gcc -c ./coders/.libs/png_la-png.i -O2 -march=znver4 -O3
during GIMPLE pass: vect
coders/png.c: In function ‘MngReadInfoFreeStruct.part.0.isra’:
coders/png.c:1417:21: internal compiler error: in vect_get_loop_mask, at
tree-vect-loop.cc:10960
 1417 | static MngReadInfo *MngReadInfoFreeStruct(MngReadInfo *mng_info)
  | ^
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
```

```

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/16/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/16
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/16/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/16/include/g++-v16
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/16/python
--enable-libphobos --enable-languages=c,c++,d,fortran,ada --enable-obsolete
--enable-secureplt --disable-werror --with-system-zlib --enable-nls
--without-included-gettext --disable-libunwind-exceptions
--enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo Hardened 16.0. p, commit
fe1f0199d8773ec7dffa4b7b7c26b1dd56cf6fd6' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-offload-defaulted
--enable-offload-targets=nvptx-none --enable-libgomp --disable-libssp
--enable-libada --enable-cet --disable-systemtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --without-isl
--enable-default-pie --enable-host-pie --enable-host-bind-now
--enable-default-ssp --disable-fixincludes
--with-gxx-libcxx-include-dir=/usr/include/c++/v1 --enable-linker-build-id
--with-build-config='bootstrap-O3 bootstrap-cet'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250712 (experimental)
f3186568d09c02a6d8915e43c0f5d7df704dfa0d (Gentoo Hardened 16.0. p, commit
fe1f0199d8773ec7dffa4b7b7c26b1dd56cf6fd6)
```

[Bug tree-optimization/121059] [16 regression] ICE when building imagemagick-7.1.1-47 (vect_get_loop_mask, at tree-vect-loop.cc:10960)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |16.0
 Target||X86_64
   Keywords||needs-bisection
 CC||pinskia at gcc dot gnu.org

[Bug tree-optimization/121059] [16 regression] ICE when building imagemagick-7.1.1-47 (vect_get_loop_mask, at tree-vect-loop.cc:10960)

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

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

--- Comment #1 from Sam James  ---
I'm reducing it.

[Bug tree-optimization/121059] [16 regression] ICE when building imagemagick-7.1.1-47 (vect_get_loop_mask, at tree-vect-loop.cc:10960)

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

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

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

bisecting

[Bug tree-optimization/121059] [16 regression] ICE when building imagemagick-7.1.1-47 (vect_get_loop_mask, at tree-vect-loop.cc:10960)

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

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

--- Comment #3 from Sam James  ---
(In reply to Sam James from comment #2)
> Created attachment 61857 [details]
> reduced.i
> 
> bisecting

with 
  char exists[256], frozen[256];
instead

[Bug tree-optimization/121059] [16 regression] ICE when building imagemagick-7.1.1-47 (vect_get_loop_mask, at tree-vect-loop.cc:10960) since r16-2088-ge9079e4f43d135

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

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

Sam James  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Keywords|needs-bisection |
Summary|[16 regression] ICE when|[16 regression] ICE when
   |building|building
   |imagemagick-7.1.1-47|imagemagick-7.1.1-47
   |(vect_get_loop_mask, at |(vect_get_loop_mask, at
   |tree-vect-loop.cc:10960)|tree-vect-loop.cc:10960)
   ||since
   ||r16-2088-ge9079e4f43d135

--- Comment #4 from Sam James  ---
(In reply to Sam James from comment #2)
> Created attachment 61857 [details]
> reduced.i
> 
> bisecting

r16-2088-ge9079e4f43d135 but given my luck with going back further in the other
bug, I won't bother here

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

[damian at archaeologic dot codes via Gcc-bugs]

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

Bug ID: 121060
   Summary: ICE when argument is associate name created from
type-bound operator result
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at archaeologic dot codes
  Target Milestone: ---

% cat all.f90 
module subdomain_m
  implicit none

  type subdomain_t 
real :: s_ = 0.
  contains
generic :: operator(.laplacian.) => laplacian
procedure laplacian
  end type

contains

  function laplacian(rhs)
class(subdomain_t), intent(in) :: rhs
type(subdomain_t) laplacian
  end function

end module

  use subdomain_m
  implicit none

  type operands_t
  end type

  type(subdomain_t) phi
  type(operands_t) operands

  associate(laplacian_phi => .laplacian. phi)
operands = approximates(laplacian_phi%s_)
  end associate

contains

  function approximates(actual)
real actual 
type(operands_t) approximates
  end function

end

% gfortran all.f90 
f951: internal compiler error: in matching_typebound_op, at
fortran/interface.cc:4763
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

% gfortran --version
GNU Fortran (Homebrew GCC 15.1.0) 15.1.0

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

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

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #1 from Jerry DeLisle  ---
Thankyou Damian for reducing this one. I can confirm it.

[Bug tree-optimization/121049] [16 regression] timezone-data miscompiled with -O3 -march=x86-64-v4 -mtune=znver4 since r16-2088-ge9079e4f43d135

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64

--- Comment #10 from Andrew Pinski  ---
Unlike the other one, `-O3 -march=x86-64-v4 --param
vect-partial-vector-usage=1` still works.

[Bug tree-optimization/121059] [16 regression] ICE when building imagemagick-7.1.1-47 (vect_get_loop_mask, at tree-vect-loop.cc:10960) since r16-2088-ge9079e4f43d135

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Known to work||14.3.0
 Status|UNCONFIRMED |NEW
  Known to fail||15.1.0
   Last reconfirmed||2025-07-14
   Keywords||needs-bisection

--- Comment #5 from Andrew Pinski  ---
(In reply to Sam James from comment #4)
> (In reply to Sam James from comment #2)
> > Created attachment 61857 [details]
> > reduced.i
> > 
> > bisecting
> 
> r16-2088-ge9079e4f43d135 but given my luck with going back further in the
> other bug, I won't bother here

`-O3 -march=x86-64-v4 --param vect-partial-vector-usage=1` ICEs for GCC 15.1.0
also. But works in GCC 14.3.0.

[Bug go/121050] New: 'check-gotools': 'Use -buildvcs=false to disable VCS stamping'

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

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

Bug ID: 121050
   Summary: 'check-gotools': 'Use -buildvcs=false to disable VCS
stamping'
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

I've recently done some changes in (some of) my GCC testing setup, and noticed
that when running 'check-gotools' in a container without Git installed, we
regress:

=== gotools Summary ===
# of expected passes[-415-]{+315+}
# of unexpected failures[-2-]{+75+}
# of untested testcases [-130-]{+85+}

... due to, 'build-gcc/gotools/gotools.log':

[...]
Running cmd/go ...
[...]
go: missing Git command. See https://golang.org/s/gogetcmd
error obtaining VCS status: exec: "git": executable file not found in $PATH
Use -buildvcs=false to disable VCS stamping.
FAIL: go test cmd/go
[...]

... etc.  Would it be OK to pass '-buildvcs=false', or do I need to install Git
just for this?

[Bug target/121047] Possible hardware issue with Raptor Lake processors for code that gcc may generate

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

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

--- Comment #2 from Thomas Koenig  ---
(In reply to Andrew Pinski from comment #1)
> This is most likely a won't fix. Do you if there is an errata issued for
> this yet?

I haven't seen anything that addresses that. This may or may not be
covered by

https://community.intel.com/t5/Blogs/Tech-Innovation/Client/Intel-Core-13th-and-14th-Gen-Desktop-Instability-Root-Cause/post/1633239

but this only talks about "instability", which can mean anything.

[Bug ipa/120987] [13/14/15/16 regression] gdb build with lto triggers use after free since r12-5541-g2cadaa1f134bec

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

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

--- Comment #23 from Sam James  ---
(In reply to Tom de Vries from comment #20)
> Seems to be fixed by:

I've regtested this and it was fine.