[Bug fortran/113152] New: Fortran 2023 half-cycle trigonometric functions

[Bug fortran/113152] New: Fortran 2023 half-cycle trigonometric functions

[kargl at gcc dot gnu.org]

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

            Bug ID: 113152
           Summary: Fortran 2023 half-cycle trigonometric functions
           Product: gcc
           Version: 13.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 56949
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56949&action=edit
patch with implementation

The attach patch implements the half-cycle trigonometric functions that
are now contained within Fortran 2023.  There a few things to note.

1) IEEE 754-2008, ISO/IEC TS 18661-4, C23, and Fortran 2023 all contain
   these functions.  This likely means that the functions acospi(), asinpi(),
   ..., tanpi() may be available as part of an operating system's libm.  In
   fact, FreeBSD has implementations of cospi, sinpi, and tanpi in libm, and
   these conform to the requirements of IEEE 754-2008 and ISO/IEC TS 18661-4.
   The file libgfortran/intrinsics/trigpi_fallback1.c provides fallbacks for
   float, double, and long double functions.  As I don't know the internals
   for libquadmath or ibm double-double, the REAL(16) (and GFC_REAL_17)
   fallback functions are in libgfortran/intrinsics/trigpi_fallback1.F90.
   I have tested REAL(16) that sits on top of libquadmath.  I have not tested
   the double-double situation.  Finally, the fallback functions do not go
   to any length in meeting all of the requirements of IEEE 754-2008. For
   example, sinpi(n+0.5) is exactly +-1 for representable integer n.  The
   fallbacks may raise an FE_INEXACT exception. 

2) I tried adding math builtins in gcc/fortran/mathbuiltins.def to directly
   map to libm functions, but this ultimately led to much frustration.  I gave
   up and wrap, for example, cospi() in _gfortran_cospi_r8().  So, there is a
   level of in-direction.  This is done in libgfortran/intrinsics/trigpi.c.
   Someone smarter than I can do the math builtins.

3) I tried inserting GFC_ISYM_ACOSPI, ..., GFC_ISYM_TANPI in alphabetical
   order in 'enum gfc_isym_id' of gfortran.h.  This runs into some obscure
   issue with libgomp where C_ASSOCIATED is no longer recognized.  So, I
   placed the new members of the enum at its end.

4) I don't use git.  I tried to do 'git add libgfortran/intrinsics/trigpi\*'
   followed by 'git commit libgfortran/intrinsics/trigpi\*', and then 
   finally 'git diff > z_halfcycle.diff'.  This does not generate one 
   unified diff file.  Sigh.  I'll attach the new files along with the
   mangled diff.

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[kargl at gcc dot gnu.org]

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

--- Comment #1 from kargl at gcc dot gnu.org ---
Created attachment 56950
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56950&action=edit
new file that git cannot diff

Put file in libgfortran/intrinsics.

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Created attachment 56951
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56951&action=edit
file that git cannot find

Put file in libgfortran/intrinsics

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Created attachment 56952
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56952&action=edit
file that git cannot find

Put in libgfortran/intrinsics

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Created attachment 56953
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56953&action=edit
test program

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

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

--- Comment #5 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to kargl from comment #0)
>
> 4) I don't use git.  I tried to do 'git add libgfortran/intrinsics/trigpi\*'
>    followed by 'git commit libgfortran/intrinsics/trigpi\*', and then 
>    finally 'git diff > z_halfcycle.diff'.  This does not generate one 
>    unified diff file.  Sigh.  I'll attach the new files along with the
>    mangled diff.

