[gfortran,ping] support for large kinds in front-end and library

[Steve Kargl]

On Thu, Sep 01, 2005 at 09:55:24PM +0200, FX Coudert wrote:
> [http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00222.html]
> 
> >Can someone review it? Or only part of it? I guess the front-end part is 
> >more difficult and will need more care that the library part, since I am 
> >not an expert in this area.
> >
> >Built, tested and regtested on:
> >
> >  - i686-linux, which has real(10)
> >  - sparc-solaris, whichs has real(16)
> >  - x86_64-linux, which has real(10) and integer(16)
> >  - alpha-linux, which has integer(16)
> >
> >OK for mainline?
> 
> Steve staid the front-end part was OK given a few modifications (changes 
> included in the patch attached). Can someone review the library part?
> 
> FX
> 
> 
> PS: the frontend an test patches are version 3, the library is
> version 4, that's normal ;-)

I'm completely stymied by --enable-maintainer-mode.  After installing
up-to-date versions of autoconf, libtools, and automake, all tests
still still fail with

/home/kargl/gcc/obj41/i386-unknown-freebsd7.0/./libgfortran/.libs/\
libgfortran.so: undefined reference to `_gfortrani_internal_pack_c8'
: undefined reference to `_gfortrani_internal_unpack_4'
: undefined reference to `csin'
: undefined reference to `csqrt'
: undefined reference to `_gfortrani_internal_unpack_c4'
: undefined reference to `_gfortrani_internal_pack_8'
: undefined reference to `ccosf'
: undefined reference to `cexpf'
: undefined reference to `csqrtf'
: undefined reference to `clog'
: undefined reference to `_gfortrani_internal_unpack_c8'
: undefined reference to `_gfortrani_internal_pack_4'
: undefined reference to `csinf'
: undefined reference to `cexp'
: undefined reference to `_gfortrani_internal_unpack_8'
: undefined reference to `clogf'
: undefined reference to `_gfortrani_internal_pack_c4'
: undefined reference to `ccos'


If I randomly pick generated/_sin_c4.f90 from gcc 4.0.2
I see

   elemental function specific__sin_c4 (parm)
     complex (kind=4), intent (in) :: parm
     complex (kind=4) :: specific__sin_c4
     specific__sin_c4 = sin (parm)
   end function

If I compare this to generated/_sin_c4.F90 that is produced
during --enable-maintainer-mode, I see

   #include "kinds.inc"
   #if defined (HAVE_GFC_UNKNOW_)
   elemental function specific___ (parm)
     unknown (kind=), intent (in) :: parm
     unknown (kind=) :: specific___
     specific___ =  (parm)
   end function
   #endif

The only rule I can find in obj41/i386-unknown-freebsd7.0/libgfortran
is

_sin_c4.lo: generated/_sin_c4.F90
    $(LIBTOOL) --mode=compile $(FC) $(DEFS) $(DEFAULT_INCLUDES) \
    $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_FCFLAGS) $(FCFLAGS) \
    -c -o _sin_c4.lo `test -f 'generated/_sin_c4.F90' || echo \
    '$(srcdir)/'`generated/_sin_c4.F90

Checking the $(YADA) variables shows no references to HAVE_GFC_UNKNOW_
kargl[223] find . -type f | xargs grep UNKNOW_ | grep -v Binary | more
kargl[224] pwd
/home/kargl/gcc/obj41

So, HAVE_GFC_UNKNOW_ is not set, and we build an empty _sin_c4.o,
which should contain csin().

Assuming that there is pilot error in some step I execute and in
the absense of other reviewer interest in this patch,  FX can you
send me a uuencode, gzipped, tarball of gcc/libgfortran with your
patch applied.  I'd like to compare what I have now and then build
gfortran with your gcc/libgfortran.  If all goes well with your
gcc/libgfortran, I say commit the patch.

-- 
steve