[Bug fortran/50937] STAT option with ALLOCATE statement on large arrays

["fwi at inducks dot org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #11 from fwi at inducks dot org 2011-11-01 12:00:54 UTC ---
(In reply to comment #10)
> 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 hate to continue this discussion, but I think the integer overflow problem,
which is what I was reporting, was a different issue. The fact that you solved
it in recent gfortran versions proves that there was something you could do
about that.

> 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

Thanks for the info.

> 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.

Not really, because then I can directly tell users how they can solve the
issue, that is either switch to a 64bit OS or compile the MPI version of the
same program (because then the main array is splitted in several chunks, all of
them small enough to be indexed with 32bit integers).
Without the STAT option, users will be left in the dark with just "it doesn't
work". Or with "I need to spend time reading the manual".

And please - I hope you all do not take my remarks as harsh criticism, I do
appreciate the efforts and job you did with gfortran. A few years ago, my code
was much faster with ifort than gcc's Fortran, nowadays it's comparable and I
can tell people to use gfortran if they like.