Resending to "everyone":
What's wrong with checking
short foo(double d)
{
if (trunc(d) > MAX_SHORT || trunc(d) < MIN_SHORT) return 0; else
return
short(d);
}
If you don't care about the one in difference, you could do `abs(trunc(d))
< MAX_SHORT;` to avoid the check against min.
That's what you want, right?
--
Mats
On 28 January 2016 at 11:17, Simon Byrne via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Thank Tom and Tim for your responses.
>
> If the behaviour is truly undefined as Tom says, would it be possible
> to get checked intrinsics for this?
>
> -Simon
>
> On 22 January 2016 at 20:24, Tim Northover <t.p.northover at
gmail.com>
> wrote:
> > On 22 January 2016 at 12:20, Tom Stellard via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> >>> 1) I realise this is a somewhat silly question, but is this
still
> >>> acceptable "undefined behaviour"?
> >>
> >> Yes, it is.
> >
> > I always thought these out-of-range instructions did produce an
> > "undef" rather than allowing fully-general undefined
behaviour
> > (otherwise we couldn't speculate them, for a start).
> >
> > If so, I think the code ought to be valid: %1 is *some* i16
> > bitpattern, which means %2 cannot be completely unconstrained and
> > should never be equal to %0.
> >
> > Cheers.
> >
> > Tim.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160128/10cbcd47/attachment.html>