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).
