[Bug tree-optimization/45470] New: [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions

[Bug tree-optimization/45470] New: [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions

[zsojka at seznam dot cz]

Compiler output:
$ gcc -O1 -ftree-vectorize -fnon-call-exceptions testcase.C 
testcase.C: In constructor 'B::B()':
testcase.C:17:1: error: BB 2 can not throw but has an EH edge
testcase.C:17:1: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Tested revisions:
r163636 - crash
r162940 - OK


-- 
           Summary: [4.6 Regression] ICE: verify_flow_info failed: BB 2 can
                    not throw but has an EH edge with -ftree-vectorize -
                    fnon-call-exceptions
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions

[zsojka at seznam dot cz]

------- Comment #1 from zsojka at seznam dot cz  2010-08-31 22:39 -------
Created an attachment (id=21627)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21627&action=view)
reduced testcase

$ gcc -O1 -ftree-vectorize -fnon-call-exceptions pr45470.C


-- 


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

[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions

[hjl dot tools at gmail dot com]

------- Comment #2 from hjl dot tools at gmail dot com  2010-09-01 01:10 -------
It is caused by revision 163260:

http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00471.html


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |irar at il dot ibm dot com


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

[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions

[irar at il dot ibm dot com]

------- Comment #3 from irar at il dot ibm dot com  2010-09-01 09:06 -------
r163260 only made this BB vectorizable.

I checked lookup_stmt_eh_lp for the last stmt of the BB and EDGE_EH flags
before and after vectorization (basic block SLP), and in both cases
lookup_stmt_eh_lp returns 0 and there is an EH edge from the basic block.

I also tried to add cleanup_eh pass after SLP. If is somewhere before
pass_tree_loop_done, there is no ICE:

Index: passes.c
===================================================================
--- passes.c    (revision 163538)
+++ passes.c    (working copy)
@@ -925,6 +925,7 @@ init_optimization_passes (void)
          NEXT_PASS (pass_parallelize_loops);
          NEXT_PASS (pass_loop_prefetch);
          NEXT_PASS (pass_iv_optimize);
+          NEXT_PASS (pass_cleanup_eh);
          NEXT_PASS (pass_tree_loop_done);
        }
       NEXT_PASS (pass_cse_reciprocals);


If cleanup_eh is scheduled after tree_loop_done, there is ICE:

Index: passes.c
===================================================================
--- passes.c    (revision 163538)
+++ passes.c    (working copy)
@@ -926,6 +926,7 @@ init_optimization_passes (void)
          NEXT_PASS (pass_loop_prefetch);
          NEXT_PASS (pass_iv_optimize);
          NEXT_PASS (pass_tree_loop_done);
+          NEXT_PASS (pass_cleanup_eh);
        }
       NEXT_PASS (pass_cse_reciprocals);
       NEXT_PASS (pass_reassoc);


-- 

irar at il dot ibm dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-09-01 09:06:19
               date|                            |


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

[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2010-09-01 09:43 -------
I'll have a look.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.6.0


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

[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2010-09-01 10:19 -------
I see before SLP:

<bb 2>:
  MEM[(struct A *)this_1(D)].a = 0;
  MEM[(struct A *)this_1(D)].b = 0;
  MEM[(struct A *)this_1(D)].c = 0;
  [LP 2] MEM[(struct A *)this_1(D) + 12B].a = 0;

and after:

<bb 2>:
  vect_cst_.1_16 = { 0, 0, 0, 0 };
  vect_p.5_17 = &MEM[(struct A *)this_1(D)].a;
  M*vect_p.5_17{misalignment: 0} = vect_cst_.1_16;

so EH info has not been properly transfered.  Now that only
MEM[(struct A *)this_1(D) + 12B].a can throw internally but not
MEM[(struct A *)this_1(D)].c = 0; is a fact that the frontend establishes.

The following mitigates the problem by simply removing the dead EH edges.

Index: gcc/tree-vect-slp.c
===================================================================
--- gcc/tree-vect-slp.c (revision 163721)
+++ gcc/tree-vect-slp.c (working copy)
@@ -2474,6 +2474,9 @@ vect_schedule_slp (loop_vec_info loop_vi
         }
     }

+  if (bb_vinfo)
+    gimple_purge_dead_eh_edges (BB_VINFO_BB (bb_vinfo));
+
   return is_store;
 }



-- 


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

[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions

[irar at il dot ibm dot com]

------- Comment #6 from irar at il dot ibm dot com  2010-09-01 11:54 -------
(In reply to comment #5)
> I see before SLP:
> 
> <bb 2>:
>   MEM[(struct A *)this_1(D)].a = 0;
>   MEM[(struct A *)this_1(D)].b = 0;
>   MEM[(struct A *)this_1(D)].c = 0;
>   [LP 2] MEM[(struct A *)this_1(D) + 12B].a = 0;
> 
> and after:
> 
> <bb 2>:
>   vect_cst_.1_16 = { 0, 0, 0, 0 };
>   vect_p.5_17 = &MEM[(struct A *)this_1(D)].a;
>   M*vect_p.5_17{misalignment: 0} = vect_cst_.1_16;
> 
> so EH info has not been properly transfered.  

How should it be done? Is it ok to assume that if one of the old stmts can
throw, then we can set TREE_THIS_NOTRAP for the new access to 0? (and then we
can call maybe_duplicate_eh_stmt (new_stmt, old_stmt)).

Or maybe it's better to avoid vectorization?...

Thanks,
Ira

> Now that only
> MEM[(struct A *)this_1(D) + 12B].a can throw internally but not
> MEM[(struct A *)this_1(D)].c = 0; is a fact that the frontend establishes.
> 
> The following mitigates the problem by simply removing the dead EH edges.
> 
> Index: gcc/tree-vect-slp.c
> ===================================================================
> --- gcc/tree-vect-slp.c (revision 163721)
> +++ gcc/tree-vect-slp.c (working copy)
> @@ -2474,6 +2474,9 @@ vect_schedule_slp (loop_vec_info loop_vi
>          }
>      }
> 
> +  if (bb_vinfo)
> +    gimple_purge_dead_eh_edges (BB_VINFO_BB (bb_vinfo));
> +
>    return is_store;
>  }
> 
> 


-- 

irar at il dot ibm dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.0                       |---


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

[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions

[zsojka at seznam dot cz]

------- Comment #7 from zsojka at seznam dot cz  2010-09-04 00:12 -------
Created an attachment (id=21691)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21691&action=view)
different crash

$ gcc -O -march=amdfam10 -ftree-slp-vectorize -fnon-call-exceptions pr45470-2.C 
pr45470-2.C: In constructor 'LoadGraph::LoadGraph(int)':
pr45470-2.C:46:1: error: BB 2 can not throw but has an EH edge
pr45470-2.C:46:1: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 


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

[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2010-09-10 13:26 -------
(In reply to comment #6)
> (In reply to comment #5)
> > I see before SLP:
> > 
> > <bb 2>:
> >   MEM[(struct A *)this_1(D)].a = 0;
> >   MEM[(struct A *)this_1(D)].b = 0;
> >   MEM[(struct A *)this_1(D)].c = 0;
> >   [LP 2] MEM[(struct A *)this_1(D) + 12B].a = 0;
> > 
> > and after:
> > 
> > <bb 2>:
> >   vect_cst_.1_16 = { 0, 0, 0, 0 };
> >   vect_p.5_17 = &MEM[(struct A *)this_1(D)].a;
> >   M*vect_p.5_17{misalignment: 0} = vect_cst_.1_16;
> > 
> > so EH info has not been properly transfered.  
> 
> How should it be done? Is it ok to assume that if one of the old stmts can
> throw, then we can set TREE_THIS_NOTRAP for the new access to 0? (and then we
> can call maybe_duplicate_eh_stmt (new_stmt, old_stmt)).
> 
> Or maybe it's better to avoid vectorization?...

I think it's best to avoid vectorization if one of the old stmts can
throw.

Richard.


-- 


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

[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.3.6


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

[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions

[irar at il dot ibm dot com]

------- Comment #9 from irar at il dot ibm dot com  2010-09-12 09:46 -------
OK, thanks. I am going to test this patch, it only checks data-refs and
function calls:

Index: tree-vect-data-refs.c
===================================================================
--- tree-vect-data-refs.c       (revision 164227)
+++ tree-vect-data-refs.c       (working copy)
@@ -2542,6 +2542,17 @@ vect_analyze_data_refs (loop_vec_info lo
       offset = unshare_expr (DR_OFFSET (dr));
       init = unshare_expr (DR_INIT (dr));

+      if (stmt_could_throw_p (stmt))
+        {
+          if (vect_print_dump_info (REPORT_UNVECTORIZED_LOCATIONS))
+            {
+              fprintf (vect_dump, "not vectorized: statement can throw an "
+                       "exception ");
+              print_gimple_stmt (vect_dump, stmt, 0, TDF_SLIM);
+            }
+          return false;
+        }
+
       /* Update DR field in stmt_vec_info struct.  */

       /* If the dataref is in an inner-loop of the loop that is considered for
Index: tree-vect-stmts.c
===================================================================
--- tree-vect-stmts.c   (revision 164227)
+++ tree-vect-stmts.c   (working copy)
@@ -1343,6 +1343,9 @@ vectorizable_call (gimple stmt, gimple_s
   if (TREE_CODE (gimple_call_lhs (stmt)) != SSA_NAME)
     return false;

+  if (stmt_could_throw_p (stmt))
+    return false;
+
   vectype_out = STMT_VINFO_VECTYPE (stmt_info);

   /* Process function arguments.  */

Thanks,
Ira


-- 


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

[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions

[irar at gcc dot gnu dot org]

------- Comment #10 from irar at gcc dot gnu dot org  2010-09-14 09:21 -------
Subject: Bug 45470

Author: irar
Date: Tue Sep 14 09:21:15 2010
New Revision: 164270

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164270
Log:

        PR tree-optimization/45470
        * tree-vect-data-refs.c (vect_analyze_data_refs): Fail if a statement
        can throw an exception.
        * tree-vect-stmts.c (vectorizable_call): Likewise.


Added:
    trunk/gcc/testsuite/g++.dg/vect/pr45470-a.cc
    trunk/gcc/testsuite/g++.dg/vect/pr45470-b.cc
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-vect-data-refs.c
    trunk/gcc/tree-vect-stmts.c


-- 


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

[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions

[rguenth at gcc dot gnu dot org]

------- Comment #11 from rguenth at gcc dot gnu dot org  2010-09-14 10:17 -------
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

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


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