https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
--- Comment #9 from Petr Skocik ---
Regarding the size of alloca/VLA-generated code under -fstack-clash-protection.
I've played with this a little bit and while I love the feature, the code size
increases seem quite significant and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
--- Comment #8 from Jakub Jelinek ---
Alloca itself doesn't touch the stack on many architectures, and the code
doesn't have to have a function call in between.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
--- Comment #7 from Petr Skocik ---
(In reply to Jakub Jelinek from comment #4)
> Say for
> void bar (char *);
> void
> foo (int x, int y)
> {
> __attribute__((assume (x < 64)));
> for (int i = 0; i < y; ++i)
> bar (__builtin_alloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
--- Comment #6 from Petr Skocik ---
(In reply to Jakub Jelinek from comment #2)
> (In reply to Petr Skocik from comment #1)
> > Sidenote regarding the stack-allocating code for cases when the size is not
> > known to be less than pagesize: the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
--- Comment #5 from Jeffrey A. Law ---
Right. You also have to know the distance from the last probe (possibly an
implicit one) to the start of the alloca space before you can contemplate
eliding the probes in alloca space. There's a hook we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
--- Comment #4 from Jakub Jelinek ---
Say for
void bar (char *);
void
foo (int x, int y)
{
__attribute__((assume (x < 64)));
for (int i = 0; i < y; ++i)
bar (__builtin_alloca (x));
}
all the alloca calls are known to be small, yet they
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
Jakub Jelinek changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
--- Comment #1 from Petr Skocik ---
Sidenote regarding the stack-allocating code for cases when the size is not
known to be less than pagesize: the code generated for those cases is quite
large. It could be replaced (at least under -Os) with a
