[Bug middle-end/36593] New: [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc

[Bug middle-end/36593] New: [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc

[hp at gcc dot gnu dot org]

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.


-- 
           Summary: [4.4 Regression]: gfortran.dg/default_format_1.f90,
                    22_locale/num_get/get/char/2.cc
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36593

[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc

[hp at gcc dot gnu dot org]

-- 

hp at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-06-22 03:02:18
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36593

[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc

[hp at gcc dot gnu dot org]

-- 

hp at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36593

[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc

[hp at gcc dot gnu dot org]

------- Comment #1 from hp at gcc dot gnu dot org  2008-06-22 08:39 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36593

[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2008-06-22 15:43 -------
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).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36593

[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc

[hp at gcc dot gnu dot org]

------- 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.


-- 

hp at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36593

[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc

[hp at gcc dot gnu dot org]

------- Comment #4 from hp at gcc dot gnu dot org  2008-06-23 07:38 -------
FWIW, I'm about to fix newlib...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36593

[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc

[rguenther at suse dot de]

------- Comment #5 from rguenther at suse dot de  2008-06-23 09:48 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36593

[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc

[hp at gcc dot gnu dot org]

------- Comment #6 from hp at gcc dot gnu dot org  2008-06-23 13:13 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36593

[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc

[hp at gcc dot gnu dot org]

------- Comment #7 from hp at gcc dot gnu dot org  2008-06-23 13:30 -------
Created an attachment (id=15806)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15806&action=view)
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36593

[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc

[hp at gcc dot gnu dot org]

------- Comment #8 from hp at gcc dot gnu dot org  2008-06-24 02:38 -------
Newlib patch here: <http://sourceware.org/ml/newlib/2008/msg00350.html>, also
referring to a gcc documentation improvement patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36593