Re: [lmi] MinGW-w64 roundl() anomaly

[Vadim Zeitlin]

On Sat, 17 Dec 2016 00:40:16 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-12-16 01:39, Vadim Zeitlin wrote:
GC> > On Thu, 15 Dec 2016 16:02:54 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC> Because this function is supposed to round to nearest always,
GC> > 
GC> >  Yes, http://en.cppreference.com/w/cpp/numeric/math/round confirms it:
GC> > 
GC> >   Computes the nearest integer value to arg (in floating-point
GC> >   format), rounding halfway cases away from zero, regardless of the
GC> >   current rounding mode.
GC> 
GC> I can never remember which of the popular sites is more untrustworthy:
GC>   http://stackoverflow.com/questions/6520052/whats-wrong-with-cplusplus-com

 I think even cplusplus.com is decent now, but I don't know really use it,
so I could be wrong. cppreference.com is definitely excellent (maybe not
perfect, but what is...) however and I do use it a lot.

GC> so I confirmed it here:
GC> 
GC> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

 Sure, primary sources trump everything, but links work better with
cppreference.com

GC> > [...] the implementation in glibc (I think this is the one which
GC> > is used for i386, although it's hard to be sure with the number of aliases
GC> > and indirections in glibc sources):
GC> > 
GC> > 
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/ldbl-96/s_roundl.c
GC> > 
GC> >  FWIW we could probably use the version above as a workaround for now.
GC> 
GC> That sounds like our best idea,

 OK, but I won't do anything as you said that you preferred to work on this
on your own. Please let me know if you change your mind.

GC> BTW, there's some interesting discussion here:
GC> 
GC> http://blog.frama-c.com/index.php?post/2013/05/02/nearbyintf1
GC> http://blog.frama-c.com/index.php?post/2013/05/03/nearbyintf2
GC> http://blog.frama-c.com/index.php?post/2013/05/04/nearbyintf3

 By following a link from there I found about a (relatively recent, added
in 2009/4.5) gcc option -fexcess-precision=standard that I hadn't known
about (see https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html if you
didn't neither).

 It seemed like it would be a pretty good idea to turn it on, but then I
decided to test it and found that, for some inexplicable reason, this
option is only implemented for C but not C++. So to systematically avoid
problems inherent to the use of different precision in x87 and in memory in
C++ code the only available option remains -ffloat-store which is not
completely universal and also has, AFAICS, serious negative performance
implications.

 So, finally, I didn't really learn anything new today and by far the best
option remains just switching to using SSE and not ever having to deal with
x87 again.

 Regards,
VZ