On 07/17/2015 05:03 PM, Richard Biener wrote:
> 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.
Hi Richi.
Should I place the placement new to alloc-pool.c or should I leave it as it is?
Thanks for decision,
Martin
>
>> Thoughts?
>> Martin
>
>
