[Bug fortran/112873] New: F2023 degree trig functions

[Bug fortran/112873] New: F2023 degree trig functions

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

            Bug ID: 112873
           Summary: F2023 degree trig functions
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56810
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56810&action=edit
* intrinsic.cc(add_functions): Update the standard that the various   degree
trigonometric functions come from.   (gfc_check_intrinsic_standard):  Add an
error string for F2023.

The Fortran 2023 standard has added a number degree trigonometric
functions.  See 23-007r1.pdf, p. xiii:

   The intrinsic functions ACOSD, ASIND, ATAND, ATAN2D, COSD, SIND, and
   TAND are trigonometric functions in which angles are specified in
   degrees.

gfortran already supported these functions under its DEC Fortran
compatibility and made them available under -std=gnu.  There is a
-fdec-math function, but that seems to be non-functional or I don't
understand what it does.

In any event, the attached patch changes GFC_STD_GNU to GFC_STD_F2023
where appropriate.  It also added the case for GFC_STD_F2023 for 
error messages.

[Bug fortran/112873] F2023 degree trig functions

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #1 from kargl at gcc dot gnu.org ---
Possible ChangeLog (although I don't know the git world requirements).

* intrinsic.cc(add_functions): Update the standard that the various
  degree trigonometric functions have been described in.
  (gfc_check_intrinsic_standard):  Add an error string for F2023.

[Bug fortran/112873] F2023 degree trig functions

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

[Bug fortran/112873] F2023 degree trig functions

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #2 from anlauf at gcc dot gnu.org ---
The patch looks mostly fine, but can you explain why you make some of the
specific functions generic?  Like:

+  make_generic ("dacosd", GFC_ISYM_ACOSD, GFC_STD_GNU);

Because we do not make the ordinary specific dacos generic, only acos.

Do you also plan to provide a patch for gfortran.texi abd intrinsic.texi?

[Bug fortran/112873] F2023 degree trig functions

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Dec 06, 2023 at 08:56:32PM +0000, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
> 
> --- Comment #2 from anlauf at gcc dot gnu.org ---
> The patch looks mostly fine, but can you explain why you make some of the
> specific functions generic?  Like:
> 
> +  make_generic ("dacosd", GFC_ISYM_ACOSD, GFC_STD_GNU);
> 
> Because we do not make the ordinary specific dacos generic, only acos.

I'm probably mis-remembering how make_generic() works.  I'll look
at this PR over weekend and fix up the patch.

> Do you also plan to provide a patch for gfortran.texi abd intrinsic.texi?

Whoops.  I forgot about the *.texi files.  I'll update those this
weekend as well.

Thanks for the response.

PS:  I implemented the half-cycle trig functions (e.g., sinpi, ...) for
FreeBSD a few years ago.  These have a 2-clause BSD license.  I'm
willing to dual-license the code with LGPL if you think these might
be good fallback routines.

[Bug fortran/112873] F2023 degree trig functions

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-12-06
             Status|UNCONFIRMED                 |NEW

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #3)
> PS:  I implemented the half-cycle trig functions (e.g., sinpi, ...) for
> FreeBSD a few years ago.  These have a 2-clause BSD license.  I'm
> willing to dual-license the code with LGPL if you think these might
> be good fallback routines.

Thanks for the offer.  But do we actually need fallback routines?

In your experience, how good (or bad) is a naive inline version
like we do for the degree versions?

[Bug fortran/112873] F2023 degree trig functions

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Dec 06, 2023 at 09:58:18PM +0000, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
> 
> anlauf at gcc dot gnu.org changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>      Ever confirmed|0                           |1
>    Last reconfirmed|                            |2023-12-06
>              Status|UNCONFIRMED                 |NEW
> 
> --- Comment #4 from anlauf at gcc dot gnu.org ---
> (In reply to Steve Kargl from comment #3)
> > PS:  I implemented the half-cycle trig functions (e.g., sinpi, ...) for
> > FreeBSD a few years ago.  These have a 2-clause BSD license.  I'm
> > willing to dual-license the code with LGPL if you think these might
> > be good fallback routines.
> 
> Thanks for the offer.  But do we actually need fallback routines?
> 
> In your experience, how good (or bad) is a naive inline version
> like we do for the degree versions?

It would be possible to use a naive version, but it will
likely not approach the requirements placed on these functions
by at least the IEEE 754 and C23 standards.  I think gfortran
should test with configure for these functions in libm and
use those if available (e.g., HAVE_COSPI, etc).  In libgfortran,
we'll need fallbacks if not available.  To see the complexity
of the implementation details see

https://cgit.freebsd.org/src/tree/lib/msun/src/s_cospi.c

Header files defining computation kernels and these use
the computation kernels for sin() and cos() from fdlibm.

https://cgit.freebsd.org/src/tree/lib/msun/src/k_cospi.h
https://cgit.freebsd.org/src/tree/lib/msun/src/k_sinpi.h

Note, AFAIK, glibc does not implement these functions.

Finally, for FreeBSD's cospif(x), here's exhaustive testing
for its floating accuracy:

% tlibm cospi -x 0x1p-9 -X 0x2p23 -fDE cospi
Interval tested for cospif: [0.00195312,1.67772e+07]
count: 276824064 (276824064)
  xm =  6.66955039e-02f, /* 0x3d8897a7 */
 flt =  9.78128791e-01f, /* 0x3f7a66a6 */
 dbl =  9.7812876099954837e-01, /* 0x3fef4cd4, 0xaff8a456 */
 ULP =  0.50090

[Bug fortran/112873] F2023 degree trig functions

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #5)
> On Wed, Dec 06, 2023 at 09:58:18PM +0000, anlauf at gcc dot gnu.org wrote:
> > In your experience, how good (or bad) is a naive inline version
> > like we do for the degree versions?
> 
> It would be possible to use a naive version, but it will
> likely not approach the requirements placed on these functions
> by at least the IEEE 754 and C23 standards.

I see.  The naive version would have done only range reduction and scaling,
maybe good enough for F2023 ("SINPI (X) is approximately equal to SIN (X×π)")
but not more.

Also, one needs mpfr-4.2.0 or higher for simple simplification, or do more
work.

> I think gfortran
> should test with configure for these functions in libm and
> use those if available (e.g., HAVE_COSPI, etc).  In libgfortran,
> we'll need fallbacks if not available.  To see the complexity
> of the implementation details see
> 
> https://cgit.freebsd.org/src/tree/lib/msun/src/s_cospi.c
> 
> Header files defining computation kernels and these use
> the computation kernels for sin() and cos() from fdlibm.
> 
> https://cgit.freebsd.org/src/tree/lib/msun/src/k_cospi.h
> https://cgit.freebsd.org/src/tree/lib/msun/src/k_sinpi.h
> 
> Note, AFAIK, glibc does not implement these functions.

Right.

Would you like to open a separate PR for dealing with the half-cycle
trigonometric functions?

[Bug fortran/112873] F2023 degree trig functions

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Dec 07, 2023 at 07:59:25PM +0000, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
> 
> --- Comment #6 from anlauf at gcc dot gnu.org ---
> (In reply to Steve Kargl from comment #5)
> > On Wed, Dec 06, 2023 at 09:58:18PM +0000, anlauf at gcc dot gnu.org wrote:
> > > In your experience, how good (or bad) is a naive inline version
> > > like we do for the degree versions?
> > 
> > It would be possible to use a naive version, but it will
> > likely not approach the requirements placed on these functions
> > by at least the IEEE 754 and C23 standards.
> 
> I see.  The naive version would have done only range reduction and scaling,
> maybe good enough for F2023 ("SINPI (X) is approximately equal to SIN (X×π)")
> but not more.
> 
> Also, one needs mpfr-4.2.0 or higher for simple simplification, or do more
> work.

Correct. A newer version of MPFR contains these functions.  In fact,
the MPFR developer and I cross-checked each other.  We can probably
use a naive implementation with high precision if an older MPFR is
used.

> > I think gfortran
> > should test with configure for these functions in libm and
> > use those if available (e.g., HAVE_COSPI, etc).  In libgfortran,
> > we'll need fallbacks if not available.  To see the complexity
> > of the implementation details see
> > 
> > https://cgit.freebsd.org/src/tree/lib/msun/src/s_cospi.c
> > 
> > Header files defining computation kernels and these use
> > the computation kernels for sin() and cos() from fdlibm.
> > 
> > https://cgit.freebsd.org/src/tree/lib/msun/src/k_cospi.h
> > https://cgit.freebsd.org/src/tree/lib/msun/src/k_sinpi.h
> > 
> > Note, AFAIK, glibc does not implement these functions.
> 
> Right.
> 
> Would you like to open a separate PR for dealing with the half-cycle
> trigonometric functions?

Yes, I'll add a new PR for the half-cycle functions, and 
point to here for the initial discussion.

[Bug fortran/112873] F2023 degree trig functions

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #56810|0                           |1
        is obsolete|                            |

--- Comment #8 from kargl at gcc dot gnu.org ---
Created attachment 56838
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56838&action=edit
updated diff

This is an updated diff.  It removes making some functions generic when they
are only specific intrinsic routines (e.g., DSIND).  It also updates the
documentation.

[Bug fortran/112873] F2023 degree trig functions

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #9 from kargl at gcc dot gnu.org ---
I have updated the diff.  I don't know have ChangeLog works under git.  Here's
what I have written.

* gcc/fortran/gfortran.texi: Remove the "Extended math intrinsics" node.
  It documented the only the degree trigonometric functions.  That is, it
  was a very limited list of the additional nonstandard intrinsic subprograms
  offered by gfortran.  Most of these functions are now part of Fortran 2023.

* gcc/fortran/intrinsic.cc(add_functions):  Degree trigonometric functions
  [A]COSD, [A]SIND, [A]TAND, and [A]TAN2D have been added to the Fortran
  2023 standard.  These were originally added for compaitiblity with DEC
  Fortran under the -fdec-math.  Change these from GFC_STD_GNU to
  GFC_STD_F2023.
  (gfc_check_intrinsic_standard): Add a check for Fortran 2023.

* gcc/fortran/intrinsic.texi:  Update documentation for [A]COSD, [A]SIND,
  [A]TAND, and [A]TAN2D.

[Bug fortran/112873] F2023 degree trig functions

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org

--- Comment #10 from anlauf at gcc dot gnu.org ---
Created attachment 56847
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56847&action=edit
Potential commit

Steve,

here's a minor update that fully removes the "Extended math intrinsics" node.
Otherwise your patch would not compile here.

The flag -fdec-math now seems fully dysfunctional, i.e. it does nothing.
I adjusted the documentation (intrinsic.texi, invoke.texi) declaring it
obsolete.

Can you have a look?  If you think everything is fine, please submit to the
ML so that others have a chance to have a look.  Or should I do it?

[Bug fortran/112873] F2023 degree trig functions

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #11 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sun, Dec 10, 2023 at 09:45:33PM +0000, anlauf at gcc dot gnu.org wrote:
> 
> here's a minor update that fully removes the "Extended math intrinsics" node.
> Otherwise your patch would not compile here.

Once agin thanks.  I thought I did a 'gmake pdf' after my 
changes, but may have missed that step.

> The flag -fdec-math now seems fully dysfunctional, i.e. it does nothing.
> I adjusted the documentation (intrinsic.texi, invoke.texi) declaring it
> obsolete.

In looking (briefly) at -fdec-math, I'm not sure it ever had
an effect.  I left -fdec-math in options.cc for backwards
compatibilities in Makefiles as it should be a no-opt.

> Can you have a look?  If you think everything is fine, please submit to the
> ML so that others have a chance to have a look.  Or should I do it?

I'll give your updated patch a scan early next week.  I can submit
the patch to both fortran@ and gcc-patches@.  AS you know, I won't
be committing it as I am too git incompetent to do so.

[Bug fortran/112873] F2023 degree trig functions

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #11)
> On Sun, Dec 10, 2023 at 09:45:33PM +0000, anlauf at gcc dot gnu.org wrote:
> > The flag -fdec-math now seems fully dysfunctional, i.e. it does nothing.
> > I adjusted the documentation (intrinsic.texi, invoke.texi) declaring it
> > obsolete.
> 
> In looking (briefly) at -fdec-math, I'm not sure it ever had
> an effect.  I left -fdec-math in options.cc for backwards
> compatibilities in Makefiles as it should be a no-opt.

I think it is fine to leave the switch in options.cc.  Just updating the
documentation should suffice, no bothering of users.

Apparently Fritz implemented -fdec-math in r7-3677-g8e8c2744faa0cf, and
this part of code was rewritten later.

> > Can you have a look?  If you think everything is fine, please submit to the
> > ML so that others have a chance to have a look.  Or should I do it?
> 
> I'll give your updated patch a scan early next week.  I can submit
> the patch to both fortran@ and gcc-patches@.  AS you know, I won't
> be committing it as I am too git incompetent to do so.

Jerry or myself can do the commit later.

Looking at my addition again, I think that this change to invoke.texi:

"... These functions are now GNU extensions."

should correctly read: "These functions are now either part of Fortran 2023
or GNU extensions."

Note to myself to fix this.

[Bug fortran/112873] F2023 degree trig functions

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #13 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to anlauf from comment #12)

> Jerry or myself can do the commit later.
> 
> Looking at my addition again, I think that this change to invoke.texi:
> 
> "... These functions are now GNU extensions."
> 
> should correctly read: "These functions are now either part of Fortran 2023
> or GNU extensions."
> 
> Note to myself to fix this.

Hi Harald and Steve, please let me commit this for the practice. I will fix
that last comment you made and see how this goes.

[Bug fortran/112873] F2023 degree trig functions

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #14 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #12)
> Note to myself to fix this.

Comparing the documentation of the degree trigonometric intrinsics with
F2023, I see that these need only support real arguments.

Currently intrinsic.texi claims that these accept also complex arguments, but
these are rejected, as intrinsic.cc invokes gfc_check_fn_r/gfc_check_fn_d
for argument checking.  This was likely an oversight we can fix in passing.

(COTAN accepts real and complex and is a GNU extension, thus it is fine.)

[Bug fortran/112873] F2023 degree trig functions

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #15 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Dec 11, 2023 at 07:53:01PM +0000, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
> 
> --- Comment #13 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
> (In reply to anlauf from comment #12)
> 
> > Jerry or myself can do the commit later.
> > 
> > Looking at my addition again, I think that this change to invoke.texi:
> > 
> > "... These functions are now GNU extensions."
> > 
> > should correctly read: "These functions are now either part of Fortran 2023
> > or GNU extensions."
> > 
> > Note to myself to fix this.
> 
> Hi Harald and Steve, please let me commit this for the practice. I will fix
> that last comment you made and see how this goes.
> 

Jerry, are you starting with the patch submitted by Harald that
fixes the doc issue.  It seems 'gmake pdf', which is what I use
to check doc changes, works while 'gmake info' fails.  I assume
that this is how Harald found the issue.

Thanks for taking up the commit.

[Bug fortran/112873] F2023 degree trig functions

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #16 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to Steve Kargl from comment #15)
--- snip ---
> 
> Jerry, are you starting with the patch submitted by Harald that
> fixes the doc issue.  It seems 'gmake pdf', which is what I use
> to check doc changes, works while 'gmake info' fails.  I assume
> that this is how Harald found the issue.
> 
> Thanks for taking up the commit.

Yes, I will start with Harald's patch and will plan to test make pdf and make
info.

Do we need any other test cases?

[Bug fortran/112873] F2023 degree trig functions

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #17 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Dec 13, 2023 at 05:36:55PM +0000, jvdelisle at gcc dot gnu.org wrote:
> 
> Do we need any other test cases?
> 

I think that we need not added any testcases.  The degree
trig function have been available for awhile now.  The 
patch simply changes the visibility to be F2023 instead
of a DEC Fortran extension.

[Bug fortran/112873] F2023 degree trig functions

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #18 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I have the patch applied.

make pdf and make info work as expected.  I fixed a minor typo in a comment for
intrinsic.cc. I have a few of the git magics to do. Shall I submit to the list
before commit?

[Bug fortran/112873] F2023 degree trig functions

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #19 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Dec 14, 2023 at 05:03:35PM +0000, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
> 
> --- Comment #18 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
> I have the patch applied.
> 
> make pdf and make info work as expected.  I fixed a minor typo in a comment for
> intrinsic.cc. I have a few of the git magics to do. Shall I submit to the list
> before commit?
> 

Given that Harald reviewed my initial submission,
and you now have taken the patch and reviewed it
sufficiently to find a typo, I think you can 
commit it.  Submit whatever you've committed to
the list and refer to the PR for our discussion.

[Bug fortran/112873] F2023 degree trig functions

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #20 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #18)
> I have the patch applied.
> 
> make pdf and make info work as expected.  I fixed a minor typo in a comment
> for intrinsic.cc. I have a few of the git magics to do. Shall I submit to
> the list before commit?

Have you seen my comment#14?

[Bug fortran/112873] F2023 degree trig functions

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #21 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jerry DeLisle <jvdelisle@gcc.gnu.org>:

https://gcc.gnu.org/g:95b70545331764c85079a1d0e1e19b605bda1456

commit r14-6558-g95b70545331764c85079a1d0e1e19b605bda1456
Author: Jerry DeLisle <jvdelisle@gcc.gnu.org>
Date:   Wed Dec 13 19:04:50 2023 -0800

    fortran: Add degree based trig functions for F2023

            PR fortran/112873

    gcc/fortran/ChangeLog:

            * gfortran.texi: Update to reflect the changes.
            * intrinsic.cc (add_functions): Update the standard that the
            various  degree trigonometric functions have been described in.
            (gfc_check_intrinsic_standard): Add an error string for F2023.
            * intrinsic.texi: Update accordingly.

[Bug fortran/112873] F2023 degree trig functions

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #22 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to anlauf from comment #20)
> (In reply to Jerry DeLisle from comment #18)
> > I have the patch applied.
> > 
> > make pdf and make info work as expected.  I fixed a minor typo in a comment
> > for intrinsic.cc. I have a few of the git magics to do. Shall I submit to
> > the list before commit?
> 
> Have you seen my comment#14?

Passed in the wind.  I can go back and adjust that. No big deal.

[Bug fortran/112873] F2023 degree trig functions

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #23 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I am going to suggest the following. The wording was confusing around the
functionality of the option vs the intrinsics. Hope this is OK?

@opindex @code{fdec-math}
@item -fdec-math
Obsolete flag.  The purpose of this option was to
enable legacy math intrinsics such as COTAN and degree-valued trigonometric
functions (e.g. TAND, ATAND, etc...) for compatibility with older code. This
option is no longer operable. The trigonometric functions are now either 
part of Fortran 2023 or GNU extensions.

[Bug fortran/112873] F2023 degree trig functions

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #24 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #23)
> I am going to suggest the following. The wording was confusing around the
> functionality of the option vs the intrinsics. Hope this is OK?
> 
> @opindex @code{fdec-math}
> @item -fdec-math
> Obsolete flag.  The purpose of this option was to
> enable legacy math intrinsics such as COTAN and degree-valued trigonometric
> functions (e.g. TAND, ATAND, etc...) for compatibility with older code. This
> option is no longer operable. The trigonometric functions are now either 
> part of Fortran 2023 or GNU extensions.

I am not a native speaker, so this is certainly better than what I wrote.

[Bug fortran/112873] F2023 degree trig functions

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #25 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Dec 14, 2023 at 07:48:08PM +0000, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
> 
> --- Comment #24 from anlauf at gcc dot gnu.org ---
> (In reply to Jerry DeLisle from comment #23)
> > I am going to suggest the following. The wording was confusing around the
> > functionality of the option vs the intrinsics. Hope this is OK?
> > 
> > @opindex @code{fdec-math}
> > @item -fdec-math
> > Obsolete flag.  The purpose of this option was to
> > enable legacy math intrinsics such as COTAN and degree-valued trigonometric
> > functions (e.g. TAND, ATAND, etc...) for compatibility with older code. This
> > option is no longer operable. The trigonometric functions are now either 
> > part of Fortran 2023 or GNU extensions.
> 
> I am not a native speaker, so this is certainly better than what I wrote.
> 

Your English is much better than my non-existent German. ;-)

The above is fine for the -fdec-math option.  However, we'll need
to audit the description of each function to cleanup the non-support
for complex.  For example, ASIND has

_Arguments_:
    X     The type shall be either ‘REAL’ and a magnitude
          that is less than or equal to one - or be ‘COMPLEX’.

_Return value_:
     The return value is of the same type and kind as X.  The real part
     of the result is in degrees and lies in the range -90 \leq \Re
     \asin(x) \leq 90.

These should likely read

_Arguments_:
    X     The type shall be ‘REAL’.  The  magnitude of X should be
          less than or equal to one.

_Return value_:
     The return value is of the same type and kind as X.  The 
     result is in degrees and lies in the range -90 \leq \Re
     \asin(x) \leq 90.

[Bug fortran/112873] F2023 degree trig functions

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jvdelisle at gcc dot gnu.org

--- Comment #26 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Auditing now

[Bug fortran/112873] F2023 degree trig functions

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #27 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Created attachment 56882
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56882&action=edit
Description changes

This is what I arrived at going through. OK?

[Bug fortran/112873] F2023 degree trig functions

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #28 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Dec 14, 2023 at 08:35:32PM +0000, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
> 
> --- Comment #27 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
> Created attachment 56882
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56882&action=edit
> Description changes
> 
> This is what I arrived at going through. OK?
> 

Thanks.  That looks goog, but I think we need to also update what
is returned.

ASIND has 

 The real part of the result is in degrees and lies in the
 range -90 \leq \Re \asin(x) \leq 90.


Writing the "The real part of" seems redundant if not a bit misleading.

[Bug fortran/112873] F2023 degree trig functions

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #29 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Created attachment 56883
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56883&action=edit
Updated Descriptions

Fixed a few more things, The return value of tand is not in degrees.

[Bug fortran/112873] F2023 degree trig functions

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #30 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #29)
> Created attachment 56883 [details]
> Updated Descriptions
> 
> Fixed a few more things, The return value of tand is not in degrees.

I think the following is also incorrect:

@item @code{RESULT = ATAND(Y, X)}

We accept only the variant with one real argument X,
or one needs to use ATAN2D (Y, X).  Another old copy&paste bug.

ATAN is different in this respect.

[Bug fortran/112873] F2023 degree trig functions

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #31 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to anlauf from comment #30)
> (In reply to Jerry DeLisle from comment #29)
> > Created attachment 56883 [details]
> > Updated Descriptions
> > 
> > Fixed a few more things, The return value of tand is not in degrees.
> 
> I think the following is also incorrect:
> 
> @item @code{RESULT = ATAND(Y, X)}

Yes, got that one now. Thanks.

[Bug fortran/112873] F2023 degree trig functions

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #32 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
commit a1f0d227481fe143f8c15b3f268e2d5964a3c90a (HEAD -> master, origin/master,
origin/HEAD)
Author: Jerry DeLisle <jvdelisle@gcc.gnu.org>
Date:   Fri Dec 15 13:05:18 2023 -0800

    fortran: Update degree trigs documentation.

    This is only some cleanup.

    gcc/fortran/ChangeLog:

            PR fortran/112783

            * intrinsic.texi: Fix where no COMPLEX allowed.
            * invoke.texi: Clarify -fdev-math.

I fat fingered the PR number, sigh.

[Bug fortran/112873] F2023 degree trig functions

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

--- Comment #33 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #32)
> commit a1f0d227481fe143f8c15b3f268e2d5964a3c90a (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Jerry DeLisle <jvdelisle@gcc.gnu.org>
> Date:   Fri Dec 15 13:05:18 2023 -0800
> 
>     fortran: Update degree trigs documentation.
>     
>     This is only some cleanup.
>     
>     gcc/fortran/ChangeLog:
>     
>             PR fortran/112783
>     
>             * intrinsic.texi: Fix where no COMPLEX allowed.
>             * invoke.texi: Clarify -fdev-math.
> 
> I fat fingered the PR number, sigh.

You can always --amend before pushing.

[Bug fortran/112873] F2023 degree trig functions

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #34 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
If not resolved, feel free to reopen.