Handling of Fortran language extensions
One place where Sun Fortran needs work is in management of language extensions. For example, it seems that it is not possible to exclude the generic REALLOC() extension function, meaning that it is not possible to have a generic subroutine interface of that name. The same is probably true of many other extensions. Also, using the -ansi flag causes warnings about F2003 features as extensions. It also allows incorrect use of F2003 features, and has no way to warn specifically about non-standard usage.
I think that a good approach to language extensions is to support all of them in terms of intrinsic modules, including all of the existing non-standard extensions. Instead of compiler flags to control sets of extensions, the "-use=" flag could be used to automatically include those extensions for existing code that uses it. Supporting extensions this way also allows extensions to be used selectively in certain subroutines, and would allow renaming so that name conflicts can be avoided without completely disabling the extension.
[1051 byte] By [
Joe_Krahna] at [2007-11-27 10:36:45]
# 1
> I think that a good approach to language extensions
> is to support all of them in terms of intrinsic
> modules, including all of the existing non-standard
> extensions.
I strongly agree with this statement. This is precisely what the NAG compiler does and it works well. Moreover in F2003, such vendor-supplied modules don't stomp on the module namespace; I can have a module of exactly the same name, and the compiler will use mine, unless I specifically ask for the intrinsic one as in "use, intrinsic :: ..." It seems that the F2003 standards committee had just this approach in mind.
As a general principle I think compilers should, by default, be strictly standards-compliant; if I want to use some language extension I should have to throw some compiler flags to do so (or use an intrinsic module). Unfortunately, for most compilers the default seems to be an extended language with (sometimes, but not here) compiler flags to turn on warnings about non-standard usage. This just encourages writing sloppy, non-portable Fortran.
# 2
> As a general principle I think compilers should, by
> default, be strictly standards-compliant; if I want
> to use some language extension I should have to throw
> some compiler flags to do so (or use an intrinsic
> module). Unfortunately, for most compilers the
> default seems to be an extended language with
> (sometimes, but not here) compiler flags to turn on
> warnings about non-standard usage. This just
> encourages writing sloppy, non-portable Fortran.
While your position has merit, it is the minority view.
Most of the users I deal with have never seen the
Fortran standard. They just want their codes to
compile and run regardless of whether those codes
are standard conforming or not. That is why pretty
much all of the major vendors' compilers accept the
same extensions.
I have known compiler vendors who chose not to
implement the industry-standard extensions. One of
them was reasonably successful when they had the
only compiler for a particular popular platform. They
lost almost all their customers as soon as a second
compiler became available.
Bob Corbett
# 3
It may be a minority view to handle extensions as modules, but it is not a minority view to avoid interference with completely valid code. Intel Fortran compiles the code posted under bug 6579426 with no problems, despite the fact that it supports the same traditional realloc() extensions as Sun Fortran. This has to be fixed to be Standards compliant, and therefore is a bug.
Without vendor modules, language extensions are not supposed to be brought into the name space if the first instance of their use is to declare them otherwise. If REALLOC is declared INTRINSIC, the extension becomes valid. If REALLOC is declared EXTERNAL, the extension becomes invalid, unless it is provided as an external-procedure in a library which only gets linked in if their is no such user function. Sun Fortran seems to get this right.
If REALLOC is first seen in an INTERFACE declaration that conflicts with the intrinsic REALLOC, then the user's REALLOC takes priority. Sun Fortran gets this wrong. For example, if I declare "intrinsic :: realloc", then Intel Fortran gives me the same generic-procedure error as Sun.
# 4
Just to summarize a bit:
People want old code to "just work". But, all compilers should have at least two general modes: one being standards compliant, and one that supports all extensions by default. Good compilers give a more fine-grained control, traditionally via compiler-dependent flags like Sun's "-f77=...". Modules provide a much cleaner way to organize these extensions. It allows access control to be better managed in Fortran90+, but can still be automatically made available through traditional compiler flags. For example, -std=f2003 turns off all extensions, but also turns off features deprecated in F2003.
This is particularly with Sun's "-use=" flag, which can provide the same control. I would also add a "-use-intrinsic=" to account for intrinsic modules. Then, you could use a syntax like this:
-use-intrinsic=%all-- activate all of the extensions (traditional mode).
-use-intrinsic=sun_cray_pointers -- only use Cray-pointer extensions.
-use-intrinsic=iso_c_binding -- use C-binding features automatically.
