gcc (GCC) 4.7.0 20111029 (experimental) Newlib cvs head as of same date m32c-rtems4.11-gcc --pipe -mcpu=m32cm --pipe -DHAVE_CONFIG_H -I.. -I../../../lib/include -D__RTEMS_INSIDE__ -g -O2 -Wall -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -mcpu=m32cm -MT src/libscore_a-heap.o -MD -MP -MF src/.deps/libscore_a-heap.Tpo -c -o src/libscore_a-heap.o `test -f 'src/heap.c' || echo '/users/joel/test-gcc/rtems/cpukit/score/'`src/heap.c In file included from ../../../lib/include/rtems/score/basedefs.h:25:0, from ../../../lib/include/rtems/score/types.h:22, from ../../../lib/include/rtems/score/cpu.h:40, from ../../../lib/include/rtems/score/percpu.h:22, from ../../../lib/include/rtems/system.h:23, from /users/joel/test-gcc/rtems/cpukit/score/src/heap.c:28: ../../../lib/include/rtems/score/cpuopts.h:56:0: warning: "__RTEMS_SIZEOF_VOID_P__" redefined [enabled by default] In file included from /users/joel/test-gcc/rtems/cpukit/score/src/heap.c:23:0: ../config.h:465:0: note: this is the location of the previous definition /users/joel/test-gcc/rtems/cpukit/score/src/heap.c: In function '_Heap_Initialize': /users/joel/test-gcc/rtems/cpukit/score/src/heap.c:300:1: error: unable to find a register to spill in class 'A_REGS' /users/joel/test-gcc/rtems/cpukit/score/src/heap.c:300:1: error: this is the insn: (insn 119 118 120 13 (set (mem/s:SI (subreg:PSI (reg/f:SI 30 [ first_block.3 ]) 0) [3 first_block.3_22->prev_size+0 S4 A8]) (reg/v:SI 28 [ heap_area_end ])) /users/joel/test-gcc/rtems/cpukit/score/src/heap.c:260 98 {movsi_24} (nil)) /users/joel/test-gcc/rtems/cpukit/score/src/heap.c:300:1: internal compiler error: in spill_failure, at reload1.c:2118 Please submit a full bug report,
Created attachment 25670 [details] Preprocessed source code
xgcc (GCC) 4.8.0 20121103 (experimental) [trunk revision 193124] Now fails just building libgcc with what appears to be the same error. Short command line for preprocessed source I will attach /home/joel/v850/tools/b-gcc-svn/./gcc/xgcc -B/home/joel/v850/tools/b-gcc-svn/./gcc/ -c m32c_bug.c -O2 -mcpu=m32cm At -O0, it compiles Full command line: /home/joel/v850/tools/b-gcc-svn/./gcc/xgcc -B/home/joel/v850/tools/b-gcc-svn/./gcc/ -nostdinc -B/home/joel/v850/tools/b-gcc-svn/m32c-rtems4.11/newlib/ -isystem /home/joel/v850/tools/b-gcc-svn/m32c-rtems4.11/newlib/targ-include -isystem /home/joel/v850/tools/gcc-svn/newlib/libc/include -B/home/joel/v850/install/m32c-rtems4.11/bin/ -B/home/joel/v850/install/m32c-rtems4.11/lib/ -isystem /home/joel/v850/install/m32c-rtems4.11/include -isystem /home/joel/v850/install/m32c-rtems4.11/sys-include -g -O2 -mcpu=m32cm -O2 -I../../../../gcc-svn/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../gcc-svn/libgcc -I../../../../gcc-svn/libgcc/. -I../../../../gcc-svn/libgcc/../gcc -I../../../../gcc-svn/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _ffssi2.o -MT _ffssi2.o -MD -MP -MF _ffssi2.dep -DL_ffssi2 -c ../../../../gcc-svn/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS ../../../../gcc-svn/libgcc/libgcc2.c: In function '__ffssi2': ../../../../gcc-svn/libgcc/libgcc2.c:524:1: error: unable to find a register to spill in class 'A_REGS' } ^ ../../../../gcc-svn/libgcc/libgcc2.c:524:1: error: this is the insn: (insn 58 56 59 10 (set (reg:HI 0 r0 [orig:26 D.2772 ] [26]) (zero_extend:HI (mem/u/j:QI (plus:PSI (subreg:PSI (reg:SI 68 [ D.2773 ]) 0) (symbol_ref:PSI ("__clz_tab") [flags 0x40] <var_decl 0xb77dc5c0 __clz_tab>)) [0 __clz_tab S1 A8]))) ../../../../gcc-svn/libgcc/libgcc2.c:522 115 {zero_extendqihi2} (expr_list:REG_DEAD (reg:SI 68 [ D.2773 ]) (nil))) ../../../../gcc-svn/libgcc/libgcc2.c:524:1: internal compiler error: in spill_failure, at reload1.c:2124 0x849f565 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc-svn/gcc/rtl-error.c:110 0x849f2c3 spill_failure ../../gcc-svn/gcc/reload1.c:2124 0x849f2c3 find_reload_regs ../../gcc-svn/gcc/reload1.c:2050 0x849f2c3 select_reload_regs ../../gcc-svn/gcc/reload1.c:2070 0x849f2c3 reload(rtx_def*, int) ../../gcc-svn/gcc/reload1.c:991 0x83cb8ea do_reload ../../gcc-svn/gcc/ira.c:4636 0x83cb8ea rest_of_handle_reload ../../gcc-svn/gcc/ira.c:4737
Created attachment 28604 [details] libgcc preprocessed file which trips bug Description on how to reproduce given messages.
This bug had vanished with gcc-4.7.2, but has returned with gcc-4.8.0: /builddir/build/BUILD/rtems-4.11-m32c-rtems4.11-gcc-4.8.0/build/./gcc/xgcc -B/builddir/build/BUILD/rtems-4.11-m32c-rtems4.11-gcc-4.8.0/build/./gcc/ -nostdinc -B/builddir/build/BUILD/rtems-4.11-m32c-rtems4.11-gcc-4.8.0/build/m32c-rtems4.11/newlib/ -isystem /builddir/build/BUILD/rtems-4.11-m32c-rtems4.11-gcc-4.8.0/build/m32c-rtems4.11/newlib/targ-include -isystem /builddir/build/BUILD/rtems-4.11-m32c-rtems4.11-gcc-4.8.0/gcc-4.8.0/newlib/libc/include -B/opt/rtems-4.11/m32c-rtems4.11/bin/ -B/opt/rtems-4.11/m32c-rtems4.11/lib/ -isystem /opt/rtems-4.11/m32c-rtems4.11/include -isystem /opt/rtems-4.11/m32c-rtems4.11/sys-include -g -O2 -mcpu=m32cm -O2 -I../../../../gcc-4.8.0/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../gcc-4.8.0/libgcc -I../../../../gcc-4.8.0/libgcc/. -I../../../../gcc-4.8.0/libgcc/../gcc -I../../../../gcc-4.8.0/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _ffsdi2.o -MT _ffsdi2.o -MD -MP -MF _ffsdi2.dep -DL_ffsdi2 -c ../../../../gcc-4.8.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS ../../../../gcc-4.8.0/libgcc/libgcc2.c: In function '__ffssi2': ../../../../gcc-4.8.0/libgcc/libgcc2.c:522:1: error: unable to find a register to spill in class 'A_REGS' } ^ ../../../../gcc-4.8.0/libgcc/libgcc2.c:522:1: error: this is the insn: (insn 58 56 59 10 (set (reg:HI 0 r0 [orig:26 D.2817 ] [26]) (zero_extend:HI (mem/u/j:QI (plus:PSI (subreg:PSI (reg:SI 44 [ D.2818 ]) 0) (symbol_ref:PSI ("__clz_tab") [flags 0x40] <var_decl 0x7f55b9a14ab0 __clz_tab>)) [0 __clz_tab S1 A8]))) ../../../../gcc-4.8.0/libgcc/libgcc2.c:520 115 {zero_extendqihi2} (expr_list:REG_DEAD (reg:SI 44 [ D.2818 ]) (nil))) ../../../../gcc-4.8.0/libgcc/libgcc2.c:522: confused by earlier errors, bailing out
Created attachment 32892 [details] Patch to fix the ICE on building libgcc I tried this patch on 4.9.0 and 4.10 trunk. It seems to work. At least it is successfully building libgcc and libquadmath, but I cannot test, if the generated code works in practice. Maybe one of you can test it?
Hello- I ran into the same error message as below while compiling for m32c ('error: unable to find a register to spill in class 'A_REGS'') I applied the patches provided in Comment 5 Now the build succeeds. Cannot test code coming out of the build, though. newlib-2.2.0 binutils-2.25 gcc-4.9.2
DJ.. do you think the patch from Bernd can be applied to the 4.9 branch? and maybe the head?
There are a few regressions in the testsuite (pr26255.c with -mcpu=m32c for example) and libstdc++ still doesn't build, but ieee/920810-1 now passes and newlib builds. I suppose that's "better".
I updated binutils, newlib and gcc. The build fails very early for me: /users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc/xgcc -B/users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc/ -nostdinc -B/users/joel/test-gcc/b-m32c-rtems4.11-gcc/m32c-rtems4.11/newlib/ -isystem /users/joel/test-gcc/b-m32c-rtems4.11-gcc/m32c-rtems4.11/newlib/targ-include -isystem /users/joel/test-gcc/gcc/newlib/libc/include -B/users/joel/test-gcc/install-head/m32c-rtems4.11/bin/ -B/users/joel/test-gcc/install-head/m32c-rtems4.11/lib/ -isystem /users/joel/test-gcc/install-head/m32c-rtems4.11/include -isystem /users/joel/test-gcc/install-head/m32c-rtems4.11/sys-include -g -O2 -mcpu=m32cm -O2 -I../../../../gcc/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../gcc/libgcc -I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../../gcc/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS /tmp/ccx0vJbF.s: Assembler messages: /tmp/ccx0vJbF.s: Error: relocation out of range make[4]: *** [_muldi3.o] Error 1
Hmm... I use this configuration: binutils-build: ../binutils-2.25/configure --prefix=/home/ed/gnu/m32c-rtems --target=m32c-rtems --disable-werror gcc-build: ../gcc-trunk/configure --prefix=/home/ed/gnu/m32c-rtems --target=m32c-rtems --enable-languages=c --disable-libssp Revision: 219900 with above patch. => build succeeds. But pr26255.c does not work. I have no idea how to fix that. Something wrong with addpsi3 constraints? I think there is another relatively simple issue with exception handling. What are your configure options?
I see the "relocation out of range" error too. I'm configuring for m32c-elf
The reloc bug is caused when gcc puts a JMP.A at the very end of .text and also adds debug info; this puts a 3-byte reloc right at the end of a section (m32c-as pads the last section if it's a code section, the debug info makes .text not last) but BFD has no option for a non-power-of-two reloc in the HOWTO table, so it thinks it's 4 bytes and thus extends past the end of the section. I suspect the way to fix this is to handle that one reloc specially (the rest are handled by generic reloc handlers), unless someone has an alternate idea?
ok, now I see. the binutils-2.25.tar.gz works, but if we build directly from the git it does not. is this a new check that makes this problem? regarding my patch on pr26255.c, this happens: m32c-elf-gcc -O1 -mcpu=m32c pr26255.c pr26255.c: In function 'foo': pr26255.c:31:1: error: insn does not satisfy its constraints: } ^ (insn 62 61 63 2 (set (reg:PSI 4 a0) (plus:PSI (reg:PSI 4 a0) (reg/v/f:PSI 28 [ w ]))) pr26255.c:29 5 {addpsi3} (expr_list:REG_EQUIV (plus:PSI (reg/v/f:PSI 28 [ w ]) (const_int 128 [0x80])) (nil))) pr26255.c:31:1: internal compiler error: in extract_constrain_insn, at recog.c:2246 0x9e9478 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc-trunk/gcc/rtl-error.c:110 0x9e949f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc-trunk/gcc/rtl-error.c:121 0x9c0505 extract_constrain_insn(rtx_insn*) ../../gcc-trunk/gcc/recog.c:2246 0x9a1a5d reload_cse_simplify_operands ../../gcc-trunk/gcc/postreload.c:430 0x9a4485 reload_cse_simplify ../../gcc-trunk/gcc/postreload.c:207 0x9a4485 reload_cse_regs_1 ../../gcc-trunk/gcc/postreload.c:246 0x9a459b reload_cse_regs ../../gcc-trunk/gcc/postreload.c:94 0x9a459b execute ../../gcc-trunk/gcc/postreload.c:2367 I had similar traps and could avoid them by adding an explicit mode to some patterns. But here I have no idea at the moment. DJ do you see anything obvious in the addpsi3 pattern?
Author: edlinger Date: Fri Jan 23 16:32:34 2015 New Revision: 220048 URL: https://gcc.gnu.org/viewcvs?rev=220048&root=gcc&view=rev Log: 2015-01-23 Bernd Edlinger <bernd.edlinger@hotmail.de> PR target/50928 * config/m32c/m32c.c (encode_pattern_1): Removed gcc_unreachable here. (DEBUG_RELOAD): Removed define. (m32c_limit_reload_class): Enable traces with if DEBUG0. (m32c_function_arg): Added a type cast. (m32c_legitimize_reload_address): Push A_REGS reload with PSImode. * config/m32c/addsub.md (addsi3_1): Specify the mode of all arguments. * config/m32c/bitops.md (andqi3_16): Likewise. * config/m32c/mov.md (m32c_immd_dbl_mov): Likewise. (push_a01_l): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m32c/addsub.md trunk/gcc/config/m32c/bitops.md trunk/gcc/config/m32c/m32c.c trunk/gcc/config/m32c/mov.md
The binutils team has been working a lot on patching vulnerabilities in the binutils tools. The m32c, however, has a 3-byte reloc that might occur at the end of a section, and was implemented as three bytes of a four-byte "word", which would then be outside the bounds of the section. Recent patches check for such bounds crossings, hence the breakage. I've checked in a patch to binutils head to manually process the R_M32C_24 relocations so that the range checking is more appropriate to the three-byte relocation.
(In reply to DJ Delorie from comment #15) > The binutils team has been working a lot on patching vulnerabilities in the > binutils tools. The m32c, however, has a 3-byte reloc that might occur at > the end of a section, and was implemented as three bytes of a four-byte > "word", which would then be outside the bounds of the section. Recent > patches check for such bounds crossings, hence the breakage. I've checked > in a patch to binutils head to manually process the R_M32C_24 relocations so > that the range checking is more appropriate to the three-byte relocation. Which version of binutils was the patch released in?
*** Bug 63683 has been marked as a duplicate of this bug. ***
Can the bug be marked as resolved?
(In reply to Martin Liška from comment #18) > Can the bug be marked as resolved? WAITING on a reply
I filed this in 2011 and we dropped RTEMS support for the m32c last year for our next release. If you all think it is fixed, please feel free to close it.
(In reply to Joel Sherrill from comment #20) > I filed this in 2011 and we dropped RTEMS support for the m32c last year for > our next release. If you all think it is fixed, please feel free to close it. OK.