| /netbsd-src/lib/libc/gen/ |
| H A D | wordexp.c | 61 wordexp(const char * __restrict words, wordexp_t * __restrict we, int flags) in wordexp() argument
65 _DIAGASSERT(we != NULL); in wordexp()
68 wordfree(we); in wordexp()
70 we->we_wordc = 0; in wordexp()
71 we->we_wordv = NULL; in wordexp()
72 we->we_strings = NULL; in wordexp()
73 we->we_nbytes = 0; in wordexp()
76 wordfree(we); in wordexp()
79 if ((error = we_askshell(words, we, flags)) != 0) { in wordexp()
80 wordfree(we); in wordexp()
[all …]
|
| /netbsd-src/usr.sbin/rwhod/ |
| H A D | rwhod.c | 315 struct whoent *we; in handleread() local
322 we = wd.wd_we; in handleread()
324 we->we_idle = ntohl(we->we_idle); in handleread()
325 we->we_utmp.out_time = in handleread()
326 ntohl(we->we_utmp.out_time); in handleread()
327 we++; in handleread()
362 struct whoent *we = mywd.wd_we, *wlast; in send_host_information() local
381 (void)strncpy(we->we_utmp.out_line, ep->line, in send_host_information()
382 sizeof(we->we_utmp.out_line)); in send_host_information()
383 (void)strncpy(we->we_utmp.out_name, ep->name, in send_host_information()
[all …]
|
| /netbsd-src/external/apache2/llvm/dist/llvm/docs/tutorial/MyFirstLanguageFrontend/ |
| H A 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 …]
|
| H A 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 …]
|
| H A 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, let's 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", let's 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:
115 Now that we have the relevant tokens coming from the lexer and we have
117 First we define a new parsing function:
[all …]
|
| H A D | LangImpl04.rst | 60 Well, that was easy :). In practice, we recommend always using
121 For Kaleidoscope, we are currently generating functions on the fly, one
123 ultimate optimization experience in this setting, but we also want to
124 catch the easy and quick stuff where possible. As such, we will choose
126 in. If we wanted to make a "static Kaleidoscope compiler", we would use
127 exactly the code we have now, except that we would defer running the
130 In order to get per-function optimizations going, we need to set up a
132 and organize the LLVM optimizations that we want to run. Once we have
133 that, we can add a set of optimizations to run. We'll need a new
134 FunctionPassManager for each module that we want to optimize, so we'll
[all …]
|
| H A 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 …]
|
| H A D | LangImpl07.rst | 12 LLVM <index.html>`_" tutorial. In chapters 1 through 6, we've built a
15 journey, we learned some parsing techniques, how to build and represent
51 In this case, we have the variable "X", whose value depends on the path
54 two values. The LLVM IR that we want for this example looks like this:
108 With this in mind, the high-level idea is that we want to make a stack
110 mutable object in a function. To take advantage of this trick, we need
138 above, we could rewrite the example to use the alloca technique to avoid
166 With this, we have discovered a way to handle arbitrary mutable
176 another one: we have now apparently introduced a lot of stack traffic
209 pass is the answer to dealing with mutable variables, and we highly
[all …]
|
| H A D | LangImpl02.rst | 15 language. Once we have a parser, we'll define and build an `Abstract
18 The parser we will build uses a combination of `Recursive Descent
23 the former for everything else). Before we get to parsing though, let's
33 Kaleidoscope, we have expressions, a prototype, and a function object.
53 subclass which we use for numeric literals. The important thing to note
58 Right now we only create the AST, so there are no useful accessor
61 definitions that we'll use in the basic form of the Kaleidoscope
104 For our basic language, these are all of the expression nodes we'll
106 Turing-complete; we'll fix that in a later installment. The two things
107 we need next are a way to talk about the interface to a function, and a
[all …]
|
| H A D | LangImpl03.rst | 28 In order to generate LLVM IR, we want some simple setup to get started.
29 First we define virtual code generation (codegen) methods in each AST
70 The second thing we want is a "LogError" method like we used for the
89 detail, we just need a single instance to pass into APIs that require it.
99 uses to contain code. It will own the memory for all of the IR that we
110 With these basics in place, we can start talking about how to generate
112 has been set up to generate code *into* something. For now, we'll assume
113 that this has already been done, and we'll just use it to emit code.
120 First we'll do numeric literals:
147 version of Kaleidoscope, we assume that the variable has already been
[all …]
|
| /netbsd-src/external/bsd/openldap/dist/doc/devel/lloadd/ |
| H A D | design.md | 8 upstream but depending on where we started, we might want to start with
10 - [ ] how to deal with the balancer running out of fds? Especially when we hit
11 the limit, then lose an upstream connection and accept() a client, we
50 we're under TLS
51 - ber_get_next(), if we don't have a tag, finished (unless we have true
52 edge-triggered I/O, also put the fd back into the ones we're waiting for)
56 client link (would it be fast enough if we remove them from upstream
63 - remove op from client map (how if we're in avl_apply?, another pass?)
64 - would be nice if we could wipe the complete client map then, otherwise
65 we need to queue it to have it freed when all abandons get passed onto
[all …]
|
| /netbsd-src/external/apache2/llvm/dist/llvm/docs/HistoricalNotes/ |
| H A 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 …]
|
| H A D | 2000-11-18-EarlyDesignIdeasResp.txt | 6 Okay... here are a few of my thoughts on this (it's good to know that we
9 > 1. We need to be clear on our goals for the VM. Do we want to emphasize
10 > portability and safety like the Java VM? Or shall we focus on the
21 pretty expensive operation to have to do. Additionally, we would like
25 2. Instead, we can do the following (eventually):
27 reinventing something that we don't add much value to). When the
36 we could sign the generated VM code with a host specific private
37 key. Then before the code is executed/loaded, we can check to see if
47 3. By focusing on a more low level virtual machine, we have much more room
52 > 2. Design issues to consider (an initial list that we should continue
[all …]
|
| /netbsd-src/external/apache2/llvm/dist/llvm/docs/ |
| H A D | MergeFunctions.rst | 20 explains how we could combine equal functions correctly to keep the module
38 LLVM code fundamentals. In this article, we assume the reader is familiar with
85 Do we need to merge functions? The obvious answer is: Yes, that is quite a
87 of them. But how do we detect duplicates? This is the idea: we split functions
89 we compare the "bricks" themselves, and then do our conclusions about functions
93 (let's assume we have only one address space), one function stores a 64-bit
95 mentioned above, and if functions are identical, except the parameter type (we
96 could consider it as a part of function type), then we can treat a ``uint64_t``
107 Let's briefly consider possible options about how and what we have to implement
116 As the second step, we should merge equal functions. So it should be a "merger"
[all …]
|
| /netbsd-src/external/gpl3/gdb/dist/sim/testsuite/cris/asm/ |
| H A D | bare3.ms | 6 ; Test that we can load a binary program at a non-zero address.
13 ; ...and that we know an offset we can jump for it to work, and all we
23 ; Make sure we're loaded at the linked address. Since we're re-used
24 ; in other tests, we have to provide for non-v32 as well.
39 ; Make sure we have enough contents for the mapping.
|
| /netbsd-src/external/apache2/llvm/dist/clang/docs/ |
| H A D | LibASTImporter.rst | 8 In this document, we assume basic knowledge about the Clang AST. See the :doc:`Introduction
21 For example, we'd like to parse multiple different files inside the same Clang tool.
22 It may be convenient if we could view the set of the resulting ASTs as if they were one AST resulti…
24 … refer to the context from which we import as the **"from" context** or *source context*; and the …
29 …text`` for that and then imports the missing definitions from the AST what we got from the debug i…
35 Why do we have to copy the node?
41 E.g. if we include the definition of the vector template (``#include <vector>``) in two translation…
42 Also, we have to discover *one definition rule* (ODR) violations.
44 So, we look up existing definitions, and then we check the structural equivalency on those nodes.
80 If A and B are AST nodes and *A depends on B*, then we say that A is a **dependant** of B and B is …
[all …]
|
| /netbsd-src/external/apache2/llvm/dist/llvm/docs/tutorial/ |
| H A D | BuildingAJIT3.rst | 9 change frequently.** Nonetheless we invite you to try it out as it stands, and
10 we welcome any feedback.
27 When we add a module to the KaleidoscopeJIT class from Chapter 2 it is
42 we have seen so far: rather than doing any work up front, it just scans the
49 for the lifetime of the program we can give the function a permanent "effective
56 function's stub to point at the function's compile callback, we enable lazy
63 chapter of this tutorial, but for now we'll trust the CompileOnDemandLayer to
64 set all the stubs and callbacks up for us. All we need to do is to add the
65 CompileOnDemandLayer to the top of our stack and we'll get the benefits of
95 First we need to include the CompileOnDemandLayer.h header, then add two new
[all …]
|
| H A D | BuildingAJIT2.rst | 9 change frequently.** Nonetheless we invite you to try it out as it stands, and
10 we welcome any feedback.
22 `Chapter 1 <BuildingAJIT1.html>`_ of this series we examined a basic JIT
28 In this layer we'll learn more about the ORC layer concept by using a new layer,
37 in short: to optimize a Module we create an llvm::FunctionPassManager
42 added to it. In this Chapter we will make optimization a phase of our JIT
45 important benefit: When we begin lazily compiling code (i.e. deferring
50 To add optimization support to our JIT we will take the KaleidoscopeJIT from
84 but after the CompileLayer we introduce a new member, TransformLayer, which sits
87 a *transform function*. For our transform function we supply our classes
[all …]
|
| /netbsd-src/external/apache2/llvm/dist/clang/docs/analyzer/developer-docs/ |
| H A D | InitializerLists.rst | 14 I've seen a few false positives that appear because we construct
34 Ideally, we should be able to model the initializer list's methods precisely.
41 which would be of type ``T*`` and represent ``begin()``, so we'd trivially model ``begin()``
53 Approach (1): If only we enabled ``ProgramState::bindLoc(..., notifyChanges=true)``
57 conservative as the current patch's solution. Ideally, we do not want escapes to
58 happen so early. Instead, we'd prefer them to be delayed until the list itself
62 would be the right thing to do. Currently we didn't think about that because we
77 moments. If we allow doing this within ``checkPointerEscape`` callback itself, we
80 with maximum stress on the checkers - still not too much stress when we have
91 Sometimes we model library aspects in the engine and model language constructs in checkers.
[all …]
|
| /netbsd-src/external/gpl3/gcc.old/dist/libgcc/config/i386/ |
| H A D | morestack.S | 34 # When this is called stack space is very low, but we ensure that
47 # the stack which we should not use.
67 # After we allocate more stack, we call L, which is in our caller.
68 # When that returns (to the predicted instruction), we release the
75 # The amount of extra space we ask for. In general this has to be
86 # The amount of space we ask for when calling non-split-stack code.
118 cmpl %gs:0x30,%eax # See if we have enough space.
119 jb 2f # Get more space if we need it.
129 # Since we aren't doing a full split stack, we don't need to
137 # probably take more clock cycles than we will lose breaking
[all …]
|
| H A D | t-sol2 | 1 # We need to use -fPIC when we are using gcc to compile the routines in
2 # crtstuff.c. This is only really needed when we are going to use gcc/g++
3 # to produce a shared library, but since we don't know ahead of time when
4 # we will be doing that, we just always use -fPIC when compiling the
8 # the call & alignment statement, but before we switch back to the
|
| /netbsd-src/external/gpl3/gcc/dist/libgcc/config/i386/ |
| H A D | morestack.S | 35 # When this is called stack space is very low, but we ensure that
48 # the stack which we should not use.
68 # After we allocate more stack, we call L, which is in our caller.
69 # When that returns (to the predicted instruction), we release the
76 # The amount of extra space we ask for. In general this has to be
87 # The amount of space we ask for when calling non-split-stack code.
119 cmpl %gs:0x30,%eax # See if we have enough space.
120 jb 2f # Get more space if we need it.
130 # Since we aren't doing a full split stack, we don't need to
138 # probably take more clock cycles than we will lose breaking
[all …]
|
| H A D | t-sol2 | 1 # We need to use -fPIC when we are using gcc to compile the routines in
2 # crtstuff.c. This is only really needed when we are going to use gcc/g++
3 # to produce a shared library, but since we don't know ahead of time when
4 # we will be doing that, we just always use -fPIC when compiling the
8 # the call & alignment statement, but before we switch back to the
|
| /netbsd-src/external/ibm-public/postfix/dist/implementation-notes/ |
| H A D | MILTER | 16 If we want to support message modifications (add/delete recipient,
18 to be implemented in the cleanup server, if we want to avoid extra
31 How do we set up the Milters with SMTP mail versus local submissions?
62 work around it. But we should avoid inconsistency. If Postfix can
72 applications can be tested with XCLIENT. If not, then we must
93 after "postsuper -r" we simply disable Milter processing. The
109 the message body. If we can implement all the header/body-related
110 Milter operations in the cleanup server, then we can try to edit
116 To implement in-place queue file edits, we need to introduce
118 structure. All we need is a way to specify a jump from one place
[all …]
|
| /netbsd-src/sys/arch/mac68k/mac68k/ |
| H A D | pramasm.s | 74 bcs _readPramDone | see if we are through
255 moveml #0x78c0,%sp@- | store off the regs we need
258 bsr _C_LABEL(Transfer) | so we can set our value
261 swap %d1 | we want access to data byte of command
268 movel #0x00d50035,%d1 | we have to set the write protect bit
278 swap %d0 | we want the length byte
289 | (we really only need to zero the high
310 dbf %d1,fivebit | til we've done bit 4-0
335 swap %d1 | we want access to (data/dummy) byte
338 swap %d1 | now we want to tweak the command
[all …]
|