https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126305
Steve Kargl <kargl at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P4
--- Comment #14 from Steve Kargl <kargl at gcc dot gnu.org> ---
(In reply to dave.anglin from comment #13)
> On 2026-07-17 7:53 p.m., kargl at gcc dot gnu.org wrote:
> > 1. The patch is comment #5 is wrong. sind(0, cosd(), ... are
> > functions where the argument has an unit of degree. These functions
> > are part of Fortran 2023, and have nothing to do with decimal
> > arithmetic.
>
> But the functions result in calls to atanl, etc.
>
> I think now it would be better to implement atanl even if the implemention
> was a gross hack.
> > 2. Your comment #3 shows a program from Harald that uses atand().
> >
> > program test
> > real(16) :: x = 1
> > print *, atand(x)
> > end
> >
> > and your reply shows
> >
> > test.f90.006t.original: D.1079 = __builtin_atanl (x)*
> > 5.72957795130823208767981548141051722660080813268252612005e+1;
> >
> > which is the correct result in that atanl() has units of radian
> > and the constant multiplier converts that to degree. So, you're
> > chasing how does gcc translate __builtin_atanl().
>
> In subsequent tree dumps, the call to __builtin_atanl is changed to a
> call to atanl.
>
> I believe gfortran is responsible for the call to __builtin_atanl and the
> conversion to degrees.
>
> On HPUX,
> > are long double math functions magically translated into libquadmath
> > references? That is, __builtin_atanl(x) somehow ends up as
> > atanq((__float128)x)?
>
> I wish but no.
>
> The above could be used to implement atanl on hppa-hpux:
>
> #if defined(HAVE_ATAN) && !defined(HAVE_ATANL)
> #define HAVE_ATANL 1
> long double atanl(long double);
>
> long double
> atanl(long double x)
> {
> return ((long double)atanq((__float128)x));
> }
> #endif
>
> Casting to/from long double from __float128 works on hppa-hpux.
>
> I think configure could be modified to define USE_LIBQUADMATH when
> libquadmath
> support isn't disabled.
> > Does
> >
> > #include <math.h>
> >
> > long double
> > foo(long double x)
> > {
> > long double y;
> > y = atanl(x);
> > return (y);
> > }
> >
> > generate __builtin_atanl(x) and if you compile to assembly
> > is there a reference to atanl or atanq?
>
> No and there is a reference to atanl.
>
> 1) math.h doesn't declare atanl. To get program to compile, I need to
> declare atanl.
>
> 2) If atanl is declared, the program calls atanl. It does not generate
> __builtin_atanl.
>
> 3) If atanl is changed to __builtin_atanl in the above, atanl is still
> called in the .s
> file. I believe __builtin_atanl only handles a few special cases where the
> call to atanl
> can be eliminated.
Okay, I now understand the situation.
Yes, gfortran will generate that __builtin_atanl(). Much of the top
portion of fortran/trans-intrinsic.cc does the dance to get builtin
functions; some are in-lined, others become library function references.
I think what you/(we) need to do is something like
#if defined(HAVE_ATAN) && !defined(HAVE_ATANL)
#define HAVE_ATANL 1
long double atanl(long double);
long double
atanl(long double x)
{
#ifdef __HPUX__
return ((long double)atanq((__float128)x));
#else
return ((long double)atan((double)x));
#endif
}
#endif
The #ifdef __HPUX__ guards against other targets that cannot
do the cast to __float128, but have a missing long double.
