[flang] [OpenMP] Flang inline directive regression

[scamp-nvidia]

There is a new regression with Flang OpenMP inline directive handling. We have narrowed it down to occurring between 22079e3 and 9a51879. Consider the following test.F90 code with inline OpenMP directives:

subroutine kern_xx(NA, BLK, NSP, OUT, A1, A2)
  implicit none
  integer :: NA, BLK, NSP
  integer :: M, MM
  real(8) :: OUT(NA)
  complex(8) :: A1(BLK*NSP), A2(BLK*NSP)

!$OMP       PARALLEL SHARED(NSP,OUT,A1,A2) !$OMP PRIVATE(M,MM)
!$OMP       END PARALLEL
end subroutine kern_xx

Compiling this with Flang before 22079e3 generates everything okay, but after 9a51879 we get the following error:

scamp$ flang test.F90 -c -fopenmp
error: Could not parse test.F90
./test.F90:8:50: error: expected 'END'
  !$OMP       PARALLEL SHARED(NSP,OUT,A1,A2) !$OMP PRIVATE(M,MM)
                                                   ^
./test.F90:8:44: in the context: execution part construct
  !$OMP       PARALLEL SHARED(NSP,OUT,A1,A2) !$OMP PRIVATE(M,MM)
                                             ^
./test.F90:8:1: in the context: OpenMP construct
  !$OMP       PARALLEL SHARED(NSP,OUT,A1,A2) !$OMP PRIVATE(M,MM)
  ^

The same code compiled with GCC and NVHPC works perfectly fine - and like I said, before the given hash range, Flang handled it fine. Looking at the commit range, I'm very suspicious of 9a51879 causing the regression since it altered how some inline directives are handled - tagging @Meinersbur and @EbinJose2002 for a check over, since they worked on the suspicious issue.

[llvmbot]

@llvm/issue-subscribers-flang-frontend

Author: None (scamp-nvidia)

There is a new regression with Flang OpenMP inline directive handling. We have narrowed it down to occurring between 22079e3 and 9a51879. Consider the following test.F90 code with inline OpenMP directives:

subroutine kern_xx(NA, BLK, NSP, OUT, A1, A2)
  implicit none
  integer :: NA, BLK, NSP
  integer :: M, MM
  real(8) :: OUT(NA)
  complex(8) :: A1(BLK*NSP), A2(BLK*NSP)

!$OMP       PARALLEL SHARED(NSP,OUT,A1,A2) !$OMP PRIVATE(M,MM)
!$OMP       END PARALLEL
end subroutine kern_xx

Compiling this with Flang before 22079e3 generates everything okay, but after 9a51879 we get the following error:

scamp$ flang test.F90 -c -fopenmp
error: Could not parse test.F90
./test.F90:8:50: error: expected 'END'
  !$OMP       PARALLEL SHARED(NSP,OUT,A1,A2) !$OMP PRIVATE(M,MM)
                                                   ^
./test.F90:8:44: in the context: execution part construct
  !$OMP       PARALLEL SHARED(NSP,OUT,A1,A2) !$OMP PRIVATE(M,MM)
                                             ^
./test.F90:8:1: in the context: OpenMP construct
  !$OMP       PARALLEL SHARED(NSP,OUT,A1,A2) !$OMP PRIVATE(M,MM)
  ^

The same code compiled with GCC and NVHPC works perfectly fine - and like I said, before the given hash range, Flang handled it fine. Looking at the commit range, I'm very suspicious of 9a51879 causing the regression since it altered how some inline directives are handled - tagging @Meinersbur and @EbinJose2002 for a check over, since they worked on the suspicious issue.

[Meinersbur]

Is the second !$OMP on the line meant to be interpreted as a comment? gfortran seems to think so.

[scamp-nvidia]

I talked to our engineer in charge of the code where this showed up, and he is of the opinion that it's supposed to work inline like that. But I could very easily believe that it's actually considered as a comment and the original code either has an issue in it or resolves that privatization somewhere else in the area.

However, either way, this is definitely a regression in behavior - because if it's supposed to be processed, it's not being processed properly. And if it's supposed to be a comment, it shouldn't be getting processed, right?

[scamp-nvidia]

Sorry for back to back comments - we bounced back and forth and agreed that it should be considered a comment actually, in which case it's definitely being handled wrong here, as it shouldn't be getting handled at all.