-flto -g fails

[Trass3r]

I tested the toolchain, thanks for it!
It even saves 2-3KB compared to my older 8.2 toolchain.
LTO works too but not when adding debug info (worked with the older toolchain). Can you reproduce this?
arm-none-eabi/bin/ld.exe: error: could not unlink output file

[Trass3r]

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

[Trass3r]

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

[FreddieChopin]

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.

[Trass3r]

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.

[FreddieChopin]

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).

[Trass3r]

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