search for: math

Hi all, In a mailing-list post last November: http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html I raised some concerns that having the IR-level fast-math-flag 'fast' act as an "umbrella" to implicitly turn on all the lower-level fast-math-flags, causes some fundamental problems. Those fundamental problems are related to situations where a user wants to disable a portion of the fast-math behavior. For example, to enable all the fas...

Hi, Warren, Thanks for writing all of this up. In short, regarding your suggested solution: > 4. To fix this, I think that additional fast-math-flags are likely > needed in > > the IR. Instead of the following set: > > 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' > > something like this: > > 'reassoc' + 'libm' + 'nnan' + 'ninf' + 'nsz&...

...t;path> then run cmake: cmake -GNinja -DLIBCXXABI_USE_LLVM_UNWINDER=ON DLLVM_TARGET_ARCH=ARM -DLLVM_DEFAULT_TARGET_TRIPLE=arm-linux-gnueabihf -DLLVM_TARGETS_TO_BUILD=ARM -DCMAKE_CROSSCOMPILING=True .. This errors out as shown below. It's like it's missing some definitions of different math functions that I can't seem to be able to see anywhere else. Is this a known problem? Or is it something with my compiler / toolchain setup that creates this problem? Thanks for any assistance. -- Tobias armv7a-plex-linux-gnueabihf-g++ -DLLVM_BUILD_GLOBAL_ISEL -DNDEBUG -D_DEBUG -D_FILE_OFFS...

At first glance, it looks like long double functions (such as fabsl and friends) are missing from your sysroot's <math.h>. Does your target support long double at all? -Dimitry > On 6 Feb 2018, at 09:51, Tobias Hieta via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > I am trying to cross-compile libc++ from my x86_64 linux system to armv7hf. We have our own gcc compiler tha...

...r toolchain. long double support is required in libc++ then I gather? -- Tobias On Tue, Feb 6, 2018 at 11:47 AM, Dimitry Andric <dimitry at andric.com> wrote: > At first glance, it looks like long double functions (such as fabsl and > friends) are missing from your sysroot's <math.h>. Does your target > support long double at all? > > -Dimitry > > > On 6 Feb 2018, at 09:51, Tobias Hieta via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hello, > > > > I am trying to cross-compile libc++ from my x86_64 linux syst...

...et the values to display along the right edge of the horizontal graph whereas my goal is to have them displayed just off the ends of each horizontal bar, as they are on the veritical graph. I was hoping someone could provide me with direction or a solution to this problem. #Vertical bars syntax: math.bar <- c(53,31,55,28,55,100) names(math.bar) <- c('Grade \n 3','Grade \n 4','Grade \n 5','Grade \n 6','Grade \n 7','Grade \n 8') o <- rev(order(math.bar)) math.bar <- math.bar[o] par(ps=10) math.barplot <- barplot(math.bar, main = list(...

libswfdec/swfdec_as_math.c | 16 ++++++++-------- libswfdec/swfdec_as_object.c | 3 ++- libswfdec/swfdec_movie.c | 12 +++++------- libswfdec/swfdec_sprite_movie.c | 3 ++- test/trace/Makefile.am | 7 +++++++ test/trace/math-constants-5.swf |binary t...

...t;path> then run cmake: cmake -GNinja -DLIBCXXABI_USE_LLVM_UNWINDER=ON DLLVM_TARGET_ARCH=ARM -DLLVM_DEFAULT_TARGET_TRIPLE=arm-linux-gnueabihf -DLLVM_TARGETS_TO_BUILD=ARM -DCMAKE_CROSSCOMPILING=True .. This errors out as shown below. It's like it's missing some definitions of different math functions that I can't seem to be able to see anywhere else. Is this a known problem? Or is it something with my compiler / toolchain setup that creates this problem? Thanks for any assistance. -- Tobias armv7a-plex-linux-gnueabihf-g++ -DLLVM_BUILD_GLOBAL_ISEL -DNDEBUG -D_DEBUG -D_FILE_OFFS...

Processing commands for control at bugs.debian.org: > # bugs from schepler at math.unipd.it > submitter 390095 ! Bug#390095: klash: No control keys working Changed Bug submitter from Daniel Schepler <schepler at math.unipd.it> to Daniel Schepler <dschepler at gmail.com>. > submitter 419472 ! Bug#419472: aegis: FTBFS under pbuilder even building as non-root Chan...

Hi all, This is about https://reviews.llvm.org/D26708 Currently when the command-line switch '-ffast-math' is specified, the IR-level fast-math-flag 'fast' gets attached to appropriate FP math instructions. That flag acts as an "umbrella" to implicitly turn on all the other fast-math-flags ('nnan', 'ninf', 'nsz' and 'arcp'): http://llvm.org/docs/L...

