* [PATCH] PR fortran/91300 - runtime error message with allocate and errmsg= @ 2022-05-28 20:25 Harald Anlauf 2022-05-30 7:33 ` Tobias Burnus 0 siblings, 1 reply; 3+ messages in thread From: Harald Anlauf @ 2022-05-28 20:25 UTC (permalink / raw) To: fortran, gcc-patches [-- Attachment #1: Type: text/plain, Size: 1386 bytes --] Dear Fortranners, 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. 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". (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.) 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. First, ERRMSG is very compiler-dependent anyway and thus not really portable. If a user wants to know what the size of the failed allocation is and really wants to recover, he/she should find that out himself. Second, I think that the more important change is the introduction of a STAT value that allows the distinction between the different causes of failure. The testcase should be able to handle 32 and 64 bit systems. At least that's what I think. Regtested on x86_64-pc-linux-gnu. OK for mainline? Suggestions? Thanks, Harald [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Fortran-improve-runtime-error-message-with-ALLOCATE-.patch --] [-- Type: text/x-patch, Size: 6285 bytes --] From 19ccd22ee9359bd14b32a95bd9efcaead3593b2f Mon Sep 17 00:00:00 2001 From: Harald Anlauf <anlauf@gmx.de> Date: Sat, 28 May 2022 22:02:20 +0200 Subject: [PATCH] Fortran: improve runtime error message with ALLOCATE and ERRMSG= 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. --- gcc/fortran/libgfortran.h | 1 + gcc/fortran/trans-stmt.cc | 33 +++++++++++++-- gcc/fortran/trans.cc | 4 +- .../gfortran.dg/allocate_alloc_opt_15.f90 | 40 +++++++++++++++++++ 4 files changed, 73 insertions(+), 5 deletions(-) create mode 100644 gcc/testsuite/gfortran.dg/allocate_alloc_opt_15.f90 diff --git a/gcc/fortran/libgfortran.h b/gcc/fortran/libgfortran.h index 064795eb469..4328447be04 100644 --- a/gcc/fortran/libgfortran.h +++ b/gcc/fortran/libgfortran.h @@ -133,6 +133,7 @@ typedef enum LIBERROR_CORRUPT_FILE, LIBERROR_INQUIRE_INTERNAL_UNIT, /* Must be different from STAT_STOPPED_IMAGE. */ LIBERROR_BAD_WAIT_ID, + LIBERROR_NO_MEMORY, LIBERROR_LAST /* Not a real error, the last error # + 1. */ } libgfortran_error_codes; diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc index 79096816c6e..fd6d294147e 100644 --- a/gcc/fortran/trans-stmt.cc +++ b/gcc/fortran/trans-stmt.cc @@ -7130,7 +7130,8 @@ gfc_trans_allocate (gfc_code * code) if (code->expr1 && code->expr2) { const char *msg = "Attempt to allocate an allocated object"; - tree slen, dlen, errmsg_str; + const char *oommsg = "Insufficient virtual memory"; + tree slen, dlen, errmsg_str, oom_str, oom_loc; stmtblock_t errmsg_block; gfc_init_block (&errmsg_block); @@ -7151,8 +7152,34 @@ gfc_trans_allocate (gfc_code * code) gfc_default_character_kind); dlen = gfc_finish_block (&errmsg_block); - tmp = fold_build2_loc (input_location, NE_EXPR, logical_type_node, - stat, build_int_cst (TREE_TYPE (stat), 0)); + tmp = fold_build2_loc (input_location, EQ_EXPR, logical_type_node, + stat, build_int_cst (TREE_TYPE (stat), + LIBERROR_ALLOCATION)); + + tmp = build3_v (COND_EXPR, tmp, + dlen, build_empty_stmt (input_location)); + + gfc_add_expr_to_block (&block, tmp); + + oom_str = gfc_create_var (pchar_type_node, "OOMMSG"); + oom_loc = gfc_build_localized_cstring_const (oommsg); + gfc_add_modify (&errmsg_block, oom_str, + gfc_build_addr_expr (pchar_type_node, oom_loc)); + + slen = build_int_cst (gfc_charlen_type_node, strlen (oommsg)); + dlen = gfc_get_expr_charlen (code->expr2); + slen = fold_build2_loc (input_location, MIN_EXPR, + TREE_TYPE (slen), dlen, slen); + + gfc_trans_string_copy (&errmsg_block, dlen, errmsg, + code->expr2->ts.kind, + slen, oom_str, + gfc_default_character_kind); + dlen = gfc_finish_block (&errmsg_block); + + tmp = fold_build2_loc (input_location, EQ_EXPR, logical_type_node, + stat, build_int_cst (TREE_TYPE (stat), + LIBERROR_NO_MEMORY)); tmp = build3_v (COND_EXPR, tmp, dlen, build_empty_stmt (input_location)); diff --git a/gcc/fortran/trans.cc b/gcc/fortran/trans.cc index f0a5dfb50fc..912a206f2ed 100644 --- a/gcc/fortran/trans.cc +++ b/gcc/fortran/trans.cc @@ -772,7 +772,7 @@ gfc_call_malloc (stmtblock_t * block, tree type, tree size) if (newmem == NULL) { if (stat) - *stat = LIBERROR_ALLOCATION; + *stat = LIBERROR_NO_MEMORY; else runtime_error ("Allocation would exceed memory limit"); } @@ -807,7 +807,7 @@ gfc_allocate_using_malloc (stmtblock_t * block, tree pointer, if (status != NULL_TREE) { tmp = fold_build2_loc (input_location, MODIFY_EXPR, status_type, status, - build_int_cst (status_type, LIBERROR_ALLOCATION)); + build_int_cst (status_type, LIBERROR_NO_MEMORY)); gfc_add_expr_to_block (&on_error, tmp); } else diff --git a/gcc/testsuite/gfortran.dg/allocate_alloc_opt_15.f90 b/gcc/testsuite/gfortran.dg/allocate_alloc_opt_15.f90 new file mode 100644 index 00000000000..04f7bf11970 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/allocate_alloc_opt_15.f90 @@ -0,0 +1,40 @@ +! { dg-do run } +! PR fortran/91300 - runtime error message with allocate and errmsg= +! Contributed by zed.three + +program bigarray_prog + use, intrinsic :: iso_c_binding, only: C_INTPTR_T + implicit none + real, dimension(:), allocatable :: array, bigarray + integer :: stat1, stat2 + character(len=100) :: errmsg1, errmsg2 + integer(8), parameter :: n1 = huge (1) / 3 ! request more than 2GB + integer(8), parameter :: n2 = huge (1_C_INTPTR_T) / 4 ! "safe" for 64bit + integer(8), parameter :: bignumber = max (n1, n2) + + stat1 = -1 + errmsg1 = "" + allocate (array(1), stat=stat1, errmsg=errmsg1) + if (stat1 /= 0) stop 1 + if (errmsg1 /= "") stop 1 + + ! 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 + + 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 + end if + +end program bigarray_prog -- 2.35.3 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] PR fortran/91300 - runtime error message with allocate and errmsg= 2022-05-28 20:25 [PATCH] PR fortran/91300 - runtime error message with allocate and errmsg= Harald Anlauf @ 2022-05-30 7:33 ` Tobias Burnus 2022-05-30 20:53 ` [PATCH] Fortran: improve runtime error message with ALLOCATE and, ERRMSG= [PR91300] Harald Anlauf 0 siblings, 1 reply; 3+ messages in thread From: Tobias Burnus @ 2022-05-30 7:33 UTC (permalink / raw) To: Harald Anlauf, fortran, gcc-patches 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* [PATCH] Fortran: improve runtime error message with ALLOCATE and, ERRMSG= [PR91300] 2022-05-30 7:33 ` Tobias Burnus @ 2022-05-30 20:53 ` Harald Anlauf 0 siblings, 0 replies; 3+ messages in thread From: Harald Anlauf @ 2022-05-30 20:53 UTC (permalink / raw) To: Tobias Burnus, fortran, gcc-patches [-- Attachment #1: Type: text/plain, Size: 5743 bytes --] Hi Tobias, Am 30.05.22 um 09:33 schrieb Tobias Burnus: > 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.) for reference these are the messages of selected compilers: ifort: insufficient virtual memory nag: Out of memory crayftn: The program was unable to request more memory space. And since Intel's message for attempting to allocate an already allocated object was closest to gfortran's version, and Cray is far too verbose for my taste, I threw mental dice between Intel and NAG, and Intel won. >> (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. Thanks for confirming this. >> 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.) OK, will do from now on. My visual parsing and reading ability of subject lines is not really positive-correlated with their machine- readability, but then gcc-patches@ is not what I'm reading... ;-) (I consider it basically a write-only list). >> 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 I've adjusted the testcase as suggested and hardened it somewhat against strange options like -fdefault-integer-8 -fdefault-real-8. Committed and pushed as attached. Thanks for the review! Harald > 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 > [-- Attachment #2: 0001-Fortran-improve-runtime-error-message-with-ALLOCATE-.patch --] [-- Type: text/x-patch, Size: 6708 bytes --] From 871dbb6112e22ff92914613c332944fd19dd39a8 Mon Sep 17 00:00:00 2001 From: Harald Anlauf <anlauf@gmx.de> Date: Sat, 28 May 2022 22:02:20 +0200 Subject: [PATCH] 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. --- gcc/fortran/libgfortran.h | 1 + gcc/fortran/trans-stmt.cc | 33 +++++++++++-- gcc/fortran/trans.cc | 4 +- .../gfortran.dg/allocate_alloc_opt_15.f90 | 49 +++++++++++++++++++ 4 files changed, 82 insertions(+), 5 deletions(-) create mode 100644 gcc/testsuite/gfortran.dg/allocate_alloc_opt_15.f90 diff --git a/gcc/fortran/libgfortran.h b/gcc/fortran/libgfortran.h index 064795eb469..4328447be04 100644 --- a/gcc/fortran/libgfortran.h +++ b/gcc/fortran/libgfortran.h @@ -133,6 +133,7 @@ typedef enum LIBERROR_CORRUPT_FILE, LIBERROR_INQUIRE_INTERNAL_UNIT, /* Must be different from STAT_STOPPED_IMAGE. */ LIBERROR_BAD_WAIT_ID, + LIBERROR_NO_MEMORY, LIBERROR_LAST /* Not a real error, the last error # + 1. */ } libgfortran_error_codes; diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc index 79096816c6e..fd6d294147e 100644 --- a/gcc/fortran/trans-stmt.cc +++ b/gcc/fortran/trans-stmt.cc @@ -7130,7 +7130,8 @@ gfc_trans_allocate (gfc_code * code) if (code->expr1 && code->expr2) { const char *msg = "Attempt to allocate an allocated object"; - tree slen, dlen, errmsg_str; + const char *oommsg = "Insufficient virtual memory"; + tree slen, dlen, errmsg_str, oom_str, oom_loc; stmtblock_t errmsg_block; gfc_init_block (&errmsg_block); @@ -7151,8 +7152,34 @@ gfc_trans_allocate (gfc_code * code) gfc_default_character_kind); dlen = gfc_finish_block (&errmsg_block); - tmp = fold_build2_loc (input_location, NE_EXPR, logical_type_node, - stat, build_int_cst (TREE_TYPE (stat), 0)); + tmp = fold_build2_loc (input_location, EQ_EXPR, logical_type_node, + stat, build_int_cst (TREE_TYPE (stat), + LIBERROR_ALLOCATION)); + + tmp = build3_v (COND_EXPR, tmp, + dlen, build_empty_stmt (input_location)); + + gfc_add_expr_to_block (&block, tmp); + + oom_str = gfc_create_var (pchar_type_node, "OOMMSG"); + oom_loc = gfc_build_localized_cstring_const (oommsg); + gfc_add_modify (&errmsg_block, oom_str, + gfc_build_addr_expr (pchar_type_node, oom_loc)); + + slen = build_int_cst (gfc_charlen_type_node, strlen (oommsg)); + dlen = gfc_get_expr_charlen (code->expr2); + slen = fold_build2_loc (input_location, MIN_EXPR, + TREE_TYPE (slen), dlen, slen); + + gfc_trans_string_copy (&errmsg_block, dlen, errmsg, + code->expr2->ts.kind, + slen, oom_str, + gfc_default_character_kind); + dlen = gfc_finish_block (&errmsg_block); + + tmp = fold_build2_loc (input_location, EQ_EXPR, logical_type_node, + stat, build_int_cst (TREE_TYPE (stat), + LIBERROR_NO_MEMORY)); tmp = build3_v (COND_EXPR, tmp, dlen, build_empty_stmt (input_location)); diff --git a/gcc/fortran/trans.cc b/gcc/fortran/trans.cc index f0a5dfb50fc..912a206f2ed 100644 --- a/gcc/fortran/trans.cc +++ b/gcc/fortran/trans.cc @@ -772,7 +772,7 @@ gfc_call_malloc (stmtblock_t * block, tree type, tree size) if (newmem == NULL) { if (stat) - *stat = LIBERROR_ALLOCATION; + *stat = LIBERROR_NO_MEMORY; else runtime_error ("Allocation would exceed memory limit"); } @@ -807,7 +807,7 @@ gfc_allocate_using_malloc (stmtblock_t * block, tree pointer, if (status != NULL_TREE) { tmp = fold_build2_loc (input_location, MODIFY_EXPR, status_type, status, - build_int_cst (status_type, LIBERROR_ALLOCATION)); + build_int_cst (status_type, LIBERROR_NO_MEMORY)); gfc_add_expr_to_block (&on_error, tmp); } else diff --git a/gcc/testsuite/gfortran.dg/allocate_alloc_opt_15.f90 b/gcc/testsuite/gfortran.dg/allocate_alloc_opt_15.f90 new file mode 100644 index 00000000000..3c26e8179cb --- /dev/null +++ b/gcc/testsuite/gfortran.dg/allocate_alloc_opt_15.f90 @@ -0,0 +1,49 @@ +! { dg-do run } +! { dg-additional-options "-fdump-tree-original" } +! PR fortran/91300 - runtime error message with allocate and errmsg= +! Contributed by zed.three + +program bigarray_prog + use, intrinsic :: iso_c_binding, only: C_INTPTR_T + implicit none + real(4), dimension(:), allocatable :: array, bigarray + integer :: stat1, stat2 + character(len=100) :: errmsg1, errmsg2 + character(*), parameter :: no_error = "no error" + integer(8), parameter :: n1 = huge (1_4) / 3 ! request more than 2GB + integer(8), parameter :: n2 = huge (1_C_INTPTR_T) / 4 ! "safe" for 64bit + integer(8), parameter :: bignumber = max (n1, n2) + + stat1 = -1 + stat2 = -1 + errmsg1 = no_error + errmsg2 = no_error + allocate (array(1), stat=stat1, errmsg=errmsg1) + if (stat1 /= 0 ) stop 1 + if (errmsg1 /= no_error) stop 1 + + ! Obtain stat, errmsg for attempt to allocate an allocated object + allocate (array(1), stat=stat1, errmsg=errmsg1) + if (stat1 == 0 ) stop 2 + if (errmsg1 == no_error) stop 2 + + ! Try to allocate very large object + allocate (bigarray(bignumber), stat=stat2, errmsg=errmsg2) + if (stat2 /= 0) then + print *, "stat1 =", stat1 + print *, "errmsg: ", trim (errmsg1) + print *, "stat2 =", stat2 + print *, "errmsg: ", trim (errmsg2) + ! Ensure different results for stat, errmsg variables (all compilers) + if (stat2 == stat1 ) stop 3 + if (errmsg2 == no_error .or. errmsg2 == errmsg1) stop 4 + + ! Finally verify gfortran-specific error messages + if (errmsg1 /= "Attempt to allocate an allocated object") stop 5 + if (errmsg2 /= "Insufficient virtual memory" ) stop 6 + end if + +end program bigarray_prog + +! { dg-final { scan-tree-dump-times "Attempt to allocate an allocated object" 4 "original" } } +! { dg-final { scan-tree-dump-times "Insufficient virtual memory" 4 "original" } } -- 2.35.3 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-05-30 20:53 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-05-28 20:25 [PATCH] PR fortran/91300 - runtime error message with allocate and errmsg= Harald Anlauf 2022-05-30 7:33 ` Tobias Burnus 2022-05-30 20:53 ` [PATCH] Fortran: improve runtime error message with ALLOCATE and, ERRMSG= [PR91300] Harald Anlauf
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).