ICE with 11.1.064

[Alexis_R_]

[fortran]module test_mod

	CONTAINS

	!>	\brief	Returns a pointer to the function described by the text string
	FUNCTION FIND_INTERPOLATION_FUNCTION(DESCRIPTION)
		IMPLICIT NONE
		! Arguments
		CHARACTER(LEN=24),	INTENT(IN)	::	DESCRIPTION
		! Result
		PROCEDURE(INTERPOLATION_FUNCTION), POINTER	::	FIND_INTERPOLATION_FUNCTION
		! Private variables

		! Start work
	END FUNCTION FIND_INTERPOLATION_FUNCTION

end module test_mod

program hello
	use test_mod
	implicit none
end program hello[/fortran]

The above code is not valid (because the abstract interface declaration of INTERPOLATION_FUNCTION is missing), so I'd expect ifort to throw an error. Instead, I get an ICE:

[bash]% ifort -c helloworld.f90 
: catastrophic error: **Internal compiler error: segmentation violation signal raised** 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 helloworld.f90 (code 3)
% ifort --version
ifort (IFORT) 11.1 20091130
Copyright (C) 1985-2009 Intel Corporation.  All rights reserved.[/bash]

[Steven_L_Intel1]

Thanks for reporting this. My testing shows that this behavior happens even if the interface is defined, or an intrinsic type is specified for the interface. I have escalated this as issue DPD200149801.

[Steven_L_Intel1]

This is an interesting issue. After consulting with members of the Fortran standards committee, we find that the current standard (and the draft of F2008) is ambiguous and contradictory regarding the ability to declare a function result variable as a procedure pointer.

What we will be doing for now is to make this an error, until the standards committee decides how it should be handled. A workaround is to return a derived type containing a procedure pointer.

[Alexis_R_]

Thanks for looking into this & suggesting a workaround.

Returning a procedure pointer came naturally to me once I started getting used to abstract interfaces :), I can live with wrapping it in a derived type though, so... thanks!