This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
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.
Created an attachment (id=6128) [edit] C preprocessor output of gcc-3.4.0/gcc/libjava/interpret.cc
Please make sure that you have read http://gcc.gnu.org/bugs.html and provide all the information needed.
*** Bug 15042 has been marked as a duplicate of this bug. ***
This should have been fixed by the patch for PR 13468. Tom, I think this is a weird CVS thing going on.
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
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
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.
I did reproduce it on a i686-pc-linux-gnu with 64Mb RAM and about 200M swap and kernel 2.4.20
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.
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.
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 ***
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
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.