[Bug fortran/78640] [F2015] gfortran accepts invalid allocatable polymorphic result in pure function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78640 --- Comment #3 from Stefano Zaghi --- Yes, I am one who think that respecting this constrain is important: I was not aware that standard does not allow pure polymorphic functions, thus I mislead myself from the fact that the compiler did bot complain about this violation. My best regards. An enthusiast.
[Bug fortran/80477] [OOP] Polymorphic function result generates memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477 --- Comment #15 from Stefano Zaghi --- Dear all, I add that the workaround (inserting an allocatable inside the type being a result of polymorphic function) if used into a real code (https://github.com/szaghi/FORESEER) does not solve the memory leak and generates Error in `./exe/foreseer_test_shock_tube': free(): invalid pointer: 0x7f04e4f80b00 I have not yet minimized this last example. I do not know if this is of some help. My best regards.
[Bug fortran/80477] [OOP] Polymorphic function result generates memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477 --- Comment #13 from Stefano Zaghi --- Dear all, I have done further test about Vipul's workaround, you can find my complete report here https://github.com/szaghi/leaks_hunter#results Essentially, my current conclusion is that the workaround does not work always. In particular the "simple inheritance leaker" test shows that the leak is still generated no matter the workaround is used. In this last case, I think that issues could be placed into the "child_t" finalizer: you can find the generated code here https://github.com/szaghi/leaks_hunter#note I hope this can help for your patch. My best regards.
[Bug fortran/80477] [OOP] Polymorphic function result generates memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477 --- Comment #12 from Stefano Zaghi --- Created attachment 41267 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41267=edit simple inheritance leaker
[Bug fortran/80477] [OOP] Polymorphic function result generates memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477 --- Comment #10 from Stefano Zaghi --- Dear all, here https://github.com/szaghi/leaks_hunter you can find my report. Into the report I shown all the test I have done, I provide the sources and the scripts I used to generate them. As FortranFan and Francesco Salvadore pointed out, it seems that a simple workaround exists: add an allocatable into types which have only static components and have polymorphic result-functions. I'll try this workaround into the real program after 25 April. I hope this report you for your patch. My best regards.
[Bug fortran/80477] [OOP] Polymorphic function result generates memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477 --- Comment #8 from Stefano Zaghi --- Dear Janus, > No offense taken. Asking questions is not a crime ;) Good, thank you for the clarification. > I'm sorry to disappoint you, but there simply is no roadmap and I'm not able > to provide one. That's just not how things work with gfortran. > If you absolutely critically depend on some feature being available in a > certain > time-frame, then your best options are probably: > a) Try to implement it yourself or > b) pay someone to implement it. No disappointing at all: this is, indeed, the answer I was searching for taking a decision. If there is not a "timeline" for this bug, because the option a) is not up to me and option b) is currently impossible, this means that I have to left GNU if I cannot find a workaround for the leaks quickly. > I don't think the bug is incredibly difficult to solve. I already have a > basic > understanding of what's missing (see my analysis above) and I might > look into fixing it soon. BUT: I simply can not give you any roadmaps or > guarantees for that. > And yes, gfortran could definitely use some more manpower. If you are willing > to help (or know someone who is), you're certainly welcome. I really would like to help, but I am not up to the task (I never go over tutorial-level with C). Anyhow, if you can share your idea about the issue is placed (files involved, rationale...) it could be a starting a point: I have a colleague well-versed in C, maybe in some eons I could be of some help. > Sure, that will probably help to understand the problem. Thanks for your > efforts. You are much more than welcome. After 25 April I'll provide my report. My best regards.
[Bug fortran/80477] [OOP] Polymorphic function result generates memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477 --- Comment #6 from Stefano Zaghi --- Dear Janus, thank you very much for your help, it is really appreciated. > Note that most gfortran developers actually sacrifice their spare time to > contribute, without receiving any kind of financial reward for it. > I contributed large parts of the OOP implementation when I was a student > (with some funding via GSoC). Nowadays my day job and private life keeps me > from spending too much time on gfotran, but I still try to contribute the > occasional bug fix if I can. As I tried to clarify to Steve, mine was absolutely not a polemic question: although my contributions are definitely not equal to yours, I am also an active FOSS developer doing things for the community spending my free time, I clearly understand the FOSS developing effort. What I meant was "because the bug is known from 2014, can I conclude that there are not any developer who takes care (for time/interest lacking) about this in a reasonable time?". It is just a hint-request about a roadmap (I have to decide how to progress my work, gnu was a key feature), absolutely no critics about you, you are my superheros. My concern was that the bug was very difficult to solve and you are too few to solve it. I am going to create a detailed report (within a github repository) taking into account many combinations: it seems that if I add an allocatable component alongside the static one, the leaks disappear (although this does not happen in a real,omplex code where both static and dynamic components are present). If it is of some help, I would like to share with you. My best regards.
[Bug fortran/80477] Polymorphic functions (thus operators) generates memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477 --- Comment #2 from Stefano Zaghi --- A very kind and great Fortraner (Chris MacMackin) has just let me know that a very similar (or really the same) bug has been already reported (60913) here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60913 Probably my test is slightly more simple. I read that the other bug report is dated 2014: can I conclude that such a bug will need a long time to be fixed? Please, consider that this is not a "polemic" question: I consider all of you my superheros! However, this bug really stops me to use OOP thus I have to decide about my future work: without GNU I have no other compilers, thus if I will decide to invest more on OOP I have probably to left Fortran, probably for Julia... My best regards.
[Bug fortran/80477] Polymorphic functions (thus operators) generates memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477 --- Comment #1 from Stefano Zaghi --- I forget to say that I test this issue with GNU gfortran gcc version 6.3.1 20170306 and gcc version 7.0.0 20161206 (experimental). My best regards.
[Bug fortran/80477] New: Polymorphic functions (thus operators) generates memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477 Bug ID: 80477 Summary: Polymorphic functions (thus operators) generates memory leaks Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: stefano.zaghi at cnr dot it Target Milestone: --- Created attachment 41241 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41241=edit Code test to raise the memory leaks Dear all, I faced with a possible serious bug: polymorphic functions (necessary to define polymorphic operators in OOP programs) generate memory leaks making OOP program not feasible. In the attached example "polymorphic_operators_memory_leaks.f90" I show the possible bug in less than 100 lines. Essentially, the derived type "a_type_t" defines the operators "=" and "+" in a polymorphic way (in order to allow "a_type_t" to be extended while all other "agents" using "a_type_t" do not need to be changed, OOP). The assignment operator does not create memory leaks because it is subroutine that does not allocate temporary. On the contrary, the operator "+" is a function that allocates a temporary: this temporary generates the memory leaks because it is not correctly destroyed after its usage. I checked the above conclusion with "valgrind" and it confirms that the "+" operator (function) generates the leaks. Note that the same code compiled and run with Intel Fortran (17.0.2) does not generates memory leaks and it works as expected. Moreover, is the "+" operator/function is modified disallowing polymorphic (namely changing "class(a_type_t), allocatable :: res" with "type(a_type_t) :: res" the leaks disappear, thus I could conclude that the leaks are generated only for polymorphic function results. A word of advice: the test is designed to point out the memory leaks occurrences, running it your RAM will be quickly consumed! Please, be rapid to quickly kill it before your OS start swapping on HD. To test it with valgrind I added a little "ui": it can be executed without arguments, thus its loop will be very long (and your RAM totally consumed) or you can pass one integer argument and the loop will do the iterations you provided, e.g. "a.out 1" will execute 1 iteration loop. This is written into the code comments. Please, consider that if this is really a bug, all serious OOP programs are indeed impossible to be done. Thank you very much for your help.
[Bug fortran/79402] New: ICE with submodules: module procedure interface defined in parent module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79402 Bug ID: 79402 Summary: ICE with submodules: module procedure interface defined in parent module Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: stefano.zaghi at cnr dot it Target Milestone: --- Created attachment 40685 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40685=edit MCVE of ICE with submodule Dear gfortran team, I am writing on the behalf of Chris Coutinho who cannot create a bugzilla account. GNU gfortran generates and ICE when a submodule implementation of a procedure inherits its signature from the parent module by means of the "module procedure" syntax. In the "gfortran_ice_submodule.f90" file attached there is a minimal example raising the ICE (Arch Linux, 4.8.13-1-ARCH #1 SMP PREEMPT) with both 6.3.1 and development trunk 7.0.0 (I have not yet installed 7.0.1 version). If you comment lines 24-26 and un-comment lines 17-22 the program runs as expected. Our best regards. Stefano
[Bug fortran/78983] New: ICE with CAF-DT with allocatable member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78983
Bug ID: 78983
Summary: ICE with CAF-DT with allocatable member
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: stefano.zaghi at cnr dot it
Target Milestone: ---
Created attachment 40450
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40450=edit
MCVE of CAF-DT with allocatable member
My current "env" is
+ GNU Fortran (GCC) 7.0.0 20161206 (experimental)
+ MPICH 3.2.0 built with GCC 7.0.0
+ OpenCoarrays built 1.7.5 with GCC 7.0.0 and MPICH 3.2.0
+ Linux 4.8.8-2-ARCH #1 SMP PREEMPT Thu Nov 17 14:51:03 CET 2016 x86_64
GNU/Linux
The MCVE raising the ICE is attached as "MCVE of CAF-DT with allocatable
member". Essentially, there is a "base" DT (named "node") with an allocatable
member, a second DT (named "caf") that has a coarray member of "type(node)".
The last concrete instance of "type(caf)" is a scalar, static variable thus the
code should be valid (while I still think that the other is invalid).
Compiling this code with the above env generates the following ICE
stefano@zaghi(09:38 AM Mon Dec 12) desk {opencoarrays-1.7.5-gnu-7.0.0 -
OpenCoarrays 1.7.5 with gcc 7.0.0 environment}
~/fortran/compilers_bug/gfortran_sigsegv_caf_dt_allocatable_member 5 files,
84Kb
→ caf -fcoarray=lib sigsegv_caf_dt.f90
sigsegv_caf_dt.f90:77:0:
end module caf_module
internal compiler error: Segmentation fault
0xc0db4f crash_signal
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/toplev.c:333
0xeb1764 recompute_tree_invariant_for_addr_expr(tree_node*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/tree.c:4317
0xeb1d7c build1_stat(tree_code, tree_node*, tree_node*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/tree.c:4414
0x92c76c build1_stat_loc
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/tree.h:3903
0x92c76c fold_build1_stat_loc(unsigned int, tree_code, tree_node*, tree_node*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fold-const.c:12139
0x6f204f gfc_build_addr_expr(tree_node*, tree_node*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:298
0x70532b structure_alloc_comps
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-array.c:8329
0x7827b3 gfc_trans_deallocate(gfc_code*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:6477
0x6f1bf7 trans_code
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:1942
0x7742f3 gfc_trans_if_1
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1303
0x77c39a gfc_trans_if(gfc_code*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1334
0x6f1ce7 trans_code
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:1878
0x7742f3 gfc_trans_if_1
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1303
0x77c39a gfc_trans_if(gfc_code*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1334
0x6f1ce7 trans_code
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:1878
0x77e271 gfc_trans_simple_do
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1924
0x77e271 gfc_trans_do(gfc_code*, tree_node*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:2057
0x6f1cba trans_code
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:1890
0x723038 gfc_generate_function_code(gfc_namespace*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-decl.c:6271
0x6f6949 gfc_generate_module_code(gfc_namespace*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:2164
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
My best regards.
[Bug fortran/78682] [Coarray] [OOP] ICE calling (locally) a TBP of a remote CAF derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78682
--- Comment #7 from Stefano Zaghi ---
Dear all,
I confirm that with gcc 7.0.0 this ICE vanishes.
However, I find a new ICE. I am not sure if it is good to report it here or if
it is better to open a new ticket. In doubt, I start adding some details here.
My current "env" is
+ GNU Fortran (GCC) 7.0.0 20161206 (experimental)
+ MPICH 3.2.0 built with GCC 7.0.0
+ OpenCoarrays built 1.7.5 with GCC 7.0.0 and MPICH 3.2.0
+ Linux 4.8.8-2-ARCH #1 SMP PREEMPT Thu Nov 17 14:51:03 CET 2016 x86_64
GNU/Linux
The MCVE raising the ICE is attached as "MCVE of CAF-DT with allocatable
member". Essentially, there is a "base" DT (named "node") with an allocatable
member, a second DT (named "caf") that has a coarray member of "type(node)".
The last concrete instance of "type(caf)" is a scalar, static variable thus the
code should be valid (while I still think that the other is invalid).
Compiling this new code with the above env generates the following ICE
stefano@zaghi(09:38 AM Mon Dec 12) desk {opencoarrays-1.7.5-gnu-7.0.0 -
OpenCoarrays 1.7.5 with gcc 7.0.0 environment}
~/fortran/compilers_bug/gfortran_sigsegv_caf_dt_allocatable_member 5 files,
84Kb
→ caf -fcoarray=lib sigsegv_caf_dt.f90
sigsegv_caf_dt.f90:77:0:
end module caf_module
internal compiler error: Segmentation fault
0xc0db4f crash_signal
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/toplev.c:333
0xeb1764 recompute_tree_invariant_for_addr_expr(tree_node*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/tree.c:4317
0xeb1d7c build1_stat(tree_code, tree_node*, tree_node*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/tree.c:4414
0x92c76c build1_stat_loc
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/tree.h:3903
0x92c76c fold_build1_stat_loc(unsigned int, tree_code, tree_node*, tree_node*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fold-const.c:12139
0x6f204f gfc_build_addr_expr(tree_node*, tree_node*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:298
0x70532b structure_alloc_comps
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-array.c:8329
0x7827b3 gfc_trans_deallocate(gfc_code*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:6477
0x6f1bf7 trans_code
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:1942
0x7742f3 gfc_trans_if_1
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1303
0x77c39a gfc_trans_if(gfc_code*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1334
0x6f1ce7 trans_code
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:1878
0x7742f3 gfc_trans_if_1
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1303
0x77c39a gfc_trans_if(gfc_code*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1334
0x6f1ce7 trans_code
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:1878
0x77e271 gfc_trans_simple_do
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1924
0x77e271 gfc_trans_do(gfc_code*, tree_node*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:2057
0x6f1cba trans_code
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:1890
0x723038 gfc_generate_function_code(gfc_namespace*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-decl.c:6271
0x6f6949 gfc_generate_module_code(gfc_namespace*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:2164
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
My best regards.
[Bug fortran/78682] [Coarray] [OOP] ICE calling (locally) a TBP of a remote CAF derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78682 --- Comment #6 from Stefano Zaghi --- Created attachment 40307 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40307=edit MCVE of CAF-DT with allocatable member
[Bug fortran/78682] [Coarray] [OOP] ICE calling (locally) a TBP of a remote CAF derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78682 --- Comment #4 from Stefano Zaghi --- (In reply to janus from comment #3) > I see the ICE with 5.4.1 and 6.2.0, but I can confirm that it is gone on > current trunk. > > For which reason do you think the code is invalid? I have not yet studied in details what the standard states (if it says anything about), but Damian Rouson is very sure that it is invalid and I have great respect of Damian's words...
[Bug fortran/78682] ICE calling (locally) a TBP of a remote CAF derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78682 --- Comment #2 from Stefano Zaghi --- (In reply to Dominique d'Humieres from comment #1) > This seems to have been fixed on trunk (7.0), likely r238007. Dear Dominique, thank you for your fast replay. I can check this tomorrow after a fresh download/build of the 7.0 trunk. My best regards.
[Bug fortran/78682] New: ICE calling (locally) a TBP of a remote CAF derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78682 Bug ID: 78682 Summary: ICE calling (locally) a TBP of a remote CAF derived type Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: stefano.zaghi at cnr dot it Target Milestone: --- Created attachment 40252 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40252=edit the MCVE reproducing the ICE Dear all, I get an ICE when I try to call (locally) a type-bound-procedure of derived-type coarray on a remote image, see the attached MCVE. I know that very very probably my code is invalid with respect the current standard, but because with GNU gfortran 6.2.1 I obtain the following Internal Compiler Error, I would like to let you know. Compilation/Error results gfortran -fcoarray=lib gfortran_ice_caf.f90 gfortran_ice_caf.f90:31:0: if (this_image()==2) call core_caf[1]%core_value_print internal compiler error: in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:1818 Please submit a full bug report, with preprocessed source if appropriate. See <https://bugs.archlinux.org/> for instructions. Architecture details Linux 4.8.8-2-ARCH #1 SMP PREEMPT Thu Nov 17 14:51:03 CET 2016 x86_64 GNU/Linux Intel(R) Xeon(R) CPU X5650@2.67GHz GNU Fortran (GCC) 6.2.1 20160830 My best regards. P.S. thank you very very much for your work, you are my superheroes!
