http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
--- Comment #7 from Ralf Corsepius <ralf_corsepius at rtems dot org> 2012-03-13 03:28:39 UTC --- Result with your patch applied: ... ./../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c: In function 'glob': ../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c:206:1: error: allocating 2050 bytes of stack is more than 'at90s2313' can provide make[8]: *** [lib_a-glob.o] Error 1 => Progress, at least no ICE. However, this warning still leaves users in unclearity as GCC doesn't tell the maximum of stack it can provide. (In reply to comment #6) > avr-gcc 4.7 implements PR51345 which result in new multilib variants for tiny > devices with only 8-bit SP. > > newlib derives its build configury from -print-multi-directory Yes, that's the way multilibs are being built ever since multilibs exists (> 20 years?). > or whatever and > tries to build insane code with 2050 bytes of stack for device(s) with only > 128 > bytes of RAM. Well, my view is different: 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.
