In D124207#3490324, @stellaraccident wrote:

In D124207#3490221, @mehdi_amini wrote:

per-project installation directory (useful for standalone)

Can you help me figuring out what this means? (which part of the code change does something about this here?)

Doesn't look like it applies to this patch. Maybe leaking from a related patch.

I wasn't sure who to ask either.

FWIW this isn't quite enough for MLIR standalone but helps get things there. One issue is that the use of LLVM's TableGen.cmake instead of our own means that mlir-tblgen wants to be installed to LLVM_TOOLS_INSTALL_DIR which isn't great when building MLIR separately from LLVM (and keeping installation paths separate, such as for packaging purposes).

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.

Okay, that makes sense. Thanks for accommodating my use-case anyway! :D.

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.

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!!

In 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 a few weeks internally without any issues:
https://github.com/apple/swift-clang/commit/3ebe7d87b9d545aebdd80452d0b79695ff871bce

Don't mean to block this, but just FYI I won't be able to look into this carefully until later this week (sorry!).

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 offset) is a signed expression[1].
(we also tracked conversions and whatnot, so... well things were different. Anyway, sorry for missing this!)

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 time around).

In D20322#750438, @regehr wrote:

In D20322#750381, @vsk wrote:

Hi @dtzWill, I have some time to work on this, and would be happy to implement the changes suggested by @rsmith. Let me know if it's all right for me to take a stab at this.

I"m not @dtzWill but I'm guessing he'll be happy for you to do this (same with me)!

Sorry for the delay!

In D29369#673064, @vsk wrote:

In 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, since this reduces the friction of debugging a ubsan-instrumented project.

After some thought, can we discuss why this is a good idea?

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.

In D28336#658899, @rampitec wrote:

In D28336#658696, @dtzWill wrote:

Looks like this was fixed for NVPTX in r293256, Hexagon earlier. Can confirm resolves the issue I was encountering, thanks!

(And I think you're right, it only seems to have occurred in the shared library variants)

But now undefined reference in AMDGPU haha, but not relating to PassManagerBuilder :).

Thanks and sorry I did not notice it right away. For some reason my builds do work, just as Linux shared build I did right now. Do you still see error building AMDGPU or is it already fixed as well?

Looks like this was fixed for NVPTX in r293256, Hexagon earlier. Can confirm resolves the issue I was encountering, thanks!

Breaks build on other platforms too, for example: http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/1928/steps/build%20stage%201/logs/stdio

Thanks for the fix!

+1, I've been using trunk with this revision reverted since I need liblldELF as well. Would it fix all use cases if we added bits to install the libraries to add_lld_library?

Fixed test:

// RUN: %clangxx -fsanitize=pointer-overflow %s -o %t
// RUN: %t 1 2>&1 | FileCheck %s --check-prefix=ERR
// RUN: %t 0 2>&1 | FileCheck %s --check-prefix=SAFE
// RUN: %t -1 2>&1 | FileCheck %s --check-prefix=SAFE

Hmm, this test actually is wonky if argv[0] happens to be negative when represented as intptr_t... which happens on -m32 for my machine. I'll see about constructing a better test case!