Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29249 Discussions

assume: noprotect_constants generates crashing code for parameter arrays

Tobias_Loew
Novice
1,009 Views
The following code compiled with "noprotect_constants" genrates wrong code as it copies only the first field of the constant array!

program-file
/////////////////////////////////////////////////////////////////
program Console1

use source_1
implicit none

INTEGER*4 NAB0
PARAMETER (NAB0 = 3)
INTEGER*4 IAB (NAB0)
PARAMETER (IAB = (/1,4,8 /))

call test(NAB0,IAB)

end program Console1


module-file
////////////////////////////////////////////////////////////////////

module source_1
contains

SUBROUTINE test(NAB,IAB)
IMPLICIT NONE
INTEGER * 4, INTENT(IN), VALUE :: NAB !
INTEGER * 4, INTENT(IN) :: IAB(NAB) !

INTEGER*4 I

I=IAB(2)

END SUBROUTINE

end module

/////////////////////////////////////////////////////////////////////

This bug happens with Version

Intel Visual Fortran Package ID: w_fcompxe_2011.9.300

0 Kudos
9 Replies
Steven_L_Intel1
Employee
1,009 Views
Thanks - I've escalated this as issue DPD200180394.
0 Kudos
Steven_L_Intel1
Employee
1,009 Views
This has been fixed for a release later this year. It requires /warn:interface to see this bug, so disabling that is a workaround.
0 Kudos
Tobias_Loew
Novice
1,009 Views
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 Tobias
0 Kudos
mecej4
Honored Contributor III
1,009 Views
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).
0 Kudos
Tobias_Loew
Novice
1,009 Views
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.
0 Kudos
Steven_L_Intel1
Employee
1,009 Views
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.
0 Kudos
Tobias_Loew
Novice
1,009 Views
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.
0 Kudos
Steven_L_Intel1
Employee
1,009 Views
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.
0 Kudos
Tobias_Loew
Novice
1,009 Views
Thank you, Steve!
0 Kudos
Reply