search for: laxer

...manual (from GNU, not the Linux manual pages!) *implies* that fork(), as opposed to _Fork(), does not restrict the child process to AS-Safe functions. Anyway, I think your characterization is right. My approach was, "avoid calling anything that's not explicitly async-signal-safe". A laxer approach is "avoid calling anything that might interfere with particular resources". Unfortunately, this laxer approach, while it may require some "further caution" in case we want to call further functions in the affected context, quite summarily obviates this particular execv...

...stant folding and no consensus that it shouldn’t be allowed then we should probably believe that someone will eventually do it. The standard argument against trying to introduce "scope-like" mechanisms to LLVM IR is inlining; unless you're going to prevent functions that use stricter/laxer FP rules from being inlined into each other (which sounds disastrous), you're going to need to communicate strictness on an instruction-by-instruction basis. If the backend wants to handle that by using the strictest rule that it sees in use anywhere in the function because pattern-matching is...

>The standard argument against trying to introduce "scope-like" mechanisms to LLVM IR is inlining; >unless you're going to prevent functions that use stricter/laxer FP rules from being inlined >into >each other (which sounds disastrous), you're going to need to communicate strictness on an >instruction-by-instruction basis. If the backend wants to handle that by using the strictest >rule that it sees in use anywhere in the function because pat...

...dev at lists.llvm.org> wrote: On Jan 9, 2018, at 3:50 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: >The standard argument against trying to introduce "scope-like" mechanisms to LLVM IR is inlining; >unless you're going to prevent functions that use stricter/laxer FP rules from being inlined >into >each other (which sounds disastrous), you're going to need to communicate strictness on an >instruction-by-instruction basis. If the backend wants to handle that by using the strictest >rule that it sees in use anywhere in the function because pat...

...ogrammers don't realize the complexities that glibc is solving on their behalf, and how their code may not be portable to a lesser libc. > > Anyway, I think your characterization is right. My approach was, "avoid calling anything that's not explicitly async-signal-safe". A laxer approach is "avoid calling anything that might interfere with particular resources". > > Unfortunately, this laxer approach, while it may require some "further caution" in case we want to call further functions in the affected context, quite summarily obviates this partic...

On Aug 11, 2011, at19:34, John McCall wrote: > On Aug 11, 2011, at 7:31 AM, Florian Merz wrote: > > If we had nsw and nuw flags for truncations we'd know when to check for > > this kind of overflow and when not. The compiler likely doesn't need > > these flags and can still ignore them, for us they would be useful. > > Duncan's point is that this is totally

Folks: When using rsync to copy huge amounts of data I've found that a significant amount of time is spent computing the checksums. Sometimes hours, ... sometimes days - it depends on the total amount of data checked! And after that sometimes it's only a few files that need to be updated. I've pulled the latest git (rsync-3.1.1pre1) and didn't see anything to address this (or I

Andrew Kaylor wrote: >In general, the current "strict FP" handling stops at instruction >selection. At the MachineIR level we don't currently have a mechanism >to prevent inappropriate optimizations based on floating point >constraints, or indeed to convey such constraints to the backend. >Implicit register use modeling may provide some restriction on some