This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Use __builtin_is_constant_evaluated in std::less etc. (PR tree-optimization/88775)


On Mon, Jan 14, 2019 at 9:42 AM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Mon, Jan 14, 2019 at 09:29:03AM +0100, Richard Biener wrote:
> > So why is this not just
> >
> >   return (__UINTPTR_TYPE__)__x > (__UINTPTR_TYPE__)__y;
> >
> > or with the casts elided?  Does the C++ standard say pointers are
> > to be compared unsigned here?  Or do all targets GCC support
> > lay out the address space in a way that this is correct for pointers
> > into distinct objects?
>
> See PR78420 for details on why it is done that way.

I see.  So the __builtin_is_constant_evaluated thing makes it
"correct" (but then eventually exposing the non-total order issue again).

And if I read the PR correctly we'd really like to be able to write

 if (__builtin_constant_p (<expr>, &result))
   return result;

to make sure whatever undesired-in-the-IL things of <expr>
do not leak there.

Btw, wouldn't sth like

  if (__builtin_is_constant_evaluated())
    {
       union U { __UINTPTR_TYPE__ u; _Tp *p } __ux, __uy;
       __ux.p = __x;
       __uy.p = __y;
       return __ux.u < __uy.u;
    }

be more correct and consistent?  Well, or any other way of
evading that reinterpret-cast "issue"?

Richard.


>
>         Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]