mipsisa64-elf tools compile from unified tree with sources dated 2003-07-28 00:00 UTC. 55 [ldt-sj3-010] gccspin % mipsisa64-elf-gcc -G0 -mabicalls -c trimmed.c trimmed.c: In function `a': trimmed.c:14: error: unrecognizable insn: (insn 59 58 16 (set (reg:SI 28 gp) (unspec_volatile [ (const_int 0 [0x0]) ] 10)) -1 (nil) (nil)) trimmed.c:14: internal compiler error: in extract_insn, at recog.c:2064 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. 56 [ldt-sj3-010] gccspin % mipsisa64-elf-gcc -v Reading specs from /projects/bbp_ext13/systems/users/cgd/proj/gcc-testing6/work/mipsisa64-elf.install/bin/../lib/gcc-lib/mipsisa64-elf/3.4/specs Configured with: /home/cgd/proj/gcc-testing6/combined/configure --target=mipsisa64-elf --prefix=/home/cgd/proj/gcc-testing6/work/mipsisa64-elf.install Thread model: single gcc version 3.4 20030727 (experimental) 57 [ldt-sj3-010] gccspin % the source file will be attached shortly. (i happened to trip over this, while looking into another problem, hence the strange options.)
Created attachment 4499 [details] source file to demonstrate problem. compile as: mipsisa64-elf-gcc -G0 -mabicalls -c trimmed.c
On the mainline (Mon Jul 28 22:55:27 UTC 2003) with a cross from powerpc-apple- darwin6.6, I do not get the ICE. ./xgcc -B. -G0 -mabicalls pr11699.c -S Can you try with a new gcc (sorry if this is the next day but who knows)? Also do you use any patch in the version of gcc? ./xgcc -B. -v Reading specs from ./specs Configured with: ../configure --target=mipsisa64-unknown-elf --disable-nls --enable- languages=c Thread model: single gcc version 3.4 20030728 (experimental)
Subject: Re: internal compiler error, unrecognized instruction. At 29 Jul 2003 02:13:22 -0000, pinskia at physics dot uc dot edu wrote: > Can you try with a new gcc (sorry if this is the next day but who > knows)? checking out 2003-07-29 03:00 UTC (i.e., sources from about 15 minutes ago 8-) now. I'll report results when i have them. > Also do you use any patch in the version of gcc? no (not in this case).
yup, still there with sources dated 2003-07-29 00:00 UTC. host is x86 linux Red Hat 7.2. You'll note that the host compiler is 3.2.3 with some local mods. the only mods in that compiler for x86 hosts is that -fno-strict-alias is hard-wired. (I ran into too many problems w/ strict aliasing on RH 6.0 systems, on which i need to compile some binaries.) as noted previously, no mods to the gcc (or other tools) that i'm compiling. (because i'm sure somebody will ask, i'll also try to build the tools w/ /usr/bin/gcc. 8-) mipsisa64-elf-gcc -v -G0 -mabicalls -c trimmed.c produces: Reading specs from /projects/bbp_ext13/systems/users/cgd/proj/gcc- testing6/work/mipsisa64-elf.install/bin/../lib/gcc-lib/mipsisa64-elf/3.4/specs Configured with: /home/cgd/proj/gcc-testing6/combined/configure -- target=mipsisa64-elf --prefix=/home/cgd/proj/gcc-testing6/work/mipsisa64- elf.install Thread model: single gcc version 3.4 20030729 (experimental) /projects/bbp_ext13/systems/users/cgd/proj/gcc-testing6/work/mipsisa64- elf.install/bin/../lib/gcc-lib/mipsisa64-elf/3.4/cc1 -quiet -v - iprefix /projects/bbp_ext13/systems/users/cgd/proj/gcc-testing6/work/mipsisa64- elf.install/bin/../lib/gcc-lib/mipsisa64-elf/3.4/ trimmed.c -G0 -quiet - dumpbase trimmed.c -mabicalls -auxbase trimmed -version -o /tmp/ccjLQUYm.s ignoring nonexistent directory "/projects/bbp_ext13/systems/users/cgd/proj/gcc- testing6/work/mipsisa64-elf.install/mipsisa64-elf/sys-include" ignoring duplicate directory "/home/cgd/proj/gcc-testing6/work/mipsisa64- elf.install/lib/gcc-lib/mipsisa64-elf/3.4/include" ignoring nonexistent directory "/home/cgd/proj/gcc-testing6/work/mipsisa64- elf.install/mipsisa64-elf/sys-include" ignoring duplicate directory "/home/cgd/proj/gcc-testing6/work/mipsisa64- elf.install/mipsisa64-elf/include" #include "..." search starts here: #include <...> search starts here: /projects/bbp_ext13/systems/users/cgd/proj/gcc-testing6/work/mipsisa64- elf.install/lib/gcc-lib/mipsisa64-elf/3.4/include /projects/bbp_ext13/systems/users/cgd/proj/gcc-testing6/work/mipsisa64- elf.install/mipsisa64-elf/include End of search list. GNU C version 3.4 20030729 (experimental) (mipsisa64-elf) compiled by GNU C version 3.2.3 with SiByte modifications. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 trimmed.c: In function `a': trimmed.c:14: error: unrecognizable insn: (insn 59 58 16 (set (reg:SI 28 gp) (unspec_volatile [ (const_int 0 [0x0]) ] 10)) -1 (nil) (nil)) trimmed.c:14: internal compiler error: in extract_insn, at recog.c:2064 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Subject: Re: internal compiler error, unrecognized instruction. At Tue, 29 Jul 2003 05:48:29 +0000 (UTC), "cgd at broadcom dot com" wrote: > (because i'm sure somebody will ask, i'll also try to build the tools > w/ /usr/bin/gcc. 8-) same behaviour, this time GCC reports as its version: GNU C version 3.4 20030729 (experimental) (mipsisa64-elf) compiled by GNU C version 2.96 20000731 (Red Hat Linux 7.1 2.96-98). (Yes, that's the compiler on a RH 7.2 system. "don't ask me." 8-) Andrew, what assembler were you using? In particular, were you using one for which GCC decided to use -mexplicit-relocs. (gcc does use explicit relocs with the the assembler i'm using -- from cvs binutils as of the same date as gcc.) I just tried to compile with: mipsisa64-elf-gcc -mno-explicit-relocs -v -G0 -mabicalls -c trimmed.c and the compile went fine. chris
I was not using any as which gave by default the MIPS as which is wrong in this case. I can confirm this with `./cc1 -G0 -mexplicit-relocs -mabicalls pr11699.c'. Since the option -mexplicit-relocs did not exist before 3.4, this is not a regression.
Subject: Re: internal compiler error, unrecognized instruction. At 29 Jul 2003 17:43:46 -0000, pinskia at physics dot uc dot edu wrote: > Since the option -mexplicit-relocs did not exist before 3.4, this is not a regression. Let me try to spin this my way. 8-) Consider the args: -G0 -mabicalls pr11699.c gcc 3.3 + stock binutils of approximately same vintage: works fine as far as i know. I've not tested it, but I've never seen problems like this before... CVS gcc + CVS binutils of same vintage: crashes. no "-mexplicit-relocs" options is needed in the latter case, because -mexplicit-relocs is the *default*. I.e., compiling this test program with "-G0 -mabicalls" on top of the built-in defaults used to work, and now does not. So, regression. On simple solution to the regression would be to disable -mexplicit-relocs by default, but that would seriously bite. 8-) (I can provide you the scripts that i use to checkout and combine, if that'd help you demonstrate to your satisfaction.) chris
You are right that it is an user visible regression so for not reading the previous comment right.
Looks like it's my fault.
Note that the problem is the combination of -mabicalls with the configuration's default -mabi=eabi. I don't think anyone has defined an abicalls version of EABI. Perhaps it would be best to just report an error in this case. What do you think?
Subject: Re: [3.4 Regression] internal compiler error, unrecognized instruction. At Thu, 7 Aug 2003 20:05:39 +0000 (UTC), "rsandifo at gcc dot gnu dot org" wrote: > I don't think anyone has defined an abicalls version of EABI. > Perhaps it would be best to just report an error in this case. > What do you think? that'd be reasonable. now i'm wondering why it was "OK" with no explicit relocs... i guess the assembler was falling back to *something* which at least compiled/assembled... cgd
Subject: Bug 11699 CVSROOT: /cvs/gcc Module name: gcc Changes by: rsandifo@gcc.gnu.org 2003-08-09 07:09:14 Modified files: gcc : ChangeLog gcc/config/mips: mips.c Log message: PR target/11699 * config/mips/mips.c (override_options): Reject -mabi=eabi -mabicalls. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.746&r2=2.747 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/mips/mips.c.diff?cvsroot=gcc&r1=1.295&r2=1.296
Now produces an error as agreed.