On Sun, Aug 08, 2010 at 12:24:58PM +0200, Steinar H. Gunderson wrote:
> On Sun, Aug 08, 2010 at 02:20:38PM +0400, Kirill Smelkov wrote:
> > No thanks, I can't afford NDA for myself.
>
> I wouldn't require an NDA to be signed -- it would be on honor code. :-)
> (It's not a commercial product, but I wouldn't want the source code
> distributed regardless, especially as I'd have to confer with the 4-5 others
> who has code rights.)
Still it would be an agreement where one party promises not to
disclose...
On Sun, Aug 08, 2010 at 12:46:54PM +0200, Steinar H. Gunderson wrote:
> On Sun, Aug 08, 2010 at 12:24:58PM +0200, Steinar H. Gunderson wrote:
> >> Though I may suggest to try latest upstream binutils and gcc-4.5 to see
> >> whether it works there, and if not, try harder to still disentangle the
> >> testcase.
> > I'll give probably give it a shot, eventually.
>
> OK, I think I've spotted the problem -- it doesn't like that .a files
> reference variables in .o files.
>
> fugl:~/dev/lto> cat a.cpp
> int var;
> fugl:~/dev/lto> cat b.cpp
> #include <stdio.h>
>
> extern int var;
>
> int main(void)
> {
> printf("hello: %d\n", var);
> }
> fugl:~/dev/lto> g++-4.5 -flto -o a.o -c a.cpp
> fugl:~/dev/lto> g++-4.5 -flto -o b.o -c b.cpp
> fugl:~/dev/lto> ar rc libwhatever.a b.o
> fugl:~/dev/lto> ranlib libwhatever.a
> fugl:~/dev/lto> g++-4.5 -flto -fwhole-program -Wl,--gc-sections -o prog
> -Wl,--start-group a.o libwhatever.a -Wl,--end-group
> libwhatever.a(b.o): In function `main':
> b.cpp:(.text+0xa): undefined reference to `var'
> collect2: ld returned 1 exit status
>
> If I put a.o into an .a file, it works. The order of a.o and libwhatever.a
> doess not matter. Removing -fwhole-program fixes it.
>
> This is a bug, right?
On Sun, Aug 08, 2010 at 12:59:51PM +0200, Steinar H. Gunderson wrote:
> On Sun, Aug 08, 2010 at 12:46:54PM +0200, Steinar H. Gunderson wrote:
> > OK, I think I've spotted the problem -- it doesn't like that .a files
> > reference variables in .o files.
>
> Actually, .a files are not recompiled for LTO at all. If I stick everything
> in .a files and link, linking is very fast; if I give the same .o files on
> the command line, the machine chugs for a long time and then a smaller
> result comes out.
I have not tried -flto for myself yet, but what is maybe happening here
is that if lto skips archives, when you try to link a.o and
libwhatever.a through lto with -fwhole-program, lto takes only a.o and
then yes, var is optimized away, because there is no link-chain from
main to it (remember we passed -fwhole-program to it).
And then ld sees main, but does not see var.
What is ranted here is completely untested, but maybe somehow related to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41376
> -frepo still makes everything crash and burn, but I guess that's for a
> separate bug.
Probably yes. All those new gc features need time to get into shape...
Thanks,
Kirill
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
