Internal Compiler Error with Intel 16+ (ifort)

[Robert_M_1]

The attached code has a function interface where the function returns an array of a size not known until runtime.  The interface module compiles just fine but compiling the module that uses the procedure pointer results in an internal compiler error with Intel 16.  I've tried to simplify the example as much as possible while still maintaining a structure similar to our real code.  I've annotated the code with the following information, but making the return array in the interface a fixed size (either through an explicit integer or changing ARRSIZE to a parameter) allows the code to compile, as does removing the 'private' from the functionInterface module.  For reference, here is the error message:

010101_14248

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 functionUser.f90 (code 1)

The code compiles fine with Intel 14.0.4, 15.0.3, and 15.0.7.  It fails with Intel 16.0.4 and 17.0.0.  Please let me know if I'm doing something wrong.  If this is a compiler bug, please let me know if there is a better workaround than making the functionInterface module completely public.  Making the return array a fixed-size is not really an option for us.

545689

545690

545691

[Kevin_D_Intel]

Thank you for reporting the error. We'll investigate shortly.

[Kevin_D_Intel]

This is a compiler bug. Thank you for reducing this down to the compact reproducer. I reproduced the internal error with 17.0 and newer internal builds too. I was unable to identify a work around so I’ll let you know whether Development finds any alternative work around that meets your needs/requirements.

(Internal tracking id: DPD200419922)

[Robert_M_1]

Thank you for the quick response.  It appears that replacing the blanket 'private' directive with a list of items we wish to be private also sidesteps this issue, which is a workable solution for us right now.  However, if you come up with any additional guidance on how to avoid triggering this in the future, I'd appreciate it.