soft-fp: Support rsigned == 2 in _FP_TO_INT
diff mbox

Message ID Pine.LNX.4.64.1409232040060.8132@digraph.polyomino.org.uk
State New
Headers show

Commit Message

Joseph Myers Sept. 23, 2014, 8:41 p.m. UTC
Continuing the addition of soft-fp features in the Linux kernel
version, this patch adds _FP_TO_INT support for rsigned == 2 (reduce
overflowing results modulo 2^rsize to fit in the destination, used for
alpha emulation).  (This patch is relative to a tree with
<https://sourceware.org/ml/libc-alpha/2014-09/msg00411.html>,
<https://sourceware.org/ml/libc-alpha/2014-09/msg00442.html>,
<https://sourceware.org/ml/libc-alpha/2014-09/msg00461.html>,
<https://sourceware.org/ml/libc-alpha/2014-09/msg00463.html>,
<https://sourceware.org/ml/libc-alpha/2014-09/msg00464.html> and
<https://sourceware.org/ml/libc-alpha/2014-09/msg00488.html> applied;
there are actual dependencies on at least the fourth and fifth of
those patches.)

The kernel version is buggy; it can left shift by a negative amount
when right shifting is required in an overflow case (the kernel
version also has other bugs fixed long ago in glibc; at least,
spurious exceptions converting to the most negative integer).  This
version avoids that by handling overflow (other than to 0) for rsigned
== 2 along with the normal non-overflow case, which already properly
determines the direction in which to shift.

Tested for powerpc-nofpu.  Some functions get slightly bigger and some
get slightly smaller, no doubt as a result of the change to where in
the macro "inexact" is raised, but I don't think those changes are
significant.  Also tested for powerpc-nofpu with the relevant __fix*
functions changed to use rsigned == 2 (which is after all just as
valid as rsigned == 1 in IEEE terms), including verifying the results
and exceptions for various cases of conversions.

With these seven patches, the one remaining feature to add for the
soft-fp code to have all the features of the kernel version is
_FP_TO_INT_ROUND.

2014-09-23  Joseph Myers  <joseph@codesourcery.com>

	* soft-fp/op-common.h (_FP_TO_INT): Handle rsigned == 2.

Comments

Joseph Myers Sept. 30, 2014, 2:40 p.m. UTC | #1
Ping.  This patch 
<https://sourceware.org/ml/libc-alpha/2014-09/msg00544.html> is pending 
review.
Carlos O'Donell Sept. 30, 2014, 2:47 p.m. UTC | #2
On 09/30/2014 10:40 AM, Joseph S. Myers wrote:
> Ping.  This patch 
> <https://sourceware.org/ml/libc-alpha/2014-09/msg00544.html> is pending 
> review.

Who do we expect to review these patches? There is a considerable amount of
work required to review soft-fp, and at present I find it hard to be motivated
for anything but hard float.

I think soft-fp is useful for embedded targets, do we have anyone else in the
community working on embedded targets that might help with review?

Cheers,
Carlos.
Joseph Myers Sept. 30, 2014, 5:28 p.m. UTC | #3
On Tue, 30 Sep 2014, Carlos O'Donell wrote:

> On 09/30/2014 10:40 AM, Joseph S. Myers wrote:
> > Ping.  This patch 
> > <https://sourceware.org/ml/libc-alpha/2014-09/msg00544.html> is pending 
> > review.
> 
> Who do we expect to review these patches? There is a considerable amount of
> work required to review soft-fp, and at present I find it hard to be motivated
> for anything but hard float.

Well, soft-fp is used in libgcc for x86/x86_64 for __float128 support, for 
example, and in the Linux kernel on various architectures both for 
emulation on soft-float processors and to handle traps to the kernel on 
processors where some floating-point cases are handled in hardware but 
various special cases trap to software - the feature this particular patch 
adds is used in the kernel for Alpha (see 
<https://sourceware.org/ml/libc-alpha/2013-10/msg00347.html> regarding the 
desire to resync the kernel with glibc soft-fp again).  (Some 
architectures have their own floating-point emulation implementations in 
the kernel for whatever reason, rather than using soft-fp.)
Joseph Myers Oct. 6, 2014, 10:03 a.m. UTC | #4
Ping^2.  This patch 
<https://sourceware.org/ml/libc-alpha/2014-09/msg00544.html> is still 
pending review.
Joseph Myers Oct. 7, 2014, 4:22 p.m. UTC | #5
On Tue, 30 Sep 2014, Carlos O'Donell wrote:

> On 09/30/2014 10:40 AM, Joseph S. Myers wrote:
> > Ping.  This patch 
> > <https://sourceware.org/ml/libc-alpha/2014-09/msg00544.html> is pending 
> > review.
> 
> Who do we expect to review these patches? There is a considerable amount of
> work required to review soft-fp, and at present I find it hard to be motivated
> for anything but hard float.

