In a large application, a certain routine from the UMFPACK library is miscompiled when -O is specified. Without optimisation, the routine works fine. This triggers an assertion failure in the code. I use gcc (GCC) 4.1.0 20051030 (experimental). The problem can be reproduced with the attached source files. To see the error, compile them with /gcc/bin/gcc -g -O -o umfpack-bug umfpack-call.c umf_analyze.i umf_apply_order.i umf_order_front_tree.i umf_dump.i When run, the executable aborts with an assertion failure: /Users/eschnett/Calpha/arrangements/AEIThorns/AHFinderDirect/src/sparse-matrix/umfpack/umf_analyze.c:500: failed assertion `parent == j+1' Abort trap (core dumped) To make the error go away, omit the "-O" option. In this case, the executable runs without producing any output. The error seems to be the following. The routine UMF_analyze contains a large loop in which the local variable pdest is changed. In the next iteration, pdest is reset to the value it had before the loop. This happens only for local variables, not for static or global variables. The error seems to be specific to powerpc; it does not happen on i386. gcc 3.3 does not have this problem.
Created attachment 10165 [details] Tarball with source code demonstrating the problem
(In reply to comment #0) > The error seems to be specific to powerpc; it does not happen on i386. It does fail for me on i686 with 4.1.0 20051026.
A little more info, umf_analyze.i is being miscompiled. I don't know which one yet.
-O1 -fno-tree-ccp -fno-tree-store-ccp -fno-tree-dominator-opts works (maybe this will give a hint on how to reduce the issue).
I would like to identify the cause of this problem. Would it help if I tracked down the patch number that caused this problem? Andrew, do you have an automated system to do that, or is someone already doing it? Otherwise I would try that with a small script. But it seems to take a long time to do that, so I wouldn't want to waste the effort.
For now, I am trying to get the size of umf_analyze down by removing the unnecessary prototypes, beautifying the code, etc... Paolo
Reduced testcase /* { dg-do run } */ /* { dg-options "-O -fdump-tree-dom3" } */ int Link[] = { -1 }; int W[] = { 2 }; extern void abort (void); int f (int k, int p) { int pdest, j, D1361; j = 0; pdest = 0; for (;;) { if (pdest > 2) do j--, pdest++; while (j > 2); if (j == 1) break; while (pdest > p) if (j == p) pdest++; do { D1361 = W[k]; do if (D1361 != 0) pdest = 1, W[k] = D1361 = 0; while (p < 1); } while (k > 0); do { p = 0; k = Link[k]; while (p < j) if (k != -1) pdest++, p++; } while (k != -1); j = 1; } /* The correct return value should be pdest (1 in the call from main). DOM3 is mistaken and propagates a 0 here. */ return pdest; } int main () { if (!f (0, 2)) abort (); return 0; } /* { dg-final { scan-tree-dump-times "return 0" 1 "dom3" } } */ /* { dg-final { cleanup-tree-dump "dom3" } } */
dom3 is at fault
It's IVCANONs fault, pr24716.c.t76.ivcanon: ... # pdest_23 = PHI <0(1)>; <L24>:; return pdest_23; }
Or more definitely, store copyprop. # BLOCK 1 freq:122 # PRED: 0 [100.0%] (fallthru,exec) 31 [100.0%] (fallthru,exec) # jD.1285_18 = PHI <0(0), 1(31)>; # pD.1281_7 = PHI <pD.1281_25(0), pD.1281_48(31)>; # kD.1280_5 = PHI <kD.1280_26(0), kD.1280_30(31)>; # WD.1277_1 = PHI <WD.1277_27(0), WD.1277_57(31)>; <L0>:; if (0) goto <L43>; else goto <L3>; # SUCC: 2 [50.0%] (true,exec) 6 [50.0%] (false,exec) ... # BLOCK 6 freq:122 # PRED: 1 [50.0%] (false,exec) 5 [100.0%] (fallthru,exec) # jD.1285_20 = PHI <jD.1285_18(1), jD.1285_17(5)>; # pdestD.1284_11 = PHI <0(1), 1(5)>; <L3>:; if (jD.1285_20 == 1) goto <L24>; else goto <L26>; # SUCC: 33 [10.0%] (loop_exit,true,exec) 7 [90.0%] (false,exec) ... # BLOCK 33 freq:12 # PRED: 6 [10.0%] (loop_exit,true,exec) # pdestD.1284_23 = PHI <pdestD.1284_11(6)>; <L24>:; return pdestD.1284_23; cfg_cleanup will propagate through the PHIs.
Doh, I have a fix. What a stupid error in analyze_evolution_in_loop.
Created attachment 10185 [details] patch this is what I'm going to test.
(In reply to comment #10) > Or more definitely, store copyprop. s/store/scev/
Subject: Bug 24716 Author: rguenth Date: Wed Nov 9 18:00:59 2005 New Revision: 106700 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106700 Log: 2005-11-09 Richard Guenther <rguenther@suse.de> PR tree-optimization/24716 * tree-scalar-evolution.c (analyze_evolution_in_loop): Use t_bool to track results from follow_ssa_edge. * gcc.c-torture/execute/pr24716.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr24716.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-scalar-evolution.c
Fixed.