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

[Janne Blomqvist <blomqvist dot janne at gmail dot com>]

Steve Kargl wrote:
> On Fri, Aug 28, 2009 at 11:06:31AM +0100, IainS wrote:
> > 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.

Yes, this is a historical accident, that should be fixed when we need to 
break ABI compatibility. See

http://gcc.gnu.org/wiki/LibgfortranAbiCleanup

For new code, we shouldn't repeat this mistake.

> > 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.

Again, this is a case where one shouldn't repeat the mistakes of the 
past. In most cases we should have as few library functions as possible 
and the frontend doing any type casting before calling the library. E.g. 
for LOGICAL arguments, the library should just contain a single function 
that takes a logical of default kind (GFC_LOGICAL_4), and the frontend 
being responsible for creating a logical(kind=4) temporary in case the 
user calls the intrinsic with a logical of some other kind. Of course, 
for floating point arguments, we still need multiple library functions.

Again, see http://gcc.gnu.org/wiki/LibgfortranAbiCleanup


--
Janne Blomqvist