GNU Lilypond is miscompiled on Fedora 17. It manifests as a failure to process any non-trivial input. Both i386 and x86_64 are affected. $ gcc --version gcc (GCC) 4.7.0 20120502 (Red Hat 4.7.0-3) It turns out that adding -fno-tree-vrp fixes the problem. A call to min() is affected. Comparing the assembly output without and with -fno-tree-vrp shows that the generated assembly code wrongly eliminates a conditional register move after calling the compare (_ZN6Moment7compareERKS_S1_) function. The attached file was generated on i386. Credit for finding a problem in the assembly goes to David Kastrup.
Created attachment 27310 [details] Example (made on i386) This line is miscompiled: next = min (next, it->pending_moment ()); The result of comparison in min() is unused unless the -fno-tree-vrp option is used.
s_6 = this_5(D)->children_list_; x.4_39 = (long unsigned int) s_6; D.36426_37 = x.4_39 & 6; I think the code is depending on undefined code dealing with alignment requirements on pointers.
prephitmp.102_38 = MEM[(struct scm_unused_struct * *)s_6]; D.36424_34 = (long unsigned int) prephitmp.102_38; D.36423_40 = D.36424_34 & 1; Is the real place.
Actually the following is what is being removed: if (D.36751_45 < 0) goto <bb 6>; else goto <bb 7>; <bb 6>: <bb 7>: # D.36747_44 = PHI <<retval>_2(D)(6), &D.35100(5)> So it is not VRP really as it is doing something fine. It is just we say <retval>_2 is uninitialized.
Is there a self-contained run-time testcase?
Created attachment 27330 [details] Self-contained test case Run the "compile" script. The output would be: return = 2/1 return = 1/1 It means that the output depends on whether -fno-tree-vrp is used.
VRP bug.
Created attachment 27331 [details] gcc47-pr53239.patch Untested fix.
Doh. Patch looks ok.
I applied the patch to gcc 4.7.0 and tested it with my example and GNU Lilypond. Both are fixed. Thanks!
This is caused by revision 176918: http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg01186.html Does the fix improve gcc.dg/uninit-suppress.c/gcc.dg/uninit-suppress_2.c?
Unrelated question: this kind of code is quite common in connection with user-defined arithmetic classes. While I understand that changing the bug priority from "P3 normal" will likely do nothing with regard to which releases of gcc the fix will appear in, it might make a difference for distributors that tend to cherry-pick important fixes ahead of regular releases. For example, the next release of Fedora is slated to be delivered using gcc 4.7.0, and its miscompilation of LilyPond, a bonafide application, was what triggered this report. Given that the triggering pattern is quite typical for C++ and the problem being present on all architectures, it might make sense to adjust the priority.
Author: jakub Date: Mon May 7 13:31:00 2012 New Revision: 187240 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187240 Log: PR tree-optimization/53239 * tree-vrp.c (get_value_range): Set VR of SSA_NAME_IS_DEFAULT_DEF of DECL_BY_REFERENCE RESULT_DECL to nonnull. * g++.dg/opt/vrp3.C: New test. * g++.dg/opt/vrp3-aux.cc: New file. * g++.dg/opt/vrp3.h: New file. Added: trunk/gcc/testsuite/g++.dg/opt/vrp3-aux.cc trunk/gcc/testsuite/g++.dg/opt/vrp3.C trunk/gcc/testsuite/g++.dg/opt/vrp3.h Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
Author: jakub Date: Mon May 7 13:33:27 2012 New Revision: 187241 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187241 Log: PR tree-optimization/53239 * tree-vrp.c (get_value_range): Set VR of SSA_NAME_IS_DEFAULT_DEF of DECL_BY_REFERENCE RESULT_DECL to nonnull. * g++.dg/opt/vrp3.C: New test. * g++.dg/opt/vrp3-aux.cc: New file. * g++.dg/opt/vrp3.h: New file. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/opt/vrp3-aux.cc branches/gcc-4_7-branch/gcc/testsuite/g++.dg/opt/vrp3.C branches/gcc-4_7-branch/gcc/testsuite/g++.dg/opt/vrp3.h Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-vrp.c
Fixed.