This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Still crashes due to aliasing violation (Re: [RFC, PATCH] Split pool_allocator and create a new object_allocator)
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: richard dot guenther at gmail dot com (Richard Biener)
- Cc: mliska at suse dot cz, gcc-patches at gcc dot gnu dot org
- Date: Fri, 17 Jul 2015 15:44:23 +0200 (CEST)
- Subject: Re: Still crashes due to aliasing violation (Re: [RFC, PATCH] Split pool_allocator and create a new object_allocator)
- Authentication-results: sourceware.org; auth=none
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
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com