This is the mail archive of the 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] handle zero-sized constructor component if side effects

On Mon, 2005-09-12 at 11:43 -0400, Richard Kenner wrote:
>     This will cause you bugs, because nothing expects to see sets of zero
>     sized fields, and it confuses things like subvars, regardless of
>     whether they have side effects or not.
> Well, there *were* certainly a number of bugs a while ago in the area of
> setting and referencing zero-sized fields, but I thought I fixed them all.
> Which did I miss?

We do not expect to see sets of zero sized fields in the instruction
stream in GIMPLE.

They cause issues dealing with subvars.

In particular, because they are zero sized, the subvar code will never
think they overlap with any subvar (becuase in fact, they don't
overlap).  This will in turn cause verification failures.

>     We should still throw the set away, we just need to execute the
>     instructions in the constructor.
> You miss the point.  What we have is a MODIFY_EXPR whose type is zero-sized
> and whose RHS is a CALL_EXPR.  We can't simply "execute" the CALL_EXPR since
> that would only be a valid statement if the type were void, but it is not.

What are you talking about?
This is *exactly* what we do in gimplify_modify_expr.

>     You should be doing what gimplify_modify_expr does, which is to still
>     place the *value* side of the constructor in the instruction stream,
>     just don't assign it to anything.
> Isn't that going to be the ultimate effect of the proposed change?

it's going to create

a.b = call()

a.b will be a set of a zero sized field.

This in turn, will cause the subvar code to break.

And before you say it should handle that, there is no sane way to handle
a zero sized field.  They are meaningless, and stores to them mean
nothing.  The only interesting thing is the side effect from the RHS of
the store to them.

Thus, we should simply be executing the call(), and throwing away the
result, since it's not actually going anywhere.

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