[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