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.