https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #26 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Sure. I'm pointing out that Windows has had safety here for years, while
> Linux doesn't.
Thanks for correcting, the initial formulation was quite misleading and could
be understood as GCC not being on par with MSVC and Clang on Windows; it is.
> ... pointing out that something isn't implemented ideally is FUD now? If it
> had no significant performance hit (which should be the case for optimized
> C, because it shouldn't need to reserve a register), then it would surely be
> enabled by default.
Well, the sentence is "The implementation of -fstack-check in GCC does have
significant overhead" so it seems to be talking about something implemented.
-fstack-check has a measurable overhead but doesn't cause a significant
performance hit in most cases.
> We tried enabling it in Arch Linux but it had to be backed out due to
> performance concerns. Some compatibility issues came up (due to inline
> assembly) and then investigation into it demonstrated that it wasn't really
> causing a negligible performance hit, especially on i686. Among other
> things, it causes a significant performance hit (over 5% slower in a malloc
> micro-benchmark on x86_64, more on i686) for jemalloc which has large enough
> stack frames to trigger it and essentially all of the code is inlined. It's
> usually pretty small... but a lot more than it should be.
Thanks for the figures. There is a specific issue on x86{-64}/Linux caused by
the reservation of the frame pointer in order to be able to unwind the stack
for propagating exceptions (stack checking was initially implemented for Ada
and the Ada language requires stack overflows to be turned into exceptions that
can be caught) and which also gives rise to PR target/67265; that's not the
case on other platforms. I'll propose a fix for the PR.
