Conversation
When the checksum is not defined (hardcoded) the check would be failing everytime the user modifies the number of grid points, or request a size for which the checksum is not known. Not properly managing these cases would result with the application returning a failure for bad checksum. This commit resolves this case by propagating into Input a flag indicating whether the number of grid points has been modified. If the number of points has been modified (even if it stays the same as the default for "small", "large", "XL" or "XXL"), then the checksum comparison result is ignored, a warning is issued, but the application returns a success return code.
|
Thanks for submitting this PR! This is a great point that it is not ideal to have it return an error code if running in a non-default configuration. I am actually working on an update for XSBench to include a HIP version, so may try to add something in along these lines. I am thinking I may go a slightly different route, where it will still return an error code if run in a non-default configuration, with the exception of if an expected hash is given by the user to compare against via a new command line argument. The idea being they can run it on CPU or somewhere first to generate the expected hash and then use that for comparison. This could be useful for automated testing where passing success for non-default configurations might not catch regressions. |
2 participants
It's mainly the third commit that matters. The problem I had was that whenever I was using a custom number of gridpoints, or not using either small or large, the checksum was not compared right and the program was returning an error code. I changed it so the program would issue a warning instead of failing in cases where it is unable to check the checksum.