Bug report
Describe the bug
The test case t8_gtest_compute_first_element_serial does not work on the github Mac OS runner. More specifically, the test for large numbers stalls. From what I investigated, it seems like it because the sum_0 in t8_cmesh_get_first_element_of_process runs into some overflow. At least it only stalls when we actually want to access its value after computing it.
Other things to note:
- The variable
size in this test case is of type uint64_t but then passed to t8_cmesh_get_first_element_of_process, which expects uint32_t. However, that did not cause the problem.
- I ran it on a Mac Mini and there everything was fine, so it is not a general Mac OS issue.
I already put WAY more time in it than I should have, so for now I deactivate the test case (in PR TODO) for the Mac OS workflow.
To Reproduce
remove the if (NOT APPLE) condition I added to the test case.
Estimated priority
Which of these is most applicable (remove the others):
"Priority: low" Should be solved eventually
Bug report
Describe the bug
The test case
t8_gtest_compute_first_element_serialdoes not work on the github Mac OS runner. More specifically, the test for large numbers stalls. From what I investigated, it seems like it because thesum_0int8_cmesh_get_first_element_of_processruns into some overflow. At least it only stalls when we actually want to access its value after computing it.Other things to note:
sizein this test case is of typeuint64_tbut then passed tot8_cmesh_get_first_element_of_process, which expectsuint32_t. However, that did not cause the problem.I already put WAY more time in it than I should have, so for now I deactivate the test case (in PR TODO) for the Mac OS workflow.
To Reproduce
remove the
if (NOT APPLE)condition I added to the test case.Estimated priority
Which of these is most applicable (remove the others):
"Priority: low" Should be solved eventually