| Oh right, sorry, off-by-one error when evaluating that by hand; I got 0x7fffffff (which is also a NaN, 0x7fc00000 is not the only NaN). No worries.
| http://llvm.org/docs/LangRef.html#uitofp-to-instruction is clear that you get an undefined result for overflow currently. Other parts of the LangRef are comfortable talking about infinities, e.g. there's a way to write them as constants, and IEEE float is pervasive in this era, so it would seem consistent for uitofp to return +infinity for the overflow case. I'm not the one to propose it, though. ☺ --paulr From: meta...@gmail.com [mailto:meta...@gmail.com] On Behalf Of Richard Smith Sent: Wednesday, December 09, 2015 12:43 PM To: Robinson, Paul Cc: Joerg Sonnenberger; cfe-commits (cfe-commits@lists.llvm.org) Subject: Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled On Wed, Dec 9, 2015 at 10:17 AM, Robinson, Paul via cfe-commits <cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>> wrote: | And at runtime, on some targets, we use this: | | https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/builtins/floatuntisf.c | | ... which gives a NaN in this case. I copied that function into a test program on Ubuntu, built with gcc, and it gives me +Infinity (0x7f800000) not NaN (0x7fc00000). Oh right, sorry, off-by-one error when evaluating that by hand; I got 0x7fffffff (which is also a NaN, 0x7fc00000 is not the only NaN). So, I think the question is, do we want to update LLVM to define the value of an out-of-range uitofp (and "fix" any targets that don't give +/- Inf for these conversions)? http://llvm.org/docs/LangRef.html#uitofp-to-instruction is clear that you get an undefined result for overflow currently. In (AFAICS) all supported targets, for integer types supported by clang, there are only two ways to hit the overflow case: 1) uint128 -> float 2) uint64 or larger -> half Case (1) goes through uitofp (which explicitly says the result is undefined at the moment), case (2) goes via @llvm.convert.to.fp16 (which says nothing about what happens in this case, but presumably it is defined). These are both phenomenally rare conversions, so adding (potential) extra cost to them to make them handle the out-of-range case correctly doesn't seem unreasonable. --paulr From: meta...@gmail.com<mailto:meta...@gmail.com> [mailto:meta...@gmail.com<mailto:meta...@gmail.com>] On Behalf Of Richard Smith Sent: Tuesday, December 08, 2015 11:42 AM To: Robinson, Paul Cc: Joerg Sonnenberger; cfe-commits (cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>) Subject: Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled On Tue, Dec 8, 2015 at 11:18 AM, Richard Smith <rich...@metafoo.co.uk<mailto:rich...@metafoo.co.uk>> wrote: On Tue, Dec 8, 2015 at 10:59 AM, Robinson, Paul <paul_robin...@playstation.sony.com<mailto:paul_robin...@playstation.sony.com>> wrote: Okay, I'll bite: so what *does* UINT128_MAX actually convert to? $ echo 'unsigned __int128 max = -1; float f = max;' | ~/clang-8/build/bin/clang -x c++ - -emit-llvm -S -o - -O3 | grep @f @f = global float undef, align 4 And at runtime, on some targets, we use this: https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/builtins/floatuntisf.c ... which gives a NaN in this case. From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org<mailto:cfe-commits-boun...@lists.llvm.org>] On Behalf Of Richard Smith via cfe-commits Sent: Tuesday, December 08, 2015 10:52 AM To: Joerg Sonnenberger; cfe-commits Subject: Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled On Tue, Dec 8, 2015 at 2:13 AM, Joerg Sonnenberger via cfe-commits <cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>> wrote: On Mon, Dec 07, 2015 at 01:32:14PM -0800, Richard Smith via cfe-commits wrote: > C11 6.3.1.5/1<http://6.3.1.5/1>: "If the value being converted is outside the > range of values > that can be represented, the behavior is undefined." The value of 1e100 can be represented as +inf, even if not precisely. Only if +inf is in the range of representable values, which, as already noted, is problematic. This is a bit different from non-IEEE math like VAX, that doesn't have infinities. Joerg _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
