[lmi] lmi tests and MSVC (was: Don't initialize constexpr variable with std::ldexp())

[Vadim Zeitlin]

 Hello,

 I'm resurrecting a very old thread which might still be relevant -- but
please let me know if it is, and if I should spend more time on this, or
not really any longer.

On Mon, 24 Apr 2017 22:19:46 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 2017-04-24 16:51, Vadim Zeitlin wrote:
GC> > On Mon, 24 Apr 2017 16:37:55 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
GC> > 
GC> > GC> On 2017-04-24 16:16, Vadim Zeitlin wrote:
GC> > GC> > On Mon, 24 Apr 2017 15:25:48 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
GC> > GC> > 
GC> > GC> > GC> With this patch, does the 'bourn_cast_test.cpp' unit test 
compile and
GC> > GC> > GC> report zero errors with these other two compilers?
GC> > GC> > 
GC> > GC> >  Yes, the test passes with both gcc and clang (and sorry, I meant 
to say
GC> > GC> > this in my previous message but after rereading it I see that I 
forgot to
GC> > GC> > include it).
GC> > GC> 
GC> > GC> I think you meant
GC> > GC> - the test passes with both gcc and clang
GC> > GC> + the test passes with both msvc and clang
GC> > 
GC> >  No, for once I did write what I meant: the test (still) passes with gcc
GC> > and (now also) passes with clang. I didn't test with MSVC because I didn't
GC> > think you'd be interested in neither the result of the test nor,
GC> > especially, in fixing any possible problems with it, but I could do if
GC> > you'd like to.
GC> 
GC> As far as I can remember, lmi builds with MSVC except for 'any_member',
GC> which it defectively refuses to compile--and which can't be made to work
GC> except by replacing a great deal of template goodness with macro badness.
GC> (Paragraph break so that you can explain how poorly I've remembered....)
GC> 
GC> It would be good to know whether at least lmi's unit tests (except for
GC> 'any_member_test') build and report zero errors for msvc. I'd especially
GC> like to know whether the very recent 'bourn_cast_test' does.

 I still don't have a build system allowing me to build all the lmi tests
with MSVC, but I tried at least this one (even though it's not so recent
any more) and it fails with the following error:

???? uncaught exception: std::runtime_error: Cast would transgress upper limit.

This happens in test_same<long long int> on the line

        T imax = bourn_cast<T>(max);

because "limit" and "from" are both equal to 9.2233720368547758e+18 (or
43e0000000000000 as IEEE-754 binary, i.e. 1b63) inside bourn_cast(). I
don't really understand why should we throw in case of equality nor why are
they equal only with MSVC but not the other compilers. I could look at this
in more details but I wanted to ask first just in case the problem is
already immediately clear to you?

 FWIW there are also several compilation warnings in this test with MSVC:

bourn_cast_test.cpp(473,36): warning C4305: 'initializing': truncation from 
'const unsigned __int64' to 'float'
bourn_cast_test.cpp(90,9): warning C4805: '==': unsafe mix of type 'bool' and 
type 'const long double' in operation
bourn_cast_test.cpp(737): message : see reference to function template 
instantiation 'void test_same<bool>(const char *,int)' being compiled
bourn_cast_test.cpp(89,41): warning C4805: '==': unsafe mix of type 'bool' and 
type 'long double' in operation
bourn_cast_test.cpp(166,1): warning C4245: 'initializing': conversion from 
'int' to 'CFrom', signed/unsigned mismatch
bourn_cast_test.cpp(780): message : see reference to function template 
instantiation 'void test_signednesses<true,false>(const char *,int)' being 
compiled
bourn_cast_test.cpp(167,1): warning C4245: 'initializing': conversion from 
'int' to 'IFrom', signed/unsigned mismatch
bourn_cast_test.cpp(168,1): warning C4245: 'initializing': conversion from 
'__int64' to 'LFrom', signed/unsigned mismatch
bourn_cast_test.cpp(170,1): warning C4245: 'initializing': conversion from 
'int' to 'CTo', signed/unsigned mismatch
bourn_cast_test.cpp(784): message : see reference to function template 
instantiation 'void test_signednesses<false,true>(const char *,int)' being 
compiled
bourn_cast_test.cpp(171,1): warning C4245: 'initializing': conversion from 
'int' to 'ITo', signed/unsigned mismatch
bourn_cast_test.cpp(172,1): warning C4245: 'initializing': conversion from 
'__int64' to 'LTo', signed/unsigned mismatch

but they look mostly harmless (even though definitely annoying).


GC> BTW, does LMI_MSVCRT serve any purpose any more? It's used only in
GC> 'numeric_io*', to work around printf() problems in the msw system C RTL
GC> like missing support for "%Lf" and formatting infinity as "1.#INF". The
GC> mingw* toolchains work around that with libmingwex. Does msvc now use an
GC> updated C RTL that doesn't have these defects, so that these LMI_MSVCRT
GC> workarounds can be expunged?

 I wanted to check this one as well, but numeric_io_test.cpp currently
fails even with LMI_MSVCRT defined:

???? test failed:   '15' == '12'
[file numeric_io_test.cpp, line 141]

???? test failed:   '15' == '16'
[file numeric_io_test.cpp, line 174]
Conversions:
  2/3, lmi  : 1.032e-05 s mean;          9 us least of 970 runs
  inf, lmi  : 5.285e-06 s mean;          4 us least of 1893 runs

???? 2 test errors detected; 441 tests succeeded

Again, it doesn't seem immediately obvious to me what is wrong here and I
could try to find out if you think this would be useful.

 But, just to check, I've tried removing LMI_MSVCRT definition from
config.hpp and it seems like it's still useful because without it I also
get

???? uncaught exception: std::invalid_argument: Attempt to convert string 
'i.nf' from type class std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> > to type double found 
nothing valid to convert.

towards the end. As you can see, the result of sprintf("%#.*f", 0, inf)
with MSVC is "i.nf" which seems weird but OTOH I have no idea what is the
output supposed to be when the "#" flag is used with infinity and precision
of zero. FWIW using just "%f" would output "inf", as expected (and not
"1.#INF" as before) with the currently supported MSVC versions, so the
current workaround for LMI_MSVCRT in numeric_io_cast.hpp is certainly
useless and at least some of those in numeric_io_traits.cpp probably are
too, but it seems like we still need to do something special for it. Again,
I could look at this further and maybe propose a patch if you think it's
worth doing this -- just please let me know.

 Thanks,
VZ

pgp6jUT1PxBcW.pgp
Description: PGP signature