From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 69F743842334; Tue, 6 Dec 2022 15:59:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 69F743842334 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1670342391; bh=UlmHxxqs/ihQ5XWviRGtR3SVdyWlABBAmcb4kOEtXDY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SxeIo4odk79Jtd8mN0BlCUUWHSmiFcHtnCvms0OuGT2AW1Ym3Zt2SJ6OwQ6m84wTo a+9QPBljzH4E3wuDxa6pwHgi8T/qVpSPU89iL0JveEE3VkVgaQFKiqkRA3McMAAQlI t3x5vx7YeFq2rqxOvMqspnhD6vAd9h0K7f8yJWfE= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails. Date: Tue, 06 Dec 2022 15:59:49 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: needs-reduction, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107967 --- Comment #7 from Jakub Jelinek --- Ok, I can reproduce this, disabling all the +-*/ handlers fixes it. It isn libm.so.6 that matters for the failures, not the tests themselves. So far I've looked at the expm1 stuff, the failures are: Failure: expm1 (0x1.86ap+16): Exception "Overflow" not set Failure: expm1 (0x2.c5c4p+12): Exception "Overflow" not set Failure: expm1 (0xf.ffffffffffff8p+1020): Exception "Overflow" not set Failure: expm1 (0xf.fffffp+124): Exception "Overflow" not set Failure: expm1_downward (0x1.86ap+16): Exception "Overflow" not set Failure: Test: expm1_downward (0x1.86ap+16) Result: is: inf inf should be: 1.7976931348623157e+308 0x1.fffffffffffffp+1023 Failure: expm1_downward (0x2.c5c4p+12): Exception "Overflow" not set Failure: Test: expm1_downward (0x2.c5c4p+12) Result: is: inf inf should be: 1.7976931348623157e+308 0x1.fffffffffffffp+1023 ... Failure: expm1_upward (0x1.86ap+16): Exception "Overflow" not set Failure: expm1_upward (0x2.c5c4p+12): Exception "Overflow" not set Failure: expm1_upward (0xf.ffffffffffff8p+1020): Exception "Overflow" not s= et Failure: expm1_upward (0xf.fffffp+124): Exception "Overflow" not set For all the arguments >=3D 710.0 or so (non-inf/nan), the path in the sourc= e is: static const double huge =3D 1.0e+300, tiny =3D 1.0e-300, o_threshold =3D 7.09782712893383973096e+02; /* 0x40862E42, 0xFEFA39EF */ ... if (x > o_threshold) { __set_errno (ERANGE); return huge * huge; /* overflow */ } and the file is compiled with -frounding-math. So the reduced testcase for at least part of this PR is: double foo (void) { const double huge =3D 1.0e+300; return huge * huge; } GCC 12 would compile this into return __builtin_inf (); only with -fno-trapping-math, not without it nor with -frounding-math. Now, GCC trunk compiles this into return __builtin_inf (); with all of -fno-trapping-math, default or -frounding-math. For the default case, the problem is the same as in=20 PR107608. But with -frounding-math, we have an extra problem with the valu= e, which actually shouldn't be +INF but DBL_MAX. E.g. #include #include int main () { volatile double huge =3D 1.0e+308; volatile double inf =3D __builtin_inf (); fesetround (FE_DOWNWARD); volatile double r1 =3D huge + huge; volatile double r2 =3D huge * huge; volatile double r3 =3D huge + inf; volatile double r4 =3D r2 + huge; volatile double r5 =3D inf - 1.0; volatile double r6 =3D inf - huge; fesetround (FE_TONEAREST); printf ("%e %e %e %e %e %e\n", r1, r2, r3, r4, r5, r6); } prints 1.797693e+308 1.797693e+308 inf 1.797693e+308 inf inf, so the behavi= or seems to be if either operand is already inf, then the result should be inf even when rounding to -inf (except special cases when it is nan), but if neither operand is inf, when rounding downward it shouldn't be +inf but max representable (or when rounding upward not -inf but min representable). So I assume we should tweak frange_arithmetics for this behavior when flag_rounding_math.=