Joseph Myers wrote: > Another question to consider: what about configurations (mostly > soft-float) where floating-point exceptions are not supported? (glibc > wrongly defines math_errhandling to include MATH_ERREXCEPT there, but the > only option actually permitted by C99 in that case would be to define it > to MATH_ERRNO.) > > If we wish to distinguish that case, the > targetm.float_exceptions_rounding_supported_p hook is the one to use (in > the absence of anyone identifying a target that supports exceptions but > not rounding modes) - possibly together with flag_iso.
I looked into this and the issue is that calling targetm functions is not possible until the backend is fully initialized (whether the pattern exists or not is not sufficient, the pattern condition must be valid to evaluate as well), and that happens after option parsing. In general soft-float is used on tiny targets which don't use errno at all (as in remove all the code dealing with it, including the errno variable itself!), so I believe it's best to let people explicitly enable -fmath-errno in the rare case when they really want to. >> lroundf in GLIBC doesn't set errno, so all the inefficiency was for nothing: > > (glibc bug 6797.) I see, that explains it! A decade old bug - it shows the popularity of errno... Wilco
