Passing derived data types

[creepa1982]

Dear all,

I am trying to pass a variable of derived data type to different subroutines. I receive the following error:

policies.f90(37): 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.
1>call dummy(grid)
1>-----------^
1>compilation aborted for policies.f90 (code 3)

The type is defined in a module all subroutines have access to and includes (among others) allocatable arrays. Calling the above dummy subroutine from "main.f90" works fine. But a call from policies.f90 (which is called by main.f90) always fails with the above error code.

The dummy subroutine looks like this:
Subroutine Dummy(Grid)
use params ! This is where the type SplineGrid is defined
Type(SplineGrid) :: Grid
write(*,*) 'Do nothing'
End Subroutine Dummy

Any help would be greatly appreciated.

Benjamin

[reinhold-bader]

Hello,

Internal Compiler Errors should always be reported to your compiler vendor. That being said, it is not unlikely that your code has a bug. Since you do not really provide enough information (optimally a small test case which allows to reproduce the problem), it is only possible for me to speculate what this might be... since your subroutine dummy() apparently is defined outside any module your application might simply miss the explicit interface required for a derived type argument.

Regards
Reinhold

[Steven_L_Intel1]

Please attach a small (if possible) but complete example source thst shows the problem. Also tell us which exact compiler version you are using and which compile options are used.

[creepa1982]

Quoting - Steve Lionel (Intel)

Please attach a small (if possible) but complete example source thst shows the problem. Also tell us which exact compiler version you are using and which compile options are used.

Hey,

thanks for the replies! I was able to reproduce the error with a stylized version of my code(see attachment). The error seems to be caused by the associate construct in policies.f90. Commenting it out, the code runs fine.

I am using compiler version 11.1.038 on a 32 bit intel dual core. Command line options are standard Visual Fortran, i.e. /nologo /debug:full /Od /gen-interfaces /warn:interfaces /module:"Debug" /object:"Debug" /traceback /check:bounds /libs:static /threads /dbglibs /c .
In the full code version I am also using /Qopenmp.

Thanks a lot,
Benjamin

[Steven_L_Intel1]

Thanks - I can reproduce this and will report it to the developers. The issue ID is DPD200139530.

[creepa1982]

Quoting - Steve Lionel (Intel)

Thanks - I can reproduce this and will report it to the developers. The issue ID is DPD200139530.

In case someone else has the same problem: I have replaced the associate construct with pointers and everything works fine.

I thougt "Associate" would simply set pointers so I am a little surprised this makes a difference.

Anyway thanks for the support!

Benjamin

[Steven_L_Intel1]

ASSOCIATE is not pointers, though I suppose it looks that way at times.

[creepa1982]

Quoting - Steve Lionel (Intel)

Thanks - I can reproduce this and will report it to the developers. The issue ID is DPD200139530.

Sorry for this naive question, but where can I look up this ID?

Benjamin

[Kevin_D_Intel]

You can't. It mayappear in a Knowledge base article or in the "Fixes Lists" (here), but it is an internal id from our Developer defect tracking system. I assume perhaps you are interested in the resolution status. The defect is fixed internally and the fix will be available in a future 11.1 release. Our next scheduled 11.1 updateis around mid-October, but as with any scheduled release, that's subject to change.

Steve will update this post when the fix is available, so stay tuned.....

[Steven_L_Intel1]

Right - I will update this thread when there is news. This bug has been fixed in our sources and the fix has been approved for inclusion in the next 11.1 update. I think it is November rather than October.

[creepa1982]

Quoting - Steve Lionel (Intel)

Right - I will update this thread when there is news. This bug has been fixed in our sources and the fix has been approved for inclusion in the next 11.1 update. I think it is November rather than October.

Allright, thanks for letting me know

[Steven_L_Intel1]

This problem is corrected in 11.1 Update 3, available now.