With git you need to add all the files, not only the new ones (you can use git
add --update to add the existing files).
Then the patch can be generated (if you don't commit) with git diff --staged

If you commit, you need to add an argument to git diff to tell him a reference
to compare against, namely origin/master (remote master), master (local
master), HEAD^ (last commit before the tip of the branch), etc.  The default
reference if omitted is the tip of the branch, what you have just committed, so
the diff is empty.

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
In reflecting on the possibility of an OS lacking support for
REAL(10) but having a REAL(16), the mapping of types into 
C are likely REAL(4) <--> float, REAL(8) <--> double, and
REAL(16) <--> long double.  The current patch sort of gets 
this wrong, because REAL(16) is not properly mapped.  I'll
fix that shortly.

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Created attachment 56955
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56955&action=edit
test program for inverse functions

The attach program tests the inverse functions, e.g., acospi, for all kinds on
AMD64 hardware.

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org ---
Created attachment 56956
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56956&action=edit
git diff cannot find trigpi.c (updated file)

The new file tries to deal with a system with REAL(4), REAL(8), and REAL(16).
The various files and patch have been tested on AMD64 where gfortran has
REAL(4), REAL(8), REAL(10), and REAL(16).

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

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

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
Current patch is incomplete as it fails to scalarize.
It seems I need to remember how to register the new
intrinsic subprograms in trans-intrinsics.cc.

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[anlauf at gcc dot gnu.org]

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #0)
> Created attachment 56949 [details]
> patch with implementation

Not a review, just a comment:

diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index 87fefe46cfd..4e546ddb8fa 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -30,6 +30,14 @@ along with GCC; see the file COPYING3.  If not see
 #include "constructor.h"
 #include "version.h"   /* For version_string.  */

+/* MPFR 4.2.0 introduced half-cycle trigonometric functions, e.g., sinpi(x).
+   Introduce a macro so older versions of the MPFR can still be used.  */
+
+#ifdef MPFR_HALF_CYCLE
+#undef MPFR_HALF_CYCLE
+#endif
+#define MPFR_HALF_CYCLE (MPFR_VERSION_MAJOR > 3 && MPFR_VERSION_MINOR > 1)
+
 /* Prototypes.  */


This does not look right, as it would exclude e.g. all mpfr-[5-9].[01]
How about:

#define MPFR_HALF_CYCLE (MPFR_VERSION_MAJOR * 100 + MPFR_VERSION_MINOR >= 402)

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #11 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Dec 29, 2023 at 08:34:38PM +0000, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
> 
> --- Comment #10 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #0)
> > Created attachment 56949 [details]
> > patch with implementation
> 
> Not a review, just a comment:
> 
> diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
> index 87fefe46cfd..4e546ddb8fa 100644
> --- a/gcc/fortran/simplify.cc
> +++ b/gcc/fortran/simplify.cc
> @@ -30,6 +30,14 @@ along with GCC; see the file COPYING3.  If not see
>  #include "constructor.h"
>  #include "version.h"   /* For version_string.  */
> 
> +/* MPFR 4.2.0 introduced half-cycle trigonometric functions, e.g., sinpi(x).
> +   Introduce a macro so older versions of the MPFR can still be used.  */
> +
> +#ifdef MPFR_HALF_CYCLE
> +#undef MPFR_HALF_CYCLE
> +#endif
> +#define MPFR_HALF_CYCLE (MPFR_VERSION_MAJOR > 3 && MPFR_VERSION_MINOR > 1)
> +
>  /* Prototypes.  */
> 
> 
> This does not look right, as it would exclude e.g. all mpfr-[5-9].[01]
> How about:
> 
> #define MPFR_HALF_CYCLE (MPFR_VERSION_MAJOR * 100 + MPFR_VERSION_MINOR >= 402)
> 

Indeed, it looks like I'm skipping all .0 and .1 minor releases.
I'll adopt your suggestion, and include it in an updated patch.

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #56949|0                           |1
        is obsolete|                            |
  Attachment #56950|0                           |1
        is obsolete|                            |
  Attachment #56951|0                           |1
        is obsolete|                            |
  Attachment #56952|0                           |1
        is obsolete|                            |
  Attachment #56956|0                           |1
        is obsolete|                            |

--- Comment #12 from kargl at gcc dot gnu.org ---
Created attachment 57179
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57179&action=edit
Patch

Here is a new patch.  It includes an implementation for the half-cycle
trigonometric functions as well as fixes for

PR113412 -- better error message for atan(y,x)
PR113413 -- implement atand(y,x)

Here's text that may be suitable formatted for a ChangeLog.

gfortran:

        * gfortran.h (gfc_isym_id): Add GFC_ISYM_ACOSPI, GFC_ISYM_ASINPI,
        GFC_ISYM_ATANPI, GFC_ISYM_ATAN2PI, GFC_ISYM_COSPI, GFC_ISYM_SINPI, and
        GFC_ISYM_TANPI
        * intrinsic.cc (do_check): Whitespace and typo in comments.
        (add_functions): Add two-argument form of ATAND.  Add half-cycle 
        trigonometric functions ACOSPI, ASINPI, ATANPI, ATAN2PI, COSPI,
        SINPI, and TANPI.
        (sort_actual): Generate sensible error messages for two argument
        versions of ATAN, ATAND, and ATANPI.
        * intrinsic.h: New prototypes for gfc_simplify_acospi, 
        gfc_simplify_asinpi, gfc_simplify_atanpi, gfc_simplify_atan2pi,
        gfc_simplify_cospi, gfc_simplify_sinpi, gfc_simplify_tanpi,
        gfc_resolve_acospi, gfc_resolve_asinpi, gfc_resolve_atanpi,
        gfc_resolve_atan2pi, gfc_resolve_cospi, gfc_resolve_sinpi, and
        gfc_resolve_tanpi
        * intrinsic.texi: Document new functions ACOSPI, ASINPI, ATANPI,
        ATAN2PI, COSPI, SINPI, and TANPI.  Put the ATAN* family of functions
        in lexigraphical order.
        * iresolve.cc (gfc_resolve_acospi, gfc_resolve_asinpi,
        gfc_resolve_atanpi, gfc_resolve_atan2pi, gfc_resolve_cospi,
        gfc_resolve_sinpi, gfc_resolve_tanpi):  New functions.
        * simplify.cc (gfc_simplify_acospi, gfc_simplify_asinpi,
        gfc_simplify_atanpi, gfc_simplify_atan2pi, gfc_simplify_cospi,
        gfc_simplify_sinpi, gfc_simplify_tanpi): New functions.
        Introduce MPFR_HALF_CYCLE macros to use MPFR half-cycle functions
        if available.
        * trans-intrinsic.cc: Declare asinpi, acospi, atanpi, atan2pi, sinpi, 
        cospi, and tanpi as LIB_FUNCTION's.

libgfortran 

        *Makefile.am: New files trigpi.c, trigpi_fallback1.c, and
        trigpi_fallback2.F90
        * configure.ac: Check libm for float, double, and long double
        functions for asinpi, acospi, atanpi, atan2pi, sinpi, cospi, and
        tanpi
        * Makefile.in: Regenerated.
        * config.h.in: Ditto.
        * configure: Ditto.
        * gfortran.map: Add GFORTRAN_14 section to expose the library
        symbols.
        * trigpi.c: Fallback implementations of the half-cycle trigonometric
        functions.
        * trigpi_fallback1.c: Fallback functions for float, double, and
        long double routines if libm does provide them.
        * trigpi_fallback2.F90: REAL(16)/REAL(17) fallback implementations
        of the half-cycle trigonometric functions.

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-01-21
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #13 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #12)
> Created attachment 57179 [details]
> Patch

This patch does not compile with older MPFR versions:

../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr*
gfc_simplify_cospi(gfc_expr*)':
../../gcc-trunk/gcc/fortran/simplify.cc:2085:7: error: 'mpfr_cospi' was not
declared in this scope; did you mean 'mpfr_cosh'?
 2085 |       mpfr_cospi (result->value.real, result->value.real,
GFC_RND_MODE);
      |       ^~~~~~~~~~
      |       mpfr_cosh
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr*
gfc_simplify_sinpi(gfc_expr*)':
../../gcc-trunk/gcc/fortran/simplify.cc:7893:7: error: 'mpfr_sinpi' was not
declared in this scope; did you mean 'mpfr_sinh'?
 7893 |       mpfr_sinpi (result->value.real, x->value.real, GFC_RND_MODE);
      |       ^~~~~~~~~~
      |       mpfr_sinh
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr*
gfc_simplify_tanpi(gfc_expr*)':
../../gcc-trunk/gcc/fortran/simplify.cc:8265:7: error: 'mpfr_tanpi' was not
declared in this scope; did you mean 'mpfr_tanh'?
 8265 |       mpfr_tanpi (result->value.real, x->value.real, GFC_RND_MODE);
      |       ^~~~~~~~~~
      |       mpfr_tanh
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr*
gfc_simplify_atan2pi(gfc_expr*, gfc_expr*)':
../../gcc-trunk/gcc/fortran/simplify.cc:8320:7: error: 'mpfr_atan2pi' was not
declared in this scope; did you mean 'mpfr_atan2'?
 8320 |       mpfr_atan2pi (result->value.real, y->value.real, x->value.real,
      |       ^~~~~~~~~~~~
      |       mpfr_atan2
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr*
gfc_simplify_atanpi(gfc_expr*)':
../../gcc-trunk/gcc/fortran/simplify.cc:8349:7: error: 'mpfr_atanpi' was not
declared in this scope; did you mean 'mpfr_atanh'?
 8349 |       mpfr_atanpi (result->value.real, x->value.real, GFC_RND_MODE);
      |       ^~~~~~~~~~~
      |       mpfr_atanh
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr*
gfc_simplify_asinpi(gfc_expr*)':
../../gcc-trunk/gcc/fortran/simplify.cc:8377:7: error: 'mpfr_asinpi' was not
declared in this scope; did you mean 'mpfr_asinh'?
 8377 |       mpfr_asinpi (result->value.real, x->value.real, GFC_RND_MODE);
      |       ^~~~~~~~~~~
      |       mpfr_asinh
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr*
gfc_simplify_acospi(gfc_expr*)':
../../gcc-trunk/gcc/fortran/simplify.cc:8405:7: error: 'mpfr_acospi' was not
declared in this scope; did you mean 'mpfr_acosh'?
 8405 |       mpfr_acospi (result->value.real, x->value.real, GFC_RND_MODE);
      |       ^~~~~~~~~~~
      |       mpfr_acosh

I think that you cannot do

+  if (MPFR_HALF_CYCLE)

you really must use

#if MPFR_HALF_CYCLE

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #14 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sun, Jan 21, 2024 at 09:52:39PM +0000, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
> 
> I think that you cannot do
> 
> +  if (MPFR_HALF_CYCLE)
> 
> you really must use
> 
> #if MPFR_HALF_CYCLE
> 

#include <stdio.h>
#include "mpfr.h"

#define MPFR_HALF_CYCLE (MPFR_VERSION_MAJOR * 100 + MPFR_VERSION_MINOR >= 402)

int
main(void)
{
   if (MPFR_HALF_CYCLE)
      printf("here\n");
   else
      printf("there\n");
   return (0);
}

% cc -o z -I/usr/local/include a.c && ./z
here
% cc -E -I/usr/local/include a.c | grep -v mpfr_ | grep -v gmp | cat -s
...
int
main(void)
{
   if ((4 * 100 + 2 >= 402))
      printf("here\n");
   else
      printf("here\n");
   return (0);
}

Are you sure that your testing is finding the right mpfr.h?
If I add 

#ifdef MPFR_VERSION_MAJOR
#undef MPFR_VERSION_MAJOR
#endif 
#define MPFR_VERSION_MAJOR 3

above the define for MPFR_HALF_CYCLE in simplify.cc, it compiles
for me.  With this simple program

   real, parameter :: x = cospi(1.)
   print *,x
   end

gdb ends up in the else { } branch.

Breakpoint 1, gfc_simplify_cospi (x=0x803e24b60)
    at ../../gcc/gcc/fortran/simplify.cc:2085
2085      result = gfc_get_constant_expr (x->ts.type, x->ts.kind, &x->where);
(gdb) n
2101          mpfr_inits2 (2 * mpfr_get_prec (x->value.real), cs, n, r, NULL);

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[kargl at gcc dot gnu.org]

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

--- Comment #15 from kargl at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #14)
> On Sun, Jan 21, 2024 at 09:52:39PM +0000, anlauf at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
> > 
> > I think that you cannot do
> > 
> > +  if (MPFR_HALF_CYCLE)
> > 
> > you really must use
> > 
> > #if MPFR_HALF_CYCLE
> > 
> 

...

> Breakpoint 1, gfc_simplify_cospi (x=0x803e24b60)
>     at ../../gcc/gcc/fortran/simplify.cc:2085
> 2085      result = gfc_get_constant_expr (x->ts.type, x->ts.kind, &x->where);
> (gdb) n
> 2101          mpfr_inits2 (2 * mpfr_get_prec (x->value.real), cs, n, r,
> NULL);

Good news is that your testing forced me to look at the
else-{} branch again, and it exposed a shortcoming.  I'm
looking at a fix.  So an updated patch will be necessary.

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

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

--- Comment #16 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #14)
> On Sun, Jan 21, 2024 at 09:52:39PM +0000, anlauf at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
> > 
> > I think that you cannot do
> > 
> > +  if (MPFR_HALF_CYCLE)
> > 
> > you really must use
> > 
> > #if MPFR_HALF_CYCLE
> > 
> 
> #include <stdio.h>
> #include "mpfr.h"
> 
> #define MPFR_HALF_CYCLE (MPFR_VERSION_MAJOR * 100 + MPFR_VERSION_MINOR >=
> 402)
> 
> int
> main(void)
> {
>    if (MPFR_HALF_CYCLE)
>       printf("here\n");
>    else
>       printf("there\n");
>    return (0);
> }
> 
> % cc -o z -I/usr/local/include a.c && ./z

This does not test the right thing.

% cat sgk.cc
#include <stdio.h>

#define MPFR_HALF_CYCLE 0

int
main(void)
{
   if (MPFR_HALF_CYCLE)
      printf_not_declared_if_0 ("here\n");
   else
      printf ("there\n");
   return (0);
}

% g++ sgk.cc
sgk.cc: In function 'int main()':
sgk.cc:9:7: error: 'printf_not_declared_if_0' was not declared in this scope
       printf_not_declared_if_0 ("here\n");
       ^~~~~~~~~~~~~~~~~~~~~~~~

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #17 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Jan 22, 2024 at 05:35:41PM +0000, anlauf at gcc dot gnu.org wrote:
> --- Comment #16 from anlauf at gcc dot gnu.org ---
> (In reply to Steve Kargl from comment #14)
> > On Sun, Jan 21, 2024 at 09:52:39PM +0000, anlauf at gcc dot gnu.org wrote:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
> > > 
> > > I think that you cannot do
> > > 
> > > +  if (MPFR_HALF_CYCLE)
> > > 
> > > you really must use
> > > 
> > > #if MPFR_HALF_CYCLE
> > > 
> > 
> > #include <stdio.h>
> > #include "mpfr.h"
> > 
> > #define MPFR_HALF_CYCLE (MPFR_VERSION_MAJOR * 100 + MPFR_VERSION_MINOR >=
> > 402)
> > 
> > int
> > main(void)
> > {
> >    if (MPFR_HALF_CYCLE)
> >       printf("here\n");
> >    else
> >       printf("there\n");
> >    return (0);
> > }
> > 
> > % cc -o z -I/usr/local/include a.c && ./z
> 
> This does not test the right thing.
> 
> % cat sgk.cc
> #include <stdio.h>
> 
> #define MPFR_HALF_CYCLE 0

This is not what the pre-processor should be doing
(on at least FreeBSD).  See below.


> int
> main(void)
> {
>    if (MPFR_HALF_CYCLE)
>       printf_not_declared_if_0 ("here\n");
>    else
>       printf ("there\n");
>    return (0);
> }
> 
> % g++ sgk.cc
> sgk.cc: In function 'int main()':
> sgk.cc:9:7: error: 'printf_not_declared_if_0' was not declared in this scope
>        printf_not_declared_if_0 ("here\n");
>        ^~~~~~~~~~~~~~~~~~~~~~~~

Of course, it will fail.  You need to actually have a
printf_not_declared_if_0 function defined during parsing.

#include <stdlib.h>
#include <stdio.h>

#define MPFR_HALF_CYCLE 1
#define printf_not_declared_if_0(a) abort()

int
main(void)
{
   if (MPFR_HALF_CYCLE)
      printf_not_declared_if_0 ("here\n");
   else
      printf ("there\n");
   return (0);
}

~/work/x/bin/g++ -I/usr/local/include -o z a.cc && ./z
Abort (core dumped)

Changing 1 to 0 the MPFR_HALF_CYCLE define.

 ~/work/x/bin/g++ -I/usr/local/include -o z a.cc && ./z
there

Going back to my original example and g++ from master, I'm seeing

% ~/work/x/bin/g++ -I/usr/local/include -E a.cc

int
main(void)
{
   if ((
# 9 "a.cc" 3
      4 
# 9 "a.cc"
      * 100 + 
# 9 "a.cc" 3
      2 
# 9 "a.cc"
      >= 402))
      printf("here\n");
   else
      printf("there\n");
   return (0);
}

and with clang++

% c++ -E -I/usr/local/include a.cc
int
main(void)
{
   if ((4 * 100 + 2 >= 402))
      printf("here\n");
   else
      printf("there\n");
   return (0);
}

Is there something that is different between your OS and FreeBSD?
Or is there some fundamental difference between C and C++ that
I am unaware of?

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[anlauf at gcc dot gnu.org]

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

--- Comment #18 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #17)
> Is there something that is different between your OS and FreeBSD?
> Or is there some fundamental difference between C and C++ that
> I am unaware of?

You should not expect everybody to have the latest MPFR installed.
That's the whole point.

Please use #if / #else / #endif