assume: noprotect_constants generates crashing code for parameter arrays

assume: noprotect_constants generates crashing code for parameter arrays

The following code compiled with "noprotect_constants" genrates wrong code as it copies only the first field of the constant array!

program Console1

use source_1
implicit none

PARAMETER (IAB = (/1,4,8 /))

call test(NAB0,IAB)

end program Console1


module source_1





end module


This bug happens with Version

Intel Visual Fortran Package ID: w_fcompxe_2011.9.300

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

Thanks - I've escalated this as issue DPD200180394.

Retired 12/31/2016

This has been fixed for a release later this year. It requires /warn:interface to see this bug, so disabling that is a workaround.

Retired 12/31/2016

Hi Steve,

I upgraded my compiler version to 13 (XE 2013) and as you pointed out, the crash disapeared. But what's still puzzling me is the following:
I'm using "noprotect_constants" to guard procedure-calls to legacy/third-party code that have parameter(-array)s as arguments, while I'm using modules and fully-specified interfaces (with "intent") in my own code. Thus the compiler knows all the intent in/out info for calls within my code, but the noprotect_constants-switch forces it to make temporary copies for all parameter-arrays, even for the "intent in".

What I would like to have (and I think I'm not alone) is a switch that generates temporaries for calls without explicit interface but still generates fast calls (without temporaries) for calls with expicit interface.

Any comments welcome


Since providing an explicit interface does not guarantee that the called routine adheres to that interface, when such routines are subject to separate compilation there is a risk associated with having the compiler ignore the "noprotect_constants" option on a selective basis (that an explicit interface is provided).

IMO a routine that does not adhere to its interface is broken. I only want to able to compile the fastest correct code under the assumtion that all procedure adhere to their interface (which IMO is an empty requirement). With the actual compiler options I can only have either fast and potential buggy or safe and slow code. Further, the compiler should have enough information, to produce a warning when calling a routine without interface and supplying constant data as arguments; but again - there is no option for that neither.

I added a feature request for this, DPD200239590, though to be honest I don't see a strong motivation for implementing it. A program that requires /assume:noprotect_constants is, by definition, incorrect, and complicating the compiler to improve performance for incorrect programs doesn't seem like the right thing.

What I would suggest as an alternative is to write your own jacket routines for the buggy third-party routines and pass a copy of the appropriate argument. You could even give the argument in the jacket routine the VALUE attribute and the copy would be made automatically - this requires an explicit interface visible to the caller. You could then drop the use of noprotect_constants and speed up the rest of your program.

Retired 12/31/2016

Ok, I understand that jeopardizing the compiler for such a feature is not a good idea. But what about a switch for compile-time warning for calling a routine without interface with constant data. Thus users were able to find all the potentially buggy calls in large legacy code-bases. And to go even a step further, I would also appreciate an option to force fully specified interfaces when defining a routine, i.e. mandatory "intent" for every parameter.

Passing a constant without an interface would be a very common occurrence in standard Fortran. But I have seen others ask for an option to require an explicit interface for all routines, and I can see the usefulness of that. I will file a feature request for it if we don't already have one.

Retired 12/31/2016

Thank you, Steve!

Leave a Comment

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