- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 . . .
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 )
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Kevin,
Thanks much for your prompt follow-up.
Regards,
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page