Re: patch with larger errors for "float"

[Carlos O'Donell <codonell at redhat dot com>]

On 1/22/20 4:43 AM, paul zimmermann wrote:
>        Dear Carlos,
> 
>>>> Just to confirm, does it pass make check without regression?
>>>
>>> well, not really. I get *before* and after my patch:
>>>
>>> Summary of test results:
>>>     141 FAIL
>>
>> This is very bad. What are these failures?
> 
> I get for example:
> 
> FAIL: debug/tst-backtrace2
> FAIL: debug/tst-backtrace3
> FAIL: debug/tst-backtrace4
> FAIL: debug/tst-backtrace5
> FAIL: debug/tst-backtrace6
> FAIL: dlfcn/bug-atexit3
> ...
> FAIL: stdlib/tst-thread-quick_exit
> 
> Is there a file where all failures are written?

Yes, every release has lists: https://sourceware.org/glibc/wiki/Release/2.30

You should not have that many failures. This looks like an environment issue.

Can you please post the full test results?

Starting with the tst-backtrace*, what do the *.out files say?

Then we can work down the list and get your results clean :-)

>> Could you please also review Joseph's comment to add the ULPs
>> to libm-test-ulps for all 10 functions?
>>
>> If you have actually found 10 functions with specific inputs
>> that have higher error bounds we should expect to see those
>> larger error bounds reflected in the libm-test-ulps file.
>>
>> As it stands it looks like either only 6 functions have larger
>> error bounds, or as Joseph says there is a difference between
>> how mpcheck and glibc compute ULPs.
> 
> as I said, I didn't use the testrun.sh wrapper, thus I was using
> glibc 2.29 instead of the development version, which should explain
> why some errors were larger. I'll use the development version in
> further runs.

Sorry if I missed that. Yes, you need to use testrun.sh to make sure
you are testing the version of the libraries you just built.

-- 
Cheers,
Carlos.