Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ebpJb-000809-QU for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Jan 2018 15:07:47 +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 1ebpJb-00017u-3g for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Jan 2018 15:07:47 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ebpJa-00017k-Po for pgsql-hackers@lists.postgresql.org; Wed, 17 Jan 2018 15:07:46 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ebpJY-0008TK-OC for pgsql-hackers@postgresql.org; Wed, 17 Jan 2018 15:07: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 w0HF7b37016721; Wed, 17 Jan 2018 10:07:37 -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: <90ab676392c8f9c84431976147097cf0@postgrespro.ru> 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> Comments: In-reply-to Marina Polyakova message dated "Wed, 17 Jan 2018 18:02:26 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16719.1516201657.1@sss.pgh.pa.us> Date: Wed, 17 Jan 2018 10:07:37 -0500 Message-ID: <16720.1516201657@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Marina Polyakova writes: > investigating the regression diffs, we found out that the error occurs > when we pass int128 as not the first argument to the function (perhaps > its value is replaced by the value of some address): > ... > Based on this, we modified the test program (see attached). Here is its > output on Solaris 10 for different alignments requirements for int128 > (on my machine where make check-world passes everything is OK) > (ALIGNOF_PG_INT128_TYPE is 16 on Solaris 10): Excellent. This fails the same way on gcc 5.2.0 and 5.5.0? > Maybe some pass test from int128test2.c can be used to test __int128? Yeah, I can work with this. What I propose to do is use a somewhat stripped-down version of this test as an AC_RUN_IFELSE test normally, but if cross-compiling, fall back to just seeing if we can link. Thanks for investigating! regards, tom lane