Re: %LOC and %VAL availability



On Nov 24, 10:30 am, James Tursa <aclassyguywithakno...@xxxxxxxxxxx>
wrote:
The non-standard %LOC() and %VAL() constructs are available in the
Intel Fortran and Compaq Fortran compilers that I have (32-bit,
WinXP). Are these constructs available in other compilers such as
gfortran, f95, etc? What about linux, mac, etc.? If not, is there a
workaround for this functionality? I am writing a package for others
to use and would like it to run in other environments out of the box
if possible. Thanks.

See the gfortran documentation for information concerning its
implementation of these constructs.

Short: gfortran supports %LOC(), %VAL() and %REF(), see
http://gcc.gnu.org/onlinedocs/gfortran/Argument-list-functions.html and
GCC/gfortran runs on a large variety of systems (Sparc, x86, arm, mips,
PowerPC, ia64, x86-64, s390, ...) and operating systems (FreeBSD, Linux,
Windows, Darwin (Mac), AIX, Solaris, HPUX, ...). [And the Intel compiler
you mention also runs on (x86 and x86-64) Windows, Linux and Mac.] Note,
however, that those are only supported as arguments in procedure calls
and not on their own (cf. "LOC()"). Note further that these all are
vendor extensions, which are relatively common but by far not supported
by all compilers.

As others have pointed out before, using the C binding support is the
better alternative. See, e.g.,
http://gcc.gnu.org/onlinedocs/gfortran/Interoperability-with-C.html and
especially
http://gcc.gnu.org/onlinedocs/gfortran/Interoperable-Subroutines-and-Functions.html
for an introduction, which should be relatively vendor agnostic.
The C binding support - as defined in the Fortran 2003 standard - is
present is a number of recent compilers, but older ones do not have it.

It depends on your users whether it is more likely that they have
compilers with %LOC, %VAL or with C binding support. But if you have the
choice, I would go for the latter. Advantages: (a) C bindings are well
defined (Fortran standard; vendor extensions tend to differ slightly
between vendors and even different versions). (b) I think the syntax is
also easier: You define what the procedure wants to get (e.g. a
pass-by-value argument) and then you simply pass the variable in the
call without having to care whether it should be a %VAL or a %REF or
%LOC. (c) The market share of older compilers is decreasing thus C
binding support should become more and more common.

Example for compilers not supporting %VAL: NAG f95. Example for not
supporting C bindings: Open64, g77. Examples for supporting both: ifort,
gfortran, sunf95, g95.

Tobias
.



Relevant Pages

  • Re: "Implicit" use of assignment(=)
    ... but that also doesn't work with those compiles which claim full Fortran 2003 conformance; vendors might miss smaller features. ... The code was compiling with 5 of my compilers - but not with the only one which claimed full Fortran 2003 conformance. ... For GCC 4.8 you can expect support for CLASSand FINAL subroutines - and many smaller improvements which aren't visible in the release notes; e.g. a fix for the bug which started this thread. ...
    (comp.lang.fortran)
  • Re: f2003 compilers?
    ... is compilers that are said to have "most" of 2003. ... As far as I understood it, supports all of Fortran ... nagfor v5.2, Intel's ifort v11.1, and GCC's gfortran v4.5 support a lot, ... but still there are many features unimplemented. ...
    (comp.lang.fortran)
  • Re: Announcement: GCC 4.6.0 / GCC at Google Summer of Code
    ... Is GFortran written in C, ... Where can I learn more about a GSC project with GFortran? ... favourite compiler - and earn some bucks as well. ... Support for new CPUs and improved CPU tuning - in particular with ...
    (comp.lang.fortran)
  • Re: fortran 2003 compiler
    ... I think there are two reasons: One is that implementing Fortran 2003 ... Fortran 90/95 which essentially all compiler support. ... Fortran 2003 features, check whether enough compiler support it. ... implemented in many compilers before they fully support Fortran 2003. ...
    (comp.lang.fortran)
  • Re: Suspicious Gfortran
    ... Fortran 77 compilers that exist, and thus doesn't mean anything in this ... problem is coming from a bug in your code, rather than a bug in gfortran. ...
    (comp.lang.fortran)