[PATCH] Tree SRA and atomicity/volatility

[Mark Mitchell]

Richard Guenther wrote:

>> I understand Daniel's comments about wanting to make sure that we're
>> checking the right flags, but the basic issue seems entirely independent
>> of Ada.  If there's an assignment of a volatile object to a non-volatile
>> object, I think we should avoid splitting the copy, in order to reduce
>> the chances that we're accessing volatile words multiple times.
> 
> We don't have defined what TYPE_VOLATILE on a structure type means.

In general, GCC's middle-end implements C, unless otherwise specified.
Now, it's true that ISO C also doesn't completely say what volatile
means on a struct, as discussed in the previous thread.  (For example,
if the struct is 8 bytes, and the machine only has 4 byte loads, it is
not guaranteed that the accesses are ordered in any particular way.)

But, I think your statement is overly broad.  We certainly know some
things about volatile.  For example, it's a bad thing to generate two
references to the same byte of a volatile object when only one appears
in the source.  So, we should prefer word accesses to byte accesses,
when we think we can.

I'm a big fan of specifications, but volatile is something where, in
practice, best-effort and semi-formal rules are probably the best we can
do, in the context of a portable compiler with a big legacy codebase.
There are enough defect reports about volatile in the C and C++
standards to make me think that there's no clear consensus about exactly
what ought to be done, but, clearly, volatile is a useful concept, and
we should try to do our best.

> Of course fixing SRA with Erics patch is not wrong - but it will make us
> not fix the bug or missing feature on the mainline, it's only papering over
> at one specific place.

I don't think it's papering over anything.  It just may not be the
complete solution.  The fact that it's not complete doesn't mean it's
not a good start.  Is there some more generic, over-arching mechanism
that you think will solve the whole problem?  That's a serious question,
but my expectation is that there's nothing for it but to handle this
case-by-case, in which case Eric's approach is a fine step.

> And without a set of sophisticated testcases we're
> going to regress again without noticing.

Yes, test cases are good.  If Eric's patch didn't have a test case, then
one should be added.

My concern is that we not block incremental progress just because we
don't have a 100% solution.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713