- User Since
- Nov 19 2012, 2:50 AM (244 w, 11 h)
Tue, Jul 18
Mon, Jul 17
rebased after reverting r307595 and moving __refstring header
Fri, Jul 14
Thu, Jul 13
Mon, Jul 10
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
Sun, Jul 9
Thu, Jul 6
@EricWF , do you mean factoring out the __sync_* functions like this?
Wed, Jul 5
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.
Mon, Jul 3
Fri, Jun 30
Mon, Jun 26
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 )
I guess HAS_80_BIT_LONG_DOUBLE is passed as some build-time flags. I can't find it anywhere in the compiler-rt source tree that defines it.
Apr 2 2017
I see. Should we mark the test as "Unsupported" for aarch64?
Apr 1 2017
After we agree on the patch, __fixxfti() will be fixed similarly.
Mar 29 2017
The same test passed on
But failed on
Looks good to me but I'm not very familiar with the build of sanitizer and xray.
pushed r298997 that removes XFAIL
We can remove the XFAIL for now
Interestingly, mulsc3_test.c XPASSed. Looks like the compiltion line has no hardfp flag, so the problem was not exposed. In my local build.
Mar 28 2017
Mar 27 2017
it was commited by mistake and was reverted immediately.
Mar 24 2017
Mar 23 2017
It's part of already-accepted patch ((https://reviews.llvm.org/D30802)
Will re-land it.
Mar 22 2017
need to include builtin-config-ix to get the right ARM32 variable.
This patch *should* address the issue of buildbot of powerpc (http://lab.llvm.org:8011/builders/sanitizer-ppc64le-linux/builds/1703).
I was using
It should be
Mar 21 2017