On 11/05/18 11:19, Richard Biener wrote: > On Thu, May 10, 2018 at 11:32 PM, Freddie Chopin <freddie_cho...@op.pl> wrote: >> Hi! >> >> In one of my embedded projects I have an option to enable LTO. This was >> working more or less fine for GCC 6 and GCC 7, however for GCC 8.1.0 >> (and binutils 2.30) - with the same set of options - I see something >> like this >> >> -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >> >> $ arm-none-eabi-g++ -Wall -Wextra -Wshadow -std=gnu++11 -mcpu=cortex-m4 >> -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -g -ggdb3 -O2 -flto -ffat- >> lto-objects -fno-use-cxa-atexit -ffunction-sections -fdata-sections >> -fno-rtti -fno-exceptions ... [include paths] ... -MD -MP -c >> test/TestCase.cpp -o output/test/TestCase.o >> <snip> > Hmm, can you try without --gc-sections? "Old" GNU ld versions have > a bug that wrecks debug info (sourceware PR20882). >
For the Cortex-M devices (and probably many other RISC targets), -fdata-sections comes at a big cost - it effectively blocks -fsection-anchors and makes access to file-static data a lot bigger. People often use -fdata-sections and -ffunction-sections along with -Wl,--gc-sections with the aim of removing unused code and data (and thus saving space, useful on small devices) - I would expect LTO would manage that anyway. The other purpose of these is to improve locality of reference - again LTO should do that for you. But even without LTO, I find the cost of -fdata-sections high compared to -fsection-anchors.
