Bug 36096 - F2008 Bessel: Documentation/diagnostic errors
Summary: F2008 Bessel: Documentation/diagnostic errors
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic, documentation
Depends on:
Blocks: 39627 33197
  Show dependency treegraph
 
Reported: 2008-05-01 06:23 UTC by Tobias Burnus
Modified: 2014-06-09 10:09 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-03-28 15:45:48


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2008-05-01 06:23:36 UTC
Found at:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e9add97708681397

Please re-check the thread, I have likely missed something.


BESSEL_J0, BESSEL_J1, BESSEL_Y0, and BESSEL_Y1 are elemental, but the manual says otherwise.http://gcc.gnu.org/onlinedocs/gfortran/Intrinsic-Procedures.html

Note by Dan:
| The j0, j1, y0, y1 functions are elemental.
| The confusion come from the jn and yn functions.
| 
| There are two versions of these.  One is elemental.
| That one is the straight y( :) = jn( n, x( :)) version.
| 
| The transformational version is j/yn( n1, n2, x) version.
| This returns all j/y's between order n1 and order n2 inclusive. 


Furthermore, James Van Buskirk writes:

So gfortran treats the elemental case of BESSEL_J0 elementally
even though its documentation says that X shall be scalar, and
it treats the elemental cases of BESSEL_JN elementally even though
its docs says N and X shall be scalar, and N1723.pdf says the result
of BESSEL_JN(N,X) is scalar.

gfortran doesn't document nor does it implement the transformational
flavor of BESSEL_JN(N1,N2,X), partly because the N1723 documentation
is vague (I think) and partly because transformational intrinsics
are a royal PITB.


The manual says DFLOAT needs an INTEGER actual argument but in fact
it will takes REAL*4, REAL*8, or REAL*10.  LOG_GAMMA was out of
alphabetic order in the manual.  Is it true the gfortran's
implementation of NINT doesn't take a KIND optional argument?
Amusing that there is an INT2 and INT8 but no INT1 nor INT4.  I
suppose you don't want to add extensions like that if you don't
really have to.  Similar with SNGL accepting REAL*8 but not
REAL*10 input.

I didn't see what the default KIND for the result of CEILING was
in the manual.

ERF, ERFC, GAMMA, and LOG_GAMMA returned NaN for REAL*10 inputs in
my test.  EXPONENT returned garbage for REAL*10 and FRACTION
return its input for REAL*10.  SPACING and RRSPACING were hosed in
my test so that I didn't capture any output.

Test is at http://home.comcast.net/~kmbtib/Fortran_stuff/funr1.ZIP
Oops, I forgot to include a README: you can run the tests by
deleting funr1_gfc.out and funr1_gfc.err and then running
funr1_gfc.bat.  If not on Windows, you may have to edit those
*.bat files to make it all go. :)
Comment 1 Tobias Burnus 2008-05-05 05:28:27 UTC
> ERF, ERFC, GAMMA, and LOG_GAMMA returned NaN for REAL*10 inputs in
> my test.  EXPONENT returned garbage for REAL*10 and FRACTION

There is another thing which has to be addressed. On Windows there seems to be no "long double" support for some C99 functions. FX writes in the same thread:

> > I would assume that the absence of BESSEL_J0, BESSEL_J1, BESSEL_Y0, and
> > BESSEL_Y1 for REAL(10) inputs for non-initialization expressions for
> > both Win32 and Win64 is a different issue altogether.
>
> This isn't, for now, treated as a bug: Windows C library doesn't provide
> these C99 intrinsic functions ({j,y}{0,1}l). It's been our policy until
> now that while we provide fallback versions of some C99 intrinsics when
> they're missing (for example, float variants or double variants), support
> for real types larger than double (real kinds 10 and 16) entirely relies
> on the system libraries for mathematical intrinsics. Maybe this should be
> documented somewhere, but I don't know really where. Suggestions as to a
> point where to insert this in our current documentation are welcome.
Comment 2 kargl 2008-05-05 06:06:02 UTC
(In reply to comment #1)
> > ERF, ERFC, GAMMA, and LOG_GAMMA returned NaN for REAL*10 inputs in
> > my test.  EXPONENT returned garbage for REAL*10 and FRACTION
> 
> There is another thing which has to be addressed. On Windows there seems to be
> no "long double" support for some C99 functions. FX writes in the same thread:
> 

This is true for many operating systems.  For example, none of the 
*BSD systems have a complete C99 libm.  It's not windows specific.
It took me nearly 2 years to get a sqrtl() committed to FreeBSD.
Note sqrtl() is special in that ieee754 requires correct rounding
in all rounding modes.  It took between 6 to 9 months to get 
sinl(), cosl(), and tanl() committed to FreeBSD.  Writing standard
conforming libm functions that have accept ULP is much harder than
one might think.

The simplest fix is to add a note to the Intrinsic Procedure 
section of the manual stating the ligfortran/gfortran depends
on a C99 libm.
Comment 3 Francois-Xavier Coudert 2014-06-09 09:49:32 UTC
Author: fxcoudert
Date: Mon Jun  9 09:49:01 2014
New Revision: 211368

URL: http://gcc.gnu.org/viewcvs?rev=211368&root=gcc&view=rev
Log:
	PR fortran/36096
	* intrinsic.texi: Fix documentation of BESSEL_J0, BESSEL_J1,
	BESSEL_Y0, and BESSEL_Y1.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/intrinsic.texi
Comment 4 Francois-Xavier Coudert 2014-06-09 10:09:24 UTC
Documentation for BESSEL is fixed, and transformational variants of BESSEL_JN and BESSEL_YN have been implemented since the PR was created. I've checked the other doc issues reported, and they have all been fixed at some point. Thus: closing this issue.