dtzWill added a comment.
Ping! Is this stalling on reviewer attention? If so, please submit to LLVM
Weekly's review corner (assuming it works with current LLVM), see
http://llvmweekly.org/reviewcorner for details.
Repository:
rL LLVM
https://reviews.llvm.org/D28462
__
dtzWill added a comment.
Okay, that makes sense. Thanks for accommodating my use-case anyway! :D.
Repository:
rL LLVM
https://reviews.llvm.org/D40685
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/l
dtzWill added a comment.
Hmm, this change means very recent LLVM is required to build libunwind--
previously I was able to use recent libunwind/libcxx/libcxxabi with LLVM 5 and
LLVM 4.
Other runtime projects (compiler-rt, libcxx, libcxxabi) were modified to
support the new "strip-and-install"
dtzWill added a comment.
Wow, I've finally debugged some unwind failures to this on x86_64 Linux ...
1. Call-frame optimization introduces it
2. This fixes the cases I was investigating!!
Thank you!
https://reviews.llvm.org/D38680
___
cfe-commits
dtzWill added a comment.
In https://reviews.llvm.org/D34121#806978, @vsk wrote:
> @dtzWill do you have any further comments on this one?
>
> I'd like to get another 'lgtm' before committing, and it'd be nice to get
> this in before llvm 5.0 branches (7/19).
>
> FWIW we've been living on this for
dtzWill added a comment.
Don't mean to block this, but just FYI I won't be able to look into this
carefully until later this week (sorry!).
Kicked off a rebuild using these patches just now, though! O:)
https://reviews.llvm.org/D34121
___
cfe-comm
dtzWill accepted this revision.
dtzWill added a comment.
LGTM!
Sorry for missing this originally, as a perhaps interesting note:
the checks were extracted from a research prototype that worked at the IR level
--where pointer itself is unsigned but the offsets (including the computed
total offse
dtzWill added a comment.
LGTM!
I've built quite a bit with this (ground-up Linux distribution) which attests
to it being fairly robust (no crashing or new errors not experienced with
unpatched clang) and the bugs found so far are all true positives (few of which
were caught and reported last t
dtzWill accepted this revision.
dtzWill added a comment.
This revision is now accepted and ready to land.
Sorry for the delay!
LGTM, thanks!
https://reviews.llvm.org/D29369
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.o
dtzWill added a comment.
In https://reviews.llvm.org/D29369#673064, @vsk wrote:
> In https://reviews.llvm.org/D29369#672166, @dtzWill wrote:
>
> > After some thought, can we discuss why this is a good idea?
>
>
> The goal is to lower ubsan's compile-time + instrumentation overhead at -O0,
> sinc
dtzWill requested changes to this revision.
dtzWill added a comment.
This revision now requires changes to proceed.
After some thought, can we discuss why this is a good idea?
This increases the cyclomatic complexity of code that already is difficult to
reason about, and seems like it's both bri
dtzWill accepted this revision.
dtzWill added a comment.
I've been bitten when attempting to use existence/nature of casts in the AST to
reason about the original code, but this looks like it does the right thing in
all the situations I can think of.
Missing overflows because of a bugged attemp
12 matches
Mail list logo