public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: Roland McGrath <roland@hack.frob.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: Richard Henderson <rth@twiddle.net>,    <libc-ports@sourceware.org>
Subject: Re: [PATCH v2 12/14] arm: Add optimized addmul_1
Date: Fri, 25 Oct 2013 22:13:00 -0000	[thread overview]
Message-ID: <20131025221321.5D25C746AC@topped-with-meat.com> (raw)
In-Reply-To: Joseph S. Myers's message of  Wednesday, 6 March 2013 01:17:49 +0000 <Pine.LNX.4.64.1303060114560.27512@digraph.polyomino.org.uk>

[A very old thread, but I still had it sitting around.]

> On Fri, 1 Mar 2013, Roland McGrath wrote:
> 
> > I think the license is a non-problem since FSF is copyright owner.
> 
> My understanding was that FSF approval was needed for relicensing code 
> from other FSF-owned packages (as opposed to correcting simple mistakes, 
> e.g. making the license notice on a file reflect established licensing 
> practice for files used in a particular way).  (E.g., when license 
> exception notices were added to soft-fp for use in libgcc, that involved 
> FSF approval for adding those notices.)

Given that we imported GMP code before and had permission, I don't think we
really need new permission for more GMP code being used for the same
purpose.  That was 20 years ago and lots of things have changed, but I
still think so.  Nonetheless, the most conservative thing would be to ask
the current FSF authorities and make it clear that it is a continuation of
a past exception rather than an entirely fresh one.

> > But if your from-scratch code is good then I don't know there's a
> > strong reason to use GMP's instead, since we haven't been tracking
> > GMP changes in our copies for years anyway AFAIK.
> 
> I suspect other architectures might benefit from changes made in GMP to 
> improve performance - but certainly this is code that has diverged 
> significantly from the GMP versions over time.

Agreed.  I think the long-term right thing is to be sharing the code with
GMP.  But that requires both verifying that the reasons for the past
libc-local changes are satisfied by new GMP code, and establishing the
relationship with the current GMP maintainers so they understand what code
we are using and what extra constraints being used in libc puts on that
code (probably just name space issues and maybe PLT issues).


Thanks,
Roland

  reply	other threads:[~2013-10-25 22:13 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-01 17:36 [PATCH v2 00/14] ARM improvements Richard Henderson
2013-03-01 17:36 ` [PATCH v2 09/14] arm: Tidy architecture selection Richard Henderson
2013-03-01 17:55   ` Roland McGrath
2013-03-05  2:01   ` Joseph S. Myers
2013-03-01 17:36 ` [PATCH v2 05/14] arm: Use push/pop mnemonics Richard Henderson
2013-03-01 17:36 ` [PATCH v2 08/14] arm: Unless arm4t, pop return address directly into pc Richard Henderson
2013-03-01 17:36 ` [PATCH v2 02/14] arm: Introduce and use NEGOFF series of macros Richard Henderson
2013-03-01 17:57   ` Roland McGrath
2013-03-05  1:42   ` Joseph S. Myers
2013-03-01 17:36 ` [PATCH v2 12/14] arm: Add optimized addmul_1 Richard Henderson
2013-03-01 17:58   ` Roland McGrath
2013-03-01 18:00   ` Roland McGrath
2013-03-06  1:18     ` Joseph S. Myers
2013-10-25 22:13       ` Roland McGrath [this message]
2013-03-06  1:11   ` Joseph S. Myers
2013-03-01 17:36 ` [PATCH v2 03/14] arm: Introduce and use GET_TLS Richard Henderson
2013-03-01 17:57   ` Roland McGrath
2013-03-05  1:45   ` Joseph S. Myers
2013-03-01 17:36 ` [PATCH v2 11/14] arm: Add optimized ffs for armv6t2 Richard Henderson
2013-03-05  2:08   ` Joseph S. Myers
2013-03-06 15:52     ` Richard Henderson
2013-03-01 17:36 ` [PATCH v2 07/14] arm: Commonize BX conditionals Richard Henderson
2013-03-01 17:36 ` [PATCH v2 01/14] arm: Introduce and use LDST_PCREL Richard Henderson
2013-03-04 17:47   ` Joseph S. Myers
2013-03-01 17:36 ` [PATCH v2 13/14] arm: Add optimized submul_1 Richard Henderson
2013-03-01 17:58   ` Roland McGrath
2013-03-06  1:14   ` Joseph S. Myers
2013-03-01 17:36 ` [PATCH v2 06/14] arm: Delete LOADREGS macro Richard Henderson
2013-03-01 17:36 ` [PATCH v2 10/14] arm: Implement hard-tp for GET_TLS Richard Henderson
2013-03-01 17:55   ` Roland McGrath
2013-03-05  2:01   ` Joseph S. Myers
2013-03-01 17:36 ` [PATCH v2 14/14] arm: Add optimized add_n and sub_n Richard Henderson
2013-03-01 17:59   ` Roland McGrath
2013-03-06  0:53   ` Joseph S. Myers
2013-03-01 17:36 ` [PATCH v2 04/14] arm: Enable thumb2 mode in assembly files Richard Henderson

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=20131025221321.5D25C746AC@topped-with-meat.com \
    --to=roland@hack.frob.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-ports@sourceware.org \
    --cc=rth@twiddle.net \
    /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).