From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dmitry Mityugov <d(dot)mityugov(at)postgrespro(dot)ru> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: --with-llvm on 32-bit platforms? |
Date: | 2025-09-15 20:21:54 |
Message-ID: | 660340.1757967714@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dmitry Mityugov <d(dot)mityugov(at)postgrespro(dot)ru> writes:
> Tom Lane писал(а) 2025-09-15 22:16:
>> Interesting. You have at no point shown any details about what
>> these failures look like.
> I did mention that `make check` fails if I enable --with-llvm flag on
> 32-bit Linux platforms, for both GCC and Clang, at the very first
> message in this thread.
Indeed you said that, but that's about as content-free a problem
report as I've run into. What are the regression diffs? (If
they're massive, the first few would still be useful.) Does it
get hung up entirely? Are there crashes, and if so can you get
stack traces from them? You really shouldn't expect people to
spin up an environment like this just to see what happens.
> What's interesting is that when I add the following (quick and dirty)
> assertion to DatumGetPointer on 32-bit Linux platforms,
> DatumGetPointer(Datum X)
> {
> Assert((X & 0xFFFFFFFF00000000) == 0);
> return (Pointer) (uintptr_t) X;
> }
> I get a failure in Postgres executable early on startup.
Interesting, but again, how about a stack trace?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Álvaro Herrera | 2025-09-15 20:24:05 | Re: Implement waiting for wal lsn replay: reloaded |
Previous Message | Dmitry Mityugov | 2025-09-15 20:08:28 | Re: --with-llvm on 32-bit platforms? |