| Message ID | AANLkTiknGYnQ5UR+QHTx-vVCCbEZXH4+FkZA7ZiZe0tP@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On Mon, Jan 17, 2011 at 8:16 PM, Kai Tietz <ktietz70@googlemail.com> wrote: > Hello, > > By running for x86_64-w64-mingw32 target g++.dg's testsuite > (torture/stackalign/stackalign.exp) > I noticed that some LTO tests are failing due unresolved symbols, > which are part of libstc++. > By this I found that c++ driver did not add for enabled linker-plugin > linker-specific option > -plugin-opt=-pass-through=-l<library-name> for libstdc++ and libm.a. > > 2011-01-17 Kai Tietz > > * g++spec.c (lang_specific_driver): Add > linker specific options for libstdc++/libm when > LTO and linker-plugin are used. > > > Tested for x86_64-pc-linux-gnu and x86_64-w64-mingw32. Ok for apply? I don't think we introduce new symbol references to libstdc++. libm should be already handled, but there is an ongoing (but stalled) discussion as how to go forward with several other libs as well (libgcov and libgomp come to my mind here). So, I don't think the patch should go in without resolving that previous discussion. Richard. > > Regards, > Kai >
2011/1/17 Richard Guenther <richard.guenther@gmail.com>: > On Mon, Jan 17, 2011 at 8:16 PM, Kai Tietz <ktietz70@googlemail.com> wrote: >> Hello, >> >> By running for x86_64-w64-mingw32 target g++.dg's testsuite >> (torture/stackalign/stackalign.exp) >> I noticed that some LTO tests are failing due unresolved symbols, >> which are part of libstc++. >> By this I found that c++ driver did not add for enabled linker-plugin >> linker-specific option >> -plugin-opt=-pass-through=-l<library-name> for libstdc++ and libm.a. >> >> 2011-01-17 Kai Tietz >> >> * g++spec.c (lang_specific_driver): Add >> linker specific options for libstdc++/libm when >> LTO and linker-plugin are used. >> >> >> Tested for x86_64-pc-linux-gnu and x86_64-w64-mingw32. Ok for apply? > > I don't think we introduce new symbol references to libstdc++. libm should > be already handled, but there is an ongoing (but stalled) discussion as how > to go forward with several other libs as well (libgcov and libgomp > come to my mind here). > > So, I don't think the patch should go in without resolving that > previous discussion. > > Richard. > >> >> Regards, >> Kai >> > Well, for C case we have for linker-plugin in gcc.c the LINK_COMMAND_SPEC part %{"PLUGIN_COND": \ -plugin %(linker_plugin_file) \ -plugin-opt=%(lto_wrapper) \ -plugin-opt=-fresolution=%u.res \ %{!nostdlib:%{!nodefaultlibs:%:pass-through-libs(%(link_gcc_c_sequence))}} \ }"PLUGIN_COND_CLOSE" \ %{flto|flto=*:%<fcompare-debug*} \ but sadly, we don't see here in spec the language-hook (g++spec.c) added libstdc++ and (if not before present) added libm . In fact the operation of pass_through_libs_spec_func() in gcc could be called on completed argument list (with lang-part and the other libraries as user ones, too) before calling linker, if linker-plugin is used. This would at least solve for now most of the rescan issues for libraries caused by linker-plugin. I saw this discussion about avoiding rescan (and indeed it is reasonable), but as you already mentioned, it somehow stucked and no real decission was found. Kai
Richard Guenther <richard.guenther@gmail.com> writes: > On Mon, Jan 17, 2011 at 8:16 PM, Kai Tietz <ktietz70@googlemail.com> wrote: >> By running for x86_64-w64-mingw32 target g++.dg's testsuite >> (torture/stackalign/stackalign.exp) >> I noticed that some LTO tests are failing due unresolved symbols, >> which are part of libstc++. What symbols are these, and where are they being introduced? Ian
Kai Tietz <ktietz70@googlemail.com> writes: > I saw this discussion about avoiding rescan (and indeed it is > reasonable), but as you already mentioned, it somehow stucked and no > real decission was found. Nobody has commented on that discussion other than H.J. and myself, and we have diametrically opposed opinions. I would prefer if somebody else would consider the issue as well. Ian
> Kai Tietz <ktietz70@googlemail.com> writes: > > > I saw this discussion about avoiding rescan (and indeed it is > > reasonable), but as you already mentioned, it somehow stucked and no > > real decission was found. > > Nobody has commented on that discussion other than H.J. and myself, and > we have diametrically opposed opinions. I would prefer if somebody else > would consider the issue as well. It is still on my TODO, will try to get into it tomorrow. For libstdc++ I think we should never autogenerate references, so we need to debug from where the undefined references are comming. Honza > > Ian
2011/1/18 Jan Hubicka <hubicka@ucw.cz>: >> Kai Tietz <ktietz70@googlemail.com> writes: >> >> > I saw this discussion about avoiding rescan (and indeed it is >> > reasonable), but as you already mentioned, it somehow stucked and no >> > real decission was found. >> >> Nobody has commented on that discussion other than H.J. and myself, and >> we have diametrically opposed opinions. I would prefer if somebody else >> would consider the issue as well. > > It is still on my TODO, will try to get into it tomorrow. > > For libstdc++ I think we should never autogenerate references, so we need to debug > from where the undefined references are comming. > > Honza >> >> Ian > The testsuite failures are like that (the same testcases without LTO works as expected). Executing on host: /vol/d/source/gcc-svn/build64/gcc/testsuite/g++/../../g++ -B/vol/d/source/gcc-svn/build64/gcc/testsuite/g++/../../ /vol/d/home_kai/source/gcc-svn/gcc/gcc/testsuite/g++.dg/torture/stackalign/eh-alloca-1.C -nostdinc++ -I/vol/d/home_kai/source/gcc-svn/build64/x86_64-pc-mingw32/libstdc++-v3/include/x86_64-pc-mingw32 -I/vol/d/home_kai/source/gcc-svn/build64/x86_64-pc-mingw32/libstdc++-v3/include -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/libsupc++ -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/include/backward -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -flto -flto-partition=none -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs -B/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libiberty -lm -o ./eh-alloca-1.exe (timeout = 300) spawn /vol/d/source/gcc-svn/build64/gcc/testsuite/g++/../../g++ -B/vol/d/source/gcc-svn/build64/gcc/testsuite/g++/../../ /vol/d/home_kai/source/gcc-svn/gcc/gcc/testsuite/g++.dg/torture/stackalign/eh-alloca-1.C -nostdinc++ -I/vol/d/home_kai/source/gcc-svn/build64/x86_64-pc-mingw32/libstdc++-v3/include/x86_64-pc-mingw32 -I/vol/d/home_kai/source/gcc-svn/build64/x86_64-pc-mingw32/libstdc++-v3/include -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/libsupc++ -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/include/backward -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -flto -flto-partition=none -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs -B/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libiberty -lm -o ./eh-alloca-1.exe /vol/c/TEMP/ccJabJVm.lto.o:ccyL0UuP.o:(.text+0x10): undefined reference to `__gxx_personality_sj0' /vol/c/TEMP/ccJabJVm.lto.o:ccyL0UuP.o:(.text.startup+0x6e): undefined reference to `__gxx_personality_sj0' collect2: ld returned 1 exit status compiler exited with status 1 output is: /vol/c/TEMP/ccJabJVm.lto.o:ccyL0UuP.o:(.text+0x10): undefined reference to `__gxx_personality_sj0' /vol/c/TEMP/ccJabJVm.lto.o:ccyL0UuP.o:(.text.startup+0x6e): undefined reference to `__gxx_personality_sj0' collect2: ld returned 1 exit status FAIL: g++.dg/torture/stackalign/eh-alloca-1.C (test for excess errors) Excess errors: /vol/c/TEMP/ccJabJVm.lto.o:ccyL0UuP.o:(.text+0x10): undefined reference to `__gxx_personality_sj0' /vol/c/TEMP/ccJabJVm.lto.o:ccyL0UuP.o:(.text.startup+0x6e): undefined reference to `__gxx_personality_sj0' WARNING: g++.dg/torture/stackalign/eh-alloca-1.C compilation failed to produce executable Executing on host: /vol/d/source/gcc-svn/build64/gcc/testsuite/g++/../../g++ -B/vol/d/source/gcc-svn/build64/gcc/testsuite/g++/../../ /vol/d/home_kai/source/gcc-svn/gcc/gcc/testsuite/g++.dg/torture/stackalign/eh-alloca-1.C -nostdinc++ -I/vol/d/home_kai/source/gcc-svn/build64/x86_64-pc-mingw32/libstdc++-v3/include/x86_64-pc-mingw32 -I/vol/d/home_kai/source/gcc-svn/build64/x86_64-pc-mingw32/libstdc++-v3/include -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/libsupc++ -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/include/backward -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -flto -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs -B/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libiberty -lm -o ./eh-alloca-1.exe (timeout = 300) spawn /vol/d/source/gcc-svn/build64/gcc/testsuite/g++/../../g++ -B/vol/d/source/gcc-svn/build64/gcc/testsuite/g++/../../ /vol/d/home_kai/source/gcc-svn/gcc/gcc/testsuite/g++.dg/torture/stackalign/eh-alloca-1.C -nostdinc++ -I/vol/d/home_kai/source/gcc-svn/build64/x86_64-pc-mingw32/libstdc++-v3/include/x86_64-pc-mingw32 -I/vol/d/home_kai/source/gcc-svn/build64/x86_64-pc-mingw32/libstdc++-v3/include -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/libsupc++ -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/include/backward -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -flto -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs -B/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libiberty -lm -o ./eh-alloca-1.exe /vol/c/TEMP/ccqzwYW8.ltrans0.ltrans.o:ccqzwYW8.ltrans0.o:(.text+0x10): undefined reference to `__gxx_personality_sj0' /vol/c/TEMP/ccqzwYW8.ltrans0.ltrans.o:ccqzwYW8.ltrans0.o:(.text.startup+0x6e): undefined reference to `__gxx_personality_sj0' collect2: ld returned 1 exit status compiler exited with status 1 output is: /vol/c/TEMP/ccqzwYW8.ltrans0.ltrans.o:ccqzwYW8.ltrans0.o:(.text+0x10): undefined reference to `__gxx_personality_sj0' /vol/c/TEMP/ccqzwYW8.ltrans0.ltrans.o:ccqzwYW8.ltrans0.o:(.text.startup+0x6e): undefined reference to `__gxx_personality_sj0' collect2: ld returned 1 exit status FAIL: g++.dg/torture/stackalign/eh-alloca-1.C (test for excess errors) Excess errors: ... This causes for x86_64-w64-mingw32 more then 80 regressions failures. Interestingly it is always just the symbol __gxx_personality_sj0, which isn't resolved. And this symbol is part of libstdc++ (libsup++). If someone is interested I can sent the testsuite log of g++.dg testsuite run for it. Regards, Kai
On Tue, Jan 18, 2011 at 8:45 AM, Kai Tietz <ktietz70@googlemail.com> wrote: > 2011/1/18 Jan Hubicka <hubicka@ucw.cz>: >>> Kai Tietz <ktietz70@googlemail.com> writes: >>> >>> > I saw this discussion about avoiding rescan (and indeed it is >>> > reasonable), but as you already mentioned, it somehow stucked and no >>> > real decission was found. >>> >>> Nobody has commented on that discussion other than H.J. and myself, and >>> we have diametrically opposed opinions. I would prefer if somebody else >>> would consider the issue as well. >> >> It is still on my TODO, will try to get into it tomorrow. >> >> For libstdc++ I think we should never autogenerate references, so we need to debug >> from where the undefined references are comming. >> >> Honza >>> >>> Ian >> > > The testsuite failures are like that (the same testcases without LTO > works as expected). > > Executing on host: > /vol/d/source/gcc-svn/build64/gcc/testsuite/g++/../../g++ > -B/vol/d/source/gcc-svn/build64/gcc/testsuite/g++/../../ > /vol/d/home_kai/source/gcc-svn/gcc/gcc/testsuite/g++.dg/torture/stackalign/eh-alloca-1.C > -nostdinc++ -I/vol/d/home_kai/source/gcc-svn/build64/x86_64-pc-mingw32/libstdc++-v3/include/x86_64-pc-mingw32 > -I/vol/d/home_kai/source/gcc-svn/build64/x86_64-pc-mingw32/libstdc++-v3/include > -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/libsupc++ > -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/include/backward > -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/testsuite/util > -fmessage-length=0 -O2 -flto -flto-partition=none > -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs > -B/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs > -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libiberty -lm > -o ./eh-alloca-1.exe (timeout = 300) > spawn /vol/d/source/gcc-svn/build64/gcc/testsuite/g++/../../g++ > -B/vol/d/source/gcc-svn/build64/gcc/testsuite/g++/../../ > /vol/d/home_kai/source/gcc-svn/gcc/gcc/testsuite/g++.dg/torture/stackalign/eh-alloca-1.C > -nostdinc++ -I/vol/d/home_kai/source/gcc-svn/build64/x86_64-pc-mingw32/libstdc++-v3/include/x86_64-pc-mingw32 > -I/vol/d/home_kai/source/gcc-svn/build64/x86_64-pc-mingw32/libstdc++-v3/include > -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/libsupc++ > -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/include/backward > -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/testsuite/util > -fmessage-length=0 -O2 -flto -flto-partition=none > -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs > -B/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs > -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libiberty -lm -o > ./eh-alloca-1.exe > /vol/c/TEMP/ccJabJVm.lto.o:ccyL0UuP.o:(.text+0x10): undefined > reference to `__gxx_personality_sj0' > /vol/c/TEMP/ccJabJVm.lto.o:ccyL0UuP.o:(.text.startup+0x6e): undefined > reference to `__gxx_personality_sj0' > collect2: ld returned 1 exit status > compiler exited with status 1 > output is: > /vol/c/TEMP/ccJabJVm.lto.o:ccyL0UuP.o:(.text+0x10): undefined > reference to `__gxx_personality_sj0' > /vol/c/TEMP/ccJabJVm.lto.o:ccyL0UuP.o:(.text.startup+0x6e): undefined > reference to `__gxx_personality_sj0' > collect2: ld returned 1 exit status > > FAIL: g++.dg/torture/stackalign/eh-alloca-1.C (test for excess errors) > Excess errors: > /vol/c/TEMP/ccJabJVm.lto.o:ccyL0UuP.o:(.text+0x10): undefined > reference to `__gxx_personality_sj0' > /vol/c/TEMP/ccJabJVm.lto.o:ccyL0UuP.o:(.text.startup+0x6e): undefined > reference to `__gxx_personality_sj0' > > WARNING: g++.dg/torture/stackalign/eh-alloca-1.C compilation failed to > produce executable > Executing on host: > /vol/d/source/gcc-svn/build64/gcc/testsuite/g++/../../g++ > -B/vol/d/source/gcc-svn/build64/gcc/testsuite/g++/../../ > /vol/d/home_kai/source/gcc-svn/gcc/gcc/testsuite/g++.dg/torture/stackalign/eh-alloca-1.C > -nostdinc++ -I/vol/d/home_kai/source/gcc-svn/build64/x86_64-pc-mingw32/libstdc++-v3/include/x86_64-pc-mingw32 > -I/vol/d/home_kai/source/gcc-svn/build64/x86_64-pc-mingw32/libstdc++-v3/include > -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/libsupc++ > -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/include/backward > -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/testsuite/util > -fmessage-length=0 -O2 -flto > -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs > -B/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs > -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libiberty -lm > -o ./eh-alloca-1.exe (timeout = 300) > spawn /vol/d/source/gcc-svn/build64/gcc/testsuite/g++/../../g++ > -B/vol/d/source/gcc-svn/build64/gcc/testsuite/g++/../../ > /vol/d/home_kai/source/gcc-svn/gcc/gcc/testsuite/g++.dg/torture/stackalign/eh-alloca-1.C > -nostdinc++ -I/vol/d/home_kai/source/gcc-svn/build64/x86_64-pc-mingw32/libstdc++-v3/include/x86_64-pc-mingw32 > -I/vol/d/home_kai/source/gcc-svn/build64/x86_64-pc-mingw32/libstdc++-v3/include > -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/libsupc++ > -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/include/backward > -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/testsuite/util > -fmessage-length=0 -O2 -flto > -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs > -B/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs > -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libiberty -lm -o > ./eh-alloca-1.exe > /vol/c/TEMP/ccqzwYW8.ltrans0.ltrans.o:ccqzwYW8.ltrans0.o:(.text+0x10): > undefined reference to `__gxx_personality_sj0' > /vol/c/TEMP/ccqzwYW8.ltrans0.ltrans.o:ccqzwYW8.ltrans0.o:(.text.startup+0x6e): > undefined reference to `__gxx_personality_sj0' > collect2: ld returned 1 exit status > compiler exited with status 1 > output is: > /vol/c/TEMP/ccqzwYW8.ltrans0.ltrans.o:ccqzwYW8.ltrans0.o:(.text+0x10): > undefined reference to `__gxx_personality_sj0' > /vol/c/TEMP/ccqzwYW8.ltrans0.ltrans.o:ccqzwYW8.ltrans0.o:(.text.startup+0x6e): > undefined reference to `__gxx_personality_sj0' > collect2: ld returned 1 exit status > > FAIL: g++.dg/torture/stackalign/eh-alloca-1.C (test for excess errors) > Excess errors: > ... > > > This causes for x86_64-w64-mingw32 more then 80 regressions failures. > Interestingly it is always just the symbol __gxx_personality_sj0, > which isn't resolved. And this symbol is part of libstdc++ (libsup++). > If someone is interested I can sent the testsuite log of g++.dg > testsuite run for it. That's indeed a symbol reference we introduce late (the symbol referenced can change when merging CUs). Also on linux the C++ EH personality is in libgcc_s and not taken from libsupc++. Simply emitting all EH personality references we would emit in lto-symtab.c would fix the issue I guess. Richard. > Regards, > Kai >
On Tue, Jan 18, 2011 at 12:45 AM, Ian Lance Taylor <iant@google.com> wrote: > Kai Tietz <ktietz70@googlemail.com> writes: > >> I saw this discussion about avoiding rescan (and indeed it is >> reasonable), but as you already mentioned, it somehow stucked and no >> real decission was found. > > Nobody has commented on that discussion other than H.J. and myself, and > we have diametrically opposed opinions. I would prefer if somebody else > would consider the issue as well. I think for 4.6 we want to go with extending the pass-through machinery and not do a full 2-stage link. That was, after all, the point of using a linker-plugin. It would be nice to get the GCC side fixed and eventual binutils changes put on the 2.21 branch. Richard. > Ian >
> > -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/include/backward > > -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/testsuite/util > > -fmessage-length=0 -O2 -flto > > -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs > > -B/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs > > -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libiberty -lm -o > > ./eh-alloca-1.exe > > /vol/c/TEMP/ccqzwYW8.ltrans0.ltrans.o:ccqzwYW8.ltrans0.o:(.text+0x10): > > undefined reference to `__gxx_personality_sj0' > > /vol/c/TEMP/ccqzwYW8.ltrans0.ltrans.o:ccqzwYW8.ltrans0.o:(.text.startup+0x6e): > > undefined reference to `__gxx_personality_sj0' > > collect2: ld returned 1 exit status > > compiler exited with status 1 > > output is: > > /vol/c/TEMP/ccqzwYW8.ltrans0.ltrans.o:ccqzwYW8.ltrans0.o:(.text+0x10): > > undefined reference to `__gxx_personality_sj0' > > /vol/c/TEMP/ccqzwYW8.ltrans0.ltrans.o:ccqzwYW8.ltrans0.o:(.text.startup+0x6e): > > undefined reference to `__gxx_personality_sj0' > > collect2: ld returned 1 exit status > > > > FAIL: g++.dg/torture/stackalign/eh-alloca-1.C (test for excess errors) > > Excess errors: > > ... > > > > > > This causes for x86_64-w64-mingw32 more then 80 regressions failures. > > Interestingly it is always just the symbol __gxx_personality_sj0, > > which isn't resolved. And this symbol is part of libstdc++ (libsup++). > > If someone is interested I can sent the testsuite log of g++.dg > > testsuite run for it. > > That's indeed a symbol reference we introduce late (the symbol > referenced can change when merging CUs). Also on linux > the C++ EH personality is in libgcc_s and not taken from libsupc++. Ah, yes, we can autogenerate references to libsupc++. > > Simply emitting all EH personality references we would emit > in lto-symtab.c would fix the issue I guess. Well, I guess handling libsupc++ as proposed in the patch makes most sense. Emiting fake symbols to lto-symtab is even uglier... Honza > > Richard. > > > Regards, > > Kai > >
On Tue, Jan 18, 2011 at 11:52 AM, Jan Hubicka <hubicka@ucw.cz> wrote: >> > -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/include/backward >> > -I/vol/d/home_kai/source/gcc-svn/gcc/libstdc++-v3/testsuite/util >> > -fmessage-length=0 -O2 -flto >> > -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs >> > -B/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libstdc++-v3/src/.libs >> > -L/vol/d/source/gcc-svn/build64/x86_64-pc-mingw32/./libiberty -lm -o >> > ./eh-alloca-1.exe >> > /vol/c/TEMP/ccqzwYW8.ltrans0.ltrans.o:ccqzwYW8.ltrans0.o:(.text+0x10): >> > undefined reference to `__gxx_personality_sj0' >> > /vol/c/TEMP/ccqzwYW8.ltrans0.ltrans.o:ccqzwYW8.ltrans0.o:(.text.startup+0x6e): >> > undefined reference to `__gxx_personality_sj0' >> > collect2: ld returned 1 exit status >> > compiler exited with status 1 >> > output is: >> > /vol/c/TEMP/ccqzwYW8.ltrans0.ltrans.o:ccqzwYW8.ltrans0.o:(.text+0x10): >> > undefined reference to `__gxx_personality_sj0' >> > /vol/c/TEMP/ccqzwYW8.ltrans0.ltrans.o:ccqzwYW8.ltrans0.o:(.text.startup+0x6e): >> > undefined reference to `__gxx_personality_sj0' >> > collect2: ld returned 1 exit status >> > >> > FAIL: g++.dg/torture/stackalign/eh-alloca-1.C (test for excess errors) >> > Excess errors: >> > ... >> > >> > >> > This causes for x86_64-w64-mingw32 more then 80 regressions failures. >> > Interestingly it is always just the symbol __gxx_personality_sj0, >> > which isn't resolved. And this symbol is part of libstdc++ (libsup++). >> > If someone is interested I can sent the testsuite log of g++.dg >> > testsuite run for it. >> >> That's indeed a symbol reference we introduce late (the symbol >> referenced can change when merging CUs). Also on linux >> the C++ EH personality is in libgcc_s and not taken from libsupc++. > > Ah, yes, we can autogenerate references to libsupc++. >> >> Simply emitting all EH personality references we would emit >> in lto-symtab.c would fix the issue I guess. > > Well, I guess handling libsupc++ as proposed in the patch makes most sense. > Emiting fake symbols to lto-symtab is even uglier... Well, we simply merge the EH personality references but they are already there implicitly - just not "real" because the EH tables are not yet emitted. So emitting the reference in the LTO symbol table does sound correct to me. Richard. > Honza >> >> Richard. >> >> > Regards, >> > Kai >> > >
> > Well, we simply merge the EH personality references but they are > already there implicitly - just not "real" because the EH tables are > not yet emitted. So emitting the reference in the LTO symbol > table does sound correct to me. I would be happy with this solution, too. But the same is true about other cases as well, like libgcov calls and some builtins, where we decided to go with the passthrough. So it might make sense to handle all the cases equally... Honza > > Richard. > > > Honza > >> > >> Richard. > >> > >> > Regards, > >> > Kai > >> > > >
On Tue, Jan 18, 2011 at 12:05 PM, Jan Hubicka <hubicka@ucw.cz> wrote: >> >> Well, we simply merge the EH personality references but they are >> already there implicitly - just not "real" because the EH tables are >> not yet emitted. So emitting the reference in the LTO symbol >> table does sound correct to me. > > I would be happy with this solution, too. But the same is true about > other cases as well, like libgcov calls and some builtins, where > we decided to go with the passthrough. So it might make sense to > handle all the cases equally... Builtins are different. But both gcov and the personality are just bugs because we misrepresent references that are already there (or at least we know will be there in the end). Richard. > Honza >> >> Richard. >> >> > Honza >> >> >> >> Richard. >> >> >> >> > Regards, >> >> > Kai >> >> > >> > >
Index: gcc/gcc/cp/g++spec.c =================================================================== --- gcc.orig/gcc/cp/g++spec.c 2010-12-31 11:36:42.000000000 +0100 +++ gcc/gcc/cp/g++spec.c 2011-01-17 20:05:32.618112600 +0100 @@ -57,6 +57,8 @@ lang_specific_driver (struct cl_decoded_ int *in_added_libraries) { unsigned int i, j; + const char *p; + char *pp; /* If nonzero, the user gave us the `-p' or `-pg' flag. */ int saw_profile_flag = 0; @@ -112,12 +114,24 @@ lang_specific_driver (struct cl_decoded_ /* The total number of arguments with the new stuff. */ unsigned int num_args = 1; + /* True if lto-linker plugin is used. */ + bool is_lto_linker_plugin = false; + + /* True if lto is enabled by -flto,-flto=, or -fuse-linker-plugin. */ + bool is_lto_enabled = false; + argc = *in_decoded_options_count; decoded_options = *in_decoded_options; added_libraries = *in_added_libraries; args = XCNEWVEC (int, argc); +#ifdef HAVE_LTO_PLUGIN + is_lto_linker_plugin = true; +#else + is_lto_enabled = true; +#endif + for (i = 1; i < argc; i++) { const char *arg = decoded_options[i].arg; @@ -126,6 +140,14 @@ lang_specific_driver (struct cl_decoded_ switch (decoded_options[i].opt_index) { + case OPT_fuse_linker_plugin: + is_lto_linker_plugin = true; + is_lto_enabled = true; + break; + case OPT_flto: + case OPT_flto_: + is_lto_enabled = true; + break; case OPT_nostdlib: case OPT_nodefaultlibs: library = -1; @@ -240,6 +262,9 @@ lang_specific_driver (struct cl_decoded_ } } + if (!is_lto_enabled) + is_lto_linker_plugin = false; + /* There's no point adding -shared-libgcc if we don't have a shared libgcc. */ #ifndef ENABLE_SHARED_LIBGCC @@ -248,6 +273,8 @@ lang_specific_driver (struct cl_decoded_ /* Add one for shared_libgcc or extra static library. */ num_args = argc + added + need_math + (library > 0) * 4 + 1; + if (library > 0 && is_lto_linker_plugin) + num_args += 4; new_decoded_options = XNEWVEC (struct cl_decoded_option, num_args); i = 0; @@ -321,18 +348,31 @@ lang_specific_driver (struct cl_decoded_ j++; } #endif - generate_option (OPT_l, - saw_profile_flag ? LIBSTDCXX_PROFILE : LIBSTDCXX, 1, - CL_DRIVER, &new_decoded_options[j]); + p = saw_profile_flag ? LIBSTDCXX_PROFILE : LIBSTDCXX; + generate_option (OPT_l, p, 1, CL_DRIVER, &new_decoded_options[j]); added_libraries++; j++; + if (is_lto_linker_plugin && p && *p != 0) + { + pp = concat ("-plugin-opt=-pass-through=-l", p, NULL); + generate_option (OPT_Wl_, pp, 1, CL_DRIVER, + &new_decoded_options[j]); + j++; + } /* Add target-dependent static library, if necessary. */ - if ((static_link || library > 1) && LIBSTDCXX_STATIC != NULL) + p = LIBSTDCXX_STATIC; + if ((static_link || library > 1) && p != NULL && *p != 0) { - generate_option (OPT_l, LIBSTDCXX_STATIC, 1, - CL_DRIVER, &new_decoded_options[j]); + generate_option (OPT_l, p, 1, CL_DRIVER, &new_decoded_options[j]); added_libraries++; j++; + if (is_lto_linker_plugin) + { + pp = concat ("-plugin-opt=-pass-through=-l", p, NULL); + generate_option (OPT_Wl_, pp, 1, CL_DRIVER, + &new_decoded_options[j]); + j++; + } } #ifdef HAVE_LD_STATIC_DYNAMIC if (library > 1 && !static_link) @@ -347,11 +387,17 @@ lang_specific_driver (struct cl_decoded_ new_decoded_options[j++] = *saw_math; else if (library > 0 && need_math) { - generate_option (OPT_l, - saw_profile_flag ? MATH_LIBRARY_PROFILE : MATH_LIBRARY, - 1, CL_DRIVER, &new_decoded_options[j]); + p = saw_profile_flag ? MATH_LIBRARY_PROFILE : MATH_LIBRARY; + generate_option (OPT_l, p, 1, CL_DRIVER, &new_decoded_options[j]); added_libraries++; j++; + if (is_lto_linker_plugin) + { + pp = concat ("-plugin-opt=-pass-through=-l", p, NULL); + generate_option (OPT_Wl_, pp, 1, CL_DRIVER, + &new_decoded_options[j]); + j++; + } } if (saw_libc) new_decoded_options[j++] = *saw_libc;