[Bug target/115135] New: [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants

[Bug target/115135] New: [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants

[clopez at igalia dot com]

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

            Bug ID: 115135
           Summary: [C++] GCC produces wrong code at certain inlining
                    levels on Aarch64 with -fno-exceptions, related to
                    lambdas and variants
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: clopez at igalia dot com
  Target Milestone: ---

Created attachment 58225
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58225&action=edit
Simplified test case to reproduce the issue on Aarch64. The program should
print OK at the end. Check the comments at the top on how to build it.

This issue has been detected on the WebKit project. The builds of some CI bots
of WPEWebKit for Aarch64 started to crash heavily recently.
We are currently using GCC-12, but the issue happens also with newer GCC
versions. I tested and I can reproduce the issue with GCC-13 and GCC-14.

The original bug report is here: https://bugs.webkit.org/show_bug.cgi?id=273703
and further discussion is at: https://github.com/WebKit/WebKit/pull/28117

After quite a bit of effort I managed to create a simplified test case of only
a hundred lines. I'm attaching the test-case here.

If you build the test case and everything goes as expected you should see this:

intel-64:~# g++ -O3 -fno-exceptions test.cpp && ./a.out
[DEBUG] aPtr at 0x7ffd042c5080 points to 0x55e26078eec0 which has value 10 [At
initTest()]
[DEBUG] bObj at 0x7ffd042c5078 has value 11 [At initTest()]
[DEBUG] aPtr at 0x7ffd042c5090 points to 0x55e26078eec0 which has value 10 [At
doTest():aTest]
[DEBUG] bObj at 0x7ffd042c507c has value 11 [At doTest():aTest]
[DEBUG] mObj at 0x7ffd042c50cc [At doTest():aTest]
[DEBUG] mObj at 0x7ffd042c50cc has value 33 [At main()]

[OK] Everything went as expected. Program compiled correctly :)

So the program checks itself that everything was calculated as expected. It
reports OK if everything works as it should. Which is for example, what you see
if you build the program on x86_64

However, if you try this on Aarch64 you see something like this:

raspberrypi4-64:~# g++ -O3 -fno-exceptions test.cpp && ./a.out
[DEBUG] aPtr at 0x7fec013cb0 points to 0x55cf43cec0 which has value 10 [At
initTest()]
[DEBUG] bObj at 0x7fec013ca0 has value 11 [At initTest()]
[DEBUG] aPtr at 0x7fec013cc0 points to 0x5590b2fd20 which has value -1867445184
[At doTest():aTest]
[DEBUG] bObj at 0x7fec013ca8 has value -2006561636 [At doTest():aTest]
[DEBUG] mObj at 0x7fec013cf8 [At doTest():aTest]
[DEBUG] mObj at 0x7fec013cf8 has value 420960488 [At main()]

[ERROR] Something went wrong compiling the program!:  mObj.m_data should be 33
but is 420960488

The program ends with error, because the last two function parameters that the
doTest() function receives (aPtr and bObj) are messed up when passed into the
lambda.
It seems to me that is like the compiler somehow misses the initialization of
those function parameters (pass-by-value in this case) when the doTest()
function is called if those parameters are not used on the main body of the
function, but only inside the lambda.

What is even more amazing, is that if you comment out the third printfs() that
print the address of mObj inside the lambda then the program works correctly.

In other words, basically apply this patch to the program:

--- a/test.cpp  2024-05-17 12:12:50.561903072 +0000
+++ b/test.cpp  2024-05-17 12:32:45.957454704 +0000
@@ -81,13 +81,11 @@
         [&](std::unique_ptr<aTest>& ptr_a) -> int {
             printf("[DEBUG] aPtr at %p points to %p which has value %d [At
doTest():aTest]\n", &aPtr, aPtr.get(), aPtr->m_data);
             printf("[DEBUG] bObj at %p has value %d [At doTest():aTest]\n",
&bObj, bObj.m_data);
-            printf("[DEBUG] mObj at %p [At doTest():aTest]\n", &mObj);
             return aPtr->m_data + ptr_a->m_data + bObj.m_data;
         },
         [&](std::unique_ptr<bTest>& ptr_b) -> int {
             printf("[DEBUG] aPtr at %p points to %p which has value %d [At
doTest():bTest]\n", &aPtr, aPtr.get(), aPtr->m_data);
             printf("[DEBUG] bObj at %p has value %d [At doTest():bTest]\n",
&bObj, bObj.m_data);
-            printf("[DEBUG] mObj at %p [At doTest():bTest]\n", &mObj);
             return aPtr->m_data + ptr_b->m_data + bObj.m_data;
         });
 }


