http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488

--- Comment #42 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-12-01 
22:14:23 UTC ---
(In reply to comment #41)
> The warning machinery is faced with:
> 
>   (struct apr_bucket *) &a->list.next
> 
> It doesn't warn because, although &a->list has a different type than struct
> apr_bucket, its field 'next' has the same type as the 'next' sub-field of the
> 'link' field of struct apr_bucket.  Too much sophistication for the machinery.
> One would probably need to mimic the disambiguation rules of tree-ssa-alias.c.
> 
> Richard, any idea?

The frontend machinery uses get_alias_set on types but it should use it
on the references (but it also warns at places that are not memory references
but just pointer casts, which of course will result in false positives and
us not being able to do real analysis).

I am repeatedly about to remove all but the memory-reference cases from
the frontend warning code as with the many false positives people only
learn how to circumvent it via casts which is never a real fix.

If you want to experiment try using get_alias_set on the reference
or get_deref_alias_set on the ADDR_EXPRs.

The warn_strict_aliasing == 2 && !alias_sets_must_conflict_p check doesn't
make sense at all btw. and the alias_sets_conflict_p check should really
be set1 != set2 && !alias_set_subset_of (set2, set1).

The interface of strict_aliasing_warning is also not good.  Callers seem
to check the warning level dependent on if they are in a dereference or
just a casting context, instead they should pass a flag.  And really
the frontend should only warn about the dereference case.

We can do a warning in the middle-end whenever we disambiguate using
TBAA and could not do with only points-to info.   We could restrict this
to type-punned pointers if we can mark them somehow.  But again this
would result in very many false positives.  Warning about TBAA
violations is hard - you have to be better at alias-analysis than
the optimizer (which otherwise would see the alias and not optimize).

Reply via email to