https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61876
--- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Fri, 25 Jul 2014, ktkachov at gcc dot gnu.org wrote: > In any case, it seems to me the transformation of cast+round -> lround is only > valid when: > - the result is within the range of the long int > - the argument is not NaN or infinity. > > In convert.c this transformation is already guarded by the type precision so > we > got the first point covered, but I think we also have to guard it by > -ffinite-math-only. > > Is that reasonable? The precision test in convert.c is about conversions to types narrower than long; it's purely about precisions of integer types and has nothing to do with the first point (which would be about exponent range). The transformation should be conditional on -fno-math-errno. If in future DTS 18661-3 support is implemented, exponent range checks would be relevant to being able to determine that a conversion from cast + roundf16 to lroundf16 is safe with -ffinite-math-only (because of the limited exponent range of _Float16), but there are many other things that would be needed for proper implementation of DTS 18661-3 (making all the relevant builtins generic across a wider range of floating-point types).
