5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

GCCについて part3

1 :デフォルトの名無しさん:03/12/27 09:20
単発質問から始まったGCC(GNU Compiler Collection)について語るスレ。
あまり勢いはないが地味に逝こう。

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

前スレ
・GCCについて part2
http://pc2.2ch.net/test/read.cgi/tech/1046179115/
・GCCについて(過去ログ倉庫)
http://pc2.2ch.net/tech/kako/1007/10077/1007731543.html

関連スレ
・cygwin + mingwn + gcc 相談室
http://pc2.2ch.net/test/read.cgi/tech/1058134693/
・gcjって使ってる人います?
http://pc2.2ch.net/test/read.cgi/tech/1046627795/


2 :デフォルトの名無しさん:03/12/27 09:24
2ゲット

3 :デフォルトの名無しさん:03/12/27 11:18
乙かれー >>1

4 :デフォルトの名無しさん:03/12/27 11:39
m9( `Д´)

5 :982:03/12/27 15:22
5ゲット


6 :nokai:03/12/27 15:26
http://www.nokai.ne.jp/
君たちのような頭の悪すぎる人たちはここへ来なさい

7 :デフォルトの名無しさん:03/12/27 16:51
他スレの話で知ったんだけど、
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12435
これって、「バグ」ですよね?

だってせっかく型にアラインメント指定したのに、
配列に入れたらインスタンスのアライメントが保証されないとか困るっしょ。
その型のポインタ受け取る関数に配列の要素渡してあぼーんとか泣くっしょ。

8 :デフォルトの名無しさん:03/12/28 04:16
>>7
先頭要素だけアラインメント指定を遵守して、ポインタ演算はアラインメント指定を
無視してくれてる模様。

9 :ヽ(´ー`)ノ:03/12/28 20:13
>>1
前スレの 998-1000 わろた。

10 :デフォルトの名無しさん:03/12/31 22:36
GCCステータス・アップデート
ttp://japan.linux.com/desktop/03/12/29/1419225.shtml

3.4以降から採用の新しいC++パーサとPCHの話題が載ってる。

11 :デフォルトの名無しさん:04/01/02 11:04
今年はプリコンパイラが導入されますように。

12 :デフォルトの名無しさん:04/01/02 23:40
海外掲示板用オフラインリーダーを作るスレ
http://pc2.2ch.net/test/read.cgi/tech/1072883528/

海外でよく使われていうる掲示板スクリプト
専用のオフラインリーダー作って下さい。

必要な条件はID、PASSを管理できること、
OpenJaneみたいな三面型の見た目。
簡単にローカライズできるように言語ファイルを採用

13 :デフォルトの名無しさん:04/01/04 21:11
ここを紹介されて来ました。マルチポストですみません。
gcc-3.3.1なのですが、ソースをコンパイルするとき-I./includeを付けると、
ソース中でインクルードしているpthread.hの内部で未定義エラーが
でます。実際に-I./includeが必要であってもなくても、付けるだけでエラーが
出ます。もちろん、付けなければコンパイルは通ります。

エラーの原因はデフォルトの検索パスが無視されているため起こるようなの
ですが、これを回避する方法はないでしょうか。
#問題の簡略化のため、このディレクトリは使用しないでいますが、本当は
#必要なヘッダファイルがあるので使いたいのです。

$ gcc test.c -I./include -c
In file included from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/include/pthread.h:664,
from test.c:6:
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/include/bits/sigthread.h:41: error: 構文解析エラー before '*' token

14 :デフォルトの名無しさん:04/01/04 21:12
たのむよ、まだこっちを使えよ。新しくスレたてんなよ!!
http://pc2.2ch.net/test/read.cgi/tech/1071613279/

15 :デフォルトの名無しさん:04/01/04 21:27
>>13
includeのディレクトリがbinの中にあるの?

16 :デフォルトの名無しさん:04/01/04 21:29
>>13
> エラーの原因はデフォルトの検索パスが無視されているため
../include にシステム標準のヘッダファイルと重複する名前のファイルが
置いてないか? あるいはファイル名は違っても、インクルードガードが
一致しているとか。

17 :13:04/01/04 22:13
>>13 まさかね。gccは自分でソースからインスコしたものです。
ちなみに、TL8WSなので、元からあるgcc-2.96でも同じ現象が出ます。
>>16 レスサンクス。重複するファイルはありません。
ただ気付いたことといえば、crypt()なんかを使う場合、__USE_XOPENとか
unistd.hをインクルードする直前にdefineしなければ、undefされてしまう
ような、面倒くさい事象があるのには気付きました。(-Wallとか-Wシリーズ
のオプションを幾つも付けた場合に警告されるので分かる)

元々はこっちにポストしてました。
http://pc2.2ch.net/test/read.cgi/tech/1072212403/658-659

18 :デフォルトの名無しさん:04/01/04 22:23
>>17
とりあえず gcc -v して結果貼り付け。

19 :13:04/01/04 22:28
>>17 リンク先見てもらえればそのまま張ってあります。659のほうをドゾー。

20 :デフォルトの名無しさん:04/01/04 22:30
>>19
ちゃうちゃう。

% gcc test.c -I./include -c -v

ここまでつけて。そうすると include パスとかずらずら出てくるはずだから。


21 :13:04/01/04 22:46
>>20 レスありがとうございます。
あー失礼しました。テストしたいのですが出先からのアクセスですので
レスは長く後になります。(TT

ヒントをありがとうございます。チェックしてみます。

22 :デフォルトの名無しさん:04/01/06 17:30
で、どうなったんだろう・・・・
レス先間違えまくっているあたり注意力に問題がありそうだけど。

23 :デフォルトの名無しさん:04/01/07 16:43
>>7
struct {
  char c;
  achar a;
} b;

 printf("sizeof(achar):%u\n",sizeof(achar));
 printf("&b: %p\n", &b);
 printf("&b.a: %p\n", &b.a);

__aligned__は指定された型/変数が割り付けられるときに、
その先頭のalignmentを指定するだけ。
achar自体はあくまでもchar。
じゃなきゃ通常のchar*を受け取る関数が全く使えなくなる。


24 :7:04/01/07 21:48
>>23
現状での挙動は分かってます。

でも、現状の挙動では>>7で書いたような問題が防げません。
aligned指定でsizeofも変わりうる挙動をしていれば、>>7の問題も、解決しますし、
配列の先頭だけにalignmentを指定したければ、配列に対して指定すればよい話です。

ですが、alignedの挙動を変更すると、char*にachar*を渡しているような
現状動いているコードが壊れてしまいます。

sizeofも変わりうるaligned指定を別名で作り、
sizeofが変わってしまった場合はポインタが互換しないようにする、
というのは、どうでしょうか?

ちなみに、bugzilla の id=12435 は Andrew Pinski によって 12/28 に
「バグじゃない」ってことで終了されてしまっています。

25 :デフォルトの名無しさん:04/01/07 22:46
>>24
> aligned指定でsizeofも変わりうる挙動をしていれば、>>7の問題も、解決しますし、
> 配列の先頭だけにalignmentを指定したければ、配列に対して指定すればよい話です。
本当に、それで他の部分に影響でないの?

個人的には配列にたたき込みたいなら構造体にして、padding 自分で詰めれば良いと思うが。

26 :7:04/01/07 23:10
>>25
> 本当に、それで他の部分に影響でないの?

「それ」とは、
「aligned指定でsizeofも変わりうる挙動」をすることですか?
「配列の先頭だけにalignmentを指定したければ、配列に対して指定」することですか?

> 個人的には配列にたたき込みたいなら構造体にして、padding 自分で詰めれば良いと思うが。

アラインメントを指定したいときに、aligned属性があるのなら、
それを使って行うのが自然だと思います。
正しくpaddingを詰めるためには、必要な情報もどうにかしてひねり出さないといけないですし、
構造体にしてしまって、意味薄いフィールド名を考えるのも使うのも面倒です。

27 :デフォルトの名無しさん:04/01/07 23:17
GCCが卵に見えるからだろうね

28 :デフォルトの名無しさん:04/01/07 23:18
ちょっと考えても問題出るな。


29 :デフォルトの名無しさん:04/01/07 23:48
>>26
> 「それ」とは、
どっちでも良いけど。

アライメントの問題を解決したが、他の部分で既存のコードが動かなくなるような致命的な
問題が出たら意味ないわけで。現状の gcc の設計と矛盾しないなら、パッチ作って送れば
対応してくれると思うぞ。

30 :ヽ(´ー`)ノ:04/01/08 05:31
というか id=12435 は俺はバグじゃないと思う。>>24 の解決策の方が相当不味いと思われ。
納得できないのなら ML や Pinski 氏に質問してみたら?それか >>29 が言うように
パッチ書いてみるかだな。

31 :7:04/01/08 08:58
>>30
今あるalignedの挙動を変えてしまうと不味いのはわかったのですが、
アライメント指定に伴ってsizeofも変わること自体が「相当不味い」のでしょうか?

挙動が変わるので、新しい別の属性キーワードを作る必要があるとおもいます。
そしてその属性をつけた型および値を指すポインタは
オリジナルの型と互換しない(int*とchar*の関係になる)ようにする必要がありそうです。

この方針で問題なければ、パッチを書いてみよう
・・・かなぁ、と思います。
ほかにも不味いところが残っていれば指摘して欲しいです。

32 :デフォルトの名無しさん:04/01/08 19:08
>>31
まずすぎるというか、
それじゃ結局別の型を作るだけだろ?
>>25のいうようにalignof使って構造体作れ。

33 :デフォルトの名無しさん:04/01/08 20:46
どうしてもバグにしたい人がいるようだ

34 :7:04/01/08 21:50
>>32
> それじゃ結局別の型を作るだけだろ?
そうです。いま欲しがってる属性を xxx_aligned とすると、
 typedef int more_aligned_int __attribute__ ((xxx_aligned (8)));
この宣言でmore_aligned_int型の値はすべて8バイト境界に割り当てられます。
 void f( more_aligned_int* p );
この宣言で、f()は8バイトアラインが保証されている整数型へのポインタを受け取ります。
無理なキャストをはさまない限り、
この関数に不正なアライメントの値を渡すコードはコンパイルできなくなります。

現状のalignedの挙動では、上記のような宣言をしても、
f()の定義側で引数pが正しくアラインされていることを期待できません。

今回の件を知らなければ、こんな関数を作って不可解なバグに悩まされていたかもしれません。

ドキュメントに"force the compiler to insure (as far as it can) that ..."とあったので、
やっぱりバグではなく、こういう仕様のようです。
パッチ書くより、「この"as far as it can"をもっと具体的に書いとけ」と突っ込むのが良いように思います。

35 :デフォルトの名無しさん:04/01/08 22:19
(´-`).。oO(いったい何がしたいんだろう?)

36 :デフォルトの名無しさん:04/01/08 23:22
>>34
typedef は型に「別名」をつけるだけで、型を作成するものじゃないが。typedef したものが
別の型ってことになると、C/C++ の従来の typedef と意味が違ってしまうから、影響でか
すぎだと思うぞ。

矛盾しない形で gcc のソースコード改修できるのなら、パッチを作る事は止めないが。

37 :デフォルトの名無しさん:04/01/08 23:33
別の型には変わりないが、完全に互換性がある。

38 :デフォルトの名無しさん:04/01/09 00:01
>>36
typedef int const cint;
typedef int volatile vint;
typedef int iarray[2];
こんなのと同じ感じじゃないの?

39 :デフォルトの名無しさん:04/01/09 01:15
more_aligned_int* p

p++はどんなうごきすんねん

40 :7:04/01/09 01:21
>>39
(more_aligned_int*)((char*)p + sizeof(more_aligned_int))
得られたポインタはmore_aligned_intのアラインメント要求を満たす。
sizeof(more_aligned_int)は、sizeof(int)以上で最小の8の倍数になる。

more_aligned_int*からint*への変換はエラーにしないといけない。

41 :デフォルトの名無しさん:04/01/09 01:30
うざってー
構造体&paddingでなぜ不満? 却下である!

42 :デフォルトの名無しさん:04/01/09 02:03
本7うざい死ね

43 :デフォルトの名無しさん:04/01/09 02:05
>>34
> パッチ書くより、「この"as far as it can"をもっと具体的に書いとけ」と突っ込むのが良いように思います。
だったら今すぐそうすればいいだろが、誰も止めないぞ。
オープンソースである以上、必要だと思った人間が手を動かす。
今までもこれからもそうやって成り立っていくんだよ。
文句は言わないけど自分は手を動かさないってんじゃ話にならんわ。
独り言なら日記にでも書きたまえ。


44 :デフォルトの名無しさん:04/01/09 08:01
パッチ書いてもいいけど、ばらまかないでね。
迷惑だから。

45 :デフォルトの名無しさん:04/01/09 08:29
>>34
> 今回の件を知らなければ、こんな関数を作って不可解なバグに悩まされていたかもしれません。

それはGCCのせいじゃなくて、そんなおかしな設計したお前に責任がある。

46 :デフォルトの名無しさん:04/01/09 08:30
s/した/する/

47 :デフォルトの名無しさん:04/01/09 08:39
align関連はGCCの独自仕様なのだから、君が思った仕様と食い違っていても、
その仕様はくつがえらないし、もちろんバグではない。
問題視して欲しければ、GCCの仕様のままで通常使用したときに、致命的な
問題が発生することを示すか、他の仕様と論理的不整合が存在することを
示す必要がある。
それができなければ、ローカルパッチを作って、思う存分使えばいい。

48 :デフォルトの名無しさん:04/01/09 15:28
ttp://gcc.gnu.org/ml/gcc/2004-01/msg00504.html

GCCにPL/Iのフロントエンドをつけてる人が。

……今更使う人いるのかなぁ

49 :デフォルトの名無しさん:04/01/09 16:49
ちょっと使ってみたかったりして<PL/I
大昔バイトで使って以来書く事もなかたので。

50 :デフォルトの名無しさん:04/01/09 22:01
PL/1はいいぞー

Fortranもいい。 なんていうか、そそるものがあるんだよ


51 :デフォルトの名無しさん:04/01/09 22:03
>>50
魅力が全然分からん。
小一時間愛を語ってはくれんかね?

52 :デフォルトの名無しさん:04/01/10 03:56
名前指定ループ多段ブレイク

53 :デフォルトの名無しさん:04/01/10 09:15
gotoとどう違うんですか?

54 :デフォルトの名無しさん:04/01/10 11:15
>>51
使い手にナイスミドルのおじさまが多い。

55 :デフォルトの名無しさん:04/01/10 22:12
>>53
goto みいにどこにでも飛べるわけじゃなく、ループから抜けると言う意図がはっきり伝わる。(=読みやすい)

C/C++ にも欲しいよ。

56 :デフォルトの名無しさん:04/01/10 22:33
ラベル名を工夫すればはっきりと伝わると思うが。

57 :55:04/01/10 23:05
まあ、goto 文使ったってわかりやすいプログラムは作ることができるからね。
でも、「ラベル名を工夫すれば」と言う労力がかかるし、それができない奴もたくさんいるから。

(今見たら、>>55 日本語変だな。goto みいに → goto みたいに)

58 :デフォルトの名無しさん:04/01/10 23:21
> それができない奴もたくさんいるから。
L1,L2,・・・・,Lnとつけている俺のことか?

59 :デフォルトの名無しさん:04/01/10 23:25
>>58
アセンブラかよ !!

60 :デフォルトの名無しさん:04/01/11 00:03
>>55
そんなあなたにPerl

だいたい>>52程度でPL/Iへの愛を騙(ry

61 :デフォルトの名無しさん:04/01/11 00:23
>>57
break でも、それなりの名前つけないとダメだろう。

62 :デフォルトの名無しさん:04/01/11 00:38
>>55
ポインタ使えば?

63 :デフォルトの名無しさん:04/01/11 00:53
>>60
名前指定ループ多段ブレイク があれば何でもいいわけじゃないぞ。

>>61
どんな名前でも、「ループを抜ける」と言う意図は伝わるぞ。
どんなループなのかわからんと言うのはまた別の話だし。

>>62
ハァ ?
具体的に書いてみてくれ。

64 :デフォルトの名無しさん:04/01/11 02:53
>>63
邪悪な提案を1つ。

#define break_loop goto

65 :デフォルトの名無しさん:04/01/11 03:10
>>40

>more_aligned_int*からint*への変換はエラーにしないといけない。
C的には Warning で。

一時変数(ただの配列だけど)に aligned アトリビュート効かなくて
面倒な思いをした事は何度かあるけど、

>(more_aligned_int*)((char*)p + sizeof(more_aligned_int))
>得られたポインタはmore_aligned_intのアラインメント要求を満たす。
>sizeof(more_aligned_int)は、sizeof(int)以上で最小の8の倍数になる。

それなら当然一時変数も対応?ちょっとしたパッチじゃ済まんよ。

66 :デフォルトの名無しさん:04/01/11 05:18
挙動がわるいぞ?





今日どうしたんだろう…

67 :デフォルトの名無しさん:04/01/11 09:39
>>64
行き先ラベルの定義はどうやるんだ ?

C/C++ のマクロはここら辺が作りにくい。

昔さわった汎用機の PL/I のマクロは、substr() なんかの文字列操作は当たり前、FOR, WHILE 等の制御構文に加えて手続き/関数定義までできた。
ほとんどフルセットのインタープリタだったよ。
(使い出すと面白くて病みつきになるけど、はっきり言って や ・ り ・ す ・ ぎ。)

68 :デフォルトの名無しさん:04/01/11 10:35
C/C++のcppが貧弱すぎるという方が正しい物の見方だと思うぞ。
C++はtemplateやらinlineやらというマクロ構文のおかげでわりとましになったが、
もともとの育ちの悪さからくる使い勝手の悪さはついて回る。
cppとtemplateとかが連携していないから、デバッグ版のnew/deleteを作ろうと
すると行番号などを渡すのが難しかったりとかするし。

まあそこまでは望まないにしても、どうしてm4くらいにしなかったのかねえ。
条件分岐とか任意個の引数それぞれについて展開文を生成するくらいはやって欲しいと
時々思う。


69 :デフォルトの名無しさん:04/01/11 10:59
>>68
> まあそこまでは望まないにしても、どうしてm4くらいにしなかったのかねえ。
そりゃあ UNIX V6 書いた時代に m4 なかったからだよ。

70 :デフォルトの名無しさん:04/01/11 15:21
ああ、そりゃそうだな。確かに。


71 :デフォルトの名無しさん:04/01/11 15:34
http://www.tldp.org/HOWTO/GCC-Frontend-HOWTO

web crawl していて発見。
gcc のフロントエンド書いてる人なんているのかしらん。

72 :デフォルトの名無しさん:04/01/11 17:16
>>71
Wide Stadio

73 :デフォルトの名無しさん:04/01/12 19:54
gccソース配布にはTreelangというフロントエンド実装例示用言語のレクサとパーザとあれこれが付属.
GNU VHDLがGCCのフロントエンドとして書かれていたと思った.フランスの教育機関の中の人.

74 :デフォルトの名無しさん:04/01/12 23:48
gccのソースをチェックアウトしようと思って、cygwin bash shell から
 $ cvs -d :ext:anoncvs@savannah.gnu.org:/cvsroot/gcc co -P gcc
ってしてみたんですが、
 > savannah.gnu.org:接続がタイムアウトしました
 rsh.exe: can't establish connection
 cvs [checkout aborted]: end of file from server (consult above messages if any)
と表示されて取ってこれませんでした。
ここ2日ほど試してるんですけど、同じメッセージが出ます。
何が悪いんでしょうか?

75 :デフォルトの名無しさん:04/01/13 00:02
>>74
http://savannah.gnu.org/ 見るポ。

76 :デフォルトの名無しさん:04/01/13 01:56
>>75
ありがとうございます。
 $ CVS_RSH='ssh' cvs -d :ext:anoncvs@savannah.gnu.org:/cvsroot/gcc co -P gcc
これでいけました。

77 :デフォルトの名無しさん:04/01/13 22:18
-Wmissing-prototypes が、Cではちゃんと警告出すのに、C++だと動作しないみたいなんですが、
bugzillaに情報があるかどうか調べるにはどうしたらいいのでしょうか?

78 :デフォルトの名無しさん:04/01/13 22:36
つーかそもそもC++だとprototypeないとダメだろ。

79 :デフォルトの名無しさん:04/01/13 23:16
-Wmissing-prototypesは、グローバルな関数の定義に対して、
先にプロトタイプ宣言が無いことを警告するものです。
呼び出し側でエラーになるのとは別です。

80 :デフォルトの名無しさん:04/01/15 01:37
gcc開発してる人達ってこれが本職なの?
RedHatやSuSEが金出して雇ってるのかな。

81 :デフォルトの名無しさん:04/01/15 12:44
SuSEは買収されたYO

82 :デフォルトの名無しさん:04/01/15 20:53
みんなRedHatのことを悪くいうけど、
GCCの開発者の多くはRedHatだよな。
ああいう会社は大事にしないといけない。
オプソ注はガキだから、独占商売してる!
とかうるさいけど。だったらお前がGCC作れ、と。

83 :デフォルトの名無しさん:04/01/15 21:57
>>80
どっちも金出してる。
勤め人が片手間でこなせる作業量じゃないし。

>>82
Cygnusから流れただけやん。
金にならんからクビって事がないことを願おう。


84 :デフォルトの名無しさん:04/01/17 13:47
流れたっつーか買収されたっつーか。
でもRedHat Linuxやってる連中と旧Cygnusの連中の間には溝がある
ような気がしないでもない。何年か前、リリース版じゃないgcc 2.96を
RHに載せて出荷しちまったとかでgccチームが抗議文出してたしな。

85 :デフォルトの名無しさん:04/01/24 19:23
gccint.texiをHTMLで読もうと思って、gccのソースディレクトリ(以下では GCC )から、
 $ makeinfo -Igcc/doc -Igcc/doc/include --html -ogcc/doc/HTML/internal gcc/doc/gccint.texi
としてみました。
でも以下のようなメッセージが表示されて、index.htmlが生成されません。
 GCC/gcc/doc/HTML/internal/index.html: TOC should be here, but it was not found
 GCC/gcc/doc/HTML/internal/index.html: TOC should be here, but it was not found
 makeinfo: Removing output file `GCC/gcc/doc/HTML/internal/index.html' due to errors; use --force to preserve.

texiのことは良く分からないですが、テキストエディタでgccint.texiのなかを覗いてみたところ、
メニューっぽいものは書いてあるようです。
index.htmlをきちんと(--force使わずに)生成するには、どうしたらいいんでしょうか?

86 :デフォルトの名無しさん:04/01/24 22:05
>>85
gcc-3.3.2/gcc/docディレクトリに移動して、
$ makeinfo -Iinclude --html gccint.texi
だけで問題無くできたけど、ちなみに
makeinfo (GNU texinfo) 4.6です。

87 :デフォルトの名無しさん:04/01/24 22:58
>>86
レスありがとうございます。
こちらの環境はcygwinで、makeinfoのバージョンは(GNU texinfo) 4.2でした。
バージョンの古さが原因の問題なのかもしれません。

で、望むものはgccのサイトに置いてあるのに気付いたので、
そちらを使わせてもらうことで解決しました。

88 :デフォルトの名無しさん:04/01/30 01:17
age

89 :デフォルトの名無しさん:04/02/09 13:54
C#のフロントエンドやMSILを出力するバックエンドを
作るような話はあるんでしょうか?3.5以降になるのかもしれませんが。

90 :デフォルトの名無しさん:04/02/12 16:14
makedepend が g++ に対応していなくて cstddef や cstdio が探せない
どうしたらいい?

91 :デフォルトの名無しさん:04/02/12 20:19
g++ -M

92 :90:04/02/13 02:11
>>91
makefileのDO NOT DELETE This line以降を書き換えるようにできないでしょうか?

93 :デフォルトの名無しさん:04/02/13 09:44
> makefileのDO NOT DELETE This line
なんですかそれは?

94 :デフォルトの名無しさん:04/02/13 09:46
sed '/DO NOT DELETE This line/q' Makefile > Makefile.tmp
g++ -MM $(SRCS) >> Makefile.tmp
mv -f Makefile.tmp Makefile


95 :ヽ(´ー`)ノ:04/02/13 10:40
俺なら include するかなぁ。

Makefile.dep: $(SRCS)
g++ -MM $(SRCS) > Makefile.dep

# dependencies
.include Makefile.dep

構文これであってたっけ?(;´Д`)>
最近は専ら automake/autoconf だから自分で Makefile 書かなくなったな。

96 :デフォルトの名無しさん:04/02/13 10:59
>>95
> Makefile.dep: $(SRCS)
> g++ -MM $(SRCS) > Makefile.dep
追記じゃなければ -MMF Makefile.dep でもいい。

> .include Makefile.dep
BSD make?
たしかBSD makeは.dependってのを自動的にincludeしてくれると聞いたような
気がするので、こうするとGNU makeとBSD makeでは共通にできる。

# Makefile
.depend: $(SRCS)
        g++ -MMF $@ $(SRCS)

# GNUmakefile
include Makefile
include .depend


97 :ヽ(´ー`)ノ:04/02/13 11:26
> 追記じゃなければ -MMF Makefile.dep でもいい。
10ヘー(・∀・)⊇


> BSD make?
あぁ、先頭に . がいるのは BSD make だったか。
間違えますた、スマソ。

98 :デフォルトの名無しさん:04/02/13 11:49
ttp://make.paulandlesley.org/autodep.html
ここなんかどよ。(gcc -Mの項)


99 : :04/02/20 07:02
gcc -laaa -lbbb main.o →リンク失敗
gcc -laaa main.o /usr/lib/libbbb.a →リンク成功

/usr/lib/ には libaaa.a も libbbb.a もあるし、
libaaa.a は正常にリンクされているのに。
なぜでしょうか?

100 :デフォルトの名無しさん:04/02/20 07:07
朝から釣りか。

101 :デフォルトの名無しさん:04/02/20 07:49
エラーメッセージ見りゃ見当つくだろ。



102 :デフォルトの名無しさん:04/02/20 10:01
gcc main.o -laaa -lbbb
いじょ

103 :デフォルトの名無しさん:04/02/20 10:03
3.3.3は話題にもならない?

104 :デフォルトの名無しさん:04/02/20 10:08
g++のtemplateもかなり良くできてきたし満腹状態。
g++拡張でtypedef templateが付いたら教えてねん。

105 :デフォルトの名無しさん:04/02/20 11:28
g++のコンパイル速度って、こんなもん?
体感できるほどPCHで劇的に変わるんでしょうか。

106 :デフォルトの名無しさん:04/02/20 17:07
>>105
3.4は普通に使えるから、自分で試してレポートよろしこ
FTP://ftp.iij.ad.jp/pub/gcc/snapshots/3.4-20040218/gcc-3.4-20040218.tar.bz2

107 :デフォルトの名無しさん:04/02/22 12:47
適当に age とこうか.

>>103
そもそもリリースのアナウンスって流れたっけ ?
ftp mirror に行きわたるのを待ってると言ったっきりのような.

108 :105:04/02/22 19:47
>>106
サンクス。g++自体のコンパイルに時間がかかりそうだけど、
おわったら試してレポートします。

109 :デフォルトの名無しさん:04/02/22 19:57
>>107
> そもそもリリースのアナウンスって流れたっけ ?
まだだけど。でも ttp://gcc.gnu.org/releases.html では
とっくに出たことになってるんだよなぁ・・・。

ftp.gnu.org にないから気づかなかったけど、ミラーによってはもうあるぽ。

# 普通ミラーに行き渡るのに一週間もかからないよなぁ・・・。

110 :105:04/02/22 22:12
やってみました。cygwin上の
gcc version 3.4.0 20040218 (prerelease)
なg++です。比較の対象にしたのは、3.3.1です。

結果としては、コンパイルの速度はあまり変わらなかったけど、
吐かれたバイナリの実行速度が結構速くなってました。
ってこれじゃPCHと関係ないですよね。
俺がやり方間違えたかな…参考にならないレポートですんません。

111 :デフォルトの名無しさん:04/02/22 22:19
PCHてなにもしなくても効果するん?
設定ファイルとか、オプションとか必要ないん?

112 :デフォルトの名無しさん:04/02/23 00:27
今見たら ftp.gnu.org にも 3.3.3 置いてあったよ.



113 :デフォルトの名無しさん:04/02/23 10:26
3.3.4のはなしもあるみたい。

114 :デフォルトの名無しさん:04/02/23 11:17
>>110
最適化が上がったけどコンパイル時間が増えなかった。
と考えると効果あり?

115 :デフォルトの名無しさん:04/02/23 11:27
PCHを使うにはオプションが必要だった気がしたけど

116 :デフォルトの名無しさん:04/02/23 16:29
>>96
サブディレクトリを$(SRCS)に含んでいるとうまくいかないのですが何か方法ありますか?

SRCS := ${SRCS} misc.cpp
SRCS := ${SRCS} foo.cpp
SRCS := ${SRCS} subdir/window.cpp

てな状態の時の出力が

misc.cpp: misc.h
foo.cpp: foo.h
window.cpp: subdir/window.h # subdir/window.cpp : subdir/window.h になって欲しいのに!!

のようになってしまうのでつ。

117 :デフォルトの名無しさん:04/02/23 18:01
生成ルールのターゲットになるのは *.cppじゃなくて *.o だろ?

-oオプションで指定しない限り,コンパイルしたオブジェクトファイルは
カレントディレクトリに作られるので
window.o: subdir/window.cpp subdir.window.h
となって当然だと思う。

infoを見ると、-MT target というオプションをつけると変更できるようなので、
どうしてもというなら、${SRCS}についてループを回せばできるんじゃないかな。



118 :116:04/02/23 21:27
>>117
>生成ルールのターゲットになるのは *.cppじゃなくて *.o だろ?
いっけね、うっかりしてましたです。

>infoを見ると、-MT target というオプションをつけると変更できるようなので、
>どうしてもというなら、${SRCS}についてループを回せばできるんじゃないかな。

-MT はうまくいきましたです。ありがとうございます。
ループを回すっていうのは↓みたいな感じでしょうか?GNUのmake専用になっちゃうんすかね?
もう少し賢いやり方あったら教えてもらえると嬉しいです。

depend:
$(RM) Makefile.dep
$(foreach src, $(SRCS), g++ -MM -MT $(src:.cpp=.o) $(src) >> Makefile.dep;)


119 :デフォルトの名無しさん:04/02/23 22:49
depend:
  for s in $(SRCS); do g++ -MM -MT `echo $$s | sed 's/\.cpp$$/.o/'` $$s; done > Makefile.dep
でいいんじゃないの? (非GNU make依存)

120 :デフォルトの名無しさん:04/02/25 06:15
3.3.3 あなうんすきたーage

121 :デフォルトの名無しさん:04/02/29 00:27
tree-ssaのfrozeきてたー
gcc/ssa-*をさっそく調べないと。

122 :デフォルトの名無しさん:04/02/29 15:46
ソースからライブラリを指定したいのですが、
VCの
#pragma comment (lib, "***.lib")
に相当するものはGCCにあるのでしょうか?


123 :デフォルトの名無しさん:04/02/29 15:59
>>115
試したのがしばらく前なので、状況変わってるかも知れんが。俺が試したとき
には、ヘッダファイルを事前にコンパイルしておく必要があった。

% gcc foo.h

これで #include "foo.h" しているファイルをコンパイルすると、勝手に
プリコンパイル済みヘッダが使われた。

あと VC の stdafx.h のように「よく使うヘッダファイルを全部 #include する
だけのヘッダ」を用意して、そいつをプリコンパイルしておくと良いみたい。
多数のヘッダを個別にプリコンパイルしても、あまり速くならなかったよ。

124 :デフォルトの名無しさん:04/02/29 16:19
おれもPCH使ってみたけど、遅いのはインクルードファイル処理じゃ無いから全然
速くならなかった。
Cで巨大ファイルインクルードしてないと意味ないんじゃないか?
またはC++で巨大汎用テンプレートをインクルードするけどほとんど
インスタンス化しない場合とか。

致命的なのはmakeファイル作り替えないといけない点。

125 :デフォルトの名無しさん:04/02/29 16:50
>>124
つまり boost::* 用ってことでFA?

126 :デフォルトの名無しさん:04/02/29 17:19
>>121
英語は全っ然読んでないんだけど、
http://gcc.gnu.org/projects/tree-ssa/#ssa
から察するに「もう一段かませてもっと最適化」って事? 何が新しいの?

127 :デフォルトの名無しさん:04/02/29 17:34
Static Single Assignment使ってるから、
部分冗長性の検出とか定数伝搬がより賢くなる可能性があるんでしょ。
言語に依存しないレベルで、かつ、RTLや生成コードよりもう少し抽象度の高いところで。

128 :デフォルトの名無しさん:04/02/29 17:40
>>122
俺も知りたい
便利なんだよな

129 :デフォルトの名無しさん:04/02/29 17:48
setjmpの関数アドレス取得しようとして数十分はまった。

>XXXX.c:77: `setjmp' undeclared (first use in this function)
>XXXX.c:77: (Each undeclared identifier is reported only once
>XXXX.c:77: for each function it appears in.)

で、結局

setjmp.h
>#definesetjmp(x)_setjmp(x)

これが原因かよ
おいおい関数マクロたのむよ

mingwだけど。

130 :デフォルトの名無しさん:04/02/29 18:20
>>129
#include <setjmp.h> 忘れただけだろ ?

131 :デフォルトの名無しさん:04/02/29 18:28
>>130
ちーがーうー
setjmpが関数マクロだったから、
setjmpの名前だけ書くと未定義エラーになるわけ。
関数マクロは後ろの括弧が必須なの。
mingwのinclude/setjmp.h見りゃわかる。


132 :デフォルトの名無しさん:04/02/29 18:31
ただのマクロでいいものを関数マクロにする開発者もアホだが、setjmpのアドレスを得ようとする129もアホ。

133 :デフォルトの名無しさん:04/02/29 18:32
だからそれに気づいて
#ifdef __GNUC___
add_func(_setjmp);
add_func(_longjmp);
#else //その他
add_func(setjmp);
add_func(longjmp);
#endif
みたいにした。

んで、これには続きがあって、よく見たら対になるlongjmpは
関数マクロじゃない。
これに気づかずになんでだろーなんでだろーと
延々コンパイルを繰り返したさ。

#ifdef __GNUC___
add_func(_setjmp);
add_func(longjmp);
#else //その他
add_func(setjmp);
add_func(longjmp);
#endif
結局これが正解。

馬鹿野郎。


134 :132:04/02/29 18:33
つーかマクロって決まっているんじゃねーか
アホなのは129だけに決定
http://www.bohyoh.com/CandCPP/C/Library/setjmp.html

135 :デフォルトの名無しさん:04/02/29 18:33
>>132
スクリプト言語の実装で必要なんだよアホ

136 :デフォルトの名無しさん:04/02/29 18:34
>>134

はあ?どこに「マクロ」なんて書いてあるんだよアホ!

137 :デフォルトの名無しさん:04/02/29 18:35
あああ
>setjmpマクロ

アホはおれだけかよ!

悪かったな>>132

138 :デフォルトの名無しさん:04/02/29 18:36
>>127
というと相当広範囲な最適化が望めるって事ですね。そりゃ、スバラシイ。
(でも処理系専門外な自分は多分その素晴らしさの一割も理解できてない…)

139 :デフォルトの名無しさん:04/02/29 18:36
つーかね、わざわざ関数マクロにしてトラップ作る必要ねーだろ
ざけんな!>mingw


140 :132:04/02/29 18:38
>>137
俺も勉強になった。
マクロと決まっているのはassertだけじゃなかったのか。

141 :デフォルトの名無しさん:04/02/29 18:55
>>137
俺も知らなかった…K&RにもC99にもそう書いてあるわ。
あとマクロと決まってるのはva_*くらい?
std{in,out,err}が「マクロ」なのは、glibcのhackで有名、かな。
# Linuxな人は今すぐ grep stdin /usr/include/stdio.h

142 :デフォルトの名無しさん:04/02/29 19:19
マクロか疑似関数じゃないとsetjmp()は実装しにくいでしょ。
ほとんど全てのregisterを保存しないといけないわけだから。
関数で実装するとstackのrewindして(から)保存しないといけないからね。

C99でもgetcなんかもマクロなんじゃないの?

143 :132:04/02/29 19:20
そうだ。va_argとかもマクロだ(^_^;)
va_argは型名を受けるから関数として実装するのは不可能だもんな。

144 :デフォルトの名無しさん:04/02/29 19:33
>>142
そんなことないよ
mingwはmsvcrt.dll借用してるよ

145 :デフォルトの名無しさん:04/02/29 19:37
なことないって言われても…
Windowsは1CPU, 1プラットフォームでしょ。

146 :デフォルトの名無しさん:04/02/29 19:49
なんかトン沈下んな奴がいるな
145のことだが。

147 :デフォルトの名無しさん:04/02/29 20:16
>>142
getc・putc共に、C99でも「マクロ『かも』しれない」です。
これはC89から変わってないですよね。
# C99持ってない方、C99相当のJISがPDFで手に入ります。
# ttp://www.jisc.go.jp/ →JIS検索→JIS X3010 でどうぞ。

148 :デフォルトの名無しさん:04/02/29 20:30
>>142
別に関数で普通に実装できますがなにか ?
例えば、FreeBSD 4.8R/i386 + GCC 2.95 は関数で実装されてるよ。

149 :デフォルトの名無しさん:04/02/29 20:42
>>148
手元のi386なglibc-2.2.4でも、cygwinで使ってるnewlib-1.12.0でも、
setjmp()は関数です。もちろんソースは「.S」。
# マクロじゃなきゃ規格非準拠だ! って怒られたら、
# glibcのstdinみたく「Make them happy.」にすればいいって事なんだろう

150 :デフォルトの名無しさん:04/03/01 19:44
俺俺に聞け→勉強するぞ から流れてきました。ちょいと教えとくれ。
#include <stdio.h>
/* #define GLOBAL */
#ifdef GLOBAL
const int DragonKiller=15000,AngelRobe=3000,DragonShield=3500;
struct _item{ char *name; int price;
}ItemList[]={
{"ドラゴンキラー", DragonKiller},
{"天使のローブ", AngelRobe},
{"ドラゴンシールド",DragonShield},
};
#endif

int main(void)
{
#ifndef GLOBAL
const int DragonKiller=15000,AngelRobe=3000,DragonShield=3500;
struct _item{ char *name; int price;
}ItemList[]={
{"ドラゴンキラー", DragonKiller},
{"天使のローブ", AngelRobe},
{"ドラゴンシールド",DragonShield},
};
#endif

return 0;
}
GCC 3.3.1 で、GLOBAL無効だとOKなんだけど、
GLOBAL有効だとコンパイルエラーになるんだ。なんで?

151 :デフォルトの名無しさん:04/03/01 20:27
const qualifierのついた変数は定数ではない。

152 :デフォルトの名無しさん:04/03/01 20:28
ローカル変数とグローバル変数とでの違いが気になります

153 :デフォルトの名無しさん:04/03/01 21:11
グローバル変数は定数でしか初期化できない。
ローカル変数は初期化時点で決まっている値ならOK。

154 :デフォルトの名無しさん:04/03/01 22:39
つーかどこがGCC依存な話題なんだ??

155 :デフォルトの名無しさん:04/03/01 23:08
それ、VCだと通ったりするんじゃない?
そんなケースが前あった。

156 :150:04/03/02 00:13
>154
例えば ボーランドのbcc32とかだとローカルだろうがグローバルだろーが
"不正な初期化"となるのです

157 :デフォルトの名無しさん:04/03/02 00:20
>>156
ボーランドのはC99に準拠してなんでしょ。
http://gcc.gnu.org/onlinedocs/gcc-3.3.3/gcc/Initializers.html#Initializers

158 :デフォルトの名無しさん:04/03/02 00:20
→してないんでしょ

159 :150:04/03/02 00:23
了解です。分かりました。

160 :105:04/03/02 21:48
すんません。PCHの話題の言いだしっぺです。
110で一度レポートしたのですが、冷静に色々やってみるとPCHが有効になっていなかったみたいです。

GCC(3.4.0 20040218 (prerelease))は/usr/local/以下にインストールしました。
自分がコンパイルを試したソースでは
#include <iostream>
#include <string>
...
などとなっていたので、/usr/local/include/c++/3.4.0の中で
g++ -x c++-header -c iostream
g++ -x c++-header -c string
...
とやって*.gchを作りました。その後でコンパイルをしたのですが、
g++ -H (...) 2>usedheaders
とやっても、usedheadersの中に*.gchが出てきません。infoが正しければ、「...!」と出てくるはずなんですが…。
何が足りないんでしょうか。

161 :デフォルトの名無しさん:04/03/03 18:09
ここで聞いていいのか分からないんですけど……。

libfoo.so や libfoo.a があったとして、その中から特定のシンボルだけ
削除したい場合ってどうすればいいですか?ソースはありません。

162 :デフォルトの名無しさん:04/03/03 19:00
>>161
やり方は知らないけど、なんでそんなことするの?

163 :デフォルトの名無しさん:04/03/03 19:31
関係ないけど、binutilsにELFの形式をチェックするような
ツールってある?

164 :デフォルトの名無しさん:04/03/03 19:40
>>163
readelfのことか?
http://itpro.nikkeibp.co.jp/linux/faq/200205-3.shtml


165 :デフォルトの名無しさん:04/03/03 20:21
>>161
.aはar使えばいいじゃん。ar知らずにどうやって.a作ったのさ。
.soは知らん。

166 :デフォルトの名無しさん:04/03/03 21:03
>>163
objdump -xじゃ不満かい?

167 :デフォルトの名無しさん:04/03/04 22:15
gcc3.3.3の標準ライブラリのソースを見たいのですが、
どのディレクトリにあるのでしょうか?

168 :デフォルトの名無しさん:04/03/04 23:35
標準ライブラリって、Cの?
それは普通言語処理系じゃなくてOSが持つ。


169 :167:04/03/05 00:01
レスどうもです。
説明不足ですみません。
Cのprintf, scanfなどのANSI標準ライブラリ関数のソースのことです。
gccのソースコードから抜き出したいと考えてたのですが…

170 :デフォルトの名無しさん:04/03/05 00:08
抜き出してどうすんのん? ライセンスあるよん。
glibcの中にあるの。

171 :167:04/03/05 00:18
なるほどglibcにあったのですね。
Cの勉強をしていて、あるライブラリ関数がどのように実装されているのか
興味があって、探し求めていたんです。
どうもありがとうございました。

172 :デフォルトの名無しさん:04/03/05 01:31
gccが使う標準Cライブラリはglibc以外にもいろいろあるわけだが、

173 :デフォルトの名無しさん:04/03/12 14:00
コンパイルしたプログラムに
どのバージョンでコンパイルしたか埋め込める#define とか 関数ってあるの?

int main(){
printf("thist complile by%s",#GCC_COMPILE_VERSION);
}

という風にしたいんだけど

174 :デフォルトの名無しさん:04/03/12 14:23
>>173
__GNUC__ と __GNUC_MINOR__ で何とかならないか。

175 :デフォルトの名無しさん:04/03/12 14:25
大抵のコンパイラは自身を識別する定義済マクロを用意していて、
(メジャー)バージョン番号がその値になっていることが多い。

gccなら
__GNUC__ と __GNUC_MINOR__ (それぞれ整数)。
__VERSION__ もある (こちらは文字列)。


176 :173:04/03/12 15:27
>>174 >>175
ありがとう

177 :デフォルトの名無しさん:04/03/13 00:58
__atribute__

178 :デフォルトの名無しさん:04/03/13 02:58
>>176
gcc -vも覚えれ

179 :デフォルトの名無しさん:04/03/13 14:10
gccの解説本で良いのありますか?


180 :デフォルトの名無しさん:04/03/13 15:03
>>179
infoはだめか?
info以上の情報があるなら俺も知りたい。

181 :デフォルトの名無しさん:04/03/14 20:10
うーん。
2chってこんなに低レベルだったの?

# って嘆いてみるテスト

182 :デフォルトの名無しさん:04/03/14 20:33
特に若い人に、調べる能力の低いのが多いね。

183 :デフォルトの名無しさん:04/03/14 20:42
2chにレベルもクソもないと思うが

184 :デフォルトの名無しさん:04/03/14 21:00
コンピューティングが低年齢の人に解放されたってことで喜んでいいんじゃない?
といってもこんな所でクダ巻いてる奴なんて小学校の頃から触ってるか

低レベルすぎる質問は無料コンパイラとして初心者の入門用にと
宣伝されてるから仕方ないと思われ

185 :デフォルトの名無しさん:04/03/14 21:29
低レベル云々の煽りは馬鹿の証し

186 :デフォルトの名無しさん:04/03/14 21:41
>>181って逆切れ厨でしょ。文句あるなら自分で調べろよ。

187 :デフォルトの名無しさん:04/03/21 14:55
gccってどうやってインストールするんですか?

188 :デフォルトの名無しさん:04/03/21 15:03
>>187
./configure --prefix=/usr/local
make bootstrap
make install

確かこんな感じ。インストール先ディレクトリは./configureに--prefixオプションで指定する。

189 :デフォルトの名無しさん:04/03/21 15:03
configure && make all && make install

190 :187:04/03/21 15:18
すいません、初心者なんで何をどうすればいいかも
分からないんです。
参考になるページか何か知っていませんか?
自分でも調べたけどわかんなくて、、、、

191 :デフォルトの名無しさん:04/03/21 15:33
もっと質問の仕方ってものがあるだろうし、
'初心者'は免罪符でもなんでもない
とりあえずOS環境を書けよ
まあ答えは出てるけどさ

192 :デフォルトの名無しさん:04/03/21 15:35
>>190
本家:http://gcc.gnu.org/
インストール:http://gcc.gnu.org/install/
翻訳:http://www.excite.co.jp/world/url/body/?trans_type=enja-ATL&body=http://gcc.gnu.org/install/

193 :デフォルトの名無しさん:04/03/21 15:41
おまいら釣りにひっかかってあげるやさしい奴

194 :デフォルトの名無しさん:04/03/21 15:47
>>191
すいません。
今度から気をつけます。
>>192
ありがとうございます。
>>193
釣りではありません。

195 :デフォルトの名無しさん:04/03/21 16:12
>>194
MinGWを使おう
http://pc2.2ch.net/test/read.cgi/tech/1042611308/

196 :デフォルトの名無しさん:04/03/21 16:17
それでもOS環境をかかない頑固な194。


197 :デフォルトの名無しさん:04/03/21 18:18
いきなり自動車免許を取ろうとせずに歩行者・三輪車・自転車……と
段階的にすすめてみてはどうだろう。



198 :デフォルトの名無しさん:04/03/21 20:09
歩行者です
gccってどうやって使うんですか?

199 :デフォルトの名無しさん:04/03/21 23:30
先行者です
キャノンってどうやって使うんですか?

200 :デフォルトの名無しさん:04/03/21 23:31
あなたには使えません

201 :デフォルトの名無しさん:04/03/22 11:47
お前ら面白すぎ

202 :デフォルトの名無しさん:04/03/22 12:52
3.4branchが切られてメインラインがいつのまにか3.5になってまつね。

203 :デフォルトの名無しさん:04/03/22 18:58
奇数バージョンは安定しないんだっけ?

204 :デフォルトの名無しさん:04/03/22 19:27
major>minorのうちは危ないというが、
奇数・偶数の区別はない。


205 :デフォルトの名無しさん:04/03/22 19:30
>>204
じゃあ3.3以上ならいいの?

206 :デフォルトの名無しさん:04/03/22 19:35
>>204
了解。

>>205
そういうジンクスがあるってだけで、
実際その通りってわけじゃないよ。

207 :デフォルトの名無しさん:04/03/22 20:50
printfの%pにint *等を渡すと警告が出る(要-ansi -pedantic)。
最初バグかと思った。void *じゃないと警告が出るのね。

208 :デフォルトの名無しさん:04/03/22 21:16
さすがpedantic。マゾ向けですな。

209 :デフォルトの名無しさん:04/03/22 21:44
>>207
>void *じゃないと警告が出るのね。

理由は何?

210 :デフォルトの名無しさん:04/03/22 21:57
>>209
なんだろう?
可変個引数ゆえにtype *がvoid *に変換されずにそのまま渡されるからかな?
そこまで文句をつけるかー!?って思うけど(だからこそpedanticなのかな)

3.3.2や3.3.3では出るけど、2.95.3では出ないね。

211 :デフォルトの名無しさん:04/03/22 22:31
| 7.19.6.1 The fprintf function
| 8
| p   The argument shall be a pointer to void. The value of the pointer is
|     converted to a sequence of printing characters, in an implementation-defined
|     manner.

と、void へのポインタって書いてあって、かつ、
>可変個引数ゆえにtype *がvoid *に変換されずにそのまま渡されるからかな?
かと思われ。

212 :デフォルトの名無しさん:04/03/22 22:37
さすが pedantic だ

213 :デフォルトの名無しさん:04/03/23 00:00
-ansi -pedanticだけじゃ警告出ないな。-Wall付けると出る。

214 :ヽ(´ー`)ノ ◆.ogCuANUcE :04/03/23 17:02
CFLAGS=-std=c99 -Wall -pedantic

