similar to: [LLVMdev] Documentation is missing hardware platform FreeBSD on amd64 and states that Solaris/Sparc is 'working'

On Dec 13, 2010, at 10:26 AM, Yuri wrote: > Here http://llvm.org/docs/GettingStarted.html#requirements FreeBSD/amd64 > isn't mentioned. It works quite fine for me. > Yes, it should. I fixed that. Thanks! > Also, it mentions that its known to work on Solaris/V9(Ultrasparc). > Isn't this wrong since JIT isn't currently working on Sparc and is only > expected to

Hi, Is there anyone who knows about a Xen port to the SPARC v9 architecture (aka Niagara or UltraSPARC-T1)? I heard there has been some work on it, but don''t know where to find detailed information. Your help is very appreciated. Zhiyi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hello When I was using OpenSSH-2.9p2 in Solaris 8 sparcv9 (64bit) environment, I found some trouble that wtmpx has broken. The size of utmpx structure object becomes larger than 32 bit environment in sparcv9 environment.Therefore, instead of using utmpx structure object, using futmpx structure object is better. In sparcv9 environment, futmpx structure object is used instead of utmpx structure

Bryan J. Smith b.j.smith at ieee.org wrote: >Not only that, but people forget that SPARC is not sold by just Sun. >SPARC is an IEEE standard licensed under "fair and non-discriminatory" >terms. The SPARC ISA and most architectural details are freely >available. Yep - but what is your point with bringing that up? >The _majority_ of my Solaris/SPARC experience in more

Santiago, I appreciate your offer. I'm not really a kernel hacker, however I do know C and I would be willing to try if you point me in the right direction. Here is my first attempt using Debian running on an UltraSPARC: debian{root}:/root<512>strace -f -F -v brctl addbr br0 execve("/usr/sbin/brctl", ["brctl", "addbr", "br0"], [/* 16 vars */]) =

Hi Pawel, > We can not let it die and I volunteer to keep the Sparc alive! > > My SPARCstation pizzaboxes can be ready for action in a day or two. there are three sparc buildbots which are hooked up to lab.llvm.org. They are currently idle because no builders have been scheduled to use them: # gcc54 36G 0.5 GHz TI UltraSparc IIe (Hummingbird) / 1.5 GB RAM / Sun Netra T1 200 /

Invocation of randomForest() using the iris example in the help file crashes R with a segmentation fault. This happens on all of our ultraSPARC machines running Solaris 2.7. We're using R-1.4.1, compiled using Sun cc and f77 and the flags: CC=cc CFLAGS="-xO5 -xlibmil -dalign" FC=f77 FFLAGS="-xO5 -xlibmil -dalign" "make check" runs withour errors, and R has been

If I remember correctly, you get the following warning when you configure LLVM: configure:2087: WARNING: Unknown project (Stacker) won't be configured automatically That leads would lead me to believe that you need to run configure inside llvm/projects/Stacker (and inside llvm/projects/Hello) before you run gmake inside of them. I don't know for sure, but perhaps that might fix

When I try running one llvm function in JIT without optimization I get SEGV. Looking at assembly (below) I see that the local value 0xffffffffffffffe0(%rbp) is used without being ever initialized (see my comment in asm). Same code on i386 works fine, with and w/out optimization. My guess is that this is a bug in LLVM. Yuri --- llvm --- %struct.mystruct = type { i32, i8, i8, i8, i8 } define

Anton Korobeynikov wrote: > The patch is incorrect and the problems you're seeing are caused by > your patch, since sparc != sparc64. > In LLVM sense "sparc" means "sparc with ILP32 architecture model", > llvm does not support anything 64 bit in sparc world SparcTargetMachine.h file lists SparcV9TargetMachine as 64-bit machine and SparcV8TargetMachine as

Hi all, I've put together some preliminary patches to add frontend support for the sparcv9-* subtarget (ie 64-bit SPARC), modelled on the corresponding x86-64 code - do these look reasonable for inclusion? This doesn't address the codegen side of things yet (isel falls over when trying to actually emit 64-bit code), but at least bitcode generation looks correct now. Tested on

