similar to: [LLVMdev] CVS Broken?

On Fri, 7 Apr 2006, Robert L. Bocchino Jr. wrote: > I just updated from CVS, and after doing a clean rebuild I get this error: Are you sure that no conflicts prevented updating from going smoothly? How are you building (srcdir ==/!= objdir)? -Chris > /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h: In static > member function 'static bool

I did a utils/cvsupdate, and there are no conflicts. srcdir != objdir. This is on persephone. Are you not getting this error? Perhaps I should check out a fresh tree and try to compile it? Rob On Apr 7, 2006, at 11:40 AM, Chris Lattner wrote: > On Fri, 7 Apr 2006, Robert L. Bocchino Jr. wrote: >> I just updated from CVS, and after doing a clean rebuild I get >> this

I've done several CVS head builds today .. no problems on Linux. Reid. On Fri, 2006-04-07 at 11:53 -0500, Chris Lattner wrote: > On Fri, 7 Apr 2006, Robert L. Bocchino Jr. wrote: > > > I did a utils/cvsupdate, and there are no conflicts. srcdir != objdir. This > > is on persephone. > > > > Are you not getting this error? Perhaps I should check out a fresh

On Fri, 7 Apr 2006, Robert L. Bocchino Jr. wrote: > I did a utils/cvsupdate, and there are no conflicts. srcdir != objdir. This > is on persephone. > > Are you not getting this error? Perhaps I should check out a fresh tree and > try to compile it? Nope, I don't think anyone else is getting this error. If you could try a fresh build that would be great, I'll fire

I'm guessing the problem occurred because I hadn't updated in a while (maybe a couple of weeks?) and I had an old Intrinsics.gen file hanging around in my source directory that was getting picked up by the makefile for some reason. This is a bug, but maybe it's harmless because there's a onetime workaround (delete the file by hand) and it won't be a problem for

OK, when I copy $(SRCDIR)/include/llvm/Intrinsics.gen to $(OBJDIR)/ include/llvm/ by hand after building (and failing) once, the build succeeds. This is definitely a makefile bug. Rob On Apr 7, 2006, at 11:40 AM, Chris Lattner wrote: > On Fri, 7 Apr 2006, Robert L. Bocchino Jr. wrote: >> I just updated from CVS, and after doing a clean rebuild I get >> this error: > >

On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote: > On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at gcc.gnu.org> > wrote: >> >> On Aug 21, 2009, at 8:46 PM, Eli Friedman wrote: >> >>> On Fri, Aug 21, 2009 at 3:29 PM, Jakub Staszak<kuba at gcc.gnu.org> >>> wrote: >>>> >>>> On Aug 21, 2009, at 7:31 PM, Eli

On Aug 21, 2009, at 10:27 PM, Eli Friedman wrote: > On Fri, Aug 21, 2009 at 5:05 PM, Jakub Staszak<kuba at gcc.gnu.org> > wrote: >> >> On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote: >> >>> On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at gcc.gnu.org> >>> wrote: >>>> >>>> On Aug 21, 2009, at 8:46 PM, Eli

On Fri, Aug 21, 2009 at 5:05 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: > > On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote: > >> On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: >>> >>> On Aug 21, 2009, at 8:46 PM, Eli Friedman wrote: >>> >>>> On Fri, Aug 21, 2009 at 3:29 PM, Jakub Staszak<kuba at

On Fri, Aug 21, 2009 at 5:47 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: > > On Aug 21, 2009, at 10:27 PM, Eli Friedman wrote: > >> On Fri, Aug 21, 2009 at 5:05 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: >>> >>> On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote: >>> >>>> On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at

On Thu, Nov 29, 2012 at 7:43 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Thu, Nov 29, 2012 at 3:49 PM, David Blaikie <dblaikie at gmail.com> wrote: > > Moving to LLVM dev to discuss the possibility of extending the cast > > infrastructure to handle this. > > > > On Tue, Nov 20, 2012 at 5:51 PM, John McCall <rjmccall at apple.com> wrote:

On Thu, Nov 29, 2012 at 8:16 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Thu, Nov 29, 2012 at 7:43 PM, Eli Friedman <eli.friedman at gmail.com> > wrote: >> >> On Thu, Nov 29, 2012 at 3:49 PM, David Blaikie <dblaikie at gmail.com> wrote: >> > Moving to LLVM dev to discuss the possibility of extending the cast >> > infrastructure to

Moving to LLVM dev to discuss the possibility of extending the cast infrastructure to handle this. On Tue, Nov 20, 2012 at 5:51 PM, John McCall <rjmccall at apple.com> wrote: > On Nov 18, 2012, at 5:05 PM, David Blaikie <dblaikie at gmail.com> wrote: >> TypeLoc casting looks bogus. >> >> TypeLoc derived types return true from classof when the dynamic type >>

Ok. I'm basically just following the model of the other fast-isel ports. On 01/30/2015 09:12 PM, David Blaikie wrote: > (I'm assuming you're building LLVM with clang, in this case?) > > Looks like IntrinsicInst is one of those "lies" in LLVM that works via > type punning that's undefined behavior in C++, so it's code that > should be fixed anyway.

Here's why I was questioning the change to sample/lib/sample Makefile: make[4]: Entering directory `/proj/llvm/build/projects/sample/lib/sample' llvm[4]: Compiling sample.c for Debug build (PIC) llvm[4]: Linking Debug Shared Library sample.so llvm[4]: Linking Debug Object Library sample.o /proj/install/lib/libstdc++.a: member /proj/install/lib/libstdc++.a (allocator-inst.o) in archive is

(I'm assuming you're building LLVM with clang, in this case?) Looks like IntrinsicInst is one of those "lies" in LLVM that works via type punning that's undefined behavior in C++, so it's code that should be fixed anyway. In any case, the reason this produces the debugging experience you're seeing is that LLVM (& GCC, for that matter) assumes that if your class

On Thu, Nov 29, 2012 at 3:49 PM, David Blaikie <dblaikie at gmail.com> wrote: > Moving to LLVM dev to discuss the possibility of extending the cast > infrastructure to handle this. > > On Tue, Nov 20, 2012 at 5:51 PM, John McCall <rjmccall at apple.com> wrote: >> On Nov 18, 2012, at 5:05 PM, David Blaikie <dblaikie at gmail.com> wrote: >>> TypeLoc

On Fri, Jan 30, 2015 at 10:37 PM, reed kotler <rkotler at mips.com> wrote: > Ok. > > I'm basically just following the model of the other fast-isel ports. > Yeah, not your fault - just an architectural quirk. It's possible we could workaround the debug info side of this by declaring the virtual dtor (or some other virtual function - even an explicit anchor as we have

When trying to display and do anything with a variable of type IntrinsicInst, gdb thinks that it's an incomplete type and kind find any member functions or even display the class. (gdb) list 1337 1332 1333 // Finish off the call including any return values. 1334 return finishCall(CLI, RetVT, NumBytes); 1335 } 1336 1337 bool MipsFastISel::fastLowerIntrinsicCall(const

When I tried this a while back, the .so file wasn't being built on Mac OS X. Now it looks like it is. I got dynamic loading to work following the instructions in http://llvm.cs.uiuc.edu/docs/ WritingAnLLVMPass.html. However, there was a typo in the instructions (it should say LOADABLE_MODULE = 1), and I fixed that and committed it. I also fixed the sample/lib/sample Makefile to