public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug tree-optimization/109386] New: [13 Regression] Frange value relation related miscompilation @ 2023-04-03 8:00 jakub at gcc dot gnu.org 2023-04-03 8:00 ` [Bug tree-optimization/109386] " jakub at gcc dot gnu.org ` (6 more replies) 0 siblings, 7 replies; 8+ messages in thread From: jakub at gcc dot gnu.org @ 2023-04-03 8:00 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109386 Bug ID: 109386 Summary: [13 Regression] Frange value relation related miscompilation Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- I've totally missed a regression caused by my recent frange improvements (most likely r13-6967-g5fe05ffefd21c4fa): +FAIL: libphobos.phobos/std/math/algebraic.d execution test +FAIL: libphobos.phobos_shared/std/math/algebraic.d execution test Reduced testcase in C: static inline float foo (float x, float y) { float u = __builtin_fabsf (x); float v = __builtin_fabsf (y); if (!(u >= v)) { v = u; u = __builtin_fabsf (y); if (__builtin_isinf (u)) return u; if (__builtin_isinf (v)) return v; } return 42.0f; } int main () { if (!__builtin_isinf (foo (__builtin_inff (), __builtin_nanf ("")))) __builtin_abort (); } for -O2. I believe the bug is that (as discussed earlier) we don't implement the full set of VREL_* relations for the case where NAN may be seen and in this case register VREL_LT for the if block, which is wrong, the inverse of VREL_GE is VREL_UNLT which we don't currently have. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/109386] [13 Regression] Frange value relation related miscompilation 2023-04-03 8:00 [Bug tree-optimization/109386] New: [13 Regression] Frange value relation related miscompilation jakub at gcc dot gnu.org @ 2023-04-03 8:00 ` jakub at gcc dot gnu.org 2023-04-03 8:48 ` jakub at gcc dot gnu.org ` (5 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: jakub at gcc dot gnu.org @ 2023-04-03 8:00 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109386 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P1 Target Milestone|--- |13.0 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/109386] [13 Regression] Frange value relation related miscompilation 2023-04-03 8:00 [Bug tree-optimization/109386] New: [13 Regression] Frange value relation related miscompilation jakub at gcc dot gnu.org 2023-04-03 8:00 ` [Bug tree-optimization/109386] " jakub at gcc dot gnu.org @ 2023-04-03 8:48 ` jakub at gcc dot gnu.org 2023-04-03 10:21 ` jakub at gcc dot gnu.org ` (4 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: jakub at gcc dot gnu.org @ 2023-04-03 8:48 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109386 --- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Created attachment 54802 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54802&action=edit gcc13-pr109386.patch Untested patch. I've tried to fix the incorrect registraction of value relation (in the scope of the current set of VREL_*), but unfortunately it didn't fix it. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/109386] [13 Regression] Frange value relation related miscompilation 2023-04-03 8:00 [Bug tree-optimization/109386] New: [13 Regression] Frange value relation related miscompilation jakub at gcc dot gnu.org 2023-04-03 8:00 ` [Bug tree-optimization/109386] " jakub at gcc dot gnu.org 2023-04-03 8:48 ` jakub at gcc dot gnu.org @ 2023-04-03 10:21 ` jakub at gcc dot gnu.org 2023-04-03 11:00 ` marxin at gcc dot gnu.org ` (3 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: jakub at gcc dot gnu.org @ 2023-04-03 10:21 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109386 --- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> --- The swapping isn't really needed, the testcase can be simplified to: static inline float foo (float x, float y) { float u = __builtin_fabsf (x); float v = __builtin_fabsf (y); if (!(u >= v)) { if (__builtin_isinf (v)) return v; if (__builtin_isinf (u)) return u; } return 42.0f; } int main () { if (!__builtin_isinf (foo (__builtin_inff (), __builtin_nanf ("")))) __builtin_abort (); } ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/109386] [13 Regression] Frange value relation related miscompilation 2023-04-03 8:00 [Bug tree-optimization/109386] New: [13 Regression] Frange value relation related miscompilation jakub at gcc dot gnu.org ` (2 preceding siblings ...) 2023-04-03 10:21 ` jakub at gcc dot gnu.org @ 2023-04-03 11:00 ` marxin at gcc dot gnu.org 2023-04-03 12:16 ` jakub at gcc dot gnu.org ` (2 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: marxin at gcc dot gnu.org @ 2023-04-03 11:00 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109386 Martin Liška <marxin at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed| |2023-04-03 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/109386] [13 Regression] Frange value relation related miscompilation 2023-04-03 8:00 [Bug tree-optimization/109386] New: [13 Regression] Frange value relation related miscompilation jakub at gcc dot gnu.org ` (3 preceding siblings ...) 2023-04-03 11:00 ` marxin at gcc dot gnu.org @ 2023-04-03 12:16 ` jakub at gcc dot gnu.org 2023-04-04 14:20 ` cvs-commit at gcc dot gnu.org 2023-04-04 14:22 ` jakub at gcc dot gnu.org 6 siblings, 0 replies; 8+ messages in thread From: jakub at gcc dot gnu.org @ 2023-04-03 12:16 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109386 --- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Created attachment 54803 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54803&action=edit gcc13-pr109386.patch Untested fix. When LT/LE/GT/GE have lhs [0, 0] or UNLT/UNLE/UNGT/UNGE have lhs [1, 1], we don't know anything (VARYING) about one operand if the other operand may be a NAN, not just is known to be a NAN, because if it happens to be NAN at runtime, the comparison is false (resp. true) regardless of the finite/infinite comparison results. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/109386] [13 Regression] Frange value relation related miscompilation 2023-04-03 8:00 [Bug tree-optimization/109386] New: [13 Regression] Frange value relation related miscompilation jakub at gcc dot gnu.org ` (4 preceding siblings ...) 2023-04-03 12:16 ` jakub at gcc dot gnu.org @ 2023-04-04 14:20 ` cvs-commit at gcc dot gnu.org 2023-04-04 14:22 ` jakub at gcc dot gnu.org 6 siblings, 0 replies; 8+ messages in thread From: cvs-commit at gcc dot gnu.org @ 2023-04-04 14:20 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109386 --- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:ce243c9eefc2728cb8743ebbcb84c3e08236f06a commit r13-7002-gce243c9eefc2728cb8743ebbcb84c3e08236f06a Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Apr 4 16:13:06 2023 +0200 range-op-float: Fix reverse ops of comparisons [PR109386] I've missed one of my recent range-op-float.cc changes (likely the r13-6967 one) caused FAIL: libphobos.phobos/std/math/algebraic.d execution test FAIL: libphobos.phobos_shared/std/math/algebraic.d execution test regressions, distilled into a C testcase below. In the testcase, we have !(u >= v) condition where both u and v are results of fabs*, which guards t1 = u u<= __FLT_MAX__; and t2 = v u<= __FLT_MAX__; comparisons. From false u >= v where u and v have [0.0, +Inf] NAN ranges we (incorrectly deduce that one of them is [nextafterf (0.0, 1.0), +Inf] NAN and the other is [0.0, nextafterf (+Inf, 0.0)] NAN and from that deduce that one of the comparisons is always true, because UNLE_EXPR with the maximum representable number are false only if the value is +Inf and our ranges tell that is not possible. The bug is that the u >= v comparison determines a sensible range only when it is true - we then know neither operand can be NAN and it behaves correctly. But when the comparison is false, our current code gives sensible answers only if the other op can't be NAN. If it can be NAN, whenever it is NAN, the comparison is always false regardless of the other value, so the other value needs to be VARYING. Now, foperator_unordered_lt::op1_range etc. had code to deal with that for op?.known_nan (), but as the testcase shows, it is enough if it may be a NAN at runtime to make it VARYING. So, the following patch replaces for all those BRS_FALSE cases of the normal non-equality comparisons if (opOTHER.known_isnan ()) r.set_varying (type); to do it also if maybe_isnan (). For the unordered or ... comparisons, it is similar for BRS_TRUE. Those comparisons are true whenever either operand is NAN, or if neither is NAN, the corresponding normal comparison. So, if those comparisons are true and other operand might be a NAN, we can't tell (VARYING), if it is false, currently handling is correct. 2023-04-04 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/109386 * range-op-float.cc (foperator_lt::op1_range, foperator_lt::op2_range, foperator_le::op1_range, foperator_le::op2_range, foperator_gt::op1_range, foperator_gt::op2_range, foperator_ge::op1_range, foperator_ge::op2_range): Make r varying for BRS_FALSE case even if the other op is maybe_isnan, not just known_isnan. (foperator_unordered_lt::op1_range, foperator_unordered_lt::op2_range, foperator_unordered_le::op1_range, foperator_unordered_le::op2_range, foperator_unordered_gt::op1_range, foperator_unordered_gt::op2_range, foperator_unordered_ge::op1_range, foperator_unordered_ge::op2_range): Make r varying for BRS_TRUE case even if the other op is maybe_isnan, not just known_isnan. * gcc.c-torture/execute/ieee/pr109386.c: New test. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/109386] [13 Regression] Frange value relation related miscompilation 2023-04-03 8:00 [Bug tree-optimization/109386] New: [13 Regression] Frange value relation related miscompilation jakub at gcc dot gnu.org ` (5 preceding siblings ...) 2023-04-04 14:20 ` cvs-commit at gcc dot gnu.org @ 2023-04-04 14:22 ` jakub at gcc dot gnu.org 6 siblings, 0 replies; 8+ messages in thread From: jakub at gcc dot gnu.org @ 2023-04-04 14:22 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109386 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Fixed. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-04-04 14:22 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-04-03 8:00 [Bug tree-optimization/109386] New: [13 Regression] Frange value relation related miscompilation jakub at gcc dot gnu.org 2023-04-03 8:00 ` [Bug tree-optimization/109386] " jakub at gcc dot gnu.org 2023-04-03 8:48 ` jakub at gcc dot gnu.org 2023-04-03 10:21 ` jakub at gcc dot gnu.org 2023-04-03 11:00 ` marxin at gcc dot gnu.org 2023-04-03 12:16 ` jakub at gcc dot gnu.org 2023-04-04 14:20 ` cvs-commit at gcc dot gnu.org 2023-04-04 14:22 ` jakub at gcc dot gnu.org
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).