[PATCH] fix PR middle-end/17885, gimplifing of volatile &a->b

[Andrew Pinski]

On Oct 18, 2004, at 3:58 PM, Richard Kenner wrote:

>     I think that should still be the general case; if we're taking the 
> address
>     of, say, a struct returned from a function, we want to propagate
>     TREE_SIDE_EFFECTS from the call to the ADDR_EXPR.
>
> I wonder if the problem isn't here:
>
>   if (TREE_CODE (node) == INDIRECT_REF)
>     {
>       /* If this is &((T*)0)->field, then this is a form of addition.  
> */
>       if (TREE_CODE (TREE_OPERAND (node, 0)) != INTEGER_CST)
> 	UPDATE_TITCSE (node);
>
> Shouldn't that last "node" be TREE_OPERAND (node, 0)?  We don't care 
> about
> the INDIRECT_REF here: all we care about is its operand.

Yes but we don't UPDATE_TITCSE on the INDRIECT_REF for the case which I 
am
looking at.
We have <COMPONENT_REF <INDIRECT_REF <VAR_DECL <VOLATILE> SIDE_EFFECTS>
SIDE_EFFECTS> in my case.  The reason why COMPONENT_REF got the 
SIDE_EFFECTS
is because the INDIRECT_REF got it, this is done in build3. So the 
address
expression still gets the SIDE_EFFECTS.

Here is another testcase where SIDE_EFFECTS needs to be set to true and
where we ICE without the patch:
struct lock {
  int lk_interlock;
};
volatile struct lock *f();
void
acquire(void)
{
   &f()->lk_interlock;
}

Maybe we should ignore ADDR_EXPR instead of the patch where I call
gimplify_addr_expr (but I could be wrong).

-- Pinski