Skip to content
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

Implement Kokkos::printf #6083

Merged
merged 3 commits into from
Jul 8, 2023
Merged

Implement Kokkos::printf #6083

merged 3 commits into from
Jul 8, 2023

Conversation

masterleinad
Copy link
Contributor

@masterleinad masterleinad commented Apr 26, 2023

Supersedes #6061. This pull request implements Kokkos::printf as discussed.
After trying a bunch of implementations (just wrap KOKKOS_IMPL_DO_NOT_USE_PRINTF, define a separate function that calls printf), it seems that importing printf into the Kokkos namespace is the only option that works.

In my opinion, it's a good idea to keep the KOKKOS_IMPL_DO_NOT_USE_PRINTF macro around a little longer to allow some users to transition.

@masterleinad
Copy link
Contributor Author

Retest this please.

@masterleinad
Copy link
Contributor Author

NVHPC seems to error out when we are not using a string literal for the formatting string.

@masterleinad masterleinad marked this pull request as ready for review June 26, 2023 15:47
Copy link
Contributor

@cz4rs cz4rs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

@masterleinad masterleinad marked this pull request as draft June 28, 2023 15:12
@masterleinad masterleinad force-pushed the kokkos_printf branch 2 times, most recently from 58eea6c to 1b71a4f Compare June 28, 2023 21:11
#endif

int backup_no, new_no;
fflush(stdout);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any particular reason why you are not using ::testing::internal::CaptureStdout()
It is not part of the GTest API but we already use it elsewhere and if/when we get into trouble for it we can encapsulate and replace.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't quite realize that we are already reaching into someone else's internal namespace. Sure, we can try that instead. It's just for testing anyway.

@masterleinad masterleinad marked this pull request as ready for review June 29, 2023 16:51
#elif defined(KOKKOS_COMPILER_NVHPC) // FIXME_NVHPC
template <typename... Args>
KOKKOS_FUNCTION int printf(const char* format, Args... args) {
::printf(format, args...);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Returning a value here doesn't work with NVHPC.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did we discuss whether we should be providing a checked version or return anything at all?
By that I mean, should we attempt to cause program termination when we detect than an error occurred?
Should we return void instead of "passing through" the return value of printf as currently proposed?

I don't necessarily have an issue with what is proposed but I do want to make sure we considered alternatives.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's good to stay close to what printf does since that's what people are used to (even though I doubt many people use the return value anyway).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did we discuss whether that should be a private or public header?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, my intuition was to do the same as for core/src/impl/Kokko_Error.hpp (and it's easier to go from "private" to "public" than the other way around).

template <typename... Args>
KOKKOS_FUNCTION int printf(const char* format, Args... args) {
::printf(format, args...);
return 1;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In case anyone is using the return value of printf for some diagnostic, I think this should return some other value than 1 to avoid confusion. But since negative value is reserved to indicate errors for standard ::printf, perhaps 0 is the neutral option.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was choosing 1 because that is what I get for most GPU backends and it's fairly difficult to make printf fail anyway.

Comment on lines 24 to 26
// We are forwarding the format string to printf but gcc and clang warn about
// the format string not being a literal.
#if defined(__GNUC__)
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wformat-security"
#endif
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't get this one. Can you share a godbolt link?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed commit to remove these lines and you can see the CI failing with these warnings.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, see https://godbolt.org/z/bdM4ozM9r where I found a different workaround when there are no arguments for the format string.

@masterleinad
Copy link
Contributor Author

Failures in CUDA-11.7-NVHPC

[ 92%] Building CXX object core/unit_test/CMakeFiles/Kokkos_CoreUnitTest_Cuda1.dir/cuda/TestCuda_RangePolicyConstructors.cpp.o
NVC++-S-0000-Internal compiler error. extractor: bad opc       0  (/var/jenkins/workspace/Kokkos/algorithms/unit_tests/TestStdAlgorithmsMoveBackward.cpp: 216)
NVC++-S-0000-Internal compiler error. extractor: bad opc       0  (/var/jenkins/workspace/Kokkos/algorithms/unit_tests/TestStdAlgorithmsMoveBackward.cpp: 216)
NVC++-S-0000-Internal compiler error. extractor: bad opc       0  (/var/jenkins/workspace/Kokkos/algorithms/unit_tests/TestStdAlgorithmsMoveBackward.cpp: 216)
NVC++-S-0000-Internal compiler error. extractor: bad opc       0  (/var/jenkins/workspace/Kokkos/algorithms/unit_tests/TestStdAlgorithmsMoveBackward.cpp: 216)
NVC++-S-0000-Internal compiler error. extractor: bad opc       0  (/var/jenkins/workspace/Kokkos/algorithms/unit_tests/TestStdAlgorithmsMoveBackward.cpp: 216)
NVC++-S-0000-Internal compiler error. extractor: bad opc       0  (/var/jenkins/workspace/Kokkos/algorithms/unit_tests/TestStdAlgorithmsMoveBackward.cpp: 216)
NVC++-S-0000-Internal compiler error. extractor: bad opc       0  (/var/jenkins/workspace/Kokkos/algorithms/unit_tests/TestStdAlgorithmsMoveBackward.cpp: 216)
NVC++-S-0000-Internal compiler error. extractor: bad opc       0  (/var/jenkins/workspace/Kokkos/algorithms/unit_tests/TestStdAlgorithmsMoveBackward.cpp: 216)
[ 92%] Building CXX object core/unit_test/CMakeFiles/Kokkos_CoreUnitTest_OpenMP.dir/openmp/TestOpenMP_ViewCopy_a.cpp.o
NVC++/x86-64 Linux 22.9-0: compilation completed with severe errors

are unrelated.

@dalg24
Copy link
Member

dalg24 commented Jul 6, 2023

Do these show on other builds?

@masterleinad
Copy link
Contributor Author

Do these show on other builds?

I have seen that in a couple of other builds.

Co-authored-by: Damien L-G <dalg24+github@gmail.com>
@dalg24 dalg24 merged commit 597bc36 into kokkos:develop Jul 8, 2023
28 checks passed
@masterleinad masterleinad mentioned this pull request Jul 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants