This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Adjust omp-low test for alignment
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Richard Henderson <rth at twiddle dot net>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 2 Dec 2011 08:12:31 -0500 (EST)
- Subject: Re: Adjust omp-low test for alignment
- References: <4ED17EB4.4070807@twiddle.net> <alpine.BSF.2.00.1111282343070.66213@dair.pair.com> <4ED529B1.8060406@redhat.com> <alpine.BSF.2.00.1111291557020.92717@dair.pair.com>
On Tue, 29 Nov 2011, Hans-Peter Nilsson wrote:
> 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"?
Oh, on second reading I see you probably mean I have to make
sure the atomic types are aligned in the library, by e.g.
attaching __attribute__ ((__aligned__)). Sure: the reply to
this change in the gut of gcc is however more important to make
sure it's not cast in stone and copied to other places that I'll
only find the hard way. BTW, on the topic, I cringe whenever I
see futexes expressed as plain "int", they absolutely have to
have at least natural alignment which is not always true e.g. in
structs. People, please keep the atomic types
target-overridable in libraries.
> > > 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
>