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

PDT: KIND and LEN type parameters are mutually exclusive

Harald1
New Contributor II
673 Views

The following invalid code is erroneously accepted by ifort 2021.4.0:

  type :: bad_pdt (k,l)
     integer, kind, len      :: k = 1
     integer, len, kind      :: l = 1
     character(kind=k,len=l) :: c
  end type bad_pdt
end

 The Fortran 2018 standard (and similarly 2003+) state:

 

F2018: 7.5.3.1  Type parameter definition statement

R732  type-param-def-stmt is
      integer-type-spec, type-param-attr-spec :: type-param-decl-list

R734  type-param-attr-spec  is KIND or LEN

(3) The type-param-attr-spec explicitly specifies whether a type parameter is a kind parameter or a length parameter.

Thus the KIND and LEN attributes are mutually exclusive.

The correct solution would be to reject the code sample.

 

Thanks,

Harald

 

0 Kudos
1 Solution
Barbara_P_Intel
Moderator
599 Views

I filed a bug report on this issue for you, CMPLRIL0-34368. I'll let you know when a fix is available.



View solution in original post

0 Kudos
4 Replies
jimdempseyatthecove
Honored Contributor III
643 Views

FWIW your type declaration is (may be) non-conformant. From:

   A type declaration has the general form:

   type-spec[ [, att] ... ::] v[/c-list/][, v[/c-list/]] ...
Thus your:
...
  integer, kind, len  :: k = 1
 
Is ?ambiguous??
 
The presence of the "integer, kind, len" part of the statement are of the old/legacy format declaring kind and len as integers. However, you statement contains "::", which now state that the ", kind, len" portion are attributes. So, which are they? Attributes or variables of integer type? If attribute, there is no attribute named "kind" nor "len".
 
Jim Dempsey
0 Kudos
Harald1
New Contributor II
632 Views

Jim,

 

I was talking about F2003 parameterized derived types.  I wouldn't call that "old/legacy" yet.  Maybe you are thinking of some old/legacy DEC/Intel extension?

The compiler should provide a means to reject non-standard-conforming code.  The above sample violates F2018:R734.  "ifort -stand" remains quiet.

 

Harald

 

0 Kudos
Steve_Lionel
Honored Contributor III
617 Views

I agree that the compiler should complain. This is not an extension, just a lack of error checking.

0 Kudos
Barbara_P_Intel
Moderator
600 Views

I filed a bug report on this issue for you, CMPLRIL0-34368. I'll let you know when a fix is available.



0 Kudos
Reply