Created attachment 32073 [details] Testcase This might be a dup of PR52372 or PR57933 but since I am not sure I am opening a new bug. When trying to compile powerpc libgcc fp-bit I get an ICE using trunk: $ /home/pmatos/projects/EXTERNAL/GCC/builds/gcc-trunk_powerpc/./gcc/cc1 -fpreprocessed fp-bit.i -quiet -dumpbase fp-bit.c -msoft-float -mcpu=8540 -auxbase-strip _addsub_df.o -g -g -g -O2 -O2 -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fbuilding-libgcc -fno-stack-protector -fvisibility=hidden -o fp-bit.s GNU C (GCC) version 4.9.0 20140205 (experimental) (powerpc-eabispe) compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.1-p2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.9.0 20140205 (experimental) (powerpc-eabispe) compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.1-p2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 52229a64c376a95d997a16c551e2c79f fp-bit.i: In function ‘fn3’: fp-bit.i:27:1: internal compiler error: in dwf_regno, at dwarf2cfi.c:909 } ^ 0x786749 dwf_regno ../../../gcc-trunk/gcc/dwarf2cfi.c:909 0x78696b dwarf2out_flush_queued_reg_saves ../../../gcc-trunk/gcc/dwarf2cfi.c:988 0x789981 scan_trace ../../../gcc-trunk/gcc/dwarf2cfi.c:2522 0x789ab2 create_cfi_notes ../../../gcc-trunk/gcc/dwarf2cfi.c:2565 0x78a553 execute_dwarf2_frame ../../../gcc-trunk/gcc/dwarf2cfi.c:2925 0x78b402 execute ../../../gcc-trunk/gcc/dwarf2cfi.c:3421 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. I will attach the fp-bit.i reduced version.
I can confirm this problem on the GCC 4.9.0 release. This is a bit unfortunate since on 2014-04-17 everything was fine: http://gcc.gnu.org/ml/gcc-testresults/2014-04/msg01349.html
Sorry, but my test run on 2014-04-17 used --disable-multilib, so it didn't build the multilib in question. So the problem was also present on 2014-04-17.
*** Bug 60945 has been marked as a duplicate of this bug. ***
I had to go back a bit to find a problematic commit: 3983036a8b6b2710c57777194f21507819a73553 is the first bad commit commit 3983036a8b6b2710c57777194f21507819a73553 Author: chrbr <chrbr@138bc75d-0d04-0410-961f-82ee72b054a4> Date: Tue May 21 07:48:08 2013 +0000 2013-05-21 Christian Bruel <christian.bruel@st.com> * dwarf2out.c (multiple_reg_loc_descriptor): Use dbx_reg_number for spanning registers. LEAF_REG_REMAP is supported only for contiguous registers. Set register size out of the PARALLEL loop. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@199132 138bc75d-0d04-0410-961f-82ee72b054a4 :040000 040000 434a95d8d10d5196bc464622e1741164eb2f5d79 06baa9f87c6c993c6cd76d187246db20f793098e M gcc If I revert this patch on the current 4.9 branch, then I still get an ICE: fp-bit.c: In function '_fpadd_parts': fp-bit.c:738:1: internal compiler error: in dwf_regno, at dwarf2cfi.c:909 } ^ 0x405adf dwf_regno /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:909 0x532cdb dwf_regno /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:909 0x532cdb dwarf2out_flush_queued_reg_saves /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:990 0x534cf3 scan_trace /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:2415 0x535308 create_cfi_notes /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:2565 0x535308 execute_dwarf2_frame /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:2925 0x535308 execute /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:3421 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
With different starting points I found another commit that leads to a similar failure: 561af01c2c9ba4c5df95348d8252896088147e32 is the first bad commit commit 561af01c2c9ba4c5df95348d8252896088147e32 Author: hjl <hjl@138bc75d-0d04-0410-961f-82ee72b054a4> Date: Wed Nov 27 23:54:26 2013 +0000 Also handle REG_XXX notes in spill_pseudos PR rtl-optimization/59311 * dwarf2cfi.c (dwf_regno): Assert reg isn't pseudo register. * lra-spills.c (spill_pseudos): Handle REG_XXX notes. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205468 138bc75d-0d04-0410-961f-82ee72b054a4 :040000 040000 518275c5696e814bd8f7970a5914e09f0fa7f5aa 16da683b4720ab0b343b910718ad7969b0713c2d M gcc This is the error message in this case: /home/sh/git-build/b-gcc-git-powerpc-eabispe/./gcc/xgcc -B/home/sh/git-build/b-gcc-git-powerpc-eabispe/./gcc/ -nostdinc -B/home/sh/git-build/b-gcc-git-powerpc-eabispe/powerpc-eabispe/newlib/ -isystem /home/sh/git-build/b-gcc-git-powerpc-eabispe/powerpc-eabispe/newlib/targ-include -isystem /home/sh/archive/gcc-git/newlib/libc/include -B/home/sh/install-gcc-git/powerpc-eabispe/bin/ -B/home/sh/install-gcc-git/powerpc-eabispe/lib/ -isystem /home/sh/install-gcc-git/powerpc-eabispe/include -isystem /home/sh/install-gcc-git/powerpc-eabispe/sys-include -g -O2 -msoft-float -O2 -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/home/sh/archive/gcc-git/libgcc -I/home/sh/archive/gcc-git/libgcc/. -I/home/sh/archive/gcc-git/libgcc/../gcc -I/home/sh/archive/gcc-git/libgcc/../include -DHAVE_CC_TLS -o _divxc3.o -MT _divxc3.o -MD -MP -MF _divxc3.dep -DL_divxc3 -c /home/sh/archive/gcc-git/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS 0x406285 dwf_regno /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:909 0x534aa4 vec<queued_reg_save, va_heap, vl_embed>::truncate(unsigned int) /home/sh/archive/gcc-git/gcc/vec.h:892 0x534aa4 vec<queued_reg_save, va_heap, vl_ptr>::truncate(unsigned int) /home/sh/archive/gcc-git/gcc/vec.h:1559 0x534aa4 dwarf2out_flush_queued_reg_saves /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:996 0x53616f scan_trace /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:2522 0x536b1e create_cfi_notes /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:2565 0x536b1e execute_dwarf2_frame /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:2925 0x536b1e execute /home/sh/archive/gcc-git/gcc/dwarf2cfi.c:3421 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions In case I revert this patch on the current 4.9 branch (5935f964089edccd96efa7f0bda85800dc0ee31d) I am able to build the powerpc-eabispe target.
I've found a similar problem with dwf_regno() when I tried to bootstrap a ppc-eabispe compiler. The problem there is the register aliasing of r0 between 32 and 64-bit modes. The rs6000 backend uses pseudo registers to disambiguate those two usages. I've posted a patch here <http://gcc.gnu.org/ml/gcc-patches/2014-04/msg02064.html>, but it hasn't been reviewed yet.
I ran into the same problem compiling fp-bit.c. Cesar's patch isn't enough to fix my build on its own -- I also had to revert the r199132 patch Sebastian pointed at in comment 4 to avoid another assertion failure in dbx_reg_number() later on.
(In reply to Sandra Loosemore from comment #7) > I ran into the same problem compiling fp-bit.c. Cesar's patch isn't enough > to fix my build on its own -- I also had to revert the r199132 patch > Sebastian pointed at in comment 4 to avoid another assertion failure in > dbx_reg_number() later on. After these two commits I get another ICE powerpc-oe-linux-gnuspe-gcc -m32 -mcpu=8548 -mabi=spe -mspe -mfloat-gprs=double --sysroot=/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/sysroots/p1022ds -O2 -pipe -g -feliminate-unused-debug-types -O2 -O2 -pipe -g -feliminate-unused-debug-types -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -mlong-double-128 -mno-minimal-toc -I. -I. -I/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work/ppce500v2-oe-linux-gnuspe/libgcc/4.9.0-r0/gcc-4.9.0/build.powerpc-oe-linux-gnuspe.powerpc-oe-linux-gnuspe/powerpc-oe-linux-gnuspe/libgcc/../.././gcc -I/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc -I/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/. -I/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/../gcc -I/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/../include -I/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/../libdecnumber/dpd -I/home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/../libdecnumber -DHAVE_CC_TLS -o decLibrary.o -MT decLibrary.o -MD -MP -MF decLibrary.dep -c /home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/../libdecnumber/decLibrary.c /home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/../libdecnumber/decLibrary.c: In function 'isinfd64': /home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/../libdecnumber/decLibrary.c:60:1: error: unrecognizable insn: } ^ (insn 2 4 3 2 (set (reg/v:DD 128 [ arg ]) (reg:DD 3 3 [ arg ])) /home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/../libdecnumber/decLibrary.c:53 -1 (nil)) /home/kraj/work/angstrom-repo/sources/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.9.0-r0/gcc-4.9.0/libgcc/../libdecnumber/decLibrary.c:60:1: internal compiler error: in extract_insn, at recog.c:2202 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions.
I've been looking at this a little bit more. DWARF_FRAME_REGNUM is specifically documented to take a hard register number as its operand, so the assertion in dwf_regno is at least consistent with that. The one in dbx_reg_number is more dubious, since neither LEAF_REG_REMAP or DBX_REGISTER_NUMBER are documented to require a hard register number. So: either the powerpc backend is broken to be using a pseudo in this context, or else the documentation for DWARF_FRAME_REGNUM should be changed to permit this and the assertions (as necessary) moved into the target-specific implementations of these macros.
Please specify more exactly the affected target triplet and specify a known-to-work version. Marking as regression for now.
(In reply to Richard Biener from comment #10) > Please specify more exactly the affected target triplet and specify a > known-to-work version. > > Marking as regression for now. A target is for example "powerpc-eabispe" or "powerpc-rtems". Known to work are GCC 4.8.0, 4.8.1, 4.8.2 and 4.8.3.
(In reply to Sandra Loosemore from comment #9) > I've been looking at this a little bit more. > > DWARF_FRAME_REGNUM is specifically documented to take a hard register number > as its operand, so the assertion in dwf_regno is at least consistent with > that. The one in dbx_reg_number is more dubious, since neither > LEAF_REG_REMAP or DBX_REGISTER_NUMBER are documented to require a hard > register number. > > So: either the powerpc backend is broken to be using a pseudo in this > context, or else the documentation for DWARF_FRAME_REGNUM should be changed > to permit this and the assertions (as necessary) moved into the > target-specific implementations of these macros. All those routines are supposed to implement mappings from GCC internal hard register numbers to some externally-defined number scheme (DWARF, DBX, ...), so it is consistent that they only accept hard register numbers. The rs6000 back-end isn't actually attempting to use a "pseudo", they're just using a quick hack there: apparently, with SPE registers, GCC internal hard registers 0 .. 31 may be backed by a pair of external registers in debug info, where the high element of the pair gets a DWARF number in the 1200 ... 1231 range. The rs6000_dwarf_register_span attempts to implement that by returning a PARALLEL of two registers. Now, according to the rules, those both ought to be hard registers. However, there is no GCC internal number defined for the high part of the pair. The back-end used to hack around that by simply using the DWARF number (in the 1200 ... 1231) range as "hard" regno, combined with another hack in rs6000_dbx_register_number that then just passes that number through unchanged to the DWARF assembler output. This all worked as long as the middle-end didn't look too closely at those PARALLELs ... but with those extra asserts, it now fails. I guess I don't quite understand why there aren't real GCC hard regnos to cover those SPE high parts ... that seems the cleanest solution. Not sure if this was done to avoid some drawback I'm not seeing right now ...
(In reply to Khem Raj from comment #8) > error: unrecognizable insn: > } > ^ > (insn 2 4 3 2 (set (reg/v:DD 128 [ arg ]) > (reg:DD 3 3 [ arg ])) This is PR57353.
I have tried to handle this as per comment #12. https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00513.html
GCC 4.9.1 has been released.
Author: edmarwjr Date: Mon Aug 4 16:34:34 2014 New Revision: 213596 URL: https://gcc.gnu.org/viewcvs?rev=213596&root=gcc&view=rev Log: PR target/60102 [libgcc] 2014-07-31 Rohit <rohitarulraj@freescale.com> * config/rs6000/linux-unwind.h (ppc_fallback_frame_state): Update based on change in SPE high register numbers and 3 HTM registers. [gcc] 2014-07-31 Rohit <rohitarulraj@freescale.com> * config/rs6000/rs6000.c (rs6000_reg_names) : Add SPE high register names. (alt_reg_names) : Likewise. (rs6000_dwarf_register_span) : For SPE high registers, replace dwarf register numbers with GCC hard register numbers. (rs6000_init_dwarf_reg_sizes_extra) : Likewise. (rs6000_dbx_register_number): For SPE high registers, return dwarf register number for the corresponding GCC hard register number. * config/rs6000/rs6000.h (FIRST_PSEUDO_REGISTER) : Update based on 32 newly added GCC hard register numbers for SPE high registers. (DWARF_FRAME_REGISTERS) : Likewise. (DWARF_REG_TO_UNWIND_COLUMN) : Likewise. (DWARF_FRAME_REGNUM) : Likewise. (FIXED_REGISTERS) : Likewise. (CALL_USED_REGISTERS) : Likewise. (CALL_REALLY_USED_REGISTERS) : Likewise. (REG_ALLOC_ORDER) : Likewise. (enum reg_class) : Likewise. (REG_CLASS_NAMES) : Likewise. (REG_CLASS_CONTENTS) : Likewise. (SPE_HIGH_REGNO_P) : New macro to identify SPE high registers. * gcc.target/powerpc/pr60102.c: New testcase. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.h trunk/gcc/config/rs6000/rs6000.md trunk/libgcc/ChangeLog trunk/libgcc/config/rs6000/linux-unwind.h
Author: edmarwjr Date: Mon Aug 4 16:48:53 2014 New Revision: 213597 URL: https://gcc.gnu.org/viewcvs?rev=213597&root=gcc&view=rev Log: PR target/60102 [libgcc] 2014-08-04 Rohit <rohitarulraj@freescale.com> * config/rs6000/linux-unwind.h (ppc_fallback_frame_state): Update based on change in SPE high register numbers and 3 HTM registers. [gcc] 2014-08-04 Rohit <rohitarulraj@freescale.com> * config/rs6000/rs6000.c (rs6000_reg_names) : Add SPE high register names. (alt_reg_names) : Likewise. (rs6000_dwarf_register_span) : For SPE high registers, replace dwarf register numbers with GCC hard register numbers. (rs6000_init_dwarf_reg_sizes_extra) : Likewise. (rs6000_dbx_register_number): For SPE high registers, return dwarf register number for the corresponding GCC hard register number. * config/rs6000/rs6000.h (FIRST_PSEUDO_REGISTER) : Update based on 32 newly added GCC hard register numbers for SPE high registers. (DWARF_FRAME_REGISTERS) : Likewise. (DWARF_REG_TO_UNWIND_COLUMN) : Likewise. (DWARF_FRAME_REGNUM) : Likewise. (FIXED_REGISTERS) : Likewise. (CALL_USED_REGISTERS) : Likewise. (CALL_REALLY_USED_REGISTERS) : Likewise. (REG_ALLOC_ORDER) : Likewise. (enum reg_class) : Likewise. (REG_CLASS_NAMES) : Likewise. (REG_CLASS_CONTENTS) : Likewise. (SPE_HIGH_REGNO_P) : New macro to identify SPE high registers. [gcc/testsuite] 2014-08-04 Rohit <rohitarulraj@freescale.com> * gcc.target/powerpc/pr60102.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/powerpc/pr60102.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.h branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.md branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/libgcc/ChangeLog branches/gcc-4_9-branch/libgcc/config/rs6000/linux-unwind.h
Author: edmarwjr Date: Mon Aug 4 16:55:07 2014 New Revision: 213598 URL: https://gcc.gnu.org/viewcvs?rev=213598&root=gcc&view=rev Log: [gcc/testsuite] 2014-08-04 Rohit <rohitarulraj@freescale.com> PR target/60102 * gcc.target/powerpc/pr60102.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr60102.c Modified: trunk/gcc/testsuite/ChangeLog
GCC 4.9.2 has been released.
The commits from comments #16 and #17 broke the compiler (and bootstrap) on powerpc-apple-darwin9: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703
(In reply to Francois-Xavier Coudert from comment #20) > The commits from comments #16 and #17 broke the compiler (and bootstrap) on > powerpc-apple-darwin9: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703 Sorry. The "REGISTER_NAMES" macro that was updated in "rs6000.h" file gets redefined in "darwin.h" file. I can provide the required patch, but I don't have a darwin machine to test the changes.
> Sorry. The "REGISTER_NAMES" macro that was updated in "rs6000.h" file gets > redefined in "darwin.h" file. I can provide the required patch, but I don't > have a darwin machine to test the changes. If you upload a patch on the bugzilla entry, I will test it. FX
Sounds like fallout on the 4.9 branch is not fixed yet (ppc-darwin bootstrap fail) but the original bug is fixed? Please open new bugs for new issues.
(In reply to Richard Biener from comment #23) > Sounds like fallout on the 4.9 branch is not fixed yet (ppc-darwin bootstrap > fail) but the original bug is fixed? Please open new bugs for new issues. That looks like it. The ppc-darwin issues (4.9 and trunk) were reported there: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703