User Details
- User Since
- Apr 16 2014, 9:28 AM (492 w, 4 d)
Aug 25 2023
Only pull in required translations, instead of linking more.
Aug 23 2023
Dec 21 2022
Dec 7 2022
Dec 6 2022
This fixes an issue in the CIRCT project where virtually none of our statistics worked with threading enabled: https://github.com/llvm/circt/issues/3513 .
Sep 8 2022
Small question about usage of std::equal here, if you don't mind? Thanks!
May 6 2022
Apr 25 2022
I wasn't sure who to ask either.
Apr 21 2022
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).
Mar 19 2022
Jan 11 2018
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.
Dec 8 2017
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.
Oct 19 2017
Wow, I've finally debugged some unwind failures to this on x86_64 Linux ...
- Call-frame optimization introduces it
- This fixes the cases I was investigating!!
Jul 13 2017
Jun 13 2017
Don't mean to block this, but just FYI I won't be able to look into this carefully until later this week (sorry!).
Jun 12 2017
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!)
May 29 2017
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).
May 17 2017
May 9 2017
Feb 24 2017
Sorry for the delay!
Feb 14 2017
Feb 9 2017
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.
Jan 28 2017
Jan 27 2017
Looks like this was fixed for NVPTX in r293256, Hexagon earlier. Can confirm resolves the issue I was encountering, thanks!
Jan 26 2017
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
Jan 24 2017
Thanks for the fix!
Jan 21 2017
+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?
May 17 2016
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!