Web lists-archives.com

Re: [Mingw-users] msvcrt printf bug




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,
>
> Emanuel
>
> 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...

> 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 [1]. -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 [2] 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.
>>
>> [1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
>> [2] http://www.agner.org/optimize/
>>


-- 
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


------------------------------------------------------------------------------
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
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe