- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is the following program valid under the current Fortran language "supported" by Intel Fortran? If it is, is the output defined by this standard (and what is it)?
type t(n) integer, len :: n end type type(t(1)), allocatable :: x print*, x%n end
This program attempts type parameter inquiry for the object x, which has no deferred type parameters. It is not allocated but Fortran doesn't seem to prohibit type parameter inquiry in this case.
ifort 19.1 presents a run-time check failure (when compiled with -check) saying:
forrtl: severe (408): fort: (7): Attempt to use pointer X when it is not associated with a target
This seems to be incorrect. Even if it is correct as a general statement, it's a bit silly to complain about the pointer x, given that x isn't a pointer.
I originally reported this issue to Intel support (request 03214162) in January 2018 and yesterday had an update saying
I just double checked with a compiler developer who also represents Intel in the Fortran standards group. He wrote that since you are using a derived type that has not yet been allocated the compiler behavior is undefined. And that is what that error message is telling you.
The workaround is to allocate the derived type.
Is it really necessary under the Fortran standard for the object to be allocated, or is this a compiler bug?
In contrast, we know that the program
character, allocatable :: c print*, kind(c), len(c) end
is expressly permitted by the Fortran standard, with defined results. If the above program with parameterized derived type is not permitted does this mean that type parameter inquiry like
character, allocatable :: c print*, c%kind, c%len end
is also not permitted (and c must first be allocated) even though the inquiry function references are, or is there an explicit difference between intrinsic and derived types in type parameter inquiry? ifort's run-time check does not complain in this final case.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
An interesting question. My initial inclination is to say that you should be able to ask about x%n, even if x is not allocated, as long as the length type parameter of x is not deferred (F2018 9.4.5p2) Note 1 in that section is revealing (emphasis mine):
A type-param-inquiry has a syntax like that of a structure component reference, but it does not have the
same semantics. It is not a variable and thus can never be assigned to. It can be used only as a primary in
an expression. It is scalar even if designator is an array.
I think that the support response you got was mistaken, but this is understandable as the standard is complex and if you don't find the right words (as I didn't initially) you could come to a different conclusion. I suggest that you reopen or respond to the issue and point them to my comments here so they can take another look.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For whatever it's worth, the code snippets do not appear to be standard-conforming to me:
- The standard is clear when it states for an unallocated allocatable variable, "It shall not be supplied as an actual argument corresponding to a nonallocatable nonoptional dummy argument, except to certain intrinsic inquiry functions."
- Intrinsic inquiry function LEN accepts an unallocated CHARACTER variable as long as its length parameter is not deferred. However KIND is not listed as accepting an unallocated allocated variable, so 'KIND(c)' does not appear conformant.
Re: the message from Intel Fortran compiler with the run-time check on, perhaps Intel Fortran team will be kind enough to make it sound more meaningful for the customer and place the message in actual context of the code in Fortran rather than issue something primitive which appears to pertain to the specific compiler implementation it follows, likely using C++.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
KIND is an intrinsic inquiry function which does not explicitly state that not-allocated arguments are not permitted. This corresponds to "except to certain intrinsic inquiry functions" of your quote, and the explicit statement in the Fortran standard that
Unless the description of an intrinsic inquiry function states otherwise, these arguments are permitted to be unallocated allocatable variables or pointers that are undefined or disassociated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
An interesting question. My initial inclination is to say that you should be able to ask about x%n, even if x is not allocated, as long as the length type parameter of x is not deferred (F2018 9.4.5p2) Note 1 in that section is revealing (emphasis mine):
A type-param-inquiry has a syntax like that of a structure component reference, but it does not have the
same semantics. It is not a variable and thus can never be assigned to. It can be used only as a primary in
an expression. It is scalar even if designator is an array.
I think that the support response you got was mistaken, but this is understandable as the standard is complex and if you don't find the right words (as I didn't initially) you could come to a different conclusion. I suggest that you reopen or respond to the issue and point them to my comments here so they can take another look.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you Steve. I've updated the support ticket pointing here and will update once I have a reply.
If the standard does want to prohibit this inquiry, then it certainly tries very hard to hide that fact!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Research A. wrote:KIND is an intrinsic inquiry function which does not explicitly state that not-allocated arguments are not permitted. This corresponds to "except to certain intrinsic inquiry functions" of your quote, and the explicit statement in the Fortran standard that
Unless the description of an intrinsic inquiry function states otherwise, these arguments are permitted to be unallocated allocatable variables or pointers that are undefined or disassociated.
Good point, I overlooked section 16.1, p2 in the standard.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The update seems to support Steve Lionel's conclusion:
That team of Fortran experts on the Forum is amazing! We stand corrected. The compiler should accept that.
The workaround is to allocate the object until the problem is fixed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ifort 19.1.2 now correctly inquires of the non-deferred type parameter in the example of the original post, both with and without error checking enabled. The workaround of allocating the object is no longer required.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I was going to suggest just turning off pointer checking, but that results in an access violation/segfault.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page