This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
I noticed that the code which converts nearbyint/rint (whose result is cast to an int type) into lrint is wrong. Currently it unconditionally converts nearbyint into lrint, and only converts rint into lrint when -fno-trapping-math is set. This is backwards, what it should do is the opposite.
The result is that people using nearbyint under the expectation that it preserves the exception status are getting lrint which sets fp exceptions. Also we're needlessly pessimizing the rint case.
We have a testcase that checks that both nearbyint/rint get converted when trapping math is off, and it passes correctly. However we have nothing that checks for nearbyint staying put when trapping math is on.
This bug is present on all active branches.
Patch tested on sparc-sun-solaris2.10, no regressions.
Okay for mainline/4.2/4.1?
I think this is not correct, as lrint will get extra exceptions compared to using conversion and rint (the invalid exception in case the result doesn't fit the integer type). It looks like now we are only trying to not remove traps and do not care about introducing more, which is wrong as you noted. I fear the only valid solution is to make both transformations conditional under flag_no_trapping_math.
Thanks, Richard.
2007-03-04 Kaveh R. Ghazi <ghazi@caip.rutgers.edu>
* convert.c (convert_to_integer): Fix nearbyint/rint -> *lrint conversion.
testsuite: * gcc.dg/torture/builtin-convert-4.c: New test.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |