- User Since
- Nov 19 2012, 2:50 AM (260 w, 5 d)
Thu, Nov 9
Tue, Nov 7
If compiler-rt is to provide optimized version, then, should MUSL just forwards the calls like memcpy ->__aeabi_memcpy ? Because libc is usually appear first in linking order, a standard implementation in libc will hide the optimized version in compiler-rt.
Mon, Nov 6
Should we use "ARM" instead of "Arm" ?
Sep 26 2017
LGTM. (Let Saleem to sign off)
Sep 19 2017
Moved the inclusion from stdexcept.cpp into refstring.h
Sep 6 2017
Aug 30 2017
Aug 22 2017
LGTM. Adding Renato and Saleem to approve.
Aug 15 2017
guard the "DEFINE_CODE_STATE" with "__ARM_ARCH < 6" check.
Aug 14 2017
remove unreleated change (CMakefile) and address comments from Saleem
Aug 11 2017
Aug 7 2017
And since it's an assertion, in Release build, the flag will still be accepted silently.
rebased. Please review. Thanks
Aug 3 2017
Aug 2 2017
I tried to address it via checking pre-defined macros:
Jul 31 2017
add test case
Jul 27 2017
Jul 26 2017
Jul 18 2017
Jul 17 2017
rebased after reverting r307595 and moving __refstring header
Jul 14 2017
Jul 13 2017
Jul 10 2017
I should use existing include/atomic_support.h. Will upload the patch shortly.
simplify test case
missed to upload the change to include __atomic_support header file
Jul 9 2017
Jul 6 2017
@EricWF , do you mean factoring out the __sync_* functions like this?
Jul 5 2017
How about we use "#ifdef GCC_ATOMIC_POINTER_LOCK_FREE < 2 && LIBCPP_HAS_NO_THREAD" ?
This can minimize the impact.
If the architecture doesn't support atomics (like cortex-m0), seems there is no software solution to make them signal-safe. Mutex/lock won't work.
Jul 3 2017
Jun 30 2017
Jun 26 2017
May 11 2017
May 5 2017
Apr 20 2017
Just find that one case was fixed by r297871 ARM: avoid clobbering register in v6 jump-table expansion.
Apr 19 2017
Below are the measurements of text size of benchmarks.
Build flag: "-Oz -mthumb -mcpu=cortex-m3 -fomit-frame-pointer"
Baseline has extra flag: " -mllvm -arm-favor-r4-r7=false"
This fixes some SPEC2000 fails when build for Thumb1 with -Os.
I do not upload the lit test because it's not easy to reduce to a simple/clean one as it needs specific reg alloc to show the problem.
Apr 10 2017
btw, should we use "--rtlib=compiler-rt" rather than passing the libname explicitly?
Apr 8 2017
Thanks for the info!
Apr 6 2017
I tried to use the lib name from cmake/Module/AddCompilerRT.cmake : add_compiler_rt_runtime but no luck.
And I can't find where the suffix is set in compiler-rt project.
Not sure if it is the portable way to do.
I see cmake/base-config-ix.cmake has set(CMAKE_STATIC_LIBRARY_SUFFIX_C ".lib"), but I can't find where the variable is used and not sure if we can use it in test/CMakefile.
Apr 5 2017
Thanks for the explanation. The current patch should address the problem, right?
move up the "divby0" block for the case with HW div to make the code easier to read.
I think the r7 (fp) was not set to initial SP, so it won't matter for stack-based unwinding. Anyway, use r7 now.
Apr 3 2017
these tests are the only 4 tests that use 128 bit long long.
Other tests that uses HAS_80_BIT_LONG_DOUBLE should be replaced with __LDBL_MANT_DIG__ == 64
In my view, LDBL_MANT_DIG == 64 implies HAS_80_BIT_LONG_DOUBLE, but need t to exclude MIPS as it clang BE doesn't support it.
seems no way to detect if 80-bit ldbl is supported or not. Leave it to the build time flags.
Change to HAS_80_BIT_LONG_DOUBLE just like other tests.
Also, if HAS_80_BIT_LONG_DOUBLE is not defined, we can set it if CRT_HAS_128BIT && LDBL_MANT_DIG == 64. So even if the build doesn't specify it, the test won't be skipped by mistake.
If the platform doesn't support it, the LDBL_MANT_DIG will be 53 (refer to clang/test/Preprocessor/init.c )