[Bug demangler/68159] Demangler crash (GDB PR 19190)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68159 --- Comment #15 from Carlos Alberto Lopez Perez --- (In reply to H.J. Lu from comment #11) > *** Bug 68383 has been marked as a duplicate of this bug. *** Bug 68383 was fixed by r245978 So, this one is also fixed right ?
[Bug c++/68159] Demangler crash (GDB PR 19190)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68159
Carlos Alberto Lopez Perez changed:
What|Removed |Added
CC||clopez at igalia dot com
--- Comment #9 from Carlos Alberto Lopez Perez ---
This is still happening with last master from GDB as of today
(7.11.50.20160729-git)
$ echo 'void
_ZSt7forwardIRKZN5Write14DataMapGrammarISt20back_insert_iteratorISsEEC4EvEUlRT_E_EOS5_RNSt16remove_referenceIS5_E4typeE()
{} int main() {}' | gcc -xc - -o /tmp/a.out && gdb /tmp/a.out
GNU gdb (GDB) 7.11.50.20160729-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /tmp/a.out...cp-support.c:1600: demangler-warning: unable
to demangle
'_ZSt7forwardIRKZN5Write14DataMapGrammarISt20back_insert_iteratorISsEEC4EvEUlRT_E_EOS5_RNSt16remove_referenceIS5_E4typeE'
(demangler failed with signal 11)
Unable to dump core, use `ulimit -c unlimited' before executing GDB next time.
cp-support.c:1615: demangler-warning: unable to demangle
'_ZSt7forwardIRKZN5Write14DataMapGrammarISt20back_insert_iteratorISsEEC4EvEUlRT_E_EOS5_RNSt16remove_referenceIS5_E4typeE'
(demangler failed with signal 11)
A problem internal to GDB has been detected,
further debugging may prove unreliable.
[Bug c++/68159] Demangler crash (GDB PR 19190)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68159 --- Comment #10 from Carlos Alberto Lopez Perez --- It seems c++filt also crashes with the very same test case: $ echo '_ZSt7forwardIRKZN5Write14DataMapGrammarISt20back_insert_iteratorISsEEC4EvEUlRT_E_EOS5_RNSt16remove_referenceIS5_E4typeE'|c++filt Segmentation fault (core dumped)
[Bug c++/68159] Demangler crash (GDB PR 19190)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68159 --- Comment #13 from Carlos Alberto Lopez Perez --- (In reply to H.J. Lu from comment #12) > Created attachment 39042 [details] > A patch to avoid stack oveflow This fixes the issue with the previous test case. However, this other one (obtained from a coredump of WebKitGTK+) is still crashing: $ echo '_ZSt7forwardIRZZN6WebKit29NetworkConnectionToWebProcess26writeBlobsToTemporaryFilesERKN3WTF6VectorINS2_6StringELm0ENS2_15CrashOnOverflowELm16EEEmENUlRT_E_clIS7_EEDaSA_EUlvE_EOS9_RNSt16remove_referenceIS9_E4typeE' | c++filt Segmentation fault (core dumped)
[Bug c++/114997] New: ICE with -std=c++20: unexpected expression ‘static_cast('\"')’ of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114997
Bug ID: 114997
Summary: ICE with -std=c++20: unexpected expression
‘static_cast('\"')’ of kind
static_cast_expr
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: clopez at igalia dot com
Target Milestone: ---
Created attachment 58137
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58137&action=edit
preprocessed file from JSONObject.cpp to reproduce the problem
On the WebKit project recently this commit landed:
https://github.com/WebKit/WebKit/commit/4855c7a1dc4214523c0b3d0c430215456ed7a0a9
It caused GCC-12 to fail with an ICE.
./Source/JavaScriptCore/runtime/JSONObject.cpp: In lambda function:
./Source/JavaScriptCore/runtime/JSONObject.cpp:1124:89: internal compiler
error: unexpected expression ‘static_cast('\"')’ of kind
static_cast_expr
1124 | constexpr auto quoteMask =
WTF::splatBulk(static_cast('"'));
|
^
0x7ffb005ff1c9 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7ffb005ff284 __libc_start_main_impl
../csu/libc-start.c:360
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
I checked that it fails with the last released version of GCC 12 (12.3.0) both
from Yocto
when cross-building for ARM64 as well as the GCC 12.3.0 shipped in
Debian/testing.
On Debian I tested with gcc-13 and with it builds fine.
I'm attaching the .ii file to reproduce the problem (compressed with xz as it
is quite big)
To reproduce it, download the .ii file and simple execute this command:
g++-12 -O3 --std=c++20 -c JSONObject.ii
Not sure if useful information, but the original compiler command had the
following switches enabled
g++-12 -DBUILDING_JavaScriptCore -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1
-DBUILDING_WPE__=1 -DBWRAP_EXECUTABLE=\"/usr/bin/bwrap\"
-DDBUS_PROXY_EXECUTABLE=\"/usr/bin/xdg-dbus-proxy\" -DGETTEXT_PACKAGE=\"WPE\"
-DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED -DPAS_BMALLOC=1
-DPKGLIBDIR=\"/usr/local/lib/wpe-webkit-2.0\" -DSTATICALLY_LINKED_WITH_WTF
-DSTATICALLY_LINKED_WITH_bmalloc
[...-I/long/list/of/includes/excluded/for/clarity...]
-fdiagnostics-color=always -Wextra -Wall -fmax-errors=20 -Wno-odr
-Wno-stringop-overread -Wno-stringop-overflow -Wno-nonnull -Wno-array-bounds
-Wno-expansion-to-defined -Wno-noexcept-type -Wno-psabi
-Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef -Wpointer-arith
-Wmissing-format-attribute -Wformat-security -Wcast-align
-Wno-tautological-compare -fno-strict-aliasing -fno-exceptions -fno-rtti
-ffunction-sections -fdata-sections -O3 -DNDEBUG -fPIC -fvisibility=hidden
-fvisibility-inlines-hidden -ffp-contract=off -std=c++20 -c
Source/JavaScriptCore/runtime/JSONObject.cpp
[Bug c++/114997] ICE with -std=c++20: unexpected expression ‘static_cast('\"')’ of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114997 --- Comment #1 from Carlos Alberto Lopez Perez --- The original cpp file that causes the issue can be found here: https://raw.githubusercontent.com/WebKit/WebKit/4855c7a1dc4214523c0b3d0c430215456ed7a0a9/Source/JavaScriptCore/runtime/JSONObject.cpp just for reference, the md5hash of the file is $ md5sum Source/JavaScriptCore/runtime/JSONObject.cpp a4799453f1b2b3c0e2bec60a095c962d Source/JavaScriptCore/runtime/JSONObject.cpp
[Bug c++/114997] ICE with -std=c++20: unexpected expression ‘static_cast('\"')’ of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114997 --- Comment #2 from Carlos Alberto Lopez Perez --- On WebKit we finally work-arounded the problem by replacing `constexpr` with `const` at commit https://github.com/WebKit/WebKit/commit/1ee00a2309c03ed119e8591022ba14f936440d71
[Bug target/115135] New: [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants
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 +
+++ b/test.cpp 2024-05-17 12:32:45.957454704 +
@@ -81,13 +81,11 @@
[&](std::unique_ptr& 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& 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
[Bug middle-end/115135] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115135 --- Comment #2 from Carlos Alberto Lopez Perez --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115135 --- Comment #3 from Carlos Alberto Lopez Perez --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115135
--- Comment #4 from Carlos Alberto Lopez Perez ---
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 +
+++ b/test.cpp 2024-05-20 13:18:51.334943200 +
@@ -75,7 +75,7 @@
class mTest;
-int doTest(mTest& mObj, std::variant,
std::unique_ptr>&& dVar, std::shared_ptr aPtr, bTest bObj)
+int __attribute__ ((noinline)) doTest(mTest& mObj,
std::variant, std::unique_ptr>&& dVar,
std::shared_ptr aPtr, bTest bObj)
{
return switchOn(dVar,
[&](std::unique_ptr& 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115135 --- Comment #6 from Carlos Alberto Lopez Perez --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115135 --- Comment #7 from Carlos Alberto Lopez Perez --- 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 0xe610 points to 0xe4a7e2c0 which has value 10 [At initTest()] [DEBUG] bObj at 0xe61eeed0 has value 11 [At initTest()] [DEBUG] aPtr at 0xe61eeef0 points to 0xe4a7e2c0 which has value 10 [At doTest():aTest] [DEBUG] bObj at 0xe61eeed8 has value 11 [At doTest():aTest] [DEBUG] mObj at 0xe61eef68 [At doTest():aTest] [DEBUG] mObj at 0xe61eef68 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 0xd052ba00 points to 0xe95d02c0 which has value 10 [At initTest()] [DEBUG] bObj at 0xd052b9f0 has value 11 [At initTest()] [DEBUG] aPtr at 0xd052ba10 points to 0xd052bbc8 which has value -799881990 [At doTest():aTest] [DEBUG] bObj at 0xd052b9f8 has value -1136642444 [At doTest():aTest] [DEBUG] mObj at 0xd052ba48 [At doTest():aTest] [DEBUG] mObj at 0xd052ba48 has value -1936524422 [At main()] [ERROR] Something went wrong compiling the program!: mObj.m_data should be 33 but is -1936524422
[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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115135 --- Comment #9 from Carlos Alberto Lopez Perez --- (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.
