On Thu, Sep 15, 2011 at 6:26 PM, Paolo Bonzini <bonz...@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 >
