[Bug tree-optimization/27341] New: [4.2 Regression] ICE in in add_virtual_operand with complex types

[Bug tree-optimization/27341] New: [4.2 Regression] ICE in in add_virtual_operand with complex types

[pinskia at gcc dot gnu dot org]

Reduced testcase (-O2 to invoke the ICE):
void zgemm_ (const int*, const double*);
extern void matmul_c8 (_Complex double * dest)
{
  const int  ldc = 0;
  const double zero = 0;
  zgemm_ ( &zero, &ldc);
  dest[1] += 1 ;
}
-----------------------------------------------------
Unlike PR26626, the code above is not questionable code if it is undefined or
not.


-- 
           Summary: [4.2 Regression] ICE  in in add_virtual_operand with
                    complex types
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pinskia at gcc dot gnu dot org


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

[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.2.0


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

[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-04-27 19:11 -------
Confirmed, since this is a reducetion from PR 26626 #13.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-04-27 19:11:20
               date|                            |


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

[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-04-27 19:14 -------
Note fixing the prototype of zgemm_ to:
void zgemm_ (const double*, const int*);

We Still ICE (I had messed the order up before).


-- 


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

[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-04-27 19:17 -------
And this is fully complex types related, the ICE comes right after cplxlower,
most likely caused by the complex type getting split up into two different
loads.  (I have not checked that theory yet).


-- 


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

[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2006-05-02 07:25 -------
This is not fixed by the patch which fixes PR 26626.


-- 


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

[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2006-05-11 08:56 -------
Reduced testcase:

double zero;
double matmul_c8 (_Complex double * dest)
{
  *dest += 1;
  return zero;
}

we go from before cplxlower

matmul_c8 (dest)
{
  double D.1526;
  complex double D.1525;
  complex double D.1524;

<bb 2>:
  #   VUSE <zero_4>;
  D.1524_2 = *dest_1;
  D.1525_3 = D.1524_2 + __complex__ (1.0e+0, 0.0);
  #   zero_7 = V_MAY_DEF <zero_4>;
  *dest_1 = D.1525_3;
  #   VUSE <zero_7>;
  D.1526_5 = zero;
  return D.1526_5;

}

to after it

;; basic block 2, loop depth 0, count 0
;; prev block 0, next block 1
;; pred:       ENTRY [100.0%]  (fallthru,exec)
;; succ:       EXIT [100.0%] 
<bb 2>:
#   VUSE <SMT.4>;
D.1538 = REALPART_EXPR <*dest_1>;
#   VUSE <SMT.4>;
D.1539 = IMAGPART_EXPR <*dest_1>;
D.1524_2 = COMPLEX_EXPR <D.1538, D.1539>;
CR.9_9 = D.1538;
CI.10_10 = D.1539;
D.1542 = CR.9_9 + 1.0e+0;
D.1525_3 = COMPLEX_EXPR <D.1542, CI.10_10>;
CR.11_11 = D.1542;
#   zero_7 = V_MAY_DEF <zero_4>;
*dest_1 = D.1525_3;
#   VUSE <zero_7>;
D.1526_5 = zero;
return D.1526_5;

note that for the complex dest, we have Vops for zero only, but later
a SMT falls out of the sky.


-- 


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

[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2006-06-01 03:47 -------
Another reduced testcase:
extern double R_NaReal;
void z_atan2 (double _Complex * r, double _Complex * ccs)
{
    if (*ccs == 0)
        __imag__ *r = R_NaReal;
}


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |alias


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

[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2006-06-01 03:47 -------
*** Bug 27841 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tbm at cyrius dot com


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

[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types

[dberlin at gcc dot gnu dot org]

------- Comment #8 from dberlin at gcc dot gnu dot org  2006-06-01 12:22 -------
The SMT related stuff is a red herring.
Someone is not marking things for renaming when they should be.

The following patch will show that (it disables the used alone code).

Index: tree-ssa-operands.c
===================================================================
--- tree-ssa-operands.c (revision 114136)
+++ tree-ssa-operands.c (working copy)
@@ -1294,12 +1294,12 @@ add_virtual_operand (tree var, stmt_ann_
              || none_added
              || (TREE_CODE (var) == SYMBOL_MEMORY_TAG
                  && for_clobber
-                 && SMT_USED_ALONE (var)))
+                 /*&& SMT_USED_ALONE (var)*/))
            {
              /* Every bare SMT def we add should have SMT_USED_ALONE
                 set on it, or else we will get the wrong answer on
                 clobbers.  */
-             if (none_added
+             if (0 && none_added
                  && !updating_used_alone && aliases_computed_p
                  && TREE_CODE (var) == SYMBOL_MEMORY_TAG)
                gcc_assert (SMT_USED_ALONE (var));


-- 


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

[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types

[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=27341

[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types

[fxcoudert at gcc dot gnu dot org]

------- Comment #9 from fxcoudert at gcc dot gnu dot org  2006-06-15 14:21 -------
Daniel, this bug was exposed by your 2006-02-20 patch. It's been blocking
testing/submission of one of my libgfortran patches for more than two months
now. It's in an area of the compiler I don't have any experience with, but is
there someone I can pressure on in order to get things fixed? Do you have any
idea why/where it's happening?


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2006-05-18 07:21:33         |2006-06-15 14:21:10
               date|                            |


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

[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types

[dberlin at gcc dot gnu dot org]

------- Comment #10 from dberlin at gcc dot gnu dot org  2006-06-15 14:35 -------
Uh, nobody told me it was exposed by my patch, and it's certainly not in the
bug history, or else i would be working on the bug.

In fact, as comment 8 shows, even if you disable the code i added in
2006-02-20, an ICE still occurs.

I'll look at this bug anyway


-- 


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

[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types

[dberlin at gcc dot gnu dot org]

------- Comment #11 from dberlin at gcc dot gnu dot org  2006-06-15 15:04 -------
This should fix it
It looks like gimplify_val never calls mark_new_vars_to_rename, but may create
new statements that nothing else gets a handle to.

Index: tree-cfg.c
===================================================================
--- tree-cfg.c  (revision 114136)
+++ tree-cfg.c  (working copy)
@@ -5584,6 +5584,8 @@ gimplify_val (block_stmt_iterator *bsi,
   TREE_BLOCK (new_stmt) = TREE_BLOCK (orig_stmt);

   bsi_insert_before (bsi, new_stmt, BSI_SAME_STMT);
+  if (in_ssa_p)
+    mark_new_vars_to_rename (new_stmt);

   return t;
 }

I'll look at this bug anyway


-- 


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

[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types

[dberlin at dberlin dot org]

------- Comment #12 from dberlin at gcc dot gnu dot org  2006-06-15 15:18 -------
Subject: Bug 27341

Patch I am testing for all the testcases here.
It turns out to be a problem not actually in the 02-20-06 patch.
Index: gcc/tree-complex.c
===================================================================
--- gcc/tree-complex.c  (revision 114136)
+++ gcc/tree-complex.c  (working copy)
@@ -1541,11 +1541,12 @@ struct tree_opt_pass pass_lower_complex 
   0,                                   /* tv_id */
   PROP_ssa,                            /* properties_required */
   0,                                   /* properties_provided */
-  0,                                   /* properties_destroyed */
+  PROP_smt_usage,                       /* properties_destroyed */
   0,                                   /* todo_flags_start */
   TODO_dump_func | TODO_ggc_collect
-    | TODO_update_ssa
-    | TODO_verify_stmts,               /* todo_flags_finish */
+  | TODO_update_smt_usage
+  | TODO_update_ssa
+  | TODO_verify_stmts,                 /* todo_flags_finish */
   0                                    /* letter */
 };

Index: gcc/testsuite/gcc.c-torture/compile/pr27341-1.c
===================================================================
--- gcc/testsuite/gcc.c-torture/compile/pr27341-1.c     (revision 0)
+++ gcc/testsuite/gcc.c-torture/compile/pr27341-1.c     (revision 0)
@@ -0,0 +1,7 @@
+extern double R_NaReal;
+void z_atan2 (double _Complex * r, double _Complex * ccs)
+{
+    if (*ccs == 0)
+        __imag__ *r = R_NaReal;
+}
+
Index: gcc/testsuite/gcc.c-torture/compile/pr27341-2.c
===================================================================
--- gcc/testsuite/gcc.c-torture/compile/pr27341-2.c     (revision 0)
+++ gcc/testsuite/gcc.c-torture/compile/pr27341-2.c     (revision 0)
@@ -0,0 +1,8 @@
+void zgemm_ (const int*, const double*);
+extern void matmul_c8 (_Complex double * dest)
+{
+  const int  ldc = 0;
+  const double zero = 0;
+  zgemm_ ( &zero, &ldc);
+  dest[1] += 1 ;
+}
Index: gcc/tree-cfg.c
===================================================================
--- gcc/tree-cfg.c      (revision 114136)
+++ gcc/tree-cfg.c      (working copy)
@@ -5584,6 +5584,8 @@ gimplify_val (block_stmt_iterator *bsi, 
   TREE_BLOCK (new_stmt) = TREE_BLOCK (orig_stmt);

   bsi_insert_before (bsi, new_stmt, BSI_SAME_STMT);
+  if (in_ssa_p)
+    mark_new_vars_to_rename (new_stmt);

   return t;
 }


-- 


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

[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types

[dberlin at gcc dot gnu dot org]

------- Comment #13 from dberlin at gcc dot gnu dot org  2006-06-19 14:34 -------
Subject: Bug 27341

Author: dberlin
Date: Mon Jun 19 14:33:46 2006
New Revision: 114771

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114771
Log:
2006-06-19  Daniel Berlin  <dberlin@dberlin.org>

        Fix PR tree-optimization/27341
        * tree-cfg.c (gimplify_val): Call mark_new_vars_to_rename on the
        statement we get.
        * tree-complex.c (pass_lower_complex): Update SMT usage.        



Added:
    trunk/gcc/testsuite/gcc.c-torture/compile/pr27341-1.c
    trunk/gcc/testsuite/gcc.c-torture/compile/pr27341-2.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-cfg.c
    trunk/gcc/tree-complex.c


-- 


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

[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types

[dberlin at gcc dot gnu dot org]

------- Comment #14 from dberlin at gcc dot gnu dot org  2006-06-19 14:34 -------
Fixed


-- 

dberlin at gcc dot gnu dot org changed:

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


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