[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lmi] lmi tests and MSVC (was: Don't initialize constexpr variable with
From: |
Vadim Zeitlin |
Subject: |
[lmi] lmi tests and MSVC (was: Don't initialize constexpr variable with std::ldexp()) |
Date: |
Sun, 19 Feb 2023 01:20:21 +0100 |
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
- [lmi] lmi tests and MSVC (was: Don't initialize constexpr variable with std::ldexp()),
Vadim Zeitlin <=