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