だなぁ。みんな、-Wall だけなの?

215 :デフォルトの名無しさん:04/03/24 04:30
3.4はスケジュール通りだせるんでつかね。
Mitchellタソ、ブチ切れぎみですが・・・
GCCの開発は、いろいろ踏まえなくてはならないことが
多すぎてなかなか大変だとは思いますががんがってください。
応援しております。

216 :デフォルトの名無しさん:04/03/24 15:55
>>215
向こうで言ったれよ

217 :デフォルトの名無しさん:04/03/24 18:24
俺もそうおもた

218 :デフォルトの名無しさん:04/03/25 00:38
gc#出ないの?

219 :デフォルトの名無しさん:04/03/25 08:59
俺もそうおもた

220 :デフォルトの名無しさん:04/03/29 11:44
修正

単発質問から始まったGCC(GNU Compiler Collection)について語るスレ。
あまり勢いはないが地味に逝こう。

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

前スレ
・GCCについて part2
http://pc5.2ch.net/test/read.cgi/tech/1046179115/
・GCCについて(過去ログ倉庫)
http://pc5.2ch.net/tech/kako/1007/10077/1007731543.html

関連スレ
・cygwin + mingwn + gcc 相談室
http://pc5.2ch.net/test/read.cgi/tech/1058134693/
・gcjって使ってる人います?
http://pc5.2ch.net/test/read.cgi/tech/1046627795/

221 :デフォルトの名無しさん:04/03/29 12:38
更に勢いの無いスレ

祝・GCC 3.0リリース
http://pc3.2ch.net/test/read.cgi/unix/992942337/

222 :デフォルトの名無しさん:04/03/29 13:04
glibcコンパイル時は-fomit-frame-pointerを付けてはいけないのか。
くそー、俺の二時間を返せ。

223 :デフォルトの名無しさん:04/03/29 16:13
プリコンパイルヘッダ対応マダー?

224 :デフォルトの名無しさん:04/03/30 17:57
>>223
自分でビルドすればいいじゃん。

225 :デフォルトの名無しさん:04/03/30 18:08
>>224
ハァ?

226 :デフォルトの名無しさん:04/03/30 19:48
>>225
http://gcc.gnu.org/gcc-3.4/index.html
使えてるよ。

227 :225:04/03/31 01:39
>>224
スマソ
>>226
サンクス

228 :デフォルトの名無しさん:04/03/31 03:25
Appleのgccは独自のプリコンパイルヘッダ対応付いてるよ。
cpp-precompってやつ。

229 :デフォルトの名無しさん:04/04/20 09:49
conio.hをインクルードするには、
コンパイルするときにどのようなオプションをつければいいんですか?

230 :デフォルトの名無しさん:04/04/20 10:05
インクルードするのにオプションは必要ない

231 :デフォルトの名無しさん:04/04/20 10:06
いや、そのconio.hがサーチパスに入っていない場合は、-I<そのパス>が必要か

232 :229:04/04/20 10:13
>>231
stdio.hと同じディレクトリに入ってるんですが。

233 :デフォルトの名無しさん:04/04/20 10:19
では、>>229が抱えているのは別の問題。

234 :デフォルトの名無しさん:04/04/20 11:15
gcc3.4.0をインストールしてプリコンパイル済みヘッダを使おうとしたら
test.cc:1: sorry, unimplemented: had to relocate PCH
というメッセージが出ました。ホントに実装されてないんですか?
それとも私が何かおかしなことをしているんでしょうか。
実行した手順は以下のとおりです。

1.インストール
 ftp.dti.ad.jp から
   gcc-core-3.4.0-20040416.tar.gz と gcc-g++-3.4.0-20040416.tar.gz
 をコピー
 
 3つのディレクトリ /srcdir /builddir /usr/local/xp
 を作成して上記2つの .tar.gz ファイルを/srcdirに展開
 
 cd /builddir
 /srcdir/gcc-3.4.0-20040416/configure --prefix=/usr/local/xp --enable-language=c++
 make bootstrap
 make install
 
 /usr/local/xp/bin にパスを通す

2.使ってみる 
 /usr/local/xp/bin/g++ test.hh
 /usr/local/xp/bin/g++ test.cc
 ---- test.hhの中身 ----
#include <iostream>

 ---- test.ccの中身 ----
#include "test.hh"
int main() { std::cout << "hoge" << std::endl; return 0; }

235 :デフォルトの名無しさん:04/04/20 19:06
GCC 3.4.0 リリースage
ftp;//ftp.gnu.org/gnu/gcc/gcc-3.4.0/

236 :デフォルトの名無しさん:04/04/20 19:51
アナウンスはまだ出てない?
ChangeLog
ttp://gcc.gnu.org/gcc-3.4/changes.html


237 :236:04/04/20 19:52
あ、ChangeLogじゃないか。
変更点一覧だ。


238 :デフォルトの名無しさん:04/04/20 21:16
>>236
出てないけど、前もそうだったし、まぁいいかな、と。

239 :デフォルトの名無しさん:04/04/20 21:53
アナウンスがない以上はバイナリの差し替えもありうるということですよね。

240 :デフォルトの名無しさん:04/04/21 00:44
3.3.3を上書きしちゃったから確認はしてないけど、プリコンパイルヘッダ無
しでも3.3.3よりC++のコンパイルが速くなった気がするなぁ。パーザを書き変
えた効果がこんな所にも出てるのかな。

241 :デフォルトの名無しさん:04/04/21 08:45
> GCC 3.4 automatically places zero-initialized variables in the .bss section on some operating systems.
> Versions of GNU Emacs up to (and including) 21.3 will not work correctly when using this optimization;
> you can use -fno-zero-initialized-in-bss to disable it.

うれしいな〜

242 :デフォルトの名無しさん:04/04/21 13:17
>>239
ある程度ミラーされるまでアナウンスしない方針だったような。
今週中には出ると思うが。




