[llvm-dev] fptosi undefined behaviour

[Simon Byrne via llvm-dev]

Well, you would need switch the check the other way round, to avoid
problems with NaNs. But this is probably what we will do (and indeed,
appears to be what Swift does without -Ounchecked).

On 28 January 2016 at 12:46, mats petersson <mats at planetcatfish.com> wrote:
> 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
>
>