[Bug fortran/92587] [9/10/11 Regression] Compiler is unable to generate finalization wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92587 --- Comment #17 from DIL --- Thanks for fixing this!
[Bug fortran/92587] Compiler is unable to generate finalization wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92587 --- Comment #7 from DIL --- Please download the Updated ICE reproducer as I explain in the comments above (the reproducer archive uploaded 2020-01-30). It builds with gcc/8.x just fine, but causes ICE in gfortranc/9.x. As I mentioned, this ICE showed up very early in the gfortran/9.x trunk (on Jan 17, 2019 it already had this ICE).
[Bug fortran/92587] Compiler is unable to generate finalization wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92587 --- Comment #5 from DIL --- If this helps, the gcc/gfortran svn repository from 17 Jan 2019 already had this regression bug while gcc/gfortran 8.2.0 did not. Hopefully this may help shorten the length of bisection.
[Bug fortran/92587] Compiler is unable to generate finalization wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92587 --- Comment #4 from DIL --- Sorry, I was removing unnecessary dependencies in order to reduce the reproducer source size, but forgot to remove PRIVATE declaration for the deleted procedures. Now fixed. It builds with gfortran-8.x but produces ICE with gfortran-9.x.
[Bug fortran/92587] Compiler is unable to generate finalization wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92587 --- Comment #3 from DIL --- (In reply to Martin Liška from comment #1) > For older GCC 8 I see: > > tensor_recursive.F90:738:36: > > private TensBodyGetDataDescr > 1 > Error: Symbol ‘tensbodygetdatadescr’ at (1) has no IMPLICIT type; did you > mean ‘tensbodygetdatatype’? > tensor_recursive.F90:734:35: > > private TensBodySetLocation >1 > Error: Symbol ‘tensbodysetlocation’ at (1) has no IMPLICIT type; did you > mean ‘tensbodygetdatatype’? > tensor_recursive.F90:714:38: > > private TensLayoutGetDataDescr > 1 > Error: Symbol ‘tenslayoutgetdatadescr’ at (1) has no IMPLICIT type; did you > mean ‘tenslayoutgetdatatype’? > tensor_recursive.F90:706:37: > > private TensLayoutSetLocation > 1 > Error: Symbol ‘tenslayoutsetlocation’ at (1) has no IMPLICIT type; did you > mean ‘tenslayoutgetbodysize’? > tensor_recursive.F90:768:37: > > private TensRcrsvGetDataDescr > 1 > Error: Symbol ‘tensrcrsvgetdatadescr’ at (1) has no IMPLICIT type; did you > mean ‘tensrcrsvgetdatatype’? > tensor_recursive.F90:769:36: > > private TensRcrsvSetLocation > 1 > Error: Symbol ‘tensrcrsvsetlocation’ at (1) has no IMPLICIT type; did you > mean ‘tensrcrsvgetlayout’? > > Is it really a valid code?
[Bug fortran/92587] Compiler is unable to generate finalization wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92587 --- Comment #2 from DIL --- Created attachment 47742 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47742=edit Updated ICE reproducer Fixed build issues for gfortran-8. Builds with gfortran-8.x but produces ICE with gfortran-9.x.
[Bug fortran/92587] New: Compiler is unable to generate finalization wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92587 Bug ID: 92587 Summary: Compiler is unable to generate finalization wrapper Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: liakhdi at ornl dot gov Target Milestone: --- Created attachment 47304 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47304=edit Complete reproducer of the reported ICE There is a regression ICE introduced in gfortran/9.x (all versions up to 9.2.0 produce this ICE). The compiler reports ICE in generate_finalization_wrapper (see below). The complete reproducer is attached (please run make.sh to build it). I could not reduce it yet to a single small source file as stripping things off makes the ICE disappear, so I apologize for supplying multiple source files. Importantly this code compiles fine with gfortran/8.x, so this ICE was introduced in gfortran/9 very early, when gfortran/9 was not yet released. My system is Ubuntu 16.04 with the gcc/9.2.0 release installed from source. gfortran -c -g tensor_recursive.F90 f951: internal compiler error: in generate_finalization_wrapper, at fortran/class.c:2009 0x588c29 generate_finalization_wrapper /home/dima/src/gcc-9.2.0/gcc/fortran/class.c:2009 0x588c29 gfc_find_derived_vtab(gfc_symbol*) /home/dima/src/gcc-9.2.0/gcc/fortran/class.c:2484 0x5e1891 gfc_find_vtab(gfc_typespec*) /home/dima/src/gcc-9.2.0/gcc/fortran/class.c:2865 0x5e1891 gfc_find_vtab(gfc_typespec*) /home/dima/src/gcc-9.2.0/gcc/fortran/class.c:2855 0x62f9b2 gfc_match_assignment() /home/dima/src/gcc-9.2.0/gcc/fortran/match.c:1378 0x64f3f4 match_word /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:65 0x64f3f4 decode_statement /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:361 0x652f24 next_free /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:1241 0x652f24 next_statement /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:1473 0x655a89 parse_executable /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:5436 0x6563a1 parse_if_block /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:4079 0x6563a1 parse_executable /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:5329 0x6563a1 parse_if_block /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:4079 0x6563a1 parse_executable /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:5329 0x656e06 parse_progunit /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:5706 0x65715e parse_contained /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:5581 0x657e5e parse_module /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:5953 0x6582ad gfc_parse_file() /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:6256 0x6a170f gfc_be_parse_file /home/dima/src/gcc-9.2.0/gcc/fortran/f95-lang.c:204 Thanks, Dmitry
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 --- Comment #20 from DIL --- (In reply to anlauf from comment #19) > Fixed on trunk and all open branches (7/8). > > Closing, as no reduced run-time testcase was provided. > Please reopen or create a new PR if an issue is found. > > Thanks for the report! Thanks for fixing this bug! Sorry, I have not had time yet to create a reduced non-trivial test case. Would you still like to add it later if I make it? If yes, should I just attach it later to this closed bug report?
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 --- Comment #14 from DIL --- (In reply to anlauf from comment #13) > (In reply to Dominique d'Humieres from comment #12) > > > Sorry, I am confused, I think Comment 1 already has such a reduced test. > > > At least the what it says there ... > > > > It is a reduced test for the ICE (as are further reduced tests in comments 3 > > and 9), > > but they do not allow to check that fortran is not producing a wrong code > > instead of an ICE. > > > > I understand > > > > > However, I do not have a working code sample to run. > > > > as asking for such a test. > > Exactly. > > Taking this PR. It has some overlap to PR85797 and can probably be fixed > with the same patch. Ok, so you are still looking for a single Fortran source file using this feature, namely optional dummy procedure pointers, that would do something non-trivial with them and produce PASS/FAIL output? If yes, then I can try making such a reduced test (if needed). I am just not familiar with GNU test requirements.
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 --- Comment #11 from DIL --- (In reply to Dominique d'Humieres from comment #10) > With the patch in comment 8 all the tests compile and the original test in > comment 0 gives ta runtime > > gfc::bank testing status:0 (PASSED): Performance: > 3532045.4736842103 > gfc::vector testing status:0 (PASSED): Performance: > 2515463.5218254919 > gfc::list testing status:0 (PASSED): Performance: > 2515463.5218254919 > gfc::tree testing status:0 (PASSED): Performance: > 1045525.1575901519 > gfc::dictionary testing status:0 (PASSED): Performance: > 836199.51143490721 > gfc::graph testing status:0 (PASSED): Performance: > 118470.61398863114 > Multi-index sort testing status:0 (PASSED): Performance: > 239778.83863299151 > Dynamic type inferrence slowdown: 0.1258 67109934.2342983 0.1312 > 67109934.23429831.0432470247796064 > > > However, I do not have a working code sample to run > > The original test is not suitable for the test suite, but the author can > probably reduce it. Sorry, I am confused, I think Comment 1 already has such a reduced test. At least the what it says there ...
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 --- Comment #6 from DIL --- (In reply to Thomas Schwinge from comment #4) > (In reply to DIL from comment #2) > > For GFORTRAN 6.4.0 and earlier, the relevant compiler bug has been fixed in > > 78300. > > Are you saying that the exact same bug reappeared here, which had previously > been discussed and fixed in PR78300? > > > (In reply to G. Steinmetz from comment #3) > > Simplified : [...] > > Thanks, ICE confirmed/still present. What I meant in Comment 2 is that this ICE might be related to 78300 that I reported in the past. Both have issues with optional dummy procedure arguments. Sorry for the confusion. This is still an open issue and I still observe this ICE with gfortran/8.2.0.
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 --- Comment #5 from DIL --- (In reply to Thomas Schwinge from comment #4) > (In reply to DIL from comment #2) > > For GFORTRAN 6.4.0 and earlier, the relevant compiler bug has been fixed in > > 78300. > > Are you saying that the exact same bug reappeared here, which had previously > been discussed and fixed in PR78300? > > > (In reply to G. Steinmetz from comment #3) > > Simplified : [...] > > Thanks, ICE confirmed/still present. This ICE is still present in gfortran/8.2.0.
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 --- Comment #2 from DIL --- For GFORTRAN 6.4.0 and earlier, the relevant compiler bug has been fixed in 78300.
[Bug fortran/83515] New: ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 Bug ID: 83515 Summary: ICE: Invalid expression in gfc_element_size Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: liakhdi at ornl dot gov Target Milestone: --- Code: https://github.com/DmitryLyakh/GFC.git To reproduce: Open Makefile, make line 138 look exactly like line 140: NO_GNU := -DNO_GNU Type "make" If you need a debuggable version (-g), please change OPT to DEV in line 9. If you need any help from me to debug the issue (we did this in the past with Paul Thomas, but not for ICE), please let me know. ICE description: source file gfc_vector.F90 is causing this: gfortran -I. -I. -c -fopenmp -O3 -DNO_GPU -DNO_AMD -DNO_PHI -DLINUX -DNO_GNU -DNO_PGI -fPIC gfc_vector.F90 -o ./OBJ/gfc_vector.o f951: internal compiler error: Invalid expression in gfc_element_size. 0x891e7f gfc_internal_error(char const*, ...) /home/dima/src/gcc/gcc/fortran/error.c:1358 0x922e6b gfc_element_size(gfc_expr*) /home/dima/src/gcc/gcc/fortran/target-memory.c:126 0x8768f9 find_intrinsic_vtab /home/dima/src/gcc/gcc/fortran/class.c:2703 0x8768f9 gfc_find_vtab(gfc_typespec*) /home/dima/src/gcc/gcc/fortran/class.c:2846 0x8a039c compare_actual_formal /home/dima/src/gcc/gcc/fortran/interface.c:2934 0x8a14d4 gfc_arglist_matches_symbol(gfc_actual_arglist**, gfc_symbol*) /home/dima/src/gcc/gcc/fortran/interface.c:3797 0x905bc2 resolve_typebound_generic_call /home/dima/src/gcc/gcc/fortran/resolve.c:6125 0x905f5e resolve_typebound_call /home/dima/src/gcc/gcc/fortran/resolve.c:6183 0x8fa4c9 resolve_typebound_subroutine /home/dima/src/gcc/gcc/fortran/resolve.c:6494 0x8fa4c9 gfc_resolve_code(gfc_code*, gfc_namespace*) /home/dima/src/gcc/gcc/fortran/resolve.c:11270 0x908aab gfc_resolve_blocks(gfc_code*, gfc_namespace*) /home/dima/src/gcc/gcc/fortran/resolve.c:10108 0x8f8fd9 gfc_resolve_code(gfc_code*, gfc_namespace*) /home/dima/src/gcc/gcc/fortran/resolve.c:11052 0x908aab gfc_resolve_blocks(gfc_code*, gfc_namespace*) /home/dima/src/gcc/gcc/fortran/resolve.c:10108 0x8f8fd9 gfc_resolve_code(gfc_code*, gfc_namespace*) /home/dima/src/gcc/gcc/fortran/resolve.c:11052 0x908aab gfc_resolve_blocks(gfc_code*, gfc_namespace*) /home/dima/src/gcc/gcc/fortran/resolve.c:10108 0x8f8fd9 gfc_resolve_code(gfc_code*, gfc_namespace*) /home/dima/src/gcc/gcc/fortran/resolve.c:11052 0x908aab gfc_resolve_blocks(gfc_code*, gfc_namespace*) /home/dima/src/gcc/gcc/fortran/resolve.c:10108 0x8f8fd9 gfc_resolve_code(gfc_code*, gfc_namespace*) /home/dima/src/gcc/gcc/fortran/resolve.c:11052 0x8fbf2f resolve_codes /home/dima/src/gcc/gcc/fortran/resolve.c:16433 0x8fbe6e resolve_codes /home/dima/src/gcc/gcc/fortran/resolve.c:16417
[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 --- Comment #23 from DIL --- Paul, Great work! Thanks a lot for fixing this. This bug was a stopper for me for 6 months, so I am really looking forward to fully switching back to my favorite gcc/gfortran compiler :)
[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 --- Comment #22 from DIL --- On the other hand, I have another test which also crashes in clone_object() for the same reason, but does not involve gfc_vector.F90. It goes through line 710 of gfc_list.F90, function ListIterAppend(), where again a concrete type is argument associated with an unlimited polymorphic dummy variable. So I suspect the _len corruption happens here as well.
[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 --- Comment #21 from DIL --- Paul, And as you have noticed, this characteristic construct is there (gfc_vector:806) :) call this%container%vec_tile(q(4))%tile_batch(q(3))%batch_seg(q(2))%seg_elem(q(1))%& _elem_ctor(elem_val,ierr,assoc_only=assoc)
[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 --- Comment #20 from DIL --- So, if we for a second trust valgrind executed on an -O3 optimized binary, then line 1402 of gfc_graph.F90, namely, ierr=git%append_vertex(vrt) should be the origin. The object vrt (type graph_vertex_t) is the object being cloned in clone_object() that contains an uninitialized field (you mentioned _len in the previous comments). In line 1113 of gfc_graph.F90, this graph_vertex_t object is passed into VectorIterAppend() (gfc_vector.F90:773) as an unlimited polymorphic dummy argument, so I guess that's where it acquires the _len field, right?
[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 --- Comment #19 from DIL --- On my Ubuntu 16.04, removing STAT= from the allocate() statement does not help unfortunately, but it now crashes via a different path, although for the same reason. I will experiment more to see if I can finally reproduce this problem in a debugger, so far I was unlucky. Interestingly, valgrind passes the DEV version (the one which fails if run standalone), but complains with the OPT version about an uninitialized stack variable. However, further inspecting the function referred to as the origin of an uninitialized stack variable does not really reveal anything. But this explains why -fno-automatic helps. Somehow it seems like an uninitialized field appears on the stack. I will continue digging to see if I can find something useful for you to inspect. Thanks for looking into this issue! Below is the valgrind output from the OPT binary: ==16508== Conditional jump or move depends on uninitialised value(s) ==16508==at 0x41D597: __stsubs_MOD_clone_object (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x424D67: __gfc_base_MOD_contelemconstruct (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x408667: __gfc_vector_MOD_vectorelemconstruct (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x40AC5B: __gfc_vector_MOD_vectoriterappend (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x418ACD: __gfc_graph_MOD_graphiterappendvertex (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x4195B7: __gfc_graph_test_MOD_test_gfc_graph (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x401FB8: MAIN__ (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x40169E: main (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508== Uninitialised value was created by a stack allocation ==16508==at 0x4191D4: __gfc_graph_test_MOD_test_gfc_graph (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508== ==16508== Conditional jump or move depends on uninitialised value(s) ==16508==at 0x4C2DB3C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==16508==by 0x41D5B0: __stsubs_MOD_clone_object (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x424D67: __gfc_base_MOD_contelemconstruct (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x408667: __gfc_vector_MOD_vectorelemconstruct (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x40AC5B: __gfc_vector_MOD_vectoriterappend (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x418ACD: __gfc_graph_MOD_graphiterappendvertex (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x4195B7: __gfc_graph_test_MOD_test_gfc_graph (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x401FB8: MAIN__ (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x40169E: main (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508== Uninitialised value was created by a stack allocation ==16508==at 0x4191D4: __gfc_graph_test_MOD_test_gfc_graph (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508== ==16508== Conditional jump or move depends on uninitialised value(s) ==16508==at 0x41D597: __stsubs_MOD_clone_object (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x424D67: __gfc_base_MOD_contelemconstruct (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x408667: __gfc_vector_MOD_vectorelemconstruct (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x40AE0D: __gfc_vector_MOD_vectoriterappend (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x418ACD: __gfc_graph_MOD_graphiterappendvertex (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x4195B7: __gfc_graph_test_MOD_test_gfc_graph (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x401FB8: MAIN__ (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508==by 0x40169E: main (in /home/div/src/ExaTensor/GFC/test_gfc.x) ==16508== Uninitialised value was created by a stack allocation ==16508==at 0x4191D4: __gfc_graph_test_MOD_test_gfc_graph (in /home/div/src/ExaTensor/GFC/test_gfc.x)
[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758 --- Comment #21 from DIL --- Greatly appreciate!
[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758 --- Comment #19 from DIL --- Hi Paul, Great, thanks a lot! That was pretty quick. Upon a chance, as there is still a momentum :), could you please take a brief look at bug #80850 to see whether it may be related since you mentioned "allocation with source" in the previous comment? That's exactly what 80850 is about. If fails to allocate a previously nullified pointer with a sourced allocate(), complaining that the pointer is already allocated. From what I could deduce from valgrind, somehow the code produced by the sourced allocate() here encounters a corrupted internal pointer representation. If you need any debugging information/screenshots from me, I will be happy to provide (I did not really see an easy way to reduce the code).
[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758 --- Comment #16 from DIL --- Hi Paul, Thanks for looking into this issue. I ran the debugger again. The vtab corruption occurs upon the first encounter in function VectorIterElement() in line 720 of gfc_vector.F90. Just to make sure, that line begins with: elem_p=>this%container%vec_tile(q(4))%... Before that line, the elem_p (cep) vtab looks fine. After that line it gets bad. Please let me know if you need more information from the debugger.
[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758 --- Comment #10 from DIL --- (In reply to Thomas Koenig from comment #9) > I just checked on powerpc64 with a rather current trunk with > > gfc::bank testing status:0 (PASSED): Performance: > 2888199.6889235629 > gfc::vector testing status:0 (PASSED): Performance: > 2108461.4164096378 > gfc::list testing status:0 (PASSED): Performance: > 2108461.4164096378 > gfc::tree testing status:0 (PASSED): Performance: > 327471.70199407206 > gfc::dictionary testing status:0 (PASSED): Performance: > 281461.77688575117 >16383 > gfc::graph testing status:5 (FAILED) > Multi-index sort testing status:0 (PASSED): Performance: > 120529.43369575262 > Dynamic type inferrence slowdown: 0.2418 67110738.2064877 0.5810 > 67110738.20648772.4023336875488646 > > Is this an indication of success or of failure? It is a failure, seems to occur along the same code path, but without a SegFault.
[Bug fortran/81758] [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758 --- Comment #6 from DIL --- It is not that I am not willing to, I just do not see an easy way to reduce the relevant code. For now, I have attached a debugger screenshot (jpg above) to show you the details of the problem. The segfault occurs when running the binary test_gfc.x produced by the Makefile, specifically in the GFC::graph test (gfc_graph.F90). In the bottom left corner of the .JPG file you will see the exact callstack at the point of crash. In the central window, you will see the line 742 of gfc_vector.F90, specifically: val_p => cep%get_value(errc) The pointer "cep" is class(gfc_cont_elem_t) defined in gfc_base.F90. Now if you look at the right window on the .JPG where I inspect the content of the "cep", you will see a completely messed up _vptr table, where the type-bound procedure bindings are associated with wrong procedures from a completely unrelated type "vector_t" from gfc_vector.F90. In particular, if you look at the "get_value" binding, that is, the procedure we are trying to call in line 742 above, you will see that it is wrongly associated with vector_t%vectorlowerbound, a totally unrelated type-bound procedure from a different type. That's exactly why the segfault occurs (please see the callstack). All other type-bound bindings of "cep" are wrong as well, except maybe few.
[Bug fortran/81758] [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758 --- Comment #7 from DIL --- P.S. I do not have GCC-8.0 installed anywhere.
[Bug fortran/81758] [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758 --- Comment #5 from DIL --- Created attachment 42373 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42373=edit Debugger screenshot
[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 --- Comment #12 from DIL --- Could you please tell me if there is a way I can check whether the dissociated unlimited polymorphic pointer (class(*), pointer), which is set to NULL, is indeed set to a clean state internally? That is, could you please tell me the size and structure of the internal representation of a class(*) pointer and what the proper values of those components would be when the pointer is set to NULL()? I am still trying to understand why the sourced allocate() statement sees that pointer as ALLOCATED. Basically, I want to inspect the internal state of the class(*) NULL pointer to make sure that the problem indeed occurs inside the sourced allocate() statement. Thanks!
[Bug fortran/81758] [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758 --- Comment #2 from DIL --- No, at this point I do not, unfortunately. These OOP bugs tend to show up at higher levels, so it is not always clear how to reduce it to something small. I will try to reduce it to something smaller, but not sure how far. For example, the current problem shows up in the implementation of a vector container (gfc_vector.F90), but only when it is used to implement something more complex, specifically the graph container in this case (gfc_graph.F90). The latter uses three containers in its implementation: vector, list, and dictionary, so it depends on all of those.
[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 --- Comment #11 from DIL --- The additional problem you observe with gfortran/7.1 described in the comment "2017-05-26 22:43:21 UTC" seems to be another gfortran compiler bug introduced in GCC/7.0. I have just filed a bug report for it (#81758). To my current understanding, it is not related to this (potential) bug report which is observed with GCC/5.x and GCC/6.x. Also, in the context of the current bug report, for more convenience I have isolated the problematic section of my code in a separate few-line procedure that can be found in stsubs.F90 line 275 (function clone_object). I still observe the same wrong behavior: Sourced allocate() returns "Attempt to allocated and allocated object" on an explicitly dissociated pointer (meaning allocation status is Unallocated). Additionally, I ran more tests on different platforms and here is the statistics: a) The sourced allocation crash I observe is non-deterministic; b) It is more likely to appear in the "-O0 -g" build than in "-O3"; c) It disappears in GDB; d) It always crashes on Mac; e) It crashes ~ 50% of times on Ubuntu Linux; f) It does not crash on some platforms with RedHat Linux. The code repo is the same: https://github.com/DmitryLyakh/GFC.git or https://gitlab.com/DmitryLyakh/GFC.git Any response or comment would be highly appreciated! Thanks.
[Bug fortran/81758] New: [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758 Bug ID: 81758 Summary: [OOP] Broken vtab Product: gcc Version: 7.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: liakhdi at ornl dot gov Target Milestone: --- It seems like something is seriously wrong with GFORTRAN 7.x virtual table constructor. I observe an incorrect association of type-bound procedures to their calling names. For example, in procedure, public:: method_name=>ProcedureName I observe method_name to be associated with another (unrelated) type-bound procedure from a completely different type (pretty much all of them are associated with wrong procedures). If you clone my GFC (Generic Fortran Containers) code from https://github.com/DmitryLyakh/GFC.git or https://gitlab.com/DmitryLyakh/GFC.git then in file gfc_vector.F90 lines 740-742 you will see that a pointer "cep" is associated and is trying to invoke one of its type-bound procedures "get_value()". However the debugger shows that get_value() in _vptr is currently associated with another type-bound procedure from a completely different type vector_t, specifically its type-bound procedure VectorLowerBound(), which does not make any sense. Other type-bound procedures in "cep" also associated with wrong procedures. As a consequence, the call crashes with invalid memory reference. This is only observed with GCC 7. To build my code, just type make and run the binary.
[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 --- Comment #10 from DIL --- Sorry, just wanted to clarify few things. I am still struggling with this issue I reported. However I am not sure if you could every reproduce it (it seemed like you observed a different issue)? Namely, if by running the binary built from here "https://gitlab.com/DmitryLyakh/GFC.git; you could see that the allocate() statement in gfc_base.F90:343 fails to allocate a dissociated pointer (dissociated in the previous line)? For convenience I removed few unneeded things from the code, so the code now directly proceeds to the problematic path and explicitly (manually) crashes (via divide by zero) to reveal the callstack when allocate() fails. I reproduced the problem on multiple Linux machines with GNU 5.3.0, 5.4.0, and 6.3.1. The problems shows up non-deterministically, so the binary needs to be executed 5-10 times. If I build the binary with -O3, the problem shows up much less often. Also, another big complication is that I could never reproduce the failing behavior inside gdb (it always works fine in gdb). Additionally, as I mentioned before, the binary seems to be VALGRIND clean. I am running out of ideas how to figure out what is going on wrong in that allocate() statement. We tried to look in the GFORTRAN source "gcc-5.4.0/gcc/fortran/trans-stmt.c:6132", but it seems like allocate() is actually parsed to something and not called as a runtime function, so there is no way for us to understand why allocate() sees an explicitly dissociated pointer as already allocated (and why this is happening only occasionally and not every time). Any ideas from you guys would be appreciated. Thanks! Dmitry
[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 --- Comment #4 from DIL --- Offset of zero is fine. I have never observed this SegFault before. I ran the test on multiple machines with GCC/5.3.0, GCC/5.4.0, and GCC/6.3.1. Also, as I mentioned before, the test passed the VALGRIND check. Would you be able to point me to the specific line of the deepest user-level procedure in the call stack where the segfault occurs? Was it line 744 of __gfc_vector_MOD_vectoriterelementvalue (from your previous comment)?
[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 --- Comment #2 from DIL --- I have fixed all issues reported by VALGRIND so the code now is valgrind-clean. However, the problem I reported still shows up from time to time (only when the code is compiled with -g and no optimization: BUILD_TYPE = DEV). The test which fails depends on a number of source files, so I do not really see a clear way to localize the problem in a small code snippet. In fact, the ALLOCATE() statement which fails works just fine when called from other places. I thought you might have some tools to inspect the ALLOCATE() code to see why it sees a NULLIFIED pointer as ALLOCATED when the error message is triggered (the exact location of the ALLOCATE statement is specified in the previous message). But I am not sure how hard this would be. Also, I haven't had a chance to try the new 7.1 compiler. Thanks, Dmitry
[Bug libfortran/80850] New: Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 Bug ID: 80850 Summary: Sourced allocate() fails to allocate a pointer Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: liakhdi at ornl dot gov Target Milestone: --- Hello, Code repo: https://gitlab.com/DmitryLyakh/GFC Build: Type make. Problem (bug): Please run the binary test_gfc.x 5-10 times (it is quick). On my Ubuntu laptop some (not all) of these identical runs crash with a message from allocate(): "Attempt to allocate an allocated object" This crash happens in gfc_base.F90 line 343. As you will see, the allocate() statement is trying to clone an object via the sourced allocation. The corresponding class(*) pointer "new_el" is explicitly nullified in line 342. Thus, I do not see how I could get the above "Attempt to allocate an allocated object" error. If you change the BUILD_TYPE in Makefile (line 9) from "DEV" to "OPT" (optimized), the problem disappears. New versions of GCC have the same problem (up to 6.3). The Intel and IBM XL compilers pass all tests without any problems. Thanks, Dmitry
[Bug fortran/79311] [OOP] ICE in generate_finalization_wrapper, at fortran/class.c:1992
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79311 --- Comment #10 from DIL --- Thanks for fixing.
[Bug fortran/79311] New: internal compiler error: generate_finalization_wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79311 Bug ID: 79311 Summary: internal compiler error: generate_finalization_wrapper Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: liakhdi at ornl dot gov Target Milestone: --- Created attachment 40641 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40641=edit Source reproducer Below is the GFORTRAN internal compiler error backtrace I encountered. There are four source files in the attachment and a simple make script. Files dil_basic.F90, tensor_algebra.F90, and stsubs.F90 are just auxiliary utilities. The problematic source file is tensor_recursive.F90. There are three classes defined there: tens_signature_t, tens_shape_t, and tens_header_t. The latter class contains two components of the former types (tens_signature_t and tens_shape_t). While Final subroutines in the tens_signature_t and tens_shape_t compile fine, the Final subroutine in the composite class fails to compile with an internal compiler error (below). If you comment it in the type declaration (tens_header_t), it will compile. Please help fixing this issue: f951: internal compiler error: in generate_finalization_wrapper, at fortran/class.c:1972 0x63e92a generate_finalization_wrapper ../../cray-gcc-6.2.0/gcc/fortran/class.c:1972 0x63e92a gfc_find_derived_vtab(gfc_symbol*) ../../cray-gcc-6.2.0/gcc/fortran/class.c:2404 0x63fcf5 finalize_component ../../cray-gcc-6.2.0/gcc/fortran/class.c:995 0x63ed9e generate_finalization_wrapper ../../cray-gcc-6.2.0/gcc/fortran/class.c:2128 0x63ed9e gfc_find_derived_vtab(gfc_symbol*) ../../cray-gcc-6.2.0/gcc/fortran/class.c:2404 0x6b02e0 gfc_resolve_finalizers ../../cray-gcc-6.2.0/gcc/fortran/resolve.c:12198 0x6c5573 resolve_fl_derived ../../cray-gcc-6.2.0/gcc/fortran/resolve.c:13463 0x6c0476 resolve_symbol ../../cray-gcc-6.2.0/gcc/fortran/resolve.c:13762 0x6d9dbb do_traverse_symtree ../../cray-gcc-6.2.0/gcc/fortran/symbol.c:3926 0x6c36aa resolve_types ../../cray-gcc-6.2.0/gcc/fortran/resolve.c:1 0x6bf0df gfc_resolve(gfc_namespace*) ../../cray-gcc-6.2.0/gcc/fortran/resolve.c:15665 0x6aaaf4 gfc_parse_file() ../../cray-gcc-6.2.0/gcc/fortran/parse.c:6059 0x6ebed2 gfc_be_parse_file ../../cray-gcc-6.2.0/gcc/fortran/f95-lang.c:201
[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 --- Comment #12 from DIL --- Indeed, thanks again.
[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 --- Comment #10 from DIL --- Thanks!
[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 --- Comment #8 from DIL --- Is there a way to download the GCC source with this patch applied?
[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 --- Comment #4 from DIL --- Created attachment 40019 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40019=edit Source file
[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 --- Comment #3 from DIL --- Created attachment 40018 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40018=edit Source file
[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 --- Comment #2 from DIL --- Created attachment 40017 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40017=edit Source file
[Bug fortran/78300] New: Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 Bug ID: 78300 Summary: Failure to compile a Fortran-2003 code with an optional dummy procedure argument. Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: liakhdi at ornl dot gov Target Milestone: --- Source code: https://gitlab.com/DmitryLyakh/GFC.git The minimal reproducer can be created by taking only three source files from GFC: gfortran -c dil_basic.F90 gfortran -c timers.F90 gfortran -c -DNO_GNU gfc_base.F90 (GFORTRAN fails to compile if you define -DNO_GNU) If you look inside gfc_base.F90 line 240 (subroutine ContElemConstruct), you will see the exact place where the compile error occurs. For some reason, it has problems with an optional dummy procedure argument. I believe this is a compiler bug. All other compilers I tried compile and run the code fine (Cray, PGI, XL, probably Intel as well). Please help fixing this problem in gfortran. Thanks!
