Re: master make check fails on Solaris 10

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marina Polyakova <m(dot)polyakova(at)postgrespro(dot)ru>
Cc: vitus(at)wagner(dot)pp(dot)ru, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Subject: Re: master make check fails on Solaris 10
Date: 2018-01-18 17:24:44
Message-ID: 7326.1516296284@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Marina Polyakova <m(dot)polyakova(at)postgrespro(dot)ru> writes:
> On 18-01-2018 19:53, Tom Lane wrote:
>> So basically, we're outta luck and we have to consider __int128 as
>> unsupportable on SPARC. I'm inclined to mechanize that as a test on
>> $host_cpu. At least that means we don't need an AC_RUN test ;-)

> %-)) :-)
> Can I do something else about this problem?..

I don't see any other workable alternative. The box we're in as far
as the interaction with MAXALIGN goes is still the same as it was
a month ago: raising MAXALIGN is impractical, and so is allowing
some datatypes to have more-than-MAXALIGN alignment specs.

I suppose you could imagine declaring int128s that are in any sort
of palloc'd storage as, in effect, char[16], and always memcpy'ing
to and from local variables that're declared int128 whenever you
want to do arithmetic with them. But ugh. I can't see taking that
sort of notational and performance hit for just one non-mainstream
architecture.

Really, this is something that the compiler ought to do for us, IMO.
If the gcc guys don't want to be bothered, OK, but that tells you more
about the priority they place on SPARC support than anything else.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-01-18 17:34:35 Re: master make check fails on Solaris 10
Previous Message Robert Haas 2018-01-18 17:22:59 Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)