Re: --with-llvm on 32-bit platforms?

From: Dmitry Mityugov <d(dot)mityugov(at)postgrespro(dot)ru>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: --with-llvm on 32-bit platforms?
Date: 2025-09-15 16:23:30
Message-ID: 7a32d348a882199a035643f78e26f97a@postgrespro.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut wrote 2025-09-15 09:36:
> On 05.09.25 13:32, Dmitry Mityugov wrote:
>> Dmitry Mityugov писал(а) 2025-09-05 11:11:
>>> Dmitry Mityugov писал(а) 2025-09-05 00:32:
>>>> It seems that when I add --with-llvm flag to ./configure on any 32-
>>>> bit platform that I have (Debian 12, Debian 13, Arch Linux), many
>>>> tests invoked by `make check` fail, or, sometimes, hang forever. Is
>>>> this a known problem? It's not critical to me, just wanted to know
>>>> if I should abandon --with-llvm forever on such platforms. On 64-bit
>>>> Linux platforms, both x86 and ARM, --with-llvm works fine.
>>>>
>>>> To reproduce, it's enough to:
>>>>
>>>> make distclean
>>>> ./configure --with-llvm
>>>> make -j23 -ks
>>>> make check
>>>>
>>>> The last step is never successful to me, and, by the way, this can
>>>> also be reproduced with clang:
>>>>
>>>> make distclean
>>>> ./configure CC=clang CXX=clang++ --with-llvm CFLAGS=-msse2
>>>> make -j23 -ks
>>>> make check
>>>>
>>>> Thanks in advance for your attention to this problem, or telling me
>>>> this is not a problem at all
>>>
>>> One of the reasons I ask this question is that according to
>>> f5d07085822a1 parameter --with-llvm is now mandatory in some cases,
>>> but it seems it can't be used.
>>
>> By the way, when I rebuild REL_17_STABLE using the steps above (on
>> Debian 13 32-bit is this matters) tests in `make check` pass, so it
>> seems that something is broken in master.
>
> It seems plausible that this is related to commit 2a600a93c7b "Make
> type Datum be 8 bytes wide everywhere.". I don't have any more
> insights than that.

Thanks for the hint. I did git bisect, and it seems that the first ‘bad’
commit is this:

commit 2a600a93c7be5b0bf8cacb1af78009db12bc4857
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Wed Aug 13 16:35:06 2025 -0400

Make type Datum be 8 bytes wide everywhere.

I'll try to look further to understand what particular change in this
commit is responsible for the problem.

Thank you again

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2025-09-15 16:32:15 Re: plan shape work
Previous Message Tom Lane 2025-09-15 16:15:26 Re: BUG #18959: Name collisions of expression indexes during parallel Index creations on a pratitioned table.