1.
Q. コンパイラをサイレントインストールする方法について A.
コンパイラのサイレントインストールがうまくいかない場合、 start /wait msiexec /qn /i nintendo.msi /l*v nintendo_install.log EULA=1 [オプションについて] /qn: quiet install mode /i: install /l*v log all the information EULA=1 accepting EULA from command line |
2.
Q. コンパイラが C9932E / C9558E エラーを返すときの対応について Error: C9932E: Cannot obtain license for Compiler (feature besp_compiler_00) with license version >= 4.0 System clock has been set back・ARMCC 5.04(build 146 以降) Error: C9558E: System clock tampering detected. License checkout will fail. Error: C9555E: License checkout for feature bsp_compiler5 with version 5.0201505 has been denied by Flex back-end. Error code: -1004なお、コンパイラ以外の ARM ツールでは、メッセージ番号の最初の一文字が変わります。 (例:リンカでは L9932E / L9558E / L9555E エラーになります。) A.
コンパイラのライセンスファイルチェックでは、ランダムに PC 上のファイルをチェックしており、 $ cd /cygdrive/c $ find -type f -mmin -1 -exec touch {} \; $ find -type f -amin -1 -exec touch {} \;また、RVCT 4.0 / ARMCC4.1 / ARMCC5.03 / ARMCC 5.04(build 166 以前)には、Timezone が +1~+12 の PCで、 1970/1/2 以前のタイムスタンプのファイルを不正なファイルとして誤検出する不具合があります。 上記のコマンドで問題が解決しない場合は、以下のコマンドも試してください。 $ cd /cygdrive/c $ find -type f -mtime +16425 -exec touch {} \; $ find -type f -atime +16425 -exec touch {} \;コマンドの実行対象は、環境変数 %SystemDrive% 及び %TEMP% で指定されているドライブ(パス)です。 通常は C ドライブですが、C ドライブ以外に変更している場合は指定しているドライブで実行してください。 なお、ファイルのチェックはごみ箱の中身も対象となっているため、 上記のチェックで問題が解決しない場合、ごみ箱を空にして試してください。 |
3.
Q. atan2f() を atan2f(0.f, 0.f) として呼んだ場合の挙動についてatan2f() を、atan2f(0.f, 0.f) として呼んだ場合、CTR の開発環境(RVCT4.0)では NaN が返されますが、本来は0.0が返されるべきではないでしょうか? A.
ISO 仕様では、上記関数で範囲外の引数が与えられた場合の挙動は |
4.
Q. すべてのwarningをerrorにする方法について A.
コマンドラインオプションに--diag_error=warningを追加すると、 |
5.
Q. --fpmode=fast 指定時に非有限値を扱うことができません A.
--fpmode=fast 指定時には、IEEEで規定されている非有限値の取り扱いは完全に対応しておらず、 |
6.
Q. --enum_is_int を指定してアプリケーションをビルドできません A.
CTR-SDKは --enum_is_int を無効にしてビルドされています。 |
7.
Q. 最適化に関する不具合への対策について A.
現状、-O3 -Otimeの組み合わせで使用した際に不具合が発生するケースが多いようです。 対策としては、下記の方法があります。 ■不正なコードを生成する関数を特定できていない場合 ・ソースコードの先頭に以下の記述を追加し、ソースコードの最適化レベルを変更する。 #pragma Ospace ・特定の最適化レベルが指定されたときのみ最適化レベルを変更する。 #if __OPTIMISE_LEVEL == 3 #ifdef __OPTIMISE_TIME #pragma Ospace #endif #endif ■不正なコードを生成する関数が特定できている場合 ・特定の関数だけの最適化レベルを変更する。 #pragma push #pragma Ospace void foo() { ... } #pragma pop ・-O3 -Otimeで有効になるループ最適化機能のみを無効にする。 #pragma push #pragma Ono_vast void foo() { ... } #pragma pop ※この Ono_vast オプションは、ドキュメント化していない非公開のオプションですが、 この指定でループ最適化機能だけを無効にすることが出来ます。 |
8.
Q. std::bitsetでto_string関数を使うとコンパイルエラーが発生します 下記のようなコードをコンパイルすると、(a)の箇所でコンパイルエラーになります。 std::string foo() { std::bitset<10> bits = 100; std::string str = bits.to_string(); // ---(a) return str; } A. C++標準のライブラリ仕様では、to_stringはテンプレートメンバ関数を 使用するものが定義されているため、本症状は仕様となります。
正しい呼び出し方法は下記の通りとなります。
また、非推奨ではありますが、_RWSTD_NO_MEMBER_TEMPLATES をマクロ名としてコンパイラに渡すことで、
使用例: armcc -c test.cpp -D_RWSTD_NO_MEMBER_TEMPLATES |
9.
Q. 先行宣言と実際の宣言で、クラスと構造体を間違えてもコンパイルエラーにならない A. 上記はコンパイラの仕様となります。
C++における struct と class の違いは、デフォルトのアクセス指定だけのため、 |
10.
Q. プリコンパイルヘッダ使用時にコンパイラが出力するメッセージを非表示にする方法について A. --no_pch_messagesコマンドを追加することで、プリコンパイルヘッダ関連のメッセージを抑止することができます。 |
11.
Q. テンプレート関数からstaticな関数を呼んだ場合に、コンパイルエラーが発生します A. C++標準の[14.6.4.2]で定義されている依存名のルックアップ手続きに従い、外部リンケージを持つ 名前だけがルックアップの対象となっているためで、仕様となります。 ttp://www.csci.csusb.edu/dick/c++std/cd2/template.html#temp.dep.candidate
なお、RVCTには、依存名に関して GCC や VC++ と同等の振る舞いを行う--no_dep_name オプションがあります。 |
12.
Q. C形式のソースからバイナリファイルを生成する方法について C形式のソースファイルからarmcc、armlinkを使用してaxfを作成し、fromelfでバイナリファイルを 作成したいのですが、リンク時にL6048Uのエラーが出ます。 A.
RVCT4.0 20100909版より、ライセンス保護の仕組み上、上記のような使い方ができないようになりました。 |
13.
Q. --gnu 指定時に警告メッセージ #94 「配列のサイズはゼロより大きくする必要があります」 を表示する方法について A. --gnu 指定時に警告メッセージ #94 を表示することは出来ません。 |
14.
Q. 浮動小数点数から整数への暗黙的なキャストが行われた際に警告を出す方法について A.
現在のコンパイラではこのような機能はありません。 |
15.
Q. 構造体を含む構造体配列で、本来最適化によって呼ばれるべきではないaeabi_vec_ctor_nocookie_nodotrが呼び出されています
下記のようなコードで、デフォルトコンストラクタを定義すると、コンストラクタが本来最適化されてなくなるはずが、
デフォルトコンストラクタを定義しなければ、この症状は発生しません。 struct Point { int x; int y; int z; // Comment this out in order to see "inlined" version Point() {} }; struct Line { Point ends[2]; }; extern "C" void nnMain() { Line lines[10] __attribute__((unused)); while(1){} } A.
現状のコンパイラでは、そのような最適化を行っていません。 |
16.
Q. メンバ変数と同じ名前のオート変数を定義したときに警告を出す方法について A. 現状では警告を出すことはできません。 機能追加について検討を行いましたが、変更の予定はありません。 |
17.
Q. --ltcgオプションの使用方法について A.
現状--ltcgオプションを使用することはできません。 --multifile機能を使用することで、同等のことを実現することができます。 |
18.
Q. VFP ベクタモードの使用可否について A.
VFP ベクタモードは使用していただいて問題ありません。 |
19.
Q. --fpmode=ieee_no_fenv オプションを使用したときの例外に関する挙動について
コンパイラリファレンスガイドには、--fpmode=ieee_no_fenv を使用すると例外が発生されない、と書かれていますが、 A. CTR-SDK では --fpmode=fast の指定が必須であり、--fpmode=ieee_no_fenv 指定時の動作はサポートしていません。 なお、コンパイラのマニュアルに記載されているとおり、--fpmode=ieee_no_fenv 指定時には、下記の例外は発生しなくなります。
Signal NaN, Quiet NaNが演算で使用された場合の挙動は、テクニカルリファレンスマニュアルの
--fpmode=ieee_no_fenv を使用した場合、デフォルト NaN モードはオフになるため、例えば FCMPE 命令(VCMPE と等価です)で
一方、--fpmode=fast または --fpmode=std の場合は、_fp_init でデフォルト NaN モードをオンに設定するライブラリが
--fpmode=fast と --fpmode=ieee_* でコンパイルされたオブジェクトが混在する場合には、
上記理由により、--fpmode=ieee_no_fenv を CTR 環境で使用した場合には、VFP 初期化部分でデフォルト NaN モードが |
20.
Q. ビルド時に #1620-D: Internal fault: translation failed. Please contact your supplier (ipa_nfuncs) というエラーが出る A. この内部エラー表示は実際には、診断メッセージが出力した 'internal fault' 文字列であり、エラーではありません。
このメッセージは、--remarks オプションにより発生し、なぜ各種最適化が失敗したかを表示しています。 |
21.
Q. Releaseビルド時に、thisポインタの NULL チェックを行うコードが生成されません A.
this ポインタが NULL の状態で、メンバ関数を呼び出した際の実装は未定義です。
コマンドラインオプション --allow_null_this を使うことで、this ポインタの NULL チェックを有効にし、 |
22.
Q. オブジェクトレベルでinline展開を行う方法について リンカで--inlineを指定した場合に、少し複雑な関数でもリンカレベルでインライン展開する方法はないでしょうか? A.
リンカでのインライン展開は、コンパイラが生成した関数コール部分のコードに関数の実体を挿入する機能のため、 |
23.
Q. ヒープからではなく、スタックからアロケートする方法について A.
ARMCC4.1 b640より、alloca関数を使用することでスタックからアロケートできます。 |
24.
Q. プリコンパイルヘッダの作成側と参照側で統一させるべきコンパイルオプションの並び順について A.
コンパイラはコマンドラインまたはviaファイル経由のオプションを種類ごとにソートしてから使用します。
例えば: --create_pch=file.pch -O3 -Iaaa -Otime -Ibbb --use_pch=file.pch -O3 -Otime -Iaaa -Ibbb という二つのコマンドライン指定は、 -O3 -Otime -Iaaa -Ibbbという種類順でソートされますので、プリコンパイルヘッダを使用することが可能です。 これに該当するオプションは、-D/-U/-I/-J/--preincludeのように、複数回指定できるオプションが該当します。 --diag_suppressなどのように一つのオプション指定で複数の要素が設定できる場合は、要素を単純に連結して処理します。 例えば: --diag_suppress=1 --diag_suppress=2 --diag_suppress=3 は、以下のように変換されます。 --diag_suppress=1,2,3 一方、 --diag_suppress=1,3 --diag_suppress=2 は、以下の様に連結されるため注意が必要です。 --diag_suppress=1,3,2なお、 種類順にソートされた結果は、以下のいずれかで確認することが出来ます。
|
25.
Q. ライブラリ内の非 weak シンボルより、weak シンボルが優先してリンクされることがあります A.
ライブラリ内の非 weak シンボルは、使用方法によっては先にリンクされている weak シンボルを
RVCT コンパイラリファレンスガイドの「4.1.19 __weak」には以下のように記載されています。 -- リンカは、他のコンパイルで関数や変数が非 weak で使用されている場合を除き、 ライブラリから関数や変数をロードしません。 --
weak シンボルを、ライブラリ内の非 weak シンボルで置き換えようとする場合、実際に置き換えられているかどうか注意してください。 |
26.
Q.
プリコンパイルするヘッダ内で、#pragma diag_suppress を使用した場合、プリコンパイルヘッダ生成時には A.
これは、プリコンパイルヘッダの仕組みとして正しい振る舞いです。
main.cpp ソースファイルの例: #include "main.h" #pragma diag_suppress 177 main.cpp ソースファイルの例: #include "main.h" #pragma hdrstop // プリコンパイルヘッダ生成の終了 #include "user.h" // このファイル内に #pragma diag_suppress を記述する |
27.
Q. メンバ関数の定義の際にクラス名を多重に書いてもエラーになりません
下記のようなコードでエラーが検出されません。 例) class MyClass { public: MyClass(); ~MyClass(); void DoAnything(); }; MyClass::MyClass::MyClass() {} // no error MyClass::MyClass::MyClass::~MyClass() {} // no error void MyClass::MyClass::MyClass::MyClass::DoAnything() {} // no error A. C++標準仕様の9.0.2章に関連した記述があり、C++の仕様となります。
A class-name is inserted into the scope in which it is declared immediately after the class-name is seen. The class-name is also inserted into the scope of the class itself; this is known as the injected-class-name. For purposes of access checking, the injected-class-name is treated as if it were a public member name. 【JIS X3014での翻訳】 ≪クラス名≫は、≪クラス名≫が現れると即座に、宣言される有効範囲に加えられる。 ≪クラス名≫は、クラス自身の有効範囲にも加えられる(補正クラス名と呼ぶ。)。 アクセス検査に当たっては、補正クラス名は、公開メンバ名であるかのように扱われる。このクラス名は、そのクラスの有効範囲に挿入されたクラス名(injected-class-name)です。 |
28.
Q. インクルードパスを再帰的に検索する方法について A.
インクルードパスを再帰的に検索する方法はありません。 |
29.
Q. __align に 16 や 32 を指定できません A.
上記はコンパイラの仕様となります。 |
30.
Q. -Otime -O3 と -Otime -O2 との最適化の違いについて A. -Otime -O3 では、以下の特徴があります。
|
31.
Q. #2819-D の診断メッセージについて
テンプレートクラス内で仮想関数を使用すると、#2819-D の診断メッセージが表示されますが、 A.
本診断メッセージは、キー関数がテンプレートメンバ関数だった場合に、暗黙的にインスタンス化されることを 下記の対応で回避することができます。
|
32.
Q. インラインアセンブラで、GCC のassmebler instruction template のような記法に対応する予定について A.
追加機能として検討されていますが、長期的な計画として検討されているため、 |
33.
Q. --create_pch で作成したプリコンパイルヘッダを使用するとエラーが出ます A. --create_pch で作成したプリコンパイルヘッダを使用する際には下記の点に注意してください。
|
34.
Q. --create_pch/--use_pch を使用する際に、-I オプションに相対パスを使用できるか A.
ARMCC 4.1 build 640 以降で、--force_pch_reuse オプションをサポートしました。
このオプションは、PCHファイルを再利用する場合にディレクトリチェックを強制的に無効にします。
注意: このオプションはコンパイラがPCHファイルを再利用する場合、以下のように任意のPCHオプションと組み合わせて使用することができます。 armcc --force_pch_reuse --use_pch=foo.pch armcc --force_pch_reuse --pchマニュアルに記載していない非公開のオプションですが、ARMCC 5.x でも同様の条件で使用できます。 |
35.
Q. --split_sections を指定しても、組み込みアセンブラで記述された関数がデッドストリップされません A.
--split_sections が組み込みアセンブラで記述した関数で有効にならないのは仕様です。 #pragma push #pragma arm section code="AAAA_Asm" AAAA_Asm() {...} #pragma arm section code="BBBB_Asm" BBBB_Asm() {...} #pragma arm section code="CCCC_Asm" CCCC_Asm() {...} : 省略 #pragma pop |
36.
Q. コンパイラが挿入したパディングの位置を知る方法について
クラスや構造体のアライメントのために以下の警告が出ますが、これがどこに、何バイトの #1301-D: padding inserted in XXXXX A.
現状ではありません。 |
37.
Q. __forceinline を指定した関数を複数回呼び出すコードが最適化されません
__forceinline を指定した関数を複数回呼び出すようなコードを -O3 -Otime でビルドした際に、 A.
改善が検討されていますが、ARMCC 5.x での対応予定はありません。 |
38.
Q. コンパイラで使用可能な文字コードについて
A.
ARMCCでのマルチバイトコードの扱いは、使用するホストOSに依存します。 また、コンパイル後のオブジェクトファイルの文字コードは、マルチバイト文字では ソースコードと同じ文字コードに、ワイド文字列ではUTF-16LEとなります。 |
39.
Q. スタティックイニシャライザの挙動について インラインでコンストラクタを書いた場合以下のようなソースコードのビルドが通ります。 --- ・A.cpp #include <nn.h> class C { public: C() { NN_LOG("AAA:%s(%d)\n", __FILE__, __LINE__); } }; C A; --- ・B.cpp #include <nn.h> class C { public: C() { NN_LOG("BBB:%s(%d)\n", __FILE__, __LINE__); } }; C B; ---
これを実行すると、インスタンスA、Bのスタティックイニシャライザはコンストラクタを A.
ビルドオプションに、--retain=calls を指定している場合、スタティックイニシャライザによる __sti___5_A_cpp PROC PUSH {r4,lr} LDR r0,|L1.16| BL _ZN1CC1Ev ; C::C() の呼び出し POP {r4,pc} ENDPこれにより、クラス C のコンストラクタ _ZN1CC1Ev への参照が発生します。 リンカはこれを解決しますが、クラス C のコンストラクタ_ZN1CC1Ev は同名で 複数のオブジェクト内で定義されており、これらは同名の共通グループ(COMGROUP)が 使用されます。 AREA ||i._ZN1CC1Ev||, COMGROUP=_ZN1CC1Ev, CODE, READONLY, ALIGN=2 _ZN1CC2Ev ; Alternate entry point _ZN1CC1Ev PROCドキュメント「リンカの使用」内の「5.2 共通グループまたは共通セクションの削除」に 説明があるように、リンカは最初に検出したグループを保持し、それ以外を削除します。 このため、多重定義などのリンクエラーは発生しません。
--retain=calls を指定しなかった場合、コンストラクタはインライン展開され、 __sti___5_A_cpp PROC MOV r2,#6 ADR r1,|L1.16| ADR r0,|L1.52| B _ZN2nn3dbg6detail6PrintfEPKczこれにより、同一変換ユニット内のそれぞれのコンストラクタが呼び出されます。 --retain=calls 以外でも、--no_inline を指定した場合は、コンストラクタはインライン展開 されませんので、同名のコンストラクタを別のコンパイル単位で意図的に使用する場合には、ご注意下さい。 |
40.
Q. 配列へのポインタの扱いについて 以下のコードをコンパイルしても、エラーにならず通ってしまいます。 char (*str)[256] = new (char(*)[256])[2];右辺は「配列へのポインタ」ですが左辺は「配列へのポインタの配列(の先頭アドレス)」なので、 間接参照のレベルが違います。左辺について、配列へのポインタの配列というのはそもそも new できる ものなのでしょうか。(VisualStudio 2008 ではできませんでした) A.
上記コードは、以下の様に置き換えることが出来ます。 typedef char(*the_type)[256]; the_type str = new (the_type)[2];ここでの式 'new (the_type)[2]' は、C++では有効な記述ではないため、厳密なC++準拠を指定する モード(--strict)ではエラーになります。また、--strict_warnings では、警告メッセージが表示 されます。デフォルトの非厳密モード(--no_strict)では、以下の様に取り扱います。 the_type str = (new (the_type))[2];the_type は、256 chars の配列へのポインタです。(new (the_type))は、このポインタをアロケートし、 このアドレスを返します。(new (the_type))[2] はこれを行い、その後に配列として返される値を扱い、 その二番目の(the_type 型を持つ)要素を返します。 配列へのポインタの配列をアロケートする場合には、以下の様になります(明確にするため、ここでもtypedefを使用します) typedef char array_type[256]; typedef array_type *array_type_ptr; array_type_ptr *str = new array_type_ptr[2];これは 256 chars の配列へのポインタの2つの要素を持った配列をアロケートし、'str' にポインタの 配列の最初の要素をセットします。
C++標準規格では、new expression でパーレン(丸括弧)の使用は'can have surprising effects' |
41.
Q. 無名名前空間の大域変数を組み込みアセンブラから使う方法について
無名名前空間内にある変数のアドレスを得たいのですが、うまくいきません。 namespace{ float localValue; asm float *GetLocalValueAddr() { LDR r0,=__cpp(&localValue) BX lr } } main() { NN_LOG("local Addr:%p\n",GetLocalValueAddr()); } A.
組み込みアセンブラで記述した __asm 関数は同一変換ユニット内での複数の __asm 関数が
__cpp キーワードでは、外部リンケージを使用するデータまたは関数アドレスのみを取り扱う |
42.
Q. ARMCC での C++0x(C++11) の導入について A.
ARMCC5.05 以降での導入を検討してきましたが、機能実装のためのフロントエンドコンパイラ変更による影響が大きく、 |
43.
Q. fast ビルド時に、ARMv5T 用ではなく ARMv4 用のライブラリがリンクされます A.
リンカのデフォルトオプションでは、入力オブジェクトが ARM コードのみである場合は、
リンカのオプションに --cpu=MPCore を指定することで、入力オブジェクトがARM コードのみの CTR-SDK 4.0 のビルドルールで、リンカのデフォルトオプションに --cpu=MPCore が追加されました。 |
44.
Q. コンパイラを ARMCC5.x に変更したら、以前には出ていなかった警告が出ます A.
ARMCC5.x でのフロントエンドコンパイラ変更の影響で、以前には出ていなかった警告が出る場合があります。 例を挙げると、以下のような警告が出る場合があります。
|
45.
Q. コンパイラを ARMCC5.x に変更したら、--gnu 未指定時に #3093 のエラーになります A.
コンパイラは、--gnu モードが指定された場合、またはソースコード中に "#pragma anon_unions" が
しかしながら、以前はこれらの2つのオプションが使用されていない場合においても、 不正なコードの生成の原因となるため、ARMCC5.x ではエラーを出力するように修正しています。 |
46.
Q. ARMCC5.04 に変更したら、DLL モジュールのリンク時に L6244E のエラーになります A. ARMCC 5.04 のリンカでは、ダイナミックリロケーションが生成された場合、--no_legacyalign が デフォルトとなるように仕様を変更しています。
CTR-SDK のビルドシステムは、この仕様変更に対応していないため、DLL モジュールのリンク時に L6244E のエラーが発生します。 ARMCC5.04 では DLL アプリ / モジュールのリンク時には、--no_force-dynamic-natural-alignment を指定するようにしてください。
CTR-SDK 11.3.0 の SampleDemos でオプションを追加しています。 |
47.
Q. ビルド時間を短縮する方法について A. ビルド時間を短縮する方法として、以下のような方法が考えられます。 1.ビルド時間全体に影響する方法
- 並列実行を活用する
- ビルド環境に十分なメモリを実装する
- ビルドで使用するファイルを高速なディスクに配置する
2.コンパイル時間に影響する方法
- ヘッダファイル検索順を調整する
- プリコンパイルヘッダを使用する
- 不要なデバッグ情報を出力しない
- コンパイル単位をまとめる 3.リンク時間に影響する方法
- マップファイルとコールグラフを生成しない
- 逆アセンブルリストを生成しない
- 入力オブジェクトファイルのデバッグ情報を減らす
- DLL アプリ・モジュールの部分リンク時にデバッグ情報を出力しない
CTR-SDK 7.2.1 以降で、DLL の部分リンク時にはデバッグ情報を作成しないように対応しました。 |
48.
Q. マップファイルを生成しない方法について A.
SDK のデフォルトのビルドルールでは、以下のオプションで指定した情報を、--list オプションで指定するファイル(.map) --info, --map, --symbols, --verbose, --xref
上記のオプションを指定しないようにしたうえで、--list オプションを指定しないことで、コンソールに出力される情報を SDK のビルドルールでは、ビルド変数 LDFLAGS_INFO を変更してください。 |
49.
Q. ARMCC5.04 に変更したら、デバッガが誤動作を起こします A.
ARMCC 5.04 では、デバッガが参照する出力ファイル(.axf ファイル)内の情報に変更がありました。
ARMCC 5.04 で作成したアプリケーションをデバッグするには、PARTNER-CTR 5.70-040(2014/01/23 版)以降を使用してください。 |
50.
Q. C++ 例外使用時に未使用関数が削除されない場合があります A.
未使用関数は、リンカの未使用セクションの削除により最終イメージから削除されますが、
以下にリンカの未使用セクションの削除処理について説明します。
1) Unused : リンカは最初に全てのセクションが未使用だと仮定します
Weakly Used セクションは、使用済みとしてマークされたすべてのコードセクションから例外テーブルと セクションへの参照が存在します。 2) コードセクションから例外テーブルへの参照が無い場合はエントリポイントからの再配置が通常の チェーンで行われ、全ての例外テーブルは破棄されます。これは、イメージで例外をスローしない 場合に行われます。 3) Strongly used セクションから参照される section_name$$Base と section_name$$Limit のシンボルを 持つ個々のセクションは Weakly Used としてマークされます。 4) Weakly Used セクションから参照される全てのセクションは、Weakly Used としてマークされます (既に Strongly Used でない場合)。Weakly Used セクションは、いくつかの section_name$$Base と section_name$$Limit のコード処理で間接的に到達するセクションです。 5) Weakly used セクションが、同一オブジェクト(同一コンパイル単位)内のStrongly Used セクションを 参照している場合は、Weakly Used セクションは Strongly Used セクションとなります。 6) 全ての Strongly Used セクションは保持され、残った全ての Weakly Used と Unused セクションは、 削除されます。
なお、アプリ側での明示的な例外のスロー処理がない場合でも、コンパイラオプションで --exceptions が
以下のようなソースで、アプリ内で used_function() 使用され、unused_function() が void foo() { } void used_function() { foo(); } void unused_function() { foo(); }Unused セクションの unused_function() は例外テーブルエントリから参照されていますが、C++ 例外が使用されなければ、 2) により例外テーブルが破棄されるため、Unused として削除されます。 C++ 例外が使用されている場合、 unused_function() は例外テーブルエントリからの参照があるため 4) により Weakly Used としてマークされます。また、unused_function() から Strongly Used セクションである foo() が 参照されているため、5) により Strongly Used セクションとなります。unused_function() は 6) により 削除の対象にはなりません。 Weakly Used セクションの取り扱いに関しては、やや慎重な扱いをしており、現行のリンカ仕様では、 上記の条件にあてはまる関数を未使用として判断することは出来ません。そのため、最終イメージで 削除されずに残る場合があります。 上記の例の場合では、unused_function()を、参照する Strongly Used セクションとは別のソースに移動する ことで、5) が適用されなくなり、Weakly used セクションとして削除されるようになります。
|
51.
Q. ARMCC4.1 b1454 の --conservative_init_expression_optimization オプションについて A. ARMCC4.1 b1454 では、まれに初期化式を不正に生成する重複した関数呼び出しを引き起こす、以下の 2つの不具合を修正しています。
最適化を制限するオプション --conservative_init_expression_optimization を追加しています。 --remarks オプションを併用すると、--conservative_init_expression_optimization によって最適化が無効となった箇所で、 "test.cpp", line 19: #2463-D: Unsupported feature: (Auto splitting initialization from declaration)のような診断結果が表示されます。この表示によって、本オプションによる最適化への影響を確認できます。
|