http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50937
--- Comment #10 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-11-01 07:55:06 UTC --- (In reply to comment #8) > I indeed do not know everything about the OS and what it does when I > "allocate" > an array. But that's exactly the purpose of a programming language like > Fortran, an abstraction that should be "good enough" for programing without > having to know everything about the OS. Sometimes abstractions leak, unfortunately. There's really not anything gfortran can do about that. And, it's not unique to gfortran either. gfortran ALLOCATE uses the C malloc(), as does e.g. the default implementation of the C++ new operator and presumably a lot of other language runtimes as well. So they all share the same issues in case the system overcommits memory. I can certainly sympathize with the notion that memory overcommit is inane and shouldn't be enabled by default, but that's a system policy issue and nothing gfortran can do anything about. As you're on Linux, FWIW you can disable overcommit by setting the "vm.overcommit_memory" sysctl to the value 2. See http://www.mjmwired.net/kernel/Documentation/vm/overcommit-accounting > Secondly, users are sometimes better than programmers at telling them if > something is really useful or not. In that case, the question is: what is the > purpose of the STAT flag in an allocate STATEMENT if it won't give you any > reasonable indication if the array you have can be used or not. Indeed, on a system which overcommits memory, ALLOCATE with STAT is not particularly useful. But, again, memory overcommitting is a system policy issue and gfortran can't do anything about it. And, one might add, if all you're going to do with the STAT result is checking whether it's nonzero and stopping the program in that case, you might as well not bother because that's exactly what ALLOCATE without STAT already does.
