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

ifort2018beta regression: segmentation fault on valid code

Juergen_R_R
Valued Contributor I
508 Views

The attached code leads to a seg fault with ifort2018beta, however works with gfortran 4.8., 4.9., 5, 6, 7, and 8 as well as nagfor 6 and PGF17.3. It also worked with ifort 17.0.3, so this clearly is a regression. I filed this as a report to the support under the number 02772804.

This is the message from the backtrace etc.:

 

 

 PDG(out) =  -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6

forrtl: severe (174): SIGSEGV, segmentation fault occurred

Image              PC                Routine            Line        Source             

whizard_test       000000000041133D  Unknown               Unknown  Unknown

libpthread-2.19.s  00007F983ACBD330  Unknown               Unknown  Unknown

libc-2.19.so       00007F983A967D2C  cfree                 Unknown  Unknown

whizard_test       000000000042406D  Unknown               Unknown  Unknown

whizard_test       0000000000404E5D  Unknown               Unknown  Unknown

whizard_test       0000000000403536  Unknown               Unknown  Unknown

whizard_test       0000000000402A1E  Unknown               Unknown  Unknown

libc-2.19.so       00007F983A906F45  __libc_start_main     Unknown  Unknown

whizard_test       0000000000402929  Unknown               Unknown  Unknown

0 Kudos
7 Replies
Juergen_R_R
Valued Contributor I
508 Views

Here is the missing file. 

0 Kudos
Juergen_R_R
Valued Contributor I
508 Views

Unfortunately, we don't have a workaround for this (yet). Any idea would be very much appreciated. 

 

0 Kudos
Juergen_R_R
Valued Contributor I
508 Views

Some more insight: the problematic line is  

pdg_in(i_beam) = pdg_out 

It seems that the compiler is confused about the proper assignment. i_beam is an array, pdg_in an allocatable array of type pdg_array_t, and so is pdg_out. Writing an explicit assignment of the form pdg_array_from_pdg_array solves this issue: 

  elemental subroutine pdg_array_from_pdg_array (aval_out, aval_in)
    type(pdg_array_t), intent(in) :: aval_in
    type(pdg_array_t), intent(inout) :: aval_out
    integer :: i
    if (allocated (aval_out%pdg))  deallocate (aval_out%pdg)
    if (allocated (aval_in%pdg)) then
       allocate (aval_out%pdg (size (aval_in%pdg)))
       do i = 1, size (aval_in%pdg)
          aval_out%pdg(i) = aval_in%pdg(i)
       end do
    end if
  end subroutine pdg_array_from_pdg_array  

 

0 Kudos
Kevin_D_Intel
Employee
508 Views

Thank you for reporting this. A colleague has taken ownership of the associated support ticket and is investigating the issue now.

0 Kudos
Juergen_R_R
Valued Contributor I
508 Views

Unfortunately, the workaround posted above does not work for the nagfor compiler. But apparently, ifort hiccups over intrinsic derived type assignment vs. user-defined assignment. Is it possible that ifort interprets pdg_in(i_beam) as a function call instead of an array slice? 

 

0 Kudos
Igor_V_Intel
Employee
508 Views

I escalated this to the developers (CMPLRS-42758).

0 Kudos
Juergen_R_R
Valued Contributor I
508 Views

We also have a general workaround now, not introducing an explicit assignment for pdg_array_t from pdg_array_t, but changing the offending line in the code from   pdg_in(i_beam) = pdg_out   to an explicit do loop of the form:

do i = 1, size (i_beam)

    pdg_in (i_beam(i)) = pdg_out(i)

end do

 

 

 

0 Kudos
Reply