On 17.11.2016 09:51, Ristow, Warren wrote: > Those are all good points. Your reassociation point in the context of > inlining is particularly interesting. > > > > FWIW, we also have a case where a customer wants '-fno-associative-math' > to suppress reassociation under '-ffastmath'. It would take me a while > to find the specifics of the issue, but it was (if my memory is right) > more of a real use-case. (That is to say, the code that was "failing" > due to reassociation didn't have an ob...

...4-unknown-linux-gnu" ; Function Attrs: norecurse nounwind readnone uwtable define dso_local float @foo(float %a, float %b) local_unnamed_addr #0 { entry: %add = fadd float %a, %b ret float %add } attributes #0 = { norecurse nounwind readnone uwtable "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "frame-pointer"="none" "less-precise-fpmad"="false" "min-legal-vector-width"="0" "no-infs-fp-math"="false" "no-jump-tables"="false&...

...t;llvm-dev at lists.llvm.org> > To: "Warren Ristow" <warren.ristow at sony.com> > Cc: llvm-dev at lists.llvm.org > Sent: Tuesday, November 15, 2016 11:10:48 PM > Subject: Re: [llvm-dev] RFC: Consider changing the semantics of > 'fast' flag implying all fast-math-flags > Hi, > > On Nov 15, 2016, at 5:15 PM, Ristow, Warren via llvm-dev < > > llvm-dev at lists.llvm.org > wrote: > > > Hi all, > > > This is about https://reviews.llvm.org/D26708 > > > Currently when the command-line switch '-ffast-math&...

New patches with review feedback incorporated: * Changed single letter flags to short abbreviations ('S' ==> 'nsz') * Indentation fixes * Comments don't state function names -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fast-math-flags-added-to-FPMathOperator.patch Type: application/octet-stream Size: 4937 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121115/2e3c515f/attachment.obj> -------------- next part -------------- -------------- next part -------------- A non-text atta...

...m-dev at lists.llvm.org>> wrote: > On 17.11.2016 09:51, Ristow, Warren wrote: > Those are all good points. Your reassociation point in the context of > inlining is particularly interesting. > > > > FWIW, we also have a case where a customer wants '-fno-associative-math' > to suppress reassociation under '-ffastmath'. It would take me a while > to find the specifics of the issue, but it was (if my memory is right) > more of a real use-case. (That is to say, the code that was "failing" > due to reassociation didn't have an ob...

Hi Mehdi, The ISO C specification does permit the math functions to modify ‘errno’, but I thought that the ‘-fno-math-errno’ option was to tell the optimiser to assume that ‘errno’ is not modified by the math functions. Explicitly providing ‘-fno-math-errno’ is not restoring the elision optimisation that was performed by LLVM v3.8, and this is really...

...Michael Ilseman <milseman at apple.com> wrote: > New patches with review feedback incorporated: > * Changed single letter flags to short abbreviations ('S' ==> 'nsz') > * Indentation fixes > * Comments don't state function names > > <0002-Fast-math-flags-added-to-FPMathOperator.patch> > <0003-Fast-math-interfaces-for-Instructions.patch> > <0004-Fast-math-flags-for-LLVM-IR-parsing-and-printing.patch> > <0005-Fast-math-flags-for-the-bitcode.patch> > <0006-Fast-math-test-case-for-bitcode-and-textual-reading-.p...

Hi, I came across an issue where some optimizations that would normally be applied to standard math function calls are not getting applied when the –ffast-math option is enabled on the Clang command line on a Linux x86_64 target. I tracked down the issue to occurring because the –ffast-math option is triggering Clang to preprocess the math.h header file with the __FINITE_MATH_ONLY__ macro set t...

A little while ago I asked a question on CFE-Dev about a change in the behaviour of programs using the ISO C math functions, although that question should have been put to LLVM-Dev. But I got excellent clarification of the problem anyway. However, since then I have been trying to adapt our out-of-tree implementation to get the previous behaviour. The problem is that something like: #include <math.h&g...

...016 09:51, Ristow, Warren wrote: >> >>> Those are all good points. Your reassociation point in the context of >>> inlining is particularly interesting. >>> >>> >>> >>> FWIW, we also have a case where a customer wants '-fno-associative-math' >>> to suppress reassociation under '-ffastmath'. It would take me a while >>> to find the specifics of the issue, but it was (if my memory is right) >>> more of a real use-case. (That is to say, the code that was "failing" >>> due to rea...