[Bug regression/49572] New: [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[Bug regression/49572] New: [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[hp at gcc dot gnu.org]

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

           Summary: [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c
                    scan-tree-dump-times cddce2 ".rtmem" 0
           Product: gcc
           Version: 4.4.7
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: regression
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hp@gcc.gnu.org
                CC: ebotcazou@gcc.gnu.org
              Host: x86_64-unknown-linux-gnu
            Target: cris-axis-elf


This test previously passed, now it fails on the 4.4 branch.
A commit in the revision range 175566:175604, of which the commit at revision
r175603 applies to the 4.4 branch, exposed or caused this regression.
Since then it fails as follows:

...
Running /tmp/hpautotest-gcc44/gcc/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp
...
FAIL: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0
...

The message in gcc.log has no additional information.
The test looks identical to that on trunk, so it doesn't seem to be as trivial
as adjusting it.

Author of suspect patch CC:ed.

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[hp at gcc dot gnu.org]

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

--- Comment #1 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2011-06-29 01:30:53 UTC ---
I don't see this regression on the 4.5 branch after the commit.  The autotester
for the 4.6 branch isn't hasn't tested this yet.

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[hp at gcc dot gnu.org]

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

--- Comment #2 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2011-06-29 04:20:26 UTC ---
Nope, not on 4.6 either; it's just 4.4.  Is it possible that the patch was
backported too far?

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.06.29 06:56:29
     Ever Confirmed|0                           |1

--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-29 06:56:29 UTC ---
(In reply to comment #2)
> Nope, not on 4.6 either; it's just 4.4.  Is it possible that the patch was
> backported too far?

The bug was present on the 4.4 branch and is fixed by the patch so the first
answer is no.  Now some optimizations might rely on it.  Present on x86 too.

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.4.7

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-06-29 09:37:18 UTC ---
I suppose on 4.5 and higher FRE/PRE are strong enough to catch this.  This
testcase has seen multiple adjustments in the past, so I suggest to not
worry and adjust its scan patterns (maybe analyzing what is different now).

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.7                       |---

--- Comment #5 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-29 10:31:38 UTC ---
> I suppose on 4.5 and higher FRE/PRE are strong enough to catch this.  This
> testcase has seen multiple adjustments in the past, so I suggest to not
> worry and adjust its scan patterns (maybe analyzing what is different now).

DOM1 used to declare the expressions generated by

(gdb) p debug_gimple_stmt(stmt1)
# VUSE <SMT.13_17(D)> { SMT.13 }
D.1254_7 = D.1249_5->fld[1].rtmem;

(gdb) p debug_gimple_stmt(stmt2)
# VUSE <SMT.13_17(D)> { SMT.13 }
D.1252_11 = D.1249_5->fld[1].rtmem;

as equivalent.  Now D.1254_7 and D.1252_11 have incompatible types:

(gdb) p debug_tree(0xf7d814d0)
 <ssa_name 0xf7d814d0
    type <pointer_type 0xf7d74c30
        type <record_type 0xf7d74af8 mem_attrs type_0 SI
            size <integer_cst 0xf7ce66ac constant 32>
            unit size <integer_cst 0xf7ce6498 constant 4>
            align 32 symtab 0 alias set -1 canonical type 0xf7d749c0 fields
<field_decl 0xf7d5eb80 foo> context <translation_unit_decl 0xf7d80208 D.1262>
            pointer_to_this <pointer_type 0xf7d74c30>>
        public unsigned SI size <integer_cst 0xf7ce66ac 32> unit size
<integer_cst 0xf7ce6498 4>
        align 32 symtab 0 alias set -1 canonical type 0xf7d74c98>
    visited var <var_decl 0xf7d82160 D.1254>def_stmt D.1254_7 =
D.1249_5->fld[1].rtmem;

    version 7
    ptr-info 0xf7d83114 value 0xf7d7fc40>

(gdb) p debug_tree(0xf7d815b0)
 <ssa_name 0xf7d815b0
    type <pointer_type 0xf7cfc2d8
        type <void_type 0xf7cfc270 void VOID
            align 8 symtab 0 alias set -1 canonical type 0xf7cfc270
            pointer_to_this <pointer_type 0xf7cfc2d8>>
        public unsigned SI
        size <integer_cst 0xf7ce66ac constant 32>
        unit size <integer_cst 0xf7ce6498 constant 4>
        align 32 symtab 0 alias set -1 canonical type 0xf7cfc2d8
        pointer_to_this <pointer_type 0xf7cff820>>
    visited var <var_decl 0xf7d820b0 D.1252>def_stmt D.1252_11 =
D.1249_5->fld[1].rtmem;

    version 11
    ptr-info 0xf7d83150>

so the equivalence is now rejected.

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #6 from Jeffrey A. Law <law at redhat dot com> 2011-06-29 19:26:53 UTC ---
ISTM that DOM considering those two accesses equivalent, even though they had
different types is arguably incorrect behaviour.

I have vague memories that we played things a little fast and loose with types
of memory loads.  ie, if the destination had type T1, but the field reference
had type T2 and we knew that T1 and T2 were the same size, then we'd change the
type of the field reference to T1 and avoid the typecast from T2 to T1.  IIRC
we did this in the gimplifier.

Is that part of the problem here?

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-29 21:14:55 UTC ---
> ISTM that DOM considering those two accesses equivalent, even though they had
> different types is arguably incorrect behaviour.

The accesses themselves have the same type, since they are strictly identical.
The problem is the type of the LHS, which is incompatible between the 2 cases.

> I have vague memories that we played things a little fast and loose with types
> of memory loads.  ie, if the destination had type T1, but the field reference
> had type T2 and we knew that T1 and T2 were the same size, then we'd change the
> type of the field reference to T1 and avoid the typecast from T2 to T1.  IIRC
> we did this in the gimplifier.

After tuplification, DOM records the type of the LHS of assignment statements
as the type of the expression.  And then it tests the compatibility of these
types.
This is problematic because you can have non-compatible types on the LHS and
RHS of assignment statements, if the conversion RHS->LHS is deemed useless,
e.g. for pointers.  See types_compatible_p and useless_type_conversion_p in
tree-ssa.c.

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-30 09:01:00 UTC ---
> After tuplification, DOM records the type of the LHS of assignment statements
> as the type of the expression.  And then it tests the compatibility of these
> types.

Maybe DOM could use the type of the RHS instead in the GIMPLE_SINGLE_RHS case.

On the 4.4 branch, the code generated for the testcase at -O2 is pessimized:

--- old//20030709-2.s   2011-06-30 10:41:30.000000000 +0200
+++ new/20030709-2.s    2011-06-29 12:01:55.000000000 +0200
@@ -8,7 +8,8 @@
        movl    %esp, %ebp
        movl    8(%ebp), %eax
        popl    %ebp
-       cmpl    $1, (%eax)
+       movl    (%eax), %eax
+       cmpl    $1, %eax
        sbbl    %eax, %eax
        ret
        .size   get_alias_set, .-get_alias_set

but it isn't on the other branches.  But DOM is hindered on all branches.

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> 2011-06-30 09:54:49 UTC ---
On Thu, 30 Jun 2011, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49572
> 
> Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |rguenth at gcc dot gnu.org
> 
> --- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-30 09:01:00 UTC ---
> > After tuplification, DOM records the type of the LHS of assignment statements
> > as the type of the expression.  And then it tests the compatibility of these
> > types.
> 
> Maybe DOM could use the type of the RHS instead in the GIMPLE_SINGLE_RHS case.

For loads yes.

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-30 10:30:28 UTC ---
> For loads yes.

OK, what's the right predicate to use on the RHS here?  !is_gimple_val?

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> 2011-06-30 10:42:21 UTC ---
On Thu, 30 Jun 2011, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49572
> 
> --- Comment #10 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-30 10:30:28 UTC ---
> > For loads yes.
> 
> OK, what's the right predicate to use on the RHS here?  !is_gimple_val?

Do we ever end up with stores in that function?  I doubt so given
that expr->ops.single.rhs is set to RHS1.  ISTR DOM enters a load
for a store operation.  So just unconditionally use the type
of rhs1.

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |ebotcazou at gcc dot
                   |gnu.org                     |gnu.org

--- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-30 11:00:09 UTC ---
> Do we ever end up with stores in that function?  I doubt so given
> that expr->ops.single.rhs is set to RHS1.  ISTR DOM enters a load
> for a store operation.  So just unconditionally use the type of rhs1.

Indeed, stores are turned into loads.  OK, I'm going to test the change.

[Bug tree-optimization/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|regression                  |tree-optimization

--- Comment #13 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-30 18:54:22 UTC ---
Recategorizing.

[Bug tree-optimization/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

--- Comment #14 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-30 19:32:29 UTC ---
Author: ebotcazou
Date: Thu Jun 30 19:32:23 2011
New Revision: 175721

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175721
Log:
    PR tree-optimization/49572
    * tree-ssa-dom.c (initialize_hash_element) <GIMPLE_SINGLE_RHS>: Use the
    type of the RHS instead of that of the LHS for the expression type.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-dom.c

[Bug tree-optimization/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

--- Comment #15 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-30 19:35:49 UTC ---
Author: ebotcazou
Date: Thu Jun 30 19:35:45 2011
New Revision: 175722

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175722
Log:
    PR tree-optimization/49572
    * tree-ssa-dom.c (initialize_hash_element) <GIMPLE_SINGLE_RHS>: Use the
    type of the RHS instead of that of the LHS for the expression type.

Modified:
    branches/gcc-4_6-branch/gcc/ChangeLog
    branches/gcc-4_6-branch/gcc/tree-ssa-dom.c

[Bug tree-optimization/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-30 19:37:43 UTC ---
Author: ebotcazou
Date: Thu Jun 30 19:37:41 2011
New Revision: 175723

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175723
Log:
    PR tree-optimization/49572
    * tree-ssa-dom.c (initialize_hash_element) <GIMPLE_SINGLE_RHS>: Use the
    type of the RHS instead of that of the LHS for the expression type.

Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/tree-ssa-dom.c

[Bug tree-optimization/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

--- Comment #17 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-30 19:39:47 UTC ---
Author: ebotcazou
Date: Thu Jun 30 19:39:41 2011
New Revision: 175724

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175724
Log:
    PR tree-optimization/49572
    * tree-ssa-dom.c (initialize_hash_element) <GIMPLE_SINGLE_RHS>: Use the
    type of the RHS instead of that of the LHS for the expression type.

Modified:
    branches/gcc-4_4-branch/gcc/ChangeLog
    branches/gcc-4_4-branch/gcc/tree-ssa-dom.c

[Bug tree-optimization/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #18 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-30 19:45:11 UTC ---
Thanks for reporting the problem.