Re: [PATCH] libquadmath: add quad support for trig-pi functions
Hello, On Thu, 3 Jul 2025, Joseph Myers wrote: > > > Isn't the whole raison d'etre for the trig-pi functions that the internal > > > argument reduction against multiples of pi becomes trivial and hence (a) > > > performant, and (b) doesn't introduce rounding artifacts? Expressing the > > > trig-pi functions in terms of their counterparts completely defeats this > > > purpose. The other way around would be more sensible for the cases where > > > it works, but the above doesn't seem very attractive. > > > x = M_FABS (x - M_LIT (2.0) * M_SUF (round) (M_LIT (0.5) * x)); > > In particular, this is what trivial range reduction looks like: no need to > do multiple-precision multiplication with the relevant bits of a > multiple-precision value of 1/pi, just round to the nearest integer > (typically a single instruction). Yes. And then the above is multiplied by PI, passed to cos/sin and that one then tries to figure out the multiple of PI (i.e. the 'x' above) again via range reduction (not a _terribly_ slow one anymore in a good implementation, because of the limited input range, but still). That's backwards. Ciao, Michael.
Re: [PATCH] libquadmath: add quad support for trig-pi functions
Hello,
On Thu, 3 Jul 2025, Yuao Ma wrote:
> This patch adds the required function for Fortran trigonometric functions to
> work with glibc versions prior to 2.26. It's based on glibc source commit
> 632d895f3e5d98162f77b9c3c1da4ec19968b671.
>
> I've built it successfully on my end. Documentation is also included.
>
> Please take a look when you have a moment.
+__float128
+cospiq (__float128 x)
+{
...
+ if (__builtin_islessequal (x, 0.25Q))
+return cosq (M_PIq * x);
Isn't the whole raison d'etre for the trig-pi functions that the internal
argument reduction against multiples of pi becomes trivial and hence (a)
performant, and (b) doesn't introduce rounding artifacts? Expressing the
trig-pi functions in terms of their counterparts completely defeats this
purpose. The other way around would be more sensible for the cases where
it works, but the above doesn't seem very attractive.
Ciao,
Michael.
Re: [Patch] gfortran: Fix in-build-tree testing [PR101305, PR101660]
Hello, On Tue, 10 Aug 2021, Jakub Jelinek via Gcc-patches wrote: > > +# Place ISO_Fortran_binding.h also under include/ in the build directory > > such > > +# that it can be used for in-built-tree testsuite runs without > > interference of > > +# other files in the build dir - like intrinsic .mod files or other .h > > files. > > ISO_Fortran_binding.h: $(srcdir)/ISO_Fortran_binding-1-tmpl.h \ > >$(srcdir)/ISO_Fortran_binding-2-tmpl.h \ > >$(srcdir)/ISO_Fortran_binding-3-tmpl.h \ > > @@ -1085,6 +1088,8 @@ ISO_Fortran_binding.h: > > $(srcdir)/ISO_Fortran_binding-1-tmpl.h \ > > $(COMPILE) -E -dD $(srcdir)/ISO_Fortran_binding-2-tmpl.h \ > > | grep '^#define CFI_type' >> $@ > > cat $(srcdir)/ISO_Fortran_binding-3-tmpl.h >> $@ > > + $(MKDIR_P) include > > + cp $@ include/ISO_Fortran_binding.h > > I see many Makefile.* in GCC doing rm -f file before cp whatever file, > but don't know if that is just trying to be extra cautious or if it is > needed for portability. coreutils cp (and what POSIX says) is that > overwriting the destination file should be fine and shouldn't cause > failures, at least when the destination is writable. I think this is to deal cautiously with symlinks: if the destination filename is a symlink to an existing file that target file is overwritten by cp, not the symlink (which continues to point to the now changed target file). Ciao, Michael.
