Dear Intel community,
below is an example program which takes unusually long time to be compiled with "-O3" optimization (up to -O2 is fine), tested with ifort versions 14.0.3 and 15.0.3. This might be a compiler issue.
(But I don't know what is going on. Mabye the compiler is really doing something very sophisticated and the long compile-time is justified).
program p ! Compound type with alloc. components type :: a_type end type type :: b_type ! The more fields, the longer takes -O3 compiling. integer, allocatable :: & i00,i01,i02,i03,i04,i05,i06,i07,i08,i09, & i10,i11,i12,i13,i14,i15,i16,i17,i18,i19, & i20,i21,i22,i23,i24,i25,i26,i27,i28,i29, & i30,i31,i32,i33,i34,i35,i36,i37,i38,i39 class(a_type), allocatable :: & a00,a01,a02,a03,a04,a05,a06,a07,a08,a09, & a10,a11,a12,a13,a14,a15,a16,a17,a18,a19, & a20,a21,a22,a23,a24,a25,a26,a27,a28,a29, & a30,a31,a32,a33,a34,a35,a36,a37,a38,a39 end type type(b_type), allocatable :: b ! Switch, undetermined at compile-time logical :: switch ! Allocate anything (doesn't have to, but can, be b) integer, allocatable :: i allocate(i) ! Deallocate compound type deallocate(b) ! Specific repeated conditional loop structure read (*,*) switch if (switch) then do ! any do-loop end do end if if (switch) then do ! any do-loop end do end if end program
Usually, changing the order of statements does not change the compile-time delay. However, after changing the code in any other way the reported delay is gone (e.g. removing one loop, removing the switch, removing the allocation, removing the allocatable-attribute, changing the class keyword to type, or removing entirely one of the fields in b_type) .
I post this issue only out of curiosity and for your information. For me, it is sufficient to use -O2 optimization on the affected code.
With regards
Ferdinand