Re: IEEE 754 floating point standard

John wrote:
Hi, I was wondering a couple things:

1) Does VC6 comply with the IEEE 754 floating point standard?

No, but VC6 doesn't do any floating-point operations. Rather, it delegates
them to the hardware you are running on.

2) Does complying with this standard guarantee exactly the same result
of a calculation on different manufactured AMD64 compliant CPUs and
different OSes.

No. It might even depend on the optimisation settings of the compiler.

3) I understand that different optimization settings could possibly
change the result of a calculation, but given the same compiled
executable, could optimization settings change the results on different
OSes?

I'd say the OS is less responsible than the hardware, and relying on exact
same results is not a good idea.

We are trying to track down a strange bug in an algorithm that converts
a NURBS surface to a mesh. The algorithm has worked for years on Win2k
and XP but is not working on Vista.

Sounds like your program does some invalid assumptions like a pointer being
32 bits, a long having the size of a pointer (which is a valid assumption
in C99 and C++, bit broken by win64 using the LLP64 model) or similar
things.

I find unlikely to be a floating point implementation problem but I am
not an expert in systems implementations. I would, more likely suspect
memory management, which has undergone significant changes in Vista, but
I would like to rule out the floating point implementation possibility,
so I would appreciate any input you may have.

I also don't think it's the floating point operations.

I should also mention that, yes we are still using VC6. We are in the
process of converting everything over to VC2005, but have not reached
that point yet.

VS2005 has a much better compiler (two major releases ahead) which also
includes helpers to find common errors like buffer overflows, use of
uninitialised variables and a checked implementation of the C++
standardlibrary. I would make that switch first, possibly you will find the
errors on the way.

Uli

.

Relevant Pages

  • Re: IIR filter help
    ... Why do you think floating point will work in an interrupt? ... For one because interrupts are outside the C standard so their ... IIRC I've also run across a compiler that had non-reentrant long ...
    (comp.arch.embedded)
  • Re: A question about memory allocation
    ... what is required by the standard is that one be able to ... tell that a particular reference is to a floating point numbers. ... Now it is possible, with appropriate declarations and compiler settings, ...
    (comp.lang.lisp)
  • Re: Sine code for ANSI C
    ... >> shell script) fully conforming. ... limits mentioned in the standard. ... adding a few more translation limits. ... minimal accuracy requirements for the floating point operations. ...
    (comp.lang.c)
  • Re: compression in floating point arithmetic
    ... If you want to force floating point values to the same type, ... I was thinking that the sequence point stuff could affect in some way this behaviour, it just seemed very reasonable reading the standard, even if not explicitally stated. ... showed me that in the other way the augmented precision can be carried out. ... Of course you don't need to explain to me the entire standard, there was just a specific point I thought it was saying that the truncation was forbidden, so for me it would have been enough that someone could explain me that in this case that point doesn't apply (like for example Jack did when he showed me that the contraction thing was wrong). ...
    (comp.std.c)
  • Re: Rfd: floating point truncation V1
    ... Some other standard I looked at makes "round towards zero" ... an internal representation of floating point negative zero, "-0E", which differs ... to go for an IEEE FP extension). ...
    (comp.lang.forth)
Loading