Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ecDRC-0002Og-QM for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jan 2018 16:53: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 1ecDRC-0008Pr-1d for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jan 2018 16:53:14 +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 1ecDRB-0008Ph-RM for pgsql-hackers@lists.postgresql.org; Thu, 18 Jan 2018 16:53: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 1ecDR8-0000up-2M for pgsql-hackers@postgresql.org; Thu, 18 Jan 2018 16:53:13 +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 w0IGr1j0005488; Thu, 18 Jan 2018 11:53:01 -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: 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> Comments: In-reply-to Marina Polyakova message dated "Thu, 18 Jan 2018 19:42:26 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5486.1516294381.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jan 2018 11:53:01 -0500 Message-ID: <5487.1516294381@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Marina Polyakova writes: > On 18-01-2018 17:56, Tom Lane wrote: >> Weird. Maybe the gcc bug only manifests with certain optimization >> flags? That's not what I'd have expected from Victor's theory about >> why the code is wrong, but if it only shows up some of the time, >> it's hard to think of another explanation. > Thank you! Using ./configure CC=3D"gcc" CFLAGS=3D"-m64 -O1" on commit = > 9c7d06d60680 with your patch, I got this: > [ configure check passes ] > But make check got the same failures, and I see the same debug output as= = > in [1].. Interesting. Maybe the parameter-passing misbehavior that Victor's test is looking for isn't the only associated bug. > P.S. As I understand it, this comment on bugzilla [2] is also about = > this. > [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D83925#c6 Even more interesting, see c7 that was just posted there: >> Eric Botcazou 2018-01-18 16:22:48 UTC >> 128-bit types requite 128-bit alignment on SPARC64 so we cannot support= that. 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 ;-) regards, tom lane