-
Type:
Bug
-
Resolution: Fixed
-
Priority:
P3
-
Affects Version/s: 26
-
Component/s: hotspot
-
b21
Found by fuzzer.
Looks like one of the values computed is off by one, comparing interpreter vs compiled.
But it does not seem to reproduce with -XX:-UseSuperWord
Update: it seems it does also not reproduce with: -XX:-UseAutoVectorizationSpeculativeAliasingChecks
Also either one of these does it, but but not if both are on: -XX:-UseAutoVectorizationPredicate -XX:-LoopMultiversioning
So probably something with the aliasing runtime check is wrong, probablyJDK-8324751.
java -Xbatch -XX:CompileCommand=compileonly,Test::test -XX:CompileCommand=printcompilation,Test::test Test.java
4206 99 % b 4 Test::test @ 18 (76 bytes)
4233 100 b 4 Test::test (76 bytes)
4253 101 % b 4 Test::test @ 51 (76 bytes)
sum: 141
sum: 139
at 0: 0 vs 0
at 1: 2 vs 2
...
at 45: 2 vs 2
at 46: 19 vs 17
at 47: 2 vs 2
...
at 62: 2 vs 2
at 63: 0 vs 0
...
at 99: 0 vs 0
Exception in thread "main" java.lang.RuntimeException: wrong result: 141 139
at Test.main(Test.java:39)
At 46 is where the constant address is pointing. Value should be 19, but it is sometimes 15 and sometimes 17. It is just a bad reordering of the memory ops, which should be prevented by the aliasing runtime check.
And with -Xint or -XX:-UseSuperWord it passes.
------------------------- FROM ORIGINAL REPORT ----------------
java -Xbatch Test_3164.java > comp.txt
java -Xint Test_3164.java > int.txt
diff comp.txt int.txt
24c24
< lArr1 iArr2 Test_3164 = 6209323228939198569,21767,-185
---
> lArr1 iArr2 Test_3164 = 6209323228939198569,21766,-185
34c34
< lArr1 iArr2 Test_3164 = 6209323228939198569,21767,-185
---
> lArr1 iArr2 Test_3164 = 6209323228939198569,21766,-185
44c44
< lArr1 iArr2 Test_3164 = 6209323228939198569,21767,-185
---
> lArr1 iArr2 Test_3164 = 6209323228939198569,21766,-185
54c54
< lArr1 iArr2 Test_3164 = 6209323228939198569,21767,-185
---
> lArr1 iArr2 Test_3164 = 6209323228939198569,21766,-185
64c64
< lArr1 iArr2 Test_3164 = 6209323228939198569,21767,-185
---
> lArr1 iArr2 Test_3164 = 6209323228939198569,21766,-185
74c74
< lArr1 iArr2 Test_3164 = 6209323228939198569,21767,-185
---
> lArr1 iArr2 Test_3164 = 6209323228939198569,21766,-185
84c84
< lArr1 iArr2 Test_3164 = 6209323228939198569,21767,-185
---
> lArr1 iArr2 Test_3164 = 6209323228939198569,21766,-185
94c94
< lArr1 iArr2 Test_3164 = 6209323228939198569,21767,-185
---
> lArr1 iArr2 Test_3164 = 6209323228939198569,21766,-185
Looks like one of the values computed is off by one, comparing interpreter vs compiled.
But it does not seem to reproduce with -XX:-UseSuperWord
Update: it seems it does also not reproduce with: -XX:-UseAutoVectorizationSpeculativeAliasingChecks
Also either one of these does it, but but not if both are on: -XX:-UseAutoVectorizationPredicate -XX:-LoopMultiversioning
So probably something with the aliasing runtime check is wrong, probably
java -Xbatch -XX:CompileCommand=compileonly,Test::test -XX:CompileCommand=printcompilation,Test::test Test.java
4206 99 % b 4 Test::test @ 18 (76 bytes)
4233 100 b 4 Test::test (76 bytes)
4253 101 % b 4 Test::test @ 51 (76 bytes)
sum: 141
sum: 139
at 0: 0 vs 0
at 1: 2 vs 2
...
at 45: 2 vs 2
at 46: 19 vs 17
at 47: 2 vs 2
...
at 62: 2 vs 2
at 63: 0 vs 0
...
at 99: 0 vs 0
Exception in thread "main" java.lang.RuntimeException: wrong result: 141 139
at Test.main(Test.java:39)
At 46 is where the constant address is pointing. Value should be 19, but it is sometimes 15 and sometimes 17. It is just a bad reordering of the memory ops, which should be prevented by the aliasing runtime check.
And with -Xint or -XX:-UseSuperWord it passes.
------------------------- FROM ORIGINAL REPORT ----------------
java -Xbatch Test_3164.java > comp.txt
java -Xint Test_3164.java > int.txt
diff comp.txt int.txt
24c24
< lArr1 iArr2 Test_3164 = 6209323228939198569,21767,-185
---
> lArr1 iArr2 Test_3164 = 6209323228939198569,21766,-185
34c34
< lArr1 iArr2 Test_3164 = 6209323228939198569,21767,-185
---
> lArr1 iArr2 Test_3164 = 6209323228939198569,21766,-185
44c44
< lArr1 iArr2 Test_3164 = 6209323228939198569,21767,-185
---
> lArr1 iArr2 Test_3164 = 6209323228939198569,21766,-185
54c54
< lArr1 iArr2 Test_3164 = 6209323228939198569,21767,-185
---
> lArr1 iArr2 Test_3164 = 6209323228939198569,21766,-185
64c64
< lArr1 iArr2 Test_3164 = 6209323228939198569,21767,-185
---
> lArr1 iArr2 Test_3164 = 6209323228939198569,21766,-185
74c74
< lArr1 iArr2 Test_3164 = 6209323228939198569,21767,-185
---
> lArr1 iArr2 Test_3164 = 6209323228939198569,21766,-185
84c84
< lArr1 iArr2 Test_3164 = 6209323228939198569,21767,-185
---
> lArr1 iArr2 Test_3164 = 6209323228939198569,21766,-185
94c94
< lArr1 iArr2 Test_3164 = 6209323228939198569,21767,-185
---
> lArr1 iArr2 Test_3164 = 6209323228939198569,21766,-185
- caused by
-
JDK-8324751 C2 SuperWord: Aliasing Analysis runtime check
-
- Resolved
-
- duplicates
-
JDK-8368578 ARM32: C2 SuperWord analysis fails with assert
-
- Closed
-
- relates to
-
JDK-8370408 [s390x] TestDoNotFilterNaNSummands.java failed with assert
-
- Open
-
- links to
-
Commit(master)
openjdk/jdk/207fe55d
-
Review(master)
openjdk/jdk/27848