[Bug c++/87207] ODR issue with static functions and lambda templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87207 --- Comment #6 from blastrock at free dot fr --- Great, thanks!
[Bug c++/87207] ODR issue with static functions and lambda templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87207
--- Comment #2 from blastrock at free dot fr ---
This seems to be due to this symbol in each .o file:
W
shared::shared(toto()::{lambda()#1}&&)::{lambda()#1}>(toto()::{lambda()#1})::{lambda()#1}::~shared()
It is weak and global, but I think it should be local since it depends on
toto() which is static.
[Bug c++/87207] ODR issue with static functions and lambda templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87207 --- Comment #1 from blastrock at free dot fr --- Created attachment 44653 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44653=edit output of gcc -v when compiling the test case
[Bug c++/87207] New: ODR issue with static functions and lambda templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87207 Bug ID: 87207 Summary: ODR issue with static functions and lambda templates Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: blastrock at free dot fr Target Milestone: --- Created attachment 44652 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44652=edit Small reproduction test case I have a library that instantiates a chain of class templates and lambda templates. I have two files with a static function that has the same name, but by being static they should not interfere with each other. It seems that gcc generates and exports a symbol depending on this static function, and the linker only keeps one instance of it, making the other instantiation wrong. I have prepared a small reproduction test case. The String class is initialized to 0 and asserts that it still contains 0 in its destructor. Moreover, it prints the addresses where it is constructed and destroyed. When compiling this project with any GCC version from Ubuntu (tested on Ubuntu 18.04, with GCC 6, 7 and 8), it will crash. I couldn't reproduce the issue on Debian. I tried adding the stack-protector and fortify flags that are enabled by default on Ubuntu but couldn't reproduce the bug on Debian. The output is: new 0x7ffcb217a6a8 new 0x7ffcb217a648 delete 0x7ffcb217a660 terminate called after throwing an instance of 'int' Aborted (core dumped) Removing the `async_resumable` instantiation from bunny.cpp (which is code that is never called) will make main.cpp work. The test case is attached.
[Bug preprocessor/85211] -isystem automatically adds extern "C" to includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85211 --- Comment #7 from blastrock at free dot fr --- You are right, my bad. I managed to build it by adding the definition in gcc/config/arm/arm.h . My initial suggestion was to mention that behavior in the documentation, but if you think it is not worth it, I guess you can close this bug. Thanks anyway for your help!
[Bug preprocessor/85211] -isystem automatically adds extern "C" to includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85211 --- Comment #5 from blastrock at free dot fr --- I tried using their recipe to rebuild gcc. The configure line is the following: $ /media/usb1/vitasdkbuild/build/gcc-final-prefix/src/gcc-final/configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-vita-eabi --prefix=/media/usb1/vitasdkbuild/build/vitasdk --libdir=/media/usb1/vitasdkbuild/build/vitasdk/lib --libexecdir=/media/usb1/vitasdkbuild/build/vitasdk/lib --with-sysroot=/media/usb1/vitasdkbuild/build/vitasdk/arm-vita-eabi --with-gmp=/media/usb1/vitasdkbuild/build/deps_build --with-mpfr=/media/usb1/vitasdkbuild/build/deps_build --with-mpc=/media/usb1/vitasdkbuild/build/deps_build --with-isl=/media/usb1/vitasdkbuild/build/deps_build --with-libelf=/media/usb1/vitasdkbuild/build/deps_build --with-python-dir=share/gcc-arm-vita-eabi --enable-languages=c,c++ --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --disable-multilib --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=neon --with-float=hard --with-mode=thumb --with-pkgversion=GNU Tools for ARM Embedded Processors --with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm --with-headers=yes --enable-threads=posix You can see --with-newlib in there. However I can confirm that NO_IMPLICIT_EXTERN_C is not defined as I tried inserting broken code in the #ifndef NO_IMPLICIT_EXTERN_C in parser.c and it did break compilation. So is this a regression since #37727 was fixed?
[Bug preprocessor/85211] -isystem automatically adds extern "C" to includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85211 --- Comment #2 from blastrock at free dot fr --- I think it would be nice to mention it in the documentation as it was in version 6. And I was hoping for a way to disable it at runtime, recompiling gcc seems quite complex...
[Bug preprocessor/85211] New: -isystem automatically adds extern "C" to includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85211 Bug ID: 85211 Summary: -isystem automatically adds extern "C" to includes Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: blastrock at free dot fr Target Milestone: --- This is a very old problem documented in GCC 6: https://gcc.gnu.org/onlinedocs/gcc-6.4.0/cpp/System-Headers.html#System-Headers (see the last paragraph) However that part was removed from the documentation in GCC 7: https://gcc.gnu.org/onlinedocs/gcc-7.3.0/cpp/System-Headers.html#System-Headers I would suggest putting it back since that legacy behavior is still present. Also, it would be nice to have a documented way to opt out from it. If it is of any importance, I have that problem with the g++ compiled in the vitasdk ( https://github.com/vitasdk/autobuilds/releases/download/master-linux-v771/vitasdk-x86_64-linux-gnu-2018-04-02_17-48-36.tar.bz2 ) that should have been built with the following script: https://github.com/vitasdk/buildscripts/blob/master/CMakeLists.txt . The target arch is arm-vita-eabi.
[Bug other/70517] c++filt crashes when demangling a symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70517 blastrock at free dot fr changed: What|Removed |Added Attachment #38165|0 |1 is obsolete|| Attachment #38166|0 |1 is obsolete|| --- Comment #3 from blastrock at free dot fr --- Created attachment 38418 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38418=edit Very small test case I investigated this bug a little more and managed to produce a very small test case. Compile this file with g++ 5.3.1 and clang 3.8 and you will get these two symbols: _Z4moveIRZ5awaitIRiEDaOT_EUlRKS3_E_ES4_S4_ from clang _Z4moveIRZ5awaitIRiEDaOT_EUlRKS2_E_ES3_S3_ from gcc When trying c++filt on the one got from gcc, it will just fail demangling it and print it raw. But when we do it with the one produced by clang, we get a crash. The only difference I see there is the substitutions which are shifted by one on the clang version (I have no idea which compiler is right though). I enabled the debug stuff from the demangle binary in libiberty and got this (I added the addresses of the nodes for debugging): 0x7fffd620: typed name 0x7fffd5d8: template 0x7fffd410: name 'move' 0x7fffd5c0: template argument list 0x7fffd5a8: reference 0x7fffd590: local name 0x7fffd518: typed name 0x7fffd488: template 0x7fffd428: name 'await' 0x7fffd470: template argument list 0x7fffd458: reference 0x7fffd440: builtin type int 0x7fffd500: function type 0x7fffd4a0: name 'auto' 0x7fffd4e8: argument list 0x7fffd4d0: rvalue reference 0x7fffd4b8: template parameter 0 0x7fffd578: lambda 0 0x7fffd560: argument list 0x7fffd548: reference 0x7fffd530: const 0x7fffd4d0: rvalue reference 0x7fffd4b8: template parameter 0 0x7fffd608: function type 0x7fffd530: const 0x7fffd4d0: rvalue reference 0x7fffd4b8: template parameter 0 0x7fffd5f0: argument list 0x7fffd530: const 0x7fffd4d0: rvalue reference 0x7fffd4b8: template parameter 0 What I understand is that when libiberty goes down the first branch, the "template parameter 0" references this same branch and so we get infinite recursion. I guess we can at least prevent the crash if we keep in the state a variable saying which template parameter we are referencing so that we don't go down the same path infinitely. My (de)mangling skills are still very low and I don't think I can solve this one alone. Any help is appreciated.
[Bug other/70517] c++filt crashes when demangling a symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70517 --- Comment #2 from blastrock at free dot fr --- Created attachment 38166 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38166=edit preprocessed file by gcc 5.3.1
[Bug other/70517] c++filt crashes when demangling a symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70517 --- Comment #1 from blastrock at free dot fr --- Created attachment 38165 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38165=edit preprocessed file by clang 3.8
[Bug other/70517] New: c++filt crashes when demangling a symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70517 Bug ID: 70517 Summary: c++filt crashes when demangling a symbol Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: blastrock at free dot fr Target Milestone: --- The following command always crashes: c++filt _ZSt4moveIRZN11tconcurrent6futureIvE4thenIZ5awaitIS2_EDaOT_EUlRKS6_E_EENS1_INSt5decayIDTclfp_defpTEEE4typeEEES7_EUlvE_EONSt16remove_referenceIS6_E4typeES7_ I have been told to report the bug here. This may be a duplicate of #67375. I am attaching the preprocessed file (by clang) that generates the symbol which triggers the bug. Compile it with: clang++ test_coroutine2.ii -c -std=c++14 with clang 3.8 (I haven't tested other versions). You can then trigger the bug with: objdump -C -t test_coroutine2.o The bug does not appear when the file is compiled with GCC. I am attaching the .ii generated by GCC too in case you need it. I am not sure, but shouldn't clang and gcc generate the same symbol names? Does this hide another bug in one of these compilers?
[Bug c++/70121] New: spurious warning and crash when returning a reference from lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70121
Bug ID: 70121
Summary: spurious warning and crash when returning a reference
from lambda
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blastrock at free dot fr
Target Milestone: ---
When I try to compile this simple program with gcc 5.3.1:
#include
int main(int argc, char *argv[])
{
const int val = 28;
auto ff = [&]() -> const int& { return val; };
int i = ff();
}
with the argument -std=c++11, I get the following warning:
warning: returning reference to temporary [-Wreturn-local-addr]
And the program crashes on the int assign statement.
I believe this code is legal, the temporary variable is still valid when the
lambda is called. And the same code compiles without warning and runs without
crash with clang 3.7.
