Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
26756 Discussions

ifort2018beta regression: segmentation fault on valid code

Juergen_R_R
Valued Contributor I
169 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
169 Views

Here is the missing file. 

Juergen_R_R
Valued Contributor I
169 Views

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

 

Juergen_R_R
Valued Contributor I
169 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  

 

Kevin_D_Intel
Employee
169 Views

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

Juergen_R_R
Valued Contributor I
169 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? 

 

Igor_V_Intel
Employee
169 Views

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

Juergen_R_R
Valued Contributor I
169 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

 

 

 

Reply