Re: Use of "SUSPENDED" in Bugzilla

["Joseph S. Myers" <joseph at codesourcery dot com>]

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 
meta-bug.

-- 
Joseph S. Myers
joseph@codesourcery.com