Bug 88174 - Optimization causes corruption of NA value in the R language
Summary: Optimization causes corruption of NA value in the R language
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gcc
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-07 12:13 UTC by Plummer, Martyn
Modified: 2007-04-18 16:52 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-04-07 16:13:39 UTC

Attachments (Terms of Use)
Example C program to reproduce bug. (1005 bytes, text/plain)
2003-04-07 12:15 UTC, Plummer, Martyn
no flags Details

Description Plummer, Martyn 2003-04-07 12:13:20 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830

Description of problem:
This bug emerged in the R language and environment for statistical computing (
http://www.r-project.org ) when compiled on RH 9.

R has uses a special value to denote "missing values" in statistical
computations - NA (not available) - which is distinct from NaN.  When compiled
under Red Hat 9, this distinction is lost. Consequently the build fails to pass
"make check-all".

The essential code has been abstracted to a small demonstration program which is

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
gcc -O1 RNAcheck.c

Actual Results:  Program prints "1"

Expected Results:  Program prints "0"

Additional info:

A workaround, which has been incorporated into the upcoming release of R, is to
declare ieee_double to be volatile.

For some reason, the bug is not triggered when the "-pedantic" flag is used in

Comment 1 Plummer, Martyn 2003-04-07 12:15:52 UTC
Created attachment 90947 [details]
Example C program to reproduce bug.

Comment 2 Jakub Jelinek 2003-04-07 16:13:39 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.