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