Lines Matching +refs:po +refs:edited +refs:fields
3264 'po'
3266 various languages, 'LANGUAGE.po'. This directory also contains
6762 * A language definition record. These records have two fields: the
6768 These records have two fields: the string 'TargetSave', and a
6772 information. These records have two fields: the string 'Variable',
6781 information. These records have two fields: the string
6793 These records have two fields: the string 'HeaderInclude' and the
6800 These records have two fields: the string 'SourceInclude' and the
6805 fields: the string 'Enum', a space-separated list of properties and
6826 given in an 'Enum' record. These records have two fields: the
6856 fields:
9758 All GENERIC trees have two fields in common. First, 'TREE_CHAIN' is a
10054 of the fields in the type or whether one or more of them overlap.
10067 of the expressions in the previous fields in 'TYPE_FIELDS' are
10225 field within this word; this may be nonzero even for fields that
10226 are not bit-fields, since 'DECL_OFFSET_ALIGN' may be greater than
10261 'DECL' macros to work. The fields it contains are a unique ID,
10266 contains fields that most 'DECL' nodes need, such as a field to
10300 contains fields necessary to store visibility information, as well
10383 Add macros to access any new fields and flags
11070 In the front end, you should not depend on the fields appearing in
11071 any particular order. However, in the middle end, fields must
11072 appear in declaration order. You should not assume that all fields
11073 will be represented. Unrepresented fields will be cleared
12164 'TREE_CHAIN' fields.
12202 not depend in any way on the order in which fields appear on this list.
12521 fields.
12538 fields.
12796 most GIMPLE statements. There are some fields that may not be relevant
12798 to take advantage of holes left by other fields (thus making the
12839 bit holes left by the previous fields.
12867 take advantage of the 32-bit hole left by the previous fields.
12887 On the other hand, several fields in this tuple need to be shared with
12888 the 'gimple_statement_with_memory_ops' tuple. So, these common fields
12916 except that it contains 4 additional fields to hold vectors related
12952 Each tuple will add some fields.
15249 possible to keep track of all the elements of an array or the fields of
15946 * Bit-Fields:: Expressions representing bit-fields in memory or reg.
16372 'SYMBOL_REF_BLOCK_OFFSET' fields.
16404 RTL expressions contain several flags (one-bit bit-fields) that are used
16593 Set the 'unchanging' and 'volatil' fields in a 'subreg' to reflect
16626 These are the fields to which the above macros refer:
18954 These three fields occupy the same position in every insn, independent
19004 Insns with code 'insn' have four additional fields beyond the three
19015 'jump_insn' insns have the same extra fields as 'insn' insns,
19036 'call_insn' insns have the same extra fields as 'insn' insns,
19062 to. It contains two special fields of data in addition to the
19116 They contain no information beyond the three standard fields.
19120 declarative information. They contain two nonstandard fields, an
19239 Here is a table of the extra fields of 'insn', 'jump_insn' and
20037 Each 'basic_block' contains two integer fields to represent profile
20414 innermost loop to that the block belongs. The most useful fields of
20423 There are other fields in the loop structures, many of them used only
20795 two representations has all its fields filled for both data
25457 fields that should be extracted, should be either element mode of
25465 individual fields. The N mode is the mode of the elements, should
30725 *Note RTL Classes::. Int iterators can appear in only those rtx fields
31611 Set target-dependent initial values of fields in OPTS.
31715 This macro does not affect the way structure fields are packed into
31903 'BIGGEST_ALIGNMENT' for structure and union fields only, unless the
32057 handle alignment of bit-fields and the structures that contain
32080 bit-fields may cross more than one alignment boundary. The
32084 The other known way of making bit-fields work is to define
32093 bit-fields as are used by another compiler, here is how to
32206 This target hook returns 'true' if bit-fields in the given
32220 bit-fields (that is, if its long:3, 32 bits is used in the record,
32221 and any additional adjacent long bit-fields are packed into the
32226 If both MS bit-fields and '__attribute__((packed))' are used, the
32228 on a single field when MS bit-fields are in use, it will take
34412 context with version, args_size and by_value fields. If it is
36783 fields in SIMD_CLONE structure pointed by CLONE_INFO argument and
37303 subsequent accesses occur to other fields in the same word of the
41080 control object type. TYPE is the RECORD_TYPE the fields are for
41543 On machines that have instructions that act on bit-fields at
43434 the structure that this fields points to is never defined, so long
43522 'atomic'; only fields of a struct can. This is a known limitation.
43536 The 'user' option indicates that the code to mark structure fields
43585 "kind", visiting all appropriate fields. For example, if kind is 2, it
43586 will cast to "some_other_subclass" and visit fields a, b, and c.
43644 to provide template functions to mark all the fields of the type.
43682 walker for all the fields of T. */
43696 inside fields of 'T'). In the case of 'TP<T *>', references to 'T
43796 should not be uninitialized pointer fields in the structures even if
43797 your code never reads or writes those fields at a particular instance.
43799 all the fields are initialized manually immediately after allocation.
43977 but you can also check the individual fields if you want a less strict
47136 edited only by proprietary word processors, SGML or XML for which
52453 * bit-fields: Bit-Fields. (line 6)