This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug other/22368] [meta-bugs] mis-match types in GCC


------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-13 14:16 -------
Note fixing all of these issues and we can remove the "hack" in may_propagate_copy which right now 
says:
  /* FIXME.  GIMPLE is allowing pointer assignments and comparisons of
     pointers that have different alias sets.  This means that these
     pointers will have different memory tags associated to them.

     If we allow copy propagation in these cases, statements de-referencing
     the new pointer will now have a reference to a different memory tag
     with potentially incorrect SSA information.

     This was showing up in libjava/java/util/zip/ZipFile.java with code
     like:

        struct java.io.BufferedInputStream *T.660;
        struct java.io.BufferedInputStream *T.647;
        struct java.io.InputStream *is;
        struct java.io.InputStream *is.662;
        [ ... ]
        T.660 = T.647;
        is = T.660;     <-- This ought to be type-casted
        is.662 = is;

     Also, f/name.c exposed a similar problem with a COND_EXPR predicate
     that was causing DOM to generate and equivalence with two pointers of
     alias-incompatible types:

        struct _ffename_space *n;
        struct _ffename *ns; 
        [ ... ]
        if (n == ns)
          goto lab;
        ...
        lab:
        return n;
   
     I think that GIMPLE should emit the appropriate type-casts.  For the
     time being, blocking copy-propagation in these cases is the safe thing
     to do.  */


-- 


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]