similar to: [LLVMdev] error: unable to get target for 'armv5', see --version and --triple.

On Wed, Mar 20, 2013 at 6:42 AM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: > Current llvm svn fails make check when built for only x86... Ah, right, need to put that behind a "requires"... hrm. (or I could just drop it & let the machines that are armv5 native catch this) > > [100%] Running the LLVM regression tests > FAIL: LLVM ::

I hope this is addressed by r177545 - please let me know if this test is still failing for you after that change. On Wed, Mar 20, 2013 at 8:38 AM, David Blaikie <dblaikie at gmail.com> wrote: > On Wed, Mar 20, 2013 at 6:42 AM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: >> Current llvm svn fails make check when built for only x86... > > Ah, right, need to put

On x86_64-apple-darwin12, I am seeing regressions in the current llvm 3.4 release branch during 'make check'... Scanning dependencies of target check-llvm [100%] Running the LLVM regression tests FAIL: LLVM :: CodeGen/Generic/isel-optnone.ll (1362 of 9265) ******************** TEST 'LLVM :: CodeGen/Generic/isel-optnone.ll' FAILED ******************** Script: --

Paul, could you take a look at this? Maybe it would make more sense for the in-progress optnone work to be omitted from the release? -- Sean Silva On Thu, Nov 21, 2013 at 11:27 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > On x86_64-apple-darwin12, I am seeing regressions in the current > llvm 3.4 release branch during 'make check'... > > Scanning

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 --

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

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

Currently trunk fails to build openmp on darwin due to the failure of... [ 46%] Linking CXX shared library ../../../lib/libomptarget.dylib cd /sw/src/fink.build/llvm50-5.0.0-1/build/stage1/projects/openmp/libomptarget && /sw/bin/cmake -E cmake_link_script CMakeFiles/omptarget.dir/link.txt --verbose=1 /sw/src/fink.build/llvm50-5.0.0-1/opt-bin/ccclang++ -fno-common -fPIC

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

At 167457 on x86_64-apple-darwin12, I am seeing a slew of AddressSanitizer failures due to unresolved symbols such as... Exit Code: 1 Command Output (stderr): -- Undefined symbols for architecture x86_64: "___asan_init", referenced from: _asan.module_ctor in shared-lib-test-so-moBSTe.o "___asan_register_globals", referenced from: _asan.module_ctor in

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 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)

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>

+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

The fix is under review. --kcc On Tue, Nov 6, 2012 at 6:08 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > At 167457 on x86_64-apple-darwin12, I am seeing a slew of > AddressSanitizer failures due to > unresolved symbols such as... > > Exit Code: 1 > Command Output (stderr): > -- > Undefined symbols for architecture x86_64: > "___asan_init",

Fix is in (r167460). On Tue, Nov 6, 2012 at 6:18 PM, Kostya Serebryany <kcc at google.com> wrote: > The fix is under review. > > --kcc > > > On Tue, Nov 6, 2012 at 6:08 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > >> At 167457 on x86_64-apple-darwin12, I am seeing a slew of >> AddressSanitizer failures due to >> unresolved symbols

Since we are only a week away from branching for 3.7.0, this new breakage in the stage2 bootstrap of llvm/clang/compiler-rt/clang-tools-extra should get triaged. At r241513, a three stage bootstrap with comparision of stage2/stage3 files completed fine. However at r241594 we now have the new regression reported in https://llvm.org/bugs/show_bug.cgi?id=24054... Assertion failed: (Val &&

On Tue, May 24, 2016 at 3:03 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > On Tue, May 24, 2016 at 2:37 PM, Jack Howarth > <howarth.mailing.lists at gmail.com> wrote: >> On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: >>> Jack, >>> >>> What version of CMake are you using? >>> >>>

On Sat, Oct 14, 2017 at 10:25 AM, Don Hinton <hintonda at gmail.com> wrote: > Hi Jack: > > Looks like I missed this one in my recent change. > > Please let me know if this solves your problem: > > $ git diff > diff --git a/utils/TableGen/InfoByHwMode.cpp > b/utils/TableGen/InfoByHwMode.cpp > index 7e1e1864356..8d3636432aa 100644 > ---

On Sat, Oct 14, 2017 at 11:25 AM, Don Hinton <hintonda at gmail.com> wrote: > Hi Jack: > > Yes, I was just looking at that. Seems like TableGen wasn't done along > with the rest of llvm. I'll work up a complete patch shortly. > > Btw, I'm curious how this happened. Do you have a stale CMakeCache.txt by > any chance? You might check the value for