[powerpc] Some build errors and test results: issues to be addressed – threading, endianness #2128
Comments
|
Perhaps this: Does not look great either: |
|
Generally speaking, folly only supports 64 bit architectures. There may be bits and pieces that work on 32-bit platforms, but overall Folly is entirely untested on them. If the fixes needed to get it compiling on 32-bit PPC are reasonably small, we can probably accept a pull request. |
|
@Orvid I had the basic build fixed for |
|
@Orvid I got tests running on I hacked pthreads for now, just setting |
|
@Orvid @pkubaj For the context, on macOS 14.2.1 arm64 I got 91% passing, 279 failures, and I had to remove one test since it was simply freezing. |
|
The log from tests is almost 7 GB, my PowerMac refuses to even open it Few quick notes before digging into it further:
Anything mentioning overflow is not surprising, since this is 32-bit arch. Tests using long double will likely fail since, I would believe, nothing accounts for IBM format of those. To be updated. |
barracuda156
changed the title
PicoSpinLock.h: error: no match for call to '(const folly::make_atomic_ref_t) (folly::PicoSpinLock<long long int, 63>::UIntType&)'
|
@Orvid Unfortunately, most of the failures produce no meaningful output in logs, so to figure out what fails I will need perhaps to run those separately via GDB. However, I will summarize below meaningful failures. Gonna make it similar-problem-per-comment to make it readable, dropping repeated error messages. |
Also, there is no real monotonic clock on older macOS, and Macports provides a drop-in implementation which relies on what is actually available in the kernel. It is a compromise and cannot serve as a 100% substitute. This could be another reason.
Perhaps related as well: |
|
|
Same story here: |
|
There should be a way to use So this test failed as a result of my imperfect preliminary fix to the problem: |
This is more of a note to myself, it has to be checked elsewhere too. |
|
crc32cSoftware and crc32cAutodetect all fail, but hardware ones pass. |
|
It is also used in Can we use |
Etc. |
|
|
@Orvid While there was a typo in the initial version of one patch, which was used with the test run above, I corrected it, and also dropped reverting a few commits related to thread caching, rebuilt and rerun tests, results are nearly identical: (I disabled a couple of known-to-be-broken-tests, and there is one new for thread caching, which expectedly fails, but otherwise I do not see anything notable. Gonna check logs tomorrow, this already took some 20+ hrs in a row.) On the other hand, and ironically, on the latest macOS 14.3 arm64 tests are just marginally better with 91% passing vs 90% on 10.6 ppc :) |
|
Re time, perhaps we can use |
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Could someone help me a bit with an advice on the following? (I do not ask to fix it for me, but perhaps for someone who knows what the code does exactly, pointing out at the issue will be fairly easy.)
This is the error I get:
It seems that
folly/synchronization/AtomicRef.huses a kind of SFINAE, which does not work as intended either due to implicit assumption of 64-bit arch (so pointers and offsets are wrong) or due to incorrect assumption of bool and spinlock being equal to 1 byte (both are 4 byte onppc).Any ideas and suggestions will be greatly appreciated.
The text was updated successfully, but these errors were encountered: