[Bug target/25603] [4.1/4.2 Regression]: Miscompiled FORTRAN program

wilson at gcc dot gnu dot org gcc-bugzilla@gcc.gnu.org
Tue Jan 31 03:49:00 GMT 2006

------- Comment #7 from wilson at gcc dot gnu dot org  2006-01-31 03:49 -------
Things start going wrong in the reload inheritance code.  For reload 0, for
insn 11, we choose to inherit the value already in r14 in an inner loop in
choose_reload_regs.  Near the end, we double check to make sure we can still
inherit it, and notice we can't because the reload_reg_unavailable test fails. 
We cancel the inheritance, but we continue to use r14 as the reload reg.  We
then have to reload the value into r14, possibly hoping that post reload cse
can simplify the code.  Unfortunately, r14 is used in an auto-inc address in
this instruction which gets reloaded, so we have two reloads using the same
reg, one of which modifies the reg, and this fails miserably.

The inheritance code is calling find_equiv_reg, and then doing a number of
validity tests on the returned result.  One of the tests it does is to call
regno_clobbered_p.  This makes sure the reg isn't used in a clobber or set, but
it makes no attempt to look for other kinds of side-effects, such as auto-inc
addresses.  I think this is where the error lies.  If we modify
regno_clobberred_p to handle a REG_INC note the same as a clobber, then we
would get the right result here for this testcase, as reload 0 is
RELOAD_FOR_OPERAND_ADDRESS.  I'm not sure if this works in general though.  We
might need to be more strict for regs used in a REG_INC note, e.g. we might
need to disallow them always.

I'm curious whether Bernd's new reload-branch works for this testcase.  I don't
have a post-svn-conversion copy, so I had to check out a new copy and I'm doing
a build now.



More information about the Gcc-bugs mailing list