On 18-01-2018 19:53, Tom Lane wrote:
> Marina Polyakova <[email protected]> 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="gcc" CFLAGS="-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=83925#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 ;-)
%-)) :-)
Can I do something else about this problem?..
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
