Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ebEOE-0008SS-Ak for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Jan 2018 23:42:06 +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 1ebEOD-0004XI-5l for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Jan 2018 23:42:05 +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 1ebEOC-0004X8-Vb for pgsql-hackers@lists.postgresql.org; Mon, 15 Jan 2018 23:42:05 +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 1ebEO9-000850-Ud for pgsql-hackers@postgresql.org; Mon, 15 Jan 2018 23:42:04 +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 w0FNfpw3018210; Mon, 15 Jan 2018 18:41:51 -0500 From: Tom Lane To: Marina Polyakova cc: Andres Freund , pgsql-hackers@postgresql.org, Alvaro Herrera Subject: Re: master make check fails on Solaris 10 In-reply-to: References: <0d3a9fa264cebe1cb9966f37b7c06e86@postgrespro.ru> <20180111173938.jimybeayp2u5mmup@alap3.anarazel.de> <31a342fa6a025a8bdfc5b8b19c29d56d@postgrespro.ru> <1232.1515780057@sss.pgh.pa.us> <15299.1515867055@sss.pgh.pa.us> Comments: In-reply-to Marina Polyakova message dated "Mon, 15 Jan 2018 15:07:01 +0300" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <18167.1516059660.0@sss.pgh.pa.us> Date: Mon, 15 Jan 2018 18:41:51 -0500 Message-ID: <18209.1516059711@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18167.1516059660.1@sss.pgh.pa.us> Marina Polyakova writes: > On 13-01-2018 21:10, Tom Lane wrote: >> I'm not sure there's much we can do about this. Dropping the use >> of the alignment spec isn't a workable option. If there were a >> simple way for configure to detect that the compiler generates bad >> code for that, we could have it do so and reject use of __int128, >> but it'd be up to you to come up with a workable test. > I'll think about it.. Attached is a possible test program. I can confirm it passes on a machine with working __int128, but I have no idea whether it will detect the problem on yours. If not, maybe you can tweak it? regards, tom lane ------- =_aaaaaaaaaa0 Content-Type: text/x-c; name="int128test.c"; charset="us-ascii" Content-ID: <18167.1516059660.2@sss.pgh.pa.us> Content-Description: int128test.c #include #include /* GCC, Sunpro and XLC support aligned */ #if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__IBMC__) #define pg_attribute_aligned(a) __attribute__((aligned(a))) #endif typedef __int128 int128a #if defined(pg_attribute_aligned) pg_attribute_aligned(8) #endif ; /* * These are globals to discourage the compiler from folding all the * arithmetic tests down to compile-time constants. We do not have * convenient support for 128bit literals at this point... */ struct glob128 { __int128 start; char pad; int128a a; int128a b; int128a c; int128a d; } g = {0, 'p', 48828125, 97656255, 0, 0}; int main() { if (offsetof(struct glob128, a) < 17 || offsetof(struct glob128, a) > 24) { printf("wrong alignment, %d\n", (int) offsetof(struct glob128, a)); return 1; } g.a = (g.a << 12) + 1; /* 200000000001 */ g.b = (g.b << 12) + 5; /* 400000000005 */ /* use the most relevant arithmetic ops */ g.c = g.a * g.b; g.d = (g.c + g.b) / g.b; /* return different values, to prevent optimizations */ if (g.d != g.a + 1) { printf("wrong arithmetic result\n"); return 1; } printf("A-OK!\n"); return 0; } ------- =_aaaaaaaaaa0--