This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Incorrect bitfield aliasing with Tree SSA
> > No. You assign those fields precisely to the alias set of the type of
> > the record that it's in. Why would you want to make a new type?
>
> Not a new type just a new alias set. As you return the parent alias
> set of the field right now you might as well return a separate alias
> set different from the type's alias set.
OK, same question: why do you need a new alias set? The one for the
parent works fine.
> 1) We need to correctly track the subset relationship so that
> structure-field aliasing receives valid information. Without this
> we miss the reference to the field when the parent is accessed.
Wrong! There IS no subset relationship. The type of the field is
COMPLETELY IRRELEVANT FOR ANY PURPOSE in the non-addressable cases
(bitfields in C and no-aliased in Ada).
> > For one thing, the C bitfield cases and the Ada non-aliased cases
> > are *identical*: in both cases, a pointer to the type of the field
> > can't conflict with a reference to the type of the struct.
>
> Right but the two cases are different in the complexity of the
> solution they require. For bitfields we can just record the subtype
> relationship whereas for Ada the subtyping would introduce unnecessary
> dependecies.
No. They are COMPLETELY IDENTICAL. If you don't understand that, then
you don't understand this issue. This always worked right in the past.
Somebody broke it someplace in tree-level code by using the wrong alias
set (that of the field's type instead of the parent's type) and all that
has to be done is to find that place and fix it. Everything else is fine.