[Bug tree-optimization/109008] [13 Regression] Wrong code in scipy package since r13-3926-gd4c2f1d376da6f

["aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com

--- Comment #26 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #16)
> (In reply to Jakub Jelinek from comment #14)
> > Created attachment 54599 [details]
> > gcc13-pr109008-wip.patch
> > 
> > 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.
> 
> 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. 
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 &, const
nan_state_t &, value_range_kind = 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).