similar to: SourceMgr vs EXPENSIVE_CHECKS

Hmm. What about the errors I quoted from using clang-7 (starting about a third of the way down my email, sorry if they got kinda lost in all the noise)? Thanks, Jay. On Tue, 3 Sep 2019 at 20:00, David Blaikie <dblaikie at gmail.com> wrote: > > Looks to me like a bug in GCC's constexpr+_GLIBCXX_CONCEPT_CHECKS support. Small test case: > > $ g++-8 test.cpp -std=c++2a

I just ran into this today. Do we need to update our requirements on libstdc++ version? Jay, did you figure out a way around this? On Wed, Sep 4, 2019 at 5:29 AM David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > It's a bug in libstdc++ - so if you have clang using libstdc++ (which it will by default, I think) then it's the same thing. You could try with

I just switched gcc from 4.6.2 to 4.7.1 and see the massive amount of warnings, see few examples below. They mostly didn't exist with gcc-4.6.2. rev.159224 Yuri /usr/home/yuri/llvm-2012-06/latest-unpatched/llvm-fix/include/llvm/ADT/PointerUnion.h:56:10: warning: enumeral mismatch in conditional expression:

When compiling trunk using gcc 4.1.2 on linux/ppc64, I now see a warning that I don't remember seeing previously: llvm[2]: Compiling InlineSpiller.cpp for Release+Asserts build /src/llvm-trunk-dev/include/llvm/ADT/PointerIntPair.h: In member function ‘const PointerTy* llvm::PointerIntPair<PointerTy, IntBits, IntType, PtrTraits>::getAddrOfPointer() const [with PointerTy = void*, unsigned

Johannes, This patch seems to be causing test failures when I just do "ninja check", without running "ninja" or "ninja all" first. $ CC=clang CXX=clang++ cmake -G Ninja ~/git/llvm-project/llvm -DLLVM_USE_LINKER=lld -DLLVM_PARALLEL_LINK_JOBS=4 -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86 && ninja check [...] FAIL: LLVM ::

Jay, Hiroshi, did [0] resolve the problem you've seen. [0] https://github.com/llvm/llvm-project/commit/d23c61490c282a7a8f29aaa5c021cbfdaf87fb6f On 12/10, Doerfert, Johannes wrote: > I think the problem is that only clang has a dependence on the new > library and when you check LLVM without building clang it does not exist > yet. I will commit a LLVM patch today that will cause LLVM

This seems to be happening to me, too. I think this happens for me on "ninja check-llvm" in a clean build. Let me know if you need more info. On Tue, Dec 10, 2019 at 2:22 PM Doerfert, Johannes via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Jay, > > I am not sure why this happens. > Can you give me some information so I can reproduce it: > Is this happens

I tried to reduce the test case in https://bugs.llvm.org/show_bug.cgi?id=42706. Here it is crashing opt: $ ~/llvm-debug/bin/opt -use-gpu-divergence-analysis -divergence stripped.ll WARNING: You're attempting to print out a bitcode file. This is inadvisable as it may cause display problems. If you REALLY want to taste LLVM bitcode first-hand, you can force output with the `-f' option.

around line 45 a bitmask is computed as: PointerBitMask = ~(uintptr_t)(((intptr_t)1 << PtrTraits::NumLowBitsAvailable)-1), my question is why is the shift performed on intptr_t? Wouldn't the following be ok? PointerBitMask = ~(((uintptr_t)1 << PtrTraits::NumLowBitsAvailable)-1), Thanks in advance, Maurizio

Hi all, I've located a regression that causes my project to crash. It's in revision 67979, where PointerIntPair is changed from storing the integer in the upper bits instead of the lower bits. My project is an experimental JIT-compiler in Windows. So I was wondering if anyone had any clue why the new PointerIntPair implementation might fail. It doesn't seem very safe to me to

Hi Nicolas, Looks like Preston and I have found the cause of the problem. The issue is with PointerLikeTypeTraits<T*>::NumLowBitsAvailable. This is set to 3, which basically assumes that unless the traits are specialized for a particular pointer type, objects of that type are allocated with malloc() and aligned to 8 bytes. While PointerLikeTypeTraits is overloaded for Use*, it is

Changing a header file somewhere and having to spend 10 minutes waiting for a build leads to a lot of wasted developer time. The real culprit here is tablegen. Can we split support and ADT into two - the parts that tablegen depends on and the parts that it doesn't? >From what I can gather, Tablegen currently depends on these headers and all of their transitive dependencies. #include

On Oct 8, 2009, at 10:50 AM, Maurizio Vitale wrote: > around line 45 a bitmask is computed as: > > PointerBitMask = > ~(uintptr_t)(((intptr_t)1 << PtrTraits::NumLowBitsAvailable)-1), > > my question is why is the shift performed on intptr_t? Wouldn't the > following be ok? > > PointerBitMask = > ~(((uintptr_t)1 <<

>>>>> "Chris" == Chris Lattner <clattner at apple.com> writes: Chris> On Oct 8, 2009, at 10:50 AM, Maurizio Vitale wrote: > around line 45 a bitmask is computed as: >> >> PointerBitMask = ~(uintptr_t)(((intptr_t)1 << >> PtrTraits::NumLowBitsAvailable)-1), >> >> my question is why is the shift

On 2009-05-01, at 18:40, Stefanus Du Toit wrote: > Hi Nicolas, > > Looks like Preston and I have found the cause of the problem. The > issue is with PointerLikeTypeTraits<T*>::NumLowBitsAvailable. This > is set to 3, which basically assumes that unless the traits are > specialized for a particular pointer type, objects of that type are > allocated with malloc()

-Wenum-compare is buggy / bogus. We should turn this warning off in our build scripts if possible. On Tue, Jun 26, 2012 at 5:15 PM, Yuri <yuri at rawbw.com> wrote: > I just switched gcc from 4.6.2 to 4.7.1 and see the massive amount of > warnings, see few examples below. > They mostly didn't exist with gcc-4.6.2. > > rev.159224 > > Yuri > > >

It would be better, because a debug tablegen is slower than an optimized tablegen, but it's still slow and it doesn't address the problem that tablegen runs *at all* when it doesn't really need to. I think if tablegen wasn't running all the time we could incremental builds down from 15 minutes (and that's on my really powerful machine) to under 5, which seemed like a big

Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> writes: > Hi Varun, > > I'm definitely in favour of making -v more useful like this. > > On Thu, 12 Sep 2019 at 19:31, Varun Gandhi via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Option 2 (less deviation from status quo): >> -v: Adopts behavior of -vvv from Option 1. :) >> -vv: Same

I thought we already did write tablegen output to temporary files like X86GenAsmWriter1.inc.tmp first and then diffed them with the real .inc file and conditionally copied. ~Craig On Sat, May 27, 2017 at 11:02 AM, David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Fri, May 26, 2017 at 8:06 PM Zachary Turner via llvm-dev < > llvm-dev at

It's that TableGen depends on Support, so if you change one file in support, support gets recompiled into a new static archive, which triggers a rerun of tablegen on all the tablegen inputs, which is extremely slow. On Fri, May 26, 2017 at 5:56 PM Hal Finkel <hfinkel at anl.gov> wrote: > > > On 05/26/2017 07:47 PM, Zachary Turner via llvm-dev wrote: > > Changing a header