Displaying 20 results from an estimated 1100 matches similar to: "buildbot failure in LLVM on sanitizer-x86_64-linux-gn"
2019 Jul 31
2
buildbot failure in LLVM on sanitizer-x86_64-linux-gn
vitalybuka, sanitizer-x86_64-linux-gn is _still_ on
http://lab.llvm.org:8011/console . Can we please get it removed?
On Wed, Jul 3, 2019 at 7:07 AM Nico Weber <thakis at chromium.org> wrote:
> https://reviews.llvm.org/D63909 landed. Maybe it needs a master restart
> to have an effect?
>
> On Wed, Jul 3, 2019 at 1:03 PM Roman Lebedev <lebedev.ri at gmail.com> wrote:
>
2019 Jun 27
2
buildbot failure in LLVM on sanitizer-x86_64-linux-gn
Why is there a public GN buildbot that sends emails and IRC notifications?
That isn't what was agreed upon. Either un-GM it, or silence it.
Roman.
On Fri, Jun 28, 2019 at 1:05 AM <llvm.buildmaster at lab.llvm.org> wrote:
>
> The Buildbot has detected a new failure on builder sanitizer-x86_64-linux-gn while building llvm.
> Full details are available at:
>
2019 Jul 31
2
buildbot failure in LLVM on sanitizer-x86_64-linux-gn
On Wed, Jul 31, 2019 at 11:37 AM Vitaly Buka via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I have no idea how.
> Are there particular problems? Now it should be quite.
> Console has a bunch of stale builders which are even less useful.
>
LLVM has a silent build master that does not send email. When Nico added
the gn build, apparently we promised not to set up builders
2018 Nov 01
2
[cfe-dev] GN build roundtable summary; adding GN build files to the repo
Any easy way to do this as some kind of overlay, so they GN files wouldn't
live in the LLVM repository, but in a separate one?
(this might avoid some of the community discussion - though would perhaps
still likely have the issue I see as most significant: With a sufficient
number of developers using GN, the rate of build breaks due to those
developers missing CMake file updates might rise to
2018 Nov 01
2
[cfe-dev] GN build roundtable summary; adding GN build files to the repo
On Thu, Nov 1, 2018 at 1:22 AM Vedant Kumar via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
>
> Hi all,
>
>> On Oct 31, 2018, at 11:18 AM, Nico Weber via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>> Hi,
>>
>> first things first: If you're happy with cmake, you can stop reading now.
>>
I'm not, I just put up with it :)
> ...
2019 Aug 31
2
clang.exp/gn
Hello,
I was wondering who owns the clang.exp bots which builds llvm using gn?
I need to add another generator to clang-tablegen, but the build seems
to be failing:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-gn/builds/4816
I'd appreciate it if someone could take a look at the problem.
Thank you,
Nandor Licker
2018 Nov 06
2
[cfe-dev] GN build roundtable summary; adding GN build files to the repo
Awesome. I'm happy with moving the .rst file into that directory and not
have it on the public website. I'll try to make a patch that lands enough
scaffolding to build `not` in the next few days, and then I'll land the
other build files I have through the regular build process after that.
Unless someone feels strongly, I'll go with Justin's suggestion of
llvm/utils/gn/...
On
2018 Nov 06
2
[cfe-dev] GN build roundtable summary; adding GN build files to the repo
The value in having them somewhere in-tree is that it's easier for people
collaborate on these files, and it's way lower setup overhead if someone
wants to try it out. If people prefer llvm/util over llvm/experimental,
that's fine with me.
There would only be a single directory that will contain build files for
all of llvm, clang, lld, etc. The build files would be in
2018 Nov 05
3
[cfe-dev] GN build roundtable summary; adding GN build files to the repo
If I read this correctly, there isn't much opposition to landing the gn
files as long as it's very clear that regular devs aren't supposed to
update them and that it's clear that they're experimental
The main concerns I've heard so far:
- Having two build systems is confusing. I can see this, but I think
putting the gn files below llvm/experimental/gn (instead of right
2017 May 09
2
lib/CodeGen/AsmPrinter/DwarfDebug.h:131: void llvm::DbgVariable::addMMIEntry(const llvm::DbgVariable&): Assertion `V.Var == Var && "conflicting variable"' failed.
David, Dean, all,
The bots got red today with assertion failures in
llvm::DbgVariable::addMMIEntry:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/1816/steps/check-msan%20in%20gcc%20build/logs/stdio
I did not find the offender yet. Any ideas?
clang-5.0: /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h:131:
void
2017 May 09
2
lib/CodeGen/AsmPrinter/DwarfDebug.h:131: void llvm::DbgVariable::addMMIEntry(const llvm::DbgVariable&): Assertion `V.Var == Var && "conflicting variable"' failed.
Thanks!
On Mon, May 8, 2017 at 6:25 PM, Reid Kleckner <rnk at google.com> wrote:
> I give it 99% odds it was r302483. Let's revert and debug it tomorrow.
>
> On Mon, May 8, 2017 at 6:20 PM, Kostya Serebryany via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> David, Dean, all,
>>
>> The bots got red today with assertion failures in
>>
2015 May 08
3
[LLVMdev] buildbot failure in LLVM on sanitizer-x86_64-linux
Hey Alexey,
This bot has been failing for a week, by the looks of it - what's the deal?
On Thu, May 7, 2015 at 7:31 PM, <llvm.buildmaster at lab.llvm.org> wrote:
> The Buildbot has detected a new failure on builder sanitizer-x86_64-linux
> while building llvm.
> Full details are available at:
> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/17810
>
2015 May 08
2
[LLVMdev] buildbot failure in LLVM on sanitizer-x86_64-linux
I'm sure it's obvious and I'm just blind, but I can't find the relevant
part of that build that's showing a crash. Can you help me out?
On Fri, May 8, 2015 at 1:49 PM, Alexey Samsonov <vonosmas at gmail.com> wrote:
> +Sergey
>
> The bot failed on (and looks like it still fails even after LLVM r236877)
> on AddressSanitizer-i386-linux ::
2015 May 13
2
[LLVMdev] Confusing buildbot failure in LLVM on sanitizer-x86_64-linux
Alexey, I got mail from one of the tsan buildbots, claiming a breakage
in tsan tests. But I cannot see anything on the logs it has for the
build.
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/17916/steps/run%2064-bit%20tsan%20unit%20tests/logs/stdio
Any ideas? Thanks. Diego.
---------- Forwarded message ----------
From: <llvm.buildmaster at lab.llvm.org>
Date: Wed,
2015 May 13
2
[LLVMdev] Confusing buildbot failure in LLVM on sanitizer-x86_64-linux
On Wed, May 13, 2015 at 10:39 AM, Reid Kleckner <rnk at google.com> wrote:
> It's a 20m timeout without output.
>
> If you back up to the build and look at the 'annotate' step output,
> there's this text:
>
> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/17916/steps/annotate/logs/stdio
>
> -- Testing: 258 tests, 16 threads --
>
2015 May 14
0
[LLVMdev] Confusing buildbot failure in LLVM on sanitizer-x86_64-linux
+dvyukov
On Wed, May 13, 2015 at 11:08 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
> On Wed, May 13, 2015 at 10:39 AM, Reid Kleckner <rnk at google.com> wrote:
>
>> It's a 20m timeout without output.
>>
>> If you back up to the build and look at the 'annotate' step output,
>> there's this text:
>>
>>
2015 May 29
2
[LLVMdev] Confusing buildbot failure in LLVM on sanitizer-x86_64-linux
Happened to me again:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/18273/steps/annotate/logs/stdio
In fact, this whole bot has a 20% failure rate with the same failure mode,
from looking at the history:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/?numbuilds=50
They all end with this:
[100%] Running ThreadSanitizer tests
-- Testing: 258 tests, 16 threads --
2024 Aug 09
1
WDI package commands timing out and not working
>>>>> Ivan Krylov via R-help
>>>>> on Fri, 9 Aug 2024 15:23:58 +0300 writes:
> ? Thu, 8 Aug 2024 12:43:23 +0530
> Anupam Tyagi <anuptyagi at gmail.com> ?????:
>> In open.connection(con, "rb") :
>> URL
>>
2014 Jun 06
2
[LLVMdev] buildbot failure in LLVM on sanitizer-x86_64-linux (-Wframe-larger-than)
On 06/06/2014 02:33, Alexey Samsonov wrote:
> Hi Alp,
>
> This warning should be fixed by r210301. However, consider
> investigating why the frame size appears to be that large. I believe
> we build this code with GCC as well and have seen no complaints
> from its implementation of -Wframe-larger-than.
CC'ing in llvmdev. Like Chandler said it could just be due to lack of
2011 Mar 19
2
problem running a function
Dear people,
I'm trying to do some analysis of a data using the models by Royle & Donazio
in their fantastic book, particular the following function:
http://www.mbr-pwrc.usgs.gov/pubanalysis/roylebook/panel4pt1.fn
that applied to my data and in the console is as follows:
> `desman.y` <- structure(c(3L,4L,3L,2L,1L), .Names = c("1", "2", "3",