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

[Jonathan Wakely]

On 13/08/18 13:04 +0100, Jonathan Wakely wrote:
>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).

I've committed this to trunk and will do so on the branches too.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 1001 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20180814/926bcdfa/attachment.bin>