search for: port70

* Sanjay Patel <spatel at rotateright.com> [2019-10-08 08:07:10 -0400]: > On Tue, Oct 8, 2019 at 7:08 AM Szabolcs Nagy <nsz at port70.net> wrote: > > why is that ok? > > > > Because there are no FP exceptions/signals for this IR opcode: > http://llvm.org/docs/LangRef.html#floating-point-environment so llvm cannot support an iso c frontend on an ieee754 target? (or fortran for that matter)

...= pA; { int *restrict y = x + N; *x = *y; } } Both Jeroen's and Hal's implementation (the intrinsic-based one) will say "NoAlias" for the accesses in assign2() but shouldn't x and y be in the same restrictness "bucket" since y is based on x? [1] http://port70.net/~nsz/c/c11/n1570.html#6.7.3.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200214/f91a6da6/attachment.html>

...; *x = *y; > } > } > > Both Jeroen's and Hal's implementation (the intrinsic-based one) will say > "NoAlias" for the accesses in assign2() but shouldn't x and y be in the > same restrictness "bucket" since y is based on x? > > [1] http://port70.net/~nsz/c/c11/n1570.html#6.7.3.1 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__port70.net_-7Ensz_c_c11_n1570.html-236.7.3.1&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=ELyOnT0WepII6UnFk-OSzxlGOXXSfAvOLT6E8iPwwJk&m=xMDqkSAlj-YCOS4JMDXAENpBS-eaCcLYSkIm1qK68fs&s=B3LRzqpd9bD...

...al pointer. When the realloc is done in-place the reference <http://en.cppreference.com/w/c/memory/realloc> says: "The original pointer ptr is invalidated and any access to it is undefined behavior (even if reallocation was in-place)." Additionally from the C11 standard <https://port70.net/~nsz/c/c11/n1570.html#6.2.4p2> we have: "The value of a pointer becomes indeterminate when the object it points to (or just past) reaches the end of its lifetime" Is this enough to infer that we can safely mark realloc as noalias? -- Regards Bhatu -------------- next part ------...

...only one void side. So the (needslow ? slowpath() : fastpath) code for outc in the !USE_GLIBC_STDIO case might not be portable. More importantly, it's hard to read. Rip it out and replace it with an inline function which should generate the same code. Reported-by: Szabolcs Nagy <nsz at port70.net> Signed-off-by: Jonathan Nieder <jrnieder at gmail.com> Signed-off-by: Herbert Xu <herbert at gondor.apana.org.au> Signed-off-by: maximilian attems <max at stro.at> --- usr/dash/output.h | 15 +++++++++++++-- 1 files changed, 13 insertions(+), 2 deletions(-) diff --git...

...ault on some platforms, e.g. BSD-derived OSes. bool MathErrno = TC.IsMathErrnoDefault(); Here's another comment, // Turning *off* -ffast-math restores the toolchain default. MathErrno = TC.IsMathErrnoDefault(); > -----Original Message----- > From: Szabolcs Nagy <nsz at port70.net> > Sent: Tuesday, January 28, 2020 8:09 AM > To: Kaylor, Andrew <andrew.kaylor at intel.com> > Cc: cfe-dev at lists.llvm.org; LLVM Developers Mailing List <llvm- > dev at lists.llvm.org>; Ristow, Warren <warren.ristow at sony.com>; Ulrich > Weigand (Ulrich.We...

.... In clang we're mapping this to an intrinsic that gets a target-specific inline expansion. For example: https://godbolt.org/z/uQD-AF And FLT_EVAL_METHOD I take to be an indicator of how the compiler is handling intermediate results. -----Original Message----- From: Szabolcs Nagy <nsz at port70.net> Sent: Tuesday, January 28, 2020 5:09 AM To: Kaylor, Andrew <andrew.kaylor at intel.com> Cc: cfe-dev at lists.llvm.org; LLVM Developers Mailing List <llvm-dev at lists.llvm.org>; Ristow, Warren <warren.ristow at sony.com>; Ulrich Weigand (Ulrich.Weigand at de.ibm.com) <...

* Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> [2019-10-01 09:44:54 -0400]: > Let's change the example to eliminate suspects: > #include <math.h> > int is_nan(float x) { > /* > The following subclauses provide macros that are quiet (non > floating-point exception raising) > versions of the relational operators, and other comparison

AKA: MinGW + win32threads is holding LLVM (and all of its subprojects) back. We need to stop supporting this host platform. I'm aware of essentially 2 reasonably important use cases for supporting MinGW + win32threads: 1) Sane host toolchain on Windows that doesn't require downloading MSVC. (I'm dubious about the value of this one...) 2) Cross-compiling a Windows clang.exe (and

Hi all, I'm trying to put together a set of rules for how the various floating point semantic modes should be handled in clang. A lot of this information will be relevant to other front ends, but the details are necessarily bound to a front end implementation so I'm framing the discussion here in terms of clang. Other front ends can choose to follow clang or not. The existence of this set

> > note: these bits are not really reserved for os or processor > specific use in ELF. in practice they are processor specific > so it will be STO_AARCH64_TAGGED. > Correct. note2: undefined symbol references will need correct marking > too if objects may get copy relocated into the main exe and > linkers should check if definitions match references. Yep - at this point I