The Language Reference states that fptrunc (1) has an undefined result "if the value cannot fit within the destination type" and (2) has "undefined" rounding mode. This is quite worrying for frontends that want to avoid UB or even just reliably provide ties-to-even truncation. Furthermore, there does not seem to be any reason for fptrunc to be so undefined. By the assumption about the default floating point environment (also in the Language Reference): 1. the rounding mode is ties-to-even everywhere, this should apply to fptrunc as well 2. no floating-point exception state is maintained, i.e., the overflow exception signaled if the value does not fit in the destination type can't be inspected and is handled in the default way, which gives an infinite result as one would expect As far as I can tell, fixing this just requires a clarification in the Language Reference. APFloat already does the right thing, and none of the in-tree passes seem to make any attempt to exploit this nominal source of undefs.
This sounds right to me. Current constant folding behavior does not follow the existing LangRef example that would supposedly return undef on oveflow: http://llvm.org/docs/LangRef.html#fptrunc-to-instruction ...we return infinity there.
https://reviews.llvm.org/rL329065