[lmi] ICE with '-fno-omit-frame-pointer', 64-bit msw [Was: Segfault in wxGrid]

[Greg Chicares]

On 2016-07-06 23:21, Greg Chicares wrote:
> On 2016-06-21 23:21, Vadim Zeitlin wrote:
>> On Tue, 21 Jun 2016 20:08:19 +0000 Greg Chicares <address@hidden> wrote:
> 
> [...backtrace much more useful in an archived year-old build...]
> 
>> GC> BTW, that version gives a deeper trace of the call stack (below), which
>> GC> makes me wonder whether we've removed some useful debugging option.
>> 
>>  I think this was a side effect of compiler upgrade, quoting
>> https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/Optimize-Options.html
>> 
>> -fomit-frame-pointer
[...]
>> Without the frame pointer (EBP) and without any extra auxiliary information
>> (such as saved in the special FPO section of debug information files by
>> Microsoft tools) it becomes impossible to reconstruct the stack, in
>> general, and I'm afraid this is what might happen here.
> 
> Confirmed. Rebuilding with commit 50b1e9d154014e2f75881cfcce0c4b097dfd0337
> to restore '-fno-omit-frame-pointer' gives us the deeper stack trace that
> we want.
> 
> For the record:
> 
> (1) [...] apparently MinGW-w64's 32-bit toolchains are configured with
> '-momit-leaf-frame-pointer'
> 
[...aside from making stack traces available,]
> (2) Omitting the frame pointer gains no benefit for lmi according to
> the following measurements [...of execution time...]:
[ archived at https://lists.nongnu.org/archive/html/lmi/2016-07/msg00008.html ]

We've been using '-fno-omit-frame-pointer' since 2016. However, we
may have to inhibit it for x86_64-w64-mingw32-gcc version 8.2.0
due to a compiler defect:

/opt/lmi/src/lmi[0]$x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/8.2-win32/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir='/usr/include' --mandir='/usr/share/man' 
--infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir='/usr/lib/x86_64-linux-gnu' 
--libexecdir='/usr/lib/x86_64-linux-gnu' --disable-maintainer-mode 
--disable-dependency-tracking --prefix=/usr --enable-shared --enable-static 
--disable-multilib --with-system-zlib --libexecdir=/usr/lib 
--without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes 
--with-tune=generic --with-headers=/usr/x86_64-w64-mingw32/include 
--enable-version-specific-runtime-libs --enable-fully-dynamic-string 
--enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto 
--with-plugin-ld --enable-threads=win32 --program-suffix=-win32 
--program-prefix=x86_64-w64-mingw32- --target=x86_64-w64-mingw32 
--with-as=/usr/bin/x86_64-w64-mingw32-as 
--with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic
Thread model: win32
gcc version 8.2-win32 20190215 (GCC)

/opt/lmi/src/lmi[0]$x86_64-w64-mingw32-g++ -c -I /opt/lmi/src/lmi -I 
/opt/lmi/third_party/include  -I /opt/lmi/x86_64-w64-mingw32/local/include 
-std=c++17 -Werror -ggdb -O2 -fno-omit-frame-pointer    
/opt/lmi/src/lmi/accountvalue.cpp -oaccountvalue.o             
during RTL pass: final
/opt/lmi/src/lmi/accountvalue.cpp: In member function 'void 
AccountValue::IncrementEOM(int, int, double, double)':
/opt/lmi/src/lmi/accountvalue.cpp:1062:13: internal compiler error: in 
based_loc_descr, at dwarf2out.c:14318
     {return;}
             ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

/opt/lmi/src/lmi[1]$x86_64-w64-mingw32-g++ -c -I /opt/lmi/src/lmi -I 
/opt/lmi/third_party/include  -I /opt/lmi/x86_64-w64-mingw32/local/include 
-std=c++17 -Werror -ggdb -O2 /opt/lmi/src/lmi/accountvalue.cpp -oaccountvalue.o 
/opt/lmi/src/lmi[0]$
                 ^ returns zero, indicating success
Thus, removing '-fno-omit-frame-pointer' works around this compiler error,
as suggested here:

  https://github.com/msys2/MINGW-packages/issues/4409#issuecomment-463602250
| Still seeing this problem. Proceeding by removing "-fno-emit-frame-pointer" 
as a work around.

The testcase above (which has of course been stripped way down) succeeds
in my gcc-7.3.0 chroot.

This gcc-8.1 defect report:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593
seems to be relevant, although the diagnostic I see refers to a
different line in 'based_loc_descr'.