On 26/05/20 07:11 -0300, Alexandre Oliva wrote:
On May 9, 2020, Jonathan Wakely wrote:
Also approved for gcc-10 branch if the target maintainers are OK with
it. It's an ABI change (allocations aligned to alignof(max_align_t)
will store the token in the allocation after this change) but the
he
On May 9, 2020, Jonathan Wakely wrote:
> Also approved for gcc-10 branch if the target maintainers are OK with
> it. It's an ABI change (allocations aligned to alignof(max_align_t)
> will store the token in the allocation after this change) but the
> header is an experimental TS feature so not g
On 13/05/20 04:49 -0300, Alexandre Oliva wrote:
Hello, Jonathan,
On May 9, 2020, Jonathan Wakely wrote:
On 08/05/20 17:22 -0300, Alexandre Oliva wrote:
(Couldn't r1->allocate(2, alignof(char)) possibly return a pointer
that's *not* aligned? Maybe we should drop the test even
if !defined(
Hello, Jonathan,
On May 9, 2020, Jonathan Wakely wrote:
> On 08/05/20 17:22 -0300, Alexandre Oliva wrote:
>> (Couldn't r1->allocate(2, alignof(char)) possibly return a pointer
>> that's *not* aligned? Maybe we should drop the test even
>> if !defined(BAD_MAX_ALIGN_T).)
> Yes.
> Different ma
On 08/05/20 17:22 -0300, Alexandre Oliva wrote:
Vxworks 7's malloc, like Solaris', only ensures 8-byte alignment of
returned pointers on 32-bit x86, though GCC's stddef.h defines
max_align_t with 16-byte alignment for __float128. This patch enables
on x86-vxworks the same memory_resource workar
