The following snippet (reduced from a larger test case) causes top-of-trunk cc1 to hang (infinite loop) on x86_64-linux using -O or above. This is a regression from 4.7.2 which does not have this issue. $ cat volatile.c volatile int a[1]; int b; void fn1 () { for (;;) { int *c[3][6] = { 0, 0, 0, &b, 0, 0, 0, 0, &b, 0, 0, 0, 0, 0, 0, 0, &b, (int *)&a[0] }; b = *c[2][5]; } } $ gcc-trunk --version gcc-trunk (GCC) 4.8.0 20130225 (experimental) [trunk revision 196255] $ gcc-4.7 -O -c volatile.c $ gcc-trunk -c volatile.c $ gcc-trunk -O -c volatile.c <hangs>
Started with my http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195136 fix. I think the problem is that for: tree val; // which is &a[0] where a is volatile array operand_equal_p (val, unshare_expr (val), OEP_PURE_SAME) is false.
Created attachment 29536 [details] gcc48-pr56448.patch Untested fix. For OEP_CONSTANT_ADDRESS_OF, we should ignore side-effects of the reference from which the address is taken, they change the value, not its address. OEP_CONSTANT_ADDRESS_OF in flags is fine to propagate to the first operand of some references, so e.g. &a.b[0].c[9] is constant, even when c and b arrays are volatile, but not the other arguments (e.g. array indexes, etc.), but for *MEM_REF not even the first argument should get that.
Author: jakub Date: Tue Feb 26 10:00:31 2013 New Revision: 196278 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196278 Log: PR tree-optimization/56448 * fold-const.c (operand_equal_p) <case tcc_reference>: Don't look at TREE_SIDE_EFFECTS if flags contain OEP_CONSTANT_ADDRESS_OF. Clear OEP_CONSTANT_ADDRESS_OF from flags before recursing on second or later operands of the references, or even first operand for INDIRECT_REF, TARGET_MEM_REF or MEM_REF. * gcc.c-torture/compile/pr56448.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr56448.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
Fixed.
Thanks! That was a very quick fix.