On 06/11/2015 08:19 PM, Richard Biener wrote: > On June 11, 2015 7:50:36 PM GMT+02:00, Jakub Jelinek <ja...@redhat.com> wrote: >> On Fri, Jun 12, 2015 at 12:58:12AM +0800, pins...@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); Martin > >> Jakub > >
