The rint intrinsic makes this statement about FP exceptions:
It may raise an inexact floating-point exception if the operand isn’t an integer.
nearbyint differs from rint by not having that statement.
However, this is misleading, since LLVM also documents "the default LLVM floating-point environment assumes that traps are disabled and status flags are not observable". This means that whether or not rint raises an exception is assumed to be un-observable, and LLVM will freely reorder rint with other operations that might alter FP exception flags. Effectively, rint and nearbyint provide equivalent semantics (as least that's how LLVM frontends should treat the situation), and anyone relying on rint doing anything with exceptions will be disappointed eventually.
It would probably be better to remove any mention of exceptions in the rint and nearbyint docs, and possibly to merge those intrinsics. People relying on exception behavior need to use the constrained intrinsics.
The rint intrinsic makes this statement about FP exceptions:
nearbyint differs from rint by not having that statement.
However, this is misleading, since LLVM also documents "the default LLVM floating-point environment assumes that traps are disabled and status flags are not observable". This means that whether or not rint raises an exception is assumed to be un-observable, and LLVM will freely reorder rint with other operations that might alter FP exception flags. Effectively, rint and nearbyint provide equivalent semantics (as least that's how LLVM frontends should treat the situation), and anyone relying on rint doing anything with exceptions will be disappointed eventually.
It would probably be better to remove any mention of exceptions in the rint and nearbyint docs, and possibly to merge those intrinsics. People relying on exception behavior need to use the constrained intrinsics.