243 :デフォルトの名無しさん:04/04/21 15:21
>>241
2行目以降も引用して「うれしいな〜」と言っているところを見ると…アンチEmacs? (w

244 :デフォルトの名無しさん:04/04/21 15:52
vivavi

245 :デフォルトの名無しさん:04/04/21 16:06
-pedantic を愛用してる俺はダメ人間ですか?

246 :234:04/04/21 16:13
リリース版入れたけどダメだ orn
cygwin未対応なのかな

247 :デフォルトの名無しさん:04/04/21 16:36
gccがC#に対応するなんてことあるの?
Unix上でC#使ってみたいんだけど・・・

248 :デフォルトの名無しさん:04/04/21 16:39
monoじゃだめなの?

249 :デフォルトの名無しさん:04/04/21 16:53
>>246
それ以前にウチのCygwinでコンパイル通んないんすけど・・・。

250 :247:04/04/21 17:13
>>248
ありがと。既にもうあったんだ・・・調べてみます。

251 :デフォルトの名無しさん:04/04/21 23:59
>>222
そうなの?

252 :デフォルトの名無しさん:04/04/23 00:12
gcc 3.4:
* The C, C++, and Objective-C compilers can now handle source files
written in any character encoding supported by the host C library. The
default input character set is taken from the current locale, and may be
overridden with the -finput-charset command line option. In the future
we will add support for inline encoding markers.

MinGWのランタイムとかCygwinって日本語ロケールはサポートしてるのかな?


253 :デフォルトの名無しさん:04/04/23 00:30
それ iconv 必須

254 :デフォルトの名無しさん:04/04/23 00:39
iconvがあればいいの? じゃあ話は簡単だね。


255 :デフォルトの名無しさん:04/04/23 00:43
>>252
とりあえず cygwin について。
ttp://www.okisoft.co.jp/esc/cygwin-5.html#5.3
とりあえずだめぽ?

256 :Richard Stallman:04/04/23 14:17
GCC & GNU Toolchain Developers' Summit
June 2-4th, 2004, Ottawa Congress Centre, Ottawa, Canada
ttp://www.gccsummit.org/2004/

みんな逝くのだ!

257 :デフォルトの名無しさん:04/04/23 17:03
>>256
チョトだけ遠いな

258 :デフォルトの名無しさん:04/04/23 18:30
GNUのネ申が言うんだからしかたない漏れも逝くか。

259 :デフォルトの名無しさん:04/04/23 18:54
>>256に逝かない奴は、GPL違反

260 :デフォルトの名無しさん:04/04/23 19:19
gcc3.4のC99規格対応表
ttp://gcc.gnu.org/gcc-3.4/c99status.html

261 :デフォルトの名無しさん:04/04/23 19:45
なんでcomplex (and imaginary) support in <complex.h>がBrokenなんだろ

262 :デフォルトの名無しさん:04/04/23 20:23
ちゃんと理由書いてあるやん。

263 :デフォルトの名無しさん:04/04/23 21:08
ぐはぁっ。ほんとですね。イッテキマス…

264 :デフォルトの名無しさん:04/04/24 13:13
GCCは3.0からC++ISO準拠したと聞きましたが
ISO以外の形式はコンパイルできないのですか?

265 :デフォルトの名無しさん:04/04/24 13:23
>>264
ISO以外の形式とはなんだ。
誰かの脳内にある俺様C++をGCCの中の人がわかるわけないだろ。

266 :デフォルトの名無しさん:04/04/24 20:22
>>265
例えば
cout << "文章" << x << "文章2" << endl;
(xは変数)
でコンパイルすると「stray '\33' in program」「文字の終端を欠いています」
と出てコンパイルできません。

cout << "文章" << x;
cout << "文章2" << endl;
とするとうまくいくのですが

267 :デフォルトの名無しさん:04/04/24 20:42
foo.cc:
#include <iostream>
using namespace std;
int main() { int x = 10; cout << "文章" << x << "文章2" << endl; }
% g++ foo.cc
% ./a.out
文章10文章2

うまくいくけど?

268 :デフォルトの名無しさん:04/04/24 20:43
>>266
SJISか?

269 :デフォルトの名無しさん:04/04/24 20:45
解決しました。
文字コードの問題だったようです。
エディタを変えたら無事コンパイルできました。

270 :いやーん:04/04/25 00:23
>>266
> cout << "文章" << x << "文章2" << endl;
> (xは変数)

これがISO C++に適合したプログラム断片じゃないと思ったわけだ…

271 :GCCer:04/04/25 15:59
これ知ってたか?
-fpreprocessed

272 :デフォルトの名無しさん:04/04/25 17:10
>>270
全ては方法的懐疑に基づく訳ですな

273 :デフォルトの名無しさん:04/04/25 22:34
それでgcc3.4はどうよ? > 使用してる奴

274 :デフォルトの名無しさん:04/04/25 22:40
以下を実行すると..
gcc -###

275 :デフォルトの名無しさん:04/04/26 02:21
RH9付属のgcc-3.2.2でgcc-3.4をmakeできた人いる?xgccができたあたりでICEしちゃうんだけど..


276 :デフォルトの名無しさん:04/04/26 03:31
gcc -finput-charset=sjis -fexec-charset=sjis testsjis.c -o testsjis
内部で\がすべて2バイトコードに変換されてしまいます。
libiconvのsjis->utf-8がよろしくないようで

277 :デフォルトの名無しさん:04/04/26 13:11
もろ環境依存の話ですが,
どこに書けばいいのかわからないので,ここに書かせてください.
(もし,適切な場所があれば誘導をお願いします.)
MacOSXのg++(3.1 20020420)で(gccではなく)isnanを使いたいのですが,うまくいきません.
#include <cmath>
int main () {double d (NAN); std::isnan (d); return 0;}
なるコードをg++ test.cppすると,
`isnan' undeclared in namespace `std'
とエラーがでてしまいます.
stdを取っても同じエラーが出ます.
ヘッダをチラッと読んでみると,__isnanみたいな関数が途中あったので,
こちらを呼ぶと,とりあえずはビルドできるんですが,
これは正常な使い方とは思えません.
どうやって使ったらよいものかご存知の方いらっしゃいますでしょうか?


278 :デフォルトの名無しさん:04/04/26 13:22
>>277
解決方法ではないんだが、
ISO/IEC 9899:1999 (C99規格) の§7.12.3.4 によると、isnanはマクロとなっているね。だからとりあえずstd::は不要だ。


279 :デフォルトの名無しさん:04/04/26 13:41
>>276
長らくバックスラッシュを \ で代用していたことの弊害が本格的に出てきたヨカーン。
スレ違いだけど、本質的な解決策ないよね。gcc 的にはアドホックな解決でいいんだろうけど。

280 :277:04/04/26 13:51
>>278
> 解決方法ではないんだが、
> ISO/IEC 9899:1999 (C99規格) の§7.12.3.4 によると、isnanはマクロとなっているね。だからとりあえずstd::は不要だ。

レスありがとうございます.
std::取っちゃうと,
`isnan' undeclared (first use this function)
とのエラーがでちゃうんですよ.
ちなみにgccで(#include math.h>して)は,コンパイルは正常に行えます.

(ただし,別件になりますが,リンカで,
ld: Undefined symbols:
___gxx_personality_v0
のように出てしまいます.-lmはしてみたんですけど,
こちらは何をリンクすればいいんでしょうか?)


281 :デフォルトの名無しさん:04/04/26 14:03
だからマクロだっての。

282 :ヽ(´ー`)ノ ◆.ogCuANUcE :04/04/26 14:39
>>280
#include <cmath>
int main () {double d (NAN); isnan (d); return 0;}

283 :277:04/04/26 14:44
>>281
> だからマクロだっての。
すみません.
リンカの話,忘れてください.(エラーでなくなった.)


284 :277:04/04/26 14:45
>>282
test1.cpp: In function `int main()':
test1.cpp:2: `isnan' undeclared (first use this function)
test1.cpp:2: (Each undeclared identifier is reported only once for each
function it appears in.)


285 :デフォルトの名無しさん:04/04/26 14:48
>>276,>>279
それってエディタが全角に変換してない。

286 :デフォルトの名無しさん:04/04/26 14:51
>>277
gcc3.3.1はうまくいった
$ g++ test.cpp
$

287 :277:04/04/26 14:57
>>286
> gcc3.3.1はうまくいった
これ,Mac OS X上のgccでしょうか?


288 :デフォルトの名無しさん:04/04/26 14:58
>>285
んな話じゃない。Shift-JISはISO646IRVではなくてJIS X 0201(のLeftHalf)を仮定してるって話だよ。
ゲラゲラ

289 :デフォルトの名無しさん:04/04/26 15:02
必死だなw

290 :286:04/04/26 15:16
>>287
Linux

291 :デフォルトの名無しさん:04/04/26 15:28
>>285
>それってエディタが全角に変換してない。
iconvのソース(shift_jisx0213.h)より
/* Plain ISO646-JP character. */
if (c == 0x5c)
*pwc = (ucs4_t) 0x00a5;
else if (c == 0x7e)
*pwc = (ucs4_t) 0x203e;
else
*pwc = (ucs4_t) c;

>>288
euc-jpだと\(0x5c)を元に戻してくれるみたい。なぜ?

292 :277:04/04/26 15:28
>>290
> Linux
ああ,やっぱそうですか.
私の所も,Linux(gcc 3.3.3)ではうまく行くんですよね.
う〜ん.OS Xの人はどうしてるんだろう?


293 :デフォルトの名無しさん:04/04/26 15:36
Panther (10.3.3) 使ってるけど同じエラー出た。
$ gcc isnan.cpp -o isnan
isnan.cpp: In function `int main()':
isnan.cpp:2: error: `isnan' undeclared (first use this function)
isnan.cpp:2: error: (Each undeclared identifier is reported only once for each
function it appears in.)
$ gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1495)

294 :デフォルトの名無しさん:04/04/26 15:38
> >>288
> euc-jpだと\(0x5c)を元に戻してくれるみたい。なぜ?

EUC-JPは、規格上は0x5cがバックスラッシュ(ISO646IRV)なんだよ。実際にどう表示されるかは
実装の問題で。


295 :277:04/04/26 15:43
>>293
> Panther (10.3.3) 使ってるけど同じエラー出た。
あっ,ども.
やっぱりそうですか.
とりあえず,__isnanでも使って凌いどくか.


296 :デフォルトの名無しさん:04/04/26 15:46
で、何が問題なのさ。>>288


297 :デフォルトの名無しさん:04/04/26 15:52
>>296
288に書いてあるままなんだがな・・・・
問題は、
>gcc -finput-charset=sjis -fexec-charset=sjis testsjis.c -o testsjis
>内部で\がすべて2バイトコードに変換されてしまいます。
>libiconvのsjis->utf-8がよろしくないようで
これがlibiconvのバグでもなんでもなくて、Shift-JISというエンコーディングの
仕様に従った動作だという点だな。
279もそう言っている。


298 :デフォルトの名無しさん:04/04/26 15:53
288じゃないけど。
Shift_JIS の 0x5c は \ なんだけど、C / C++ のソース中ではバックスラッシュと同じ働きをするという
日本ローカルな慣例が i18n と馴染まないということが問題なのでは(←ローカルだから当然か・・・)?

299 :デフォルトの名無しさん:04/04/26 15:55
要するに'¥'と'\'が同居できないって事?


300 :デフォルトの名無しさん:04/04/26 15:57
>>299
> 要するに'¥'と'\'が同居できないって事?
EUC-JP, Shift-JIS, ISO-2022-JPで日本語を書く限りは同居できない。
直接UTF-8で書けば同居できる。


