| /external/llvm/lib/Support/ |
| D | APFloat.cpp | 120 assertArithmeticOK(const llvm::fltSemantics &semantics) { in assertArithmeticOK() argument
121 assert(semantics.arithmeticOK && in assertArithmeticOK()
594 semantics = ourSemantics; in initialize()
610 assert(semantics == rhs.semantics); in assign()
650 unsigned bitsToPreserve = semantics->precision - 1; in makeNaN()
658 unsigned QNaNBit = semantics->precision - 2; in makeNaN()
677 if (semantics == &APFloat::x87DoubleExtended) in makeNaN()
692 if (semantics != rhs.semantics) { in operator =()
694 initialize(rhs.semantics); in operator =()
706 if (semantics != rhs.semantics || in bitwiseIsEqual()
[all …]
|
| /external/clang/lib/StaticAnalyzer/Checkers/ |
| D | PthreadLockChecker.cpp | 39 bool isTryLock, enum LockingSemantics semantics) const;
97 enum LockingSemantics semantics) const { in AcquireLock()
129 switch (semantics) { in AcquireLock()
142 } else if (semantics == PthreadSemantics) { in AcquireLock()
149 assert((semantics == XNUSemantics) && "Unknown locking semantics"); in AcquireLock()
|
| /external/llvm/docs/HistoricalNotes/ |
| D | 2001-02-13-Reference-Memory.txt | 21 an object, etc...) and more closely matches Java semantics. The
22 pointer type would be kept for C++ like semantics. Through analysis,
|
| D | 2001-02-13-Reference-MemoryResponse.txt | 12 > an object, etc...) and more closely matches Java semantics. The
13 > pointer type would be kept for C++ like semantics. Through analysis,
|
| D | 2001-02-09-AdveComments.txt | 21 semantics). It should simplify building the CFG and my guess is it could
107 What is the semantics of the IA64 stop bit?
|
| D | 2001-07-06-LoweringIRForCodeGen.txt | 16 processor but have VM semantics otherwise, i.e., all operands are in SSA
|
| /external/llvm/test/YAMLParser/ |
| D | spec-02-23.data | 13 The semantics of the tag
|
| /external/v8/test/sputnik/ |
| D | sputnik.status | 150 # These tests check for ES3 semantics, and differ from ES5.
151 # When we follow ES5 semantics, it's ok to fail the test.
208 # Invalid test case (recent change adding var changes semantics)
212 # Invalid test case (recent change adding var changes semantics)
214 # Invalid test case (recent change adding var changes semantics)
|
| /external/llvm/docs/ |
| D | Atomics.rst | 15 rough semantics in the presence of concurrency. However, this is changing;
27 * Proper semantics for Java-style memory, for both ``volatile`` and regular
34 * Other scenarios with atomic semantics, including ``static`` variables with
47 with instructions with special semantics in the presence of concurrency. This
48 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/llvm/include/llvm/ADT/ |
| D | APFloat.h | 321 const fltSemantics &getSemantics() const { return *semantics; } in getSemantics()
438 const fltSemantics *semantics; variable
|
| /external/clang/test/Rewriter/ |
| D | finally.m | 7 …return(0); // expected-warning{{rewriter doesn't support user-specified control flow semantics for…
|
| /external/bison/m4/ |
| D | extensions.m4 | 9 # have a macro AC_USE_SYSTEM_EXTENSIONS with identical semantics.
|
| /external/valgrind/main/ |
| D | darwin10.supp | 40 # unavoidable due to BSD setenv() semantics.
|
| D | darwin11.supp | 106 # unavoidable due to BSD setenv() semantics.
|
| /external/valgrind/main/VEX/ |
| D | TODO.txt | 49 write API doc, clarify IR semantics
|
| /external/llvm/test/Transforms/InstCombine/ |
| D | 2004-01-13-InstCombineInvokePHI.ll | 4 ; used by the PHI instruction. This is bad: because of the semantics of the
|
| /external/mesa3d/src/glsl/glcpp/ |
| D | README | 9 This specification is not precise on some semantics, (for example,
|
| /external/libusb-compat/ |
| D | configure.ac | 52 # Restore gnu89 inline semantics on gcc 4.3 and newer
|
| /external/libvpx/ |
| D | usage.dox | 91 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/stlport/stlport/ |
| D | bitset | 36 // The C++ standard does not define the precise semantics of operator[].
|
| /external/iproute2/doc/actions/ |
| D | gact-usage | 11 ACTION semantics
|
| /external/clang/include/clang/Driver/ |
| D | CC1AsOptions.td | 38 "Note this may change .s semantics, it should almost never be used "
|
| /external/clang/test/SemaObjCXX/ |
| D | arc-0x.mm | 3 // "Move" semantics, trivial version.
|
| /external/clang/lib/AST/ |
| D | Expr.cpp | 3707 ArrayRef<Expr*> semantics, in Create() argument
3710 assert(semantics.size() && "no semantic expressions!"); in Create()
3718 assert(resultIndex < semantics.size()); in Create()
3719 type = semantics[resultIndex]->getType(); in Create()
3720 VK = semantics[resultIndex]->getValueKind(); in Create()
3721 assert(semantics[resultIndex]->getObjectKind() == OK_Ordinary); in Create()
3725 (1 + semantics.size()) * sizeof(Expr*), in Create()
3727 return new(buffer) PseudoObjectExpr(type, VK, syntax, semantics, in Create()
3732 Expr *syntax, ArrayRef<Expr*> semantics, in PseudoObjectExpr() argument
3736 PseudoObjectExprBits.NumSubExprs = semantics.size() + 1; in PseudoObjectExpr()
[all …]
|
| /external/libusb/ |
| D | configure.ac | 99 # Restore gnu89 inline semantics on gcc 4.3 and newer
|