[Bug c++/125123] mangler issue with 'template for' and 'requires expr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125123 --- Comment #15 from GCC Commits --- The releases/gcc-16 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a880082f559dcc0d8c3bfd6c60e38cb3151eb0d9 commit r16-9033-ga880082f559dcc0d8c3bfd6c60e38cb3151eb0d9 Author: Jakub Jelinek Date: Sat May 30 17:49:18 2026 +0200 c++: Don't ICE on the static constexpr expansion-stmt vars during mangling [PR125123] The following testcase ICEs, because we decide to mangle the (for the time being as workaround static constexpr variables created for expansion statements). And if there is more than one in the same function and we mangle both, we ICE because they mangle the same. The problem is that cp_finish_decl does not determine_local_discriminator for DECL_ARTIFICIAL vars. The following patch fixes that by calling it even for DECL_ARTIFICIAL vars. The patch also sets DECL_IGNORED_P on those vars, I think there is no value exposing those in the debug information, the iterating is done at compile time and all user IMHO cares are the individual user variables initialized to whatever was derived from the temporaries. 2026-05-29 Jakub Jelinek PR c++/125123 * parser.cc (cp_build_range_for_decls): If range_temp or begin are static, set DECL_IGNORED_P on it. * pt.cc (finish_expansion_stmt): Similarly for iter. * decl.cc (cp_finish_decl): Call determine_local_discriminator etc. also for DECL_ARTIFICIAL TREE_STATIC vars. * g++.dg/cpp26/expansion-stmt42.C: New test. Reviewed-by: Jason Merrill (cherry picked from commit 833722e02b083a5828e0f7dbf67ae5456755f0de)
[Bug c++/125123] mangler issue with 'template for' and 'requires expr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125123 nurullahcitil1536 at gmail dot com changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from nurullahcitil1536 at gmail dot com --- I can confirm the issue is resolved(trunk) on my local and on godbolt example. I'll mark the bug report as resolved, if I can. godbolt seems to cached the original link. So I just changed what's get printed here, if anyone wants to take a look: https://godbolt.org/z/eKvKdq6f3
[Bug c++/125123] mangler issue with 'template for' and 'requires expr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125123 --- Comment #13 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:833722e02b083a5828e0f7dbf67ae5456755f0de commit r17-1041-g833722e02b083a5828e0f7dbf67ae5456755f0de Author: Jakub Jelinek Date: Sat May 30 17:49:18 2026 +0200 c++: Don't ICE on the static constexpr expansion-stmt vars during mangling [PR125123] The following testcase ICEs, because we decide to mangle the (for the time being as workaround static constexpr variables created for expansion statements). And if there is more than one in the same function and we mangle both, we ICE because they mangle the same. The problem is that cp_finish_decl does not determine_local_discriminator for DECL_ARTIFICIAL vars. The following patch fixes that by calling it even for DECL_ARTIFICIAL vars. The patch also sets DECL_IGNORED_P on those vars, I think there is no value exposing those in the debug information, the iterating is done at compile time and all user IMHO cares are the individual user variables initialized to whatever was derived from the temporaries. 2026-05-29 Jakub Jelinek PR c++/125123 * parser.cc (cp_build_range_for_decls): If range_temp or begin are static, set DECL_IGNORED_P on it. * pt.cc (finish_expansion_stmt): Similarly for iter. * decl.cc (cp_finish_decl): Call determine_local_discriminator etc. also for DECL_ARTIFICIAL TREE_STATIC vars. * g++.dg/cpp26/expansion-stmt42.C: New test. Reviewed-by: Jason Merrill
[Bug c++/125123] mangler issue with 'template for' and 'requires expr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125123 --- Comment #12 from nurullahcitil1536 at gmail dot com --- (In reply to Jakub Jelinek from comment #11) > It has been tested and is waiting for review, see > https://gcc.gnu.org/pipermail/gcc-patches/2026-May/717935.html Got it. Thank you for your patience as I don't really know how everything works around here. Also thanks for the great work
[Bug c++/125123] mangler issue with 'template for' and 'requires expr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125123 --- Comment #11 from Jakub Jelinek --- It has been tested and is waiting for review, see https://gcc.gnu.org/pipermail/gcc-patches/2026-May/717935.html
[Bug c++/125123] mangler issue with 'template for' and 'requires expr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125123 --- Comment #10 from nurullahcitil1536 at gmail dot com --- (In reply to Jakub Jelinek from comment #9) > Yes. I'm sorry, but that wasn't a yes/no question :d What I meant is: A-) Are we waiting for someone to test this and confirm it does work? --- OR --- B-) Are we waiting for some maintainer to approve the code into trunk? Like review the code If we are waiting for confirmation of fix, I could try building it locally
[Bug c++/125123] mangler issue with 'template for' and 'requires expr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125123 --- Comment #9 from Jakub Jelinek --- Yes.
[Bug c++/125123] mangler issue with 'template for' and 'requires expr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125123 --- Comment #8 from nurullahcitil1536 at gmail dot com --- (In reply to Jakub Jelinek from comment #7) > Created attachment 64547 [details] > gcc17-pr125123.patch > > Untested fix. Are we waiting for someone to test this or approve the patch into trunk?
[Bug c++/125123] mangler issue with 'template for' and 'requires expr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125123 --- Comment #7 from Jakub Jelinek --- Created attachment 64547 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=64547&action=edit gcc17-pr125123.patch Untested fix.
[Bug c++/125123] mangler issue with 'template for' and 'requires expr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125123
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|--- |16.2
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Last reconfirmed||2026-05-25
Status|UNCONFIRMED |ASSIGNED
--- Comment #6 from Jakub Jelinek ---
struct A
{
int a[2];
constexpr int const *begin () const { return a; }
constexpr int const *end () const { return a + 2; }
};
template
requires true
void
foo ()
{
template for (constexpr int i : A { 0, 1 })
;
template for (constexpr int i : A { 0, 1 })
;
}
template void foo ();
rejects even duplicate mangling of "__for_begin ", not just "__for_iter ".
The reason is that discriminators aren't tracked for DECL_ARTIFICIAL vars.
[Bug c++/125123] mangler issue with 'template for' and 'requires expr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125123
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org,
||jakub at gcc dot gnu.org
--- Comment #5 from Eric Gallager ---
(In reply to Kael Franco from comment #4)
> (In reply to nurullahcitil1536 from comment #0)
> > Compilation failure when a template for is used within a function with
> > requires expression. It doesn't matter what is the content of requires expr,
> > compilation always fails with mangler issues:
> > https://godbolt.org/z/7ef94vz6W
> > I think the problem was introduced recently, at most 1-2 months.
>
> (In reply to Alex from comment #2)
> > ```
> > struct my_array
> > {
> > int _arr[2];
> >
> > constexpr int const*
> > begin() const
> > { return _arr; }
> >
> > constexpr int const*
> > end() const
> > { return _arr + 2; }
> > };
> >
> > template
> > requires true
> > void f()
> > {
> > template for(constexpr int I : my_array{0, 1})
> > {
> >
> > }
> > }
> > template void f();
> > ```
>
> Both are caused by r16-8704-gf99c1d5c5d24bf
cc-ing author of that commit (Jakub)
[Bug c++/125123] mangler issue with 'template for' and 'requires expr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125123
--- Comment #4 from Kael Franco ---
(In reply to nurullahcitil1536 from comment #0)
> Compilation failure when a template for is used within a function with
> requires expression. It doesn't matter what is the content of requires expr,
> compilation always fails with mangler issues: https://godbolt.org/z/7ef94vz6W
> I think the problem was introduced recently, at most 1-2 months.
(In reply to Alex from comment #2)
> ```
> struct my_array
> {
> int _arr[2];
>
> constexpr int const*
> begin() const
> { return _arr; }
>
> constexpr int const*
> end() const
> { return _arr + 2; }
> };
>
> template
> requires true
> void f()
> {
> template for(constexpr int I : my_array{0, 1})
> {
>
> }
> }
> template void f();
> ```
Both are caused by r16-8704-gf99c1d5c5d24bf
[Bug c++/125123] mangler issue with 'template for' and 'requires expr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125123 --- Comment #3 from Alex --- Reproduced locally, requires -g, does not emit with -O2. I'm not sure what keyword for add for that.
[Bug c++/125123] mangler issue with 'template for' and 'requires expr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125123
Alex changed:
What|Removed |Added
CC||waffl3x at gcc dot gnu.org
--- Comment #2 from Alex ---
Further reduced without headers.
It should be noted that a minimal iota implementation exhibits the same
behavior, the array can be done in less code. Simply using a c-array
does not trigger the behavior.
I believe there are two bugs here. I don't think mangling should be
required in this case as `I` is not ODR used. However clearly mangling
is also bugged for cases where `I` is ODR used... although I'm not sure
that case is even allowed as I don't think `I` has static lifetime
technically speaking. I will have to double check the spec to be sure.
Thank you for the concise reproducer and notes. It made it much easier
to reduce it down to this version.
https://godbolt.org/z/jxrPafj3o
```
struct my_array
{
int _arr[2];
constexpr int const*
begin() const
{ return _arr; }
constexpr int const*
end() const
{ return _arr + 2; }
};
template
requires true
void f()
{
template for(constexpr int I : my_array{0, 1})
{
}
}
template void f();
```
[Bug c++/125123] mangler issue with 'template for' and 'requires expr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125123 --- Comment #1 from nurullahcitil1536 at gmail dot com --- Any updates? Do we at least know the reason? Why mangler even looking at consteval things? As far as I understand mangling is done for exporting symbols for linking or DLLs. This is a local variable that only executes at compile time...
