similar to: [LLVMdev] Help diagnosing a failing hexagon bot?

Displaying 20 results from an estimated 9000 matches similar to: "[LLVMdev] Help diagnosing a failing hexagon bot?"

2014 Oct 02
3
[LLVMdev] How do I update Ocaml debug info? (was Re: [llvm] r218914 - DI: Fold constant arguments into a single MDString)
-llvm-commits, +llvmdev > On Oct 2, 2014, at 2:57 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > Author: dexonsmith > Date: Thu Oct 2 16:56:57 2014 > New Revision: 218914 > > URL: http://llvm.org/viewvc/llvm-project?rev=218914&view=rev > Log: > DI: Fold constant arguments into a single MDString > > This patch addresses the first
2015 Jun 04
2
[LLVMdev] Assert in BlockFrequency pass
> On 2015-Jun-04, at 12:45, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> On 2015-Jun-04, at 12:28, Ivan Baev <ibaev at codeaurora.org> wrote: >> >> Hi, we got the following assert: >> >> assert(!Working[0].isLoopHeader() && "entry block is a loop header"); >> >> [in
2019 Jun 01
2
Adding llvm-undname to the llvm-cov bot
Probably this job: lab.llvm.org:8080/green/job/clang-stage2-coverage-R/ 💬 from 📱 > On May 31, 2019, at 3:35 PM, Duncan Exon Smith <dexonsmith at apple.com> wrote: > > +Chris Matthews, do you know where the configs are stored for this? > >> On 2019 May 31, at 12:39, Chris Bieneman <beanz at apple.com> wrote: >> >> Hey Nico, >> >> I'm
2018 Jul 20
2
Marking lit::shtest-format.py unsupported on PS4?, Re: buildbot failure in LLVM on llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast
Should "lit :: shtest-format.py" (from check-lit) be marked unsupported on PS4? It seems flakey there. This evening, it failed on my commit, r337514, and I'm fairly confident it wasn't my commit's fault. Then it recovered on the next commit. http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/33502
2015 Jun 04
2
[LLVMdev] Assert in BlockFrequency pass
Hi, we got the following assert: assert(!Working[0].isLoopHeader() && "entry block is a loop header"); [in BlockFrequencyInfoImpl<BT>::tryToComputeMassInFunction(), BlockFrequencyInfoImpl.h] on a Hexagon target - the entry block is a loop header. Has someone seen this assert on other targets? What would be a preferable way to fix it: - extend BlockFrequency pass to
2018 Jun 23
4
RFC: Should SmallVectors be smaller?
> On Jun 23, 2018, at 10:14, Chris Lattner <clattner at nondot.org> wrote: > > > >> On Jun 23, 2018, at 9:11 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com <mailto:dexonsmith at apple.com>> wrote: >> >>> >>> I think we might be better off just reducing the pre-allocation size of most of our SmallVectors across LLVM and Clang.
2015 Jan 15
2
[LLVMdev] [RFC] First-class debug info IR: MDLocation (redux)
> On 2015-Jan-15, at 09:35, Hans Wennborg <hans at chromium.org> wrote: > > On Wed, Jan 14, 2015 at 8:26 PM, Duncan P. N. Exon Smith > <dexonsmith at apple.com> wrote: >> >>> On 2015 Jan 13, at 11:13, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: >>> >>>> I suspect it would actually be *better* if I got all this
2019 Jun 04
2
Adding llvm-undname to the llvm-cov bot
On Mon, Jun 3, 2019 at 2:06 PM <vsk at apple.com> wrote: > Hi Nico, > > Sorry for the delay, I've been OOO. The llvm-cov bot should produce > reports for llvm-undname starting today. > Thanks! It looks like http://lab.llvm.org:8080/coverage/coverage-reports/index.html now has an "llvm-undname" entry, but
2015 May 24
3
[LLVMdev] RFC: Reduce the memory footprint of DIEs (and DIEValues)
> On 2015 May 20, at 17:51, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > >> On 2015 May 20, at 17:39, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> >> With just those four patches, memory usage went *up* slightly. Add in >> the 5th patch (which does #2 below), and we get an overall memory drop >> of 4%. > >
2015 Sep 03
4
RFC: LTO should use -disable-llvm-verifier
On Thu, Sep 03, 2015 at 01:10:42AM +0000, Eric Christopher wrote: > On Tue, Sep 1, 2015 at 10:43 AM Duncan P. N. Exon Smith < > dexonsmith at apple.com> wrote: > > > > > > On 2015-Aug-31, at 18:09, Eric Christopher <echristo at gmail.com> wrote: > > > > > > > > > > > > On Mon, Aug 31, 2015 at 5:50 PM Duncan P. N. Exon Smith
2014 Jul 15
3
[LLVMdev] [cfe-dev] Bug in MapVector::erase ?
> On 2014-Jul-15, at 11:07, Reid Kleckner <rnk at google.com> wrote: > > Can we explicitly delete the erase method or do something else to document the fact that it is unsupported? It was added incidentally in r211350, even though it was added and removed by Doug back in r175538 / r175449. > I'm happy with it deleted or fixed (see WIP patch that fixes it w/o tests). For
2016 Mar 24
2
[RFC] Lazy-loading of debug info metadata
On Thu, Mar 24, 2016 at 6:35 AM, Duncan Exon Smith <dexonsmith at apple.com> wrote: > > > On Mar 24, 2016, at 6:22 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > > On Wed, Mar 23, 2016 at 11:06 PM, Duncan P. N. Exon Smith < > dexonsmith at apple.com> wrote: > >> >> > On 2016-Mar-22, at 19:28, Duncan P. N. Exon Smith via
2015 Apr 15
2
[LLVMdev] RFC: Metadata attachments to function definitions
> On 2015-Apr-15, at 10:03, Reid Kleckner <rnk at google.com> wrote: > > On Wed, Apr 15, 2015 at 9:46 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > I'm happy to defer to conventional wisdom here if anyone wants me to > (and TBH, I've only been looking at profiles that include debug info, > so maybe `sizeof(Function)` matters with -g0). >
2015 Jan 14
2
[LLVMdev] Crash on invalid during LLVMContext destruction MDNode::dropAllReferences
On Wed, Jan 14, 2015 at 9:05 AM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2015 Jan 14, at 07:58, Duncan P. N. Exon Smith <dexonsmith at apple.com> > wrote: > > > >> > >> On 2015 Jan 13, at 23:59, David Blaikie <dblaikie at gmail.com> wrote: > >> > >> > >> > >> On Tue, Jan 13, 2015
2016 Feb 27
5
Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")
----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames" > <listmail at philipreames.com>, "Duncan P. N. Exon Smith" > <dexonsmith at apple.com>, "Xinliang David Li"
2015 Sep 16
3
RFC: LTO should use -disable-llvm-verifier
On Tue, Sep 15, 2015 at 3:31 PM, Duncan P. N. Exon Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> On 2015-Sep-02, at 19:31, Peter Collingbourne <peter at pcc.me.uk> wrote: >> >> On Thu, Sep 03, 2015 at 01:10:42AM +0000, Eric Christopher wrote: >>> On Tue, Sep 1, 2015 at 10:43 AM Duncan P. N. Exon Smith < >>> dexonsmith at
2018 Jul 10
2
RFC: should we spell lambdas like functions?
> On Jul. 5, 2018, at 18:12, Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Thu, Jul 5, 2018 at 5:30 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > On Jul 5, 2018, at 1:09 PM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at
2015 Sep 01
2
RFC: LTO should use -disable-llvm-verifier
> On 2015-Aug-31, at 18:09, Eric Christopher <echristo at gmail.com> wrote: > > > > On Mon, Aug 31, 2015 at 5:50 PM Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > > On 2015-Aug-31, at 12:21, Eric Christopher <echristo at gmail.com> wrote: > > Yep. This is where I was going :) > > Glad I found consensus, but I want to
2015 Sep 16
5
RFC: LTO should use -disable-llvm-verifier
> On Sep 16, 2015, at 9:45 AM, Teresa Johnson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Sep 16, 2015 at 7:47 AM, Teresa Johnson <tejohnson at google.com> wrote: >> On Tue, Sep 15, 2015 at 3:31 PM, Duncan P. N. Exon Smith via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> >>>> On 2015-Sep-02, at 19:31, Peter
2019 Jun 06
4
Adding llvm-undname to the llvm-cov bot
On Wed, Jun 5, 2019 at 1:33 PM <vsk at apple.com> wrote: > > > On Jun 4, 2019, at 4:41 PM, Nico Weber <thakis at chromium.org> wrote: > > On Mon, Jun 3, 2019 at 2:06 PM <vsk at apple.com> wrote: > >> Hi Nico, >> >> Sorry for the delay, I've been OOO. The llvm-cov bot should produce >> reports for llvm-undname starting today. >>