- User Since
- Nov 19 2012, 2:50 AM (269 w, 2 d)
Thu, Jan 11
Fri, Jan 5
We can wrap the random_device as a minstd_rand, a linear congruential enginer that a lot of C lib uses for rand().
However based on documentation, we should just provides dummy implementation which throws an exception in the constructor of random_device [1,2]
But compared with run-time exception, a link time error is better if we simply skip the implementation. Any thoughts?
Tue, Jan 2
Should we go with current patch? or provide a srand/rand based implementation as an option?
Dec 16 2017
Does it make sense to provide an implementation based on C99 rand?
Dec 15 2017
Nov 30 2017
Nov 28 2017
Nov 20 2017
Hold on. Why do we need this flag? There is no c++ code in builtins.
LGTM. Adding Saleem and Peter for confirming.
Nov 9 2017
Nov 7 2017
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.
Nov 6 2017
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.