Home
last modified time | relevance | path

Searched refs:semantics (Results 1 – 25 of 180) sorted by relevance

12345678

/external/llvm/lib/Support/
DAPFloat.cpp579 semantics = ourSemantics; in initialize()
595 assert(semantics == rhs.semantics); in assign()
633 unsigned bitsToPreserve = semantics->precision - 1; in makeNaN()
641 unsigned QNaNBit = semantics->precision - 2; in makeNaN()
660 if (semantics == &APFloat::x87DoubleExtended) in makeNaN()
675 if (semantics != rhs.semantics) { in operator =()
677 initialize(rhs.semantics); in operator =()
689 semantics = rhs.semantics; in operator =()
695 rhs.semantics = &Bogus; in operator =()
701 return isFiniteNonZero() && (exponent == semantics->minExponent) && in isDenormal()
[all …]
/external/clang/lib/StaticAnalyzer/Checkers/
DPthreadLockChecker.cpp67 bool isTryLock, enum LockingSemantics semantics) const;
126 enum LockingSemantics semantics) const { in AcquireLock()
164 switch (semantics) { in AcquireLock()
177 } else if (semantics == PthreadSemantics) { in AcquireLock()
184 assert((semantics == XNUSemantics) && "Unknown locking semantics"); in AcquireLock()
/external/clang/docs/
DAutomaticReferenceCounting.rst16 * This is wrong from the semantics point of view, since it is an ordered
81 runtime which implements these new semantics.
247 ARC's semantics and restrictions.
273 varied transfer semantics.
288 Retain count semantics
309 :arc-term:`high-level semantics` is an intentionally vague term; the intent is
322 semantics to a computation history in which these sends are removed. Note that
333 When the semantics call for performing one of these operations on a retainable
336 All of the semantics described in this document are subject to additional
339 semantics describe the high-level behaviors that the compiler implements, not
[all …]
/external/llvm/docs/HistoricalNotes/
D2001-02-13-Reference-Memory.txt21 an object, etc...) and more closely matches Java semantics. The
22 pointer type would be kept for C++ like semantics. Through analysis,
D2001-02-13-Reference-MemoryResponse.txt12 > an object, etc...) and more closely matches Java semantics. The
13 > pointer type would be kept for C++ like semantics. Through analysis,
/external/llvm/test/YAMLParser/
Dspec-02-23.data13 The semantics of the tag
/external/llvm/docs/
DAtomics.rst13 rough semantics in the presence of concurrency. However, this is changing;
25 * Proper semantics for Java-style memory, for both ``volatile`` and regular
32 * Other scenarios with atomic semantics, including ``static`` variables with
45 with instructions with special semantics in the presence of concurrency. This
46 is not intended to be a precise guide to the semantics; the details can get
274 semantics. The precise fences required varies widely by architecture, but for
278 maintain Acquire semantics for a memory operation.
303 implement Release semantics; store-store fences are generally not exposed to
325 This operation has Acquire and Release semantics; see the sections on Acquire
331 SequentiallyConsistent (``seq_cst`` in IR) provides Acquire semantics for loads
[all …]
/external/libvpx/libvpx/
Dusage.dox91 The semantics of how each error condition should be processed is clearly
114 returning. This is a soft deadline -- that is, the semantics of the
118 after 2000us. In this case the deadline is not met, but the semantics of the
124 and the semantics of the call are preserved, as before.
/external/chromium-trace/trace-viewer/tracing/third_party/tvcm/third_party/rcssmin/
DREADME.chromium11 The minifier is based on the semantics of the YUI compressor, which itself is
/external/valgrind/docs/internals/
Davx-notes.txt23 work I think because the host happens to have the same semantics.
/external/chromium-trace/trace-viewer/tracing/third_party/tvcm/third_party/rjsmin/
DREADME.chromium10 The minifier is based on the semantics of jsmin.c by Douglas Crockford.
/external/llvm/test/Transforms/SimplifyCFG/
Dlifetime.ll3 ; Test that a lifetime intrinsic isn't removed because that would change semantics
/external/pcre/dist/m4/
Dpcre_visibility.m414 dnl semantics (see the 'vismain' test in glibc) and does not exist e.g. on
17 dnl dependent semantics.
/external/bison/m4/
Dassert.m410 dnl it has broken semantics for --enable-assert until 2.64.
D00gnulib.m49 dnl assume Autoconf 2.64, with its improved AC_DEFUN_ONCE semantics.
/external/clang/test/Rewriter/
Dfinally.m7 …return(0); // expected-warning{{rewriter doesn't support user-specified control flow semantics for…
/external/llvm/test/CodeGen/AArch64/
Dgot-abuse.ll4 ; LLVM gives well-defined semantics to this horrible construct (though C says
/external/llvm/test/Other/
Dcan-execute.txt13 If we want, it is probably OK to change the semantics of can_execute and this
/external/valgrind/VEX/
DTODO.txt49 write API doc, clarify IR semantics
/external/llvm/test/Transforms/InstCombine/
D2004-01-13-InstCombineInvokePHI.ll4 ; used by the PHI instruction. This is bad: because of the semantics of the
/external/llvm/docs/TableGen/
DDeficiencies.rst21 There are some in favour of extending the semantics even more, but making sure
/external/valgrind/
Ddarwin10.supp40 # unavoidable due to BSD setenv() semantics.
/external/mesa3d/src/glsl/glcpp/
DREADME9 This specification is not precise on some semantics, (for example,
/external/llvm/include/llvm/ADT/
DAPFloat.h431 const fltSemantics &getSemantics() const { return *semantics; } in getSemantics()
616 const fltSemantics *semantics; variable
/external/llvm/test/CodeGen/PowerPC/
Dfast-isel-load-store-vsx.ll3 ;; The semantics of VSX stores for when R0 is used is different depending on

12345678