(With reference to 
<https://sourceware.org/ml/libc-alpha/2014-09/msg00679.html>.)

Perhaps we should have subsystem maintainers for more areas than just 
architecture ports, where the number of people interested in a particular 
area is limited?  The principle would be that changes by those people in 
those areas are presumed to have consensus and not need someone else to 
review them, in the absence of any actual objections that show the absence 
of consensus (but it would still be the case that anyone could express 
their concerns about such a change, or a change in such an area could 
reach consensus through review by people other than the subsystem 
maintainers, especially when it's just part of a global change, just as 
today with architecture changes).

I'd be willing to be a subsystem maintainer in this sense for soft-fp and 
the conform/ tests.
Carlos O'Donell Oct. 7, 2014, 6:07 p.m. UTC | #6
On 10/07/2014 12:22 PM, Joseph S. Myers wrote:
> On Tue, 30 Sep 2014, Carlos O'Donell wrote:
> 
>> On 09/30/2014 10:40 AM, Joseph S. Myers wrote:
>>> Ping.  This patch 
>>> <https://sourceware.org/ml/libc-alpha/2014-09/msg00544.html> is pending 
>>> review.
>>
>> Who do we expect to review these patches? There is a considerable amount of
>> work required to review soft-fp, and at present I find it hard to be motivated
>> for anything but hard float.
> 
> (With reference to 
> <https://sourceware.org/ml/libc-alpha/2014-09/msg00679.html>.)
> 
> Perhaps we should have subsystem maintainers for more areas than just 
> architecture ports, where the number of people interested in a particular 
> area is limited?  The principle would be that changes by those people in 
> those areas are presumed to have consensus and not need someone else to 
> review them, in the absence of any actual objections that show the absence 
> of consensus (but it would still be the case that anyone could express 
> their concerns about such a change, or a change in such an area could 
> reach consensus through review by people other than the subsystem 
> maintainers, especially when it's just part of a global change, just as 
> today with architecture changes).

I agree. We should have some kind of subsystem maintainers to simplify
the process of finding an expert to review your patch, and simplifying
the work for the subsystem maintainer.

> I'd be willing to be a subsystem maintainer in this sense for soft-fp and 
> the conform/ tests.

We should see consensus on the idea of subsystem maintainers.

I'd like to see others comment that they are OK with the idea.

Cheers,
Carlos.
Torvald Riegel Oct. 7, 2014, 7:44 p.m. UTC | #7
On Tue, 2014-10-07 at 14:07 -0400, Carlos O'Donell wrote:
> On 10/07/2014 12:22 PM, Joseph S. Myers wrote:
> > On Tue, 30 Sep 2014, Carlos O'Donell wrote:
> > 
> >> On 09/30/2014 10:40 AM, Joseph S. Myers wrote:
> >>> Ping.  This patch 
> >>> <https://sourceware.org/ml/libc-alpha/2014-09/msg00544.html> is pending 
> >>> review.
> >>
> >> Who do we expect to review these patches? There is a considerable amount of
> >> work required to review soft-fp, and at present I find it hard to be motivated
> >> for anything but hard float.
> > 
> > (With reference to 
> > <https://sourceware.org/ml/libc-alpha/2014-09/msg00679.html>.)
> > 
> > Perhaps we should have subsystem maintainers for more areas than just 
> > architecture ports, where the number of people interested in a particular 
> > area is limited?  The principle would be that changes by those people in 
> > those areas are presumed to have consensus and not need someone else to 
> > review them, in the absence of any actual objections that show the absence 
> > of consensus (but it would still be the case that anyone could express 
> > their concerns about such a change, or a change in such an area could 
> > reach consensus through review by people other than the subsystem 
> > maintainers, especially when it's just part of a global change, just as 
> > today with architecture changes).
> 
> I agree. We should have some kind of subsystem maintainers to simplify
> the process of finding an expert to review your patch, and simplifying
> the work for the subsystem maintainer.
> 
> > I'd be willing to be a subsystem maintainer in this sense for soft-fp and 
> > the conform/ tests.
> 
> We should see consensus on the idea of subsystem maintainers.
> 
> I'd like to see others comment that they are OK with the idea.

This would be fine with me.  If we have areas of glibc where only a few
people (or, 1 person) are knowledgeable enough to maintain it, then we
can as well be honest about it :)
Siddhesh Poyarekar Oct. 8, 2014, 6:55 a.m. UTC | #8
On Tue, Oct 07, 2014 at 02:07:30PM -0400, Carlos O'Donell wrote:
> > I'd be willing to be a subsystem maintainer in this sense for soft-fp and 
> > the conform/ tests.
> 
> We should see consensus on the idea of subsystem maintainers.
> 
> I'd like to see others comment that they are OK with the idea.

I am OK with Joseph as subsystem maintainer for the soft-fp and
conform bits.

Siddhesh
Matthew Fortune Oct. 8, 2014, 9:39 a.m. UTC | #9
Carlos O'Donell <carlos@redhat.com> writes:
> On 10/07/2014 12:22 PM, Joseph S. Myers wrote:
> > On Tue, 30 Sep 2014, Carlos O'Donell wrote:
> >
> >> On 09/30/2014 10:40 AM, Joseph S. Myers wrote:
> >>> Ping.  This patch
> >>> <https://sourceware.org/ml/libc-alpha/2014-09/msg00544.html> is
> pending
> >>> review.
> >>
> >> Who do we expect to review these patches? There is a considerable
> amount of
> >> work required to review soft-fp, and at present I find it hard to be
> motivated
> >> for anything but hard float.
> >
> > (With reference to
> > <https://sourceware.org/ml/libc-alpha/2014-09/msg00679.html>.)
> >
> > Perhaps we should have subsystem maintainers for more areas than just
> > architecture ports, where the number of people interested in a
> particular
> > area is limited?  The principle would be that changes by those people in
> > those areas are presumed to have consensus and not need someone else to
> > review them, in the absence of any actual objections that show the
> absence
> > of consensus (but it would still be the case that anyone could express
> > their concerns about such a change, or a change in such an area could
> > reach consensus through review by people other than the subsystem
> > maintainers, especially when it's just part of a global change, just as
> > today with architecture changes).
> 
> I agree. We should have some kind of subsystem maintainers to simplify
> the process of finding an expert to review your patch, and simplifying
> the work for the subsystem maintainer.
> 
> > I'd be willing to be a subsystem maintainer in this sense for soft-fp
> and
> > the conform/ tests.
> 
> We should see consensus on the idea of subsystem maintainers.
> 
> I'd like to see others comment that they are OK with the idea.

From a newcomer's perspective it would help to know who has a good
understanding of each major area. The consensus based approach is good
but it is not always clear whether an OK from someone is really
sufficient or not. i.e. someone who has the slightest doubt about a
change could wait on the subsystem maintainer commenting even if others
say OK.

I would definitely agree that an expert in one area of glibc should not
be held up by lack of reviewers with enough interest or experience.

Matthew
Thomas Schwinge Oct. 8, 2014, 9:49 a.m. UTC | #10
Hi!

On Tue, 07 Oct 2014 21:44:45 +0200, Torvald Riegel <triegel@redhat.com> wrote:
> On Tue, 2014-10-07 at 14:07 -0400, Carlos O'Donell wrote:
> > On 10/07/2014 12:22 PM, Joseph S. Myers wrote:
> > > Perhaps we should have subsystem maintainers for more areas than just 
> > > architecture ports, where the number of people interested in a particular 
> > > area is limited?  The principle would be that changes by those people in 
> > > those areas are presumed to have consensus and not need someone else to 
> > > review them, in the absence of any actual objections that show the absence 
> > > of consensus (but it would still be the case that anyone could express 
> > > their concerns about such a change, or a change in such an area could 
> > > reach consensus through review by people other than the subsystem 
> > > maintainers, especially when it's just part of a global change, just as 
> > > today with architecture changes).
> > 
> > I agree. We should have some kind of subsystem maintainers to simplify
> > the process of finding an expert to review your patch, and simplifying
> > the work for the subsystem maintainer.
> > 
> > > I'd be willing to be a subsystem maintainer in this sense for soft-fp and 
> > > the conform/ tests.
> > 
> > We should see consensus on the idea of subsystem maintainers.
> > 
> > I'd like to see others comment that they are OK with the idea.
> 
> This would be fine with me.  If we have areas of glibc where only a few
> people (or, 1 person) are knowledgeable enough to maintain it, then we
> can as well be honest about it :)

I agree.  So, basically, extend (and rename)
<https://sourceware.org/glibc/wiki/MAINTAINERS#Reviewers_by_component>.


Grüße,
 Thomas
Torvald Riegel Oct. 8, 2014, 10:31 a.m. UTC | #11
On Wed, 2014-10-08 at 11:49 +0200, Thomas Schwinge wrote:
> Hi!
> 
> On Tue, 07 Oct 2014 21:44:45 +0200, Torvald Riegel <triegel@redhat.com> wrote:
> > On Tue, 2014-10-07 at 14:07 -0400, Carlos O'Donell wrote:
> > > On 10/07/2014 12:22 PM, Joseph S. Myers wrote:
> > > > Perhaps we should have subsystem maintainers for more areas than just 
> > > > architecture ports, where the number of people interested in a particular 
> > > > area is limited?  The principle would be that changes by those people in 
> > > > those areas are presumed to have consensus and not need someone else to 
> > > > review them, in the absence of any actual objections that show the absence 
> > > > of consensus (but it would still be the case that anyone could express 
> > > > their concerns about such a change, or a change in such an area could 
> > > > reach consensus through review by people other than the subsystem 
> > > > maintainers, especially when it's just part of a global change, just as 
> > > > today with architecture changes).
> > > 
> > > I agree. We should have some kind of subsystem maintainers to simplify
> > > the process of finding an expert to review your patch, and simplifying
> > > the work for the subsystem maintainer.
> > > 
> > > > I'd be willing to be a subsystem maintainer in this sense for soft-fp and 
> > > > the conform/ tests.
> > > 
> > > We should see consensus on the idea of subsystem maintainers.
> > > 
> > > I'd like to see others comment that they are OK with the idea.
> > 
> > This would be fine with me.  If we have areas of glibc where only a few
> > people (or, 1 person) are knowledgeable enough to maintain it, then we
> > can as well be honest about it :)
> 
> I agree.  So, basically, extend (and rename)
> <https://sourceware.org/glibc/wiki/MAINTAINERS#Reviewers_by_component>.

Or add the additional column for "component owners".

We might also want to not just base this on components, but other
cross-cutting things like "security".  For example, I'd be happy to
review everything related to concurrency.
Joseph Myers Oct. 8, 2014, 11:42 a.m. UTC | #12
On Wed, 8 Oct 2014, Thomas Schwinge wrote:

> > This would be fine with me.  If we have areas of glibc where only a few
> > people (or, 1 person) are knowledgeable enough to maintain it, then we
> > can as well be honest about it :)
> 
> I agree.  So, basically, extend (and rename)
> <https://sourceware.org/glibc/wiki/MAINTAINERS#Reviewers_by_component>.

