LNK2001: unresolved external symbol XE 2015 in GENMOD

[Frankcombe__Kim]

I recently upgraded from XE 2013 SP1 to XE 2015 (15.0.22) and with no changes to the code am getting LNK2001: unresolved external symbol errors from the Interface modules automatically generated by the compiler when using the -warn:all switch.

Hopefully attached is a code snippet showing the problem along with a batch file to compile with from the 64 bit command line.

The problem is relatively simple. My main program IPProc calls S/R AVERAGEIP

PROGRAM IPPROC
IMPLICIT NONE
CALL AVERAGEIP()
END

AVERAGEIP contains a S/R AVERMED which dimensions an array using a variable declared in AVERAGEIP

SUBROUTINE AVERAGEIP()
IMPLICIT NONE

INTEGER :: NRPTS

RETURN
CONTAINS
! even though this S/R is no longer called if I remove it the link error disapears
  SUBROUTINE AVERMED()
  REAL, DIMENSION(NRPTS) :: ZVEC
  ZVEC = 0
  RETURN
  END SUBROUTINE AVERMED
END SUBROUTINE AVERAGEIP

The integer NRPTS is local to AVERAGEIP yet when I compile with-check:all -debug:full -traceback -warn:all I get the following error

ipproc.obj : error LNK2001: unresolved external symbol AVERAGEIP__GENMOD_mp_NRPTS

Which does not make sense. NRPTS is noted in the object code for IPPROC which also does not make sense.

Can you please confirm this is a bug and not something I am doing and advise on a patch.

Cheers

Kim

[mecej4]

Apart from the spurious link-time error that you report, the test code provided has another bug: averageip.f90", line 4: 'NRPTS' is used but never set. 

[Frankcombe__Kim]

True but in the full version of the code it is set and the error is still produced.  This snipped was designed to reduce the amount of code to the bare minimum which could show the problem. The full program has over 100 source code files and many more routines, I didn't think that posting that would be helpful or make me very popular:-)

Cheers

Kim

[Steven_L_Intel1]

I can reproduce this. As a workaround, add -warn:nointerface after -warn:all. I'll send this on to the developers, Issue ID is DPD200371104.

[Frankcombe__Kim]

Thanks Steve.

[Frankcombe__Kim]

I just installed the latest update, 16.0.110 and this bug still exists! I'm wondering what my annual maintenance payments buy me :-(

Not Happy.

Kim

[Kevin_D_Intel]

I'm sorry Kim we were unable to address this in the initial 16.0 release. I can genuinely say that our Development teams do their best to resolve defects and add features just as quickly as possible. Steve did request in the internal tracking id he filed that we resolve this in 16.0 so I believe our Development teams will do their best to do so.

Steve provided what seemed like a reasonable work around to hopefully lessen the impact of this issue, although I understand that's not zero impact. I am hopeful that was usable in your case but please let me know if not.

[Frankcombe__Kim]

Thanks Kevin

Yes Steve's workaround does allow me to compile the code but does not then check for interface mismatches so if I want to check new routines at compile time I need to run the compiler once with -warn:all and if that compiles OK then re-run with -warn:all -warn:nointerface, a two step process.

The programs each consist of a hundred or so subroutines ranging in age from 40 years to recent so keeping track of all the interfaces is not always something I can do in my head and thus rely on the compiler to check for me. I build two versions of each of my programs, one with full debugging and one optimised for speed. The optimised version does not have any or the warnings so compiles and links without problem, it would be good if the debug version did too.

I look forward to a patch, hopefully within this maintenance period.

Cheers

Kim

[Kevin_D_Intel]

I hadn't considered the potential of the iterative compilation scenario. I will add that additional detail to the internal tracking id so others understand there is a bit more impact beyond just the initial problem reported.

Thank you and we'll keep you updated.

[Kevin_D_Intel]

The PSXE 2015 Update 5 released last month was the last scheduled update for the PSXE 2015 release. There might be another unscheduled update in the future.

The complexity of the underlying fix/changes and associated risk are factors considered when determining if changes for any defect can be incorporated into a specific compiler branch. We don't have details about the underlying fix/changes for this case yet.

