This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: gcc/gcc ChangeLog Makefile.in fixinc/Makefile. ...
- From: "Zack Weinberg" <zack at codesourcery dot com>
- To: bkorb at gnu dot org
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 09 Jul 2003 07:51:37 -0700
- Subject: Re: gcc/gcc ChangeLog Makefile.in fixinc/Makefile. ...
- References: <3F0C256E.6F759D50@veritas.com>
Bruce Korb <bkorb@gnu.org> writes:
> Hi Zack,
>
> I didn't see your patch for this. There is a caveat: the unmodified
> GNU flavor of regex insists on using its own alloca when the native
> compiler doesn't support it. This is a problem. It is so because
> fixincludes invokes regexec 100's of thousands of times at the same
> stack level and the alloca emulator never frees these data. It exhausts
> all virtual memory. So, if this ``xregex'' thing uses the same thing,
> there will be a problem.
I am not clear on the allocation pattern in regex.c, because the file
is very complicated and hides stuff behind lots of macros, but all
the match primitives are structured like this:
match()
{
setup work
match_internal()
#ifdef C_ALLOCA
alloca(0);
#endif
}
Which makes me think that the problem has been solved. I could be
wrong though.
If the problem recurs, we could just stick an alloca(0) call into the
loop in fixincludes.
zw