https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
Andrew Pinski changed:
What|Removed |Added
Target Milestone|4.9.4 |---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|4.9.3 |4.9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #27 from Jakub Jelinek ---
GCC 4.9.3 has been released.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|4.9.2 |4.9.3
--- Comment #26 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|4.9.1 |4.9.2
--- Comment #25 from Jakub Jelinek
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|4.9.0 |4.9.1
--- Comment #24 from Jakub Jelinek
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #23 from Paolo Carlini ---
Thanks. I'm sending to the mailing list an updated version, which only proceeds
with do_mpfr_arg1 when !flag_trapping_math && !flag_errno_math.
About the -nan, yes by now we know well that if we don't use mp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #22 from Vincent Lefèvre ---
(In reply to Paolo Carlini from comment #20)
> Thus I clearly realize something: if we do better for mpfr, the issue
> remains that if we do *not* optimize and constants are not propagated, we
> issue libra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #21 from Vincent Lefèvre ---
(In reply to Paolo Carlini from comment #19)
> If I change fold_builtin_logarithm to pass a true as last argument to
> do_mpfr_arg1 (thus 0 is accepted) and do_mpfr_ckconv to accept a folded
> result which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #20 from Paolo Carlini ---
Thus I clearly realize something: if we do better for mpfr, the issue remains
that if we do *not* optimize and constants are not propagated, we issue library
calls, which, for command line switches like -fno-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #19 from Paolo Carlini ---
If I change fold_builtin_logarithm to pass a true as last argument to
do_mpfr_arg1 (thus 0 is accepted) and do_mpfr_ckconv to accept a folded result
which is infinity, things finally work. Patchlet below. Not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #18 from Paolo Carlini ---
Now the question is: why we use a library call for log(0) instead of mpfr?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #17 from Paolo Carlini ---
If I play with some constexprs, I understand that, irrespective of the command
line switches, we never fold to a constant the log. However, only for
-fno-math-errno -funsafe-math-optimizations the library cal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #16 from Paolo Carlini ---
Uhm, something isn't going as planned. If I change that check in do_mpfr_arg1
to
!real_isnan (ra), then we always fold __builtin_expl(-__builtin_huge_vall()) to
an exact 0.
However, with *both* -fno-math-err
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #15 from Vincent Lefèvre ---
If GCC intends to handle Bessel functions j0, j1, jn, y0, y1, yn (POSIX), there
may be differences with GNU MPFR. See my messages and bug report:
http://permalink.gmane.org/gmane.comp.standards.posix.aust
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #13 from Vincent Lefèvre ---
A difference that may occur in the future if the C library adds a rsqrt
function (based on the IEEE 754-2008 rSqrt function) or constant folding is
used on builtins: in MPFR, mpfr_rec_sqrt on -0 gives +Inf,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #12 from Vincent Lefèvre ---
(In reply to Marc Glisse from comment #9)
> I believe there are far fewer special cases (and thus
> risks) with MPFR, but that would indeed require a suitable testsuite for all
> functions for which we enab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #11 from joseph at codesourcery dot com ---
On Sat, 27 Jul 2013, glisse at gcc dot gnu.org wrote:
> Yeah, any of those. I was inspired by glibc, which has for instance:
>
> double
> __fdim (double x, double y)
> {
> int clsx = fpcl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #10 from Paolo Carlini ---
About testing, it would be just matter of extending/updating what Kaveh Ghazi
set up when mpfr/mpc came in.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #9 from Marc Glisse ---
(In reply to jos...@codesourcery.com from comment #7)
> An example of MPC not following all the Annex G special cases is that
> catanh (1 + i0) is specified in Annex G to return Inf + i0 with
> divide-by-zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #8 from Paolo Carlini ---
About sin(Inf): I checked that with / without the real_isfinite the expression
evaluated in every case the same, -nan, if I remember correctly. I don't have
more details at the moment. My general point, again,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #6 from Marc Glisse ---
(In reply to Paolo Carlini from comment #5)
> Today I was thinking that given that, per docs and testsuite (double checked
> yesterday) the mpfr functions are able to cope with +-Inf arguments to the
> mathemati
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #7 from joseph at codesourcery dot com ---
An example of MPC not following all the Annex G special cases is that
catanh (1 + i0) is specified in Annex G to return Inf + i0 with
divide-by-zero exception, but at least with my MPC insta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #5 from Paolo Carlini ---
Today I was thinking that given that, per docs and testsuite (double checked
yesterday) the mpfr functions are able to cope with +-Inf arguments to the
mathematical functions and evaluate correctly, gating the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #4 from Marc Glisse ---
The MPFR documentation does claim that it strictly conforms to annex F (with an
explanation on how to emulate subnormals), though it isn't clear if that claim
only concerns +-*/sqrt or everything.
(In reply to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #2 from joseph at codesourcery dot com ---
There are no errno issues - this is an exact zero result, not underflow.
But I'm not confident that MPFR follows all the Annex F special cases for
infinities and NaNs (and even less confide
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #1 from Paolo Carlini ---
Thanks Marc.
29 matches
Mail list logo
