This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: should sync builtins be full optimization barriers?
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Paolo Bonzini <bonzini at gnu dot org>
- Cc: Richard Henderson <rth at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Sat, 24 Sep 2011 11:24:07 +0200
- Subject: Re: should sync builtins be full optimization barriers?
- References: <4E7225AF.3060800@redhat.com> <4E722733.3010003@gnu.org>
On Thu, Sep 15, 2011 at 6:26 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
> On 09/15/2011 06:19 PM, Richard Henderson wrote:
>>
>> I wouldn't go that far. ?They *used* to be compiler barriers,
>> but clearly something broke at some point without anyone noticing.
>> We don't know how many versions are affected until we debug it.
>> For all we know it broke in 4.5 and 4.4 is fine.
>
> 4.4 is not necessarily fine, it may also be that an unrelated 4.5 change
> exposed a latent bug.
>
> But indeed Richard Sandiford mentioned offlist that perhaps
> ALIAS_SET_MEMORY_BARRIER machinery broke. ?Fixing the bug in 4.5/4.6/4.7
> will definitely shed more light.
ALIAS_SET_MEMORY_BARRIER?! Eh, well - that will make TBAA consider
something a memory barrier (I suppose the value of the macro is just zero),
but clearly non-TBAA alias analysis will happily disambiguate things.
An alias-set is certainly not the correct way of making a MEM a memory
barrier.
But well, I might have missed some of GCCs history here and broke things.
Please CC me on the bug that was eventually created.
Richard.
>> There's no reference to a GCC bug report about this in the thread.
>> Did the folks over at the libdispatch project never think to file one?
>
> I asked them to attach a preprocessed testcase somewhere, but they haven't
> done so yet. :(
>
> Paolo
>