Re: [lmi] Treacherous gcc-10 defect

[Greg Chicares]

On 12/19/20 7:37 PM, Vadim Zeitlin wrote:
[...]
> On Thu, 10 Dec 2020 23:14:10 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> On 12/10/20 1:26 PM, Greg Chicares wrote:
> GC> [...a certain '-fno-omit-frame-pointer' testcase...]
> GC> > succeeds with gcc-10, but fails with gcc-8. Accordingly, I'll
> GC> > restrict the '-fomit-frame-pointer' workaround to
> GC> > x86_64-w64-mingw32-gcc-8.x only, so that it doesn't propagate
> GC> > to gcc-10 builds when we upgrade the compiler (very soon).
> GC> 
> GC> TL;DR: x86_64-w64-mingw32 gcc-10 seems to need '-fomit-frame-pointer'.
> 
>  This looks extraordinarily bad. I couldn't find any existing bug for this
> in gcc bugzilla, do you think it would be worth spending time on providing
> the minimal reproducible test case and reporting it?

Yes--provided, of course, that it's not too difficult. This
does seem to be a serious compiler defect, which greatly
resembles one that they believe they've just recently fixed.

And AFAICT they've still kept '-fomit-frame-pointer' as the
default for x86_64-w64-mingw32, making it less likely that
anyone else will raise this issue. But, again AFAICT, this
option was a kludge to get a fifth general-purpose register
on 1980s hardware, so it's goofy to require it now--it
smells like a deep problem with gcc.

[...]
> 4. Yet something does change the value of xmm6 in the build using
>    -fno-omit-frame-pointer between the two calls because it's clearly wrong
>    when the function is called again (it's not actually 0, but 4.94066e-324
>    which is less random than it might appear because it corresponds to the
>    IEEE-754 64-bit double value of exactly 1). I couldn't hunt down where
>    exactly is it being changed yet, but I think I should be able to, if I
>    spend more time on this. The problem is that I'm not sure if it's going
>    to be really useful, producing a minimal example reproducing the problem
>    would probably be more so. But it still would take quite some time. Do
>    you think it would be useful to spend it on this?

As for lmi...we want to use x86_64-w64-mingw32 in production,
but we do have a workaround, so there's no (known) problem
that affects us now, and it's not important to understand
exactly how this lmi example fails. What would be really
valuable is a minimal standalone test case (which doesn't
need to pertain directly to the observed lmi failure).