similar to: [LLVMdev] Compile SPEC2006 with clang-3.2, multi definition errors.

The problem was solved by setting environment variable CXX. But somehow a new one came. The gcc is installed in /usr/local/gcc-4.2.3. I managed to change clang/lib/Frontend/InitHeaderSearch.cpp clang/lib/Driver/ToolChains.cpp to force clang use the crt lib for that version. For details, plz see http://www.advogato.org/person/redi/diary/228.html. So now I have no problem of using clang to

When trying to link more than one object files compiled with clang, I run into errors of the following type: $ clang -fblocks -g -I$HOME/opt/include -L$HOME/opt/lib/ -o helloworld helloworld.c hello.o world.o -lBlocksRuntime world.o: In function `gnu_dev_major': /usr/include/sys/sysmacros.h:43: multiple definition of `gnu_dev_major' hello.o:/usr/include/sys/sysmacros.h:43: first defined

On 14/12/09 13:57, Abhishek Kulkarni wrote: > When trying to link more than one object files compiled with clang, I run into > errors of the following type: > > $ clang -fblocks -g -I$HOME/opt/include -L$HOME/opt/lib/ -o helloworld > helloworld.c hello.o world.o -lBlocksRuntime > world.o: In function `gnu_dev_major': > /usr/include/sys/sysmacros.h:43: multiple definition

Are you saying this is this the first time you've tried to compile it on the cluster? It's easy to determine if g++ is installed and in the PATH - just get a console on the cluster and type "g++". However, AFAIK cluster nodes are not usually configured for software development, are they? Typically you build your code locally and then job it out to the cluster? Greg

I've compiled llvm several times, but this is the first time I saw this error when I was trying to compile it in a cluster. checking tool compatibility... configure: error: g++|clang++|icc required but not found I am pretty sure g++ is installed and in the path. I then downloaded clang++ binary and set path. The error was still there. OS: opensuse 10.1 gcc, g++ version: 4.2.3 Any idea? Bo

The getpwd() function in dash assumed than getcwd(0, 0) will allocate the buffer dynamically using malloc(); however, this glibc extension is not implemented by klibc. Make getpwd() use a temporary buffer and invoke savestr() itself instead of relying on a nonstandard extension. Signed-off-by: Sergey Vlasov <vsu at altlinux.ru> --- Alternatively, you may pull from the following git repo

Hi Reza, -O4 is the highest level of LLVM optimization that I know of. But, I don't know if it has been tried on Spec2006. IIRC, Dan Gohman has run Spec. tests with LLVM, so he can provide more info. - fariborz On Jul 19, 2010, at 6:06 PM, Reza Yazdani wrote: > Hi, > > What are the best options to compile Spec2006 with LLVM compilers to > get the best performance numbers

Hi, What are the best options to compile Spec2006 with LLVM compilers to get the best performance numbers on x86? Has anybody compared LLVM Spec2006 numbers with GCC 4.5 base? reza -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100719/40cf38a5/attachment.html>

On 07/20/10 18:03, Jim Grosbach wrote: > -O4 does give good additional performance compared to -O3 with llvm. The additional inlining opportunities and such add up quite a bit. The SPEC2006 runs I've done have all been within the framework of the llvm test suite, the LTO is run directly, rather than via an explicit -O4 option. The test-suite Makefiles themselves are probably the best place

On 08/16/2013 01:42 PM, Renato Golin wrote: > On 16 August 2013 20:02, reed kotler <rkotler at mips.com > <mailto:rkotler at mips.com>> wrote: > > -std=gnu89 is not valid for c++ > > > I think the point here is that this is the default std for GCC but not > Clang, so you have to force clang to behave like GCC. For C++, you'll > have to force

Hi Adam, I find LoopLoadElimination (r262250) causes SPEC2006/gcc generate wrong result (166.s) in AArch64 when running with *ref* data set. The error happens when I use either "-Ofast -flto -fuse-ld=gold" or "-O3 -fno-strict-aliasing". Please let me know if you need more information. Best, Haicheng -------------- next part -------------- An HTML attachment was

On 16 August 2013 20:02, reed kotler <rkotler at mips.com> wrote: > -std=gnu89 is not valid for c++ > I think the point here is that this is the default std for GCC but not Clang, so you have to force clang to behave like GCC. For C++, you'll have to force whatever default GCC has for it's C++ standard. Though, GCC 4.8 is getting very close to Clang's behaviour, so

I used the suite with clang 3.3 a few months ago. If I remember correctly, I ran into the same error seen here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036013.html Although it doesn't seem to be a problem with the frontend, adding -std=gnu89, as suggested, fixed everything for me. H. ----- Original Message ----- From: reed kotler Sent: 08/16/13 01:26 AM To: LLVM Developers

Dear llvmers, I decided to write my own scripts to compile the SPEC programs, and they work fine, except with 403.gcc. Basically, I take the file 403.gcc.linked.rbc from the ...\Output folder that the LLVM test suite produces. Then I use this linked.rbc file to generate an executable file via the following commands: llc 403.gcc.linked.rbc -o 403.gcc.linked.s clang 403.gcc.linked.s -o

On 08/15/2013 10:29 PM, Henrique Santos wrote: > I used the suite with clang 3.3 a few months ago. > If I remember correctly, I ran into the same error seen here: > http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036013.html > Although it doesn't seem to be a problem with the frontend, adding > -std=gnu89, as suggested, fixed everything for me. > H. -std=gnu89 is

Thank you, Adam. It passes all the benchmarks I have. Haicheng From: anemet at apple.com [mailto:anemet at apple.com] Sent: Wednesday, March 09, 2016 7:17 PM To: Haicheng Wu; Eric Christopher; Benjamin Kramer Cc: llvm-dev Subject: Re: Regression in SPEC2006/gcc caused by LoopLoadElimination I’ve committed the fix in r263058. Haicheng, Eric/Benjamin, can you guys please give it a

Has anyone been running this? Do you need to use one of the -std= or -ansi or whatever to set the language conformance level of clang to match some assumed gcc level? Tia. Reed

I can't really tell what is happening based on this output, but 'make' is not the right way to build SPECcpu2006 components. You need to do either by using the supplied 'runspec' command with '-build' action directive or to issue the 'specmake' (which is a make adjusted by spec.org) on the build component folder. I can build 433.milc on PPC64 with clang without

> On Mar 7, 2016, at 9:43 AM, Adam Nemet <anemet at apple.com> wrote: > > Hi Haicheng, > > Sorry about the breakage. I reverted it in r262839. > > I will try to reproduce it locally. Please don’t blow away your directories yet in case I need further help. OK, I managed to reproduce this locally. Should be able to make progress from here without further help from

Actually I am trying to run SPEC2006 through the Makefiles provided with LLVM Test Suite, so I think it should work properly... On 18 February 2013 15:49, Adhemerval Zanella <azanella at linux.vnet.ibm.com>wrote: > I can't really tell what is happening based on this output, but 'make' is > not the right way > to build SPECcpu2006 components. You need to do either by