one more ifc bug ?

[chatmann]

Hello,

if somebody could light me on these 3 points, I will be very gratefull...

1) The mathkernel library contains the LAPACK library whose sources can be found on netlib.com. I have tried to compile them with the ifc, but it leads to some infinite looping when executing the code in parallel. Note that it does not happen when I use the LAPACK subroutines by means of the precompiled Mathkernel library. The issue is that, I cannot chose the kind (4 or 8 or..) of datas in the mathkernel library, so is there a trick to compile the LAPACK subroutines in such a way that they work fine in parallel ??

2) In the many difficulties I have encountered with IFC compiler, most of them come from the usage of old, but standard, fortran 77 instructions. I am quite sure that there are due to the compiler since such kind of bugs do not appear at all in ALL the other unix f95 compilers. Is it an Intel politic to not respect old standard procedures ?? If yes, I guess this is a non sense since, fortran is already an old stuff ;o)
As an example of one of my encountered bug:

3) I get an address error, or not, when executing this little code due to the ENTRY statement.
Okay, ENTRY statements are obsolete and deprecated features in f90, nevertheless I often use old subroutines written in f77 which have such kind of things, and there is not error at all in all other compiler that I have tested (compaq, sgi, ibm, sun ...).


++++++++++++++++++++++++++++++++++++++++++++++++++++++
program ifcbug
implicit none

call submov()

end

subroutine submov()
implicit none
integer, allocatable :: inda(:)
integer na
integer i

na=5

allocate(inda(na))

do i=1,na
inda(i)=i
enddo

goto 100

c Try to comment or decomment the following line...
ENTRY chkmov()

na=5
allocate(inda(na))

do i=0,na-1
inda(i)=na-i
enddo

100 continue

print *,'na',na

print *,'inda',inda(1:na)

deallocate(inda)

end


+++++++++++++++++++++++++++++++++++++++++++++++++++

[TimP]

1) I'm fairly certain the standards committee had this very situation in mind when they introduced the intrinsics TINY(), EPSILON(), HUGE(). Surely someone has introduced them into the machine dependency subroutines. If you're interested, you might ask on the netlib forum. Otherwise, you will need to reduce optimization on those subroutines, e.g. by adding -mp, to persuade ifc to leave in the loop exits.
I don't entirely understand your question about data kinds. MKL uses the traditional netlib way of switching data kinds by changing the subroutine name, e.g. DGEMM (double), SGEMM (single).

3) You're on shaky ground when you combine syntax which was obsoleted in f90 with features which didn't exist until f90. Since ENTRY wasn't standardized until f77, some compilers try to recognize some variants outside the standard. I don't believe that the empty ENTRY argument list was covered in f77, not to mention allocatable arrays.
ENTRY might have been more useful if it had been standardized before function in-lining was invented. Even g77 does better when the entry points are written as separate functions at the top of a file, the subroutine containing the common code appears later in the file, and -O3 (or the separate in-lining option) is issued.

[Steven_L_Intel1]

You should find that handling of "old code" improves quite a bit in the next release that uses the Compaq Fortran "front-end" (language analysis).

Steve

[Martyn_C_Intel]

To elaborate on Tim's response below: the loops to determine machine precision in LAPACK make certain assumptions that are inappropriate to the IA-32 architecture. Essentially, some computations are carried out in 80 bit FP registers, and this additional precision invalidates the algorithm used to determine machine precision. There is a related FAQ at
http://www.intel.com/support/performancetools/fortran/linux/rounding.htm

Martyn