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.
