build: move -fstack-reuse=none to CORE_CXXFLAGS
#28672
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. |
I viewed it "confusing" in the same way while working on CMake-based build system. Concept ACK. |
|
Should we also consider any of other related bugs mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111843? |
This is not a hardening specific flag, it should be used at all times, regardless of if hardening is enabled or not. Note that this was still the case here, but having this exist in the hardening flags is confusing, and may lead someone to move it inside one of the `use_hardening` blocks, where it would become unused, with `--disable-hardening`.
40350b9 to
8cfa22a
Compare
I've switched to linking to the meta issue, over a specific bug report, but I'm not sure what else you're suggesting to do. |
|
ACK 8cfa22a. Agree it's confusing as-is and this better matches the intent. |
Guix builds (on x86_64)
|
8cfa22a build: move -fstack-reuse=none to CORE_CXXFLAGS (fanquake) Pull request description: This is not a hardening specific flag, it should be used at all times, regardless of if hardening is enabled or not. Note that this was still the case here, but having this exist in the hardening flags is confusing, and may lead someone to move it inside one of the `use_hardening` blocks, where it would become unused, with `--disable-hardening`. Noticed while reviewing hebasto#32 (comment). ACKs for top commit: theuni: ACK 8cfa22a. Agree it's confusing as-is and this better matches the intent. hebasto: ACK 8cfa22a luke-jr: utACK 8cfa22a TheCharlatan: ACK 8cfa22a Tree-SHA512: 74c3219301398361d06b1ef2257fc9ec18055b1661f8733ee909adefee61e458d70991c32adf0e0450905a7ffbddc99799f5fdac894f4896cfade19f961818df
This is not a hardening specific flag, it should be used at all times, regardless of if hardening is enabled or not. Note that this was still the case here, but having this exist in the hardening flags is confusing, and may lead someone to move it inside one of the
use_hardeningblocks, where it would become unused, with--disable-hardening.Noticed while reviewing hebasto#32 (comment).