トップページ⇒tech
1001コメント281KB

GCCについて part8

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん2007/10/13(土) 00:07:39
史上最強かもしれないツール、GCC(GNU Compiler Collection)について語るスレ。

GNU本家のGCCページ
http://gcc.gnu.org/

Binutils - Collection of binary utilities ←これも必要だぞ。
http://www.gnu.org/directory/GNU/binutils.html

GNU Binutils
http://sources.redhat.com/binutils/

GCC online documentation
http://gcc.gnu.org/onlinedocs/

Installing GCC
http://gcc.gnu.org/install/

GCC Timeline
http://gcc.gnu.org/releases.html#timeline

Calendar
http://gcc.gnu.org/develop.html#timeline

前スレ
GCCについて part7
http://pc11.2ch.net/test/read.cgi/tech/1145357824/l50
0951デフォルトの名無しさん2009/06/21(日) 19:19:13
>>948->>949
嘘を言うな
0952デフォルトの名無しさん2009/06/21(日) 19:22:46
>>951
いやicc以外バグがあるってintelに指摘されてるでしょ
0953デフォルトの名無しさん2009/06/21(日) 19:24:16
>>952
ソースは？
0954デフォルトの名無しさん2009/06/22(月) 01:08:45
こういう嘘つき野郎って、やっぱり頭おかしいんだろうな
0955デフォルトの名無しさん2009/06/22(月) 05:23:14
GCC以前に64bitの演算器が32bit未満の並列粒度しか保障してない
CPUもなかったっけ？
0956デフォルトの名無しさん2009/06/22(月) 05:58:46
世の中にないと断言するのは難しいが。
0957デフォルトの名無しさん2009/06/22(月) 06:41:47
プレスコは32bit演算器のパイプ2段で64bit命令実行している。
CoreMAは最初のころ命令デコーダがEM64Tの命令切りわけ時に
ペナルティがあった。

レジスタが増えた分と実行性能が落ちる分とがあるから、
64bitにしたら単純に性能が上がるとは言えない。
0958デフォルトの名無しさん2009/06/22(月) 06:58:33
一般論で言えるわけではなく、そのCPUの出来が悪いってだけの話だな。
0959デフォルトの名無しさん2009/06/22(月) 10:11:04
Athlon64は初期のころから性能上がるケースが多かったけど、
Intel は Core2 でもあまり性能上がらなかったからな。
ネハーレンでやっと最初から64bitをターゲットに設計したCPUになった。
0960デフォルトの名無しさん2009/06/22(月) 20:34:09
そもそも、一般論で終わらない話題だろーが。
上のほうで「速くなる」とか「遅くなる」とか言ってるのがアホってだけで。
んなもん、CPUと対象のプログラムに依存するにきまってんだろ。
0961デフォルトの名無しさん2009/06/23(火) 00:08:05
iccもvcもpgも速くなるのに
なぜかgccだけは64bitでもっさりするｗ

終わってるよな
0962デフォルトの名無しさん2009/06/23(火) 04:53:20
vcは全然はやくなんねーけどな。
0963デフォルトの名無しさん2009/06/24(水) 02:02:15
レジスタいるような計算ぶん回してるときって、
push/popが実質0クロックで終わるから、レジスタ増えたこと自体は
大した解決にならないんでないの。
push reg/pop regも1バイト命令だし、ALUがボトルネックになるだろうから
今時のx86デコーダの負荷にはならんだろうし。

レジスタリネーミングが無いプロセッサとか、
レジスタ割り当て問題にコンパイラが悩まされてるときなら
レジスタが多いのは役に立ったけど、今となっちゃあ
それだけでパフォーマンスアップしろってのは難しいでしょ。
0964デフォルトの名無しさん2009/06/24(水) 02:09:10
スタックフレーム上のローカル変数(レジスタ割付できなかったもの)は
普通、push/popなんてしません。
毎回直接読み書きするし、
それがアドレスを示すものならば、必ずレジスタにロードしてから(アドレス先に)アクセスします。
0965デフォルトの名無しさん2009/06/24(水) 02:12:59
>>963の内容は
「レジスタ変数に割り当て可能なレジスタ」が増えた場合の話だけね。
局所的な計算に用いる「レジスタの増加」とはあまり関係ない。
0966デフォルトの名無しさん2009/06/24(水) 02:45:08
そういえば、レジスタが足りなくてpush/popするのは人間だけか。
でもやっぱりmovも0クロックじゃね？
ほとんどのケースで演算に隠れちゃいそうだけど。
0967デフォルトの名無しさん2009/06/24(水) 03:08:16
たとえキャッシュに乗っていたとしても、
メモリの読み書きとレジスタじゃ速度が違うんだよ。
そうでなければレジスタの存在意義が半減する。

