[Bug target/48830] [4.4/4.5/4.6/4.7 Regression] unrecognized insn: storing invalid upper fp reg in SImode to stack

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |ebotcazou at gcc dot
                   |gnu.org                     |gnu.org
   Target Milestone|---                         |4.6.1

--- Comment #10 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-05-01 12:42:36 UTC ---
> A quick vetting of uses will hopefully convince you like me: when CLASS is
> EXTRA_FP_REGS, for at least 4.4 and trunk all uses seem to be from testing an
> "upper" floating-point register number, for which TO has no reason to be
> SImode.

That's what I'm not convinced of.  In 64-bit mode, the 'e' constraint is mapped
to EXTRA_FP_REGS, not FP_REGS, so this class cannot be used to distinguish
lower from upper regs in a bunch of FP insns.

I don't think the bug is serious enough as to warrant any risk on old (4.4/4.5)
release branches; a simple workaround is to replace -O2 with -O on the command
line.  But I agree that fixing it in 4.6.1 would be desirable.

> BTW incidentally-related: maybe a good time to introduce a register class that
> is actually the EXTRA_FP_REGS (the upper ones), with its current contents
> renamed to ALL_FP_REGS. See "misnomer" in the sparc.h enum reg_class comment.

This would be sort of an earthquake in the back-end though.

> Very much appreciated.  Feel free to take the bug; I'm unassigning myself as I
> can't commit to testing the patches (at least) the next few days.

OK, I'm taking it.