[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed for gcc-13. Closing. Thanks for the report!
[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 --- Comment #8 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:871dbb6112e22ff92914613c332944fd19dd39a8 commit r13-858-g871dbb6112e22ff92914613c332944fd19dd39a8 Author: Harald Anlauf Date: Sat May 28 22:02:20 2022 +0200 Fortran: improve runtime error message with ALLOCATE and ERRMSG= [PR91300] ALLOCATE: generate different STAT,ERRMSG results for failures from allocation of already allocated objects or insufficient virtual memory. gcc/fortran/ChangeLog: PR fortran/91300 * libgfortran.h: Define new error code LIBERROR_NO_MEMORY. * trans-stmt.cc (gfc_trans_allocate): Generate code for setting ERRMSG depending on result of STAT result of ALLOCATE. * trans.cc (gfc_allocate_using_malloc): Use STAT value of LIBERROR_NO_MEMORY in case of failed malloc. gcc/testsuite/ChangeLog: PR fortran/91300 * gfortran.dg/allocate_alloc_opt_15.f90: New test.
[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org CC||anlauf at gcc dot gnu.org --- Comment #7 from anlauf at gcc dot gnu.org --- Patch submitted: https://gcc.gnu.org/pipermail/fortran/2022-May/057887.html
[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 --- Comment #6 from anlauf at gcc dot gnu.org --- Currently the only generated STAT code is 5014 for LIBERROR_ALLOCATION. This is ambiguous. Shall we add another enum value to libgfortran_error_codes, such as LIBERROR_VIRTUAL_MEMORY, LIBERROR_MEMORY, or LIBERROR_ALLOCATED?
[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 --- Comment #5 from G. Steinmetz --- Please ignore comment 4, wrong PR ...
[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #4 from G. Steinmetz --- Variants that actually compile : $ cat z3.f90 # with a scalar, x(:) -> x module m type t contains procedure :: f => g end type contains subroutine g (z, x) class(t) :: z class(t), optional :: x end subroutine s (z, x) class(t) :: z class(t), optional :: x if ( present(x) ) call z%f(x) end end $ cat z4.f90 # without optional module m type t contains procedure :: f => g end type contains subroutine g (z, x) class(t) :: z class(t), optional :: x end subroutine s (z, x) class(t) :: z class(t) :: x(:) call z%f(x(1)) end end
[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 Bug 91300 depends on bug 68401, which changed state. Bug 68401 Summary: improve 'Allocation would exceed memory limit' https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 Janne Blomqvist 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 --- 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.
[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 --- Comment #2 from zed.three at gmail dot com --- Forgive me, but what is stupid here? 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. Unfortunately, the error message is not correct here. If you mean trying to allocate a 1D array that is huge(1) -- this is just a large enough value that it's likely to fail due to not enough memory on most machines, as it's about 17GB. A 5D array of real64s of size 64x64x64x64x64 is 8GB, which is definitely not an unrealistic size. That's only 2x10^9 points. 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.
[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 CC||kargl at gcc dot gnu.org Severity|normal |enhancement --- Comment #1 from kargl at gcc dot gnu.org --- If you do stupid things, one is likely to get a stupid result. I vote to close as WONTFIX or INVALID. I'll leave this open for someone else to waste their time.
