-flto -g fails about bleeding-edge-toolchain HOT 6 CLOSED

Ok seems to go away when removing -save-temps.

from bleeding-edge-toolchain.

Looks like it is a legit bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90369

from bleeding-edge-toolchain.

You sorted that out even before I could try it (; After the gcc team publishes a new snapshot (10.x.x snapshot or 9.x.x snapshot if the bug report will have info about fixing this in gcc-9-branch too) you can build the new toolchain using the script - just replace gccVersion="9.1.0" with gccVersion="10-YYYYMMDD" (depending on the snapshot name) and run it again.

from bleeding-edge-toolchain.

Yeah I guess they won't backport it to v9. -save-temps is not used that often. I also just use it to see the produced assembly in the case of LTO.

from bleeding-edge-toolchain.

Yeah I guess they won't backport it to v9.

You never know (; Maybe they will, try to nag them a bit if you care about that. But if you can also try the 10.x.x snapshot, then it doesn't matter that much.

-save-temps is not used that often. I also just use it to see the produced assembly in the case of LTO.

You can inspect assembler in a different way. I just dump the assembly straight from the produced executable like this:
https://github.com/DISTORTEC/distortos/blob/master/cmake/distortos-utilities.cmake#L90
$ arm-none-eabi-objdump --demangle -S output.elf > output.lss

If you compile with debugging symbols, then the assembly usually is nicely mixed with the sourcecode (it gets worse with higher optimization levels).

from bleeding-edge-toolchain.

Yeah I know but gcc's output is way better than objdump's iirc. Would need to re-check.

from bleeding-edge-toolchain.