On Mon, Mar 9, 2026 at 10:49 AM Jakub Jelinek <[email protected]> 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.
> Also, what is the stack growth factor e.g. on that problematic testcase?
> Is it 2x, or say 1.5x or 1.25x? Perhaps we don't need 128MB but 96MB etc.,
> doesn't have to be a power of two...
I wonder if, at least for release builds, removing the limit (aka RLIM_INFINITY)
would be reasonable? libiberty currently does
struct rlimit rlim;
if (getrlimit (RLIMIT_STACK, &rlim) == 0
&& rlim.rlim_cur != RLIM_INFINITY
&& rlim.rlim_cur < pref
&& (rlim.rlim_max == RLIM_INFINITY || rlim.rlim_cur < rlim.rlim_max))
{
rlim.rlim_cur = pref;
if (rlim.rlim_max != RLIM_INFINITY && rlim.rlim_cur > rlim.rlim_max)
rlim.rlim_cur = rlim.rlim_max;
so passing -1UL might work? GCC is single-threaded and does not have
a bound recursion depth - of course we do want to know of excesses,
because not all platforms can raise the limit arbitrarily.
Richard.
>
> Jakub
>
