[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
                 CC|                            |ebotcazou at gcc dot
                   |                            |gnu.org

--- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-05-01 08:46:28 UTC ---
> The root problem seems to be that the SPARC port allows a change from DImode to
> SImode for regno 66 (%f34) (by CANNOT_CHANGE_MODE_CLASS) even though there's no
> %f35 and no way to move around such a small quantity, also specified through
> HARD_REGNO_MODE_OK(either of 66 and 67, SImode) being 0.

Right, CANNOT_CHANGE_MODE_CLASS doesn't need to prohibit mode changes already
forbidden by HARD_REGNO_MODE_OK.  I'm a bit reluctant to tweak the macro on the
release branches because this is a sensitive one.

> It seems wrong for the sparc CANNOT_CHANGE_MODE_CLASS to not refuse this
> change, but also wrong for subreg_get_info to not consult HARD_REGNO_MODE_OK
> when setting info.representable_p (as "%f35" is flagged as representable, which
> it isn't according to the related field comment in rtl.h).  There's a kludge
> involving the latter, that implies that such a non-representable register is
> expected to be flagged as representable (ugh!), see last "return -1" in
> simplify_subreg_regno.

Indeed, looks like SPARC gets bitten by its own laziness here.  I think that we
should first try to get rid of the kludge on the mainline.  I'll investigate on
my side.