Re: [PATCH] Fix inconsistency with alias_sets_conflict_p and alias_set_subset_of

[Richard Guenther <rguenther at suse dot de>]

On Thu, 15 Apr 2010, Paolo Bonzini wrote:

> >> > Well, yes. ?[...] The problem is that C character types use the magic
> >> > alias-set zero. ?So we'd pessimize every structure containing a char
> >> > to effectively have disabled TBAA - the workaround was to have this
> >> > weird inversion.
> >>
> >> Why should it apply to unions too, though? ?Unions with an alias-zero member
> >> should also get alias zero, period.
> >
> > Because we can't distinguish the case. ?I'm not arguing against what
> > is correct here just with past experience that the C/C++ frontend
> > is not willing to change that character types have alias-set zero.
> 
> Surely we can use a different routine for UNION_TYPE and RECORD_TYPE,
> or an extra argument?

Where exactly?  For alias_sets_conflict_p?  If I'd be asked the
C/C++ FE maintainers would fix their frontend instead ...
And we go into DR territorry again.

struct X { char x; };

int y;

((struct X *)&y)->x

is that an lvalue of character type?  I doubt so.

char x;

x

is that an lvalue of character type?  Yes.  Does it matter here?  No.

Thus, it only matters for pointer dereferences where the frontend
should know exactly if it _is_ supposed to be an lvalue of
character type.  On the mem-ref2 branch it can then simply,
instead of a plain INDIREC_REF (p), emit a MEM_REF (T, p)
with a pointer type T that when dereferenced uses alias-set zero
(a ref-all pointer to char maybe).

That is, char should not have alias-set zero.

Richard.