[Bug target/31797] New: powerpc: race

[Bug target/31797] New: powerpc: race

[ralf_corsepius at rtems dot org]

When building RTEMS with gcc-4.2.0-20070430, gcc races on one file of the RTEMS
sources. It consumes up all available CPU time, gradually (very slowly) seems
consume all memory and doesn't seem to finish:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 6176 joel      18   0 1614m 937m  604 D    2 92.9 491:53.20 cc1                


# ps ax | grep cc1
 6176 ?        D    491:55
/opt/rtems-4.8/libexec/gcc/powerpc-rtems4.8/4.2.0/cc1 -quiet -imultilib m7400
-isystem ../../../../../.././mvme5500/lib/include -MD network_rel-GT64260eth.d
-MF .deps/network_rel-GT64260eth.Tpo -MP -MT network_rel-GT64260eth.o -MQ
network_rel-GT64260eth.o -DHAVE_CONFIG_H -D_KERNEL -Dmpc7455 -isystem
../../../../../.././mvme5500/lib/include
../../../../../../../../current/c/src/lib/libbsp/powerpc/mvme5500/network/GT64260eth.c
-quiet -dumpbase GT64260eth.c -mcpu=7450 -mno-altivec -mabi=altivec -mvrsave=no
-mmultiple -mstring -mstrict-align -ansi -auxbase-strip
network_rel-GT64260eth.o -g -O2 -Wall -ansi -fasm -o -

This issue is reproduceable on i386-FC5 and FC6.
I would try to attach the *.i, but bugzilla refuses to let to do so, ATM. 

The same piece of code compiles fine with gcc-4.1.2 and older, so I am inclined
to call this to be a regression.


-- 
           Summary: powerpc: race
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ralf_corsepius at rtems dot org
GCC target triplet: powerpc-rtems*


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

[Bug target/31797] powerpc: race

[ralf_corsepius at rtems dot org]

------- Comment #1 from ralf_corsepius at rtems dot org  2007-05-03 09:36 -------
Using -O1 instead of -O2 causes the hogging to vanish.


-- 


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

[Bug target/31797] powerpc: race

[ralf_corsepius at rtems dot org]

------- Comment #2 from ralf_corsepius at rtems dot org  2007-05-03 10:45 -------
Created an attachment (id=13502)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13502&action=view)
*.i of the breakdown above


-- 


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

[Bug target/31797] powerpc: race

[ralf_corsepius at rtems dot org]

------- Comment #3 from ralf_corsepius at rtems dot org  2007-05-04 06:29 -------
Created an attachment (id=13505)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13505&action=view)
Stripped down example to expose the issue on all targets


-- 


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

[Bug target/31797] gcc-4.2.0 racing

[ralf_corsepius at rtems dot org]

------- Comment #4 from ralf_corsepius at rtems dot org  2007-05-04 06:36 -------
Using GT64260eth.c from attachment 13505, I am able to reproduce the race with
gcc-4.2.0-20070430 for arm-rtems, bfin-rtems, powerpc-rtems, i386-rtems.

=> I assume this issue to be target independent and to affect all targets.


-- 

ralf_corsepius at rtems dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |major
 GCC target triplet|powerpc-rtems*              |all
            Summary|powerpc: race               |gcc-4.2.0 racing


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

[Bug tree-optimization/31797] gcc-4.2.0 racing

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2007-05-04 09:05 -------
On the mainline I get an ICE:
t.c:20: internal compiler error: in compute_antic, at tree-ssa-pre.c:1968


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dberlin at gcc dot gnu dot
                   |                            |org
          Component|middle-end                  |tree-optimization


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

[Bug tree-optimization/31797] gcc-4.2.0 racing

[mark at codesourcery dot com]

------- Comment #6 from mark at codesourcery dot com  2007-05-05 23:16 -------
Subject: Re:  powerpc: race

ralf_corsepius at rtems dot org wrote:
> ------- Comment #2 from ralf_corsepius at rtems dot org  2007-05-03 10:45 -------
> Created an attachment (id=13502)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13502&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13502&action=view)
> *.i of the breakdown above

Is this a regression?  Because it is not marked as such, it is presently
not on my radar for 4.2.0 bugs.  (If you want to see what I look at,
visit the gcc.gnu.org home page, and click on the "Serious Regressions"
link under 4.2.0.)

Thanks,


-- 


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

[Bug tree-optimization/31797] gcc-4.2.0 racing

