https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117997
--- Comment #1 from Jeffrey A. Law <law at gcc dot gnu.org> --- I'm highly confident the problem is in the libgo DSO and not in the testcode itself (I can run the test binary with the system libgo DSO and it works). Given the error message I would expect the problem is either in the bzip2 CRC codegen or in the CRC32 codegen. If I capture the .optimized output from building those components and search for the CRC IFN we have: ./hash/crc32.go.269t.optimized: crc_30 = .CRC_REV (_27, 0, 517762881); ./hash/crc32.go.269t.optimized: crc_17 = .CRC_REV (_14, 0, 79764919); ./compress/bzip2.go.269t.optimized: crc_22 = .CRC (_23, 0, 79764919); ./compress/bzip2.go.269t.optimized: crc_22 = .CRC (_23, 0, 79764919); So we're recognizing the CRC functions in gimple. My suspicion is we muck something up in the gimple->rtl step, but I don't have any evidence to back that up. The real goal of that step was to very what objects have CRC implementations so that we can focus debugging efforts in the right place. Anyway, just wanted to get some thoughts recorded. ISTM like the next step would be to isolate the failure a bit further into either the crc32 or bzip2 code.