Created attachment 27768 [details] Repeat with e.g. cc1 -O2 ba2.c Observed with gcc-4_7-branch revision 189394. The attached test-case calls is_basic(user_name) < 0 && is_digest(user_name) < 0 with *user_name = NULL. The call to is_basic "fails"; returns < 0 without writing to *user_name. The call to is_digest is successful and furthermore writes *user_name (a char **). Next, *user_item = find_user(*user_name) is called, but the load of *user_name after the is_digest call is lost; wrongly eliminated in favor of the load after the call to is_basic. A dump shows wrong code first in the ".207r.csa" pass (for crisv32-axis-linux-gnu, likely for x86_64 as well). The test-case does not expose the bug on trunk r189401. Not observed with a gcc-4.3-based toolchain (cris-*), not observed with (host) "Debian 4.4.5-8". Unknown 4.5, 4.6.
I can reproduce on sparc64-linux: gcc 4.4, 4.5, and 4.8 generate working code, but 4.6 and 4.7 generate code that SEGVs. I wasn't able to reproduce on ARMv5 or m68k.
I can't reproduce on x86_64-linux, nor with a cross to sparc64-linux (only natively on sparc64-linux so far). HP: are you sure it fails on x86_64? I'll try to bisect natively on sparc64, but that will take ages...
(In reply to comment #2) > I can't reproduce on x86_64-linux, Odd. What does valgrind say / did you check the generated code? > HP: are you sure it fails on x86_64? Yes, as written. N.B.: I used --disable-bootstrap, but that shouldn't have any significance modulo bugs. Host (native) compiler was the mentioned "Debian 4.4.5-8" x86_64 gcc, but not for all targets and only for pristine FSF code checks. Are you sure you used the gcc 4.7 branch for x86_64? ;) It can't be ruled out of course that there's some address hash thing clouding the issue, but the reproducibility seems stable (same gcc binary on different targets; different host gcc).
My mistake, I can now reproduce the runtime SEGV on x86_64-linux with vanilla gcc-4.7-20120707.
On x86_64-linux the SEGV went away on trunk with r186159: http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00108.html http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00202.html The patch description makes it sound more like a cleanup than fixing actual bugs, but when I diff the assembly code for the test case with r186158 and r186159 I see: --- pr53908.s-r186158 2012-07-11 00:28:57.000000000 +0200 +++ pr53908.s-r186159 2012-07-11 00:34:32.000000000 +0200 ... call is_basic testl %eax, %eax - movq 8(%rsp), %rbp - js .L68 -.L29: + js .L29 +.L33: movq users(%rip), %rbx + movq 8(%rsp), %rbp testq %rbx, %rbx ... That is, a load is being moved across a control flow insn. All other diffs seem to just be changed label numbers. I'll give it some more testing tomorrow.
It is fixed on trunk by revision 186159: http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00108.html
It is caused by revision 167779: http://gcc.gnu.org/ml/gcc-cvs/2010-12/msg00461.html
Backporting r186159 and its followup fix r186164 to 4.7.1 was easy and fixed the test case there too (untested beyond this test case). Backporting those revisions to 4.6.3 required more elbow grease but didn't fix the test case there. I'm going to test the 4.7 backport properly now, in case a smaller more direct fix doesn't emerge soon.
The fix is posted at http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00410.html
Created attachment 27783 [details] patch from Richard Sandiford Updated patch, from http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00463.html (which wasn't in patch form).
Author: hp Date: Fri Jul 13 08:53:24 2012 New Revision: 189454 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189454 Log: PR rtl-optimization/53908 * df-problems.c (can_move_insns_across): When doing memory-reference book-keeping, handle call insns. Modified: trunk/gcc/ChangeLog trunk/gcc/df-problems.c
Author: hp Date: Fri Jul 13 08:58:46 2012 New Revision: 189455 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189455 Log: PR rtl-optimization/53908 * gcc.dg/torture/pr53908.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr53908.c Modified: trunk/gcc/testsuite/ChangeLog
Author: hp Date: Fri Jul 13 17:21:41 2012 New Revision: 189468 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189468 Log: PR rtl-optimization/53908 * df-problems.c (can_move_insns_across): When doing memory-reference book-keeping, handle call insns. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/df-problems.c
Author: hp Date: Fri Jul 13 17:22:55 2012 New Revision: 189469 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189469 Log: PR rtl-optimization/53908 * gcc.dg/torture/pr53908.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr53908.c Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
Testing for 4.7 went well, as expected from the previous versions, so committed. Closing, but feel free to post test-results for 4.6 and permission for back-port.
GCC 4.6 is still maintained, so this regression report should stay open. In fact, being wrong code on a primary target, and relatively trivial to fix, I'd say this has to be a P1 bug for GCC 4.6.
Will take care of GCC 4.6.
(In reply to comment #17) > Will take care of GCC 4.6. Thanks!
Author: steven Date: Mon Jul 16 09:36:04 2012 New Revision: 189512 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189512 Log: Backport from trunk: gcc/ PR rtl-optimization/53908 * df-problems.c (can_move_insns_across): When doing memory-reference book-keeping, handle call insns. testsuite/ PR rtl-optimization/53908 * gcc.dg/torture/pr53908.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr53908.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/df-problems.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
.