loc_mentioned_in_p invokes undefined behavior

[Alexandre Oliva]

On Nov  5, 2007, Eric Botcazou <ebotcazou@libertysurf.fr> wrote:

>> Debugging this, I realized this function would access every 
>> fld of an RTX as if it was a pointer to an RTX itself.  This is wrong:
>> it makes room for false positives and it accesses as pointers fields
>> that might have been initialized as narrower or otherwise non-pointer
>> values, thus invoking undefined behavior.

> I don't think there is undefined behavior, the code only takes the address of 
> these fields.

Hmm...  Indeed, since these are fields of a union, taking the address
using a static type different from the dynamic type should work.
Thanks.

> /* Return nonzero if IN contains a piece of rtl that has the address LOC.  */
> int
> loc_mentioned_in_p (rtx *loc, const_rtx in)

> means exactly.  My interpretation is that the predicate was intended to be 
> generic, in the sense that you woudn't need to overload it

then it should have taken a void*.  But yes, that makes sense.

>> This patch, that I've already tested in the vta branch, and I'm not
>> re-testing in mainline (x86_64-linux-gnu for both), should fix this
>> problem.  Ok to install?

s/not/now/ sorry

> I don't think that end of Stage 3 is the right time to change the semantics of 
> a predicate that is used by the reload pass.  I think that only what

> 	* rtlanal.c (loc_mentioned_in_p): Test XVECEXPs correctly.

> describes is acceptable at this point.

Sounds quite reasonable, under the light of your feedback.  I'll
retest that portion alone.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}