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

Type parameter inquiry for non-deferred type parameter of not-allocated allocatable object

Research_A_
Beginner
724 Views

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.

 

 

0 Kudos
1 Solution
Steve_Lionel
Honored Contributor III
724 Views

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.

View solution in original post

0 Kudos
8 Replies
FortranFan
Honored Contributor II
724 Views

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++.

0 Kudos
Research_A_
Beginner
724 Views

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.

0 Kudos
Steve_Lionel
Honored Contributor III
725 Views

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.

0 Kudos
Research_A_
Beginner
724 Views

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!

0 Kudos
FortranFan
Honored Contributor II
724 Views

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.

0 Kudos
Research_A_
Beginner
724 Views

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.

0 Kudos
Research_A_
Beginner
709 Views

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.

0 Kudos
Steve_Lionel
Honored Contributor III
724 Views

I was going to suggest just turning off pointer checking, but that results in an access violation/segfault.

0 Kudos
Reply