[comp.lang.fortran] Fortran compiler test

cpcahil@virtech.uucp (Conor P. Cahill) (10/18/90)

I am trying to tally which fortran compilers provide a compatibility
with the fortran compiler delivered with masscomp systems (which is reputed
to provide compatibility with the AT&T compiler).  

The problem area is that if we open a file with a record length of 1 the 
at&t compiler then will read as much data as necessary to solve the 
read argument list.  

If you have the time (it only takes a couple of minutes) pleas run the
attached test & email the results to me.  I will post a summary if
desired.

I have run the test on the following compilers:

	HP/UX f77,  NDP Fortran, and LPI Fortran

All of which failed.

Thanks in advance.

(To run the test, unshar the rest of this posting and run "runtest.sh")

#!/bin/sh
# This is a shell archive (shar 3.21)
# made 10/12/1990 18:51 UTC by cpcahil@virtech
#
# existing files WILL be overwritten
#
# This shar contains:
# length  mode       name
# ------ ---------- ------------------------------------------
#    425 -rw-r--r-- testio.f
#    306 -rwxr-xr-x runtest.sh
#
if touch 2>&1 | fgrep '[-amc]' > /dev/null
 then TOUCH=touch
 else TOUCH=true
fi
# ============= testio.f ==============
echo "x - extracting testio.f (Text)"
sed 's/^X//' << 'SHAR_EOF' > testio.f &&
X      CHARACTER STRING*8,FNAME*12
X      FNAME='wada'	
X      OPEN(1,FILE=FNAME,RECL=1,ACCESS='direct',FORM='unformatted')
X      NREC=1
X      READ(1,REC=NREC)STRING
X      IF(STRING.EQ.'!<ARCH>\n')THEN
X        WRITE(6,100)FNAME,STRING
X      ELSE
X        WRITE(6,101)FNAME,STRING
X      ENDIF
X      STOP
X  100 FORMAT(' FILE=',A12,' is an archive; STRING=',A8)
X  101 FORMAT(' FILE=',A12,' is not an archive; STRING=',A8)
X      END
SHAR_EOF
$TOUCH -am 1012143690 testio.f &&
chmod 0644 testio.f ||
echo "restore of testio.f failed"
set `wc -c testio.f`;Wc_c=$1
if test "$Wc_c" != "425"; then
	echo original size 425, current size $Wc_c
fi
# ============= runtest.sh ==============
echo "x - extracting runtest.sh (Text)"
sed 's/^X//' << 'SHAR_EOF' > runtest.sh &&
X
X#
X# compile the program
X#
Xf77 testio.f -o testio
X
X#
X# generate data file to be read
X#
Xecho banana > junk
Xar r wada junk
X
X#
X# run the test
X#
Xresult="`./testio | grep 'is an'`"
X
Xif [ ! -z "$result" ]; then
X	echo TEST was successful
Xelse
X	echo TEST failed
Xfi
X
X#
X# clean up
X#
Xrm -f junk wada testio.o testio
X
SHAR_EOF
$TOUCH -am 1012145190 runtest.sh &&
chmod 0755 runtest.sh ||
echo "restore of runtest.sh failed"
set `wc -c runtest.sh`;Wc_c=$1
if test "$Wc_c" != "306"; then
	echo original size 306, current size $Wc_c
fi
exit 0
-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

