[PATCH] D17741: adds __FILE_BASENAME__ builtin macro

2018-04-13 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz updated this revision to Diff 142499. weimingz edited the summary of this revision. weimingz added a comment. split the original into two parts. This one supports -ffile-macro-prefix-to-remove function. I locally verified it. To add a test case, do we need to use VFS? https://reviews

[PATCH] D41316: [libcxx] Allow random_device to be built optionally

2018-04-05 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz added a comment. Thanks Eli! Repository: rCXX libc++ https://reviews.llvm.org/D41316 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D41316: [libcxx] Allow random_device to be built optionally

2018-03-05 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz added a comment. gentle ping? https://reviews.llvm.org/D41316 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D41316: [libcxx] Allow random_device to be built optionally

2018-02-23 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz added a comment. ping? https://reviews.llvm.org/D41316 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D41316: [libcxx] Allow random_device to be built optionally

2018-02-12 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz updated this revision to Diff 133977. weimingz added a comment. Modified the random generator in filesystem_test_helper to use high_resolution_clock as seed. https://reviews.llvm.org/D41316 Files: CMakeLists.txt include/__config_site.in include/random src/random.cpp test/std

[PATCH] D41316: [libcxx] Allow random_device to be built optionally

2018-02-09 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz added a comment. ping? Repository: rCXX libc++ https://reviews.llvm.org/D41316 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D41316: [libcxx] Allow random_device to be built optionally

2018-01-30 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz updated this revision to Diff 132089. weimingz added a comment. Herald added a subscriber: hintonda. Disable tests that depend on random_device. filesystem tests rely on random_device as seed to create random path. Although it's possible to avoid the random_device but if the build targe

[PATCH] D41316: [libcxx] Allow random_device to be built optionally

2018-01-11 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz added a comment. any suggestions? Repository: rCXX libc++ https://reviews.llvm.org/D41316 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D41316: [libcxx] Allow random_device to be built optionally

2018-01-05 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz added a comment. 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 compar

[PATCH] D41316: [libcxx] Allow random_device to be built optionally

2018-01-02 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz added a comment. Should we go with current patch? or provide a srand/rand based implementation as an option? Repository: rCXX libc++ https://reviews.llvm.org/D41316 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.ll

[PATCH] D41316: [libcxx] Allow random_device to be built optionally

2017-12-16 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz added a comment. Does it make sense to provide an implementation based on C99 rand? like #ifdef _LIBCPP_USING_C99_RANDOM srand(0), rand() Repository: rCXX libc++ https://reviews.llvm.org/D41316 ___ cfe-commits mailing list cfe-commi

[PATCH] D41316: [libcxx] Allow random_device to be built optionally

2017-12-15 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz created this revision. weimingz added reviewers: EricWF, bcain. Herald added a subscriber: mgorny. The default implementation of random_device uses /dev/urandom, which may not be available to systems like bare-metals. This patch adds a CMake option "LIBCXX_ENABLE_RANDOM_DEVICE" to contr

[PATCH] D35235: [libc++] Replace __sync_* functions with __libcpp_atomic_* functions

2017-09-19 Thread Weiming Zhao via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes. Closed by commit rL313694: [libc++] Replace __sync_* functions with __libcpp_atomic_* functions (authored by weimingz). Changed prior to commit: https://reviews.llvm.org/D35235?vs=115918&id=115922#toc Repository: rL LL

[PATCH] D35235: [libc++] Replace __sync_* functions with __libcpp_atomic_* functions

2017-09-19 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz updated this revision to Diff 115918. weimingz added a comment. minor change https://reviews.llvm.org/D35235 Files: src/exception.cpp src/include/atomic_support.h src/include/refstring.h src/locale.cpp src/new.cpp src/support/runtime/exception_fallback.ipp src/support/run

[PATCH] D35235: [libc++] Replace __sync_* functions with __libcpp_atomic_* functions

2017-09-19 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz updated this revision to Diff 115891. weimingz added a comment. Moved the inclusion from stdexcept.cpp into refstring.h For exception.cpp and new.cpp, I think it's better to keep the inclusion there. Those files include new_handler_fallback.ipp, exception_fallback.ipp, which need the

[PATCH] D36555: Move x86-specific sources to x86-specific source lists.

2017-08-22 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz added inline comments. Comment at: compiler-rt/lib/builtins/CMakeLists.txt:483 +set(powerpc64le_SOURCES ${powerpc64_SOURCES}) + set(wasm32_SOURCES ${GENERIC_SOURCES}) why these files were not used before? should the change be in a separate patch? or up

