[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop

["jakub at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #16 from jakub at gcc dot gnu dot org  2007-08-23 12:13 -------
But doesn't ipa_type_escape_field_does_not_clobber_p do what is documented?
At least for the uses in nonoverlapping_memrefs_p where
ipa_type_escape_field_does_not_clobber_p is always called on some field, first
argument is a DECL_FIELD_CONTEXT of some field ans second argument is its type.
Then IMHO ipa_type_escape_field_does_not_clobber_p does the right thing.
If you take address of the whole struct rather than some specific field and
that address doesn't escape the CU, then that still doesn't explain how
could a pointer var with first field's type point to the struct.  Say for
struct A { int i; float f; } you still need (int *) ptrA where ptrA is
struct A *, or &ptrA->i.  Optimizations before ipa-type-escape will transform
the former to the latter and if they don't, I believe check_cast will handle
it anyway.  The only problem in alias.c might be if exprx is COMPONENT_REF
of the first field and expry is a var pointer to the whole struct A (or vice
versa), then any taking of address of the whole struct anywhere would mean
the MEMs could overlap.  But in that case both MEMs will have different alias
sets, don't they?

The ipa_type_escape_field_does_not_clobber_p call in may_alias_p is very
different though.  Here we don't necessarily call it with some record (or
union)
type and a type of one of its fields, but rather with some record type (or
pointer to it, pointer to pointer etc.) and some possibly completely unrelated
other pointer type.  Well, because of previous
if (!alias_sets_conflict_p (mem_alias_set, var_alias_set)) return false;
it shouldn't be completely unrelated.  In most cases it will actually be the
same
type and that's something ipa_type_escape_field_does_not_clobber_p wasn't
meant to answer.  I have instrumented may_alias_p, so that if
ipa_type_escape_field_does_not_clobber_p returned false for reasons other than
!initialized or !ipa_type_escape_type_contained_p, it would abort.
The only testcase in the whole make check-{gcc,g++,gfortran} testsuite
triggering this was gcc.c-torture/execute/builtins/pr22237.c, where var had a
union type which contained ptr's type as one of its subfields.

The whole use of ipa_type_escape_field_does_not_clobber_p in may_alias_p
is very much unclear to me.
E.g.:
              else if (ptr_star_count == 0)
                {
                  /* If PTR_TYPE was not really a pointer to type, it cannot
                     alias.  */
                  alias_stats.structnoaddress_queries++;
                  alias_stats.structnoaddress_resolved++;
                  alias_stats.alias_noalias++;
                  return false;
                }
Isn't ptr guaranteed to be have POINTER_TYPE or REFERENCE_TYPE?  Both from the
way how is ->pointers array populated and e.g. that PTR_IS_REF_ALL is used
before may_alias_p on the p_map->var resp. p_map1->var?  That implies
ptr_star_count > 0, so the above listed chunk is never executed.  Also, as
we don't care in the code whether ptr_star_count is 37 or just 1, I don't see
the point in computing ptr_star_count at all, nor the existence of ptr_type
variable.

If ipa_type_escape_star_count_of_interesting_type (var_type) > 0 (i.e. var is
a pointer to struct/union rather than struct/union itself, how is the fact that
something took address of fields within the struct itself relevant to whether
some pointer may point to the pointer var or not?  If
ipa_type_escape_star_count_of_interesting_type (var_type) == 0, then
ipa_type_escape_field_does_not_clobber_p call would make sense if ptr was
a pointer to some field (field of field etc.), but then it needs to be called
with TREE_TYPE (TREE_TYPE (ptr)) as second argument, otherwise it is asking
a wrong question.  But if ptr's type is the struct/union itself, all we care is
if that record/union's address has been taken, which is not something
ipa-type-escape won't answer.  Isn't that what TREE_ADDRESSABLE can be used
for?

Please explain.


-- 


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