クロスコンパイルはGCC & binutilsの独擅場だからねぃ

このスレには優しい神が宿っているようだ。

>>550
変態なgccだなあ

4.3.2

GCCは最高のクロス開発環境だなあ

GCC に #pragma optimize はないんですよね？

ある大きな数値計算プログラムがあって、
全体としては -O や -O2 など最適化はしたい。
けど一部、計算誤差などを考慮した、
計算の順番を変えてほしくないコードがある。

Intel Compiler などは pragma でソコは最適化しないように
回避できるんだけど、GCC はどうしようかと。

なんか手段あります？
ソースを分けて、そこだけ -O0 にするしかないのかな？

> ソースを分けて、そこだけ -O0 にするしかないのかな？

と思う。

>>556
-fno-fast-math か？

556とは別人なんだがinline関数なんかの場合はそこだけコンパイラオプションを変えるわけにもいかないし
精度は保ちつつ最大限速くしてもらいたいからvolatile使うのも嫌だしとワガママ言ってしまうことはあるね。

Cを高級アセンブラとして使っているときに
局所的に自分でスケジューリングした順序で動いて欲しいこともあるし。

>>556
研究や業務で使う道具としては悩むよりもicc使っておいた方が良い場合に該当するんじゃなかろうか？

volatile とかうまく使えないんだろうか

GCCでもPGOであるんですか？

最近のならあるよ
-fprofile-generate/-fuse-profile

まちがえた-fprofile-useね

フリーなのにすごいですね…

実績だけは(アーキテクチャによっては)存分にあるからな。

__artificial__アトリビュートを調べていたら、下のドキュメントが
あったけどなんかいまいち理解できん。
わかりやすい日本語で解説してくれ！

artificial
This attribute is useful for small inline wrappers
which if possible should appear during debugging as a unit,
depending on the debug info format it will either mean marking
the function as artificial or using the caller location for
all instructions within the inlined body.

この属性は小さなインラインラッパー関数に使いよい。
その関数とはどういうものかというと、デバッグ中には
関数の中に入らずに単体として扱われるのが望ましいもの。
この属性がどう実現されるかというと、
デバッグ情報フォーマットによるが、
関数にartificialというマークをつけるか、
またはインライン化された関数本体中の呼び出し位置を使う
(どう使うのかは書いてない)ことになるだろう。

……と理解した。
デバッグの必要のないような機械的に生成したラッパーインライン関数
なんかに使うといいんでないのかしら。

$(GCC)/gcc/config/i386/emmintrin.h みてね。

>>568
よく分かった！ありがとぅ！

>>569
まさにそれを見てて気になったんで調べてた

とりあえず、*mmintrin.h は非常に使いづらいんで
自前でラッピングしようと思った次第。

それにしても、GCCのアトリビュートは書きにくい。
アトリビュートはC#の書き方がいい感じ。

[Align(16)]
int hoge = 12;

とか。

gccの方が何に掛っているかはっきりする。

gccでコンパイルしたバイナリを販売したらダメなんだろ？
イミネー

いや、コンパイルしたもの自体は問題にならない。
GPLなソースが混入してない限り。

だがそれが回避しにくいように念入りに作られてるんだわこれが…

それと仮にGPLだったとしても、GPLなら販売禁止ってわけじゃないよ。屁理屈みたいだけど。

>>572
どこでそんな嘘聞いてきたんだ。

>>573
作られてない。そもそもふつーにコンパイルする範囲ではGPLの影響は受けない。
お前のプログラムにGPLが感染するのは、コンパイラ関係無しにGPLのコードを混入させたときだけだ。

>>572-573
なのこの頭の悪いしったか連中…
libcがGPLのときのバイナリと混同でもしているのか?

4.4がstage3になったのか。
リリースは来年ですかねえ。

>>577
libgccが例外なしGPLとか。

In addition to the permissions in the GNU General Public License, the
Free Software Foundation gives you unlimited permission to link the
compiled version of this file into combinations with other programs,
and to distribute those combinations without any restriction coming
from the use of this file.

GNU一般共有使用許諾における許容に加えて、フリーソフトウェア基金はこのファイルのコンパイルされたバージョンを他のプログラムへの組み合わせにリンクして、このファイルの使用から無制限に来るそれらの組み合わせを広げる無制限な許可をあなたに与えます。

しかし、このスレは定期的にGPLの話がでるな。

とりあえず、

・GLPのソースを含んだ実行ファイルから利益を得ることは制限されない。
・ただ、ソースを見せろと言われたら全て見せなくてはならない。
・それは不便だからLGPLがあり、その場合は以下の条件を満たせばソースを
　見せる必要はない。
・使用しているLGPLなソースを第三者が修正して、再度、配布しているもの
　と同等の実行ファイルを作成出来なければならない。
・ダイナミックリンクの場合は特になにもする必要はないが、
　スタティックリンクの場合は、リンクに必要なオブジェクトファイル
　(具体的には、*.o)を提供しなければならない。
・同等の実行ファイルを作成出来ることが必要という縛りがあるので、
　LGPLだからと言ってこっそりコピペするのは(･Ａ･)ｲｸﾅｲ!!
　(結局ソースを提供しなければ同等にならない可能性があるので。)

