Re: [Mingw-users] msvcrt printf bug
Hi again, KHMan,
On 20-Jan-17 09:20, KHMan wrote:
> On 1/20/2017 12:07 PM, Emanuel Falkenauer wrote:
>> Hi KHMan,
>> Thank you for your well documented explanation - it shows how it could
>> be that my "stubbornness" is actually grounded in reality. :-) Gosh,
>> good Lord I never even knew about -Ofast! :-D
>> And I guess kudos also to the IEEE: these "standards bodies" are often
>> seen as stifling creativity, but in this case they're just invaluable:
>> I'd hate our clients reporting different results just because they'd be
>> running on AMDs!
>> All the best,
>> P.S. Your "(a+b != b+a) for floating point" example is excellent: that's
>> indeed the kind of "gymnastics" we often do to manage the floats'
>> inherent IMprecision.
> My memory failed me and I think I should correct the above. IIRC I
> tripped on a+(b+c) != (a+b)+c. I remembered well that I blundered,
> but did not recall correctly what I blundered on... It popped out
> of my slow neurons about an hour after I posted -- fast memory
> retrieval is not reliable. I'm not sure though what the IEEE
> standards say about a+b and b+a equivalence, if any.
> In any case, Agner Fog is a much better point of reference for
> these sort of things...
Don't worry, I'm sure everybody "in the know" understood: you need to
first add the small values so their SUM actually counts in the large
one, rather than adding them to the large one one by one only to be
rounded out without a trace... ;-)
I'm pretty sure IEEE says NOTHING about a+b v. b+a... but it sure (i.e.
hopefully!!) DOES standardize what should be the outcome in each case -
and that's all I need.
>> On 20-Jan-17 04:34, KHMan wrote:
>>> On 1/20/2017 9:53 AM, Emanuel Falkenauer wrote:
>>>> On 19-Jan-17 12:35, Peter Rockett wrote:
>>>> [snip snip]
>>>>> I think everybody (apart maybe from the OP) agrees how floating point
>>>>> numbers behave. Keith makes a good point about rounding. Can I toss in
>>>>> another feature that changing the compiler optimisation level often
>>>>> reorders instructions meaning that rounding errors accumulate in
>>>>> different ways. So changing the optimisation level often slightly
>>>>> changes the numerical answers. :-\
>>>> I agree that it could well (or even should?) be the case... but it's not
>>>> in my case - to my own pleasant surprise.
>>>> I can build with -O3 to get the most juice for releases, or with -O0 to
>>>> debug... my logs are still the same (spare for actual bugs). I even
>>>> compile with -mtune=native -march=native -mpopcnt -mmmx -mssse3 -msse4.2
>>>> (native: I'm on Xeons), although I doubt very much the Borland compiler
>>>> knows anything about those optimizations... and yet the latter's logs
>>>> are still identical to MinGW's.
>>>> Honestly it beats me as well... but I'm sure glad it's the case! :-)
>>> Since nobody has filled this in...
>>> In the past it has been pointed out to me that gcc by default
>>> respects the possibility that (a+b != b+a) for floating point, so
>>> it does not attempt those kinds of reordering. So one ought to get
>>> consistent results from the FPU.
>>> By default -O[0123s] is still math-strict . -Ofast, a host of
>>> other math options and some CPU-specific options break strictness
>>> for more speed. If -O[0123s] misbehaves, I guess it should be
>>> investigated as a potential bug.
>>> Agner Fog's manual 1, section 8  gives a table of optimizations
>>> performed, including floating point optimizations and many
>>> compilers including gcc and Borland. So it is likely that gcc did
>>> all optimizations while being math-strict.
>>>  https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
>>>  http://www.agner.org/optimize/
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: