uweigand added a comment. In https://reviews.llvm.org/D53157#1303193, @andrew.w.kaylor wrote:
> I agree that it's preferable to re-use these existing options if possible. I > have some concerns that -ftrapping-math has a partial implementation in place > that doesn't seem to be well aligned with the way fast-math flags are > handled, so it might require some work to have that working as expected > without breaking existing users. In general though these seem like they > should do what we need. So as far as I can see, the current implementation of -f(no-)trapping-math in LLVM is pretty much a stub. The driver passes the option on to CC1, and in addition it disables -menable-unsafe-fp-math and -massociative-math if -fno-trapping-math is in effect (the latter may be a minor difference to GCC, but should be conservatively compatible). The compiler itself does nothing except mark all functions with the no-trapping-math attribute if -fno-trapping-math is in effect. LLVM itself completely ignores this attribute except on ARM, where it is used to set the ABI_FP_exceptions extended attribute. (But since LLVM doesn't really implement the flag in actual codegen, setting the attribute to indicate the property seems a bit odd ...) > Regarding GCC compatibility, I notice that GCC defaults to trapping math > being enabled and I don't think that's what we want with clang. It also seems > to imply something more than I think we need for constrained handling. For > example, the GCC documentation says that -fno-trapping-math "can result in > incorrect output for programs that depend on an exact implementation of IEEE > or ISO rules/specifications for math functions" so it sounds like maybe it > also implies (for GCC) something like LLVM's "afn" fast math flag. > > So if we are going to use these options, I think we need to have a discussion > about whether or not it's OK to diverge from GCC's interpretation of them. The GCC documentation says: > -fno-trapping-math > > Compile code assuming that floating-point operations cannot generate > user-visible traps. These traps include division by zero, overflow, > underflow, inexact result and invalid operation. This option requires that > -fno-signaling-nans be in effect. Setting this option may allow faster code > if one relies on ``non-stop'' IEEE arithmetic, for example. > > This option should never be turned on by any -O option since it can result in > incorrect output for programs that depend on an exact implementation of IEEE > or ISO rules/specifications for math functions. > > The default is -ftrapping-math. As far as I can tell, this does not imply any **additional** differences except that -fno-trapping-math may rearrange floating-point operations to eliminate or introduce traps or changes to exception flags. It is **those** changes themselves (not anything else) that can result in incorrect output for programs that depend on exact IEEE semantics, and therefore this option must not be enabled by default at any optimization level, as the second paragraph above states. Note that in GCC, -fno-trapping-math is implied by -funsafe-math-optimizations, which in turn is implied by -ffast-math. Those options all are documented using the same "incorrect output for programs that depend on exact IEEE semantics" clause: -funsafe-math-optimization is the catch-all for all such effects, but it is separated into -fno-signed-zeros, -fno-trapping-math, -fassociative-math, and -freciprocal-math that cover the distinct aspects of just how IEEE semantics might get violated. We can of course still have a separate discussion on what the default should be. But even if we choose a different default than GCC (as is already the case e.g. for the -ffp-contract option), I think it would be preferable for the two explicit options to behave in a compatible way. https://reviews.llvm.org/D53157 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
