r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[Richard Smith via cfe-commits]

On Wed, Dec 9, 2015 at 10:17 AM, Robinson, Paul via cfe-commits <
cfe-commits at 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:* metafoo at gmail.com [mailto:metafoo at 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 at 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 <richard at metafoo.co.uk>
> wrote:
>
> On Tue, Dec 8, 2015 at 10:59 AM, Robinson, Paul <
> Paul_Robinson at 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-bounces at 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 at 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: "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 at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
>
>
>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20151209/8a06cfe6/attachment.html>