------- Comment #5 from rguenth at gcc dot gnu dot org  2010-02-11 13:31 -------
The basic issue here is that sub0 is inlined into main and we assign different
alias sets to struct my_c_type_1 and struct c_type_1 because they have
different
tags.  Something ok for C but too strict for cross-language TBAA.

Thus tree DSE removes the initialization of c_type.j.

main (<unnamed-signed:32> argc, <unnamed-signed:8> * * argv)
{
  <unnamed-signed:32> D.2072;
  struct my_c_type_1 & restrict my_type;
  struct c_type_1 c_type;
  <unnamed-signed:32> D.2054;

<bb 2>:
  c_type.j = 11;
  my_type_5 = (struct my_c_type_1 & restrict) &c_type;
  D.2072_6 = my_type_5->j;
  if (D.2072_6 != 11)
    goto <bb 3>;
  else
    goto <bb 4>;

<bb 3>:
  _gfortran_abort ();

<bb 4>:
  return 0;

tree DCE doesn't because its aliased.

The offending check in gimple_types_compatible that forces us to not
merge the two structure types is

        /* The struct tags shall compare equal.  */
        if (!compare_type_names_p (TYPE_MAIN_VARIANT (t1),
                                   TYPE_MAIN_VARIANT (t2), false))
          goto different_types;


This bug will only be fully fixed with the introduction of a purely
structural type hierarchy for TBAA.  We can use TYPE_CANONICAL for that
once we make that unnecessary in its current meaning (meaning doing
the gimple type-merging per TU at gimplification time).

For now we can relax the alias-oracle somewhat to give leeway to this
and similar (even if slightly undefined) testcases.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2009-10-10 18:43:53         |2010-02-11 13:31:59
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41664

Reply via email to