https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67966
--- Comment #6 from Jan Hubicka <hubicka at ucw dot cz> --- > It's again a move between a BLKmode RHS and a DImode LHS. Frankly, I don't > understand why this is now allowed to reach the RTL expander, we will probably > need to add conversions on quite a number of paths instead of having a single > treatment in the VIEW_CONVERT_EXPR case... This was a outcome of dicussion of the patch: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02392.html I believe the general idea is that modes should not be part of GIMPLE's type system and things will work bit smoother if we do not produce VIEW_CONVERT_EXPRs for these. Originally the code also skipped TYPE_MODE checking for aggregates only, but it checked TYPE_CANONICAL which, at least in a way built by Ada, seems to be never same for two types of different modes. Either we commit to this decision and add conversions to the paths as needed (indeed it seems like there will be quite few) or we can decide that mode should match. This should be accomplished by the patch attached which permits only conversions from incomplete types (where mode ought to be VOIDmode). This patch bootstraps/regtested ppc64-linux. Going either way is not going to block my original desire to fix LTO's type based alias analysis for cross-language cases. Here I needed to make TYPE_CANONICAL to match for cases where are not useless_type_conversion, thus the motivation to get rid of this use of TYPE_CANONICAL and make it agan TBAA specific. In this respect I would grealy apprechiate help with adding Ada testcases. The testcases I added for Fortran basically iterate through list of types that should be compatible with C variants and checks that TBAA works and that no surprious warnings are output. See testsuite/gfortran.dg/lto/bind_c-* Because I do not understand Ada much, I would really apprechiate if you or someone at Adacore could prepare Ada variants of these testcases. Note that I am not done with Fortran and C standards yet - we have at least two deviations still. C standard state that order of fields in union does not matter and Fortran has character type that apparently forces compatibility between array and scalar char. I am not sure if the second can be done reliably (because proably there are ABIs out there that require char and array of char of size 1 to be passed differently). Perhaps this can be handled as a defect in the standard. There is also case where global variable of Fortran variant of size_t (which is signed) will produce warning when matched by size_t declared variable. I have a patch for this but I am looking for cleaner solution. Index: gimple-expr.c =================================================================== --- gimple-expr.c (revision 228851) +++ gimple-expr.c (working copy) @@ -88,9 +88,12 @@ useless_type_conversion_p (tree outer_ty return true; /* Changes in machine mode are never useless conversions unless we - deal with aggregate types in which case we defer to later checks. */ + deal with aggregate types in which case we defer to later checks. + For Aggregates we allow casts to incomplete types that always have + VOIDmode. */ if (TYPE_MODE (inner_type) != TYPE_MODE (outer_type) - && !AGGREGATE_TYPE_P (inner_type)) + && (!AGGREGATE_TYPE_P (inner_type) + || COMPLETE_TYPE_P (outer_type))) return false; /* If both the inner and outer types are integral types, then the
