Associate construct ICE

[netphilou31]

Hi,

Before deploying the latest version of the compiler (XE 2016), I was trying to compile some existing code and I got an ICE in every routine that uses the associate construct. The construct is used to associate a local variable to a derived type that is allocated through the malloc function. Wou will find attached a simple Visual Fortran project that compiles and runs fine with the compiler version we are currently using (Intel(R) Visual Fortran Compiler XE 14.0.0.103 [IA-32]) but generates an ICE with version 16.0 as shown below:

------ Rebuild All started: Project: associate_ICE, Configuration: Debug Win32 ------
Deleting intermediate files and output files for project 'associate_ICE', configuration 'Debug|Win32'.
Compiling with Intel(R) Visual Fortran Compiler 16.0 [IA-32]...
CmpdDef.f90
V:\Tests\associate_ICE\associate_ICE\CmpdDef.f90(6): warning #6379: The structure contains one or more misaligned fields.   [TTCORRELATION]
Mod_PropData.f90
associate_ICE.f90
ResetTPropData.for
0_1855
V:\Tests\associate_ICE\associate_ICE\ResetTPropData.for(11): catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.
compilation aborted for V:\Tests\associate_ICE\associate_ICE\ResetTPropData.for (code 1)

Build log written to  "file://V:\Tests\associate_ICE\associate_ICE\Debug\BuildLog.htm"
associate_ICE - 1 error(s), 1 warning(s)
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

I have been able to mangage the situation by removing the use of the associate construct but I would like to know if it's a compiler bug or if my way of using the construct is wrong (but not detected in previous versions).

Best regards,

[Steven_L_Intel1]

An ICE is always a compiler bug. Always. I will check this out and escalate as necessary. Issue ID <tbs>

[netphilou31]

Thanks Steve !

Best regards,

Phil.

[Steven_L_Intel1]

Escalated as issue DPD200381359. I was unable to get this to compile in earlier versions as far back as 13.1, but I could see that maybe your full sources did compile earlier. Your use of a use-associated Cray-pointee assumed-size array gave me the shivers, but the pointee and assumed-size aspects did not contribute to the problem. You might want to consider use of allocatable arrays, just as a general comment.

[netphilou31]

That's strange, because it compiles with my version (14.0.0.103). I am not sure that the main program was well written, as some checks are missing, but it can allow to test the console app.

To come back to your comment, originally the derived type was shared with the calling process (a Delphi application) and sharing allocatable arrays is very difficult because Delphi does not know anything about the Fortran array descriptor structure which is used when you declare a derived type member with the pointer attribute (and because I did not want to use arrays with predefined dimensions). I know that this may be a bad practice and also that it could lead to memory problems but I am using this technique for a while and it is sometimes difficult to correct wrong habits.

Best regards,

Phil.

[Steven_L_Intel1]

I didn't test that specific 14.0 version - I tend to keep around only the last update from old versions. Nevertheless, the bug has been there for a while. Even with nothing in the ASSOCIATE block it still fails, so there's something about the ASSOCIATE itself that the compiler doesn't like.

I understand you have your reasons for doing it with integer pointers, and that's ok.

[Steven_L_Intel1]

This has been fixed for a major release later this year.

[netphilou31]

Many thanks steve.