search for: fsignaling

...y) all floating point operations. The presense of this flag > would trigger generation of the fcomi instruction instead of fucomi (on X86) > for example, and would inhibit optimizations that would break the semantics of > the program. There is no -fhonor-snans; I guess you mean -fsignaling-nans here. And -fsignaling-nans doesn't mean use fcomi instead of fucomi; the -ffinite-math-only option does that. I think you're asking one bit to mean too many different things here. "Don't reorder or DCE floating-point operations" is distinct from "Prefer (o...

...6.2.0/gcc/Optimize-Options.html#Optimize-Options> > > -ffp-contract=style > -ffast-math > -fno-math-errno > -funsafe-math-optimizations > -fassociative-math > -freciprocal-math > -ffinite-math-only > -fno-signed-zeros > -fno-trapping-math > -frounding-math > -fsignaling-nans > -fsingle-precision-constant > > etc, and the relevant negations of these options. We can't predict how customers will choose to chain these together, so I think the LLVM optimizer and backend designs should accommodate all possibilities derived from those clang flags. This incl...

On Jun 13, 2011, at 10:50 AM, John McCall wrote: > On Jun 13, 2011, at 10:30 AM, Jakob Stoklund Olesen wrote: >> The try block would look something like: >> >> call _malloc >> movq %rax, p(%rpb) >> >> If you take an exception between those two instructions, you are leaking memory. > > This is primarily an argument that C is not a good language to

....2.0/gcc/Optimize-Options.html# > Optimize-Options > > -ffp-contract=style > -ffast-math > -fno-math-errno > -funsafe-math-optimizations > -fassociative-math > -freciprocal-math > -ffinite-math-only > -fno-signed-zeros > -fno-trapping-math > -frounding-math > -fsignaling-nans > -fsingle-precision-constant > > etc, and the relevant negations of these options. We can't predict how > customers will choose to chain these together, so I think the LLVM > optimizer and backend designs should accommodate all possibilities derived > from those clang fl...

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

Hi Jack, On 29/05/13 22:04, Jack Howarth wrote: > On Wed, May 29, 2013 at 03:25:30PM +0200, Duncan Sands wrote: >> Hi Jack, I pulled the loop vectorizer and fast math changes into the 3.3 branch, >> so hopefully they will be part of 3.3 rc3 (and 3.3 final!). It would be great >> if you could redo the benchmarks rc3. >> > > Duncan, > As requested, appended