search for: armv6hl

.../firmware firmware-loaders make[2]: Entering directory `/usr/src/dahdi-linux-complete-2.10.2+2.10.2/linux/drivers/dahdi/firmware' make[2]: Leaving directory `/usr/src/dahdi-linux-complete-2.10.2+2.10.2/linux/drivers/dahdi/firmware' make -C /lib/modules/3.12.26-1.20140808git4ab8abb.rpfr20.armv6hl.bcm2708/build SUBDIRS=/usr/src/dahdi-linux-complete-2.10.2+2.10.2/linux/drivers/dahdi DAHDI_INCLUDE=/usr/src/dahdi-linux-complete-2.10.2+2.10.2/linux/include DAHDI_MODULES_EXTRA=" " HOTPLUG_FIRMWARE=yes modules DAHDI_BUILD_ALL=m make[2]: Entering directory `/usr/src/kernels/3.12.26-1....

...that change, and it would be included in any revised diff that I send out. Thanks, - Will > On Jan 6, 2016, at 10:02 AM, Artyom Skrobov <Artyom.Skrobov at arm.com> wrote: > > William, what revision of LLVM is your patch based on? > > The trunk hasn't had ARM_ARCH("armv6hl") since r252903 (Nov 12th) > > > -----Original Message----- > From: William Dillon [mailto:william at housedillon.com] > Sent: 06 January 2016 17:55 > To: Renato Golin > Cc: Tim Northover; LLVM Dev; nd; Artyom Skrobov; Daniel Sanders; Eric Christopher > Subject: Re:...

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: llvm-armv6l.diff Type: application/octet-stream Size: 2198 bytes...

...>> On Jan 6, 2016, at 10:02 AM, Artyom Skrobov <Artyom.Skrobov at arm.com <mailto:Artyom.Skrobov at arm.com>> wrote: >>>> >>>> William, what revision of LLVM is your patch based on? >>>> >>>> The trunk hasn't had ARM_ARCH("armv6hl") since r252903 (Nov 12th) >>>> >>>> >>>> -----Original Message----- >>>> From: William Dillon [mailto:william at housedillon.com <mailto:william at housedillon.com>] >>>> Sent: 06 January 2016 17:55 >>>> To: Rena...

> 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

...his. > > 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 they can > shed some light. Going back through SVN history, I cannot find any evidence that ARMv6L ever existed. There used to be ARMv6HL, until r252903 changed it from an architecture variant into an alias for ARMv6K; i.e. ARMv6HL can still be used in a target triple. For a reference, http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Support/TargetParser.cpp?revision=238651 is the last version of TargetParser before any of our cha...

Hi all. I’ve been working with Swift on ARMv6 and v7. While working with ARMv6 on linux, I noticed that my arm architecture canonicalization code didn’t produce the expected result. The code that I had been using (within Swift’s Driver.cpp the following: static llvm::Triple computeTargetTriple(StringRef DefaultTargetTriple) { llvm::Triple triple = llvm::Triple(DefaultTargetTriple); //

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