-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use int64_t
for KLU_INDEXTYPE
if SUNDIALS_INT64_T
is true.
#477
Conversation
This looks good to me, so I'm temporarily approving and initiating the CI runs. Before this is merged the fix should be mentioned in the |
`long int` is 32 bits wide on systems that use an LLP64 data model (e.g., Windows 64-bit). Use a type for which the C standard guarantees that it is 64-bit instead (i.e., `int64_t`). Signed-off-by: Markus Mützel <[email protected]>
Thank you for the review. I added notes about that change to the two files you pointed out. Is the wording ok? |
Yes, the wording is OK. Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks; the wording of your notes is excellent.
Looks like one of the tests failed for the MSVC runner in CI:
Is there any way to get more detailed information from the runner to see what specifically failed? |
@mmuetzel That test randomly fails some times if the VM is slow. I reran it, and it passed. |
Could this cause problems with older versions of KLU (before 6.0.0) on Windows? I think |
You are correct that prior to 6.0.0 SuiteSparse defined |
I think even on most Windows systems it would use |
I interpret "64-bit ARM or x64" to include "x86-64" so most Windows systems would define |
If we want to ensure that other LLP64 and ILP32 systems can use SuiteSparse < 6 and 64-bit SUNDIALS_INDEX_SIZE together, then we can add a check of the SuiteSparse version in a preprocessor macro. I actually don't think it would be possible for an ILP32 system to run into the issue because they would probably not be using SUNDIALS_INDEX_SIZE=64, and I don't know of any non Windows LLP64 systems. |
I'm not sure, the
I think setting |
You are right. Before SuiteSparse version 6.0.0,
Maybe, those pointer casts should be removed entirely to allow the compiler to correctly detect if the pointers that are returned by these function don't match what For easier reference, the code in question is, e.g., here: sundials/src/sunlinsol/klu/sunlinsol_klu.c Lines 282 to 284 in b685654
sundials/src/sunlinsol/klu/sunlinsol_klu.c Lines 296 to 299 in b685654
|
@gardner48 said:
@mmuetzel said:
This is correct. @gardner48 said:
I think that the combination of a 32-bit system, latest and greatest SUNDIALS, but a SuiteSparse that is 2 versions old (or more) is very unlikely, but for other TPLs we check that the index sizes used by the TPL and SUNDIALS match in CMake. We could do that and it would also catch the case where users have just misconfigured SUNDIALS or SuiteSparse. @mmuetzel Would you be able to add a check in the file |
`long int` is 32 bits wide on systems that use an LLP64 data model (e.g., Windows). Use a type for which the C standard guarantees that it is 64-bit instead (i.e., `int64_t`). See the error in CI for PR #432. Signed-off-by: Markus Mützel <[email protected]> Co-authored-by: Cody Balos <[email protected]>
long int
is 32 bits wide on systems that use an LLP64 data model (e.g., Windows). Use a type for which the C standard guarantees that it is 64-bit instead (i.e.,int64_t
).See the error in CI for PR #432.