On 07/17/2015 03:44 PM, Ulrich Weigand wrote:
> Richard Biener wrote:
>> On July 17, 2015 3:11:51 PM GMT+02:00, Ulrich Weigand <uweig...@de.ibm.com>
>> wrote:
>>> (Since there is no C++ operator new involved at all anymore,
>>> this clearly violates even the C aliasing rules ...)
>>>
>>> I really think the allocate routine needs to be more careful to
>>> avoid violating aliasing, e.g. by using memcpy or union-based
>>> type-punning to access its free list info.
>>
>> As far as I understand the object allocator delegates construction to
>> callers and thus in the above case cselib
>> Would be responsible for calling placement new on the return value from
>> Allocate.
>
> Ah, it looks like I was wrong above: the code uses the *object*
> allocator, so it should go through a placement new here:
> inline T *
> allocate () ATTRIBUTE_MALLOC
> {
> return ::new (m_allocator.allocate ()) T ();
> }
>
> It's still being miscompiled at least by my GCC 4.1 host compiler ...
>
> Bye,
> Ulrich
>
Hi.
I've just wanted to write you that it really utilizes a placement new :)
The first example that bypasses pool allocator is of course a bug, I'll fix.
Question is why aliasing oracle still wrongly aliases these pointers?
Another option (suggested by Martin Jambor) would be to place ::allocate
implementation
to alloc-pool.c file.
Thoughts?
Martin
