まともだよ。
ただGPLがらみでgcc止めるとか言い出している人いるから、
また諸々ぐだぐだになるかも。

なぁ、Linux上でGCC4を使っています。コンパイルしたアプリケーション中、
各モジュールがどう構成されているのかを知りたいのだけどどうすれば
いいのかな。知りたいのは以下の通り

読み取り専用データサイズ（コード＋定数）
読み書き可能なデータサイズ
ゼロクリアされるデータサイズ

また動作しているアプリケーションのメモリ中、共有ライブラリが
使用しているメモリサイズ、ヒープ領域のサイズ、スタック領域のサイズ
も知りたいのだけど。どうしたらええんかな。

$ size a.out
$ lsof -p PID
じゃダメか?

ライブラリの使っているメモリの区分ってのは難しいな。
テキスト領域しか分からない。
別のヒープ、スタック使ってるわけじゃないから。
スタックについては、debuggerが頑張れば追跡可能だろうけども。

/proc ?
gccのネタ関係なry

>>103
ありがとう！sizeがまさに欲しかったものでした。

　　　　　 -=-::.
　　／　　 　　　＼:＼
　 .|　　　　　　　　　　ﾐ:::|
　ﾐ|_≡=､´ ｀, ≡=_、　|;/
　 ||. ◎ .|￣|. ◎　|─/ヽ　　我は成大作･姜尚中･張勲･郭光雄･成田豊･辛格浩・盧勝正公認
　 |ヽ二/　　＼二/　　∂>　恨憎貶日創価高麗大使である。お前が立てたスレッドをグレート
　/.　 ハ - －ハ　　　|_/　　コリアレスリングエンターテインメントワイドショースレッドとして認定する。
　|　 ヽ／ヽ／＼_ノ　 / |
.　＼､ ヽ二二／ヽ　 / /
.　　 ＼i ＿＿＿ ／_／
　　 　 ＿__
　　 ／　?＼　ﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳ
　／ノ　　(＠)＼　ﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷ
.｜　(＠) 　 ⌒）＼　ﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯ
.｜　　 （__ノ￣|　　| 　 ///;ﾄ, 　ﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮ
　＼　　　|＿／　 /　////ﾞlﾞl; 　ﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮ
　　 ＼　　　　 _ノ 　 l 　 .i .! | 　ﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮ
　　　/´　　 　 ｀＼ │　 　| .| 　ﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮ
　 　 |　　>>1 　　　|　{　　 .ﾉ.ﾉ 　ﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮ
　 　 |　　　　　　　|../　　 / .　ﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳ

>>105
共有ライブラリ云々は、.soをsizeすればいい。

が、sizeで出力されるtextサイズには.rodataセクションのサイズは含まれていないと思う。そっちはreadelfかな。
あと、sizeじゃヒープとスタックのサイズもわからんだろう。それはいいのか？
簡単なのは、 /proc/pid/maps 見るとかかな。粒度荒いけど。

sizeで情報が足りなかったらldにmapfile吐かせれば大抵間にあうだろ。

kwsk
出力付きでな。

群馬のＧＣＣの池田には散々嫌がらせをされたなー。
あの野郎あったら確実に・・・
まーここのスレとは関係ないが。

あんま関係ないけど、gcc-4.1.2とicc-10.1のO3同士の比較があったから。
http://www.anandtech.com/IT/showdoc.aspx?i=3162&p=6
4.1でこれなら4.2,4.3と結構速くなっきているから結構いい線いってんのかな？

まぁまだvectorizeはちょっと信頼性の部分で弱そうだけどね。。。

>>111
＞4.1でこれなら4.2,4.3と結構速くなっきているから結構いい線いってんのかな？
それはダウト
少なくとも4.2ではかなり遅くなった
4.3では性能向上…のはずが、いつのまにかパッとしない性能で仕上がっちゃってる

確かにvectorizeはどうもね…バグがまだ潰しきれてない感じ

C++派の俺から観ると、4.3は非常によろしいんだけど、
C数値計算はたまらんでしょうな。

4.3は4.2と同様、4.1よりはかなり性能悪くなってた

でもメーリングリストではコードの信頼性が上がるなら
性能などいくらでも落ちてよいって流れだったから
これからも性能は悪化し続けそう

>>114
http://www.suse.de/~gcctest/ ではいい傾向になってるし
自分で試してもよくなった部分もあるんだけどな。
多分112と同じ人と思うけど、どこかuriポイントしてください。

数値計算する場合は細かなチューニングよりもGOMP使ってくださいサーセンwwww
ってところじゃないのかな。

http://gcc.gnu.org/ml/gcc/2007-11/msg00023.html

もしかして1コードだけのregressionで判断してるのか。

いや最近期待できない方向に進んでるみたいだから悲観的になってるだけ

GOMPで思い出したが、ゴンプ言うな。

>>119
>>118への答えになってないじゃないか。

判断してるってことだよ

以前このスレにgcc-2.95が最高で、以後はクソとひたすら叫んでいるヤシがいたけど、
そいつがまだ粘着しておるのか?

違うよ
その人は実行速度のことは気にしてないんじゃなかった？

コンパイル速度を気にしている人はいたな。
俺はC++の標準準拠最優先だから、人それぞれって事で。

もっとベンチ結果無いかな

俺はコンパイル速度よりもコンパイル後の実効速度さえ速ければいいや。

gcc4.2.0をインストールしようと思っているのですが、
configureしてmakeすると、parse-scan.cが見つからないと出てしまい、
それはネットで拾ってきて入れたら、通ったのですが、今度は

java/jv-scan.o: In function `main':
../.././gcc/java/jv-scan.c:221: undefined reference to `main_input_filename'

と出て、その解決方法がわかりません。そのchar*型変数自体はgcc/toplev.cに宣言されているので、
toplev.hにextern宣言して、jv-scan.cに明示的にインクルードしてみたんですが、それでもダメです。

この解決方法や解決案について誰か教えてください。
SuSE Linux 10.1です。

parse-scan.cはparse-scan.yから作られます。
bisonがinstallされてないと生成できません。

・エラーメッセージをちゃんと読んでない
・かなり無茶をしている
・既にそのbuild環境はダーティ

なので、冷静になって初めからやり直してください。
SuSEなら何の問題もなく作成できると思います。

>>129
ご回答どうもありがとうございました^^)
bisonをインストールしたら、gccも無事にビルド出来ました！
P4 1.8GHzでmakeに４時間もかかったよﾏﾏﾝ

