[Bug math/18875] Excess precision leads incorrect libm

["joseph at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=18875

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
That would be the issue Carlos has twice reported.

https://sourceware.org/ml/libc-alpha/2015-01/msg00484.html
https://sourceware.org/ml/libc-alpha/2015-01/msg00485.html
https://sourceware.org/ml/libc-alpha/2015-07/msg00212.html

Fixing it shouldn't be hard - just store to and load back from the stack 
(remembering CFI adjustments) before return, at least when the result is 
below FLT_MIN (DBL_MIN for the double functions - the issue could 
presumably appear for those as well depending on the compiler version).  
I've just never seen this issue with the compilers I've been testing with, 
so am not in a good position to prepare and test a fix.

E.g. atan2 already does this, together with (in the case of small results) 
storing to the stack the result of multiplying the small result by itself 
to avoid missing underflow exceptions if the extended precision result 
rounds exactly to float / double but in fact isn't exact.  The same issue 
of avoiding such missing underflows also applies to these functions, so 
you could always copy all the code from atan2f / atan2 that compares with 
FLT_MIN / DBL_MIN and handles these issues if so (minus the fabs 
instructions since the functions in question here never have negative 
results).

-- 
You are receiving this mail because:
You are on the CC list for the bug.