I don't think it's obvious that every defined area needs to / should have 
a maintainer, or that everyone listed as a reviewer should thereby be 
considered to have consensus for their patches in that area.  (After all, 
we decided to have community review for x86/x86_64 patches rather that 
having maintainers who routinely apply their patches there without 
separate review.)

At least initially I was thinking about areas that are reasonably 
self-contained and specialized - even if we had stdio experts routinely 
reviewing all patches in that area (and we could probably do with such; 
Adhemerval's fmemopen patch has been pending review for some time), it 
might still be a good idea for other people to review their patches, as 
with x86 port patches.

Of the areas listed there, I'd say hurd, localedata, math, nis, nscd, 
regex, soft-fp would be suitable for having subsystem maintainers in the 
sense I suggest.  In view of Andreas stepping down I'll also volunteer to 
be such a subsystem maintainer for math, though I hope other people will 
also continue to review patches there, especially where optimized .S 
implementations are involved.  (I also think questions of adding new 
functions to the ABI, whoever is adding them, would best go to community 
consensus - if I were to start adding new functions from TS 18661, for 
example, it would be desirable to have agreement first that the functions 
should indeed be added to the libraries in question, even if no-one else 
reviewed the details of the implementations.)
Joseph Myers Oct. 8, 2014, 11:45 a.m. UTC | #13
On Wed, 8 Oct 2014, Torvald Riegel wrote:

> > I agree.  So, basically, extend (and rename)
> > <https://sourceware.org/glibc/wiki/MAINTAINERS#Reviewers_by_component>.
> 
> Or add the additional column for "component owners".
> 
> We might also want to not just base this on components, but other
> cross-cutting things like "security".  For example, I'd be happy to
> review everything related to concurrency.

And the conform/ tests which I volunteered to maintain don't have a 
Bugzilla component (nor do they need one - I think there are zero open 
bugs for them).  So, yes, maintainers and reviewers make sense in areas 
not directly corresponding to Bugzilla components (but if significant 
parts of the catch-all "libc" component can be clearly distinguished from 
the rest, it's possible more Bugzilla components should be added 
accordingly - though we added a few components a while back for some such 
areas).
Siddhesh Poyarekar Oct. 8, 2014, 3:19 p.m. UTC | #14
On Wed, Oct 08, 2014 at 11:42:09AM +0000, Joseph S. Myers wrote:
> Of the areas listed there, I'd say hurd, localedata, math, nis, nscd, 
> regex, soft-fp would be suitable for having subsystem maintainers in the 
> sense I suggest.  In view of Andreas stepping down I'll also volunteer to 
> be such a subsystem maintainer for math, though I hope other people will 
> also continue to review patches there, especially where optimized .S 
> implementations are involved.  (I also think questions of adding new 

At the expense of overestimating my expertise in various components
(and my understanding of the way our development model works), I
volunteer to be subsystem maintainer for benchtests (since I wrote it)
and nscd (since I spent a fair bit of time fixing netgroups bugs and
miscellaneous things).  I can also be fallback for malloc since I
spent a fair bit of time in that code for work reasons in the past
(tech support debugging other people's memory corruption is fun, for
some liberal definitions of fun).

I can also back you up on libm, specifically the multiple precision
bits since I shuffled that code around a bit a couple of years ago and
also because I'm pretty sure nobody else will touch it ;)

Of course, I understand if anyone objects saying that I don't have the
expertise that I think I have.

Siddhesh
Joseph Myers Oct. 8, 2014, 3:31 p.m. UTC | #15
On Wed, 8 Oct 2014, Siddhesh Poyarekar wrote:

> At the expense of overestimating my expertise in various components
> (and my understanding of the way our development model works), I
> volunteer to be subsystem maintainer for benchtests (since I wrote it)
> and nscd (since I spent a fair bit of time fixing netgroups bugs and
> miscellaneous things).  I can also be fallback for malloc since I
> spent a fair bit of time in that code for work reasons in the past
> (tech support debugging other people's memory corruption is fun, for
> some liberal definitions of fun).

I support having you as maintainer for benchtests and nscd.  malloc is 
sufficiently central I think we may be better off having reviewers for it.
Joseph Myers Oct. 8, 2014, 11:29 p.m. UTC | #16
On Wed, 8 Oct 2014, Torvald Riegel wrote:

> > I agree.  So, basically, extend (and rename)
> > <https://sourceware.org/glibc/wiki/MAINTAINERS#Reviewers_by_component>.
> 
> Or add the additional column for "component owners".
> 
> We might also want to not just base this on components, but other
> cross-cutting things like "security".  For example, I'd be happy to
> review everything related to concurrency.

I've added more reviewers to that table based on this discussion.  We may 
wish to allow for more discussion of subsystem maintainers as people who 
can assume consensus for their changes in a given area by default (the 
general concept, or specific people for specific components) before 
listing any of those.
Carlos O'Donell Oct. 9, 2014, 1:26 a.m. UTC | #17
On 09/23/2014 04:41 PM, Joseph S. Myers wrote:
> Continuing the addition of soft-fp features in the Linux kernel
> version, this patch adds _FP_TO_INT support for rsigned == 2 (reduce
> overflowing results modulo 2^rsize to fit in the destination, used for
> alpha emulation).  (This patch is relative to a tree with
> <https://sourceware.org/ml/libc-alpha/2014-09/msg00411.html>,
> <https://sourceware.org/ml/libc-alpha/2014-09/msg00442.html>,
> <https://sourceware.org/ml/libc-alpha/2014-09/msg00461.html>,
> <https://sourceware.org/ml/libc-alpha/2014-09/msg00463.html>,
> <https://sourceware.org/ml/libc-alpha/2014-09/msg00464.html> and
> <https://sourceware.org/ml/libc-alpha/2014-09/msg00488.html> applied;
> there are actual dependencies on at least the fourth and fifth of
> those patches.)
> 
> The kernel version is buggy; it can left shift by a negative amount
> when right shifting is required in an overflow case (the kernel
> version also has other bugs fixed long ago in glibc; at least,
> spurious exceptions converting to the most negative integer).  This
> version avoids that by handling overflow (other than to 0) for rsigned
> == 2 along with the normal non-overflow case, which already properly
> determines the direction in which to shift.
> 
> Tested for powerpc-nofpu.  Some functions get slightly bigger and some
> get slightly smaller, no doubt as a result of the change to where in
> the macro "inexact" is raised, but I don't think those changes are
> significant.  Also tested for powerpc-nofpu with the relevant __fix*
> functions changed to use rsigned == 2 (which is after all just as
> valid as rsigned == 1 in IEEE terms), including verifying the results
> and exceptions for various cases of conversions.
> 
> With these seven patches, the one remaining feature to add for the
> soft-fp code to have all the features of the kernel version is
> _FP_TO_INT_ROUND.
> 
> 2014-09-23  Joseph Myers  <joseph@codesourcery.com>
> 
> 	* soft-fp/op-common.h (_FP_TO_INT): Handle rsigned == 2.

Looks good to me.

> diff --git a/soft-fp/op-common.h b/soft-fp/op-common.h
> index 3deb9b1..cab6fba 100644
> --- a/soft-fp/op-common.h
> +++ b/soft-fp/op-common.h
> @@ -1390,6 +1390,8 @@
>     1:  the number is required to be -(2^(rsize-1))..(2^(rsize-1))-1, if not,
>         NV is set plus the result is either -(2^(rsize-1)) or (2^(rsize-1))-1
>         depending on the sign in such case.
> +   2:  the number is required to be -(2^(rsize-1))..(2^(rsize-1))-1, if not,
> +       NV is set plus the result is reduced modulo 2^rsize.

OK.

>     -1: the number is required to be -(2^(rsize-1))..(2^rsize)-1, if not, NV is
>         set plus the result is either -(2^(rsize-1)) or (2^(rsize-1))-1
>         depending on the sign in such case.  */
> @@ -1411,10 +1413,28 @@
>  	  else								\
>  	    FP_SET_EXCEPTION (FP_EX_INEXACT);				\
>  	}								\
> -      else if (X##_e >= (_FP_EXPMAX_##fs < _FP_EXPBIAS_##fs + rsize	\
> -			 ? _FP_EXPMAX_##fs				\
> -			 : _FP_EXPBIAS_##fs + rsize - (rsigned > 0 || X##_s)) \
> -	       || (!rsigned && X##_s))					\
> +      else if (rsigned == 2						\
> +	       && (X##_e						\
> +		   >= ((_FP_EXPMAX_##fs					\
> +			< _FP_EXPBIAS_##fs + _FP_FRACBITS_##fs + rsize - 1) \
> +		       ? _FP_EXPMAX_##fs				\
> +		       : _FP_EXPBIAS_##fs + _FP_FRACBITS_##fs + rsize - 1))) \
> +	{								\
> +	  /* Overflow resulting in 0.  */				\
> +	  r = 0;							\
> +	  FP_SET_EXCEPTION (FP_EX_INVALID				\
> +			    | FP_EX_INVALID_CVI				\
> +			    | ((FP_EX_INVALID_SNAN			\
> +				&& _FP_ISSIGNAN (fs, wc, X))		\
> +			       ? FP_EX_INVALID_SNAN			\

OK.

> +			       : 0));					\
> +	}								\
> +      else if (rsigned != 2						\
> +	       && (X##_e >= (_FP_EXPMAX_##fs < _FP_EXPBIAS_##fs + rsize	\
> +			     ? _FP_EXPMAX_##fs				\
> +			     : (_FP_EXPBIAS_##fs + rsize		\
> +				- (rsigned > 0 || X##_s)))		\
> +		   || (!rsigned && X##_s)))				\

OK.



>  	{								\
>  	  /* Overflow or converting to the most negative integer.  */	\
>  	  if (rsigned)							\
> @@ -1461,6 +1481,7 @@
>  	}								\
>        else								\
>  	{								\
> +	  int _FP_TO_INT_inexact = 0;					\
>  	  _FP_FRAC_HIGH_RAW_##fs (X) |= _FP_IMPLBIT_##fs;		\
>  	  if (X##_e >= _FP_EXPBIAS_##fs + _FP_FRACBITS_##fs - 1)	\
>  	    {								\
> @@ -1469,17 +1490,27 @@
>  	    }								\
>  	  else								\
>  	    {								\
> -	      int _FP_TO_INT_inexact;					\
>  	      _FP_FRAC_SRST_##wc (X, _FP_TO_INT_inexact,		\
>  				  (_FP_FRACBITS_##fs + _FP_EXPBIAS_##fs - 1 \
>  				   - X##_e),				\
>  				  _FP_FRACBITS_##fs);			\
> -	      if (_FP_TO_INT_inexact)					\
> -		FP_SET_EXCEPTION (FP_EX_INEXACT);			\
>  	      _FP_FRAC_ASSEMBLE_##wc (r, X, rsize);			\
>  	    }								\
>  	  if (rsigned && X##_s)						\
>  	    r = -r;							\
> +	  if (rsigned == 2 && X##_e >= _FP_EXPBIAS_##fs + rsize - 1)	\
> +	    {								\
> +	      /* Overflow or converting to the most negative integer.  */ \
> +	      if (X##_e > _FP_EXPBIAS_##fs + rsize - 1			\
> +		  || !X##_s						\
> +		  || r != (((typeof (r)) 1) << (rsize - 1)))		\
> +		{							\
> +		  _FP_TO_INT_inexact = 0;				\
> +		  FP_SET_EXCEPTION (FP_EX_INVALID | FP_EX_INVALID_CVI);	\
> +		}							\
> +	    }								\
> +	  if (_FP_TO_INT_inexact)					\
> +	    FP_SET_EXCEPTION (FP_EX_INEXACT);				\

OK.

>  	}								\
>      }									\
>    while (0)
> 

Cheers,
Carlos.
Carlos O'Donell Oct. 9, 2014, 1:30 a.m. UTC | #18
On 10/08/2014 11:31 AM, Joseph S. Myers wrote:
> On Wed, 8 Oct 2014, Siddhesh Poyarekar wrote:
> 
>> At the expense of overestimating my expertise in various components
>> (and my understanding of the way our development model works), I
>> volunteer to be subsystem maintainer for benchtests (since I wrote it)
>> and nscd (since I spent a fair bit of time fixing netgroups bugs and
>> miscellaneous things).  I can also be fallback for malloc since I
>> spent a fair bit of time in that code for work reasons in the past
>> (tech support debugging other people's memory corruption is fun, for
>> some liberal definitions of fun).
> 
> I support having you as maintainer for benchtests and nscd.  malloc is 
> sufficiently central I think we may be better off having reviewers for it.
> 

I agree. In general for core pieces of glibc we want multiple reviewers.

Cheers,
Carlos.
Joseph Myers Oct. 13, 2014, 11:35 a.m. UTC | #19
Does anyone else wish to comment on the idea of subsystem maintainers 
(whether generally, or specific people for specific areas)?
Thomas Schwinge Oct. 17, 2014, 8:20 a.m. UTC | #20
Hi!

On Wed, 8 Oct 2014 23:29:02 +0000, "Joseph S. Myers" <joseph@codesourcery.com> wrote:
> On Wed, 8 Oct 2014, Torvald Riegel wrote:
> 
> > > I agree.  So, basically, extend (and rename)
> > > <https://sourceware.org/glibc/wiki/MAINTAINERS#Reviewers_by_component>.
> > 
> > Or add the additional column for "component owners".

Yes, for example.

> > We might also want to not just base this on components, but other
> > cross-cutting things like "security".  For example, I'd be happy to
> > review everything related to concurrency.

Agreed.

> I've added more reviewers to that table based on this discussion.  We may 
> wish to allow for more discussion of subsystem maintainers as people who 
> can assume consensus for their changes in a given area by default (the 
> general concept, or specific people for specific components) before 
> listing any of those.

I'd like to propse Florian Weimer for the security "component" (that is,
issues related to system security).


Grüße,
 Thomas
Siddhesh Poyarekar Oct. 17, 2014, 8:23 a.m. UTC | #21
On Fri, Oct 17, 2014 at 10:20:35AM +0200, Thomas Schwinge wrote:
> I'd like to propse Florian Weimer for the security "component" (that is,
> issues related to system security).

+1

Siddhesh
Florian Weimer Oct. 17, 2014, 8:38 a.m. UTC | #22
On 10/17/2014 10:20 AM, Thomas Schwinge wrote:
>> I've added more reviewers to that table based on this discussion.  We may
>> wish to allow for more discussion of subsystem maintainers as people who
>> can assume consensus for their changes in a given area by default (the
>> general concept, or specific people for specific components) before
>> listing any of those.
>
> I'd like to propse Florian Weimer for the security "component" (that is,
> issues related to system security).

Fine with me, as long as it is understood that this does not cover the 
functional aspects of the NSS modules (e.g., how many supplementary 
groups you can set for a user using the NIS account database).  I can't 
really help with the latter.
Joseph Myers Oct. 20, 2014, 3:31 p.m. UTC | #23
Should I take it that we have consensus on the idea of subsystem 
maintainers, with me as such a maintainer for soft-fp and the conform/ 
tests?  (I don't think anyone commented on me as a maintainer for the math 
component.)
Roland McGrath Oct. 20, 2014, 6:15 p.m. UTC | #24
> Should I take it that we have consensus on the idea of subsystem 
> maintainers, with me as such a maintainer for soft-fp and the conform/ 
> tests?  (I don't think anyone commented on me as a maintainer for the math 
> component.)

I'm fine with all that, including math.
Joseph Myers Oct. 24, 2014, 12:47 a.m. UTC | #25
On Mon, 20 Oct 2014, Roland McGrath wrote:

> > Should I take it that we have consensus on the idea of subsystem 
> > maintainers, with me as such a maintainer for soft-fp and the conform/ 
> > tests?  (I don't think anyone commented on me as a maintainer for the math 
> > component.)
> 
> I'm fine with all that, including math.

I've now added the concept of subsystem maintainers to 
<https://sourceware.org/glibc/wiki/MAINTAINERS>, with myself listed for 
soft-fp and conform/ (still hoping for any more comments regarding the 
math component, and more volunteers as maintainers for the more 
specialised and self-contained areas, or reviewers for any area would be 
welcome).
Carlos O'Donell Nov. 4, 2014, 4:21 p.m. UTC | #26
On 10/08/2014 11:31 AM, Joseph S. Myers wrote:
> On Wed, 8 Oct 2014, Siddhesh Poyarekar wrote:
> 
>> At the expense of overestimating my expertise in various components
>> (and my understanding of the way our development model works), I
>> volunteer to be subsystem maintainer for benchtests (since I wrote it)
>> and nscd (since I spent a fair bit of time fixing netgroups bugs and
>> miscellaneous things).  I can also be fallback for malloc since I
>> spent a fair bit of time in that code for work reasons in the past
>> (tech support debugging other people's memory corruption is fun, for
>> some liberal definitions of fun).
> 
> I support having you as maintainer for benchtests and nscd.  malloc is 
> sufficiently central I think we may be better off having reviewers for it.

I also support Siddhesh as benchtests and nscd maintainer.

c.
Siddhesh Poyarekar Nov. 4, 2014, 4:24 p.m. UTC | #27
On Fri, Oct 24, 2014 at 12:47:29AM +0000, Joseph S. Myers wrote:
> I've now added the concept of subsystem maintainers to 
> <https://sourceware.org/glibc/wiki/MAINTAINERS>, with myself listed for 
> soft-fp and conform/ (still hoping for any more comments regarding the 
> math component, and more volunteers as maintainers for the more 
> specialised and self-contained areas, or reviewers for any area would be 
> welcome).

And I've given myself superpowers on benchtests and nscd given your
and Carlos' consent.

Siddhesh
Joseph Myers Nov. 4, 2014, 4:33 p.m. UTC | #28
On Tue, 4 Nov 2014, Siddhesh Poyarekar wrote:

> On Fri, Oct 24, 2014 at 12:47:29AM +0000, Joseph S. Myers wrote:
> > I've now added the concept of subsystem maintainers to 
> > <https://sourceware.org/glibc/wiki/MAINTAINERS>, with myself listed for 
> > soft-fp and conform/ (still hoping for any more comments regarding the 
> > math component, and more volunteers as maintainers for the more 
> > specialised and self-contained areas, or reviewers for any area would be 
> > welcome).
> 
> And I've given myself superpowers on benchtests and nscd given your
> and Carlos' consent.

Thanks - still short of comments regarding maintainership for the math 
component.
Siddhesh Poyarekar Nov. 4, 2014, 6:15 p.m. UTC | #29
On Tue, Nov 04, 2014 at 04:33:20PM +0000, Joseph Myers wrote:
> Thanks - still short of comments regarding maintainership for the math 
> component.

I agree with you being subsystem maintainer for the math component.

Siddhesh
Roland McGrath Nov. 4, 2014, 9:47 p.m. UTC | #30
> On Tue, Nov 04, 2014 at 04:33:20PM +0000, Joseph Myers wrote:
> > Thanks - still short of comments regarding maintainership for the math 
> > component.
> 
> I agree with you being subsystem maintainer for the math component.

Seconded (as someone who knows nothing useful about math code).
Joseph Myers Nov. 4, 2014, 10:16 p.m. UTC | #31
On Tue, 4 Nov 2014, Siddhesh Poyarekar wrote:

> On Tue, Nov 04, 2014 at 04:33:20PM +0000, Joseph Myers wrote:
> > Thanks - still short of comments regarding maintainership for the math 
> > component.
> 
> I agree with you being subsystem maintainer for the math component.

Thanks, now added there.  (If I have occasion to add new public interfaces 
to libm, or to deprecate existing interfaces, I'd still expect to seek a 
wider consensus before implementing things.)

Patch
diff mbox

diff --git a/soft-fp/op-common.h b/soft-fp/op-common.h
index 3deb9b1..cab6fba 100644
--- a/soft-fp/op-common.h
+++ b/soft-fp/op-common.h
@@ -1390,6 +1390,8 @@ 
    1:  the number is required to be -(2^(rsize-1))..(2^(rsize-1))-1, if not,
        NV is set plus the result is either -(2^(rsize-1)) or (2^(rsize-1))-1
        depending on the sign in such case.
+   2:  the number is required to be -(2^(rsize-1))..(2^(rsize-1))-1, if not,
+       NV is set plus the result is reduced modulo 2^rsize.
    -1: the number is required to be -(2^(rsize-1))..(2^rsize)-1, if not, NV is
        set plus the result is either -(2^(rsize-1)) or (2^(rsize-1))-1
        depending on the sign in such case.  */
@@ -1411,10 +1413,28 @@ 
 	  else								\
 	    FP_SET_EXCEPTION (FP_EX_INEXACT);				\
 	}								\
-      else if (X##_e >= (_FP_EXPMAX_##fs < _FP_EXPBIAS_##fs + rsize	\
-			 ? _FP_EXPMAX_##fs				\
-			 : _FP_EXPBIAS_##fs + rsize - (rsigned > 0 || X##_s)) \
-	       || (!rsigned && X##_s))					\
+      else if (rsigned == 2						\
+	       && (X##_e						\
+		   >= ((_FP_EXPMAX_##fs					\
+			< _FP_EXPBIAS_##fs + _FP_FRACBITS_##fs + rsize - 1) \
+		       ? _FP_EXPMAX_##fs				\
+		       : _FP_EXPBIAS_##fs + _FP_FRACBITS_##fs + rsize - 1))) \
+	{								\
+	  /* Overflow resulting in 0.  */				\
+	  r = 0;							\
+	  FP_SET_EXCEPTION (FP_EX_INVALID				\
+			    | FP_EX_INVALID_CVI				\
+			    | ((FP_EX_INVALID_SNAN			\
+				&& _FP_ISSIGNAN (fs, wc, X))		\
+			       ? FP_EX_INVALID_SNAN			\
+			       : 0));					\
+	}								\
+      else if (rsigned != 2						\
+	       && (X##_e >= (_FP_EXPMAX_##fs < _FP_EXPBIAS_##fs + rsize	\
+			     ? _FP_EXPMAX_##fs				\
+			     : (_FP_EXPBIAS_##fs + rsize		\
+				- (rsigned > 0 || X##_s)))		\
+		   || (!rsigned && X##_s)))				\
 	{								\
 	  /* Overflow or converting to the most negative integer.  */	\
 	  if (rsigned)							\
@@ -1461,6 +1481,7 @@ 
 	}								\
       else								\
 	{								\
+	  int _FP_TO_INT_inexact = 0;					\
 	  _FP_FRAC_HIGH_RAW_##fs (X) |= _FP_IMPLBIT_##fs;		\
 	  if (X##_e >= _FP_EXPBIAS_##fs + _FP_FRACBITS_##fs - 1)	\
 	    {								\
@@ -1469,17 +1490,27 @@ 
 	    }								\
 	  else								\
 	    {								\
-	      int _FP_TO_INT_inexact;					\
 	      _FP_FRAC_SRST_##wc (X, _FP_TO_INT_inexact,		\
 				  (_FP_FRACBITS_##fs + _FP_EXPBIAS_##fs - 1 \
 				   - X##_e),				\
 				  _FP_FRACBITS_##fs);			\
-	      if (_FP_TO_INT_inexact)					\
-		FP_SET_EXCEPTION (FP_EX_INEXACT);			\
 	      _FP_FRAC_ASSEMBLE_##wc (r, X, rsize);			\
 	    }								\
 	  if (rsigned && X##_s)						\
 	    r = -r;							\
+	  if (rsigned == 2 && X##_e >= _FP_EXPBIAS_##fs + rsize - 1)	\
+	    {								\
+	      /* Overflow or converting to the most negative integer.  */ \
+	      if (X##_e > _FP_EXPBIAS_##fs + rsize - 1			\
+		  || !X##_s						\
+		  || r != (((typeof (r)) 1) << (rsize - 1)))		\
+		{							\
+		  _FP_TO_INT_inexact = 0;				\
+		  FP_SET_EXCEPTION (FP_EX_INVALID | FP_EX_INVALID_CVI);	\
+		}							\
+	    }								\
+	  if (_FP_TO_INT_inexact)					\
+	    FP_SET_EXCEPTION (FP_EX_INEXACT);				\
 	}								\
     }									\
   while (0)