Following revision 171039 the test with gcc.dg/lto/pr46940* fails on *-apple-darwin* with both -m32 and -m64: FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble, -O0 -flto -flto-partition=none FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble, -O2 -flto -flto-partition=none FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble, -O0 -flto -flto-partition=1to1 FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble, -O2 -flto -flto-partition=1to1 FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble, -O0 -flto FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble, -O2 -flto The errors are /opt/gcc/p_work/gcc/testsuite/gcc.dg/lto/pr46940_0.c:11:28: error: only weak aliases are supported in this configuration compiler exited with status 1 Before revision 171039 the test was unsupported: UNSUPPORTED: /opt/gcc/p_work/gcc/testsuite/gcc.dg/lto/pr46940_0.c because the test for 'check_linker_plugin_available' in /opt/gcc/p_work/gcc/testsuite/lib/target-supports.exp returned gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found while following revision 171039 the same test compiles and executes without error. Note that among the tests using 'dg-require-linker-plugin': /opt/gcc/p_work/gcc/testsuite/gcc.dg/lto/20100722-1_0.c /opt/gcc/p_work/gcc/testsuite/gcc.dg/lto/20110201-1_0.c /opt/gcc/p_work/gcc/testsuite/gcc.dg/lto/pr46940_0.c /opt/gcc/p_work/gcc/testsuite/gcc.dg/lto/pr47188_0.c /opt/gcc/p_work/gcc/testsuite/gcc.dg/pr43157.c pr46940_0.c is the only one failing.
> Before revision 171039 the test was unsupported: > > UNSUPPORTED: /opt/gcc/p_work/gcc/testsuite/gcc.dg/lto/pr46940_0.c > > because the test for 'check_linker_plugin_available' in > /opt/gcc/p_work/gcc/testsuite/lib/target-supports.exp returned > > gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found > > while following revision 171039 the same test compiles and executes without > error. Which linker do you use, and what's the value of HAVE_LTO_PLUGIN in gcc/auto-host.h? Could you check the gcc/config.log snippet for the linker plugin support test. If, as I assume, you're using the Darwin linker, HAVE_LTO_PLUGIN should be 0 and you should get the following error for the linker_plugin test: gcc: error: -fuse-linker-plugin is not supported in this configuration Rainer
> Which linker do you use, and what's the value of HAVE_LTO_PLUGIN in > gcc/auto-host.h? Could you check the gcc/config.log snippet for the > linker plugin support test. > > If, as I assume, you're using the Darwin linker, HAVE_LTO_PLUGIN should > be 0 and you should get the following error for the linker_plugin test: > > gcc: error: -fuse-linker-plugin is not supported in this configuration The linker is @(#)PROGRAM:ld PROJECT:ld64-97.17 llvm version 2.9svn, from Apple Clang 1.7 (build 77) on x86_64-apple-darwin10.7.0, and @(#)PROGRAM:ld PROJECT:ld64-85.2.1 on powerpc-apple-darwin9. In gcc/auto-host.h I have ... /* Define to the level of your linker's plugin support. */ #ifndef USED_FOR_TARGET #define HAVE_LTO_PLUGIN 0 #endif ... and in gcc/config.log ... | #define LTOPLUGINSONAME "liblto_plugin.so" ... configure:23133: checking linker plugin support configure:23163: result: 0 ... gcc_cv_lto_plugin=0 ... enable_plugin='yes' ... pluginlibs='' ... #define LTOPLUGINSONAME "liblto_plugin.so" ... I have grepped the different *.log files, but I did not see any gcc: error: -fuse-linker-plugin is not supported in this configuration
> The linker is > > @(#)PROGRAM:ld PROJECT:ld64-97.17 > llvm version 2.9svn, from Apple Clang 1.7 (build 77) > > on x86_64-apple-darwin10.7.0, and > > @(#)PROGRAM:ld PROJECT:ld64-85.2.1 > > on powerpc-apple-darwin9. So both of them non-GNU and not supporting -plugin. > In gcc/auto-host.h I have > > ... > /* Define to the level of your linker's plugin support. */ > #ifndef USED_FOR_TARGET > #define HAVE_LTO_PLUGIN 0 > #endif > ... As it should: vendor linker without plugin support. > I have grepped the different *.log files, but I did not see any > > gcc: error: -fuse-linker-plugin is not supported in this configuration This would only occur in gcc/testsuite/*/*.log, but of course with xgcc or something as the command name. What happens if you try to compile and link the test program from check_linker_plugin_available with the new gcc? $ cd gcc $ cat > lpl.c int main() { return 0; } $ ./xgcc -B./ -flto -fuse-linker-plugin lpl.c Rainer
> What happens if you try to compile and link the test program from > check_linker_plugin_available with the new gcc? > > $ cd gcc > $ cat > lpl.c > int main() { return 0; } > $ ./xgcc -B./ -flto -fuse-linker-plugin lpl.c See >Before revision 171039 the test was unsupported: > ... > because the test for 'check_linker_plugin_available' in > /opt/gcc/p_work/gcc/testsuite/lib/target-supports.exp returned > > gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found > > while following revision 171039 the same test compiles and executes without > error. in comment #0.
I see what's going on now: Darwin (in gcc/config/darwin.h) is one of only two targets (besides i386/djgpp.h) that override LINK_COMMAND_SPEC. I think darwin.h should use/honor LINK_PLUGIN_SPEC. Can you try inserting LINK_PLUGIN_SPEC \ in LINK_COMMAND_SPEC_A just after %(linker) \ as is done in gcc.c (LINK_COMMAND_SPEC) for other targets? Thanks. Rainer
> I see what's going on now: Darwin (in gcc/config/darwin.h) is one of > only two targets (besides i386/djgpp.h) that override > LINK_COMMAND_SPEC. > > I think darwin.h should use/honor LINK_PLUGIN_SPEC. Can you try > inserting > > LINK_PLUGIN_SPEC \ > > in LINK_COMMAND_SPEC_A just after > > %(linker) \ > > as is done in gcc.c (LINK_COMMAND_SPEC) for other targets? I'll do the check ASAP (CC Iain Sandoe, Mike Stump, and Jack Howarth). Meanwhile the following patch skips the test: --- /opt/gcc/_clean/gcc/testsuite/gcc.dg/lto/pr46940_0.c 2010-12-16 08:01:29.000000000 +0100 +++ /opt/gcc/work/gcc/testsuite/gcc.dg/lto/pr46940_0.c 2011-03-23 17:17:07.000000000 +0100 @@ -1,4 +1,5 @@ /* { dg-require-linker-plugin "" } */ +/* { dg-require-alias "" } */ /* { dg-extra-ld-options "-fuse-linker-plugin" } */ #include <stdio.h>
I'll try this on *-darwin9 and a darwin9-X-cris-elf (I assume we need to clone all the logic to cater for cross compiler cases... ) maybe this is getting complex enough to warrant a spec of its own? (and then we could avoid cloning it) === Index: gcc/config/darwin.h =================================================================== --- gcc/config/darwin.h (revision 171353) +++ gcc/config/darwin.h (working copy) @@ -174,6 +174,38 @@ extern GTY(()) int darwin_ms_struct; #define CPP_SPEC "%{static:%{!dynamic:-D__STATIC__}}%{!static:-D__DYNAMIC__}" \ " %{pthread:-D_REENTRANT}" +/* Conditional to test whether the LTO plugin is used or not. + FIXME: For slim LTO we will need to enable plugin unconditionally. This + still cause problems with PLUGIN_LD != LD and when plugin is built but + not useable. For GCC 4.6 we don't support slim LTO and thus we can enable + plugin only when LTO is enabled. We still honor explicit + -fuse-linker-plugin if the linker used understands -plugin. */ + +/* The linker has some plugin support. */ +#if HAVE_LTO_PLUGIN > 0 +/* The linker used has full plugin support, use LTO plugin by default. */ +#if HAVE_LTO_PLUGIN == 2 +#define PLUGIN_COND "!fno-use-linker-plugin:%{flto|flto=*|fuse-linker-plugin" +#define PLUGIN_COND_CLOSE "}" +#else +/* The linker used has limited plugin support, use LTO plugin with explicit + -fuse-linker-plugin. */ +#define PLUGIN_COND "fuse-linker-plugin" +#define PLUGIN_COND_CLOSE "" +#endif +#define LINK_PLUGIN_SPEC \ + "%{"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 +#else +/* The linker used doesn't support -plugin, reject -fuse-linker-plugin. */ +#define LINK_PLUGIN_SPEC "%{fuse-linker-plugin:\ + %e-fuse-linker-plugin is not supported in this configuration}" +#endif + /* This is mostly a clone of the standard LINK_COMMAND_SPEC, plus precomp, libtool, and fat build additions. @@ -185,6 +217,7 @@ extern GTY(()) int darwin_ms_struct; #define LINK_COMMAND_SPEC_A \ "%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\ %(linker) \ + " LINK_PLUGIN_SPEC " \ %{flto*:%<fcompare-debug*} \ %{flto*} \ %l %X %{s} %{t} %{Z} %{u*} \
With the change in comment #5, bootstrapping fails with ld: file not found: LINK_PLUGIN_SPEC collect2: ld returned 1 exit status make[5]: *** [libgcc_s.dylib] Error 1
> maybe this is getting complex enough to warrant a spec of its own? (and then we > could avoid cloning it) Why would you want to clone that? LINK_PLUGIN_SPEC is defined in gcc.c before it is used in LINK_COMMAND_SPEC, irrespective if the latter is from gcc itself or from target headers. Just use it as is. The fact that Darwin uses a clone of LINK_COMMAND_SPEC instead of having hooks in the generic one to to its stuff is a mistake, IMO. Rainer
> --- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-03-23 17:08:59 UTC --- > With the change in comment #5, bootstrapping fails with > > ld: file not found: LINK_PLUGIN_SPEC > collect2: ld returned 1 exit status > make[5]: *** [libgcc_s.dylib] Error 1 Iain is right: we need to turn this into a proper spec since LINK_PLUGIN_SPEC isn't defined at the point darwin.h is included. Rainer
(In reply to comment #9) > > maybe this is getting complex enough to warrant a spec of its own? (and then we > > could avoid cloning it) > The fact that Darwin uses a clone of LINK_COMMAND_SPEC instead of having > hooks in the generic one to to its stuff is a mistake, IMO. any simplification of maintenance and shortening of darwin.h would suit me ;) .. .. however this pre-dates my involvement and I don't know the reason it was done... perhaps Mike can shed some light on it...
(In reply to comment #10) > > --- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-03-23 17:08:59 UTC --- > > With the change in comment #5, bootstrapping fails with > > > > ld: file not found: LINK_PLUGIN_SPEC > > collect2: ld returned 1 exit status > > make[5]: *** [libgcc_s.dylib] Error 1 > > Iain is right: au contraire, I think Rainer is right... ;) ... Iain did not engage brain sufficiently... but one needs the " " around the insert spec - see below. > we need to turn this into a proper spec since that still might be a nice idea, Iain ===== Index: gcc/config/darwin.h =================================================================== --- gcc/config/darwin.h (revision 171353) +++ gcc/config/darwin.h (working copy) @@ -185,6 +185,7 @@ extern GTY(()) int darwin_ms_struct; #define LINK_COMMAND_SPEC_A \ "%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\ %(linker) \ + " LINK_PLUGIN_SPEC " \ %{flto*:%<fcompare-debug*} \ %{flto*} \ %l %X %{s} %{t} %{Z} %{u*} \
> au contraire, I think Rainer is right... ;) ... Iain did not engage brain > sufficiently... Me neither ;-) > but one needs the " " around the insert spec - see below. Of course, thanks for finding my snafu. >> we need to turn this into a proper spec since > > that still might be a nice idea, True, together with documenting this. But for the moment, the simpler fix would do, IMO. Rainer
If you guys like the patch from #12, I'll approve it... Looks reasonable to me.
(In reply to comment #14) > If you guys like the patch from #12, I'll approve it... Looks reasonable to > me. it seems to the the Right Thing on *-darwin9 (cross-to-cris-elf will take longer). Executing on host: /Volumes/ScratchCS/gcc-4-7-trunk-build/gcc/xgcc -B/Volumes/ScratchCS/gcc-4-7-trunk-build/gcc/ linker_plugin26306.c -flto -fuse-linker-plugin -m32 -o linker_plugin26306.exe (timeout = 60) xgcc: error: -fuse-linker-plugin is not supported in this configuration compiler exited with status 1 output is: xgcc: error: -fuse-linker-plugin is not supported in this configuration
> it seems to the the Right Thing on *-darwin9 (cross-to-cris-elf will take > longer). > > Executing on host: /Volumes/ScratchCS/gcc-4-7-trunk-build/gcc/xgcc > -B/Volumes/ScratchCS/gcc-4-7-trunk-build/gcc/ linker_plugin26306.c -flto > -fuse-linker-plugin -m32 -o linker_plugin26306.exe (timeout = 60) > xgcc: error: -fuse-linker-plugin is not supported in this configuration > compiler exited with status 1 > output is: > xgcc: error: -fuse-linker-plugin is not supported in this configuration But this is probably a different issue with correctly detecting HAVE_LTO_PLUGIN in cross scenarios. Why not fix the Darwin problem now and deal with the cross issue separately? Rainer
(In reply to comment #16) > > it seems to the the Right Thing on *-darwin9 (cross-to-cris-elf will take > > longer). > > > > Executing on host: /Volumes/ScratchCS/gcc-4-7-trunk-build/gcc/xgcc > > -B/Volumes/ScratchCS/gcc-4-7-trunk-build/gcc/ linker_plugin26306.c -flto > > -fuse-linker-plugin -m32 -o linker_plugin26306.exe (timeout = 60) > > xgcc: error: -fuse-linker-plugin is not supported in this configuration > > compiler exited with status 1 > > output is: > > xgcc: error: -fuse-linker-plugin is not supported in this configuration sorry, badly phrased - I should have said: the message above is the (correct) output from *-darwin9 native bootstrapped - the tests are unsupported as expected. > Why not fix the Darwin problem now and deal with the cross issue > separately? I don't see why there should be a cross- issue - - but it will take a while longer before I can test it ;)
> --- Comment #17 from Iain Sandoe <iains at gcc dot gnu.org> 2011-03-23 18:46:06 UTC --- > (In reply to comment #16) >> > it seems to the the Right Thing on *-darwin9 (cross-to-cris-elf will take >> > longer). >> > >> > Executing on host: /Volumes/ScratchCS/gcc-4-7-trunk-build/gcc/xgcc >> > -B/Volumes/ScratchCS/gcc-4-7-trunk-build/gcc/ linker_plugin26306.c -flto >> > -fuse-linker-plugin -m32 -o linker_plugin26306.exe (timeout = 60) >> > xgcc: error: -fuse-linker-plugin is not supported in this configuration >> > compiler exited with status 1 >> > output is: >> > xgcc: error: -fuse-linker-plugin is not supported in this configuration > > sorry, badly phrased - > > I should have said: > > the message above is the (correct) output from *-darwin9 native bootstrapped - > the tests are unsupported as expected. I think it's time for me to call it a day ;-) Didn't read right... >> Why not fix the Darwin problem now and deal with the cross issue >> separately? > > I don't see why there should be a cross- issue - > - but it will take a while longer before I can test it ;) I'll have to look at cross (and canadian cross) setups in the future for testsuite work, but would like to do this with my current native targets involved (like i386-pc-solaris2.11 x sparc-sun-solaris2.11 x mips-sgi-irix6.5 :-). The problem is, IRIX doesn't work with gld right so, so much for a cross toolchain. Rainer
AFAICT, comment #12 is OK on *-darwin9 including cross-cris-elf. given that Mike has approved, if someone could chip in with a test on x86-64-darwin10, I would think you could apply it.
> AFAICT, comment #12 is OK on *-darwin9 including cross-cris-elf. > given that Mike has approved, > if someone could chip in with a test on x86-64-darwin10, I would think you > could apply it. I have bootstrapped gcc on x86-64-darwin10 with the patch in comment #12 on top of revision 171401 without failures for the tests ran by lto.exp (full test by tomorrow). Now I wonder what are the tests gcc/testsuite/gcc.dg/lto/20100722-1_0.c gcc/testsuite/gcc.dg/lto/20110201-1_0.c gcc/testsuite/gcc.dg/lto/pr46940_0.c gcc/testsuite/gcc.dg/lto/pr47188_0.c gcc/testsuite/gcc.dg/pr43157.c supposed to test? pr46940_0.c fails because "only weak aliases are supported" on darwin and the other tests pass even without plugin support.
Author: ro Date: Mon Mar 28 11:06:58 2011 New Revision: 171598 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171598 Log: PR target/48245 * config/darwin.h (LINK_COMMAND_SPEC_A): Use LINK_PLUGIN_SPEC. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.h
Fixed for 4.7.0.
> --- Comment #20 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-03-24 18:46:41 UTC --- >> AFAICT, comment #12 is OK on *-darwin9 including cross-cris-elf. >> given that Mike has approved, >> if someone could chip in with a test on x86-64-darwin10, I would think you >> could apply it. > > I have bootstrapped gcc on x86-64-darwin10 with the patch in comment #12 on top > of revision 171401 without failures for the tests ran by lto.exp (full test by > tomorrow). Thanks. Based on Iain's and your testing and Mike's approval, I've applied the patch (slightly adapted to match the gcc.c form). > Now I wonder what are the tests > > gcc/testsuite/gcc.dg/lto/20100722-1_0.c > gcc/testsuite/gcc.dg/lto/20110201-1_0.c > gcc/testsuite/gcc.dg/lto/pr46940_0.c > gcc/testsuite/gcc.dg/lto/pr47188_0.c > gcc/testsuite/gcc.dg/pr43157.c > > supposed to test? pr46940_0.c fails because "only weak aliases are supported" > on darwin and the other tests pass even without plugin support. No idea. You'll have to ask the patch authors. This whole LTO and lto-plugin business remains a mystery to me. Rainer
(In reply to comment #20) > > AFAICT, comment #12 is OK on *-darwin9 including cross-cris-elf. > > given that Mike has approved, > > if someone could chip in with a test on x86-64-darwin10, I would think you > > could apply it. > > I have bootstrapped gcc on x86-64-darwin10 with the patch in comment #12 on top > of revision 171401 without failures for the tests ran by lto.exp (full test by > tomorrow). > > Now I wonder what are the tests > > gcc/testsuite/gcc.dg/lto/20100722-1_0.c > gcc/testsuite/gcc.dg/lto/20110201-1_0.c > gcc/testsuite/gcc.dg/lto/pr46940_0.c > gcc/testsuite/gcc.dg/lto/pr47188_0.c > gcc/testsuite/gcc.dg/pr43157.c > > supposed to test? pr46940_0.c fails because "only weak aliases are supported" > on darwin and the other tests pass even without plugin support. They are various tests for previously existing bugs (mostly ICEs). Of course they now work.
>> supposed to test? pr46940_0.c fails because "only weak aliases are supported" >> on darwin and the other tests pass even without plugin support. > > They are various tests for previously existing bugs (mostly ICEs). Of course > they now work. But Dominique's point that all those tests have dg-require-linker-plugin, but passed on Darwin even without the lto-plugin. Rainer