[Bug libstdc++/120305] Cannot create a std::vector from a std::ranges::transform_view.

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to aneris from comment #0)
> The code compiles correctly if you replace all the long unsigned with just
> unsigned though, which I find very peculiar, the code also compiles with
> gnu++20 as the standard.

An iota_view with unsigned elements (i.e. 32-bit integers) can use 64-bit
integer for the difference_type of its iterators.

An iota_view with unsigned long elements (i.e. 64-bit integers) must use
something wider than 64 bits for the difference_type of its iterators. The
C++20 standard allows that to be an integer type or an integer-like class type.

In strict standard-conforming mode, we do not use the non-standard __int128
type for iota_view iterators, so we use an integer-like class type.

The Cpp17InputIterator requirements do not allow an integer-like class type to
be used, which means that in strict conformance mode, an iota_view with 64-bit
elements has iterators which do not meet the Cpp17InputIterator requirements.

You should not be assuming that C++20 ranges can be used in code that expects
class STL-style iterators. C++20 iterators and classic STL-style iterators are
not fully compatible with each other.

[Bug libstdc++/120305] Cannot create a std::vector from a std::ranges::transform_view.

[aneris at disroot dot org via Gcc-bugs]

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

--- Comment #3 from aneris  ---
(In reply to Andrew Pinski from comment #2)
> The difference is int128_t support.

Could you elaborate a bit? I am afraid I don't follow.

[Bug libstdc++/120305] Cannot create a std::vector from a std::ranges::transform_view.

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

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

--- Comment #8 from Jonathan Wakely  ---
N.B. this has nothing to do with ranges::transform_view, the problem is
entirely due to iota_view

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1522r1.pdf has the
background on integer-like class types.

[Bug libstdc++/120259] Using Incomplete&& as argument in invoke_r/move_only_function fails to compile

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

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

--- Comment #4 from Tomasz Kamiński  ---
> I agree we should revert the static_assert for the swappable traits.

I am most concerned with is_invocable family here.

[Bug libstdc++/120305] Cannot create a std::vector from a std::ranges::transform_view.

[aneris at disroot dot org via Gcc-bugs]

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

--- Comment #9 from aneris  ---
Hmm, alright.

Thank you very much for your time.

[Bug c++/120306] New: Copy constructor with requires (!std::copy_constructible) is available

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 120306
   Summary: Copy constructor with requires
(!std::copy_constructible) is available
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

The following contradicting program
```
#include 

template 
struct S {
S() = default;
S(const S &) requires (!std::copy_constructible) {}
};

S u;
S v(u);

static_assert( !std::copy_constructible> );
```
is accepted starting from GCC 13, but fails in all other compilers. Online
demo: https://gcc.godbolt.org/z/qMWzjohnd

[Bug c++/120306] Copy constructor with requires (!std::copy_constructible) is available

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #2 from Richard Biener  ---
So clang says

error: incomplete type 'S' used in type trait expression

is that a required diagnostic or is it one of the "no diagnostic required"
cases?

[Bug preprocessor/119753] gcc -E is not POSIX-compliant

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #12 from Jonathan Wakely  ---
Suspending while OP's posix submission is processed:
https://www.austingroupbugs.net/bug_view_page.php?bug_id=1925

[Bug target/120304] SPARC lacks __float128 support

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Rainer Orth from comment #0)
> * I initially tried aliasing __float128 to _Float128, but that broke the
>   libstdc++ build:

Libstdc++ could be changed to handle it, but I don't think we want that.

In C++ the _FloatN types have special rules that prevent some implicit
conversions, which would break existing code that uses __float128 and expects
it to have the usual implicit conversions e.g. to double.

> 
> In file included from
> /vol/gcc/src/git/gcc-iains/libstdc++-v3/include/precompiled/stdc++.h:57:
> /var/gcc/cobol/11.4-gcc-64/sparcv9-sun-solaris2.11/libstdc++-v3/include/
> limits:2096:12: error: redefinition of ‘struct
> std::numeric_limits<_Float128>’
>  2096 | struct numeric_limits<__float128>
>   |^~
> 
>   So I went for aliasing long double instead, just like HP-UX/ia64.

And powerpc64le when using -mabi=ieeelongdouble, for which long double,
__float128 and __ieee128 are the same type (and with -mabi=ibmlongdouble only
__float128 and __ieee128 are the same type).

[Bug target/120304] SPARC lacks __float128 support

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> In C++ the _FloatN types have special rules that prevent some implicit
> conversions, which would break existing code that uses __float128 and
> expects it to have the usual implicit conversions e.g. to double.

e.g. converting __float128 to double always works, but converting _Float128 to
double gives a diagnostic:

warning: ISO C++ does not allow converting to ‘double’ from ‘_Float128’ with
greater conversion rank [-Wnarrowing]

So aliasing long double seems preferable.

[Bug fortran/120302] ICE in gfc_trans_call

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed for all versions since at least 7.

Workaround: move

use :: ivs, only : vs

in the second file from function to module level.

[Bug libstdc++/120315] std::format gcc 14 / 15 interop issue

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> >I got undefined behavior (segfault, missing output or exceptions) when using 
> >a gcc 14 compiled library with a gcc 15 compiled executable.
> 
> 
> Forward compatibility is not guaranteed; only backwards.

No, neither direction is supported for C++20 yet.

std::format is not ABI stable, and neither are any other C++20 features.

[Bug c++/120314] internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in decl_internal_context_p, at cp/tree.cc:3866 only in trunk and 15.1 with

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

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

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

[Bug c++/120314] internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in decl_internal_context_p, at cp/tree.cc:3866

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||13.1.0
   Last reconfirmed||2025-05-17
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

With my reduced testcase it ICEs further back.
Note starting in GCC 13.1.0 the ICE changes to:
:3:3: internal compiler error: tree check: expected tree that contains
'decl minimal' structure, have 'error_mark' in decl_internal_context_p, at
cp/tree.cc:3880


From:
:3:3: internal compiler error: tree check: expected tree that contains
'decl minimal' structure, have 'error_mark' in decl_anon_ns_mem_p, at
cp/tree.cc:3844

[Bug c++/105228] [12/13/14/15/16 Regression] ICE tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in decl_anon_ns_mem_p, at cp/tree.cc:3826 since r7-755-g23cb7266305

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

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

--- Comment #7 from Andrew Pinski  ---
Note starting in GCC 13 the ICE changes to:
:5:15: internal compiler error: tree check: expected tree that contains
'decl minimal' structure, have 'error_mark' in decl_internal_context_p, at
cp/tree.cc:3880

[Bug ipa/120307] ICE in combine_with_ipa_count_within, at profile-count.cc:410 during aarch64 -O3 profiledbootstrap

[mcccs at gmx dot com via Gcc-bugs]

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

--- Comment #2 from mcccs at gmx dot com ---
r16-101-g132d01d96ea9d6

[Bug preprocessor/119753] gcc -E is not POSIX-compliant

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

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

--- Comment #14 from Jonathan Wakely  ---
Isn't there a 30 day period for comments?

[Bug fortran/120099] [16 regression] gfortran.dg/specifics_1.f90 FAILs since r16-372-g064cac730f88dc

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

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #17 from Thomas Koenig  ---
(In reply to Andrew Pinski from comment #15)
> (In reply to anlauf from comment #14)
> > This fixes the reduced testcase for me, but gfortran.dg/specifics_1.f90
> > still fails here.
> 
> Which means there are many more intrinsics here that need this treatment.
> The testcase has just subroutine test_* calls in the "program" (main) in it
> which you can narrow down which ones are failing ones are failing.

The following tests fail (checked with a quick&dirty perl script):

  call test_c (conjg, (1.2,-4.), conjg((1.2,-4.)))
  call test_c (ccos, (1.2,-4.), ccos((1.2,-4.)))
  call test_c (cexp, (1.2,-4.), cexp((1.2,-4.)))
  call test_c (clog, (1.2,-4.), clog((1.2,-4.)))
  call test_c (csin, (1.2,-4.), csin((1.2,-4.)))
  call test_c (csqrt, (1.2,-4.), csqrt((1.2,-4.)))
  call test_z (dconjg, (1.2d0,-4.d0), dconjg((1.2d0,-4.d0)))
  call test_z (cdcos, (1.2d0,-4.d0), cdcos((1.2d0,-4.d0)))
  call test_z (zcos, (1.2d0,-4.d0), zcos((1.2d0,-4.d0)))
  call test_z (cdexp, (1.2d0,-4.d0), cdexp((1.2d0,-4.d0)))
  call test_z (zexp, (1.2d0,-4.d0), zexp((1.2d0,-4.d0)))
  call test_z (cdlog, (1.2d0,-4.d0), cdlog((1.2d0,-4.d0)))
  call test_z (zlog, (1.2d0,-4.d0), zlog((1.2d0,-4.d0)))
  call test_z (cdsin, (1.2d0,-4.d0), cdsin((1.2d0,-4.d0)))
  call test_z (zsin, (1.2d0,-4.d0), zsin((1.2d0,-4.d0)))
  call test_z (cdsqrt, (1.2d0,-4.d0), cdsqrt((1.2d0,-4.d0)))
  call test_z (zsqrt, (1.2d0,-4.d0), zsqrt((1.2d0,-4.d0)))

[Bug fortran/120099] [16 regression] gfortran.dg/specifics_1.f90 FAILs since r16-372-g064cac730f88dc

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

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

--- Comment #18 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #17)
> (In reply to Andrew Pinski from comment #15)
> > (In reply to anlauf from comment #14)
> > > This fixes the reduced testcase for me, but gfortran.dg/specifics_1.f90
> > > still fails here.
> > 
> > Which means there are many more intrinsics here that need this treatment.
> > The testcase has just subroutine test_* calls in the "program" (main) in it
> > which you can narrow down which ones are failing ones are failing.
> 
> The following tests fail (checked with a quick&dirty perl script):
> 
>   call test_c (conjg, (1.2,-4.), conjg((1.2,-4.)))
>   call test_c (ccos, (1.2,-4.), ccos((1.2,-4.)))
>   call test_c (cexp, (1.2,-4.), cexp((1.2,-4.)))
>   call test_c (clog, (1.2,-4.), clog((1.2,-4.)))
>   call test_c (csin, (1.2,-4.), csin((1.2,-4.)))
>   call test_c (csqrt, (1.2,-4.), csqrt((1.2,-4.)))
>   call test_z (dconjg, (1.2d0,-4.d0), dconjg((1.2d0,-4.d0)))
>   call test_z (cdcos, (1.2d0,-4.d0), cdcos((1.2d0,-4.d0)))
>   call test_z (zcos, (1.2d0,-4.d0), zcos((1.2d0,-4.d0)))
>   call test_z (cdexp, (1.2d0,-4.d0), cdexp((1.2d0,-4.d0)))
>   call test_z (zexp, (1.2d0,-4.d0), zexp((1.2d0,-4.d0)))
>   call test_z (cdlog, (1.2d0,-4.d0), cdlog((1.2d0,-4.d0)))
>   call test_z (zlog, (1.2d0,-4.d0), zlog((1.2d0,-4.d0)))
>   call test_z (cdsin, (1.2d0,-4.d0), cdsin((1.2d0,-4.d0)))
>   call test_z (zsin, (1.2d0,-4.d0), zsin((1.2d0,-4.d0)))
>   call test_z (cdsqrt, (1.2d0,-4.d0), cdsqrt((1.2d0,-4.d0)))
>   call test_z (zsqrt, (1.2d0,-4.d0), zsqrt((1.2d0,-4.d0)))

Isn't that the full list of intrinsics returning complex results?

[Bug fortran/120099] [16 regression] gfortran.dg/specifics_1.f90 FAILs since r16-372-g064cac730f88dc

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

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

--- Comment #19 from Andrew Pinski  ---
(In reply to anlauf from comment #18)
> (In reply to Thomas Koenig from comment #17)
> > (In reply to Andrew Pinski from comment #15)
> > > (In reply to anlauf from comment #14)
> > > > This fixes the reduced testcase for me, but gfortran.dg/specifics_1.f90
> > > > still fails here.
> > > 
> > > Which means there are many more intrinsics here that need this treatment.
> > > The testcase has just subroutine test_* calls in the "program" (main) in 
> > > it
> > > which you can narrow down which ones are failing ones are failing.
> > 
> > The following tests fail (checked with a quick&dirty perl script):
> > 
> >   call test_c (conjg, (1.2,-4.), conjg((1.2,-4.)))
> >   call test_c (ccos, (1.2,-4.), ccos((1.2,-4.)))
> >   call test_c (cexp, (1.2,-4.), cexp((1.2,-4.)))
> >   call test_c (clog, (1.2,-4.), clog((1.2,-4.)))
> >   call test_c (csin, (1.2,-4.), csin((1.2,-4.)))
> >   call test_c (csqrt, (1.2,-4.), csqrt((1.2,-4.)))
> >   call test_z (dconjg, (1.2d0,-4.d0), dconjg((1.2d0,-4.d0)))
> >   call test_z (cdcos, (1.2d0,-4.d0), cdcos((1.2d0,-4.d0)))
> >   call test_z (zcos, (1.2d0,-4.d0), zcos((1.2d0,-4.d0)))
> >   call test_z (cdexp, (1.2d0,-4.d0), cdexp((1.2d0,-4.d0)))
> >   call test_z (zexp, (1.2d0,-4.d0), zexp((1.2d0,-4.d0)))
> >   call test_z (cdlog, (1.2d0,-4.d0), cdlog((1.2d0,-4.d0)))
> >   call test_z (zlog, (1.2d0,-4.d0), zlog((1.2d0,-4.d0)))
> >   call test_z (cdsin, (1.2d0,-4.d0), cdsin((1.2d0,-4.d0)))
> >   call test_z (zsin, (1.2d0,-4.d0), zsin((1.2d0,-4.d0)))
> >   call test_z (cdsqrt, (1.2d0,-4.d0), cdsqrt((1.2d0,-4.d0)))
> >   call test_z (zsqrt, (1.2d0,-4.d0), zsqrt((1.2d0,-4.d0)))
> 
> Isn't that the full list of intrinsics returning complex results?

I think so.

[Bug fortran/120099] [16 regression] gfortran.dg/specifics_1.f90 FAILs since r16-372-g064cac730f88dc

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

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

--- Comment #20 from anlauf at gcc dot gnu.org ---
Does anybody know why there is the following comment preceding the suspcious
block:

  /* Possibly return complex numbers by reference for g77 compatibility.
 We don't do this for calls to intrinsics (as the library uses the
 -fno-f2c calling convention), nor for calls to functions which always
 require an explicit interface, as no compatibility problems can
 arise there.  */

In view of the current observations this seems wrong.

[Bug libstdc++/120315] std::format gcc 14 / 15 interop issue

[nilsgladitz at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Nils Gladitz  ---
Yes sorry I should have clarified.

I use the following before running the binaries:
export LD_LIBRARY_PATH=/opt/gcc-15.1.0/lib64

ldd correspondingly confirms:
libstdc++.so.6 => /opt/gcc-15.1.0/lib64/libstdc++.so.6 (0x7ccceda0)

[Bug target/120316] GCC-15.1.0 for Target RX: internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2cfi.cc:1854

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

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

--- Comment #1 from Andrew Pinski  ---
  /* Saving a register in a register.  */
  gcc_assert (!fixed_regs [REGNO (dest)]
  /* For the SPARC and its register window.  */
  || (dwf_regno (src) == DWARF_FRAME_RETURN_COLUMN));

[Bug target/96233] XGCC-10.1.0 for Target RX: internal compiler error: in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1189

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

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

--- Comment #2 from Andrew Pinski  ---
   gcc_assert (cur_cfa->reg == XEXP (src, 0));

[Bug target/120316] New: GCC-15.1.0 for Target RX: internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2cfi.cc:1854

[hdusel--- via Gcc-bugs]

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

Bug ID: 120316
   Summary: GCC-15.1.0 for Target RX: internal compiler error: in
dwarf2out_frame_debug_expr, at dwarf2cfi.cc:1854
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hdu...@tangerine-soft.de
  Target Milestone: ---

Created attachment 61444
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61444&action=edit
Bugreport as proposed by using -freport-bug

Host System: Mac OS 14.7.5

By attempting to cross compile the attached code I'll get an "internal compiler
error: in dwarf2out_frame_debug_expr, at dwarf2cfi.cc:1854" 

This Error kind of ICE happens since GCC 9.2.0. So my last reported Issue 96233
is very likely to relate with this.

[Bug target/120186] [pa] internal compiler error: in fail, at selftest.cc:47 during bootstrap with LRA enabled

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

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

--- Comment #9 from John David Anglin  ---
I was not able to reproduce this on c8000

[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.

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

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

--- Comment #22 from James K. Lowden  ---
I removed use of glob(3) entirely.  The code is actually simpler because there
never was any wildcard; we just iterate over variations on the name. I also
converted all stdio.h to cstdio, etc, for all such files. 

The commit is in our development branch.  When applied, I believe this issue
can be closed, because other parts have been addressed already.

[Bug c++/120314] internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in decl_internal_context_p, at cp/tree.cc:3866 only in trunk and 15.1 with

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

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

--- Comment #1 from Andrew Pinski  ---
Reducing. It is taking longer because I don't want to run into any other
unrelated issues.

[Bug cobol/119887] runtime-switches are not documented / implemented (and don't pass NC211A and others)

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

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

James K. Lowden  changed:

   What|Removed |Added

   Last reconfirmed||2025-05-16
 CC||jklowden at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from James K. Lowden  ---
AFAIK gcobol conforms to the ISO specification.  Switches are documented in
gcobol.1:

 UPSI COBOL defines a User Programmable Status Indicator (UPSI)
  switch. In gcobol, the settings are denoted UPSI-0 through
  UPSI-7, where 0-7 indicates a bit position.  The value of the
  UPSI switches is taken from the UPSI environment variable, whose
  value is a string of up to eight 1's and 0's.  The first
  character represents the value of UPSI-0, and missing values are
  assigned 0.  For example, UPSI=111 in the environment sets
  bits 0, 5, and 6 on, which means that UPSI-0, UPSI-5, and UPSI-6
  are on.

We run NC211A using nist/Makefile in our repository.  This command should work: 

$ make -C gcc/cobol/nist/ NC/NC211A.rpt

That command will configure the COBOL file (using NC211A.conf, as you observed)
and runs it with the correct environment.  

We did not attempt compatibility with other implementations for this arcane
feature, to avoid devoting time to something that might never be used.  A
concrete example (not one file, but a million lines) would inform what approach
is best.  For example, the UPSI name could be set when the compiler is
configured, or could be a command-line option.

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

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

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

Jerry DeLisle  changed:

   What|Removed |Added

  Attachment #61307|0   |1
is obsolete||

--- Comment #30 from Jerry DeLisle  ---
Created attachment 61445
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61445&action=edit
Preliminary patch showing all the logic

This patch shows all the logic involved. I have some debugging aspects in this
which I will get rid of.  Also, I encountered some interesting cases where
trying to return gfc_typename for the error message, the BT_VOID was giving an
internal error. We may want to handle that a bit differently.  I also found
that when processing the following test case, issueing an error from one
example can hide the ICE from another. To test these, I would comment all
examples except one, one at a time. It is a bbt laborious.  I will finish
dejagnu-ing this test:

! Test the fix for PR120049
program tests_gtk_sup
  use gtk_sup
  implicit none

  type mytype
integer :: myint
  end type mytype
  type(mytype) :: ijkl = mytype(42)
  logical :: truth
  real :: var1
  type(c_ptr), target :: val
  character(15) :: stringy
  complex :: certainly
  truth = .true.
  var1 = 86.
  stringy = "what the hay!"
  certainly = (3.14,-4.13)
  if (c_associated(val, c_loc(val))) then
stop 1
  endif
  if (c_associated(c_loc(val), val)) then
stop 2
  endif
  print *, c_associated(c_loc(val), 42)
  print *, c_associated(c_loc(val), .42)
  print *, c_associated(c_loc(val), truth)
  print *, c_associated(c_loc(val), .false.)
  print *, c_associated(c_loc(val), var1)
  print *, c_associated(c_loc(val), stringy)
  print *, c_associated(c_loc(val), certainly)
  print *, c_associated(42)
  print *, c_associated(.42)
  print *, c_associated(truth)
  print *, c_associated(.false.)
  print *, c_associated(var1)
  print *, c_associated(stringy)
  print *, c_associated(certainly)
  print *, c_associated(.42)
  print *, c_associated(val, testit(val))
  print *, c_associated(testit(val), val)
  print *, c_associated(testit(val))
contains

  function testit (avalue) result(res)
type(c_ptr) :: avalue
type(mytype) :: res
res%myint = 42
  end function

end program tests_gtk_sup

[Bug tree-optimization/120317] New: Missed DCE with __attribute__((const)) bijection function

[kaelfandrew at gmail dot com via Gcc-bugs]

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

Bug ID: 120317
   Summary: Missed DCE with __attribute__((const)) bijection
function
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kaelfandrew at gmail dot com
  Target Milestone: ---

Created attachment 61446
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61446&action=edit
C code

https://en.wikipedia.org/wiki/Bijection function are 1 to 1 and is invertible.

For example, assume f0_biject_out() increments and f0_biject_inverse()
decrements. (Both are bijective and decrements is a inverse of increment).
Then GCC should be able to remove f0_unreachable():

if(f0_biject_out(100) == f0_biject_out(101))
f0_unreachable();

since this would equal to

if(101 == 102)
f0_unreachable();

by assuming if(arg0 != f0_biject_inverse(f0_biject_out(arg0) ) ) to be true.

gcc -v
==
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-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 16.0. p,
commit 05d9c70131be267bfe5b36e663acda8729da6456' --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
--disable-libada --enable-cet --disable-systemtap
--disable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--with-zstd --with-isl --disable-isl-version-check --enable-default-pie
--enable-host-pie --enable-host-bind-now --enable-default-ssp
--disable-fixincludes --with-gxx-libcxx-include-dir=/usr/include/c++/v1
--with-build-config='bootstrap-lto bootstrap-cet'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250423 (experimental)
e9a81addd5b7d018e173fa8d59aafc2f84e41d8b (Gentoo 16.0. p, commit
05d9c70131be267bfe5b36e663acda8729da6456)

[Bug tree-optimization/120317] Missed DCE with __attribute__((const)) bijection function

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/120317] Missed DCE with __attribute__((const)) bijection function

[kaelfandrew at gmail dot com via Gcc-bugs]

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

Kael Franco  changed:

   What|Removed |Added

  Attachment #61446|0   |1
is obsolete||

--- Comment #1 from Kael Franco  ---
Created attachment 61447
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61447&action=edit
Updated C code

Forgot to check if ARG0 == ARG1 so if(tmp0 == tmp2) can be removed

[Bug tree-optimization/120317] Missed DCE with __attribute__((const)) bijection function

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

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

--- Comment #2 from Andrew Pinski  ---
I am not sure this is valid to with documentated const definition.

const does not mean `(arg0 != arg1)` -> `f(arg0) != f(arg1)` and even if you
have `arg0 == g(f(arg0))` as an assumption, that does not mean there is not a
value which causes undefined behavior. It just means the defined range of f (or
g) will have some value where that holds true.

[Bug fortran/120099] [16 regression] gfortran.dg/specifics_1.f90 FAILs since r16-372-g064cac730f88dc

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

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

--- Comment #16 from anlauf at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #15)
> (In reply to anlauf from comment #14)
> > This fixes the reduced testcase for me, but gfortran.dg/specifics_1.f90
> > still fails here.
> 
> Which means there are many more intrinsics here that need this treatment.
> The testcase has just subroutine test_* calls in the "program" (main) in it
> which you can narrow down which ones are failing ones are failing.

The following works:

diff --git a/gcc/fortran/trans-types.cc b/gcc/fortran/trans-types.cc
index f8980754685..eb45abe97d5 100644
--- a/gcc/fortran/trans-types.cc
+++ b/gcc/fortran/trans-types.cc
@@ -3237,7 +3237,7 @@ gfc_return_by_reference (gfc_symbol * sym)
   if (flag_f2c && sym->ts.type == BT_COMPLEX
   && !sym->attr.pointer
   && !sym->attr.allocatable
-  && !sym->attr.intrinsic && !sym->attr.always_explicit)
+  && !sym->attr.always_explicit)
 return 1;

   return 0;


I wonder whether the 20 year old comment before this block was ever correct.

[Bug fortran/103312] [11/12 Regression] ICE in gfc_find_component since r9-1098-g3cf89a7b992d483e

[kargls at comcast dot net via Gcc-bugs]

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

kargls at comcast dot net changed:

   What|Removed |Added

 CC||kargls at comcast dot net

--- Comment #15 from kargls at comcast dot net ---
(In reply to Paul Thomas from comment #14)
> (In reply to Paul Thomas from comment #13)
> > Fixed on 13- to 15-branches. Closing.
> 
> I have been working on the 2018 changes to IMPORT. With it partially
> implemented, 

Hi Paul, I did not realize that you were working on import.
Are you aware of 

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

[Bug fortran/120099] [16 regression] gfortran.dg/specifics_1.f90 FAILs since r16-372-g064cac730f88dc

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #9)
> Can't be done for the f2c functions.

libgfortran/intrinsics/f2c_specifics.F90 has:

subroutine _gfortran_f2c_specific__conjg_4 (res, parm)
  COMPLEX, intent (in) :: parm
  COMPLEX, intent (out) :: res
  res = conjg (parm)
end subroutine

So this is actually really a pure subroutine with no side-effects in the
fortran sense (the normal non-f2c counterpart is a pure elemental function).
'parm' is input, 'res' is output.

What is the expected way to do this?

[Bug fortran/120099] [16 regression] gfortran.dg/specifics_1.f90 FAILs since r16-372-g064cac730f88dc

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to anlauf from comment #10)
> (In reply to Andrew Pinski from comment #9)
> > Can't be done for the f2c functions.
> 
> libgfortran/intrinsics/f2c_specifics.F90 has:
> 
> subroutine _gfortran_f2c_specific__conjg_4 (res, parm)
>   COMPLEX, intent (in) :: parm
>   COMPLEX, intent (out) :: res
>   res = conjg (parm)
> end subroutine
> 
> So this is actually really a pure subroutine with no side-effects in the
> fortran sense (the normal non-f2c counterpart is a pure elemental function).
> 'parm' is input, 'res' is output.
> 
> What is the expected way to do this?

It might be pure in the fortran sense but it is not pure in the GCC IR sense
since it stores to the first argument.

I wonder why gfc_return_by_reference is not returning true here because I think
that would be idea here.

[Bug target/100165] fmov could be used to zero out the upper bits instead of movi/zip or movi/ins with __builtin_shuffle and zero vector

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Pengxuan Zheng :

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

commit r16-702-gdc501cb0dc857663f7fa762f3dbf0ae60973d2c3
Author: Pengxuan Zheng 
Date:   Wed May 7 10:47:37 2025 -0700

aarch64: Recognize vector permute patterns which can be interpreted as AND
[PR100165]

Certain permute that blends a vector with zero can be interpreted as an AND
of a
mask. This idea was suggested by Richard Sandiford when he was reviewing my
patch which tries to optimizes certain vector permute with the FMOV
instruction
for the aarch64 target.

For example, for the aarch64 target, at present:

v4hi
f_v4hi (v4hi x)
{
  return __builtin_shuffle (x, (v4hi){ 0, 0, 0, 0 }, (v4hi){ 4, 1, 6, 3 });
}

generates:

f_v4hi:
uzp1v0.2d, v0.2d, v0.2d
adrpx0, .LC0
ldr d31, [x0, #:lo12:.LC0]
tbl v0.8b, {v0.16b}, v31.8b
ret
.LC0:
.byte   -1
.byte   -1
.byte   2
.byte   3
.byte   -1
.byte   -1
.byte   6
.byte   7

With this patch, it generates:

f_v4hi:
mvniv31.2s, 0xff, msl 8
and v0.8b, v0.8b, v31.8b
ret

This patch also provides a target-independent routine for detecting vector
permute patterns which can be interpreted as AND.

Changes since v1:
* v2: Rework the patch to only perform the optimization for aarch64 by
calling
the target independent routine vec_perm_and_mask.

PR target/100165

gcc/ChangeLog:

* config/aarch64/aarch64.cc (aarch64_evpc_and): New.
(aarch64_expand_vec_perm_const_1): Call aarch64_evpc_and.
* optabs.cc (vec_perm_and_mask): New.
* optabs.h (vec_perm_and_mask): New prototype.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/and-be.c: New test.
* gcc.target/aarch64/and-le.c: New test.

Signed-off-by: Pengxuan Zheng 

[Bug target/100165] fmov could be used to zero out the upper bits instead of movi/zip or movi/ins with __builtin_shuffle and zero vector

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Pengxuan Zheng :

https://gcc.gnu.org/g:0417a630811404c2362060b7e15f99e5a4a0d76a

commit r16-703-g0417a630811404c2362060b7e15f99e5a4a0d76a
Author: Pengxuan Zheng 
Date:   Mon May 12 10:12:11 2025 -0700

aarch64: Optimize AND with certain vector of immediates as FMOV [PR100165]

We can optimize AND with certain vector of immediates as FMOV if the result
of
the AND is as if the upper lane of the input vector is set to zero and the
lower
lane remains unchanged.

For example, at present:

v4hi
f_v4hi (v4hi x)
{
  return x & (v4hi){ 0x, 0x, 0, 0 };
}

generates:

f_v4hi:
movid31, 0x
and v0.8b, v0.8b, v31.8b
ret

With this patch, it generates:

f_v4hi:
fmovs0, s0
ret

Changes since v1:
* v2: Simplify the mask checking logic by using native_decode_int and
address a
few other review comments.

PR target/100165

gcc/ChangeLog:

* config/aarch64/aarch64-protos.h (aarch64_output_fmov): New
prototype.
(aarch64_simd_valid_and_imm_fmov): Likewise.
* config/aarch64/aarch64-simd.md (and3): Allow
FMOV
codegen.
* config/aarch64/aarch64.cc (aarch64_simd_valid_and_imm_fmov): New.
(aarch64_output_fmov): Likewise.
* config/aarch64/constraints.md (Df): New constraint.
* config/aarch64/predicates.md (aarch64_reg_or_and_imm): Update
predicate to support FMOV codegen.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/fmov-1-be.c: New test.
* gcc.target/aarch64/fmov-1-le.c: New test.
* gcc.target/aarch64/fmov-2-be.c: New test.
* gcc.target/aarch64/fmov-2-le.c: New test.

Signed-off-by: Pengxuan Zheng 

[Bug target/100165] fmov could be used to zero out the upper bits instead of movi/zip or movi/ins with __builtin_shuffle and zero vector

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Pengxuan Zheng :

https://gcc.gnu.org/g:265fdb3fa91346f1be40111a9f3e8a0838f7d7fd

commit r16-704-g265fdb3fa91346f1be40111a9f3e8a0838f7d7fd
Author: Pengxuan Zheng 
Date:   Mon May 12 10:21:49 2025 -0700

aarch64: Add more vector permute tests for the FMOV optimization [PR100165]

This patch adds more tests for vector permutes which can now be optimized
as
FMOV with the generic PERM change and the aarch64 AND patch.

Changes since v1:
* v2: Add -mlittle-endian to the little endian tests explicitly and rename
the
tests accordingly.

PR target/100165

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/fmov-3-be.c: New test.
* gcc.target/aarch64/fmov-3-le.c: New test.
* gcc.target/aarch64/fmov-4-be.c: New test.
* gcc.target/aarch64/fmov-4-le.c: New test.
* gcc.target/aarch64/fmov-5-be.c: New test.
* gcc.target/aarch64/fmov-5-le.c: New test.

Signed-off-by: Pengxuan Zheng 

[Bug fortran/120099] [16 regression] gfortran.dg/specifics_1.f90 FAILs since r16-372-g064cac730f88dc

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

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

--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #11)
> I wonder why gfc_return_by_reference is not returning true here because I
> think that would be idea here.

Good point.  Tentative patch which excepts (d)conjg:

diff --git a/gcc/fortran/trans-types.cc b/gcc/fortran/trans-types.cc
index f8980754685..e1e4f1604cd 100644
--- a/gcc/fortran/trans-types.cc
+++ b/gcc/fortran/trans-types.cc
@@ -3237,7 +3237,10 @@ gfc_return_by_reference (gfc_symbol * sym)
   if (flag_f2c && sym->ts.type == BT_COMPLEX
   && !sym->attr.pointer
   && !sym->attr.allocatable
-  && !sym->attr.intrinsic && !sym->attr.always_explicit)
+  && (!sym->attr.intrinsic
+ || strcmp (sym->name, "conjg") == 0
+ || strcmp (sym->name, "dconjg") == 0)
+  && !sym->attr.always_explicit)
 return 1;

   return 0;

[Bug fortran/120099] [16 regression] gfortran.dg/specifics_1.f90 FAILs since r16-372-g064cac730f88dc

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

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

--- Comment #13 from Andrew Pinski  ---
(In reply to anlauf from comment #12)
> (In reply to Andrew Pinski from comment #11)
> > I wonder why gfc_return_by_reference is not returning true here because I
> > think that would be idea here.
> 
> Good point.  Tentative patch which excepts (d)conjg:
> 
> diff --git a/gcc/fortran/trans-types.cc b/gcc/fortran/trans-types.cc
> index f8980754685..e1e4f1604cd 100644
> --- a/gcc/fortran/trans-types.cc
> +++ b/gcc/fortran/trans-types.cc
> @@ -3237,7 +3237,10 @@ gfc_return_by_reference (gfc_symbol * sym)
>if (flag_f2c && sym->ts.type == BT_COMPLEX
>&& !sym->attr.pointer
>&& !sym->attr.allocatable
> -  && !sym->attr.intrinsic && !sym->attr.always_explicit)
> +  && (!sym->attr.intrinsic
> +   || strcmp (sym->name, "conjg") == 0
> +   || strcmp (sym->name, "dconjg") == 0)
> +  && !sym->attr.always_explicit)
>  return 1;
>  
>return 0;

Does it fix the whole original testcase? Because I just tried to reduce it into
one of the failures

[Bug fortran/120099] [16 regression] gfortran.dg/specifics_1.f90 FAILs since r16-372-g064cac730f88dc

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

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

--- Comment #14 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #12)
> Good point.  Tentative patch which excepts (d)conjg:
> 
> diff --git a/gcc/fortran/trans-types.cc b/gcc/fortran/trans-types.cc
> index f8980754685..e1e4f1604cd 100644
> --- a/gcc/fortran/trans-types.cc
> +++ b/gcc/fortran/trans-types.cc
> @@ -3237,7 +3237,10 @@ gfc_return_by_reference (gfc_symbol * sym)
>if (flag_f2c && sym->ts.type == BT_COMPLEX
>&& !sym->attr.pointer
>&& !sym->attr.allocatable
> -  && !sym->attr.intrinsic && !sym->attr.always_explicit)
> +  && (!sym->attr.intrinsic
> +   || strcmp (sym->name, "conjg") == 0
> +   || strcmp (sym->name, "dconjg") == 0)
> +  && !sym->attr.always_explicit)
>  return 1;
>  
>return 0;

This fixes the reduced testcase for me, but gfortran.dg/specifics_1.f90
still fails here.

:-(

[Bug fortran/120099] [16 regression] gfortran.dg/specifics_1.f90 FAILs since r16-372-g064cac730f88dc

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

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

--- Comment #15 from Andrew Pinski  ---
(In reply to anlauf from comment #14)
> This fixes the reduced testcase for me, but gfortran.dg/specifics_1.f90
> still fails here.

Which means there are many more intrinsics here that need this treatment. The
testcase has just subroutine test_* calls in the "program" (main) in it which
you can narrow down which ones are failing ones are failing.

[Bug libstdc++/120315] New: std::format gcc 14 / 15 interop issue

[nilsgladitz at gmail dot com via Gcc-bugs]

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

Bug ID: 120315
   Summary: std::format gcc 14 / 15 interop issue
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nilsgladitz at gmail dot com
  Target Milestone: ---

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

I got undefined behavior (segfault, missing output or exceptions) when using a
gcc 14 compiled library with a gcc 15 compiled executable.

The issue does not seem to be reproducible when the same compiler is used for
both the library and the compiler.

Attached is a reduced test case that I compile on x86_64 GNU Linux thusly:

/opt/gcc-14.2.0/bin/g++ -fvisibility=hidden -fvisibility-inlines-hidden -shared
-fPIC -std=c++23 library.cpp -o liblibrary14.so -Wl,-soname,liblibrary14.so
/opt/gcc-15.1.0/bin/g++ -fvisibility=hidden -fvisibility-inlines-hidden -shared
-fPIC -std=c++23 library.cpp -o liblibrary15.so -Wl,-soname,liblibrary15.so

/opt/gcc-15.1.0/bin/g++ -std=c++23 executable.cpp -o executable14
liblibrary14.so '-Wl,-rpath,$ORIGIN' 
/opt/gcc-15.1.0/bin/g++ -std=c++23 executable.cpp -o executable15
liblibrary15.so '-Wl,-rpath,$ORIGIN'

Running executable15 I get the expected output:
Hello World

Running executable14 I get e.g.:
terminate called after throwing an instance of 'std::format_error'
  what():  format error: invalid arg-id in format string
Aborted (core dumped)

I am unsure if maybe std::format isn't supposed to be ABI stable yet or if
there is something else not being done properly / well defined in the test
case.

[Bug target/120186] [pa] internal compiler error: in fail, at selftest.cc:47 during bootstrap with LRA enabled

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

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

--- Comment #8 from John David Anglin  ---
I was able to reproduce this on c8000.  Maybe this is a qemu issue?

[Bug libstdc++/120315] std::format gcc 14 / 15 interop issue

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

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

--- Comment #1 from Andrew Pinski  ---
>I got undefined behavior (segfault, missing output or exceptions) when using a 
>gcc 14 compiled library with a gcc 15 compiled executable.


Forward compatibility is not guaranteed; only backwards.

Does GCC 14 compiled program work with a GCC 15 library?

[Bug libstdc++/120315] std::format gcc 14 / 15 interop issue

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

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

--- Comment #2 from Andrew Pinski  ---
Wait I read that incorrectly. 

That which libstdc++ shared library is being loaded?

[Bug libstdc++/120305] Cannot create a std::vector from a std::ranges::transform_view.

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to aneris from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > The difference is int128_t support.
> 
> Could you elaborate a bit? I am afraid I don't follow.

I am saying why `-std=c++20 -pedantic` fails but `-std=gnu++20 -pedantic`
works. it seems related to int128_t support in libstdc++. I have not looked
further than that.

[Bug libstdc++/120305] Cannot create a std::vector from a std::ranges::transform_view.

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Jonathan Wakely  ---
(In reply to aneris from comment #0)
> auto triangularNums = std::ranges::views::iota(1lu, N + 1) |
> std::views::transform([](long unsigned a){return (a * (a + 1))/2;}); 
> return std::vector{triangularNums.begin(),
> triangularNums.end()};

This is not a bug. The std::vector(InputIterator, InputIterator) constructor
requires arguments that meet the Cpp17InputIterator requirements.
ranges::iota_view iterators do not meet those requirements.

The correct way to do this is:

  return std::ranges::to>(triangularNums);

You can also directly use the constructor that std::ranges::to uses:

  return std::vector{std::from_range, triangularNums);

The std::ranges::to solution works since GCC 14, the std::from_range
constructor is only supported since GCC 15.

[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.

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

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

--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #20 from James K. Lowden  ---
> NAME_MAX has been removed entirely as of
> ca44643f75c437fb1fb4b17e59b72bc836d12cc6.

This commit isn't in the gcc repo yet.

>> * GLOB_BRACE and GLOB_TILDE are not in POSIX.1 and missing on Solaris:
>
> What is the rule?  When cobol is enabled, both c and c++ are built, too.  I 
> was
> told a bootstrap build is the standard, and that libgcobol should link to the
> just-built libstdc++.  Is that not true of libc, too?  Or does that rule apply

There's no libc inside the gcc tree, unlike libstdc++, and I know of no
libc implementation portable to the wide variety of hosts and targets
supported by gcc.

> only to the target, whereas the compiler runs on the host and uses the host
> system libraries?  

Neither: libc will always be the host resp. target libc.

GCC is supposed to work on the primary and secondary platforms listed in
the release criteria:

https://gcc.gnu.org/gcc-15/criteria.html

> The patch (which was applied) to #define GLOB_BRACE 0 indeed compiles, and 
> will
> never work.  Braces are supplied in the pattern as static text; if not 
> expanded
> by the library, glob(3) will not execute the intended search.  
>
> If we are constrained to work with every libc and not only glibc, then my
> answer to would be to add xglob to libiberty. At least then the work would be
> useful outside the GCC COBOL front end.

I'd already mentioned (Comment #10) that gnulib provides an
implementation of glob(3) that includes GLOB_BRACE and GLOB_TILDE.  If
it's feasible to integrate that is another question (the gnulib
framework is considerable, though gdb currently uses it).

[Bug c++/120306] Copy constructor with requires (!std::copy_constructible) is available

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

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

--- Comment #1 from Jonathan Wakely  ---
This seems clearly undefined nonsense, so what difference does it make whether
it compiles?

copy_constructible depends on an incomplete type, for a start.

[Bug c++/120272] [13/14/15/16 Regression] ICE in get_local_decls, at cp/name-lookup.c:4594 since 13.3 (r14-5514)

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

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

Simon Martin  changed:

   What|Removed |Added

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

--- Comment #3 from Simon Martin  ---
Working on this one.

[Bug libstdc++/120305] Cannot create a std::vector from a std::ranges::transform_view.

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

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #7)
> An iota_view with unsigned long elements (i.e. 64-bit integers) must use
> something wider than 64 bits for the difference_type of its iterators. The
> C++20 standard allows that to be an integer type or an integer-like class
> type.
> 
> In strict standard-conforming mode, we do not use the non-standard __int128
> type for iota_view iterators, so we use an integer-like class type.

Sorry, I slightly misremembered the details and this is not quite correct. We
use __int128 for the difference_type even in strict mode. 

The problem is that the Cpp17InputIterator requirements require the iterator's
difference_type to be a standard integer type, and in struct modes __int128 is
not considered a standard integer type (it's a non-standard extension).

In non-strict -std=gnu++20 mode we consider __int128 to be a standard integer
type, and so iota iterators meet the Cpp17InputIterator requirements. 

So the end result is the same, the difference is just in the precise details of
*why* iota view iterators do not meet the Cpp17InputIterator requirements.

[Bug libstdc++/96710] __int128 vs

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

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

--- Comment #4 from Jonathan Wakely  ---
I think we should try to do this for GCC 16, so we don't have ODR violations
between -std=c++20 and -std=gnu++20 for anything that depends on
iterator_traits>>::iterator_category

[Bug libstdc++/96710] __int128 vs

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |16.0
 Blocks||120305


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120305
[Bug 120305] Cannot create a std::vector from a std::ranges::transform_view.

[Bug libstdc++/120299] GCC started using __flt128_t when __float128 exists but _Float128 does not

[tymi at tymi dot org via Gcc-bugs]

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

--- Comment #13 from Tymi  ---
(In reply to Jonathan Wakely from comment #12)
> (In reply to Tymi from comment #4)
> > Why not check for __clang__ and fallback to a compatible solution then?
> 
> Because that should only ever be a last resort. The right way to do it is
> write portable code that depends on which features are supported by the
> compiler, not what the compiler's name is.

Of course, that would be ideal. Anyway the bug is fixed

[Bug target/120304] SPARC lacks __float128 support

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

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Rainer Orth from comment #0)
> > * I initially tried aliasing __float128 to _Float128, but that broke the
> >   libstdc++ build:
> 
> Libstdc++ could be changed to handle it, but I don't think we want that.
> 
> In C++ the _FloatN types have special rules that prevent some implicit
> conversions, which would break existing code that uses __float128 and
> expects it to have the usual implicit conversions e.g. to double.

Aliasing __float128 to _Float128 is wrong for C++.
The latter has the standard required behavior for std::float128_t, while the
former doesn't and shouldn't.
I think best just leave __float128 not implemented.  E.g. loongarch enabled it
recently and ran into issues with e.g. libquadmath all of sudden being built
when it shouldn't etc.
If you really want to implement it, then it should be a distinct REAL_TYPE from
both long_double_type and float128_type_node and you need to also enable the
q/Q suffixes on floating point literals.

[Bug target/120304] SPARC lacks __float128 support

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

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

--- Comment #4 from Jakub Jelinek  ---
But of course then it needs to be mangled differently from long double and
_Float128 too.
Itanium ABI documents e for long double, g for __float128 and DF128_ for
_Float128,
not really sure if g isn't already taken for something else on SPARC (e.g.
PowerPC had issues with that).

[Bug libstdc++/96710] __int128 vs

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug ipa/120307] ICE in combine_with_ipa_count_within, at profile-count.cc:410 during aarch64 -O3 profiledbootstrap

[mcccs at gmx dot com via Gcc-bugs]

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

mcccs at gmx dot com changed:

   What|Removed |Added

 CC||mcccs at gmx dot com

--- Comment #1 from mcccs at gmx dot com ---
I can reproduce it with --disable-bootstrap

[Bug c++/120312] New: internal compiler error: error reporting routines re-entered. in build_array_type_1 since 4.7.1 until trunk

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

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

Bug ID: 120312
   Summary: internal compiler error: error reporting routines
re-entered. in build_array_type_1 since 4.7.1 until
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: ---

ICEs when using after incorrectly using aligned.

```
#include 
int main(void) {
   void *__attribute__((aligned(1024))) ptr[1];
   char *result;
   int v = 0;
   ptr = v;
}

```

```
internal compiler error: error reporting routines re-entered.
0x294317e diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x2943295 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2960676 error(char const*, ...)
???:0
0x17f9089 build_array_type_1(tree_node*, tree_node*, bool, bool, bool)
???:0
0x29849b3 pretty_printer::format(text_info&)
???:0
0x2942dd6 diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x2943295 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x29608ef error_at(unsigned long, char const*, ...)
???:0
0xddaec0 cp_build_modify_expr(unsigned long, tree_node*, tree_code, tree_node*,
int)
???:0
0xddb327 build_x_modify_expr(unsigned long, tree_node*, tree_code, tree_node*,
tree_node*, int)
???:0
0xcfced3 c_parse_file()
???:0
0xe5f9d9 c_common_parse_file()
???:0
```

To quickly reproduce:

https://godbolt.org/z/K1snh1cME

[Bug c++/120306] Copy constructor with requires (!std::copy_constructible) is available

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

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

--- Comment #3 from Andrew Pinski  ---
So clang accepts it also when using libstdc++. when using libc++ clang rejects
it due to the type trait __is_nothrow_destructible  being used with an
incomplete type.

Simplified testcase:
```
#include 

struct S;
auto t = std::copy_constructible;
```

[Bug c++/120289] internal compiler error: tree check: accessed elt 2 of 'tree_vec' with 1 elts in tsubst, at cp/pt.cc:16650 since 6.1

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||error-recovery

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

[Bug c++/120289] [12/13/14/15/16 Regression] internal compiler error: tree check: accessed elt 2 of 'tree_vec' with 1 elts in tsubst, at cp/pt.cc:16650 since 6.1

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

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

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

[Bug c++/120289] [12/13/14/15/16 Regression] internal compiler error: tree check: accessed elt 2 of 'tree_vec' with 1 elts in tsubst, at cp/pt.cc:16650 since 6.1

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #61449|0   |1
is obsolete||

--- Comment #4 from Andrew Pinski  ---
Created attachment 61450
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61450&action=edit
Updated reduced

[Bug c++/120289] [12/13/14/15/16 Regression] internal compiler error: tree check: accessed elt 2 of 'tree_vec' with 1 elts in tsubst, at cp/pt.cc:16650 since 6.1

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.5

[Bug c++/120289] [12/13/14/15/16 Regression] internal compiler error: tree check: accessed elt 2 of 'tree_vec' with 1 elts in tsubst, at cp/pt.cc:16650 since 6.1

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug c++/120274] internal compiler error: in tsubst_expr, at cp/pt.cc:21618 since clang 10 using -std=c++20

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

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

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

[Bug c++/120274] internal compiler error: in tsubst_expr, at cp/pt.cc:21618 since clang 10 using -std=c++20

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

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

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

[Bug c++/120274] [12/13/14/15/16 Regression] internal compiler error: in tsubst_expr when trying to call a concept inside a template since GCC 10 using -std=c++20/-fconcepts

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-05-17
Summary|internal compiler error: in |[12/13/14/15/16 Regression]
   |tsubst_expr, at |internal compiler error: in
   |cp/pt.cc:21618 since clang  |tsubst_expr when trying to
   |10 using -std=c++20 |call a concept inside a
   ||template since GCC 10 using
   ||-std=c++20/-fconcepts
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |12.5
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
Confirmed. I suspect this was introduced by r10-3735-gcb57504a550158 .

[Bug c++/120275] ICE in write_type at cp/mangle.cc:2687 when using decltype(auto) with initializer list since 11.3

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||11.1.0, 11.2.0
  Known to fail||11.3.0, 11.4.0, 12.1.0
   Target Milestone|--- |12.5
   Keywords||error-recovery,
   ||ice-on-invalid-code

[Bug c++/120318] New: Module deduced return type error.

[kongmingd234 at proton dot me via Gcc-bugs]

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

Bug ID: 120318
   Summary: Module deduced return type error.
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kongmingd234 at proton dot me
  Target Milestone: ---

Created attachment 61452
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61452&action=edit
This code does not compile.

The code given in the file does not compile, however, using include instead
will cause this code to compile perfectly fine.

Weirder is that having the code inside a lambda function instead of a normal
function causes the error to go away.

This could be an issue with libstdc++, but seems unlikely to me. In the off
chance that it was I apologize for tagging it as c++.

[Bug libstdc++/120305] Cannot create a std::vector from a std::ranges::transform_view.

[aneris at disroot dot org via Gcc-bugs]

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

aneris  changed:

   What|Removed |Added

 CC||aneris at disroot dot org

--- Comment #1 from aneris  ---
Created attachment 61440
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61440&action=edit
the ii file produced by the compiler

[Bug libstdc++/120305] Cannot create a std::vector from a std::ranges::transform_view.

[aneris at disroot dot org via Gcc-bugs]

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

--- Comment #5 from aneris  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to aneris from comment #3)
> > (In reply to Andrew Pinski from comment #2)
> > > The difference is int128_t support.
> > 
> > Could you elaborate a bit? I am afraid I don't follow.
> 
> I am saying why `-std=c++20 -pedantic` fails but `-std=gnu++20 -pedantic`
> works. it seems related to int128_t support in libstdc++. I have not looked
> further than that.

Ah, okay!

[Bug c/120303] [15/16 Regression] ICE , in groktypename at gcc/c/c-decl.cc:5442 with _Generic after an error

[mcccs at gmx dot com via Gcc-bugs]

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

mcccs at gmx dot com changed:

   What|Removed |Added

 CC||mcccs at gmx dot com

--- Comment #2 from mcccs at gmx dot com ---
r15-1190-g0cf68222d2df3a (unsurprisingly) for the reduced testcase

[Bug tree-optimization/120307] New: ICE in combine_with_ipa_count_within, at profile-count.cc:410 during aarch64 -O3 profiledbootstrap

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

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

Bug ID: 120307
   Summary: ICE in combine_with_ipa_count_within, at
profile-count.cc:410 during aarch64 -O3
profiledbootstrap
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

Created attachment 61441
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61441&action=edit
unreduced testcase (src + profile data)

The attached unreduced testcase is extracted from an aarch64 -O3
profiledbootstrap, (configured --with-build-config=bootstrap-O3).  It fails as
follows:

$ ls
optabs.gcda  optabs.ii
$ ../xgcc -B .. -c -S -o /dev/null -O3 -fprofile-use -fno-exceptions optabs.ii
during IPA pass: inline
/home/alecop01/toolchain/src/gcc-worktress/base-profile/gcc/optabs.cc:8280:1:
internal compiler error: in combine_with_ipa_count_within, at
profile-count.cc:410
 8280 | }
  | ^
0x265c92b internal_error(char const*, ...)
/home/alecop01/toolchain/src/gcc/gcc/diagnostic-global-context.cc:517
0x809e7b fancy_abort(char const*, int, char const*)
/home/alecop01/toolchain/src/gcc/gcc/diagnostic.cc:1815
0x1207213 profile_count::combine_with_ipa_count_within(profile_count,
profile_count)
/home/alecop01/toolchain/src/gcc/gcc/profile-count.cc:410
0xd5987b cgraph_edge::clone(cgraph_node*, gcall*, unsigned int, profile_count,
profile_count, bool)
/home/alecop01/toolchain/src/gcc/gcc/cgraphclones.cc:151
0xd5becf cgraph_node::create_clone(tree_node*, profile_count, bool,
vec, bool, cgraph_node*, ipa_param_adjustments*,
char const*)
/home/alecop01/toolchain/src/gcc/gcc/cgraphclones.cc:466
0x102328f clone_inlined_nodes(cgraph_edge*, bool, bool, int*)
/home/alecop01/toolchain/src/gcc/gcc/ipa-inline-transform.cc:224
0x1023b97 inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
/home/alecop01/toolchain/src/gcc/gcc/ipa-inline-transform.cc:516
0x24350fb inline_to_all_callers_1
/home/alecop01/toolchain/src/gcc/gcc/ipa-inline.cc:2635
0x24350fb inline_to_all_callers
/home/alecop01/toolchain/src/gcc/gcc/ipa-inline.cc:2660
0x243627b cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool)
/home/alecop01/toolchain/src/gcc/gcc/cgraph.h:3444
0x243627b ipa_inline
/home/alecop01/toolchain/src/gcc/gcc/ipa-inline.cc:2985
0x243627b execute
/home/alecop01/toolchain/src/gcc/gcc/ipa-inline.cc:3314
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.

I'm trying to reduce the testcase but it's slow going, so figured I ought to
raise this in the meantime.

[Bug c++/120311] New: internal compiler error: in lookup_base, at cp/search.cc:251

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

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

Bug ID: 120311
   Summary: internal compiler error: in lookup_base, at
cp/search.cc:251
   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 internal compiler error: in lookup_base, at cp/search.cc:251 since g++ 4.6.
It only occurs in c++ not in c although it uses no libraries.

```
int main(int argc, char *argv[])
{
   int x = ((struct {
  struct {
char c;
  };
   }) {0}).c;
}
```

```
:7:12: internal compiler error: in lookup_base, at cp/search.cc:251
7 |}) {0}).c;
  |^
0x2943295 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2961006 internal_error(char const*, ...)
???:0
0xad8afe fancy_abort(char const*, int, char const*)
???:0
0xdd2527 build_class_member_access_expr(cp_expr, tree_node*, tree_node*, bool,
int)
???:0
0xddba82 finish_class_member_access_expr(cp_expr, tree_node*, bool, int)
???:0
0xcfced3 c_parse_file()
???:0
0xe5f9d9 c_common_parse_file()
???:0
```

To reproduce:

https://godbolt.org/z/3aWbsnjrK
```

[Bug debug/120310] Missing location for initially addressable variable

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||wrong-debug
 CC||pinskia at gcc dot gnu.org
   Last reconfirmed||2025-05-16
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed. THere might be another report of this too.

[Bug libstdc++/65909] check_v3_target_namedlocale blows up on targets that don't support command-line arguments

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #16 from Jonathan Wakely  ---
(In reply to Thomas Schwinge from comment #8)
> With this, I see:
> 
> [-PASS:-]{+UNSUPPORTED:+} 22_locale/locale/cons/12352.cc 
> -std=gnu++17[-(test for excess errors)-]
> [-PASS: 22_locale/locale/cons/12352.cc  -std=gnu++17 execution test-]
> 
> [-PASS: 22_locale/locale/cons/12438.cc  -std=gnu++17  (test for
> warnings, line 48)-]
> [-PASS: 22_locale/locale/cons/12438.cc  -std=gnu++17 (test for excess
> errors)-]
> [-PASS:-]{+UNSUPPORTED:+} 22_locale/locale/cons/12438.cc 
> -std=gnu++17[-execution test-]
> 
> [-PASS:-]{+UNSUPPORTED:+} 22_locale/locale/cons/7222-env.cc 
> -std=gnu++17[-(test for excess errors)-]
> [-PASS: 22_locale/locale/cons/7222-env.cc  -std=gnu++17 execution test-]
> 
> These are exactly the test cases that 'dg-require-namedlocale ""', which now
> fails:
> 
> locale '{}' not supported

This is now fixed, those three tests now PASS again instead of being
UNSUPPORTED.

[Bug target/118603] aarch64-cores.def causes narrowing conversion warnings due to -1 for variant

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug debug/120310] Missing location for initially addressable variable

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

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

--- Comment #2 from Jakub Jelinek  ---
Guess one case is when tree DSE removes all stores to some automatic
addressable variable, in that case it would be nice to populate debug stmts to
all those removed locs and state what values it had there.
Another case is where DSE keeps some stores to it and removes others.
If it removes the last store before the var goes out of scope, perhaps adding
debug stmt for that is fine too, but not sure what to do in case it removes a
store because it is overwritten by a later store, say
void qux (int *);
void
baz (void)
{
  int a = 42;
  a = 43;
  qux (&a);
}
Because there dse1 does
   # DEBUG BEGIN_STMT
-  a = 42;
   # DEBUG BEGIN_STMT
   a = 43;
and if we add   # DEBUG a => 42 we'd need to add some debug stmt to say from
this point on, value of a is in the a variable.  Not sure if # DEBUG a => a
would do it or if we'd need something else.

[Bug target/118603] aarch64-cores.def causes narrowing conversion warnings due to -1 for variant

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

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

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

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

commit r16-694-gdca6f3534d2b6c52cecc770c40b204fb5e4a12b3
Author: Andrew Pinski 
Date:   Fri May 9 21:13:48 2025 -0700

aarch64: Fix narrowing warning in driver-aarch64.cc [PR118603]

Since the AARCH64_CORE defines in aarch64-cores.def all use -1 for
the variant, it is just easier to add the cast to unsigned in the usage
in driver-aarch64.cc.

Build and tested on aarch64-linux-gnu.

gcc/ChangeLog:

PR target/118603
* config/aarch64/driver-aarch64.cc (aarch64_cpu_data): Add cast to
unsigned
to VARIANT of the define AARCH64_CORE.

Signed-off-by: Andrew Pinski 

[Bug c++/120287] [12/13/14/15/16 Regression] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in is_std_substitution, at cp/mangle.cc:507

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

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

--- Comment #6 from Jonathan Wakely  ---
Should this be two separate bugs? There might be one that's been there since
gcc-5 but there's still a newer one that's is a gcc-15 regression.

It's only ice-on-invalid-code though, so I guess it's not too important.

[Bug libstdc++/120299] GCC started using __flt128_t when __float128 exists but _Float128 does not

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

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Tymi from comment #4)
> Why not check for __clang__ and fallback to a compatible solution then?

Because that should only ever be a last resort. The right way to do it is write
portable code that depends on which features are supported by the compiler, not
what the compiler's name is.

[Bug c++/120287] [12/13/14/15/16 Regression] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in is_std_substitution, at cp/mangle.cc:507

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

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

--- Comment #7 from Jakub Jelinek  ---
I guess it depends on what approach is used to fix this.
If just handling error_mark_node gracefully during the mangling (emit something
in that case, what exactly doesn't matter much) and/or somehow figure out that
the to be mangled entity (whether variable template or function template etc.)
is somehow erroneous and don't try to mangle it at all.
If the former, then it is the same bug...

[Bug libstdc++/120305] New: Cannot create a std::vector from a std::ranges::transform_view.

[aneris at disroot dot org via Gcc-bugs]

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

Bug ID: 120305
   Summary: Cannot create a std::vector from a
std::ranges::transform_view.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aneris at disroot dot org
  Target Milestone: ---

The following code

--
#include 
#include 
#include 

template
constexpr auto triangularNumbersTill()
{
auto triangularNums = std::ranges::views::iota(1lu, N + 1) |
std::views::transform([](long unsigned a){return (a * (a + 1))/2;}); 
return std::vector{triangularNums.begin(),
triangularNums.end()};
}

int main() {

for (auto x : triangularNumbersTill<10>()) {
std::cout << x;
}
}
--
does not compile on GCC 14, GCC 15 and GCC 16 (HEAD).

Options used were,
-O2 -Wall -Wextra -pedantic -std=c++20

The code compiles correctly if you replace all the long unsigned with just
unsigned though, which I find very peculiar, the code also compiles with
gnu++20 as the standard. I also tried with clang and it failed to compile it as
well (though, some versions like those provided by wandbox.org could compile it
properly... somehow.)

My GCC version:
sing built-in specs.
COLLECT_GCC=g++-15
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/15/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
15-20250404-0ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-15/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust,cobol,algol68
--prefix=/usr --with-gcc-major-version-only --program-suffix=-15
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-libstdcxx-backtrace
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-15-n9L2J0/gcc-15-15-20250404/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-15-n9L2J0/gcc-15-15-20250404/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250404 (experimental) [master r15-9193-g08e803aa9be]
(Ubuntu 15-20250404-0ubuntu1)

---
Here is the complete error.
---
x.cpp: In instantiation of ‘constexpr auto triangularNumbersTill() [with long
unsigned int N = 10]’:
x.cpp:14:44:   required from here
   14 | for (auto x : triangularNumbersTill<10>()) {
  |   ~^~
x.cpp:9:83: error: no matching function for call to ‘std::vector::vector()’
9 | d::vector{triangularNums.begin(), triangularNums.end()};
  |  ^
x.cpp:9:83: note: there are 12 candidates
In file included from /usr/include/c++/15/vector:68,
 from x.cpp:3:
/usr/include/c++/15/bits/stl_vector.h:736:9: note: candidate 1: ‘template constexpr std::vector<_Tp,
_Alloc>::vector(_InputIterator, _InputIterator, const allocator_type&) [with
 = _InputIterator; _Tp = long unsigned int; _Alloc =
std::allocator]’
  736 | vector(_InputIterator __first, _InputIterator __last,
  | ^~
/usr/include/c++/15/bits/stl_vector.h:736:9: note: template argument
deduction/substitution failed:
In file included from /usr/include/c++/15/bits/move.h:37,
 from /usr/include/c++/15/bits/exception_ptr.h:41,
 from /usr/include/c++/15/exception:168,
 from /usr/include/c++/15/ios:43,
 from /usr/include/c++/15/bits/ostream.h:43,
 from /usr/include/c++/15/ostream:42,
 from /usr/include/c++/15/iostream:43,
 from x.cpp:1:
/usr/include/c++/15/type_traits: In substitution of ‘template using std::__enable_if_t = typename std::enable_if::type [with bool _Cond
= false; _Tp = void]’:
/usr/include/c++/15/bits/stl_iterator_base_types.h:252:11:   required by
substitution of ‘template using st

[Bug tree-optimization/120280] ABS < 0 is not optimized to false by match

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

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

--- Comment #12 from Richard Biener  ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Andrew Pinski from comment #9)
> > So the easy workaround is not use tree_expr_nonnegative_p as predicate here
> > and just do:
> > ```
> >  (simplify
> >   (cmp @0 zerop@1)
> >   (if (tree_expr_nonnegative_p (@0) && !fixed_zerop (@1)
> > ```
> > 
> > Though I am not 100% sure this will workaround all of the issues.
> 
> This also works around the issue:
> ```
> diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
> index b74fb8bb50c..b7e5d32c76d 100644
> --- a/gcc/gimple-fold.cc
> +++ b/gcc/gimple-fold.cc
> @@ -11108,6 +11108,8 @@ gimple_phi_nonnegative_warnv_p (gimple *stmt, bool
> *strict_overflow_p,
>for (unsigned i = 0; i < gimple_phi_num_args (stmt); ++i)
>  {
>tree arg = gimple_phi_arg_def (stmt, i);
> +  if (!arg || SSA_NAME_IN_FREE_LIST (arg))
> +   continue;
>if (!tree_single_nonnegative_warnv_p (arg, strict_overflow_p, depth +
> 1))
> return false;
>  }
> 
> ```
> 
> But I am not 100% sure if this is correct.

No.

> Is FRE/VN supposed to leave around references to ssa names ih a phi which
> are in the free list even if the block is no longer reachable and depend on
> cleanup cfg?

Yes.  FRE/VN will have turned the conditions into if (0) / if (1) and
relies on CFG cleanup to prune the unreachable parts of the CFG.  FRE/VN
does not bother to update/substitute into unreachable parts of the CFG
as that's a waste of time.

[Bug tree-optimization/120280] ABS < 0 is not optimized to false by match

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

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

--- Comment #11 from Richard Biener  ---
Well, the issue is that tree_expr_nonnegative_p does not honor
no_follow_ssa_edges in

static bool
cleanup_control_expr_graph (basic_block bb, gimple_stmt_iterator gsi)
{
...
  switch (gimple_code (stmt))
{
case GIMPLE_COND:
  {
gimple_match_op res_op;
if (gimple_simplify (stmt, &res_op, NULL, no_follow_ssa_edges,
 no_follow_ssa_edges)
&& res_op.code == INTEGER_CST)
  val = res_op.ops[0];

this is done because we operate on a partially valid SSA form only.
Esp. the PHI handling in gimple_stmt_nonnegative_warnv_p is problematic
here.

So I'd say match.pd should never use any of the SSA following predicates
(and the more and more added helpers like bitwise_equal are equally
problematic).

In fact, we should try to get rid of those GIMPLE walks in predicates,
_esp_ those walking of PHI edges.

In the overall GCC design plan I've always wanted some kind of folding
context - there we could eventually check for an active no_follow_ssa_edges
or other valueization hook.  But apart from some ad-hoc partial conversion
by adding some global "fold_context" pointer (and possibly ways to stack
them, like we can with the gimplify context), this is a lot of work.

Now, another idea might be to add

(define_predicate_with_valueization
  tree_expr_nonnegative_p)

and have genmatch generate tree_expr_nonnegative_p (valueize, @0) calls,
thus pass down such hook and handle the hook all the way down.

The other thing is to at least try pruning the PHI handling of all those
hooks and see whether we still need that.

For the abs(x) >= 0 pattern you could, instead of using
tree_expr_nonnegative_p, rely on get_range_query ()->range_of_expr ()
instead of the tree predicate.  That works only on GIMPLE of course.

[Bug libstdc++/120305] Cannot create a std::vector from a std::ranges::transform_view.

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

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

--- Comment #11 from Jonathan Wakely  ---
Specifically, we have these concepts used to select a partial specialization of
std::iterator_traits:

template
  concept __cpp17_iterator = requires(_Iter __it)
{
  { *__it } -> __can_reference;
  { ++__it } -> same_as<_Iter&>;
  { *__it++ } -> __can_reference;
} && copyable<_Iter>;

template
  concept __cpp17_input_iterator = __cpp17_iterator<_Iter>
&& equality_comparable<_Iter>
&& requires(_Iter __it)
{
  typename incrementable_traits<_Iter>::difference_type;
  typename indirectly_readable_traits<_Iter>::value_type;
  typename common_reference_t&&,
   typename indirectly_readable_traits<_Iter>::value_type&>;
  typename common_reference_t::value_type&>;
  requires signed_integral<
typename incrementable_traits<_Iter>::difference_type>;
};

That last signed_integral requirement is the problem.

signed_integral<__int128> is satisfied for -std=gnu++20 and not for -std=c++20.

[Bug libstdc++/120305] Cannot create a std::vector from a std::ranges::transform_view.

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

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

--- Comment #12 from Jonathan Wakely  ---
tl;dr if you want to compile with strict -std=c++20 -pedantic settings, you
need to strictly follow the rules of the standard.

[Bug target/120308] 'TYPE_EMPTY_P' vs. code offloading

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

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

--- Comment #1 from Richard Biener  ---
It looks like TYPE_EMPTY_P is only used during RTL expansion for ABI purposes,
so computing it during layout_type is premature as shown here.

I would suggest to simply re-compute it at offload stream-in time.

Design-wise we might want to replace all TYPE_EMPTY_P uses with a call
to the target hook or instead make it tri-state and maintain only a cache
in the tree node and make sure that cache isn't populated until after
LTO stream-in.

[Bug target/120308] 'TYPE_EMPTY_P' vs. code offloading

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2025-05-16

--- Comment #2 from Thomas Schwinge  ---
Created attachment 61442
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61442&action=edit
'0001-TYPE_EMPTY_P-vs.-code-offloading-PR120308.patch'

(In reply to Richard Biener from comment #1)
> It looks like TYPE_EMPTY_P is only used during RTL expansion for ABI
> purposes, so computing it during layout_type is premature as shown here.

Thanks for confirming what I suspected/hoped.

> I would suggest to simply re-compute it at offload stream-in time.

I'm testing the patch that I'm attaching here.  Does that look alright?  Do I
understand correctly that (per (non-)handling of other similar cases) I do
*not* conditionalize 'compare_values (TYPE_EMPTY_P);' in
'gcc/lto/lto-common.cc:compare_tree_sccs_1'?

> Design-wise we might want to replace all TYPE_EMPTY_P uses with a call
> to the target hook or instead make it tri-state and maintain only a cache
> in the tree node

ACK, noted for further improvement, later on.

> and make sure that cache isn't populated until after
> LTO stream-in.

ACK.  I wish that we generally were more explicit about which information in
GCC data structures is valid at which stage during compilation.

[Bug target/120308] 'TYPE_EMPTY_P' vs. code offloading

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

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

--- Comment #3 from Richard Biener  ---
(In reply to Thomas Schwinge from comment #2)
> Created attachment 61442 [details]
> '0001-TYPE_EMPTY_P-vs.-code-offloading-PR120308.patch'
> 
> (In reply to Richard Biener from comment #1)
> > It looks like TYPE_EMPTY_P is only used during RTL expansion for ABI
> > purposes, so computing it during layout_type is premature as shown here.
> 
> Thanks for confirming what I suspected/hoped.
> 
> > I would suggest to simply re-compute it at offload stream-in time.
> 
> I'm testing the patch that I'm attaching here.  Does that look alright?  Do
> I understand correctly that (per (non-)handling of other similar cases) I do
> *not* conditionalize 'compare_values (TYPE_EMPTY_P);' in
> 'gcc/lto/lto-common.cc:compare_tree_sccs_1'?

That looks OK to me, indeed compare_values should be kept.

[Bug c/120309] New: internal compiler error: Segmentation fault in groktypename since gcc 15.1

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

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

Bug ID: 120309
   Summary: internal compiler error: Segmentation fault in
groktypename since gcc 15.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 only since 15.1 and happening in trunk:

```
#include 
#include 
typedef _Atomic(uintptr_t) g;
_Static_assert(_Generic(g(0)))
```

```
:4:1: internal compiler error: Segmentation fault
4 | _Static_assert(_Generic(g(0)))
  | ^~
0x261bc05 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2639976 internal_error(char const*, ...)
???:0
0xa2d7cb groktypename(c_type_name*, tree_node**, bool*)
???:0
0xab9b0e c_parse_file()
???:0
0xb38779 c_common_parse_file()
???:0
```

To reproduce quickly:

https://godbolt.org/z/a9eofno5j

[Bug ipa/120295] [15/16 Regression] Wrong code on -O3 for trunk version (live code is wrongly eliminated) since r15-6294-g96fb71883d438b

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Jambor  ---
Mine.

[Bug c/120303] [15/16 Regression] ICE , in groktypename at gcc/c/c-decl.cc:5442 with _Generic after an error

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||mario.rodriguezb1 at um dot es

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

[Bug c/120309] internal compiler error: Segmentation fault in groktypename since gcc 15.1

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

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

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

[Bug c++/115940] ICE: tree check: expected record_type or union_type or qual_union_type, have translation_unit_decl in maybe_dummy_object, at cp/tree.cc:4379

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

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

MARIO RODRIGUEZ BEJAR  changed:

   What|Removed |Added

 CC||mario.rodriguezb1 at um dot es

--- Comment #2 from MARIO RODRIGUEZ BEJAR  ---
This code arises same ICE 


```
typedef int instant;
double elapsed (instant this, instant second);
int main (int argc, char* argv[]) {
  instant now;
  elapsed (now, now + 100.0);
}
```

https://godbolt.org/z/Td78snfn9