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).