Re: Still crashes due to aliasing violation (Re: [RFC, PATCH] Split pool_allocator and create a new object_allocator)

[Martin LiÅka <mliska at suse dot cz>]

On 07/17/2015 05:03 PM, Richard Biener wrote:
> On July 17, 2015 3:50:19 PM GMT+02:00, "Martin LiÅka" <mliska@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
>> <uweigand@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
> 
>