[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802 --- Comment #11 from vries at gcc dot gnu.org --- Author: vries Date: Fri Apr 24 14:18:57 2015 New Revision: 222413 URL: https://gcc.gnu.org/viewcvs?rev=222413root=gccview=rev Log: Replace g++.dg/pr65802.C with gcc.dg/pr65802.c 2015-04-24 Tom de Vries t...@codesourcery.com PR tree-optimization/65802 * g++.dg/pr65802.C: Move to ... * gcc.dg/pr65802.c: ... here. Add -fexceptions to dg-options. Include stdarg.h. Rewrite for C. (fn1): Use va_list and va_arg. Make variable args function. Add use of va_start and va_end. Remove unnecessary inline asm. Added: trunk/gcc/testsuite/gcc.dg/pr65802.c Removed: trunk/gcc/testsuite/g++.dg/pr65802.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802 --- Comment #9 from vries at gcc dot gnu.org --- Author: vries Date: Tue Apr 21 08:43:07 2015 New Revision: 59 URL: https://gcc.gnu.org/viewcvs?rev=59root=gccview=rev Log: Mark ifn_va_arg with ECF_NOTHROW 2015-04-21 Tom de Vries t...@codesourcery.com PR tree-optimization/65802 * internal-fn.def (VA_ARG): Add ECF_NOTROW to flags. * g++.dg/pr65802.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr65802.C Modified: trunk/gcc/ChangeLog trunk/gcc/internal-fn.def trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from vries at gcc dot gnu.org --- patch with test-case committed, marking resolved fixed.
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to vries from comment #6) (In reply to vries from comment #5) So the question is: should ifn_va_arg have ECF_NOTHROW? Adding ECF_NOTHROW to ifn_va_arg also fixes the ICE. And at gimplify_va_arg_expr, the VA_ARG_EXPR tree is non-throwing: Is that always the case (try -fnon-call-exceptions)? Then doing that looks obvious. Richard. (gdb) call debug_generic_expr (*expr_p ) VA_ARG_EXPR c (gdb) call debug_tree (*expr_p ) va_arg_expr 0x7661e9a0 type pointer_type 0x764c97e0 type integer_type 0x764a7690 int public SI size integer_cst 0x764c50a8 constant 32 unit size integer_cst 0x764c50c0 constant 4 align 32 symtab 0 alias set -1 canonical type 0x764a7690 precision 32 min integer_cst 0x764c5060 -2147483648 max integer_cst 0x764c5078 2147483647 pointer_to_this pointer_type 0x764c97e0 sizes-gimplified unsigned DI size integer_cst 0x764a3e58 constant 64 unit size integer_cst 0x764a3e70 constant 8 align 64 symtab 0 alias set -1 canonical type 0x764c97e0 pointer_to_this pointer_type 0x76622540 side-effects arg 0 var_decl 0x764b0c60 c type array_type 0x764ccbd0 __builtin_va_list type record_type 0x764cc738 __va_list_tag sizes-gimplified BLK size integer_cst 0x764c5318 constant 192 unit size integer_cst 0x764c52e8 constant 24 align 64 symtab 0 alias set -1 canonical type 0x764cc888 domain integer_type 0x764cc7e0 used tree_1 decl_5 BLK file test.cc line 13 col 25 size integer_cst 0x764c5318 192 unit size integer_cst 0x764c52e8 24 align 64 context function_decl 0x766240d8 fn1 test.cc:15:32 (gdb) call tree_could_throw_p (*expr_p ) $1 = false ... I'll bootstrap and reg-test this fix.
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802 --- Comment #8 from vries at gcc dot gnu.org --- (In reply to Richard Biener from comment #7) (In reply to vries from comment #6) (In reply to vries from comment #5) So the question is: should ifn_va_arg have ECF_NOTHROW? Adding ECF_NOTHROW to ifn_va_arg also fixes the ICE. And at gimplify_va_arg_expr, the VA_ARG_EXPR tree is non-throwing: Is that always the case (try -fnon-call-exceptions)? Then doing that looks obvious. Richard. Yep, that's also the case with -fnon-call-exceptions: ... (gdb) call debug_generic_expr (*expr_p) VA_ARG_EXPR c (gdb) call tree_could_throw_p (*expr_p ) $1 = false (gdb) p flag_non_call_exceptions $2 = 1 ...
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802 --- Comment #6 from vries at gcc dot gnu.org --- (In reply to vries from comment #5) So the question is: should ifn_va_arg have ECF_NOTHROW? Adding ECF_NOTHROW to ifn_va_arg also fixes the ICE. And at gimplify_va_arg_expr, the VA_ARG_EXPR tree is non-throwing: ... (gdb) call debug_generic_expr (*expr_p ) VA_ARG_EXPR c (gdb) call debug_tree (*expr_p ) va_arg_expr 0x7661e9a0 type pointer_type 0x764c97e0 type integer_type 0x764a7690 int public SI size integer_cst 0x764c50a8 constant 32 unit size integer_cst 0x764c50c0 constant 4 align 32 symtab 0 alias set -1 canonical type 0x764a7690 precision 32 min integer_cst 0x764c5060 -2147483648 max integer_cst 0x764c5078 2147483647 pointer_to_this pointer_type 0x764c97e0 sizes-gimplified unsigned DI size integer_cst 0x764a3e58 constant 64 unit size integer_cst 0x764a3e70 constant 8 align 64 symtab 0 alias set -1 canonical type 0x764c97e0 pointer_to_this pointer_type 0x76622540 side-effects arg 0 var_decl 0x764b0c60 c type array_type 0x764ccbd0 __builtin_va_list type record_type 0x764cc738 __va_list_tag sizes-gimplified BLK size integer_cst 0x764c5318 constant 192 unit size integer_cst 0x764c52e8 constant 24 align 64 symtab 0 alias set -1 canonical type 0x764cc888 domain integer_type 0x764cc7e0 used tree_1 decl_5 BLK file test.cc line 13 col 25 size integer_cst 0x764c5318 192 unit size integer_cst 0x764c52e8 24 align 64 context function_decl 0x766240d8 fn1 test.cc:15:32 (gdb) call tree_could_throw_p (*expr_p ) $1 = false ... I'll bootstrap and reg-test this fix.
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-19 CC||vries at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from vries at gcc dot gnu.org --- Confirmed, I see the failure as well.
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802
--- Comment #5 from vries at gcc dot gnu.org ---
Before the patch series, at 011.cfg we had this representation:
...
;; basic block 2, loop depth 0, count 0, freq 0, maybe hot
;;prev block 0, next block 3, flags: (NEW, REACHABLE)
;;pred: ENTRY (FALLTHRU)
D.2342 = cD.2333.gp_offsetD.5;
if (D.2342 = 48)
goto bb 4;
else
goto bb 3;
;;succ: 4 (TRUE_VALUE)
;;3 (FALSE_VALUE)
;; basic block 3, loop depth 0, count 0, freq 0, maybe hot
;;prev block 2, next block 4, flags: (NEW, REACHABLE)
;;pred: 2 (FALSE_VALUE)
D.2344 = cD.2333.reg_save_areaD.8;
D.2345 = cD.2333.gp_offsetD.5;
D.2346 = (sizetype) D.2345;
addr.0D.2339 = D.2344 + D.2346;
D.2347 = cD.2333.gp_offsetD.5;
D.2348 = D.2347 + 8;
cD.2333.gp_offsetD.5 = D.2348;
goto bb 5;
;;succ: 5 (FALLTHRU)
;; basic block 4, loop depth 0, count 0, freq 0, maybe hot
;;prev block 3, next block 5, flags: (NEW, REACHABLE)
;;pred: 2 (TRUE_VALUE)
D.2349 = cD.2333.overflow_arg_areaD.7;
addr.0D.2339 = D.2349;
D.2350 = D.2349 + 8;
cD.2333.overflow_arg_areaD.7 = D.2350;
;;succ: 5 (FALLTHRU)
;; basic block 5, loop depth 0, count 0, freq 0, maybe hot
;;prev block 4, next block 6, flags: (NEW, REACHABLE)
;;pred: 3 (FALLTHRU)
;;4 (FALLTHRU)
d.1D.2351 = MEM[(intD.9 * * {ref-all})addr.0D.2339];
dD.2334 = d.1D.2351;
eD.2335 = dD.2334;
__asm__( : =d eD.2335);
[LP 1] # USE = anything
# CLB = anything
m_fn1D.2327 (aD.2330);
;;succ: 9 (EH)
;;6 (FALLTHRU)
...
There's no exception connected to the whole va_arg sequence.
So the question is: should ifn_va_arg have ECF_NOTHROW?
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802
--- Comment #4 from vries at gcc dot gnu.org ---
The assert triggering is:
...
(gdb)
#5 0x011325fe in redirect_eh_edge_1 (edge_in=0x764af4d0,
new_bb=0x764ae4e0, change_region=true) at src/gcc/tree-eh.c:2335
2335 gcc_assert (lookup_stmt_eh_lp (throw_stmt) == old_lp_nr);
...
Indeed the comparison fails:
...
(gdb) p old_lp_nr
$1 = 1
(gdb) p lookup_stmt_eh_lp (throw_stmt)
$2 = 0
...
And lookup_stmt_eh_lp (throw_stmt) is 0, because throw_stmt is NULL, which
presumably is not intended to be NULL here:
...
(gdb) p throw_stmt
$3 = (gimple) 0x0
...
throw_stmt is initialized here:
...
2334 throw_stmt = last_stmt (edge_in-src);
...
In fact edge_in-src is an empty bb:
...
(gdb) call debug_bb (edge_in-src)
;; basic block 15, loop depth 0, count 0, freq 0, maybe hot
;; prev block 14, next block 3, flags: (NEW)
;; pred: 14 (FALLTHRU)
;; succ: 7 (EH)
;; 3 (FALLTHRU)
...
Before pass_lower_vaarg, we have this definition in bb2 definining for _6:
...
;; basic block 2, loop depth 0, count 0, freq 0, maybe hot
;;prev block 0, next block 3, flags: (NEW, REACHABLE)
;;pred: ENTRY (FALLTHRU)
[LP 1] # .MEM_5 = VDEF .MEM_4(D)
# USE = anything
# CLB = anything
_6 = VA_ARG (cD.2333, 0B);
;;succ: 7 (EH)
;;3 (FALLTHRU)
...
After pass_lower_vaarg, it's spread over several basic blocks:
...
;; basic block 2, loop depth 0, count 0, freq 0, maybe hot
;;prev block 0, next block 11, flags: (NEW, REACHABLE)
;;pred: ENTRY (FALLTHRU)
;;succ: 11 [100.0%] (FALLTHRU)
;; basic block 11, loop depth 0, count 0, freq 0, maybe hot
;;prev block 2, next block 12, flags: (NEW)
;;pred: 2 [100.0%] (FALLTHRU)
# VUSE .MEM_4(D)
_22 = cD.2333.gp_offsetD.5;
if (_22 = 48)
goto bb 13 (L6);
else
goto bb 12 (L5);
;;succ: 13 (TRUE_VALUE)
;;12 (FALSE_VALUE)
;; basic block 12, loop depth 0, count 0, freq 0, maybe hot
;;prev block 11, next block 13, flags: (NEW)
;;pred: 11 (FALSE_VALUE)
L5:
# VUSE .MEM_4(D)
_23 = cD.2333.reg_save_areaD.8;
# VUSE .MEM_4(D)
_24 = cD.2333.gp_offsetD.5;
_25 = (sizetype) _24;
addr.1_26 = _23 + _25;
# VUSE .MEM_4(D)
_27 = cD.2333.gp_offsetD.5;
_28 = _27 + 8;
# .MEM_29 = VDEF .MEM_4(D)
cD.2333.gp_offsetD.5 = _28;
goto bb 14 (L7);
;;succ: 14 (FALLTHRU)
;; basic block 13, loop depth 0, count 0, freq 0, maybe hot
;;prev block 12, next block 14, flags: (NEW)
;;pred: 11 (TRUE_VALUE)
L6:
# VUSE .MEM_4(D)
_30 = cD.2333.overflow_arg_areaD.7;
addr.1_31 = _30;
_32 = _30 + 8;
# .MEM_33 = VDEF .MEM_4(D)
cD.2333.overflow_arg_areaD.7 = _32;
;;succ: 14 (FALLTHRU)
;; basic block 14, loop depth 0, count 0, freq 0, maybe hot
;;prev block 13, next block 15, flags: (NEW)
;;pred: 12 (FALLTHRU)
;;13 (FALLTHRU)
# .MEM_20 = PHI .MEM_29(12), .MEM_33(13)
# addr.1_21 = PHI addr.1_26(12), addr.1_31(13)
L7:
# VUSE .MEM_20
_6 = MEM[(intD.9 * * {ref-all})addr.1_21];
;;succ: 15 (FALLTHRU)
;; basic block 15, loop depth 0, count 0, freq 0, maybe hot
;;prev block 14, next block 3, flags: (NEW)
;;pred: 14 (FALLTHRU)
;;succ: 7 (EH)
;;3 (FALLTHRU)
...
Before the expansion, the ifn_va_arg is the statement that could throw:
...
(gdb) call debug_bb_n (2)
;; basic block 2, loop depth 0, count 0, freq 0, maybe hot
;; prev block 0, next block 3, flags: (NEW, REACHABLE)
;; pred: ENTRY (FALLTHRU)
[LP 1] # .MEM_5 = VDEF .MEM_4(D)
# USE = anything
# CLB = anything
_6 = VA_ARG (cD.2333, 0B);
;; succ: 7 (EH)
;; 3 (FALLTHRU)
$1 = (basic_block_def *) 0x764ae270
(gdb) call stmt_could_throw_p ( last_stmt ($1 ) )
$3 = true
...
But the last statement before bb15 cannot throw:
...
(gdb) call debug_bb_n (14)
;; basic block 14, loop depth 0, count 0, freq 0, maybe hot
;; prev block 13, next block 15, flags: (NEW)
;; pred: 12 (FALLTHRU)
;; 13 (FALLTHRU)
# .MEM_20 = PHI .MEM_29(12), .MEM_33(13)
# addr.1_21 = PHI addr.1_26(12), addr.1_31(13)
L7:
# VUSE .MEM_20
_6 = MEM[(intD.9 * * {ref-all})addr.1_21];
;; succ: 15 (FALLTHRU)
$4 = (basic_block_def *) 0x764aea90
(gdb) call stmt_could_throw_p ( last_stmt ($4 ) )
$5 = false
...
So it does not seem to be just a question of removing the last empty bb.
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802 --- Comment #3 from vries at gcc dot gnu.org --- This patch allows the example to pass: ... diff --git a/gcc/passes.def b/gcc/passes.def index ffa63b5..041197c 100644 --- a/gcc/passes.def +++ b/gcc/passes.def @@ -344,7 +344,6 @@ along with GCC; see the file COPYING3. If not see NEXT_PASS (pass_tm_edges); POP_INSERT_PASSES () NEXT_PASS (pass_vtable_verify); - NEXT_PASS (pass_lower_vaarg); NEXT_PASS (pass_lower_vector); NEXT_PASS (pass_lower_complex_O0); NEXT_PASS (pass_asan_O0); @@ -352,6 +351,7 @@ along with GCC; see the file COPYING3. If not see NEXT_PASS (pass_sanopt); NEXT_PASS (pass_cleanup_eh); NEXT_PASS (pass_lower_resx); + NEXT_PASS (pass_lower_vaarg); NEXT_PASS (pass_nrv); NEXT_PASS (pass_cleanup_cfg_post_optimizing); NEXT_PASS (pass_warn_function_noreturn); ... I have no knowledge of the exception handling implementation, so: 1. a proper root cause analysis would take me some time. 2. I have no idea whether the patch is actually correct. I'll try a bootstrap and reg-test though, that'll gives us at least more information.
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802 Dmitry G. Dyachenko dimhen at gmail dot com changed: What|Removed |Added CC||tom at codesourcery dot com --- Comment #1 from Dmitry G. Dyachenko dimhen at gmail dot com --- r222168 PASS r222174 FAIL
