Issue with array allocation in C++

Compilers Intel
1

ifx -fiopenmp corrupts whole-array assignment to CFI-allocated array

Minimal reproducer for an Intel oneAPI Fortran (ifx) bug observed in DAMASK
(GitHub - damask-multiphysics/DAMASK: Düsseldorf Advanced Material Simulation Kit (Read-only mirror) · GitHub). In discretization_grid.f90 the line

materialAt_global = materialAt_global + 1

corrupted the material-ID array when compiled with oneAPI, while the
array-section form materialAt_global(:) = materialAt_global(:) + 1 worked.

Pattern

  1. A BIND(C) subroutine declared as
    integer(C_INT), allocatable, intent(out) :: data(:) is called from Fortran.
  2. C allocates the array via CFI_allocate and fills it (fill.c).
  3. Fortran performs a whole-array assignment to the returned allocatable:
    a = a + 1.
  4. The whole unit is compiled with -fiopenmp.

With -fiopenmp, values in the LHS array are silently corrupted for arrays
above a certain size (seen from ~4000 elements up; the failure is not
monotonic in size — n=8000 passed in one run while n=4000 failed). Elements
are overwritten with garbage. Without -fiopenmp, or with the
array-section form, the result is correct.

Which (:) matters

Only the combination where both sides are whole-array triggers the bug;
(:) on either side alone is sufficient to avoid it:

Form mismatches at n=29760
a = a + 1 (both whole) 29712 BROKEN
a = a(:) + 1 (LHS whole) 0 OK
a(:) = a + 1 (RHS whole) 0 OK
a(:) = a(:) + 1 (both sect) 0 OK

Reproduce

source /path/to/oneapi/setvars.sh
make run              # BROKEN: whole-array assignment with -fiopenmp
make run-workaround   # OK:     array-section assignment
make run-noopenmp     # OK:     whole-array assignment without -fiopenmp
make run-small        # OK:     small array (n=1000)
make run-variants     # LHS/RHS section combination matrix (n=29760)

Environment

  • ifx 2026.1.0 (20260617), icx 2026.1.0 (20260617)
  • oneAPI HPC toolkit 2026.1, Linux x86_64
  • Trigger flag: -fiopenmp (any -O level reproduces)

Files

main.f90 (732 Bytes)
main_variants.f90 (1.2 KB)
main_workaround.f90 (735 Bytes)
fill.c.txt (555 Bytes) should be called fill.c
fill.c.txt (519 Bytes) should be called fill.c (updated version, closer to the original code)
Makefile.txt (1.7 KB) should be called Makefile

1 Like
2

Hi Martin,

did you file this with Intel or would you like some help getting it somewhere?

Cheers

1 Like
3

I’ve just posted it in the Intel forum: https://community.intel.com/t5/Intel-Fortran-Compiler/Issue-with-array-allocation-in-C-ISO-Fortran-binding-h/m-p/1755394#M179301

1 Like
4

I think bug reports like this one are best to simply report to the respective compiler / project. I would say you should post such a bug at Discourse if:

  • You have a specific question, such as if the code is standard conforming
  • Or another Fortran question beyond just one specific compiler
  • Or you want feedback on your bug report from the wider community, maybe you have some question

It seems in this case you don’t have any such question, so I would just report it to Intel, as you did.

5

I agree, a bug report would be the better approach. I just posted it here because of larger visibility and the unclear procedure for bug reporting to Intel. As far as I know, a paid service contract is needed to get an issue ID and structured feedback.

1 Like
6

I have never had a paid Intel service contract but I have occasionally reported a bug to their forum. Intel gave it an issue ID and corrected the next version of their compiler when they agreed that they did have a bug. Sometimes the same Fortran program finds a bug in another compiler and I report it there too.

1 Like
7

I see, so the question you are asking is how to report a bug to the Intel compiler if you don’t have a paid service contract. Such a question belongs here for sure.

@greenrongreen do you know if there is anybody else from Intel here that could answer such a question? You were our goto guy, but you are now at NVIDIA. :slight_smile:

8

You should try their Fortran Community Forum: https://community.intel.com/t5/Intel-Fortran-Compiler/bd-p/fortran-compiler. Igor Vorobtsov is the Intel moderator these days, and the community is still quite active.

1 Like
9

thanks, it’s posted there.

1 Like