IFX 2025.3.0 Using custom mapper overrides mapping behavior of scalars

[jfuchs]

Hi,

consider the small reproducer:

PROGRAM reproducer
    IMPLICIT NONE

    TYPE :: field_t
    REAL, ALLOCATABLE :: buf(:)
    END TYPE field_t
    !$omp declare mapper(field_t :: t) map(tofrom: t%buf)

    TYPE(field_t) :: field
    INTEGER :: val

    ALLOCATE(field%buf(3), source=1.0)

#ifdef _NOMAPPER_
    !$omp target map(tofrom: field%buf) map(tofrom: val)
#else
    !$omp target map(tofrom: field) map(tofrom: val)
#endif
        PRINT*, "(Sanity check) Field on device:", field%buf
        val = 42
    !$omp end target

    PRINT*, "Scalar back on host:", val

    DEALLOCATE(field%buf)
END PROGRAM reproducer

 Compiling this with 

ifx -O2 -fiopenmp -fopenmp-targets=spir64 main.F90

and running it results in the following output:

 (Sanity check) Field on device:   1.000000   1.000000   1.000000
 Scalar back on host:           0

This prints the scalar value 0 on the host even though we explicitly told it to map the scalar "val" with tofrom (expected output is 42).

We can add the flag -D_NOMAPPER_ in order to map "buf" and not use the custom defined mapper (please correct me if I am wrong). Compile with

ifx -O2 -fiopenmp -fopenmp-targets=spir64 main.F90 -D_NOMAPPER_

and it will output:

 (Sanity check) Field on device:   1.000000   1.000000   1.000000
 Scalar back on host:          42

This is the expected result for the scalar.

In conclusion, if we define a custom mapper for the derived type and use a variable holding the type in the map clause, then the mapping behavior of the scalar (which is a completely unrelated variable to the mapper and derived type) is overridden. This also happens if you use a custom mapper-identifier in the declare mapper AND target region mapping.

The findings are supported by the fact that if we comment out the definition of the custom mapper, we get the expected result of 42 for the scalar in both cases (with and without -D_NOMAPPER_) making me believe this is a bug caused by the mapper. (I think that if we comment the mapper out there is some automatic mapping generated since the derived type just holds an allocatable?)

I checked with a recent LLVM built from source and it returns 42 for the scalar back on host in all cases described above, which is the result I would have expected.

Best

Jakob

[jfuchs]

I just found out that this issue is a bit more severe than reported. The mapping behavior is not only changed for scalars but the same principle explained above also applies to arrays.