[Bug c/15040] New: numerous "sorry, unimplemented: inlining failed" failures

[Bug c/15040] New: numerous "sorry, unimplemented: inlining failed" failures

[adam at yggdrasil dot com]

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.

-- 
           Summary: numerous "sorry, unimplemented: inlining failed"
                    failures
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: adam at yggdrasil dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15040

[Bug c/15040] numerous "sorry, unimplemented: inlining failed" failures

[adam at yggdrasil dot com]

------- Additional Comments From adam at yggdrasil dot com  2004-04-21 11:20 -------
Created an attachment (id=6128)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6128&action=view)
C preprocessor output of gcc-3.4.0/gcc/libjava/interpret.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15040

[Bug c/15040] numerous "sorry, unimplemented: inlining failed" failures

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-21 11:24 -------
Please make sure that you have read http://gcc.gnu.org/bugs.html and provide all the information 
needed.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15040

[Bug c++/15040] numerous "sorry, unimplemented: inlining failed" failures

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |c++


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15040

[Bug c++/15040] numerous "sorry, unimplemented: inlining failed" failures

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-21 12:37 -------
*** Bug 15042 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel_e at dds dot nl


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15040

[Bug java/15040] numerous "sorry, unimplemented: inlining failed" failures

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-21 12:40 -------
This should have been fixed by the patch for PR 13468.
Tom, I think this is a weird CVS thing going on.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu dot
                   |                            |org
          Component|c++                         |java
           Keywords|                            |build


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15040

[Bug java/15040] numerous "sorry, unimplemented: inlining failed" failures

[daniel_e at dds dot nl]

------- Additional Comments From daniel_e at dds dot nl  2004-04-21 12:50 -------
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

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15040

[Bug java/15040] numerous "sorry, unimplemented: inlining failed" failures

[daniel_e at dds dot nl]

------- Additional Comments From daniel_e at dds dot nl  2004-04-21 13:54 -------
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

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15040

[Bug java/15040] numerous "sorry, unimplemented: inlining failed" failures

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-21 17:27 -------
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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15040

[Bug java/15040] numerous "sorry, unimplemented: inlining failed" failures

[daniel_e at dds dot nl]

------- Additional Comments From daniel_e at dds dot nl  2004-04-21 21:32 -------
I did reproduce it on a i686-pc-linux-gnu with 64Mb RAM and about 200M swap and
kernel 2.4.20

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15040

[Bug java/15040] numerous "sorry, unimplemented: inlining failed" failures

[adam at yggdrasil dot com]

------- Additional Comments From adam at yggdrasil dot com  2004-04-22 07:58 -------
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.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15040

[Bug c++/15040] numerous "sorry, unimplemented: inlining failed" failures

[adam at yggdrasil dot com]

------- Additional Comments From adam at yggdrasil dot com  2004-04-22 23:23 -------
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.



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|java                        |c++


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15040

[Bug c++/15040] numerous "sorry, unimplemented: inlining failed" failures

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-22 23:46 -------
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 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15040

[Bug c++/15040] numerous "sorry, unimplemented: inlining failed" failures

[karlankayne at comcast dot net]

------- Additional Comments From karlankayne at comcast dot net  2004-05-09 22:37 -------
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

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15040

[Bug c++/15040] numerous "sorry, unimplemented: inlining failed" failures

[adam at yggdrasil dot com]

------- Additional Comments From adam at yggdrasil dot com  2004-05-20 09:08 -------
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. 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15040