https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #24 from joseph at codesourcery dot com ---
On Mon, 13 Jun 2022, already5chosen at yahoo dot com via Gcc-bugs wrote:
> > For long double it's sysdeps/ieee754/soft-fp/s_fmal.c in glibc - some
> > adjustments would be needed to be ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #23 from Michael_S ---
(In reply to jos...@codesourcery.com from comment #22)
> On Mon, 13 Jun 2022, already5chosen at yahoo dot com via Gcc-bugs wrote:
>
> > > The function should be sqrtf128 (present in glibc 2.26 and later on
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #22 from joseph at codesourcery dot com ---
On Mon, 13 Jun 2022, already5chosen at yahoo dot com via Gcc-bugs wrote:
> > The function should be sqrtf128 (present in glibc 2.26 and later on
> > x86_64, x86, powerpc64le, ia64). I do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #21 from Michael_S ---
(In reply to jos...@codesourcery.com from comment #20)
> On Sat, 11 Jun 2022, already5chosen at yahoo dot com via Gcc-bugs wrote:
>
> > On MSYS2 _Float128 and __float128 appears to be mostly the same thing,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #20 from joseph at codesourcery dot com ---
On Sat, 11 Jun 2022, already5chosen at yahoo dot com via Gcc-bugs wrote:
> On MSYS2 _Float128 and __float128 appears to be mostly the same thing, mapped
> to the same library routines with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #19 from Michael_S ---
(In reply to jos...@codesourcery.com from comment #18)
> libquadmath is essentially legacy code. People working directly in C
> should be using the C23 _Float128 interfaces and *f128 functions, as in
> curre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #18 from joseph at codesourcery dot com ---
libquadmath is essentially legacy code. People working directly in C
should be using the C23 _Float128 interfaces and *f128 functions, as in
current glibc, rather than libquadmath interf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #17 from Michael_S ---
(In reply to Jakub Jelinek from comment #15)
> From what I can see, it is mostly integral implementation and we already
> have one such in GCC, so the question is if we just shouldn't use it (most
> of the sou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #16 from Michael_S ---
(In reply to Thomas Koenig from comment #14)
> @Michael: Now that gcc 12 is out of the door, I would suggest we try to get
> your code into the gcc tree for gcc 13.
>
> It should follow the gcc style guideline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #15 from Jakub Jelinek ---
>From what I can see, it is mostly integral implementation and we already have
one such in GCC, so the question is if we just shouldn't use it (most of the
sources
are in libgcc/soft-fp/ , then configurati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #14 from Thomas Koenig ---
@Michael: Now that gcc 12 is out of the door, I would suggest we try to get
your code into the gcc tree for gcc 13.
It should follow the gcc style guidelines, which is quite trivial to do:
Comments should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #13 from Michael_S ---
It turned out that on all micro-architectures that I care about (and majority
of those that I don't care) double precision floating point division is quite
fast.
It's so fast that it easily beats my clever reci
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #12 from Michael_S ---
(In reply to Michael_S from comment #11)
> (In reply to Michael_S from comment #10)
> > BTW, the same ideas as in the code above could improve speed of division
> > operation (on modern 64-bit HW) by factor of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #11 from Michael_S ---
(In reply to Michael_S from comment #10)
> BTW, the same ideas as in the code above could improve speed of division
> operation (on modern 64-bit HW) by factor of 3 (on Intel) or 2 (on AMD).
Did it.
On Intel i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #10 from Michael_S ---
BTW, the same ideas as in the code above could improve speed of division
operation (on modern 64-bit HW) by factor of 3 (on Intel) or 2 (on AMD).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #9 from Michael_S ---
(In reply to Michael_S from comment #4)
> If you want quick fix for immediate shipment then you can take that:
>
> #include
> #include
>
> __float128 quick_and_dirty_sqrtq(__float128 x)
> {
> if (isnanq(x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #8 from Steve Kargl ---
On Sat, Apr 09, 2022 at 10:23:39AM +, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
>
> --- Comment #6 from Jakub Jelinek ---
> (In reply to Thomas Koenig from com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #7 from Thomas Koenig ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Thomas Koenig from comment #5)
> > There is another, much worse, problem, reported and analyzed by "Michael S"
> > on comp.arch. The code has
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #6 from Jakub Jelinek ---
(In reply to Thomas Koenig from comment #5)
> There is another, much worse, problem, reported and analyzed by "Michael S"
> on comp.arch. The code has
>
> #ifdef HAVE_SQRTL
> {
> long double xl = (lon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #5 from Thomas Koenig ---
There is another, much worse, problem, reported and analyzed by "Michael S"
on comp.arch. The code has
#ifdef HAVE_SQRTL
{
long double xl = (long double) x;
if (xl <= LDBL_MAX && xl >= LDBL_MIN)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
Michael_S changed:
What|Removed |Added
CC||already5chosen at yahoo dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> (In reply to Jakub Jelinek from comment #1)
>
> > So, do we need to switch to soft-fp based implementation for it (we have a
> > copy already in libgcc/soft-f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
Francois-Xavier Coudert changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
25 matches
Mail list logo
