Bug 15040 - numerous "sorry, unimplemented: inlining failed" failures
Summary: numerous "sorry, unimplemented: inlining failed" failures
Status: RESOLVED DUPLICATE of bug 14950
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.4.0
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: build
: 15042 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-04-21 11:15 UTC by adam
Modified: 2005-07-23 22:49 UTC (History)
3 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments
C preprocessor output of gcc-3.4.0/gcc/libjava/interpret.cc (49.14 KB, text/plain)
2004-04-21 11:20 UTC, adam
Details

Note You need to log in before you can comment on or make changes to this bug.
Description adam 2004-04-21 11:15:40 UTC
gcc-3.4.0 generates numerous "sorry, unimplemented: inlining failed"
compilation failures, which never occurred in 3.3.2.

I believe this some kind of memory allocation failure, because I happend to
observe it on a system that has a slow kernel memory leak.  Some files on which
gcc got this error on a system that had been exercising the memory leak would
compile successfully if I would reboot the computer and try again.  However,
other files, such as, gcc-3.4.0/gcc/libjava/interpret.cc would always fail to
compile with this error, on a machine with 512MB of RAM and no swap.  (Deleting
the word "inline" from line 98 of interpret.cc works around the problem.)

Another example that readily reproduces these compilation failures is attempting
to build the qt-3.3.1 windowing tool kit.

I am aware that my hypothesizing that this is a memory allocation failure opens
up two areas for potential nitpicking: (1) there is no specification for the
amount of memory that gcc can require, and (2) if gcc is changed to generate
non-inline code when memory allocation for inlining fails, that would make gcc
potentially generate different code for different runs on the same input. 
However, I hope that there will be way to get the memory consumption down to
levels similar to gcc-3.3.2, which did not seem to have this problem in
practice.

I'll add an attachement to this bug report for
gcc-3.4.0/gcc/libjava/interpret.i.
Comment 1 adam 2004-04-21 11:20:39 UTC
Created attachment 6128 [details]
C preprocessor output of gcc-3.4.0/gcc/libjava/interpret.cc
Comment 2 Andrew Pinski 2004-04-21 11:24:42 UTC
Please make sure that you have read http://gcc.gnu.org/bugs.html and provide all the information 
needed.
Comment 3 Andrew Pinski 2004-04-21 12:37:19 UTC
*** Bug 15042 has been marked as a duplicate of this bug. ***
Comment 4 Andrew Pinski 2004-04-21 12:40:37 UTC
This should have been fixed by the patch for PR 13468.
Tom, I think this is a weird CVS thing going on.
Comment 5 Daniël van Eeden 2004-04-21 12:50:55 UTC
It is something memory related. After some failed compiles most of my memory is
consumed. There isn't even X running on that box nor any other memory intensive
programs.

root@snow-ldap-test:/work/gcc-3.4.0/gcc-3.4.0# free
             total       used       free     shared    buffers     cached
Mem:       2072208    1788848     283360          0      49592    1493328
-/+ buffers/cache:     245928    1826280
Swap:      1001448          0    1001448
Comment 6 Daniël van Eeden 2004-04-21 13:54:34 UTC
After a reboot I did this:
free > free.before; make -j 3; free > free.after

free.before:
             total       used       free     shared    buffers     cached
Mem:       2072208     353868    1718340          0      15544     285764
-/+ buffers/cache:      52560    2019648
Swap:      1001448          0    1001448

free.after:
             total       used       free     shared    buffers     cached
Mem:       2072208     986892    1085316          0      24928     872332
-/+ buffers/cache:      89632    1982576
Swap:      1001448          0    1001448
Comment 7 Andrew Pinski 2004-04-21 17:27:42 UTC
I cannot reproduce this on i686-pc-linux-gnu with a 1GB of memory with 2GB of swap 
with a 2.4.18 kernel.  So this looks like a kernel bug so closing as invalid.
Comment 8 Daniël van Eeden 2004-04-21 21:32:59 UTC
I did reproduce it on a i686-pc-linux-gnu with 64Mb RAM and about 200M swap and
kernel 2.4.20
Comment 9 adam 2004-04-22 07:58:27 UTC
To Andrew Pinksi:
Regarding your first comment, what additional information mentioned in
http://gcc.gnu.org/bugs.html did you think "is needed" for this bug report?

