similar to: [LLVMdev] FreeBSD tester failure

On 2010-09-09 23:44, Jakob Stoklund Olesen wrote: > The clang-i686-freebsd-selfhost-rel buildbot is failing APIntTest.i33_Count on the first run, but the stage 2 test is passing. > > It looks like it could be a miscompilation by the system gcc. Yes, unfortunately on FreeBSD the first stage should be compiled using "-O2 -fno-strict-aliasing" instead of the default optimization

Hi all In unittests/ADT/APIntTest.cpp I came across this test: // XFAIL this test on FreeBSD where the system gcc-4.2.1 seems to miscompile it. #if defined(__llvm__) || !defined(__FreeBSD__) TEST(APIntTest, i33_Count) { APInt i33minus2(33, static_cast<uint64_t>(-2), true); EXPECT_EQ(0u, i33minus2.countLeadingZeros()); EXPECT_EQ(32u, i33minus2.countLeadingOnes()); EXPECT_EQ(33u,

The clang-i686-freebsd-selfhost-rel buildbot is failing APIntTest.i33_Count on the first run, but the stage 2 test is passing. It looks like it could be a miscompilation by the system gcc. We should upgrade the system gcc on that machine, or stop testing the stage 1 llvm. The tester is not useful as is. It is failing constantly. Who owns this machine? Can the system be upgraded? /jakob

Hi all, There's been a recent bootstrap failure that might be covered up because of another failure. I just wanted to point this out so that people can take a look: -bw Here's the failure from our buildbot: Assertion failed: (DestReg == VirtReg && "Unknown load situation!"), function RewriteMBB, file /Volumes/Sandbox/Buildbot/llvm/build.llvm-

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

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

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

On Wed, Jun 29, 2016 at 12:18 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 29 June 2016 at 20:14, Sean Silva <chisophugis at gmail.com> wrote: > > Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly > > important special case we may be able to agree on. (and I say this as > > somebody that largely builds cross-compilers (targeting

On Wed, Jun 29, 2016 at 12:04 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 29 June 2016 at 19:51, Sean Silva <chisophugis at gmail.com> wrote: > > Roughly speaking, I would prefer a repo division (if any) to be along the > > lines of "core toolchain" (clang, llvm, lld, compiler-rt) and "extra > stuff > > not strictly required".

On 29 June 2016 at 20:14, Sean Silva <chisophugis at gmail.com> wrote: > Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly > important special case we may be able to agree on. (and I say this as > somebody that largely builds cross-compilers (targeting PS4)) In that case, RT wouldn't "have" to be core. We use GCC rt-libs on GNU systems, even for

Folks, It seems we got the same issue with Clang alignment as before: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost/builds/3025 http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost-neon/builds/485 http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/118 Commits between 231213 and 231255. There are a few issues that could have brought it: *

Hi, Anyone knows what's going on with SVN? http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15 http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15 http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost-neon http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh etc. svn: E175012: Connection

Hi Richard, Marco, I noticed that you two are the remaining bot owners using the `getClangBuildFactory` from `ClangBuilder`. All the other bots using that builder have moved to the new `getClangCMakeBuildFactory`, including Windows ones. Given that they do similar functionalities, I'd like to encourage you to move to the new factory, so that we can simplify the builder's code. Thanks!

David Blaikie <dblaikie at gmail.com> writes: >>> Selfhost clang. Whenever we get a warning from Clang we either fix >>> Clang or fix the build quite quickly. >> >> Not possible, > > Out of curiosity - why not? (sure, I realize everyone has internal > build systems, etc, that they're ultimately integrating LLVM into - > but that doesn't mean

This is just a reminder to say that we will be branching for the LLVM 3.0 release Friday! 07:00:00 p.m. Friday October 14, 2011 PDT 02:00:00 a.m. Saturday October 15, 2011 GMT Now is the time to look at the buildbots and see what fixes they need: http://lab.llvm.org:8011/console As of this writing, we have: • several test failures on llvm-gcc self-host:

David Blaikie <dblaikie at gmail.com> writes: > Selfhost clang. Whenever we get a warning from Clang we either fix > Clang or fix the build quite quickly. Not possible, > If you want to fix the build such that LLVM can be built -Werror clean > with GCC the right solution is going to be to turn off -Wuninitialized > when the LLVM build system detects that it is using GCC

On Thu, Jan 3, 2013 at 11:16 AM, <dag at cray.com> wrote: > David Blaikie <dblaikie at gmail.com> writes: > >> Selfhost clang. Whenever we get a warning from Clang we either fix >> Clang or fix the build quite quickly. > > Not possible, Out of curiosity - why not? (sure, I realize everyone has internal build systems, etc, that they're ultimately

The first buildbot failure I can readily find was Monday, 26oct2009 around 7PM PDT. The assertion is Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad signature!"), function init, file /Volumes/Sandbox/Buildbot/llvm/

These self-host builders all just starting failing. It looks like tablegen is being miscompiled. The first failed builds: (1) http://lab.llvm.org:8011/builders/llvm-gcc-i386-linux-selfhost/builds/208 (2) http://lab.llvm.org:8011/builders/dragonegg-i386-linux/builds/194 (3) http://lab.llvm.org:8011/builders/dragonegg-x86_64-linux/builds/197 The odd thing is that I can't see any suspicious

> Problem is, there are REALLY bad std::string implementations out there in > widely used c++ runtimes. No doubt - though widely used to build llvm/clang? Perhaps, I suppose, I'm not sure just how portable llvm code is. > StringRef/Twine is efficient everywhere. Yep - I'm just pedantic about having a tidy codebase, and duplicate code to workaround bad implementations when