https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61876
--- Comment #7 from ktkachov at gcc dot gnu.org --- (In reply to jos...@codesourcery.com from comment #6) > On Tue, 22 Jul 2014, ktkachov at gcc dot gnu.org wrote: > > > From what I understand lround can potentially set errno on a domain error > > whereas round is valid everywhere and the cast to long int could be > > undefined > > behaviour if the double is not valid, but undefined behaviour is not the > > same > > as setting errno... > > Under Annex F the cast isn't undefined behavior but raising the "invalid" > exception and returning an unspecified value (which must be a valid value > of type long, i.e. the program must behave as if each execution of the > cast in the abstract machine has some particular value of type long it > returns). In my copy at 6.3.1.4 on Real floating and integer conversions it says: If the value of the integral part cannot be represented by the integer type, the behavior is undefined. 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?
