similar to: [LLVMdev] PointerIntPair causing trouble

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

Hi Nicolas, On 1-May-09, at 6:32 AM, Nicolas Capens wrote: > 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. We're looking into a similar bug right now. We see the problem

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()

On May 1, 2009, at 3:40 PM, 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

On 1-May-09, at 8:35 PM, Chris Lattner wrote: > I still don't understand why this is a problem, but I decreased the > default to 2 bits. Please verify that this helps, I think I've figured out what's going on, and why no assertions are caused by this. It doesn't necessarily have anything to do with User* pointer alignment per se (although I believe that could still

On 3 Mai, 18:56, Stefanus Du Toit <stefanus.dut... at rapidmind.com> wrote: > On 1-May-09, at 8:35 PM, Chris Lattner wrote: > > > I still don't understand why this is a problem, but I decreased the > > default to 2 bits.  Please verify that this helps, > > I think I've figured out what's going on, and why no assertions are   > caused by this. It

On Mon, May 4, 2009 at 12:02 PM, Stefanus Du Toit <stefanus.dutoit at rapidmind.com> wrote: > /* snip PointerIntPair bug */ I had made a toy language a month ago to catch back up to the latest svn LLVM api and for some reason anytime I used a compare operator (<, =, or > are all this toy language has) that was inside a function definition (a prime example is this code "(begin

Hi Gabor, On 3-May-09, at 4:57 PM, Gabor Greif wrote: > Your analysis is perfectly correct. I Was AFK for the last two days, > so I couldn't > tell you this same story. Thanks, glad I was on the right track :). > The algorithm relies on the fact that the LSBit of the first "pointer" > in User > is zero. This is normally the case with VPtrs, which are

On 4-May-09, at 4:15 PM, OvermindDL1 wrote: > Actually, I am *very* curious if this is the bug. I can try to see if > it is now that I know what to look for (or if you fix it in SVN then I > will first make sure the bug still exists in mine, when it does then I > will update LLVM to the latest trunk and test again, if it was fixed > that I will be giving many thanks), but the

Hi Stefanus, Thanks for verifying this. Could you patch this or should I open a new bug report and find a generic solution first? Cheers, Nicolas From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Stefanus Du Toit Sent: woensdag 1 april 2009 18:59 To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Shuffle combine On 1-Apr-09, at 12:42

Hi, I'm trying to build llvm (git monorepo) on Ubuntu 18.04 with EXPENSIVE_CHECKS enabled and running into various errors compiling SourceMgr.cpp, depending on which host compiler I use. For example with GCC: $ CC=gcc-8 CXX=g++-8 cmake -GNinja -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON ~/git/llvm-project/llvm/ && ninja ... [89/2690] Building CXX object

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

For those curious about uses of LLVM, we just officially announced our adoption of LLVM in our products: http://www.rapidmind.com/News-Nov10-08-LLVM-OpenCL.php Thanks for all the support so far on here, we look forward to continuing to work with LLVM! -- Stefanus Du Toit <stefanus.dutoit at rapidmind.com> RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463

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

Hi Stefanus, Thanks for the info. I still think it's a bug though. Take for example a case where the vectors each have four elements. The values in Mask[] can range from 0 to 7, while HLSMask only has 4 elements. So LHSMask[Mask[i]] can go out of bounds, no? Cheers, Nicolas From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Stefanus Du

Hi Nicolas, On 2-Apr-09, at 6:04 PM, Nicolas Capens wrote: > Thanks for verifying this. Could you patch this or should I open a > new bug report and find a generic solution first? I don't have write access so the best I could do would be to submit a patch, and I'm crazy busy at the moment. I actually think the check I described below is fine and would fix this bug (but

The llvm-dev archives (and other llvm/clang mailing list archives) on the web don't seem to have any new messages since some time Monday night. Stefanus -- Stefanus Du Toit <stefanus.dutoit at rapidmind.com> RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463

On 1-Apr-09, at 12:42 PM, Nicolas Capens wrote: > Hi Stefanus, > > Thanks for the info. I still think it’s a bug though. Take for > example a case where the vectors each have four elements. The values > in Mask[] can range from 0 to 7, while HLSMask only has 4 elements. > So LHSMask[Mask[i]] can go out of bounds, no? Good point! One easy way to fix this would be to use:

Does 'make check' allow just running on a particualar directory of tests ? Many thanks in advance, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090617/e0dc48e4/attachment.html>

Hello, We've run across the following missed optimization: in the attached loop (addind.c/addind-opt.ll) there's a lookup into an array (V) using an indirect index (coming from another array, WI[k]) offset by a loop- invariant base (l). The full addressing expression can be reassociated so that we add the offset l to V's base first, and then add the indirect part. This makes