Re: --with-llvm on 32-bit platforms? - Mailing list pgsql-hackers

Tom Lane писал(а) 2025-09-15 23:21:
> Dmitry Mityugov <d.mityugov@postgrespro.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?

Sorry I didn't provide more information earlier. By the way, I pulled 
the latest changes from the master branch and it didn't help. For the 
problem with --with-llvm on 32-bit Debian 13.1 with GCC 14.2, I'm 
attaching the partial console output from `make check`, 5000 first lines 
from src/test/regress/regression.diffs (in particular, it contains a 
bunch of these: "error: connection to server on socket 
"/tmp/pg_regress-y0DQT8/.s.PGSQL.58928" failed"), and 
src/test/regress/log/postmaster.log. Please let me know if I should send 
more traces of the problem.

The number of tests that fail is random and is between 25-160, out of 
229 total. Sometimes the tests hang entirely and I have to press Ctrl-C 
to interrupt them.

When I enable the aforementioned assert and start `make check`, I 
immediately get in tmp_install/log/initdb-template.log:

Running in no-clean mode.  Mistakes will not be cleaned up.
The files belonging to this database system will be owned by user "dd".
This user must also own the server process.

The database cluster will be initialized with locale "C".
The default database encoding has accordingly been set to "SQL_ASCII".
The default text search configuration will be set to "english".

Data page checksums are enabled.

creating directory 
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/initdb-template 
... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default "max_connections" ... 100
selecting default "shared_buffers" ... 128MB
selecting default time zone ... Europe/Moscow
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... TRAP: failed Assert("(X & 
0xFFFFFFFF00000000) == 0"), File: "../../../../src/include/postgres.h", 
Line: 324, PID: 427452

/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(ExceptionalCondition+0x6b)

[0x56c990cb]

/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(toast_tuple_init+0x2f1)

[0x567c19e1]

/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(heap_toast_insert_or_update+0xe0)

[0x56776b60]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(+0x1a77bc) 
[0x567617bc]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(heap_insert+0x69) 
[0x56765509]

/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(simple_heap_insert+0x2d)

[0x5676660d]

/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(CatalogTupleInsertWithInfo+0x34)

[0x5681a734]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(+0x2c7fed) 
[0x56881fed]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(+0x2caca9) 
[0x56884ca9]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(analyze_rel+0x198) 
[0x568864e8]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(vacuum+0x4cc) 
[0x569066ec]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(ExecVacuum+0x1db) 
[0x56906e8b]

/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(standard_ProcessUtility+0x7ed)

[0x56b2825d]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(+0x56c02d) 
[0x56b2602d]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(+0x56c198) 
[0x56b26198]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(PortalRun+0x18b) 
[0x56b266fb]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(+0x5677a8) 
[0x56b217a8]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(PostgresMain+0x1a17)

[0x56b23667]

/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(PostgresSingleUserMain+0x10b)

[0x56b24c2b]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(main+0x4c4) 
[0x5670a504]
/lib/i386-linux-gnu/libc.so.6(+0x24cc3) [0xf75bbcc3]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0x88) [0xf75bbd88]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(_start+0x27) 
[0x5670a5a7]
Aborted (core dumped)
child process exited with exit code 134
initdb: data directory 
"/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/initdb-template" 
not removed at user's request

It's probably possible to reproduce the problem on a 64-bit Linux (that 
is, define Datum as uint128 to trigger the assert above) but I'm not 
sure if this will be the only change required.

Regards,