I am seeing a segmentation fault with the code below. I have two questions:
1) Why does Test 1 pass but Test 3 fail? In other words, if the same operation on the RHS of the assignment operator '=' is being conducted, what difference does it make if we assign the result to a local variable or to the component of a derived type?
2) Why does Test 2 pass but Test 3 fail? In other words, why does it make a difference if we multiply by a local variable or a component of a derived type, if they are simply scalars?
Below are the source code, compilation commands, and runtime result. Thank you in advance!
program main type someType real(8) :: scalar real(8), allocatable :: array(:,:) end type someType integer, parameter :: n1 = 2000 integer, parameter :: n2 = 2000 type(someType) :: obj real(8) :: scalar real(8), allocatable :: array(:,:) ! Set up arrays and scalars scalar = 1.0d0 obj%scalar = 1.0d0 allocate(array(n1,n2)) allocate(obj%array(n1,n2)) ! Do tests array = obj%array*obj%scalar print *, 'Test 1 successful.' obj%array = obj%array*scalar print *, 'Test 2 successful.' obj%array = obj%array*obj%scalar print *, 'Test 3 successful.' end program main >> ifort --version ifort (IFORT) 16.0.0 20150815 >> make ifort -O0 -xHost -traceback -check bounds -check uninit -r8 -implicitnone -c main.f90 ifort -O0 -xHost -traceback -check bounds -check uninit -r8 -implicitnone -o exec main.o >> ./exec Test 1 successful. Test 2 successful. forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PC Routine Line Source exec 0000000000478E65 Unknown Unknown Unknown exec 0000000000476C27 Unknown Unknown Unknown exec 000000000042A204 Unknown Unknown Unknown exec 000000000042A016 Unknown Unknown Unknown exec 0000000000406266 Unknown Unknown Unknown exec 0000000000409880 Unknown Unknown Unknown libpthread.so.0 0000003E5FA0F710 Unknown Unknown Unknown exec 0000000000404A70 MAIN__ 25 main.f90 exec 0000000000402F7E Unknown Unknown Unknown libc.so.6 0000003E5EE1ED5D Unknown Unknown Unknown exec 0000000000402E09 Unknown Unknown Unknown
I can reproduce the error with 16.0 compiler but not with the latest 17.0 so it should be an issue fixed in the new compiler.
Intel Customer Support