On Mon 2026-03-09 11:05:58, Richard Biener wrote:
> 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.
Doing 'stack_limit_increase (-1UL)' makes sense to me and certainly does help
with the stack overflow.
So how about this (I've discovered that the stack increase also happens in
gcc.cc so I'm patching that too)?
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index f3e0004cdb8..1f89851951a 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -8420,8 +8420,14 @@ driver::global_initializations ()
#endif
/* Parsing and gimplification sometimes need quite large stack.
- Increase stack size limits if possible. */
+ Increase stack size limits as much as possible for release builds or
+ address-sanitized builds. Keep a reasonable stack size in checking
+ builds. If GCC becomes too stack-hungry, we want to know about it. */
+#if not CHECKING_P || __SANITIZE_ADDRESS__
+ stack_limit_increase (-1UL);
+#else
stack_limit_increase (64 * 1024 * 1024);
+#endif
/* Allocate the argument vector. */
alloc_args ();
diff --git a/gcc/toplev.cc b/gcc/toplev.cc
index 682459220a2..47e28fc57b5 100644
--- a/gcc/toplev.cc
+++ b/gcc/toplev.cc
@@ -2300,8 +2300,14 @@ int
toplev::main (int argc, char **argv)
{
/* Parsing and gimplification sometimes need quite large stack.
- Increase stack size limits if possible. */
+ Increase stack size limits as much as possible for release builds or
+ address-sanitized builds. Keep a reasonable stack size in checking
+ builds. If GCC becomes too stack-hungry, we want to know about it. */
+#if not CHECKING_P || __SANITIZE_ADDRESS__
+ stack_limit_increase (-1UL);
+#else
stack_limit_increase (64 * 1024 * 1024);
+#endif
/* Stash a copy of the original argv before expansion
for use by SARIF output. */
