- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page