301 :ヽ(´ー`)ノ ◆.ogCuANUcE :04/04/26 15:58
>>295
これか?
http://www.vallis.org/blogspace/osxtricks
> There is a bug in /usr/include/gcc/darwin/3.1/g++-v3/cmath that will
> undo the definition of isnan. To fix it, comment out the line #undef isnan.
> Update: in Panther, the file to change is /usr/include/gcc/darwin/3.3/c++/cmath.

他人が使うモノだと書き換えるわけにいかんだろうから、mymath.hpp でも作って
そっちで isnan() マクロを定義する必要がありそうだね。


302 :デフォルトの名無しさん:04/04/26 15:59
>>300
>直接UTF-8で書けば同居できる。
問題は解決しました。

303 :デフォルトの名無しさん:04/04/26 16:00
>>302
ウム。


304 :デフォルトの名無しさん:04/04/26 16:14
ちょっとまてよ、同居する必要ってそもそもあるの?
コンバージョンをしないなら問題ないはずだが。


305 :デフォルトの名無しさん:04/04/26 16:15
ウム。

306 :デフォルトの名無しさん:04/04/26 16:21
>>304
毛唐はなんでもUTF-8に正規化したがるものさ。


307 :デフォルトの名無しさん:04/04/26 16:23
>>297-298
日本では歴史的に EUC と SJIS 間での変換の際 0x00〜0x7f はそのままに
してきたし、UTF への変換でもそうなったところで誰も困らないのに、
GNU libiconv では規格バカが譲歩してくれない。

sjis ではなく cp932 を使えばとりあえず回避できるけどね。

308 :デフォルトの名無しさん:04/04/26 16:24
ちなみに、自前で漢字コードコンバータを持ってる Perl 5.8 では
http://www.perldoc.com/perl5.8.0/lib/Encode/JP.html#BUGS
こんな感じで不要な変換を行わないことになってる。

309 :277:04/04/26 16:25
>>301
> http://www.vallis.org/blogspace/osxtricks
> > There is a bug in /usr/include/gcc/darwin/3.1/g++-v3/cmath that will
> > undo the definition of isnan. To fix it, comment out the line #undef isnan.
> > Update: in Panther, the file to change is /usr/include/gcc/darwin/3.3/c++/cmath.

ああ,これっすね.

> 他人が使うモノだと書き換えるわけにいかんだろうから、mymath.hpp でも作って
> そっちで isnan() マクロを定義する必要がありそうだね。

/usr/include/architecture/ppc/math.hから,

#define isnan( x ) ( ( sizeof ( x ) == sizeof(double) ) ? \
__isnand ( x ) : \
( sizeof ( x ) == sizeof( float) ) ? \
__isnanf ( x ) : \
__isnan ( x ) )
これ使うことにします.


310 :デフォルトの名無しさん:04/04/26 16:25
>>307
"sjis->utf-8"の場合のlibiconvの処理を変更して(゚д゚)ウマー
ではだめ?


311 :デフォルトの名無しさん:04/04/26 16:29
>>307
いやしかし gcc 的にはどうであれ、世間的には圧倒的に \ は円記号として使われてるわけで・・・
UTF-8 にしたらバックスラッシュで表示されますた、ではまずいような。

312 :デフォルトの名無しさん:04/04/26 16:39
\(゚听)イラネ

313 :デフォルトの名無しさん:04/04/26 17:29
>>312
\オレニクレ

314 :デフォルトの名無しさん:04/04/26 17:39
そこで trigraph ですよ。
main() { printf("表示??/n"); }
% gcc -trigraphs -finput-charset=sjis -fexec-charset=sjis sjis.c
% ./a.out
表示

315 :デフォルトの名無しさん:04/04/26 20:38
そこで trigraph ですよ。
main() { printf("表示??/n"); }
% gcc -trigraphs -finput-charset=sjis -fexec-charset=sjis sjis.c
% ./a.out
表示

316 :デフォルトの名無しさん:04/04/26 21:24
うにこーどの円マーク: ¥
バックスラッシュ: \

317 :デフォルトの名無しさん:04/04/27 00:36
universal character names(\u)じゃダメ?

318 :276:04/04/27 01:06
>>307
cp932を指定したら'\'を0x5cで処理してくれました。


319 :デフォルトの名無しさん:04/04/27 01:21
>>307
> GNU libiconv では規格バカが譲歩してくれない。
>>311
> いやしかし gcc 的にはどうであれ、
> 世間的には圧倒的に \ は円記号として使われてるわけで・・・

そうではないぞ。>>288>>294>>297の言う通り。

これだけじゃ理解できない人は、
http://euc.jp/i18n/ucsnote.ja.html
"6. ASCIIとJIS X 0201ローマ文字"を読むといい。

プログラムを書いている時でさえ、
YEN SIGN → REVERSE SOLIDUSと固定的に変換するとまずいのだ。(嗚呼神様)
ある時はYEN SIGN, ある時はREVERSE SOLIDUS。
それがShift_JISの0x5cの今までの使われ方。
規格ではYEN SIGNなのに。

納得のいかない話であるがこれが真実。
杓子定規に行くと>>314が正解。(ぐすん)

320 :デフォルトの名無しさん:04/04/27 01:30
>>318
それはUnicode.orgのmappingを利用しているからだと思います。
ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT
http://www.asahi-net.or.jp/~ez3k-msym/charsets/jis2ucs.htm

iconvがこのmappingを固定的に使ってくれると、使い分けられていいですね。
本来>>319に書いたようにYEN SIGNのままでいて欲しいところもあるわけですが…

321 :デフォルトの名無しさん:04/04/27 02:59
>>319
規格は規格として、現実的には
Windows: CP932 の 0x00〜0x7f を u+0000〜u+007f にマップ
Java: CP932 だけでなく Shift_JIS も 0x00〜0x7f を u+0000〜u+007f にマップ
Perl: Shift_JIS の 0x00〜0x7f を u+0000〜u+007f にマップ
と、ASCII のように変換する動作がデファクトスタンダードになっている。

http://mail.nl.linux.org/linux-utf8/2002-05/msg00076.html
からのスレも参照。

322 :デフォルトの名無しさん:04/04/27 12:56
圧倒的シェアを誇っている Windows の CP932 が、0x5C を「見た目は円マーク」なのに「ファイル名、
パス等として使われる場合には ASCII のバックスラッシュと同じ」って扱いにしてるんだよね。
C / C++ その他昔ながらの応用ではみんなそうか。

今後どうなるべきなの?
UTF-8 対応のエディタ使って、0x5C はバックスラッシュで入力(表示もバックスラッシュ)、
円マークはえーとコード分からないけど Unicode の円マークで入力(表示も円マーク)となるべき?

素直に EUC 使って\は2バイトで書くほうがいいような気が・・・

323 :デフォルトの名無しさん:04/04/27 14:11
微妙に話題がスレ違いになっているのは気のせいですか?
っていうか文字コード関連のスレのほうがよいと思われ。
【UTF8】文字コード変換【SJIS】
http://pc5.2ch.net/test/read.cgi/tech/1063177450/l50

324 :デフォルトの名無しさん:04/04/28 23:16
やっとcygwinでPCHでけた。
234のソースを使用
3.3.1
$ time g++ test.cc
real 0m8.416s
user 0m1.211s
sys 0m1.201s

3.4.0
$ time /usr/local/xp/bin/g++ test.hh
real 0m2.160s
user 0m1.702s
sys 0m0.470s

$ time /usr/local/xp/bin/g++ test.cc
real 0m1.593s
user 0m1.011s
sys 0m0.560s


325 :デフォルトの名無しさん:04/04/29 00:28
>>324
pch(・∀・)イイ!!


326 :デフォルトの名無しさん:04/04/29 01:21
>>324
うーむ、やはり速くなってるな

327 :234:04/04/29 04:46
>>324
どうすればできるようになるんですか?


328 :デフォルトの名無しさん:04/04/29 05:29
>>234
cygwinではggc-common.cの中のmmapでoffset指定があるところが問題

ggc-common.cの中では
#undef HAVE_MMAP_FILE
する。
なぜか、mmapが使えなくてもいい様にコーディングしてあるのに
その中の処理が全くないので処理を追加する。
追加する場所はhooks.cの中の
hook_void_void   ここで適当な大きさのメモリを確保 実行時に2回呼ばれるので注意
hook_voidp_size_t_null 確保したメモリのアドレスを返す
hook_bool_voidp_size_t_false 確保したメモリのアドレスと同じかと大きさを確認する。

ggc-common.cのneeds_readの判定後の処理がおかしいので
if (needs_read)
{
if (fseek (f, mmi.offset, SEEK_SET) != 0
/*|| fread (&mmi, mmi.size, 1, f) != 1*/)
fatal_error ("can't read PCH file: %m");
fread(addr,mmi.size,1,f);
}
上のように書き換える。

以上
 

329 :234:04/04/29 05:56
>>328
レスありがとうございます。
早速やってみます。
結果報告はのちほど。

330 :234:04/04/29 16:16
>>328
hooks.cは>>331のようにしてみましたが
  g++: 内部エラー: Segmentation fault (プログラム cc1plus)
  完全なバグレポートを送ってください。
と言われてしまいました。

ひたすら fprintf() をはさんで調べたところ、
どうやら ggc-page.c の clear_marks() の内側のループの
  size_t num_objects = OBJECTS_IN_PAGE(p);
でこけているようです。

どこが間違っているんでしょうか?


331 :234:04/04/29 16:16
void *buffer_used_for_PCH_on_cygwin = NULL;
#define BUFFSIZE_FOR_PCH_ON_CYGWIN (1<<24)

void
hook_void_void (void)
{
if (buffer_used_for_PCH_on_cygwin == NULL)
buffer_used_for_PCH_on_cygwin = xmalloc(sizeof(BUFFSIZE_FOR_PCH_ON_CYGWIN));
}

void *
hook_voidp_size_t_null (size_t a ATTRIBUTE_UNUSED)
{
return buffer_used_for_PCH_on_cygwin;
}

bool
hook_bool_voidp_size_t_false (void * a ATTRIBUTE_UNUSED, size_t b ATTRIBUTE_UNUSED)
{
if (buffer_used_for_PCH_on_cygwin != a && a != NULL) {
fprintf(stderr, "OTL\nbuf: %p\na: %p\n", buffer_used_for_PCH_on_cygwin, a);
exit(1);
}
if (BUFFSIZE_FOR_PCH_ON_CYGWIN <= b) {
fprintf(stderr, "orz\nb: %d\n", b);
exit(1);
}
return true;
}
#undef BUFFSIZE_FOR_PCH_ON_CYGWIN

332 :デフォルトの名無しさん:04/04/29 16:56
>>330
ggc-common.cで
#undef HAVE_MMAP_FILE
を入れてる場所がよくないような?

includeがすべて終わった後にundefしてみて

333 :234:04/04/29 18:06
>>332
そうしてるんですけどダメです。#undefする場所をいろいろ試してみたんですが、
#include "config.h"
#include "system.h"
...
#include "hosthooks.h"

// ******** ここに入れたり ********
#ifdef HAVE_SYS_RESOURCE_H
# include <sys/resource.h>
#endif

// ******** ここに入れたり ********
#ifdef HAVE_MMAP_FILE
# include <sys/mman.h>
# ifdef HAVE_MINCORE
/* This is on Solaris. */
# include <sys/types.h>
# endif
#endif
...
#ifdef ENABLE_VALGRIND_CHECKING
...
#endif
// ******** ここに入れたり ********

やはり状況は変わらずです。只今ほんのり自棄になってconfigureの
#define HAVE_MMAP_FILE 1
を消して configure → make bootstrap 中です。

334 :デフォルトの名無しさん:04/04/29 18:43
>>333
hooks.cの追加した処理があってることと

#undef HAVE_MMAP_FILE
が有効になっていれば

if (needs_read)
{
if (fseek (f, mmi.offset, SEEK_SET) != 0
/*|| fread (&mmi, mmi.size, 1, f) != 1*/) <−−−コメントするのを忘れるとOUT
fatal_error ("can't read PCH file: %m");
fread(addr,mmi.size,1,f);          <−−−ここを通過するはず
}




335 :234:04/04/29 18:51
>>334
そこは通過するんですけど、その後の ggc_pch_read() で
Segmentation Falte
なんです。

336 :デフォルトの名無しさん:04/04/29 19:10
>>336
gccをmakeし直したらヘッダーファイルを再度PCHしないとだめだよ。
hook_void_voidで確保したアドレスが違うとエラーになる可能性がある。


337 :デフォルトの名無しさん:04/04/29 19:18
gccのオプションで構造体のメンバ間をpaddingさせないようにする
オプションは何ですか?

338 :234:04/04/29 19:53
>>336
それもやってるんですけど...OTL

339 :デフォルトの名無しさん:04/04/29 21:42
>>337
attributeで可能だったような気がする。info読め。

340 :デフォルトの名無しさん:04/04/29 21:54
>>337
struct foo {
chara;
shortb;
intc;
} __attribute__((__packed__))

341 :デフォルトの名無しさん:04/04/29 23:03
>>339,>>340
タンクスでつ

342 :デフォルトの名無しさん:04/04/30 01:38
configureが違うからか?
$ /usr/local/xp/bin/g++ -v
Reading specs from /usr/local/xp/lib/gcc/i686-pc-cygwin/3.4.0/specs
Configured with: ../gcc-3.4.0/configure --enable-languages=c,c++ --enable-libgcj
--enable-threads=posix --with-system-zlib --enable-nls --without-included-gette
xt --enable-interpreter --enable-sjlj-exceptions --disable-version-specific-runt
ime-libs --enable-shared --host=i686-pc-cygwin --target=i686-pc-cygwin --prefix=
/usr/local/xp
Thread model: posix
gcc version 3.4.0


343 :234:04/04/30 02:29
>>342
かもしれませんね。
それでやってみます。

344 :234:04/04/30 03:43
やり直してもダメでした。

345 :デフォルトの名無しさん:04/04/30 03:54
変更したソース
ttp://up.atnifty.com/upload/file/20040430035201_.zip

gccのソースをオリジナルに戻して、やってみて

これで駄目なら、あきらめましょう。

346 :234:04/04/30 04:10
>>345
ありがとうございます。
ダウンロードさせていただきました。

報告は後ほど。

347 :234:04/04/30 05:00
>>328>>332>>334>>336>>342>>345
できました!
ほぼ丸一日お付き合いいただきありがとうございます。

でもなんで自分でいじったのはダメだったんだろう...
分かり次第報告させていただきます。(ウザイですか?)

348 :デフォルトの名無しさん:04/04/30 05:19
わくわく

349 :234:04/04/30 06:14
あ、わくわくされてる。
報告はたぶん明日以降になると思います。
(きっとすごく単純なとこではまってたんだろうなぁ)

350 :234:04/04/30 07:18
Segmentation faultが起こった分かりました。
hook_void_void()の領域を確保するところ↓(>>331 から抜粋)で、

>#define BUFFSIZE_FOR_PCH_ON_CYGWIN (1<<24)
...
>if (buffer_used_for_PCH_on_cygwin == NULL)
>  buffer_used_for_PCH_on_cygwin = xmalloc(sizeof(BUFFSIZE_FOR_PCH_ON_CYGWIN));

xmalloc(BUFFSIZE_FOR_PCH_ON_CYGWIN)
としてたつもりが
xmalloc(sizeof(BUFFSIZE_FOR_PCH_ON_CYGWIN)) // ** なぜかsizeof使ってた
としていたために充分な領域が確保されてませんでした。

"malloc()といえばsizeof"っていう癖がついてたんでしょうね、きっと。
激しくアフォでごめんなさい。

351 :デフォルトの名無しさん:04/04/30 09:10
↓何事も無かったようにどうぞ

352 :デフォルトの名無しさん:04/04/30 11:00
皮はシャッキリシコシコ
噛むと美味しいおつゆがピュッ


353 :デフォルトの名無しさん:04/04/30 13:11
-finline と -finline-functions って同じ意味でしたっけ?



354 :デフォルトの名無しさん:04/04/30 15:34
ttp://www.sra.co.jp/wingnut/gcc/gcc-j.html

355 :353:04/04/30 15:49
>>354
マニュアル類には-finlineについて記述がないんですが、指定しても
エラーにならんのですよね。


356 :デフォルトの名無しさん:04/04/30 15:57
gcc -v --help

357 :デフォルトの名無しさん:04/04/30 16:16
>>356
サンスコ!

358 :デフォルトの名無しさん:04/04/30 18:42
gccのoptionてアホだよな

359 :デフォルトの名無しさん:04/04/30 18:58
>>358
日本語書くときに促音を省略してしまうキミもね。


360 :デフォルトの名無しさん:04/04/30 20:23
>>359
日本語を書くときに助詞を省略してしまうキミもね。

361 :デフォルトの名無しさん:04/05/01 01:37
>>358
それを言うだけでageてるキミもね。

362 :デフォルトの名無しさん:04/05/01 02:01
オマエモナーって死語?

363 :デフォルトの名無しさん:04/05/01 02:42
最近はオマエガナーがナウいです

364 :デフォルトの名無しさん:04/05/01 03:31
最近のヤングにはオマエガナーがとてもナウいんです。

365 :デフォルトの名無しさん:04/05/01 10:22
ナウなヤングage

366 :デフォルトの名無しさん:04/05/01 10:34
ほとんどビョーキなスレはここですか

367 :デフォルトの名無しさん:04/05/01 14:13
tree-ssaはいつメインラインと統合されるんですかね

368 :デフォルトの名無しさん:04/05/01 14:55
tree-ssaって何?

369 :デフォルトの名無しさん:04/05/01 19:30
>>368
ttp://people.redhat.com/graydon/g++-report/

370 :デフォルトの名無しさん:04/05/01 20:24
>>368
よくわかんない、詳細希望

371 :デフォルトの名無しさん:04/05/01 23:24
>>370
ttp://gcc.gnu.org/projects/tree-ssa/

372 :デフォルトの名無しさん:04/05/02 00:24
>>371
ありがと、わかったようなわからないような感じです。

373 :371:04/05/02 01:37
>>372
コピペした者として、喜んでいいのかよくわからないレスをありがとう。

374 :デフォルトの名無しさん:04/05/02 01:41
たれかC++相談室のネタに答えてやれ


375 :デフォルトの名無しさん:04/05/03 00:24
C++相談室はVC++マンセーのようだがgccのコード品質ってどのくらい?

376 :デフォルトの名無しさん:04/05/03 00:47
あの例、gcc-3.4 だともうちょい良くなったりしないもんかなー


377 :デフォルトの名無しさん:04/05/03 00:48
tree-ssaとやらが組み込まれたgccでの結果も見たいもんだ


378 :デフォルトの名無しさん:04/05/03 00:56
>>372
http://www.is.titech.ac.jp/~sassa/lab/papers-written/02M37130.pdf
とか?(関係あるのかないのかよくわからんのだけどw


379 :デフォルトの名無しさん:04/05/03 01:00
FixedPoint f(1, 50); // 1.50
return f.i_;

だけのコードなら、gcc-3.4 で
pushl %ebp
movl %esp, %ebp
subl $8, %esp
andl $-16, %esp
subl $16, %esp
movl $1, %eax
leave
ret
にはなるね。%esp の操作が無意味だが…
掛け算入ったやつはダメダメ。



380 :デフォルトの名無しさん:04/05/03 01:05
>>379
サンクスコ

> 掛け算入ったやつはダメダメ。
gcc-3.3以前よりもっと駄目??


381 :デフォルトの名無しさん:04/05/03 01:30
方や世界で一番大きいソフト会社の製品、方や歴史はあるとは言えただの
ソフトだから当然と言えば当然。
でも、それがどの程度、普段書くコードの速度低下をもたらすかだけどね・・・
C++で数値計算やってる俺の場合、
インテルコンパイラが第一。わずかに劣ってgcc。めちゃくちゃ遅いVC7.1
ってところ。iccと同じオプションなのにVCは遅くて仕方がないんだけど
なんか使い方間違ってるんかな?
まぁWinなんてたまにしか使わないからgccだけでいいんだけどね。

382 :デフォルトの名無しさん:04/05/03 01:42
gcc はオプションで結果が全然違うぜ!
自分の目的にあった適切なオプションを選択しろよ!

383 :デフォルトの名無しさん:04/05/03 01:57
浮動小数点数値演算(複素sin/cos等あり)で速度 gcc3.0 << VC++6.0
-ffast-mathつけるとgcc3.0 ≧ VC++6.0
てなことがあった(もちろん最適化ありで)。
VC++6.0の浮動小数点は-ffast-math相当じゃないかと疑っている。
面倒くさいから試してないけど。

384 :デフォルトの名無しさん:04/05/03 02:03
>>380
自分が試した範囲だと、gcc-3.4.0 だとオプションをどーやっても真面
目に掛け算するコードを吐いてました。

もちろん、一般的に gcc-3.4 のほうが最適化がダメ、ということでは
ないですけどね。gcc-3.3.x で __attribute__((always_inline)) を付
けないと展開されなかった関数オブジェクトが gcc-3.4.0 では指定な
しでも展開してくれるようになって、自分は嬉しい。



385 :デフォルトの名無しさん:04/05/03 02:55
gcc使う奴はオプションを適切に設定していればいいわけで、
デフォルトで最適な状態はありえないと考えればいいのでは。

386 :デフォルトの名無しさん:04/05/03 03:01
ひとつだけいえるのはintelもMSも他でさんざん儲けてるんだからコンパイラなんか無償配布しろって琴田
マジでそう思うのは俺だけ?

387 :デフォルトの名無しさん:04/05/03 04:09
>>385
Intel も Microsoft もコンパイラは無償配布してますよ?


388 :387:04/05/03 04:09
みすった、>>386

389 :デフォルトの名無しさん:04/05/03 04:47
インテル版はお試し期間中の無料配布はしてるがそれをただとはいわんだろ?
http://www.xlsoft.com/jp/products/intel/prices.html

390 :デフォルトの名無しさん:04/05/03 05:14
ここわ、GCCすれです。
そこを考慮して、改めて>>391さんどうぞ。

391 :デフォルトの名無しさん:04/05/03 05:15
インテルのGCCはないの?

392 :デフォルトの名無しさん:04/05/03 05:26
お見苦しい発言を失礼しました。
では改めて>>392さんどうぞ。

393 :デフォルトの名無しさん:04/05/03 05:28
→↓
↑←

394 :デフォルトの名無しさん:04/05/03 07:06
iccのlinux版は無料だよ
確か。

395 :デフォルトの名無しさん:04/05/03 07:24
このスレではgccマンセーのようですが、
件の最適化についてはgcc3.4でも改善されていないということでFA?

396 :デフォルトの名無しさん:04/05/03 09:14
>>394
非商用限定だけどね

397 :デフォルトの名無しさん:04/05/03 09:23
>>396 lic 要らないの?

398 :デフォルトの名無しさん:04/05/03 09:25
FreeBSDでインストールしようとしたけど駄目だった。動いた人居る?

399 :デフォルトの名無しさん:04/05/03 12:10
3.4も3.5もNetBSDで普通に使ってます

400 :デフォルトの名無しさん:04/05/03 14:55
>>395
> このスレではgccマンセーのようですが、
> 件の最適化についてはgcc3.4でも改善されていないということでFA?
gcc3.4のほうが悪化しているでFA.


401 :デフォルトの名無しさん:04/05/03 15:21
>>399
コンソール画面からインストーラ起動するとログアウトする。
atermから起動するとaterm自体が落ちるんだけど。そんなことない?

402 :デフォルトの名無しさん:04/05/03 17:03
>>384
> >>380
> 自分が試した範囲だと、gcc-3.4.0 だとオプションをどーやっても真面
> 目に掛け算するコードを吐いてました。

$ rpm -qa|grep icc
intel-icc7-7.1-6

だと(最新版じゃないが)、mov $5, -4(%ebp) ひとつにコンパイルされました。
VC++と同じく問題なしですね。



403 :デフォルトの名無しさん:04/05/03 19:57
数日前にUNIX板で質問したのですが、回答いただけなかったのでこちらでも質問させてください。
2度目の皆様すみません。

nmしたときやg++ -Sしたときに、コンストラクタやデストラクタに
Foo::Foo[in-charge]() のように[なんちゃら]と注釈が入っている場合がありますけど、
これって何ですか?どこかに解説ありませんか?

in-charge, not-in-charge, in-charge deleting などがあるようで...


404 :デフォルトの名無しさん:04/05/04 01:16
真面目に掛けてほしい状況の方がふつーのプログラムでは多いんじゃないの?
プリプロセッサだけでも計算できる定数じゃなくて変数をセットしたときの実動作では
ほとんどネグれる程度だったり。そのコンパイラの苦手なソースにたまたま出くわしたという
ことじゃないの?

405 :デフォルトの名無しさん:04/05/04 01:44
>>403
libiberty/cp-demangle.c

/* Demangles and emits a <ctor-dtor-name>.

<ctor-dtor-name>
::= C1 # complete object (in-charge) ctor
::= C2 # base object (not-in-charge) ctor
::= C3 # complete object (in-charge) allocating ctor
::= D0 # deleting (in-charge) dtor
::= D1 # complete object (in-charge) dtor
::= D2 # base object (not-in-charge) dtor */


406 :デフォルトの名無しさん:04/05/04 01:50
>>405
ありがとうございます。
なるほど…


407 :デフォルトの名無しさん:04/05/04 08:34
>>404
クロスコンパイルも視野にいれると、
定数のコンパイル時計算は意外と面倒で、
最適化(定数伝搬&ループ外移動)のことを考えるとあまり効果がない。

昔のgccは結構強引なことをやった時期もあって、
(doubleの交換律による定数まとめなど)
ずいぶんと批判されてましたね。

408 :デフォルトの名無しさん:04/05/04 14:54
俺の場合、gccはVCより明らかに高速なことが多い。
でもiccには負ける。
CPU設計するときに少なくともCコンパイラは同時に開発するだろうから、
インテルが出すコンパイラが他メーカより遅いのは逆に問題ある罠。

409 :デフォルトの名無しさん:04/05/04 14:57
gdbで実クロック数のカウント表示ってできないのかな?

410 :デフォルトの名無しさん:04/05/04 15:17
今時のCPUはICEでも無理。

411 :デフォルトの名無しさん:04/05/04 16:50
それはマルチスレッドの場合でパイプラインが深いだけならカウントできるだろ?

412 :デフォルトの名無しさん:04/05/04 16:55
>>411
キャッシュヒットとか page fault もあるし、単一スレッドのプログラムでも
裏でクロック割り込みとか I/O まわりの割り込みが発生してるから。

413 :デフォルトの名無しさん:04/05/04 17:08
>>410 君ICE触ったことないね。ICEじゃ無理だよ。直接CPUが載ってるわけだから。
HWで動いてるCPUのクロックをどうやってカウントするんだ?ロジアナもってくりゃできるけどな。
クロック数カウントするのはイン・サーキット・エミュレータじゃなくてボントのシミュレータじゃないと駄目。
むしろgdbの target sim に含まれて無いほうがおかしい。

414 :デフォルトの名無しさん:04/05/04 17:09
スーパースカラ、内部コア命令翻訳、パイプラインハザード考えても、
今時のCPUで外部からクロックカウントは無理。

CPUのモデルごとにプロファイルを持って、
CPUの内部を完全にエミュレートしないと。

こんなやつ
http://www-cs-faculty.stanford.edu/~knuth/mmix.html
http://www-cs-faculty.stanford.edu/~knuth/mmix-news.html

415 :デフォルトの名無しさん:04/05/04 17:11
>>413
Z80くらい昔のCPUのICEは出来たよ。


416 :デフォルトの名無しさん:04/05/04 17:12
>>414
あのねメーカから出てるシミュレータ/デバッガでは当然できる機能なんだよ。
できなきゃ組み込みソフトなんて製品にならんぜ。
gdbがやってないのはそれはgdbの都合

417 :デフォルトの名無しさん:04/05/04 17:13
>>416
当たり前でしょ。gdbの話してんのよ。アフォ?

418 :デフォルトの名無しさん:04/05/04 17:16
>>415
ICE(エミュレータ) っていうのはハードウェアが載ってることは知ってるよね。
それをカウントしようとすると相当手間なのよ。
そんなことしなくても実効命令のクロックを順番に加算していけば算出できるんだよ。
だからシミュレータなら当然できる機能ってこと。
実際俺が使ってるSHやDSP(54X)デバッガにはその機能があるし。

419 :デフォルトの名無しさん:04/05/04 17:19
>>417
クロック数のカウントの話をしてんのにハードウェアエミュレータの話をするところが間抜けだいってるんだよ
わからんのかね。馬鹿かお前。

420 :デフォルトの名無しさん:04/05/04 17:19
>>418
> そんなことしなくても実効命令のクロックを順番に加算していけば算出できるんだよ。
そんな時代もあったなぁ…・・・

421 :デフォルトの名無しさん:04/05/04 17:21
まともなシミュレータも知らん奴は紛らわしからコメントするな。

422 :デフォルトの名無しさん:04/05/04 17:22
電波はコメントするな

423 :デフォルトの名無しさん:04/05/04 17:22
さぁ、盛り下がってまいりました。


424 :デフォルトの名無しさん:04/05/04 17:22
ICE?ナニソレおいしいの?


425 :デフォルトの名無しさん:04/05/04 17:23
人間が作ったハードウェアのクロックも数えられないと思ってる時点でも一回勉強しなおしたほうがいいんじゃないか->421
それが評価できない時点でCPUの設計はできんだろうが。

426 :デフォルトの名無しさん:04/05/04 17:24
>>421
君のCPUの設計はクロックすら不確定性関係が成立してて評価不能なようだな。

427 :デフォルトの名無しさん:04/05/04 17:26
マルチCPUで複数クロックで動いてる場合はともかく単一クロックで動作してる場合
評価できない方がおかしい。できないと思ってる奴は手を抜いてる(抜かれてる)ことに
気づかないおめでたい奴。

428 :デフォルトの名無しさん:04/05/04 17:31
>>427
単一クロックの元で動作してるという仮定の下でクロック数をカウントするってことだな。

429 :デフォルトの名無しさん:04/05/04 17:31
>>427
> 単一クロックで動作してる場合評価できない方がおかしい
環境による。

プリエンプティブマルチタスク OS だとまず不可能だが、優先度順で実行タイミングを
完全に制御できるリアルタイム OS で、かつキャッシュヒットも完全に制御下における
なら見積もれる。

ただ正確な評価を行うためには CPU の外部仕様ではなく、内部仕様に関する詳細な
知識が必須だから gdb に期待するのはアレだ。

430 :デフォルトの名無しさん:04/05/04 17:31
>>425=426=427
まぁ餅憑け


431 :デフォルトの名無しさん:04/05/04 17:33
(・∀・)ニヤニヤ

432 :デフォルトの名無しさん:04/05/04 17:35
>>429 
ヲイヲイ。デバッガでOSの仕様を考慮してるものがあれば、教えてくれよ。

433 :デフォルトの名無しさん:04/05/04 17:38
デバッガは通信機能はOS/モニタを意識してる。それをいうならソフトウェアシミュレータだな。
OSというのはあくまでオーバーヘッドがないことを前提としてる。というか時間計測するん
じゃなくてクロック数で評価するんだから当然可能なはず初期キャッシュは当然ヒットなしが前提だろ。

434 :デフォルトの名無しさん:04/05/04 17:40
(・∀・)ニヤニヤ
結局話についていけなくて笑っているしかございません。

435 :デフォルトの名無しさん:04/05/04 17:41
当然すぎ

436 :デフォルトの名無しさん:04/05/04 17:44
で、結局 >>409
はどういう環境で開発してて、なんで実クロック数のカウントを
とりたいと思ったんだ?

437 :デフォルトの名無しさん:04/05/04 17:45
gdbの sim は HDLシミュレータでいうところの機能シミュレータなんだな。
実時間シミュレータ対応でない。
modelsimぐらいの機能は持ってくれるとうれしいんだが、
当然CPUメーカにはデバイス情報も開示して欲しいな。

438 :デフォルトの名無しさん:04/05/04 17:51
>>436
それは当然必要だろ?それによって必要なリソースの条件が変わってくる。
例えばあるタスクを10mxで完了したい。そのとき何MHzのクロックを突っ込めば
よいかが設計段階で算出できる。ちなみに消費電流はクロックに対してリニアに
変化する。シビアなモバイル関係のエンジニアならだれもが経験してること。
10mA変われば製品に対する市場評価が変わる。
現状のgdbではその評価ができないってことだな。

439 :デフォルトの名無しさん:04/05/04 17:52
×10mx -> ○10ms

440 :デフォルトの名無しさん:04/05/04 17:54
>>438
CPUの命令数まで確定しているのに設計段階とはこれ如何に。


441 :デフォルトの名無しさん:04/05/04 18:00
>>438
はぁ?君まともな製品開発したことないね?命令が確定して初めて、突っ込むクロックが決まるんだよ。
ちなみにロジックデバイスの周波数っていうのはMAXが決まってるだけで最低周波数に関しては
かなりの幅があるんだよ。PLLがなければ下限がないものもある。どれだけ低いクロックで済ませ
られるかが設計の腕の見せ所じゃねぇか。

442 :デフォルトの名無しさん:04/05/04 18:00
(・∀・)ニヤニヤ

443 :デフォルトの名無しさん:04/05/04 18:02
>>436
CPUぐらい固定してくれないと話進まないよね。



444 :デフォルトの名無しさん:04/05/04 18:03
>>418
> そんなことしなくても実効命令のクロックを順番に加算していけば算出できるんだよ。

安いCPUばっかり相手にしているんですね。


445 :デフォルトの名無しさん:04/05/04 18:04
どかーん!
(⌒⌒⌒)
 ||

/ ̄ ̄ ̄ ̄ ̄\
| ・ U      |
| |ι         |つ
U||  ̄ ̄ ||
   ̄      ̄
もうおこったぞう

446 :デフォルトの名無しさん:04/05/04 18:04
>>444
> 安いCPUばっかり相手にしているんですね。
それはそれで辛い仕事のような気がする。

447 :デフォルトの名無しさん:04/05/04 18:21
>>444
なーんも知らんようだが、メモリのアドレスデコーダも外付け、
ユーザが直接触れるのは古典的なx86ベースのPentiumプロセッサを
使って設計することがどれほど面倒か、わかってるか?
ちなみにPentiumを搭載したPC以外の製品がどういう状況にあるか
わかって言ってるんだろうな?->学生ちゃんよ

448 :デフォルトの名無しさん:04/05/04 18:22
実際Intelが一般に公開してる資料だけで、
gdb(じゃなくてもいいけど)に正確にクロック数える機能付けたせるのか?
無理だろ。
できるなら作ってくれよ。頭下げて使わせてもらうから。

449 :デフォルトの名無しさん:04/05/04 18:26
>>447
だから、環境を先に特定しようよ

x86 で Win32 なのか、z80 で OS どころかモニタもない環境なのかで話がぜんぜん
違うんだからさ。

450 :デフォルトの名無しさん:04/05/04 18:29
>>448 現状のGDBではファンクションシミュレーションしか出来ず、
実クロックシミュレーションに対応してない仕様であるということだけ。
CPUのクロックを"カウントできない"ってこととはまったく意味が違う。

451 :デフォルトの名無しさん:04/05/04 18:32
>>449 だから、シミュレータのクロック数のカウントはOSには依存しないんだよ。
逆にOSのオーバーヘッドを考慮したシミュレータがあるなら教えてくれよ。

452 :デフォルトの名無しさん:04/05/04 18:33
>>450
そもそも発端の >>414 からして、無条件で「CPUのクロックを"カウントできない」とは
書いてないようだが。

>>414
> CPUのモデルごとにプロファイルを持って、
> CPUの内部を完全にエミュレートしないと。
CPU ベンダ以外がクロックを正確にカウントするのは無理だ、gdb にそれを期待するな
と言ってるだけでしょ?

453 :デフォルトの名無しさん:04/05/04 18:38
>>451
Win32 みたいな環境で「クロック数」をカウントするのは意味ないからやめとけ、
という話だって。

ラウンドロビンではなく優先度順でスレッドを実行する環境でも、ハードウェア
アーキテクチャによっては意味ないし。俺が最近触ってるのは、メインメモリと
DMA コントローラが同一のバスを共有していて、しかも大量の DMA 転送を
行うのが前提のハードなんだけど、こういう状況だとメモリアクセスに要する
時間が予期できないから、厳密にクロック数を割り出すより実際のデータを
流しながらパフォーマンス測定せざるをえない。

で話が戻るが >>409 は何でクロック数をカウントしたいんだ?

454 :デフォルトの名無しさん:04/05/04 18:43
>>452

410、412、414、429 あたりの馬鹿のコメントをよく読め。出来ないとアフォがほざいてるだろ。
出来ないのは現状のgdbの仕様ってとだけ。

455 :デフォルトの名無しさん:04/05/04 18:47
>>447=>>454アフォ決定。
以下、心ある人は無視するように。

456 :デフォルトの名無しさん:04/05/04 18:51
>>454
410 は ICE の話だし、412 は OS やモニタが介在する場合には正確にカウントできないと
条件をつけてるだけでしょ。残り二つも、一般に公開されている情報だけではカウントでき
ないから gdb では無理だと言ってるに過ぎない。

>>414
> CPUのモデルごとにプロファイルを持って、
> CPUの内部を完全にエミュレートしないと。

>>429
> ただ正確な評価を行うためには CPU の外部仕様ではなく、内部仕様に関する詳細な
> 知識が必須だから

Z80 とかならともかく、命令をいったん非公開のμop に展開してたり、分岐予測を行ってる
最近の CPU だと、そのメーカー以外は正確なクロック数は出せんでしょ。

457 :456:04/05/04 18:53
>>455
了解。

458 :デフォルトの名無しさん:04/05/04 18:55
>>445 ガキはスッコンでな。

>>453
 シミュレータでもたとえば割り込みまでシミュレートできるものがあるが、
そんな機能を多用するより実物持ってきてポートたたいてロジアナでモニタしたほうが
手っ取り早いってことは経験上わかりきってるだろ。それでもクロック数がカウントできれば
アルゴリムの優劣や、コンパイラのコード品質を知る上でプロファイラなんかを動かすよりは
るかに正確な評価が出来るってことよ。ロジック設計手がけたことあるならわかると思うが、
ファンクションシミュレートだけではきわめていい加減な評価でしかできない。フリーのHDL
コンパイラ/シミュレータが普及しないのもこのせい。

459 :デフォルトの名無しさん:04/05/04 18:56
キャッシュヒットミスの見積もりに、
OSというかソフトウェアが影響する例だと、MIPSのR2000,R3000辺り。
ミスした時のハンドラはソフトウェアで記述だから。

460 :デフォルトの名無しさん:04/05/04 18:57
>>458
誰も読まない長文お疲れさんです。

461 :デフォルトの名無しさん:04/05/04 18:59
どうでもいいが
この話題はスレ違いじゃないのか?

462 :デフォルトの名無しさん:04/05/04 19:01
>>458
その辺もプラットホームによりけりなんだよな。

小さいながらも命令キャッシュを持ってる CPU だと、コードから静的に算出される
見かけのクロック数より、関数の配置の方が効いたりする。パフォーマンスカウンタ
で命令キャッシュミスを集計しながら、手作業で関数を並び替えたヤな思い出が。

463 :デフォルトの名無しさん:04/05/04 19:04
>>456
例えばXilinxははメンターにディバイスの遅延情報を公開してるし、
一般ユーザでもそれの情報を入手できる。クロックだけでなくクロックに
対する遅延評価もできる。逆にそれが出来なきゃ設計は出来ない。
技術敵に出来ないことと、仕様としてやってないことを正確に分けろってことよ。


>>460 お前には言ってることの1割もわからんだろうからごみコメント入れるな。

464 :デフォルトの名無しさん:04/05/04 19:31
gdbってクロック精度まであるシミュレータの組み込みって出来ないんだっけ?


465 :デフォルトの名無しさん:04/05/04 19:40
>>456
gdbではH8もサポートしてるんだが。

466 :デフォルトの名無しさん:04/05/04 19:42
このスレではマルチスレッドCPUに対応した gcc しか相手にしません。

467 :デフォルトの名無しさん:04/05/04 21:07
マルチスレッドCPU

468 :デフォルトの名無しさん:04/05/05 01:37
ttp://pc.watch.impress.co.jp/docs/2003/1018/kaigai034.htm

469 :デフォルトの名無しさん:04/05/05 10:54
>>464
できる。
デバッガ部分とシミュレータ部分は結構疎遠。


470 :デフォルトの名無しさん:04/05/05 14:30
(・∀・)ニヤニヤ

471 :デフォルトの名無しさん:04/05/05 15:45
>>(・∀・)ニヤニヤ
そういう意味ありげな言い方せずにはっきり指摘すればどうよ。というか的確な指摘できないんだろ。


472 :デフォルトの名無しさん:04/05/05 15:54
>>471
スレ違いな話題はよそでやれってことじゃ?




473 :デフォルトの名無しさん:04/05/05 19:01
>>471 gcc - gdb の話は決してすれ違いじゃないよ

474 :デフォルトの名無しさん:04/05/05 19:56
「マルチスレッドCPU」とやらの話はスレ違いだろ

475 :デフォルトの名無しさん:04/05/06 15:52
マルチスレッドを効率よく機能させるのにコンパイラが対応しないでどうするんだ?

476 :デフォルトの名無しさん:04/05/08 11:44
>>463
> 例えばXilinxは

話の流れが理解できてないのか ?
それとも、単に知識を披露したいだけ ?

477 :デフォルトの名無しさん:04/05/08 14:57
gccの最適化はIntelのやVC++よりもショボいという結論でいいよね。

478 :デフォルトの名無しさん:04/05/08 15:02
しょぼいというか最適化処理そのものにバグがあるから使えない

479 :デフォルトの名無しさん:04/05/08 15:32
>>476
>>463の書いてる程度のことを知識のひけらかしと思う時点でお前がエンジニアとしての常識なさ杉

480 :デフォルトの名無しさん:04/05/08 15:49
>>479
唐突に「Xilinxはは」なんて書かれても、うざいだけだよ。

481 :デフォルトの名無しさん:04/05/08 16:45
知らないことを書かれてしまって何もまともなコメントできずにウザイと捨て台詞吐くしかないわな。


482 :デフォルトの名無しさん:04/05/08 16:56
>>477
407読め。Visual C++なんて7.1になってようやくまともになっただけ。

>>478
-O2でLinuxカーネルもFreeBSD全システムもコンパイルして大丈夫

483 :デフォルトの名無しさん:04/05/08 19:03
>>482
i386しか使ったことない犬厨か。
他のarchで-O2してみろよ。バグバグだから。

484 :デフォルトの名無しさん:04/05/08 19:05
>>483
そういうのを最適化そのものにbugがあると言うのか?
君は言うんだろうな。あーこりゃこりゃ

485 :釣りだと思うけど、まさかマジなのかな ?:04/05/08 21:23
>>481
ププッ、逆切れ ?

で、なんで Intel じゃなくて、Xilinx の話を唐突に出すの ?


486 :デフォルトの名無しさん:04/05/08 21:41
>>483
H8で-O2つけて問題なく使ってるよ。

487 :デフォルトの名無しさん:04/05/08 23:27
>>483
それは特定のアーキテクチャ向け最適化でバグがあるだけじゃないの?
そのアーキテクチャの仕事する人は災難だが、一般化するほどのことでもない。


488 :デフォルトの名無しさん:04/05/08 23:30
>>483
て言うか、どのアーキテクチャでどういうバグが書けない時点で、単なる煽りにしか見えないぞ。

489 :デフォルトの名無しさん:04/05/08 23:49
日本で最初に製品にXilinxを採用した俺から言わせれば
>>463はまるでスレの流れを理解できていない勘違い野郎

490 :デフォルトの名無しさん:04/05/09 00:02
>>日本で最初に製品にXilinxを採用した俺から言わせれば
当時のFPGA採用するような製品だから試作か実験機のたぐいだな。おーっとそれ製品にして金とってたって?
そりゃぼったくりでしょ。レベルの低いESレベルの製品世に出してることを公表して恥さらすなって!

491 :デフォルトの名無しさん:04/05/09 00:06
>>483
gccってi386より前に68kでの実績があったことすら知らないみたいだね。

492 :>>489 じゃないけど。:04/05/09 00:22
>>490
別にすべての製品が常に量産品というわけじゃないだろ。
俺の所でも、公的機関や親会社が使う試作品を設計/製造することもあるよ。
買う方から見れば試作品なんだろうけど、売る方としては一応製品だからね。
そういうのはころころ仕様が変わったりするし、納期とかもシビアだからある意味ぼったくるのは当然。
だってリスクがあるからね。
悔しかったらあんたもそういう仕事見つけて、ぼったくれるようになれよな。(藁

493 :デフォルトの名無しさん:04/05/09 00:26
>>490
大量生産しか知らんのか?
たった1台しか生産しない製品なんてのもめずらしくないし
そうゆう業界での話。
まぁぼったくってるのには間違いないな。


494 :デフォルトの名無しさん:04/05/09 00:27
ああ>>492に先を越されてたorz

495 :デフォルトの名無しさん:04/05/09 00:51
じゃ、言わせてもうおう。

>公的機関

多分NTTあたりのことを言ってるのかな?

君が試作までしか手がけてないからそれで終わりと思ってるかもしれないが、それを使って規格作るための実験したり
最終的にはメーカにおいて量産までこぎつけてそれで利益を上げられるからこそボッタくり価格でも君のところに発注してるわけよ。
まぁ、量産する前には必ず試作フェーズがあるし、試作でシビアな実装も考えずにFPGAをいじってるのはそれは非常に
楽しいが電気屋として一番醍醐味あるのはやっぱりASIC起こすことだよ。RFの実装屋とかは違うこと言うだろうけどね。

>悔しかったらあんたもそういう仕事見つけて、ぼったくれるようになれよな。(藁
自営でもやってるの?そりゃ大金手にできるだろうし、俺も大金は欲しいが経営の才能なんてないもんでな、
あくまでもサラリーマンとして一定の給料定年までもらう方でやってくよ。それでも開発設計のダイナミズムを楽しんでるよ。

496 :デフォルトの名無しさん:04/05/09 01:02
↑大手のリーマンでつか?

497 :デフォルトの名無しさん:04/05/09 01:47
>>495
492じゃないからNTTとか自営とかわからないが・・・

489の製品とは、”ある物”の製造装置で、携帯装置のようなシビアな実装などは不要な世界。
納品先に納めた段階では試作品のような物だが、現場で最終調整をしてそれがそのまま製品となってしまう。
そんな造り方なんでフィールドでのリコンフィギャブル性に目を付けたわけだよ。
10年以上経つけどいまだに大手メーカーで稼動してます。

スレ違いにつきこれにて終了

498 :デフォルトの名無しさん:04/05/09 02:05
g++3とgdbで、例外が送出されたらbreakするにはどうすればいいんでしょうか?
catch throw はサポートされていないようなんですが。



499 :デフォルトの名無しさん:04/05/09 02:24
>>498 __cxa_throw あたりにブレークポイント

500 :デフォルトの名無しさん:04/05/09 02:28
>当時のFPGA
電気スペックはともかくよく割れたな。
割れるというより、パッケージの背着が不十分ではがれるもの多数でびっくらこいた。Maid in Korea なんてこんなもんと思ってたらこの有様・・・鬱

501 :デフォルトの名無しさん:04/05/09 02:31
>>499
できました。ありがとうございます。
catchされたらbreakは可能でしょうか?


502 :デフォルトの名無しさん:04/05/09 02:55
GCC関するスレでスレ違いのframe warになってるスレはここでつか?

503 :デフォルトの名無しさん:04/05/09 02:57
frame workの話をしているんでつ。

504 :デフォルトの名無しさん:04/05/09 02:59
>>503
ワロタ

505 :デフォルトの名無しさん:04/05/09 09:07
>>501
__cxa_begin_catchじゃねーか?

egrep get_identifier $(GCC)/gcc/cp/except.cしてみ。
他にも、__cxa_call_unexpected, __cxa_end_catch, __cxa_rethrow,
__cxa_allocate_exception, __cxa_free_exception こんなん出てきます。

506 :デフォルトの名無しさん:04/05/09 18:24
gcc.gnu.orgdj?

507 :デフォルトの名無しさん:04/05/09 19:46
>>506
つか、実体のsources.redhat.comがdj

508 :デフォルトの名無しさん:04/05/10 03:30
-O[0-3]それぞれで、どの-f...フラグが有効になるのかを調べる方法はありますか?
3.4.0で-O3を使うと、いたるところでInternalCompileErrorが発生するので、
その原因となる最適化フラグだけ無効にしたいのです。


509 :デフォルトの名無しさん:04/05/10 03:40
man gcc

510 :デフォルトの名無しさん:04/05/10 03:48
$(GCC)/gcc/toplev.cの
parse_options_and_default_flags()

511 :デフォルトの名無しさん:04/05/10 08:53
>>508
-fverbose-asm でコンパイルして.sの先頭のコメントを見るってのはどうよ?


512 :デフォルトの名無しさん:04/05/10 08:53
ミス。
-fverbose-asm -S だ


513 :デフォルトの名無しさん:04/05/10 13:46
Globalっていうソフト見てて思ったんだけど、
なんでGCCのパースしたデータを活用しないの?
なんでGCCのアドインみたいな形で作らないの?

VC++ユーザとしてはその辺り不可思議

514 :デフォルトの名無しさん:04/05/10 13:55
ようやく使えるようになったVCユーザとして不思議なんだよな。

515 :508:04/05/10 14:15
みなさん、ありがとうございます。
-fverbose-asm -Sで見る方法が手軽で解りやすかったです。


516 :デフォルトの名無しさん:04/05/10 14:23
>>513
作者が別だから。。。
と言うかgccのパース結果(正確にはcc1等の出力)は
プリプロセッサの処理結果を元にしているから
Globalの様にソースコードの原型が必要な場合には適さない

これでいいか?

517 :デフォルトの名無しさん:04/05/10 15:03
>と言うかgccのパース結果(正確にはcc1等の出力)は
>プリプロセッサの処理結果を元にしているから
>Globalの様にソースコードの原型が必要な場合には適さない

なるほど

518 :デフォルトの名無しさん:04/05/10 16:18
Globalの#if〜の扱いは結構凄いぞ。

519 :デフォルトの名無しさん:04/05/10 16:56
>>324
パッチ投げてあげて〜

520 :324:04/05/10 20:25
>>519
?

521 :翻訳器:04/05/10 21:31
パッチうpして〜!

522 :519:04/05/10 21:43
>>520
Cygwin か MinGW のメーリングリストにぽいっと

523 :デフォルトの名無しさん:04/05/11 00:16
>>522が教えてあげてよ。

本家の3.5.0でmmapに依存しない場合にも対応しようとしているみたいなので
それが出るまで待って見るのもいいかも?

MinGW用にはcygwin用にでっちあげたパッチだけじゃ不十分で
fopenを"w+"でファイルアクセスしているところでこけてます。
"w+b"に変更して、fcloseする手前でエラーになっているところを
コメントアウトすると一応PCH出来るようになりますよ。

524 :デフォルトの名無しさん:04/05/11 01:12
>>506-507
状況説明
ttp://sources.redhat.com/ml/overseers/2004-q2/msg00251.html
大丈夫か?



525 :デフォルトの名無しさん:04/05/13 12:33
assert 関数自作して、その中でコールスタックを表示したいのですが、
コールスタックを自作するとなるとかなり面倒な事になります。
(関数の始まりと終わりと return を全部いじる必要があるので)

GCC 3.3.2 使ってるんですけど、何かいい関数とか用意されてませんかね?

526 :デフォルトの名無しさん:04/05/13 13:07
素直にデバッガ使いなさい


527 :デフォルトの名無しさん:04/05/14 00:31
UNIXなら、
sprintf(buf, "gdb -x scriptfile %d", getpid());
system(buf);
じゃダメかねえ。(scriptfileにはwhere)

528 :デフォルトの名無しさん:04/05/14 00:32
debuggerでいいならabort()してcore dumpする。

529 :デフォルトの名無しさん:04/05/14 09:23
>>525
__builtin_return_address(LEVEL)じゃダメなの?

530 :525:04/05/14 12:40
>>529
おおっ! リターンアドレスが取得できますね。
あとはそのアドレスがどの関数内にあるのかが分かればいいのですが...。

>>526-528
gdb の使い方よく知らないもんで...。
やっぱ勉強した方がいいですかね?

531 :デフォルトの名無しさん:04/05/14 14:23
527に書いてあるじゃん

532 :デフォルトの名無しさん:04/05/14 17:02
>>530
nlist()

533 :デフォルトの名無しさん:04/05/14 19:31
フリーのGUI,devcppが最強すぎる・・・

534 :デフォルトの名無しさん:04/05/14 19:38
Dev-C++ 4.9.8.9、クラスブラウザで例外出まくりじゃね?

535 :デフォルトの名無しさん:04/05/14 19:40
4.9.8.9入れてない。
早速ホムペ行ってくる

536 :デフォルトの名無しさん:04/05/15 18:08
ttp://up.isp.2ch.net/up/5f484bf3ca4a.zip

537 :デフォルトの名無しさん:04/05/16 17:47
>>532
> nlist()
/usr/include/linux/a.out.h:struct nlist {
これですか?なにするもの?


538 :デフォルトの名無しさん:04/05/16 17:53
なんで、man nlist とかやってみようと思わないんだろうか... ?

539 :デフォルトの名無しさん:04/05/16 18:07
>>538
どういう意味ですか?

540 :デフォルトの名無しさん:04/05/16 18:10
>>539
BSD使えってことなんだろう

541 :デフォルトの名無しさん:04/05/16 18:21
> なんで、man nlist とかやってみようと思わないんだろうか... ?
犬酎なんでmanしてもみつからず。


542 :デフォルトの名無しさん:04/05/16 18:43
>>541
Debianだけど、libelfg0-devを入れたら/usr/include/libelf/nlist.hがあった。

543 :デフォルトの名無しさん:04/05/16 18:59
> Debianだけど、libelfg0-devを入れたら/usr/include/libelf/nlist.hがあった。
んで、なにしるものだった?


544 :デフォルトの名無しさん:04/05/16 19:06
しらね、自分で調べれば。
http://landru.uwaterloo.ca/cgi-bin/man.cgi?section=3&topic=nlist

545 :デフォルトの名無しさん:04/05/16 19:14
ナニゲに親切なDQN発見


546 :デフォルトの名無しさん:04/05/16 19:18
nlist()じゃコールスタックは見れないと思いマスがね;-)

547 :デフォルトの名無しさん:04/05/16 19:44
>525
gdbなんてコマンドいくつか覚えれば使えると思うけど。
覚えようとしないで、わざわざ手間掛かる方法を独自に
試すの事はあなたの人生に潤いを与えますか?

548 :デフォルトの名無しさん:04/05/16 20:04
>>547
常にgdb上で動かせるケースばかりとは限らんだろが



549 :デフォルトの名無しさん:04/05/16 20:08
アタッチもできないのか?

550 :デフォルトの名無しさん:04/05/16 20:14
>>547
お肌に潤いを与えます。

551 :デフォルトの名無しさん:04/05/16 20:15
>>548
Win?

552 :デフォルトの名無しさん:04/05/16 20:48
>>551
マカ


553 :デフォルトの名無しさん:04/05/16 21:16
>>546
こっちだろ。

>>530
> あとはそのアドレスがどの関数内にあるのかが分かればいいのですが...。

554 :デフォルトの名無しさん:04/05/16 21:24
アスペクトC++でも使えよ

555 :デフォルトの名無しさん:04/05/16 21:32
>>546
>>529-530,>>532

556 :デフォルトの名無しさん:04/05/16 22:15
>>554
OpenC++でも使えよ


557 :デフォルトの名無しさん:04/05/16 22:15
>>554
アスベストC++?


558 :デフォルトの名無しさん:04/05/16 22:22
健康に悪そうだな、おい。

まあ、プログラミングよりましかも知れんが。

559 :978:04/05/17 00:07
>>フリーのGUI,devcppが最強すぎる・・・

どこが最強なんだか・・・
あんなの使いもんにならんよ


560 :デフォルトの名無しさん:04/05/17 00:10
>>978
C言語なら俺に聞け!の次スレ立てて

561 :デフォルトの名無しさん:04/05/17 01:09
むつかしい

562 :デフォルトの名無しさん:04/05/17 05:56
>>560
ちょっと待っていろ

563 :559:04/05/17 06:02
>>562
はい、待っています

564 :デフォルトの名無しさん:04/05/17 13:52
>>978
>C言語なら俺に聞け!の次スレ立てて
それすらもできないようでは、C言語も(ry

565 :デフォルトの名無しさん:04/05/17 16:55
>>559
コンパイラはMingwだし、何か問題でも?
ソースはフォントとかカスタマイズすれば割といける

566 :デフォルトの名無しさん:04/05/18 02:33
フリーのGUI,Eclipseが最強すぎる・・・

567 :デフォルトの名無しさん:04/05/18 03:44
>>525
CCMALLOCというメモリーデバッガのパッケージがあって
そのなかにコールスタックを記録する機能がある。

ttp://www2.inf.ethz.ch/personal/biere/projects/ccmalloc/

このなかのcallchain.cというファイルにbacktrace()という
関数があってそれがまさにその実装。 #ifdefで中身は
x86依存バージョンと、gccの__builtin_return_addressを
使用した実装に分かれてる。 


568 :デフォルトの名無しさん:04/05/18 17:49
Cygwin+gccで、バイナリーデータのみのピュアなファイルを作成したいのですが、どうしたらよいのでしょうか。

例えば、
struct SAMPLETYPE {
int a;
int b;
};
SAMPLETYPE hoge[] = { { 1,2 }, { 3,4 }, { 5,6 }, { 7,8 } };
のような、構造体の配列データ【のみ】のソースから、配列サイズと【全く同じ大きさ】のデータファイルを作りたいと思っています。

gcc ??? ??? sample.cpp
のように、コマンドラインのみでファイルを作成することはできるのでしょうか。

569 :デフォルトの名無しさん:04/05/18 18:00
#include "sample.cpp"
(略)
 n = fwrite(hoge, sizeof(struct SAMPLETYPE),
 sizeof(hoge)/sizeof(struct SAMPLETYPE), f);

570 :デフォルトの名無しさん:04/05/18 19:08
>>568
データファイルを作成する c プログラムを作って実行する。

571 :568:04/05/18 19:10
>>569
すみません、書き忘れていたのですが、
「コンパイル環境はあるが、実行環境がない」という
特殊な状況のため、fwriteが使えないのです。
ですので、コマンドラインのみでどうにかならないかなーと思いまして。

572 :デフォルトの名無しさん:04/05/18 19:20
intのsize, structのpadding, byte orderが合っていれば、
ローカルの環境でやってしまえばいいでしょう。
また、違っていてもプログラムで何とでもなりますし。

573 :568:04/05/18 19:54
具体的な話になりますが、
1つのソース(配列データが書かれたもの)から、エンディアンが違う2種類のバイナリーデータを
つくりたいと考えています。
異なるプラットフォーム(MacとWinとか)でも、基本的にプログラムのソースコードは共通化したいので、
プログラムでエンディアンを解決するというのはやりたくないのです。

1)共通プログラムソース→それぞれのプラットフォーム用にコンパイル→それぞれのプラットフォーム用実行バイナリ
2)共通データソース→それぞれのプラットフォーム用にコンパイル→それぞれのプラットフォーム用データ

ということができればいいと考えているのですが。





574 :デフォルトの名無しさん:04/05/18 19:56
>>573
>プログラムでエンディアンを解決するというのはやりたくない
じゃあ変換ICとかでも作れば?

575 :デフォルトの名無しさん:04/05/18 20:04
データファイルを作成するプログラムで

> intのsize, structのpadding, byte order

に対処すればいいだろ。



576 :デフォルトの名無しさん:04/05/18 20:05
というか、これgcc関係ないよ。C言語初心者スレ行きだな。

577 :568:04/05/18 20:08
>>575
プログラムでは解決したくないんです。

578 :デフォルトの名無しさん:04/05/18 20:31
じゃあ、諦めな。

579 :デフォルトの名無しさん:04/05/18 20:47
>>573
「それぞれのプラットフォーム用にコンパイル」のところで、gcc しか使えないの?
make とか perl とかは? perl でやれば?

580 :568:04/05/18 21:40
>>577 は私ではないですが、まあ、いっか。

構造体のサイズがかなり大きく、かつ、各メンバの構成が複雑だったり、
アラインメントなど、コンパイラ依存な部分も多いかと思ったので、
プログラムで解決することはしたくなかったのです。

また、プログラムが、ファイルから読み込んだメモリをそのまま構造体データとして
使う仕様だったので、プログラムソースと同じ結果を吐くコンパイラでバイナリデータを
作成する必要があると思い、質問しました。

とりあえず、
gcc -c test.cpp -o test.o
objcopy -O binary test.o test.bin
のように、objcopyを使うことでなんとかなりそうです。

いろいろありがとうございました。


581 :デフォルトの名無しさん:04/05/18 23:17
>>580
それポインタどうするの?
変数定義が複数あっても大丈夫?

582 :デフォルトの名無しさん:04/05/18 23:31
>>581
> それポインタどうするの?

典型的なのが、
char *strs[] = { "This", "is", "a", "test", };
ですね。

char strs[][5] = { "This", "is", "a", "test", };
なら、なんとかなりますが。


583 :568:04/05/19 01:36
>>581
>それポインタどうするの?
ポインタやリンカ解決が必要なデータは含まれない仕様なので、大丈夫でした。
構造体自体は複雑なのですが、内容はすべて数値、かつ、変数定義が1つなので、
先頭からのオフセットさえ正しければOKだったので。
では。


584 :デフォルトの名無しさん:04/05/19 21:49
GCCの生成するコードの、ABI資料はありません?

585 :デフォルトの名無しさん:04/05/20 15:44
ABIの何が知りたいの?

586 :デフォルトの名無しさん:04/05/20 16:06
何のABIが知りたいの?

例: i386 の関数呼び出しのABI、C++ の例外ハンドリングのABI


587 :デフォルトの名無しさん:04/05/20 18:25
http://www.caldera.com/developers/devspecs/
http://www.codesourcery.com/cxx-abi/
この辺しか知らない

588 :584:04/05/20 20:00
>>585,586
そのものズバリです、i386の関数呼出ABIです
>>587
おお!素晴らしい!読んでみますです

C関数コール時にに各レジスタの内容を、アセンブルコード側
で保証しなくてはならないのか、GCCの吐くコード側で保証
されるのか知りたかったのです。それとEBP(フレームポインタ)の扱いも~
(gcc -S foo.c で出力されるコードでは、(E)AX以外の内容も保証されていませんでしたが
VCの吐いたPEコードを逆アセンブルした時は、呼出先で保証していた気が...)

アセンブルするのは不慣れなんで、ABI仕様を読めば、
その辺りの規定が書いてあるんじゃないかと考えた次第です
どうもDebian上のGCC3.3.3 で -Os -O3 を付けた場合、
書いたコードの挙動が怪しくて...
最適化に左右されないCコードの呼出を行うには、
関数呼出規定を熟知しておこうと...

589 :デフォルトの名無しさん:04/05/20 21:35
まとまった文章は読んだことないけど、i386 だと
eax, ecx, edx が関数内で壊していいレジスタ、
ebx, esi, edi が関数内で変えちゃいけないレジスタ。
これは、Windows でも *BSD でも Linux でも同じはず。

gcc-3.3.x のソースだと、gcc/config/i386/i386.h の
CALL_USED_REGISTERS の値かね。

こういうのって、Intel が決めたのかなあ?


590 :デフォルトの名無しさん:04/05/20 21:56
>>589
ふつうCPUメーカが決める。大抵CPUのマニュアルに書いてあるよ。

591 :デフォルトの名無しさん:04/05/20 21:59
>>589
なんてコッタ、EAX,ECX,EDXって保証する必要無いんですね..
Intelアーキテクチャマニュアル上巻見直します...

>>gcc-3.3.x のソースだと、gcc/config/i386/i386.h の
>>CALL_USED_REGISTERS の値かね。

gcc -S -fcall-saevd-ecx -fcall-saved-edx -fcall-saved-ebx foo.c

で、 指定レジスタ使用時にpush/popされるのを確認しました
-fcall-used-reg で破壊可能レジスタとなるそうです。
アセンブル時に、保護したいレジスタはスタックフレーム
にセーブしなくてはならないってことですね
まずはマニュアルを見直します


592 :デフォルトの名無しさん:04/05/23 02:48
位置独立コードってなんでしょうか?(-fPIC)
いまいち意味がわかりません。

593 :デフォルトの名無しさん:04/05/23 02:58
>592
その名の通り、メモリ上のどのアドレスにロードされても問題ないような
コード。通常実行効率が微妙に悪くなるが、代わりに同一のバイナリ
イメージを複数のプロセスで共有できるようになる。

DLL とか共有ライブラリを作るときに使う。

594 :592:04/05/23 12:54
>>593
>その名の通り、メモリ上のどのアドレスにロードされても問題ないような
>コード。通常実行効率が微妙に悪くなるが、代わりに同一のバイナリ
>イメージを複数のプロセスで共有できるようになる。
>DLL とか共有ライブラリを作るときに使う。
Thanx.
もし仮りに、共有ライブラリ生成時に-fPICしなかった場合は、
そのライブラリを使用した時に落ちてしまうんでしょうか?

595 :デフォルトの名無しさん:04/05/23 13:02
.oにrelocatableって書いてないと、ldが怒るから.soは作れない。

596 :592:04/05/23 13:21
>>595
なるほど、ようやくわかりました。
Thanx

597 :592:04/05/24 00:43
現在、オーバレイ技術に関する勉強している者です。
オーバレイ技術って仮想メモリ全盛の今となっては、
もはや使用されないのですか、あるいは必要ないのですか?
それと、コンピュータの階層上(レイヤ)では、オーバーレイは
どのレイヤで実行されるのですか?

598 :デフォルトの名無しさん:04/05/24 01:02
まずはあんたの言ってる「オーバーレイ技術」とは何?
GCCスレで聞くからには、LDのOVERLAY指定のこと?

使用例や必要性を知らずに勉強してるの?想像しにくい状況だな。
さしあたってあんた本人が必要としてるわけじゃないのか?

どのレイヤと聞くからには、あんたの考えてるレイヤを列挙してもらわないと。
しかし、どんなレイヤがあるかは、マシン、システム、ソフトごとで様々なはずだ。

599 :デフォルトの名無しさん:04/05/24 01:33
どなたか、-fasynchronous-unwind-tables って何するものだか教えてくださいませんか?

600 :デフォルトの名無しさん:04/05/24 01:35
>>599
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg00800.html

601 :592:04/05/24 02:09
>>598
>まずはあんたの言ってる「オーバーレイ技術」とは何?
>GCCスレで聞くからには、LDのOVERLAY指定のこと?
そのとおりです。

>使用例や必要性を知らずに勉強してるの?想像しにくい状況だな。
わからないからこそ調べてるんです。

>さしあたってあんた本人が必要としてるわけじゃないのか?
さしあたって必要ではないです。でも、さしあたらないとだめなんでしょうか?

>どのレイヤと聞くからには、あんたの考えてるレイヤを列挙してもらわないと。
>しかし、どんなレイヤがあるかは、マシン、システム、ソフトごとで様々なはずだ。
様々なレイヤで存在することすらわからなかったものですから。
マシンとシステムの区別がよく分からないんですが。
レイヤがソフトであるなら、やはりローダがオーバレイ作業をするのが一般的なんですか?

602 :デフォルトの名無しさん:04/05/24 02:28
>597
オーバーレイが有効に使えるのは、

1 主記憶が狭い
2 仮想記憶がない
3 主記憶と比べて大きな二次記憶がある (これは read only のことが多い)

という場面。小さな RAM と、それより大きめの ROM で構成されてるシステムだと
使い道があるが(ゲーム機とか)、最近はハードウェア資源が豊富になってきて
るから、使う場面は少なくなってきてるんじゃないかなぁ。

メモリが増える割合に比して、コード量の増加って緩やかだから。あと、オーバーレイ
で解決せずに実行時リンク (Win32 だと DLL, UNIX なら *.so) で対応する方法も
ある。こっちの方が柔軟。

603 :592:04/05/24 02:51
>>602
ありがとうございます。

>1 主記憶が狭い
>2 仮想記憶がない
>3 主記憶と比べて大きな二次記憶がある (これは read only のことが多い)
なるほど。
これを見てて思いついたのは、組み込み系で使われる可能性がありますね。

>メモリが増える割合に比して、コード量の増加って緩やかだから。あと、オーバーレイ
>で解決せずに実行時リンク (Win32 だと DLL, UNIX なら *.so) で対応する方法も
>ある。こっちの方が柔軟。
オーバーレイで解決せずに実行時リンク?動的ライブラリのことですかね。

そもそもgcc環境では、オーバーレイor実行時リンクの作業はカーネルがするって事?

604 :デフォルトの名無しさん:04/05/24 03:32
オーバーレイの言葉の定義をしてくれー

605 :592:04/05/24 03:57
>>604
>オーバーレイの言葉の定義をしてくれー
自分がいろいろ調べて見てわかっているオーバーレイの定義は、
「少ないメモリ上で、ある関数をコールする度にオーバレイマネージャ等が
実行ファイル等から読み込み、メモリに再配置して効率的にメモリ割り当てを扱う事」
という認識でいます。間違ってますでしょうか?

606 :デフォルトの名無しさん:04/05/24 09:11
>>603
> そもそもgcc環境では、オーバーレイor実行時リンクの作業はカーネルがするって事?

gccは中立です。


607 :デフォルトの名無しさん:04/05/24 09:16
>605
> 「少ないメモリ上で、ある関数をコールする度にオーバレイマネージャ等が
それは GNU LD で実現してるオーバーレイとは違うぞ。

関数呼び出しの度に自動的にファイルを読み込むのではなく(それは遅すぎ)、
手作業で

 これから foo(), bar() を読み込むから、foo(), bar() を含むコードを
 メモリ上に読み込み

 完了後に foo(), bar() をコール

とする。

オーバーレイを有効に使うためには、プログラムを同じタイミングで呼ばれる
可能性がある複数の部分に *手作業で* 分割し、さらに読み込みタイミングを
自分で制御する必要がある。

メモリ上に読み込んでない関数をコールすると、プログラムが実行時に
吹っ飛ぶか、もしくはメモリ上に展開されている別のコードを実行して、
謎の挙動を示すことになる。


608 :デフォルトの名無しさん:04/05/24 09:18
>>605
> ある関数をコールする度にオーバレイマネージャ等が
> 実行ファイル等から読み込み、

これはある実装の機構であって、オーバーレイの定義ではないのでは?

> メモリに再配置して

ほとんどの場合、実行時に再配置もしないのでは?
再配置できるくらいなら"OVERLAY"する必要がないからね。

メモリ上のある領域をモジュール同士で共有して、排他的に利用するのが、
(たぶんあなたの言っている)オーバーレイだと思います。

オーバーレイをgccで行う方法の話じゃないんならば、
くだ質にいった方がいいんじゃない?

609 :592:04/05/24 18:21
>> 「少ないメモリ上で、ある関数をコールする度にオーバレイマネージャ等が
>それは GNU LD で実現してるオーバーレイとは違うぞ。
え、そうなんですか。もう一度GNU LDのオーバーレイを調べてみます。

>オーバーレイを有効に使うためには、プログラムを同じタイミングで呼ばれる
>可能性がある複数の部分に *手作業で* 分割し、さらに読み込みタイミングを
>自分で制御する必要がある。
これは、そのプログラム作成者がその作業をするってことですか?

>これはある実装の機構であって、オーバーレイの定義ではないのでは?
すいません。オーバーレイの定義についてまだあやふやでした。

>メモリ上のある領域をモジュール同士で共有して、排他的に利用するのが、
>(たぶんあなたの言っている)オーバーレイだと思います。
その通りです。

>オーバーレイをgccで行う方法の話じゃないんならば、
>くだ質にいった方がいいんじゃない?
そうですね。もう一度調べなおします。

Thanxでした。>>607,>>608

610 :デフォルトの名無しさん:04/05/24 18:59
> >>605
> > ある関数をコールする度にオーバレイマネージャ等が
> > 実行ファイル等から読み込み、
>
> これはある実装の機構であって、オーバーレイの定義ではないのでは?

昔アセンブラで書いたプログラムを自動的に↑とするリンカ使ったことある。
L80の互換リンカで、P?L80って名前…
LINK86互換のもあったはず。

611 :デフォルトの名無しさん:04/05/24 19:05
>>608
> オーバーレイをgccで行う方法の話じゃないんならば、
> くだ質にいった方がいいんじゃない?

って書いたけど、
Linker && Loader
http://pc5.2ch.net/test/read.cgi/tech/1033403294/
ってスレがあるね。過疎スレだけどね。

612 :!599:04/05/24 19:30
>>600
>http://gcc.gnu.org/ml/gcc-patches/2001-10/msg00800.html
↑をざっと読んだけど-fasynchronous-unwind-tablesの説明がないような気がする。

613 :592:04/05/24 19:43
>>611
実はこの本を読みながら↓質問してました。
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=4-274-06437-9
リンカ&ローダって難しい....使って天国、作って地獄って奴ですか。
関連ドキュメントが少なすぎるぅぅぅ(泣

614 :デフォルトの名無しさん:04/05/24 19:48
>>612
http://www.cqpub.co.jp/interface/column/freesoft/2004/200401/0.htm
http://www.cqpub.co.jp/interface/column/freesoft/2004/200402/0.htm

615 :612:04/05/24 19:58
>>614
サンク

616 :592:04/05/24 20:27
>>611
ここ↓見たけど途中から誤爆スレみたいなんですけど..sigh
Linker && Loader
http://pc5.2ch.net/test/read.cgi/tech/1033403294/

617 :デフォルトの名無しさん:04/05/24 23:07
>>613
この本はベストセラーだね。いい本だ。翻訳は良くできてるのかな?
この本を読んで全部理解するにはかなりの基礎知識を必要とするよ。

618 :デフォルトの名無しさん:04/05/24 23:08
>>616
あっち移ったら、あっちでお付き合いするけど
こっちはスレ違いだからね。

619 :デフォルトの名無しさん:04/05/25 00:02
>>613
>関連ドキュメントが少なすぎるぅぅぅ(泣
確かに少ないな。特に日本語のドキュメントで探すのは皆無に近い。
欧米では関連ドキュメントを探すとちゃんと見つけ出せるけど日本特有の現象なのかわからんが、
ある技術(例えばLinker & Loader)を使っているなら、その概念や動作や設計とかの資料があってもいいはずなのに、
「車輪の再発明なんかやるんじゃない」的な考えで、その関連資料を作成すること自体しなくなるのは
とてもよくない現象だと思う。
長々とスマソ。

620 :デフォルトの名無しさん:04/05/25 01:05
GCCは(・∀・)イイ!
ヽ(゚∀゚)ノGCCバンザイ!!!!

621 :デフォルトの名無しさん:04/05/25 13:59
最近、typeofが手放せなくなりつつあるんだが、
これなんとか標準C++の範囲で実現する方法はないの?
ちょっとすれ違いか。

622 :デフォルトの名無しさん:04/05/25 22:03
あの、すいません
gccのコンパイルオプションを紹介しているサイトを
教えていただけませんか?

623 :デフォルトの名無しさん:04/05/25 23:03
>622
info 読め

624 :デフォルトの名無しさん:04/05/25 23:04
>>622
googleでgcc infoを検索すれば、gccのinfoの日本語訳が見付かることだろう。


625 :デフォルトの名無しさん:04/05/25 23:18
>>614も読めよー


626 :デフォルトの名無しさん:04/05/26 01:31
隠しオプション

-fno-gates

MSVC用のpragmaを発見するとそのソースファイルを削除する

627 :デフォルトの名無しさん:04/05/26 01:36
-fno-stallman
GPL/LGPLライセンスのソースファイルを(ry

628 :デフォルトの名無しさん:04/05/26 09:48
しばらくは3.3をずっと使い続けるかな

629 :デフォルトの名無しさん:04/05/26 13:47
昔のgccでpragma使うとゲームを起動するって本当だろうか……。

630 :デフォルトの名無しさん:04/05/26 15:02
hack -> rogue -> ハノイの塔
ってやつか。
オレも気になる。

631 :デフォルトの名無しさん:04/05/26 15:23
今gcc-1.42落としてみたらcccp.cに例のコードがあったよ。

632 :デフォルトの名無しさん:04/05/26 19:09
execってオーバーレイみたいなもんだよね??

633 :デフォルトの名無しさん:04/05/26 21:03
でもinfoの説明と食い違ってるoptionあったりするしな。>gcc
info読んでも変だと思ったらsource読んで確認するのを勧める。

634 :デフォルトの名無しさん:04/05/26 21:55
>632
なにをもって「みたい」とするかに依るが。内部実装は天と地ほど違う。

635 :デフォルトの名無しさん:04/05/26 23:49
>>631
マジなんだ……。さんきゅ。俺も落としてみるか。

636 :デフォルトの名無しさん:04/05/27 12:15
>>635
俺も思わず確認してしまった。
1.42の頃はstallmanがガンガンいじってたのねぇ。

637 :デフォルトの名無しさん:04/05/28 05:43
あるソースを見てたら以下のコードがありました。
これってどういう意味ですか?
"!!"って使用できましたっけ?

if (!!var1 == !!var2)
 return 0;

638 :デフォルトの名無しさん:04/05/28 07:21
>>637
C言語くだ質スレが適当だと思うが一応。

!e → (e) ? 0 : 1
!!e → (e) ? 1 : 0

つまり!!は、0(false), それ以外(true)の0, 1への正規化。
その使い方だと、var1とvar2の(C言語的)真偽が同じならです。

flag | (!!(式) << 4)

なんてのは良く使います。


639 :デフォルトの名無しさん:04/05/28 10:47
>>637
素直にこう書いた方が判りやすいと思うのだが・・・

if(var1 && var2)
 return 0;



640 :デフォルトの名無しさん:04/05/28 11:53
>>639
それだと
var1 が 0 かつ var2 が 0 の場合に動作が異なる。

641 :デフォルトの名無しさん:04/05/28 12:04
>>639
本当にプログラマですか? (w

642 :デフォルトの名無しさん:04/05/28 12:06
if (!var1 == !var2)
return 0;
これでいいような気がする。
違うのかな?

643 :デフォルトの名無しさん:04/05/28 14:41
>>642
本当にプログラマですか? (w

644 :デフォルトの名無しさん:04/05/28 14:43
>>643
プログラマじゃないけど本当に分からない。
違い教えて。

645 :デフォルトの名無しさん:04/05/28 14:45
>>644
じゃあプログラマになれるよう、勉強しようね(w

646 :デフォルトの名無しさん:04/05/28 14:47
>>645
いいから教えろ

647 :デフォルトの名無しさん:04/05/28 14:54
>>645
おれも分らない。int型みたいな0(false)とそれ以外(true)の
{0,1}への正規化なら、>>642でいいように思うんだけど。

648 :デフォルトの名無しさん:04/05/28 15:01
>>642 はあってるぞ。
自身を持て。

649 :デフォルトの名無しさん:04/05/28 15:03
>>647
真偽が逆転するので、正規化目的なら!!だろう。
ただ、件の場合は比較しているだけなので、真偽逆でも問題なし。

650 :デフォルトの名無しさん:04/05/28 15:03
>>645
早く教えてください

if (!var1 == !var2)
if (!!var1 == !!var2)

この違いを教えてください。漏れには真偽が逆になっていて
見難いから、!!としているだけにしか見えません。

651 :デフォルトの名無しさん:04/05/28 15:09
ああ、正規化、という意図を表現したいなら!!がいいね
でもそれならマクロか何かにしてほしい

652 :デフォルトの名無しさん:04/05/28 17:13
>>651
単にあなたが見慣れてないだけじゃない?
!!というのは特徴的だし昔から使われているから、
イディオムとして受け入れる方が変なマクロ定義するよりいいと思うけど。

俺は (var?1:0) をするイディオムとして !!var を認識しているので、
if (!var1 == !var2)
よりは
if (!!var1 == !!var2)
の方が素直に読める。


653 :デフォルトの名無しさん:04/05/28 17:53
>!!というのは特徴的だし昔から使われているから、

はつみみです:-)

654 :デフォルトの名無しさん:04/05/28 18:05
652みたいなのがロートルって呼ばれるようになるんだろうナァ

655 :211:04/05/28 18:44
gcc-3.4.0 で、 gcc ディレクトリで grep -n '!!' * とかやった結果、

c-decl.c:3634: constp = !! (specbits & 1 << (int) RID_CONST) + TYPE_READONLY (element_type);
c-decl.c:3636: = !! (specbits & 1 << (int) RID_RESTRICT) + TYPE_RESTRICT (element_type);
c-decl.c:3638: = !! (specbits & 1 << (int) RID_VOLATILE) + TYPE_VOLATILE (element_type);
c-decl.c:3639: inlinep = !! (specbits & (1 << (int) RID_INLINE));
c-parse.c:1854:#define YYRECOVERING() (!!yyerrstatus)
collect2.c:824: no_demangle = !! getenv ("COLLECT_NO_DEMANGLE");
cppexp.c:320: result.unsignedp = !!(type & CPP_N_UNSIGNED);
cppexp.c:407: overflow = !!(num.high >> (PART_PRECISION - shift));
cppexp.c:593: result.unsignedp = !!unsignedp;
cppfiles.c:629: if (CPP_OPTION (pfile, deps.style) > !!sysp && !file->stack_count)
cppfiles.c:742: bool print_dep = CPP_OPTION (pfile, deps.style) > !!sysp;
cppspec.c:169: + !!o_here + !!lang_c_here + !!lang_S_here;
cpptrad.c:714: bool recursing = !!(node->flags & NODE_DISABLED);
expr.c:7398: return !!(the_word & bitmask); */
gcov.c:818: arc->on_tree = !!(flags & GCOV_ARC_ON_TREE);
gcov.c:819: arc->fake = !!(flags & GCOV_ARC_FAKE);
gcov.c:820: arc->fall_through = !!(flags & GCOV_ARC_FALLTHROUGH);
gengtype-yacc.c:429:#define YYRECOVERING() (!!yyerrstatus)
hard-reg-set.h:95: (!!((SET) & (HARD_CONST (1) << (BIT))))
hard-reg-set.h:125: (!!((SET)[(BIT) / UHOST_BITS_PER_WIDE_INT]\
ra.c:431: something_spilled = !!WEBS(SPILLED);
real.c:3043: encode_ieee_extended (fmt, buf+!!FLOAT_WORDS_BIG_ENDIAN, r);
real.c:3138: decode_ieee_extended (fmt, r, buf+!!FLOAT_WORDS_BIG_ENDIAN);
一部、みやすいように、削りましたが、ほんとにろーとるなんでしょうか???

656 :デフォルトの名無しさん:04/05/28 18:52
たったそんだけ?

657 :デフォルトの名無しさん:04/05/28 19:01
もちつけ

ロートル呼ばわりされかねないのは、
「昔から使われているから、イディオムとして受け入れろ」
という下りのところだろ。


658 :デフォルトの名無しさん:04/05/28 21:14
ロートルって何だと思ったら
中国語で老人の事なんだ(;´Д`)

