Re: Resources for updating Old Code

quemado · ‎08-17-2007

Attempting to compile some code that was last updated from Fortran 77 to Fortran 90 in 1999 by an automated script. There were a number of atrifacts that compilers complained about but accepted. It compiled with the Lahey compiler as recently as 2005. It dies with more recent Linux versions. Lahey has not updated their Linuxcompiler since 2005. The Intel compilers will not accept the artifacts at all even though a number are just noted as warnings, the resulting code fails. An Example is

ifort -std95 -us -lowercase -traceback -free -O3 -c /scale/scale5/src/scalelib/Error_functions_M.f90
fortcom: Warning: /scale/scale5/src/scalelib/Error_functions_M.f90, line 70: Fortran 95 does not allow this intrinsic procedure. [EXIT]
call exit(stopcode)
-----------^

A second example

icc -O -m32 -c /scale/scale5/src/scalelib/getmtm.c
/scale/scale5/src/scalelib/getmtm.c(48): warning #266: function "printf" declared implicitly
printf(" error code %d for path %s",i,s1);
^

from the attached routine. Is there a resource that leads to fixes for these old practices that are now fatal?

Robert McBroom

Steven_L_Intel1 · ‎08-17-2007

You show compiler warnings, which themselves are not "fatal", but don't describe how the program fails at run-time. In the case of CALL EXIT, you asked for standards checking and the compiler notes that EXIT, which is an intrinsic procedure in Intel Fortram (that does what you want it to do) is non-standard. Other than that, it should work fine.

Regarding the C complaint, that too should be harmless, though you probably want to add a

#include

to declare it. This too should not cause run-time problems.

quemado · ‎08-22-2007

The code compiles and links with nothing but the warnings. Running on Fedora 6 with the compatiblity module to get libstdc++.so.5 The execution problems come with accessing data libraries. The trace messages are

forrtl: severe (98): cannot allocate memory for the file buffer - out of memory, unit 88, file /var/tmp/scale.11571/ft88f001
Image              PC        Routine            Line        Source             
bonami             080CCC53  Unknown               Unknown  Unknown
bonami             080CC273  Unknown               Unknown  Unknown
bonami             08094482  Unknown               Unknown  Unknown
bonami             0806CD98  Unknown               Unknown  Unknown
bonami             0806CA33  Unknown               Unknown  Unknown
bonami             08080474  Unknown               Unknown  Unknown
bonami             0804A420  MAIN__                     95  bonami.f90
bonami             08049F91  Unknown               Unknown  Unknown
libc.so.6          00715DEC  Unknown               Unknown  Unknown
bonami             08049EA1  Unknown               Unknown  Unknown

Line 95 in bonami is the read statement in the code segment

      call opnfil ( mmt, 'old', 'unformatted', 'default', 'read' )  
      read ( unit=mmt ) iid, nnuc, igm, iftg, msn, ipm, dum, title

The routine opnfil that prepares the file for access is attached. My understanding is that it completed successfully. Robert McBroom

Steven_L_Intel1 · ‎08-22-2007

On which platform and with which compiler was the data file created? My guess is that it was for a big-endian platform. If so, you can add CONVERT='BIG_ENDIAN' to the OPEN statement which I assume is in routine opnfil.

quemado · ‎08-23-2007

Same platform but earlier compilers and operating system versions. The ascii to binary codes are available so I'll see if rewriting the files solves the problem.

Robert McBroom

quemado · ‎08-30-2007

Solved. The operating system provides the fix. In the script that runs the job the command

export FORT_CONVERT88=BIG_ENDIAN

provides the match for fortran device 88, etc.

Robert McBroom

Steven_L_Intel1 · ‎08-30-2007

That's a Fortran run-time option - I see my guess was correct.

quemado · ‎09-06-2007

Original f90 code segment that has worked for years with various compilers (Lahey, OSF/1, HPUX, AIX).

character(4) :: titl(18,nmix)
real , intent(in) :: dens(nmix)
real :: dtmp(nmix)
real :: awr(nmix)
real :: rho(mxxt)
!-----------------------------------------------
! L o c a l V a r i a b l e s
!-----------------------------------------------
integer :: i
!-----------------------------------------------
ntmp(:nmix) = nucl(:nmix)
mtmp(:nmix) = mixt(:nmix)
dtmp(:nmix) = dens(:nmix)
call prtmix ( mtmp, ntmp, dtmp, awr, za, titl, rho, mxxt, nmix, nsct, pbxs, outpt )

Compilation with Intel 10.0 fortran and c compilers gives the error.

ifort -std95 -us -lowercase -traceback -free -g -I /hda8/scale5/Linux_2/csas -I /hda8/scale5/Linux_2/miplib -I /hda8/scale5/Linux_2/kenova -I /hda8/scale5/Linux_2/scalelib -c /hda8/scale5/src/modify/mixprt_I.f90
fortcom: Error: /hda8/scale5/src/modify/mixprt_I.f90, line 48: Character length argument mismatch. [TITL]
call prtmix ( mtmp, ntmp, dtmp, awr, za, titl, rho, mxxt, nmix, nsct, pbxs, outpt )
-----------------------------------------------^
compilation aborted for /hda8/scale5/src/modify/mixprt_I.f90 (code 1)
make[2]: *** [mixprt_I.o] Error 1

