xlc 12.1 miscompiles 32-bit ginCompareItemPointers()

In a 32-bit build, xlc 12.1 for AIX miscompiles three inline expansions of
ginCompareItemPointers(), all in ginget.c (line numbers per commit 9aa6634):

739    Assert(!ItemPointerIsValid(&entry->curItem) ||
740           ginCompareItemPointers(&entry->curItem, &advancePast) <= 0);

847        } while (ginCompareItemPointers(&entry->curItem, &advancePast) <= 0);

915    if (ginCompareItemPointers(&key->curItem, &advancePast) > 0)

For one of the arguments, instead of computing         hi << 32 | lo << 16 | posid
it computes (lo << 16) << 32 | lo << 16 | posid

PostgreSQL 9.4, which introduced the inline ginCompareItemPointers(), is the
oldest version affected.  The problem remained invisible until my recent
commit 43d89a2; the quiet inline "configure" test had been failing, leaving
PG_USE_INLINE unset.

I tried some workarounds.  Introducing intermediate variables or moving parts
of the calculation down into other inline functions did not help.  The code
compiles fine when not inlined.  Changing "hi << 32" to "hi << 33" worked (we
need just 48 of the 64 bits), but it presumably reduces performance on ABIs
where the current bit shifts boil down to a no-op.

I propose to expand the gin_private.h "#ifdef PG_USE_INLINE" test to exclude
xlc 32-bit configurations.  The last 32-bit AIX kernel exited support on
2012-04-30.  There's little reason to prefer 32-bit PostgreSQL under a 64-bit
kernel, so that configuration can do without the latest GIN optimization.  One
alternative would be to distill a configure-time test detecting the bug, so
fixed xlc versions reacquire the optimization.  Another alternative is to
change the bit layout within the uint64; for example, we could use the
most-significant 48 bits instead of the least-significant 48 bits.  I dislike
the idea of a niche configuration driving that choice.

Thanks,
nm