Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ecE5O-0006Ch-Rd for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jan 2018 17:34:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ecE5O-00083O-Ch for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jan 2018 17:34:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ecE5O-00083E-65 for pgsql-hackers@lists.postgresql.org; Thu, 18 Jan 2018 17:34:46 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ecE5L-0001vu-0H for pgsql-hackers@postgresql.org; Thu, 18 Jan 2018 17:34:45 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w0IHYZ6e007810; Thu, 18 Jan 2018 12:34:35 -0500 From: Tom Lane To: Marina Polyakova cc: vitus@wagner.pp.ru, Andres Freund , pgsql-hackers@postgresql.org, Alvaro Herrera Subject: Re: master make check fails on Solaris 10 In-reply-to: <7326.1516296284@sss.pgh.pa.us> References: <0d3a9fa264cebe1cb9966f37b7c06e86@postgrespro.ru> <20180111173938.jimybeayp2u5mmup@alap3.anarazel.de> <31a342fa6a025a8bdfc5b8b19c29d56d@postgrespro.ru> <1232.1515780057@sss.pgh.pa.us> <15299.1515867055@sss.pgh.pa.us> <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> <5487.1516294381@sss.pgh.pa.us> <99cd20828c6c38c22ff8a08cbd294982@postgrespro.ru> <7326.1516296284@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Thu, 18 Jan 2018 12:24:44 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7808.1516296875.1@sss.pgh.pa.us> Date: Thu, 18 Jan 2018 12:34:35 -0500 Message-ID: <7809.1516296875@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I wrote: > Marina Polyakova 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. But ... let's not panic, but wait and see the final result of the discussion on the gcc PR. Jakub at least seems to think it ought to be a supportable case. What you could do in the meantime is work on finding a variation of Victor's test that will detect the bug regardless of -O level. If we do have hope that future gcc versions will handle this correctly, we'll need a better test rather than just summarily dismissing host_cpu = sparc. regards, tom lane