similar to: Fwd: buildbot failure in LLVM on sanitizer-x86_64-linux-bootstrap

Oops, I neglected to reply-all…. The current stable branch at github still has it: https://github.com/apple/swift-llvm/blob/stable/include/llvm/Support/ARMTargetParser.def#L106 <https://github.com/apple/swift-llvm/blob/stable/include/llvm/Support/ARMTargetParser.def#L106> Should I get the head of the non-swift repository and generate a new diff? Also, I suspect that it’s not a good idea

Thanks for the clarifications, Bob! I’ve spent some time with the head of the llvm.org repo, and I now understand a lot better what Renato and Tim were talking about re. the architecture aliases. The patch to add v6l, therefore, seems simple enough. I haven’t been able to test it in my usual flow, because that involves the whole swift stack. I’m considering creating a program that links to

> You assume triples make sense. That's the first mistake everyone does > when thinking about triples. :) I know they don't make sense in many corner cases, but I think discarding logic where it *does* exist is a mistake. > AFAIK, "ARMv7B" is only used by HighBank, which is no more. But that, > too, was "ARMv7A big endian". I believe it's what any

Thank you very much for the references, we've missed this discussion from last week. Seeing that the RFC hasn’t got any new responses since Wed 12th, is now the time to declare that the community has accepted the proposal, and to update the docs? Or is there any formal deadline for objections to be raised? -----Original Message----- From: meinersbur at googlemail.com [mailto:meinersbur at

Hello, About a month ago, I submitted a set of patches for review on llvm-commit. The most controversial of the patches, http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20150622/d104ea7 1/attachment-0009.obj deals with the fact that before ARMv8, the rGPR RegClass in Thumb encodings didn't include SP; but from ARMv8 onwards, it does include it. RegClass membership is

Taking the suggestions of the group under consideration, I’ve generated a new diff. The thing to note is that armv6l is now treated identically to armv6hl. I’ve also added a unit test. This seems to me to be the least invasive method, and holds to existing conventions as closely as possible. Thoughts? -------------- next part -------------- A non-text attachment was scrubbed... Name:

>> Going back through SVN history, I cannot find any evidence that ARMv6L ever existed. > > Oh, my bad!! I was thinking of ARMv7l... :/ > > Nevertheless, I'll leave you guys to review this one, as I lost touch with the parser a while ago. Ah, I see: ARMv7L is now an alias for ARMv7A. So, if William has to add support for ARMv6L, I'd suggest he adds it as an alias, and

This buildbot seems to have been failing continuously for a couple of weeks now ( http://lab.llvm.org:8011/builders/llvm-mips-linux/builds/14658 ) - is anyone watching it/caring about it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Wed, Sep 30, 2015 at 11:34 PM Subject: buildbot failure in LLVM on llvm-mips-linux To: Ahmed Bougacha

Hello, http://llvm.org/docs/GettingStarted.html#software lists "GCC >=4.7.0" among requirements for building LLVM. However, my attempt of building LLVM+Clang with gcc 4.7.3 has failed with a multitude of errors, such as: lib/LTO/Caching.cpp:74:7: error: looser throw specifier for 'virtual llvm::lto::localCache(std::string, llvm::lto::AddFileFn)::<lambda(unsigned int,

The failure is a bit odd. LLVM is ignoring $PWD because it doesn't have the same inode as '.'. This causes the test failure because DW_AT_comp_dir and $PWD differ. However, $PWD and '.' should be the same inode since $PWD is a symlink to the current directory and stat() looks through symlinks. > Since this latest board only has two cores, it will run slower and it will need

>> However, because the DefaultTargetTriple is armv6l-unknown-linux-gnueabihf, >> and llvm didn’t know about v6l, it would fail to match and canonicalize to armv6. >> I added the notion of v6l to llvm to address this. > > ARMv6l was definitely there once. I'm not sure what happened. > > I'm copying the ARM folks that did most of the recent changes in hope

On May 26, 2014, at 8:21 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Mon, May 26, 2014 at 7:41 PM, Andrew Trick <atrick at apple.com> wrote: > On May 26, 2014, at 5:02 PM, Chandler Carruth <chandlerc at google.com> wrote: > >> >> On Mon, May 26, 2014 at 4:43 PM, Andrew Trick <atrick at apple.com> wrote: >> This has been

This builder is taking too long to build. (The build stops because of a timeout.) Chip On Aug 30, 2013, at 11:29 AM, llvm.buildmaster at lab.llvm.org wrote: > The Buildbot has detected a new failure on builder clang-amd64-openbsd while building llvm. > Full details are available at: > http://lab.llvm.org:8011/builders/clang-amd64-openbsd/builds/1103 > > Buildbot URL:

Hi all, I stumbled over a problem in ilist_node::getPrevNode(). It crashes when invoked for the first element in a list. It's because the Prev pointer of a first list element does not point to the sentinel but is just null. First question: Is this really a bug or am I doing something wrong? Second question: If it is a bug, what should be the correct behaviour? Either change insert() to let

On Sat, Oct 15, 2011 at 12:26 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Sat, Oct 15, 2011 at 7:38 AM, Thomson <lilotom at gmail.com> wrote: >> I just found that some samples used link.exe from Visual Studio to generate >> the final image, does LLVM has a replacement for link.exe to generate the >> final binary? I'm not related to the topic

FWIW, I'm good with the updated data, but I'd really like at least someone from Apple and someone from ARM to chime in here... CC-ing random people in the hope it helps... On Mon, Feb 13, 2017 at 8:30 AM Dehao Chen via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thanks for the comment. The performance experiments were performed on > Intel Sandybridge. Updated this info to

On 02/10/2017 05:21 PM, Dehao Chen wrote: > Thanks every for the comments. > > Do we have a decision here? You're good to go as far as I'm concerned. -Hal > > Dehao > > On Tue, Feb 7, 2017 at 10:24 PM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > > On 02/07/2017 05:29 PM, Sanjay Patel via llvm-dev wrote:

On Tue, May 30, 2017 at 1:40 AM Agabaria, Mohammed via llvm-dev < llvm-dev at lists.llvm.org> wrote: > We’re seeing nice improvements but also significant degradations on IA, > which we would like to investigate before the patch is committed. > > > > Major degradations we see: > > > > networking > > ip_pktcheckb1m -6.80 % > >

Guys, Just to clarify that with the current fix in SLM there is no need to wait for other issues to be fixed (minor issue). So you can move on with your patch. From: Agabaria, Mohammed Sent: Wednesday, June 07, 2017 15:24 To: Zaks, Ayal <ayal.zaks at intel.com>; Chandler Carruth <chandlerc at gmail.com>; Flamedoge <code.kchoi at gmail.com>; Dehao Chen <dehao at google.com>

On 02/07/2017 05:29 PM, Sanjay Patel via llvm-dev wrote: > Sorry if I missed it, but what machine/CPU are you using to collect > the perf numbers? > > I am concerned that what may be a win on a CPU that keeps a couple of > hundred instructions in-flight and has many MB of caches will not hold > for a small core. In my experience, unrolling tends to help weaker cores even more