-ffunction-sections triggers an LLVM assert on windows

[alexcrichton]

It's the same assert as seen by #13793. I suspect that they are related bugs, and that this is likely an upstream LLVM bug.

This is a tracking issue for this for now. I'm going to turn off -ffunction-sections for windows.

[klutzy]

#13793 issue has been fixed now, but it seems that other obscure bug exists in llvm or linker.
From #16450 failure log:

note: i686-pc-mingw32\stage1\bin\rustlib\i686-pc-mingw32\lib\rustc-4e7c5e5c.o:(.data+0x2e78): undefined reference to `driver::config::cgsetters::ar::h3bd933d9f589e8e9UWy'
i686-pc-mingw32\stage1\bin\rustlib\i686-pc-mingw32\lib\rustc-4e7c5e5c.o:(.data+0x2e8c): undefined reference to `driver::config::cgsetters::linker::h257f0348e654864fgXy'
i686-pc-mingw32\stage1\bin\rustlib\i686-pc-mingw32\lib\rustc-4e7c5e5c.o:(.data+0x2ea0): undefined reference to `driver::config::cgsetters::link_args::h83c0025909f670c1CXy'
i686-pc-mingw32\stage1\bin\rustlib\i686-pc-mingw32\lib\rustc-4e7c5e5c.o:(.data+0x2eb4): undefined reference to `driver::config::cgsetters::target_cpu::h3ec762698261dbe8YXy'
...

Linker failed to find driver::config::cgsetters::* functions so emitted undefined reference error on win-32-nopt-c setting.
However, stage1 has passed on win-32-opt setting. (Both reproduced on my machine too.)

[frewsxcv]

@klutzy Are you able to reproduce those 'obscure bugs' with the latest Rust?

[vadimcn]

I re-enabled function sections on Windows in the current master branch, and it compiled and passed tests without errors.
However... I am not seeing any reductions in the size of executables. On the contrary, my hello_world.exe has gotten bigger! Rust nightly creates a 2.8MB file, whereas this modified version - 3.2MB.

[alexcrichton]

It is expected that -ffunction-sections does indeed increase the size of the resulting object if nothing is eliminated (lots more sections need to be described). That being said I'm pretty surprised that nothing was eliminated. Are we sure that ld in mingw-w64 has this implemented and working?

[vadimcn]

It is expected that -ffunction-sections does indeed increase the size of the resulting object if nothing is eliminated (lots more sections need to be described).

I am talking about size of the final executable, not about rlib. I thought all text/data sections get merged during linking. Is there some residual per-section overhead?

Are we sure that ld in mingw-w64 has this implemented and working?

Good question... There was a patch enabling --gc-sections, however the bug is still open.

[vadimcn]

... and the answer is ... NO

[alexcrichton]

I thought all text/data sections get merged during linking. Is there some residual per-section overhead?

Oh you may be right. I think I'm forgetting the exact specifics but what you're saying sounds right. Maybe there's a mixture of the two happening on windows?

... and the answer is ... NO

:(

[brson]

Kind of a wishlist feature, so closing. We just have to remember this problem if somebody ever tries to turn -ffunction-sections on again. Reopen if you disagree.