Defining a HAVE_J0 in config.h for gfortran?

Defining a HAVE_J0 in config.h for gfortran?

[Steve Kargl]

I'm contemplating adding j0, j0f, j1, j1f, y0, y0f, y1, and y1f
intrinsic functions to gfortran for compatibility with g77.  In
gcc/libgfortran I can modify configure.ac with a line similar to

AC_CHECK_LIB([m],[j0],[AC_DEFINE([HAVE_J0],[1],[libm includes j0])])

to check that j0 is present in libm.  I however need the HAVE_J0
symbol in gcc/gcc/fortran.  There is no configure.ac in this 
directory, so I need some other way to define HAVE_J0.  Any pointers
would be appreciate.

-- 
Steve

Re: Defining a HAVE_J0 in config.h for gfortran?

[Tom Tromey]

>>>>> "Steve" == Steve Kargl <sgk@troutmask.apl.washington.edu> writes:

Steve> I'm contemplating adding j0, j0f, j1, j1f, y0, y0f, y1, and y1f
Steve> intrinsic functions to gfortran for compatibility with g77.  In
Steve> gcc/libgfortran I can modify configure.ac with a line similar to
Steve> AC_CHECK_LIB([m],[j0],[AC_DEFINE([HAVE_J0],[1],[libm includes j0])])
Steve> to check that j0 is present in libm.  I however need the HAVE_J0
Steve> symbol in gcc/gcc/fortran.  There is no configure.ac in this 
Steve> directory, so I need some other way to define HAVE_J0.  Any pointers
Steve> would be appreciate.

One problem is that you want to do the library tests for the target,
but front ends are built for the host.  For gcj our solution was to
have the library generate a spec file that is then read by the front
end.  Then we add internal-only options that can be used to
communicate configury (or whatever) results from the library back to
the compiler.  This approach is very flexible, e.g., we could (in
theory, I don't think we've tried this) handle situations where
different multilibs of the same compiler have different
characteristics.

Tom

Re: Defining a HAVE_J0 in config.h for gfortran?

[Richard Henderson]

On Wed, Aug 11, 2004 at 08:27:45PM -0700, Steve Kargl wrote:
> I'm contemplating adding j0, j0f, j1, j1f, y0, y0f, y1, and y1f
> intrinsic functions to gfortran for compatibility with g77.  In
> gcc/libgfortran I can modify configure.ac with a line similar to
> 
> AC_CHECK_LIB([m],[j0],[AC_DEFINE([HAVE_J0],[1],[libm includes j0])])
> 
> to check that j0 is present in libm.  I however need the HAVE_J0
> symbol in gcc/gcc/fortran.  There is no configure.ac in this 
> directory, so I need some other way to define HAVE_J0.  Any pointers
> would be appreciate.

You don't want anything in the front end.  Define the intrinsics
all the time (modulo standards conformance).

Then you either provide the function in libgfortran, or just let
it be resolved (or not) by libm.

If they do come out unresolved for a particular system, then they
do.  Unlike the other intrinsics being discussed, the bessel functions
are not required for other Fortran standard conformance.  I don't
know that we should be trying to remedy every deficiency in the
system libm...


r~

Re: Defining a HAVE_J0 in config.h for gfortran?

[Steve Kargl]

On Wed, Aug 11, 2004 at 09:19:08PM -0700, Richard Henderson wrote:
> On Wed, Aug 11, 2004 at 08:27:45PM -0700, Steve Kargl wrote:
> > I'm contemplating adding j0, j0f, j1, j1f, y0, y0f, y1, and y1f
> > intrinsic functions to gfortran for compatibility with g77.  In
> > gcc/libgfortran I can modify configure.ac with a line similar to
> > 
> > AC_CHECK_LIB([m],[j0],[AC_DEFINE([HAVE_J0],[1],[libm includes j0])])
> > 
> > to check that j0 is present in libm.  I however need the HAVE_J0
> > symbol in gcc/gcc/fortran.  There is no configure.ac in this 
> > directory, so I need some other way to define HAVE_J0.  Any pointers
> > would be appreciate.
> 
> You don't want anything in the front end.  Define the intrinsics
> all the time (modulo standards conformance).

