That flag was introduced in GCC 14, and defines a bunch of options that enable more runtime checks
My Clang 22.1.5 doesn't seem to support -fhardened (but it has the -D_LIBCPP_HARDENING_MODE which we enable already, so...); Ubuntu ships GCC...
- 11.2.0 in 22.04LTS (jammy)
- 13.2.0 in 24.04LTS (noble)
- 15.2.0 in 26.04LTS (resolute)
...so we may not be able to enable it in our develop configs by default, unless we made CMake test for the flag's availability (it has built-in functionality for that).
Apparently this has a very minimal impact on runtime perf nowadays, largely due to better compiler ability to elide checks, so GCC's docs recommend enabling it in production also. This is making me think that we may want to make it opt-out rather than opt-in. (The sanitizers have a much larger perf and deployment impact, and the extra warnings are generally not useful to non-developers, so I don't think we ought to alter their rationale.)
That flag was introduced in GCC 14, and defines a bunch of options that enable more runtime checks
My Clang 22.1.5 doesn't seem to support
-fhardened(but it has the-D_LIBCPP_HARDENING_MODEwhich we enable already, so...); Ubuntu ships GCC......so we may not be able to enable it in our
developconfigs by default, unless we made CMake test for the flag's availability (it has built-in functionality for that).Apparently this has a very minimal impact on runtime perf nowadays, largely due to better compiler ability to elide checks, so GCC's docs recommend enabling it in production also. This is making me think that we may want to make it opt-out rather than opt-in. (The sanitizers have a much larger perf and deployment impact, and the extra warnings are generally not useful to non-developers, so I don't think we ought to alter their rationale.)