link time optimization

[hazelnusse]

I tried building my program with gcc 4.7.3 and enabling -flto in the compile and link steps. I'm mostly doing this because I'm curious if there would actually be any benefit. I'm getting the following error:

Code: Select all

In file included from :2:0:
/home/hazelnusse/repos/ChibiOS/os/ports/GCC/ARMCMx/crt0.c:126:17: error: function '__main_stack_end__' redeclared as variable
In file included from /home/hazelnusse/repos/ChibiOS/os/ports/common/ARMCMx/nvic.h:151:0,
                 from :3:
/home/hazelnusse/repos/ChibiOS/os/ports/GCC/ARMCMx/STM32F4xx/vectors.c:34:13: note: previously declared here
lto1: fatal error: errors during merging of translation units
compilation terminated.
lto-wrapper: /home/hazelnusse/toolchain/bin/arm-none-eabi-g++ returned 1 exit status
/home/hazelnusse/toolchain/lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [build/robot.bike.elf] Error 1

From what I can tell, this is caused by the fact that the symbol __main_stack_end__ is extern declared with two different types. In crt0.c it is:

Code: Select all

extern uint32_t __main_stack_end__;

while in the various vectors.c it is:

Code: Select all

extern void __main_stack_end__(void);

So in one case it is a uint32_t and in the other case it is a function pointer. Later in crt0.c, a the fill32 used is used on __main_stack_end__ and maybe a simple cast here would do the trick, rather than redeclaring the type of __main_stack_end__ to be a uint32_t.

If there is a simple work around for this, I'd be interested to try it out and report back.

Thanks,
Luke

[Giovanni]

Hi,

Last time I used LTO I got bad results from benchmarks, I will look into that declaration.

Giovanni

[hazelnusse]

I tried commenting that bit out since it is only used if you want to fill the stack with special characters, and it compiled and linked fine but the code size ballooned for me, I'm not sure why. I think LTO is still quite immature in gcc.

Either way, the type mismatch would probably be good to take care of.

[Tommino]

Months ago I had the same problem, when I ran static code verification tool over ChibiOS and I had to "harmonized" types to match each other. I can also run MISRA 2004 checker over the code, is there some interest? For sure, there will be (lot of) violations, but it will be nice to clean-up the code to open the door to many industries because there is MISRA a must (automotive and also slowly aerospace and other).
-Tommino

[Giovanni]

Hi,

Feel free to post your results in case there are significant violations. The problem with MISRA is that it is way too restrictive and not meaningful in some cases.

From my experience code where MISRA is strongly enforced becomes cluttered with useless casts and other workarounds around harmless constructs.

Giovanni

[Giovanni]

Hi,

Update, a fix has been committed for the conflicting types issue.

Giovanni