similar to: [LLVMdev] llvm-ld behavior change?

Good summer, all! This patch enables ENABLE_SHARED=1 to build DLL based LLVM toolchain. I have checked this on Cygwin-1.5, Cygwin-1.7, mingw(msysgit) and mingw-cross-fedora12. I can separate this patch into some parts; cleanups, adding definitions and adding rules. Any feedbacks are welcome. Have fun! ...Takumi * Pros - reduction of linking time of toolchain. - capability of -load

Hi, I have a large-ish application I'm trying to build with LLVM, so I replaced g++ in the Makefiles with llvm-g++. This appears to work fine when I pass -Wl,-native to generate an ELF executable, but I want to control the inlining threshold it uses, so I am now passing -Wl,-disable-inlining and -Wa,-disable-inlining, and having it generate LLVM bytecode, then running opt -inlining to generate

On Mon, 3 Apr 2006, Michael McCracken wrote: > the bytecode with lli - I get the following error: > > $ lli -load=/home/mmccrack/linux/lib/libTau.sh leo-inline-300-tau.bc > ERROR: Program used external function > '__llvm_cxxeh_allocate_exception' which could not be resolved! This is most likely because you are trying to link with llvmgcc, not with llvm-g++. Make sure that

On Wednesday, February 5, 2003, at 10:47 PM, Josh Coalson wrote: > --- Matt Zimmerman <mdz@debian.org> wrote: > > good, very good. it may take me a little bit to get to it > since I'm starting a new job next week. > > Ben, can you inspect the patch and confirm that it covers > what you also suggested? The patch fixed the problem with your libs. However, when

Hi Takumi, > Any feedbacks are welcome. > Have fun! This seems to be pretty useful addition to LLVM on windows! And it seems the only painless way to make plugins working, yay! For me the patch looks pretty good. One minor thing: could you please rename SharedDir => SharedLibDir Thanks! -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg

Anton, Thanks for your comment. 2nd patch attached. - s/SharedDir/SharedLibDir/g - move prefix=cyg sunk into if(cygwin or mingw) arigato gozaimasu...Takumi * Additional issues - You may build LLVMHello.dll but I don't modify lib/Transforms/Makefile. Because making LLVMHello.dll requires the library LLVM.dll, but it oughta be on the way to making libs at building

Sorry to have to ask... I'm catching too much noise from dumps. I'm building LLVM 7.0 using release tarballs on OS X 10.5 PowerPC. I'm building out-of-tree mostly following https://llvm.org/docs/GettingStarted.html#getting-started-quickly-a-summary . Cmake gets this far and hangs: -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Looking

Hi Duncan I am facing a build error about __builtin_iceil when compiled with dragonegg using -ffast-math option. My dragonegg is built with gcc-4.7.0 (I am compiling namd spec benchmark here again). Any idea? g++ -march=bdver2 -save-temps -fplugin=/home/anboyapa/install/bin/dragonegg.so -O2 -march=bdver2 -save-temps -fplugin=/home/anboyapa/install/bin/dragonegg.so -mno-fma -mfma4 -ffast-math

On 6 November 2012 14:52, Duncan Sands <baldrick at free.fr> wrote: > Hi Anitha, > > > On 06/11/12 10:19, Anitha Boyapati wrote: > >> Hi Duncan >> I am facing a build error about __builtin_iceil >> > > it's surely just that dragonegg doesn't have any support for this builtin. > ok. Just verified that Target.cpp and x86_builtins do not have

