Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!cs.umn.edu!uc!shamash!rrr
From: rrr@u02.svl.cdc.com (Rich Ragan)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran 90 status
Message-ID: <32775@shamash.cdc.com>
Date: 2 May 91 19:48:59 GMT
Article-I.D.: shamash.32775
References: <1991Apr24.202115.16119@dragon.wpd.sgi.com> <22900@lanl.gov> <5526@goanna.cs.rmit.oz.au> <23069@lanl.gov>
Sender: usenet@shamash.cdc.com
Reply-To: rrr@svl.cdc.com
Organization: Control Data Corporation, Silicon Valley Operations
Lines: 20

In <23069@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:

>This is why it's easy to do this in the loader.  The information is
>usually there (in the symbol tables).  Further, the information is
>in its final form: all the compilation is done by the time the loader
>runs.

This is exactly what we do in the Control Data Cyber 180 Fortran.
The compiler has an option to generate caller/callee information tables.
At load time, the loader will report type mismatches, usage mismatches
(e.g., storing into a constant or an expression result), scalar/array
mismatches (e.g. passing a variable to an array), and probably a
couple of other checks I can't remember off the top of my head.
It works quite well and the loader tables get chucked when the
fully bound production version is generated so you don't have any
space cost in production binaries.
--
Richard R. Ragan   rrr@svl.cdc.com    (408) 496-4340 
Control Data Corporation - Silicon Valley Operations
5101 Patrick Henry Drive, Santa Clara, CA 95054-1111