Re: [lmi] MinGW-w64 anomaly?

[Greg Chicares]

On 2016-12-21 14:23, Vadim Zeitlin wrote:
> On Wed, 21 Dec 2016 02:09:09 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> Still, AFAICT this is the relevant change:
> GC> 
> GC> ----------------------------------8<----------------------------------
> GC> -#else  // !(defined __GNUC__ && defined LMI_X86)
> GC> -
> GC> -// The round_X functions below work with any real_type-to-integer_type.
> GC> -// Compilers that provide rint() may have optimized it (or you can
> GC> -// provide a fast implementation yourself).
> GC> -
> GC> -template<typename RealType>
> GC> -inline RealType perform_rint(RealType r)
> GC> -{
> GC> -#if defined LMI_HAVE_RINT
> GC> -    return rint(r);
> GC> -#else  // !defined LMI_HAVE_RINT
> GC> -    throw std::logic_error("rint() not defined.");
> GC> -#endif // !defined LMI_HAVE_RINT
> GC> -}
> GC> -
> GC> -#endif // !(defined __GNUC__ && defined LMI_X86)
> GC> ---------------------------------->8----------------------------------
> GC> 
> GC> and I'm not quite sure how replacing a cover function that simply
> GC> delegated to C99 rint() with direct calls to std::rint() could
> GC> make a difference
> 
>  No, sorry, this is not the right change. The change in the commit
> 54d250300e367b33af5719c40087e5536640fa1f which really broke it was to
> remove
> 
>       template<typename RealType>
>       inline RealType perform_rint(RealType r)
>       {
>           __asm__ ("frndint" : "=t" (r) : "0" (r));
>           return r;
>       }
> 
> and replace the calls to it with std::rint(). The old version worked
> because it used x87 instruction which was governed by the x87 rounding
> mode. The new version doesn't work because it uses the SSE instruction
> (some _mm_cvtsd_xxx I think), but the rounding mode is not set for SSE
> (this would require modifying MXCSR register instead of the x87 control
> word).

Now I'm confused. There's some sort of breakage here--with all x86_64
builds, IIRC. But what is actually broken? Is it that lmi fails to
compile? Or that some unit-test program fails to compile? Or only that
some unit test that formerly passed now doesn't?

It sounds like it's the last of those--in which case maybe there is
no real problem. I.e., if we have some code that's supposed to behave
in a certain way when the rounding direction is set (in the x87 control
word or in some MMX register, as appropriate), and we test that code by
manipulating the x87 control word only, then the test is invalid for
non-87 code, right?