- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Consider this subroutine:
subroutine model_update_sed_frac_mass(this)
type(model), intent(inout) :: this
type(iw2d_sediment_fraction), pointer :: sed_frac
type(element), pointer :: elem_
real(dp_kind), dimension(iw2d_num_sediment_fractions) :: total_mass
integer :: elem, sed_fraction
integer :: threads
logical :: exec_in_parallel
integer, parameter :: parallel_threshold = generic_parallel_threshold ! Enable parallel code path with > 1 thread
integer :: num_data
if (iw2d_there_is_bed_update()) then
total_mass = zero
! A140655 - This seg faults with IFX 2024.0.2 on Linux if compiled as an OpenMP loop
#if (__INTEL_COMPILER < 20240002 || _WIN32)
! The following statement is only compiled when OpenMP directives are processed
!$ threads = omp_get_max_threads()
num_data = model_get_num_elem(this)
exec_in_parallel = (threads > 1) .and. (num_data > parallel_threshold)
if (.not.exec_in_parallel) threads = 1
call iw2d_set_in_parallel(.true.)
!$OMP parallel &
!$OMP & if(exec_in_parallel) &
!$OMP & private (elem_, sed_fraction) &
!$OMP & reduction(+:total_mass) &
!$OMP & shared (this)
!$OMP do schedule(guided,128)
#endif
do elem = model_get_lbound_elem(this), model_get_ubound_elem(this)
elem_ => model_get_elem(this, elem)
do sed_fraction = 1, model_get_num_sed_frac(this)
! Deposition is in m, multiplied by area.. m3
total_mass(sed_fraction) = total_mass(sed_fraction) + &
& elem_sed_get_deposition(elem_, sed_fraction)*elem_get_area(elem_)
end do
end do
#if (__INTEL_COMPILER < 20240002 || _WIN32)
!$OMP end do
!$OMP end parallel
call iw2d_set_in_parallel(.false.)
#endif
do sed_fraction = 1, model_get_num_sed_frac(this)
sed_frac => model_get_sed_frac(this, sed_fraction)
total_mass(sed_fraction) = total_mass(sed_fraction)*sed_frac_get_density(sed_frac)
call sed_frac_set(sed_frac, mass = total_mass(sed_fraction))
end do
end if
end subroutine
With IFX 2024.0.2 on Linux, I get a segmentation fault at the start of the OpenMP in release builds, hence it is conditionally compiled as serial for that compiler/OS. This runs fine with IFX 2024.0 on Windows and with older versions of IFORT and also in debug builds on Linux.
This is part of a large commercial program, I haven't had time yet to produce a reproducer, so has anyone encountered anything similar?
Compiler options (from CMakeLists.txt):
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm surprised your program compiled and linked.
1) the Fortran PreProcessor requires the "#" of the fpp directives to be located in column 1 (unless that has changed with ifx)
2) Your code does not include "use omp_lib", thus the calls to the omp_xxx functions will not have proper interfacing as well as may not link.
And it may help to add "implicit none".
And the reduction(+:total_mass) where total_mass is an array of size = model_get_num_sed_frac(this) may cause stack overflow.
If the size of the array total_mass is too large, note the stack size of the OpenMP threads is .NOT. the size of the linker specified stack size for the main thread. You must specifiy the thread team stack size by API or environment variable. Alternatively, using heap arrays may or may not help (experiment to find out). If this fails, and if the issue relates to the reduction, then construct a different method (e.g. in-region allocate and critical section to perform reduction manually outside the region's internal loop).
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The subroutine is in a module that uses omp_lib and has implicit none.
You're right about the pre-processor directives - it would appear that IFX 2024.0 can handle this, but I'll fix the code so that GNU Fortran could work with it.
I'd be surprised if there was a stack overflow for total_mass, it is normally 1 or 2.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
well the IFX FPP # position is a bug as is is contrary to the manual! Something needs to change.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Agreed. Something is amiss. I filed 2 bugs against the FPP documentation in the DGR (Developer Guide and Reference), bug number DOC-12159. This is true for both ifx and ifort.
1. This is not a true statement:
Preprocessor directives must begin in column 1 of any Fortran source file.
Maybe it should be something like:
Preprocessor directives may begin in any column of a Fortran source file.
2. And this statement needs some tuning:
However, the Intel® Fortran Compiler automatically calls fpp when compiling source files that have file extension .fpp or .FPP, .f or .F, .f90
or .F90, .for or .FOR, .ftn or .FTN, and .fpp or .FPP.
It should state:
However, the Intel® Fortran Compiler automatically calls fpp when compiling source files that have file extension .fpp or .FPP, .F, .F90, .FOR, and .FTN.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Barbara, for a long time, the fpp's # had to be in column 1 (at least for ifort). When did this change?
Jim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't know exactly when. The compiler engineer was surprised that the doc still said that fpp's # had to be in column 1.
Remember that ifx and ifort share the same front-end, so fpp is the same for both.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The Fortran Developer Guide and Reference has been updated with the 2024.1 release last week. The documentation is fixed. Check it out!

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