https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300
Janne Blomqvist <jb at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-08-12
CC| |jb at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Janne Blomqvist <jb at gcc dot gnu.org> ---
AFAICT this is a valid bug report, albeit maybe not of the highest priority.
The problem is that the code in the fortran frontend for handling this is a
flaming mess.
Without stat=, it properly generates a call to an error handling function in
libgfortran, which examines errno and uses strerror() (or depending on what is
available on the target, strerror_l() or strerror_r() ) to convert errno to a
string describing the error why the allocation fails.
However, if stat= and errmsg= are present, the only possible errmsg= value is a
string literal with the value "Attempt to allocate an allocated object", which
in this case is not correct. GFortran should do something similar to the
allocate without stat= also in this case, that is, use one of the strerror()
family functions to translate the errno value set by malloc() to a useful error
message.
(In reply to zed.three from comment #2)
> The perceived wisdom is that it is best
> practice to always use `stat` with `allocate`, and the addition of `errmsg`
> now gives us something portable to hopefully get a sensible error message.
Perceived wisdom is wrong, then, if all you do with stat= is print the errmsg=
error message and stop the program, because that's what the compiler already
does for you if you omit the stat= specifier (or, modulo bugs like this one,
should do).
allocate(stat=) is useful only if you can somehow recover usefully from failing
to allocate. E.g. switch to another less memory-hungry algorithm, sparser grid,
or whatever. And even so, thanks to overcommit in many operating systems such
as Linux, this isn't likely to work usefully anyway.
> I'm certainly not saying this is a show-stopper, but I don't think it's at
> all stupid to expect useful error messages.
I agree.
