similar to: [LLVMdev] compiler-rt compile problem for 32bit OS X

Hi, I'm trying to compile llvm/clang so that: it is compiled on osx 10.6, it runs on osx, but it outputs win32 objects. More exactly, I'm building an app which generates a .c file that doesn't include or link with anything, and I'd like to be able to make a win32 .dll of it on osx. Below is what I'm getting. Full log is here: http://pastebin.com/KsPGvAfW It fails while

(cc'ing llvm-dev) Hello Gregory, i just recompiled llvm from scratch, and was able to build the ocaml kaleidoscope bindings. Did you know the llvm's build system already can compile the kaleidoscope tutorials for you? You can run this to build them: make BUILD_EXAMPLES=1 Or just cd into the examples directory in your build directory, and run "make" there. Anyway, I think the

TB --- 2013-10-31 19:50:43 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2013-10-31 19:50:43 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-31 19:50:43 - starting RELENG_10 tinderbox run for i386/pc98 TB --- 2013-10-31 19:50:43 - cleaning the

If this is not the proper place to report this problem, I apologize and would like to know the proper avenue. Information on compiler-rt is very scarce, and I have been unable to get block support on Linux any other way. I'm running X86_64 Ubuntu Linux, and I checked out the trunk of compiler-rt and built it according to the instructions on it's page, and ran the test suite. Three tests

I'm posting this here to document what I encountered and the solution I found, in hopes that others may find it useful. When building clang 3.2 on Linux (Ubuntu 12.04, 32-bit, x86 PC), I received the following errors (messages from the make output): ... make[4]: Entering directory `/home/youngmj/DevTools/LLVM/Version_3.2/build/tools/clang/runtime/compiler-rt' /bin/sh: 1:

A new pixman release 0.34.0 is now available. This is a major release, following three development releases in the past six months. It contains all the changes detailed in the last three development releases in the 0.33 series. Please note that this release doesn't contain any changes since the previous development version (0.33.6) was released. For those who didn't follow the

I tracked down the error. There’s an ifneq check for IOSSIM_SDK_PATH before it’s defined. $ grep -n IOSSIM_SDK_PATH projects/compiler-rt/make/platform/clang_darwin.mk 91:ifneq ($(IOSSIM_SDK_PATH),) 157:IOSSIM_SDK_PATH := $(call XCRunSdkPath,iphonesimulator) 158:$(warning clang_darwin.mk: $(IOSSIM_SDK_PATH)) 161: -isysroot $(IOSSIM_SDK_PATH) \ 207: -mios-simulator-version-min=7.0

A new pixman release 0.33.2 is now available. This is a release candidate for a stable 0.34.0 release. This release comes after little more than 1 year since the previous release (0.32.6). Therefore, the git log is quite long and there are multiple changes, fixes and enhancements. The main changes are: - ARMv6 - Many fast paths implementations were added - PPC64/PPC64LE - Fix all outstanding

Hi all. I’ve been working with Swift on ARMv6 and v7. While working with ARMv6 on linux, I noticed that my arm architecture canonicalization code didn’t produce the expected result. The code that I had been using (within Swift’s Driver.cpp the following: static llvm::Triple computeTargetTriple(StringRef DefaultTargetTriple) { llvm::Triple triple = llvm::Triple(DefaultTargetTriple); //

Should be fixed in r195216. On 2013 Nov 19, at 21:30, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > I tracked down the error. There’s an ifneq check for IOSSIM_SDK_PATH before it’s defined. > > $ grep -n IOSSIM_SDK_PATH projects/compiler-rt/make/platform/clang_darwin.mk > 91:ifneq ($(IOSSIM_SDK_PATH),) > 157:IOSSIM_SDK_PATH := $(call

On Thu, 8 Jan 2015, Jonathan Lennox wrote: > Every armv7 (and armv8) iOS device has supported Neon, and Xcode support for > armv6 was dropped with Xcode 4.5. > > Even if you?re compiling with an old Xcode version to support really old iOS > devices, Apple?s armv6/armv7 selection was a compile-time switch (supported > using fat binaries). ?I think the arch can be detected based

Hi, I'm fairly new at poking around in llvm internals so if you find misconceptions / problems with the below let me know, this is just how I've understood this so far. When doing a build which uses functionality from LinkModules to combine bitcode from different versions of LLVM, or between LLVM-GCC (I know) and Clang, I've noticed that multiple warnings which sometimes seem

On Jan 8, 2015, at 2:33 PM, Tom Hughes <tom at airtime.com<mailto:tom at airtime.com>> wrote: This adds run-time CPU detection for iOS devices. I found this page useful for CPU support and models: http://iossupportmatrix.com/ The patch could be simplified to just set the OPUS_CPU_ARM_NEON flag if you think it's unlikely that anyone would be running on the really old devices that

Hi, I recently attempted to cross compile libogg1.3.0 for armv6, armv7 and i386 for iOS development. Anyway, I had some issues with the getting configure to work with armv6/7. I put up this post<http://stackoverflow.com/questions/11711100/cross-compiling-libogg-for-ios/11769528#11769528> on stack overflow. It appears the configure file sets the -O4 option when compiling in a darwin

A new pixman release 0.33.4 is now available. This is a release candidate leading up to a stable release (0.34.0). The stable release is expected to be made around January 2016. The main changes are (see the git log below for full list of commits): - Important security fix to prevent stack buffer overflow - POWER: New fast-paths and optimizations to existing fast-paths - ARMv6: New fast-path

Hi Brenden, Thanks for the heads up. I don’t expect that to be a blocker for deprecating autoconf because autoconf doesn’t have an equivalent of LLVMExports.cmake. That said it is a real issue and I’ll track it with the other issues on this list, and I’ve added it as a dependency on the meta bug (PR15732) to make it easier to keep track of. Thanks, -Chris > On Jul 29, 2015, at 4:48 PM,

It depends, of course, what operating system you have installed on the RPi, but given that it's an ARM1176JZFS (ARMv6) chip, I would expect to see armv6, not armv4t, in the CPU part of the triple. It has a VFP unit, so I'd assume that you'd want to set hardfp (unless you installed an OS that doesn't support hardfp in its standard library), but if ld is complaining then you almost

> On May 28, 2015, at 8:37 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > > Probably not a blocker for replacing autoconf, while at it: > Bug 23468 - LLVM_OPTIMIZED_TABLEGEN does not work with Visual Studio. > It makes the tablegenning really slow. This is actually a feature of the CMake build system that the autoconf one doesn’t have, so this is not related to

So just to add to this conversation, I *too* was thinking about rewriting the build system :) I've been writing a new build system from the ground up, and I was hoping to see how my system would work against llvm. I wanted to make sure that I understand the licensing issues. I'm releasing my build system using just a standard BSD license, which is compatible with llvm's license, right?

> My copy of the ARM ARM says: > > "Use of R15: Specifying R15 for register <Rd>, <Rm>, or <Rs> has > UNPREDICTABLE results." > > This is the same as above. However, it goes on to say: > > "Operand restriction: Specifying the same register for <Rd> and <Rm> was > previously described as producing UNPREDICTABLE results. There