Historically, from the avr-gcc 4.3.2 compiler used in Arduino, though several intermediate versions, the compiler has become more and more aggressive about in-lining "small" functions, and has done an increasingly bad job of detecting "small" on AVRs (perhaps it bases its decisions on "intermediate code" size rather actual code size.) This is even in the presence of "-Os" compile instructions. (getting optiboot to fit in 512 bytes with newer compilers has meant chasing optimization switches and eventually adding "__attribute__((noinline))" for ... everything.
But a particularly awful example has just surfaced, apparently related to the use of floating point. The following not-very-complex sketch compiles to about 12k with 4.3.2 (Arduino 1.0.6), and bloats to over 44k with 4.8.x (Arduino 1.6.2) This is because the compiler is in-lining calls to "move3Servos(Servo servo1Name, float target_pos1,Servo servo2Name, float target_pos2,Servo servo3Name, float target_pos3,float easing)" and similar, and it ends up NOT being a very small function (over 1k) http://forum.arduino.cc/index.php?action=dlattach;topic=314062.0;attach=121538 http://forum.arduino.cc/index.php?topic=314062 Is there anything that can be done about this? (preferably short of specifying a bunch of obscure special-purpose optimization switches. Perhaps like giving the compiler some per-architecture guess at the average internal->final instruction mapping efficiency?) _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
