Unresolved contained procedures at link in XE2016 Update 1

[Andrew_Smith]

I have an abstract type and 3 concrete types derived from it. The abstract type declares some deferred internal procedures and the derived types implement them. The project compiles fine under Visual Studio 2015 but link fails with unresolved references in a subroutine in a separate source. But that routine does not call any of the unresolved references.

The link error is only related to a small percentage of similar derived type structures in my project.

It is a clean build before anyone suggests this.

It is existing code and it compiles and links OK under XE 15.0.4.221.

I am not able to post the code and would need to spend some hours deriving a reproducer. But if there no other way I will do so eventually.

[Steven_L_Intel1]

I think we will need a reproducer - you don't have to "post" the code here, you can use Intel Premier Support which is private if you prefer. Do you get the errors only in a debug build? Can you post the full text of the linker error messages (please don't obscure any text in the messages)?

[Steven_L_Intel1]

Thanks for providing the linker output. It looks to me as if the compiler believes these are all external routines, not type-bound procedures. I think at this point I'll need a reproducer.

[Andrew_Smith]

I tried to make a reproducer, keeping only relevant source files and stripping out stuff not involved. I tried twice and each time all of 28 unresolved references to type bound procedures go away. XE2016 Update 2 still has this issue. It looks like we are stuck with XE2015 for some time if I cannot make a reproducer.

One odd thing to note is that the source file linked to the unresolved is not calling any of these references.

I make extensive use of private statements in modules to hide everything that is not required outside of a module since it has helped simplify module dependency calculations by visual studio/Intel compiler. If the type bound procedure itself is not public, it should be visible due to a public declaration for the derived type in question.

I will experiment with some removal of the private statements.

[Andrew_Smith]

I found a solution. I have a abstract base type with deferred procedures. These use an interface statement to define them:

type X
contains
   procedure(foo), deferred :: foo
end type

interface
   subroutine foo()
   end subroutine
end interface

By adding the word "abstract" in front of "interface" it eliminated the unresolved. XE2015 is happy without this so which compiler is correct ?

[Steven_L_Intel1]

If you don't say abstract, the interface defines an external procedure, so adding the "abstract" is the correct solution. But I would not expect an external reference just from an interface declaration.

Of course, your snippet above isn't valid syntax either so I am not really sure what you are doing. I tried to construct a test case that showed the problem and failed. I'd be happy to look at the full application - you can submit it to Intel Premier Support and ask that it be assigned to me.