Re: Compiler Correctness

glen herrmannsfeldt <>
17 Feb 2006 16:55:37 -0500

          From comp.compilers

Related articles
[13 earlier articles]
Re: Compiler Correctness (Hans-Peter Diettrich) (2006-02-14)
Re: Compiler Correctness (Marco van de Voort) (2006-02-14)
Re: Compiler Correctness (Hans-Peter Diettrich) (2006-02-14)
Re: Compiler Correctness (2006-02-17)
Re: Compiler Correctness (2006-02-17)
Re: Compiler Correctness (Sid Touati) (2006-02-17)
Re: Compiler Correctness (glen herrmannsfeldt) (2006-02-17)
Re: Compiler Correctness (=?iso-8859-1?Q?Ingo_St=FCrmer?=) (2006-04-27)
| List of all articles for this month |

From: glen herrmannsfeldt <>
Newsgroups: comp.compilers
Date: 17 Feb 2006 16:55:37 -0500
Organization: Compilers Central
References: 06-02-053 06-02-078 06-02-093 06-02-107 06-02-110
Keywords: arithmetic, testing, comment
Posted-Date: 17 Feb 2006 16:55:37 EST

Henry Spencer wrote:
> Hans-Peter Diettrich <> wrote:

>>Ambiguities also can arise from different models or precision, as
>>implemented in specific FPU hardware. Doesn't this imply that a correct
>>compiler must emulate all floating point operations, so that the output
>>does not depend on the host machine of the compiler?

> Not *necessarily*, although (as I said in a previous message) that may be
> a sensible thing to do on general principles.


I remember when the Pentium FDIV bug came out there was a C program to
compile and run to test for the bug. All the operations were done with
constants, which were evaluated by the compiler. Some compilers did it
in software, not using FDIV, and so didn't report the bug.

The IBM 360/91 supplies a rounded quotient in floating point divide,
instead of the truncated quotient specified by S/360. A program
compiled on one system may have different values for constant
expressions from the system it runs on.

-- glen
[The /91 didn't round. That was the /195. -John]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.