[Bug middle-end/111655] [11/12/13/14 Regression] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655 Bruno Haible changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #16 from Bruno Haible --- (In reply to Paul Eggert from comment #5) > Although it is indeed unspecified whether 0.0/0.0 yields -NaN or +NaN, it is > well understood that negating a floating point value flips its sign bit. While I agree that this is generally true, it's not the case on mips with clang as compiler. Namely, this compiler generates 'neg.d' instructions for the unary minus of a 'double' value, and this instruction may be a no-op on NaN values, depending on the CPU's control registers. For details, see the "MIPS® Architecture for Progreammers, Volume II-A: The MIPS® Instruction Set Manual", page 307 (317). Whereas gcc generates an integer XOR instruction (at least in my test cases), so is fine.
[Bug middle-end/111655] [11/12/13/14 Regression] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2 --- Comment #15 from Jakub Jelinek --- I don't think a 9+ years old bug should be a P1. It would be nice to get it fixed, but I'm not sure it is feasible for GCC 14 and very unlikely backportable if we e.g. have to split the *nonnegative* predicates to 2 sets.
[Bug middle-end/111655] [11/12/13/14 Regression] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 CC||law at gcc dot gnu.org
[Bug middle-end/111655] [11/12/13/14 Regression] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655 --- Comment #14 from rguenther at suse dot de --- On Fri, 24 Nov 2023, amonakov at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655 > > --- Comment #13 from Alexander Monakov --- > > Then there is the MULT_EXPR x * x case > > This is PR 111701. > > It would be nice to clarify what "nonnegative" means in the contracts of this > family of functions, because it's ambiguous for NaNs and negative zeros (x < 0 > is false while signbit is set, and x >= 0 is also false for positive NaNs). Agreed, I think we're using it in both ways which is the problem in the end. Maybe having _compares_nonnegative and _sign_positive would clarify this.
[Bug middle-end/111655] [11/12/13/14 Regression] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655 --- Comment #13 from Alexander Monakov --- > Then there is the MULT_EXPR x * x case This is PR 111701. It would be nice to clarify what "nonnegative" means in the contracts of this family of functions, because it's ambiguous for NaNs and negative zeros (x < 0 is false while signbit is set, and x >= 0 is also false for positive NaNs).
[Bug middle-end/111655] [11/12/13/14 Regression] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek --- Started with r6-3811-g68e57f040c6330eb853551622d458a67d6f9e572 on this testcase, but as pointed out tree_binary_nonnegative_warnv_p needs to be more careful. Given that tree_single_nonnegative_warnv_p may return true on REAL_CST NaN literal with sign bit unset, one question is if e.g. such NaN + nonnegative_value or nonnegative_value + such NaN could result in NaN result with negative sign, in that case even PLUS_EXPR if (FLOAT_TYPE_P (type)) return RECURSE (op0) && RECURSE (op1); would be incorrect and we'd need to guard it with && !tree_expr_maybe_nan_p (op0) && !tree_expr_maybe_nan_p (op1). Then there is the MULT_EXPR x * x case, that might suffer from similar problem to PLUS_EXPR if NaN with positive sign * NaN with positive sign can result in NaN with negative sign. Then there is the MULT_EXPR RECURSE (op0) && RECURSE (op1) case, that one can certainly result in possibly NaN if one operand is 0 and another +inf, so we'd need to guard it for FLOAT_TYPE_P with (tree_expr_nonzero_warnv_p (op0, strict_overflow_p) || !tree_expr_maybe_infinite_p (op1)) && (tree_expr_nonzero_warnv_p (op1, strict_overflow_p) || !tree_expr_maybe_infinite_p (op0)) And then RDIV_EXPR, again corresponding checks.
[Bug middle-end/111655] [11/12/13/14 Regression] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655 --- Comment #11 from Alexander Monakov --- (In reply to Richard Biener from comment #10) > And this conservatively has to apply to all FP divisions where we might infer > "nonnegative" unless we can also infer !zerop? Yes, I think the logic in tree_binary_nonnegative_warnv_p is incorrect for floating-point division. Likewise for multiplication: it returns true for 'x * x', but when x is a NaN, 'x * x' is also a NaN (potentially with the same sign). > On the side of replacing all uses I'd error on simply not folding. Yes, as preceding transforms might have duplicated the division already. We can only do such folding very early, when we are sure no duplication might have taken place. > Note 6.5.5/6 says "In both operations, if the value of the second operand is > zero, the behavior is undefined." only remotely implying this doesn't > apply to non-integer types (remotely by including modulo behavior in this > sentence). > > Possibly in some other place the C standard makes FP division by zero subject > to other rules. I think the intention is that Annex F makes it follow IEEE rules (returns an Inf/NaN and sets FE_DIVBYZERO/FE_INVALID), but it doesn't seem to be clearly worded, afaict.
[Bug middle-end/111655] [11/12/13/14 Regression] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655 Richard Biener changed: What|Removed |Added Known to work||4.8.5 Target Milestone|--- |11.5 --- Comment #10 from Richard Biener --- And this conservatively has to apply to all FP divisions where we might infer "nonnegative" unless we can also infer !zerop? On the side of replacing all uses I'd error on simply not folding. Note 6.5.5/6 says "In both operations, if the value of the second operand is zero, the behavior is undefined." only remotely implying this doesn't apply to non-integer types (remotely by including modulo behavior in this sentence). Possibly in some other place the C standard makes FP division by zero subject to other rules.
