Re: [PATCH, gfortran testsuite]: Do not load denormals in gfortran.fortran_torture/intrinsic_nearest.f90

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Fri, Aug 28, 2009 at 11:06:31AM +0100, IainS wrote:
> 
> I have perused the wiki, read the gfc_internals pdf, and looked at  
> library versioning information.
> 
> Whilst the low-level issues of implementing the required FPU  
> manipulation functions per platform are relatively easy to  
> understand, I'm struggling with the various interface layers (as  
> applied to intrinsic modules defined within libgfortran).
> 
> for example, taking the iso_c_binding as an example.
> 
> I do not see a fortran interface definition for this module; rather  
> the c functions appear to be exported in a specific namespace  
> (__iso_c_binding_).

This is largely historical.  IIRC, it has been established that
the _gfortran_ prefix should be used by the routines in libgfortran.
However, with symbol versioned in libraries, gfortran now needs to
retain the __iso_c_binding_ prefix.

> Nor do I see an "iso_c_binding.mod" in the installation for gfortran;  
> indeed nm reveals that the relevant functions are part of the shared  
> libgfortran.

You won't a iso_c_binding.mod nor a iso_fortran_env.mod file.  These
are built on the fly.  See the files named iso-c-binding.def and
iso-fortran-env.def and the source code

troutmask:sgk[219] grep iso- *[ch]
gfortran.h:#include "iso-fortran-env.def"
gfortran.h:#include "iso-c-binding.def"
module.c:#include "iso-fortran-env.def"
module.c:#include "iso-fortran-env.def"
symbol.c:#include "iso-c-binding.def"
symbol.c:#include "iso-c-binding.def"
symbol.c:#include "iso-c-binding.def"
trans-types.c:#include "iso-c-binding.def"

> Is this the model that should be used for "ieee_arithmetic"? (i.e.  
> declare the c functions in a __ieee_arithmetic_ namespace).
> Is this the manner in which a USE statement decides how to form a  
> function name precursor ?

The prefix should be _gfortran_.  I haven't given it much thought, but
I suspect the IEEE modules can be built on the fly as well.

> The spec describes the introduction of derived types and constants  
> e.g.  IEEE CLASS TYPE,  IEEE ROUND TYPE.
> Where should these be defined?

Mostlikely in a iso-ieee754.def file.

> ===
> 
> if I want to add a subroutine to libgfortran which is
> 
> FOO(BAR)
> LOGICAL, INTENT(OUT) :: BAR
> 
> do I need to provide a series of c functions (in libgfortran/ 
> intrinsics/  ) viz:
> 

See the scripts in the m4/ subdirectory.  You basically need
to write a foo.m4 script that when processed will generated 
all of the possible functions for the target.  The generated
files are placed into the generated/ directory.

-- 
Steve