Nvfortran compilation error on WHERE construct

Dear All,

I’ve recently started working on GPU acceleration of a Fortran code for astrophysics. The code was previously compiled with gfortran without an issue. However, when I switched to nvfortran I discovered a strange behavior.

 program comperror
    implicit none

    type :: mg_t
    sequence
        integer             :: arr(4)
    end type
    type(mg_t),target       :: mg

    integer                 :: arr(4)

    integer                 :: i,j
    integer, pointer        :: arr_ptr(:)

    i=0;j=1
    
    arr(:) = 0;
    where ([i, j] == 1)
        arr(1:4:2) = -77
    end where
    print*,arr(:)
    
    !problematic construct
    mg%arr(:) = 0
    where ([i, j] == 1)
        mg%arr(1:4:2) = -77
    end where
    print*,mg%arr(:)


    mg%arr(:) = 0
    where ([i, j] == 1)
        mg%arr(1:2) = -77
    end where
    print*,mg%arr(:)

    mg%arr(:) = 0
    arr_ptr => mg%arr
    where ([i, j] == 1)
        arr_ptr(1:4:2) = -77
    end where
    print*,mg%arr(:)
   
    mg%arr(:) = 0
    associate(assoc_arr => mg%arr)
    where ([i, j] == 1)
        assoc_arr(1:4:2) = -77
    end where
    end associate
    print*,mg%arr(:)

end program comperror

Compiled with:

nvfortran comperror.F90 -o comperror
nvfortran --version

nvfortran 23.11-0 linuxarm64 target on aarch64 Linux -tp neoverse-n1 
NVIDIA Compilers and Tools
Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES.  All rights reserved.

The problem is when I’m trying to set a array which is part of derived type with non-default stride in where construct. There are several ways to work around this, but I was wandering whether it shouldn’t behave consistently. It can be pretty much the case that I am doing something which I’m not supposed to.

The error message:

NVFORTRAN-S-0511-The WHERE mask expression and the array assignment do not conform (comperror.F90: 26)
  0 inform,   0 warnings,   1 severes, 0 fatal for comperror

Thank you for the inputs.

Thanks for the report Kristian,

I was able to reproduce the issue here and have filed a problem report, TPR #35614. We’ll have engineering investigate.

-Mat