回答編集履歴
4
fix c
test
CHANGED
|
@@ -80,7 +80,7 @@
|
|
|
80
80
|
|
|
81
81
|
struct S {
|
|
82
82
|
|
|
83
|
-
double b
|
|
83
|
+
double b;
|
|
84
84
|
|
|
85
85
|
int i;
|
|
86
86
|
|
|
@@ -96,7 +96,7 @@
|
|
|
96
96
|
|
|
97
97
|
// 下記の処理によりメモリ位置*aが書き換わる可能性がある
|
|
98
98
|
|
|
99
|
-
S t = { 3.14, 42 };
|
|
99
|
+
struct S t = { 3.14, 42 };
|
|
100
100
|
|
|
101
101
|
*s = t;
|
|
102
102
|
|
3
fix
test
CHANGED
|
@@ -6,7 +6,7 @@
|
|
|
6
6
|
|
|
7
7
|
|
|
8
8
|
|
|
9
|
-
"Strict Aliasing Rules"の本題は、Cコンパイラは「変数型が異なる場合は、互いにエイリアス(別名)となっている可能性を
|
|
9
|
+
"Strict Aliasing Rules"の本題は、Cコンパイラは「変数型が異なる場合は、互いにエイリアス(別名)となっている可能性を排除して良く」、「エイリアス不在を前提とした生成コード最適化をして良い」というものです。"Strict(厳密な)"とは、コンパイラ視点からは「型に互換性がある場合は、互いにエイリアス(別名)の**可能性を考慮すべき**」、プログラマ視点からは「互換性のない型でエイリアスを**作ってはいけない**」というニュアンスから来ています。
|
|
10
10
|
|
|
11
11
|
|
|
12
12
|
|
|
@@ -18,7 +18,7 @@
|
|
|
18
18
|
|
|
19
19
|
|
|
20
20
|
|
|
21
|
-
上記5つのルールは、"Strict Aliasing Rules"の**例外事項**を規定しています。例えば5番目「文字型(a character type)」は、基本ルール
|
|
21
|
+
上記5つのルールは、"Strict Aliasing Rules"の**例外事項**を規定しています。例えば5番目「文字型(a character type)」は、基本ルールに従うと`int`型と`char`型は互換性のない型なので互いにエイリアスであってはいけないが、例外規定により「エイリアスになり得ると考慮すべき（コンパイラ視点）」「エイリアスを作っても良い（プログラマ視点）」という意味です。
|
|
22
22
|
|
|
23
23
|
|
|
24
24
|
|
|
@@ -53,8 +53,6 @@
|
|
|
53
53
|
}
|
|
54
54
|
|
|
55
55
|
```
|
|
56
|
-
|
|
57
|
-
|
|
58
56
|
|
|
59
57
|
|
|
60
58
|
|
|
@@ -100,7 +98,7 @@
|
|
|
100
98
|
|
|
101
99
|
S t = { 3.14, 42 };
|
|
102
100
|
|
|
103
|
-
s = t;
|
|
101
|
+
*s = t;
|
|
104
102
|
|
|
105
103
|
// つまり下記処理では改めてメモリ位置*aから値を読み込まなければならない。
|
|
106
104
|
|
|
@@ -126,4 +124,4 @@
|
|
|
126
124
|
|
|
127
125
|
|
|
128
126
|
|
|
129
|
-
善意的に解釈すればプログラマに優しく、悪意を持って解釈すれば性能が劣るコンパイラということになります。しかし、"Strict Aliasing Rules"を厳密に守っているプログラムはほとんど存在せず（たぶん）、積極的な最適化はしばしばトラブルの元になります。C言語仕様で規定する以上「Cコンパイラが正しくプログラムが誤っている」のですが、現実的には"Strict Aliasing Rules"に基づいた最適化を無効化して運用されることが多いようです。
|
|
127
|
+
善意的に解釈すればプログラマに優しく、悪意を持って解釈すれば最適化性能が劣るコンパイラということになります。しかし、"Strict Aliasing Rules"を厳密に守っているプログラムはほとんど存在せず（たぶん）、積極的な最適化はしばしばトラブルの元になります。C言語仕様で規定する以上「Cコンパイラが正しくプログラムが誤っている」のですが、現実的には"Strict Aliasing Rules"に基づいた最適化を無効化して運用されることが多いようです。GCC、Clangでは`-fno-strict-aliasing`オプションが用いられます。
|
2
refine
test
CHANGED
|
@@ -78,7 +78,7 @@
|
|
|
78
78
|
|
|
79
79
|
```c
|
|
80
80
|
|
|
81
|
-
// int型を含む集成体型は...
|
|
81
|
+
// int型を含む集成体(struct)型は...
|
|
82
82
|
|
|
83
83
|
struct S {
|
|
84
84
|
|
|
@@ -96,9 +96,11 @@
|
|
|
96
96
|
|
|
97
97
|
*a = 0;
|
|
98
98
|
|
|
99
|
-
// 下記の処理
|
|
99
|
+
// 下記の処理によりメモリ位置*aが書き換わる可能性がある
|
|
100
100
|
|
|
101
|
+
S t = { 3.14, 42 };
|
|
102
|
+
|
|
101
|
-
s
|
|
103
|
+
s = t;
|
|
102
104
|
|
|
103
105
|
// つまり下記処理では改めてメモリ位置*aから値を読み込まなければならない。
|
|
104
106
|
|
1
update
test
CHANGED
|
@@ -48,7 +48,7 @@
|
|
|
48
48
|
|
|
49
49
|
printf("%d", *a);
|
|
50
50
|
|
|
51
|
-
//
|
|
51
|
+
// コンパイラは↑をprintf("%d", 0);やprintf("0");に最適化しても良い。
|
|
52
52
|
|
|
53
53
|
}
|
|
54
54
|
|
|
@@ -107,3 +107,21 @@
|
|
|
107
107
|
}
|
|
108
108
|
|
|
109
109
|
```
|
|
110
|
+
|
|
111
|
+
|
|
112
|
+
|
|
113
|
+
----
|
|
114
|
+
|
|
115
|
+
|
|
116
|
+
|
|
117
|
+
> visual studio C++ が strict aliasing rules をサポートしているのかについて調査をしてみたのですが、そのようなものは見つかりませんでした。
|
|
118
|
+
|
|
119
|
+
> もしかしたらそもそもサポートしていないのではないのかと思いました。
|
|
120
|
+
|
|
121
|
+
|
|
122
|
+
|
|
123
|
+
コンパイラが"Strict Aliasing Rules"をサポートするとは、前掲のように「型情報に基づいた積極的コード生成最適化を行う」という意味です。最新のVisualC++事情までは把握していませんが、私が知る限りはVisual C++はこのような積極的な**最適化を行いません**。なお、GCCやClangは積極的な最適化をサポートします。
|
|
124
|
+
|
|
125
|
+
|
|
126
|
+
|
|
127
|
+
善意的に解釈すればプログラマに優しく、悪意を持って解釈すれば性能が劣るコンパイラということになります。しかし、"Strict Aliasing Rules"を厳密に守っているプログラムはほとんど存在せず（たぶん）、積極的な最適化はしばしばトラブルの元になります。C言語仕様で規定する以上「Cコンパイラが正しくプログラムが誤っている」のですが、現実的には"Strict Aliasing Rules"に基づいた最適化を無効化して運用されることが多いようです。
|