| Message ID | Pine.LNX.4.64.1409232040060.8132@digraph.polyomino.org.uk |
|---|---|
| State | New |
| Headers | show |
Ping. This patch <https://sourceware.org/ml/libc-alpha/2014-09/msg00544.html> is pending review.
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.
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.)
Ping^2. This patch <https://sourceware.org/ml/libc-alpha/2014-09/msg00544.html> is still pending review.
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.
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.
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 :)
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
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
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
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.
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.)
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).
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
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.
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.
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.
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.
Does anyone else wish to comment on the idea of subsystem maintainers (whether generally, or specific people for specific areas)?
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
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
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.
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.)
> 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.
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).
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.
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
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.
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
> 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).
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.)
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)