https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
--- Comment #18 from Fritz Reese <foreese at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to Jakub Jelinek from comment #13)
> > I've missed that. I'm afraid there is no way around missing sinl/cosl/tanl
> > etc.,
> > those aren't likely implemented inline by the compiler. The only exception
> > would be for targets where long double and double are the same type.
> > What has libgfortran been doing before? Seems to me it just wouldn't define
> > the _gfortran* entrypoint that use them.
>
> But if long double is 64-bit, there is no really a point to use the *l
> suffixed functions, is it?
If long double is 64-bit, then neither REAL(10) nor REAL(16) will be available,
since the kinds are set by precision / 8. Then HAVE_GFC_REAL_16 and
HAVE_GFC_REAL_10 are not defined, in which case the *l suffixed version is not
built. The problem comes when REAL(10) or REAL(16) are supported by the system,
but the system's libm does not declare or define the math builtins for that
precision.
(In reply to Jakub Jelinek from comment #15)
> Thus, I think we can extend the patch I've attached (and fix the two fmaf to
> fmal spots), plus do the HAVE_INLINE_BUILTIN_* in configure.ac either
> through a config/math.m4 macro, or through a loop over the functions that
> can have such treatment with a likely inlined implementation.
>
According to comments in pr94586, it seems that on HPUX __builtin_cosl is
available but a proper "cosl" is not. I'm not sure how this happens but it
suggests to me that a similar pattern might work for the trig functions, at
least sometimes.
(In reply to Jakub Jelinek from comment #17)
> (In reply to rguent...@suse.de from comment #16)
> > Maybe they can be implemented like
> >
> > long double _gfortran_xyz (long double x)
> > {
> > __sorry_fortran_intrinsic_xyz_is_not_available_because_cosl_is_not ();
> > }
> >
> > instead of simply not providing them. Coordination between the FE
> > and (the various multilibs of) libgfortran and emitting diagnostics
> > from the FE would of course be even better.
>
> libgfortran has runtime_error or internal_error and other functions that can
> deliver messages to the user, sure.
Yes, I think we should use this approach at least. It is not immediately clear
to me how to properly check this in the FE. I think checking HAVE_* at compiler
compile time in the FE is wrong. I don't know what/how the FE can inquire about
the library at compile (run) time.
> But still, the trig*.inc needs to check HAVE_* macros of everything that it
> uses and just don't provide the definitions if it can't be implemented.
I will provide a patch which handles the checks in trigd*.inc. I have no
experience writing m4/autoconf so I would appreciate help streamlining that
side. The best I could do quickly is to simply extend your patch with copy |
paste | sed and touching up c99_functions.c. I expect there is probably some
better way to reduce duplication, thus opportunities for typos.
