>>! In D3806#14, @rsmith wrote: >>>! In D3806#12, @hfinkel wrote: >> The problem, as pointed out in the bug report, is that libstdc++ implements >> std::X in terms of __builtin_X > > This is only non-conforming because `math_errhandling` is defined to a value > that includes `MATH_ERRNO`.
Correct. > Another possible approach would be to subvert that macro instead of providing > an `errno` guarantee in our builtins. Is there some reason we want to provide > a guarantee that we set `errno` on domain error if the underlying libc does? Interesting idea. Are the calls allowed to set `errno` if `math_errhandling` does not include `MATH_ERRNO`? And do we introduce a usability problem by having the behavior differ from the C functions? Part of the problem here is that we don't really track `errno`, and if we think the calls don't set `errno`, we mark them as const. In doing so, they can be reordered with calls that do set `errno` (like open()), and can corrupt the `errno` value coming from those calls. That having been said, we have this problem in fast-math mode too. http://reviews.llvm.org/D3806 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