ereiamjh@jhunix.HCF.JHU.EDU (Tom B. O'Toole) (10/19/90)

It doesn't work (it's doesn't even get started) on my
VMS system. Maybe you made a few too many assumptions?

-- 
Tom O'Toole - ecf_stbo@jhuvms.bitnet - JHUVMS system programmer 
Homewood Computing Facilities, Johns Hopkins University, Balto. Md. 21218 
ease!Trim!eeeaaaassse!trimtrimtrimeeeeeeaaaaassetrimease!trim!ease!trimeaase

cpcahil@virtech.uucp (Conor P. Cahill) (10/19/90)

In article <6662@jhunix.HCF.JHU.EDU> ereiamjh@jhunix.HCF.JHU.EDU (Tom B. O'Toole) writes:
>It doesn't work (it's doesn't even get started) on my
>VMS system. Maybe you made a few too many assumptions?

I didn't make any assumptions.  This tests an extension to fortran that was
added by AT&T (this is from a second hand source, so I may have it wrong). 

The reason for the test is my client has a big simulation software package 
that he created on a masscomp system that makes use of this little
feature.  We are looking for another compiler that has the same "feature" so
we can upgrade his system.

Results so far:

	Sun 		Failed
	Cray		Failed
	Ultrix 4.0	Failed
	MIPS RC6280	Failed

Looks like someone is going to have to do alot of recoding.  (Let this
be an example of why you shouldn't use compiler-specific extensions)
-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

ereiamjh@jhunix.HCF.JHU.EDU (Tom B. O'Toole) (10/19/90)

I think you made the assumption that a computer is a box
of electronic components that runs the unix operating
system.

-- 
Tom O'Toole - ecf_stbo@jhuvms.bitnet - JHUVMS system programmer 
Homewood Computing Facilities, Johns Hopkins University, Balto. Md. 21218 
ease!Trim!eeeaaaassse!trimtrimtrimeeeeeeaaaaassetrimease!trim!ease!trimeaase

doug@jhunix.HCF.JHU.EDU (Douglas W O'neal) (10/19/90)

In article <1990Oct19.012745.7875@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes:
>In article <6662@jhunix.HCF.JHU.EDU> ereiamjh@jhunix.HCF.JHU.EDU (Tom B. O'Toole) writes:
->>It doesn't work (it's doesn't even get started) on my
->>VMS system. Maybe you made a few too many assumptions?
->
->I didn't make any assumptions.  This tests an extension to fortran that was
->added by AT&T (this is from a second hand source, so I may have it wrong). 
->

I think that you want the code to run on a UN*X box.  You have not said so,
but posting a shell archive and using commands such as touch seem to indicate
such.  Extensions common to various platforms can be tested, but your posting
*assumed* that we would run under some flavor of UN*X.
 
-- 
Doug O'Neal, Distributed Systems Programmer, Johns Hopkins University
doug@jhuvms.bitnet, doug@jhuvms.hcf.jhu.edu, mimsy!aplcen!jhunix!doug 
Like many of the features of UNIX, UUCP appears theoretically 
unworkable... - DEC Professional, April 1990

andyo@glasperl.masscomp (Andy Oram) (10/19/90)

I've been communicating with Conor P. Cahill through e-mail, but since people
are interested in the test for reading a stream bytes, I'll post this version
I just did (it's different from what I sent you, Conor).

I'm not tuned in to every variation in FORTRAN's and OS's, but I think that
the following are the only system-dependent things that I know the program
depends on (besides, of course, the extension you're trying to test):

    1. The program assumes that direct-access, unformatted files contain
       exactly the data that the program writes to them -- no extra record
       delimiters, etc.  On UNIX systems I think this is a fair
       assumption, since the original f77 compiler was based on it.  If
       it's not true, the whole notion of file as byte stream breaks down
       anyway.

    2. A character is one byte.  If anybody thinks THIS assumption is
       unsafe, let them suggest another standard data type that's more
       reliable.

(My background is that I wrote the latest few versions of MASSCOMP's Fortran
manual.)

      CHARACTER*8 STRING
      INTEGER IERR
      OPEN(1,RECL=8,ACCESS='DIRECT',FORM='UNFORMATTED',STATUS='NEW')
      WRITE(1,REC=1)'SPQRSPQR'
      CLOSE(1)
C
      OPEN(1,RECL=1,ACCESS='DIRECT',FORM='UNFORMATTED')
      READ(1,REC=1,IOSTAT=IERR)STRING
      IF(IERR .NE. 0)THEN
         WRITE(6,1000)IERR
      ELSEIF(STRING.EQ.'SPQRSPQR')THEN
        WRITE(6,1001)STRING
      ELSE
        WRITE(6,1002)STRING
      ENDIF
1000  FORMAT(1X,'ERROR: ',I5)
1001  FORMAT(1X,'OK -- GOT ',A8)
1002  FORMAT(1X,'NOT OK -- GOT ',A8)
      STOP
      END

-------------------------------------------------------------------------------

Andrew Oram                            Concurrent Computer Corporation
(I don't represent Concurrent; this message represents my own opinion)

Digital Communications Route: andyo@westford.ccur.com
                              {harvard,uunet,petsd}!masscomp!andyo
Analog Communications Route:  (508) 392-2865

Automatic UN*X documentation utility:

          cref | compress | crypt | man

-------------------------------------------------------------------------------

dik@cwi.nl (Dik T. Winter) (10/20/90)

In article <6671@jhunix.HCF.JHU.EDU> doug@jhunix.HCF.JHU.EDU (Douglas W O'neal) writes:
 > I think that you want the code to run on a UN*X box.  You have not said so,
 > but posting a shell archive and using commands such as touch seem to indicate
 > such.  Extensions common to various platforms can be tested, but your posting
 > *assumed* that we would run under some flavor of UN*X.
Not only the assumption was a UN*X box, but also some special UN*X box.  Not
all fortran compilers are called 'f77'; I have seen 'fortran', 'fort', 'fc',
'cft' to name but a few.  However, here are the results from an Alliant FX/4
running Concentrix (and the compiler is called 'fortran'):
   FORTRAN ERROR on Unit 1
   FORTRAN ERROR in line 5 of testio.f:  E_READ_RECORDTOOSMALL
   Cannot read a record larger than the RECORDSIZE value specified in the OPEN
   statement
   TEST failed
--
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl

bill@ssd.csd.harris.com (Bill Leonard) (10/23/90)

In article <1990Oct18.160412.8187@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes:

   I am trying to tally which fortran compilers provide a compatibility
   with the fortran compiler delivered with masscomp systems (which is reputed
   to provide compatibility with the AT&T compiler).  

   The problem area is that if we open a file with a record length of 1 the 
   at&t compiler then will read as much data as necessary to solve the 
   read argument list.  

   If you have the time (it only takes a couple of minutes) pleas run the
   attached test & email the results to me.  I will post a summary if
   desired.

I ran this test using the f77 compiler we got from AT&T, and it failed, so
I question whether that is an "AT&T compatibility" feature.  When I run the
program by hand, it prints out an error message complaining about premature
end-of-file (my interpretation of the obscure message it really produced),
and then aborts.

Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
bill@ssd.csd.harris.com
--
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
bill@ssd.csd.harris.com

bill@ssd.csd.harris.com (Bill Leonard) (10/23/90)

In article <1990Oct19.012745.7875@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes:

   Looks like someone is going to have to do alot of recoding.  (Let this
   be an example of why you shouldn't use compiler-specific extensions)

Grrrrrr, I really get irritated when I hear this statement.  First, if no
one used vendor extensions, ever, then the only way you would ever get new
language features is either with a brand-new language or by having some
committee (like X3J3) design it for you without any idea of how well it
will work or serve the intended purpose.  Vendor extensions give the
marketplace (i.e., the users) a chance to decide what features they like
and which one they don't.

Having said that, I would certainly advise a user not to use a vendor
extension IF: a) other vendors in that segment of the market do not offer
the same or at least similar extension, or b) the user does not have
sufficient "clout" to force the next vendor to implement the same
extension.  It is not necessary that EVERY vendor support an extension
unless you really plan to buy systems from every one of them (which is
highly unlikely).  If, for instance, your systems are primarily doing
accounting and payroll tasks, you are unlikely to buy systems from
a real-time vendor.

I've observed that certain market segments make unique demands on
programming languages, and vendors that are leaders in each segment usually
implement about the same set of extensions.  In fact, the vendor that does
not implement the extensions that are popular with users in his market
quickly finds himself losing business to those that do.  Therefore, you are
usually pretty safe in using those extensions.

Where you will get in trouble, though, is using an extension that is not
specific to a particular market and/or is not widely implemented.  However,
if the extension is the only (convenient) way to get the job done, then you
have the uncomfortable choice of either writing non-standard code or using
some other equally onerous solution.  If you happen to be a large corporate
user that buys millions of dollars worth of machines each year, probably
you can "persuade" other vendors to implement your extension; otherwise,
you have to either hope other users will like and promote it, or that you
won't have to change vendors for awhile. :-)

--
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
bill@ssd.csd.harris.com

rsb@makro.nhh.no (Roger S Bivand) (10/23/90)

A short comment on the original test program: both AT&T and BSD
"ar" denote their archives with lower case "arch", so the test
could never have worked. Altering the case leaves an AT&T f77 succeeding,
and Mips f77 failing. Insight is available from f2c, that is the
original source for AT&T f77 in essence. The converted c program
compiles and runs passing the test. In the Bell Labs CS Tech Report #149
of 8/2/90 (on research.att.com), the authors state "When using a machine
whose vendor provides but has gratuitously changed _libF77_ or _libI77_,
one cannot safely mix objects compiled from the C produced by f2c with
objects compiled with the vendor's Fortran compiler, and one must use
the correct libraries with programs translated by f2c" (p. 14). A
conclusion is then that by compiling via f2c and its libraries, emulation
of classical AT&T f77 behaviour may be possible. For the same reason,
programs targeted on machines not running Unix may also be rendered
portable by using f2c as a precompiler, and the lib[IF]77 in the f2c
release as the necessary libraries. There may on the other hand be
a slight efficiency loss, less I feel than the "recoding thousands of
lines of source" complaint.

Roger Bivand
Institute of Geography
Norwegian School of Economics and Business Administration
Bergen, Norway
rsb@czech.nhh.no