That will make things easier; although I was trying to keep the
frontend clean of undefined intrinsics.

> If they do come out unresolved for a particular system, then they
> do.  Unlike the other intrinsics being discussed, the bessel functions
> are not required for other Fortran standard conformance.

I know the bessel functions are not part of the Fortran standard.
Unfortunately, we need backwards compatibility with g77 and the author
of g77 made libg2c the kitchen sink of Fortran extensions.  If g77
detects the presences of the bessel functions, it includes them; otherwise
it does not.

> I don't know that we should be trying to remedy every deficiency in the
> system libm...

Are stubs acceptable?  That is, if j0 isn't in libm, can I do (in
psuedo-code)

j0(arg) {
   printf("Extension: j0 Bessel function is unsupported.\n");
   exit(1);
}

in libgfortran.

-- 
Steve

Re: Defining a HAVE_J0 in config.h for gfortran?

[Richard Henderson]

On Wed, Aug 11, 2004 at 10:13:07PM -0700, Steve Kargl wrote:
> Are stubs acceptable?  That is, if j0 isn't in libm, can I do (in
> psuedo-code)
> 
> j0(arg) {
>    printf("Extension: j0 Bessel function is unsupported.\n");
>    exit(1);
> }
> 
> in libgfortran.

Seems better to just not let it link.


r~

Re: Defining a HAVE_J0 in config.h for gfortran?

[Joseph S. Myers]

On Wed, 11 Aug 2004, Richard Henderson wrote:

> If they do come out unresolved for a particular system, then they
> do.  Unlike the other intrinsics being discussed, the bessel functions
> are not required for other Fortran standard conformance.  I don't
> know that we should be trying to remedy every deficiency in the
> system libm...

One thing to bear in mind is that there is a draft TR for additional 
<math.h> functions (WG14 N1051) that adds these functions under different 
names, so in future it might be necessary to consider libm with the new 
names but not the old.  But hopefully libgfortran configure can deal with 
that as and when it is needed.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: Defining a HAVE_J0 in config.h for gfortran?

[Toon Moene]

Joseph S. Myers wrote:

> On Wed, 11 Aug 2004, Richard Henderson wrote:

>>If they do come out unresolved for a particular system, then they
>>do.  Unlike the other intrinsics being discussed, the bessel functions
>>are not required for other Fortran standard conformance.  I don't
>>know that we should be trying to remedy every deficiency in the
>>system libm...

> One thing to bear in mind is that there is a draft TR for additional 
> <math.h> functions (WG14 N1051) that adds these functions under different 
> names, so in future it might be necessary to consider libm with the new 
> names but not the old.  But hopefully libgfortran configure can deal with 
> that as and when it is needed.

And, in addition to this, there's a good chance that Bessel functions et 
al. will be intrinsic functions in Fortran 2008 (which will be the 
Fortran Standard after 2003 has gone out succesfully - a paper exercise 
if there ever was one ... ;-)

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/

Re: Defining a HAVE_J0 in config.h for gfortran?

[Steve Kargl]

On Mon, Aug 16, 2004 at 05:50:28PM +0200, Toon Moene wrote:
> Joseph S. Myers wrote:
> 
> >On Wed, 11 Aug 2004, Richard Henderson wrote:
> 
> >>If they do come out unresolved for a particular system, then they
> >>do.  Unlike the other intrinsics being discussed, the bessel functions
> >>are not required for other Fortran standard conformance.  I don't
> >>know that we should be trying to remedy every deficiency in the
> >>system libm...
> 
> >One thing to bear in mind is that there is a draft TR for additional 
> ><math.h> functions (WG14 N1051) that adds these functions under different 
> >names, so in future it might be necessary to consider libm with the new 
> >names but not the old.  But hopefully libgfortran configure can deal with 
> >that as and when it is needed.
> 
> And, in addition to this, there's a good chance that Bessel functions et 
> al. will be intrinsic functions in Fortran 2008 (which will be the 
> Fortran Standard after 2003 has gone out succesfully - a paper exercise 
> if there ever was one ... ;-)
> 

I don't really care about what the C standard might do, 
and I don't care about future Fortran standards beyond
F2003.  However, I do care about unreviewed patchs. :-)

http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00965.html

-- 
Steve