Regarding your suggestion that this problem may be fixed by the fix discussed
(but not currently included) in PR 13468.  It may be that that fix would change
interpret.cc so that compiling consumes sufficiently less memory so as not to
trigger this problem, but there are plenty of other files that do.  interpret.cc
is just a handy example.  I can submit at least one example from the qt
windowing toolkit if that would help.  The problem described by this bug report
is not specific to interpret.cc.

Thank you for reporting that the suspected memory allocation failure that I see
with 512MB of memory does not occur on your system with about six times as much
memory available (1GB RAM + 2GB swap = 3GB = 512MB x 6).  I'm serious when I see
that that is helpful to know.

However, I hope you would agree that for debugging a memory usage problem like
this, the difference between 3GB available and 512MB is more likely to explain
why you did not see the problem than "it's a kernel bug."  If you could try to
do the compile on your computer again after doing a "swapoff -a", you will have
results for 1GB of memory space available.  If you reboot Linux and pass
"mem=512M", do "swapoff -a", and then try again, then you should see the result
of having 512MB available.  Perhaps you could try some smaller value like
"mem=300M" or something if that does not reproduce the problem.

If I understand correctly, Daniel van Eeden has reproduced the problem on both
2.4.20 (his comment to this bug report) and 2.6.2 (his bug report 15042),
neither of which would contain the kernel changes that I was trying to debug.

Regarding Daniel's observation of the total virtual memory available
shrinking by 37MB (from 2,019,648kB to 1,982,576kB) after a "make -j",
that looks like too much memory loss to attribute to other caching
data structures besides the buffer cache (file name lookup cache, inode cache),
but it might be.  In particular, if file contents transferred only via page
operations are not counted in the "+/- buffers cache", then there might not be a
memory leak at all.  I would be interested in knowing what happens as you run
"make -j" several time.

However, even if all 37MB of that change is memory leak, I think gcc still
should be expected to be able to compile itself on a 277MB system (277MB =
64MB RAM + 200MB swap - 37MB memory leak).

For this bug to be "resolved invalid", I think the information presented would
have to rule out or at least indicate with near certainty that this is not a gcc
bug.  Indeed, I think the information presented thus far still implies that gcc
is the most likely culpit.  Therefore, I think I must reopen this bug.

I am not reopening the bug as "verified" at this point, even though Daniel has
obviiously seen the same bug, because I assume that "verified" in this context
means "verified" by a someone who is likely to make use of that verification as
a starting point for further debugging, which I think is the useful progress
point that the "verified" state is supposed to indicate.
Comment 10 adam 2004-04-22 23:23:37 UTC
Changing component from java to C++.  libjava/interpret.cc was just an example
of one file that exhibited this problem.  The files on which I've observed
this problem are all C++ files.  I suspect that the bug probably occurs with
inline functions generally (for example, in C), but, since that hasn't been
observed yet, I'll call this a "C++" bug rather than a "middle-end" bug.

Comment 11 Andrew Pinski 2004-04-22 23:46:49 UTC
Okay I was able to reproduce this -O1 so that is the bug, but this is dup of bug 14950.

*** This bug has been marked as a duplicate of 14950 ***
Comment 12 Karlan Kayne 2004-05-09 22:37:06 UTC
I got no error with (2.6.5(gcc(fedoraC1))) and gcc(fedoraC1) compiling 3.4.0,
but I did with:

2.6.4(gcc(fedora)) + gcc 3.4.0 compiling gcc 3.4.0
and
2.6.5(gcc(3.4.0)) + gcc 3.4.0 compiling gcc 3.4.0
I also noticed compiling the kernel with gcc 3.4.0, and compiling gcc 3.4.0
results in many segfaults, and alwasy eats my memory.

my machine:
p4 with 1gb ram noswap
(THATS IT! SORRY)
karlankayne at comcast dot net
Comment 13 adam 2004-05-20 09:08:17 UTC
Off-topic note: The Linux kernel memory leak that I mentioned seems to have 
disappeared in Linux 2.6.6.  This, however, does not mean the gcc problem is 
fixed.