Repository navigation
0.20.2: i686 --- the x87 routines kept, atomic.c for sixty-four bit atomics on four-aligned objects - #73
Merged
Conversation
…tomics on four-aligned objects
Without a branch of the same name a backend's default branch was taken. openkal- windows main is on 0.22 while openkal-musl names ^0.21.1 and mcpplibs.os bounds it below 0.22, so the Windows host's graph was refused. The default branch is taken when its version is within the stated range, and otherwise the newest release within it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
openkal-llvm-runtime 0.20.2: the compiler-rt selection for
i686-linux-musl(design K7; openkal 0.25.1, clause 5.5). No change for any 64-bit target.*xf*.c,*xc3.c(x87long double)atomic.cint64_tfield, 4-aligned on i386) lowers to__atomic_load; mimalloc's statistics do so (measured:undefined symbol: __atomic_load). It uses its own spin locks and no system call. Elsewhere it stays out, as before (the blanket!atomic*.cbecame!atomic_*.cplus!atomic.cfor every architecture but i686, because an exclusion anywhere in the merged list wins over an inclusion).Verification (local, x86_64 Linux, above openkal-linux#55 and the openkal-musl i386 branch through a local openkal-platform with
i686-linux-muslhosted):import std, a thrown and caught exception, fourstd::jthreads,std::format("{:>6.2f}|{}", 3.14159, 1LL << 40), a file stream,std::map-- all held, ELF32 static;full,optional): 407 held, 0 did not hold, the same five not observed as on x86_64.The CI leg for
i686-linux-muslbelongs where the rows are hosted (openkal-platform), after openkal-linux 0.26.2 and openkal-musl's i386 release are indexed.The branch graph (
tools/branch-graph.sh) takes a backend's default branch only when its version is within the range openkal-musl states for it, and otherwise the newest release within that range: openkal-windows main is on 0.22 while the family names ^0.21.1, and the Windows host's graph was refused (mcpplibs.os bounds openkal-windows below 0.22).