Created attachment 30179 [details] testcase With current trunk: gfortran -c -g -O2 -ffast-math -ffree-form -cpp bug.f90 bug.f90: In function ‘xb88_lr_adiabatic_lda_calc’: bug.f90:1:0: error: definition in block 4 follows the use SUBROUTINE xb88_lr_adiabatic_lda_calc(rho, norm_drho,& ^ for SSA_NAME: _83 in statement: # DEBUG D#20 => _83 + _54 bug.f90:1:0: internal compiler error: verify_ssa failed 0xb37624 verify_ssa(bool) ../../gcc/gcc/tree-ssa.c:1046 0x903f12 execute_function_todo ../../gcc/gcc/passes.c:1970 0x90486d execute_todo ../../gcc/gcc/passes.c:2002 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. Since the testcase is actually a reduced version of PR57370 the bug could be related. However, since this one is ICE-ing while the other hangs, I'm assuming this is a different issue.
fine with 4.8 fails with 4.9
Dup of PR57337?
(In reply to Igor Zamyatin from comment #2) > Dup of PR57337? Likely so. I'll add a dependency
still fails with r199397
Re-confirmed to be reassoc.
Simplified testcase that fails with 'gfortran -c -g -O2 -ffast-math bug.f90' > cat bug.f90 SUBROUTINE xb88_lr_adiabatic_lda_calc(npoints,e,g,sx) IMPLICIT REAL*8 (t) INTEGER, PARAMETER :: dp=8 REAL(kind=dp) :: e(npoints) DO ii=1,npoints t804 = 0.1955555555e2_dp * t7 * t766 + & 0.6000000000e1_dp * t405 * t2873 * t237 t3026 = 0.1620000000e3_dp * t1143 * t474 * t2169 + & 0.1080000000e3_dp * t1143 * t3030 * t237 - & 0.6000000000e1_dp * t478 * t27 * t379 * t14 - & 0.2400000000e2_dp * t478 * t123 * t2843 - & 0.1200000000e2_dp * t473 * t1157 * t2368 t3070 = t3026 + t3069 t3093 = (3 * t496 * t865 * t65) + & (t187 * t2285 * t65) + (t3070 * t65) - & 0.3333333336e0_dp * t1137 * t1134 t3268 = 0.1555555556e1_dp * t2937 * t446 * t2843 + & (t3093 + t3141 + t3181 + t3232) * & 0.3125000000e0_dp * t3262 * t45 * t166 * t3264 t3288 = -0.1000000001e1_dp * t165 * t2636 * t237 - & (t2724 + t2783 + t2935 + t3268) - & 0.8333333340e-1_dp * t906 * t384 * t2160 t3291 = -0.1000000001e1_dp * t2147 * t84 * t754 - & t8 * (t2635 + t3288) IF( g>= 3 .OR. g== -3 ) THEN e(ii) = e(ii) + t3291 * sx END IF END DO END SUBROUTINE xb88_lr_adiabatic_lda_calc
For convenience, I put here a testcase from bug 57400. Joost VandeVondele: "this second testcase is almost certainly a dup of PR57393. It passes with -fno-tree-reassoc. The testcase is conveniently smaller." ======================== 8< ======================== extern void bar(double); struct S { int n; }; void foo(struct S s, double a, int i, int j, int k) { struct S t; bar(s.n * a * i * j); t.n = s.n * a * i * k; } ======================== >8 ======================== $ gcc -S -g -O -ffast-math bug.c bug.c: In function 'foo': bug.c:7:6: error: definition in block 2 follows the use void foo(struct S s, double a, int i, int j, int k) ^ for SSA_NAME: _4 in statement: # DEBUG D#3 => _4 * _6 bug.c:7:6: internal compiler error: verify_ssa failed 0x888c299 verify_ssa(bool) ../../gcc-4.9/gcc/tree-ssa.c:1046 0x85dc5ca execute_function_todo ../../gcc-4.9/gcc/passes.c:1970 0x85db901 do_per_function ../../gcc-4.9/gcc/passes.c:1707 0x85dc6df execute_todo ../../gcc-4.9/gcc/passes.c:2002 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. GCC 4.9.0 20130630 (experimental).
Still fails on 20130710. Another test case that generates the same message is available on request.
*** Bug 57923 has been marked as a duplicate of this bug. ***
*** Bug 58131 has been marked as a duplicate of this bug. ***
*** Bug 58018 has been marked as a duplicate of this bug. ***
Started with r199048.
(In reply to Marek Polacek from comment #12) > Started with r199048. yes, as was pointed out in PR57370 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57370#c2 which is presumably a dup (but hanging instead of ICEing). Given the number of duplicates, it would be great to see this fixed sooner than later, but so far there has been no reply by the author of r199048.
>Given the number of duplicates, it would be great to see this fixed sooner than >later, but so far there has been no reply by the author of r199048. They have had almost 13 weeks to think about it. Ok, it's holiday season, but AFAIK that's quite some time really. Richard Biener is usually pretty sharp at these kind of problems. Richard, do you have any spare time to offer your expertise, or should I avoid bothering you at this time ?
The fix am about to test (optimize_range_tests can change the ranks...) --- gcc/tree-ssa-reassoc.c.mp 2013-08-20 13:40:45.478290165 +0200 +++ gcc/tree-ssa-reassoc.c 2013-08-20 13:41:00.428348680 +0200 @@ -4237,6 +4237,9 @@ reassociate_bb (basic_block bb) if (TREE_CODE (lhs) == SSA_NAME && has_zero_uses (lhs)) continue; + if (rhs_code == BIT_IOR_EXPR || rhs_code == BIT_AND_EXPR) + optimize_range_tests (rhs_code, &ops); + gimple_set_visited (stmt, true); linearize_expr_tree (&ops, stmt, true, true); ops.qsort (sort_by_operand_rank); @@ -4248,9 +4251,6 @@ reassociate_bb (basic_block bb) optimize_ops_list (rhs_code, &ops); } - if (rhs_code == BIT_IOR_EXPR || rhs_code == BIT_AND_EXPR) - optimize_range_tests (rhs_code, &ops); - if (first_pass_instance && rhs_code == MULT_EXPR && flag_unsafe_math_optimizations)
That doesn't look right to me, optimize_range_test I'd expect to depend on the linearization etc.
Yeah, it "fixed" a few testcases for me, but it's wrong. :(
Could you confirm if the patch in http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01584.html fix this? I am waiting for someone to review that patch.
(In reply to Easwaran Raman from comment #18) > Could you confirm if the patch in > http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01584.html fix this? I am > waiting for someone to review that patch. Thanks! I have added the patch URL to bugzilla. I've tested your patch, and it fixes the Fortran testcase in comment #6 . It does not fix the c testcase in comment #7.
Yes, the patch maybe fixes the debuginfo issue, but there's something else that is wrong. E.g., on the testcase from PR58018, we have in reassociate_bb *after* (and that is important) optimize_range_tests this: <bb 7>: [...] e.1_16 = _14 & e.0_15; _17 = f_12 >= 0; _18 = (int) _17; e.1_19 = e.1_16 & _18; _20 = f_12 > 0; _23 = f_12 > 0; _24 = (int) _23; _21 = (int) _20; e.1_22 = e.1_19 & _21; [...] Now, in reassociate_bb, we go over the stmts, from the last stmt to the first stmt in the bb. For the appropriate stmts, we call rewrite_expr_tree to rewrite the linearized statements according to the operand_entry_t ops vector, in this case we call it on e.1_22 = e.1_19 & _21; and the vector ops contains Op 0 -> rank: 589826, tree: _14 Op 1 -> rank: 3, tree: _24 Op 2 -> rank: 1, tree: e.0_15 In rewrite_expr_tree, we recursively call this function on e.1_19, whose SSA_NAME_DEF_STMT is e.1_19 = e.1_16 & _18; This stmt is then transformed into e.1_19 = _24 & e.0_15; But, at the point where e.1_19 is defined, the _24 isn't defined yet! So, it seems, ensure_ops_are_available should handle a situation like this. However, it doesn't: perhaps the issue is that find_insert_point won't find the right insert point (the stmt is e.1_19 = e.1_16 & _18;, the dep_stmt is _24 = (int) _23;), in there we have: if (gimple_uid (insert_stmt) == gimple_uid (dep_stmt) && gimple_bb (insert_stmt) == gimple_bb (dep_stmt) && insert_stmt != dep_stmt) insert_stmt = appears_later_in_bb (insert_stmt, dep_stmt); else if (not_dominated_by (insert_stmt, dep_stmt)) insert_stmt = dep_stmt; return insert_stmt; Neither of these condition holds; gimple_uid of the dep_stmt is 0 and of insert_stmt it is 16. Thus, find_insert_point returns e.1_19 = e.1_16 & _18;. That's wrong, I suppose. Maybe the issue is that if the two stms are in the same bb, we just look at their UIDs and based on that we find out the dependency, but the new stms coming from optimize_range_tests don't have gimple UIDs set, thus this can't work. Likely I'm wrong, would appreciate if someone could shed some light on this. Looking into it more...
Created attachment 30690 [details] Proposed patch
(In reply to Marek Polacek from comment #20) > Yes, the patch maybe fixes the debuginfo issue, but there's something else > that is wrong. E.g., on the testcase from PR58018, we have in > reassociate_bb *after* > (and that is important) optimize_range_tests this: > > <bb 7>: > [...] > e.1_16 = _14 & e.0_15; > _17 = f_12 >= 0; > _18 = (int) _17; > e.1_19 = e.1_16 & _18; > _20 = f_12 > 0; > _23 = f_12 > 0; > _24 = (int) _23; > _21 = (int) _20; > e.1_22 = e.1_19 & _21; > [...] > > Now, in reassociate_bb, we go over the stmts, from the last stmt to the > first stmt in the bb. For the appropriate stmts, we call rewrite_expr_tree > to rewrite the linearized statements according to the operand_entry_t ops > vector, in this case we call it on > e.1_22 = e.1_19 & _21; > and the vector ops contains > Op 0 -> rank: 589826, tree: _14 > Op 1 -> rank: 3, tree: _24 > Op 2 -> rank: 1, tree: e.0_15 > > In rewrite_expr_tree, we recursively call this function on e.1_19, whose > SSA_NAME_DEF_STMT is > e.1_19 = e.1_16 & _18; > This stmt is then transformed into > e.1_19 = _24 & e.0_15; > > But, at the point where e.1_19 is defined, the _24 isn't defined yet! > > So, it seems, ensure_ops_are_available should handle a situation like this. > However, it doesn't: perhaps the issue is that find_insert_point won't find > the right insert point (the stmt is e.1_19 = e.1_16 & _18;, the dep_stmt is > _24 = (int) _23;), in there we have: > > if (gimple_uid (insert_stmt) == gimple_uid (dep_stmt) > && gimple_bb (insert_stmt) == gimple_bb (dep_stmt) > && insert_stmt != dep_stmt) > insert_stmt = appears_later_in_bb (insert_stmt, dep_stmt); > else if (not_dominated_by (insert_stmt, dep_stmt)) > insert_stmt = dep_stmt; > return insert_stmt; > > Neither of these condition holds; gimple_uid of the dep_stmt is 0 and of > insert_stmt it is 16. Thus, find_insert_point returns e.1_19 = e.1_16 & > _18;. That's wrong, I suppose. > Maybe the issue is that if the two stms are in the same bb, we just look at > their UIDs and based on that we find out the dependency, but the new stms > coming from optimize_range_tests don't have gimple UIDs set, thus this > can't work. > Likely I'm wrong, would appreciate if someone could shed some light on this. > > Looking into it more... The problem with this test case is that there is a statement with uid 0 that is being compared. The assumption was every stmt will have a UID in a monotonically non-decreasing order. This is broken here because force_gimple_operand_gsi generates new stmts that don't have a UID. The proposed patch generates UIDs for these newly generated statements but I think this is a bit ugly and fragile now.
(In reply to Easwaran Raman from comment #21) > Created attachment 30690 [details] > Proposed patch I tested this patch on top of the one posted to the mailing list (comment #18), and this fixes the testcase in #6 and #7. However it does not fix the testcase reported in PR57923 (marked as dup of this PR, and replicated now for completeness): gcc -O3 : char a; foo (int **p) { int b; for (;;) { int c[1] = {}; unsigned *d = &c[0]; for (b=7; b; b--) **p &= --*d >= a; } }
Also the other 'dup' PRs still fail (gcc -O3) . Collecting testcases here: > cat PR58018.c int a, b, c, d, e; void bar (int p) { int f = b; e &= p <= (f ^= 0); } void foo () { for (; d; d++) { bar (a && c); bar (0); bar (1); } } > cat PR58131.c short a; int b, c; int d[1][4][2]; void foo () { int *e; for (b = 1;; b--) { if (*e) break; for (c = 2; c >= 0; c--) { *e |= d[0][3][b] != a; int *f = &d[0][3][b]; *f = 0; } } }
*** Bug 58248 has been marked as a duplicate of this bug. ***
*** Bug 57718 has been marked as a duplicate of this bug. ***
These two test cases pass for me (compiles with -O3) with the attached patch (http://gcc.gnu.org/bugzilla/attachment.cgi?id=30690). gcc --version returns: gcc (GCC) 4.9.0 20130821 (experimental) At what revision are you still getting the ICEs? The patch attached to this bug subsumes the one posted in http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01584.html . (In reply to Joost VandeVondele from comment #24) > Also the other 'dup' PRs still fail (gcc -O3) . Collecting testcases here: > > > cat PR58018.c > > int a, b, c, d, e; > > void bar (int p) > { > int f = b; > e &= p <= (f ^= 0); > } > > void foo () > { > for (; d; d++) > { > bar (a && c); > bar (0); > bar (1); > } > } > > > > cat PR58131.c > > short a; > int b, c; > int d[1][4][2]; > > void foo () > { > int *e; > for (b = 1;; b--) > { > if (*e) > break; > for (c = 2; c >= 0; c--) > { > *e |= d[0][3][b] != a; > int *f = &d[0][3][b]; > *f = 0; > } > } > }
(In reply to Easwaran Raman from comment #27) > These two test cases pass for me (compiles with -O3) with the attached patch > (http://gcc.gnu.org/bugzilla/attachment.cgi?id=30690). > gcc --version returns: OK, with only the patch mentioned above applied all testcases now pass. I think this patch should be posted to gcc-patches for review, if you haven't done yet. Thanks!
(In reply to Joost VandeVondele from comment #28) > OK, with only the patch mentioned above applied all testcases now pass. I > think this patch should be posted to gcc-patches for review, if you haven't > done yet. Thanks! Unfortunately, more testing with this patch applied now leads to this: > gfortran -g -O2 -c bug.f90 bug.f90: In function ‘mp_alltoall_z11v’: bug.f90:1:0: internal compiler error: Segmentation fault SUBROUTINE mp_alltoall_z11v ( sb, scount, sdispl, rb, rcount, rdispl, group ) ^ 0x9d222f crash_signal ../../gcc/gcc/toplev.c:335 0xb11ac7 assign_uids_for_stmts_before ../../gcc/gcc/tree-ssa-reassoc.c:1968 0xb128bb negate_value ../../gcc/gcc/tree-ssa-reassoc.c:3410 0xb1b123 break_up_subtract ../../gcc/gcc/tree-ssa-reassoc.c:3460 0xb1b123 break_up_subtract_bb ../../gcc/gcc/tree-ssa-reassoc.c:3801 > cat bug.f90 SUBROUTINE mp_alltoall_z11v ( sb, scount, sdispl, rb, rcount, rdispl, group ) COMPLEX(kind=8), DIMENSION(:), INTENT(IN) :: sb INTEGER, DIMENSION(:), INTENT(IN) :: scount, sdispl, rdispl, rcount COMPLEX(kind=8), DIMENSION(:), INTENT(INOUT) :: rb rb(rdispl(1)+1:rdispl(1)+rcount(1))=sb(sdispl(1)+1:sdispl(1)+scount(1)) END SUBROUTINE mp_alltoall_z11v
Created attachment 30727 [details] New patch This fixes the ICE. Bootstraps ok with this patch, but haven't run the tests.
(In reply to Easwaran Raman from comment #30) > Created attachment 30727 [details] > New patch fixes all previously observed issues and further light testing.
*** Bug 58247 has been marked as a duplicate of this bug. ***
*** Bug 57592 has been marked as a duplicate of this bug. ***
Looks like another occurrence of the same issue? regehr@john-home ~/z/reduce/r114 $ gcc -c -O3 small.c small.c: In function ‘x4’: small.c:3:5: error: definition in block 3 follows the use int x4() { ^ for SSA_NAME: _30 in statement: x1.2_15 = _30 & pretmp_25; small.c:3:5: internal compiler error: verify_ssa failed 0xaa1e9d verify_ssa(bool) /home/regehr/z/compiler-source/gcc/gcc/tree-ssa.c:1046 0x87ea51 execute_function_todo /home/regehr/z/compiler-source/gcc/gcc/passes.c:1834 0x87f197 execute_todo /home/regehr/z/compiler-source/gcc/gcc/passes.c:1866 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. regehr@john-home ~/z/reduce/r114 $ regehr@john-home ~/z/reduce/r114 $ cat small.c int x0, x1, x2; void x3(); int x4() { for (;;) { x3(); int x5 = x0 = 0; for (; x0 < 7; ++x0) { x5--; x1 &= x2 <= x5; } } } regehr@john-home ~/z/reduce/r114 $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/regehr/z/compiler-install/gcc-r202470-install/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/regehr/z/compiler-source/gcc/configure --prefix=/home/regehr/z/compiler-install/gcc-r202470-install --enable-languages=c,c++ --disable-multilib Thread model: posix gcc version 4.9.0 20130910 (experimental) (GCC)
The #c34 testcase seems to fail starting r199048 till current HEAD.
(In reply to Jakub Jelinek from comment #35) > The #c34 testcase seems to fail starting r199048 till current HEAD. Besides John's new testcase from #c34, I've also encountered quite a number of different testcases causing this same ICE (either at -O2 or -O3, with and without -g), but the proposed patch by Easwaran from #c30 appears to fix everything so far (tested with revision 202121).
*** Bug 57400 has been marked as a duplicate of this bug. ***
*** Bug 58494 has been marked as a duplicate of this bug. ***
*** Bug 58522 has been marked as a duplicate of this bug. ***
What's the status on this?
(In reply to Richard Biener from comment #40) > What's the status on this? I checked comment #34 and a number of the bugs marked as dup, and they all seem to pass. I think this can be closed as fixed ?
(In reply to Richard Biener from comment #40) > What's the status on this? I'd hope r203979 (and earlier reassoc changes) fixed all this, perhaps we want to add testcases from this to the testsuite?
Author: jakub Date: Wed Nov 27 23:41:56 2013 New Revision: 205466 URL: http://gcc.gnu.org/viewcvs?rev=205466&root=gcc&view=rev Log: PR middle-end/57393 PR tree-optimization/58018 PR tree-optimization/58131 * gcc.dg/torture/pr57393-1.c: New test. * gcc.dg/torture/pr57393-2.c: New test. * gcc.dg/torture/pr57393-3.c: New test. * gcc.dg/torture/pr58018.c: New test. * gcc.dg/torture/pr58131.c: New test. * gfortran.dg/pr57393-1.f90: New test. * gfortran.dg/pr57393-2.f90: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr57393-1.c trunk/gcc/testsuite/gcc.dg/torture/pr57393-2.c trunk/gcc/testsuite/gcc.dg/torture/pr57393-3.c trunk/gcc/testsuite/gcc.dg/torture/pr58018.c trunk/gcc/testsuite/gcc.dg/torture/pr58131.c trunk/gcc/testsuite/gfortran.dg/pr57393-1.f90 trunk/gcc/testsuite/gfortran.dg/pr57393-2.f90 Modified: trunk/gcc/testsuite/ChangeLog
Fixed.
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.