Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eaQGw-0005aj-EF for pgsql-hackers@arkaria.postgresql.org; Sat, 13 Jan 2018 18:11:14 +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 1eaQGv-00024f-N9 for pgsql-hackers@arkaria.postgresql.org; Sat, 13 Jan 2018 18:11:13 +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 1eaQGv-00024U-Gd for pgsql-hackers@lists.postgresql.org; Sat, 13 Jan 2018 18:11:13 +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 1eaQGn-0004Qf-BR for pgsql-hackers@postgresql.org; Sat, 13 Jan 2018 18:11:12 +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 w0DIAt2q015300; Sat, 13 Jan 2018 13:10:55 -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> Comments: In-reply-to Marina Polyakova message dated "Sat, 13 Jan 2018 12:40:33 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15298.1515867055.1@sss.pgh.pa.us> Date: Sat, 13 Jan 2018 13:10:55 -0500 Message-ID: <15299.1515867055@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Marina Polyakova writes: > On 12-01-2018 21:00, Tom Lane wrote: >> Hm ... so apparently, that compiler has bugs in handling nondefault >> alignment specs. You said upthread it was gcc, but what version >> exactly? > This is 5.2.0: Ugh ... protosciurus has 3.4.3, but I see that configure detects that as *not* having __int128. Probably what's happening on your machine is that gcc knows __int128 but generates buggy code for it when an alignment spec is given. So that's unfortunate, but it's not really a regression from 3.4.3. 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. In the end this might just be an instance of the old saw about avoiding dot-zero releases. Have you tried a newer gcc? (Digging in their bugzilla finds quite a number of __int128 bugs fixed in 5.4.x, though none look to be specifically about misaligned data.) Also, if it still happens with current gcc on that hardware, there'd be grounds for a new bug report to them. regards, tom lane