[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lmi] Treacherous gcc-10 defect [Was: ICE with '-fno-omit-frame-pointer'
From: |
Greg Chicares |
Subject: |
[lmi] Treacherous gcc-10 defect [Was: ICE with '-fno-omit-frame-pointer', 64-bit msw] |
Date: |
Thu, 10 Dec 2020 23:14:10 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 |
On 12/10/20 1:26 PM, Greg Chicares wrote:
[...a certain '-fno-omit-frame-pointer' testcase...]
> succeeds with gcc-10, but fails with gcc-8. Accordingly, I'll
> restrict the '-fomit-frame-pointer' workaround to
> x86_64-w64-mingw32-gcc-8.x only, so that it doesn't propagate
> to gcc-10 builds when we upgrade the compiler (very soon).
TL;DR: x86_64-w64-mingw32 gcc-10 seems to need '-fomit-frame-pointer'.
With gcc-8, '-fno-omit-frame-pointer' gave an ICE. With gcc-10, the
failure is more insidious: the unit test below compiles without any
warning, but gives incorrect results.
[This failure somewhat resembles this older report:
https://lists.nongnu.org/archive/html/lmi/2019-04/msg00053.html
| a few [unit tests] fail with 64-bit gcc-7, and conversion between
| double and std::string seems to be the problem:
|
| numeric_io_test
| 25 test errors detected; 453 tests succeeded
but the resemblance seems superficial.]
Earlier today I ran this command in a chroot with MinGW-w64 gcc-10:
make raze; ./nychthemeral_test.sh
['raze' is a brutally emphatic 'clean' target]
and observed the following output (only with gcc-10; not with
MinGW-w64 gcc-8).
LMI_TRIPLET = "x86_64-w64-mingw32"
Production system built--ready to start GUI test in another session.
???? test failed: '0.666666666666667' == '0'
???? test failed: '0.666666666666667' == '0'
???? test failed: '0.666666666666667' == '0'
???? test failed: '0.666666666666667' == '0'
???? test failed: '0.666666666666667' == '0'
???? test failed: '0.666666666666667' == '0'
???? 6 test errors detected; 472 tests succeeded
???? returning with error code 201
????
???? errors detected; see stdout for details
The failure arose here:
test_interconvertibility(y, "0.666666666666667" , __FILE__, __LINE__);
and, at a wild guess, it looks as though the compiler treated the
expression "(2.0 / 3.0)" as integral. An alternative and wilder guess
is that '-fno-omit-frame-pointer' causes the error, but generating
incorrect code without any diagnostic seemed so implausible that I
investigated the problem laboriously, as follows.
I wrote this throwaway script:
/opt/lmi/src/lmi[0]$cat test.sh
#!/bin/sh
make clean
make $coefficiency unit_tests unit_test_targets=numeric_io_test.exe 2>&1
>eraseme
<eraseme grep --quiet '!!!!'
exit $?
...to use with 'git bisect':
/opt/lmi/src/lmi[0]$git bisect start
/opt/lmi/src/lmi[0]$git bisect bad
/opt/lmi/src/lmi[0]$git bisect good d0bc2d15
Bisecting: 30 revisions left to test after this (roughly 5 steps)
running post-checkout hook...
...post-checkout hook finished.
[2acf38516935f940b146176d767fe3d521c0a400] Let "PolicyForm" vary by state for
product 'sample'
/opt/lmi/src/lmi[0]$git bisect run ./test.sh
...
/opt/lmi/src/lmi[0]$git bisect log
# first bad commit: [e13315d23053535a51bf00574069a8236bf0d06d] Use
'-fomit-frame-pointer' only as a last resort
Here's a manual demonstration:
/opt/lmi/src/lmi[0]$git status
On branch master
Your branch is up to date with 'origin/master'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
test.sh
nothing added to commit but untracked files present (use "git add" to track)
/opt/lmi/src/lmi[0]$LMI_COMPILER=gcc ; LMI_TRIPLET=x86_64-w64-mingw32 ; .
/opt/lmi/src/lmi/set_toolchain.sh
/opt/lmi/src/lmi[0]$make clean; make $coefficiency unit_tests
unit_test_targets=numeric_io_test.exe 2>&1 |grep '!!!!\|????'
rm --force --recursive /opt/lmi/gcc_x86_64-w64-mingw32/build/ship
???? test failed: '0.666666666666667' == '0'
???? test failed: '0.666666666666667' == '0'
???? test failed: '0.666666666666667' == '0'
???? test failed: '0.666666666666667' == '0'
???? test failed: '0.666666666666667' == '0'
???? test failed: '0.666666666666667' == '0'
???? 6 test errors detected; 472 tests succeeded
???? returning with error code 201
????
???? errors detected; see stdout for details
/opt/lmi/src/lmi[0]$make clean; make $coefficiency unit_tests
unit_test_targets=numeric_io_test.exe tutelary_flag='-fomit-frame-pointer' 2>&1
|grep '!!!!\|????'
rm --force --recursive /opt/lmi/gcc_x86_64-w64-mingw32/build/ship
!!!! no errors detected
/opt/lmi/src/lmi[0]$make clean; make $coefficiency unit_tests
unit_test_targets=numeric_io_test.exe tutelary_flag='-fno-omit-frame-pointer'
2>&1 |grep '!!!!\|????'
rm --force --recursive /opt/lmi/gcc_x86_64-w64-mingw32/build/ship
???? test failed: '0.666666666666667' == '0'
???? test failed: '0.666666666666667' == '0'
???? test failed: '0.666666666666667' == '0'
???? test failed: '0.666666666666667' == '0'
???? test failed: '0.666666666666667' == '0'
???? test failed: '0.666666666666667' == '0'
???? 6 test errors detected; 472 tests succeeded
???? returning with error code 201
????
???? errors detected; see stdout for details
Just to make sure, I upgraded this chroot, which changed MinGW-w64:
Preparing to unpack
.../061-g++-mingw-w64-x86-64-win32_10.2.0-19+24+b1_amd64.deb ...
Unpacking g++-mingw-w64-x86-64-win32 (10.2.0-19+24+b1) over (10.1.0-3+23) ...
Preparing to unpack
.../062-gcc-mingw-w64-x86-64-win32_10.2.0-19+24+b1_amd64.deb ...
Unpacking gcc-mingw-w64-x86-64-win32 (10.2.0-19+24+b1) over (10.1.0-3+23) ...
Preparing to unpack
.../063-gcc-mingw-w64-x86-64-win32-runtime_10.2.0-19+24+b1_amd64.deb ...
Unpacking gcc-mingw-w64-x86-64-win32-runtime (10.2.0-19+24+b1) over
(10.1.0-3+23) ...
/opt/lmi/src/lmi[0]$x86_64-w64-mingw32-gcc --version
x86_64-w64-mingw32-gcc (GCC) 10-win32 20201125
...and repeated the tests above, with the same outcome.
Soon I'll push a commit to countervail this lmi commit:
e13315d2 Use '-fomit-frame-pointer' only as a last resort
which made this gcc-10 defect manifest.