Hi, Jeff Em seg, 29 de abr de 2019 às 18:22, Jeff Law <l...@redhat.com> escreveu: > > On 1/22/19 12:31 PM, Rafael Tsuha wrote: > > This patch simplifies the expression sinh (x) / cosh (x) to tanh (x). > > This rule is mathematically valid. > > > > There's a slight difference in the result when applying this > > optimization with x in the interval 0 < x <= 1e-4951. With the > > optimization, the result using long double is -0 and without the > > optimization, the result is +0. > That's an indication something has gone wrong. > > If I'm reading this correctly it sounds like tanh in that range is > returning -0? If so, that just seems like the wrong output from tanh > since IIUC for a positive input tanh will always have a positive output. >
I reverted the patch sent to solve bug 88556 and found out that tanhl(0) started returning -0 after this patch. patch we reverted: (https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/i386.c?r1=267325&r2=267324&pathrev=267325) In the line 44480 of this patch, it checks the sign bit of the input and if it's false the expression is multiplied by -1. In the way it's being calculated, this should be done only if the input is a number greater than zero. If we follow the code starting at line 44468, replacing op1 with 0, we can see that e2 equals 0 at line 44482, flags will be false and finally the e2 = -e2 operation will be executed generating the -0 result. I have implemented a testcase to reproduce the bug: https://paste.debian.net/1098800/ this code was compiled with -Ofast when we tested it. Should I file a bug about this? And for fixing, Is it a good solution to emit an instruction to return zero immediately if the input equals zero? > Jeff > Rafael Tsuha
