This is the mail archive of the
mailing list for the glibc project.
Re: Use of "SUSPENDED" in Bugzilla
On Sun, 19 Feb 2012, Aurelien Jarno wrote:
> > So when should we use SUSPENDED? My inclination: SUSPENDED is if there is
> > known to be something particularly hard about fixing a bug, not simply
> > that a patch is needed. For example, if a bug cannot be fixed by libc
> > maintainers on their own because various other components need to change
> > as well, or because ABI implications make a fix hard (e.g. bug 5945). And
> > so many of the SUSPENDED bugs should become NEW (and be unassigned from
> > anyone they are assigned to).
> I agree, sounds reasonable.
Thanks, I've added this to
<http://sourceware.org/glibc/wiki/bugzilla/procedures> (which already had
some information from 2009 about use in release management, before I added
things from my recent proposals).
> The main problem is that if a new test is added without updating the
> ULPs, the test code assumes 0 ULP and in most of the cases the test
> fails. That's what happened with the new jn tests for which I have sent
> patches to update ULPs for the various architectures.
I don't think that's avoidable; some things need people testing on each
architecture to update things for that architecture. I recently added a
list to <http://sourceware.org/glibc/wiki/Release> of things that should
be done on master in each release cycle (probably incomplete; it will need
to be updated based on experience, and Carlos may add more details to some
items based on doing them for 2.15). I've now added ULPs updates to that
list - but of course it's fine for people who are not the architecture
maintainer to update them, and to do so as soon as they see a new test
failing rather than waiting until shortly before a release.
> The bugs you are talking about are very old bugs, and they look more
> like "hey the math testsuite doesn't pass" than "I would like more
> precision in foobar math function". Given the math testsuite currently
> passes for most architectures, I think the bugs can simply be closed.
I did spot checks on them to make sure they were not reporting the
testsuite not to pass; in none of the cases I checked did the given test
inputs appear in the current testsuite, although the output given is in
the format in which the testsuite generates it (as if the reporter had
testsuite patches to add them, but didn't send them).
I've now checked some in more detail, as is needed for a proper triage of
each issue. Bug 2575 turned out to be invalid; the expected output was
for a double input, but the function being tested was for float and the
rounding of the input value to float changed the expected output value by
7ulps - to exactly the value log2f gives. Bug 2541 however is correct;
the input is representable in float, the expected output agrees with MPFR,
and current glibc on x86_64 does indeed still give the reported value that
is off by 64ulp.
So in my model the testcase from bug 2541 would be added to the testsuite
(with of course an expected value to sufficiently many places to be
accurate for IEEE quad long double). I'd add a refinement to my proposal
for these bugs: there should be one meta-bug for "libm functions are not
correctly / faithfully rounding", and any bug for functions off by, say,
1-999ulps (other than functions with fully specified semantics such as
scalbln or nearbyint) should have the test added to the testsuite and the
bug marked as a duplicate of that meta-bug (rather than closed in some
other way). If something like the proposed project in
<http://gcc.gnu.org/ml/gcc/2012-02/msg00298.html> comes to fruition, then
maybe in a few years it will be possible to replace many functions with
automatically generated correctly rounding versions that take advantage of
recent research in efficient and accurate implementation of special
functions - and if the set is sufficiently complete, to close the
Joseph S. Myers