public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Preparing to merge ARM/hard_vfp_branch to trunk
@ 2009-08-05 15:28 Richard Earnshaw
  2009-08-05 16:47 ` Eric Botcazou
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Richard Earnshaw @ 2009-08-05 15:28 UTC (permalink / raw)
  To: gcc; +Cc: Kazu Hirata, rth, davem, jakub, ebotcazou

I think we are now in the position where we can merge the arm hard-vfp
ABI code into trunk.  There are no known issues with the compiler code
and just one outstanding issue relating to tests and dealing with
compiler variants (multilibs and other options).  That issue shouldn't
prevent merging.

All the patches to non-arm code bar one have already received approval
for mainline integration.  The outstanding issue is a change to the
SPARC back-end to account for a change to the LIBCALL_VALUE macro.

I believe that I could legitimately approve that patch myself (it's
pretty trivial and I didn't author it), but I'd prefer to get approval
from one of the SPARC maintainers.  Here's your chance:

	http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01027.html

Once that issue is taken care of, I don't think there are any further
obstacles to completing the merge and propose to do that sometime over
the next week.

Comments/objections please?

R.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Preparing to merge ARM/hard_vfp_branch to trunk
  2009-08-05 15:28 Preparing to merge ARM/hard_vfp_branch to trunk Richard Earnshaw
@ 2009-08-05 16:47 ` Eric Botcazou
  2009-08-05 21:15   ` David Miller
  2009-08-06 14:21 ` Joseph S. Myers
  2009-08-06 19:35 ` Richard Earnshaw
  2 siblings, 1 reply; 5+ messages in thread
From: Eric Botcazou @ 2009-08-05 16:47 UTC (permalink / raw)
  To: Richard Earnshaw; +Cc: gcc, Kazu Hirata, rth, davem, jakub

> I believe that I could legitimately approve that patch myself (it's
> pretty trivial and I didn't author it), but I'd prefer to get approval
> from one of the SPARC maintainers.  Here's your chance:
>
> 	http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01027.html

OK.

-- 
Eric Botcazou

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Preparing to merge ARM/hard_vfp_branch to trunk
  2009-08-05 16:47 ` Eric Botcazou
@ 2009-08-05 21:15   ` David Miller
  0 siblings, 0 replies; 5+ messages in thread
From: David Miller @ 2009-08-05 21:15 UTC (permalink / raw)
  To: ebotcazou; +Cc: rearnsha, gcc, kazu, rth, jakub

From: Eric Botcazou <ebotcazou@adacore.com>
Date: Wed, 5 Aug 2009 17:59:01 +0200

>> I believe that I could legitimately approve that patch myself (it's
>> pretty trivial and I didn't author it), but I'd prefer to get approval
>> from one of the SPARC maintainers.  Here's your chance:
>>
>> 	http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01027.html
> 
> OK.

It looks fine to me too.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Preparing to merge ARM/hard_vfp_branch to trunk
  2009-08-05 15:28 Preparing to merge ARM/hard_vfp_branch to trunk Richard Earnshaw
  2009-08-05 16:47 ` Eric Botcazou
@ 2009-08-06 14:21 ` Joseph S. Myers
  2009-08-06 19:35 ` Richard Earnshaw
  2 siblings, 0 replies; 5+ messages in thread
From: Joseph S. Myers @ 2009-08-06 14:21 UTC (permalink / raw)
  To: Richard Earnshaw; +Cc: gcc

On Wed, 5 Aug 2009, Richard Earnshaw wrote:

> I think we are now in the position where we can merge the arm hard-vfp
> ABI code into trunk.  There are no known issues with the compiler code
> and just one outstanding issue relating to tests and dealing with
> compiler variants (multilibs and other options).  That issue shouldn't
> prevent merging.

I've remembered two outstanding issues from 
<http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00591.html>:

* The pcs attribute needs documentation and testcases.

* The attribute warning using %qs should now use %qE.

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Preparing to merge ARM/hard_vfp_branch to trunk
  2009-08-05 15:28 Preparing to merge ARM/hard_vfp_branch to trunk Richard Earnshaw
  2009-08-05 16:47 ` Eric Botcazou
  2009-08-06 14:21 ` Joseph S. Myers
@ 2009-08-06 19:35 ` Richard Earnshaw
  2 siblings, 0 replies; 5+ messages in thread
From: Richard Earnshaw @ 2009-08-06 19:35 UTC (permalink / raw)
  To: gcc; +Cc: Kazu Hirata, rth, davem, jakub, ebotcazou


On Wed, 2009-08-05 at 14:20 +0100, Richard Earnshaw wrote:
> I think we are now in the position where we can merge the arm hard-vfp
> ABI code into trunk.  There are no known issues with the compiler code
> and just one outstanding issue relating to tests and dealing with
> compiler variants (multilibs and other options).  That issue shouldn't
> prevent merging.
> 
> All the patches to non-arm code bar one have already received approval
> for mainline integration.  The outstanding issue is a change to the
> SPARC back-end to account for a change to the LIBCALL_VALUE macro.
> 
> I believe that I could legitimately approve that patch myself (it's
> pretty trivial and I didn't author it), but I'd prefer to get approval
> from one of the SPARC maintainers.  Here's your chance:
> 
> 	http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01027.html
> 
> Once that issue is taken care of, I don't think there are any further
> obstacles to completing the merge and propose to do that sometime over
> the next week.
> 
> Comments/objections please?
> 
> R.

I've now completed the merge.  A couple of late issues that Joseph has
just reminded me of will now be fixed on the trunk.

R.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2009-08-06 14:32 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-05 15:28 Preparing to merge ARM/hard_vfp_branch to trunk Richard Earnshaw
2009-08-05 16:47 ` Eric Botcazou
2009-08-05 21:15   ` David Miller
2009-08-06 14:21 ` Joseph S. Myers
2009-08-06 19:35 ` Richard Earnshaw

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).