[Resend - lists rejected previous mail]
Hello,
When -ftrivial-auto-var-init= is enabled, allocas unconditionally
receive auto-initialization since [1].
In certain cases, it turns out, this is causing problems [2], as it
causes significant overheads with no way to turn off that behaviour.
The more fundamental problem, that GCC devs pointed out to us [3], is
that an explicit __builtin_alloca() is not an "automatic variable",
which is also why GCC 12's behaviour of the same command-line option
diverges from Clang's behaviour.
As the command-line option's name suggestions, and also our
documentation [4] does point out that this is for "trivial automatic
stack variables".
From all that, the conclusion appears to be that initializing
__builtin_alloca is out-of-scope of ftrivial-auto-var-init.
Without entirely reverting __builtin_alloca initialization, the cleanest
option appears to be introducing yet another -f<option> to enable
auto-init of allocas.
Another alternative is to entirely leave alloca() initialization to libc
definitions of alloca():
// strawman
static inline void *alloca(size_t size)
{
void *ret = alloca(size);
#ifdef __ALLOCA_AUTO_INIT__
memset(ret, 0, size);
#endif
return ret;
}
Preferences?
Thanks,
-- Marco
[1] ⚙ D60548 Variable auto-init: also auto-init alloca
[2] randomize_kstack: To init or not to init?
[3] randomize_kstack: To init or not to init?
[4] Clang command line argument reference — Clang 16.0.0git documentation