Re: master make check fails on Solaris 10 - Mailing list pgsql-hackers

From Marina Polyakova
Subject Re: master make check fails on Solaris 10
Date
Msg-id 0e183c12a68af526ebc03c5c26206c44@postgrespro.ru
Whole thread Raw
In response to Re: master make check fails on Solaris 10  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: master make check fails on Solaris 10
List pgsql-hackers
Thank you!

On 17-01-2018 19:33, Tom Lane wrote:
> Attached is a draft patch to incorporate Victor's slimmed-down test
> into configure.  If you have a chance, could you confirm it does
> the right thing on your Sparc machine?

> Victor Wagner <vitus(at)wagner(dot)pp(dot)ru> writes:
>> It seems that what it does is not exactly a right thing.
>> I've applied it to commit 9c7d06d60680 in master and see following
>> checking for __int128 alignment bug... ok
>> As far as I understand your patch, there should be:
>> checking for __int128 alignment bug... broken
> ...
>> Then in the pg_config.h I see
>> /* The normal alignment of `PG_INT128_TYPE', in bytes. */
>> #define ALIGNOF_PG_INT128_TYPE 16
>> /* Define to the name of a signed 128-bit integer type. */
>> #define PG_INT128_TYPE __int128
> ...
>> However, make check passes.
> Uh ... how could that be?  If the output of configure is exactly
> the same as before the patch, how could the end result be different?

Applying your patch on commit f033462d8f77c40b7d6b33c5116e50118fb4699d 
and using the configuration command from [1], I got:
checking for __int128... yes
checking for __int128 alignment bug... broken

Nothing is defined for int128 in pg_config.h:
/* The normal alignment of `PG_INT128_TYPE', in bytes. */
/* #undef ALIGNOF_PG_INT128_TYPE */
...
/* Define to the name of a signed 128-bit integer type. */
/* #undef PG_INT128_TYPE */

And make check-world passes. Victor said that he used a much simpler 
configuration command, and I'm trying to figure out what's changed..

> BTW, it would be a good idea to set up a buildfarm member on that
> machine, if you care about whether that configuration continues
> to work in the future.

Victor answered this in [2]:
> Really we already have buildfarm member on this machine. It is just
> member of PostgresPro private buildfarm, not of big comminity
> buildfarm.
> 
> So, I'll register it in the big buildfarm as soon as I figure out how
> to distribute limited resources of this machine between two buildfarms.

P.S. I found the trailing whitespace in line 80:
! int128a q;

[1] 
https://www.postgresql.org/message-id/0d3a9fa264cebe1cb9966f37b7c06e86%40postgrespro.ru
[2] 
https://www.postgresql.org/message-id/20180117203648.2626d97a%40wagner.wagner.home

-- 
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [Sender Address Forgery]Re: pg_(total_)relation_size andpartitioned tables
Next
From: Amit Langote
Date:
Subject: Re: [Sender Address Forgery]Re: pg_(total_)relation_size andpartitioned tables