summaryrefslogtreecommitdiff
path: root/share/doc/gccint/Storage-Layout.html
diff options
context:
space:
mode:
authoralk3pInjection <webmaster@raspii.tech>2024-02-04 16:16:35 +0800
committeralk3pInjection <webmaster@raspii.tech>2024-02-04 16:16:35 +0800
commitabdaadbcae30fe0c9a66c7516798279fdfd97750 (patch)
tree00a54a6e25601e43876d03c1a4a12a749d4a914c /share/doc/gccint/Storage-Layout.html
Import stripped Arm GNU Toolchain 13.2.Rel1HEADumineko
https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads Change-Id: I7303388733328cd98ab9aa3c30236db67f2e9e9c
Diffstat (limited to 'share/doc/gccint/Storage-Layout.html')
-rw-r--r--share/doc/gccint/Storage-Layout.html795
1 files changed, 795 insertions, 0 deletions
diff --git a/share/doc/gccint/Storage-Layout.html b/share/doc/gccint/Storage-Layout.html
new file mode 100644
index 0000000..d94446b
--- /dev/null
+++ b/share/doc/gccint/Storage-Layout.html
@@ -0,0 +1,795 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<html>
+<!-- Copyright (C) 1988-2023 Free Software Foundation, Inc.
+
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.3 or
+any later version published by the Free Software Foundation; with the
+Invariant Sections being "Funding Free Software", the Front-Cover
+Texts being (a) (see below), and with the Back-Cover Texts being (b)
+(see below). A copy of the license is included in the section entitled
+"GNU Free Documentation License".
+
+(a) The FSF's Front-Cover Text is:
+
+A GNU Manual
+
+(b) The FSF's Back-Cover Text is:
+
+You have freedom to copy and modify this GNU Manual, like GNU
+ software. Copies published by the Free Software Foundation raise
+ funds for GNU development. -->
+<!-- Created by GNU Texinfo 5.1, http://www.gnu.org/software/texinfo/ -->
+<head>
+<title>GNU Compiler Collection (GCC) Internals: Storage Layout</title>
+
+<meta name="description" content="GNU Compiler Collection (GCC) Internals: Storage Layout">
+<meta name="keywords" content="GNU Compiler Collection (GCC) Internals: Storage Layout">
+<meta name="resource-type" content="document">
+<meta name="distribution" content="global">
+<meta name="Generator" content="makeinfo">
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+<link href="index.html#Top" rel="start" title="Top">
+<link href="Option-Index.html#Option-Index" rel="index" title="Option Index">
+<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
+<link href="Target-Macros.html#Target-Macros" rel="up" title="Target Macros">
+<link href="Type-Layout.html#Type-Layout" rel="next" title="Type Layout">
+<link href="Per_002dFunction-Data.html#Per_002dFunction-Data" rel="previous" title="Per-Function Data">
+<style type="text/css">
+<!--
+a.summary-letter {text-decoration: none}
+blockquote.smallquotation {font-size: smaller}
+div.display {margin-left: 3.2em}
+div.example {margin-left: 3.2em}
+div.indentedblock {margin-left: 3.2em}
+div.lisp {margin-left: 3.2em}
+div.smalldisplay {margin-left: 3.2em}
+div.smallexample {margin-left: 3.2em}
+div.smallindentedblock {margin-left: 3.2em; font-size: smaller}
+div.smalllisp {margin-left: 3.2em}
+kbd {font-style:oblique}
+pre.display {font-family: inherit}
+pre.format {font-family: inherit}
+pre.menu-comment {font-family: serif}
+pre.menu-preformatted {font-family: serif}
+pre.smalldisplay {font-family: inherit; font-size: smaller}
+pre.smallexample {font-size: smaller}
+pre.smallformat {font-family: inherit; font-size: smaller}
+pre.smalllisp {font-size: smaller}
+span.nocodebreak {white-space:nowrap}
+span.nolinebreak {white-space:nowrap}
+span.roman {font-family:serif; font-weight:normal}
+span.sansserif {font-family:sans-serif; font-weight:normal}
+ul.no-bullet {list-style: none}
+-->
+</style>
+
+
+</head>
+
+<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
+<a name="Storage-Layout"></a>
+<div class="header">
+<p>
+Next: <a href="Type-Layout.html#Type-Layout" accesskey="n" rel="next">Type Layout</a>, Previous: <a href="Per_002dFunction-Data.html#Per_002dFunction-Data" accesskey="p" rel="previous">Per-Function Data</a>, Up: <a href="Target-Macros.html#Target-Macros" accesskey="u" rel="up">Target Macros</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p>
+</div>
+<hr>
+<a name="Storage-Layout-1"></a>
+<h3 class="section">18.5 Storage Layout</h3>
+<a name="index-storage-layout"></a>
+
+<p>Note that the definitions of the macros in this table which are sizes or
+alignments measured in bits do not need to be constant. They can be C
+expressions that refer to static variables, such as the <code>target_flags</code>.
+See <a href="Run_002dtime-Target.html#Run_002dtime-Target">Run-time Target</a>.
+</p>
+<dl>
+<dt><a name="index-BITS_005fBIG_005fENDIAN"></a>Macro: <strong>BITS_BIG_ENDIAN</strong></dt>
+<dd><p>Define this macro to have the value 1 if the most significant bit in a
+byte has the lowest number; otherwise define it to have the value zero.
+This means that bit-field instructions count from the most significant
+bit. If the machine has no bit-field instructions, then this must still
+be defined, but it doesn&rsquo;t matter which value it is defined to. This
+macro need not be a constant.
+</p>
+<p>This macro does not affect the way structure fields are packed into
+bytes or words; that is controlled by <code>BYTES_BIG_ENDIAN</code>.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-BYTES_005fBIG_005fENDIAN"></a>Macro: <strong>BYTES_BIG_ENDIAN</strong></dt>
+<dd><p>Define this macro to have the value 1 if the most significant byte in a
+word has the lowest number. This macro need not be a constant.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-WORDS_005fBIG_005fENDIAN"></a>Macro: <strong>WORDS_BIG_ENDIAN</strong></dt>
+<dd><p>Define this macro to have the value 1 if, in a multiword object, the
+most significant word has the lowest number. This applies to both
+memory locations and registers; see <code>REG_WORDS_BIG_ENDIAN</code> if the
+order of words in memory is not the same as the order in registers. This
+macro need not be a constant.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-REG_005fWORDS_005fBIG_005fENDIAN"></a>Macro: <strong>REG_WORDS_BIG_ENDIAN</strong></dt>
+<dd><p>On some machines, the order of words in a multiword object differs between
+registers in memory. In such a situation, define this macro to describe
+the order of words in a register. The macro <code>WORDS_BIG_ENDIAN</code> controls
+the order of words in memory.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-FLOAT_005fWORDS_005fBIG_005fENDIAN"></a>Macro: <strong>FLOAT_WORDS_BIG_ENDIAN</strong></dt>
+<dd><p>Define this macro to have the value 1 if <code>DFmode</code>, <code>XFmode</code> or
+<code>TFmode</code> floating point numbers are stored in memory with the word
+containing the sign bit at the lowest address; otherwise define it to
+have the value 0. This macro need not be a constant.
+</p>
+<p>You need not define this macro if the ordering is the same as for
+multi-word integers.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-BITS_005fPER_005fWORD"></a>Macro: <strong>BITS_PER_WORD</strong></dt>
+<dd><p>Number of bits in a word. If you do not define this macro, the default
+is <code>BITS_PER_UNIT * UNITS_PER_WORD</code>.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-MAX_005fBITS_005fPER_005fWORD"></a>Macro: <strong>MAX_BITS_PER_WORD</strong></dt>
+<dd><p>Maximum number of bits in a word. If this is undefined, the default is
+<code>BITS_PER_WORD</code>. Otherwise, it is the constant value that is the
+largest value that <code>BITS_PER_WORD</code> can have at run-time.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-UNITS_005fPER_005fWORD"></a>Macro: <strong>UNITS_PER_WORD</strong></dt>
+<dd><p>Number of storage units in a word; normally the size of a general-purpose
+register, a power of two from 1 or 8.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-MIN_005fUNITS_005fPER_005fWORD"></a>Macro: <strong>MIN_UNITS_PER_WORD</strong></dt>
+<dd><p>Minimum number of units in a word. If this is undefined, the default is
+<code>UNITS_PER_WORD</code>. Otherwise, it is the constant value that is the
+smallest value that <code>UNITS_PER_WORD</code> can have at run-time.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-POINTER_005fSIZE"></a>Macro: <strong>POINTER_SIZE</strong></dt>
+<dd><p>Width of a pointer, in bits. You must specify a value no wider than the
+width of <code>Pmode</code>. If it is not equal to the width of <code>Pmode</code>,
+you must define <code>POINTERS_EXTEND_UNSIGNED</code>. If you do not specify
+a value the default is <code>BITS_PER_WORD</code>.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-POINTERS_005fEXTEND_005fUNSIGNED"></a>Macro: <strong>POINTERS_EXTEND_UNSIGNED</strong></dt>
+<dd><p>A C expression that determines how pointers should be extended from
+<code>ptr_mode</code> to either <code>Pmode</code> or <code>word_mode</code>. It is
+greater than zero if pointers should be zero-extended, zero if they
+should be sign-extended, and negative if some other sort of conversion
+is needed. In the last case, the extension is done by the target&rsquo;s
+<code>ptr_extend</code> instruction.
+</p>
+<p>You need not define this macro if the <code>ptr_mode</code>, <code>Pmode</code>
+and <code>word_mode</code> are all the same width.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-PROMOTE_005fMODE"></a>Macro: <strong>PROMOTE_MODE</strong> <em>(<var>m</var>, <var>unsignedp</var>, <var>type</var>)</em></dt>
+<dd><p>A macro to update <var>m</var> and <var>unsignedp</var> when an object whose type
+is <var>type</var> and which has the specified mode and signedness is to be
+stored in a register. This macro is only called when <var>type</var> is a
+scalar type.
+</p>
+<p>On most RISC machines, which only have operations that operate on a full
+register, define this macro to set <var>m</var> to <code>word_mode</code> if
+<var>m</var> is an integer mode narrower than <code>BITS_PER_WORD</code>. In most
+cases, only integer modes should be widened because wider-precision
+floating-point operations are usually more expensive than their narrower
+counterparts.
+</p>
+<p>For most machines, the macro definition does not change <var>unsignedp</var>.
+However, some machines, have instructions that preferentially handle
+either signed or unsigned quantities of certain modes. For example, on
+the DEC Alpha, 32-bit loads from memory and 32-bit add instructions
+sign-extend the result to 64 bits. On such machines, set
+<var>unsignedp</var> according to which kind of extension is more efficient.
+</p>
+<p>Do not define this macro if it would never modify <var>m</var>.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-TARGET_005fC_005fEXCESS_005fPRECISION"></a>Target Hook: <em>enum flt_eval_method</em> <strong>TARGET_C_EXCESS_PRECISION</strong> <em>(enum excess_precision_type <var>type</var>)</em></dt>
+<dd><p>Return a value, with the same meaning as the C99 macro
+<code>FLT_EVAL_METHOD</code> that describes which excess precision should be
+applied. <var>type</var> is either <code>EXCESS_PRECISION_TYPE_IMPLICIT</code>,
+<code>EXCESS_PRECISION_TYPE_FAST</code>,
+<code>EXCESS_PRECISION_TYPE_STANDARD</code>, or
+<code>EXCESS_PRECISION_TYPE_FLOAT16</code>. For
+<code>EXCESS_PRECISION_TYPE_IMPLICIT</code>, the target should return which
+precision and range operations will be implictly evaluated in regardless
+of the excess precision explicitly added. For
+<code>EXCESS_PRECISION_TYPE_STANDARD</code>,
+<code>EXCESS_PRECISION_TYPE_FLOAT16</code>, and
+<code>EXCESS_PRECISION_TYPE_FAST</code>, the target should return the
+explicit excess precision that should be added depending on the
+value set for <samp>-fexcess-precision=<span class="roman">[</span>standard<span class="roman">|</span>fast<span class="roman">|</span>16<span class="roman">]</span></samp>.
+Note that unpredictable explicit excess precision does not make sense,
+so a target should never return <code>FLT_EVAL_METHOD_UNPREDICTABLE</code>
+when <var>type</var> is <code>EXCESS_PRECISION_TYPE_STANDARD</code>,
+<code>EXCESS_PRECISION_TYPE_FLOAT16</code> or
+<code>EXCESS_PRECISION_TYPE_FAST</code>.
+</p></dd></dl>
+<p>Return a value, with the same meaning as the C99 macro
+<code>FLT_EVAL_METHOD</code> that describes which excess precision should be
+applied.
+</p>
+<dl>
+<dt><a name="index-TARGET_005fPROMOTE_005fFUNCTION_005fMODE"></a>Target Hook: <em>machine_mode</em> <strong>TARGET_PROMOTE_FUNCTION_MODE</strong> <em>(const_tree <var>type</var>, machine_mode <var>mode</var>, int *<var>punsignedp</var>, const_tree <var>funtype</var>, int <var>for_return</var>)</em></dt>
+<dd><p>Like <code>PROMOTE_MODE</code>, but it is applied to outgoing function arguments or
+function return values. The target hook should return the new mode
+and possibly change <code>*<var>punsignedp</var></code> if the promotion should
+change signedness. This function is called only for scalar <em>or
+pointer</em> types.
+</p>
+<p><var>for_return</var> allows to distinguish the promotion of arguments and
+return values. If it is <code>1</code>, a return value is being promoted and
+<code>TARGET_FUNCTION_VALUE</code> must perform the same promotions done here.
+If it is <code>2</code>, the returned mode should be that of the register in
+which an incoming parameter is copied, or the outgoing result is computed;
+then the hook should return the same mode as <code>promote_mode</code>, though
+the signedness may be different.
+</p>
+<p><var>type</var> can be NULL when promoting function arguments of libcalls.
+</p>
+<p>The default is to not promote arguments and return values. You can
+also define the hook to <code>default_promote_function_mode_always_promote</code>
+if you would like to apply the same rules given by <code>PROMOTE_MODE</code>.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-PARM_005fBOUNDARY"></a>Macro: <strong>PARM_BOUNDARY</strong></dt>
+<dd><p>Normal alignment required for function parameters on the stack, in
+bits. All stack parameters receive at least this much alignment
+regardless of data type. On most machines, this is the same as the
+size of an integer.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-STACK_005fBOUNDARY"></a>Macro: <strong>STACK_BOUNDARY</strong></dt>
+<dd><p>Define this macro to the minimum alignment enforced by hardware for the
+stack pointer on this machine. The definition is a C expression for the
+desired alignment (measured in bits). This value is used as a default
+if <code>PREFERRED_STACK_BOUNDARY</code> is not defined. On most machines,
+this should be the same as <code>PARM_BOUNDARY</code>.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-PREFERRED_005fSTACK_005fBOUNDARY"></a>Macro: <strong>PREFERRED_STACK_BOUNDARY</strong></dt>
+<dd><p>Define this macro if you wish to preserve a certain alignment for the
+stack pointer, greater than what the hardware enforces. The definition
+is a C expression for the desired alignment (measured in bits). This
+macro must evaluate to a value equal to or larger than
+<code>STACK_BOUNDARY</code>.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-INCOMING_005fSTACK_005fBOUNDARY"></a>Macro: <strong>INCOMING_STACK_BOUNDARY</strong></dt>
+<dd><p>Define this macro if the incoming stack boundary may be different
+from <code>PREFERRED_STACK_BOUNDARY</code>. This macro must evaluate
+to a value equal to or larger than <code>STACK_BOUNDARY</code>.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-FUNCTION_005fBOUNDARY"></a>Macro: <strong>FUNCTION_BOUNDARY</strong></dt>
+<dd><p>Alignment required for a function entry point, in bits.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-BIGGEST_005fALIGNMENT"></a>Macro: <strong>BIGGEST_ALIGNMENT</strong></dt>
+<dd><p>Biggest alignment that any data type can require on this machine, in
+bits. Note that this is not the biggest alignment that is supported,
+just the biggest alignment that, when violated, may cause a fault.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-TARGET_005fABSOLUTE_005fBIGGEST_005fALIGNMENT"></a>Target Hook: <em>HOST_WIDE_INT</em> <strong>TARGET_ABSOLUTE_BIGGEST_ALIGNMENT</strong></dt>
+<dd><p>If defined, this target hook specifies the absolute biggest alignment
+that a type or variable can have on this machine, otherwise,
+<code>BIGGEST_ALIGNMENT</code> is used.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-MALLOC_005fABI_005fALIGNMENT"></a>Macro: <strong>MALLOC_ABI_ALIGNMENT</strong></dt>
+<dd><p>Alignment, in bits, a C conformant malloc implementation has to
+provide. If not defined, the default value is <code>BITS_PER_WORD</code>.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-ATTRIBUTE_005fALIGNED_005fVALUE"></a>Macro: <strong>ATTRIBUTE_ALIGNED_VALUE</strong></dt>
+<dd><p>Alignment used by the <code>__attribute__ ((aligned))</code> construct. If
+not defined, the default value is <code>BIGGEST_ALIGNMENT</code>.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-MINIMUM_005fATOMIC_005fALIGNMENT"></a>Macro: <strong>MINIMUM_ATOMIC_ALIGNMENT</strong></dt>
+<dd><p>If defined, the smallest alignment, in bits, that can be given to an
+object that can be referenced in one operation, without disturbing any
+nearby object. Normally, this is <code>BITS_PER_UNIT</code>, but may be larger
+on machines that don&rsquo;t have byte or half-word store operations.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-BIGGEST_005fFIELD_005fALIGNMENT"></a>Macro: <strong>BIGGEST_FIELD_ALIGNMENT</strong></dt>
+<dd><p>Biggest alignment that any structure or union field can require on this
+machine, in bits. If defined, this overrides <code>BIGGEST_ALIGNMENT</code> for
+structure and union fields only, unless the field alignment has been set
+by the <code>__attribute__ ((aligned (<var>n</var>)))</code> construct.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-ADJUST_005fFIELD_005fALIGN"></a>Macro: <strong>ADJUST_FIELD_ALIGN</strong> <em>(<var>field</var>, <var>type</var>, <var>computed</var>)</em></dt>
+<dd><p>An expression for the alignment of a structure field <var>field</var> of
+type <var>type</var> if the alignment computed in the usual way (including
+applying of <code>BIGGEST_ALIGNMENT</code> and <code>BIGGEST_FIELD_ALIGNMENT</code> to the
+alignment) is <var>computed</var>. It overrides alignment only if the
+field alignment has not been set by the
+<code>__attribute__ ((aligned (<var>n</var>)))</code> construct. Note that <var>field</var>
+may be <code>NULL_TREE</code> in case we just query for the minimum alignment
+of a field of type <var>type</var> in structure context.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-MAX_005fSTACK_005fALIGNMENT"></a>Macro: <strong>MAX_STACK_ALIGNMENT</strong></dt>
+<dd><p>Biggest stack alignment guaranteed by the backend. Use this macro
+to specify the maximum alignment of a variable on stack.
+</p>
+<p>If not defined, the default value is <code>STACK_BOUNDARY</code>.
+</p>
+</dd></dl>
+
+<dl>
+<dt><a name="index-MAX_005fOFILE_005fALIGNMENT"></a>Macro: <strong>MAX_OFILE_ALIGNMENT</strong></dt>
+<dd><p>Biggest alignment supported by the object file format of this machine.
+Use this macro to limit the alignment which can be specified using the
+<code>__attribute__ ((aligned (<var>n</var>)))</code> construct for functions and
+objects with static storage duration. The alignment of automatic
+objects may exceed the object file format maximum up to the maximum
+supported by GCC. If not defined, the default value is
+<code>BIGGEST_ALIGNMENT</code>.
+</p>
+<p>On systems that use ELF, the default (in <samp>config/elfos.h</samp>) is
+the largest supported 32-bit ELF section alignment representable on
+a 32-bit host e.g. &lsquo;<samp>(((uint64_t) 1 &lt;&lt; 28) * 8)</samp>&rsquo;.
+On 32-bit ELF the largest supported section alignment in bits is
+&lsquo;<samp>(0x80000000 * 8)</samp>&rsquo;, but this is not representable on 32-bit hosts.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-TARGET_005fLOWER_005fLOCAL_005fDECL_005fALIGNMENT"></a>Target Hook: <em>void</em> <strong>TARGET_LOWER_LOCAL_DECL_ALIGNMENT</strong> <em>(tree <var>decl</var>)</em></dt>
+<dd><p>Define this hook to lower alignment of local, parm or result
+decl &lsquo;<samp>(<var>decl</var>)</samp>&rsquo;.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-TARGET_005fSTATIC_005fRTX_005fALIGNMENT"></a>Target Hook: <em>HOST_WIDE_INT</em> <strong>TARGET_STATIC_RTX_ALIGNMENT</strong> <em>(machine_mode <var>mode</var>)</em></dt>
+<dd><p>This hook returns the preferred alignment in bits for a
+statically-allocated rtx, such as a constant pool entry. <var>mode</var>
+is the mode of the rtx. The default implementation returns
+&lsquo;<samp>GET_MODE_ALIGNMENT (<var>mode</var>)</samp>&rsquo;.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-DATA_005fALIGNMENT"></a>Macro: <strong>DATA_ALIGNMENT</strong> <em>(<var>type</var>, <var>basic-align</var>)</em></dt>
+<dd><p>If defined, a C expression to compute the alignment for a variable in
+the static store. <var>type</var> is the data type, and <var>basic-align</var> is
+the alignment that the object would ordinarily have. The value of this
+macro is used instead of that alignment to align the object.
+</p>
+<p>If this macro is not defined, then <var>basic-align</var> is used.
+</p>
+<a name="index-strcpy"></a>
+<p>One use of this macro is to increase alignment of medium-size data to
+make it all fit in fewer cache lines. Another is to cause character
+arrays to be word-aligned so that <code>strcpy</code> calls that copy
+constants to character arrays can be done inline.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-DATA_005fABI_005fALIGNMENT"></a>Macro: <strong>DATA_ABI_ALIGNMENT</strong> <em>(<var>type</var>, <var>basic-align</var>)</em></dt>
+<dd><p>Similar to <code>DATA_ALIGNMENT</code>, but for the cases where the ABI mandates
+some alignment increase, instead of optimization only purposes. E.g.&nbsp;AMD x86-64 psABI says that variables with array type larger than 15 bytes
+must be aligned to 16 byte boundaries.
+</p>
+<p>If this macro is not defined, then <var>basic-align</var> is used.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-TARGET_005fCONSTANT_005fALIGNMENT"></a>Target Hook: <em>HOST_WIDE_INT</em> <strong>TARGET_CONSTANT_ALIGNMENT</strong> <em>(const_tree <var>constant</var>, HOST_WIDE_INT <var>basic_align</var>)</em></dt>
+<dd><p>This hook returns the alignment in bits of a constant that is being
+placed in memory. <var>constant</var> is the constant and <var>basic_align</var>
+is the alignment that the object would ordinarily have.
+</p>
+<p>The default definition just returns <var>basic_align</var>.
+</p>
+<p>The typical use of this hook is to increase alignment for string
+constants to be word aligned so that <code>strcpy</code> calls that copy
+constants can be done inline. The function
+<code>constant_alignment_word_strings</code> provides such a definition.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-LOCAL_005fALIGNMENT"></a>Macro: <strong>LOCAL_ALIGNMENT</strong> <em>(<var>type</var>, <var>basic-align</var>)</em></dt>
+<dd><p>If defined, a C expression to compute the alignment for a variable in
+the local store. <var>type</var> is the data type, and <var>basic-align</var> is
+the alignment that the object would ordinarily have. The value of this
+macro is used instead of that alignment to align the object.
+</p>
+<p>If this macro is not defined, then <var>basic-align</var> is used.
+</p>
+<p>One use of this macro is to increase alignment of medium-size data to
+make it all fit in fewer cache lines.
+</p>
+<p>If the value of this macro has a type, it should be an unsigned type.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-TARGET_005fVECTOR_005fALIGNMENT"></a>Target Hook: <em>HOST_WIDE_INT</em> <strong>TARGET_VECTOR_ALIGNMENT</strong> <em>(const_tree <var>type</var>)</em></dt>
+<dd><p>This hook can be used to define the alignment for a vector of type
+<var>type</var>, in order to comply with a platform ABI. The default is to
+require natural alignment for vector types. The alignment returned by
+this hook must be a power-of-two multiple of the default alignment of
+the vector element type.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-STACK_005fSLOT_005fALIGNMENT"></a>Macro: <strong>STACK_SLOT_ALIGNMENT</strong> <em>(<var>type</var>, <var>mode</var>, <var>basic-align</var>)</em></dt>
+<dd><p>If defined, a C expression to compute the alignment for stack slot.
+<var>type</var> is the data type, <var>mode</var> is the widest mode available,
+and <var>basic-align</var> is the alignment that the slot would ordinarily
+have. The value of this macro is used instead of that alignment to
+align the slot.
+</p>
+<p>If this macro is not defined, then <var>basic-align</var> is used when
+<var>type</var> is <code>NULL</code>. Otherwise, <code>LOCAL_ALIGNMENT</code> will
+be used.
+</p>
+<p>This macro is to set alignment of stack slot to the maximum alignment
+of all possible modes which the slot may have.
+</p>
+<p>If the value of this macro has a type, it should be an unsigned type.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-LOCAL_005fDECL_005fALIGNMENT"></a>Macro: <strong>LOCAL_DECL_ALIGNMENT</strong> <em>(<var>decl</var>)</em></dt>
+<dd><p>If defined, a C expression to compute the alignment for a local
+variable <var>decl</var>.
+</p>
+<p>If this macro is not defined, then
+<code>LOCAL_ALIGNMENT (TREE_TYPE (<var>decl</var>), DECL_ALIGN (<var>decl</var>))</code>
+is used.
+</p>
+<p>One use of this macro is to increase alignment of medium-size data to
+make it all fit in fewer cache lines.
+</p>
+<p>If the value of this macro has a type, it should be an unsigned type.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-MINIMUM_005fALIGNMENT"></a>Macro: <strong>MINIMUM_ALIGNMENT</strong> <em>(<var>exp</var>, <var>mode</var>, <var>align</var>)</em></dt>
+<dd><p>If defined, a C expression to compute the minimum required alignment
+for dynamic stack realignment purposes for <var>exp</var> (a type or decl),
+<var>mode</var>, assuming normal alignment <var>align</var>.
+</p>
+<p>If this macro is not defined, then <var>align</var> will be used.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-EMPTY_005fFIELD_005fBOUNDARY"></a>Macro: <strong>EMPTY_FIELD_BOUNDARY</strong></dt>
+<dd><p>Alignment in bits to be given to a structure bit-field that follows an
+empty field such as <code>int : 0;</code>.
+</p>
+<p>If <code>PCC_BITFIELD_TYPE_MATTERS</code> is true, it overrides this macro.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-STRUCTURE_005fSIZE_005fBOUNDARY"></a>Macro: <strong>STRUCTURE_SIZE_BOUNDARY</strong></dt>
+<dd><p>Number of bits which any structure or union&rsquo;s size must be a multiple of.
+Each structure or union&rsquo;s size is rounded up to a multiple of this.
+</p>
+<p>If you do not define this macro, the default is the same as
+<code>BITS_PER_UNIT</code>.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-STRICT_005fALIGNMENT"></a>Macro: <strong>STRICT_ALIGNMENT</strong></dt>
+<dd><p>Define this macro to be the value 1 if instructions will fail to work
+if given data not on the nominal alignment. If instructions will merely
+go slower in that case, define this macro as 0.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-PCC_005fBITFIELD_005fTYPE_005fMATTERS"></a>Macro: <strong>PCC_BITFIELD_TYPE_MATTERS</strong></dt>
+<dd><p>Define this if you wish to imitate the way many other C compilers handle
+alignment of bit-fields and the structures that contain them.
+</p>
+<p>The behavior is that the type written for a named bit-field (<code>int</code>,
+<code>short</code>, or other integer type) imposes an alignment for the entire
+structure, as if the structure really did contain an ordinary field of
+that type. In addition, the bit-field is placed within the structure so
+that it would fit within such a field, not crossing a boundary for it.
+</p>
+<p>Thus, on most machines, a named bit-field whose type is written as
+<code>int</code> would not cross a four-byte boundary, and would force
+four-byte alignment for the whole structure. (The alignment used may
+not be four bytes; it is controlled by the other alignment parameters.)
+</p>
+<p>An unnamed bit-field will not affect the alignment of the containing
+structure.
+</p>
+<p>If the macro is defined, its definition should be a C expression;
+a nonzero value for the expression enables this behavior.
+</p>
+<p>Note that if this macro is not defined, or its value is zero, some
+bit-fields may cross more than one alignment boundary. The compiler can
+support such references if there are &lsquo;<samp>insv</samp>&rsquo;, &lsquo;<samp>extv</samp>&rsquo;, and
+&lsquo;<samp>extzv</samp>&rsquo; insns that can directly reference memory.
+</p>
+<p>The other known way of making bit-fields work is to define
+<code>STRUCTURE_SIZE_BOUNDARY</code> as large as <code>BIGGEST_ALIGNMENT</code>.
+Then every structure can be accessed with fullwords.
+</p>
+<p>Unless the machine has bit-field instructions or you define
+<code>STRUCTURE_SIZE_BOUNDARY</code> that way, you must define
+<code>PCC_BITFIELD_TYPE_MATTERS</code> to have a nonzero value.
+</p>
+<p>If your aim is to make GCC use the same conventions for laying out
+bit-fields as are used by another compiler, here is how to investigate
+what the other compiler does. Compile and run this program:
+</p>
+<div class="smallexample">
+<pre class="smallexample">struct foo1
+{
+ char x;
+ char :0;
+ char y;
+};
+
+struct foo2
+{
+ char x;
+ int :0;
+ char y;
+};
+
+main ()
+{
+ printf (&quot;Size of foo1 is %d\n&quot;,
+ sizeof (struct foo1));
+ printf (&quot;Size of foo2 is %d\n&quot;,
+ sizeof (struct foo2));
+ exit (0);
+}
+</pre></div>
+
+<p>If this prints 2 and 5, then the compiler&rsquo;s behavior is what you would
+get from <code>PCC_BITFIELD_TYPE_MATTERS</code>.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-BITFIELD_005fNBYTES_005fLIMITED"></a>Macro: <strong>BITFIELD_NBYTES_LIMITED</strong></dt>
+<dd><p>Like <code>PCC_BITFIELD_TYPE_MATTERS</code> except that its effect is limited
+to aligning a bit-field within the structure.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-TARGET_005fALIGN_005fANON_005fBITFIELD"></a>Target Hook: <em>bool</em> <strong>TARGET_ALIGN_ANON_BITFIELD</strong> <em>(void)</em></dt>
+<dd><p>When <code>PCC_BITFIELD_TYPE_MATTERS</code> is true this hook will determine
+whether unnamed bitfields affect the alignment of the containing
+structure. The hook should return true if the structure should inherit
+the alignment requirements of an unnamed bitfield&rsquo;s type.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-TARGET_005fNARROW_005fVOLATILE_005fBITFIELD"></a>Target Hook: <em>bool</em> <strong>TARGET_NARROW_VOLATILE_BITFIELD</strong> <em>(void)</em></dt>
+<dd><p>This target hook should return <code>true</code> if accesses to volatile bitfields
+should use the narrowest mode possible. It should return <code>false</code> if
+these accesses should use the bitfield container type.
+</p>
+<p>The default is <code>false</code>.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-TARGET_005fMEMBER_005fTYPE_005fFORCES_005fBLK"></a>Target Hook: <em>bool</em> <strong>TARGET_MEMBER_TYPE_FORCES_BLK</strong> <em>(const_tree <var>field</var>, machine_mode <var>mode</var>)</em></dt>
+<dd><p>Return true if a structure, union or array containing <var>field</var> should
+be accessed using <code>BLKMODE</code>.
+</p>
+<p>If <var>field</var> is the only field in the structure, <var>mode</var> is its
+mode, otherwise <var>mode</var> is VOIDmode. <var>mode</var> is provided in the
+case where structures of one field would require the structure&rsquo;s mode to
+retain the field&rsquo;s mode.
+</p>
+<p>Normally, this is not needed.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-ROUND_005fTYPE_005fALIGN"></a>Macro: <strong>ROUND_TYPE_ALIGN</strong> <em>(<var>type</var>, <var>computed</var>, <var>specified</var>)</em></dt>
+<dd><p>Define this macro as an expression for the alignment of a type (given
+by <var>type</var> as a tree node) if the alignment computed in the usual
+way is <var>computed</var> and the alignment explicitly specified was
+<var>specified</var>.
+</p>
+<p>The default is to use <var>specified</var> if it is larger; otherwise, use
+the smaller of <var>computed</var> and <code>BIGGEST_ALIGNMENT</code>
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-MAX_005fFIXED_005fMODE_005fSIZE"></a>Macro: <strong>MAX_FIXED_MODE_SIZE</strong></dt>
+<dd><p>An integer expression for the size in bits of the largest integer
+machine mode that should actually be used. All integer machine modes of
+this size or smaller can be used for structures and unions with the
+appropriate sizes. If this macro is undefined, <code>GET_MODE_BITSIZE
+(DImode)</code> is assumed.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-STACK_005fSAVEAREA_005fMODE"></a>Macro: <strong>STACK_SAVEAREA_MODE</strong> <em>(<var>save_level</var>)</em></dt>
+<dd><p>If defined, an expression of type <code>machine_mode</code> that
+specifies the mode of the save area operand of a
+<code>save_stack_<var>level</var></code> named pattern (see <a href="Standard-Names.html#Standard-Names">Standard Names</a>).
+<var>save_level</var> is one of <code>SAVE_BLOCK</code>, <code>SAVE_FUNCTION</code>, or
+<code>SAVE_NONLOCAL</code> and selects which of the three named patterns is
+having its mode specified.
+</p>
+<p>You need not define this macro if it always returns <code>Pmode</code>. You
+would most commonly define this macro if the
+<code>save_stack_<var>level</var></code> patterns need to support both a 32- and a
+64-bit mode.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-STACK_005fSIZE_005fMODE"></a>Macro: <strong>STACK_SIZE_MODE</strong></dt>
+<dd><p>If defined, an expression of type <code>machine_mode</code> that
+specifies the mode of the size increment operand of an
+<code>allocate_stack</code> named pattern (see <a href="Standard-Names.html#Standard-Names">Standard Names</a>).
+</p>
+<p>You need not define this macro if it always returns <code>word_mode</code>.
+You would most commonly define this macro if the <code>allocate_stack</code>
+pattern needs to support both a 32- and a 64-bit mode.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-TARGET_005fLIBGCC_005fCMP_005fRETURN_005fMODE"></a>Target Hook: <em>scalar_int_mode</em> <strong>TARGET_LIBGCC_CMP_RETURN_MODE</strong> <em>(void)</em></dt>
+<dd><p>This target hook should return the mode to be used for the return value
+of compare instructions expanded to libgcc calls. If not defined
+<code>word_mode</code> is returned which is the right choice for a majority of
+targets.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-TARGET_005fLIBGCC_005fSHIFT_005fCOUNT_005fMODE"></a>Target Hook: <em>scalar_int_mode</em> <strong>TARGET_LIBGCC_SHIFT_COUNT_MODE</strong> <em>(void)</em></dt>
+<dd><p>This target hook should return the mode to be used for the shift count operand
+of shift instructions expanded to libgcc calls. If not defined
+<code>word_mode</code> is returned which is the right choice for a majority of
+targets.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-TARGET_005fUNWIND_005fWORD_005fMODE"></a>Target Hook: <em>scalar_int_mode</em> <strong>TARGET_UNWIND_WORD_MODE</strong> <em>(void)</em></dt>
+<dd><p>Return machine mode to be used for <code>_Unwind_Word</code> type.
+The default is to use <code>word_mode</code>.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-TARGET_005fMS_005fBITFIELD_005fLAYOUT_005fP"></a>Target Hook: <em>bool</em> <strong>TARGET_MS_BITFIELD_LAYOUT_P</strong> <em>(const_tree <var>record_type</var>)</em></dt>
+<dd><p>This target hook returns <code>true</code> if bit-fields in the given
+<var>record_type</var> are to be laid out following the rules of Microsoft
+Visual C/C++, namely: (i) a bit-field won&rsquo;t share the same storage
+unit with the previous bit-field if their underlying types have
+different sizes, and the bit-field will be aligned to the highest
+alignment of the underlying types of itself and of the previous
+bit-field; (ii) a zero-sized bit-field will affect the alignment of
+the whole enclosing structure, even if it is unnamed; except that
+(iii) a zero-sized bit-field will be disregarded unless it follows
+another bit-field of nonzero size. If this hook returns <code>true</code>,
+other macros that control bit-field layout are ignored.
+</p>
+<p>When a bit-field is inserted into a packed record, the whole size
+of the underlying type is used by one or more same-size adjacent
+bit-fields (that is, if its long:3, 32 bits is used in the record,
+and any additional adjacent long bit-fields are packed into the same
+chunk of 32 bits. However, if the size changes, a new field of that
+size is allocated). In an unpacked record, this is the same as using
+alignment, but not equivalent when packing.
+</p>
+<p>If both MS bit-fields and &lsquo;<samp>__attribute__((packed))</samp>&rsquo; are used,
+the latter will take precedence. If &lsquo;<samp>__attribute__((packed))</samp>&rsquo; is
+used on a single field when MS bit-fields are in use, it will take
+precedence for that field, but the alignment of the rest of the structure
+may affect its placement.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-TARGET_005fDECIMAL_005fFLOAT_005fSUPPORTED_005fP"></a>Target Hook: <em>bool</em> <strong>TARGET_DECIMAL_FLOAT_SUPPORTED_P</strong> <em>(void)</em></dt>
+<dd><p>Returns true if the target supports decimal floating point.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-TARGET_005fFIXED_005fPOINT_005fSUPPORTED_005fP"></a>Target Hook: <em>bool</em> <strong>TARGET_FIXED_POINT_SUPPORTED_P</strong> <em>(void)</em></dt>
+<dd><p>Returns true if the target supports fixed-point arithmetic.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-TARGET_005fEXPAND_005fTO_005fRTL_005fHOOK"></a>Target Hook: <em>void</em> <strong>TARGET_EXPAND_TO_RTL_HOOK</strong> <em>(void)</em></dt>
+<dd><p>This hook is called just before expansion into rtl, allowing the target
+to perform additional initializations or analysis before the expansion.
+For example, the rs6000 port uses it to allocate a scratch stack slot
+for use in copying SDmode values between memory and floating point
+registers whenever the function being expanded has any SDmode
+usage.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-TARGET_005fINSTANTIATE_005fDECLS"></a>Target Hook: <em>void</em> <strong>TARGET_INSTANTIATE_DECLS</strong> <em>(void)</em></dt>
+<dd><p>This hook allows the backend to perform additional instantiations on rtl
+that are not actually in any insns yet, but will be later.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-TARGET_005fMANGLE_005fTYPE"></a>Target Hook: <em>const char *</em> <strong>TARGET_MANGLE_TYPE</strong> <em>(const_tree <var>type</var>)</em></dt>
+<dd><p>If your target defines any fundamental types, or any types your target
+uses should be mangled differently from the default, define this hook
+to return the appropriate encoding for these types as part of a C++
+mangled name. The <var>type</var> argument is the tree structure representing
+the type to be mangled. The hook may be applied to trees which are
+not target-specific fundamental types; it should return <code>NULL</code>
+for all such types, as well as arguments it does not recognize. If the
+return value is not <code>NULL</code>, it must point to a statically-allocated
+string constant.
+</p>
+<p>Target-specific fundamental types might be new fundamental types or
+qualified versions of ordinary fundamental types. Encode new
+fundamental types as &lsquo;<samp>u&nbsp;<var>n</var>&nbsp;<var>name</var><!-- /@w --></samp>&rsquo;, where <var>name</var>
+is the name used for the type in source code, and <var>n</var> is the
+length of <var>name</var> in decimal. Encode qualified versions of
+ordinary types as &lsquo;<samp>U&nbsp;<var>n</var>&nbsp;<var>name</var>&nbsp;<var>code</var><!-- /@w --></samp>&rsquo;, where
+<var>name</var> is the name used for the type qualifier in source code,
+<var>n</var> is the length of <var>name</var> as above, and <var>code</var> is the
+code used to represent the unqualified version of this type. (See
+<code>write_builtin_type</code> in <samp>cp/mangle.cc</samp> for the list of
+codes.) In both cases the spaces are for clarity; do not include any
+spaces in your string.
+</p>
+<p>This hook is applied to types prior to typedef resolution. If the mangled
+name for a particular type depends only on that type&rsquo;s main variant, you
+can perform typedef resolution yourself using <code>TYPE_MAIN_VARIANT</code>
+before mangling.
+</p>
+<p>The default version of this hook always returns <code>NULL</code>, which is
+appropriate for a target that does not define any new fundamental
+types.
+</p></dd></dl>
+
+<dl>
+<dt><a name="index-TARGET_005fEMIT_005fSUPPORT_005fTINFOS"></a>Target Hook: <em>void</em> <strong>TARGET_EMIT_SUPPORT_TINFOS</strong> <em>(emit_support_tinfos_callback <var>callback</var>)</em></dt>
+<dd><p>If your target defines any fundamental types which depend on ISA flags,
+they might need C++ tinfo symbols in libsupc++/libstdc++ regardless of
+ISA flags the library is compiled with.
+This hook allows creating tinfo symbols even for those cases, by temporarily
+creating each corresponding fundamental type trees, calling the
+<var>callback</var> function on it and setting the type back to <code>nullptr</code>.
+</p></dd></dl>
+
+<hr>
+<div class="header">
+<p>
+Next: <a href="Type-Layout.html#Type-Layout" accesskey="n" rel="next">Type Layout</a>, Previous: <a href="Per_002dFunction-Data.html#Per_002dFunction-Data" accesskey="p" rel="previous">Per-Function Data</a>, Up: <a href="Target-Macros.html#Target-Macros" accesskey="u" rel="up">Target Macros</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p>
+</div>
+
+
+
+</body>
+</html>