Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
For the latest information on Intel’s response to the Log4j/Log4Shell vulnerability, please see Intel-SA-00646
26870 Discussions

PDT: KIND and LEN type parameters are mutually exclusive

Harald1
Novice
284 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
210 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

4 Replies
jimdempseyatthecove
Black Belt
254 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
Harald1
Novice
243 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

 

Steve_Lionel
Black Belt Retired Employee
228 Views

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

Barbara_P_Intel
Moderator
211 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

Reply