User Details
- User Since
- Nov 6 2017, 10:05 AM (167 w, 2 d)
Yesterday
ping
Tue, Jan 19
Added static_asserts that check that SourceRange and SourceLocation are trivially destructible.
I will wait until the end of this week to see if anyone has objections.
Thu, Jan 14
This revision was landed with ongoing or failed builds.
Wed, Jan 13
Refactored SLocEntry in a similar way.
Tue, Jan 12
Mon, Jan 11
Fixed a typo in the word "implicit"
Sat, Jan 9
Removed alignas
Thu, Jan 7
Fixed formatting.
Mon, Jan 4
Wed, Dec 30
Dec 10 2020
Dec 3 2020
Hi @MaskRay, this commit broke our builds which use GCC 7.3. I've posted some comments in D92591, but have just realized that it probably was not the right place. Could you please fix the breakage?
Nov 2 2020
I guess I'll leave it in our downstream version then.
Oct 27 2020
Oct 26 2020
Oct 23 2020
Fixed linter errors.
Oct 22 2020
Reverted the accidentally removed chunk.
Addressed review comments
Oct 20 2020
The test failure is unrelated (see D89463)
Added an example of usage.
Oct 19 2020
Split out the refactoring part.
Yes, I am still interested in working on this. For now, I've split out some changes that don't require any modifications in SourceLocation into https://reviews.llvm.org/D89705.
A general comment is that there are a couple of functional changes in this patch, where hash values are changing and data structures are being changed, but they're buried in the noise of the refactoring that's going on at the same time. I suggest splitting this up at least into two
Will do.
Oct 1 2020
Customization allows storing data of OS structures such as mutexes and threads in-place, thus avoiding the need for additional dynamic memory allocations, this is important in embedded environments.
Sep 30 2020
Given this new setup where build bots are checked into the repo, I think adding a bot that test this configuration would be a good way of making sure this doesn't regress. What do you think?
Yes, setting up a build bot is part of my original plan. I will be on holiday for the next two weeks, but I do plan to continue working on this after returning.
Is there a reason why your platform can't simply provide the pthread or the C11 threading APIs, and libc++ has to provide this bridge instead?
The original intent of the external threading API was to make it usable with bare-metal real-time OS-es which tend not to have POSIX or POSIX-like APIs. For example, __libcpp_mutex_t can include the OS structure representing a mutex, instead of allocating it elsewhere.
Sep 29 2020
@ldionne, do you have any thoughts on how we might progress this forward?
Sep 28 2020
Use setenv in the parent process
Sep 25 2020
In our case, the child process fails to find the correct version of libstdc++ and exits with return code 1, ASSERT_EQ(-2, RetCode) fails.
Sep 24 2020
Sep 23 2020
Sep 11 2020
Thanks!
Hi Olivier,
Prior versions of the C++ standard (11, 14, 17) required more specialized templates for atomic_fetch_{add,sub}[_explicit] for pointers. E.g.:
template <class T> T atomic_fetch_add(atomic<T>*, T) noexcept; template <class T> T* atomic_fetch_add(atomic<T*>*, ptrdiff_t) noexcept;
Implementing them as a single template breaks the following code (when compiled as C++17):
#include <atomic>
Sep 1 2020
I've just committed D86773
Aug 28 2020
Thanks!
Aug 27 2020
Small refactoring of bitcode updater tests (use some-name.ll.bc names for bitcode files in order to be able to refer to them as %s.bc from some-name.ll)
Sorry about that. I've reverted the change and will investigate.
Aug 26 2020
- Also update bfdot
- Add auto-upgrade for old intrinsics
Cast to the correct type
Aug 21 2020
Abandoning in favour of:
Aug 20 2020
- Addressed review comments
- Added a cast back to the original type