Polymorphic dummy arguments and ICE

[NotThatItMatters]

This discussion is going to be generic until I can create a suitable small test case.  I am just hoping somebody has seen this problem before and can point me in the right direction.

I am attempting to create a TYPE and a TYPE which extends the original.  I then wish to use the second (child class) in many places around my fixed-form Fortran code.  I have been getting the warning message 

warning #8499: The procedure has a dummy argument that is polymorphic. Required explicit interface is missing from original source.

Then comes the internal compiler error.  If I put an explicit interface in the code, the warning disappears but the ICE remains.

I know these statements are general, but my current "small" example has a PROGRAM, two SUBROUTINEs and 16 modules.  Once I start paring it down, I have not had much luck reproducing the ICE.

Any help would be appreciated.

Intel(R) Visual Fortran Compiler XE 15.0.4.221 [IA-32]

[Steven_L_Intel1]

Try turning off generated interface checking (/warn:interface) and see if that makes the ICE go away. We would very much like to see a test case so we can fix the ICE.

[NotThatItMatters]

The more I finagle the code, the more it becomes "funny".  As of late, when I jump out of Visual Studio and come back in, the ICE has been replaced by

libifcoremdd.lib(for_main.obj) : error LNK2019: unresolved external symbol _MAIN__ referenced in function _main

Debug\ICE.exe : fatal error LNK1120: 1 unresolved externals

And you are correct: removing the WarnInterfaces = True switch from the project makes the compile work.  I guess I can use this as a go by in my actual project for the time being.  I will attach my "small" test case in a private correspondence.  I was hoping I could make it reproducible, but the above proves it is not.

[NotThatItMatters]

I have shortened the code and am still generating the ICE when compiling Debug.  Please note the attached, which really is a "do nothing" snippet.  It generates the following when compiled in Debug.

error #7001: Error in creating the compiled module file.   [RATESET__genmod]
fortcom: Fatal: There has been an internal compiler error (C0000005)

[NotThatItMatters]

This is proving unacceptable.  I cannot compile my code to any point of satisfaction without the ICE showing up.  I am trying to do a not-so-small development task which involves the reduction of stack size and complexity by taking all my "global" arrays from the stack and putting them into a user-defined type with appropriate procedures.  These procedures are yet to be fully fledged, but the ICE is keeping anything from happening.

I have created an Interfaces module which holds the interfaces to globally accessible routines which have the class as an argument.  The module contains several named INTERFACE blocks so that the code that needs to call the routine would have something along the lines of

USE Interfaces, ONLY : Interface_Block_Name

When I compile it complains the required code has no interface and then gives the ICE.  What gives?

[NotThatItMatters]

Okay, now that I have made a fool of myself, let me try to complete the argument.  I now see that I was using the INTERFACE block incorrectly.  The block is providing an INTERFACE (hence the name) to a routine.  If I name the block, the INTERFACE has that name.  Hence I can call the routine with that name.  The code is semi-compiling now and I just need to be patient.

[FortranFan]

NotThatItMatters wrote:

Okay, now that I have made a fool of myself, let me try to complete the argument.  I now see that I was using the INTERFACE block incorrectly.  The block is providing an INTERFACE (hence the name) to a routine.  If I name the block, the INTERFACE has that name.  Hence I can call the routine with that name.  The code is semi-compiling now and I just need to be patient.

Invalid code or not, an ICE implies a compiler bug that a compiler writer would want to prevent from occurring.  Hence if you have a reproducible case, you should still report it.  In case where the code may be incorrect, the compiler should graciously point that out instead of throwing an ICE.

[Steven_L_Intel1]

I can't reproduce an ICE using the sources in post 4. Please attach a zip of buildlog.htm showing the failed build.

[NotThatItMatters]

Here is a project/solution which produces the ICE (ICEsmall).  Also attached are the contents of my Debug build folder (ICEbuild).

[Steven_L_Intel1]

I can't reproduce the ICE. The build log is puzzling - the only error (preceding the ICE) is one saying that it couldn't create the generated interface module. What happens if you delete all files from the Debug folder and do a rebuild? There may be something external to the compiler that is interfering.

[NotThatItMatters]

Steve,

I always use "Clean Solution" before a build.  I am noting manually when I do a clean I get an empty folder with only the BuildLog in it.

For what else might I look?

[NotThatItMatters]

I am now noting that I can build the darn thing without the ICE.  I do get it back from time to time by commenting sections of code and re-building.  I have yet to find a reproducible set of commands to cause it.

