On 5/19/2026 10:30 AM, Andrew Pinski wrote:
On Tue, May 19, 2026 at 6:29 AM Kito Cheng <[email protected]> wrote:
Before r17-567 ("middle-end: Optimize reversed CRC table-based
implementation"), a reversed CRC without a crc_rev optab was
expanded as: reflect the input, run the non-reversed CRC table,
then reflect the result. So the table that got emitted was the
non-reversed one, and the dump printed:
;; emitting crc table crc_<N>_polynomial_<P> ...
After that patch, the middle end builds a reversed CRC table
directly and the dump prints:
;; emitting reversed crc table crc_<N>_polynomial_<P> ...
Any target without a crc_rev optab hits the new path. For example,
RISC-V's bitmanip.md defines crc_rev<ANYI1:mode><ANYI:mode>4 with
no TARGET_ guard, so the optab is always there and the dump still
says "using optab for ..." -- the test passes. But x86's
crc_rev<SWI124:mode>si4 needs TARGET_CRC32, so a default x86 build
(no SSE4.2 / -march=cascadelake) has no optab, falls back to the
table, and prints the new "emitting reversed crc table" message.
The old regex only accepted "emitting crc table", so x86 fails.
These tests only call __builtin_rev_crc*, which always take the
reversed path, so the non-reversed "emitting crc table" message
cannot appear here. Just replace it with the new wording.
gcc/testsuite/ChangeLog:
* gcc.dg/crc-builtin-rev-target32.c: Match the new
"emitting reversed crc table" dump message.
* gcc.dg/crc-builtin-rev-target64.c: Likewise.
Ok.
And just to close the loop. This fixes the various regressions spotted
by my tester as well.
jeff
