gcc's lto breaks rust's jemalloc/llvm interfaces

[MagaTailor]

As an experiment I had -flto in my CFLAGS while building rustc which didn't cause any problems.
(Dec 2 nightly, i686-linux, gcc 4.9.3, local llvm 3.6)

It seems the compiler is fully functional but still I'm getting segfaults like this (in other build commands too):

 Compiling gl v0.0.12
failed to run custom build command for `gl v0.0.12`
Process didn't exit successfully: `/home/petevine/unpacked/rust-snake-master/target/release/build/gl-a90cb7fe89544061/build-script-build` (signal: 11)

Program received signal SIGSEGV, Segmentation fault.
0x8007d629 in je_mallocx ()
(gdb) bt
#0  0x8007d629 in je_mallocx ()
#1  0x800890f6 in __rust_allocate ()
#2  0x00000000 in ?? ()

If it's not a good idea to use lto flags at build-time, configure should definitely filter them out or at least warn the user.

EDIT:
This issue is not about artifacts as it can be reproduced with empty .cargo and fresh project directories.

[MagaTailor]

After repeating the whole procedure with jemalloc disabled the resulting compiler generates fully working code meaning it was just jemalloc that got miscompiled with lto.

[sfackler]

This seems like a bug that should be filed on jemalloc?

[MagaTailor]

Probably yes; meanwhile what about rust's build system? The compiler builds without a slightest problem and even generates a working hello world! (as well as manages to build some crates)

[MagaTailor]

The jemalloc maintainter didn't give a definitive answer to my last question but it's almost certain now it wasn't about jemalloc per se. Back to you guys :)

[pnkfelix]

I suspect you're going to have issues with people saying "there's nothing actionable here" on both the jemalloc side and the Rust side...

[MagaTailor]

Let's recap:

• jemalloc compiled separately with -flto passes all tests
• disabling jemalloc allows -flto
• not using -flto is necessary for a fully functional compiler w/jemalloc enabled.

At least that was the case two weeks ago.

[MagaTailor]

After the recent C purge I can no longer reproduce.
(or it could have been the -flto-partition=none flag I used this time)

[MagaTailor]

Well no, still happens sometimes:

failed to run custom build command for `kernel32-sys v0.2.1`
Process didn't exit successfully: `/home/petevine/exa-master/target/release/build/kernel32-sys-49d5fc958bd6fccd/build-script-build` (signal: 11)

or

failed to run custom build command for `openssl-sys v0.7.1`
Process didn't exit successfully: `/home/petevine/exa-master/target/release/build/openssl-sys-3f949b2c9b71dbaa/build-script-build` (signal: 11)

which yields the same trace:

Program received signal SIGSEGV, Segmentation fault.
0x800167ee in je_malloc_tsd_boot0.part ()
(gdb) bt
#0  0x800167ee in je_malloc_tsd_boot0.part ()
#1  0x80016657 in je_malloc_tsd_boot0 ()
#2  0x80039975 in malloc_init_hard.lto_priv ()
#3  0x800383fe in jemalloc_constructor ()
#4  0x8004f4f6 in __libc_csu_init ()
#5  0xb7dec237 in __libc_start_main () from /lib/libc.so.6
#6  0x8000aa81 in _start () at ../sysdeps/i386/start.S:102

[pnkfelix]

Can you provide a full transcript of the steps you are following to exhibit this behavior? If will probably need both your configure invocation (for rustc) and whatever remaining steps you used to exhibit the bug

Independently, since I am inferring that these stack traces are coming from invocations of your locally built rustc, maybe you should run make check on your local build rather than just "hello world", in the hopes that we find a smaller test input that reproduces the problem.

[MagaTailor]

No, I'd already stated clearly it was all about CFLAGS (-flto) when building rustc. So it should either reproduce anywhere or it's a bug in gcc. The last part about hello world is rather funny as the gdb traces were coming from regular projects' cargo builds.

[pnkfelix]

@petevine I do not understand your response to my suggestion. you have reopened the issue here, so I infer that you are not actually suggesting that you believe this to be a bug in gcc, but continuing to do full cargo runs rather than first double checking against the rust test site just seems like you don't think the problem can be narrowed down?