On Mon, Jun 15, 2015 at 2:09 AM, Martin Liška <mli...@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 <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);
That is only a cast and not a placement new. Try this instead: return new(header) T(); Thanks, Andrew > > Martin > >> >>> Jakub >> >> >
