Internal Compiler Error: Co-Array array and openMP offload map(to:)

[RJaBi]

Hi,

I'm getting an internal compiler error trying to compile some openMP Offload + co-array fortran code.

 error #5623: **Internal compiler error: internal abort**

Specifically this comes when I try to copy the data across using a 'target data map(to:)' pragma. Below is a minimal example:

Program propgen_rewrite
  implicit none
  integer, parameter :: SP = kind(1.0)     !! Single precision scalars.
  integer, parameter :: DC = kind((1.0D0, 1.0D0)) !! Double precision complex scalars.
  ! gauge field
  integer, parameter :: ip4 = 32768
  integer, parameter :: n4 = 8
  complex(kind=dc), dimension(:,:,:,:,:), codimension[:], allocatable :: s ! ICE
  !complex(kind=dc), dimension(:,:,:,:,:), allocatable :: s ! Works
  integer, codimension[*] :: number, iseed
  real(kind=sp), codimension[*] :: beta
  ! counters
  integer :: n, i, j, mu, ls
  allocate(s(ip4, 3, 3, 4, n4)[*]) ! ICE
  ! allocate(s(ip4,3,3,4,n4)) ! Works
  read(40) (((((s(n, i, j, mu, ls), n = 1, ip4), i = 1, 3), j = 1, 3), mu = 1, 4), ls = 1, n4)
  read(40) number, beta, iseed
  !$omp target data map(to: s)
  write(*,*) 'done'
  !$omp end target data

END PROGRAM propgen_rewrite

 This was tested with the compilation command: 

ifx -g -O0 -traceback -qopenmp -coarray=shared -coarray-num-images=1 -fopenmp-offload-mandatory -fopenmp-targets=spir64 minimalExample.f90

I tested using

ifx (IFX) 2025.1.1 20250418 with the above error:

ifx (IFX) 2024.2.0 20240602 and ifx (IFX) 2023.2.0 20230622 give the error error "#5633: **Internal compiler error: segmentation violation signal raised**" instead.

The system has a Intel(R) Xeon(R) Platinum 8480+ CPU and two Intel(R) Data Center GPU Max 1100 (not that this is truly relevant as it is a compiler error).

Not entirely sure this is the right place to post/inform the compiler team of this, but it's where I could find.

I'm not entirely sure of the 'correct' behaviour. My desired behaviour would be for each co-array image to copy the data that it has across. (I am compiling with only 1 image though as you can see).

Please let me know if there's anything else I should do instead.

Cheers,

Ryan

[Ron_Green]

While this example is conformant Fortran, the use of Coarray objects in offload regions is highly discouraged.  I think you know why this should be avoided. And I understand what target systems may be more amenable to this usage and why in your perspective you would like Intel to support this usage.  Or perhaps you are comparing various multi-vendor offload implementations for a paper on CAF and it's use in GPU enabled environments.  I am not sure your intent for this example.  

Still, a compiler should not ICE if code is conformant.  I can open a bug report.   This is not a common use case nor a recommended use case. 

[Ron_Green]

bug ID is CMPLRLLVM-69232

[Ron_Green]

1 image is not a problem, as you state.  And if that is the extent of your testing that is probably OK.  But if you intend others to use this example or some user forgets to set number of images to 1 there can be problems.  Another image can update 's' asynchronously.  And if the data is offloaded already when this update occurs, it gets stomped on map from.  And did the user intend to use the remote update data or the local image data a fraction of a second before the update?  You would need synchronization/barriers to prevent any data updates until the offload computation starts and ends and returns results.  Yes, can be done, but so many ways an unwary user will someday make a mistake and cause runtime race conditions.

But if your intent is just to run this 1 image example I suppose it is fine.  Barriers can prevent race conditions, but then why use an inherently asynchronous programming model like CAF with a lot of barriers to try to control asynchronous updates? Most OpenMP users think that offload of coarray objects is just asking for race condition problems.  Personally I think allowing Coarray objects in offload is just a bad idea and should not have been allowed in the OMP Standard. Just my opinion. 

[RJaBi]

Thanks for reporting this! That's the main thing so thank you greatly.

The example code above is very much a minimal example to reproduce the bug and no anything anyone should be using as a learning example.

For the rest of your questions:

We are investigating openMP offload for a production code https://gitlab.com/fastsum/NRQCD in lattice QCD. The way to think about it is

NT (independent) copies of a problem consisting of NT time steps of size NS^3

I wanted to play around with coarrays when I updated the code from F77 to modern fortran, and so I implemented coarrays to parallelise over the NT independent copies.

The data `s` is required by each copy & time step and is constant but is read from file. I did try only having one copy on one image and accessing it from the others, but I found that access times were very slow.

I understand of course that coarrays are more capable than what we use them for, but really I just wanted to play around with them.

We have now implemented CPU openMP within each time-step - i.e. for the size NS^3. We are looking at initial explorations for openMP offload. Right now this is just with one image. Our naive thought was to just use each image to target a different device (GPU) which would avoid any question of clobbering data.