On Tue 2026-03-31 10:39:33, Jeffrey Law wrote:
>
>
> On 3/30/2026 6:16 AM, Filip Kastl wrote:
> > Hi.
> >
> > This is the second version of this patch. In this version:
> > - I've also modified gcc.cc instead of just toplev.cc (so both places in
> > GCC's
> > codebase where 'stack_limit_increase ()' gets called are now patched
> > - I correctly request more memory when GCC *is* built with ASAN. I switched
> > that around in v1.
> >
> > Please also consider this to be a ping.
> >
> > Btw, if this isn't a stage 4 material, do tell me and I'll postpone pinging
> > to
> > stage 1 :).
> >
> > Cheers,
> > Filip Kastl
> >
> > -- 8< --
> >
> >
> > 64MB stack is not enough for running
> > gcc/testsuite/gcc.c-torture/compile/limits-exprparen.c with an
> > ASAN-instrumented GCC. Ask for more stack if GCC was compiled with ASAN
> > instrumentation.
> >
> > PR sanitizer/124206
> >
> > gcc/ChangeLog:
> >
> > * gcc.cc (driver::global_initializations): Ask for 128MB stack
> > instead of just 64MB when __SANITIZE_ADDRESS__ is defined.
> > * toplev.cc (toplev::main): Ditto.
> I'm not excited by new #ifdefs. I don't guess we have any runtime way to
> check for asan being enabled? Assuming the answer to that is no, we don't
> have a way to check that, then this is OK for gcc-17.
Would it even make sense to check if GCC was compiled with address sanitizers
during runtime? I searched a bit and didn't find a way to do that. This
should be handled during compile time, I think. Even though I understand that
#ifdefs guarding parts of function bodies are ugly and make the code harder to
read, in this instance I think it is the best thing to do.
Or we could do something like this, if you like it more:
gcc.h and toplev.h:
```
#ifdef __SANITIZE_ADDRESS__
constexpr unsigned long STACK_SIZE = 128 * 1024 * 1024;
#else
constexpr unsigned long STACK_SIZE = 64 * 1024 * 1024;
#endif
```
gcc.cc and toplev.cc:
```
stack_limit_increase (STACK_SIZE);
```
But both solutions seem roughly equivalent to me.
Cheers,
Filip Kastl
