similar to: Diff to add ARMv6L to Target parser

>> 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

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

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

> 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

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

Hello LLVMdev!! Yesterday I posted a patch request to the llvm-commits list requesting that someone could apply a patch to Triple.h and Triple.cpp for me. I didn't get any response so I wondered whether I should have posted to this list instead. My story is as follows: we are trying to get lldb/llvm support for CSRs range of Kalimba DSPs. Eventually we are planning to hire someone to

Hi all, Thank you so much for this discussion. It has been very helpful and educational. I think that I understand the perspectives of both Tim and Renato. Let me briefly summarize them to ensure that I correctly understand: Renato’s perspective is that the triple means whatever the author says it does, and that may or not be meaningful. :) In the case of armv7l (for example) it has a clear

Hi, IMO we should support this, even though if given the option I'd have asked the linux guys not to invent a new triple. It's in linux now, and `uname -a` is a very standard way of obtaining the host's triple. James On Tue, 5 Jan 2016 at 08:34 Tim Northover via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 4 January 2016 at 14:42, Artyom Skrobov via llvm-dev >

On 7/9/14, 12:33 PM, Eric Christopher wrote: > Any reason why you deleted code that isn't related? > > -eric > >> - enum SubArchType { >> - NoSubArch, >> - >> - ARMSubArch_v8, >> - ARMSubArch_v7, >> - ARMSubArch_v7em, >> - ARMSubArch_v7m, >> - ARMSubArch_v7s, >> - ARMSubArch_v6, >> -

On 5 January 2016 at 09:13, Renato Golin <renato.golin at linaro.org> wrote: > Anyhow, Artyom's proposal is the best, IMO, to treat it like an alias > and handle like v7A internally. If we end up needing specific > decisions in the driver, it should stay in the driver. That's rather a hack, given that the 'l' actually has semantic meaning, but I suppose I could live

Eric Christopher wrote: > On Wed, Jul 9, 2014 at 11:39 AM, Jonathan Roelofs > <jonathan at codesourcery.com> wrote: >> >> On 7/9/14, 12:33 PM, Eric Christopher wrote: >>> Any reason why you deleted code that isn't related? >>> >>> -eric >>> >>>> - enum SubArchType { >>>> - NoSubArch, >>>> -

On 5 January 2016 at 10:55, Renato Golin <renato.golin at linaro.org> wrote: > On 5 January 2016 at 10:28, Tim Northover <t.p.northover at gmail.com> wrote: >> That's rather a hack, given that the 'l' actually has semantic >> meaning, but I suppose I could live with it. > > Not really. I disagree. "armv7l" is created specifically by Linux

In R 3.3.2 detectCores() in package parallel reports 2 rather than 1 on Raspberry Pi B+ running Raspbian. (This report is just 'for the record'. The model is superseded and I think no longer produced.) The problem seems to be caused by grep processor /proc/cpuinfo processor : 0 model name : ARMv6-compatible processor rev 7 (v6l) (On Raspberry Pi 2 and 3 there is no error because

I just purchased an Amfeltec USB-FXO adapter and am trying to compile DAHDI 2.10 on a Raspberry PI running Pidora 2014 R3. I have all the dependencies but I get an error and cannot finish. Is it even possible to compile DAHDI for the ARM plataform? Here is the error I am getting: root at astpi dahdi-linux-complete-2.10.2+2.10.2]# make make -C linux all make[1]: Entering directory

I was successful in compiling asterisk in raspbien except for the following error If I enable the gsm codec. It appears there is something in the Makefile n this directory that needs to be changed. Probably involving optimization. Not sure why it does not recognize the processor since it is one that is mentioned in the Makefile.? Any help would be appreciated. make[2]: Entering directory

Sounds good, I'll give it a try sooner or later. I've never messed with triples, so is there anything I need to be aware of so I don't break any code on other platforms? In particular, I want llvm::sys::getDefaultTargetTriple() to return me this new haswell-aware triple, so what do I need to do to ensure that I don't break anyone else who is running one of these systems and

I'm working on LLDB and we have a bunch of code that is manually manipulating triples and doing a bunch of nasty stuff to account for the fact that llvm::Triple doesn't currently have a way to detect x86_64h. Is this something that llvm::Triple could be modified to support? Either as a new ArchType, or a new SubArchType? -------------- next part -------------- An HTML attachment was

Hi Fred, Thanks. How did you get to " The build log show this error: /Users/buildslave/as-bldslv9/lld-x86_64-darwin13/llvm.src/lib/Target/ARM/MCTargetDesc/ARMMCTargetDesc.cpp:92:11: error: enumeration values 'KalimbaSubArch_v3', 'KalimbaSubArch_v4', and 'KalimbaSubArch_v5' not handled in switch [-Werror,-Wswitch] switch (triple.getSubArch()) { " from here

On Feb 16, 2016, at 12:57 AM, T. Ermlich <pelegrine at gmail.com> wrote: > > Sorry for the email only send to you, Charles! > Here's the one for the list. I realize it is no longer a common list configuration. Feel free to use "Reply All" in Gmail - I won't get two copies. > torsten at raspberrypi ~ $ uname -a > Linux raspberrypi 4.1.13-v7+ #826 SMP