Tom Stellard
2014-Dec-05 20:15 UTC
[LLVMdev] ARM/AArch64 FreeBSD patches for 3.5.1 (was Re: Proposed patches for Clang 3.5.1)
On Sat, Nov 29, 2014 at 08:34:37PM +0100, Dimitry Andric wrote:> On 29 Nov 2014, at 02:48, Tom Stellard <tom at stellard.net> wrote: > > On Wed, Nov 26, 2014 at 07:44:20PM +0100, Dimitry Andric wrote: > ... > >> I would like to propose the following additional patches for 3.5.1. These will already be part of the upcoming clang 3.5.0 import into the FreeBSD 11.0 base system. Apologies in advance for the long list. :) > ... > > Can you cc the appropriate code owners to get their approval. It might > > help to send a separate email per code owner. > > Hi Chad, > > Can you please approve the following revisions for backporting to 3.5.1: > > r217454: Use armv6k default for FreeBSD/ARM > r221900: Hook up FreeBSD AArch64 support >cc'ing ARM an AArch64 code owners Links to the patches: http://llvm.org/viewvc/llvm-project?view=revision&revision=217454 http://llvm.org/viewvc/llvm-project?view=revision&revision=221900 I only see Chad listed as code owner for fast-isel, I'm not sure why he would need to approve these patches. Is there a FreeBSD code owner? These patches seem to only affect FreeBSD and are fairly trivial. As long as Tim and Evan don't have any objections I think these can be merged. -Tom
Tim Northover
2014-Dec-05 20:27 UTC
[LLVMdev] ARM/AArch64 FreeBSD patches for 3.5.1 (was Re: Proposed patches for Clang 3.5.1)
> Is there a FreeBSD code owner? These patches seem to only affect > FreeBSD and are fairly trivial. As long as Tim and Evan don't have > any objections I think these can be merged.They both look completely innocuous on the ARM/AArch64 side. Only FreeBSD people can really say if they're right for that OS, and since they're the ones asking for the merge I reckon it should be fine. Cheers. Tim.
Dimitry Andric
2014-Dec-05 20:35 UTC
[LLVMdev] ARM/AArch64 FreeBSD patches for 3.5.1 (was Re: Proposed patches for Clang 3.5.1)
On 05 Dec 2014, at 21:27, Tim Northover <t.p.northover at gmail.com> wrote:> >> Is there a FreeBSD code owner? These patches seem to only affect >> FreeBSD and are fairly trivial. As long as Tim and Evan don't have >> any objections I think these can be merged. > > They both look completely innocuous on the ARM/AArch64 side. Only > FreeBSD people can really say if they're right for that OS, and since > they're the ones asking for the merge I reckon it should be fine.Yes, both patches were originally submitted by Andrew Turner (andrew at FreeBSD.org), who is one of the FreeBSD/arm maintainers. (Note that we are already using these patches in our project branch for importing clang 3.5.0.) -Dimitry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141205/0ce1805e/attachment.sig>
David Chisnall
2014-Dec-05 20:36 UTC
[LLVMdev] ARM/AArch64 FreeBSD patches for 3.5.1 (was Re: Proposed patches for Clang 3.5.1)
On 5 Dec 2014, at 20:15, Tom Stellard <tom at stellard.net> wrote:> Is there a FreeBSD code owner? These patches seem to only affect > FreeBSD and are fairly trivial. As long as Tim and Evan don't have > any objections I think these can be merged.We don't have one officially. Roman, Dimitry, Ed and I intermittently fill that rôle. Since the patch is from Ed, and Dimitry wants to merge it, there's a good chance that it's the right thing for FreeBSD. David
Renato Golin
2014-Dec-05 21:39 UTC
[LLVMdev] ARM/AArch64 FreeBSD patches for 3.5.1 (was Re: Proposed patches for Clang 3.5.1)
On 5 December 2014 at 20:36, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:> We don't have one officially. Roman, Dimitry, Ed and I intermittently fill that rôle. Since the patch is from Ed, and Dimitry wants to merge it, there's a good chance that it's the right thing for FreeBSD.Maybe you guys should pick one and add to the file, but still share the role, to make it easier to request reviews in the future. --renato