On July 17, 2015 3:50:19 PM GMT+02:00, "Martin Liška" <mli...@suse.cz> wrote:
>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.
Note that all compilers up to 4.4 have aliasing issues with placement new.
A fix is to move the placement new out-of-line.
Richard.
>Thoughts?
>Martin
