Conditional compile issue

[jimdempseyatthecove]

I have a (low priority) strange compilation issue observable in ifort and ifx

I have an OpenMP threaded program that builds a Debug build without OpenMP

When compiling Debug (without OpenMP) the following statement

!$  integer(kind=omp_lock_kind) :: lockOK

Is expanded and I get an error as omp_lock_kind is undefined

However, if I change the statement to

  !$integer(kind=omp_lock_kind) :: lockOK

Note leading whitespace.

Both compilers treat this as a comment.

The actual code (with error) compiles with fpp

My attempt at a reproducer does not exhibit the issue

module foo
    type abc
        integer :: dontcare
!$      integer(kind=omp_lock_kind) :: lock
    end type abc
end module foo
    
program Console24
    use foo
    implicit none
    type(abc) :: X
!$  integer(kind=omp_lock_kind) :: lockOK
end program Console24

As you do not have a simple reproducer, I don't expect you to work on this.

However, keep this in mind such that you can recommend an easy work around to others that experience the same.

FWIW the Solution exhibiting this error, has in other projects the use of

!$  **bleep**

and treating statement as comment

I am unsure as to what triggers this behavior

Jim Dempsey

[Ron_Green]

I can ask the developers on the front front-end code if they have seen anything like this, or know of what could trip up the recognition of this syntax.  Like you, I can't get the simple reproducer to trigger the behavior - not with tab characters, leading comments, continuation lines, all the usual suspects that could trip up the parsing.  

One last ditch thought - maybe it's not in the parsing but in fpp.  You mentioned fpp, is the source file preprocessed?  Could you compile just this one file with -keep and see what FPP is doing to the source with the issue?  Inspect the .i90 file for fpp anomalies around this statement. 

[jimdempseyatthecove]

The sample non-reproducer does not show the symptom either with or without using fpp.

The problem seems intermittent. Just today, the issue showed up in a different source file that had been working as intended.

Remember, this is lowest of low priority. 

Jim Dempsey