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

Fortran 90 character literals in array constructor support

IanH
Honored Contributor II
489 Views

ifort and ifx get rather confused with the following...

PROGRAM silly_char_parser
  IMPLICIT NONE
  
  INTEGER, PARAMETER :: ck = KIND(' ')
  PRINT *, (/  &
      ck_'::        ',  &
      ck_'The       ',  &
      ck_'parser    ',  &
      ck_'should    ',  &
      ck_'not       ',  &
      ck_'be        ',  &
      ck_'looking   ',  &
      ck_'for       ',  &
      ck_'tokens    ',  &
      ck_'inside    ',  &
      ck_'character ',  &
      ck_'literal   ',  &
      ck_'constants!' /)
END PROGRAM silly_char_parser

 

>ifort /c "2023-03-13 silly-char-parser.f90"
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.8.0 Build 20221119_000000
Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

2023-03-13 silly-char-parser.f90(18): error #5082: Syntax error, found '/)' when expecting one of: :: ) , :
      ck_'constants!' /)
----------------------^
2023-03-13 silly-char-parser.f90(6): error #6404: This name does not have a type, and must have an explicit type.   [TYPE]
      ck_'::        ',  &
------^
compilation aborted for 2023-03-13 silly-char-parser.f90 (code 1)

Compilation succeeds if the value of the first element in the array constructor is changed.

4 Replies
jimdempseyatthecove
Honored Contributor III
463 Views

IanH, (haven't heard from you in a while)

 

RE: 'The parser should not be looking for tokens inside character literal constants!'

 

I experienced something similar (though I don't have a simple reproducer).

In my case, my source uses fpp to preprocess the file.

The problem was if you had a:

       ! comment (without balance parentheses

that the preprocessor lost context by trying to locate the matching, and missing, )

Both problems are similar, but may not be located in the same place in the compiler/preprocessor.

Jim Dempsey

0 Kudos
FortranFan
Honored Contributor II
458 Views

Intel Team,

Re: the original post by @IanH and the comment by @jimdempseyatthecove , "The parser should not be looking for tokens inside character literal constants!," perhaps the following variant might help the Intel Fortran team to hone in on the issue where double colon that has syntactical significance as a separator is being misunderstood in a literal constant?

 

   integer, parameter :: ck = kind(' ')
   print *, [ ck_"::", ck_"ab" ] !<-- change the double colon to another string and the compiler succeeds
end

 

 

Barbara_P_Intel
Moderator
399 Views

Thank you both for the reproducers. @IanH, yours made me laugh!

I filed a bug report, CMPLRLLVM-45740. I'll let you know when it's fixed.



0 Kudos
Barbara_P_Intel
Moderator
71 Views

@IanH and @FortranFan, the parsing problems are fixed in the 2024.2.0 compilers. That release is planned for mid-2024. Watch for the announcement!



0 Kudos
Reply