[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 --- Comment #15 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-22 15:07:31 UTC --- Author: gjl Date: Thu Mar 22 15:06:57 2012 New Revision: 185697 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185697 Log: libgcc/ Backport from 2012-03-07 mainline r185033. PR target/52507 * config/avr/lib1funcs.S (__movmemx_hi): Fix loop label in RAM-part. Backport from 2012-03-07 mainline r185031. PR target/52505 * config/avr/lib1funcs.S (__xload_1): Don't read unintentionally from RAM. Backport from 2012-03-07 mainline r185030. PR target/52461 PR target/52508 * config/avr/lib1funcs.S (__do_copy_data): Clear RAMPZ after usage if RAMPZ affects reading from RAM. (__tablejump_elpm__): Ditto. (.xload): Ditto. (__movmemx_hi): Ditto. (__do_global_ctors): Right condition for RAMPZ usage is have ELPM. (__do_global_dtors): Ditto. (__xload_1, __xload_2, __xload_3, __xload_4): Ditto. (__movmemx_hi): Ditto. gcc/ Backport from 2012-03-22 mainline r185692. PR target/52496 * config/avr/avr.md (unspec): Remove UNSPEC_MEMORY_BARRIER. (unspecv): Add UNSPECV_MEMORY_BARRIER. (cli_sei): Use unspec_volatile instead of unspec for memory barrier. (delay_cycles_1, delay_cycles_2): Ditto. (delay_cycles_3, delay_cycles_4): Ditto. (nopv, *nopv): Ditto. (sleep, *sleep): Ditto. (wdr, *wdr): Ditto. Backport from 2012-03-21 mainline r185605. PR rtl-optimization/52543 PR target/52461 * config/avr/avr-protos.h (avr_load_lpm): New prototype. * config/avr/avr.c (avr_mode_dependent_address_p): New function. (TARGET_MODE_DEPENDENT_ADDRESS_P): New define. (avr_load_libgcc_p): Restrict to __flash loads. (avr_out_lpm): Only handle 1-byte loads from __flash. (avr_load_lpm): New function. (avr_find_unused_d_reg): Remove. (avr_out_lpm_no_lpmx): Remove. (adjust_insn_length): Handle ADJUST_LEN_LOAD_LPM. * config/avr/avr.md (unspec): Add UNSPEC_LPM. (load_mode_libgcc): Use UNSPEC_LPM instead of MEM. (load_mode, load_mode_clobber): New insns. (movmode): For multi-byte move from non-generic 16-bit address spaces: Expand to load_mode resp. load_mode_clobber. (loadmode_libgcc): Remove expander. (split-lpmx): Remove split. Backport from 2012-03-13 mainline r185329. PR target/52488 * config/avr/avr.c (avr_prologue_setup_frame): Cut down stack offset (size) to a value the insns can deal with. (expand_epilogue): Ditto. Backport from 2012-03-12 mainline r185256. PR target/52499 * config/avr/avr.c (avr_mode_code_base_reg_class): Change return type from reg_class_t to enum reg_class. * config/avr/avr-protos.h (avr_mode_code_base_reg_class): Ditto. Backport from 2012-03-12 mainline r185253. PR target/52148 * config/avr/avr.c (avr_out_movmem): Fix typo in output template for the case ADDR_SPACE_FLASH and AVR_HAVE_LPMX introduced in r184615 from 2012-02-28. Backport from 2012-03-08 mainline r185105. * config/avr/avr.md (*addhi3, addhi3_clobber): Add w alternative for constants in [-63,63]. Backport from 2012-03-08 mainline r185100. PR target/52496 * config/avr/avr.c (avr_mem_clobber): New static function. (avr_expand_delay_cycles): Add memory clobber operand to delay_cycles_1, delay_cycles_2, delay_cycles_3, delay_cycles_4. * config/avr/avr.md (unspec): Add UNSPEC_MEMORY_BARRIER. (enable_interrupt, disable_interrupt): New expander. (nopv, sleep, wdr): New expanders. (delay_cycles_1): Add memory clobber. (delay_cycles_2): Add memory clobber. (delay_cycles_3): Add memory clobber. (delay_cycles_4): Add memory clobber. (cli_sei): New insn from former enable_interrupt, disable_interrupt with memory clobber. (*wdt): New insn from former wdt with memory clobber. (*nopv): Similar, but for nopv. (*sleep): Similar, but for sleep. Backport from 2012-03-07 mainline r185043. PR target/52484 * config/avr/avr.md (xloadmode_A): Add R22... to register footprint. Backport from 2012-03-07 mainline r185032. PR target/52506 * gcc/config/avr/avr.c (expand_epilogue): Fix order of restoration to: RAMPZ, RAMPY, RAMPX, RAMPD. (expand_prologue): Only clear RAMPZ if it has effect on RAM-read. Backport from 2012-03-07 mainline r185031. PR target/52505 * config/avr/avr.c (avr_out_xload): Don't read unintentionally from RAM. * config/avr/avr.md (xload_8): Adjust insn length. Backport from 2012-03-07 mainline r185030. PR target/52461 * gcc/config/avr/avr.c (avr_out_lpm): Clear RAMPZ after usage if RAMPZ affects reading from RAM. Backport from 2012-03-05 mainline r184919. * config/avr/avr.md (*umaddqihi4.2): New insn-and-split. Modified: branches/gcc-4_7-branch/gcc/ChangeLog
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #16 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-22 15:32:41 UTC --- Fixed in 4.7.1
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
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.
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 Joerg Wunsch j at uriah dot heep.sax.de changed: What|Removed |Added CC||j at uriah dot heep.sax.de --- Comment #10 from Joerg Wunsch j at uriah dot heep.sax.de 2012-03-13 07:02:51 UTC --- (In reply to comment #9) 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) ... There is no fixed stack size in GCC. It's just the SRAM size sets an upper limit for the largest possible stack size. Thus Eric's question about printing out the RAM size.
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 --- Comment #11 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-13 11:25:04 UTC --- (In reply to comment #7) However, this warning still leaves users in unclearity as GCC doesn't tell the maximum of stack it can provide. The compiler does not know. It can estimate the RAM size from the width of the stack pointer, but it's just a guess. 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. There is a patch at http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00811.html that is less strict and allows to build insane code without error. If user wants to ensure reasonable code, he can use -Wlarger-than=len -Wframe-larger-than=len -Wstack-usage=len or whatever to let the compiler complain if unappropriate code will be generated. BTW: The -mmcu=at90s2313 from above is fallout from -print-multi-lib. The first two configurations are phantom configurations that should not be there. tiny-stack;@mmcu=at90s2313 avr25/tiny-stack;@mmcu=attiny13 .; avr25;@mmcu=avr25 avr3;@mmcu=avr3 avr31;@mmcu=avr31 avr35;@mmcu=avr35 avr4;@mmcu=avr4 avr5;@mmcu=avr5 avr51;@mmcu=avr51 avr6;@mmcu=avr6 avrxmega2;@mmcu=avrxmega2 avrxmega4;@mmcu=avrxmega4 avrxmega5;@mmcu=avrxmega5 avrxmega6;@mmcu=avrxmega6 avrxmega7;@mmcu=avrxmega7 tiny-stack;@mtiny-stack avr25/tiny-stack;@mmcu=avr25@mtiny-stack
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 --- Comment #12 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-13 11:28:32 UTC --- Author: gjl Date: Tue Mar 13 11:28:25 2012 New Revision: 185329 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185329 Log: PR target/52488 * config/avr/avr.c (avr_prologue_setup_frame): Cut down stack offset (size) to a value the insns can deal with. (expand_epilogue): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 --- Comment #13 from Ralf Corsepius ralf_corsepius at rtems dot org 2012-03-13 14:16:10 UTC --- (In reply to comment #11) (In reply to comment #7) BTW: The -mmcu=at90s2313 from above is fallout from -print-multi-lib. Well, IMO, --print-multi-lib is the only legitmate configuration. FYI: I could provide an alternative configuration for RTEMS, but avr-gcc-4.7.0 currently does not build at all due to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52925 rsp. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52575.
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 --- Comment #14 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-13 18:16:04 UTC --- (In reply to comment #13) FYI: I could provide an alternative configuration for RTEMS, but avr-gcc-4.7.0 currently does not build at all due to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52925 rsp. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52575. 52925 does not exists. You mean PR50925 ? These bugs are hard to fix and open since over 2 years now, see PR42204 You might get around these by building with -fno-caller-saves which avoids the spill fails in some situations. I don't know if someone is working on these issues. AVR with its register layout is real stress test for the register allocator, but AVR is neither primary nor secondary platform so that such bugs are outside the focus of GCC developers.
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 --- Comment #2 from Ralf Corsepius ralf_corsepius at rtems dot org 2012-03-12 06:21:42 UTC --- Created attachment 26876 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26876 *.i of the file triggering the ICE This *.i was created from today's (ca. 2012-03-12 05:00 UTC) gcc from gcc-4_7-branch ../gcc-4.7.0-RC-20120302/configure --prefix=/opt/rtems-4.11 --bindir=/opt/rtems-4.11/bin --exec_prefix=/opt/rtems-4.11 --includedir=/opt/rtems-4.11/include --libdir=/opt/rtems-4.11/lib --libexecdir=/opt/rtems-4.11/libexec --mandir=/opt/rtems-4.11/share/man --infodir=/opt/rtems-4.11/share/info --datadir=/opt/rtems-4.11/share --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=avr-rtems4.11 --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose --with-newlib --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --enable-threads --disable-lto --disable-plugin --enable-newlib-io-c99-formats --enable-newlib-iconv --enable-languages=c ... make ... /builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/build/./gcc/xgcc -B/builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/build/./gcc/ -nostdinc -B/builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/build/avr-rtems4.11/tiny-stack/newlib/ -isystem /builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/build/avr-rtems4.11/tiny-stack/newlib/targ-include -isystem /builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/gcc-4.7.0-RC-20120302/newlib/libc/include -B/opt/rtems-4.11/avr-rtems4.11/bin/ -B/opt/rtems-4.11/avr-rtems4.11/lib/ -isystem /opt/rtems-4.11/avr-rtems4.11/include -isystem /opt/rtems-4.11/avr-rtems4.11/sys-include -mmcu=at90s2313 -DPACKAGE_NAME=\newlib\ -DPACKAGE_TARNAME=\newlib\ -DPACKAGE_VERSION=\1.20.0\ -DPACKAGE_STRING=\newlib\ 1.20.0\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -I. -I../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix -Os -DPREFER_SIZE_OVER_SPEED -mcall-prologues -D_COMPILING_NEWLIB -DMALLOC_PROVIDED -DEXIT_PROVIDED -DSIGNAL_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL -DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT -D_NO_GETPASS -D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN -fno-builtin -D_GNU_SOURCE -g -O2 -c -o lib_a-glob.o `test -f 'glob.c' || echo '../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/'`glob.c ../../../../../../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: unrecognizable insn: (insn/f 305 304 306 2 (set (reg:QI 28 r28) (plus:QI (reg:QI 28 r28) (const_int -2050 [0xf7fe]))) ../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c:160 -1 (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:HI 28 r28) (plus:HI (reg/f:HI 28 r28) (const_int -2050 [0xf7fe]))) (nil))) ../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c:206:1: internal compiler error: in extract_insn, at recog.c:2123 One-tree-style bootstrap (comprising newlib), using avr-rtems4.11-binutils-2.22, newlib-1.20 + rtems patches (glob.c is part of newlib) on fedora-16-x86_64.
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3 |P4
Status|WAITING |NEW
Version|unknown |4.7.0
Target Milestone|--- |4.7.1
--- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-12
11:11:49 UTC ---
Confirmed for the followin test case
void bar (char*);
void foo (void)
{
char c[2000];
bar (c);
}
and compiled with
$ avr-gcc sp.c -S -mmcu=attiny2313
The program should not run into ICE, there should be a proper error message.
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-12 12:37:24 UTC --- Created attachment 26878 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26878 pr52488.diff Does this patch fix the ICE for you?
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-12 12:55:14 UTC --- + 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? (1 GET_MODE_BITSIZE (GET_MODE (my_fp))) - 1 is GET_MODE_MASK (GET_MODE (my_fp)). And, why = ? Subtracting 255 for 8-bit fp or 65535 for 16-bit fp should still work.
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
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.
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
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.
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 --- Comment #8 from Eric Weddington eric.weddington at atmel dot com 2012-03-13 05:37:45 UTC --- (In reply to comment #7) ../../../../../../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. You can look up in the device datasheet to see how much RAM it has. Or do you want GCC to print out how much RAM each device has? 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. Do you have recommendations? Or better still, a patch?
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-03-11 CC||gjl at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-11 22:30:17 UTC --- Would you please add a test case following the instructions in http://gcc.gnu.org/bugs/#need BTW, this appreas to be a frame pointer adjustment for a device with 8-bit SP. Allocating 2050 bytes of stack space on a device with 8-bit SP is not going to produce a reasonable executable, anyway.
