similar to: Should I worry about test failures in a release?

On Sun, Nov 22, 2015 at 8:40 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 22 November 2015 at 14:32, Brian Cain <brian.cain at gmail.com> wrote: > > AFAICT it's an OpenMP link error (that I got when running > "test-release.sh" > > with -openmp). > > Right. In that case, don't worry too much. > > The default release

On 11 October 2015 at 21:46, Joachim Durchholz via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Since I plan to use LLVM as a backend, not hack on it, I'm not going to get > much joy out of TRUNK, so I reverted to 3.7. > Which led me to the realization that GettingStarted does not mention > libcxxabi. That depends on what you use. If you use libc++, then you need to worry

On Sun, Nov 22, 2015 at 8:09 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 22 November 2015 at 03:59, Brian Cain <brian.cain at gmail.com> wrote: > > Should I expect the "-openmp" to work for this RC? > > Only if it worked before on the target you're building to in 3.7.0. > Ok, I'll check if I can get it to work on 3.7.0. > >

On 13 October 2015 at 09:19, Joachim Durchholz via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Oh... why do I need to rebase? If your project is a product that wants to benefit from the advances of LLVM over the years, you'll have to update the code to the newer versions some time. Moreover, if you do find a bug, and it's in an old version, you won't have the same response

Going from 3.6 to 3.7 would almost certainly break binary compatibility between .bc files. You may be able to get away with it for some particular use-cases (but in that case, it's by luck, not by design). I'm not enough "part of the community" to say if there are rules about what can and can't change between certain levels of releases, but my general understanding is that

Hi Galina, It seems that our libcxx bots are now triggering builds for any changes to llvm: http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/2434 Should I file a bug report for this? Thanks, Diana On Sat, 19 Oct 2019 at 11:36, Galina Kistanova via cfe-commits <cfe-commits at lists.llvm.org> wrote: > > Hello everyone, > > The staging master is

Hello build bot owners! The staging master is ready. Please feel free to use it to make sure your bots would work well with the monorepo and github. The following builders could be configured to build monorepo: * clang-atom-d525-fedora-rel * clang-native-arm-lnt-perf * clang-cmake-armv7-lnt * clang-cmake-armv7-selfhost-neon * clang-cmake-armv7-quick * clang-cmake-armv7-global-isel *

Hello everyone, Below are some buildbot numbers for the last week of 6/05/2016 - 6/11/2016. Thanks Galina buildername | was_red -----------------------------------------------------------+----------- sanitizer-x86_64-linux-bootstrap | 134:12:25 perf-x86_64-penryn-O3-polly-parallel-fast | 46:29:26

Hello everyone, Below are some buildbot numbers for the last week of 9/25/2016 - 10/1/2016. Please see the same data in attached csv files: The longest time each builder was red during the last week; "Status change ratio" by active builder (percent of builds that changed the builder status from greed to red or from red to green); Count of commits by project; Number of completed

I think what she is referring to was that the build seemed to be triggered by a commit to a project that shouldn't trigger builds on a libcxx bot (i.e. the change was in llvm). I have a somewhat orthogonal but related question. In the past, commits to compiler-rt did not trigger builds on llvm/clang/sanitizer bots. Has this behaviour been rectified with the move to github? I am really sorry

Hello everyone, Below are some buildbot numbers for the week of 7/10/2016 - 7/16/2016. Please see the same data in attached csv files: The longest time each builder was red during the week; "Status change ratio" by active builder (percent of builds that changed the builder status from greed to red or from red to green); Count of commits by project; Number of completed builds, failed

On 12 October 2015 at 16:29, Joachim Durchholz via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I've been planning to switch to a new release whenever it's out. > What are the advantages of following trunk? Some people prefer following releases and having a higher cost when migrating, other people prefer to spread the cost over many months, but you'll have to resolve

On 13 October 2015 at 13:45, Kuperstein, Michael M via llvm-dev <llvm-dev at lists.llvm.org> wrote: > As far as I know, the consensus was that all 3.x versions should retain > backward compatibility for bitcode. Emphasis on "should". :) I don't think we have enough tests to make sure we don't break that promise, precisely because it's important, but not crucial.

> On Jan 17, 2017, at 12:33 PM, Stephen Checkoway <s at pahtak.org> wrote: > > >> On Jan 17, 2017, at 10:11, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Actually you have to opt-in instead of opt-out right now, and I encourage you to try it if you’re contributing to LLVM:

Hello, I have just built LLVM with CMake by following these instructions https://llvm.org/docs/GettingStarted.html#getting-started-quickly-a-summary and I am trying to run the regression tests using "make check-all" but there are some unexpected failures in libcxx and libcxxabi. Here's the test log: Expected Passes : 40745 Expected Failures : 258 Unsupported Tests : 1594

Recently I have been building LLVM and Clang from the distribution using gcc 4.9.2. With the new 5.0.0 rc2 that is giving warning messages during the compilation. I have been trying out some other compilers. gcc 5.2 with -std=c++11 This works, although there are still some warnings. gcc 6.4 and gcc 7.1 fail with errors such as this in building libcxxabi as follows: Command:

On 05/19/2015 08:50 PM, Chris Matthews wrote: > Just some stats, after looking through lab.llvm.org > <http://lab.llvm.org>:8011 > > Maybe these should be marked as experimental, and removed from the > builders link on the main page. > > Never passed at all: > libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 > libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan >

Hi, During last 2-3 days I started to get some new regressions from the libc++ testsuite, one of them is std/containers/sequences/list/list.modifiers/insert_iter_iter_iter.pass.cpp . When run under gdb this seems to be a crash under libunwind code: Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00007ffff73d00ce in

Thank Ismail for quick reply. I read that Linux, we need to build... (1) libcxx (without libcxxabi) ==> done (2) build libcxxabi ==> failing with following error (3) and then re-build libcxx By the way I am building libcxx and libcxxabi Out-of-tree llvm build. Please correct me if I am missing something. Thank you. -Hiral -----Original Message----- From: İsmail Dönmez [mailto:ismail

On Thu, Jul 5, 2012 at 9:08 AM, Chandler Carruth <chandlerc at google.com>wrote: > In the same way that the core LLVM libraries have support routines for > DWARF, I think that both mangling and demangling should be provided as > well. I suspect that the 'Support' library is the best we have, although > eventually we need to split this library up a bit. That's not