This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC optimizes integer overflow: bug or feature?
On 12/20/06, Marcin Dalecki <martin@dalecki.de> wrote:
You better don't. Really! Please just realize for example the impact
of the (in)famous 80 bit internal (over)precision of a
very common IEEE 754 implementation...
volatile float b = 1.;
if (1. / 3. == b / 3.) {
printf("HALLO!\n")
} else {
printf("SURPRISE SURPRISE!\n");
}
It has always seemed to me that floating point comparison could
be standardized to regularize the exponent and ignore the least significant
few bits and doing so would save a lot of headaches. Would it really save
the headaches or would it just make the cases where absolute comparisons
of fp results break less often, making the error more intermittent and
thereby worse? Could a compiler switch be added that would alter
fp equality?
I have argued for "precision" to be included in numeric types in other forae
and have been stunned that all except people with a background in Chemistry
find the suggestion bizarre and unnecessary; I realize that GCC is not really
a good place to try to shift norms; but on the other hand if a patch was to
be prepared that would add a command-line switch (perhaps -sloppy-fpe and
-no-sloppy-fpe) that would govern wrapping ((fptype) == (fptype)) with something
that threw away the least sig. GCC_SLOPPY_FPE_SLOP_SIZE bits in
the mantissa, would it get accepted or considered silly?