From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25498 invoked by alias); 26 Jan 2003 09:43:57 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 25200 invoked by uid 48); 26 Jan 2003 09:40:06 -0000 Date: Sun, 26 Jan 2003 09:43:00 -0000 Message-ID: <20030126094006.25199.qmail@sources.redhat.com> To: 133574@bugs.debian.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, pavel@atrey.karlin.mff.cuni.cz From: rth@gcc.gnu.org Reply-To: rth@gcc.gnu.org, 133574@bugs.debian.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, pavel@atrey.karlin.mff.cuni.cz, gcc-gnats@gcc.gnu.org Subject: Re: other/9081: gcc doesn't diagnose, that the compiler exceeds a compiler limit X-SW-Source: 2003-01/txt/msg01474.txt.bz2 List-Id: 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