[Bug fortran/66544] [F03] ICE on function with procedure-pointer result in combination with implicit none

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66544

--- Comment #9 from Gerhard Steinmetz  
---

Frankly speaking, it's difficile. Smells more invalid than valid.
As a side note, I do not have any production code using a contruct 
similar to that in comment 0 or in recursive_interface_*.


Still affects some examples from testsuite/gfortran.dg :
  - data_value_1.f90
  - recursive_interface_1.f90
  - recursive_interface_2.f90


$ gfortran-7-20161204 -c recursive_interface_1.f90
$ gfortran-7-20161204 -fimplicit-none -c recursive_interface_1.f90
recursive_interface_1.f90:16:0:

   function baz() result(r3)

internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1064
0x7c7b83 gfc_typenode_for_spec(gfc_typespec*, bool)
../../gcc/fortran/trans-types.c:1064
0x7c5c03 gfc_sym_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:2167
0x7c670b gfc_get_function_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:3030
0x7c68bc gfc_get_function_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:3023
0x75130f build_function_decl
../../gcc/fortran/trans-decl.c:2157
0x75674b gfc_create_function_decl(gfc_namespace*, bool)
../../gcc/fortran/trans-decl.c:2833
0x733137 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2149
0x6e72fd translate_all_program_units
../../gcc/fortran/parse.c:6025
0x6e72fd gfc_parse_file()
../../gcc/fortran/parse.c:6238
0x72b182 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug fortran/66544] [F03] ICE on function with procedure-pointer result in combination with implicit none

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66544

--- Comment #8 from janus at gcc dot gnu.org ---
(In reply to janus from comment #4)
> Btw, I don't fully understand why "implicit none" should make any difference
> here.

The problem is that we simply do not know which typespec to give to 'z' (and
thus to 'f'), therefore it stays with BT_UNKNOWN which causes the ICE. When
omitting the 'implicit none', the symbols get typed implicitly, which is not
really correct either.

If you believe it's valid, one could hack around the ICE using BT_VOID or so:

Index: resolve.c
===
--- resolve.c   (revision 243433)
+++ resolve.c   (working copy)
@@ -220,6 +220,8 @@ resolve_procedure_interface (gfc_symbol *sym)
  sym->attr.class_ok = ifc->result->attr.class_ok;
  sym->as = gfc_copy_array_spec (ifc->result->as);
  sym->result = sym;
+ if (sym->ts.type == BT_UNKNOWN && ifc->result->attr.proc_pointer)
+   sym->ts.type = BT_VOID;
}
   else
{


But that's certainly not a very nice and clean solution and I have no idea if
it would produce the expected results at runtime.

I'm still a bit doubtful if it's really valid. Are there any other compilers
which accept such a construct?

[Bug fortran/66544] [F03] ICE on function with procedure-pointer result in combination with implicit none

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66544

Gerhard Steinmetz  changed:

   What|Removed |Added

Version|5.1.1   |7.0

--- Comment #7 from Gerhard Steinmetz  
---
Update, backtrace :


$ cat z1_comment_0.f90
module m
   implicit none
contains
   function f() result(z)
  procedure(f), pointer :: z
   end
end module


$ gfortran-7-20161106 -c z1_comment_0.f90
z1_comment_0.f90:4:0:

function f() result(z)

internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1064
0x7beda3 gfc_typenode_for_spec(gfc_typespec*, bool)
../../gcc/fortran/trans-types.c:1064
0x7bce23 gfc_sym_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:2167
0x7bd92b gfc_get_function_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:3030
0x7bdadc gfc_get_function_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:3023
0x74a92f build_function_decl
../../gcc/fortran/trans-decl.c:2153
0x74fd1b gfc_create_function_decl(gfc_namespace*, bool)
../../gcc/fortran/trans-decl.c:2829
0x72d277 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2057
0x6e1cbd translate_all_program_units
../../gcc/fortran/parse.c:5931
0x6e1cbd gfc_parse_file()
../../gcc/fortran/parse.c:6144
0x725822 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/66544] [F03] ICE on function with procedure-pointer result in combination with implicit none

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66544

--- Comment #6 from Gerhard Steinmetz  
---
When running several private scripts, there was a difference between
some scripts including option -fimplicit-none, and some others that didn't.

Reducing and simplifying gave example z0.f90 from comment 1. Explicitly
including "implicit none" into source then gives first example in comment 0.


> Btw, I don't fully understand why "implicit none" should make any
> difference here.

Me too.


> There is also the very closely related PR54107, which is fixed already.

Now interestingly, compiling examples from ./gcc/testsuite/gfortran.dg/
with an additional -fimplicit-none shows the same error message as above
for these sources :

   automatic_char_len_1.f90
   data_value_1.f90
   init_flag_9.f90
   recursive_interface_1.f90
   recursive_interface_2.f90


$ gfortran-6 --version
GNU Fortran (SUSE Linux) 6.0.0 20160121 (experimental) [trunk revision 232670]

$ gfortran-6 -c recursive_interface_1.f90
# ok

$ gfortran-6 -fimplicit-none -c recursive_interface_1.f90
recursive_interface_1.f90:16:0:

   function baz() result(r3)


internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1064

[Bug fortran/66544] [F03] ICE on function with procedure-pointer result in combination with implicit none

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66544

--- Comment #5 from janus at gcc dot gnu.org ---
Note that there are other ways to generate a "recursive" interface, like:

module m
  implicit none
contains
  real function f(z)
procedure(f), pointer :: z
  end
end module

This one is compiled just fine by gfortran.

There is also the very closely related PR54107, which is fixed already. From
the discussion there it sounds like self-referential interfaces are legal in
principle.

[Bug fortran/66544] [F03] ICE on function with procedure-pointer result in combination with implicit none

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66544

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
Summary|ICE on function with|[F03] ICE on function with
   |pointer result in   |procedure-pointer result in
   |combination with implicit   |combination with implicit
   |none|none

--- Comment #3 from janus at gcc dot gnu.org ---
Note that the interface of the function 'f' is somewhat
recursive/self-referential: The function f returns a pointer to a function that
has the same interface as itself, namely returning a pointer to a function that
has the same interface as itself, returning a pointer to a function ... (ad
inf.)

I'm not sure if that is allowed in any version of the Fortran standard. There
are other self-reference restrictions in the language, e.g. for derived types,
some of which have been loosened in F08 (see e.g. PR45516).

Do you actually have a real-world problem where such a construction is
necessary, or are you just trying to break the compiler? ;)

[Bug fortran/66544] [F03] ICE on function with procedure-pointer result in combination with implicit none

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66544

--- Comment #4 from janus at gcc dot gnu.org ---
Btw, I don't fully understand why "implicit none" should make any difference
here.

I can see that it would make a difference if you don't specify an interface in
the procedure statement:

module m
  implicit none
contains
  function f() result(z)
  procedure(), pointer :: z
  end
end module

But this version works fine, with and without "implicit none". In your original
test case the interface is fully specified, i.e. nothing is really 'implicit'.

I guess the actual problem is the self reference of the interface. We should
check if this is legal, and if not reject it.