And then it works.. why? It makes zero sense to me.
Note that mObj is not used on the calculation returned, so it shouldn't even
need to be captured into the lambda for the program to work.

Inside the test code example there are some comments at the top about different
switches on how to compile it to reproduce the error.

The issue is only reproducible on Aarch64.
And I reproduced with gcc-12, gcc-13 and gcc-14 both on a Debian system as well
on a Yocto/OpenEmbedded based system. Both on Aarch64.

Note: To the best of my understanding there is no undefined behaviour or
dangling references here, as the lambda should finish the execution before the
function doTest() ends and those function parameters that were passed into the
lambda by reference go out of scope.
Another fun thing: if you pass -fsanitize=undefined then the program works
correctly

[Bug middle-end/115135] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Does either -fno-ivopts or -fno-ipa-modref help?

[Bug middle-end/115135] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants

[clopez at igalia dot com]

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

--- Comment #2 from Carlos Alberto Lopez Perez <clopez at igalia dot com> ---
(In reply to Andrew Pinski from comment #1)
> Does either -fno-ivopts or -fno-ipa-modref help?

-fno-ivopts does not help

-fno-ipa-modref helps! passing this flag makes the compiled program is correct
:)

[Bug middle-end/115135] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants

[clopez at igalia dot com]

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

--- Comment #3 from Carlos Alberto Lopez Perez <clopez at igalia dot com> ---
Note: I just tested to build GCC from master branch (version 15.0.0 20240520:
commit e14c673ea9ab2eca5de4db91b478f0b5297ef321) and the issue is still
reproducible with it.

[Bug middle-end/115135] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants

[clopez at igalia dot com]

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

--- Comment #4 from Carlos Alberto Lopez Perez <clopez at igalia dot com> ---
FYI: Another way to workaround the issue and make the test pass is to tell GCC
to not in-line the function doTest().

--- a/test.cpp  2024-05-17 03:15:07.275473492 +0000
+++ b/test.cpp  2024-05-20 13:18:51.334943200 +0000
@@ -75,7 +75,7 @@
 class mTest;


