Created attachment 9229 [details]
catch mismatch in MODIFY_EXPR

I should note that you can now bootstrap C with the patch.  But still some
testsuite regressions in the 
testsuite which have been filed already.

(In reply to comment #2)
> I should note that you can now bootstrap C with the patch.  But still some testsuite regressions in the 
> testsuite which have been filed already.

With the patch in PR 22358 we can now bootstrap with C++ enabled too.  Though there are many 
regressions which have been filed except for failing to compile testsuite_abi.cc which have not been 
filed/reduced yet but that might not be a C++ specific problem:
/Users/pinskia/src/local/gcc/objdir/powerpc-apple-darwin7.9.0/libstdc++-v3/include/ext/
hashtable.h:793: error: statement types mismatch^M
D.45260_261 = __pD.71381_212;^M
^M
struct pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> 
>,symbol>D.39168 &^M
voidD.34 *^M
/Users/pinskia/src/local/gcc/objdir/powerpc-apple-darwin7.9.0/libstdc++-v3/include/ext/
hashtable.h:793: internal compiler error: verify_stmts failed^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See <URL:http://gcc.gnu.org/bugs.html> for instructions.^M

(In reply to comment #3)
> (In reply to comment #2)
> > I should note that you can now bootstrap C with the patch.  But still some testsuite regressions in 
the 
> > testsuite which have been filed already.
> 
> With the patch in PR 22358 we can now bootstrap with C++ enabled too.  Though there are many 
> regressions which have been filed except for failing to compile testsuite_abi.cc which have not been 
> filed/reduced yet but that might not be a C++ specific problem:
yes this is the same as PR 21840.

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.  */

Note I think I already fixed the DOM problem in PR 22335.

Even though PR 22398 is not caught by my patch it is caught later by VRP.  I
will add a patch to catch 
mismatch in comparisons.

Created attachment 9265 [details]
catch mismatch in comparisons

The patch which catches mismatch in comparisons.

Note the comparisions patch because of the way gimple removes casts to void*
gets:
int f(int *a, char*b)
{
  return ((void*)a) == ((void*)b);
}

wrong.
The following is also effected:
g++.dg/abi/vbase13.C:
g++.dg/expr/cond1.C
g++.old-deja/g++.abi/primary.C

I have to figure out how to handle that.  Maybe in
tree_ssa_useless_type_conversion_1 remove the 
special case for void*.

Created attachment 9294 [details]
catch mismatch in some unary trees

Created attachment 9396 [details]
catch mismatch in PHIs

This patch detects mismatch types in PHI_NODEs which can be used with the one
which catches the one in MODIFY_EXPR as some PHIs get moved to MODIFY_EXPR.

(In reply to comment #6)
> Note I think I already fixed the DOM problem in PR 22335.

And now the java front-end bug has been fixed, maybe I should go ahead and test a patch to remove 
the hack from may_propagate_copy.

I also filed PR 23329 for the removal of the hack.

(In reply to comment #9)
> Note the comparisions patch because of the way gimple removes casts to void*
> gets:
That gets fixed automatically by:
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00179.html

Rev. 124497 of mainline fails to bootstrap with these patches on i686-linux:

[during stage2]
../../../trunk3/gcc/df-scan.c: In function ‘df_ref_record’:
../../../trunk3/gcc/df-scan.c:1057: error: types mismatch in comparsion
long unsigned int

int

shifttmp.1580_150 == 0;

../../../trunk3/gcc/df-scan.c:1057: internal compiler error: verify_stmts
failed

Debugging this error yields:

Breakpoint 5, verify_expr (tp=0xb70f1b5c, walk_subtrees=0xbfa475f0, data=0x0)
    at ../../../trunk3/gcc/tree-cfg.c:3298
3298                error ("types mismatch in comparsion");
(gdb) p debug_tree(lhs)
 <ssa_name 0xb73e498c
    type <integer_type 0xb7bf1438 long unsigned int sizes-gimplified
asm_written public unsigned SI
        size <integer_cst 0xb7be1658 constant invariant 32>
        unit size <integer_cst 0xb7be1444 constant invariant 4>
        align 32 symtab -1211504504 alias set -1 canonical type 0xb7bf1438
precision 32 min <integer_cst 0xb7be16e4 0> max <integer_cst 0xb7be16c8
4294967295>
        pointer_to_this <pointer_type 0xb7a82a8c>>
    var <var_decl 0xb7b3d284 shifttmp.1580> def_stmt <gimple_modify_stmt
0xb7387214>
    version 150>
$1 = void
(gdb) p debug_tree(rhs)
 <integer_cst 0xb7be1c40 type <integer_type 0xb7bf12f4 int> constant invariant
0>
$2 = void

http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01265.html

has some fixes for some of this PRs and a verifier.  So while we're working
on this, this is my bug.

"Finished", so unassigning.

I was willing to check the current state of the Fortran failures (PR28722). I
have thus applied these patches to current trunk, and bootstrap fails due to:

$ cat foo.i
char * getc_unlocked (char *foo) { return foo++; }
$ ../prev-gcc/cc1 -fpreprocessed foo.i -quiet
foo.i: In function ‘getc_unlocked’:
foo.i:1:1: error: types mismatch in comparsion
char *

long unsigned int

foo + 1;

foo.i:1:1: internal compiler error: verify_stmts failed


(In the patches, tree_ssa_useless_type_conversion_1 needs to be changed into
useless_type_conversion_p)

Subject: Re:  [meta-bug] mis-match types in GCC

On Fri, 2 Nov 2007, fxcoudert at gcc dot gnu dot org wrote:

> ------- Comment #17 from fxcoudert at gcc dot gnu dot org  2007-11-02 14:16 -------
> I was willing to check the current state of the Fortran failures (PR28722). I
> have thus applied these patches to current trunk, and bootstrap fails due to:
> 
> $ cat foo.i
> char * getc_unlocked (char *foo) { return foo++; }
> $ ../prev-gcc/cc1 -fpreprocessed foo.i -quiet
> foo.i: In function ‘getc_unlocked’:
> foo.i:1:1: error: types mismatch in comparsion
> char *
> 
> long unsigned int
> 
> foo + 1;
> 
> foo.i:1:1: internal compiler error: verify_stmts failed
> 
> 
> (In the patches, tree_ssa_useless_type_conversion_1 needs to be changed into
> useless_type_conversion_p)

I think all these patches are way out-of-date.  If the fortran FE still
produces mismatched trees (as PR28722 suggests), those should be catched
by --enable-checking=yes,types.

Richard.

All bugs have been closed as fixed, so closing this meta-bug as we have
checking now.