This adds a test for GCC bug 90348 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348), using a test case extracted from our own sha256d64 test in crypto_tests.cpp, which was failing on some platforms.
This is based on top of #15983 to make sure the bug doesn't trigger (it does in some Travis configurations without it).
Looks like this only fails for the no-wallet build and win64 (not sure what that wine32 warning means):
Running tests: compilerbug_tests from test/compilerbug_tests.cpp
it looks like wine32 is missing, you should install it.
multiarch needs to be enabled first. as root, please
execute "dpkg --add-architecture i386 && apt-get update &&
apt-get install wine32"
Running 1 test case...
Test cases order is shuffled using seed: 1529978656
Entering test module "Bitcoin Core Test Suite"
test/compilerbug_tests.cpp(8): Entering test suite "compilerbug_tests"
test/compilerbug_tests.cpp(30): Entering test case "gccbug_90348"
test/compilerbug_tests.cpp(38): error: in "compilerbug_tests/gccbug_90348": check check_zero(in, i) has failed
test/compilerbug_tests.cpp(38): error: in "compilerbug_tests/gccbug_90348": check check_zero(in, i) has failed
test/compilerbug_tests.cpp(38): error: in "compilerbug_tests/gccbug_90348": check check_zero(in, i) has failed
test/compilerbug_tests.cpp(38): error: in "compilerbug_tests/gccbug_90348": check check_zero(in, i) has failed
test/compilerbug_tests.cpp(30): Leaving test case "gccbug_90348"; testing time: 53ms
test/compilerbug_tests.cpp(8): Leaving test suite "compilerbug_tests"; testing time: 53ms
Leaving test module "Bitcoin Core Test Suite"; testing time: 53ms
I guess that's expected; sanitizers break the bug (I think they automatically enable stack-reuse=none).
What about win32, linux32, bionic qt5 and the trusty build without sanitizers?
The trusty one could have a gcc that is old enough to not have this bug, but the others should fail, hmm
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
No conflicts as of last run.
@sipa :eyes: ^
utACK 9d269e1 (needs rebase)
I did some investigating using Compiler Explorer and the c test case from the GCC bug report to better understand what's happening here.
Using the flags produced by ./configure (master) on a Debian box (GCC 8.3.0):
-fstack-reuse=none -Wstack-protector -fstack-protector-all -Wall -Wextra -Wformat -Wvla -Wredundant-decls -Wno-unused-parameter -Wno-implicit-fallthrough -g -O2
I setup a test to compare the assembly produced with and without -fstack-reuse=none.
You can see my setup on Compiler Explorer here. The difference produced with and without -fstack-reuse on line 83:
< lea rdi, [rsp+3]
---
> lea rdi, [rsp+4]
As mentioned in the original bug report, the issue is seen on GCC 7, 8 and 9.
There hasn't been any activity in the last two weeks, so I went ahead to rebase and force push to the branch in your repo. Hope you don't mind.
Unless there are objections, this will be merged tomorrow.
Milestone
0.18.1