Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29273 Discussions

Non-abstract types with un-implemented deferred bindings

IanH
Honored Contributor III
505 Views
(I know there's a few abstract type/inheritance issues floating outstanding, so apologies if this has already been reported.)

I think C429 in F2003 (C427 in F2008) means that the compiler should be giving me a good kicking for the following, but with 12.0.5 on IA32 (sorry for forgetting to specify that last time...) with /check:all /warn:all my transgressions pass unnoticed.

[fortran]PROGRAM AbstractlyConcrete

  IMPLICIT NONE
  
  TYPE, ABSTRACT :: abstract_type
  CONTAINS
    PROCEDURE(at_DeferredProc), DEFERRED :: DeferredProc
  END TYPE abstract_type
  
  ABSTRACT INTERFACE
    SUBROUTINE at_DeferredProc(obj)
      IMPORT :: abstract_type
      IMPLICIT NONE
      !----
      CLASS(abstract_type), INTENT(IN) :: obj	  
    END SUBROUTINE at_DeferredProc
  END INTERFACE

  ! oops, forgot ", ABSTRACT"...  
  TYPE, EXTENDS(abstract_type) :: still_abstract_type
  END TYPE still_abstract_type

  !****

  TYPE(still_abstract_type) :: look_mum_no_bindings
  
  ! CALL look_mum_no_bindings%DeferredProc     ! Results in link error
  
END PROGRAM AbstractlyConcrete
[/fortran]

(I'm sure the compiler has picked me up on this before (?) - it sticks in my head because the reported location of the error was something daft like the first line of the file or the location of the parent type, rather than the location of the definition of the extension type.)
0 Kudos
3 Replies
Steven_L_Intel1
Employee
505 Views
You had me a bit confused at first with your constraint references until I realized that you had them reversed. It's C429 in F2008, C427 in F2003.

I agree that the compiler should give an error for this and I will let the developers know. Thanks. Issue ID is DPD200172982.
0 Kudos
IanH
Honored Contributor III
505 Views
Tacked on here because I think its a consequence of the potential link error (which I think others have reported) in the previous example.

12.0.5 compiles and links this (as I think it should, despite the program not being terribly useful), but 12.1.0 gives a silly link error.

[fortran]MODULE Parents
  IMPLICIT NONE  
  PRIVATE  
  
  TYPE, ABSTRACT, PUBLIC :: Parent
  CONTAINS
    PROCEDURE(which_the_linker_should_not_be_looking_for), DEFERRED :: Proc
  END TYPE Parent
  
  ABSTRACT INTERFACE 
    SUBROUTINE which_the_linker_should_not_be_looking_for(op)
      IMPORT :: Parent
      IMPLICIT NONE
      CLASS(Parent), INTENT(IN) :: op
    END SUBROUTINE which_the_linker_should_not_be_looking_for
  END INTERFACE       
END MODULE Parents

MODULE ATypes
  USE Parents
  IMPLICIT NONE
  PRIVATE
  
  TYPE, PUBLIC, EXTENDS(Parent) :: TypeA
  CONTAINS
    PROCEDURE :: Proc => a_Proc
  END TYPE TypeA
CONTAINS  
  SUBROUTINE a_Proc(op)
    CLASS(TypeA), INTENT(IN) :: op
  END SUBROUTINE a_Proc
END MODULE ATypes

MODULE BTypes
  USE Parents
  IMPLICIT NONE
  PRIVATE
  
  TYPE, PUBLIC, EXTENDS(Parent), ABSTRACT :: TypeB
  END TYPE TypeB
CONTAINS      
  SUBROUTINE sub
    USE ATypes
    CLASS(TypeA), ALLOCATABLE :: conn
    !****
    ALLOCATE(TypeA:: conn)    
  END SUBROUTINE sub
  
  SUBROUTINE sub2(op)
    CLASS(TypeB), INTENT(IN) :: op
    !****
    CALL op%Proc
  END SUBROUTINE sub2
END MODULE BTypes

PROGRAM ThatIsRatherShort
  IMPLICIT NONE  
END PROGRAM ThatIsRatherShort
[/fortran]


[plain]>ifort /check:all /warn:all /standard-semantics abstract-links.F90
Intel Visual Fortran Compiler XE for applications running on IA-32, Version 12.1.0.233 Build 20110811
Copyright (C) 1985-2011 Intel Corporation.  All rights reserved.

abstract-links.F90(30): remark #7712: This variable has not been used.   [OP]
  SUBROUTINE a_Proc(op)
--------------------^
Microsoft  Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:abstract-links.exe
-subsystem:console
abstract-links.obj
abstract-links.obj : error LNK2001: unresolved external symbol _WHICH_THE_LINKER_SHOULD_NOT_BE_LOOKING_FOR
abstract-links.exe : fatal error LNK1120: 1 unresolved externals[/plain]
0 Kudos
Steven_L_Intel1
Employee
505 Views
The missing error as originally reported has been fixed in our sources. The fix will appear in a future release.

The linker error is one we have several reports on and we're working on it.
0 Kudos
Reply