ifort19_beta: segfault in block+omp construct

[Martin1]

This concerns the recently published ifort19 beta release.

The following piece of code crashs with SIGSEGV. Trying various versions it is clear that the combination of block and the omp do loop causes the problem. Moving declaration of variable x out of the block (and for example move declaration of k into the block) avoids the crash.

The code has been compiled with "ifort -qopenmp test.f90 -o test". The crash occurs regardless of optimisation level (tested -O0 and -O3).

I should also note that valgrind reports use of an uninitialised value of size 8 (with option -O0).

program test

   integer(4) :: k

   block
     integer(4), dimension(:), pointer :: x

     allocate(x(1:100))

!$omp parallel do schedule(dynamic, 10) default(shared) private(k)
     do k = 1,100
        x(k) = k
     end do
!$omp end parallel do

     deallocate(x)
   end block

end program test

[Martin1]

This crashing example has been derived while checking whether other valgrind warnings are still present with the new beta release. I would like to mention that these (unrelated) problems discussed in

https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/753833

are still present. I was not able to reproduce the valgrind warnings with any of the three small testcases mentioned in that thread (for various parameters) with the ifort19 beta release. However, using valgrind with our software and ifort19_beta still gives a number of disturbing warnings in conjunction with allocation/deallocation (mainly unconditional jumps).

With the analysis, providing the exact location in the assemble code (from the ifort openmp code?) and the exact bit of the pointer header causing the uninitialised warning in valgrind, it should be possible to find the cause even without a testcase. Something like adding a few lines of code which writes garbage to this particular bit just after the allocation mechanism has grabbed the memory and before initialising the data within the pointer header might help to expose the problem. Or some similar approach.

[TimP]

I received an email a day after installing specifying the subdirectory at supporttickets.intel.com where problem reports should be accepted. In my case I did ask on vtune forum for general hints about whether it could analyze the problem I encountered in hope of coming up with a more targeted description. Reports specific to beta tests always have required formal reports, more so now that problem reports aren't taken routinely from the forum reports.

[Martin1]

I will try to submit it to supporttickets.intel.com as 'Request support' (does not fit as I do not want support, just reporting a likely bug, but there is no better fit). So far I have not been able, as my browser seems to prevent me from navigating intels support page.