https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122268
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #1)
> Does it ICE before that commit with -ftrivial-auto-var-init=zero?
[with mainline - just with r16-4212-gf256a13f8aed83 'patch -R'ed:]
Using -ftrivial-auto-var-init=zero has no effect on the result.
BTW: GCC 15 behaves identical to mainline before that commit: ICE in
gcn/nvptx lto1 for -O0, but not for -O1 or higher and
-ftrivial-auto-var-init=zero has no effect.
And, for completes, using -ftrivial-auto-var-init=uninitialized on
mainline with that commit also doesn't avoid the ICE.
(In reply to Jakub Jelinek from comment #2)
> Though, if it really shows up with -std=c++23 and not -std=c++26
Yes, I specified it for manual testing – and it shows up as regression in our
weekly cron-based testing and the test has:
/* { dg-additional-options -std=c++23 } */
> and if
> -ftrivial-auto-var-init=* isn't used, then I wonder what has changed,
> because the patch really should only change behavior of
> -std=c++26/-std=gnu++26 or -ftrivial-auto-var-init=*.
(No idea. Seems as if something is different; whether relevant or only
triggering a/the preexisting issue is the question.)
