similar to: [LLVMdev] regression in llvm 3.4 branch

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

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

+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

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

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>

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

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

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

Current llvm/clang/compiler-rt/polly/testsuite/libcxx from 3.4 branch is broken during the bootstrap on x86_64-apple-darwin12 against Xcode 5's clang with the failure... [ 54%] [ 54%] Building CXX object lib/Analysis/CMakeFiles/LLVMAnalysis.dir/AliasAnalysisCounter.cpp.o Building CXX object lib/ExecutionEngine/CMakeFiles/LLVMExecutionEngine.dir/ExecutionEngine.cpp.o

Current llvm svn fails make check when built for only x86... [100%] Running the LLVM regression tests FAIL: LLVM :: DebugInfo/inlined-vars.ll (3994 of 7466) ******************** TEST 'LLVM :: DebugInfo/inlined-vars.ll' FAILED ******************** Script: -- /sw/src/fink.build/llvm33-3.3-0/llvm-3.3/build/bin/./llc -O0 <

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

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

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

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

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

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

The new cmake 3.7.0-rc1 release produces a stage2 bootstrap failure in openmp project build on OS X 10.11 under Xcode 8.... In file included from /sw/src/fink.build/llvm40-4.0.0-1/llvm-4.0.0.src/projects/openmp/runtime/src/kmp_alloc.c:16: In file included from /sw/src/fink.build/llvm40-4.0.0-1/llvm-4.0.0.src/projects/openmp/runtime/src/kmp.h:98: