From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E711F3858C30; Wed, 8 Mar 2023 09:27:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E711F3858C30 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1678267622; bh=zLw+BBUGhhKNvJsEpcvQ1M0X1b1aMkXarWMcO/tt8p8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aQ7Ounu7go9y6DNavogbfXsTax2bdUmElvvcozTb13jHvvZtnBvLghFz6gN77ShNK 3qRvmdPKH2Lruu4rUC/2o5XTx1uo7Kurrl1I9LNVnlNTyMwcX9bwH82Nybtx9IRLYL VP+8Z3n6NiEmrdo2zFYK4lgF/8RkeIEOpMoSKl6c= From: "aldyh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/109008] [13 Regression] Wrong code in scipy package since r13-3926-gd4c2f1d376da6f Date: Wed, 08 Mar 2023 09:26:55 +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: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: aldyh at gcc dot gnu.org X-Bugzilla-Status: NEW 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: cc 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=3D109008 Aldy Hernandez changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amacleod at redhat dot com --- Comment #26 from Aldy Hernandez --- (In reply to Richard Biener from comment #16) > (In reply to Jakub Jelinek from comment #14) > > Created attachment 54599 [details] > > gcc13-pr109008-wip.patch > >=20 > > I have now this WIP but it doesn't work correctly yet, need to debug it= now, > > just finished writing it and making it compile. > > Note, after the binary search it is still unfinished, I'd like to then > > adjust it one bit at a time to narrow it further. But before working on > > that it needs to work correctly. >=20 > Looks nicer and more precise (even though the iterating function is ugly > and you also suffer from the lack of copying of alternate range state, > but using .union () is a way out here I guess ;)). While working on LTO streaming of ranges, I also noticed that we don't have= a way of accessing the individual NAN sign bits or a way of copying NAN state= .=20 Why don't we get this right instead of hacking around it? Would it help if we provided the following? nan_state_t irange::get_nan_state (); irange::set (tree type, const REAL_VALUE_TYPE &, const REAL_VALUE_TYPE &, c= onst nan_state_t &, value_range_kind =3D VR_RANGE); We could implement nan_state_t to include the m_pos_nan and m_neg_nan for minimal disruption now, and later use it for extending the NAN information (signalling, etc).=