Re: __attribute__ for non-gcc compilers

On 2015-01-14 17:46:39 -0500, Robert Haas wrote:
> On Wed, Jan 14, 2015 at 5:29 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > I think it's better than the alternatives:
> >
> > a) Don't support 64bit atomics on any 32bit platform. I think that'd be
> > sad because there's some places that could greatly benefit from being
> > able to read/store/manipulate e.g. LSNs atomically.
> > b) Double the size of 64bit atomics on 32bit platforms, and add
> > TYPEALIGN() to every access inside the atomics implementation.
> > c) Require 64 atomics to be aligned appropriately manually in every
> > place they're embedded. I think that's completely impractical.
> >
> > The only viable one imo is a)
>
> I can't really fault that reasoning, but if __attribute__((align))
> only works on some platforms, then you've got silent, subtle breakage
> on the ones where it doesn't.

The __attribute__((align()))'s are in compiler specific code sections
anyway - and there's asserts ensuring that the alignment is correct in
all routines where it matters (IIRC). Those are what caught the
problem. C.f.
http://archives.postgresql.org/message-id/20150108204635.GK6299%40alap3.anarazel.de

I think I'd for now simply not define pg_attribute_aligned() on
platforms where it's not supported, instead of defining it empty. If we
need a softer variant we can name it pg_attribute_aligned_if_possible or
something.

Sounds sane?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services