g++ and aliasing bools

[Dan Nicolaescu]

Mark Mitchell <mark@codesourcery.com> writes:

  > > An incremental improvement would be to allow at least C-type structs.
  > >
  > > {
  > >   if (AGGREGATE_TYPE_P (t) &&
  > >      IS_A_CLASS_DERIVED_FROM_ANOTHER_CLASS_P (t)) /* [1] */
  > >     return 0;
  > >
  > >   return c_common_get_alias_set (t);
  > > }
  > >
  > > should be safe because:
  > > a) the predicate [1] is true for any aggregate that is not a C-type struct
  > > b) c_common_get_alias_set deals with C-type structs correctly
  > > c) C-type structs cannot alias derived classes because the later are
  > >    put in alias set 0 because of [1]
  > >
  > 
  > See this is where things get subtle.  You have to (at least) worry
  > about whether or not t is zero-sized or has zero-sized bases or members.
  > If it does, there may be other zero-sized things at the same address.
  > If that's so, then if you put the zero-sized things in different alias
  > sets, you're saying they never alias.  Now, obviously, we never read or
  > write zero-sized things -- but different alias sets also implies that
  > &x != &y which is false.


I bootstrapped this version on sparc-sun-solaris2.8:

{
  if (AGGREGATE_TYPE_P (t) &&
      !((TREE_CODE (t) == RECORD_TYPE)
        && !CLASSTYPE_NON_POD_P(t)
        && !CLASSTYPE_N_BASECLASSES(t)))
      return 0;
  }
 
 return c_common_get_alias_set (t);
}

This is quite conservative, (the CLASSTYPE_N_BASECLASSES test might not
be needed). 
Is it acceptable? 

The test should filter out all the non

AGGREGATE_TYPE_P(TYPE) is defined as: 
  (TREE_CODE (TYPE) == ARRAY_TYPE || TREE_CODE (TYPE) == RECORD_TYPE \
   || TREE_CODE (TYPE) == UNION_TYPE || TREE_CODE (TYPE) == QUAL_UNION_TYPE \
   || TREE_CODE (TYPE) == SET_TYPE)

I am not sure which of these apply to C++, it seems that only
RECORD_TYPE and UNION_TYPE should be taken into consideration. Is that
true? 


The test results are:


                === g++ Summary ===

# of expected passes            6805
# of unexpected failures        18
# of expected failures          95
# of untested testcases         19
# of unsupported tests          1

Unfortunately I don't have the results before the change. 
I'll bootstrap again without the change and rerun the tests, this
will take a few hours.

        --dan