Re: [lmi] Fwd: How did this unit test fail?

[Vadim Zeitlin]

On Thu, 22 Mar 2018 19:18:15 +0000 Greg Chicares <address@hidden> wrote:

[...compiler output changes depending on the warning options used...]
GC> Fascinating.

 Turns out this was nothing at all in comparison with what came later: the
output also changes depending on the input file path being used. I.e.

        % i686-w64-mingw32-g++ -c -std=c++17 -Wnonnull -Woverloaded-virtual -O2 
tmp/foo.cpp

and

        % mv tmp/foo.cpp .
        % i686-w64-mingw32-g++ -c -std=c++17 -Wnonnull -Woverloaded-virtual -O2 
foo.cpp

produce different object files (the former one is good, the latter one is
broken).

 So this is clearly a bug in gcc, although I don't know if it's a "real"
bug or some weird miscompilation of Debian MinGW package or a result of one
of Debian patches -- although I don't see anything remotely relevant in
https://anonscm.debian.org/cgit/collab-maint/gcc-mingw-w64.git/tree/debian/patches
OTOH I can't reproduce the problem neither with the native Debian gcc 7 nor
with MinGW-w64 gcc 7 under MSW.

 For now I've opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091 but
I'm not sure if anybody is going to look at it, the bug report seems far
too crazy to be real and, to be honest, I'd personally probably skip it if
I got something like this, thinking that it's due to gremlins on the
reporter machine... If it indeed doesn't get any attention, I might try
building the compiler myself from Debian sources and see if I can manage to
debug it: of course, understanding how gcc optimizer works is way beyond my
abilities, but I might be able to find where exactly the execution of the
program with and without the warning options diverge.

 In the meanwhile, one workaround I may report is that removing the use of
"constexpr" from bourn_cast.hpp definitely avoids the problem. Considering
that this is required for building with clang anyhow because it (correctly,
AFAICS) disallows the use of non-constexpr lmi::TypeInfo and
std::ostringstream classes in a constexpr function, perhaps we should do
this just to make sure to avoid the problem? OTOH as long as the official
releases are only built using MinGW-w64 under MSW and not the Debian
cross-compiler, it probably doesn't matter much, as the former is not
affected by this problem.

 Sorry for the continued lack of any results, but this problem is really
baffling.

VZ