Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28951 Discussions

Seg fault with OpenMP loop in IFX 2024.0.2 Linux

Mark_Lewy
Valued Contributor I
1,581 Views

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):

    set (CMAKE_Fortran_FLAGS "-fpp -qopenmp -mkl -auto -standard-semantics -fp-model=precise -diag-disable:7841,10412,5462 ${CMAKE_Fortran_FLAGS}")
    # There is a known bug with the LLVM Memory Sanitizer feature in OneAPI 2024.0 - the workaround is to not use uninit
    if (CMAKE_Fortran_COMPILER_VERSION VERSION_EQUAL "2024.0.0")
        set (CMAKE_Fortran_FLAGS_DEBUG "-g -O0 -check all,nouninit")
    else()
        set (CMAKE_Fortran_FLAGS_DEBUG "-g -O0 -check all")
    endif()
    set (CMAKE_Fortran_FLAGS_RELEASE "-qno-opt-matmul -assume noieee_compares -O2 -xSSE3")
 
0 Kudos
7 Replies
jimdempseyatthecove
Honored Contributor III
1,562 Views

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

0 Kudos
Mark_Lewy
Valued Contributor I
1,535 Views

@jimdempseyatthecove 

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.

0 Kudos
andrew_4619
Honored Contributor III
1,525 Views

well the IFX FPP # position is a bug as is is contrary to the manual! Something needs to change.

 

Barbara_P_Intel
Employee
1,493 Views

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.

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,482 Views

Barbara, for a long time, the fpp's # had to be in column 1 (at least for ifort). When did this change?

 

Jim

0 Kudos
Barbara_P_Intel
Employee
1,474 Views

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.

 

0 Kudos
Barbara_P_Intel
Employee
1,097 Views

The Fortran Developer Guide and Reference has been updated with the 2024.1 release last week. The documentation is fixed. Check it out!



0 Kudos
Reply