search for: macosx10.8

Hi, folks. I don't know much about C++, so please excuse my newbie question: I just tried to include Xapian in a dummy Cocoa project, ie created a new project and added the libxapian.a file installed via MacPorts. When I include xapian.h in an Objective-C++ file (either mm or h), the compilation fails with the following message: ================= In file included from

Jack, Where do the "-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -mmacosx-version-min=10.8" flags come from? I don't see them in your CMake invocation - perhaps they're added via $CC or $CFLAGS? Is this being done on purpose? I can add a CMake step checking whether the current CFLAGS/LDFLAGS allow to build an

I can get clang/llvm to emit a rotate instruction on x86-64 when compiling C by just using -Os and the rotate from Hacker's Delight i.e., ====== #include <stdlib.h> #include <stdint.h> uint32_t ror(uint32_t input, size_t rot_bits) { return (input >> rot_bits) | (input << ((sizeof(input) << 3) - rot_bits)); } ====== Then compile with (assuming you are on OS

in C or C++, how can I get clang/llvm to try and do a "rotate". (want to test this code in the mips16 port) i.e. emit rotr node. tia. reed

On Mon, Nov 11, 2013 at 01:59:25PM +0400, Alexander Potapenko wrote: > Jack, > > Where do the "-isysroot > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk > -mmacosx-version-min=10.8" flags come from? I don't see them in your > CMake invocation - perhaps they're added via $CC or $CFLAGS? Is this > being done

On Sun, Nov 10, 2013 at 06:11:16AM -0800, Bill Wendling wrote: > Good day! > > This is just a reminder that branching for the 3.4 release will occur at this time: > > Monday, November 18, 2013 at 7:00:00 PM PST / Tuesday, November 19, 2013 at 3:00:00 AM UTC > > What this means for you! > ------------------------ > > * Please keep the release notes up to date --

Good day! This is just a reminder that branching for the 3.4 release will occur at this time: Monday, November 18, 2013 at 7:00:00 PM PST / Tuesday, November 19, 2013 at 3:00:00 AM UTC What this means for you! ------------------------ * Please keep the release notes up to date -- There has been very few commits to them. Please be proactive and update them with any significant feature that was

Nice! Clever compiler.. On 07/28/2012 08:55 PM, Michael Gottesman wrote: > I can get clang/llvm to emit a rotate instruction on x86-64 when compiling C by just using -Os and the rotate from Hacker's Delight i.e., > > ====== > #include<stdlib.h> > #include<stdint.h> > > uint32_t ror(uint32_t input, size_t rot_bits) > { > return (input>>

This file is for configure+make build, not CMake, so I'm not sure why it's being included into your build (these failures aren't reproducible for me). Can you please list the exact steps you're doing to build LLVM with CMake and make sure you don't have additional CFLAGS (LDFLAGS etc) defined? On Mon, Nov 11, 2013 at 6:16 PM, Jack Howarth <howarth at bromo.med.uc.edu>

Following a blend of instructions on 3 web pages, I have succeeded in getting LLVM 3.2 (with clang, extras, and compiler-rt) building - but not testing - on Xcode. I used CMake 2.8.10 GUI to create the Xcode project file. Below are my notes. First, I believe CMake ends up setting things up so that Xcode has 1 warning after scanning the project having to do with hires images or some such… it takes

On Mon, Nov 11, 2013 at 11:03:47AM -0500, Jack Howarth wrote: > On Mon, Nov 11, 2013 at 06:46:47PM +0400, Alexander Potapenko wrote: > > This file is for configure+make build, not CMake, so I'm not sure why > > it's being included into your build (these failures aren't > > reproducible for me). > > Can you please list the exact steps you're doing to build

On Mon, Nov 11, 2013 at 06:46:47PM +0400, Alexander Potapenko wrote: > This file is for configure+make build, not CMake, so I'm not sure why > it's being included into your build (these failures aren't > reproducible for me). > Can you please list the exact steps you're doing to build LLVM with > CMake and make sure you don't have additional CFLAGS (LDFLAGS etc)

+Bob Wilson I don't know if this is a recent Apple regression, or if it's now catching something which had always been invalid. -bw On Mon, Nov 11, 2013 at 8:44 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > On Mon, Nov 11, 2013 at 11:03:47AM -0500, Jack Howarth wrote: > > On Mon, Nov 11, 2013 at 06:46:47PM +0400, Alexander Potapenko wrote: > > > This

Those look like the linker is being passed the same .o file built twice, ex: ../Objects-normal/x86_64/asan_globals_test.o ../lib/asan/tests/asan_globals_test.cc.asan.o So, the symbols are colliding. Something is set up wrong in the xcode project. -Nick On Dec 19, 2012, at 9:48 AM, Relph, Richard wrote: > Following a blend of instructions on 3 web pages, I have succeeded in getting LLVM

On Sun, Nov 10, 2013 at 7:50 PM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > On Sun, Nov 10, 2013 at 06:11:16AM -0800, Bill Wendling wrote: > > Good day! > > > > This is just a reminder that branching for the 3.4 release will occur at > this time: > > > > Monday, November 18, 2013 at 7:00:00 PM PST / Tuesday, November > 19, 2013 at 3:00:00

Hi Richard! On Thu, Dec 20, 2012 at 12:48 AM, Nick Kledzik <kledzik at apple.com> wrote: > Those look like the linker is being passed the same .o file built twice, > ex: > ../Objects-normal/x86_64/asan_globals_test.o > ../lib/asan/tests/asan_globals_test.cc.asan.o > > So, the symbols are colliding. Something is set up wrong in the xcode > project. > > -Nick

Different, but still failing (this time with Xcode 4.4…) /Users/rrelph/llvm/tot/xcode/bin/Debug/clang sanitizer_allocator_test.cc.i386.o sanitizer_common_test.cc.i386.o sanitizer_flags_test.cc.i386.o sanitizer_libc_test.cc.i386.o sanitizer_list_test.cc.i386.o sanitizer_printf_test.cc.i386.o sanitizer_stackdepot_test.cc.i386.o sanitizer_test_main.cc.i386.o gtest-all.cc.i386.o

*NOTE* IIRC compiling this with -O0 on x86-64 can yield the wrong result since clang will emit shifts and on intel shifts are mod the register size: ===== .section __TEXT,__text,regular,pure_instructions .globl _ror .align 4, 0x90 _ror: ## @ror .cfi_startproc ## BB#0: pushq %rbp Ltmp2: .cfi_def_cfa_offset 16 Ltmp3: .cfi_offset %rbp, -16 movq %rsp, %rbp