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: [PATCH] fix PR middle-end/17885, gimplifing of volatile &a->b



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


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