I am concerned that the "real" code, which obviously is much greater in complexity, will display this same behavior.  Of what sort of items "external to the compiler" might I be wary?

[IanH]

Perhaps this is silly for other reasons, but I can repeatedly get an ICE if I build all files in ICEsmall using update 1 of the beta, then compile all files using 15.0.4.221

>ifort /check:all /warn:all /standard-semantics PRECISION_SPECIFICATION.f90 RelativePermeability_Module.f90 Hysteresis_M
odule.f90 RateSet.f90 ICE.f90 ELEVATION_CORRECTION.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0 Beta Build 20150501
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

...(in a different command prompt)...

>ifort /check:all /warn:all /standard-semantics PRECISION_SPECIFICATION.f90 RelativePermeability_Module.f90 Hysteresis_M
odule.f90 RateSet.f90 ICE.f90 ELEVATION_CORRECTION.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.4.221 Build 201504
07
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.
...

err_compiler_not yet supported
RateSet.f90(31): internal error: Please visit 'http://www.intel.com/software/products/support' for assistance.
      CALL ELEVATION_CORRECTION(NVQN, II, JJ, KK, PN, P, PBOTN, hyst, &
^
[ Aborting due to internal error. ]
compilation aborted for RateSet.f90 (code 1)

[Steven_L_Intel1]

I was thinking of antivirus scanners that hold files open for "scanning" thus preventing writes. Some AV programs are worse at this than others.

Ian, I can reproduce the problem you describe but it seems different from the OP topic.

[NotThatItMatters]

The OS on which the machine is compiling the code is Windows MultiPoint Server 2012 Premium.  I am using RDP to connect as are other users.  The machine has a backup protocol, as in it has backup and recovery processes running 24/7.

[Steven_L_Intel1]

Yes, the continuous backup might be the trigger.

[jimdempseyatthecove]

>>The machine has a backup protocol, as in it has backup and recovery processes running 24/7.

If this is the cause of your problem, then talk with your system administrator to exclude the build output folders from the backup. Note, you can add a post build event to copy the files you want backed up from this (excluded from backup) folder to a different folder that gets backed up. This will prevent unnecessary overhead (and media) in backing up files you do not need backed up.

Jim Dempsey

[NotThatItMatters]

I have pretty much eliminated the ICE in this set.  No, Jim, I have not gone to that extent but the problem is rare enough with the current code as to not be troubling.  Typically if it bonks now, I restart VS and it does not bonk again.

However, I am still unable to compile my code.  I am getting a number of these errors:

error #6285: There is no matching specific subroutine for this generic subroutine call.

In order to include the static class structure in numerous global namespace routines, I have made it an argument to those routines.  To eliminate the warning about these routines being

warning #8499: The procedure has a dummy argument that is polymorphic. Required explicit interface is missing from original source.

I created an Interfaces module with many snippets along the lines of

INTERFACE BLAH
    SUBROUTINE BLAH(arguments, special, ...)
        USE special_module, ONLY : special_class
        IMPLICIT NONE
!    Type specifications for arguments
        CLASS(special_class), INTENT(IN or INOUT) :: special
    END SUBROUTINE BLAH
END INTERFACE BLAH

I then do the following in the procedures which make calls to BLAH

USE Interfaces, ONLY : BLAH

This works up to a point, but then it crashes with error #6285 at other points.  If I leave the warning #8499 all over the place, then I can guarantee the code compiles with an ICE.  So, what should I do?

[NotThatItMatters]

I am trying to come to grips with the two errors.  Error #1 occurs if I use the Interfaces module for all prototypes for routines utilizing my CLASS.  In this case I get the error #6285 for five specific prototypes explicitly used from the Interfaces module.

If I happen to comment out the USE, ONLY from the Interfaces module, I then get rampant warning #8499 AND THE INTERNAL COMPILER ERROR.  I would love to get you a SMALL version of this, but that has proven difficult.  The example I supplied is not showing precisely these characteristics and the source I have is quite large.

As a postscript, all backup and recovery software on my development machine has been removed.

[Steven_L_Intel1]

I would suggest submitting the large test case to Intel Premier Support and we'll work on it.

[NotThatItMatters]

I have submitted an issue to Intel Premier Support and have received issue number 6000125851.  I am now getting messages from Intel Premier Support saying "Waiting for customer".  When I get to the portal I get the message "You do not have access to the selected issue."  What gives?