[Bug fortran/32439] hard-coded memory limit ? f951: out of memory with '-O1 -fbounds-check'
--- Comment #3 from jv244 at cam dot ac dot uk 2007-06-26 14:59 --- I ran the compilation now on a machine with 64Gb of memory, and it still failed. According to 'top' the memory used by f951 was about 4Gb. The error message: f951: out of memory allocating 4064 bytes after a total of 1148219392 bytes also seems to suggest that much less than 64Gb (in fact, just 1Gb) of memory was allocated. So, it looks like something inside gcc is hard-coded to just 1Gb of memory, instead of the available memory. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Summary|f951: out of memory with '- |hard-coded memory limit ? |O1 -fbounds-check' |f951: out of memory with '- ||O1 -fbounds-check' http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32439
[Bug fortran/32439] hard-coded memory limit ? f951: out of memory with '-O1 -fbounds-check'
--- Comment #4 from pinskia at gmail dot com 2007-06-26 15:20 --- Subject: Re: hard-coded memory limit ? f951: out of memory with '-O1 -fbounds-check' On 26 Jun 2007 14:59:27 -, jv244 at cam dot ac dot uk <[EMAIL PROTECTED]> wrote: > f951: out of memory allocating 4064 bytes after a total of 1148219392 bytes Ignore the second number, it just is total count of memory allocated via xmalloc and not the amount of memory used at the time of the crash. Why we print it out I have no idea, it is not very useful any more really. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32439
[Bug fortran/32439] hard-coded memory limit ? f951: out of memory with '-O1 -fbounds-check'
--- Comment #5 from jv244 at cam dot ac dot uk 2007-06-27 07:31 --- could be similar to PR32514 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32439
[Bug fortran/32439] hard-coded memory limit ? f951: out of memory with '-O1 -fbounds-check'
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-06-27 08:51 --- (In reply to comment #3) > So, it looks like something inside gcc is hard-coded to just 1Gb > of memory, instead of the available memory. That's probably a stupid thing to ask, but you don't have any shell limits (as reported per "ulimit -a") that would match this number, do you? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32439
[Bug fortran/32439] hard-coded memory limit ? f951: out of memory with '-O1 -fbounds-check'
--- Comment #7 from jv244 at cam dot ac dot uk 2007-06-27 12:18 --- (In reply to comment #6) > (In reply to comment #3) > > So, it looks like something inside gcc is hard-coded to just 1Gb > > of memory, instead of the available memory. > > That's probably a stupid thing to ask, but you don't have any shell limits (as > reported per "ulimit -a") that would match this number, do you? > I don't think so. We run large memory jobs on that machine (that's why we have it in the first place). I get the following output: > ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited pending signals (-i) 529920 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 529920 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32439
[Bug fortran/32439] hard-coded memory limit ? f951: out of memory with '-O1 -fbounds-check'
--- Comment #8 from jv244 at cam dot ac dot uk 2007-07-06 08:23 --- closing as magically fixed -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32439
Re: [Bug fortran/32439] hard-coded memory limit ? f951: out of memory with '-O1 -fbounds-check'
On 26 Jun 2007 14:59:27 -, jv244 at cam dot ac dot uk <[EMAIL PROTECTED]> wrote: f951: out of memory allocating 4064 bytes after a total of 1148219392 bytes Ignore the second number, it just is total count of memory allocated via xmalloc and not the amount of memory used at the time of the crash. Why we print it out I have no idea, it is not very useful any more really. -- Pinski