[PATCH] D36555: Move x86-specific sources to x86-specific source lists.

2017-08-22 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz added reviewers: rengolin, compnerd. weimingz added a comment. LGTM. Adding Renato and Saleem to approve. https://reviews.llvm.org/D36555 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo

[PATCH] D36249: Mark tests that need intel 80-bit floats as x86-only

2017-08-03 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz added a comment. In https://reviews.llvm.org/D36249#830645, @saugustine wrote: > In https://reviews.llvm.org/D36249#830121, @weimingz wrote: > > > I tried to address it via checking pre-defined macros: > > https://reviews.llvm.org/D31573 > > > > As long as the macros are defined correct

[PATCH] D36249: Mark tests that need intel 80-bit floats as x86-only

2017-08-02 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz added a comment. I tried to address it via checking pre-defined macros: https://reviews.llvm.org/D31573 As long as the macros are defined correctly by clang, we don't need to worry about the specific target machine. How do you think about it? Repository: rL LLVM https://reviews.llv

[PATCH] D32918: [ARM] Limit the diagnose when an ISR calls a regular function

2017-05-05 Thread Weiming Zhao via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes. Closed by commit rL302274: [ARM] Limit the diagnose when an ISR calls a regular function (authored by weimingz). Changed prior to commit: https://reviews.llvm.org/D32918?vs=97996&id=98001#toc Repository: rL LLVM https

[PATCH] D32918: [ARM] Limit the diagnose when an ISR calls a regular function

2017-05-05 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz created this revision. Herald added subscribers: javed.absar, rengolin, aemerson. When the function is compiled with soft-float or on CPU with no FPU, we don't need to diagnose for a call from an ISR to a regular function. Repository: rL LLVM https://reviews.llvm.org/D32918 Files:

[PATCH] D25157: [compiler-rt] [cmake] Respect COMPILER_RT_BUILD_* for libs, headers and tests

2017-03-29 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz added a comment. Looks good to me but I'm not very familiar with the build of sanitizer and xray. https://reviews.llvm.org/D25157 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com

[PATCH] D28526: [ARM] Add diagnostics when initialization global variables with ropi/rwpi

2017-02-02 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz added a comment. ping ? https://reviews.llvm.org/D28526 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28526: [ARM] Add diagnostics when initialization global variables with ropi/rwpi

2017-01-23 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz updated this revision to Diff 85446. weimingz edited the summary of this revision. weimingz added a comment. As Eli sugguested, it's better to check it in Sema. In order to access RelocationModel in Sema, we moved it from CodeGenOpts to LangOpts https://reviews.llvm.org/D28526 Files:

[PATCH] D28526: [ARM] Add diagnostics when initialization global variables with ropi/rwpi

2017-01-10 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz added a comment. Hi Eli, Thanks for the comments! I though of implementation in Sema and I actually experimented a little bit. Then it seemed that the CodeGenOpts is only available in the CGM. Any ideas? https://reviews.llvm.org/D28526 _

[PATCH] D28526: [ARM] Add diagnostics when initialization global variables with ropi/rwpi

2017-01-10 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz created this revision. weimingz added reviewers: olista01, jmolloy. weimingz added a subscriber: cfe-commits. Herald added subscribers: rengolin, aemerson. This patch adds diagnoses when initializing a global variable using the address of another global variable that uses ROPI/RWPI reloc

[PATCH] D27898: [compiler-rt] [builtins] Implement __floattitf() & __floatuntitf()

2016-12-21 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz added a comment. The patch looks good to me. https://reviews.llvm.org/D27898 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D27898: [compiler-rt] [builtins] Implement __floattitf() & __floatuntitf()

2016-12-21 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz added a comment. Thanks for the formatting. Regarding the refactoring, Regarding factoring out common code, I think it's OK to do it in a follow-up patch. For readability, it should be OK. For example, fp_add_impl.inc is used by float, double and long double. https://reviews.llvm.org

[PATCH] D27898: [compiler-rt] [builtins] Implement __floattitf() & __floatuntitf()

2016-12-20 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz added a comment. The code looks OK except for the formatting. Since the logic is almost the same as floattixf / floatuntixf except that some constants are different, I'm wondering if it makes sense to reuse the existing code? For example, make existing code as floattixf_impl.inc ==