[joel at oarcorp dot com]

------- Comment #7 from joel at oarcorp dot com  2007-05-06 17:00 -------
It is definitely a regression against 4.1.2.  It is probably a regession
against 4.0.  We have been compiling this code with the same compile options
since September 2006 using the latest gcc releases possible.


-- 


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

[Bug tree-optimization/31797] [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2007-05-07 00:22 -------
Confirmed, this ICEs with checking turned on, while it causes an infinite loop
without.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |ice-checking, ice-on-valid-
                   |                            |code
      Known to fail|4.2.0                       |4.2.0 4.3.0
   Last reconfirmed|0000-00-00 00:00:00         |2007-05-07 00:22:33
               date|                            |
            Summary|gcc-4.2.0 racing            |[4.2/4.3 Regression]
                   |                            |infinite loop in tree-ssa-
                   |                            |pre or ICE
   Target Milestone|---                         |4.2.0


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

[Bug tree-optimization/31797] [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE

[dberlin at dberlin dot org]

------- Comment #9 from dberlin at gcc dot gnu dot org  2007-05-07 00:37 -------
Subject: Re:  [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE

I'm waiting till i can actually produce PRE dumps again before  i can
debug this :(


On 6 May 2007 23:22:33 -0000, pinskia at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #8 from pinskia at gcc dot gnu dot org  2007-05-07 00:22 -------
> Confirmed, this ICEs with checking turned on, while it causes an infinite loop
> without.
>
>


-- 


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

[Bug tree-optimization/31797] [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE

[dberlin at gcc dot gnu dot org]

------- Comment #10 from dberlin at gcc dot gnu dot org  2007-05-10 19:59 -------
Ugh, so operand_equal_p claims two side-effecting component_refs are never the
same, unless they are pointer equal. For non-sideeffects ones, it checks
whether the operands are the same.

This causes PRE to continually make the value over and over again, and think
something is changing.
We only care whether they are performing the exact same operation, which they
are.

I guess i'm going to have to make expressions_equal_p that only ensures they
are the exact same operation with the same flags (IE both have side-effects,
etc).

Would any middle-end person have a problem with this?


-- 

dberlin at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org
         AssignedTo|unassigned at gcc dot gnu   |dberlin at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-05-07 00:22:33         |2007-05-10 19:59:11
               date|                            |


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

[Bug tree-optimization/31797] [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE

[rguenth at gcc dot gnu dot org]

------- Comment #11 from rguenth at gcc dot gnu dot org  2007-05-11 09:34 -------
Instead of inventing your own variant you can add an additional flag
OEP_SAME_SIDEEFFECTS or such to operand_equal_p.  I wouldn't have a problem
with that.


-- 


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

[Bug tree-optimization/31797] [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE

[pinskia at gcc dot gnu dot org]

------- Comment #12 from pinskia at gcc dot gnu dot org  2007-05-11 09:52 -------
Actually shouldn't has_volatile_ops be set?  I am thinking something is not
setting that.


-- 


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

[Bug tree-optimization/31797] [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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

[Bug tree-optimization/31797] [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE

[ebotcazou at gcc dot gnu dot org]

------- Comment #13 from ebotcazou at gcc dot gnu dot org  2007-05-11 21:27 -------
> Actually shouldn't has_volatile_ops be set?  I am thinking something is not
> setting that.

Just to say that we have seen this problem with the Ada compiler and the cause
was indeed the (non-)propagation of the volatile-ness along the chain:
  http://gcc.gnu.org/ml/gcc/2006-06/msg00695.html


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org


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

[Bug tree-optimization/31797] [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE

[dberlin at dberlin dot org]

------- Comment #14 from dberlin at gcc dot gnu dot org  2007-05-11 22:53 -------
Subject: Re:  [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE

> > Actually shouldn't has_volatile_ops be set?  I am thinking something is not
> > setting that.
>
> Just to say that we have seen this problem with the Ada compiler and the cause
> was indeed the (non-)propagation of the volatile-ness along the chain:
>   http://gcc.gnu.org/ml/gcc/2006-06/msg00695.html
>
>
I had never bothered to check, but you are probably right.  That would
certainly be much simpler to fix ;)


-- 


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

[Bug tree-optimization/31797] [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE

[rguenth at gcc dot gnu dot org]

------- Comment #15 from rguenth at gcc dot gnu dot org  2007-05-12 15:44 -------
forwprop looses the volatileness (035.dce vs 036.forwprop):

 GTeth_txq_done (sc)
 {
   struct GTeth_desc * txd;
@@ -34,12 +47,10 @@
   goto <bb 6> (<L4>);

 <L0>:;
-  D.1542_3 = &sc_1->txq_desc[0];
   D.1543_4 = sc_1->txq_fi;
   D.1544_5 = D.1543_4 * 4;
   D.1545_6 = (struct GTeth_desc *) D.1544_5;
-  txd_7 = D.1542_3 + D.1545_6;
-  D.1546_8 =/v txd_7->ed_cmdsts;
+  D.1546_8 = sc_1->txq_desc[D.1543_4].ed_cmdsts;
   if (D.1546_8 != 0) goto <L1>; else goto <L2>;

 <L1>:;

I'll take a quick shot.


-- 


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

[Bug tree-optimization/31797] [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE

[rguenth at gcc dot gnu dot org]

------- Comment #16 from rguenth at gcc dot gnu dot org  2007-05-12 16:09 -------
And it's update_stmt () that clears the flag.  It doesn't consider

(gdb) call debug_tree (stmt)
 <modify_expr 0xb7c6b384
    type <integer_type 0xb7c752e0 unsigned int public unsigned SI
        size <integer_cst 0xb7c643d8 constant invariant 32>
        unit size <integer_cst 0xb7c64168 constant invariant 4>
        align 32 symtab 0 alias set -1 precision 32 min <integer_cst 0xb7c64450
0> max <integer_cst 0xb7c64438 4294967295>>
    side-effects asm_written visited
    arg 0 <ssa_name 0xb7cf6d80 type <integer_type 0xb7c752e0 unsigned int>
        var <var_decl 0xb7c70420 D.1546> def_stmt <modify_expr 0xb7c6b384>
        version 8>
    arg 1 <component_ref 0xb7cf2168
        type <integer_type 0xb7cfa4ac unsigned int volatile unsigned SI size
<integer_cst 0xb7c643d8 32> unit size <integer_cst 0xb7c64168 4>
            align 32 symtab 0 alias set -1 precision 32 min <integer_cst
0xb7c64450 0> max <integer_cst 0xb7c64438 4294967295>>
        side-effects volatile
        arg 0 <array_ref 0xb7c715ac type <record_type 0xb7cfa3f4 GTeth_desc>

            arg 0 <component_ref 0xb7cf2870 type <array_type 0xb7cfa0b8>

                arg 0 <indirect_ref 0xb7cf3860 type <record_type 0xb7cfa000
GTeth_softc>

                    arg 0 <ssa_name 0xb7cf6c30 type <pointer_type 0xb7cfa284>
                        var <parm_decl 0xb7cfb0a0 sc> def_stmt <nop_expr
0xb7cf37a0>
                        version 1
                        ptr-info 0xb7cf0870>> arg 1 <field_decl 0xb7cfa170
txq_desc>>
            arg 1 <ssa_name 0xb7cf6cc0 type <integer_type 0xb7c752e0 unsigned
int>
                var <var_decl 0xb7c70318 D.1543> def_stmt <modify_expr
0xb7c6b318>
                version 4>
            arg 2 <integer_cst 0xb7c64180 constant invariant 0>
            arg 3 <integer_cst 0xb7c641f8 constant invariant 1>>
        arg 1 <field_decl 0xb7ceff74 ed_cmdsts type <integer_type 0xb7c752e0
unsigned int>
            unsigned SI file GT64260eth.c line 3 size <integer_cst 0xb7c643d8
32> unit size <integer_cst 0xb7c64168 4>
            align 32 offset_align 128 offset <integer_cst 0xb7c64180 0>
            bit offset <integer_cst 0xb7c64960 constant invariant 0> context
<record_type 0xb7ceff18 GTeth_desc>>>
    GT64260eth.c:24>

to have volatile ops just because the COMPONENT_REF has side-effects and wrong
types (the field_decl is non-volatile unsigned int while the component_ref
is volatile unsigned int).  So after update_stmt there is a mismatch.

Now what do we want here?  Clear the volatileness on the COMPONENT_REF?  Or
refrain from doing the propagation?  Or fix update_ssa?

Two of the solutions are like

Index: tree-ssa-operands.c
===================================================================
--- tree-ssa-operands.c (revision 124635)
+++ tree-ssa-operands.c (working copy)
@@ -2174,6 +2174,11 @@ build_ssa_operands (tree stmt)
   operand_build_sort_virtual (build_v_must_defs);

   finalize_ssa_stmt_operands (stmt);
+
+  /* If the RHS has side-effects, reset has_volatile_ops.  */
+  if (TREE_CODE (stmt) == MODIFY_EXPR
+      && TREE_SIDE_EFFECTS (TREE_OPERAND (stmt, 1)))
+    ann->has_volatile_ops = true;
 }

and

Index: tree-ssa-forwprop.c
===================================================================
--- tree-ssa-forwprop.c (revision 124635)
+++ tree-ssa-forwprop.c (working copy)
@@ -843,15 +843,22 @@ forward_propagate_addr_expr (tree stmt, 
          continue;
        }

-     /* If the use is in a deeper loop nest, then we do not want
-       to propagate the ADDR_EXPR into the loop as that is likely
-       adding expression evaluations into the loop.  */
+      /* If the use is in a deeper loop nest, then we do not want
+        to propagate the ADDR_EXPR into the loop as that is likely
+        adding expression evaluations into the loop.  */
       if (bb_for_stmt (use_stmt)->loop_depth > stmt_loop_depth)
        {
          all = false;
          continue;
        }
-      
+
+      /* If the use_stmt has side-effects, don't propagate into it.  */
+      if (stmt_ann (use_stmt)->has_volatile_ops)
+        {
+         all = false;
+         continue;
+       }
+ 
       result = forward_propagate_addr_expr_1 (stmt, use_stmt, some);
       *some |= result;
       all &= result;

where I prefer the first one.


-- 


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

[Bug tree-optimization/31797] [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE

[mark at codesourcery dot com]

------- Comment #17 from mark at codesourcery dot com  2007-05-12 16:13 -------
Subject: Re:  [4.2/4.3 Regression] infinite loop
 in tree-ssa-pre or ICE

rguenth at gcc dot gnu dot org wrote:

> +
> +  /* If the RHS has side-effects, reset has_volatile_ops.  */
> +  if (TREE_CODE (stmt) == MODIFY_EXPR
> +      && TREE_SIDE_EFFECTS (TREE_OPERAND (stmt, 1)))
> +    ann->has_volatile_ops = true;
>  }

Richard, thanks for working on this!  Would you please run a test cycle?
 If you're comfortable with the patch, please check it in and let me
know; this looks like a good fix.

Thanks,


-- 


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

[Bug tree-optimization/31797] [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE

[rguenth at gcc dot gnu dot org]

------- Comment #18 from rguenth at gcc dot gnu dot org  2007-05-12 16:38 -------
The second one is certainly safer for the branch, the first one probably should
be an assert that this situation doesn't happen there.  So I'm going to commit
the second one if testing goes ok.


-- 


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

[Bug tree-optimization/31797] [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE

[rguenth at gcc dot gnu dot org]

------- Comment #19 from rguenth at gcc dot gnu dot org  2007-05-12 18:19 -------
Subject: Bug 31797

Author: rguenth
Date: Sat May 12 17:19:25 2007
New Revision: 124636

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124636
Log:
2007-05-12  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/31797
        * tree-ssa-forwprop.c (forward_propagate_addr_expr): Do not
        propagate into a stmt that has volatile ops.

        * gcc.c-torture/compile/pr31797.c: New testcase.

Added:
    branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/compile/pr31797.c
Modified:
    branches/gcc-4_2-branch/gcc/ChangeLog
    branches/gcc-4_2-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_2-branch/gcc/tree-ssa-forwprop.c


-- 


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

[Bug tree-optimization/31797] [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE

[rguenth at gcc dot gnu dot org]

------- Comment #21 from rguenth at gcc dot gnu dot org  2007-05-12 18:21 -------
Subject: Bug 31797

Author: rguenth
Date: Sat May 12 17:21:43 2007
New Revision: 124637

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124637
Log:
2007-05-12  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/31797
        * tree-ssa-forwprop.c (forward_propagate_addr_expr): Do not
        propagate into a stmt that has volatile ops.

        * gcc.c-torture/compile/pr31797.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.c-torture/compile/pr31797.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-forwprop.c


-- 


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

[Bug tree-optimization/31797] [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE

[rguenth at gcc dot gnu dot org]

------- Comment #20 from rguenth at gcc dot gnu dot org  2007-05-12 18:21 -------
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

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


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