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

Problem with using derived type components of CHARACTER type

FortranFan
Honored Contributor III
583 Views

Consider the simple code example for a "dictionary" as shown below.  When a named constant is used in a structure constructor instead of a string literal, the code does not work as expected with Intel Fortran (Compiler XE 15.0.0.108) but it does with gfortran.  I think this is a bug in Intel Fortran.  See line #13 where named constant FOO is used - if it is replaced with "foo", then the code works with Intel Fortran as expected; with gfortran, it works both ways.

   MODULE m
   
      IMPLICIT NONE
      
      PUBLIC
      
      !..
      CHARACTER(LEN=*), PARAMETER :: FOO = "foo"
      TYPE t
         CHARACTER(LEN=80) :: Str
         INTEGER :: Val
      END TYPE t
      TYPE(t), PARAMETER :: TPAR(3) = [ t("bar", 1), t("foobar", 2), t(FOO, 3) ]

   CONTAINS
   
      PURE ELEMENTAL FUNCTION GetVal(InStr) RESULT(OutVal)
       
         !.. Argument list
         CHARACTER(LEN=*), INTENT(IN) :: InStr
         !.. Function result
         INTEGER :: OutVal
         
         !..
         INTEGER :: I
         
         !..
         OutVal = 0
         
         Loop_Get: DO I = 1, SIZE(TPAR)
            IF (InStr == TPAR(I)%Str) THEN
               OutVal = TPAR(I)%Val
               EXIT Loop_Get
            END IF
         END DO Loop_Get
         
         !..
         RETURN
      
      END FUNCTION GetVal       
      
   END MODULE m
   

   PROGRAM p
   
      USE m, ONLY : TPAR, GetVal
      
      IMPLICIT NONE
      
      !..
      INTEGER :: I
      INTEGER :: LS
      
      !..
      PRINT*, " Test #49: Dictionary Test"
      
      !..
      WRITE(6,11)
      DO I = 1, SIZE(TPAR)
         LS = LEN_TRIM(TPAR(I)%Str)
         WRITE(6,12) I, TPAR(I)%Str(1:LS), LS
      END DO

      !..
      PRINT*, " bar    = ", GetVal("bar")
      PRINT*, " foobar = ", GetVal("foobar")
      PRINT*, " foo    = ", GetVal("foo")
            
      !..
      STOP 
    
   11 FORMAT(T5," I",T10,"TPAR(I)%Str",T25,"Length")
   12 FORMAT(T5,I2,T10,A,T25,I2)
   
   END PROGRAM p

The program output with Intel Fortran is

  Test #49: String Test
     I   TPAR(I)%Str    Length
     1   bar             3
     2   foobar          6
     3   foo            80   <-- why?

  bar    =  1
  foobar =  2
  foo    =  0    <-- lookup fails!
Press any key to continue . . .

 

0 Kudos
3 Replies
Kevin_D_Intel
Employee
583 Views

It does appear to be a defect with ifort. I confirmed (same as you) the program appears to produce expected results with gfortran. I will report this to Development (see internal tracking id below) and keep you updated.

(Internal tracking id: DPD200361944 )

0 Kudos
Kevin_D_Intel
Employee
583 Views

Development confirmed there is a defect where when creating the parameter constant TPAR the third element was null padded instead of blank padded leading to the unexpected results. They further note it does not matter that this is a parameter constant; that it fails in the same way after taking out “parameter”. They also thanked you for the simple reproducer!

0 Kudos
FortranFan
Honored Contributor III
583 Views

Kevin,

Thanks much for your prompt follow-up.  

Regards,

0 Kudos
Reply