[Bug lto/69119] More fun with LTO on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119 --- Comment #9 from PeteVine --- Never mind the last one! :) It seems gcc's LTO wasn't to blame after all.
[Bug lto/69119] More fun with LTO on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Richard Earnshaw --- Reporter indicates this was 'pilot error'.
[Bug lto/69119] More fun with LTO on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119 --- Comment #5 from PeteVine --- Wait, what about #1?
[Bug lto/69119] More fun with LTO on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119 --- Comment #6 from Richard Earnshaw --- (In reply to PeteVine from comment #5) > Wait, what about #1? Sorry, I hadn't spotted that there were two issues in the one report. Please create separate bug reports for each issue - it's much easier to merge common bugs than separate distinct ones.
[Bug lto/69119] More fun with LTO on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119 --- Comment #7 from PeteVine --- That's what normally do; I simply wasn't sure if these were gcc bugs or not. I take it the jemalloc one can be closed on github then?
[Bug lto/69119] More fun with LTO on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119 --- Comment #8 from PeteVine --- There's going to be question #3 now that I've successfully built rustc on arm using -flto. The rust compiler passes all tests but an example binary (bfc) segfaults: (gdb) bt #0 0x7f642784 in thread_rng::h22bece718b8c83adkgf () #1 0x7f6422dc in util::tmpname::h63004644db7838bePja () #2 0x7f641a00 in named::NamedTempFile::new::hfa7543c1e647f61ecqa () #3 0x7f61c308 in compile_file::h04704d1240bcd17a3Fc () #4 0x7f62077c in main::h68a433d56cae34167Pc () #5 0x7f65ab4c in panic::recover::h13621087687085827578 () #6 0x7f65a68c in rt::lang_start::h5fc8517878d759f3Dky () #7 0xb6d61632 in __libc_start_main (main=0x7f621dbc , argc=2, argv=0xbeffef74, init=, fini=0x8004b0f9 <__libc_csu_fini>, rtld_fini=0xb6fea4c5 <_dl_fini>, stack_end=0xbeffef74) at libc-start.c:287 #8 0x7f61a8d8 in _start () Note line #6 - that's the C glue that's probably the victim of this optimization. Is it a bug in gcc deserving a separate issue? Needless to say, without -flto at rustc's build-time the binaries created by it don't segfault.
[Bug lto/69119] More fun with LTO on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119 --- Comment #3 from PeteVine --- You were right about #2 - I passed LDFLAGS=-fPIC to both configure and later make which solved the issue somewhere. Thanks a lot!
[Bug lto/69119] More fun with LTO on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-01-03 Ever confirmed|0 |1 Severity|major |normal --- Comment #1 from Andrew Pinski --- I think -fPIC is not on the link line which is causing the problems. Can you try 5.x also? Also can you provide a testcase which shows the failure?
[Bug lto/69119] More fun with LTO on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119 --- Comment #2 from PeteVine --- Unfortunately I don't a have working 5.x at my disposal on arm. I'll remember about this issue when it becomes available. Anyway on 4.9, the suggestion is to recompile something with -fPIC but it's not clear what - jemalloc? The diagnostic message is slightly misleading if it were to end up being about a missing LD flag.
[Bug lto/69119] More fun with LTO on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119 PeteVine changed: What|Removed |Added Target||armv7 Host||armv7 Severity|normal |major
