On Wed, 27 Aug 2025, Jonathan Wakely wrote:

> On Wed, 27 Aug 2025 at 11:05, Tomasz Kamiński <tkami...@redhat.com> wrote:
> >
> > For any minimum value of a signed type, its negation (with wraparound) 
> > results
> > in the same value, behaving like zero. Representing the unordered result 
> > with
> > this minimum value, along with 0 for equal, 1 for greater, and -1 for less
> > in partial_ordering, allows its value to be reversed using unary negation.
> >
> > The operator<=(partial_order, 0) now checks if the reversed value is 
> > positive.
> > This works correctly because the unordered value remains unchanged and thus
> > negative.
> >
> > libstdc++-v3/ChangeLog:
> >
> >         * libsupc++/compare (_Ncmp::_Unordered): Rename and change the value
> >         to minimum value of signed char.
> >         (_Ncomp::unordered): Renamed from _Unordered, the name is reserved
> >         by partial_ordered::unordered.
> >         (partial_ordering::_M_reverse()): Define.
> >         (operator<=(partial_ordering, __cmp_cat::__unspec))
> >         (operator>=(__cmp_cat::__unspec, partial_ordering)): Implemented
> >         in terms of negated _M_value.
> >         (operator>=(partial_ordering, __cmp_cat::__unspec))
> >         (operator<=(__cmp_cat::__unspec, partial_ordering)): Directly
> >         compare _M_value, as unordered value is negative.
> >         (partial_ordering::unordered): Handle _Ncmp::unoredred rename.
> > ---
> > Changes in v3:
> > * rename and simplify defintion of _Ncmp::unordered
> 
> Ah yes, we don't need to use an _Ugly name name for unordered.

FWIW it wasn't 100% obvious to me that renaming _Unordered to unordered
is safe here, but it does seem to be, since AFAICT there's no way for a
user to refer to the enumeration __cmp_cat::_Ncmp (e.g. via decltype).

Otherwise it'd potentially be an observable change:

    struct A {
      using enum decltype(some-expr-of-type-__cmp_cat::_Ncmp);
      int unordered; // now errors due to conflict with _Ncmp::unordered
    };

> 
> > * simplify defintion of _M_reverse
> >
> > Testing on x86_64-linux and powerpc64le-linux. OK for trunk when test
> > passes?
> 
> OK for trunk with the pretty printer change included.
> 
> 

Reply via email to