Fix several warnings from GCC 16#396
Conversation
| LG_TRY (LAGraph_Finalize (msg)) ; | ||
| return (GrB_SUCCESS) ; | ||
| } | ||
|
No newline at end of file |
There was a problem hiding this comment.
Don't delete this line. I use these to navigate with vim. If gcc 16 is complaining about it, then it would complain in 100s of places in my codes, and the warning should just be silenced instead.
There was a problem hiding this comment.
The last line had some trailing white space. I removed it, now it is similar to all the other files. Difficult to tell by the web diff.
|
These changes are being made to the stable branch, but the stable branch is out of date with the latest development branch ( https://github.com/GraphBLAS/LAGraph/tree/v1.3.x ). |
Found by GCC 16 (-Wpedantic).
1e482a7 to
97e4a03
Compare
Found by GCC 16 (-Wenum-int-mismatch).
Found by GCC 16 (-Wunused-variable).
Match with declaration in header. Found by GCC 16 (-Warray-paramter).
97e4a03 to
3e21558
Compare
|
What is needed to get this accepted? |
There are many many changes I have to verify, so it will take me some time to go through. Many lines of code are deleted in this PR but they shouldn't be. For example, the variables r_size, ramp_size, etc are being deleted in experimental/benchmark/FastAssign_demo.c, but they appear in the #if 0 block later on. So they should be "#if 0" commented out, not deleted. I have to check each change like this carefully to ensure I'm not deleting something important. LAGraph has many authors and I don't always know (without looking at each file one at a time) whether or not the unused variables are important or not. It would be easier to merge these changes in if none of these lines were deleted, just commented out instead. |
|
From my experience, having wrong code and outdated code in comments is confusing, thus this PR. |
|
The LAGraph/experimental/algorithms are works in progress, and if there is commented-out code in there, it's for a reason. Sometimes the code is scaffolding, meant for development use only. Deleting part of that scaffolding but not others would lead to a broken scaffolding. I'd prefer to close this PR. I can work through the gcc 16 warnings myself and triage them accordingly. |
2 participants
No description provided.