https://sourceware.org/bugzilla/show_bug.cgi?id=29998
--- Comment #20 from Nick Clifton <nickc at redhat dot com> ---
(In reply to Jan Janssen from comment #18)
Hi Jan,
There appear to be a few issues with this second test case:
> $ cat test1.c
> void test1() {}
> $ cat test2.c
> void test1(); static void test2() { test1(); }
These files appear to be redundant - their code is never called.
> $ cat test3.c
> int run(void) {
> volatile unsigned i = 4278190080;
> return __builtin_popcount(i);
> }
Shouldn't this function be called main() rather than run() ?
> $ x86_64-w64-mingw32-gcc -o test.exe -flto -nostdlib test2.o test3.o
> libtest.a -lgcc
If you are linking without the standard libraries, can you really expect
the program to run ?
> When I run the above build steps (with your path applied), they produce the
> same assembly for run(), except for this line:
>
> 14000102b: e8 00 00 00 00 call 140001030 <run+0x1c>
>
> vs this without -flto:
>
> 140001037: e8 24 00 00 00 call 140001060 <__popcountdi2>
>
> The lto build doesn't even include popcount and the EFI binary either
> produces a page fault or division error.
True - but as far as I can see this code will never be called. So having
LTO eliminate the call to __popcountdi2 is understandable.
At the moment it looks to me like you are trying to do something unusual - ie
creating a binary without the usual start up files or libraries - and this is
not working as expected. But I am currently unconvinced that the linker is
really to blame for the problems...
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