と理解している。

GPLのプログラムがLGPLのライブラリを読み込んだとき、
LGPLのプログラムのソースの公開の義務は発生しますか？

GPLのプログラムとリンクした時点で、ライブラリもGPLになります

>>583
なんですとぉ！
自作ツールでアーカイバプロジェクトの
スタティックライブラリをリンクしたとする
自分のものでもないしソースもないけど勝手にGPL？

d3d9x.lib とかスタティックライブラリじゃん
困らね？

おいおい、めちゃくちゃだな。
>>582
GPLのプログラムもLGPLのプログラムもソースを公開する義務がある。
悩む必要はまったくない。公開してくれ。

>>584
その自作ツールのライセンスはなんだ？
ソースを公開したくないんだったら、LGPLのライブラリをリンク
してれば大丈夫だ。ライブラリがGPLの場合は無理。

> d3d9x.lib とかスタティックライブラリじゃん
> 困らね？
それはまた違うラインセンスになってるだろ。
詳しくは知らんが、それをちゃんと調べるべき。

>>584
全体をGPLにできる場合のみ、GPLのコードを基に著作物を形成・複製・頒布することが許諾される
条件を満たせないなら、GPLの使用許諾は得られない

>>584
勝手じゃないだろ。使うソフトウェアのライセンスは読もうよ。

非GPLなプログラムからGPLなライブラリを使うときは
非GPL部分とGPL部分とでプログラムをわけて、
ソケット通信をすればおｋ

まあGPL部分は諦めて公開する必要があるけど
どうしても非公開にしたいコアな部分は非GPLにできる。

>>584
いや、d3d9x.libってCygwinかなんかの？LGPLなの？
困るんならMSのライブラリとコンパイラ使いなよ。
または、d3d9x.lib相当の機能は、自分で作らないと。

他人の成果物使ってんだからさ。
ライセンスに従えない人間に使われるのてむしろ困るのは、
ライブラリを作ってる側だし。

>>588
そのソケット通信は確実に白なの？
前にそんなことが議論になったみたいだけど、
結論がどうなったか知らないんで。

>>588の例だとGPL部分が不可欠ならばリンクしてなくても
派生物としてソースを公開する必要があるという議論だったと思う。

>>589
プロプライエタリなOSにGNUな開発環境を存在させるため
OSが提供するライブラリに関してはプロプライエタリでもGPLの公開義務の
対象外。

分かりにくいなぁ。GPLって。
このライセンスは、GNUが本来目指していた目的に合致するのだろうか・・・・

本来の目的って、すべてのソフトを未来永劫にわたってオープンソース化する
超過激思想だぞ? だからこそこんな感染性のあるライセンスにしたわけで。

そのへんは「オープンソース」界隈の連中が意図的にか天然か
勝手に話を混ぜ込んでいたりするからなw

>>582
*フリーではないライブラリを利用するフリーソフトウェアを書いているのですが、GPLを適用した場合どのような法的問題が発生するでしょうか?
http://www.gnu.org/licenses/gpl-faq.ja.html#WritingFSWithNFLibs

*「単なる集積」と「二つのモジュールを一つのプログラムに結合すること」の違いは何ですか?
http://www.gnu.org/licenses/gpl-faq.ja.html#MereAggregation

>>592
根本はとってもシンプル
結局はバイナリ公開したければソース出せボケ
いろいろな抜け道を塞ぐために条文追加するはめになっただけのこと

ストールマンの最初の動機と何も変わってないｗ
思想先行どころか実利的なGPL

>>591
d3d9x.libはOSのライブラリってこと？スタティックなライブラリが？
話が唐突で全然意味がわからん。
てっきり、GCC用のLGPLなライブラリだと思ったんだが。

あと、GPLならGPLが適用されるし、LGPLならLGPLが適用されるっしょ。
OSがプロプラとか関係無い。

すくなくともd3d9x.libについて調べればそういう話は出てこないとおもう。
簡単に言えば、Direct3Dについてくる、MSの3Dライブラリみたいな。

例えば、GPLな数値計算ライブラリと
Direct3D の組み合わせで計算結果を視覚化するソフトウェアがあるとする
このソフトウェアを α とする

α 内で使用されている D3DX* 系の関数は DirectX SDK の d3dx9.lib スタティックライブラリに含まれている
スタティックライブラリに含まれる部分のソースが無いので
出来上がった α を頒布することはできない

これで合ってる？

>>591
それが詭弁に過ぎないことは世の中のWebブラウザを見てればわかる