search for: eltti

On Jan 16, 2010, at 11:15 AM, Talin wrote: > OK here's the patch for real this time :) > > On Fri, Jan 15, 2010 at 4:36 PM, Talin <viridia at gmail.com> wrote: > Here's a work in progress of the union patch. Note that the test > "union.ll" does not work, so you probably don't want to check this > in as is. However, I'd be interested in any

OK here's a new version of the patch - and the unions.ll test actually passes :) On Mon, Jan 18, 2010 at 1:40 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 16, 2010, at 11:15 AM, Talin wrote: > > OK here's the patch for real this time :) >> >> On Fri, Jan 15, 2010 at 4:36 PM, Talin <viridia at gmail.com> wrote: >> Here's a work

I've made all the suggested changes - however, I'm having a bit of problem running the tests. I started "make check" and several hours later it had only made it through about 1/3 of the tests. I'm not sure what the deal is. On Mon, Jan 18, 2010 at 1:40 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 16, 2010, at 11:15 AM, Talin wrote: > > OK

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

OK here's the patch for real this time :) On Fri, Jan 15, 2010 at 4:36 PM, Talin <viridia at gmail.com> wrote: > Here's a work in progress of the union patch. Note that the test "union.ll" > does not work, so you probably don't want to check this in as is. However, > I'd be interested in any feedback you're willing to give. > > -- > -- Talin

Here's a work in progress of the union patch. Note that the test "union.ll" does not work, so you probably don't want to check this in as is. However, I'd be interested in any feedback you're willing to give. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Tue, Jun 24, 2014 at 2:38 PM, Adrian Prantl <aprantl at apple.com> wrote: > I will take this. > > !5 = metadata !{metadata !"./test.h", metadata !"/Volumes/Data/radar/17052973"} > !6 = metadata !{i32 786489, metadata !5, null, metadata !"test", i32 1} ; [ DW_TAG_namespace ] [test] [line 1] > !4 = metadata !{i32 786434, metadata !5, metadata !6,

On Jul 13, 2011, at 4:26 AM, Anton Lokhmotov wrote: > Hi Chris, > > We have updated the half patch for TOT. Could you review please? Sorry for the delay, some thoughts: +++ b/include/llvm/Bitcode/LLVMBitCodes.h @@ -110,10 +110,12 @@ namespace bitc { TYPE_CODE_METADATA = 16, // METADATA TYPE_CODE_X86_MMX = 17, // X86 MMX + + TYPE_CODE_HALF = 18, // IEEE

Given this small program: > #include <llvm/DerivedTypes.h> > #include <llvm/LLVMContext.h> > > using namespace llvm; > > int main( int argc, char const *argv[] ) { > LLVMContext &ctx = getGlobalContext(); > > Type *void_type( Type::getVoidTy( ctx ) ); > PointerType *void_ptr_type( void_type->getPointerTo() ); > > return 0; > }

ping... On Thu, Jan 28, 2010 at 12:25 PM, Talin <viridia at gmail.com> wrote: > OK here's a new version of the patch - and the unions.ll test actually > passes :) > > On Mon, Jan 18, 2010 at 1:40 PM, Chris Lattner <clattner at apple.com> wrote: > >> >> On Jan 16, 2010, at 11:15 AM, Talin wrote: >> >> OK here's the patch for real this

Hello, after completing the build i get ... BUILD SUCCESSFUL Total time: 5 seconds llvm[2]: Building Release+Asserts mmtk-vmkit.jar all vmjc: /home1/public/zakkak/llvm/lib/VMCore/Type.cpp:747: static llvm::PointerType *llvm::PointerType::get(llvm::Type *, unsigned int): Assertion `EltTy && "Can't get a pointer to <null> type!"' failed. 0 vmjc

+Adrian & Manman, Looks like this is a case of non-DIRef references ending up in the IR, and thus the references not being deduplicated. This could lead to some of the IR bloat that you guys implemented the DIRef stuff to reduce/avoid. The specific issue is that the type is slightly different in the two TUs (since the namespace scope it's contained within is different in the two TUs -

Hi Fivos, I cannot reproduce on my machine (ubuntu 64bit, clang/llvm/vmkit on svn trunk). What's your configuration? Cheers, Nicolas On Tue, Jun 5, 2012 at 3:08 PM, Fivos <fivosz at gmail.com> wrote: > Hello, > > after completing the build i get > > ... > BUILD SUCCESSFUL > Total time: 5 seconds > llvm[2]: Building Release+Asserts mmtk-vmkit.jar all > vmjc:

> When compiled using the clang binaries with MinGW32 and run, I get: >> Assertion failed: isValidElementType(EltTy) && "Invalid type for pointer element!", file /Users/asl/Projects/llvm/release/3.1/src/lib/VMCore/Type.cpp, line 748 > Why? Because there is no void* in LLVM IR world -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint

Hi, My machine is running Ubuntu server 64-bit And the revision from the trunk is 158095 for llvm, clang and vmkit llvm configuration ../../llvm/configure --enable-doxygen --enable-optimized --disable-jit vmkit configuration ../../llvm/vmkit/configure --with-llvmsrc=/home1/public/zakkak/llvm/ --with-llvmobj=/home1/public/zakkak/java/llvm/

Hi Pawel, can you please pull this dragonegg patch into 3.2. I am the code owner for dragonegg. Thanks a lot, Duncan. On 28/11/12 13:44, Duncan Sands wrote: > Author: baldrick > Date: Wed Nov 28 06:44:50 2012 > New Revision: 168787 > > URL: http://llvm.org/viewvc/llvm-project?rev=168787&view=rev > Log: > Add support for GCC's vector copysign builtins, fixing

Hello, I was fiddling with TableGen (for a use that has nothing to do with a compiler but it's doesn't matter) and TableGen triggers an assertion failure on this code (I reduced the case to the minimum, it's a parsing bug): class Bli<string _t> { string t = _t; } class Bla<list<Bli> _bli> : Bli<!car(_bli).t> { } #0 0x00007ffff6ebda75 in *__GI_raise

Hi Nicolas, I thought MMTk is written in java and it is compiled by javac. retried a clean build with JIT enabled llvm configuration ../../llvm/configure --enable-doxygen --enable-optimized --enable-jit vmkit configuration ../../llvm/vmkit/configure --with-llvmsrc=/home1/public/zakkak/llvm/ --with-llvmobj=/home1/public/zakkak/java/llvm/

Hi Fovios, On Thu, Jun 7, 2012 at 3:51 PM, Foivos <fivosz at gmail.com> wrote: > Hi, > > My machine is running Ubuntu server 64-bit > And the revision from the trunk is 158095 for llvm, clang and vmkit > > llvm configuration > ../../llvm/configure --enable-doxygen --enable-optimized --disable-jit > Why do you disable the JIT? VMKit needs it to compile MMTk.

On Sep 1, 2010, at 4:35 AM, Amaury Pouly wrote: > Hello, > I was fiddling with TableGen (for a use that has nothing to do with a compiler but it's doesn't matter) and TableGen triggers an assertion failure on this code (I reduced the case to the minimum, it's a parsing bug): David, can you take a look? This is related to your lisp interpreter :) -Chris > > class