自己レスで済みません。オプション)が有効になっていれば、ただの関数のままでもインライン展開されました。逆に-fltoがないとinline宣言してもインライン展開されないこともあったり、他の最適化オプションとの組み合わせも考えて使わないといけないみたいですね。Myマクロですがどうでしょうか。交換アルゴリズムは使用すべきではなく一時変数を使用する方法にすべきと思います。交換アルゴリズムは整数のオブジェクトにしか使用できず浮動小数点型や構造体等に対応できません。上手く最適化できないようで、一時変数を使用する方法と比べて効率も良くないようです。関係なくインライン展開が強制されると思いますが上手く行かないことがあるでしょうか?あるいは、インラインアセンブラを関数風のマクロで使用するというのも手だと思います。10:00こんにちは。FreeRTOSだそうです。ルネサスさんのRXは参加しないのかな?』でCC-RX用プロジェクトをGNURX用プロジェクトへ移植する際に参考にさせて頂こうと思います。ほやさん、LEONさん、お二人のリプライの文面から察するに、別スレッド『GUNRX用プロジェクトのスマートコンフィグレータのBSPを見ていて気付いた変な移植コード』でのCC-RXによるr_bspモジュールをGNURXによるr_bspモジュールへ移植したプログラマ殿や、本スレッドでのCC-RXのxchg()関数をGNURXによるxchg()関数へ移植したプログラマ殿と、同じ勘違いをされている状態なのだと思われます。その別スレッドに私が書いた文面と一部重複するのですが、この関数は、ただ単にデータ交換を行うだけの関数では無く、RXマイコンのXCHG命令でセマフォのロックを行う操作をプログラマがアセンブラ記述しなくても行えるようにすることも意図されている関数なのです。ソフトウェア編』の以下の画面コピーにある記述からです。生成されるXCHG命令は、data2が指す位置のメモリオペランドを持ちます。実装により、排他制御に使える場合があります。詳細については、各製品のハードウェアマニュアルを参照してください。実は、xchg()関数の2つの引数のdata1とdata2に関しては、どちらがXCHG命令のメモリオペランドでどちらがレジスタオペランドなのかを把握しないと、xchg()関数でセマフォのロックを正しく行うことが出来ません。逆に言えば、xchg()関数が、単にデータ交換を行うことしか意図されていない関数なら、引数とオペランドの対応関係はマニュアルに記載する必要は無いのです。それが記載されているということから、xchg()関数は、ただ単にデータ交換を行うことだけを意図されている関数では無い、ということが分かるのです。NoMaY:NoMaYさん、fujitaさんこんにちは、シェルティです。本件、なんらか見解だすように関係者に依頼しました。進展ありましたら、書き込みます。私としてはfujitaさんのコードを暫定として適用するのが今の対策としてよいと思いました。ご協力に感謝いたします。NoMaY:NoMaYさんほやです。xchg()関数でセマフォのロックを正しく行うことが出来ません。XCHG命令として吐かないと「そういう目的には」使えない、って話は皆さん解っているとは思いますよ。・GCCで実装されていないのだから体裁だけでもあるだけマシ・体裁だけあっても紛らわしいだけどちらと見るかは何に使おうとしているかに寄るのかと。ほや:fujitaさん、NoMaYさん検証による証明、ご指摘、ありがとうございます。お手数をおかけしました。一時変数を使用せず、変数の整数データを交換をするだけ。