https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #21 from CVS Commits ---
The releases/gcc-10 branch has been updated by Xiong Hu Luo
:
https://gcc.gnu.org/g:68d525ee859041b21d87b23030d1e829a9cc3b6f
commit r10-10116-g68d525ee859041b21d87b23030d1e829a9cc3b6f
Author: Xionghu Luo
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #20 from CVS Commits ---
The releases/gcc-11 branch has been updated by Xiong Hu Luo
:
https://gcc.gnu.org/g:a87d7fbef55f72781905bffb298aab698fe6ed40
commit r11-8985-ga87d7fbef55f72781905bffb298aab698fe6ed40
Author: Xionghu Luo
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #19 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #17)
> The Version about is to 10.2, does that mean we're going to back port this
> to the release branches, or are we calling it good with trunk?
This is a pret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #18 from Segher Boessenkool ---
+/* { dg-final { scan-assembler-not {(?n)\mb.*fmod} } } */
+/* { dg-final { scan-assembler-not {(?n)\mb.*fmodf} } } */
+/* { dg-final { scan-assembler-not {(?n)\mb.*remainder} } } */
+/* { dg-final { sc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #17 from Peter Bergner ---
(In reply to CVS Commits from comment #16)
> The master branch has been updated by Xiong Hu Luo :
So fixed on trunk.
The Version about is to 10.2, does that mean we're going to back port this to
the releas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #16 from CVS Commits ---
The master branch has been updated by Xiong Hu Luo :
https://gcc.gnu.org/g:546ecb0054af302acf0839c7f3eb78598f8c0672
commit r12-3375-g546ecb0054af302acf0839c7f3eb78598f8c0672
Author: Xionghu Luo
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #15 from luoxhu at gcc dot gnu.org ---
Patch updated:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578740.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #14 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #13)
> (In reply to luoxhu from comment #12)
> > Patch submitted:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568143.html
>
> Looks like Will r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
Peter Bergner changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #12 from luoxhu at gcc dot gnu.org ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568143.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #11 from Segher Boessenkool ---
(In reply to luoxhu from comment #10)
> If not built with fast-math, gimple_has_side_effects will return true and
> cause the expand_call_stmt fail to expand the "_1 = fmod (x_2(D), y_3(D));"
> to inter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #10 from luoxhu at gcc dot gnu.org ---
If not built with fast-math, gimple_has_side_effects will return true and cause
the expand_call_stmt fail to expand the "_1 = fmod (x_2(D), y_3(D));" to
internal function. X86 also produces "bl f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #9 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #8)
> I don't think we have an instruction for that? But we can inline the
> code we need instead of doing a library call, which is much faster.
> (We probably ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #8 from Segher Boessenkool ---
I don't think we have an instruction for that? But we can inline the
code we need instead of doing a library call, which is much faster.
(We probably can use FMAs here usefully, btw; maybe even without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
Peter Bergner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Segher Boes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #5 from Dave Love ---
I meant to show that x86_64 expands the built in fmod too. (I wasn't sure
whether "inline" was the right term, as it seems not to be done by
-finline-functions.)
Yes, xlf -O3 (?) and above imlies something like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #4 from Dave Love ---
Created attachment 49249
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49249&action=edit
xlf -O5 -S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #3 from Peter Bergner ---
(In reply to Richard Biener from comment #2)
> Btw, with -ffast-math (or -Ofast) on x86 you get fmod inlined, I guess xlf
> -O5
> is to some extent doing -ffast-math?
Xlf at -O3, -O4 and -O5 automatically en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #2 from Richard Biener ---
Btw, with -ffast-math (or -Ofast) on x86 you get fmod inlined, I guess xlf -O5
is to some extent doing -ffast-math?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-09-21
Target|
22 matches
Mail list logo
