[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |MOVED --- Comment #16 from Martin Liška --- It's not a GCC issue.
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376 Martin Liška changed: What|Removed |Added Keywords||patch --- Comment #15 from Martin Liška --- Patch candidate: https://www.sourceware.org/ml/binutils/2019-08/msg00113.html
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376 Martin Liška changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #14 from Martin Liška --- Thanks you Rainer, I've got patch for that.
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376 --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #12 from Martin Liška --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #11) >> > --- Comment #9 from Martin Liška --- >> > (In reply to r...@cebitec.uni-bielefeld.de from comment #8) >> [...] >> >> I don't see how nm would come into play here. >> > >> > I thought you see the failure for all tests. Then one could use nm to >> > identify >> > if LTO plugin is properly loaded. >> >> Ok, I see. >> >> >> $ gld.cmd >> >> ../../lto-wrapper -fresolution=cp_lto_pr90990_0.res -flinker-output=rel >> >> cp_lto_pr90990_0.o >> >> /vol/gcc/bin/gld-2.32.51: /var/tmp//ccKkavFd.lto.o: plugin needed to >> >> handle >> >> lto object >> >> [Leaving g++-dg-lto-pr90990-01.exe.lto_wrapper_args] >> >> [Leaving /var/tmp//ccKkavFd.lto.o] >> > >> > Can you please send me the *.o files so that I can investigate them? >> >> Sure, attached. > > When using current binutils master I see: > > $ ~/bin/binutils/bin/nm --version > GNU nm (GNU Binutils) 2.32.51.20190809 > > $ ~/bin/binutils/bin/nm --plugin > /dev/shm/objdir/lto-plugin/.libs/liblto_plugin.so.0.0.0 ccKkavFd.lto.o > U __gxx_personality_v0 > W _ZN1AC1Ev > W _ZN1AC2Ev > U _ZN1BixEi > W _ZN1CclE1A > U _ZN1D5m_fn1Ev > T _ZN1FC1ER1DRK1A > T _ZN1FC2ER1DRK1A > > $ ~/bin/binutils/bin/nm ccKkavFd.lto.o > /home/marxin/bin/binutils/bin/nm: ccKkavFd.lto.o: plugin needed to handle lto > object > 0001 C __gnu_lto_slim Same here... > So as seen, if the plugin is loaded, then I can't see the error message. ... however I *do* it from gld! >> >> There's no nm anywhere in sight. Besides, I find it very strange that >> >> out of hundreds if not thousends of LTO tests during this bootstrap, >> >> only a single one shows this error. If there were a fundamental >> >> problem, I'd expect a way larger number here. >> > >> > That's strange! The test-case is not special to me. >> >> So one would think. However, the fact that I'm not the only one seeing >> this particular failure suggests otherwise... > > Can you please send me links to the test-suite reports? I just grepped for the test name in an rsynced copy of the gcc-testresults archive. However, there's no need for that: you can easily reproduce the failure yourself. I've just ran a x86_64-pc-linux-gnu bootstrap with --with-as=/path/to/gas-2.32.51 --with-ld=/path/to/gld-2.32.51 and the current testcase was the only one that regressed. $ gld-2.32.51 --version GNU ld (GNU Binutils) 2.32.51.20190805
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376 --- Comment #12 from Martin Liška --- (In reply to r...@cebitec.uni-bielefeld.de from comment #11) > > --- Comment #9 from Martin Liška --- > > (In reply to r...@cebitec.uni-bielefeld.de from comment #8) > [...] > >> I don't see how nm would come into play here. > > > > I thought you see the failure for all tests. Then one could use nm to > > identify > > if LTO plugin is properly loaded. > > Ok, I see. > > >> $ gld.cmd > >> ../../lto-wrapper -fresolution=cp_lto_pr90990_0.res -flinker-output=rel > >> cp_lto_pr90990_0.o > >> /vol/gcc/bin/gld-2.32.51: /var/tmp//ccKkavFd.lto.o: plugin needed to handle > >> lto object > >> [Leaving g++-dg-lto-pr90990-01.exe.lto_wrapper_args] > >> [Leaving /var/tmp//ccKkavFd.lto.o] > > > > Can you please send me the *.o files so that I can investigate them? > > Sure, attached. When using current binutils master I see: $ ~/bin/binutils/bin/nm --version GNU nm (GNU Binutils) 2.32.51.20190809 $ ~/bin/binutils/bin/nm --plugin /dev/shm/objdir/lto-plugin/.libs/liblto_plugin.so.0.0.0 ccKkavFd.lto.o U __gxx_personality_v0 W _ZN1AC1Ev W _ZN1AC2Ev U _ZN1BixEi W _ZN1CclE1A U _ZN1D5m_fn1Ev T _ZN1FC1ER1DRK1A T _ZN1FC2ER1DRK1A $ ~/bin/binutils/bin/nm ccKkavFd.lto.o /home/marxin/bin/binutils/bin/nm: ccKkavFd.lto.o: plugin needed to handle lto object 0001 C __gnu_lto_slim So as seen, if the plugin is loaded, then I can't see the error message. > > >> There's no nm anywhere in sight. Besides, I find it very strange that > >> out of hundreds if not thousends of LTO tests during this bootstrap, > >> only a single one shows this error. If there were a fundamental > >> problem, I'd expect a way larger number here. > > > > That's strange! The test-case is not special to me. > > So one would think. However, the fact that I'm not the only one seeing > this particular failure suggests otherwise... Can you please send me links to the test-suite reports?
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #9 from Martin Liška --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #8) [...] >> I don't see how nm would come into play here. > > I thought you see the failure for all tests. Then one could use nm to identify > if LTO plugin is properly loaded. Ok, I see. >> $ gld.cmd >> ../../lto-wrapper -fresolution=cp_lto_pr90990_0.res -flinker-output=rel >> cp_lto_pr90990_0.o >> /vol/gcc/bin/gld-2.32.51: /var/tmp//ccKkavFd.lto.o: plugin needed to handle >> lto object >> [Leaving g++-dg-lto-pr90990-01.exe.lto_wrapper_args] >> [Leaving /var/tmp//ccKkavFd.lto.o] > > Can you please send me the *.o files so that I can investigate them? Sure, attached. >> There's no nm anywhere in sight. Besides, I find it very strange that >> out of hundreds if not thousends of LTO tests during this bootstrap, >> only a single one shows this error. If there were a fundamental >> problem, I'd expect a way larger number here. > > That's strange! The test-case is not special to me. So one would think. However, the fact that I'm not the only one seeing this particular failure suggests otherwise...
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376 --- Comment #10 from Rainer Orth --- Created attachment 46696 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46696&action=edit i386-pc-solaris2.11 input objects
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376
--- Comment #9 from Martin Liška ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > --- Comment #7 from Martin Liška ---
> > (In reply to Martin Liška from comment #6)
> >> Good, then let me take a look.
> >
> > So I've just tested current master of binutils and I can see:
> >
> > marxin@marxinbox:/tmp> gcc --version
> > gcc (GCC) 10.0.0 20190806 (experimental)
> > Copyright (C) 2019 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.
> >
> > marxin@marxinbox:/tmp> gcc -c -flto main.c
> >
> > $ nm main.o
> > nm: main.o: plugin needed to handle lto object
> > 0001 C __gnu_lto_slim
> >
> > The issue here is that the installed nm can't load plugin from bfd-plugins:
> >
> > $ strace -f -s512 nm main.o 2>&1 | grep plugin
> > openat(AT_FDCWD, "/home/marxin/bin/binutils/bin/../bin/../lib/bfd-plugins",
> > O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 4
> > stat("/home/marxin/bin/binutils/bin/../bin/../lib/bfd-plugins/..",
> > {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> > stat("/home/marxin/bin/binutils/bin/../bin/../lib/bfd-plugins/.",
> > {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> > write(2, "main.o: plugin needed to handle lto object", 42main.o: plugin
> > needed
> > to handle lto object) = 42
> >
> > $ nm --plugin /dev/shm/objdir/lto-plugin/.libs/liblto_plugin.so.0.0.0 main.o
> > T main
> >
> > So the question is if you have a LTO plugin accessible for the built gold or
> > nm?
>
> I don't see how nm would come into play here.
I thought you see the failure for all tests. Then one could use nm to identify
if LTO plugin is properly loaded.
> For one, I've only
> installed gas and gld from binutils trunk under non-standard names
> (gas-2.32.51 and gld-2.32.51) and use them via --with-as and --with-ld.
>
> The failing testcases boils down to (run in gcc/testsuite/g++):
>
> #!/bin/sh
>
> COLLECT_GCC=../../xg++ \
> COLLECT_GCC_OPTIONS= \
> COLLECT_LTO_WRAPPER=../../lto-wrapper \
> COMPILER_PATH=../.. \
> \
> /vol/gcc/bin/gld-2.32.51 \
> -plugin ../../liblto_plugin.so \
> -plugin-opt=../../lto-wrapper \
> -plugin-opt=-fresolution=cp_lto_pr90990_0.res \
> -plugin-opt=-v \
> -plugin-opt=-save-temps \
> -o g++-dg-lto-pr90990-01.exe -r cp_lto_pr90990_0.o
>
> $ gld.cmd
> ../../lto-wrapper -fresolution=cp_lto_pr90990_0.res -flinker-output=rel
> cp_lto_pr90990_0.o
> /vol/gcc/bin/gld-2.32.51: /var/tmp//ccKkavFd.lto.o: plugin needed to handle
> lto object
> [Leaving g++-dg-lto-pr90990-01.exe.lto_wrapper_args]
> [Leaving /var/tmp//ccKkavFd.lto.o]
Can you please send me the *.o files so that I can investigate them?
>
> When I run this under truss (Solaris equivalent of strace), I find just
> the following calls to execve:
>
> 12815:execve("../../lto-wrapper", 0xFEFFD6F4, 0xFEFFD844) argc = 2
> 12815: argv: ../../lto-wrapper
> 12815: @g++-dg-lto-pr90990-01.exe.lto_wrapper_args
>
> 12817:execve("../../xg++", 0xFEFFD5A4, 0xFEFFD990) argc = 2
> 12817: argv: ../../xg++ @/var/tmp//ccxh7UCb
>
> 12819:execve("../../lto1", 0x08189FD0, 0x08187784) argc = 19
> 12819: argv: ../../lto1 -quiet -dumpbase cp_lto_pr90990_0.o
> 12819: -mtune=generic -march=pentium4 -auxbase-strip
> 12819: /var/tmp//ccKkavFd.lto.o -O0 -fno-openmp -fno-openacc
> 12819: -fno-pie -fno-diagnostics-show-caret
> 12819: -fno-diagnostics-show-line-numbers
> 12819: -fresolution=cp_lto_pr90990_0.res -flinker-output=rel
> 12819: @/var/tmp//ccsvXE.b -o /var/tmp//ccM632hc.s
>
> 12821:execve("/vol/gcc/bin/gas-2.32.51", 0x08189FD0, 0x08187784)
> argc = 7
> 12821: argv: /vol/gcc/bin/gas-2.32.51 -Qy -s --32 -o
> 12821: /var/tmp//ccKkavFd.lto.o /var/tmp//ccM632hc.s
>
> There's no nm anywhere in sight. Besides, I find it very strange that
> out of hundreds if not thousends of LTO tests during this bootstrap,
> only a single one shows this error. If there were a fundamental
> problem, I'd expect a way larger number here.
That's strange! The test-case is not special to me.
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Martin Liška ---
> (In reply to Martin Liška from comment #6)
>> Good, then let me take a look.
>
> So I've just tested current master of binutils and I can see:
>
> marxin@marxinbox:/tmp> gcc --version
> gcc (GCC) 10.0.0 20190806 (experimental)
> Copyright (C) 2019 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.
>
> marxin@marxinbox:/tmp> gcc -c -flto main.c
>
> $ nm main.o
> nm: main.o: plugin needed to handle lto object
> 0001 C __gnu_lto_slim
>
> The issue here is that the installed nm can't load plugin from bfd-plugins:
>
> $ strace -f -s512 nm main.o 2>&1 | grep plugin
> openat(AT_FDCWD, "/home/marxin/bin/binutils/bin/../bin/../lib/bfd-plugins",
> O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 4
> stat("/home/marxin/bin/binutils/bin/../bin/../lib/bfd-plugins/..",
> {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> stat("/home/marxin/bin/binutils/bin/../bin/../lib/bfd-plugins/.",
> {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> write(2, "main.o: plugin needed to handle lto object", 42main.o: plugin needed
> to handle lto object) = 42
>
> $ nm --plugin /dev/shm/objdir/lto-plugin/.libs/liblto_plugin.so.0.0.0 main.o
> T main
>
> So the question is if you have a LTO plugin accessible for the built gold or
> nm?
I don't see how nm would come into play here. For one, I've only
installed gas and gld from binutils trunk under non-standard names
(gas-2.32.51 and gld-2.32.51) and use them via --with-as and --with-ld.
The failing testcases boils down to (run in gcc/testsuite/g++):
#!/bin/sh
COLLECT_GCC=../../xg++ \
COLLECT_GCC_OPTIONS= \
COLLECT_LTO_WRAPPER=../../lto-wrapper \
COMPILER_PATH=../.. \
\
/vol/gcc/bin/gld-2.32.51 \
-plugin ../../liblto_plugin.so \
-plugin-opt=../../lto-wrapper \
-plugin-opt=-fresolution=cp_lto_pr90990_0.res \
-plugin-opt=-v \
-plugin-opt=-save-temps \
-o g++-dg-lto-pr90990-01.exe -r cp_lto_pr90990_0.o
$ gld.cmd
../../lto-wrapper -fresolution=cp_lto_pr90990_0.res -flinker-output=rel
cp_lto_pr90990_0.o
/vol/gcc/bin/gld-2.32.51: /var/tmp//ccKkavFd.lto.o: plugin needed to handle lto
object
[Leaving g++-dg-lto-pr90990-01.exe.lto_wrapper_args]
[Leaving /var/tmp//ccKkavFd.lto.o]
When I run this under truss (Solaris equivalent of strace), I find just
the following calls to execve:
12815: execve("../../lto-wrapper", 0xFEFFD6F4, 0xFEFFD844) argc = 2
12815: argv: ../../lto-wrapper
12815:@g++-dg-lto-pr90990-01.exe.lto_wrapper_args
12817: execve("../../xg++", 0xFEFFD5A4, 0xFEFFD990) argc = 2
12817: argv: ../../xg++ @/var/tmp//ccxh7UCb
12819: execve("../../lto1", 0x08189FD0, 0x08187784) argc = 19
12819: argv: ../../lto1 -quiet -dumpbase cp_lto_pr90990_0.o
12819:-mtune=generic -march=pentium4 -auxbase-strip
12819:/var/tmp//ccKkavFd.lto.o -O0 -fno-openmp -fno-openacc
12819:-fno-pie -fno-diagnostics-show-caret
12819:-fno-diagnostics-show-line-numbers
12819:-fresolution=cp_lto_pr90990_0.res -flinker-output=rel
12819:@/var/tmp//ccsvXE.b -o /var/tmp//ccM632hc.s
12821: execve("/vol/gcc/bin/gas-2.32.51", 0x08189FD0, 0x08187784) argc = 7
12821: argv: /vol/gcc/bin/gas-2.32.51 -Qy -s --32 -o
12821:/var/tmp//ccKkavFd.lto.o /var/tmp//ccM632hc.s
There's no nm anywhere in sight. Besides, I find it very strange that
out of hundreds if not thousends of LTO tests during this bootstrap,
only a single one shows this error. If there were a fundamental
problem, I'd expect a way larger number here.
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #7 from Martin Liška ---
(In reply to Martin Liška from comment #6)
> Good, then let me take a look.
So I've just tested current master of binutils and I can see:
marxin@marxinbox:/tmp> gcc --version
gcc (GCC) 10.0.0 20190806 (experimental)
Copyright (C) 2019 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.
marxin@marxinbox:/tmp> gcc -c -flto main.c
$ nm main.o
nm: main.o: plugin needed to handle lto object
0001 C __gnu_lto_slim
The issue here is that the installed nm can't load plugin from bfd-plugins:
$ strace -f -s512 nm main.o 2>&1 | grep plugin
openat(AT_FDCWD, "/home/marxin/bin/binutils/bin/../bin/../lib/bfd-plugins",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 4
stat("/home/marxin/bin/binutils/bin/../bin/../lib/bfd-plugins/..",
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/home/marxin/bin/binutils/bin/../bin/../lib/bfd-plugins/.",
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
write(2, "main.o: plugin needed to handle lto object", 42main.o: plugin needed
to handle lto object) = 42
$ nm --plugin /dev/shm/objdir/lto-plugin/.libs/liblto_plugin.so.0.0.0 main.o
T main
So the question is if you have a LTO plugin accessible for the built gold or
nm?
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376 Martin Liška changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #6 from Martin Liška --- Good, then let me take a look.
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Martin Liška --- [...] > Sorry for not getting that. Well, then please try revision before > cc5277b173701364c10204f316db28198f2c683b That one is fine: the testcase links without error/warning.
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-08-07 Ever confirmed|0 |1 --- Comment #4 from Martin Liška --- (In reply to r...@cebitec.uni-bielefeld.de from comment #3) > > --- Comment #2 from Martin Liška --- > > (In reply to Richard Biener from comment #1) > >> Possibly related to the .gnu_lto emission changes? > > > > Well, my changes are not part of any binutils release yet. > > But I *have* been using binutils trunk for this build, as mentioned both > in the title and the report. Only then does the error occur, the 2.32 > release is fine. Sorry for not getting that. Well, then please try revision before cc5277b173701364c10204f316db28198f2c683b
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Martin Liška --- > (In reply to Richard Biener from comment #1) >> Possibly related to the .gnu_lto emission changes? > > Well, my changes are not part of any binutils release yet. But I *have* been using binutils trunk for this build, as mentioned both in the title and the report. Only then does the error occur, the 2.32 release is fine.
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376 --- Comment #2 from Martin Liška --- (In reply to Richard Biener from comment #1) > Possibly related to the .gnu_lto emission changes? Well, my changes are not part of any binutils release yet.
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376 --- Comment #1 from Richard Biener --- Possibly related to the .gnu_lto emission changes?
[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
