This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, v4] Use cygwin spawn functions
- From: Dave Korn <dave dot korn dot cygwin at gmail dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, dj at redhat dot com, kai dot tietz at onevision dot com
- Date: Sat, 23 Oct 2010 18:21:51 +0100
- Subject: Re: [PATCH, v4] Use cygwin spawn functions
- References: <4CB3AEC5.3090209@redhat.com> <4CB791AE.9080303@redhat.com> <4CBA02C4.9050801@redhat.com>
On 16/10/2010 20:53, Richard Henderson wrote:
> Version 4. The last attempt, while it fixed the hanging due
> to pipe fds left open, closed some file descriptors too early.
> This one has actually passed the entire testsuite.
>
> Ok?
:-( This caused a number of regressions in a native testsuite run on
i686-pc-cygwin.
> FAIL: g++.dg/parse/stack1.C (test for excess errors)
and
> FAIL: gcc.c-torture/compile/limits-declparen.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-declparen.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-declparen.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-exprparen.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-exprparen.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-exprparen.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-exprparen.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-exprparen.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-exprparen.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-exprparen.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-exprparen.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-pointer.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-pointer.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-pointer.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-structnest.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-structnest.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-structnest.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-structnest.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-structnest.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-structnest.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-structnest.c (test for excess errors)
> FAIL: gcc.c-torture/compile/limits-structnest.c (test for excess errors)
are the most noticeable ones. The common factor appears to be that these are
all tests that involve deeply recursive heavy stack usage. The bug only
arises when the driver is invoked to launch cc1plus.exe, I couldn't reproduce
it by invoking the language compiler directly from the shell.
Interestingly enough, even the clean cc1plus build failed the stack1.C test
when I ran it under GDB. For some reason the stack ended up at a really low
address; the default reservation of stack space for w32 console apps is 2MB,
and although there was that much space, there wasn't any further room for it
to expand down into, which there would have been if the stack had been located
at a more normal address.
It might be suitable to address this in gcc by adding "-Wl,--stack,4194304"
or simlar to the host build flags. Or there could be some kind of bug or
anomaly in cygwin's spawn function. I won't have time to investigate further
in the next few days, I'm rushing to get another stage 1 patch in.
cheers,
DaveK