This has never worked with any of the mingw-w64 compilers we use, and the -O0 is causing issues for builders applying spectre mitigations (see IRC logs).
Recent discussion on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458 would also indicate that this should just not be used on Windows.
This has never worked with any of the mingw-w64 compilers we use, and
the -O0 is causing issues for builders applying spectre mitigations.
Recent discussion on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458
also indicates that this should just not be used on Windows.
872 | - AX_CHECK_COMPILE_FLAG([-fstack-clash-protection],[HARDENED_CXXFLAGS="$HARDENED_CXXFLAGS -fstack-clash-protection"],[],["-O0"], 873 | - [AC_LANG_SOURCE([[class D {public: unsigned char buf[32768];}; int main() {D d; return 0;}]])]) 874 | + case $host in 875 | + *mingw*) 876 | + dnl stack-clash-protection doesn't currently work, and likely should just be skipped for Windows. 877 | + dnl See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458 for more details.
How does it contradict it? The two Bugzilla comments say that Windows has it's own mechanisms to handle this (and has done since day #1), hence the -fstack-clash-protection option would seem pointless, and should either be a NOP, or potentially throw an error when being applied to Windows builds.
Re-reading again. That makes sense now.
<!--9cd9c72976c961c55c7acef8f6ba82cd-->
Concept and code review ACK (but untested) 7b3434f8002d1a8cf0dbd0a0caef28e783b1efd8
<!--a722867cd34abeea1fadc8d60700f111-->
ACK 7b3434f8002d1a8cf0dbd0a0caef28e783b1efd8, I've verified that this change does not affect builds for HOST=x86_64-w64-mingw32 by comparing sizes of the output *.exe files.