On Mon, Jan 14, 2019 at 10:21 AM Jonathan Wakely <jwakely....@gmail.com> wrote:
>
> On Mon, 14 Jan 2019 at 09:17, Richard Biener <richard.guent...@gmail.com> 
> wrote:
> >
> > On Mon, Jan 14, 2019 at 9:42 AM Jakub Jelinek <ja...@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).
>
> No, because comparing unrelated pointers isn't allowed in constexpr
> contexts, so it just gets rejected at compile time.

I see.

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

Reply via email to