From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Oskari Saarenmaa <os(at)ohmu(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: __attribute__ for non-gcc compilers |
Date: | 2015-01-14 22:54:52 |
Message-ID: | 20150114225452.GC15053@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-01-14 22:59:19 | Re: s_lock.h default definitions are rather confused |
Previous Message | Robert Haas | 2015-01-14 22:46:39 | Re: __attribute__ for non-gcc compilers |