This seems to be a day-one bug which was introduced by JDK-8134553 "CRC32C implementations for x86/x64 targets". It wasn't detected until know because there are not many machines which don't support CLMUL and the CRC32 jtreg tests didn't really work.

During our work on JDK-8176580 "[ppc, s390] CRC32C: wrong checksum result in some cases" we fixed the two regression tests test/compiler/intrinsics/zip/TestCRC32.java and test/compiler/intrinsics/zip/TestCRC32C.java which finally unveiled the problem on old x86 hardware.

We will now push JDK-8176580 without the fixed regression tests. The new version of the tests are available from the following webrev:

http://cr.openjdk.java.net/~lucy/webrevs/8176580.03/

and they should be pushed together with the fix for this issue.

Running these test on old hardware will produce the following error:

command: main -Xbatch compiler.intrinsics.zip.TestCRC32C -m
reason: User specified action: run main/othervm/timeout=600 -Xbatch compiler.intrinsics.zip.TestCRC32C -m
Mode: othervm [/othervm specified]
elapsed time (seconds): 1.915
configuration:
STDOUT:
testing 1050 cases ...
STDERR:
ERROR: crc = 6f894393, crcReference = 2cdf6e8f
java.lang.Exception: TestCRC32C Error
        at compiler.intrinsics.zip.TestCRC32C.check(TestCRC32C.java:218)
        at compiler.intrinsics.zip.TestCRC32C.test_multi(TestCRC32C.java:280)
        at compiler.intrinsics.zip.TestCRC32C.main(TestCRC32C.java:74)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:563)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
        at java.base/java.lang.Thread.run(Thread.java:844)

JavaTest Message: Test threw exception: java.lang.Exception: TestCRC32C Error
JavaTest Message: shutting down test

If you don't have old hardware available, you can still manually force the error as describe by Lutz in the mail tread at http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-April/026029.html and copied here for your convenience:

The CRC32C implementation generates code depending on the CLMUL cpu feature being available. On most machines @Oracle and @SAP, this feature seems to be available – except for one of your MacOS test machines.

To gain control over that feature, I have modified just one line in src/cpu/x86/vm/vm_version_x86_64.hpp like this:
     static bool supports_clmul() { return ((_features & CPU_CLMUL) != 0) && UseNewCode; }

The boolean UseNewCode is a command line parameter we use @SAP to make experimental code switchable during development. With that modification, I can force off the CLMUL feature at will. And voila, here is what I get (linux-x86_64):

   lu0084 PrivSrc/TestCRC> /<some path>/sapjvm_9/bin/java -XX:+UseNewCode TestCRC32C_OpenJDK -m
   updateBytesCRC32C: pclmulqdq = true.
   testing 1050 cases ...
   lu0084 PrivSrc/TestCRC> /<some path>/sapjvm_9/bin/java -XX:-UseNewCode TestCRC32C_OpenJDK -m
   updateBytesCRC32C: pclmulqdq = false.
   testing 1050 cases ...
   ERROR: crc = 6f894393, crcReference = 2cdf6e8f
   iteration 0: offsets[0] = 0 sizes[30] = 1024
   Exception: java.lang.Exception: TestCRC32C Error
   Exception in thread "main" java.lang.Exception: java.lang.Exception: TestCRC32C Error
           at TestCRC32C_OpenJDK.test_multi(TestCRC32C_OpenJDK.java:306)
           at TestCRC32C_OpenJDK.main(TestCRC32C_OpenJDK.java:74)
   Caused by: java.lang.Exception: TestCRC32C Error
           at TestCRC32C_OpenJDK.test_multi(TestCRC32C_OpenJDK.java:298)
           ... 1 more
   lu0084 PrivSrc/TestCRC>

Output on MacOS is the same. I did not try solaris-x86_64.