On 2013-10-13 14:08:59 +0200, Andres Freund wrote:
> On 2013-10-13 11:34:42 +0200, Tom Lane wrote:
> > Andres Freund <andres@2ndquadrant.com> writes:
> > > I think we should remove support for the following architectures:
> > > - superH
> >
> > This one was contributed just a year or two ago, if memory serves,
> > which suggests that somebody out there cares about it. OTOH, if
> > they still care, we could insist they provide whatever atomic ops
> > we want to depend on.
>
> It was 2009 - aac3c301b5e8178841e5749b3657c1a639ba06c1 . I haven't yet
> verified if gcc's atomics support is acceptable for the platform
> (checkout is running for the last 3h...).
> If it's supported, falling back to that seems easy enough.
Ok, so the git checkout has finally
finished. http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/sh/sync.md;hb=HEAD
makes for an interesting read...
In short: On newer sh variants (SH4) true hardware support is used, on
older ones the linux provides helpers. The variant has to be selected by
gcc parameters unfortunately, but I'd guess that's ok (e.g. SH4
-matomic-model=hard-llcs ).
> > > - PA-RISC. I think Tom was the remaining user there? Maybe just !gcc.
> >
> > Until pretty recently, there was a PA-RISC machine (not mine) in the
> > buildfarm. I don't see it in the list today though. In any case,
> > HP's compiler has always been a PITA, so no objection to requiring gcc
> > for this platform.
>
> The reason I'd like to generally get rid of PA-RISC is that it's the
> only platform that doesn't seem to have any form of compare and
> swap. GCC should provide fallbacks - with some warnings - using
> spinlocks instead
Hm. I had misunderstood the documentation around this a bit - source
code still is the only reasonable documentation :(.
PA-RISC is only supported on linux using kernel helpers (which switch
off interrupts for the duration of the operation...).
> but I am afraid people will start doing things like
> atomic operations in signal handlers that won't be noticed and will be a
> PITA to debug.
That's already a possibility with our memory barriers :(.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
