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

Fortran 90 character literals in array constructor support

IanH
Honored Contributor II
406 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.

3 Replies
jimdempseyatthecove
Honored Contributor III
380 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
375 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
316 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
Reply