This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Floating point trouble with x86's extended precision

Robert Dewar wrote:
The current behavior sometimes results in objects which appear to
spontaneously change their values between two read accesses (without
any intermediate write access).  I find it hard to believe that such
indeterminacy is permitted by any language standard.

It is certainly permitted by the Fortran 77 standard
It is certainly permitted by the Ada 83 standard
It is certainly permitted by the Ada 95 standard (very explicitly)

As always it is better to go by what is in the standard rather than what
you believe (or find hard to believe).

With regard to the Fortran 77 standard, this is the subject of a well known letter from Kahane, complaining of a bug, but in fact this was
not a bug according to the standard, though it certainly surprised
the writer of that letter :-)

I will let someone else quote language from the C or C++ standard that
would show that Florians universal quantification at least is correct
in existential form :-)


OK. FWIW, C99 is quite specific about this particular case.

[ of ISO/IEC9899:1999 - extra blank lines
inserted; emphasis is original]

"Implementations employing wide registers have to take care to honor
appropriate semantics.

Values are independent of whether they are represented in a register or in memory.

For example, an implicit /spilling/ of a register is not permitted to alter the value.

Also, an explicit /store/ and /load/ is required to round to the precision of
the storage type.

In particular, casts and assignments are required to perform their specified conversion.

[example floating-point code elided]"

Also, in 6.2.4#2:

"An object exists, has a constant address, and retains its last-stored value
throughout its lifetime."

No special exemption for floating-point types.

So it seems like GCC on i387 is non-conforming (to C99). And it looks like the authors might have had i387 in mind when they wrote this.

Whether that non-conformity is considered to be a bug in GCC or not is a different

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]