だからこそRISCとかは沢山のレジスタを持ってるし
x86だってレジスタリネーミングとかを駆使して補おうとしている。
補えないから、一時変数としてのメモリの読み書きが発生してるんだがね。
0968デフォルトの名無しさん2009/06/24(水) 03:58:11
>>967
いや、だから今時のx64積んでるようなx86ってその「レジスタの存在意義が半減」してるから、
単にレジスタ増えただけじゃあんまり変らなくね？って話ですよ。
キャッシュアクセスのスループットがいくら悪くても、
前後の演算なりイテレーションなりに隠せないようなケースってのは
ほぼ無いと見ていいんじゃないかと。

もちろん、裏付けがあるわけではないので、
「んなわけねーよ、メモリ待ちでストールしまくりだよ」
と言われるとそれまでです。
0969デフォルトの名無しさん2009/06/24(水) 04:28:09
>ほぼ無いと見ていいんじゃないかと。

これだけは絶対ありません。
そして、(対32bitにおけるデコーダ等の不利の無い場合)
64bitで再コンパイルしたコードの速度が実際に速くなっているという事実が
全てを物語っていますけど。
0970デフォルトの名無しさん2009/06/24(水) 09:37:16
頼むからレジスタなんて多くても速くならないなんてスーパー馬鹿は放置してくれ
0971デフォルトの名無しさん2009/06/24(水) 13:17:59
あちこちで同じような馬鹿が沸いてるな
0972デフォルトの名無しさん2009/06/24(水) 16:33:04
レジスタの多かった下手なRISCよりもx86の方が早かったのも事実だが、
開発費を湯水のように使って高速なプロセッサの設計が出来、
開発費の回収も出来たからだろうな。

現状はレジスタ数を増やした方が早くなっているものの、早くなっていないアプリもある。
演算やポインタの単位が64ビットになって、キャッシュに対する影響が出ているのではないかと
思われるが、本当の理由についての解析は完璧に進んでいるのかな？
32bitでレジスタ増えるモードがあれば、相当に高速であるだろうとは思うが
そんな命令セットになってないし…
0973デフォルトの名無しさん2009/06/24(水) 16:41:49
最低限このくらいは読まないと。
http://www.amazon.co.jp/Computer-Architecture-Quantitative-Approach-Kaufmann/dp/0123704901
0974デフォルトの名無しさん2009/06/24(水) 17:55:27
テンプレートを使ったコードのコンパイルエラーがもっと見やすくならない
ものか。あれでSTLを使うのに恐れをなす初学者は多いだろうな。
0975デフォルトの名無しさん2009/06/24(水) 18:17:53
conceptが完成の暁には〜
0976デフォルトの名無しさん2009/06/24(水) 18:19:42
>>974
ttp://www.bdsoft.com/tools/stlfilt.html
0977デフォルトの名無しさん2009/06/24(水) 18:37:27
>>976
おお？
何じゃこれは？
09789772009/06/24(水) 18:38:43
なつたん: STLFilt
ttp://natu.txt-nifty.com/natsutan/2007/08/stlfilt.html

あまり変わらないような気もするな。
0979デフォルトの名無しさん2009/06/24(水) 18:42:18
>>976
一時期使ってたことあったのだが、何でやめたのか思い出せない。
また使ってみるか。
0980デフォルトの名無しさん2009/06/24(水) 21:05:49
ActivePerlを入れるのが面倒なのとコマンドラインでしか
使えないので使い勝手が悪かったので俺はやめた
0981デフォルトの名無しさん2009/06/26(金) 00:46:51
redhat linux 8.0 で自分のディレクトリにgccインストールしようとしたら

