Displaying 5 results from an estimated 5 matches for "40sas".
2019 Oct 01
2
PR43374 - when should comparing NaN values raise a floating point exception?
...EXTERNAL
On Tue, Oct 1, 2019 at 5:45 AM Kristof Beyls via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hi,
>
> I’ve been investigating https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.llvm.org%2Fshow_bug.cgi%3Fid%3D43374&data=02%7C01%7CKevin.Neal%40sas.com%7C1c2441d90c5b4d3c4e6408d7467aa4cc%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C637055364875886682&sdata=7LPxf1%2BSB9lxwSjQhmEW%2FgxI997UVSo6h1XkGUrnapo%3D&reserved=0, which is about clang/llvm producing code that triggers a floating point exception when x is NaN, when targeting...
2019 Oct 01
5
PR43374 - when should comparing NaN values raise a floating point exception?
Hi,
I’ve been investigating https://bugs.llvm.org/show_bug.cgi?id=43374, which is about clang/llvm producing code that triggers a floating point exception when x is NaN, when targeting ARM, in the below code example.
int bar(float x) {
return x!=x ? 0 : 1;
}
The C99 standard states in section 7.12.14:
"""
The relational and equality operators support the usual mathematical
2020 Sep 03
3
using experimental intrinsics failed
Hi:
Sorry I need to send email directly. I am new to llvm and trying to write interval arithmetic, which requires changing rounding mode during computation.
The document I found https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics, seems to be doing the trick. Here is the piece of code that I did:
2019 Dec 18
5
RFC: Opaque pointer status and future direction
Hi all,
At the dev meeting I promised to update everyone on where my work with opaque
pointers is right now. It's taken me a while, but at least it's the same year!
Current Status
==============
I've put two branches up at https://github.com/TNorthover/llvm-project:
"opaque-ptr" which has most of the real work so far; and "opaque-ptr-always"
that additionally has
2020 Jan 07
3
Calling function from non-default floating-point environment
Hi all,
Implementation of #pragma STDC FENV_ACCESS raises a problem: what to do if
a function is called inside a region where FP environment differs from the
default? If the function expects default FP mode it may work incorrectly in
such case.
The C2x standard draft (
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf) states (7.6p4):
Certain programming conventions support the intended