On 28.05.22 22:25, Harald Anlauf via Fortran wrote:
the PR rightfully complained that we did not differentiate errors on
ALLOCATE(...,stat=,errmsg=) for failures from allocation of already
allocated objects or insufficient virtual memory.
It is even worse: The error message states the wrong reason.
The attached patch introduces a new STAT value LIBERROR_NO_MEMORY
that is returned for insufficient virtual memory, and a corresponding
(simple and invariant) ERRMSG: "Insufficient virtual memory".
I think the message is fine – at least on Linux 'virtual memory' is
what's used and it is clear what's meant, even if I stumble a bit about
the wording. (But do not have a crisp short & comprehensive wording myself.)
(In the PR Janne mentions checking for errno, but since the standard
malloc(3) only mentions ENOMEM as possible error value, and the user
may replace malloc by a special library, I believe that won't be easy
to handle in a general way.)
I con concur. Especially as POSIX and the Linux manpage only list ENOMEM
as only value.
Most compilers I tried (Intel/NAG/Crayftn) behave similarly, except
for Nvidia/Flang, which try to return the size of the allocation in
the error message.
I am not sure that this is worth the effort.
I think it is not needed – especially as we generate the message in the
FE and not in libgfortran. The advantage for the users is that they know
what value has been requested – but they cannot really do much with the
knowledge, either.
The testcase should be able to handle 32 and 64 bit systems.
At least that's what I think.
I hope it is – at least on 64bit, I currently expect it too fail
somewhat reliably, with 32bit I think it won't – but that's also handled.
But you could add a -fdump-tree-original + '! { dg-final {
scan-tree-dump*' to do some checking in addition (e.g. whether both
strings appear in the dump; could be more complex, but that's probably
not needed).
Regtested on x86_64-pc-linux-gnu. OK for mainline? Suggestions?
LGTM – with considering comments on the testcase.
Fortran: improve runtime error message with ALLOCATE and ERRMSG=
Consider appending [PR91300] in that line – and try to make the
gcc-patches@ and fortran@ lines the same
(Searching for the PR number or case-insignificantly for the string in
the mailing list archive, will fine the message; thus, that's okay.)
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.
---
...
+ stat1 = -1
+ errmsg1 = ""
+ allocate (array(1), stat=stat1, errmsg=errmsg1)
+ if (stat1 /= 0) stop 1
+ if (errmsg1 /= "") stop 1
Consider to init the errmsg1 and then check that is has not been
touched. (For completeness, I think we already have such tests).
+ ! Obtain stat,errmsg for attempt to allocate an allocated object
+ allocate (array(1), stat=stat1, errmsg=errmsg1)
+ if (stat1 == 0) stop 2
+ if (errmsg1 == "") stop 2
Consider to check (either here or as a third test) for the
gfortran-specific error message.
+ stat2 = -1
+ errmsg2 = ""
+ ! Try to allocate very large object
+ allocate (bigarray(bignumber), stat=stat2, errmsg=errmsg2)
+ if (stat2 /= 0) then
+ print *, "stat =", stat1
+ print *, "errmsg: ", trim (errmsg1)
+ print *, "stat =", stat2
+ print *, "errmsg: ", trim (errmsg2)
+ ! Ensure different results for stat, errmsg variables
+ if (stat2 == stat1 ) stop 3
+ if (errmsg2 == "" .or. errmsg2 == errmsg1) stop 4
Likewise for errmsg2
Thanks,
Tobias
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
