similar to: [LLVMdev] Building LLVM on Linux/PowerPC failed

Hi, folks I am trying to build LLVM-GCC 4.2 on a Linux/PowerPC machine. Actually, the PowerPC is a PS3. The source was downloaded from http://llvm.org/releases/2.8/llvm-gcc-4.2-2.8.source.tgz Here is my system information and configuration options: ---------------------------------------------------------------------- $ uname -a Linux ps3 2.6.32-rc2-00995-g96ebbe6-dirty #2 SMP Fri Oct 2

陳韋任 wrote: > I am trying to build LLVM 2.8 Release on a Linux/PowerPC machine. > Actually, the PowerPC is a PS3. > > Here is my system information: > > ---------------------------------------------------------------------- > $ uname -a > Linux ps3 2.6.32-rc2-00995-g96ebbe6-dirty #2 SMP Fri Oct 2 15:12:28 CST > 2009 ppc64 Cell Broadband Engine, altivec supported

Hi, folks I am "stll" trying to build LLVM-GCC 4.2 on a Linux/PS3 machine, which has a 64-bit OS. Here is my system information and configuration options: ----------------------------------------------------------------- $ uname -a Linux ps3 2.6.32-rc2-00995-g96ebbe6-dirty #2 SMP Fri Oct 2 15:12:28 CST 2009 ppc64 Cell Broadband Engine, altivec supported GNU/Linux $ gcc --version

Per https://buildd.debian.org/build.php?pkg=r-base, we see the Alpha platform having trouble with deriv.c : gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -mieee-with-inexact -fpic -std=gnu99 -O3 -pipe -g -c deriv.c -o deriv.o deriv.c: In function 'simplify': deriv.c:267: error: unrecognizable insn: (insn 2103 64 65 9 ../../src/include/Rinlinedfuns.h:86 (set

陳韋任 wrote: > Linux ps3 2.6.32-rc2-00995-g96ebbe6-dirty #2 SMP Fri Oct 2 15:12:28 CST > 2009 ppc64 Cell Broadband Engine, altivec supported GNU/Linux Yes, the kenel is 64 bit, but you may still have a pure 32 bit userspace (thats what my dual G5 PowerMac running Linux has). Does your maching have directories like /lib64 and /usr/lib64? If you compile a program like: #include

I hate to be bothersome, but can someone please comment on this? Thanks again, Hal On Thu, 3 May 2012 14:49:04 -0500 Hal Finkel <hfinkel at anl.gov> wrote: > Hello, > > The current code in PPCTargetLowering::LowerFormalArguments_SVR4 > contains a FIXME over the code which saves the live floating-point > registers to the stack. The FIXME states that this should only be done

Hello, The current code in PPCTargetLowering::LowerFormalArguments_SVR4 contains a FIXME over the code which saves the live floating-point registers to the stack. The FIXME states that this should only be done if CR bit 6 is set. I've been told that the lack of this check is preventing clang/LLVM from compiling a functional FreeBSD kernel on PPC. Is is possible to insert another branch in

Hi, We're currently testing 1.2.x with a move from 1.1.x in mind however with the current 1.2 series we are encountering some serious problems. simply editing the main conf and restarting dovecot gives these errors seemingly randomly: (some previous posts indicated this might be todo with 64bit file offsets so we've played around with disable-largefile and setting _FILE_OFFSET_BITS

Jim, Thanks! Might it be possible to do this another way? For example, could I insert some special pseudo-instructions and then turn them into branches later on? -Hal On Thu, 10 May 2012 11:39:10 -0700 Jim Grosbach <grosbach at apple.com> wrote: > Hi Hal, > > For lowering code that requires inserting branches, you need to use a > custom inserter, yes. Theoretically, that

I installed R-2.3.1 and ran make check without problem, but I am having trouble installing several packages using gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-53) on Red Hat Enterprise Linux AS release 3 (Taroon Update 7) Kernel 2.4.21-40.ELsmp on an x86_64 Below are the messages from MCMCpack. Perhaps my systems are messed up? Paul Gilbert > install.packages("MCMCpack")

Hi Hal, For lowering code that requires inserting branches, you need to use a custom inserter, yes. Theoretically, that does indeed sound like what you want to do here. It's complicated by the general structure of argument passing, though. In particular, there's lots of assumptions about the call sequence stuff. I don't know if things are smart enough (EH in particular worries me) to

I install nouveau from git (from overlay "nouveau"). But when i try start Xorg i have black screen and blinking cursor. I use FX5200 (NV34). Xorg.log X.Org X Server 1.5.3 Release Date: 5 November 2008 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.29-gentoo-r1 i686 Current Operating System: Linux localhost 2.6.29-gentoo-r2 #1 SMP PREEMPT Sat May 2 14:23:23 MSD 2009

Hi Hal, Yes, you could definitely expand them later. Custom inserters are effectively just a very early expand pseudo instruction. You can even expand them very late in the MC lowering (asmprinter) if you really need to. That could get tricky, as you'll effectively be fibbing to the register allocator. ARM uses quite a lot of late expanded pseudo-instructions, for example, though generally

Hi all, I'm trying to implement llvm.memory.barrier on PowerPC. I've modelled my patch (attached) on the implementation in X86, but when I try and compile my test file (also attached) with llc I get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier 0x10fa4828, 0x10fa4c68, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0". This presumably means my "membarrier"

Dale Johannesen wrote: > On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > > I'm trying to implement llvm.memory.barrier on PowerPC. I've > > modelled my patch (attached) on the implementation in X86, but > > when I try and compile my test file (also attached) with llc I > > get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier > >

OK, I've checked it in for you, thanks. Please do contact Chris about write access. On Aug 22, 2008, at 12:38 AMPDT, Gary Benson wrote: > No, I don't. > > Cheers, > Gary > > Dale Johannesen wrote: >> This looks OK to check in, do you have write access? >> >> On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: >> >>> Dale Johannesen

Hi Evan, Evan Cheng wrote: > This does not patch cleanly for me (PPCISelLowering.cpp). Can you > prepare a updated patch? This should work, though I won't have access to my test box now until next Thursday so no guarantees :) Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- Index: lib/Target/PowerPC/PPCISelLowering.h

No, I don't. Cheers, Gary Dale Johannesen wrote: > This looks OK to check in, do you have write access? > > On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: > > >Dale Johannesen wrote: > >>On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > >>>I'm trying to implement llvm.memory.barrier on PowerPC. I've > >>>modelled my patch

Evan: I did not encounter this back trace before I committed the newest BuildVectorSDNode patch, which removed all class instance members and passes results back via reference parameters. -scooter On Tue, Feb 24, 2009 at 11:39 AM, Evan Cheng <evan.cheng at apple.com> wrote: > I believe this patch has broken a PPC app that I am tracking. Here is a > reduced test case. Reproduce

I believe this patch has broken a PPC app that I am tracking. Here is a reduced test case. Reproduce with llc -mattr=+Altivec -mcpu=g5. The backtrace looks like this: #0 0x9333ae42 in __kill () #1 0x9333ae34 in kill$UNIX2003 () #2 0x933ad23a in raise () #3 0x933b9679 in abort () #4 0x933ae3db in __assert_rtn () #5 0x0008bd8f in llvm::MVT::getVectorElementType (this=0xbfffdda4) at