From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17228 invoked by alias); 23 Jun 2008 07:13:03 -0000 Received: (qmail 17074 invoked by uid 48); 23 Jun 2008 07:12:15 -0000 Date: Mon, 23 Jun 2008 07:13:00 -0000 Message-ID: <20080623071215.17073.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "hp at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-06/txt/msg01334.txt.bz2 ------- 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