On 2014-06-30 22:44:58 -0400, Robert Haas wrote:
> On Mon, Jun 30, 2014 at 6:28 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > On 2014-06-30 19:22:59 +0200, Andres Freund wrote:
> >> On 2014-06-30 12:46:29 -0400, Robert Haas wrote:
> >> >, which if I understand you correctly are ARM without GCC
> >> > atomics, Sparc, and MIPS.
> >>
> >> I've to revise my statement on MIPS, it actually looks safe. I seem to
> >> have missed that it has its own S_UNLOCK.
> >
> > So, here's my first blind attempt at fixing these. Too tired to think
> > much more about it. Sparc's configurable cache coherency drives me
> > nuts. Linux apparently switched somewhere in 2011 from RMO (relaxed
> > memory order) to TSO (total store order), solaris always used TSO, but
> > the BSDs don't. Man.
> >
> > Accordingly there's a somewhat ugly thingy attached. I don't think this
> > is really ready, but it's what I can come up today.
>
> You know, looking at this, I wonder if we shouldn't just remove
> support for ARMv5 instead of making a blind stab at a fix.
Well, I argued that way for a while ;). We don't even need to really
desupport it, but just say it's not supported for gcc < 4.4.
On the other hand, the swpb release thing isn't too complicated and just
the inverse of existing code.
> I'm quite
> in favor of doing what we can to support obscure architectures, but I
> think this might be beyond what's reasonable.
Yea, I felt like I was going mad doing it. Perhaps I should have
stopped.
> Since we have a Sun Studio machine in the buildfarm, we shouldn't give
> up on SPARC completely, but maybe we should only add the cases for
> sparcv8+ and above? That at least has some chance of getting tested.
That we have code for sparcv7 is ridiculous btw. Sparcv8 (not 8+/9) is
from 1992. v7/sun4c been dropped from solaris 8 if I see that correctly.
I agree that v8 (in contrast to v8+ aka v9 in 32bit mode) support has to
go as well. I'd personally vote for backpatching a note to
installation.sgml saying that it's probably not working, and not do
anything else there. That means we also should replace the ldstub by cas
in the the gcc inline assembly - but we have buildfarm members for that,
so it's not too bad.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
