Re: [Mingw-users] [OT] comparing floating point results of different compilers
- Date: Fri, 20 Jan 2017 07:17:30 +0100
- From: Emanuel Falkenauer <E.Falkenauer@xxxxxxxxxxxxxxxxx>
- Subject: Re: [Mingw-users] [OT] comparing floating point results of different compilers
Extremely well put: that's exactly what we do (i.e. checking the RESULTS).
On 18-01-17 10:47, Tuomo Latto wrote:
> On 18.01.2017 10:48, Alberto Luaces wrote:
>> Emanuel Falkenauer writes:
>>> Now to debug in Embarcadero a problem found in a MinGW build, we must
>>> be sure that the two versions behave exactly the same, and it's anyway
>>> a good QC practice to make sure that that is indeed the case. In order
>>> to do that, we have developed a whole tracing system where one version
>>> writes the details of its progress into a log and the other version
>>> then reads it to spot any differences in behavior. The system already
>>> saved us years in debugging... but floats have always been a problem:
>>> Embarcadero and MinGW don't (s)print(f) them the same! The last digit
>>> in the log is different so often, that many times the logging becomes
>>> largely useless: millions of BOGUS differences show up. Usually we
>>> resign ourselves to use sprintf("%.4f",...) or such, and skip by hand
>>> what are clearly bogus "differences" remaining - but that always
>>> leaves the uncertainty that the differences COULD actually be real,
>>> i.e. that the exact float values are really different in the two
>> Honest question: how can you compare the outputs of a program compiled
>> by two different compilers? How can you make sure that all the
>> computations are carried in the same order? That cannot be done even
>> when using different optimization flags on the same compiler.
> But the fact that programs produced by different compilers work the same
> way, produce the same effects and, in general, even work at all,
> proves that they are the same to the relevant degree. Remember, we are
> not talking about the exact choice or ordering of CPU instructions
> for a single task, but are, in fact, talking about the results of those
> instructions, the completion of that task.
> Logging isn't a separate functionality but integrated to the program
> and thus taken into account in the analysis of the data flow.
> If a compiler optimizes results away or compromises their integrity
> or precision without being asked to, it is faulty.
> The way a compiler knows whether a value in a variable is a "result"
> or not is by looking if (and how) the data is being used - in this case
> probably by if it is taken outside the FPU (memory, GP registers, etc.).
> If it is not, it's an intermediate value that can be discarded once
> not needed, optimized away, or, if aggressively optimized, replaced
> by a more efficient way. On the other hand if it is used, then it is
> a result required in the program that the compiler aims to create,
> a target to satisfy, even if it optimizes how it reaches that target.
>> Are you by chance comparing the result of an iterative process that
>> should converge to a final value?
> The ftoa calculation is such a process that could be useful to have it
> provide the same answers when compared across compilers, like for Emanuel.
> However, the input float values for the process should still be equal
> up to some precision for all environments, which is what he is trying to
> verify by comparing the logs.
This email has been checked for viruses by Avast antivirus software.
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
MinGW-users mailing list
This list observes the Etiquette found at
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
You may change your MinGW Account Options or unsubscribe at: