[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #34 from Jerry DeLisle --- If not resolved, feel free to reopen.
[Bug fortran/112873] F2023 degree trig functions
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 > 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #32 from Jerry DeLisle --- commit a1f0d227481fe143f8c15b3f268e2d5964a3c90a (HEAD -> master, origin/master, origin/HEAD) Author: Jerry DeLisle 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #31 from Jerry DeLisle ---
(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
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 bug.
ATAN is different in this respect.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #29 from Jerry DeLisle --- Created attachment 56883 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56883=edit Updated Descriptions Fixed a few more things, The return value of tand is not in degrees.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #28 from Steve Kargl --- On Thu, Dec 14, 2023 at 08:35:32PM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 > > --- Comment #27 from Jerry DeLisle --- > Created attachment 56882 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56882=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #27 from Jerry DeLisle --- Created attachment 56882 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56882=edit Description changes This is what I arrived at going through. OK?
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #26 from Jerry DeLisle --- Auditing now
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #25 from Steve Kargl ---
On Thu, Dec 14, 2023 at 07:48:08PM +, 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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #23 from Jerry DeLisle ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #22 from Jerry DeLisle --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #21 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:95b70545331764c85079a1d0e1e19b605bda1456 commit r14-6558-g95b70545331764c85079a1d0e1e19b605bda1456 Author: Jerry DeLisle 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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #19 from Steve Kargl --- On Thu, Dec 14, 2023 at 05:03:35PM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 > > --- Comment #18 from Jerry DeLisle --- > 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #18 from Jerry DeLisle --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #17 from Steve Kargl --- On Wed, Dec 13, 2023 at 05:36:55PM +, 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #16 from Jerry DeLisle --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #15 from Steve Kargl --- On Mon, Dec 11, 2023 at 07:53:01PM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 > > --- Comment #13 from Jerry DeLisle --- > (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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #13 from Jerry DeLisle --- (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
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 +, 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #11 from Steve Kargl --- On Sun, Dec 10, 2023 at 09:45:33PM +, 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
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=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
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
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #7 from Steve Kargl ---
On Thu, Dec 07, 2023 at 07:59:25PM +, 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 +, 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
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 +, 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #5 from Steve Kargl --- On Wed, Dec 06, 2023 at 09:58:18PM +, 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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #3 from Steve Kargl ---
On Wed, Dec 06, 2023 at 08:56:32PM +, 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
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
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
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.