make[2]: *** [configure-stage1-target-libgcc] エラー 1
make[2]: 出ます ディレクトリ `/***/src/gcc-4.3.3'
make[1]: *** [stage1-bubble] エラー 2
make[1]: 出ます ディレクトリ `/***/src/gcc-4.3.3'
make: *** [all] エラー 2

てな エラーが出るんだが、これってどう意味？
ググったけどあんまり参考にならなかった。
0982デフォルトの名無しさん2009/06/26(金) 00:55:10
もうちょっと上のほうのメッセージがないとなんとも

もうちょっと上のほうで xgcc だかなんだかがエラーはく
→ それを起動してた make がエラーになる
→ その make を起動してた make がエラーになる
って感じになってて、そのメッセージじゃその最後の2つだけしかわからないから、根本的な原因がわからない
0983デフォルトの名無しさん2009/06/26(金) 01:21:23
make cleanして
もう一回makeしたらこういうのが出ました。

checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile

0984デフォルトの名無しさん2009/06/26(金) 01:27:06
disk fullなんじゃねーの？
0985デフォルトの名無しさん2009/06/26(金) 01:27:19
使っているgccが古すぎて新しいgccが正しく作れない。
なんて事もあったりする。

RH8じゃ元々入ってるのはかなり古くないかい？
0986デフォルトの名無しさん2009/06/26(金) 01:33:22
>>984
diskはフルじゃないこと確認した。

>>985
調べてみたけどgcc バージョン 3.2だ。2002年だけど、これってかなり古い部類？
0987デフォルトの名無しさん2009/06/26(金) 01:57:57
gmp,mpfrがらみ？
0988デフォルトの名無しさん2009/06/26(金) 02:04:32
>>987
それは両方とも最新のをインストールしてあります。
0989デフォルトの名無しさん2009/06/26(金) 02:09:43
上のエラーでググるとインストール先が変でxgccが起動してないってのがあった。
0990デフォルトの名無しさん2009/06/26(金) 04:31:46
>>986
gcc-3.4.6でgcc-4.1.1のクロスコンパイラ作ろうとしたら、
libgcc作る所でxgccがInternal Error吐いたことがあった。

gcc-4.3.3にしたら問題なし。





0991デフォルトの名無しさん2009/06/26(金) 07:24:07
configureの段階でバイナリ吐けないってlibcのヘッダが入ってないとかでないの？
09929812009/06/26(金) 16:39:35
config.logから関係ありそうな部分抜き出してみた。
configure:3251: checking whether the C compiler works
configure:3257: ./a.out
configure:3260: $? = 0
configure:3277: result: yes
configure:3284: checking whether we are cross compiling
configure:3286: result: no

configure:3630: gcc -c -g -O2 conftest.c >&5
conftest.c:2: parse error before "me"

configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h. */
|
| int
| main ()
| {
| exit (42);
| ;
| return 0;
| }
0993デフォルトの名無しさん2009/06/26(金) 19:55:13
それはstage1のtarget-libgccのconfig.logなの？
0994デフォルトの名無しさん2009/06/26(金) 21:00:16
いや、makeする前のconfigureのログだと思う。
>>983のエラーの後にfor more detail see cofig.logとか何とか書いてあったので見てみたわけです。
0995デフォルトの名無しさん2009/06/26(金) 22:22:41
stage1-gcc/cc1 --help
とかやって、コンパイラ本体が動くか確認してみては？
09969812009/06/26(金) 23:30:37
>>995
すまん、それはそのまま
% stage1-gcc/cc1 --help
って打ち込めって事で合ってる？
0997デフォルトの名無しさん2009/06/27(土) 00:09:59
もうだめかも分からんね
0998デフォルトの名無しさん2009/06/27(土) 04:53:12
エラーをエラーと見抜けないと(gccを使うのは)難しい
0999デフォルトの名無しさん2009/06/27(土) 08:29:20
999
1000デフォルトの名無しさん2009/06/27(土) 08:31:04
1000
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。