Web lists-archives.com

Re: [Mingw-users] msvcrt printf bug




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.

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/
>


------------------------------------------------------------------------------
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