pg.ddx.io pgsql-hackers@postgresql.org mailing list archive help / color / mirror / Atom feed From: Marina Polyakova <m.polyakova@postgrespro.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: vitus@wagner.pp.ru, Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
Subject: Re: master make check fails on Solaris 10
Date: Thu, 18 Jan 2018 20:41:37 +0300
Message-ID: <544da33df0355abfb6c19aa678201dab@postgrespro.ru> (raw )
In-Reply-To: <7326.1516296284@sss.pgh.pa.us >
References: <0d3a9fa264cebe1cb9966f37b7c06e86@postgrespro.ru >
<20180111173938.jimybeayp2u5mmup@alap3.anarazel.de >
<31a342fa6a025a8bdfc5b8b19c29d56d@postgrespro.ru >
<fc3c1b52d2d4121cccfc13635005bbd0@postgrespro.ru >
<1232.1515780057@sss.pgh.pa.us >
<b946893927ccfd87146d8a7c9f3bbe29@postgrespro.ru >
<15299.1515867055@sss.pgh.pa.us >
<a5559105243efcf6fb619d86c5702115@postgrespro.ru >
<18209.1516059711@sss.pgh.pa.us >
<90ab676392c8f9c84431976147097cf0@postgrespro.ru >
<17897.1516202926@sss.pgh.pa.us >
<1c70bab595a37ffa3a7fafea29fa6f55@postgrespro.ru >
<31743.1516206789@sss.pgh.pa.us >
<0e183c12a68af526ebc03c5c26206c44@postgrespro.ru >
<16822.1516287408@sss.pgh.pa.us >
<c737e36bb5eee1fa1c0f24dc33ba9e2e@postgrespro.ru >
<5487.1516294381@sss.pgh.pa.us >
<99cd20828c6c38c22ff8a08cbd294982@postgrespro.ru >
<7326.1516296284@sss.pgh.pa.us >
On 18-01-2018 20:24, Tom Lane wrote:
> Marina Polyakova <m.polyakova@postgrespro.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.
Thank you very much for your explanations!
So I'll go to all of your comments to my patch about stable functions
when the next work day begins in Moscow)
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
view thread (46+ messages) latest in thread
Message-ID: <544da33df0355abfb6c19aa678201dab@postgrespro.ru>
Permalink: ../544da33df0355abfb6c19aa678201dab@postgrespro.ru/
Also on: postgresql.org/message-id/544da33df0355abfb6c19aa678201dab@postgrespro.ru
copy link · copy postgr.es
reply Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: m.polyakova@postgrespro.ru, tgl@sss.pgh.pa.us, andres@anarazel.de, alvherre@alvh.no-ip.org
Subject: Re: master make check fails on Solaris 10
In-Reply-To: <544da33df0355abfb6c19aa678201dab@postgrespro.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox