I couldn't find a report about this test failing but it works at -O2 and lower and fails at -O3 on IA64 targets. By inlining foo into main I can make the test fail at -O2. Here is a smaller test case, it prints "36, 40, 44, 0" at -O1 and lower and prints "18, 20, 44, 0" at -O2 and higher. The -O2 results are wrong. typedef float v4sf __attribute__ ((vector_size (16))); union { v4sf v; float f[4]; } v; int main (void) { unsigned int i; for (i = 0; i < 2; i++) v.v += (v4sf) { 18.0, 20.0, 22 }; printf("%g, %g, %g, %d\n", (double) v.f[0], (double) v.f[1], (double) v.f[2], (double) v.f[3]); }
This bug appeared on 4.1 branch between 20060718 (revision 115546) and 20060721 (revision 115639), so a regression.
Janis, could you do a binary search? On 4.1 branch the bug was not in r115546, and was there in r115639. Thanks.
Sorry, I don't have an ia64 system on which to try wrong-code tests.
I will see if I can find the checkin on the 4.1 branch that caused the failure.
It looks like this failure was introduced with r115620. +2006-07-20 Paul Brook <paul@codesourcery.com> + + Backport from mainline. + PR 27363 + * cse.c (cse_insn): Add destination addresses to hash table. Check if + they are invalidated by this instruction.
This bug is weird. If I remove the code in cse_insn where the dest_addr_elt field is used, I still get the bug. So the problem occurs when creating the dest_addr_elt data, not when using it. This makes no sense to me, but that is what I see. I built with --enable-checking=all to see if it caught any data corruption or bad field accesses but I didn't get any errors. I am not sure what to try next. Paul, do you have any idea why your changes would affect a compilation if we create dest_addr_elt but don't use it?
IIRC my change can cause entries to be present into the hash table that wouldn't have been there before. However this should be harmless. I don't have any helpful suggestons why this is broken.
I submitted a patch for this defect, http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01108.html however the failure seems to have gone away even without applying this patch. I think (but did not verify) that this patch went away due to this fix by Roger Sayle: http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00456.html Since the failure no longer happens I am closing the defect as fixed.