search for: pr1711

PR1711 is an x86 codegen problem that is blocking adoption of llvm-gcc by people using linux on x86-64 boxes. Could someone with access to one of these boxes take a look? I'll help try to debug this, but I don't have access to a machine. I bet it's a small tweak required in the x86...

...64> [#uses=1] %tmp20 = add i64 %tmp19, %tmp18 ; <i64> [#uses=1] %tmp21 = tail call i8* @alloca( i64 %tmp20 ) nounwind ; <i8*> [#uses=5] other allocas in that file become instructions. Andrew On 2/16/08, Chris Lattner <sabre at nondot.org> wrote: > PR1711 is an x86 codegen problem that is blocking adoption of llvm-gcc > by people using linux on x86-64 boxes. Could someone with access to > one of these boxes take a look? I'll help try to debug this, but I > don't have access to a machine. I bet it's a small tweak required in &...

..., Type::Int32Ty); > Result = Builder.CreateAlloca(Type::Int8Ty, Amt, "tmp"); > return true; > } > for a pretty (?) print of the tree at that point) This is very strange. I built a cross compiler to x86_64-unknown- linux-gnu and it seems to work for me: ./cc1 /Users/sabre/pr1711.c -emit-llvm -quiet -O2 -o - target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64- f80:128:128" target triple = "x86_64-unknown-linux-gnu" %struct.cpp_reader = type opaque define i32 @_cpp...

On 2/16/08, Chris Lattner <sabre at nondot.org> wrote: > > This is very strange. I built a cross compiler to x86_64-unknown- > linux-gnu and it seems to work for me: > > ./cc1 /Users/sabre/pr1711.c -emit-llvm -quiet -O2 -o - > > target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- > i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64- > f80:128:128" > target triple = "x86_64-unknown-linux-gnu" > %struct.cpp_read...

Joachim Durchholz wrote: > Since llvm cannot generate code for amd64 at this time, this translates > to an additional constraint on --target, restricting me to --target=i686 > only. llvm can generate code for amd64, but shared libs don't work, and bootstrapping doesn't work (PR1711). Still, if you want to compile it as 32-bit, does it work if you run configure like this (without any build,host, target): $ linux32 ./configure It should make all tools believe you are on 32-bit: $ linux32 uname -m i686 $ uname -m x86_64 --Edwin

See the bug for a reduction and the gimple trees. validate_arglist definately is rejecting the arglist in EmitBuiltinAlloca. (try: bool TreeToLLVM::EmitBuiltinAlloca(tree exp, Value *&Result) { tree arglist = TREE_OPERAND(exp, 1); if (!validate_arglist(arglist, INTEGER_TYPE, VOID_TYPE)) { debug_tree(arglist); return false; } Value *Amt = Emit(TREE_VALUE(arglist), 0); Amt =

Am Samstag, den 01.03.2008, 10:57 -0800 schrieb Chris Lattner: > > # Configure & install > > $ cd llvm-2.2 > > # I'm trying the --build option, too. > > $ ./configure --prefix=$HOME CC=gcc-4.2 CXX=g++-4.2 \ > > --build=x86_64-pc-linux-gnu \ > > --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu > > This is probably the problem. It sounds like

Hello, I am trying to build llvm-gcc 4.2 w/ llvm 2.2 on FreeBSD/amd64 and have found that it doesn't seem to want to build shared libraries. I've found numerous notes that I should try --disable-shared, because the linker ends up erroring out with a linker error when building libgcc_s.so. Subsequently, the same error is produced when it attempts to build libstdc++.so. If you do happen to

...%tmp19, %tmp18 ; <i64> [#uses=1] > %tmp21 = tail call i8* @alloca( i64 %tmp20 ) nounwind > ; <i8*> [#uses=5] > > other allocas in that file become instructions. > > Andrew > > On 2/16/08, Chris Lattner <sabre at nondot.org> wrote: > > PR1711 is an x86 codegen problem that is blocking adoption of llvm-gcc > > by people using linux on x86-64 boxes. Could someone with access to > > one of these boxes take a look? I'll help try to debug this, but I > > don't have access to a machine. I bet it's a small twea...