Re: [lmi] MinGW-w64 anomaly?

[Greg Chicares]

On 2016-12-27 18:24, Vadim Zeitlin wrote:
> On Tue, 27 Dec 2016 17:22:17 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Now, however, we're using C++11, which says [26.3.1/1] that <cfenv>
> GC> "defines the macros", seemingly without qualification, except that
> GC> [26.3.1/2] it "the same as Clause 7.6 of the C standard", which seems
> GC> to bring in the C99 "if and only if" qualification (depending on the
> GC> meaning of the word "same").
> GC> 
> GC> Of course, I'd prefer to define
> GC>  enum e_ieee754_rounding
> GC> -    {fe_tonearest  = 0x00
> GC> +    {fe_tonearest  = FE_TONEAREST
> GC> and so on, but I guess that's not guaranteed to work, whereas the way
> GC> you wrote it is reliably correct.

I just pushed a changeset that should accomplish that. It works for i386,
and I believe it'll work for x86_64 too.

>  To be honest, I've just copied the existing code from fend_rounding()

Now I've de-copied that part, to make the code simpler; and made a similar
change in the other rounding unit test.

> itself, but planned to do exactly the above in the future. Thinking about
> it again now, I realize that we indeed don't know the type of these values.
> But I think
> 
>       enum e_ieee754_rounding : decltype(FE_TONEAREST)
>               {fe_tonearest = FE_TONEAREST
>               ...
> 
> should always work, shouldn't it?

Thanks, I used that idea. If FE_TONEAREST is not defined by the implementation,
then lmi probably won't work anyway. We'll assume a lack of perversity such as:

#define FE_TONEAREST  false
#define FE_DOWNWARD   (unsigned short int)17
#define FE_UPWARD     -1L
#define FE_TOWARDZERO -4ULL

> GC> The questions I have are:
> GC>
> GC> - For x86_64, does gcc allow no other option than SSE?
> 
>  It does allow using -mfpmath=387, but, a bit surprisingly, it still uses
> at least some SSE instructions even then. E.g. consider this simplest
> possible example program:

Thanks for the example...

>  What I can definitely say is that using x87 in 64 bit code is very rare
> and I'd be surprised if doing it didn't result in at least some
> interoperability problems with other libraries (maybe including libm).

...and the warning.

> GC> - Whenever we set the SSE rounding direction, should we also set the
> GC> x87 rounding direction compatibly?
> 
>  I don't think so. If we're just calling fesetround() instead of playing
> games with hardware registers directly, the standard library must ensure
> that everything, including trigonometric calculations, works correctly and
> I have no reason to believe that libm has any bugs in this area.

Okay, maybe we can remove the duplicative call I added to one of the
rounding unit tests to make it work with the old x87 code, and to the
other only for parallelism--i.e.:

     fesetround(mode);
-    fenv_rounding(mode);

but I haven't tested such a change.

>  Moreover, I'm almost certain that libm doesn't use x87 fsin etc
> instructions that could be affected by the x87 rounding mode in the first
> place, but C functions which are supposed to be more accurate and maybe
> even faster than the built-in ones.

I should have offered a better example than trigonometric functions, for
which the x87 doesn't do as good a job as possible. But maybe the other
transcendental functions don't matter: e.g., we use expm1() and log1p(),
but as you say a conforming implementation must make them work correctly.

> GC> >  Should I do it, test it and submit it as a proper patch/pull request?
> GC> 
> GC> Yes, please.
> 
>  Will do once you commit your outstanding changes,

I'm done for now. It's probably a good idea to
  :%s/fe[gs]etround/std::&/gc
someday, but that's just part of replacing any such C99 stuff with C++11
std::stuff, which I think is part of your plan, so I'll leave that to you.