On Mon 2026-03-09 10:48:29, Jakub Jelinek wrote:
> On Mon, Mar 09, 2026 at 10:44:21AM +0100, Filip Kastl wrote:
> > * toplev.cc (toplev::main): Ask for 128MB stack instead of 64MB
> > stack when __SANITIZE_ADDRESS__ is defined.
> >
> > Signed-off-by: Filip Kastl <[email protected]>
> > ---
> > gcc/toplev.cc | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/gcc/toplev.cc b/gcc/toplev.cc
> > index 682459220a2..b41189cab0a 100644
> > --- a/gcc/toplev.cc
> > +++ b/gcc/toplev.cc
> > @@ -2301,7 +2301,11 @@ toplev::main (int argc, char **argv)
> > {
> > /* Parsing and gimplification sometimes need quite large stack.
> > Increase stack size limits if possible. */
> > +#ifdef __SANITIZE_ADDRESS__
> > stack_limit_increase (64 * 1024 * 1024);
> > +#else
> > + stack_limit_increase (128 * 1024 * 1024);
> > +#endif
>
> In my reading this uses 64MB for ASAN instrumented gcc and 128MB otherwise,
> not 128MB for ASAN and 64MB otherwise.
Ah, you're right. Sorry. I have tested the correct patch but then retyped
that the wrong way round. I'll fix that.
> Also, what is the stack growth factor e.g. on that problematic testcase?
> Is it 2x, or say 1.5x or 1.25x?
On x86_64 linux to compile limits-exprparen.c at -O0 I need
- at least 27MB stack for regular GCC
- --disable-bootstrap --enable-checking GCC from 20260226
- at least 71MB stack for ASAN GCC
- --enable-host-shared --enable-checking=release
--with-build-config=bootstrap-asan GCC from 20260221
Measured on GCC binaries I currently have on hand. I can be more thorough
and build the two binaries from the same sources and with the same flags if you
think it is worth it.
So that's ~2.6x growth modulo the differences in configure flags and the few
days that the sources are apart.
> Perhaps we don't need 128MB but 96MB etc., doesn't have to be a power of
> two...
I was thinking that 64MB more memory isn't much on systems where people are
likely to run ASAN-instrumented GCC and that maybe the extra margin would be
good to have -- GCC's stack usage may go up in the future and maybe other
targets need more stack than x86_64 linux. But sure, we could do something
like 96MB or even 80MB.
Filip