659 :デフォルトの名無しさん:04/05/29 01:49
!!x って、 x != 0 と全く同じ(xが整数型の場合)でしょ?
正規化する場合でも、x != 0 が使われる場合の方が多いんじゃないかな。
少なくとも、俺はそうしてる。
俺はその方が読み易い(理解しやすい)し。

660 :デフォルトの名無しさん:04/05/29 06:20
君は、ね。

661 :デフォルトの名無しさん:04/05/29 11:36
一般的に目的がはっきりしている方が読み易いと言える

目的が0との比較なのか正規化なのかよく考えて使い分けるべし

662 :637:04/05/29 11:37
>>638-660
また一つ賢くなりました。ありがとうございました。

663 :デフォルトの名無しさん:04/05/29 14:26
D言語ってサポートされるの?

664 :デフォルトの名無しさん:04/05/29 14:31
外国人と仕事するようになって どっちも英語が出来ないので
仕方なくコードで会話するんだが 相手に意図を伝えられるコードを
意識して書くようになると それだけでバグって減るモンなんだね

665 :デフォルトの名無しさん:04/05/29 14:32
>>663 来週あたりにはサポートされます

666 :デフォルトの名無しさん:04/05/29 14:33
#define fuck head

667 ::04/05/29 14:38
ダミアソ

