https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #33 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #20)
> (In reply to Jakub Jelinek from comment #16)
>
> > More questionable is the #Z case, where Table 8-11 just talks about
> > Divide or reverse divide operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #31 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:8020c9c42349f51f75239b9d35a2be41848a97bd
commit r13-6361-g8020c9c42349f51f75239b9d35a2be41848a97bd
Author: Uros Bizjak
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #30 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #29)
> Note, fmod_optab is only used on i?86 (where because of the commit mentioned
> here it was limited to finite math only) and rs6000 (which guards it on
> unsafe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #29 from Jakub Jelinek ---
Note, fmod_optab is only used on i?86 (where because of the commit mentioned
here it was limited to finite math only) and rs6000 (which guards it on unsafe
math optimizations), so both in the fast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
Jakub Jelinek changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #26 from Uroš Bizjak ---
(In reply to Jan Kratochvil from comment #23)
> Created attachment 54542 [details]
> fmoderrno.cpp
>
> (In reply to Uroš Bizjak from comment #21)
> > When g:93ba85fdd253b4b9cf2b9e54e8e5969b1a3db098 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #25 from Jakub Jelinek ---
Note, the 215740 change has been backported to 4.8 branch in r215773 (I've been
wondering why I can't reproduce it on 4.8; and also to 4.9 branch).
Anyway, in 4.7 I see fmodl being called in *.optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #24 from Jan Kratochvil ---
(In reply to Alexander Monakov from comment #22)
> Strange, comment #8 claims the opposite (unless Jan tested the revert not on
> trunk, but on some branch).
The testsuite ran on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #23 from Jan Kratochvil ---
Created attachment 54542
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54542=edit
fmoderrno.cpp
(In reply to Uroš Bizjak from comment #21)
> When g:93ba85fdd253b4b9cf2b9e54e8e5969b1a3db098 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #22 from Alexander Monakov ---
Strange, comment #8 claims the opposite (unless Jan tested the revert not on
trunk, but on some branch).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #21 from Uroš Bizjak ---
(In reply to Alexander Monakov from comment #19)
> I get the feeling that you're ignoring me, but gcc-4.8.3 was already
> emitting a helper fmod call for setting errno without any flag_errno_math
> checks in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #20 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #16)
> More questionable is the #Z case, where Table 8-11 just talks about
> Divide or reverse divide operation Returns an ∞ signed with the exclusive
> OR of the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #19 from Alexander Monakov ---
I get the feeling that you're ignoring me, but gcc-4.8.3 was already emitting a
helper fmod call for setting errno without any flag_errno_math checks in
i386.md, i.e. it was already in the middle-end.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #18 from Jakub Jelinek ---
(In reply to Uroš Bizjak from comment #17)
> So, based on the above finding, should insn condition be changed to
> !flag_errno_math?
I'd say that it shouldn't be the business of backends to check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #17 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #16)
> Doesn't the SDM guarantee the right behavior though?
Indeed, this is what is missing from Table 3-31.
> It is true that the FPREM results table says * and **
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #16 from Jakub Jelinek ---
Doesn't the SDM guarantee the right behavior though?
It is true that the FPREM results table says * and ** in certain spots (Table
3-31 in my copy), but then in the Invalid Arithmetic Operand Exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #15 from Alexander Monakov ---
That is the fancy-error-handling path that is reached under _LIB_VERSION !=
_IEEE_. Before glibc-2.27, linking with -lieee would set _LIB_VERSION = _IEEE_,
and then glibc would use the fprem[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #14 from Uroš Bizjak ---
(In reply to Jan Kratochvil from comment #13)
> The question is whether gcc can rely on the undocumented Intel behavior as
> described in Comment 7. glibc already relies on it anyway.
I don't think this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #13 from Jan Kratochvil ---
(In reply to Uroš Bizjak from comment #12)
> (In reply to Jan Kratochvil from comment #8)
>
> > The revert makes it 13x faster. But the produced code still falls back to
> > calling glibc fmod() as shown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #12 from Uroš Bizjak ---
(In reply to Jan Kratochvil from comment #8)
> The revert makes it 13x faster. But the produced code still falls back to
> calling glibc fmod() as shown in the disassembly in Comment 0.
> If I use the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #11 from Uroš Bizjak ---
(In reply to Jan Kratochvil from comment #8)
> It is true replacing fmod() with fmodl() makes it 5x faster (but only 5x).
> There is still some infinity check and I haven't found any real
> justification in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #10 from Jan Kratochvil ---
(In reply to Alexander Monakov from comment #9)
> You just need to pass -fno-math-errno (the call is for setting errno,
> similar to how gcc emits the sqrt() sequence).
True, thanks.
So I think the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #9 from Alexander Monakov ---
(In reply to Jan Kratochvil from comment #8)
> The revert makes it 13x faster. But the produced code still falls back to
> calling glibc fmod() as shown in the disassembly in Comment 0.
> If I use the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #8 from Jan Kratochvil ---
(In reply to Andrew Pinski from comment #2)
> So the simple test is run the full GCC bootstrap/test with all languages and
> check if the testcase fails or not. I suspect it will.
It does not. Tested on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #7 from Alexander Monakov ---
I saw that. That's why I'm pointing out that Glibc (and musl) uses the
instruction without any additional checks: real CPUs produce the expected
result in st(0), despite the documentation making no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #6 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Alexander Monakov from comment #3)
> > I guess Uros' claim was based on what Intel and AMD manuals specify rather
> > than observed behavior of CPUs.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #5 from Uroš Bizjak ---
(In reply to Alexander Monakov from comment #3)
> I guess Uros' claim was based on what Intel and AMD manuals specify rather
> than observed behavior of CPUs.
As a "committer", I really don't remember the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #4 from Alexander Monakov ---
Plus, Glibc does use fprem/fprem1 for fmodl/remainderl on x86_64, as well as
for {fmod,remainder,remquo}{,f,l} on i386 without any branches for corner
cases. So in practice CPUs apparently implement the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #1 from Andrew Pinski ---
>The committer also claims "fixes ieee_2.f90 testsuite failure" but I have no
>idea where to find this testsuite.
./testsuite/gfortran.dg/ieee/ieee_2.f90
33 matches
Mail list logo
