gfortran: unexpected 'has no IMPLICIT type' error for a type-bound function returning a procedure pointer

[FortranFan]

FYI only to anyone interested in GNU Fortran front-end: as far as I can tell, the following simple code is standard-conforming but gfortran GCC 7.0 experimental version gives an unexpected 'has no IMPLICIT type' error.

-- begin code --
module m

implicit none

abstract interface
function I_f() result( r )
real :: r
end function I_f
end interface

type, abstract :: a_t
private
procedure(I_f), nopass, pointer :: m_f => null()
contains
private
procedure, pass(this), public :: f => get_f
end type a_t

contains

function get_f( this ) result( f_ptr )

class(a_t), intent(in) :: this
procedure(I_f), pointer :: f_ptr

f_ptr => this%m_f

end function get_f

end module m
-- end code --

Upon compilation,
function get_f( this ) result( f_ptr )
1
Error: Symbol 'get_f' at (1) has no IMPLICIT type

[herrman...@gmail.com]

On Thursday, October 13, 2016 at 7:51:18 PM UTC-7, FortranFan wrote:
> FYI only to anyone interested in GNU Fortran front-end:
> as far as I can tell, the following simple code is
> standard-conforming but gfortran GCC 7.0 experimenta
> l version gives an unexpected 'has no IMPLICIT type' error.

I suspect that you get that message when it doesn't know
the type for procedure(l_f).

That is, you might get a similar message if you:

function f(x) result(y)
type(doesntexist), pointer :: y

where you might expect a message about type(doesntexist) instead.

Or I could be completely wrong on this.

[Arjen Markus]

The code is accepted by Intel Fortran 15.

I tried it with gfortran 5.4.0 and I got the error you mentioned. Also if I drop the "result(f_ptr)" attribute and use the function name. So the "result" keyword is not the cause.

Regards,

Arjen

[FortranFan]

On Friday, October 14, 2016 at 12:48:07 AM UTC-4, herrman...@gmail.com wrote:

> ..

>
> I suspect that you get that message when it doesn't know
> the type for procedure(l_f).
>

> ..

>
> Or I could be completely wrong on this.
>

> ..


I would think all the function needs is the "I_f" aspect which is defined in the module itself within the abstract interface.

[FortranFan]

On Friday, October 14, 2016 at 7:20:16 AM UTC-4, Arjen Markus wrote:

> ..

>
> The code is accepted by Intel Fortran 15.
>
> I tried it with gfortran 5.4.0 and I got the error you mentioned. Also if I drop the "result(f_ptr)" attribute and use the function name. So the "result" keyword is not the cause.
>

> ..

@Arjen,

Thanks for your follow-up. Yes, I too don't think the RESULT keyword is the cause, a simpler version of the code in the original post compiles ok, see below.

My hunch is this probably is a Fortran 2003 feature not fully supported yet in the context of type-bound procedures.

-- a variation --

module m

implicit none

abstract interface

function I_f() result( j )
integer :: j

end function I_f
end interface

procedure(I_f), pointer :: f

contains

function get_f() result( f_ptr )

procedure(I_f), pointer :: f_ptr

f_ptr => f

return

[paul.rich...@gmail.com]

This is now PR78013 in gcc Bugzilla. This is one and the same as PR61420. I have a simple fix for both which is just now undergoing regression testing.

Best regards

Paul

[FortranFan]

On Monday, October 17, 2016 at 1:01:00 PM UTC-4, paul.rich...@gmail.com
wrote:

> ..

>
> This is now PR78013 in gcc Bugzilla. This is one and the same as PR61420. I have a simple fix for both which is just now undergoing regression testing.
>
> Best regards
>
> Paul

Thanks much, Paul, for your followup. Your responses and work is immeasurably superior and faster than commercial software I'm forced to use, that's amazing indeed. The "world" of FSF and FOSS are very fortunate to benefit from your contributions.

Best Regards,

[paul.rich...@gmail.com]

You are entirely welcome! In fact, I have just committed the patch to the development 7-branch (trunk) and will commit to 5- and 6-branches this weekend.

By the way, it was not an implementation problem. Rather it was the omission of a single line to find the type for the lhs expression in the proc pointer assignment.

Paul

[FortranFan]

On Monday, October 17, 2016 at 2:06:29 PM UTC-4, paul.rich...@gmail.com wrote:

> ..
>

> By the way, it was not an implementation problem. Rather it was the omission of a single line to find the type for the lhs expression in the proc pointer assignment.
>

> ..

Paul,

Thanks for the additional information: to me, that's sign of very well-written code when you can implement the fixes so quickly and any issues (we're all human) are often one to a few lines of corrections.

By the way, please note I'm not a gfortran user - I only *dabble* with features related to Fortran standard revisions starting with Fortran 2003, more out of an intellectual curiosity about the direction of Fortran. For a recent thread on this forum, I was curious and trying out some options with a couple of compilers when I noticed the error from gfortran:

https://groups.google.com/forum/#!topic/comp.lang.fortran/yIrwAd5NiNc

I decided to post it here as FYI; as I've mentioned elsewhere, I've constraints with using GCC bugzilla and I prefer to post any info on an online forum, more as an FYI to the world-wide community of FOSS who are also amazing Googlers, apologies for my truant behavior.