On Mon, Jan 14, 2019 at 10:21 AM Jonathan Wakely wrote:
>
> On Mon, 14 Jan 2019 at 09:17, Richard Biener
> wrote:
> >
> > On Mon, Jan 14, 2019 at 9:42 AM Jakub Jelinek wrote:
> > >
> > > On Mon, Jan 14, 2019 at 09:29:03AM +0100, Richard Biener wrote:
> > > > So why is this not just
> > > >
> >
On Mon, 14 Jan 2019 at 09:17, Richard Biener wrote:
>
> On Mon, Jan 14, 2019 at 9:42 AM Jakub Jelinek 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
On Mon, 14 Jan 2019 at 09:17, Richard Biener wrote:
>
> On Mon, Jan 14, 2019 at 9:42 AM Jakub Jelinek 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
On Mon, 14 Jan 2019 at 08:29, Richard Biener wrote:
>
> On Thu, Jan 10, 2019 at 10:02 AM Jakub Jelinek wrote:
> >
> > Hi!
> >
> > In Marc's testcase, we generate terrible code for std::string assignment,
> > because the __builtin_constant_p is kept in the IL for way too long and the
> >
On Mon, Jan 14, 2019 at 9:42 AM Jakub Jelinek 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
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
On Mon, 14 Jan 2019 at 10:29, Richard Biener wrote:
> >_GLIBCXX14_CONSTEXPR bool
> >operator()(_Tp* __x, _Tp* __y) const _GLIBCXX_NOTHROW
> >{
> > +#if __cplusplus >= 201402L
> > +#ifdef _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED
> > + if
On Thu, Jan 10, 2019 at 10:02 AM Jakub Jelinek wrote:
>
> Hi!
>
> In Marc's testcase, we generate terrible code for std::string assignment,
> because the __builtin_constant_p is kept in the IL for way too long and the
> optimizers (jump threading?) create way too many copies of the
>
On 10/01/19 10:02 +0100, Jakub Jelinek wrote:
Hi!
In Marc's testcase, we generate terrible code for std::string assignment,
because the __builtin_constant_p is kept in the IL for way too long and the
optimizers (jump threading?) create way too many copies of the
memcpy/memmove calls that it is
Hi!
In Marc's testcase, we generate terrible code for std::string assignment,
because the __builtin_constant_p is kept in the IL for way too long and the
optimizers (jump threading?) create way too many copies of the
memcpy/memmove calls that it is then hard to bring it back in sanitity.
On the
10 matches
Mail list logo
