public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Guy <martinwguy@gmail.com>
To: Ian Lance Taylor <iant@google.com>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	Nick Clifton <nickc@redhat.com>,
		Richard Earnshaw <richard.earnshaw@arm.com>,
	Paul Brook <paul@codesourcery.com>
Subject: Re: merging the maverick FPU patches
Date: Tue, 01 Jun 2010 23:39:00 -0000	[thread overview]
Message-ID: <AANLkTikvvBneYLfQn3tvNtel4Z4FL8muGyJ0vgK5x6Ds@mail.gmail.com> (raw)
In-Reply-To: <mcrbpd7queo.fsf@dhcp-172-17-9-151.mtv.corp.google.com>

On 4/25/10, Ian Lance Taylor <iant@google.com> wrote:
> Martin Guy <martinwguy@gmail.com> writes:
>
>  > now that stage3 is over I'm thinking of updating the
>  > MaverickCrunch FPU fixes (currently for 4.3) and merging them but
>  > would appreciate some guidance.
>  >
>  > There are 26 patches in all and I can't expect anyone to understand
>  > them because they require a good understanding of the FPU and its
>  > hardware bugs (and there are a lot of them!) :) What's the best path?
>  > Create a branch, work there and then merge when done?
>  >
>  > I have done the copyright assignment stuff but don't have an account
>  > on gcc.gnu.org. They all affect files under config/arm/ apart from one
>  > testsuite fix and the docs.
>
>
> For a backend specific patch like this, I would recommend contacting
>  the ARM backend maintainers directly to ask how they would prefer to
>  proceed.  They can be found in the top level MAINTAINERS file:
>
>  arm port                Nick Clifton            nickc@redhat.com
>  arm port                Richard Earnshaw        richard.earnshaw@arm.com
>  arm port                Paul Brook              paul@codesourcery.com

Hi
  I've had no reply from anyone - maybe everyone is hoping someone
else do so. :)
Of the three companies, redhat would be the most suitable, since the
original unfinished port was done by them, and I guess ARM has no
interest in making GCC work with non-ARM FPUs.
  The code they add/remove/change is pretty self-contained and doesn't
impact the other code generation options. It just fixes the current
implementation.
  Nick, are you willing to do the necessary? Since it just fixes
existing code that never worked, all it requires from a maintainer is
to check that it doesn't break code generation for other targets,
which is easy to check automatically by testing a sample of targets
and it's not hard to check by eye that the changes are only active
when TARGET_MAVERICK.

Cheers

   M

      reply	other threads:[~2010-06-01 23:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-25  9:47 Martin Guy
2010-04-25 18:07 ` Ian Lance Taylor
2010-06-01 23:39   ` Martin Guy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTikvvBneYLfQn3tvNtel4Z4FL8muGyJ0vgK5x6Ds@mail.gmail.com \
    --to=martinwguy@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=iant@google.com \
    --cc=nickc@redhat.com \
    --cc=paul@codesourcery.com \
    --cc=richard.earnshaw@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).