The race detector reports a data race between these two lines:

https://github.com/golang/go/blob/go1.15.2/src/hash/crc32/crc32.go#L83
https://github.com/golang/go/blob/go1.15.2/src/hash/crc32/crc32.go#L226

Since the function at the first line will always have returned before the pointer stored in that variable is visible to anything, there are a few possible ways this data race could actually cause the wrong code to run, none of which are too exciting:

• if d.tab is nil and castagnoliTable is nil, the wrong code path will run, but it'll crash on either code path with a nil pointer dereference.
• if castagnoliTable is set non-atomically and just happens to match the exact bit pattern of d.tab, the wrong code path will run. this would require having a CRC table allocated on a 4 gibibyte boundary, assuming CPUs can write at least 32 bits to RAM atomically.

an easy fix for this would be to allocate the memory for castagnoliTable statically, but this would increase the memory footprint of any program that uses the crc32 package but not the Castagnoli table by 1 kibibyte.