From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 304413858D20; Thu, 10 Nov 2022 11:34:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 304413858D20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1668080048; bh=oKTKtkU4dGghiBfcQlmGNjIdohCHiPUwOhaR7QsF0H0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=xmslFj5lUaTrSwjYOu9lWL3/ih5woINB334AjHXdlPhdgOzhhGxX9mxb2VlpMhUFQ btzG+yg/sobNQMqEmHMKYrxqGlofvXKNX3rjBCflSm0uDlh4BF6g9iBmELqIv89XXR 8QFwan8rDRHLkP/hxDUAymmAbVCNi+GNAocsqtOI= From: "aldyh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596 Date: Thu, 10 Nov 2022 11:34:07 +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 X-Bugzilla-Severity: normal X-Bugzilla-Who: aldyh at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: 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=3D107569 --- Comment #24 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #22) > Folding statement: _2 =3D __builtin_pow (1.0e+1, _1); > Global Exported: _2 =3D [frange] double [0.0 (0x0.0p+0), +Inf] +NAN > The +NAN looks suspicious, shouldn't that be +-NAN ? > Of course once we handle POW builtins, if we are smart enough we should s= ee > that it is 10.0 ** [INT_MIN, -1] and so [0.0, 1.0e-1] (plus some larger u= lp > error because library functions aren't exactly 0.5ulp precise all the tim= e). > But when we don't know what __builtin_pow does (from frange perspective),= I > don't see what > tells us that NAN with negative sign can't appear. Yeah, that +NAN looks very suspicious. For that matter, it took me a while= to figure out how we know that _2 can't be negative, because we don't have any range-op entries for __builtin_pow. So...here's a trick to figure this out: --param=3Dranger-debug=3Dtracegori You'll see in the *evrp dump: Folding statement: _2 =3D __builtin_pow (1.0e+1, _1); 45 range_of_stmt (_2) at stmt _2 =3D __builtin_pow (1.0e+1, _1); TRUE : (45) range_of_stmt (_2) [frange] double [0.0 (0x0.0p+0), +I= nf] +NAN 46 range_of_expr(_1) at stmt _2 =3D __builtin_pow (1.0e+1, _1); TRUE : (46) range_of_expr (_1) [frange] double VARYING +-NAN 47 range_of_stmt (_2) at stmt _2 =3D __builtin_pow (1.0e+1, _1); TRUE : (47) cached (_2) [frange] double [0.0 (0x0.0p+0), +Inf] +N= AN Global Exported: _2 =3D [frange] double [0.0 (0x0.0p+0), +Inf] +NAN So ranger was able to figure out immediately that _2 was positive. Andrew added smarts to break into any given place, so we can break where the counter is 45: (gdb) break breakpoint if index =3D=3D 45 Yes, amazingly there's only one function named breakpoint() in the entire compiler ;-). If you single step from there on, we run into: if (gimple_stmt_nonnegative_warnv_p (call, &strict_overflow_p)) r.set_nonnegative (type); else if (gimple_call_nonnull_result_p (call) || gimple_call_nonnull_arg (call)) r.set_nonzero (type); else r.set_varying (type); IIRC, we had some discussion upstream about the meaning of set_nonnegative,= and we all agreed that nuking -NAN was the right thing. Neat, huh? :)=