Re: New type-based pool allocator code miscompiled due to aliasing issue?

[Andrew Pinski <pinskia at gmail dot com>]

On Mon, Jun 15, 2015 at 2:09 AM, Martin LiÅka <mliska@suse.cz> wrote:
> On 06/11/2015 08:19 PM, Richard Biener wrote:
>> On June 11, 2015 7:50:36 PM GMT+02:00, Jakub Jelinek <jakub@redhat.com> wrote:
>>> On Fri, Jun 12, 2015 at 12:58:12AM +0800, pinskia@gmail.com wrote:
>>>> This is just a bug in the older compiler. There was a change to fix
>>> in
>>>> placement new operator.  I can't find the reference right now but
>>> this is
>>>> the same issue as that.
>>>
>>> I'm not claiming 4.1 is aliasing bug free, there are various known
>>> issues in
>>> it.  But, is that the case here?
>>>
>>>  empty_var = onepart_pool (onepart).allocate ();
>>>  empty_var->dv = dv;
>>>  empty_var->refcount = 1;
>>>  empty_var->n_var_parts = 0;
>>>
>>> doesn't really seem to use operator new at all, so I'd say the bug is
>>> in
>>> all the spots that call allocate () method of the pool, but don't
>>> really
>>> use operator new.
>>
>> Yeah.  BTW, I see the same issue on x86_64 and on ia64 with a gcc 4.1 host compiler.  I think allocate itself should use placement new, not just a static pointer conversion.
>>
>> Richard.
>
> Hi.
>
> What do you mean by calling placement new? Currently pool_allocator<T>::allocate calls placement new as a last statement in the function:
>
>   return (T *)(header);

That is only a cast and not a placement new.
Try this instead:
  return new(header) T();

Thanks,
Andrew

>
> Martin
>
>>
>>>      Jakub
>>
>>
>