Hi Anitha, On 06/11/12 10:19, Anitha Boyapati wrote: > Hi Duncan > I am facing a build error about __builtin_iceil it's surely just that dragonegg doesn't have any support for this builtin. Please open a bug report with a minimal test case. Ciao, Duncan. when compiled > with dragonegg using -ffast-math option. My dragonegg is built with gcc-4.7.0 > (I am compiling namd

Hi Anitha, > it's surely just that dragonegg doesn't have any support for this builtin. > > ok. Just verified that Target.cpp and x86_builtins do not have iceil support. > I have this tricky situation - I use dragonegg generated LLVM IR as input to > clang for some analysis (well it is clang++ actually). Understably,clang cribs > looking at __builtin_iceil. Any idea

Dear Evan Chang: I register incorrect Register class for MVT::f64. I have fixed it. Thanks your advice. "-view-legalize-dags" is very good option. But I don't know why my LLC do not know " -view-legalize-type-dags" option. By the way, I use llvm 2.5 merged from llvm2.4. Best Regards, Ren Kun --- 09年3月31日，周二, Evan Cheng <echeng at apple.com> 写道： 发件人: Evan Cheng

What u wrote here: >>once again this folder stdc++.txt does exist.... ...reminds me on having charset problems with samba, doing the same stuff here until I set up the right charsets. Also, u see in logfile: >>call_trans2qfilepathinfo: vfs_stat of New Folder2231113/.directory failed >>(No such file or directory) And u say: >>but this directory NewFolder2231113 does

On Tue, Feb 11, 2003 at 05:14:45PM +0000, Christian Weisgerber wrote: > Ben Hines <bhines@alumni.ucsd.edu> wrote: > > > The patch fixed the problem with your libs. However, when linking the > > xmms plugin i still get: > > > > *** Warning: This library needs some functionality provided by -lstdc++. > > This is because of id3lib, which is written in

Hi again, following my previous post on RCurl, I cannot install Rcpp either: g++ -m32 -I/home/renaud/bin/R/2.15/lib64/R/include -I/home/renaud/bin/R/2.15/lib64/R/include/i386 -DNDEBUG -I../inst/include/ -I/usr/local/include -fpic -g -O2 -c r_cast.cpp -o r_cast.o g++ -m32 -shared -L/usr/local/lib64 -o Rcpp.so Date.o DateVector.o Datetime.o DatetimeVector.o Dimension.o DottedPair.o

Hi again, following my previous post on RCurl, I cannot install Rcpp either: g++ -m32 -I/home/renaud/bin/R/2.15/lib64/R/include -I/home/renaud/bin/R/2.15/lib64/R/include/i386 -DNDEBUG -I../inst/include/ -I/usr/local/include -fpic -g -O2 -c r_cast.cpp -o r_cast.o g++ -m32 -shared -L/usr/local/lib64 -o Rcpp.so Date.o DateVector.o Datetime.o DatetimeVector.o Dimension.o DottedPair.o

On 11/13/2011 8:57 PM, NAKAMURA Takumi wrote: > AFAIK, on msys, trunk and release_30 is almost fine. > http://bb.pgr.jp/builders/clang-i686-msys Though, here is no builder > on win32 with --enable-shared. I'm having a problem now, building Release Candidate 3 on msys (using msysGit environment, which I find the easiest to set up and keep isolated); with --enable-optimized

Eliminate undefined references to powf, sqrtf and friends. Index: MultiSource/Benchmarks/Bullet/Makefile =================================================================== --- MultiSource/Benchmarks/Bullet/Makefile (revision 92512) +++ MultiSource/Benchmarks/Bullet/Makefile (working copy) @@ -1,7 +1,7 @@ LEVEL = ../../../ PROG = bullet CPPFLAGS += -I$(PROJ_SRC_DIR)/include -DNO_TIME -LDFLAGS

Continuing my quixotic effort to get 'check-all' clean, I am seeing a Fuzzer failure on x86-64 Linux. Do any builders run fuzzer tests? FAIL: libFuzzer :: value-profile-mem.test (103 of 103) ******************** TEST 'libFuzzer :: value-profile-mem.test' FAILED ******************** Script: -- : 'RUN: at line 4'; /build/x86_64/./bin/clang --driver-mode=g++ -std=c++11

Hi David, > Are the data below all collected when only one function is picked for > instrumentation? Yes, here is a list of the benchmarks and selected functions. +-----------------+----------------------------------------------------------------------------------------------+ | blks | _Z19BlkSchlsEqEuroNoDivfffffif |