On Mon, 22 Jun 2015, Jan Hubicka wrote: > > > 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.
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'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. Richard.
