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