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. I'm quite
in favor of doing what we can to support obscure architectures, but I
think this might be beyond what's reasonable. First of all,
committing untested assembler code to our tree seems like an iffy idea
at best. Secondly, even if someone is running on ARMv5, they'll be
fine as long as they're running a sufficiently new GCC, so we're not
really giving up much by dumping the hand-rolled code for that
platform. The relevant GCC versions are several years old at this
point, and if we rely on them to get it right, that's really probably
a better bet than trying to do this blind.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
