This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
- From: "ralf_corsepius at rtems dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 13 Mar 2012 06:16:03 +0000
- Subject: [Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
- Auto-submitted: auto-generated
- References: <bug-52488-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
--- Comment #9 from Ralf Corsepius <ralf_corsepius at rtems dot org> 2012-03-13 06:16:03 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> You can look up in the device datasheet to see how much RAM it has.
Well, datasheets is one thing, GCC's internal notion is yet another.
> Or do you want GCC to print out how much RAM each device has?
No, I would expect GCC to print its rationale for this rejection.
e.g. something like
"allocating 2050 byte of stack exceeds maximum stack size (1024 bytes) ..."
> > 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.
>
> Do you have recommendations? Or better still, a patch?
We will see, I am currently looking into implementing custom multilibs for
avr-RTEMS, which may result into a patch addressing this as a side-effect.
However, the avr's multilib implementation diverges from what is used almost
elsewhere in GCC to an extend, this is a tedious.