[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 --- Comment #15 from Thomas Schwinge --- Author: tschwinge Date: Tue Oct 8 10:20:41 2019 New Revision: 276691 URL: https://gcc.gnu.org/viewcvs?rev=276691&root=gcc&view=rev Log: Extend 'libgfortran/runtime/minimal.c' per r274599 "PR fortran/68401 Improve allocation error message" libgfortran/ PR fortran/68401 * runtime/minimal.c (os_error_at): New function. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/runtime/minimal.c
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Janne Blomqvist --- Fixed on trunk, closing.
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 --- Comment #13 from Janne Blomqvist --- Author: jb Date: Sat Aug 17 05:45:37 2019 New Revision: 274599 URL: https://gcc.gnu.org/viewcvs?rev=274599&root=gcc&view=rev Log: PR fortran/68401 Improve allocation error message Improve the error message that is printed when a memory allocation fails, by including the location, and the size of the allocation that failed. Regtested on x86_64-pc-linux-gnu. gcc/fortran/ChangeLog: 2019-08-17 Janne Blomqvist PR fortran/68401 * trans-decl.c (gfc_build_builtin_function_decls): Replace os_error with os_error_at decl. * trans.c (trans_runtime_error_vararg): Modify so the error function decl is passed directly. (gfc_trans_runtime_error): Pass correct error function decl. (gfc_trans_runtime_check): Likewise. (trans_os_error_at): New function. (gfc_call_malloc): Use trans_os_error_at. (gfc_allocate_using_malloc): Likewise. (gfc_call_realloc): Likewise. * trans.h (gfor_fndecl_os_error): Replace with gfor_fndecl_os_error_at. libgfortran/ChangeLog: 2019-08-17 Janne Blomqvist PR fortran/68401 * gfortran.map: Add GFORTRAN_10 node, add _gfortran_os_error_at symbol. * libgfortran.h (os_error_at): New prototype. * runtime/error.c (os_error_at): New function. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/error.c
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 Janne Blomqvist changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2019-08/msg01172.ht ||ml --- Comment #12 from Janne Blomqvist --- Patch at https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01172.html With this the test.f90 in the original report prints something like: In file 'test.f90', around line 5: Error allocating 4294967296 bytes: Cannot allocate memory Error termination. Backtrace: #0 0x400874 in test at /home/janne/src/gfortran/my-patches/pr68401-oserror/test.f90:4 #1 0x4008d3 in main at /home/janne/src/gfortran/my-patches/pr68401-oserror/test.f90:4 (yes, the location is off a little bit)
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 Janne Blomqvist changed: What|Removed |Added Status|WAITING |NEW CC||jb at gcc dot gnu.org Blocks||91300 Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org --- Comment #11 from Janne Blomqvist --- The variadic os_error type function is probably also necessary for solving PR 91300. Taking a stab at this. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 [Bug 91300] Wrong runtime error message with allocate and errmsg=
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 --- Comment #10 from Dominique d'Humieres --- How long this PR has to rot before being closed as WONTFIX?
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #9 from Dominique d'Humieres --- Any progress?
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 --- Comment #8 from Joost VandeVondele --- (In reply to Mikael Morin from comment #7) > (In reply to Joost VandeVondele from comment #6) > > (In reply to Mikael Morin from comment #5) > > > (In reply to Joost VandeVondele from comment #4) > > > > In the original post I suggested that I already looked at the code, > > > > > > What changes did you try? > > > > Baby steps :-) see below. Basically stuck when I realized that somehow the > > 'tree size' needs to get in. > > > I guess the easiest is to use a variadic call. > The calls can be updated by incrementing the argument count of > build_call_expr_loc, and adding the size argument. > Then you can't use os_error, which is non-variadic. > You can either use one of the existing (variadic) routines, such as > runtime_error, or create some os_error_varargs (basically create the > gfor_fndecl_XXX in trans-decl.c and use it as argument of > build_call_expr_loc). > If you create a new declaration, you'll have to write the corresponding code > in libgfortran. > > Does it sound like it's worth it? well, at least I have an idea of a way forward.. I did spent a few hours on this already. I guess it is easier once one knows the code. I do believe this is useful indeed, within our project we discussed if we could clean up the error checking of (de)allocates (14000 calls) and we already removed all checking for all but 400, cleaning away roughly 3 lines of (useless in my opinion, and with various bugs) code. See for example https://sourceforge.net/p/cp2k/code/15938/ with many similar commits. The remaining 400 calls report the size of the failed allocate. To clean those the consensus was that the compiler should report the size of the failed allocation.
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 --- Comment #7 from Mikael Morin --- (In reply to Joost VandeVondele from comment #6) > (In reply to Mikael Morin from comment #5) > > (In reply to Joost VandeVondele from comment #4) > > > In the original post I suggested that I already looked at the code, > > > > What changes did you try? > > Baby steps :-) see below. Basically stuck when I realized that somehow the > 'tree size' needs to get in. > I guess the easiest is to use a variadic call. The calls can be updated by incrementing the argument count of build_call_expr_loc, and adding the size argument. Then you can't use os_error, which is non-variadic. You can either use one of the existing (variadic) routines, such as runtime_error, or create some os_error_varargs (basically create the gfor_fndecl_XXX in trans-decl.c and use it as argument of build_call_expr_loc). If you create a new declaration, you'll have to write the corresponding code in libgfortran. Does it sound like it's worth it?
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401
--- Comment #6 from Joost VandeVondele
---
(In reply to Mikael Morin from comment #5)
> (In reply to Joost VandeVondele from comment #4)
> > In the original post I suggested that I already looked at the code,
>
> What changes did you try?
Baby steps :-) see below. Basically stuck when I realized that somehow the
'tree size' needs to get in.
Index: fortran/trans.c
===
--- fortran/trans.c (revision 227094)
+++ fortran/trans.c (working copy)
@@ -567,6 +567,8 @@ gfc_call_malloc (stmtblock_t * block, tr
tree tmp, msg, malloc_result, null_result, res, malloc_tree;
stmtblock_t block2;
+ char* msgstr;
+
size = gfc_evaluate_now (size, block);
if (TREE_TYPE (size) != TREE_TYPE (size_type_node))
@@ -593,8 +595,9 @@ gfc_call_malloc (stmtblock_t * block, tr
null_result = fold_build2_loc (input_location, EQ_EXPR,
boolean_type_node, res,
build_int_cst (pvoid_type_node, 0));
+ msgstr = xasprintf("Memory allocation of %ld bytes failed",0L);
msg = gfc_build_addr_expr (pchar_type_node,
- gfc_build_localized_cstring_const ("Memory allocation failed"));
+ gfc_build_localized_cstring_const (msgstr));
tmp = fold_build3_loc (input_location, COND_EXPR, void_type_node,
null_result,
build_call_expr_loc (input_location,
@@ -641,6 +644,7 @@ gfc_allocate_using_malloc (stmtblock_t *
{
tree tmp, error_cond;
stmtblock_t on_error;
+ char* msgstr;
tree status_type = status ? TREE_TYPE (status) : NULL_TREE;
/* Evaluate size only once, and make sure it has the right type. */
@@ -677,10 +681,12 @@ gfc_allocate_using_malloc (stmtblock_t *
else
{
/* Here, os_error already implies PRED_NORETURN. */
+ /* TODO figure out how to get 'size' in this string */
+ msgstr=xasprintf("Allocation of %ld bytes would exceed memory
limit",-1L);
tmp = build_call_expr_loc (input_location, gfor_fndecl_os_error, 1,
- gfc_build_addr_expr (pchar_type_node,
-gfc_build_localized_cstring_const
- ("Allocation would exceed memory limit")));
+ gfc_build_addr_expr (pchar_type_node,
gfc_build_cstring_const(msgstr)));
+ /* gfc_build_localized_cstring_const
+ ("Allocation would exceed memory limit")));
*/
gfc_add_expr_to_block (&on_error, tmp);
}
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #5 from Mikael Morin --- (In reply to Joost VandeVondele from comment #4) > In the original post I suggested that I already looked at the code, What changes did you try?
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 --- Comment #4 from Joost VandeVondele --- (In reply to Dominique d'Humieres from comment #3) > I am still not convinced. IMO enhancements have only two realistic status: > WONTFIX or ASSIGNED. not sure, project that do not engage with their community of users and encourage feedback in various forms, including enhancement requests, might be at risk. If only to keep track of these ideas/requests, they should be kept 'NEW'. In the original post I suggested that I already looked at the code, if anybody posts suggests how to deal with the coding, I could look into this.
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Severity|normal |enhancement --- Comment #3 from Dominique d'Humieres --- > In our code, we have about a 400 allocates that are checked for istat, > and do nothing else than abort after signalling the size of the allocation. > It is error prone (e.g. wrong sizes, missing check after istat, etc. etc.), > and would like to get rid of this, as the compiler can do this much better. I am still not convinced. IMO enhancements have only two realistic status: WONTFIX or ASSIGNED.
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 Joost VandeVondele changed: What|Removed |Added Status|WAITING |NEW CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #2 from Joost VandeVondele --- (In reply to Dominique d'Humieres from comment #1) > > This would help users and/or developers to take the right actions. > > Would this really help? I am not convinced. > In our code, we have about a 400 allocates that are checked for istat, and do nothing else than abort after signalling the size of the allocation. It is error prone (e.g. wrong sizes, missing check after istat, etc. etc.), and would like to get rid of this, as the compiler can do this much better.
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-11-19 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- > This would help users and/or developers to take the right actions. Would this really help? I am not convinced. If there are only a few ALLOCATE, it would be quite easy to spot the biggest one. If there are a large number of them, mixing big and small sizes, would 'Allocation of 10 bytes would exceed memory limit' be really helpful?