I added your comment to the internal tracking id so Development is aware of your request and can consider whether the underlying changes could be included in any possible PSXE 2015 update in the future.

[Kevin_D_Intel]

@Rainer,

It would help us to have a reproducer for your case so that can be analyzed to ensure you experienced the same underlying issue.

A complete reproducer is best/preferred, but with your noted number of files we recognize may not be easy or possible. If not, then at least seeing the problematic source file might enable our Developers to diagnose if your case shares the same underlying conditions/issue.

If necessary to safeguard your source, you can send me a private reply with the file(s) attached to avoid exposing those publically in a reply here.

Thank you.

[Frankcombe__Kim]

Kevin

Given that the problem was initiated between version 14 and 15 I would have thought that it would not be rocket science to track it down. Sorry I just don't buy your complexity argument above. We are all programmers so know the issues involved but working bugs back to a routine and then comparing the routine with the old working version is not a qualification for a Nobel prize in coding. Yes you have a lot of lines of code and yes you have to deal with dependencies on external uncontrolled code but relative to the complexity of the problems your compiler code is used for these should all be child's play.

I'd like to think that the compiler code is written with a view to making life easier for scientists who code as well as those who code for science.

Cheers

Kim

[Lorri_M_Intel]

Hi Kim -

     I think you might have misunderstood Kevin's point.

     First, we have a potential fix-in-hand for your problem, and really, we need to see Rainer's example to know if we've fixed his situation as well.

     Now, as to the "complexity" issue:  In general, the concern is that an edit to fix Problem A could have the unfortunate effect of breaking Feature B.

     In the final release of a code stream, it is completely unacceptable to render any feature unusable; I'm sure you would agree with that.

    For any code to be checked into a product code stream, it must pass our standard peer-code review PLUS an additional review from a senior engineer.   Part of that additional review is an evaluation of the likelihood of breaking existing user code  versus the impact of the user's workaround.

    That's where the "complexity" attribute comes into play, in evaluating a code-edit's "safeness" for a mature code stream.

    By the way, I didn't call it out above, but of course any code checked into any of our development streams must pass a battery of regression and other tests.

          I hope this helps -

                                   --Lorri

[Frankcombe__Kim]

Thanks Lorri

Yes I understand and appreciate the process you are working through but I'm afraid it doesn't ease the frustration at this end.

Cheers

Kim

[Frankcombe__Kim]

I've just downloaded and installed 2016 Update 1 in the hope that this problem would have been fixed. It hasn't! I reported this bug when version 2015 was released and since then there have been two releases. This bug does not get a mention in the Known Issues in the latest release notes and despite looking I couldn't find a bug fix list for this most recent version. What is my maintenance buying me and what will it take to have something that used to work, work again? For the moment I'll keep using the 2013 version which at least appears to work and is less work than the workaround above. That effectively wastes my last maintenance payment.

Still not happy!

Kim

[Steven_L_Intel1]

Kim,

This fix went in too late for Update 1 - it will be in Update 2, scheduled for February. Since this issue affects linking only, it would be straightforward to have a "checking" configuration that used /warn:interface to check for errors at compile time and a "release" configuration that omitted this allowing the link to complete.

[Frankcombe__Kim]

Steve

Thanks for the update news, I look forward to February!

I do have a debug version and a production version already, it is just that on the debug version I do want to check the interfaces at compile time. So as noted above I have to compile the debug version once with /warn:all to check interfaces and then with /warn:nointerface in order to link it. Given that I can't see any difference in the production code performance between the 2013/14 and 2016 versions it is just as easy to stick with the working version until the new one is fixed.

Cheers

Kim

[Frankcombe__Kim]

I'm delighted to be able to confirm that XE_2016_update2 fixes this problem, thank you.

I'll start building using XE2016 rather than 2014 which was the last version that did not have this issue.

Cheers

Kim

[Lorri_M_Intel]

Kim -

    Thank you so much for letting us know.   I have to admit though, that when I saw there was a reply on the thread, my first thought was "OMG, I screwed up the fix!"   HA!   Very relieved to hear otherwise!

           --Lorri