| /external/libcups/ |
| D | config.h.in | 96 * Do we have domain socket support, and if so what is the default one?
131 * Do we have posix_spawn?
138 * Do we have ZLIB?
146 * Do we have PAM stuff?
156 * Do we have <shadow.h>?
163 * Do we have <crypt.h>?
186 * Do we have the long long type?
201 * Do we have the strtoll() function?
212 * Do we have the strXXX() functions?
221 * Do we have the geteuid() function?
[all …]
|
| /external/musl/src/misc/ |
| D | wordexp.c | 26 static int do_wordexp(const char *s, wordexp_t *we, int flags) in do_wordexp() argument
41 if (flags & WRDE_REUSE) wordfree(we); in do_wordexp()
86 wc = we->we_wordc; in do_wordexp()
87 wv = we->we_wordv; in do_wordexp()
92 if (we->we_offs > SIZE_MAX/sizeof(void *)/4) in do_wordexp()
94 i += we->we_offs; in do_wordexp()
96 we->we_offs = 0; in do_wordexp()
152 we->we_wordv = wv; in do_wordexp()
153 we->we_wordc = i; in do_wordexp()
156 if (wv) for (i=we->we_offs; i; i--) in do_wordexp()
[all …]
|
| /external/perfetto/docs/design-docs/ |
| D | heapprofd-sampling.md | 15 probability p of being sampled. In theory we can think of each byte undergoing a
16 Bernoulli trial. The reason we use a random sampling approach, as opposed to
20 To scale the sampled bytes to the correct scale, we multiply by 1 / p, i.e. if
21 we sample a byte with probability 10%, then each byte sampled represents 10
32 chance of it being sampled at least once, we return the size of the
35 3. If the size of the allocation is smaller, then we compute the number of times
36 we would draw a sample if we sampled each byte with the given sampling rate:
38 * In practice we do this by keeping track of the arrival time of the next
39 sample. When an allocation happens, we subtract its size from the arrival
40 time of the next sample, and check whether we have brought it below zero. We
[all …]
|
| /external/llvm/docs/tutorial/ |
| D | LangImpl09.rst | 12 LLVM <index.html>`_" tutorial. In chapters 1 through 8, we've built a
19 source that the programmer wrote. In LLVM we generally use a format
23 The short summary of this chapter is that we'll go through the
27 Caveat: For now we can't debug via the JIT, so we'll need to compile
29 we'll make a few modifications to the running of the language and
30 how programs are compiled. This means that we'll have a source file
32 interactive JIT. It does involve a limitation that we can only
36 Here's the sample program we'll be compiling:
54 locations more difficult. In LLVM IR we keep the original source location
61 tutorial we're going to avoid optimization (as you'll see with one of the
[all …]
|
| D | LangImpl08.rst | 20 other architectures. In this tutorial, we'll target the current
23 To specify the architecture that you want to target, we use a string
28 As an example, we can see what clang thinks is our current target
39 Fortunately, we don't need to hard-code a target triple to target the
48 functionality. For example, if we're just using the JIT, we don't need
49 the assembly printers. Similarly, if we're only targeting certain
50 architectures, we can only link in the functionality for those
53 For this example, we'll initialize all the targets for emitting object
71 // Print an error and exit if we couldn't find the requested target.
72 // This generally occurs if we've forgotten to initialise the
[all …]
|
| D | LangImpl04.rst | 60 Well, that was easy :). In practice, we recommend always using
113 For Kaleidoscope, we are currently generating functions on the fly, one
115 ultimate optimization experience in this setting, but we also want to
116 catch the easy and quick stuff where possible. As such, we will choose
118 in. If we wanted to make a "static Kaleidoscope compiler", we would use
119 exactly the code we have now, except that we would defer running the
122 In order to get per-function optimizations going, we need to set up a
124 and organize the LLVM optimizations that we want to run. Once we have
125 that, we can add a set of optimizations to run. We'll need a new
126 FunctionPassManager for each module that we want to optimize, so we'll
[all …]
|
| D | LangImpl05.rst | 18 of "build that compiler", we'll extend Kaleidoscope to have an
30 Before we get going on "how" we add this extension, lets talk about
31 "what" we want. The basic idea is that we want to be able to write this
44 like any other. Since we're using a mostly functional form, we'll have
57 Now that we know what we "want", lets break this down into its
63 The lexer extensions are straightforward. First we add new enum values
73 Once we have that, we recognize the new keywords in the lexer. This is
94 To represent the new expression we add a new AST node for it:
114 Now that we have the relevant tokens coming from the lexer and we have
116 First we define a new parsing function:
[all …]
|
| D | BuildingAJIT2.rst | 9 change frequently.** Nonetheless we invite you to try it out as it stands, and
10 we welcome any feedback.
16 `Chapter 1 <BuildingAJIT1.html>`_ of this series we examined a basic JIT
22 In this layer we'll learn more about the ORC layer concept by using a new layer,
31 in short: to optimize a Module we create an llvm::FunctionPassManager
36 added to it. In this Chapter we will make optimization a phase of our JIT
39 important benefit: When we begin lazily compiling code (i.e. deferring
44 To add optimization support to our JIT we will take the KaleidoscopeJIT from
79 but after the CompileLayer we introduce a typedef for our optimization function.
80 In this case we use a std::function (a handy wrapper for "function-like" things)
[all …]
|
| D | BuildingAJIT1.rst | 43 To provide input for our JIT we will use the Kaleidoscope REPL from
53 we will make this connection with the earlier APIs explicit to help people who
83 The APIs that we build in these tutorials will all be variations on this simple
84 theme. Behind the API we will refine the implementation of the JIT to add
85 support for optimization and lazy compilation. Eventually we will extend the
92 In the previous section we described our API, now we examine a simple
102 of this tutorial we'll modify the REPL to enable new interactions with our JIT
103 class, but for now we will take this setup for granted and focus our attention on
107 usual include guards and #includes [2]_, we get to the definition of our class:
147 however the linker was hidden inside the MCJIT class. In ORC we expose the
[all …]
|
| D | LangImpl06.rst | 12 LLVM <index.html>`_" tutorial. At this point in our tutorial, we now
23 is good or bad. In this tutorial we'll assume that it is okay to use
26 At the end of this tutorial, we'll run through an example Kaleidoscope
33 The "operator overloading" that we will add to Kaleidoscope is more
37 chapter, we will add this capability to Kaleidoscope, which will let the
42 Thus far, the parser we have been implementing uses recursive descent
49 The two specific features we'll add are programmable unary operators
80 library in the language itself. In Kaleidoscope, we can implement
115 This just adds lexer support for the unary and binary keywords, like we
117 about our current AST, is that we represent binary operators with full
[all …]
|
| /external/antlr/runtime/Cpp/include/ |
| D | antlr3collections.inl | 138 /* Now we need to allocate the root node. This makes it easier
139 * to use the tree as we don't have to do anything special
144 /* Now we seed the root node with the index being the
145 * highest left most bit we want to test, which limits the
151 /* And as we have nothing in here yet, we set both child pointers
159 * we use calloc() to initialise it.
172 /* the nodes are all gone now, so we need only free the memory
189 * then by definition (as the bit index decreases as we descent the trie)
190 * we have reached a 'backward' pointer. A backward pointer means we
192 * and it must either be the key we are looking for, or if not then it
[all …]
|
| D | antlr3baserecognizer.inl | 9 // If we have been supplied with a pre-existing recognizer state
10 // then we just install it, otherwise we must create one from scratch
19 // Install the one we were given, and do not reset it here
67 // The token was the one we were told to expect
70 m_state->set_errorRecovery(false); // Not in error recovery now (if we were)
75 // We did not find the expected token type, if we are backtracking then
76 // we just set the failed flag and return.
87 // going on, so we mismatch, which creates an exception in the recognizer exception
116 return true; // This token is unknown, but the next one is the one we wanted
119 return false; // Neither this token, nor the one following is the one we wanted
[all …]
|
| /external/libxkbcommon/doc/ |
| D | quick-guide.md | 32 Before we can do anything interesting, we need a library context:
46 Next we need to create a keymap, `xkb_keymap`. This is an immutable object
50 If we are an evdev client, we have nothing to go by, so we need to ask
54 by the X server. With it, we can fill a struct called `xkb_rule_names`;
73 If we are a Wayland client, the compositor gives us a string complete
74 with a keymap. In this case, we can create the keymap object like this:
87 If we are an X11 client, we are better off getting the keymap from the
88 X server directly. For this we need to choose the XInput device; here
89 we will use the core keyboard device:
105 Now that we have the keymap, we are ready to handle the keyboard devices.
[all …]
|
| /external/python/cpython3/Objects/stringlib/ |
| D | stringlib_find_two_way_notes.txt | 41 and if a mismatch occurs, we jump ahead by the amount matched plus 1.
55 Why are we allowed to do this? Because we cut the needle very
57 we have
66 cut, then the following alignments do not work, so we can skip them:
86 right, then we could run into something like this:
91 The same argument holds that we can skip ahead by 4, so long as
102 true, we need them to be true for all possible '?' values. We thus
108 Once we have ensured the right part matches, we scan the left part
109 (order doesn't matter, but traditionally right-to-left), and if we
110 find a mismatch, we jump ahead by
[all …]
|
| /external/llvm/docs/HistoricalNotes/ |
| D | 2003-06-25-Reoptimizer1.txt | 14 exceeds a threshold, we identify a hot loop and perform second-level
30 How do we keep track of which edges to instrument, and which edges are
41 3) Mark BBs which end in edges that exit the hot region; we need to
44 Assume that there is 1 free register. On SPARC we use %g1, which LLC
46 edge which corresponds to a conditional branch, we shift 0 for not
48 through the hot region. Silently fail if we need more than 64 bits.
50 At the end BB we call countPath and increment the counter based on %g1
56 together to form our trace. But we do not allow more than 5 paths; if
57 we have more than 5 we take the ones that are executed the most. We
58 verify our assumption that we picked a hot back-edge in first-level
[all …]
|
| /external/llvm/docs/ |
| D | MergeFunctions.rst | 22 explains how we could combine equal functions correctly, keeping module valid.
31 cover only common cases, and thus avoid cases when after minor code changes we
39 code fundamentals. In this article we suppose reader is familiar with
77 again and again, and yet you don't understand why we implemented it that way.
98 Do we need to merge functions? Obvious thing is: yes that's a quite possible
99 case, since usually we *do* have duplicates. And it would be good to get rid of
100 them. But how to detect such a duplicates? The idea is next: we split functions
101 onto small bricks (parts), then we compare "bricks" amount, and if it equal,
106 (let's assume we have only one address space), one function stores 64-bit
108 mentioned above, and if functions are identical, except the parameter type (we
[all …]
|
| /external/tcpdump/ |
| D | configure.ac | 24 # Try to enable as many C99 features as we can.
25 # At minimum, we want C++/C99-style // comments.
77 # OK, we found smi.h. Do we have libsmi with smiInit?
82 # OK, we have libsmi with smiInit. Can we use it?
188 # All of the ones we check for must be available in order to enable
191 # XXX - do we need to check for all of them, or are there some that, if
196 # First, make sure we have the required header.
201 # We do; now make sure we have the required functions.
234 # If they aren't both defined, we don't have sufficient OS
235 # support for IPv6, so we don't look for IPv6 support libraries,
[all …]
|
| D | CMakeLists.txt | 3 # We need 3.12 or later, so that we can set policy CMP0074; see
77 # If, for whatever reason, directories in which we search for external
79 # added to the executable's rpath in the build process, we most
114 # So we *explicitly* state that only C is used; there is currently no
134 # If we're building with Visual Studio, we require Visual Studio 2015,
157 # Try to enable as many C99 features as we can.
158 # At minimum, we want C++/C99-style // comments.
164 # so, unless and until we require CMake 3.1 or later, we have to do it
165 # ourselves on pre-3.1 CMake, so we just do it ourselves on all versions
172 # support for HP C. Therefore, even if we use CMAKE_C_STANDARD with
[all …]
|
| /external/skia/site/docs/user/ |
| D | color.md | 9 What we mean by color management
14 D50. And we can infer from that same description how to transform from that
33 in color management, and we need to divide it out if it's multiplied in
42 type called SkColorSpaceXformSteps. You'll see it as 5 steps there: we always
48 Whenever we're about to do some drawing we look at which of those steps we
49 really need to do. Any step that's a fundamental no-op we skip:
60 * if we've skipped 3 and 4 already, we can skip 2 and 5 any time the transfer
63 * if we've skipped all of 2-5, we can skip 1 and 6 if we were going to do
70 with that same color space, we'll notice we can skip all six steps. Sometimes
84 (Order matters there.) The gist is, we assume any untagged sources are sRGB.
[all …]
|
| /external/skia/bazel/external/ |
| D | README.md | 1 This folder is where we put `BUILD.bazel` files for external (e.g. third party) dependencies.
3 If a dependency supports Bazel, we should use those rules, but if the dependency does not, we
6 We generally compile third_party deps from source. If we do, we clone the repository and use
8 `new_local_repository` or `new_git_repository`) and we refer to those targets using labels like
11 Some third_party deps we only link against prebuilt versions. For those, we do not involve
22 issues that Clang's diagnostic warnings catch (e.g. missing `override`), we will see those warnings
25 Generally, we do not want to have to fix third_party code's warnings, so instead of
|
| /external/bazel-skylib/tests/native_binary/ |
| D | BUILD | 29 # On Windows we need the ".exe" extension.
31 # Therefore we can use ".exe" on every platform.
41 # On Windows we need the ".exe" extension.
43 # Therefore we can use ".exe" on every platform.
64 # On Windows we need the ".exe" extension.
66 # Therefore we can use ".exe" on every platform.
76 # On Windows we need the ".exe" extension.
78 # Therefore we can use ".exe" on every platform.
88 # On Windows we need the ".exe" extension.
90 # Therefore we can use ".exe" on every platform.
[all …]
|
| /external/python/cryptography/docs/ |
| D | security.rst | 5 policies we have adopted to ensure that security issues are addressed in a
11 In addition to ``cryptography``'s code, we're also concerned with the security
12 of the infrastructure we run (primarily ``cryptography.io``). If you discover
13 a security vulnerability in our infrastructure, we ask you to report it using
23 That's a bit academic, but basically it means the scope of what we consider a
24 vulnerability is broad, and we do not require a proof of concept or even a
28 To give a few examples of things we would consider security issues:
33 * If, under any circumstances, we used a CSPRNG which wasn't fork-safe.
37 Examples of things we wouldn't consider security issues:
45 In general, if you're unsure, we request that you to default to treating things
[all …]
|
| /external/mesa3d/src/intel/genxml/ |
| D | README | 11 other hand, most compiler recognize that the template struct we
17 2) For some types we need to have overlapping bit fields. For
27 flexibility in how we combine things. In the case of overlapping
28 fields (the u32 and float case), if we only set one of them in
38 Once we have the pack function it allows us to hook in various
39 transformations and validation as we go from template struct to dwords
43 overflowing values to the fields, but we've of course had lots of
44 cases where we make mistakes and write overflowing values. With
45 the pack function, we can actually assert on that and catch it at
49 float to a u32, but we also convert from bool to bits, from
[all …]
|
| /external/skia/bazel/rbe/ |
| D | README.md | 7 that we use to compile our code.
13 has the desirable property of not needing to change and upload RBE Docker images if we need to
16 The only requirement we have of our Docker image (beyond the minimum requirements to run Bazel)
30 In accordance with SLSA level 1, we want to be able to have a scripted way of building our image
31 and specify exactly what artifacts are in it. To accommodate this, we specify the exact sha256
32 hash of the base Docker image we use and the exact versions of the packages we install on top of
33 that. If we need to add a package or update things, it is best build the image without these
59 While the generated files *do* have a platform we can use (e.g.
60 `//bazel/rbe/gce_linux/config:platform`), we do not use it because we cannot easily customize it
61 without a risk that the changes will be lost when we update the image. Thankfully, we can specify
[all …]
|
| /external/libpcap/ |
| D | CMakeLists.txt | 3 # We need 3.12 or later, so that we can set policy CMP0074; see
12 # neither do we with autotools; don't do so with CMake, either, and
54 # that finishes, checking for Haiku and, if we're building for
56 # we don't require a C++ compiler on platforms other than Haiku.
58 # CMAKE_SYSTEM_NAME is set by project(), so we can't do this by
91 # system library, which we do *NOT* want to put in our libpcap.pc and
94 # So we just run pkg-config ourselves, so that we get its output
118 # package for it to find. XXX - what do we do here?
140 # package for it to find. XXX - what do we do here?
170 # be CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES, so that's what we use
[all …]
|