This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug other/22368] [meta-bugs] mis-match types in GCC
- From: "pinskia at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 13 Jul 2005 14:16:30 -0000
- Subject: [Bug other/22368] [meta-bugs] mis-match types in GCC
- References: <20050708152146.22368.pinskia@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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