Re: sparc vs lapack

[craig at jcb-sc dot com]

>In a message dated 7/15/99 10:41:15 AM PST, rth@cygnus.com writes:
>
>> (I don't think Fortran statement functions are that common.)
>
>The Fortran standards committees have tried to persuade us to switch to 
>internal subroutines, but they don't work as well on any compiler I've tried 
>and haven't even been proposed for g77.  Maybe complex typed statement 
>functions are rare; it might even be debatable whether complex*16 statement 
>functions could be expected to work.

Statement functions seem to be quite popular, certainly in the kind of
code g77 compiles.

And as far as the gcc back end is concerned, an internal procedure
(subroutine or function) looks just like a statement function -- it's
a nested procedure -- though some of the more esoteric requirements
of supporting internal procedure might require changes to the back end
or kludgy implementations by the front end.  (I can't think of any, but
there might be the same kind of requirement/capability imbalances that
require g77 to use a kludgy implementation for alternate ENTRY.)

BTW, g77 should support DOUBLE COMPLEX, or COMPLEX*16, statement functions
just fine.  And, even a statement function that doesn't return a value
of type COMPLEX can take arguments of that basic type, thus returning
us to the original issue of making sure gcc/g77 works when compiling
and calling such functions.

Also, long ago, the g77 front end made some attempt to support internal
functions at least through some level of parsing.  A few years back or
so, I commented out much of that code, to reduce the size of the
executable and to stop having to worry about maintaining it as the
front end changed.  Besides, the semantic rules of internal procedures
are just way too complicated to implement them in an off-hand manner:
the Fortran 90 language design effort *really* blew that design, in
many fundamental ways, from a language-design perspective.  (The symptoms
being incredibly long threads on comp.lang.fortran consisting primarily
of people banging their heads against a wall trying to figure out
why an internal procedure, created out of what used to be an external
procedure, doesn't work right, only to find the problem being some
weird standard-mandated interaction between local and "host", or outer-
scope, symbols, among other things, requiring far more attention to
the details of specification statements in an internal procedure than
should be necessary to avoid coding bugs.)

        tq vm, (burley)