668 :デフォルトの名無しさん:04/05/29 17:58
fuck head って、どじなやつという訳なんだな。

669 :652:04/05/29 21:33
うーん、ロートルと言われればロートルなのかも。
Cとは12のころからかれこれ15年くらいつきあってるからなあ。


670 :ロートル2号:04/05/29 23:14
>>655
そう言えば、!!を始めて見たのはgccだった。
gcc-1.2くらいだったか?

671 :デフォルトの名無しさん:04/05/31 06:53
!!についての話題は直接gccに関係ないので、他のスレでやってくだされ。

672 :デフォルトの名無しさん:04/05/31 19:36
!!うるせーぼけ!!

673 :デフォルトの名無しさん:04/06/02 09:36
まだ、夏休みじゃないよな。


674 :俺も含めてな。:04/06/02 18:40
最近は、常時夏休みみたいな奴がいるからな。

675 :デフォルトの名無しさん:04/06/02 23:50
MinGWとこれの配布元が提供しているbinutil、gccのソースコードと
レッドハットのnewlibのソースコードをターゲットM68000でコンパイル
して、クロスコンパイル環境構築できますか?
(やったことのある人がいれば教えてください)

H8のクロスコンパイル環境の情報は多いんですが、M68000の
情報がほとんどないもので。

よろしくお願いします。


676 :デフォルトの名無しさん:04/06/03 00:10
ttp://www.pcs.usp.br/~jkinoshi/bs/b030722.html

--target=m68k-coff か --target=m68k-elf を指定すれば
できるじゃねえの?

677 :デフォルトの名無しさん:04/06/03 00:15
>MinGWとこれの配布元が提供しているbinutil、gccのソースコードと
Win32上でbuildしてる奴ほとんどいねぇと思う。
オレがやってみた感想。
だってあそこのbison使い物にならんし、
素直にコンパイル通すだけでもツール類自力でmakeしないといかんし。

678 :675:04/06/03 00:19
>>676

情報サンキューさんです。
多分これと同じ要領でコンパイルできそうですね。

MinGWというのが気になっているんですが、実際にやってみれば
どうなのかわかるかな?

679 :675:04/06/03 00:21
>>677

そうですか。クロスコンパイル環境を整えるにはやっぱり
UNIXやLinuxつかったほうがいいんですかね...。

680 :デフォルトの名無しさん:04/06/03 01:47
>>679
cygwin でもいけるんじゃない?

681 :デフォルトの名無しさん:04/06/03 10:50
bison1.8が改悪なんだなぁ。Win32上でのmake失敗の原因はこれだし。
スケルトンファイルをsendmail.cf化しようなんて何考えてんだか。
設計を改めず拡張してどんどこ改悪していくのはGNUの悪い癖。

682 :どんどこ:04/06/03 12:51
どんどこ

683 :デフォルトの名無しさん:04/06/03 22:33
>>675
聞くばっかりじゃなくて、実際にやって見れば
痛い目にあった方がスキルが上がる気がするけど

684 :デフォルトの名無しさん:04/06/03 23:47
>>681
>bison1.8が改悪なんだなぁ。Win32上でのmake失敗の原因はこれだし。
「最初からWinなんて眼中無かった。」に500000カノッサ

685 :675:04/06/04 00:28
>>683

そうですね。実際にやってみたほうがいいですね。
週末になれば時間が確保できるのと、試せる環境が
つかえるようになるのでやってみようと思います。

MinGWでだめだったらCygwin、それでもだめだったら
最後の手段でLinux...といきたいところですが、色々な
都合でそんなに時間がかけられないかもしれないです。

本当は市販のコンパイラを買ってもいいんですが、
gccを使うのはスキルアップも目的です。本当は
少し時間をかけてチャレンジしたいんですけどね。


686 :デフォルトの名無しさん:04/06/04 01:05
漏れも最近MinGW相手にクロスコンパイラ編成しますた。
ぶっちゃけ、イバラの道ですた。
Cygwinと比べてコミュニティの規模が小さいせいか、自前で解決しなきゃ
ならんネタが多いんですよ。
MinGWのダウンロードページから落とせるtar玉には大抵MinGW用のパッチが
あたってるので、迂闊にGNUのページとかから落としてくるより楽なんだけど、
それでもビルドできないシチュとかが結構ある。
特にクロスコンパイル編成だと、configureが混乱するのか、時々わけのわからん
ヘッダを持ってこようとしたりして、激しく混乱が加速するです。
ビルド済みパッケージには、大抵ポーティングリスト(元のパッケージから
何を変えたか)が添付されてるので、使わなくても落としてくるのが吉。
/usr/doc以下にドキュメント追加されます。
gdbがシリアル接続受け付けなかったり、明らかに消しちゃいかん機能を
消して無理矢理ビルド通してたりするので、いまいち信用ならないけど。

漏れ的に困ったのは、gccがfork等posixの関数を要求してくるところとか。
collect2とかが引っかかるので、Makefileから外してしまうので一応解決するます。

687 :675:04/06/04 01:21
>>686

本家MinGWのメーリングリストでも
「collect2でひっかかるけどどうすんの?」
「collect2はMinGWのパッケージには公式に入ってないよ。
これをどうするかどうかは過去に何回か議論しているからログ読め」
というやりとりがあったようですね。

あの、ついでにmakefileの修正箇所なぞを大雑把に
晒してもらえると大変助かるんですが。
だめですかね?

688 :675:04/06/04 01:40
ああ、英語の意味がやっといまわかりました。
過去ログ読めってことか。

うっかり、collect2が公式パッケージに入っていない
理由について述べられているんだと勘違いしてしま
いました。

689 :デフォルトの名無しさん:04/06/04 16:20
まったく関係ないが、C++ の場合、
bool operator!() const をクラスに定義して、
if( !!obj ) と使うことがある。



690 :デフォルトの名無しさん:04/06/04 20:42
>>689
メンバ関数ポインタを使う手もある。これだと整数型への暗黙の型変換が
できないから、ケアレスミスを防げるし。

class foo
{
  void dummy();
public:
  typedef void (foo::*unspecified_bool_type)();
  operator unspecified_bool_type() const {
    return xxx ? &foo::dummy : NULL;
  }
};

691 :デフォルトの名無しさん:04/06/05 08:09
>>690
ところでなんでC++ってNULLを予約後にしなかったんだろう。

692 :デフォルトの名無しさん:04/06/05 08:10
>>691
×予約後
◯予約語

693 :デフォルトの名無しさん:04/06/05 08:19
null(NULLではない)を予約語にする動きはまだある。

694 :デフォルトの名無しさん:04/06/05 12:17
gccのオプション-fomit-frame-pointerについて質問です.
gccのマニュアルを見ると
(例えば,http://gcc.gnu.org/onlinedocs/gcc-3.3.3/gcc/Optimize-Options.html#Optimize%20Optionsなど)
最適化オプション-Oを指定すると,-fomit-frame-pointerは自動的に指定されるように思われます.
しかしながら,世のgcc向けのソースを見ると,
最適化オプション(-O,-O2,中には-O6なんてのもある.効いているのか?)と-fomit-frame-pointer
を併せて指定している例を多々見掛けます.(例えば,Linuxカーネルのソースなど.)
これは,一体どういうことなんでしょう?
プログラマの勘違いなんでしょうか.
あるいは,昔は-Oが-fomit-frame-pointerを自動的に指定していなかった時期とかあるんでしょうかね?
ご存知の方いらっしゃいますでしょうか?


695 :デフォルトの名無しさん:04/06/05 12:42
環境依存でそうだった

696 :695:04/06/05 12:47
>>694
つーか,お前さんの示してるgcc-3.3.3のマニュアルでも,まだ,環境依存じゃん(w
>on machines where doing so does not interfere with debugging
ダマサレター

697 :694:04/06/05 12:50
>>695
x86では,-fomit-frame-pointerを有効にするのに
-Oと別に,明示的に指定する必要があるのでしょうか?


698 :デフォルトの名無しさん:04/06/05 12:54
>>694
> 最適化オプション-Oを指定すると,-fomit-frame-pointerは自動的に指定されるように思われます.

??? 英語力がないのか ?
だったら http://www.excite.co.jp/world/english/ とか使えよ。

英) -O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging.
日) -Oは、さらにそうすることがデバッギングに邪魔をしない機械上で―fomit構造ポインターをつけます。

699 :デフォルトの名無しさん:04/06/05 13:02
>>697
オプションの指定を最適化したいのか ?

フレームポインタ付けたくないなら指定すればいいと思うが。

700 :694:04/06/05 13:09
>>698
あぁ,すみません.
上の方にはそう書いてありますね.
もっと下の-fomit-frame-pointerの項目の
> Enabled at levels -O, -O2, -O3, -Os.
ばっかり見てました.
697の質問については,多分,
-Oと-fomit-frame-pointerを併記するソースが多いということが
その答えを物語ってるんでしょうね.


701 :694:04/06/05 13:18
>>699
> オプションの指定を最適化したいのか ?
はい.
CPUはPentium3で,今んとこ,
-O3 -march=pentium3 -msse -mfpmath=sse -fforce-addr -funroll-loops -fomit-frame-pointer
を付けてコンパイルしています.
やっているのは浮動小数点演算中心の計算です.
他にお勧めとかあったら,是非お教えて下さい.


702 :デフォルトの名無しさん:04/06/05 17:40
>>701
厳密なエラー処理が必要ない場合は -ffast-math も利く。

703 :694:04/06/05 19:31
>>702
-ffast-mathはなんとなく恐くて敬遠してましたがこの際理解しようと思います.
-ffast-mathで設定されるオプションのうち,いくつかが良く分かりません.
オプションによって結果が変わる短い例を示してもらえないでしょうか?
以下はだいたい分かります.
-fno-math-errno: errnoが設定されなくなる.
(e.g.)
$ cat test.cpp
#include <iostream>
#include <cmath>
#include <errno.h>
using namespace std;
int main () {
double d0 (-1);
cout << sqrt (d0) << " " << flush;
perror (NULL);
return 0;
}
$ g++ -O test.cpp; ./a.out
nan Numerical argument out of domain
$ g++ -O -ffast-math test.cpp; ./a.out
nan Success

-funsafe-math-optimizations: 計算精度がユーザからはコントロール不能な最適化が行なわれる.

以下がいまいちよく分かりません.
-fno-trapping-math
-ffinite-math-only
-fno-signaling-nans
(因みに私の環境はg++ 3.3.3 on Linux 2.4.26)


704 :デフォルトの名無しさん:04/06/05 19:49
>>703
-fno-trapping-math
IEEE 754 では、演算結果が非数 (0/0 とかの場合) や無限大など「ふつー
じゃない数」になった場合に割り込みを発生させ、事前に登録した割り込み
ハンドラに制御を移すことが可能になっている。

この割り込み処理がないことを前提にして最適化を行う。

-ffinit-math-only
演算結果が非数や無限大にならないことを前提にして最適化を行う。

-fno-signaling-nans
これは -fno-trapping-math のサブセットで、非数の場合に割り込みが
発生しないことを前提とする。無限大などでは割り込み発生させても OK。

705 :694:04/06/05 21:21
>>704
丁寧なレスをどうもありがとうございます.
> -fno-trapping-math
> -fno-signaling-nans
これ,UNIXだとシグナルで通知されるんですよね.たぶん.SIGFPEだと思い,
#include <iostream>
#include <signal.h>
using namespace std;
void func (int number) {cout << "SIGFPE occured " << number << endl;}
int main ()
{
if (signal (SIGFPE, func) == SIG_ERR) exit (1);
double d0 (0), d1 (0);
cout << (d0 / d1) << endl;
for (;;)
pause ();
return 0;
}
ってなコードを書いてみましたがfuncが呼ばれません.
まぁ,いずれにしても事前に割り込みハンドラを登録したプログラムでない限り,
-fno-trapping-mathの有無で動作が変わることはないということですよね.

> -ffinit-math-only
> 演算結果が非数や無限大にならないことを前提にして最適化を行う。
これがまだ分かりません.
結果が変わってくるような例ってないですか?


706 :694:04/06/05 21:26
>>705がなんか変なコードになっている.
for (;;)は抜いて下さいまし.


707 :デフォルトの名無しさん:04/06/06 01:40
>>705
> まぁ,いずれにしても事前に割り込みハンドラを登録したプログラムでない限り,
> -fno-trapping-mathの有無で動作が変わることはないということですよね.
確か OS によりけりだった気がするけど、694 の環境ではその理解で問題ない
かと。あとシグナルハンドラ中で呼べる関数には厳しい制約があるので、stream
とか操作すると不味いです。念のため。

> 結果が変わってくるような例ってないですか?
b = a + 1.0 - 1.0;

a が極めて大きな数の場合 a + 1.0 の段階で +Inf になってしまい、
結果的に b = Inf ( != a) ってケースがありえる。無限大にならない
と仮定すれば a = b; と最適化しちゃって OK。

708 :675:04/06/06 16:15
みなさんのアドバイスのおかげで無事、M68Kクロスコンパイル
環境が構築できました。ありがとうございました。

どうやらcollect2問題はMinGWで配布されている3.4系には
パッチがあたっているようです。

その他にも色々問題はありましたが、基本的にMinGWの
メーリングリストとgoogleで解決しました。

bisonやflex、gettextやlibiconvといったものは、
http://sourceforge.net/project/showfiles.php?group_id=23617
からダウンロードしました。
(これらをインストールするときはインストール先のパスにスペースが
入っていると駄目なのにはまりましたが)



709 :694:04/06/06 16:28
707様,レスをどうもありがとうございます.
>>704
> IEEE 754 では、演算結果が非数 (0/0 とかの場合) や無限大など「ふつー
> じゃない数」になった場合に割り込みを発生させ、事前に登録した割り込み
> ハンドラに制御を移すことが可能になっている。
環境依存の話になってくるかも知れませんが(もし,他に適切なスレがあれば誘導をお願いします.),
このような数学的例外が起こった場合に実行する割り込みハンドラって
どうやって登録するのでしょうか? ご存知の方いらっしゃいますでしょうか?
ぐぐってみたらmatherrってのがそれっぽい感じがするのですが,使い方が分かりません.


710 :デフォルトの名無しさん:04/06/06 16:39
man feenableexcept
C99 floating point rounding and exception handling

711 :694:04/06/06 16:42
>>707
> b = a + 1.0 - 1.0;
> a が極めて大きな数の場合 a + 1.0 の段階で +Inf になってしまい、
> 結果的に b = Inf ( != a) ってケースがありえる。無限大にならない
> と仮定すれば a = b; と最適化しちゃって OK。
ん〜,どんな類の最適化が起こりうるか,雰囲気は伝わってきたんですが,この例ですと,
「a が極めて大きな数の場合 a + 1.0 の段階で +Inf になってしまい」
これがそもそも「無限大にならないと仮定」するしないに関わらず,
浮動小数点数では起こり得ないのではないでしょうか?
aが極めて大きな数の場合に,a+1.0は丸められてしまうので上記仮定に関わらず常にb != Inf ( == a)
になると思います.試しに,以下のようなものを書きました.冒頭のoutput_as_bitsはビットダンプする関数です.
#include <iostream>
#include <bitset>
template <class T> std::ostream & output_as_bits (std::ostream &p_os, const T &p, bool ascending_order = true) {
bitset <sizeof (T) * 8> p_bit; const char *pp (reinterpret_cast <const char *> (&p)); char byte_digit (1);
for (size_t i (0); i < p_bit.size (); ++ i) {
p_bit.set (i, static_cast <bool> (*pp & byte_digit));
if ((i + 1) % 8) byte_digit <<= 1;
else {byte_digit = 1; ++ pp;}
}
if (ascending_order) {
p_os << "L"; size_t i (0);
while (i != p_bit.size ()) {p_os << p_bit.test (i); ++ i;} p_os << "H";
} else {
p_os << "H"; size_t i (p_bit.size ());
do {-- i; p_os << p_bit.test (i);} while (i != 0); p_os << "L";
}
return p_os;
}
(続く)


712 :694:04/06/06 16:43
(711の続き)
int main () {
double d0 (1);
while (true) {
d0 *= 2; if (d0 == (d0 + 1)) break;
}
output_as_bits (std::cout, d0) << " " << d0 << std::endl;
output_as_bits (std::cout, d0 + 1) << " " << (d0 + 1) << std::endl;
return 0;
}
結果:
L0000000000000000000000000000000000000000000000000000111111000010H 1.84467e+19
L0000000000000000000000000000000000000000000000000000111111000010H 1.84467e+19


713 :デフォルトの名無しさん:04/06/06 16:48
>>711
確かに。+1.0 ではなく + FLT_MAX / 2 ぐらいにしたほうが現実的だったかも。

714 :694:04/06/06 17:13
本当はこれで結果に差が出てくれば,納得するんですが....
$ cat test.cpp
#include <iostream>
#include <bitset>
#include <cmath>
using namespace std;
typedef double Type;
template <class T> std::ostream & output_as_bits (std::ostream &p_os, const T &p, bool ascending_order = true);
const Type limit (numeric_limits <Type>::max ());
const Type half_of_limit (limit / 2);
template <typename T> T func1 (T p) {return p + half_of_limit;}
template <typename T> T func2 (T p) {return p + half_of_limit - half_of_limit;}
int main () {
Type d0 (limit); Type d1 (func1 (d0)); Type d2 (func2 (d0));
output_as_bits (cout, d0) << " " << isinf (d0) << " " << d0 << endl;
output_as_bits (cout, d1) << " " << isinf (d1) << " " << d1 << endl;
output_as_bits (cout, d2) << " " << isinf (d2) << " " << d2 << endl;
return 0;
}
$ g++ -O2 test.cpp; ./a.out
L1111111111111111111111111111111111111111111111111111011111111110H 0 1.79769e+308
L0000000000000000000000000000000000000000000000000000111111111110H 1 inf
L1111111111111111111111111111111111111111111111111111011111111110H 0 1.79769e+308
$ g++ -O2 -ffinite-math-only test.cpp; ./a.out
L1111111111111111111111111111111111111111111111111111011111111110H 0 1.79769e+308
L0000000000000000000000000000000000000000000000000000111111111110H 1 inf
L1111111111111111111111111111111111111111111111111111011111111110H 0 1.79769e+308
う〜む.同じだ.最初の実行結果の3行目がinfであって欲しいんですが.

>>710
ありがとう御座います.学ぶ足掛かりができました.


715 :デフォルトの名無しさん:04/06/06 17:29
>>714
x87 だと FPU は 80bit あるののに double は 64bit だから、マジメに
計算しても FPU 内部ではオーバーフローしないような気がする。
FPU を 64bit モードにするか拡張精度浮動小数点数 (long double)
で試してみては?

あと gcc はマニュアルに書いてあることが完全に実装できてないことも
あるので、これで動作に疑問があるようなら gcc のソースを読んだ方が
良いかも。

716 :694:04/06/06 17:40
>>715
> 拡張精度浮動小数点数 (long double)で試してみては?
714の冒頭のtypedef double Typeをtypedef long double Typeにしてやってみました.
$ g++ -O2 test.cpp; ./a.out
L111111111111111111111111111111111111111111111111111111111111111101111111111111100000000000000000H 0 1.18973e+4932
L000000000000000000000000000000000000000000000000000000000000000111111111111111101111111111111101H 1 inf
L000000000000000000000000000000000000000000000000000000000000000111111111111111101111111111111101H 1 inf
$ g++ -O2 -ffinite-math-only test.cpp; ./a.out
L111111111111111111111111111111111111111111111111111111111111111101111111111111100000000000000000H 0 1.18973e+4932
L000000000000000000000000000000000000000000000000000000000000000111111111111111101111111111111101H 1 inf
L000000000000000000000000000000000000000000000000000000000000000111111111111111101111111111111101H 1 inf
今度は,両方とも溢れちゃいました.
どうやらこの例では-ffinite-math-onlyによる,演算順序の変更は行なわないようです.
まぁ,でも-ffinite-math-onlyが何をする可能性があるかは理解できました.ありがとう御座いました.
(良い例が思い付いたらお教え下さいね.)

> これで動作に疑問があるようなら gcc のソースを読んだ方が
> 良いかも。
そうですね.


717 :デフォルトの名無しさん:04/06/09 05:34


718 :デフォルトの名無しさん:04/06/09 23:53
サンクスコ


719 :デフォルトの名無しさん:04/06/11 00:03
gccの最適化オプションで-march=pentium4としたら-mmmx、-msse、-msse2も自動的にONになるんですか?

720 :デフォルトの名無しさん:04/06/11 00:42
それはさすがにならんだろ
cmovとかは使うだろうけど

721 :デフォルトの名無しさん:04/06/11 00:54
なる

722 :デフォルトの名無しさん:04/06/11 00:55
>>720-721
どちらが正しいのですか?

723 :デフォルトの名無しさん:04/06/11 00:59
-fverbose-asm

724 :デフォルトの名無しさん:04/06/11 04:05
gcc-3.3.1
gcc/config/i386/i386.c
{"pentium4", PROCESSOR_PENTIUM4, PTA_SSE | PTA_SSE2 |
PTA_MMX | PTA_PREFETCH_SSE},

バージョンによっては違うかもしれないので
ttp://gcc.gnu.org/cvs.html
で確認してみては?

725 :719:04/06/11 19:20
>>722-724
なるほど、ソースコード読んでみるという手がもっとも確実ですね。
ありがとうございます。


726 :デフォルトの名無しさん:04/06/12 02:44
>>721 「なる」ってなるほどのことかと思ったよ。

727 :デフォルトの名無しさん:04/06/12 08:43
なる

728 :デフォルトの名無しさん:04/06/12 10:32
で、結局の所どーだったのよ。

729 :デフォルトの名無しさん:04/06/12 10:42
「バージョンによって違うかもしれない」

730 :デフォルトの名無しさん:04/06/12 12:33
その日の天気による

731 :デフォルトの名無しさん:04/06/12 17:53
晴れの日はコンパイルしよう

732 :デフォルトの名無しさん:04/06/12 22:05
WindowsXPのコマンドプロンプトから
c:\cygwin\bin\g++ ../test.cpp
(c:\cygwin\bin\g++ ..\test.cpp)
(c:\cygwin\bin\g++ ..\\test.cpp)
としても
cc1plus: ../test.cpp Not Such File or Directory
とでてコンパイルできないのですが、何がいけないのでしょうか?
以前はこれでできていたはずなのですが...。


733 :694:04/06/12 22:11
>>732
c:\cygwin\bin\ls ..
は?


734 :732:04/06/12 22:41
>>733
動きました。
実行しているディレクトリ名に日本語が含まれていたのが
原因だったみたいです。


735 :デフォルトの名無しさん:04/06/12 23:53
>>734
今の最新版だとそうなる。1.5.9-1までならOK。

736 :735:04/06/12 23:54
おっと。cygwinのバージョン、な。

737 :732:04/06/13 01:29
>>735
>>733,735さん ありがとうございます。
なるほどそういうことでしたか。

もうバージョンあげちゃったんで
次期バージョンでは直っててホスィ


738 :デフォルトの名無しさん:04/06/13 22:13
構造体の配列がグローバル変数で定義されているとして、別のソースファイル中で
その配列を参照する場合には、まずそのファイル中で配列をextern宣言しますよね。
このとき、extern struct foo[3]と配列の個数を明示してやらないと、
参照した時点でSIGSEGVを食らいます。(少なくともgcc-3.2.2の場合)

単にextern struct *fooでも良いと思ってたんですが、これってgcc-3.2.2のバグ
ですか、それともCの仕様ですか? 少なくともextern struct *fooでもコンパイル
オプションに-Wallとか付けても問題なく通ります。

739 :デフォルトの名無しさん:04/06/13 22:23
>>738 ここにもポインタ変数と配列を混同している人が。。。

740 :デフォルトの名無しさん:04/06/13 22:47
>>738 頭の悪い脊髄反射レスは要らない。
extern struct foo[]としても、SIGSEGVを食らう。
なぜ、構造体のアドレスが正常に渡されないかが問題なのだ。

例えば、配列中の構造体の大きさが、実際に宣言されるまで不定で
あるような場合(構造体内部にchar *のような文字列のポインタを含む場合)、
コンパイラは間違ったポインタを渡してしまう可能性が考えられる、
とかそういうふうな答えを期待した。


