-
Notifications
You must be signed in to change notification settings - Fork 908
OSHMEM/SHMEM: fix warnings regarding types and unused variables in shmem #12648
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
Conversation
@roiedanino the fixes should be according to openshmem specification, see http://openshmem.org/site/sites/default/site_files/OpenSHMEM-1.5.pdf |
So as I see it, those functions return an index and not a return code (like implied by the current implementation), what would be the way to indicate that some function is not implemented yet? logging an error message? |
From what I can see, there is no error-checking in any of this API. Simply running through a program printing warnings on each call is a bad idea. Bailing out (with a proper message) is probably the right way to go here. The cast to |
{ | ||
return OSHMEM_ERR_NOT_IMPLEMENTED; |
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.
@roiedanino can you please explain how this line leads to a warning? I understand the warning for size_t but not for int. Same for void.
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.
This one does not, but it's incorrect to return a return code as it doesn't match specifications to do so, the caller won't expect a return code and won't interpret it as such
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.
We could internally return ssize_t
to be able to encode errors. That would resolve the warning.
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.
So we will need to add int* return_value
parameter to all of those functions to be able to return both rc and the actual value needed to be returned to the caller by specifications
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.
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.
I thought these functions return size_t
in the standard? If you replace size_t
with ssize_t
(signed size_t
) you can return a negative error code and the index/size required by the standard. That will silence the compiler warnings I pointed out (which complained about an unsigned value being tested for negative values)
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.
So we will need to add
int* return_value
parameter to all of those functions to be able to return both rc and the actual value needed to be returned to the caller by specifications
I thought these functions return
size_t
in the standard? If you replacesize_t
withssize_t
(signed size_t
) you can return a negative error code and the index/size required by the standard. That will silence the compiler warnings I pointed out (which complained about an unsigned value being tested for negative values)
@roiedanino I would suggest keeping the changes to a minimum for now, we can think about dealing with error codes for functions that do not return integers once we have the implementation in. I suggest printing an error/warning and breaking or returning SIZE_MAX
for now.
@devreal Yes, standard mandates that this function return size_t
and I think we'd better not to change the return code.
Thanks to @roiedanino for working on fixing the warnings. |
I will go through them and fix where the implementation doesn't match the specifications |
Hello! The Git Commit Checker CI bot found a few problems with this PR: 2f0dd13: OSHMEM/MCA/SPML/UCX: reverted some of the changes,...
Please fix these problems and, if necessary, force-push new commits back up to the PR branch. Thanks! |
2f0dd13
to
66947e6
Compare
@roiedanino did you check this? |
Hi went through the PR, looks like the only issue I see (other than the things mentioned earlier): |
oshmem/runtime/runtime.h
Outdated
#define RUNTIME_SHMEM_NOT_IMPLEMENTED_API_ABORT_RET_SIZE_T() \ | ||
RUNTIME_SHMEM_NOT_IMPLEMENTED_API_ABORT(); \ | ||
return SIZE_MAX | ||
|
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.
Suggest proper scoping using do-while (like above)
#define RUNTIME_SHMEM_NOT_IMPLEMENTED_API_ABORT_RET_SIZE_T() \ | |
RUNTIME_SHMEM_NOT_IMPLEMENTED_API_ABORT(); \ | |
return SIZE_MAX | |
#define RUNTIME_SHMEM_NOT_IMPLEMENTED_API_ABORT_RET_SIZE_T() \ | |
do { \ | |
RUNTIME_SHMEM_NOT_IMPLEMENTED_API_ABORT(); \ | |
return SIZE_MAX; \ | |
} while (0) | |
Hello! The Git Commit Checker CI bot found a few problems with this PR: c4588ca: OSHMEM/RUNTIME: added do while scoping to NOT_IMPL...
Please fix these problems and, if necessary, force-push new commits back up to the PR branch. Thanks! |
c4588ca
to
b36c163
Compare
@roiedanino thanks for the PR - please add a sign-off line in the commit |
Signed-off-by: Roie Danino <[email protected]>
b36c163
to
093900d
Compare
When compiling OpenShmem multiple warnings appear regarding a condition inside
RUNTIME_CHECK_IMPL_RC
macro as described in #12636The solution would be changing the return types of the following functions from
size_t
toint
:Also removed an unused variable in
void prefix##type_name##_wait_until_all_vector
which caused multiple warnings as well