Re: [PATCH] libstdc++-v3: Have aligned_alloc() on Newlib

[Jonathan Wakely <jwakely at redhat dot com>]

On 13/08/18 12:55 +0100, Szabolcs Nagy wrote:
> On 09/08/18 10:08, Jonathan Wakely wrote:
> > On 09/08/18 06:56 +0200, Sebastian Huber wrote:
> > > On 08/08/18 16:33, Jonathan Wakely wrote:
> > > > On 08/08/18 16:22 +0200, Ulrich Weigand wrote:
> > > > > Jonathan Wakely wrote:
> > > > >
> > > > > > Aha, so newlib was using memalign previously:
> > > > > >
> > > > > > @@ -53,20 +54,24 @@ aligned_alloc (std::size_t al, std::size_t sz)
> > > > > >  #else
> > > > > >  extern "C" void *memalign(std::size_t boundary, std::size_t size);
> > > > > >  #endif
> > > > > > -#define aligned_alloc memalign
> > > > >
> > > > > Yes, exactly ... this commit introduced the regression.
> > > > >
> > > > > > OK, I've regressed the branches then - I'll fix that.
> > > >
> > > > This should fix it. I'll finish testing and commit it.
> > > >
> > > > Sebastian, your patch to define HAVE_ALIGNED_ALLOC is OK for
> > > > gcc-7-branch and gcc-8-branch, because changing newlib from using
> > > > memalign to aligned_alloc is safe.
> > >
> > > Should I check in my patch in addition to your patch?
> >
> > Yes please, on trunk and 7 and 8. It's better to use the standard
> > aligned_alloc if available.
>
> but the newlib aligned_alloc is broken on baremetal targets,
> it is implemented using posix_memalign which is not provided
> by the newlib malloc implementation (except on cygwin)

Ouch, OK, let's revert it. Using memalign is fine.

The original problem that I think Sebastian was trying to solve should
be fixed by r263409 anyway (and was backported to all branches).