With r136685, these tests passed. They are known to fail since r136695. Both seem to be related to formatting of floating point numbers; possibly a miscompilation of newlib. None of the libraries or front-ends had related changes in the svn range. The gfortran test fails at execution at all the torture options, calling abort for one of the subtests. The libstdc++ test fails with (copypasted): assertion "d == d1" failed: file "/tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/22_locale/num_get/get/char/2.cc", line 101, function: void test02()^M program stopped with signal 6.^M I'll add an investigation from diffed disassembled executables and simulator traces. Author of suspect patches in this range CCed.
These tests have also regressed for mmix-knuth-mmixware 132182 -> 136827, so if it's a target-specific thing that went wrong (assuming it's the same reason; there are two more regressions in that range but that's it FWIW), it has to be at a high level, because those targets are about as different as they come.
I certainly belive this was uncovered by my patch for PR36345. But I also believe newlib is at fault here ;) The fix simply makes strict-aliasing rules followed even more (thus, if you build newlib with -fno-strict-aliasing the failure should go away).
An obvious and plausible explanation. It appears it's also correct; simulator traces and trial link-time replacement gives it's _strtod_r (in newlib/libc/stdlib/strtod.c) that's "miscompiled". On closer look it seems the cause is the ugly type-punning done in the dword0 and dword1 macros (defined in mprec.h in the same directory): typedef union { double d; __ULong L[2]; } U; #define dword0(x) ((U*)&x)->L[0] #define dword1(x) ((U*)&x)->L[1] with common use of dword0/1 as lvalues and mixing in non-cast assignments. Ugh.
FWIW, I'm about to fix newlib...
Subject: Re: [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc On Mon, 23 Jun 2008, hp at gcc dot gnu dot org wrote: > ------- Comment #3 from hp at gcc dot gnu dot org 2008-06-23 07:12 ------- > An obvious and plausible explanation. It appears it's also correct; simulator > traces and trial link-time replacement gives it's _strtod_r (in > newlib/libc/stdlib/strtod.c) that's "miscompiled". On closer look it seems the > cause is the ugly type-punning done in the dword0 and dword1 macros (defined in > mprec.h in the same directory): > > typedef union { double d; __ULong L[2]; } U; > #define dword0(x) ((U*)&x)->L[0] > #define dword1(x) ((U*)&x)->L[1] > with common use of dword0/1 as lvalues and mixing in non-cast assignments. > Ugh. Note that this type-punning using a union is ok, so it must be something else (or it is gccs fault in this case). Richard.
(In reply to comment #5) > Note that this type-punning using a union is ok, so it must be something > else (or it is gccs fault in this case). For the record, presumably (re our discussion on irc) you're confusing the type-punning through a union extension with type-punning through a cast using a type containing a union. The "type-punning through a union" extension (documentation malplaced in invoke.texi @opindex fstrict-aliasing) has an example that implies that using casts invalidates the extension. Let's defer to the gcc@ list to be safe. Warnings are emitted with -Wstrict-aliasing=1 and 2, but not 3.
Created attachment 15806 [details] preprocessed offending code Use -O2; should "work" with any 32-bit target. Note the single (U*) cast for e.g. aadj1 in _strtod_r used on the left-hand side. The actual (non-formal) breakage at hand might be that it's used together with ordinary assignments.
Newlib patch here: <http://sourceware.org/ml/newlib/2008/msg00350.html>, also referring to a gcc documentation improvement patch.