Conflict with intrinsic Intel extension

Conflict with intrinsic Intel extension

I want to have a generic function called AND taking various kinds and numbers of arguments. The functions and the generic interface are placed in module(s). When trying to compile I get the following error message:

internal error: Please visit '' for assistance

I found this very strange until I found that the same happens with an analogue OR function. There is no entry for AND in the documentation (integrated with VS), and I got no hits when searching for 'and', but there is an entry for OR (without the green colored font, but with a reference to the standart intrinsic IOR). When checking IAND I see (in green writing) that it is an Intel extension to be able to use AND as an alias for the standard IAND. As I guess that this is the root to my problem; it possible to 'turn off' Intel procedure aliases?

PS: if, instead of placing the functions and interface in a module, I place them in a PROGRAM it compiles...

10 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

If your AND function is declared with explicit interface, or even with EXTERNAL, this would "turn off" the legacy extension of AND() as an intrinsic. Regardless, an internal error report is evidence of a compiler bug, and, if produced by a current compiler release, should be reported with a test case to reproduce it.



	PROCEDURE and_gen

	INTEGER,PARAMETER :: log_gen = KIND(.true.)
	ELEMENTAL FUNCTION and_gen(log1,log2) RESULT(res)


		LOGICAL(log_gen),INTENT(IN)			:: log1,log2

		LOGICAL(log_gen)				:: res
		IF(log1) THEN

			IF (log2) THEN

				res = .TRUE.




		res = .FALSE.



I can see the ICE when I try to compile the module source given in #2 with the current Windows 32-bit compiler ( If the interface name is changed to something else, e.g., MyAnd, the ICE goes away.

Thanks - we'[ll take a look.

Retired 12/31/2016

Nevertheless, for now, is it possible to switch off all non-standard functions?

No, it is not. Use of EXTERNAL is the proper way to declare that specific functions are not intrinsic.

The real problem here is that we apparently did not do a perfect job of allowing the MODULE keyword in MODULE PROCEDURE to be omitted. If you insert that keyword in the interface (MODULE PROCEDURE and_gen) it works. I will escalate this to the developers. Issue ID is DPD200239082.

Retired 12/31/2016

Ok, inserting the MODULE keyword surely did the trick!

But will I have to use the EXTERNAL keyword everytime I want to use these functions even though they are available through USE association?

The language doesn't really give a way to undefine an intrinsic in the context of a generic interface. You're allowed to override the intrinsic with your own definition where the arguments match the intrinsic if you want. You don't need to use EXTERNAL in this case.

Retired 12/31/2016

This is fixed for a release later this year.

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today