[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123

["ralf_corsepius at rtems dot org" <gcc-bugzilla at gcc dot gnu dot org>]

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.