[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #12 from Alberto Luaces ---
It seems to be slightly different:
(gdb) p expr->ts.type
$7 = BT_PROCEDURE
(gdb) p expr->symtree->name
$8 = 0x770244e8 "@1179"
(gdb) p expr->where
$9 = {nextc = 0x0, lb = 0x0}
Maybe it will be clearer if I manage to write the example.
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #10 from Alberto Luaces --- Ok, indeed they were some warnings. I had to use _current_locus, as you suggested, so now all of them are pointed at the end of the file. Yes, I am using OOP: we have a "states" class that has its assignment and copy methods. Those are the ones that I think that they are called implicitly by the compiler, and gfortran is struggling to point exactly where. I think now I may be able to get a minimal case for aiding solving this bug. Let me see if I can. [4/126] Building Fortran object CMakeFiles/MBSLIM.dir/solidos/solidos_Sensib.f90.o [...]solidos/solidos_Sensib.f90:1001:28: 1001 | END SUBMODULE SOLIDOS_Sensib |1 Warning: Non-RECURSIVE procedure ‘statescopystates’ at (1) is possibly calling itself recursively. Declare it RECURSIVE or use ‘-frecursive’ [...]solidos/solidos_Sensib.f90:1001:28: 1001 | END SUBMODULE SOLIDOS_Sensib |1 Warning: Non-RECURSIVE procedure ‘statesassignstates’ at (1) is possibly calling itself recursively. Declare it RECURSIVE or use ‘-frecursive’ [...]solidos/solidos_Sensib.f90:1001:28: 1001 | END SUBMODULE SOLIDOS_Sensib |1 Warning: Non-RECURSIVE procedure ‘statecopystate’ at (1) is possibly calling itself recursively. Declare it RECURSIVE or use ‘-frecursive’ [...]solidos/solidos_Sensib.f90:1001:28: 1001 | END SUBMODULE SOLIDOS_Sensib |1 Warning: Non-RECURSIVE procedure ‘stateassignstate’ at (1) is possibly calling itself recursively. Declare it RECURSIVE or use ‘-frecursive
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #8 from Alberto Luaces --- No, I meant building *gcc* with those flags, but alas each gcc compilation stage was still building with "-O2" so almost all of the compiler structures are still optimized. Nevertheless I did what you suggest and climbed up those 6 levels to find that indeed expr->where has null fields. To me it is not very strange since in my code there is a structure that has copy and assignment members. gfortran is arguing about them being called in another module, but of course there is no physical place where they are called, as this is done implicitly by the compiler when using those kind of objects, if I am correct. I am rebuilding with your suggested gfc_current_locus change and reporting the results.
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #6 from Alberto Luaces --- Thanks a lot for the guidance. This is the backtrace of the last call to gcc_assert() that makes it crash. It says something about a non-recursive function likely calling itself. I will inspect my source, even it is a bit too big. Maybe a better solution would be if I compiled gcc with debugging flags. Can I just use C_FLAGS="-O0 -g" and CXX_FLAGS="-O0 -g" at configure time, or if is there a specific configure flag? 1078gcc_assert (loc->nextc - loc->lb->line >= 0); (gdb) bt #0 gfc_format_decoder (pp=0x2706750, text=0x7fffb840, spec=0x2708d10 "L", precision=, wide=false, set_locus=false, hash=false, quoted=0x7fffb667, buffer_ptr=0x2708b00) at ../../gcc-13.2.0/gcc/fortran/error.cc:1078 #1 0x01b44c0a in pp_format (pp=, text=text@entry=0x7fffb840) at ../../gcc-13.2.0/gcc/pretty-print.cc:1475 #2 0x01b34e02 in diagnostic_report_diagnostic (context=0x26ee380 , diagnostic=diagnostic@entry=0x7fffb840) at ../../gcc-13.2.0/gcc/diagnostic.cc:1592 #3 0x0071cbc8 in gfc_report_diagnostic (diagnostic=0x7fffb840) at ../../gcc-13.2.0/gcc/fortran/error.cc:890 #4 gfc_warning(int, const char *, typedef __va_list_tag __va_list_tag *) (opt=0, gmsgid=0x1c9c420 "Non-RECURSIVE procedure %qs at %L is possibly calling itself recursively. Declare it RECURSIVE or use %<-frecursive%>", ap=ap@entry=0x7fffb9c8) at ../../gcc-13.2.0/gcc/fortran/error.cc:923 #5 0x0071d287 in gfc_warning (opt=opt@entry=0, gmsgid=gmsgid@entry=0x1c9c420 "Non-RECURSIVE procedure %qs at %L is possibly calling itself recursively. Declare it RECURSIVE or use %<-frecursive%>") at ../../gcc-13.2.0/gcc/fortran/error.cc:954 #6 0x007a275f in resolve_procedure_expression (expr=0x32a9530) at ../../gcc-13.2.0/gcc/fortran/resolve.cc:1956 #7 resolve_variable (e=0x32a9530) at ../../gcc-13.2.0/gcc/fortran/resolve.cc:6066 #8 gfc_resolve_expr (e=e@entry=0x32a9530) at ../../gcc-13.2.0/gcc/fortran/resolve.cc:7302 #9 0x0079ffca in gfc_resolve_expr (e=0x32a9530) at ../../gcc-13.2.0/gcc/fortran/resolve.cc:7267 #10 resolve_structure_cons (expr=, init=init@entry=1) at ../../gcc-13.2.0/gcc/fortran/resolve.cc:1341 #11 0x007b0f02 in resolve_values (sym=0x3285270) at ../../gcc-13.2.0/gcc/fortran/resolve.cc:12802 #12 0x007c79d3 in do_traverse_symtree (st=, st_func=st_func@entry=0x0, sym_func=0x7b0e80 ) at ../../gcc-13.2.0/gcc/fortran/symbol.cc:4198 #13 0x007d080d in gfc_traverse_ns (ns=, sym_func=) at ../../gcc-13.2.0/gcc/fortran/symbol.cc:4223 #14 0x007a7671 in resolve_types (ns=ns@entry=0x2bf2140) at ../../gcc-13.2.0/gcc/fortran/resolve.cc:17932 #15 0x007ae8dd in gfc_resolve (ns=0x2bf2140) at ../../gcc-13.2.0/gcc/fortran/resolve.cc:18029 #16 0x0079d711 in resolve_symbol (sym=) at ../../gcc-13.2.0/gcc/fortran/resolve.cc:16601 #17 0x007c79d3 in do_traverse_symtree (st=, st_func=st_func@entry=0x0, sym_func=0x79b5f0 ) at ../../gcc-13.2.0/gcc/fortran/symbol.cc:4198 #18 0x007d080d in gfc_traverse_ns (ns=, sym_func=) at ../../gcc-13.2.0/gcc/fortran/symbol.cc:4223 #19 0x007a759f in resolve_types (ns=ns@entry=0x2b5ed60) at ../../gcc-13.2.0/gcc/fortran/resolve.cc:17914 #20 0x007ae8dd in gfc_resolve (ns=0x2b5ed60) at ../../gcc-13.2.0/gcc/fortran/resolve.cc:18029 #21 0x0079d711 in resolve_symbol (sym=) at ../../gcc-13.2.0/gcc/fortran/resolve.cc:16601 #22 0x007c79d3 in do_traverse_symtree (st=, st_func=st_func@entry=0x0, sym_func=0x79b5f0 ) at ../../gcc-13.2.0/gcc/fortran/symbol.cc:4198 #23 0x007d080d in gfc_traverse_ns (ns=, sym_func=) at ../../gcc-13.2.0/gcc/fortran/symbol.cc:4223 #24 0x007a759f in resolve_types (ns=ns@entry=0x27b4340) at ../../gcc-13.2.0/gcc/fortran/resolve.cc:17914 #25 0x007ae8dd in gfc_resolve (ns=0x27b4340) at ../../gcc-13.2.0/gcc/fortran/resolve.cc:18029 #26 0x0079b5de in gfc_resolve (ns=) at ../../gcc-13.2.0/gcc/fortran/resolve.cc:18016 #27 0x0078dbf0 in gfc_parse_file () at ../../gcc-13.2.0/gcc/fortran/parse.cc:6861 #28 0x007e6160 in gfc_be_parse_file () at ../../gcc-13.2.0/gcc/fortran/f95-lang.cc:229 #29 0x00d021fe in compile_file () at ../../gcc-13.2.0/gcc/toplev.cc:444 #30 0x006df6fe in do_compile (no_backend=false) at ../../gcc-13.2.0/gcc/toplev.cc:2125 #31 toplev::main (this=this@entry=0x7fffe0de, argc=, argc@entry=13, argv=, argv@entry=0x7fffe208) at ../../gcc-13.2.0/gcc/toplev.cc:2277 #32 0x006e13bb in main (argc=13, argv=0x7fffe208) at ../../gcc-13.2.0/gcc/main.cc:39
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 Alberto Luaces changed: What|Removed |Added CC||aluaces at udc dot es --- Comment #4 from Alberto Luaces --- I got the same error in almost the same circumstances (crash in error.cc:1078). I have a large codebase and I could not prepare a minimal testcase, but I have built gfortran 13 from source with the aim to debug the crash. Hoewever, even I set "set follow-fork-mode children", f951 crashes and I cannot navigate through the backtrace nor see the arguments of the functions. Is there any reference for debugging gcc in order to send some useful information to this bug?
[Bug fortran/97245] New: ASSOCIATE intrinsic does not recognize a ponter variable the second time it is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97245 Bug ID: 97245 Summary: ASSOCIATE intrinsic does not recognize a ponter variable the second time it is used Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: aluaces at udc dot es Target Milestone: --- Created attachment 49289 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49289=edit Minimal working example In the attached example, the second call to associate() makes the compiler error with "Error: ‘pointer’ argument of ‘associated’ intrinsic at (1) must be a POINTER", although it is correct and the first use passes: MODULE formulaciones IMPLICIT NONE ABSTRACT INTERFACE SUBROUTINE proc_void() IMPLICIT NONE END SUBROUTINE proc_void end INTERFACE PROCEDURE(proc_void), POINTER:: pADJSensib CONTAINS subroutine calculo() implicit none LOGICAL step IF(associated(pADJSensib)) THEN CALL pADJSensib ENDIF IF(associated(pADJSensib)) THEN CALL pADJSensib END IF end subroutine calculo END MODULE formulaciones
[Bug fortran/89943] New: Submodule functions are not allowed to have C binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89943 Bug ID: 89943 Summary: Submodule functions are not allowed to have C binding Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: aluaces at udc dot es Target Milestone: --- The submodule module Foo_mod interface module subroutine runFoo4C(ndim) bind(C, name="runFoo") use, intrinsic :: iso_c_binding implicit none integer(c_int32_t) , intent(in) :: ndim end subroutine runFoo4C end interface contains end module Foo_mod submodule (Foo_mod) Foo_smod contains module subroutine runFoo4C(ndim) bind(C, name="runFoo") use, intrinsic :: iso_c_binding implicit none integer(c_int32_t) , intent(in) :: ndim end subroutine runFoo4C end submodule Foo_smod is giving the following error: BIND(C) attribute at (1) can only be used for variables or common blocks That is, so far we cannot have a BIND(C) procedure in the interface of a submodule. The discussion at https://stackoverflow.com/questions/54857067/fortran-c-interoperable-submodule-procedure-with-bindc-reports-error-when-comp says it should be legal, so it seems it is a bug in gfortran.
[Bug fortran/88286] New: gfortran reports conflicting intent(in) with an intent(in) declared class variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88286 Bug ID: 88286 Summary: gfortran reports conflicting intent(in) with an intent(in) declared class variable Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: aluaces at udc dot es Target Milestone: --- I get the error test_bug.f90:19:16: INTENT(IN) b 1 Error: INTENT (IN) conflicts with INTENT(IN) at (1) with the attached minimal working example. The error is issued at the last function, but it is not triggered if I remove either the first or the second. If the parameter "b" is not a CLASS reference but a base type, the test passes as well, so I think it has to be something regarding polymorphic types. MODULE MOD_BUG IMPLICIT NONE TYPE BT INTEGER I END TYPE BT CONTAINS FUNCTION si_p_loc(b) CLASS(BT)::b LOGICAL si_p_loc INTENT(IN) b END FUNCTION si_p_loc FUNCTION si_v_loc(b) CLASS(BT)::b LOGICAL si_v_loc INTENT(IN) b END FUNCTION si_v_loc END MODULE MOD_BUG
[Bug fortran/82783] New: gfotran ICEs when compiling polymorphic function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82783 Bug ID: 82783 Summary: gfotran ICEs when compiling polymorphic function call Product: gcc Version: 7.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: aluaces at udc dot es Target Milestone: --- Created attachment 42504 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42504=edit Minimal test example with Makefile The attached test example triggers an ICE when it steps into a polymorphic function call.