Hi, With the talk of speex possibly mis-behaving on PPC, I decided to check the big-endian architecture I have handy - the Ultrasparc. - playback of Intel platform .spx files appears fine on the Ultra 10. - encoding a .wav file and playing back on the Ultra 10 worked too. My evaluation is that it works the same on my Ultra 10 as it did on my Intel laptop. But I must say the evaluation was made

Hello > I applied the attached patch, since the name of architecture on FreeBSD is > sparc64, not sparc. There is also one more replacement sparc -> spaarc64 was > made in gcc/Makefile in llvm-gcc. The patch is incorrect and the problems you're seeing are caused by your patch, since sparc != sparc64. In LLVM sense "sparc" means "sparc with ILP32 architecture

On Wed, Sep 29, 2004 at 06:44:50PM -0400, Shukang Zhou wrote: > I met some errors when I tried to build LLVM. The tar file is > llvm-1.3.tar.gz. I am using a sparc machine with gcc 3.2.2. > > ------------- > Compiling SparcV9CodeEmitter.cpp > /uf24/zhou/research/llvm/src/lib/Target/SparcV9/SparcV9CodeEmitter.cpp: In > static member function `static void >

Hello all, Figured I'd repost this with an edited subject line, to attract attention of people with Debian On Sparc experience. Apologies in advance if this kind of thing is frowned upon :) [AR] hash/hash.o hash/hash_bigkey.o hash/hash_buf.o hash/hash_func.o hash/hash_log2.o hash/hash_page.o hash/ndbm.o btree/bt_close.o btree/bt_conv.o btree/bt_debug.o btree/bt_delete.o btree/bt_get.o

new klibc sparc build failure against gcc 4.2 ----- Forwarded message from Kilian Krause <kilian at debian.org> ----- Subject: Bug#440721: FTBFS on sparc while linking usr/klibc/libc.so From: Kilian Krause <kilian at debian.org> To: Debian Bug Tracking System <submit at bugs.debian.org> Date: Mon, 03 Sep 2007 23:35:23 +0200 Package: klibc Version: 1.5.6-2 Severity: serious

Hi, System: Netra 1405, 4x450Mhz, 4GB RAM and 2x146GB (root pool) and 2x146GB (space pool). snv_98. After a panic the system hangs on boot and manual attempts to mount (at least) one dataset in single user mode, hangs. The Panic: Dec 27 04:42:11 base ^Mpanic[cpu0]/thread=300021c1a20: Dec 27 04:42:11 base unix: [ID 521688 kern.notice] [AFT1] errID 0x00167f73.1c737868 UE Error(s) Dec 27

llvm itself compiles fine. gcc frontend has the error, see below. I applied the attached patch, since the name of architecture on FreeBSD is sparc64, not sparc. There is also one more replacement sparc -> spaarc64 was made in gcc/Makefile in llvm-gcc. FreeBSD -8.0-STABLE gcc-4.5.0 sunblade 100 Yuri gmake[2]: Leaving directory `/tmp/llvm-build/2.7/llvm-gcc-4.2-objects/libdecnumber'

I'm trying to build NUT 2.2.1 on a SunBlade 2000 running Solaris 10 (Solaris 10 11/06 s10s_u3wos_10 SPARC) It won't compile. I'm not a programmer, so I'm afraid I don't know why... [huge at anubis ~/Prog/nut/nut-2.2.1]: ./configure --with-user=ups --with-group=nutNetwork UPS Tools version 2.2.1 checking build system type... sparc-sun-solaris2.10 checking host system type...

Hi all! I have sucessfully installed LLVM 1.9 under FreeBSD on a x86 PC. I have successfully executed "An Example Using the LLVM Tool Chain" that is written in the document http://llvm.org/docs/GettingStarted.html When I tried out the demo projects "Hello" and "Stacker" I get compile errors. When I run "gmake" in the directory