similar to: [LLVMdev] RFC: configure.ac

On Wed, 2004-12-22 at 22:09, Markus F.X.J. Oberhumer wrote: > Below you will find a small patch for llvm/autoconf/configure.ac that fixes > wrong AC_SUBST usage and adds AMD64 detection. Please review. > > ~Markus > --- autoconf/configure.ac 22 Dec 2004 05:56:56 -0000 1.147 > +++ autoconf/configure.ac 23 Dec 2004 06:06:04 -0000 > @@ -139,7 +139,8 @@ >

On Thu, 2004-12-23 at 12:35, Markus F.X.J. Oberhumer wrote: > Yes, but "TARGET_HAS_JIT" seems to be unused, so what is this for ? projects/llvm-test/Makefile.programs:175:ifdef TARGET_HAS_JIT projects/llvm-test/Makefile.programs:182:endif#TARGET_HAS_JIT projects/llvm-test/LLVMSource/Makefile:22:ifdef TARGET_HAS_JIT projects/llvm-test/SingleSource/CustomChecked/Makefile:27:ifdef

Hi all, I have a new sample project set up in my llvm/projects directory, and I'd eventually like my frontend to generate an LLVM IR tree. To do so, I believe I need to link to the appropriate LLVM libraries. That's where I'm stuck. I can't seem to find any specific documentation that describes how to set up a new project to link to LLVM libraries. To get started, I added a

Hi folks, here're some quick+dirty fixes to allow sysroot'ed crosscompiling. probably not yet very clean, but seems to work. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: contact at metux.de

Well, I don't quite understand why AC_C_BIGENDIAN and the solution you're proposing is likely to break other big endian machines (the ones that don't have __BIG_ENDIAN__). Can you send a patch that addresses that (i.e. still uses AC_C_BIGENDIAN when it works)? Jean-Marc Peter Grayson a ?crit : > Hi all, > > Speex currently decides endianness at configure-time. This causes

FYI: It also showed up for ARM yesterday, but only for a non-debug build. On Mar 5, 2009, at 4:32 AM, Gabor Greif wrote: > Hi Bill, > > this might be a latent bug related to PPC. I have no such > machine to access atm., but I shall be able to reproduce the > problem when back at home. (In about 4 hours). > > I keep you informed. > > Cheers, > > Gabor >

Hi Bill, this might be a latent bug related to PPC. I have no such machine to access atm., but I shall be able to reproduce the problem when back at home. (In about 4 hours). I keep you informed. Cheers, Gabor On Mar 4, 7:57 pm, Bill Wendling <wendl... at apple.com> wrote: > Something last night broke the build on Darwin PPC. Possible Gabor's   > check-in? > > -bw

Something last night broke the build on Darwin PPC. Possible Gabor's check-in? -bw Begin forwarded message: > From: admin at spang.apple.com (admin) > Date: March 4, 2009 3:56:10 AM PST > To: wendling at apple.com > Subject: PPC Nightly Build Result > > /Volumes/SandBox/NightlyTest/llvmgcc42.roots/llvmgcc42~obj/obj- > powerpc-powerpc/./prev-gcc/xgcc

On 5/2/07, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > Well, I don't quite understand why AC_C_BIGENDIAN and the solution > you're proposing is likely to break other big endian machines (the ones > that don't have __BIG_ENDIAN__). Can you send a patch that addresses > that (i.e. still uses AC_C_BIGENDIAN when it works)? It is not that AC_C_BIGENDIAN

g++ -m32 -c -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings - pedantic -Wno-long-long -Wno-variadic-macros -Wmissing-format- attribute -Werror -mdynamic-no-pic -DHAVE_CONFIG_H -Wno-unused - DTARGET_NAME=\"i686-apple-darwin9\" -DNDEBUG -I. -I. -I/tmp/ llvmgcc42.roots/llvmgcc42~obj/src/gcc -I/tmp/llvmgcc42.roots/ llvmgcc42~obj/src/gcc/.

Hey all, I need to use C bindings in a pass that I am authoring (specifically, I want to use the OCaml bindings that are tied to the C bindings to author the pass). However, this requires that I link in LLVMCore to provide said bindings to my library. From what I've read, there is a known issue with linking LLVMCore into a module that is fed to opt. Namely, you get the following assertion:

On Thu, Feb 9, 2017 at 2:23 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 9 Feb 2017, at 01:33, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: >> >> 4.0.0-rc2 was just tagged from the branch at r294535. > > Building on FreeBSD 10 at least didn't crash this time, and lld built just fine. :) I uploaded the following: >

On 31 Jan 2015, at 01:42, Hans Wennborg <hans at chromium.org> wrote: > Hi testers, > > 3.6.0-rc2 was just tagged. Please test and build binaries. > > The tracking bug for 3.6 blockers is http://llvm.org/pr22374. Please > file issues against it. > > Thanks for helping with the release! This time I got an error during check-all, on i386-unknown-freebsd10:

On Sat, Jan 31, 2015 at 9:24 AM, Dimitry Andric <dimitry at andric.com> wrote: > On 31 Jan 2015, at 01:42, Hans Wennborg <hans at chromium.org> wrote: >> Hi testers, >> >> 3.6.0-rc2 was just tagged. Please test and build binaries. >> >> The tracking bug for 3.6 blockers is http://llvm.org/pr22374. Please >> file issues against it. >>

Hello everyone! I've started to implement a ColdFire backend, but there are some troubles during configuring: $ ../llvm/configure --enable-targets=x86,x86_64,coldfire ... ... ... checking whether byte ordering is bigendian... no configure: error: Unrecognized target coldfire configure: error: ../../../llvm/projects/sample/configure failed for projects/sample I've added ColdFire to : 1)

(Sorry, previous post got sent by accident. This is the real one) Folks, Here's some timing results looking at LLVM when it uses libLLVMCore.o vs. libLLVMCore.a. We're trying to decide which way to go and thought some data would help. The net of it is that using libLLVMCore.a is cheaper in both time and size of executables. We save 37 seconds on linking LLVMCore and about 1 minute 30

It may be that the 'not' operator is not being found under bash at : 'RUN: at line 12';   not Perhaps this is would be better as the more commonly seen '!'. Neil Nelson On 9/13/19 12:12 PM, Neil Nelson via llvm-dev wrote: > > Toward the end of testing.9.0.0-rc4.log. > > Testing: 0 .. 10.. 20. > FAIL: Clang Tools :: clang-tidy/run-clang-tidy.cpp (17057 of

On Fri, Feb 01, 2013 at 04:43:59PM +0200, Vadim Khoptynets wrote: > Hello everyone! > > I've started to implement a ColdFire backend, but there are some troubles > during configuring: > > $ ../llvm/configure --enable-targets=x86,x86_64,coldfire > ... > ... > ... > checking whether byte ordering is bigendian... no > configure: error: Unrecognized target

> > I found an LLVM dependency graph at > > > > https://llvm.org/svn/llvm- > project/llvm/tags/RELEASE_16/docs/UsingLibraries.html#dependencies > > > > but it's really messy and hard to follow. From that graph I made a > > cleaner graph by hand (attached)... sorry about the fax-quality > > scan. But I have some questions about it... > > >

On Fri, Feb 1, 2013 at 4:01 PM, Tom Stellard <tom at stellard.net> wrote: > On Fri, Feb 01, 2013 at 04:43:59PM +0200, Vadim Khoptynets wrote: >> Hello everyone! >> >> I've started to implement a ColdFire backend, but there are some troubles >> during configuring: >> >> $ ../llvm/configure --enable-targets=x86,x86_64,coldfire >> ... >>