From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D72823858C74; Fri, 27 Jan 2023 11:30:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D72823858C74 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1674819026; bh=/h2sNcWZVbjgvYK4fQyZ1W8lQ31RRTubytfmb4VJjHw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EX/jcZ/pmiFwUt6eSsRO/xyOqvrhqpaqegjLerWvK3niw5xORUlc1ByWR35iAilxq DEDtfu6ZzDkWwSjakoOTpbX/cslqjwjBruuBqY/8IE/KS9gGXMrzaZmJHXTTUws8t/ SvLJDqi43bgPwDY2RdSclGzaBtdJr57gqB/Q+TlU= From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c Date: Fri, 27 Jan 2023 11:30:26 +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: missed-optimization, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P1 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=3D107608 --- Comment #50 from rguenther at suse dot de --- On Fri, 27 Jan 2023, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107608 >=20 > --- Comment #49 from Jakub Jelinek --- > (In reply to rguenther@suse.de from comment #47) > > > Glibc already changed the code from Inf/Inf to (x - x) / (x - x) wher= e x=20 >=20 > (x - x) / (x - x) is 0 / 0, not Inf / Inf. > Anyway, for frange potential in GCC 14, I'd hope we do figure out that > x - x has [0, 0] range (never -0.0 even, unless -frounding-math where it = could > be -0.0 when rounding to -Inf) provided x is known to be finite - > all of Inf - Inf, (-Inf) - (-Inf) and NaN - NaN are NaN. > And frange already has an infrastructure for that, foperator_minus::rv_fo= ld is > passed relation_kind between op1 and op2, so if it is VREL_EQ and we can = check > that Inf or NaN isn't possible in the range, we should yield [0, 0]. > Or for -ffast-math do it always and yield [-0., 0] as Inf/NaN aren't expe= cted > but signed zeros are present but are insignificant. > Shall we file a PR for that? >=20 > > > is not a constant, but I'm wandering if the compiler will attempt to= =20 > > > optimize out (x - x) / (x - x) later... Is it possible to provide a= =20 > > > "__builtin_feraiseexcept" so we'd be able to use it instead of the na= sty=20 > > > (x - x) / (x - x) to raise the exception? > >=20 > > Not trivially. I'd suggest glibc uses a volatile use, like for example > >=20 > > tem =3D Inf/Inf; > > __asm__ volatile ("" : : "g" (tem)); >=20 > In this case I guess that is at least right now fine (and glibc I think e= ven > has a macro for that, some math_*). The thing is that the result is NaN = and we > don't treat NaN as singleton (because there are many representations of N= aN). > Similarly the workaround for fold-overflow-1.c added in this PR will not = treat > for now > operations from finite operands yielding singleton Inf or -Inf as singlet= on. > But if it is something else, say finite + finite and the expectation is t= hat > inexact is raised, then the above wouldn't help, because we'd just turn i= t into > "g" (constant) > in the asm. For inexact yes, but we do refrain from constant folding when that loses exceptions (in some cases at least), not just when it produces a NaN.=