This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: gcj/sparc64?
- From: Jay <jayk123 at hotmail dot com>
- To: <gcc at gcc dot gnu dot org>
- Cc: Andrew Haley <aph at redhat dot com>, <tromey at redhat dot com>
- Date: Sun, 10 Aug 2008 13:41:14 +0000
- Subject: RE: gcj/sparc64?
- References: <1216680495.31069.ezmlm@gcc.gnu.org> <COL101-W834B0BE1410DDD2EA7AF9EE6870@phx.gbl> <m3k5fbl4ly.fsf@fleche.redhat.com> <488B3E30.1090008@redhat.com> <COL101-W81D72D008BD8C93AC10988E6760@phx.gbl> <489EAB81.ED1F6D2B@dessent.net>
> From: brian@
>>
> This stack exhaustion is PR36218 which was supposedly fixed on
> mainline. Two problems: the fix needs to be extended to Cygwin as well
> as MinGW, and you're not building mainline.
>
>> I wish Windows code was PIC
>
> zero to do with the topic of this thread.
I agree it's a tangent.
It seems the PIC compilation succeeds.
The whole thing where things get compiled twice, PIC and non-PIC, bugs me.
It's a "great" way to slow down builds.
I guess configure -only-pic might be nice.
I understand the results, if only linked into an executabe, might be slower.
Picking a base address that might not conflict with other code/data
doesn't eliminate the problem, just reduces it, and a cost
of random burning of address space. (I don't know the algorithm,
"random" isn't the right word).
If the code/data were really PIC, it could be tightly packed.
Thanks.
I'm trying it out with an 8meg stack like was applied to mingwin.
I believe Solaris hosts need a fix here too.
And djgpp.
And perhaps others. AIX? Irix? HP-UX? *BSD?
Or most systems default to 8 or 32meg?
Not worth changing the gcc code to reduce or eliminate the recursion?
- Jay