[From nobody Mon Apr  7 18:25:53 2003
Return-Path: apache@redhat.com
Received: from mx1.redhat.com (66.187.233.31) by hermes.iarc.fr (V5.0A-1,
	OpenVMS V7.2-1 Alpha); Mon, 07 Apr 2003 18:13:07 +0200
Received: from beta.redhat.com (beta.redhat.com [172.16.48.203]) by
	mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h37GDSe12964 for
	<plummer@iarc.fr>; Mon, 7 Apr 2003 12:13:28 -0400
Received: (from apache@localhost) by beta.redhat.com (8.11.6/8.11.6) id
	h37GDOq12781; Mon, 7 Apr 2003 12:13:24 -0400
Date: Mon, 7 Apr 2003 12:13:24 -0400
Message-Id: <200304071613.h37GDOq12781@beta.redhat.com>
From: bugzilla@redhat.com
To: plummer@iarc.fr
Subject: [Bug 88174] Optimization causes corruption of NA value in the R
	language
Content-type: text/plain; charset=utf-8
X-Loop: bugzilla@redhat.com
X-BeenThere: bugzilla@redhat.com
X-Bugzilla-Reason: Reporter
X-Bugzilla-Changed-Fields: Resolution Status 
Mime-Version: 1.0

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=88174


jakub@redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|                            |WONTFIX
             Status|NEW                         |CLOSED




------- Additional Comments From jakub@redhat.com  2003-04-07 12:13 -------
Well, you could as well use the workaround which is there for gcc 3.x on SPARC,
ie. define CONST to nothing.
The problem is that all GCCs < 3.3 only handle one default NaN in real.c, so
if some optimization decides to make the constant go through real.c routines
the exact NaN value is lost.
This is fixed in gcc 3.3 and above, as real.c has been rewritten there, but backporting
it would be too risky, the changes touched a lot of code.



------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.

]