Andres Freund <and...@anarazel.de> writes:
> On December 30, 2016 4:48:22 PM GMT+01:00, Tom Lane <t...@sss.pgh.pa.us>
> wrote:
>> and got no warnings and the attached output. I'm not very good at
>> reading PPC assembler, but I think what is happening in the "char" case is
>> that
>> gcc is trying to emulate a byte-wide operation using a word-wide one,
>> ie an lwarx/stwcx. loop.
> Hm. This seems to suggest a straight out code generation bug in that
> compiler, not a failure in intrinsic detection.
It does smell like a codegen bug; I'm planning to file a FreeBSD bug
report once I have more data (like whether 11.0 is busted similarly).
But that doesn't really detract from my point, which is that it's
totally silly for us to imagine that char and word-wide atomic ops are
interchangeable on all platforms and we can flip a coin to decide which
to use as long as the configure probes don't fail outright. Even given
working code for the byte case, we ought to prefer int atomics on PPC.
On other platforms, maybe the preference goes the other way. I'd be
inclined to follow the hard-won knowledge embedded in s_lock.h about
which to prefer.
Or in words of one syllable: this isn't the first bug we've seen in
compiler intrinsics, and it won't be the last. We need a way to deal
with that, not just claim it isn't our problem.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
