rupprecht added a comment.
In https://reviews.llvm.org/D52398#1257133, @aaronpuchert wrote:
> In https://reviews.llvm.org/D52398#1257092, @rupprecht wrote:
>
> > I patched the proposed fix-forward and it seems to have things building
> > again. Is there an ETA on landing that? If it's going to
aaronpuchert added a comment.
In https://reviews.llvm.org/D52398#1257092, @rupprecht wrote:
> I patched the proposed fix-forward and it seems to have things building
> again. Is there an ETA on landing that? If it's going to take a bit, is there
> any chance we could revert this patch until
rupprecht added a comment.
In https://reviews.llvm.org/D52398#1255290, @aaronpuchert wrote:
> @hokein Please have a look at https://reviews.llvm.org/D52888, maybe you can
> try it out already. The problem was that `?:` expressions are considered a
> branch point and when merging both branches
aaronpuchert added a comment.
@hokein Please have a look at https://reviews.llvm.org/D52888, maybe you can
try it out already. The problem was that `?:` expressions are considered a
branch point and when merging both branches the warning was emitted. Before
this change, we couldn't look into
hokein added a comment.
In https://reviews.llvm.org/D52398#1255218, @aaronpuchert wrote:
> In https://reviews.llvm.org/D52398#1255148, @hokein wrote:
>
> > Hi, @aaronpuchert, the patch has caused many new warnings in our internal
> > codebase, below is a reduced one. Do you mind reverting the
aaronpuchert added a comment.
In https://reviews.llvm.org/D52398#1255148, @hokein wrote:
> Hi, @aaronpuchert, the patch has caused many new warnings in our internal
> codebase, below is a reduced one. Do you mind reverting the patch?
>
> // if the condition is not true, CHECK will terminate
hokein added a comment.
Hi, @aaronpuchert, the patch has caused many new warnings in our internal
codebase, below is a reduced one. Do you mind reverting the patch?
// if the condition is not true, CHECK will terminate the program.
#define CHECK(condition) (__builtin_expect((condition),
This revision was automatically updated to reflect the committed changes.
Closed by commit rL343681: Thread safety analysis: Unwrap __builtin_expect in
getTrylockCallExpr (authored by aaronpuchert, committed by ).
Herald added a subscriber: llvm-commits.
Repository:
rL LLVM
aaron.ballman added a comment.
In https://reviews.llvm.org/D52398#1251894, @aaronpuchert wrote:
> @delesley Any objections to this?
>
> It's certainly useful for our code base, because our `assert`-like macros use
> `__builtin_expect`, but I'm not sure if that applies to the general public.
I
aaronpuchert added a comment.
@delesley Any objections to this?
It's certainly useful for our code base, because our `assert`-like macros use
`__builtin_expect`, but I'm not sure if that applies to the general public.
Repository:
rC Clang
https://reviews.llvm.org/D52398
aaron.ballman added a comment.
In https://reviews.llvm.org/D52398#1244074, @aaronpuchert wrote:
> No problem. Thanks for reviewing! I'm terribly sorry to be bombarding the two
> of you with so many review requests lately, and I hope it'll soon be over.
No apologies necessary -- I love and
aaronpuchert added a comment.
No problem. Thanks for reviewing! I'm terribly sorry to be bombarding the two
of you with so many review requests lately, and I hope it'll soon be over.
Repository:
rC Clang
https://reviews.llvm.org/D52398
___
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.
LGTM, but you should give @delesley a chance to weigh in before you commit.
Repository:
rC Clang
https://reviews.llvm.org/D52398
aaronpuchert created this revision.
aaronpuchert added reviewers: aaron.ballman, delesley.
Herald added subscribers: cfe-commits, kristina.
When people are really sure they'll get the lock they sometimes use
__builtin_expect. It's also used by some assertion implementations.
Asserting that
14 matches
Mail list logo