Revised code to realign the character array.

character(4) :: titl(18,nmix)
real , intent(in) :: dens(nmix)
real :: dtmp(nmix)
real :: awr(nmix)
real :: rho(mxxt)
!-----------------------------------------------
! L o c a l V a r i a b l e s
!-----------------------------------------------
integer :: i
character(72) :: title(nmix)
!-----------------------------------------------
ntmp(:nmix) = nucl(:nmix)
mtmp(:nmix) = mixt(:nmix)
dtmp(:nmix) = dens(:nmix)
do i=0,17
title(4*i+1:4*i+4)(:) = titl(i+1,:)
end do
call prtmix ( mtmp, ntmp, dtmp, awr, za, title, rho, mxxt, nmix, nsct, pbxs, outpt )

No warning but code segfaults in called subroutine while storing data in the array.

character(4) :: titl(18,nmix)
real , intent(in) :: dens(nmix)
real :: dtmp(nmix)
real :: awr(nmix)
real :: rho(mxxt)
!-----------------------------------------------
! L o c a l V a r i a b l e s
!-----------------------------------------------
integer :: i, j
character(72) :: title(nmix), title_t
!-----------------------------------------------
ntmp(:nmix) = nucl(:nmix)
mtmp(:nmix) = mixt(:nmix)
dtmp(:nmix) = dens(:nmix)
do j=1,nmix
do i=0,17
title_t(4*i+1:4*i+4) = titl(i+1,j)
end do
title(j) = title_t
end do
call prtmix ( mtmp, ntmp, dtmp, awr, za, title, rho, mxxt, nmix, nsct, pbxs, outpt )

Code runs as it used to before. Kind of messy work around for something that used to be straight forward.

Robert McBroom

Steven_L_Intel1 · ‎09-06-2007

You don't show the declaration of the corresponding argument of routine ptrmix. It looks as if the Intel compiler is catching a coding error that those other compilers did not. It is not legal to pass a CHARACTER(4) variable to a CHARACTER(72) argument. I'd need to see a complete example to explain why you got a segfault.

quemado · ‎09-07-2007

In the byte count days 4x18=72. The master binary data files were written with that structure. The routine prtmix just passes the array to the next in the chain. A complete example runs to several hundred Meg of code and data.

character(len=72) :: titl(nmix)
real :: den(nmix)
real :: awr(nmix)
real , intent(inout) :: rho(mixt)
!-----------------------------------------------
! L o c a l V a r i a b l e s
!-----------------------------------------------
integer :: mlast, n, l, m, i
real :: wtf, mneut, avogad
!-----------------------------------------------
call constant ( 'neutron_mass', mneut )
call constant ( 'avogadro', avogad )
write (nou, 10000) title, nsct, pbxs
call sortmx (mix, nuc, den, za, awr, titl, nmix)

The routine that segfaults with the code in the second example part of mixprtis sortmx which is reordering the array to have the problem specific data all grouped at the top of the array.

module sortmx_I

contains

subroutine sortmx(mix, nuc, den, za, awr, titl, mx)
!...Translated by Pacific-Sierra Research 77to90 4.3B 13:43:02 8/20/97
!...Switches: -xf2 -qt -pl0 -rl
implicit none
!-----------------------------------------------
! D u m m y A r g u m e n t s
!-----------------------------------------------
integer , intent(in) :: mx
integer , intent(inout) :: mix(mx)
integer , intent(inout) :: nuc(mx)
integer , intent(inout) :: za(mx)
character(72) , intent(inout) :: titl(mx)
real , intent(inout) :: den(mx)
real , intent(inout) :: awr(mx)
!-----------------------------------------------
! L o c a l V a r i a b l e s
!-----------------------------------------------
integer :: i, j, k, l, m, n
real :: f
character(72) :: xttl
!-----------------------------------------------

do i = 1, mx
m = mix(i)
n = za(i)
do j = i + 1, mx
if (.not.(mix(j) mix(i) = mix(j)
mix(j) = m
m = mix(i)
&nbs p; za(i) = za(j)
za(j) = n
n = za(i)
k = nuc(i)
nuc(i) = nuc(j)
nuc(j) = k
f = den(i)
den(i) = den(j)
den(j) = f
f = awr(i)
awr(i) = awr(j)
awr(j) = f
xttl = titl(i)
titl(i) = titl(j)
titl(j) = xttl
end do
end do

end subroutine sortmx

end module sortmx_I

Robert McBroom

Steven_L_Intel1 · ‎09-07-2007

I understand that 4x18=72, but it's still not legal Fortran. Before you turned it into a module, compilers could not detect the error, and some F90 compilers might not have detected it regardless.

I'd be interested in seeing a complete, buildable sample that shows the segfault. Please attach a tar file of one to an Intel Premier Support issue and ask that it be assigned to Steve Lionel.