This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: New type-based pool allocator code miscompiled due to aliasing issue?
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>,pinskia at gmail dot com
- Cc: Ulrich Weigand <uweigand at de dot ibm dot com>,"gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>,"mliska at suse dot cz" <mliska at suse dot cz>,"law at redhat dot com" <law at redhat dot com>
- Date: Thu, 11 Jun 2015 20:19:12 +0200
- Subject: Re: New type-based pool allocator code miscompiled due to aliasing issue?
- Authentication-results: sourceware.org; auth=none
- References: <20150611165115 dot E278EEDC at oc7340732750 dot ibm dot com> <60B0A9AA-8E0A-4538-8950-46224E08F1EA at gmail dot com> <20150611175036 dot GJ10247 at tucnak dot redhat dot com>
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.
> Jakub