Re: PG11 jit failing on ppc64el

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Christoph Berg <myon(at)debian(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: PG11 jit failing on ppc64el
Date: 2018-05-24 14:41:38
Message-ID: 27818.1527172898@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> On Thu, May 24, 2018 at 3:48 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> For entertainment's sake, I tried building --with-llvm on FreeBSD 12
>> arm64 (hey, gotta do something with this raspberry pi toy I got).

> Neat. Quite tempted to get one!

Fair warning: the newest "3B+" model contains new ethernet and wireless
chips that none of the BSDen have drivers for yet. I ended up spending
an extra $10 on a USB WiFi dongle so that I could get the thing on the
network. Compared to the price of the RPI itself, seems like highway
robbery. (But then again, the keyboard I plugged into it is worth
more than the RPI, not to mention the monitor.)

>> I used llvm-devel-7.0.d20180327 which seems to be the latest available in
>> FreeBSD's package system. Builds cleanly, does not work at all.

> Hmm. I just tried llvm-devel-7.0.d20180327 on my amd64 FreeBSD 12
> system and our make check passed with flying colours.

Hmph. Looking closer, "does not work at all" is overly negative.
It gets about halfway through the core regression tests and then
crashes on one specific query in the "inherit" test:

2018-05-24 01:22:28.657 EDT [51790] LOG: server process (PID 52037) was terminated by signal 11: Segmentation fault
2018-05-24 01:22:28.657 EDT [51790] DETAIL: Failed process was running: select * from matest0 order by 1-id;

Still trying to get more info on exactly where it's going off the
rails --- gdb has got some problems with printing such deep stacks,
and for some reason "ulimit -s" doesn't work to make the available
stack space smaller.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris Bandy 2018-05-24 15:14:06 Unexpected casts while using date_trunc()
Previous Message Laurenz Albe 2018-05-24 14:33:11 Locks on unlogged tables are locked?!