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
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. |