source: public/doc/gnu-c/Aliasing-Type-Rules.html@ 02598c2

Last change on this file since 02598c2 was 02598c2, checked in by Mikhail Kirillov <w96k@…>, on Oct 6, 2022 at 12:36:29 PM

Add gnu-c
  • Property mode set to 100644
File size: 7.4 KB
Line 
1<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
2<html>
3<!-- Copyright (C) 2022 Richard Stallman and Free Software Foundation, Inc.
4
5(The work of Trevis Rothwell and Nelson Beebe has been assigned or
6licensed to the FSF.)
7
8Permission is granted to copy, distribute and/or modify this document
9under the terms of the GNU Free Documentation License, Version 1.3 or
10any later version published by the Free Software Foundation; with the
11Invariant Sections being "GNU General Public License," with the
12Front-Cover Texts being "A GNU Manual," and with the Back-Cover
13Texts as in (a) below. A copy of the license is included in the
14section entitled "GNU Free Documentation License."
15
16(a) The FSF's Back-Cover Text is: "You have the freedom to copy and
17modify this GNU manual. Buying copies from the FSF supports it in
18developing GNU and promoting software freedom." -->
19<!-- Created by GNU Texinfo 6.7, http://www.gnu.org/software/texinfo/ -->
20<head>
21<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
22<title>Aliasing Type Rules (GNU C Language Manual)</title>
23
24<meta name="description" content="Aliasing Type Rules (GNU C Language Manual)">
25<meta name="keywords" content="Aliasing Type Rules (GNU C Language Manual)">
26<meta name="resource-type" content="document">
27<meta name="distribution" content="global">
28<meta name="Generator" content="makeinfo">
29<link href="index.html" rel="start" title="Top">
30<link href="Symbol-Index.html" rel="index" title="Symbol Index">
31<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
32<link href="Aliasing.html" rel="up" title="Aliasing">
33<link href="Digraphs.html" rel="next" title="Digraphs">
34<link href="Aliasing-Length.html" rel="prev" title="Aliasing Length">
35<style type="text/css">
36<!--
37a.summary-letter {text-decoration: none}
38blockquote.indentedblock {margin-right: 0em}
39div.display {margin-left: 3.2em}
40div.example {margin-left: 3.2em}
41div.lisp {margin-left: 3.2em}
42kbd {font-style: oblique}
43pre.display {font-family: inherit}
44pre.format {font-family: inherit}
45pre.menu-comment {font-family: serif}
46pre.menu-preformatted {font-family: serif}
47span.nolinebreak {white-space: nowrap}
48span.roman {font-family: initial; font-weight: normal}
49span.sansserif {font-family: sans-serif; font-weight: normal}
50ul.no-bullet {list-style: none}
51-->
52</style>
53
54
55</head>
56
57<body lang="en">
58<span id="Aliasing-Type-Rules"></span><div class="header">
59<p>
60Previous: <a href="Aliasing-Length.html" accesskey="p" rel="prev">Aliasing Length</a>, Up: <a href="Aliasing.html" accesskey="u" rel="up">Aliasing</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Symbol-Index.html" title="Index" rel="index">Index</a>]</p>
61</div>
62<hr>
63<span id="Type-Rules-for-Aliasing"></span><h3 class="appendixsection">B.3 Type Rules for Aliasing</h3>
64
65<p>C code that converts a pointer to a different pointer type can use the
66pointers to access the same memory locations with two different data
67types. If the same address is accessed with different types in a
68single control thread, optimization can make the code do surprising
69things (in effect, make it malfunction).
70</p>
71<p>Here&rsquo;s a concrete example where aliasing that can change the code&rsquo;s
72behavior when it is optimized. We assume that <code>float</code> is 4 bytes
73long, like <code>int</code>, and so is every pointer. Thus, the structures
74<code>struct a</code> and <code>struct b</code> are both 8 bytes.
75</p>
76<div class="example">
77<pre class="example">#include &lt;stdio.h&gt;
78struct a { int size; char *data; };
79struct b { float size; char *data; };
80
81void sub (struct a *p, struct b *q)
82{
83  int x;
84  p-&gt;size = 0;
85  q-&gt;size = 1;
86  x = p-&gt;size;
87  printf(&quot;x       =%d\n&quot;, x);
88  printf(&quot;p-&gt;size =%d\n&quot;, (int)p-&gt;size);
89  printf(&quot;q-&gt;size =%d\n&quot;, (int)q-&gt;size);
90}
91
92int main(void)
93{
94  struct a foo;
95  struct a *p = &amp;foo;
96  struct b *q = (struct b *) &amp;foo;
97
98  sub (p, q);
99}
100</pre></div>
101
102<p>This code works as intended when compiled without optimization. All
103the operations are carried out sequentially as written. The code
104sets <code>x</code> to <code>p-&gt;size</code>, but what it actually gets is the
105bits of the floating point number 1, as type <code>int</code>.
106</p>
107<p>However, when optimizing, the compiler is allowed to assume
108(mistakenly, here) that <code>q</code> does not point to the same storage as
109<code>p</code>, because their data types are not allowed to alias.
110</p>
111<p>From this assumption, the compiler can deduce (falsely, here) that the
112assignment into <code>q-&gt;size</code> has no effect on the value of
113<code>p-&gt;size</code>, which must therefore still be 0. Thus, <code>x</code> will
114be set to 0.
115</p>
116<p>GNU C, following the C standard, <em>defines</em> this optimization as
117legitimate. Code that misbehaves when optimized following these rules
118is, by definition, incorrect C code.
119</p>
120<p>The rules for storage aliasing in C are based on the two data types:
121the type of the object, and the type it is accessed through. The
122rules permit accessing part of a storage object of type <var>t</var> using
123only these types:
124</p>
125<ul>
126<li> <var>t</var>.
127
128</li><li> A type compatible with <var>t</var>. See <a href="Compatible-Types.html">Compatible Types</a>.
129
130</li><li> A signed or unsigned version of one of the above.
131
132</li><li> A qualifed version of one of the above.
133See <a href="Type-Qualifiers.html">Type Qualifiers</a>.
134
135</li><li> An array, structure (see <a href="Structures.html">Structures</a>), or union type
136(<code>Unions</code>) that contains one of the above, either directly as a
137field or through multiple levels of fields. If <var>t</var> is
138<code>double</code>, this would include <code>struct s { union { double
139d[2]; int i[4]; } u; int i; };</code> because there&rsquo;s a <code>double</code>
140inside it somewhere.
141
142</li><li> A character type.
143</li></ul>
144
145<p>What do these rules say about the example in this subsection?
146</p>
147<p>For <code>foo.size</code> (equivalently, <code>a-&gt;size</code>), <var>t</var> is
148<code>int</code>. The type <code>float</code> is not allowed as an aliasing type
149by those rules, so <code>b-&gt;size</code> is not supposed to alias with
150elements of <code>j</code>. Based on that assumption, GNU C makes a
151permitted optimization that was not, in this case, consistent with
152what the programmer intended the program to do.
153</p>
154<p>Whether GCC actually performs type-based aliasing analysis depends on
155the details of the code. GCC has other ways to determine (in some cases)
156whether objects alias, and if it gets a reliable answer that way, it won&rsquo;t
157fall back on type-based heuristics.
158</p>
159<p>The importance of knowing the type-based aliasing rules is not so as
160to ensure that the optimization is done where it would be safe, but so
161as to ensure it is <em>not</em> done in a way that would break the
162program. You can turn off type-based aliasing analysis by giving GCC
163the option <samp>-fno-strict-aliasing</samp>.
164</p>
165<hr>
166<div class="header">
167<p>
168Previous: <a href="Aliasing-Length.html" accesskey="p" rel="prev">Aliasing Length</a>, Up: <a href="Aliasing.html" accesskey="u" rel="up">Aliasing</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Symbol-Index.html" title="Index" rel="index">Index</a>]</p>
169</div>
170
171
172
173</body>
174</html>
Note: See TracBrowser for help on using the repository browser.