This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Reload patch for 3.1


    Reload is so notoriously hairy that changing things in there makes me
    nervous.  Can you explain the patch in a bit more detail?  What's going
    wrong, and how does this fix it?

As I said, the problem is a SUBREG in an operand with a 'p' constraint.
'p' sets WIN to 1, intending to say that this can be reloaded.  But the SUBREG
in this case sets force_reload to say that a reload is necessary.  But WIN
only clears BADOP if force_reload is not set, and it isn't here.

Since this reload can be done, BADOP should be 0, and should have been set
to zero at this stop, but it doesn't matter except in the SUBREG case because
WIN is also set.

I'm pretty sure (and can almost "prove") that this only affects things
that would presently ICE.  The above argument is essentially a proof
of that statement.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]