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

[Greg Chicares]

On 2018-03-22 02:16, Vadim Zeitlin wrote:
> On Wed, 21 Mar 2018 13:31:14 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> >  I did, using the latest master, i.e. 3d3e2b67916c72c7446f140f2f9864
> GC> > 56b1164b1e
> GC> > 
> GC> >         git checkout 3d3e2b6~ -- bourn_cast_test.cpp
> GC> 
> GC> I had expected that to give me a detached HEAD, but it didn't
> 
>  This is because "git checkout" is one of the most confusing Git commands
> because it does several apparently completely unrelated things (which are,
> in fact, related if you dive deep into Git implementation, but I definitely
> don't think it's a good reason for it to work like this -- nor does anybody
> else, AFAIK, but it's too late to change it now...). Without any paths, it
> just changes HEAD, i.e. changes the current branch (or puts you in the
> detached HEAD state), but with paths it updates their copies in the working
> tree to match the specified revision (or, to confuse people even more, the
> index) and does _not_ change HEAD.

Okay, it's a "DWIM" optimization. Thanks, at least now I understand
why it works this way.
> GC> I'm wondering the problem could be that debian's MinGW-w64 package
                   ^ whether
> GC> is missing some upstream fix. I'm using the latest:
> GC> 
> GC> # apt-get -s install g++-mingw-w64
> GC> Reading package lists... Done
> GC> Building dependency tree       
> GC> Reading state information... Done
> GC> g++-mingw-w64 is already the newest version (7.2.0-20+20.2).
> 
>  And I'm using i686-7.2.0-release-win32-sjlj-rt_v5-rev0.7z downloaded from
> SF, which seems to be pretty close, but somehow produces a much smaller
> binary which works differently.

That's exactly the compiler tarball that Kim's using:

https://lists.nongnu.org/archive/html/lmi/2018-03/msg00017.html
| cd /cache_for_lmi/downloads && echo "f34ff6eca4aa7a645f60c977b107c5d2 
| *i686-7.2.0-release-win32-sjlj-rt_v5-rev0.7z" | md5sum --check
| i686-7.2.0-release-win32-sjlj-rt_v5-rev0.7z: OK

so she would presumably see exactly the same behavior you see.

That would be troubling, as she's preparing a production release
right now, except that:

(1) As far as we know, this problem arises only in a unit test,
and only when converting negative zero between types float and
long double, and even then the anomaly is that negative zero
becomes positive zero. Yet lmi defines no variable of type float
(although it has some library-type code that would handle floats
correctly, and standalone unit tests that test such code). And,
while we've occasionally seen "-0" on illustrations, end users
perceive that as anomalous, and we don't actually need to
distinguish negative from positive zero in formatted values.

(2) Apparently everything just works for the compiler tarball
above, and the observed unit-test anomaly is seen only with
debian's package:
  # apt-get -s install g++-mingw-w64
  g++-mingw-w64 is already the newest version (7.2.0-20+20.2).

I don't see any reason to hold up the release for this.

Nevertheless, it's still a concern until we find the ultimate
cause. If it turns out that they've simply implemented
std::signbit() in a way that's fragile under optimization,
then we don't have to worry about it.