On Tue, 2 Dec 2025 10:47:29 GMT, Arno Zeller <[email protected]> wrote:
> The change looks good, but you might consider using > jdk.test.lib.RandomFactory. It allows to get and set a seed that is also > printed at every run to make a failure easily reproducible. Thanks for the tip. Thats a pattern I use a lot! My complaint with `RandomFactory` is that now I need to add an extra classpath when calling the test directly. My development pattern is usually calling this command hundreds (thousands??) of times, until it is "convinced" to pass.. make images && ./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -cp build/linux-x86_64-server-fastdebug/images/test/lib-test/test-lib.jar --add-opens java.base/sun.security.provider=ALL-UNNAMED --add-exports java.base/sun.security.provider=ALL-UNNAMED -XX:+UnlockDiagnosticVMOptions -XX:+UseDilithiumIntrinsics test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java (That is, I prefer to call java directly, instead of via jtreg) > And as the test now fails on aarch64 perhaps it should be excluded there and > a bug should be opened - or is the behavior expected on aarch64 ? I would prefer a separate bug report. There really should not be any failures on aarch64 either. But its entirely possible that I needed to constrain the range of RNG further (i.e. in which case this is test issue, not an actual bug in crypto..) @ferakocz Would you mind having a look at aarch64 failure? I have no idea how its asm works.. I really hope its something like this fix I had to put in: https://github.com/openjdk/jdk/blob/41ab1ec74139a35da789cc09fd2240dcffa49927/test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java#L156 (i.e. without that constraint, the int32 could overflow..) PS: I am happy to help as I can with the range analysis.. I spent quite a bit agonizing over it in our own internal review.. Perhaps this could.. erm... "help" :D <img width="972" height="1144" alt="image" src="https://github.com/user-attachments/assets/a84319a4-2a00-4aa2-b1a9-461f2f26e41a"; /> I do not believe the end of the proof above is fully correct; particularly, I do not see how the leap to the range "highlighted in red" is possible. I believe the conclusion is still valid, here is my own correction to that sentence: <img width="846" height="438" alt="image" src="https://github.com/user-attachments/assets/7d52ebd0-1113-4191-8277-52131d98ad88"; /> ------------- PR Comment: https://git.openjdk.org/jdk/pull/28584#issuecomment-3602818185
