Bug 88174 - Optimization causes corruption of NA value in the R language
Optimization causes corruption of NA value in the R language
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-04-07 08:13 EDT by Plummer, Martyn
Modified: 2007-04-18 12:52 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-04-07 12:13:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Plummer, Martyn 2003-04-07 08:13:20 EDT
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 08:15:52 EDT
Created attachment 90947 [details]
Example C program to reproduce bug.
Comment 2 Jakub Jelinek 2003-04-07 12:13:39 EDT
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.