http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
--- Comment #11 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-03-13 11:25:04 UTC --- (In reply to comment #7) > However, this warning still leaves users in unclearity as GCC doesn't tell the > maximum of stack it can provide. The compiler does not know. It can estimate the RAM size from the width of the stack pointer, but it's just a guess. > The avr's default set of multilib variants is non-suitable as general > default set of multlib variants. It probably is suiteable as set of > multilibs for bare-metal targets, but does not meet the demands of OSes. > > That said, I feel RTEMS needs to implement custom multilibs for the avr. There is a patch at http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00811.html that is less strict and allows to build insane code without error. If user wants to ensure reasonable code, he can use -Wlarger-than=len -Wframe-larger-than=len -Wstack-usage=len or whatever to let the compiler complain if unappropriate code will be generated. BTW: The -mmcu=at90s2313 from above is fallout from -print-multi-lib. The first two configurations are phantom configurations that should not be there. tiny-stack;@mmcu=at90s2313 avr25/tiny-stack;@mmcu=attiny13 .; avr25;@mmcu=avr25 avr3;@mmcu=avr3 avr31;@mmcu=avr31 avr35;@mmcu=avr35 avr4;@mmcu=avr4 avr5;@mmcu=avr5 avr51;@mmcu=avr51 avr6;@mmcu=avr6 avrxmega2;@mmcu=avrxmega2 avrxmega4;@mmcu=avrxmega4 avrxmega5;@mmcu=avrxmega5 avrxmega6;@mmcu=avrxmega6 avrxmega7;@mmcu=avrxmega7 tiny-stack;@mtiny-stack avr25/tiny-stack;@mmcu=avr25@mtiny-stack
