https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102
--- Comment #12 from Ulrich Weigand <uweigand at gcc dot gnu.org> --- (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 ...
