Re: [lmi] Treacherous gcc-10 defect

[Greg Chicares]

On 3/1/21 11:56 AM, Vadim Zeitlin wrote:
> On Sat, 19 Dec 2020 20:46:20 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> On 12/19/20 7:37 PM, Vadim Zeitlin wrote:
> GC> [...]
> GC> > On Thu, 10 Dec 2020 23:14:10 +0000 Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
> GC> > 
> GC> > GC> On 12/10/20 1:26 PM, Greg Chicares wrote:
[...]
> GC> > GC> TL;DR: x86_64-w64-mingw32 gcc-10 seems to need 
> '-fomit-frame-pointer'.
> GC> > 
> GC> >  This looks extraordinarily bad. I couldn't find any existing bug for 
> this
> GC> > in gcc bugzilla, do you think it would be worth spending time on 
> providing
> GC> > the minimal reproducible test case and reporting it?
> GC> 
> GC> Yes--provided, of course, that it's not too difficult.
> 
>  Bad news is that it was quite difficult

Sorry about that...but thanks for persevering.

> Good news is that not only we've
> managed to produce a reasonable test case for it, but that the bug has just
> been fixed in gcc, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234

Wow.

> GC> This does seem to be a serious compiler defect, which greatly
> GC> resembles one that they believe they've just recently fixed.
> 
>  It turns out that this was a completely different and, arguably, more
> serious problem
I say again, wow--it's probably been wrong since gcc first
implemented SEH, which would have been about twenty years ago.

We'll use it for gcc-11 of course, but not for gcc-10 unless
we can devise a good way to detect the full version. As of a few
minutes ago, in my most up-to-date chroot, I see:
  #apt-get upgrade g++-mingw-w64
  ...
  g++-mingw-w64 is already the newest version (10.2.1-6+24.1).
but the documented flags report only the major version:

$i686-w64-mingw32-g++ -dumpversion 
10-win32

$i686-w64-mingw32-g++ -dumpfullversion
10-win32

$i686-w64-mingw32-gcc --version
i686-w64-mingw32-gcc (GCC) 10-win32 20210110 [...]

and likewise for x86_64.

Here's an idea that is not necessarily exact (it gives
  (the version of the compiler used to compile the compiler)
rather than
  (the version of the compiler)
) but it seems to be the best we can do with any flags:

/opt/lmi/src/lmi[0]$i686-w64-mingw32-gcc -v --version 2>&1 |grep ompiled.by
        compiled by GNU C version 10.2.1 20210110, GMP version ...
/opt/lmi/src/lmi[0]$x86_64-w64-mingw32-gcc -v --version 2>&1 |grep ompiled.by 
        compiled by GNU C version 10.2.1 20210110, GMP version ...

though I don't see an appealing way to filter it.
This looks nasty:

x86_64-w64-mingw32-gcc -v --version 2>&1 |grep -i compiled.by | sed 
-e's/,.*$//' -e's/^.*version //' -e's/\([0-9][0-9]*\.[0-9]*\.*[0-9]*\).*/\1/'

and this is a little less nasty but seems more fragile:

x86_64-w64-mingw32-gcc -v --version 2>&1 |grep -i compiled.by | sed 
-e's/,.*$//' -e's/^.*version //' -e's/ .*//'

though both do work for 10.2.1 and 8.3.0 .

I suppose we could compile a program that would emit the gcc
version as stored in predefined macros
  __GNUC__
  __GNUC_MINOR__
  __GNUC_PATCHLEVEL__
or, better...

$x86_64-w64-mingw32-g++  -x c++ -dM -E -std=c++11 - < /dev/null |grep __GNUC_
#define __GNUC__ 10
#define __GNUC_PATCHLEVEL__ 0
#define __GNUC_STDC_INLINE__ 1
#define __GNUC_MINOR__ 2

...which works for 8.3.0 as well.

This seems like too much labor when '-dumpfullversion' should Just Work.