-int doTest(mTest& mObj, std::variant<std::unique_ptr<aTest>,
std::unique_ptr<bTest>>&& dVar, std::shared_ptr<aTest> aPtr, bTest bObj)
+int __attribute__ ((noinline)) doTest(mTest& mObj,
std::variant<std::unique_ptr<aTest>, std::unique_ptr<bTest>>&& dVar,
std::shared_ptr<aTest> aPtr, bTest bObj)
 {
     return switchOn(dVar,
         [&](std::unique_ptr<aTest>& ptr_a) -> int {

[Bug ipa/115135] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |ipa

--- Comment #5 from Sam James <sjames at gcc dot gnu.org> ---
(In reply to Carlos Alberto Lopez Perez from comment #2)
> -fno-ipa-modref helps! passing this flag makes the compiled program is
> correct :)

-> calling it an IPA issue.

Carlos, if you can find a version which worked before, could you bisect?

[Bug ipa/115135] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants

[clopez at igalia dot com]

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

--- Comment #6 from Carlos Alberto Lopez Perez <clopez at igalia dot com> ---
(In reply to Sam James from comment #5)
> (In reply to Carlos Alberto Lopez Perez from comment #2)
> > -fno-ipa-modref helps! passing this flag makes the compiled program is
> > correct :)
> 
> -> calling it an IPA issue.
> 
> Carlos, if you can find a version which worked before, could you bisect?

Unfortunately all versions of GCC that I tested fail.

I even tested with a nightly build of GCC (built yesterday at version 15.0.0
20240520 from GCC commit e14c673ea9ab2eca5de4db91b478f0b5297ef321). It also
fails.

[Bug ipa/115135] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants

[clopez at igalia dot com]

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

--- Comment #7 from Carlos Alberto Lopez Perez <clopez at igalia dot com> ---
Well, I just tested with gcc-11 now and that one works.
So the failure was introduced between 11 and 12.

$ g++-11 --version
g++-11 (Debian 11.3.0-12) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++-11 -std=c++20 -O3 -fno-exceptions test.cpp && ./a.out
[DEBUG] aPtr at 0xffffe61eeee0 points to 0xaaaae4a7e2c0 which has value 10 [At
initTest()]
[DEBUG] bObj at 0xffffe61eeed0 has value 11 [At initTest()]
[DEBUG] aPtr at 0xffffe61eeef0 points to 0xaaaae4a7e2c0 which has value 10 [At
doTest():aTest]
[DEBUG] bObj at 0xffffe61eeed8 has value 11 [At doTest():aTest]
[DEBUG] mObj at 0xffffe61eef68 [At doTest():aTest]
[DEBUG] mObj at 0xffffe61eef68 has value 33 [At main()]

[OK] Everything went as expected. Program compiled correctly :)


$ g++-12 --version
g++-12 (Debian 12.2.0-14) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++-12 -std=c++20 -O3 -fno-exceptions test.cpp && ./a.out
[DEBUG] aPtr at 0xffffd052ba00 points to 0xaaaae95d02c0 which has value 10 [At
initTest()]
[DEBUG] bObj at 0xffffd052b9f0 has value 11 [At initTest()]
[DEBUG] aPtr at 0xffffd052ba10 points to 0xffffd052bbc8 which has value
-799881990 [At doTest():aTest]
[DEBUG] bObj at 0xffffd052b9f8 has value -1136642444 [At doTest():aTest]
[DEBUG] mObj at 0xffffd052ba48 [At doTest():aTest]
[DEBUG] mObj at 0xffffd052ba48 has value -1936524422 [At main()]

[ERROR] Something went wrong compiling the program!:  mObj.m_data should be 33
but is -1936524422

[Bug ipa/115135] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants

[sjames at gcc dot gnu.org]

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

--- Comment #8 from Sam James <sjames at gcc dot gnu.org> ---
(godbolt is great for this, btw)

[Bug ipa/115135] [12/13/14/15 regression] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants

[clopez at igalia dot com]

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

--- Comment #9 from Carlos Alberto Lopez Perez <clopez at igalia dot com> ---
(In reply to Sam James from comment #8)
> (godbolt is great for this, btw)

good idea. I tried it but for target ARM64 it doesn't allow to execute the
code, only see the generated assembly. And I'm not versed enough on reading
assembly to easily spot the issue there.

[Bug ipa/115135] [12/13/14/15 regression] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants since r12-5113-gd70ef65692fced

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[12/13/14/15 regression]    |[12/13/14/15 regression]
                   |[C++] GCC produces wrong    |[C++] GCC produces wrong
                   |code at certain inlining    |code at certain inlining
                   |levels on Aarch64 with      |levels on Aarch64 with
                   |-fno-exceptions, related to |-fno-exceptions, related to
                   |lambdas and variants        |lambdas and variants since
                   |                            |r12-5113-gd70ef65692fced

--- Comment #10 from Sam James <sjames at gcc dot gnu.org> ---
r12-5113-gd70ef65692fced is the first bad commit
commit r12-5113-gd70ef65692fced
Author: Jan Hubicka <jh@suse.cz>
Date:   Wed Nov 10 13:08:41 2021 +0100

    Make EAF flags more regular (and expressive)
[...]