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

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488

--- Comment #6 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-03-12 14:15:48 UTC ---
(In reply to comment #5)
> +          size_max = (1 << GET_MODE_BITSIZE (GET_MODE (my_fp))) - 1;
> +          if (size >= size_max)
> Do you have a guarantee that GET_MODE_BITSIZE here is never 32 or more?

Yes, Pmode is HImode is 16 bits. For 8-bit SP targets only the lower 8 bits of
the SP hard register are changed which saves some bytes of code and avoids
writing the SP_H register which is not present on these devices. For teh latter
case, mode is QImode.

> (1 << GET_MODE_BITSIZE (GET_MODE (my_fp))) - 1 is GET_MODE_MASK (GET_MODE
> (my_fp)).

Not exactly; the latter is unsigned.

>  And, why >= ?  Subtracting 255 for 8-bit fp or 65535 for 16-bit fp
> should still work.

This line saturates to 255 instead of to 256 because the next line effectively
does size = size % 256 which would yield size = 0 for specific values. This
lead to yet another ICE because it results in SP = SP insn which does not
exist.

I tried to keep the change minimal.

Therefore, the patch uses 255 instead of 256. As of the hardware layout of
these small devices, there is already some margin for sane memory sizes resp.
SP offsets: The device in question has a RAM of 128 bytes located at
0x60..0xbf. The next bigger devices have 256 bytes of RAM located at
0x60..0x15f and RAM crosses the 0x100 border so that these devices use a 16-bit
SP.

My intention was to be conservative and not to put too much effort and changes
to support insane code that definitely breaks if executed.

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 or whatever and
tries to build insane code with 2050 bytes of stack for device(s) with only 128
bytes of RAM.