This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: other/9081: gcc doesn't diagnose, that the compiler exceeds a compiler limit
- From: rth at gcc dot gnu dot org
- To: 133574 at bugs dot debian dot org, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, nobody at gcc dot gnu dot org, pavel at atrey dot karlin dot mff dot cuni dot cz
- Date: 26 Jan 2003 09:40:06 -0000
- Subject: Re: other/9081: gcc doesn't diagnose, that the compiler exceeds a compiler limit
- Reply-to: rth at gcc dot gnu dot org, 133574 at bugs dot debian dot org, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, nobody at gcc dot gnu dot org, pavel at atrey dot karlin dot mff dot cuni dot cz, gcc-gnats at gcc dot gnu dot org
Synopsis: gcc doesn't diagnose, that the compiler exceeds a compiler limit
State-Changed-From-To: open->closed
State-Changed-By: rth
State-Changed-When: Sun Jan 26 09:39:58 2003
State-Changed-Why:
This isn't a compiler problem. There is no compiler limit that
has been exceeded. Indeed, the executable generated looks fine.
The kernel, however, is refusing to map the very large bss
segment. Perhaps your ulimit is set too low? Perhaps you
don't have enough VM to satisfy the request?
In fact, if I enable a 2G swap file, and link the program
statically, then it runs just fine.
(If you don't link statically, then ld.so crashes. I suspect
a different kernel bug, in that it's not adjusting where it
maps ld.so based on the large bss segment.)
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9081