| From: | "Greg Burd" <greg(at)burd(dot)me> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Andres Freund" <andres(at)anarazel(dot)de>, "Nathan Bossart" <nathandbossart(at)gmail(dot)com>, "John Naylor" <johncnaylorls(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "Andrew Dunstan" <andrew(at)dunslane(dot)net> |
| Subject: | Re: Add RISC-V Zbb popcount optimization |
| Date: | 2026-05-29 17:26:34 |
| Message-ID: | 6470e83d-b1c9-4c19-863f-9c68fdff3331@app.fastmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, May 29, 2026, at 12:23 PM, Tom Lane wrote:
> "Greg Burd" <greg(at)burd(dot)me> writes:
>> The zic.c hit is the one that bothers me. It's the same shape as des_init() --
>> byte-sized destination, scatter store via an indexing array -- and it's not
>> exercised by `make check`, since zic runs at `make install` to compile the IANA
>> tz data.
>
> "make check" certainly *will* run zic.c, while creating the temporary
> installation. (Unless you use --with-system-tzdata, which I'm sure
> most production builds do.) But our test suite touches only a very
> tiny fraction of the tzdata files, so even if there's some
> corruption in them we wouldn't necessarily notice it.
Apologies, you are correct about "make check". I think it's still bothersome that a bug can hide in plain sight, but I've not thought about how to supplement tests to fix that.
Still waiting on LLVM/Clang to compile...
> regards, tom lane
best.
-greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2026-05-29 18:21:54 | Re: Uninitialized memory access in zic |
| Previous Message | Robert Haas | 2026-05-29 17:25:45 | Re: pg_stash_advice: dump file with overlong stash name crashes worker in a restart loop |