Re: Fix more of C/fortran canonical type issues

[Jan Hubicka <hubicka at ucw dot cz>]

> > Hi,
> > I would like to ping this.  There are still few things to fix to make our
> > merging compliant at least for C/C++/Fortran rules (the array bounds for
> > Fortran and union ordering for C I believe) and I would like to progress
> > on this.
> 
> I don't like the changes to useless_type_conversion_p much.  Why
> do you preserve qualifiers for the integer kind compares?
> 
> All the testcases have the integral types in aggregates as members.
> I already said that I'm happy globbing them together in aggregates.

I originally made the testcase this way because I wanted to test the way
aggregates are built and because it needs less of fortran code to realize it.
It is possible to consutrct same testcase with scalar variables.  See the other
patch fixing the surprious warning.  You need also variant "size_t a" to be
compatible with fortran equivalent of "signed size_t a", so it is not only
about variables.

> 
> I'm still not convinced that we need a 1:1 correspondence between
> canonical types and alias sets.  In particular canonical types are
> used for type compatibility in lhs = rhs assignments
> (useless_type_conversion_p) which is a transitive relation.
> Mixing both too much will cause serious confusion.  We have
> alias-sets for a reason.

OK, I am not sure if canonical types needs to actually mean the type
compatibility in the middle-end sense.  It is a language specific thing:

   The "canonical" type for this type node, which is used by frontends to
   compare the type for equality with another type.  If two types are
   equal (based on the semantics of the language), then they will have
   equivalent TYPE_CANONICAL entries.

In a way TYPE_CANONICAL seems bit schizofrenic about if it means language level
compatibility, representation compatibility or middle end semantic
compatibility.  It seems bit odd to define something like
useless_type_conversion_p by language specific manner despite the fact its
definition is now sound in language independent way as we now have all semantics
represented in IL (and flags, well)

but I would be happy to update the patch to assign different canonical types to
signed/unsigned integers and avoid recursion on those for aggregates/arrays and
all other derived types. (After all I plan to do that for pointers
incrementally)

Here we are "lucky" that alias.c already contains the globbing for
signed/unsigned.  Do we want to do the same scheme in other cases? For example
next on my list is the fact that array with bounds 3...5 is interoperable with
array[3] in C.  Here again we can not consider these useless_type_conversion_p
because index operation is different, but they are representation compatible.
This will need a special case in get_alias_set. I would not like to make
get_alias_set, or (with less loss of code quality on non-C languages) in lto's
get_alias_set langhook.

Honza
> 
> Richard.