We should do an analysis of BFs and bug reports to see if _FORTIFY_SOURCE and especially -fstack-protector=strong have been effective at finding and preventing bugs. The latter adds an extra thread-local access and branch to (basically) every out of line c++ function call. It should only apply to functions which could overwrite a buffer on the stack, but it is very aggressive about what it considers a "buffer" and includes basically any time you pass a const& to an object on the stack. We know we have problems with branch predictor pressure so hopefully removing that could help. These are intended to improve security by preventing stack-smashing on buffer overflow, so we should tread carefully here. But if the bug analysis shows that A) they have never tripped on a released build and B) they were less effective than ASAN at producing BFs, we should reevaluate the tradeoff. We also have the option to enable them on a single variant, or in --dbg builds if they have occasionally been useful for BFs but not preventing security holes in production. I don't think we use a ton of naked stack buffers anyway, so I wouldn't expect this to be a common bug for us.

We should reevaluate enabling extra asserts in --dbg builds for libc++ and libstdc++ in order to catch more bugs earlier in development, ideally before even running on evergreen. Both also have "lite" or "fast" modes that are supposedly intended to be usable in production, so we may want to consider that as well if they actually don't have any measurable perf hit.

GCC-14 adds a new -fhardened flag to enable a number of hardening flags all at once. We should almost certainly enable that in debug builds. We should evaluate the perf impact in production.

-ftrivial-auto-var-init=pattern will help catch bugs from uninitialized members. Especially if we have at least one builder using =zero (implied by -fhardened if no option is explicitly passed). I find that one of the most common and hard to catch bugs of this variety is when a bool or similar member is uninitialized, but in tests happens to be put into memory that had the right initial value.