Re: Fix more of C/fortran canonical type issues

[Jan Hubicka <hubicka@ucw.cz>]

> > On Mon, 8 Jun 2015, Jan Hubicka wrote:
> > 
> > > > 
> > > > I think we should instead work towards eliminating the get_alias_set
> > > > langhook first.  The LTO langhook variant contains the same handling, btw,
> > > > so just inline that into get_alias_set and see what remains?
> > > 
> > > I see, i completely missed existence of gimple_get_alias_set. It makes more
> > > sense now.
> > > 
> > > Is moving everyting to alias.c realy a desirable thing? If non-C languages do
> > > not have this rule, why we want to reduce the code quality when compiling
> > > those?
> > 
> > Well, for consistency and for getting rid of one langhook ;)
> :)
> In a way this particular langhook makes sense to me - TBAA rules are language specific.
> We also may with explicit streaming of the TBAA dag, like LLVM does.
> 
> Anyway, this is the updated patch fixing the Fortran's interoperability with
> size_t and signed char.  I will send separate patch for the extra lto-symtab
> warnings shortly.
> 
> I will be happy looking into the TYPE_CANONICAL (int) to be different from
> TYPE_CANONICAL (unsigned int) if that seems desirable. There are two things that
> needs to be solved - hash_canonical_type/gimple_canonical_types_compatible_p can't
> use TYPE_CNAONICAL of subtypes in all cases (that is easy) and we will need some
> way to recognize the conflict in lto-symtab other thanjust comparing TYPE_CANONICAL
> to not warn when a variable is declared signed in Fortran unit and unsigned in C.
> 
> Bootstrapped/regtested ppc64le-linux.
> 
> 	* lto/lto.c (hash_canonical_type): Do not hash TYPE_UNSIGNED
> 	of INTEGER_TYPE.
> 	* tree.c (gimple_canonical_types_compatible_p): Do not compare TYPE_UNSIGNED
> 	of INTEGER_TYPE.
> 	* gimple-expr.c (useless_type_conversion_p): Move INTEGER type handling
> 	ahead the canonical type lookup.
> 
> 	* gfortran.dg/lto/bind_c-2_0.f90: New testcase
> 	* gfortran.dg/lto/bind_c-2_1.c: New testcase
> 	* gfortran.dg/lto/bind_c-3_0.f90: New testcase
> 	* gfortran.dg/lto/bind_c-3_1.c: New testcase
> 	* gfortran.dg/lto/bind_c-4_0.f90: New testcase
> 	* gfortran.dg/lto/bind_c-4_1.c: New testcase

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.

Honza