Re: [lmi] MinGW-w64 anomaly?

[Vadim Zeitlin]

On Sun, 25 Dec 2016 12:17:26 +0000 Greg Chicares <address@hidden> wrote:

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

 It's the latter, as I wrote before:

        round_to_test.cpp compiles just fine, but fails with 126 errors
        under 64 bit Linux, which were not present before

(see http://lists.nongnu.org/archive/html/lmi/2016-12/msg00053.html)

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

 Well, yes, but we still want (all) test(s) to pass, ideally. Of course, we
could just disable the test instead of fixing it and knowing (now, I didn't
know this when I wrote the original bug report) that we don't actually ever
change the rounding mode in the main program, maybe it's acceptable. But I
think it would still be better to fix the code changing the rounding mode
as previously discussed and let the test continue to pass.

 Regards,
VZ