741 :デフォルトの名無しさん:04/06/13 23:05
C言語スレに池

742 :デフォルトの名無しさん:04/06/13 23:11
答える知識がないなら黙ってればいいのに。

743 :デフォルトの名無しさん:04/06/13 23:18
>>740
煽るんなら、アンカーぐらいちゃんとしないと、自分で自分が「頭の悪い脊髄反射」とカミングアウトしてることになってるぞ。(藁

それはそれとして、

extern struct foo[3];
extern struct *foo;
extern struct foo[];

でコンパイルエラーにならない、GCC のバージョンを教えてくれ。

手元の、2.95.4 は全部シンタックスエラーにしやがるからな。(藁

744 :デフォルトの名無しさん:04/06/13 23:20
>>743
gcc-3.2.2と書いてあるが…。


745 :sage:04/06/13 23:26
>>743
君も配列とポインタ変数を混同していないかい?


746 :デフォルトの名無しさん:04/06/13 23:38
gccにはバージョン3以降で構造体(あるいはそのメンバ)のアドレス計算を間違うバグがあったんだがね。
それを知っていれば、配列とポインタ変数をどうこうなんてレスは返さないと思われ。

例えばfoo[2].bar.len++とすると、関係ないメモリをインクリメントしようとしていた
事がある。これをfoo[2].bar.len += 1と書くとなぜか回避できた。

答えられないなら、黙ってていいよ。

747 :デフォルトの名無しさん:04/06/13 23:45
>>744
こりゃ失礼。
って言うか、そういう問題じゃないんだけどね。

>>745
そういう問題じゃなくて、一体 foo の型って何 ? って言う話なんだけどな。
(わざわざ「シンタックスエラー」とまで書いてあるのにわからんかな...。)

>>746
そういう個別のバグ ? の話までするんであれば、問題のソースと -S の結果を貼った方が早いと思うが。

748 :デフォルトの名無しさん:04/06/13 23:48
>>746
はぁ?
配列を外部参照しにいくにもかかわらず、extern struct *fooと
書いてることが問題であって、アドレス計算は関係ないと思うのだが?


749 :デフォルトの名無しさん:04/06/13 23:51
>>746
「答えられないなら、黙ってていいよ」
こんな台詞吐くやつは大概厨房と決まってるんだがな。
GCCのアドレシングのバグなぞを持ち出してきているが、それ以前の問題だ。
char c_ary[10] の型は char* ではないということだよ。

750 :デフォルトの名無しさん:04/06/13 23:55
実際のソースは長いので、要約するとこんな感じ。

-- c.h --
typedef struct {
 int len;
 char *str;
} lascii;
-- sample1.c --
#include "c.h"
lascii foo[3] = {
 {3, "abc"},
 {4, "defg"},
 {5, "hijkl"}
};
extern int hoge();
main()
{
hoge();
}
-- sample2.c --
#include "c.h"
extern lascii foo[]; // ここでfoo[3]とすれば無問題

int hoge()
{
 printf("%s\n", foo[2].str);
}

751 :デフォルトの名無しさん:04/06/14 00:04
配列中の構造体が全て同じ大きさであることが保証されているならば配列で
宣言することは無理もない事だけど、ある程度のメモリ容量が必要だったり
構造体の大きさがまちまちならば、ポインタで宣言しておいて、malloc()で
メモリを割り当てるだろうな。


752 :デフォルトの名無しさん:04/06/14 00:29
>>750
少なくとも、そのソースは 2.95.4 なら問題はない。
他のまともなコンパイラでも問題はないはず。
お前の使ってるバージョン固有の問題、もしくはお前の環境の問題と思う。
もしこのソースでエラーになるなら、sample2.c の -S の結果を貼ってくれ。

>>751
> ある程度のメモリ容量が必要だったり

何が言いたいのかよくわからん。
日記なら、ご自分の日記帳にでも書いておけよ。

753 :デフォルトの名無しさん:04/06/14 01:24
大量の配列を宣言するくらいなら、ポインタで変数を宣言してmalloc()でメモリを
割り当てるでしょうな。

「ポインタと配列は違…」とか叫ばれてもね。そんなことは聞いてないし、言わ
なくていい。それは今問題にしてない。問題かもしれないが。

構造体の配列をextern宣言する時に配列数を含めておかないと正しい参照が
出来ないのはどういうことなのか、を気にしているの。
コンパイル時にアドレスが不定で決定できないならば、エラーなりワーニングを
出せば済む事なのだが、-Wallなどを付けても問題なく通る。

754 :デフォルトの名無しさん:04/06/14 01:58
>>753
>>751のソースは問題ない。それで動かないならコンパイラのバグ。
* fooで動かないのは当り前。それで動くと思うのはおまえの頭のバグ。

755 :デフォルトの名無しさん:04/06/14 06:59
>>753
> コンパイル時にアドレスが不定で決定できないならば、エラーなりワーニングを
> 出せば済む事なのだが
リンク時の話だからコンパイラには何もできないでしょ。


756 :デフォルトの名無しさん:04/06/14 07:56
>>750のソースと違うのかと>>754の耳に息を吹きかけながら囁いてみるテスト

なんでもいいが、>>753はそろそろ黙っとけ。

757 :デフォルトの名無しさん:04/06/14 08:25
しかし>>738にextern struct *fooとはっきり書いてるし。

>>738
> 単にextern struct *fooでも良いと思ってたんですが、

配列の不完全型を理解してないんでしょうね。

758 :デフォルトの名無しさん:04/06/14 20:01
言語を知らんヤツがコンパイラを語るってイタイよな。


759 :デフォルトの名無しさん:04/06/15 09:07
ポレは、警告を「ワーニング」って呼ぶ奴を、「あぁ、ばかなんだな」と思うことにしてるんだが。

760 :デフォルトの名無しさん:04/06/15 09:15
>>759
なぜ?
「ワーニング」ではなくて何と呼ぶんだ?
まさかとは思うが「ウォーニング」とか言うなよ。

761 :デフォルトの名無しさん:04/06/15 11:22
放置でおながいします

762 :760:04/06/15 13:18
>>761
>放置でおながいします
当たったのかよ。藁

763 :デフォルトの名無しさん:04/06/15 14:15
「わーん」の方がアップアップしてる感じが良いなぁ。

764 :デフォルトの名無しさん:04/06/15 14:33
ワーンヽ(`Д´)ノing

765 :デフォルトの名無しさん:04/06/15 14:45
ウォーヽ(`Д´)ノning

766 :デフォルトの名無しさん:04/06/15 15:39
アハーンヽ(`Д´)ノping

767 :デフォルトの名無しさん:04/06/15 16:18
>>766
>アハーンヽ(`Д´)ノping
ムシロ意味がわからん。

768 :デフォルトの名無しさん:04/06/15 16:32
エロ画像

769 :デフォルトの名無しさん:04/06/15 19:51
gccとは直接関係ないのですが、お願いします。
clispというパッケージをコンパイルしていて以下のようなエラーが出ました。

gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wno-sign-compare -O2 -fexpensive-optimizations -DUNICODE -DDYNAMIC_FFI -I. -I../../ -c linux.c
linux.c: In function `module__linux__init_function_2':
linux.c:434: error: `sigpause' undeclared (first use in this function)
linux.c:434: error: (Each undeclared identifier is reported only once
linux.c:434: error: for each function it appears in.)
make[1]: *** [linux.o] Error 1

ここで疑問なのですが、Makefileからコンパイラへ渡される変数の一覧は
どのように探したらいいのでしょうか?-DXXXというオプションがここでは
二つほど渡されていますが、他にどのような値があるのか知りたいと思います。

770 :デフォルトの名無しさん:04/06/15 19:56
-E
プププ...Makefileから渡される変数など存在しない

771 :デフォルトの名無しさん:04/06/15 20:16
make -n とかやって眺めるのが簡単じゃないの?

772 :GentooLinux glibc-2.3.4です。:04/06/15 20:22
clispのlinux.cはこのようになっています。

#include <signal.h>
・・・
void module__linux__init_function_2 (module_t* module)
{
・・・
register_foreign_function((void*)&sigpause,"sigpause",1024);


つまりLibcの関数をあるテーブルに登録してると思われる処理です。
またclispのパッケージにはsignal.hというファイルは存在していません。

773 :デフォルトの名無しさん:04/06/15 20:23
signal.hのsigpauseに関する場所はこのようになっています。
ここにコピペした場所以外にはsigpauseは記されていません。

/* The `sigpause' function has two different interfaces. The original
BSD definition defines the argument as a mask of the signal, while
the more modern interface in X/Open defines it as the signal
number. We go with the BSD version unless the user explicitly
selects the X/Open version.
This function is a cancellation point and therefore not marked with
__THROW. */
extern int __sigpause (int __sig_or_mask, int __is_sig);

#ifdef __FAVOR_BSD
/* Set the mask of blocked signals to MASK,
wait for a signal to arrive, and then restore the mask. */
extern int sigpause (int __mask) __THROW;
# define sigpause(mask) __sigpause ((mask), 0)
#else
# ifdef __USE_XOPEN
# ifdef __GNUC__
extern int sigpause (int __sig) __asm__ ("__xpg_sigpause");
# else
/* Remove a signal from the signal mask and suspend the process. */
# define sigpause(sig) __sigpause ((sig), 1)
# endif
# endif
#endif

ここで__FAVOR_BSD=FALSE,__USE_XOPEN=FALSEだったらエラーになりますよね。

774 :デフォルトの名無しさん:04/06/15 20:37
>>773
770が言うように-Eしてみたら手掛かりになるのでは?


775 :デフォルトの名無しさん:04/06/15 20:42
Glibc-2.3.2では上の__FAVOR_BSDのところが__USE_BSDになっています。
これってGlibc,GCCの環境設定,clispのどれが悪いと思われますか?
glibc-2.3.4,gcc-3.4とあたらしめのものなので、バグがあるのは当然です。

$gcc -E -I. -I../../ linux.cをしてみました。
sigpauseが含まれているのは以下の箇所だけ。

extern void psignal (int __sig, __const char *__s);
# 149 "/usr/include/signal.h" 3 4
extern int __sigpause (int __sig_or_mask, int __is_sig);
# 178 "/usr/include/signal.h" 3 4
extern int sigblock (int __mask) ;

register_foreign_function((void*)&sigpause,"sigpause",1024);

となると、上の/usr/include/signal.hと比べれば、やはりGlibcがおかしいっぽいですね。

776 :デフォルトの名無しさん:04/06/15 21:02
どっちか define しないと sigpause が宣言されないんなら、clisp の
Makefile (or configure) が悪い、ってことになるかね。

なんにしても、gcc はまるで関係ない。



777 :デフォルトの名無しさん:04/06/15 21:04
>>760
http://dictionary.goo.ne.jp/voice/w/00090699.wav

778 :デフォルトの名無しさん:04/06/15 21:15
>>777
もしも、君の書き込みが
『ほら、やっぱりウォーニングじゃん!』
という意図ならば、相当痛いぞ。

779 :デフォルトの名無しさん:04/06/15 21:28
clispの全てのヘッダーファイルの中から#undefしてるところを探しても、
__FAVOR_BSD,__USE_XOPEN,__GNUC__は一つもなし。通常はこれらの値は
Glibcでは/usr/include/features.hにてシステムの値として設定されるようです。
で/usr/include/features.hの該当箇所を見ると、以下のようになっています。

/* These are defined by the user (or the compiler)
to specify the desired environment:

__STRICT_ANSI__ISO Standard C.
_ISOC99_SOURCEExtensions to ISO C89 from ISO C99.
_POSIX_SOURCEIEEE Std 1003.1.
_POSIX_C_SOURCEIf ==1, like _POSIX_SOURCE; if >=2 add IEEE Std 1003.2;
if >=199309L, add IEEE Std 1003.1b-1993;
if >=199506L, add IEEE Std 1003.1c-1995
_XOPEN_SOURCEIncludes POSIX and XPG things. Set to 500 if
Single Unix conformance is wanted, to 600 for the
upcoming sixth revision.
_XOPEN_SOURCE_EXTENDED XPG things and X/Open Unix extensions.
  ・・・
_BSD_SOURCEISO C, POSIX, and 4.3BSD things.
  ・・・

多分エラーの原因はclispのMakefileにて、glibc-2.3.4用に上記の値のBSD関連、
もしくはXOPEN関連のどちらかを設定する必要があるということだろうと思います。

質問はこれからです。"(or the compiler)"とあるコンパイラの設定とはGCCの
場合はどこを見ればいいのでしょうか?specsには
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
という1行だけが含まれていましたが、他にもどこかにあるのでしょうか?

780 :デフォルトの名無しさん:04/06/15 21:37
補足ですが、
gcc-3.3.3のspecsには以下のようなものも含まれていましたが、
%{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2 -D__GNUC_PATCHLEVEL__=%v3}
自分のところの3.4にはこれすらなくなっていました。

781 :デフォルトの名無しさん:04/06/15 22:51
gccと関係ないって。だから犬厨しつこいって言われるんだよ。

森へお帰り

782 :デフォルトの名無しさん:04/06/16 00:42
このスレはワーニング派が多いの?

783 :デフォルトの名無しさん:04/06/16 00:46
ホントシツコイナ、答えはもう出てるだろ

These are defined by the user

お前は盲目か?ベンダ依存の制御マクロだろこれ
文句があるなら、GCCじゃなくてディストリビューターに言え

784 :デフォルトの名無しさん:04/06/16 00:48
>>782
正直どっちでもいいの

日本人じゃちゃんと発音できないから

785 :デフォルトの名無しさん:04/06/16 01:06
発音と日本語での書き方は別物。
warpをウォープとかwarrantyをウォーランティとか言う奴はアホ。

786 :デフォルトの名無しさん:04/06/16 01:08
カタカナ語にいちいちつべこべ言う香具師は


            け い こ く


とでも言い直せよヴォケ
日本語の会話中に突然 warning って発音の単語が出てきたらふつー引くだろ?

787 :アルロビュー ポッキュ ヤングギゴッポム!!!:04/06/16 01:17
白人に劣等感丸出しの朝鮮人が一人紛れ込んでヲメくヌレはここでつか?

「マクドナルドは」「メッドゥネルドゥ」じゃないから
チォックバリドル英語下手ニダとかほざく連中と変わらんて




virus を「ヴァィラス」に近い発音されてきちっと理解できる奴どれくらいいるんだ?
しかも日本語の会話の文脈で

788 :デフォルトの名無しさん:04/06/16 01:20
面接中にイオナズンとかもな

789 :759:04/06/16 01:30
こんなポレでも、cosは「コサイン」って読んじゃうけどな。

790 :デフォルトの名無しさん:04/06/16 01:59
>>780
3.4では__GNUC__等はgcc内部で定義されてるよ。

よくわからんが
linux.cの先頭で
#define __USE_XOPEN
とすれば、エラーは無くなるんじゃない。



791 :デフォルトの名無しさん:04/06/16 10:54
読み方なんてどうでもいいじゃん。
それよりも、gccのオプションを1つでも覚えれば。

792 :デフォルトの名無しさん:04/06/16 11:30
おまいら -Werror がコンパイル通るまで帰しませんよ

793 :デフォルトの名無しさん:04/06/16 11:40
>おまいら -Werror がコンパイル通るまで帰しませんよ
先生!通ったんで、もう帰っていいですか?


794 :デフォルトの名無しさん:04/06/16 12:00
>>793
キャストの嵐かよ!!!

795 :デフォルトの名無しさん:04/06/16 12:23
>>794
>キャストの嵐かよ!!!
ちがうよ。人聞きが悪いこと言うなぁ。
もともとのコードが良いからさ。

796 :デフォルトの名無しさん:04/06/16 13:13
>>790 ありがとうございます。

linux.cにて
#define __USE_XOPEN 1
#include <signal.h>
としてみましたが、なぜか>>769と同じエラーが出ます。
/usr/include/*とclispのパッケージ全てのソースにおいて#undef __USE_XOPEN
しているところを探しても、features.hにて行われているのみ。
いろいろ試してみた結果、
$gcc -D_GNU_SOURCE -I. -I../../ -c linux.c
と_GNU_SOURCEをつけた時だけコンパイル成功。謎です。
この時はソース中に__USE_XOPENを付ける必要すらなし。
もう少し時間をかけてなぜ上手くいかないのか調べてみたいと思います。

/usr/includeの下をあれこれ眺めていましたが、Libcは難しいです。
開発者の頭の中にあるUNIXに関する知識に驚くばかりです。
ただし、BSDのそれはもう少しシンプルだったようにも思います。

__GNUC__などのプリプロセッサ用の値はgcc/c-cppbuiltin.cの、
define__GNUC__という関数にてgcc/version.cの値をそのままに設定していました。
3.3まであったno-gccなるオプションは3.4にてなくなったようです。

スレ違いらしいので、これにて終りにさせて頂きます。

797 :デフォルトの名無しさん:04/06/16 13:38
半可通なGCC廚が多いな。
答えられないなら黙ってりゃいいのに。一生ビルドだけしてろ。

798 :デフォルトの名無しさん:04/06/16 15:38
お前が黙ってろw

799 :デフォルトの名無しさん:04/06/16 15:45
>>797
>>797>>797>>797
>>797>>797

800 :デフォルトの名無しさん:04/06/16 19:40
ソースとアセンブリの混合リスティング出すオプションは無いの?

801 :デフォルトの名無しさん:04/06/16 22:28
gcc --help
gcc -v --help

802 :デフォルトの名無しさん:04/06/17 00:25
発音と日本語での書き方は別物。
warming upをワーミング・アップとかStar Warsをスター・ワーズとか言う奴はアホ。

803 :デフォルトの名無しさん:04/06/17 00:50
おとうちゃん!
クロスコンパイラビルドしてみたんだけど、ブートストラップのcrti.oを作ってくれないよ!
crtbegin.oとかは作ってくれるのに、何故ぇ??

804 :デフォルトの名無しさん:04/06/17 02:35
>>803
クロスで、とくにカナディアンで、ライブラリ作るの、
けっこうノウハウいるから苦労するよ。

俺なんて、cc1 とかのコンパイル成功した時点で、それ使っちゃうからな(w

805 :800:04/06/17 02:40
>>801
探しても無いんだけど。。


806 :デフォルトの名無しさん:04/06/17 03:07
>>805
じゃ、無いってことだろ。あきらめたら。


807 :デフォルトの名無しさん:04/06/17 11:25
開発者の人はどうやってデバッグしてるんだろう。
ソースとアセンブラ(もしくは他の内部的な中間コード)の
リストあったら見やすくない?

808 :デフォルトの名無しさん:04/06/17 11:42
>開発者の人はどうやってデバッグしてるんだろう。
gdbでデバッグしている。といいたいところだけど。

制御系だとターゲットが常に手元にあるわけではないし
問題が発生しても、エンドユーザの環境でデバッグするわけにもいかない。

そこで例外発生時のバックトレース情報
(例外が発生したアドレスと、その呼び出し元のアドレスの一覧)
から調査を始めるわけなんだけど

ldの吐き出したマップファイルからアドレスと関数の対応はわかるものの
ソースのどの行かまではわからないんだよね。

アセンブリリストは -S で出るから、そのリストを見て、おそらくこの行だろう
と推測するしかないという状況。

外部ツールでもいいから、ソースとアセンブリの混合リストを吐く方法は無いだろうか?
デバッグ情報付きのオブジェクトから作れそうなものだけど。


809 :デフォルトの名無しさん:04/06/17 11:47
仕事上、生粋のエイゴリアンともよく話すんだけど
連中にもワーニングって言って通じたよ
「ウォー」より「ウヮー」って発音だったけどね

810 :デフォルトの名無しさん:04/06/17 13:15
warm と worm のどっちがワームなのか知らない奴が沢山いる予感・・・

811 :デフォルトの名無しさん:04/06/17 13:31
いつまでくだらんネタやってんの?

812 :デフォルトの名無しさん:04/06/17 14:19
>>805
objdump にそういう機能がある。

--source
Display source code intermixed with disassembly, if possible.
Implies -d.


813 :デフォルトの名無しさん:04/06/17 20:18
>>812
ありがとうございます。
objdumpとは、言われて見ればああなるほど。

これで仕事が進みます。

814 :デフォルトの名無しさん:04/06/18 22:35
>>813
>これで仕事が進みます。
それが、2chサーチエンジン。まれに嘘を吹き込まれるが。(藁

815 :デフォルトの名無しさん:04/06/19 11:01
>>734-737
Cygwinで日本語PATH問題は、Win板のこちらへ。
http://pc5.2ch.net/test/read.cgi/win/1052361218/933-940

もとはUNIX板のCygwinスレで出てきた話だけど、まとまってないし、dat落ち中だし。

816 :デフォルトの名無しさん:04/06/19 11:53
hoge
と表示してくれるのを期待したのに、piyoが表示されてしまいました。
これってANSI的にはどうなのよ?

$ gcc --version
gcc (GCC) 3.3.1 (cygming special)
Copyright(略)
$ cat hoge.c
#include <stdio.h>
int main(int argc, char **argv) {
printf("hoge\n");
return 0;
}
static void puts(void) {
printf("piyo");
}
$ gcc -ansi -pedantic -Wall -O -o hoge hoge.c
hoge.c:6: warning: `puts' defined but not used
$ ./hoge
piyo$

817 :デフォルトの名無しさん:04/06/19 11:54
あ、スペースが詰まってインデントが見難い…

818 :デフォルトの名無しさん:04/06/19 12:07
$gcc --version
gcc (GCC) 3.4.0 20040601 (Gentoo Linux 3.4.0-r6, ssp-3.4-2, pie-8.7.6.3)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$gcc -ansi -pedantic -Wall -O hoge.c
fo.c:6: error: conflicting types for 'puts'
fo.c:6: error: conflicting types for 'puts'
fo.c:6: warning: 'puts' defined but not used

でした。

819 :デフォルトの名無しさん:04/06/19 12:09
あ、ファイル名違ったままだった。スマソ。

820 :デフォルトの名無しさん:04/06/19 12:12
_main:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
andl $-16, %esp
movl $0, %eax
call __alloca
call ___main
movl $LC0, (%esp)
call _puts
movl $0, %eax
movl %ebp, %esp
popl %ebp
ret

なんでここで_putsが出てくるのかな。漏れも知りたいです。

821 :デフォルトの名無しさん:04/06/19 12:15
gccのおせっかい機能だった気がせんでもない

822 :デフォルトの名無しさん:04/06/19 14:47
-Oをはずせばprintfになる。
GCCの最適化処理が、不変な文字列出力であった場合、
puts等に置き換えるがその影響かも。
これは、既知の問題なのか?
まぁ、通常こんな書き方するやついないが。

823 :デフォルトの名無しさん:04/06/19 15:22
>>819
ANSIはしらんが、最新のJIS C(=ISO C)ではライブラリの識別子は予約とされていて、
同じ識別子を使うと未定義となる。C89でも同じだと思う。
だからこの動作でもOK。

JIS X 3010 2003(ISO/IEC 9899: 1999) 126ページ 7.1.3 予約済み識別子

824 :デフォルトの名無しさん:04/06/19 15:24
>>819でなくて>>816だった。

しかしJISCのサイトはなんでアイコンがネットスケープなのかな?

825 :デフォルトの名無しさん:04/06/19 16:31
>>824
>しかしJISCのサイトはなんでアイコンがネットスケープなのかな?
ワロタ
鯖は、Solarisだがな。

826 :デフォルトの名無しさん:04/06/19 16:47
自作putcharを作成したんですけど、以下の警告が出てしまいます。
この問題を回避する方法ってあるのでしょうか?
hoge.c:28: warning: conflicting types for built-in function `putchar'

gcc version 3.3.3です。


827 :デフォルトの名無しさん:04/06/19 17:08
putcharという名前に拘るのをやめる

828 :デフォルトの名無しさん:04/06/19 17:09
>>826
1. 自作putcharの名前を変える.
2. built-inのputcharが宣言してあるheaderを読み込まない.
3. c++にして名前空間を利用する.
くらいでしょうか.


829 :デフォルトの名無しさん:04/06/19 22:11
普通は1、正しいのは3、2を選ぶ奴はドンキホーテ

830 :デフォルトの名無しさん:04/06/20 00:18
>>823
7.1.3 予約済み識別子 だけだと、
ライブラリの extern な識別子は、extern な識別子として使うのは予約済みだけど、
>>816みたいに、static な識別子として使うのは予約されてない。
けど、6.2.2 識別子の結合 で、
翻訳単位の中で同じ識別子が内部結合と外部結合の両方で現れた場合、その動作は未定義とする
となっているので、動作は未定義になる。
という理解であってる?

>>820
最適化すると、printf("hoge\n"); が puts("hoge"); に置き換えられたり、
printf("%s\n", s); が puts(s); に置き換えられたりするみたい。
(ただし、返却値を使ってない場合)

831 :デフォルトの名無しさん:04/06/20 21:58
>>818-8223
printf が最適化で puts に置き換えられるのは、
ちょっと余計なお世話なような気はするけど、通常は問題なさそうなので許すとして、
int puts(const char *);
static void puts(void) {}
が、型が違うぞゴルァと言われずにコンパイルできてしまうのは、ちょっと気持ち悪いかな。

832 :デフォルトの名無しさん:04/06/20 23:03
Use either of -fno-builtin-printf or -fno-builtin

833 :826:04/06/21 06:36
>>832
Thanx

834 :デフォルトの名無しさん:04/06/22 11:04
局所的なstatic変数の動的な初期化をスレッドセーフに行わせるための
オプションってありますか?C++です。

void foo(void) {
static int bar = baz(); // ここ
return ++bar;
}

835 :デフォルトの名無しさん:04/06/22 11:16
排他制御しろ。

836 :デフォルトの名無しさん:04/06/22 11:18
main()に入る前(にstatic storageの変数の初期化が行われる)はシングルスレッド。

837 :デフォルトの名無しさん:04/06/22 11:21
>>835
> 排他制御しろ。
チーム全体に周知するのが困難で。

>>836
局所変数だからmainの前には初期化されまへんね。ゼロクリアは保証されてるけど。


838 :デフォルトの名無しさん:04/06/22 11:26
static __thread int bar = baz();
とすると、何が変わるの?

839 :834:04/06/22 11:26
とおもったがやっぱり排他制御しますー。


840 :デフォルトの名無しさん:04/06/22 11:50
>>838
TLSあたりでぐぐってみる。


841 :デフォルトの名無しさん:04/06/22 11:54
>>839
>とおもったがやっぱり排他制御しますー。
それが一番無難だ。

842 :デフォルトの名無しさん:04/06/22 11:56
>>837
> チーム全体に周知するのが困難で。

intだからbaz()の中で排他制御するのがいいんじゃない?
Atomicでないdata typeだと代入を排他する必要があるけども。
ってスレ違いですかね。

>>838
http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/gcc/C99-Thread-Local-Edits.html#C99%20Thread-Local%20Edits
それからgccのinfoの"Thread-Local"の項

843 :デフォルトの名無しさん:04/06/22 11:57
張り間違えた…
http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/gcc/Thread-Local.html

844 :834:04/06/22 12:04
>>838
> static __thread int bar = baz();
> とすると、何が変わるの?
動的初期化はできないですよん


845 :デフォルトの名無しさん:04/06/22 12:23
>>844
>動的初期化はできないですよん
起動時に一度だけ初期化したいってことか?
なら、フラグを持って排他制御だな。

846 :デフォルトの名無しさん:04/06/22 13:03
排他制御の徹底をチーム全体に伝えれないのに、スレッドとか使うのは
なんだか凄く危険な予感がするんだが。


847 :デフォルトの名無しさん:04/06/22 13:14
>>846
人のことなんてしったことではありません

848 :デフォルトの名無しさん:04/06/22 14:25
動的初期化って言葉あまり言わないなぁ。

849 :デフォルトの名無しさん:04/06/22 14:30
>>848
JISの用語だろうなJISX3014の3.4.2とか見てみれ。


850 :デフォルトの名無しさん:04/06/22 16:45
VC++で書いたコードをg++でコンパイルしたら
ファイルサイズが結構でかくなったんだけど、
これは仕様ですか?

851 :デフォルトの名無しさん:04/06/22 16:47
>>850
stripした?

852 :デフォルトの名無しさん:04/06/22 17:00
>>851
は?ストリップ?

853 :デフォルトの名無しさん:04/06/22 17:04
>>851
-Osでコンパイルして、stripしたら、70KBくらい減った。
ありがとー

854 :デフォルトの名無しさん:04/06/22 18:38
質問しといて「は?」は無いよな・・・

855 :デフォルトの名無しさん:04/06/22 18:59
厨房だろ

856 :850,853:04/06/22 21:27
>>854,>>855
一応だけど、>>852は漏れじゃないです。

857 :デフォルトの名無しさん:04/06/23 06:07
>>854

>>852 は多分成りすまし。
ID 無い板でよく行われる。


858 :デフォルトの名無しさん:04/06/23 12:01
gccで以下のように宣言できるんですけど
いったいどうなるんですか?

struct hoge;


859 :デフォルトの名無しさん:04/06/23 12:08
g++で以下のように宣言できるんですけど
いったいどうなるんですか?

class hoge;

860 :デフォルトの名無しさん:04/06/23 12:08
これってどういう意味?
__attribute__((noderef, hogehoge(1)))


861 :デフォルトの名無しさん:04/06/23 12:19
>>858
gccさんが、(´・∀・`) ヘェーって思う。

>>859
g++さんが、(´・∀・`) ヘェーって思う。

862 :デフォルトの名無しさん:04/06/23 12:24
http://www.sra.co.jp/wingnut/gcc/gcc-j.html#Function%20Attributes
これ見ても載ってないね。noderefってなんだろう。

863 :デフォルトの名無しさん:04/06/23 13:59
>>861
糞ワロタ

864 :デフォルトの名無しさん:04/06/23 18:22
>>860
gccのバージョンとターゲットは何?
3.3.2のソースを眺めでみたが、見当たらん。


865 :デフォルトの名無しさん:04/06/23 18:42
>>858,859

C++だと時々使うよ、Cでも通るんだな struct hoge は初めてだ

後でちゃんとしたの宣言するから、とりあえず通せって考えてるけど
実際どうなんしょ?



866 :デフォルトの名無しさん:04/06/23 18:48
>>858,>>859
何のメリットがあるんだろう..

867 :デフォルトの名無しさん:04/06/23 18:50
相互参照する構造体での前方宣言ですよ。
struct foo;
struct bar {
struct foo *p;
};
struct foo {
struct bar *p;
};


868 :デフォルトの名無しさん:04/06/23 18:53
struct __foo {
struct __foo * p;
};
というのもある意味前方参照?

869 :デフォルトの名無しさん:04/06/23 18:53
>>867
2パス通せばいいと思うんだが。
コンパイル高速化の為?

870 :デフォルトの名無しさん:04/06/23 19:51
>>869
それもあるが、実態を隠したいわゆる ADT (抽象データ型) を実装する
ためにも使う。

871 :デフォルトの名無しさん:04/06/23 22:07
>>870
>それもあるが、実態を隠したいわゆる ADT (抽象データ型) を実装する
>ためにも使う。
なるほ。

872 :デフォルトの名無しさん:04/06/23 23:47
struct foo;
こういうのは不完全型という。

873 :デフォルトの名無しさん:04/06/24 09:55
class foo; //class header
class foo {}; //class body

と、C++では言います

874 :デフォルトの名無しさん:04/06/24 09:58
>>873
聞いたことねーな。誰が言ってるの?

875 :デフォルトの名無しさん:04/06/24 10:22
>>874
lippman

876 :デフォルトの名無しさん:04/06/24 10:50
>>873
"class header"というと、ほとんどが「クラス定義を含むヘッダファイル」を指して言うみたいなんだが、
その意味で使われている例をWeb上の文書で示せるか?

877 :デフォルトの名無しさん:04/06/24 10:55
876
C++Primerに載ってただけ。便利だから俺はよく使ってる。

878 :デフォルトの名無しさん:04/06/24 10:58
ごめん今ちゃんと読んだら、class headだったし、
全然違う意味だった。逝って来る。

879 :デフォルトの名無しさん:04/06/24 11:04
>>877
たぶん一般的じゃないからやめたほうがいいと思う。
>876のような意味に勘違いされる可能性が高い。

関数の場合を考えると、
 void foo(); // 関数宣言
 void foo() {} // 関数定義
この使い分けは一般的だから、
 class foo; // クラス宣言
 class foo {}; // クラス定義
こう使い分けるのがすっきりしてるかも知れない。
ただ、「クラス宣言」が「クラス定義」の意味で使用されることが多いので、
これも誤解を生まないわけではない。

現状で最も誤解が少ないのは、
 class foo; // クラスの前方宣言(forward declaration)
 class foo {}; // クラス定義
と使い分けることだろう。

880 :デフォルトの名無しさん:04/06/24 11:13
lippmanのいうclass head,class bodyとは

class CLASS //この部分がclass head
{
  //この部分がclass body
  ...

ということ。汗かいちゃった。

881 :デフォルトの名無しさん:04/06/24 19:33
>>860
ttp://lists.gnu.org/archive/html/tinycc-devel/2003-04/msg00094.html

882 :デフォルトの名無しさん:04/06/24 21:21
>>879
> この使い分けは一般的だから、
一般的というか、規格書で使ってる用語そのまま。

883 :デフォルトの名無しさん:04/06/24 23:28
>>881
ああ、NO DEREFerenceなのか。

884 :デフォルトの名無しさん:04/06/24 23:57
・"noderef"を付けるとデータを参照してないポインタに警告を出す。
・address_space(N)データへのポインタは、同じaddress_spaceへのポインタと型が互換になり、そうでなければ警告を出す。
ってこと?
なんだかよくわからんが。

885 :デフォルトの名無しさん:04/06/25 00:02
>>884
逆でしょ。

dereferenceしようとすると警告になるんでしょ。
使い方としては「カーネル空間からユーザ空間にアクセスしようとすると警告」など。



886 :デフォルトの名無しさん:04/06/25 00:06
>>885
うむ。なるほど。

887 :デフォルトの名無しさん:04/06/25 23:54
ソース見てたら以下の文字列がありました。
#pragma pack(1)
#pragma pack()
これってなんすか?

ネットで調べるとpragmaは古い仕様なことがありましたが。

888 :デフォルトの名無しさん:04/06/26 00:39
>>887
http://www1.kcn.ne.jp/~robe/cpphtml/html03/cpp03014.html

889 :887:04/06/26 00:51
>>888
さんくすです。paddingか。
__attribute__ ((aligned (1), packed))ってことか。

pragmaってよく使用するんですかね。attributeを使えばいいような気もしますが。

890 :デフォルトの名無しさん:04/06/26 01:40
attributeはgccの拡張仕様だから。
文法的にはattributeの方がわかりやすくでいいけど。


891 :デフォルトの名無しさん:04/06/26 01:43
DLL作りでメモリ共有する時にもgccではattribute shared使うけど、MSだとpragma使うから
コンパイラ非依存にするには#ifdefでごちゃごちゃやってやらないといけないのが面倒。

892 :デフォルトの名無しさん:04/06/26 02:58
>>889
http://www.google.co.jp/search?q=cache:2nsqRSWrClEJ:www1.kcn.ne.jp/~robe/cpphtml/html03/cpp03014.html+pragma+pack+%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%83%A9%E3%80%80%E4%BE%9D%E5%AD%98&hl=ja&lr=lang_ja

893 :デフォルトの名無しさん:04/06/26 03:05
>>892
該当するページが見つかりませんでした。

検索のヒント

- キーワードに誤字・脱字がないか確かめてください。
- 違うキーワードを使ってみてください。
- より一般的な言葉を使ってみてください。
- キーワードの数を少なくしてみてください。

894 :デフォルトの名無しさん:04/06/26 03:10
>>890,>>891
なるほど、attributeってGCC依存なのか。知らんかった。Thx

895 :デフォルトの名無しさん:04/06/26 03:14
>>892さんは以下を言いたかったに違いない。
http://www.kab-studio.biz/Programing/Dictionary/Words.html#__s__pragma

896 :デフォルトの名無しさん:04/06/27 18:15
それにしても、3.0 以降はバージョン番号がさくさく進むね。
なんか 2.95.2 のときの停滞がうそのようだ。

897 :デフォルトの名無しさん:04/06/27 19:23
>>896
前は人手が足りないようなことを言ってけど、
開発メンバが増えたのかな。

898 :デフォルトの名無しさん:04/06/28 22:43
エンタープライズ向けのみになって暇になったRedhat内の開発者がまたいじってるんじゃないかと推測

899 :デフォルトの名無しさん:04/06/29 11:27
GCC 3.5 Release Series
Changes, New Features, and Fixes
http://gcc.gnu.org/gcc-3.5/changes.html

900 :デフォルトの名無しさん:04/06/29 13:13
【gccの最適化オプション一覧】
-fcaller-saves -fcse-follow-jumps -fcse-skip-blocks
-fdelayed-branch -felide-constructors
-fexpensive-optimizations -ffast-math -ffloat-store
-fforce-addr -fforce-mem -finline-functions
-fkeep-inline-functions -fmemoize-lookups
-fno-default-inline -fno-defer-pop
-fno-function-cse -fno-inline -fno-peephole
-fomit-frame-pointer -frerun-cse-after-loop
-fschedule-insns -fschedule-insns2
-fstrength-reduce -fthread-jumps -funroll-all-loops
-funroll-loops -O -O2 -O3 -Os

901 :デフォルトの名無しさん:04/06/29 13:22
これって何?
コストのかかる最適化?なんか矛盾してるような気がするが。
-fexpensive-optimizations

902 :デフォルトの名無しさん:04/06/29 14:06
>>899
3.5出たのん?


903 :デフォルトの名無しさん:04/06/29 14:44
>>901
strength reduction


904 :デフォルトの名無しさん:04/06/29 15:04
>>901
コンパイルにコストがかかるってことだろ。


905 :901:04/06/29 15:21
>>904
>コンパイルにコストがかかるってことだろ。
Oh, I see.


906 :デフォルトの名無しさん:04/06/29 15:23
>>902
まだ出てない。
>>899は、GCC 3.5を作成するにあたって行われる変更、新機能、修正一覧を知らせてるだけ。

907 :デフォルトの名無しさん:04/06/29 15:55
>>901
-fexpensive-optimizations
 Perform a number of minor optimizations that are
 relatively expensive.

意訳すると「時間もメモリも喰うワリに効果の薄い最適化を行う」だ。
gcc-2 の頃からあったような希ガス

908 :デフォルトの名無しさん:04/06/29 19:35
>>907
希ガスって風俗板方面の用語だっけ?


909 :デフォルトの名無しさん:04/06/29 20:03
gccではなくg++で、トランポリンのコードが生成されるシチュエーションってありますか?
ネストした関数はg++だとコンパイルできません。


910 :デフォルトの名無しさん:04/06/29 20:13
>>900
-Oはいっぱいあって、-O999あたりまでいける。意味は皆無だと思うが。

911 :デフォルトの名無しさん:04/06/29 21:06
>>910
昔、某ディストロは「-O99」なんてやってたね。今はどうだか知らないけど。


912 :デフォルトの名無しさん:04/06/30 00:32
プリコンパイルヘッダをもう少しだけなんとかしてくれんか脳…
そういやx86用ならIntelのC++コンパイラはGCC完全互換+ごっつい
プリコンパイラヘッダ対応らしいが、GCCとどう違うんだろう。

913 :デフォルトの名無しさん:04/06/30 00:48
>>912
どういうところが難アリとお考えで?

914 :デフォルトの名無しさん:04/07/03 02:27
よく聞きますけど、
「トランポリンコード」って何ですか?


915 :デフォルトの名無しさん:04/07/03 08:19
>>914
よく聞く ?
俺は初めて聞くが、どうも Linux 関係らしいから、それ以上調べるのはやめた。

916 :デフォルトの名無しさん:04/07/03 08:55
>>909はLinuxなのか?

917 :デフォルトの名無しさん:04/07/03 11:29
>>909は何のことか分からないけど、
Linuxのトラノポリンはスタック領域の移動に使うコード。
シグナルハンドラで使われる。
二つのトランポリンを横移動ってイメージの命名だと思う。

918 :デフォルトの名無しさん:04/07/03 12:10
clock()で秒以下の数値が戻ってこないのですが、
なにかオプションの指定が必要なのでしょうか?
gcc 3.2.3 20030502(Red Hat Linux 3.2.3-20) を使用しています。


919 :デフォルトの名無しさん:04/07/03 12:15
gccの問題なのか?

920 :デフォルトの名無しさん:04/07/03 13:12
ははは
いいつっこみだ。

921 :デフォルトの名無しさん:04/07/03 15:34
>>914
gcc のマニュアルの nested function の項に書いてあるよ。
あとはここにも。

ttp://www.shiro.dreamhost.com/scheme/docs/cont-j.html

922 :デフォルトの名無しさん:04/07/03 15:36
>>918
gccとは無関係だからLinux板で。
まぁ、gettimeofday()でも使っとけってことで。


923 :デフォルトの名無しさん:04/07/07 00:36
以下のソースで、
int main(){
 short a;
 int b;
 a = b = -1
 printf("%d, %d\n", sizeof(a), sizeof(b));
 printf("0x%X\n", a);
 printf("0x%X\n", b);
 return(0);
}
結果が
2, 4
0xFFFF
0xFFFFFFFF
とならずに
2, 4
0xFFFFFFFF
0xFFFFFFFF
になりましたけど。なぜでしょうか?

924 :デフォルトの名無しさん:04/07/07 00:43
>>923
可変長引数に short 型の変数を渡すときには、暗黙の内に int にキャスト
(格上げ)されるから。

925 :デフォルトの名無しさん:04/07/07 00:45
3.4.1 age

926 :923:04/07/07 00:57
>>924
うぉーそうだったんですか!
何年もC使ってたけど知らなかった。 _| ̄|○
逝ってくる。

927 :デフォルトの名無しさん:04/07/07 01:02
日本人でGCCデベロッパな方っているんでしょうか?
自分もGCCデベロッパに入りたい。けど、技術力がないからだめか。
やはり、コンパイラの勉強しないとだめですか?

928 :デフォルトの名無しさん:04/07/07 01:23
Kに弟子入りすれば大丈夫

929 :デフォルトの名無しさん:04/07/07 02:10
たまに開発MLに日本人らしき名前で投稿があっても、しょっちゅうスルーされてた。

930 :デフォルトの名無しさん:04/07/07 02:25
英語の下手な香具師はコミュニケーションとれないからな。
技術力以前の問題というか。

931 :デフォルトの名無しさん:04/07/07 02:31
ゾウさんが好きです。けど、gnuさんがもっと好きです。
ttp://loxosceles.org/misc/backgrounds/gnu.jpg
ttp://loxosceles.org/misc/backgrounds/gnu_engraving.jpg
ttp://loxosceles.org/misc/backgrounds/gnu_engraving_black.jpg
ttp://www.c-creators.co.jp/m-kato/kenya2000/img/gnu.jpg
ttp://www.x31.com/~andy/pics/25-06-01-various/01633-gnu-resting.jpg
ttp://heim.ifi.uio.no/~kritisk/reiser/tanzania/gnu.jpg
ttp://www.linuxgazette.com/issue72/misc/alcidi/gnu_bill.jpg
ttp://www.vonegidy.de/Bilder/Gnu.JPG

おまけ−gnuさんの頭領
ttp://internet.watch.impress.co.jp/www/article/981217/gnu.jpg

932 :デフォルトの名無しさん:04/07/07 02:35
>英語の下手な香具師はコミュニケーションとれないからな。
>技術力以前の問題というか。
その逆もまた真になる。

できる奴は技術力でそれをカバーできると思うし、
相手もできる奴とわかれば意思の疎通も多少はできるはずだが。

933 :デフォルトの名無しさん:04/07/07 02:45
>>932
コーディングだけならね。パッチ送って採用されたとか
そのレベルでしょ。

934 :デフォルトの名無しさん:04/07/07 02:52
>>933
それ以上になにかあるのか?
目的は達成されているような気がするが。

それとも相手の家にでも遊びに行くのか?

935 :デフォルトの名無しさん:04/07/07 10:52
>>934
どのバージョンでどの機能を入れるか、みたいなプロジェクトの
方針や決定に関われるようなヤシはいないって事でしょ。

もっともそこまでやるなら、それこそRedHatみたいな会社でフル
タイムのhackerとして雇ってもらうとかじゃないと時間的に無理
だろうが。

936 :デフォルトの名無しさん:04/07/07 11:37
>>933
それくらいでも、
hogehogeがおかしいので直して見たけど、これどうよ?
てな事をちゃんと説明しないとスルーされるわけですが。

それなりの実績があれば一行説明でもわかってくれるが。

>>934
commit権もらうとか。


937 :デフォルトの名無しさん:04/07/07 12:00
>>936
>commit権もらうとか。
ワロタ

938 :デフォルトの名無しさん:04/07/08 08:01
3.4.1の出来はどうですか?

939 :デフォルトの名無しさん:04/07/08 15:40
>>938
上々の出来

940 :デフォルトの名無しさん:04/07/09 01:59
GCCじゃなくってGDBの話なんだけど、Cygwin、MinGW用のビルドは
常にスレッド対応してないのかな??
クロス開発で不自由で。
5.2.1〜6.1までをぽつぽつと試してみたんだけど、info thread(s)で
どれもRMT ERRORとでるか、最初のスレッドの情報が中途半端に
帰ってくるだけで、2つめ以降のスレッドの情報は出てこない。
break置いても止まらないし、あまつさえメインのスレッド止めても
それ以外のスレッドは走りっぱなしなのでデバッグにならん。
gdbserverのバージョン変えても駄目だし、--enable-threads付けて
ビルドしても駄目だし、どうしたものか。

941 :デフォルトの名無しさん:04/07/09 02:19
んーgdbをデバッグするってのはどう?


942 :デフォルトの名無しさん:04/07/09 02:28
>>940
CygwinやMinGW等ではなくて素のOSに入れてもなるのならGDBを疑う。

943 :940:04/07/09 10:52
>>942
手元のLinuxで同じコードをでビルドした時にはならなかった…。

info threadが何も返さない、RMT ERRORが出る、
最初のスレッドの情報しか返してよこさない、というのは、
GNUのページ見てると、Win環境に留まらず、時々報告されてる
バグ?ではあるみたい。

GDBのスレッド対応はターゲット次第らしいので、仕方ないっちゃあ
仕方ないけど、思ったよりも気にしてる人少ないのかな。

944 :940:04/07/09 10:57
>>942
手元のLinuxで同じコードをでビルドした時にはならなかった…。

info threadが何も返さない、RMT ERRORが出る、
最初のスレッドの情報しか返してよこさない、というのは、
GNUのページ見てると、Win環境に留まらず、時々報告されてる
バグ?ではあるみたい。

GDBのスレッド対応はターゲット次第らしいので、仕方ないっちゃあ
仕方ないけど、思ったよりも気にしてる人少ないのかな。

945 :名無しさん@そうだ選挙に行こう:04/07/11 18:33
各アプリケーションの初期設定では、最適化オプション
-O2
であることがほとんどですが
-O3
にすると問題は多いのでしょうか?
房な私にアドバイスお願いします。

946 :名無しさん@そうだ選挙に行こう:04/07/11 18:49
多くない。

947 :名無しさん@そうだ選挙に行こう:04/07/11 18:53
多いって言うかどんな問題があるのか知りたい

948 :名無しさん@そうだ選挙に行こう:04/07/11 19:06
-O2にすると偶然動くバグとかあるじゃん。
そういう意味で-O3は問題だ。

949 :名無しさん@そうだ選挙に行こう:04/07/11 19:10
http://gcc.gnu.org/testing/
http://gcc.gnu.org/ml/gcc-testresults/

950 :デフォルトの名無しさん:04/07/12 22:23
酸素とオゾンは大違いだしな

951 :デフォルトの名無しさん:04/07/14 01:52
>>940
Cygwin で GNU gdb 2003-09-20-cvs (cygwin-special) を使ってますが、
今のところ、マルチスレッドでおかしな現象には出会ったことないですよ。

自分が不自由してるのは、detach が効かないこと。
他のバージョンではどうなんだろう、試したことないけど。

952 :デフォルトの名無しさん:04/07/15 03:17
そろそろ128bitCPU用にlong long longが欲しいな。long long long long かもしれないが。

953 :デフォルトの名無しさん:04/07/15 06:29
コンパイル時の定数計算のために、long long(uint64_t)が導入されたが、
ILP64の環境の場合にはuint128_tが必要にならないんだろうか。

954 :デフォルトの名無しさん:04/07/16 23:56
GCCの最適化オプションは数あれど
基本的には -O* を指定しておけば、必要に応じて
-fstrength-reduce等のオプションが設定されると考えて良いのでしょうか?

要するに -O3等はオプションの総合オプションのように機能しているのでしょうか?

素人な私にアドバイスをお願いします。

955 :デフォルトの名無しさん:04/07/17 00:05
んじゃ適切なアドバイスを。info読め。ちゃんと書いてあるから。



956 :デフォルトの名無しさん:04/07/17 04:00
info読むためにはemacsの使い方を(略

957 :デフォルトの名無しさん:04/07/17 04:15
#include <iostream>
すると、
/usr/include/c++/3.4.0/backward/iostream.h
が読み込まれてしまうみたいなんだけど、
/usr/include/g++-3/iostream{,.h}
を使いたい場合はどうしたらいいでしょう?

958 :デフォルトの名無しさん:04/07/17 04:56
>>954>>956
http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/Optimize-Options.html#Optimize%20Options

959 :デフォルトの名無しさん:04/07/17 10:15
>>954
その認識であってる思います.
最近どっかのスレで見掛けたのだけど,
-vと-Qを同時に指定すると, 実際に有効にされたオプションが表示されるようです.


960 :959:04/07/17 10:26
突っ込まれそうなのでもう一言.

>>954
あなたの言う「総合オプションのような機能」以外のなんらかの最適化を
更に-O*が行なうかどうかを私はよく知りません.
それはソースを当たって下さい.


961 :デフォルトの名無しさん:04/07/17 10:53
>>959>>960
変わった人…


962 :959:04/07/17 11:01
>>961
???
何か良いこと知ってるんなら教えて下さい.


963 :デフォルトの名無しさん:04/07/17 11:18
ソース読む前にinfoでしょ。

964 :デフォルトの名無しさん:04/07/17 11:47
gcc hoge.c -lm 等、ライブラリを使用してコンパイルするときに
この'-lm'で具体的にどこのライブラリを参照するかはどのように指定するのでしょうか?

965 :デフォルトの名無しさん:04/07/17 11:51
-L/home/foo/lib -L/usr/local/lib -L/opt/bar/lib

966 :959:04/07/17 11:53
>>963
それには異存ないんですが,
infoの説明では,
-O*にいくつかの-f*をまとめて指定する「総合オプションのような機能」があることは分かりますが,
-O*が,指定した-f*以外にも何らかの最適化を行なうのか,-f*の指定だけなのかちょっと不明だったもので.
読み落してたら御指摘下さい.


967 :959:04/07/17 12:08
-O2を指定して959に書いた-vと-Qを使うと,
「渡されたオプション」には-O2が表示されるけど,
「有効オプション」には-O2が表示されないところをみると,
-O*は「総合オプションのような機能」だけなのかも.


968 :デフォルトの名無しさん:04/07/17 12:43
$ gcc -O3 -v -Q test.c > o3.txt 2&>1
$ gcc -O2 -v -Q test.c > o2.txt 2&>1
$ diff o2.txt o3.txt

何もでないよ(^^;

969 :デフォルトの名無しさん:04/07/17 12:48
2&>1 じゃなくて 2>&1 だったよ(^^;

diff を見るに
-frename-registers
だけ違うように見える。

gcc version 3.3.1 (cygming special)

970 :デフォルトの名無しさん:04/07/17 13:18
古い記憶なんだが、そもそもO3が有効なのはx86系だけなんじゃなかったっけ。

971 :デフォルトの名無しさん:04/07/17 13:20
バージョンにより違うんじゃないの?

972 :デフォルトの名無しさん:04/07/17 17:09
>>970
sparcでも使えてたよ

973 :デフォルトの名無しさん:04/07/17 17:46
info も嘘っつーか、source に追いついてなかったりするから
しょうがなく gcc/toplev.c と md 部分の *.c や *.md 見て確かめてるな。

974 :デフォルトの名無しさん:04/07/17 18:02
-finline-functionsはO2にあるはず無いし、O3に無いはずが無いだろう

975 :959:04/07/17 19:08
>>974
manによるとそうなんですけど,
gcc -v -Q -O3 hoge.cpp
だと,-finline-functionsが出ません.
やっぱgccはソースを見るしかないのか.


976 :デフォルトの名無しさん:04/07/17 19:13
-v -Qが壊れてるんじゃないの?


977 :959:04/07/17 19:16
gcc -v -Q -O3 -finline-functions hoge.c
としても,有効オプションに-finline-functionsは表示されないので,
-v -Qは指定された有効なオプション全部を表示しているわけではない
みたいです.
失礼致しました.


978 :959:04/07/17 19:19
>>976
壊れてるっていうか,
-v -Qに全部の有効オプションの表示を期待した私が間違ってたってことです.


979 :デフォルトの名無しさん:04/07/17 19:24
gcc -S -O2とgcc -S -O3でコード比較すれば
インライン展開してる事なんてすぐ分かるじゃん。
アセンブラも読めないのに最適化についてなんて語るなよ。

980 :959:04/07/17 19:35
>>979
それはそうなんだろうけど,
最適化はインライン展開以外にもたくさんあるわけだし,
全部の有効オプションを表示する機能はあれば便利なのでは?


981 :デフォルトの名無しさん:04/07/17 19:46
正論だ。


ところで次スレは?

982 :西安(UCK 3.13.8) ◆CYANlp4LPo :04/07/17 20:13
立てた

GCCについて part4
http://pc5.2ch.net/test/read.cgi/tech/1090062751/

983 :デフォルトの名無しさん:04/07/18 00:01
>>980
そう思ったら-v -Qのコード直すなりしてパッチ送りなよ。どうしてそうしないの?


984 :デフォルトの名無しさん:04/07/18 00:21
>>983
思った瞬間にスレに書き込んだんでしょ。きっと、もうパッチ作って送ってるヨ。

985 :959:04/07/18 01:38
「おまえら次のリリース楽しみにしておけよ!」
と書き込みたいところだけど.

>>983,984
そうやってひとを追い込まない.(苦笑)
私はgccのコード把握してないんで,そう簡単に直せないヨ.


986 :959:04/07/18 13:17
>>975
どうやら,
c-opts.cのbool c_common_post_options ()で,
flag_inline_functions = 0;
しているからというのは分かったんですが,
flag_inline_functionsは,あとの処理で参照しているので安易に変更できないし.
ちょっと簡単ではなさそう.


987 :デフォルトの名無しさん:04/07/18 14:37
煽りに耐えてよくがんばった!感動した!

調査が進んだらまた報告しれ。

988 :デフォルトの名無しさん:04/07/18 14:53
gcc/toplev.cのf_optionsで定義されてるものしか表示してないだけのような?

989 :959:04/07/18 15:31
>>988
flag_inline_functionsはf_optionsにちゃんとありますよ.
だから-v -Qで表示しようという意図はあるんでしょうね.(つまりバグと言えるかも.)

同ファイル
static void print_switch_values (file, pos, max, indent, sep, term)
中程の
for (j = 0; j < ARRAY_SIZE (f_options); j++)
if (*f_options[j].variable == f_options[j].on_value)
pos = print_single_switch (file, pos, max, indent, sep, term,
"-f", f_options[j].string);
で表示するかしないかを判断しているみたいなのですが,
このとき,-O3あるいは-finline_functionsを指定していても,
986に書いたようにflag_inline_functionsは既に0になっているのです.


990 :デフォルトの名無しさん:04/07/18 16:02
すみません。そんなに根が深かったとは思いませんでした。

991 :デフォルトの名無しさん:04/07/18 21:31
age

992 :デフォルトの名無しさん:04/07/18 22:07
しつこくてすみません。こんな変更じゃ駄目でしょうか?

gcc/toplev.c(長いので抜粋)

int flag_inline_functions;
+static int flag_inline_functions_959;

{"inline-functions", &flag_inline_functions, 1 },
+ {"inline-functions-959", &flag_inline_functions_959, 1 },

decode_options (argc, argv);
+ flag_inline_functions_959 = flag_inline_functions;


993 :959:04/07/18 23:06
>>992
私のいじってるのと関数の名前が若干違ってますが(バージョンが違う?私は3.3.4見てます.),
たぶん,それで望みの動作になるでしょうし副作用もないでしょうね.


994 :992:04/07/19 00:37
すみません。3.4.xを使ってます。3.3.xと関数名が違うとは思っていませんでした。

3.3.xだと

parse_options_and_default_flags (argc, argv);
+ flag_inline_functions_959 = flag_inline_functions;

こうなるようです。実際の動作は確認できていません。

995 :959:04/07/19 13:01
>>994
いえ,私こそ新しいものを前提にするべきでした.

gcc-core-3.4.1.tar.bz2を取って来て見てみました.
オプションのデコードまわりは,3.3.x->3.4.xで結構変わってるんですね.
3.3.xでは,f_optionsを使って言語に関係のないオプションのデコード,および-v -Qでの表示をやっていたのが,
3.4.xでは,言語に関係あろうがなかろうがcl_options(opts.h, options.c)でデコードをやっていて,
一方,f_optionsが(まだ?)残っていて言語に関係のないオプションの表示用に使えてる印象です.
オプションの情報がcl_optionsとf_optionsで二重になってるのは,このへんのコードがまだ過渡期ということなんでしょうか.
(C++使いたくてうずうずするゾ.)

私は「print_switch_valuesの位置を変えて対処できないかな?」と画策してたんですが,
flag_inline_functions以外の他のフラグとの関係でちょっと無理そうでした.


996 :デフォルトの名無しさん:04/07/19 17:07
gcc -O3 -o 1000.exe 1000.c

997 :デフォルトの名無しさん:04/07/19 17:08
gcc -O3 -o 1000.exe 1000.c -Wall

998 :デフォルトの名無しさん:04/07/19 17:08
997

999 :デフォルトの名無しさん:04/07/19 17:10
gcc -O3 -o 1000.EXE 1000.c -Wall

1000 :デフォルトの名無しさん:04/07/19 17:10
$ make love
error: Permission denied.

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

246 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)