gccは2.95が最高、以後はクソ
gccは2.95が最高、以後はクソ
gccは2.95が最高、以後はクソ
gccは2.95が最高、以後はクソ
gccは2.95が最高、以後はクソ
gccは2.95が最高、以後はクソ
gccは2.95が最高、以後はクソ
gccは2.95が最高、以後はクソ
gccは2.95が最高、以後はクソ
gccは2.95が最高、以後はクソ
gccは2.95が最高、以後はクソ
gccは2.95が最高、以後はクソ
gccは2.95が最高、以後はクソ

俺もそう思っていたけど、2.95 が手元の環境でビルド出来なくなっていて驚いた。

flexやbisonがなくてもconfigureに成功してしまうのは、
何かの陰謀なのかねえ

x86_64に対応してればなんでもいいよ

オアーオアーオアオアオアー

gcc、お呼びgcc javaについて理解できないのですが助言お願いします。
情報を求めてwiki等を見回っていると、
gcc javaはネイティブなコードを出力するとあります。
これはVM上で動作するバイトコードではなく、マシンで直接動作するバイナリコードという事でしょうか？
又、gccの言語間の関数、クラス等の呼出は可能でしょうか。

>>136
ネイティヴコードってのはそういうこと．gcjは以下の変換ができる．
- Javaソースコード→プラットフォームのネイティブコード
- Javaソースコード→Java クラスファイル
- Java クラスファイル→プラットフォームのネイティブコード

>又、gccの言語間の関数、クラス等の呼出は可能でしょうか。
gcj の場合はJNIかCNIのいずれかの規約にしたがってのみCやC++のAPIを呼びだせる．

Sunのオープンソースになったクラスライブラリも
ずいぶんとgcjでコンパイルできるようになってきたね。

gcjはネイティブコードと言ってもCほど速くないのが何とも。

アルゴリズムによってはVM方式のほうが速い場合なんていくらでもあるだろう
JavaなんてC++で言うところのRTTIを使いまくりなんだしさあ。
ハゲがC++をvirtual宣言してないとオーバーライドできない糞仕様にしたのも
パフォーマンスの問題があるからでしょ（つまり糞仕様じゃないってことなんだけど）

virtualでオーバーロードしたら遅くなるのは自分で設計してみりゃ脳内ですぐ気付く問題

>>142
vtbl経由するコストだけで、オーバーロードは関係ないだろ。

オーバーライドと混同したって話だろうな

#include <sstream>
#include <string>

using namespace std;

int main(void){
stringstream ss;
string str;
ss.str("test1 test2 test3");
// ss >> str; //←この行のコメントを外すと、コンパイルは通るが実行するとセグメンテーションフォルト
return 0;
}

>gcc --version
2.96

バグですか？

>>145
バージョンが古すぎて調べる気にもならん。

(´･ω･｀)
管理者に言ってバージョンあげてもらいます。

cygwin版gcc 4.0まだー？

古いものなら何でもかんでも安定する！とか言って、単に今ある最新版から
テキトーにマイナス3くらいしたバグだらけの古いもの採用するVine Linuxとかある

本当に実績のあるものを選んでいるわけではなく、まさにテキトー。
最強バグ版のGCC4.0.2採用しているあたり実績で見てるわけじゃない

この板で鳥の話出す馬鹿