No actual effect on the code, but misleading and wrong. (The previous
change only fixed the argument types; I didn't notice that some of the
return types were wrong too.)
Test: treehugger
Change-Id: I1ee5c48e2652fd8cbf8178d5659e57f79e61898e
* When calculating the required guard, if a per-arch `introduced`
value is less than the arch min-API, drop the per-arch guard (i.e.
reset the value to 0). This is needed for RISC-V, where we don't
parse the headers with Clang, because the highest APIs we compile
for (e.g. 23, 34) are less than the current RISC-V min API of 10000.
Resetting it to 0 here means we don't need this optimization while
generating an arch-set guard. (i.e. We don't need to calculate
max_min_version. That code should have been calculating a
"min_min_version" anyway.)
* Remove the broken all-supported-archs entry from arch_sets. It has a
few problems:
* It's redundant with the "global availability" code path above,
which is used when the declaration has no per-arch annotations.
* If this code path runs, then we generate two more guard
expressions, for !LP64 and LP64.
* Passing "" to generate_guard is broken for a non-zero version,
and for a zero version, adding an empty string to `expressions`
breaks if the vector has 2 or more expressions.
(I think consolidating per-arch info, e.g. using a single check for
__INTRODUCED_IN_32(40) __INTRODUCED_IN_64(40), is a nice idea, but
it should happen as a natural consequence of removing the
arch-independent "global availability" info in favor of always
tracking it per-arch.)
* Rewrite the arch-set guard generation. Add an optimization so that
the (__ANDROID_API__ >= N) guard for __INTRODUCED_IN_64(N) is still
useful for RISC-V as long as N is small enough. (Currently we're
checking that N is <= 10000.)
This change fixes the "preprocessor" test that run_tests.py runs. The
"slow_preprocessor_idempotence" test is still broken.
Bug: https://github.com/android/ndk/issues/1888
Test: run_tests.py
Change-Id: I3f94357465dbdb2c23fff442a31fb5083de27a97
At least one person wasn't entirely convinced by our existing riscv64
documentation, and there was an error in the 32 vs 64 section.
Test: N/A
Change-Id: Iaa08b8f4b5a5506a4ade15f81e17325185036a07
Using the AndroidLocalUnwinder object allows unwinding interpreter
and JIT'd frames by default. In addition, it simplifies the code.
Test: Forced interpreter on all of the time and forced fdtrack on
Test: and verified unwind includes dex frames.
Test: Forced JIT on all of the time and forced fdtrack on
Test: and verified unwind includes dex frames.
Test: Unit tests pass.
Change-Id: Icae17e83c9aaa04750b07471243550a7829524f7
Neither is great, but "gp" seems actively misleading (and setjmp.S
says x3 every time, so we should be consistent if nothing else).
Bug: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/379
Test: treehugger
Change-Id: Ibccda74d4794caa770b82e7ba2e31ce7b645b83f
We don't actually care about the length of this jump, and lld will relax
it to a jal when possible anyway. Better to have people copy & paste
call and tail than jal and j.
Test: treehugger
Change-Id: I889044b95fbb5567189a0d6ef31f81df0e0383cd
The only remaining differences between vfprintf.cpp and vfwprintf.cpp
after this are the wide/narrow conversions for %c, %m, and %s. I've used
"chars" and "bytes" for the named constants for the directions because
(a) I find -1 and 1 pretty confusing and (b) although "narrow" is the
obvious opposite of "wide", only Windows actually moved to wide
characters, so "narrow" (aka "multibyte", and probably "utf8") is the
default/normal case. Even though C confuses bytes and characters via its
`char` type, "bytes" versus "chars" seems like the appropriate
terminology (and it's what Java/Python use).
Also improve the swprintf tests assertion so failures are readable.
Test: treehugger
Change-Id: Ife8f70f65ec28d96058a7d68df353945524835d2
