Bug 128806 - cc1plus tries to allocate nearly 4GB when compiling cvcl
Summary: cc1plus tries to allocate nearly 4GB when compiling cvcl
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 2
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL: http://chicory.stanford.edu/CVC/
Depends On:
TreeView+ depends on / blocked
Reported: 2004-07-29 19:27 UTC by Jerry James
Modified: 2007-11-30 22:10 UTC (History)
0 users

Clone Of:
Last Closed: 2004-08-02 13:33:40 UTC

Attachments (Terms of Use)
Preprocessed parsePL.cpp (bzip2ed) (125.97 KB, application/octet-stream)
2004-07-29 20:03 UTC, Jerry James
no flags Details

Description Jerry James 2004-07-29 19:27:44 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510

Description of problem:
Compilation of cvcl 1.1.0 fails with this error:

g++ -O2 -Wall -I/tmp/cvcl-1.1.0/src/include -I/tmp/cvcl-1.1.0 -I. -c

cc1plus: out of memory allocating 3906815220 bytes after a total of
18948096 bytes

Compiling with -O2 -fno-default-inline succeeds.  The file in question
is generated by bison.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Download and unpack cvcl-1.1.0.tar.gz
2. In the cvcl-1.1.0 directory, run ./configure
3. make

Actual Results:  When compilation reaches the file in question, it
attempts to allocate more memory than is available and fails.

Expected Results:  GCC should not fail, although what it could do in
this situation depends on why it is trying to allocate so much memory.

Additional info:

To compile with -fno-default-inline, do:
make OPTFLAGS='-O2 -fno-default-inline'

Comment 1 Jakub Jelinek 2004-07-29 19:41:00 UTC
Please provide a preprocessed source which triggers this.
(run the above command with additional -save-temps option and
attach here parsePL.ii it creates.

Comment 2 Jerry James 2004-07-29 20:03:15 UTC
Created attachment 102299 [details]
Preprocessed parsePL.cpp (bzip2ed)

I had to compress it because bugzilla complained the attachment was too large.

Comment 3 Jakub Jelinek 2004-08-02 13:33:40 UTC
Exception handling in this testcase increases number of basic blocks
from around 34000 to 176000.  Some algorithms in GCC are Ospace(nBB^2),
thus your testcase is too big.
What you can do is tweak the inline limits (see man gcc on --param)
so that less inlining happens.
GCC 3.4 has better inlining algorithm, but it is too invasive change
for GCC 3.3.  FC3t1 uses GCC 3.4.x, so you might try your fortune there.

Note You need to log in before you can comment on or make changes to this bug.