similar to: [LLVMdev] more llvmgcc build issues.

Hi , I needed to apply this patch to get the GCC frontend building on an FC5 x86 box . [ramana at venglathur gcc]$ svn diff Index: libiberty/strsignal.c =================================================================== --- libiberty/strsignal.c (revision 254) +++ libiberty/strsignal.c (working copy) @@ -557,8 +557,8 @@ void psignal (signo, message) - unsigned signo; -

Devang, On Wed, 2007-01-24 at 10:28 -0800, Devang Patel wrote: > On Jan 24, 2007, at 4:14 AM, Ramana Radhakrishnan wrote: > > > Hi , > > > > I needed to apply this patch to get the GCC frontend building on an > > FC5 > > x86 box . > > I am curious, what kind of failure are you seeing ? I should have mentioned in the email : Here's my earlier post

On Jan 24, 2007, at 4:14 AM, Ramana Radhakrishnan wrote: > Hi , > > I needed to apply this patch to get the GCC frontend building on an > FC5 > x86 box . I am curious, what kind of failure are you seeing ? Thanks, - Devang

On Jul 31, 2006, at 11:14 AM, Vikram Adve wrote: > Does llvmgcc4 convert the high-level AST to LLVM (like llvmgcc3x) > or does it go from GIMPL to LLVM? If the latter, would it be > possible to allow some TreeSSA optimizations before emitting LLVM? llvmgcc4 intercepts high-level GCC trees to GIMPLE tree transformation routines to get trees that are suitable for LLVM byte code.

Continuing with problems that I've uncovered while getting pqR to work on Windows... The file src/ghuwin32/psignal.c (used only in Windows builds) fails to use the sigset_t type in all places where it should, using "int" some places instead. Here is a diff of the needed corrections: @@ -253,7 +253,7 @@ sighandler_t signal(int signal_Number, sighandler_t signal_Handler) int

On Mon, 31 Jul 2006, Devang Patel wrote: > On Jul 31, 2006, at 11:14 AM, Vikram Adve wrote: >> Does llvmgcc4 convert the high-level AST to LLVM (like llvmgcc3x) or does >> it go from GIMPL to LLVM? If the latter, would it be possible to allow >> some TreeSSA optimizations before emitting LLVM? > llvmgcc4 intercepts high-level GCC trees to GIMPLE tree transformation

Does llvmgcc4 convert the high-level AST to LLVM (like llvmgcc3x) or does it go from GIMPL to LLVM? If the latter, would it be possible to allow some TreeSSA optimizations before emitting LLVM? --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/ On Jul 31, 2006, at 1:10 PM, Devang Patel wrote: > llvmgcc4 emits LLVM byte code before executing GCC optimizations, > so one

llvmgcc4 emits LLVM byte code before executing GCC optimizations, so one can say that llvmgcc4 disables all GCC optimizations. On Jul 31, 2006, at 11:01 AM, Zhiru Zhang wrote: > Hi, > I am trying to turn on the new GCC auto-vectorization feature > within llvmgcc4. Below is the command I used, but nothing was > vectorized. Does it mean that llvmgcc4 has disabled this >

One thing I forgot in my previous message about problems with psignal.c on Rtools for Windows... One also needs to change src/gnuwin32/fixed/h/psignal.h At a minimum, one needs the following changes: @@ -122,8 +129,8 @@ typedef struct /* Prototype stuff ***********************************************************/ -int sigsetmask(int signal_Block_MaskNew); -int

Hi My Name is Ben.T.George i successfully installed samba and other all dependencies on my Solaris 10 (SPARC) machine. i stopped the default samba and swat and enabled these 2 from the installed location (/usr/local/samba/sbin) then i edited the smb.conf using swat.after that i got a smb.conf like this\ # Samba config file created using SWAT # from UNKNOWN (??? ) # Date: 2010/09/28 16:30:12

Hi, i tried compiling llvmgcc4 on x86_64-linux. The two changes i needed to apply to llvm and llvmgcc4 are attached. Those two patches tell llvmgcc4 to use the x86 code-generator for x86_64 and give x86_64-* targets a score of 10 for the x86 backend when trying to find appropriate backends. Now i'm getting stuck during the compile when an assertion is triggered: make[3]: Leaving

Hi, I am trying to turn on the new GCC auto-vectorization feature within llvmgcc4. Below is the command I used, but nothing was vectorized. Does it mean that llvmgcc4 has disabled this optimization and all I can do is to embed SSE intrinsics in the source code by hand? Thanks! ./llvm-gcc4-x86/bin/llvm-gcc -c -O2 -ftree-vectorize -msse -ftree-vectorizer-verbose=5 -emit-llvm vec.c -o vec.bc

On the Warloc - loveloc lines as baldric4 suggested on IRC . Why not OptLOC - Optimize Lines (and Lines) of Code. cheers Ramana Ramana Radhakrishnan <ramana.radhakrishnan at codito.com> Codito Technologies Pvt. Ltd.

Hi Evan, The commit http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060327/033389.html broke CVS. The attached obvious patch fixes it. I don't have write access . So can someone commit this in ? ramana at zirakzigil:~/fsf/llvm/llvm/lib/Target/X86$ cvs diff -au X86ISelLowering.cpp Index: X86ISelLowering.cpp ===================================================================

I get the following error when building R from the subversion server as well as the latest tarball. I am on Windows XP, and I recently updated my MinGW installation. It's quite possible I am doing something wrong, but I am not sure what that might be. making console.d from console.c making dataentry.d from dataentry.c making dynload.d from dynload.c making edit.d from edit.c making editor.d

Hi , I've been giving the ARM port of LLVM a spin today and ran into this . [ramana at venglathur builddir]$ cat hello.c && llvm-gcc hello.c -c -emit-llvm -O3 -o - | llc -march=arm #include <stdio.h> int main(void) { printf ("hello world\n"); return 0; } llc: bytecode didn't read correctly. llvm and the tools is today's CVS head while llvm-gcc is

When trying to compile R on Windows 10 64-bit using LTO as I always do, I encountered a segmentation fault early in the compilation. I am uncertain as to what it means (please see below for error extract). I am using the most recent version of Rtools43 (5863) and updated its libraries prior to starting the build. My EOPTS is " -march=native -pipe -mno-rtm" and my

Suggestions: Zembla - It's a fictional northern European country in "Pale Fire" by Nabokov. Pala - The island utopia in Aldos Huxley's "Island". Thra - The world of The Dark Crystal. -bw

Invictus - unconquerable, and Invictus.org doesn't appear to exist. On Apr 12, 2007, at 1:34 AM, Bill Wendling wrote: > Suggestions: > > Zembla - It's a fictional northern European country in "Pale Fire" > by Nabokov. > Pala - The island utopia in Aldos Huxley's "Island". > Thra - The world of The Dark Crystal. > > -bw >

I tried ot build rpvm in my own makefile. But runs into some linker errors like e.g. undefined reference to `_R_alloc' My enviornment looks like this: CYGWIN pvm 3.4 compiled under cygwin myself R installed from the rw2001.exe setup file. I guess that the R under rw2001.exe was build with some other compiler? I then tried to compile R myself under CYGWIN but runs into the following