[Bug c++/124120] ICE in write_unqualified_name, at cp/mangle.cc:1535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124120 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug c++/124120] ICE in write_unqualified_name, at cp/mangle.cc:1535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124120 --- Comment #8 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f99c1d5c5d24bf343cf19b487b774e3ab497b145 commit r16-8704-gf99c1d5c5d24bf343cf19b487b774e3ab497b145 Author: Jakub Jelinek Date: Thu Apr 16 15:51:04 2026 +0200 c++: Fix up expansion-stmt mangling ICE [PR124120] One of the reflect/* tests ICEs on Solaris but not on Linux (at least not when using recent glibc). I've tracked it down to a problem with expansion statements, due to the workaround we have for missing part of P2686R4 where we make some artificial vars static. Some of them (the __for_range and __for_begin) have DECL_NAMEs (with a space in it) and so even when they are static, don't cause problems. But the iter variable (in https://eel.is/c++draft/stmt.expand#5.2 ) is when constexpr still static and was nameless. Now, because it is constexpr and not odr used, it is optimized out, but if the TU also contains weakref attribute or something else that requires cgraph to construct assembler_name_hash, we ICE when trying to mangle the iter nameless variable. The following patch fixes that by giving it yet another artificial name. 2026-04-16 Jakub Jelinek PR c++/124120 * pt.cc (finish_expansion_stmt): Give iter variable an artificial name. * g++.dg/cpp26/expansion-stmt40.C: New test. Reviewed-by: Jason Merrill
[Bug c++/124120] ICE in write_unqualified_name, at cp/mangle.cc:1535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124120 --- Comment #7 from Jakub Jelinek --- Created attachment 64214 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=64214&action=edit gcc16-pr124120.patch Untested fix.
[Bug c++/124120] ICE in write_unqualified_name, at cp/mangle.cc:1535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124120
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
Reduced testcase:
// C++26 P1306R5 - Expansion statements
// { dg-do run { target c++14 } }
// { dg-require-weak "" }
// { dg-options "" }
struct A
{
int x;
constexpr explicit A (int v) : x(v) {}
constexpr A &operator ++ () { ++x; return *this; }
constexpr int operator * () const { return x; }
constexpr bool operator != (const A &o) const { return x != o.x; }
constexpr A operator + (int o) const { A r (x + o); return r; }
constexpr int operator - (const A &o) const { return x - o.x; }
};
namespace N
{
struct B { constexpr B () {} };
constexpr A begin (const B &) { return A (0); }
constexpr A end (const B &) { return A (6); }
}
int
bar ()
{
int r = 0;
template for (constexpr auto i : N::B {}) // { dg-warning
"'template for' only available with" "" { target c++23_down } }
r += i;
return r;
}
extern void plugh ();
[[gnu::weakref ("plugh")]] static void xyzzy ();
void
plugh ()
{
}
This ICEs even on x86_64-linux. The reason for the ICE on p3491-2.C on just
some targets and not others is whether weakrefs appear in the IL or not. If
they do, gcc attempts to construct assembler_name_hash and tries to mangle even
the nameless expansion stmt decls.
[Bug c++/124120] ICE in write_unqualified_name, at cp/mangle.cc:1535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124120 Thomas Schwinge changed: What|Removed |Added Last reconfirmed||2026-04-14 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||tschwinge at gcc dot gnu.org --- Comment #5 from Thomas Schwinge --- For the record, I'm seeing this ICE also on x86_64-pc-linux-gnu, with bootstrap build in a Ubuntu 20.04 "focal" container -- but not with bootstrap build on Debian 12 "bookworm", and neither with non-bootstrap builds on Ubuntu 22.04 "jammy" or Debian "testing", for example.
[Bug c++/124120] ICE in write_unqualified_name, at cp/mangle.cc:1535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124120 Rainer Orth changed: What|Removed |Added Target|*-*-solaris2.11 |*-*-solaris2.11, ||m68k-unknown-linux-gnu, ||x86_64-unknown-freebsd13.5 --- Comment #4 from Rainer Orth --- Also happens on FreeBSD/amd64 and Linux/m68k.
[Bug c++/124120] ICE in write_unqualified_name, at cp/mangle.cc:1535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124120
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jakub Jelinek ---
> Could you please upload preprocessed source?
Sure, done.
> Does it ICE if you comment out the error in the test, i.e.
> consteval void bar() {
> -template for (constexpr int I : foo()) {
> +//template for (constexpr int I : foo()) {
> // doesn't work
> -} // { dg-error "'foo\\\(\\\)' is not a constant expression
> because it refers to a result of 'operator new'" }
> +//}// { dg-error "'foo\\\(\\\)' is not a constant
> expression because it refers to a result of 'operator new'" }
> }
> ? If not, then it would be ice-on-invalid or error-recovery. Still, that
> line
> in the mangler isn't called at all when testing this on Linux.
It ICEs just the same.
[Bug c++/124120] ICE in write_unqualified_name, at cp/mangle.cc:1535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124120 --- Comment #2 from Rainer Orth --- Created attachment 63700 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=63700&action=edit preprocessed input
[Bug c++/124120] ICE in write_unqualified_name, at cp/mangle.cc:1535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124120
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Could you please upload preprocessed source?
Does it ICE if you comment out the error in the test, i.e.
consteval void bar() {
-template for (constexpr int I : foo()) {
+//template for (constexpr int I : foo()) {
// doesn't work
-} // { dg-error "'foo\\\(\\\)' is not a constant expression
because it refers to a result of 'operator new'" }
+//}// { dg-error "'foo\\\(\\\)' is not a constant
expression because it refers to a result of 'operator new'" }
}
? If not, then it would be ice-on-invalid or error-recovery. Still, that line
in the mangler isn't called at all when testing this on Linux.
[Bug c++/124120] ICE in write_unqualified_name, at cp/mangle.cc:1535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124120 Rainer Orth changed: What|Removed |Added Target Milestone|--- |16.0
