[Bug fortran/86863] [OOP][F2008] type-bound module procedure name not recognized

2018-11-20 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86863

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Paul: Can the bug be marked as resolved?

[Bug fortran/86863] [OOP][F2008] type-bound module procedure name not recognized

2018-08-23 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86863

--- Comment #3 from Paul Thomas  ---
Author: pault
Date: Thu Aug 23 06:27:54 2018
New Revision: 263799

URL: https://gcc.gnu.org/viewcvs?rev=263799=gcc=rev
Log:
2017-08-23  Paul Thomas  

PR fortran/86863
* resolve.c (resolve_typebound_call): If the TBP is not marked
as a subroutine, check the specific symbol.

2017-08-23  Paul Thomas  

PR fortran/86863
* gfortran.dg/submodule_32.f08: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/submodule_32.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/86863] [OOP][F2008] type-bound module procedure name not recognized

2018-08-07 Thread zbeekman at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86863

Zaak  changed:

   What|Removed |Added

 CC||zbeekman at gmail dot com

--- Comment #2 from Zaak  ---
It appears that `module procedure` can also cause a link-time error that will
get resolved when switching to `module subroutine`. I haven't dug into this too
much, but I get missing/unresolved symbols, but if I switch the implementation
to `module subroutine` then the unresolved symbols go away.

The linker errors look like:

Undefined symbols for architecture x86_64:
  "___vtab_fgr_mesh_Fgr.5058", referenced from:
  ___timestep_MOD_store in Timestep_implementation.f90.o
  "___vtab_grid_index_Fd_grid.5056", referenced from:
  ___timestep_MOD_store in Timestep_implementation.f90.o
  "___vtab_material_type_Material.5041", referenced from:
  ___timestep_MOD_store in Timestep_implementation.f90.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

Changing `module procedure` to `module subroutine` and adding the interface
variables, variable declarations, etc. resolves this linker issue. So it seems
that the compiler generates code looking for the wrong symbols when `module
procedure` is used vs `module subroutine` inside of a submodule (maybe?)

I'm not entirely sure how to go about creating a minimally complete verifiable
example for this. Compilation was done with GFortran 8.2 (installed via
Homebrew) on macOS and the CMake based build system has the compiler drive the
linker, we don't call ld directly ourselves anywhere.

[Bug fortran/86863] [OOP][F2008] type-bound module procedure name not recognized

2018-08-06 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86863

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-06
 CC||janus at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org ---
(In reply to Damian Rouson from comment #0)
> With gfortran 7.3.0 and 6.4.0, the code below causes an ICE.
>
> [..]
> 
>  call object%foobar
>   1
> Error: ‘foobar’ at (1) should be a SUBROUTINE

I can confirm this error with version 6 to trunk, but I don't see the ICE.