| /llvm-project/flang/test/Semantics/ |
| H A D | allocate06.f90 | 56 …!ERROR: Type parameters in type-spec must be assumed if and only if they are assumed for allocatab…
58 …!ERROR: Type parameters in type-spec must be assumed if and only if they are assumed for allocatab…
59 …!ERROR: Type parameters in type-spec must be assumed if and only if they are assumed for allocatab…
61 …!ERROR: Type parameters in type-spec must be assumed if and only if they are assumed for allocatab…
63 …!ERROR: Type parameters in type-spec must be assumed if and only if they are assumed for allocatab…
64 …!ERROR: Type parameters in type-spec must be assumed if and only if they are assumed for allocatab…
66 …!ERROR: Type parameters in type-spec must be assumed if and only if they are assumed for allocatab…
68 …!ERROR: Type parameters in type-spec must be assumed if and only if they are assumed for allocatab…
70 …!ERROR: Type parameters in type-spec must be assumed if and only if they are assumed for allocatab…
71 …!ERROR: Type parameters in type-spec must be assumed if and only if they are assumed for allocatab…
[all …]
|
| H A D | allocate10.f90 | 83 …!ERROR: The number of shape specifications, when they appear, must match the rank of allocatable o…
85 …!ERROR: The number of shape specifications, when they appear, must match the rank of allocatable o…
87 …!ERROR: The number of shape specifications, when they appear, must match the rank of allocatable o…
89 …!ERROR: The number of shape specifications, when they appear, must match the rank of allocatable o…
91 …!ERROR: The number of shape specifications, when they appear, must match the rank of allocatable o…
94 …!ERROR: The number of shape specifications, when they appear, must match the rank of allocatable o…
98 …!ERROR: The number of shape specifications, when they appear, must match the rank of allocatable o…
100 …!ERROR: The number of shape specifications, when they appear, must match the rank of allocatable o…
102 …!ERROR: The number of shape specifications, when they appear, must match the rank of allocatable o…
104 …!ERROR: The number of shape specifications, when they appear, must match the rank of allocatable o…
|
| /llvm-project/mlir/include/mlir/Dialect/SPIRV/IR/ |
| H A D | SPIRVLogicalOps.td | 58 floating-point type. They must have the same type, and they must have
84 floating-point type. They must have the same type, and they must have
110 floating-point type. They must have the same type, and they must have
136 floating-point type. They must have the same type, and they must have
162 floating-point type. They must have the same type, and they mus
[all...] |
| /llvm-project/lldb/examples/python/ |
| H A D | scripted_step.py | 45 # a) They determine if they have completed their job or not. If they have
46 # they indicate that by calling SetPlanComplete on their thread plan.
47 # b) They decide whether they want to return control to the user or not.
48 # They do this by returning True or False respectively.
49 # c) If they are not done, they set up whatever machinery they will use
68 # plans get asked if they are "stale". If they are say they are stale
69 # then they will get popped. This question is asked with the "is_stale" method.
74 # command repeatedly until they leave the frame of interest by stepping.
|
| /llvm-project/llvm/lib/DebugInfo/PDB/Native/ |
| H A D | DbiModuleList.cpp | 35 // If they're compatible, and they're both ends, then they're equal. in operator ==()
39 // If one is an end and the other is not, they're not equal. in operator ==()
44 // - They're compatible in operator ==()
45 // - They're not *both* end iterators in operator ==()
47 // Thus, they're compatible iterators pointing to a valid file on the same in operator ==()
63 // account for this, early-out if they're equal. in operator <()
75 // If they're both end iterators, the distance is 0. in operator -()
157 // is valid, so they ar in isCompatible()
[all...] |
| /llvm-project/flang/docs/ |
| H A D | FortranForCProgrammers.md | 37 can be read only as discouraging their use in new code -- they'll
52 * Fortran has a _lot_ of built-in "intrinsic" functions. They are always
55 modified so that they have the right type (e.g., `AIMAG` has a leading `A`
93 They are parameterized with "kind" values, which should be treated as
105 `CHARACTER` variables are fixed-length strings and they get padded out
115 They can have user-defined destructors (`FINAL` procedures).
116 They can specify default initial values for their components.
145 They are automatically deallocated when they go out of scope, much
184 They share the same name space, but functions cannot be called as
277 they point instead.
[all …]
|
| H A D | ModFiles.md | 22 Module files must be searchable by module name. They are typically named
24 other compilers so users will know what they are. Also, makefiles and scripts
38 entities that they depend on.
70 The order will match the order they first appeared in the source.
92 in the `.mod` file. (Currently they are readable in PGI `.mod` files.)
124 3. The `-I` directories in the order they appear on the command line
144 modules it depends on and report if they are out of date.
150 When processing `.mod` files we know they are valid Fortran with these properties:
172 modules on which they depend, so that non-top-level local modules and the
|
| H A D | C++style.md | 33 still be able to compile f18. They are listed at the end of this document.
38 unless they introduce ambiguity.
74 they mean the same thing -- e.g., `clear()` and `size()` member functions
80 only public data members shouldn't use trailing underscores, since they
116 align vertically -- they are maintenance problems.
129 they all should, with the understanding that the cases are all unexceptional.
152 1. Use `{braced initializers}` in all circumstances where they work, including
153 default data member initialization. They inhibit implicit truncation.
185 when they can't be function results.
201 This is implicit when they are function results assigned to local variables
[all …]
|
| /llvm-project/lldb/tools/lldb-dap/ |
| H A D | README.md | 203 All commands and command outputs will be sent to the debugger console when they are executed.
|
| /llvm-project/llvm/test/CodeGen/Mips/ |
| H A D | fneg.ll | 2 ; They obey the Has2008 and ABS2008 configuration bits which govern the
4 ; present, they confirm to 1985.
5 ; In 1985 mode, abs.[ds] are arithmetic (i.e. they raise invalid operation
6 ; exceptions when given NaN's). In 2008 mode, they are non-arithmetic (i.e.
7 ; they are copies and don't raise any exceptions).
|
| /llvm-project/clang/docs/ |
| H A D | ClangTools.rst | 26 used by C++ developers. That is they are *not* primarily for use by
27 Clang developers, although they are hopefully useful to C++ developers
29 functionality. They are developed in three components: the underlying
45 find good APIs for libraries as they are lifted out of a few tools and
50 of Clang itself. They are entirely within the Clang *project*,
88 they'll be tracked here. The focus of this documentation is on the scope
138 that don't want to use ``auto`` because they are afraid that they might lose
|
| /llvm-project/libc/docs/dev/ |
| H A D | code_style.rst | 16 class data members, non-const globals and local variables. They all use the
18 #. **const and constexpr variables** - They use the capitalized
19 ``SNAKE_CASE`` irrespective of whether they are local or global.
20 #. **Function and methods** - They use the ``snake_case`` style like the
23 implementation. They use the ``CaptilizedCamelCase`` style.
33 down to the compiler with the ``-D`` command line flag. They start with the
34 ``LIBC_COPT_`` prefix. They are used to tune the behavior of the libc.
35 They either denote an action or define a constant.
38 folder. They all start with the ``LIBC_`` prefix.
124 should explicitly depend on if they set ``errno`` to indicate error
[all …]
|
| /llvm-project/lldb/docs/resources/ |
| H A D | dataformatters.rst | 20 To this aim, they are hooked into the ``ValueObjects`` model, in order to
97 ``GetScriptedSummary()`` entry point for this purpose, if they desire to allow
102 facilities for users to interact with C++ formatters, and as such they are
111 at the Python layer they are handed an ``SBValue`` (since nothing else could be
128 Filters are themselves synthetic children. Since all they do is provide child
131 they perfectly fit within the realm of synthetic children and are only shown as
133 elements to be shown with relative ease is a valuable task, and they should not
154 number of children, and then for each of them as necessary, they should be
155 prepared to return a ``ValueObject`` describing the child. They might also be
160 documentation, and they mostly serve bookkeeping purposes.
[all …]
|
| /llvm-project/mlir/docs/ |
| H A D | Canonicalization.md | 11 Most compilers have canonicalization passes, and sometimes they have many
41 They should work correctly with all instances of the canonicalization pass
45 rewrites are considered a bug: they can make the canonicalizer pass less
188 /// 1. They can leave the operation alone and without changing the IR, and
190 /// 2. They can mutate the operation in place, without changing anything else
192 /// 3. They can return an existing value or attribute that can be used instead
207 /// 1. They can leave the operation alone and without changing the IR, and
209 /// 2. They can mutate the operation in place, without changing anything else
211 /// 3. They can return a list of existing values or attribute that can be used
|
| /llvm-project/llvm/docs/ |
| H A D | Projects.rst | 61 a directory from which they can be linked later.
66 project. By global, we mean that they are used by more than one library or
69 By placing your header files in **include**, they will be found
110 variables. Below is a list of the variables one can set and what they can
128 This is a space separated list of subdirectories that should be built. They
138 This is a list of directories that can be built if they exist, but will not
139 cause an error if they do not exist. They are built serially in the order
140 in which they are listed.
|
| H A D | WritingAnLLVMPass.rst | 22 perform the transformations and optimizations that make up the compiler, they
23 build the analysis results that are used by these transformations, and they
38 pass meets (which are indicated by which class they derive from).
129 they may change the contents of an SCC.
136 described below should return ``true`` if they modified the program, or
137 ``false`` if they didn't.
147 ``CallGraphSCCPass``\ es are not allowed to do. They can add and remove
187 they are executed in a particular order, and ``FunctionPass``\ es do not modify
200 should return ``true`` if they modified the program, or ``false`` if they
[all...] |
| /llvm-project/llvm/test/CodeGen/X86/ |
| H A D | alignment.ll | 3 ; This cannot get rounded up to the preferred alignment (16) if they have an
14 ; they have an explicit alignment specified.
27 ; This cannot get rounded up to the preferred alignment (16) if they have an
37 ; they have an explicit alignment specified and a section specified.
|
| H A D | log2_not_readnone.ll | 3 ; Log2 and exp2 are string-matched to intrinsics. If they are not declared
4 ; readnone, they can't be changed to intrinsics (because they can change errno).
|
| /llvm-project/llvm/test/CodeGen/AMDGPU/ |
| H A D | store-private.ll | 159 ; they might be different locations
170 ; they might be different locations
209 ; they might be different locations
220 ; they might be different locations
258 ; they might be different locations
264 ; they might be different locations
270 ; they might be different locations
281 ; they might be different locations
287 ; they might be different locations
293 ; they might be different locations
[all …]
|
| /llvm-project/llvm/utils/ |
| H A D | findoptdiff | 12 # the two llvm builds to compare. It is generally expected that they
13 # are "close cousins". That is, they are the same except that the
17 # The script takes two bitcode files, one from each build. They are
26 # for each pass, if they do differ, are placed in a diffs.# file.
30 # so they can be differenced without making false positives for known
|
| /llvm-project/clang/test/CodeGenCXX/ |
| H A D | ps-dllstorage-vtable-rtti.cpp | 7 /// then Clang must export the vtable and typeinfo symbol from the TU where they
9 /// function") and must import them in other modules where they are referenced.
36 /// 'key()' (and they must be exported from there).
54 /// typeinfo symbols of 'FullExport' will be defined in this TU, and so they
74 /// 'key()' (and they must be exported from there). Here, we will reference the
96 /// typeinfo symbol of 'PartExport' will be defined in this TU, and so they must
|
| /llvm-project/llvm/docs/GlobalISel/ |
| H A D | GMIR.rst | 49 Generic virtual registers are like virtual registers but they are not assigned a
52 :ref:`gmir-regbank`. Eventually they will be constrained to a register class
53 at which point they become normal virtual registers.
62 * instead of immediates, they use a generic virtual register defined by an
67 * instead of physical register, they use a generic virtual register that is
88 definition is rather loose so let's talk about what they can achieve.
91 equal in every way and support the same instructions for the same cost. They're
103 In practice, register files A and B are rarely equal. They can typically store
|
| /llvm-project/lld/ELF/ |
| H A D | MarkLive.cpp | 139 // * FDEs refer to the function they contain information about
140 // The last kind of relocation cannot keep the referred section alive, or they
148 // LSDAs and personality functions if we found that they were unused. in scanEhFrameSection()
167 // Some sections are used directly by the loader, so they should never be in isReserved()
265 // Usually, non-SHF_ALLOC sections are not removed even if they are in run()
267 // whether they are garbage or not (e.g. there is usually no section in run()
272 // Note on SHF_LINK_ORDER: Such sections contain metadata and they in run()
273 // have a reverse dependency on the InputSection they are linked with. in run()
277 // or --emit-reloc were given. And they are subject of garbage in run()
335 // (because they ca in moveToMain()
[all...] |
| /llvm-project/mlir/include/mlir/IR/ |
| H A D | TypeUtilities.h | 46 /// Returns success if the given two shapes are compatible. That is, they have
53 /// they are both scalars (not shaped), or they are both shaped types and at
54 /// least one is unranked or they have compatible dimensions. Dimensions are
63 /// Returns success if all given types have compatible shapes. That is, they are
64 /// all scalars (not shaped), or they are all shaped types and any ranked shapes
|
| /llvm-project/llvm/include/llvm/Transforms/Utils/ |
| H A D | FunctionComparator.h | 46 /// when they are first visited. This order is deterministic, and so the
48 /// is updated. If the symbols are weak, this would be incorrect. If they are
90 /// they will generate machine code with the same behaviour. DataLayout is
141 /// Stage 4: Types are neither vectors, nor pointers. And they differ.
181 /// Then you can see integers, and they are, like a floats,
208 /// 2.2. All pointers of the same address space, no matter what they point to,
229 /// they are equal.
295 /// 2. If types are integers, check that they have the same width. If they
296 /// are vectors, check that they hav
[all...] |