Riemann release not compiling with intel 2021.6.0

Create issue
Issue #2615 new
Wolfgang Kastaun created an issue

When trying to build a pristine checkout of the Riemann release using the official einsteintoolkit.th provided with the release, compilation of arrangements/Lean/LeanBSSNMoL/src/adm_vs_bssn.F90 fails. I am using intel compilers version 2021.6.0. The issue seems to be a multiline OMP directive

holohome/wolfgang.kastaun/ET/Riemann/Cactus/arrangements/Lean/LeanBSSNMoL/src/adm_vs_bssn.F90(197): error #7844: Invalid directive.
!$OMP a, b, c, m, n)

The code looks like

193 !$OMP PRIVATE( i, j, k, &
194 !$OMP hh, jac, hu, &
195 !$OMP d1_hh11, d1_hh12, d1_hh13, d1_hh22, d1_hh23, d1_hh33, d1_hh, &
196 !$OMP cf1, cf2, gammat, &
197 !$OMP a, b, c, m, n)
198 do k = 1+cctk_nghostzones(3), cctk_lsh(3)-cctk_nghostzones(3)
199 do j = 1+cctk_nghostzones(2), cctk_lsh(2)-cctk_nghostzones(2)
200 do i = 1+cctk_nghostzones(1), cctk_lsh(1)-cctk_nghostzones(1)

I think this is legal but the intel ifort compiler apparently disagrees.

Comments (5)

  1. Wolfgang Kastaun reporter

    After removing Lean from the thornlist, I run into the next problem when building PAPI

    PAPI: Building...
    pfmlib_amd64.c(194): error: identifier "asm" is undefined
    asm volatile("cpuid" : "=a" (*a), "=b" (*b), "=c" (*c), "=d" (*d) : "a" (op) : "memory");

    pfmlib_amd64.c(194): error: expected a ";"
    asm volatile("cpuid" : "=a" (*a), "=b" (*b), "=c" (*c), "=d" (*d) : "a" (op) : "memory");

    compilation aborted for pfmlib_amd64.c (code 2)
    make[6]: *** [/holohome/wolfgang.kastaun/ET/Riemann/Cactus/configs/intelcomp2/scratch/build/PAPI/papi- pfmlib_amd64.o] Error 2

  2. Wolfgang Kastaun reporter

    Compiling GRHydro also breaks because of a multiline OMP directive

    /holohome/wolfgang.kastaun/ET/Riemann/Cactus/arrangements/EinsteinEvolve/GRHydro/src/GRHydro_HLLE.F90(99): error #7844: Invalid directive.
    !$OMP warnline, xpress,xeps,xtemp,xye, dpdrho, dpdeps, cs2)

  3. Roland Haas

    THere’s a max line length for fortran 90, maybe it’s running into that? May guess would also be that it could be any of the !$OMP lines that is off and ifort only reports on the final line?

  4. Roland Haas

    This was discussed for a bit in today’s ET call. Is there a public cluster where this happens and that could be used for testing? Most the XSEDE systems would be fine as well as SupeMUC at LRZ. A less convenient solution would be a pointer to where one can download Intel’s OneAPI and compiler these days.

  5. Log in to comment