similar to: [LLVMdev] hello compiles with -O3 but not -O4

What exactly are the current limitations for using -O4 to create shared libraries with llvm/llvm-gcc-4.2 2.5? I tried a build of xplor-nih at -O4 with llvm-gcc, llvm-g++ and llvm-gfortran. The build fails to link shared libraries with errors such as... Building xplor-nih for platform: Darwin_9_x86 [ -d /Users/howarth/xplor-nih-2.21/bin.Darwin_9_x86/ ] || mkdir

Re-adding the dev list. It's best to always keep the discussions on the list. Don't worry about the length of the message, you need to communicate the information that is important to describe your problem. So I am not the best person to answer this question since I don't build/test libcxx or libcxxabi, but I'm sure there are plenty of people on the list that are quite

On Wed, Aug 29, 2012 at 12:11 AM, Ramanarayanan, Ramshankar <Ramshankar.Ramanarayanan at amd.com> wrote: > I am wondering how O4 vs O3 do inlining. With O4 it looks like inlining is > done first on each file and then at linking phase. Wouldn’t it be a better > alternative to delay inlining decisions until the link stage? Yes and no. Yes in the sense that you may make some better

I am wondering how O4 vs O3 do inlining. With O4 it looks like inlining is done first on each file and then at linking phase. Wouldn't it be a better alternative to delay inlining decisions until the link stage? Ram -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120829/dda45c1c/attachment.html>

-------- Original Message -------- Subject: Sun Solaris 8 compile problem. Date: Thu, 06 Nov 2003 23:03:36 -0700 From: Jack Matthews <jmatthews@t-graphic.com> To: R-help@lists.R-project.org I am new to the list was wondering if anyone can help me find the reason and remedy for compiling R on an ultrasparc 60 solaris 8 with gcc 3.2.2 in 64 bit mode? Fails in checking for a fortran

dear community, sorry for posting again a beginner's question but i can't find a solution on my own. i installed all llvm and llvm-gcc4 in a directory called "~/programs/llvm/install" in my home folder. i can build a test c - file as follows: ~/programs/llvm/install/bin/gcc -v -o test test.c Using built-in specifications. Target: i686-pc-linux-gnu Configured with:

Just in case someone is having similar problems and/or following this thread, here's my final "solution" (at least, for now). In my bash build script, prior to configure, I set the C_INCLUDE_PATH and CPLUS_INCLUDE_PATH to empty strings, and then set some other environment variables instead: export C_INCLUDE_PATH= export CPLUS_INCLUDE_PATH=

Hello, I am trying to cross compile LLVM. Build and compile on Mac OS X 10.5.7 Target is an Angstrom Linux Cortex-A8 Beagle board. I would like to avoid GPLv3. I can compile. But when I run my executable on Beagle crt0.S is calling an AngelSWI to setup the heap and stack. But the AngelSWI seems to just be a stub because it returns zeros for the pointers. That leads to a segfault. If I hack in

On Tue, Aug 28, 2012 at 10:39 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > On Wed, Aug 29, 2012 at 12:11 AM, Ramanarayanan, Ramshankar > <Ramshankar.Ramanarayanan at amd.com> wrote: > > I am wondering how O4 vs O3 do inlining. With O4 it looks like inlining > is > > done first on each file and then at linking phase. Wouldn’t it be a > better > >

This is on Fedora FC5 x86_64 rpm -q wine wine-0.9.14-1.fc5 winecfg wine: creating configuration directory '/home/nbecker/.wine'... X Error of failed request: GLXBadContext Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 166 Current serial number in output stream: 166 wine: wineprefixcreate failed

On Fri, Oct 31, 2008 at 10:38:50AM -0700, Mike Stump wrote: > On Oct 31, 2008, at 9:40 AM, Jack Howarth wrote: >> However in current llvm svn, when I compile code with llvm-gfortran, I >> get these warning >> flags passed by default so that I get bogus warnings of... >> >> f951: warning: command line option "-Wformat" is valid for C/C++/ >>

> The -Wl,-debug result is like this: > $LLVMGCCPREFIX/lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../i686-pc-linux-gnu/bin/ld > -plugin $LLVMGCCPREFIX/libexec/gcc/i686-pc-linux-gnu/4.2.1/libLLVMgold.so > -plugin-opt=as=as --eh-frame-hdr -m elf_i386 -dynamic-linker > /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o > $LLVMGCCPREFIX/lib/gcc/i686-pc-linux-gnu/4.2.1/crtbegin.o >

On 6/26/2010 10:30 AM, Rafael Espindola wrote: >> So the gold and the LLVMgold are linked against the same libstdc++. I am >> using the gcc at /s/gcc-4.3.1/i386_rhel5/bin to compile the LLVM chain. > Can you run llvm-gcc again with -Wl,-debug? This will show the linker > line being used. You can then run gdb on it. Try to find what error is > dlopen reporting. I wonder if gold

On 7/21/2010 1:59 PM, Rafael Espindola wrote: >> I do not know how to get the ld invocation you need. If this command is not >> what you need, please tell me how to get the ld invocation. > Add -Wl,-debug to the llvm-gcc call. That should print the ld command > line in the end.

Hi,    I use the crosstool build script to build a crosscompiler for ARM. I get the following error when compilng "helloworld" program:   llvm-gcc hello.c -o hello   as: unrecognized option `-meabi=4'   I know that the reason is not to get proper cross assembler. It tries to use the native assembler but I am unable to fix the problem. I use llvm-gcc -### hello.c -o hello and see

Hi,    I use the crosstool build script to build a crosscompiler for ARM. I get the following error when compilng "helloworld" program:   llvm-gcc hello.c -o hello   as: unrecognized option `-meabi=4'   I know that the reason is not to get proper cross assembler. It tries to use the native assembler but I am unable to fix the problem. I use llvm-gcc -### hello.c -o hello and see

Chris, Thanks for the hint. Moving over the libLTO.dylib from llvm 2.5 solved all of the linkage errors. I was able to completely build xplor-nih at -O4 now. The core xplor and xplor-tcl testsuite show no regressions. I do get 7 testcases in the xplor-python testsuite failing with bus errors now. The xplor-tcl and xplor-python tests are all run by tcl and python respectively loading their

I was able to also build sparky (http://www.cgl.ucsf.edu/home/sparky/) at -O4 under llvm-gcc-4.2 and llvm-g++-4.2 on darwin with minor patches... --- sparky/c++/_tkinter.c.orig 2009-01-30 22:14:28.000000000 -0500 +++ sparky/c++/_tkinter.c 2009-01-30 22:16:40.000000000 -0500 @@ -3089,6 +3089,9 @@ } } +PyMODINIT_FUNC +init_tkinter(void)

Using -O4 requires support from the system linker, because the files written out are LLVM bitcode files rather than object files. --Owen On Dec 29, 2007, at 11:43 AM, Jack Howarth wrote: > What are the current limitations of using -O4 in > llvm-gcc-4.2? As a first test, I compiled the molscript > program first as -O3 and it works fine. However if i > try to compile the same code

Thank you for your suggestion. I did just try it with the trunc version and got the same error. Any other suggestions? >> Hi all, >> I'd like to use LLVM 2.8 on a openSUSE 10.3 box and when I try to >> compile anything I get an error: > Can you try trunk? I think this has been solved (for this config). >> martin at vm:~/project/backend>> clang tutorial001.m