On Tue, 29 Nov 2011, Richard Henderson wrote: > On 11/28/2011 08:49 PM, Hans-Peter Nilsson wrote: > > On Sat, 26 Nov 2011, Richard Henderson wrote: > >> The m68k-linux failure for the various omp atomic tests > >> is due to the fact that BIGGEST_ALIGNMENT is 16 bits on > >> that platform. I think it's pretty reasonable to assume > >> that if something is aligned to BIGGEST_ALIGNEMENT, then > >> it can be considered "aligned". > > > > BIGGEST_ALIGNMENT means aligned enough for normal access, but > > not necessarily for atomic access. > > If that's true,
It's what that macro meant up until gcc started to be atomicity-aware at this level, as implied by "when violated, may cause a fault". Changing it to higher makes gcc do all stupid things when accessing structure members with lower alignment so I can't do that, it violates the byte-aligment ABI. > then you'll have problems applying any of these > functions without additional source-code level alignment, everywhere. There has to be a type that matches the (let's call it) ATOMIC_ALIGNMENT yes, is that what you mean by "any of these functions"? > > Not that OMP support is imminent or critical for cris-linux or > > anything, but can we have a new macro? > > I'm not sure what you're suggesting that the macro actually do. Tell proper aligmnent for atomic access, defaulting to (say) natural aligmnent. brgds, H-P
