http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
--- Comment #9 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-10-18
15:42:44 UTC ---
(In reply to comment #8)
> Would it make sense to make the statement volatile even if only some
> subcomponents (or all subcomponents) are volatile?
>
> I like (2); if I understand it correctly, in this case vv1 and vv2 would not
> be
> volatile, but you'd still have
>
> vv1 ={v} vv2;
>
> in the GIMPLE source. It should be possible to use a bit on
> {ARRAY,RECORD,UNION,QUAL_UNION}_TYPE to cache this, e.g.
>
> #define TYPE_HAS_VOLATILE_PARTS(T) \
> (AGGREGATE_TYPE_P (T) \
> ? TYPE_UNSIGNED (T) \
> : TYPE_VOLATILE (T))
>
> #define AGGREGATE_TYPE_CHECK(T) \
> TREE_CHECK4(T, ARRAY_TYPE, RECORD_TYPE, UNION_TYPE, QUAL_UNION_TYPE)
>
> #define SET_TYPE_HAS_VOLATILE_PARTS(T, V) \
> (TYPE_UNSIGNED (AGGREGATE_TYPE_CHECK (T)) = (V))
>
> Separately, expand would of course need to be taught about expanding accesses
> to volatile subcomponents as mem/v. If this approach was feasible, it would
> have the advantage of splitting the task in two parts, one for GIMPLE
> (including possibly the verifier) and one for expand.
If we want to treat vv1 = vv2 as volatile then the frontends can now simply
emit MEM_REF <&vv1> = MEM_REF <&vv2> with TREE_THIS_VOLATILE set and things
should work. That leaves it up to the frontend on how to deal with this.
The much harder question is how to expand vv1 = vv2 "correctly". Thus,
we need to define what happens and document it.
Also consider memcpy (&vv1, &vv2) and eventually the compiler optimizing
that to vv1 = vv2 (note the lack of {v} here).
