public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r13-3926] range-op: Implement op[12]_range operators for {PLUS, MINUS, MULT, RDIV}_EXPR Date: Sat, 12 Nov 2022 08:43:07 +0000 (GMT) [thread overview] Message-ID: <20221112084307.88865383A318@sourceware.org> (raw) https://gcc.gnu.org/g:d4c2f1d376da6fc3f3c30a9d3160e43c95399343 commit r13-3926-gd4c2f1d376da6fc3f3c30a9d3160e43c95399343 Author: Jakub Jelinek <jakub@redhat.com> Date: Sat Nov 12 09:39:00 2022 +0100 range-op: Implement op[12]_range operators for {PLUS,MINUS,MULT,RDIV}_EXPR On Wed, Nov 09, 2022 at 04:43:56PM +0100, Aldy Hernandez wrote: > On Wed, Nov 9, 2022 at 3:58 PM Jakub Jelinek <jakub@redhat.com> wrote: > > > > On Wed, Nov 09, 2022 at 10:02:46AM +0100, Aldy Hernandez wrote: > > > We can implement the op[12]_range entries for plus and minus in terms > > > of each other. These are adapted from the integer versions. > > > > I think for NANs the op[12]_range shouldn't act this way. > > For the forward binary operations, we have the (maybe/known) NAN handling > > of one or both NAN operands resulting in VARYING sign (maybe/known) NAN > > result, that is the somehow the case for the reverse binary operations too, > > if result is (maybe/known) NAN and the other op is not NAN, op is > > VARYING sign (maybe/known) NAN, if other op is (maybe/known) NAN, > > then op is VARYING sign maybe NAN (always maybe, never known). > > But then for + we have the -INF + INF or vice versa into NAN, and that > > is something that shouldn't be considered. If result isn't NAN, then > > neither operand can be NAN, regardless of whether result can be > > +/- INF and the other op -/+ INF. > > Heh. I just ran into this while debugging the problem reported by Xi. > > We are solving NAN = op1 - VARYING, and trying to do it with op1 = NAN > + VARYING, which returns op1 = NAN (incorrectly). > > I suppose in the above case op1 should ideally be > [-INF,-INF][+INF,+INF]+-NAN, but since we can't represent that then > [-INF,+INF] +-NAN, which is actually VARYING. Do you agree? > > I'm reverting this patch as attached, while I sort this out. Here is a patch which reinstalls your change, add the fixups I've talked about and also hooks up reverse operators for MULT_EXPR/RDIV_EXPR. 2022-11-12 Aldy Hernandez <aldyh@redhat.com> Jakub Jelinek <jakub@redhat.com> * range-op-float.cc (float_binary_op_range_finish): New function. (foperator_plus::op1_range): New. (foperator_plus::op2_range): New. (foperator_minus::op1_range): New. (foperator_minus::op2_range): New. (foperator_mult::op1_range): New. (foperator_mult::op2_range): New. (foperator_div::op1_range): New. (foperator_div::op2_range): New. * gcc.c-torture/execute/ieee/inf-4.c: New test. Diff: --- gcc/range-op-float.cc | 131 +++++++++++++++++++++++ gcc/testsuite/gcc.c-torture/execute/ieee/inf-4.c | 26 +++++ 2 files changed, 157 insertions(+) diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc index 91185c5dc79..4472337e03e 100644 --- a/gcc/range-op-float.cc +++ b/gcc/range-op-float.cc @@ -1861,6 +1861,39 @@ foperator_unordered_equal::op1_range (frange &r, tree type, return true; } +// Final tweaks for float binary op op1_range/op2_range. +// Return TRUE if the operation is performed and a valid range is available. + +static bool +float_binary_op_range_finish (bool ret, frange &r, tree type, + const frange &lhs) +{ + if (!ret) + return false; + + // If we get a known NAN from reverse op, it means either that + // the other operand was known NAN (in that case we know nothing), + // or the reverse operation introduced a known NAN. + // Say for lhs = op1 * op2 if lhs is [-0, +0] and op2 is too, + // 0 / 0 is known NAN. Just punt in that case. + // Or if lhs is a known NAN, we also don't know anything. + if (r.known_isnan () || lhs.known_isnan ()) + { + r.set_varying (type); + return true; + } + + // If lhs isn't NAN, then neither operand could be NAN, + // even if the reverse operation does introduce a maybe_nan. + if (!lhs.maybe_isnan ()) + r.clear_nan (); + // If lhs is a maybe or known NAN, the operand could be + // NAN. + else + r.update_nan (); + return true; +} + // True if [lb, ub] is [+-0, +-0]. static bool zero_p (const REAL_VALUE_TYPE &lb, const REAL_VALUE_TYPE &ub) @@ -1955,6 +1988,30 @@ zero_to_inf_range (REAL_VALUE_TYPE &lb, REAL_VALUE_TYPE &ub, int signbit_known) class foperator_plus : public range_operator_float { + using range_operator_float::op1_range; + using range_operator_float::op2_range; +public: + virtual bool op1_range (frange &r, tree type, + const frange &lhs, + const frange &op2, + relation_trio = TRIO_VARYING) const final override + { + if (lhs.undefined_p ()) + return false; + range_op_handler minus (MINUS_EXPR, type); + if (!minus) + return false; + return float_binary_op_range_finish (minus.fold_range (r, type, lhs, op2), + r, type, lhs); + } + virtual bool op2_range (frange &r, tree type, + const frange &lhs, + const frange &op1, + relation_trio = TRIO_VARYING) const final override + { + return op1_range (r, type, lhs, op1); + } +private: void rv_fold (REAL_VALUE_TYPE &lb, REAL_VALUE_TYPE &ub, bool &maybe_nan, tree type, const REAL_VALUE_TYPE &lh_lb, @@ -1980,6 +2037,31 @@ class foperator_plus : public range_operator_float class foperator_minus : public range_operator_float { + using range_operator_float::op1_range; + using range_operator_float::op2_range; +public: + virtual bool op1_range (frange &r, tree type, + const frange &lhs, + const frange &op2, + relation_trio = TRIO_VARYING) const final override + { + if (lhs.undefined_p ()) + return false; + return float_binary_op_range_finish (fop_plus.fold_range (r, type, lhs, + op2), + r, type, lhs); + } + virtual bool op2_range (frange &r, tree type, + const frange &lhs, + const frange &op1, + relation_trio = TRIO_VARYING) const final override + { + if (lhs.undefined_p ()) + return false; + return float_binary_op_range_finish (fold_range (r, type, op1, lhs), + r, type, lhs); + } +private: void rv_fold (REAL_VALUE_TYPE &lb, REAL_VALUE_TYPE &ub, bool &maybe_nan, tree type, const REAL_VALUE_TYPE &lh_lb, @@ -2030,6 +2112,30 @@ protected: class foperator_mult : public foperator_mult_div_base { + using range_operator_float::op1_range; + using range_operator_float::op2_range; +public: + virtual bool op1_range (frange &r, tree type, + const frange &lhs, + const frange &op2, + relation_trio = TRIO_VARYING) const final override + { + if (lhs.undefined_p ()) + return false; + range_op_handler rdiv (RDIV_EXPR, type); + if (!rdiv) + return false; + return float_binary_op_range_finish (rdiv.fold_range (r, type, lhs, op2), + r, type, lhs); + } + virtual bool op2_range (frange &r, tree type, + const frange &lhs, + const frange &op1, + relation_trio = TRIO_VARYING) const final override + { + return op1_range (r, type, lhs, op1); + } +private: void rv_fold (REAL_VALUE_TYPE &lb, REAL_VALUE_TYPE &ub, bool &maybe_nan, tree type, const REAL_VALUE_TYPE &lh_lb, @@ -2137,6 +2243,31 @@ class foperator_mult : public foperator_mult_div_base class foperator_div : public foperator_mult_div_base { + using range_operator_float::op1_range; + using range_operator_float::op2_range; +public: + virtual bool op1_range (frange &r, tree type, + const frange &lhs, + const frange &op2, + relation_trio = TRIO_VARYING) const final override + { + if (lhs.undefined_p ()) + return false; + return float_binary_op_range_finish (fop_mult.fold_range (r, type, lhs, + op2), + r, type, lhs); + } + virtual bool op2_range (frange &r, tree type, + const frange &lhs, + const frange &op1, + relation_trio = TRIO_VARYING) const final override + { + if (lhs.undefined_p ()) + return false; + return float_binary_op_range_finish (fold_range (r, type, op1, lhs), + r, type, lhs); + } +private: void rv_fold (REAL_VALUE_TYPE &lb, REAL_VALUE_TYPE &ub, bool &maybe_nan, tree type, const REAL_VALUE_TYPE &lh_lb, diff --git a/gcc/testsuite/gcc.c-torture/execute/ieee/inf-4.c b/gcc/testsuite/gcc.c-torture/execute/ieee/inf-4.c new file mode 100644 index 00000000000..119775d7b89 --- /dev/null +++ b/gcc/testsuite/gcc.c-torture/execute/ieee/inf-4.c @@ -0,0 +1,26 @@ +__attribute__((noipa)) int +foo (double a, double b) +{ + double c = a - b; + if (!__builtin_isfinite (c)) + { + if (__builtin_isnan (c)) + { + if (!__builtin_isnan (a) && !__builtin_isnan (b)) + return 1; + } + else if (__builtin_isfinite (a) && __builtin_isfinite (b)) + return 2; + } + else if (c == 0 && a != b) + return 3; + return 4; +} + +int +main () +{ + double a = __builtin_inf (); + if (foo (a, a) != 1) + __builtin_abort (); +}
reply other threads:[~2022-11-12 8:43 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20221112084307.88865383A318@sourceware.org \ --to=jakub@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).