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

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

GCCについて part5

1 :デフォルトの名無しさん:04/12/15 05:48:40
史上最強のツール、GCC(GNU Compiler Collection)について語るスレ。

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

Binutils - Collection of binary utilities
http://www.gnu.org/directory/GNU/binutils.html

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

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

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

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

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


2 :1:04/12/15 05:49:28
前スレ
・GCCについて part4
http://pc5.2ch.net/test/read.cgi/tech/1090062751/
・GCCについて part3
http://pc5.2ch.net/test/read.cgi/tech/1072484422/
・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://pc5.2ch.net/test/read.cgi/tech/1058134693/
・gcjって使ってる人います?
http://pc5.2ch.net/test/read.cgi/tech/1046627795/

3 :デフォルトの名無しさん:04/12/15 07:09:02
         (
      ____)__
     ,. ´     `  ` 、
   ./        _   _ \
  /        _   ̄  _ ヽ
  /イィィ,,.,.,.,.,.,      ̄ ̄    !
 f/ノノノノノノノ  ヘ.__ j  jノ__ノ
 |///////   _ (__ ゚_>` __( ゚_イ
 .!|.|i/_^ヽ|_'___r⌒ y'  ヽ^)|
  !|| fニ> ::::::  `ー'゙ (_`___)ノ
   ヽ.ニ` :     /_ノ/川! /  やりおった・・・
    __ノ 、    / ヾ---'´ ノ
 __ノ \l `   ____,/
       \    ノ リ.|`ー--
        \   .//


4 :デフォルトの名無しさん:04/12/16 01:53:50
糞コンパイラ
-O1は特に酷い
手書きアセンブラのほうがマシっす

5 :デフォルトの名無しさん:04/12/16 05:15:33
>>4
Cってのは、速度が気になるコードを書きたいのならコンパイラがどんなコードを出すのかを
理解しながら書かなければならない言語だが?
その限りにおいて、GCCはそれ程ひどいコードを出してこないし、手書きアセンブリよりは
はるかに楽だが。

6 :デフォルトの名無しさん:04/12/16 17:56:11


まだ4.0試してネーヤ

7 :デフォルトの名無しさん:04/12/17 22:23:09
4.0.0の-O2は凄いな。有効オプションの数が多い。

8 :デフォルトの名無しさん:04/12/18 21:20:47
でも、gcc 4.0のはき出すコード、gcc 3.4.3より2割ぐらい遅いな。-O2でも-O3でもおなじ。僕だけ?

9 :デフォルトの名無しさん:04/12/18 21:29:58
>>1
立てなくてもいいのに・・・

10 :デフォルトの名無しさん:04/12/19 13:18:49
現在ベストオブgcc versionは、3.3らしい。

11 :デフォルトの名無しさん:04/12/19 13:35:49
3.3.3最強

12 :デフォルトの名無しさん:04/12/19 13:51:44
このテンプレを忘れてる。アリさん

GCC Bugzilla
http://gcc.gnu.org/bugzilla/

13 :デフォルトの名無しさん:04/12/19 14:00:47
gccの最適化不足をまとめてるページ

Deficiencies of GCC's optimizer
http://www.gnu.org/software/gcc/projects/optimize.html

14 :デフォルトの名無しさん:04/12/19 14:12:03
[gccトリビア]
gcc4.0でブランチしたのは、



3.4に存在したバグが相当あったために4.0としてブランチした。

15 :デフォルトの名無しさん:04/12/19 14:45:18
gccにgpcが統合されるの?
今さらpascalなんてイラネ

16 :デフォルトの名無しさん:04/12/20 03:58:31
ここだけの話、ディストロやOSにもよるが
gcc3.4系は早々とgcc4.0系に切替えていくんじゃないかという噂がある。

17 :デフォルトの名無しさん:04/12/20 18:18:09
試しにgcc4.0でFirefoxビルドしてみたら体感速度上がった。プラグイン全て使えなくなったけどなorz

18 :デフォルトの名無しさん:04/12/20 18:49:12
gcc4.0って3.4からまたABI変わっちゃったの?

19 :デフォルトの名無しさん:04/12/20 19:48:12
あび

20 :デフォルトの名無しさん:04/12/20 22:18:44
あのさ、amd64環境でさgcc4.0にしてコンパイルしたらさ
error: cast from ‘void *’ to ‘int’ loses precision
っていうエラーが出まくるようになった。
このエラーは3.3系で出なかったけど型の制限がより厳しくなったってこと?

21 :デフォルトの名無しさん:04/12/20 22:58:48
>>17
プラグインを入れ直せばいいのでは?

22 :デフォルトの名無しさん:04/12/20 23:18:12
>>20
void * が 64bit で、int が 32bit だからでしょ・・・。

23 :デフォルトの名無しさん:04/12/21 00:10:25
ポインタとintが同サイズと仮定したコードキター!!!

24 :20:04/12/21 00:40:01
>>22
実はそのアプリってFirefox1.0です。orz

>>23
あなたのそばにも依存したアプリが....。

25 :デフォルトの名無しさん:04/12/21 02:57:39
一般にAlpha/AXP がまだ現役だったころ開発・メンテされてたコードだとLP64 に結構対応してるのが多いし、
その後IA32野郎が壊したところもすぐ直るものなんだけど、Firefoxのコードは新し目のコード多いのかなぁ・・・

26 :デフォルトの名無しさん:04/12/21 04:51:54
げっ!パフォーマンスチェックしたら、
gcc 4.0がgcc 3.3.3に負けた。orz

っていうか、まだリリースされてないか4.0って(笑
改善の余地有りってことかな。

27 :デフォルトの名無しさん:04/12/21 04:55:15
gcc 3.3.3が最強ってことでFA?

28 :デフォルトの名無しさん:04/12/21 05:34:49
gcc 3.3最強

29 :20:04/12/21 07:21:25
Firefoxのソースはgccっていうか、g++なんだけど。
Quick hackしようとおもって途中までやってたんだが次から次へと依存したコードが...。

⊂⌒~⊃。Д。)⊃  依存したコードありすぎて終わらね〜〜よ!!やめたー!


30 :デフォルトの名無しさん:04/12/22 12:58:07
binutils 2.15.94.0.2 出た

31 :デフォルトの名無しさん:04/12/22 16:40:45
>>29
どのへんかちょろっと教えてクリ

32 :デフォルトの名無しさん:04/12/22 19:56:52
gcc4.0は、まだバギーみたいだね。

33 :デフォルトの名無しさん:04/12/22 21:36:11
単純にvoid *をintに代入する、なんて糞コードが
修正されずに残ってるものなのかな。

もしかしたらptrdiff_t相当の、ポインタの差ををintに代入してるのかも
と思ったけど、だったら出るエラーメッセージが違うだろうし。

34 :デフォルトの名無しさん:04/12/22 22:01:46
gfortran4.0でfortran90用に書かれたソースが無条件でとおるようになった。
姫野ベンチを試したら、5%くらい遅いね。(Opteron1.6GHzで498Mflops(gfortran4.0)と526Mflops(g77))
またSECNDS()がなくなった。

35 :デフォルトの名無しさん:04/12/22 22:05:09
でもさ、mozillaプロジェクトのコーディング規約って、
移植性最優先なんじゃなかったかなあ。
firefoxって別なのか?

36 :デフォルトの名無しさん:04/12/23 10:47:08
>>33
AMD64上でgcc4.0を使用して、Firefoxをコンパイルすればわかる。

37 :デフォルトの名無しさん:04/12/23 10:55:08
gcc 4.0来春登場 - 互換性・速度に課題も
http://pcweb.mycom.co.jp/articles/2004/12/22/gcc/


38 :デフォルトの名無しさん:04/12/23 10:56:46
gccは宇宙史上最大のツール

39 :デフォルトの名無しさん:04/12/23 11:07:48
4.0上で>>20のエラーは"Mudflap"て機能が働いてるって事?

40 :デフォルトの名無しさん:04/12/23 11:16:12
> また「完全な内部形式のTree Dumpを取りたい」という意見については、
> 小島氏は「実はこれはRMSの方針で「完全なダンプは出さないようにすること」
> ということになっている」との事実を明らかにした。これは「完全なダンプを
> 出力可能にすると、ProprietaryなBackend Pathを作られてしまう可能性がある」
> という理由からだと言うのだが、一方で開発者にとって完全なダンプが取れる
> ことが非常に魅力的であるという事情もあることから、事前に何らかの文書等を
> 交わしたユーザに限り完全なダンプの出力機能を利用可能にするといったことが
> できないか現在検討が行われている、と同氏は語った。

41 :デフォルトの名無しさん:04/12/23 11:23:13
>>40
その行動は微妙だな。

42 :デフォルトの名無しさん:04/12/23 11:29:22
自分で手を入れて吐かせりゃいいんだけどな。
以前gcc依存バリバリのコードを処理する必要があるときにそうした。


43 :デフォルトの名無しさん:04/12/23 11:34:39
>>42
オープンソースなのでやるだけ無駄だということですね。確かに。

44 :デフォルトの名無しさん:04/12/23 14:21:44
吐く所だけGPLにすりゃいいだけだもんな。
敵に塩を送らないってだけの話だな。

45 :デフォルトの名無しさん:04/12/23 14:31:07
Build status for GCC 3.4
http://gcc.gnu.org/gcc-3.4/buildstat.html

Build status for GCC 3.3
http://gcc.gnu.org/gcc-3.3/buildstat.html


3.3.5でshやsh4はまだなのかぁ..。

46 :デフォルトの名無しさん:04/12/24 20:46:00
age

47 :デフォルトの名無しさん:04/12/24 23:16:14
>>37
casts-as-lvalue って何で騒がれてるの?
Linux界でだけ?

48 :デフォルトの名無しさん:04/12/24 23:32:46
大体cast-as-lvalueがどういう意味なのかも知らん。

49 :デフォルトの名無しさん:04/12/24 23:41:49
cast as lvalue は大昔からのGNU拡張でわ?

たいていは回りくどい書き方に修正すればANSI互換に書き直せるハズ。

50 :デフォルトの名無しさん:04/12/24 23:45:37
>>47
普通の C / C++ で *(int*)&d = 1; とか書くところを、gcc では今まで (int) d = 1; と書けてた(んだと思う)。
簡易unionみたいなもの。さほど意味の無い変な拡張だけど、使ってる人もいたんだね・・・

51 :デフォルトの名無しさん:04/12/24 23:51:01
gccを導入したいんですがどこからどうしたらいいのかわからないので
詳しく説明してあるページとかあったら教えてください、日本語で

52 :デフォルトの名無しさん:04/12/24 23:55:55
ホスト(コンパイラを走らせる環境)は何だよ?

53 :デフォルトの名無しさん:04/12/25 00:18:15
windowsなんですがうごきますか?

54 :デフォルトの名無しさん:04/12/25 00:23:17
>>53
cygwin mingw SFU(interix) coLinux どれか選べ

55 :デフォルトの名無しさん:04/12/25 00:23:23
cygwinなりmingwなりで検索しる


56 :53:04/12/25 00:26:16
ラジャ

57 :デフォルトの名無しさん:04/12/25 01:01:32
>>50
なるほど。

58 :デフォルトの名無しさん:04/12/28 18:36:28
cygwinについてるgcc用のSTLのrandom_shuffleって壊れてませんか?
全然シャッフルしてくれないんですけど?(最後の要素が先頭に移動するだけ)
同じコードをVC++7.1で動かしたらちゃんとシャッフルしてくれました。

59 :デフォルトの名無しさん:04/12/28 21:52:32
http://pc5.2ch.net/test/read.cgi/tech/1058134693/122-124n

60 :デフォルトの名無しさん:04/12/30 14:34:19
質問させてください。
Adaを含めてMinGW-BSDクロスコンパイラを作りたい場合、どうconfigureすればいいですか?

61 :デフォルトの名無しさん:04/12/30 22:15:55
>>59
それでうまくいきました。どうもありがとう。
しかし…なぜデフォルトでちゃんとシャッフルしてくれないのだろうか…。
(clでは第3引数なくてもちゃんとシャッフルしてくれました。)

62 :デフォルトの名無しさん:04/12/30 23:26:24
cygwin の lrand48 が悪いらしい。

63 :デフォルトの名無しさん:05/01/02 16:26:23
#include <stdio.h>

int main()
{
printf("abc");
}
という内容のファイルをコンパイルするとヘッダファイルがないといわれるんだけど何故?

64 :デフォルトの名無しさん:05/01/02 16:28:41
>>63
ヘッダファイルがないから。
ちがうか?

65 :デフォルトの名無しさん:05/01/02 16:34:07
includeパス間違い。ユーザ マニュアル見て設定しる

66 :デフォルトの名無しさん:05/01/03 13:00:30
>>60
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14626
俺にはドキュメントからは見つけられなかった

67 :デフォルトの名無しさん:05/01/04 17:19:30
>>39
> 4.0上で>>20のエラーは"Mudflap"て機能が働いてるって事?
違うよ


68 :デフォルトの名無しさん:05/01/06 04:45:44
-fstrict-aliasingと-funit-at-a-timeはメリットよりデメリットのほうが多い気がする。

69 :デフォルトの名無しさん:05/01/07 00:41:43
あのね、linuxとかgccはビルド環境もターゲット環境も多岐にわたるから、
中核部分の開発が激しく盛り上がってるときはどうしてももっとも主流の環境が
中心になるのだよ。LinuxだったらターゲットCPUはx86系で開発環境はLinux上、つまり
セルフコンパイル環境がね。といっても他の環境でも試さなければ問題が発見できないから、
それはそれで行なうわけ。

まあ1つのターゲットと1つの環境でしか開発したことのない人間は黙ってロッテことですな(笑
たとえばautoconfとか使ったことある?ターゲット環境やビルド環境に合わせてmakefileを自動生成数ツール。

70 :gcc初心者 :05/01/07 02:46:23
-- test.c --
#include <stdio.h>

int main(void)
{
printf("abc");
return 0;
}
----------

test.cをgccで、
%gcc -o test test.c ........(1) と実行しますと、testの実行ファイルが作成されますよね、
ここで、(1)のtestが動作していることを確認しています。


そして、今度は、
%gcc -c test.c でtest.oオブジクトファイル生成で止めて、リンカ(ld)で実行ファイルの生成したいのですが、(gccから、ldは呼び出さない。)
必要なライブラリが分かりません、(1)に-vオプションで表示されたライブラリを読み込ませたのですが、
関数exitが見つかりませんでした。

test.oをldで、リンクするとき最小限に必要なライブラリを教えていただけませんでしょうか
また、startupオブジェクトはどのライブラリなのか教えていただけませんでしょうか。

ちなみに環境はSunOS 5.8です。今手元に実行環境がなくあいまいな質問になってしまいましたが、
よろしくお願いいたします。






71 :デフォルトの名無しさん:05/01/07 02:54:59
gcc -v test.cしてみる

72 :デフォルトの名無しさん:05/01/07 02:58:41
gcc -o test test.o ... でリンクすればよかったのにな。

73 :デフォルトの名無しさん:05/01/07 22:24:14
なんだよ、最後は「実行しても何も表示されません」かと思ったのに。
全部読んで損した。

74 :gcc初心者 :05/01/08 01:03:34
%ld でリインクできた。

75 :デフォルトの名無しさん:05/01/08 07:17:26
リインク!!

76 :デフォルトの名無しさん:05/01/08 17:52:14
GNUの創造主 インタビュー

Interview: Richard Stallman
http://kerneltrap.org/node/4484

77 :デフォルトの名無しさん:05/01/09 08:47:02
キムチチゲ

78 :デフォルトの名無しさん:05/01/21 20:36:27
Did you receive the electric wave?

79 :デフォルトの名無しさん:05/01/21 20:46:45
yeno.

80 :デフォルトの名無しさん:05/01/21 20:52:46
最適化強くなってるから下手にフラグ付けると変なバイナリ出来そうだな…。

81 :デフォルトの名無しさん:05/01/30 03:26:20
rmsの波だの結晶、そのひとつがgcc。

82 :デフォルトの名無しさん:05/01/30 03:27:20
波だ→涙

83 :デフォルトの名無しさん:05/01/30 03:31:38
codesourceryって何者でつか?

84 :デフォルトの名無しさん:05/01/30 09:43:48
この前初めてインテルC++使ってみたけどGCC3.3.4に比較して45%以上の
パフォーマンス向上が確認できた。


85 :デフォルトの名無しさん:05/01/30 10:42:50
そりゃそうだろ

86 :デフォルトの名無しさん:05/01/30 12:40:18
>>84
それが売りだから。>IA32orIA64パフォーマンス
逆にIAマシンでgccとパフォーマンス変わらなければ存在意義ないし。

87 :デフォルトの名無しさん:05/01/30 17:50:53
# define __acquire(x)  __context__(1)

っていうコードで悩んでるんだけどな、
__context__(1)ってのはどういう意味なんだろう?


88 :デフォルトの名無しさん:05/01/30 22:07:00
Pentium3だとほんの少し速くなる程度。Pentium4なら劇的に速くなるのかな。

89 :デフォルトの名無しさん:05/01/30 22:50:51
GCCがPen4に対応する気がないから。


90 :デフォルトの名無しさん:05/01/31 13:24:52
gccってのはなにもIAマシンだけに固執してるわけではない。(IAユーザは多いが)

91 :デフォルトの名無しさん:05/01/31 13:28:01
しかし、g++の最適化がそれほど研かれてない気もする。
それもパフォーマンスが悪い原因の一つかな。

92 :デフォルトの名無しさん:05/01/31 13:42:33
gccはクロス・コンパイル機能はダントツかもしれんな。

93 :デフォルトの名無しさん:05/01/31 13:44:45
CPUをgccに最適化するとよいと行ってみるテスト


94 :デフォルトの名無しさん:05/01/31 13:48:29
>>93
RISCにすればそこそこ速そう。x86が悪いんだ!

95 :デフォルトの名無しさん:05/02/01 00:41:19
捕手

96 :デフォルトの名無しさん:05/02/01 01:01:14
gccは多態性がある。

97 :デフォルトの名無しさん:05/02/01 02:28:38
http://gcc.gnu.org/wiki

98 :デフォルトの名無しさん:05/02/01 05:06:43
大勢がx86-64にチェンジすればまた変わるんだろうな
レジスタ数増えれば最適化のチャンスも増えるし

99 :デフォルトの名無しさん:05/02/01 06:01:30
autovectorizationをgcc3にバックポートすればもっと変わる

100 :デフォルトの名無しさん:05/02/01 09:05:12
素直に4使えば?

101 :デフォルトの名無しさん:05/02/01 10:16:17
>>99
mudflapを3に(ry

102 :デフォルトの名無しさん:05/02/01 23:42:09
gcc 3.4になってから

if (functionName) {
...
}

みたいに関数名をboolコンテキスト持ってくると

the address of `functionName', will always evaluate as `true'

と警告が出るようになったんですが、これを抑制するオプ
ションが無くて参ってます。何かこの警告を消す良い方法は
無いでしょうか? ちなみにマクロを展開したあとにこういう
文になります。

103 :デフォルトの名無しさん:05/02/02 01:32:53
>>102
試してないけど、 functionName != 0 にしたらどうだろう。
でもこれは、マクロが問題なんじゃないかな?


104 :デフォルトの名無しさん:05/02/03 22:17:50
>>103
ありがとうございます。それでうまくいきました。
でもこういうマクロ問題なのかなあ・・・

105 :デフォルトの名無しさん:05/02/03 22:26:16
>>104
出された警告の意味わかってるのか?

106 :デフォルトの名無しさん:05/02/03 23:47:22
普通の関数は0番地に配置されることは絶対無い
(アーキテクチャにもよるがこれはハードウェアの仕様)
ので常にtrueになるよという警告だろ。

x86の場合、確か0番地はベクタテーブルだから必ず
割り込みルーチンのポインタが書かれていると思ったけど。


107 :デフォルトの名無しさん:05/02/03 23:58:28
>>106
君はいつまでリアルモードで生活してるのかね?

108 :デフォルトの名無しさん:05/02/04 00:30:00
関数へのポインタが整数の定数0と比較して等しくならないのはCの仕様。

109 :デフォルトの名無しさん:05/02/04 00:37:55
>>105
字面の意味じゃなくて何故この警告が抑制できないかって
ことですよね。全然わかりません。

-Wno-xxx で警告が消せないってことはプログラマに絶対
注意喚起する必要があるって判断なんだろうけど、正直
unused variable と同レベルの警告とかしか思えません。

110 :デフォルトの名無しさん:05/02/04 01:01:18
正直unused variableと同レベルの
どうでもいい話題 > 何故この警告が抑制できないかって

111 :デフォルトの名無しさん:05/02/04 21:56:18
現在、gcc.gnu.orgのサーバが障害発生中。
このサーバはsources.redhat.comも運用している。
ファイルシステムに問題があった模様で、現在復旧中。

112 :デフォルトの名無しさん:05/02/04 22:08:36
>>111
ガンガって復旧汁ぬぬぬ

113 :デフォルトの名無しさん:05/02/04 23:25:28
>>111
アンチGNU野郎に攻撃されたのかと思ったぞ。

114 :デフォルトの名無しさん:05/02/05 22:20:38
それいいね

115 :デフォルトの名無しさん:05/02/06 09:57:19
>>102
そんな謎のコードを生成するマクロ使うな


116 :デフォルトの名無しさん:05/02/06 10:55:39
大雑把にはこういう感じなんすけど
書き方が良くないんでしょうか・・・

#define (a,b,c,func)
do {
 foo(a,b);
 bar(b,c);
 if (func) {
  func();
 }
} while(0)

117 :デフォルトの名無しさん:05/02/06 11:13:33
キモイ

118 :デフォルトの名無しさん:05/02/06 11:18:43
do とか使う人嫌いです

119 :デフォルトの名無しさん:05/02/06 12:05:03
>>118
かわりに何使えばいいでしょう??

120 :デフォルトの名無しさん:05/02/06 12:19:12
つうかこれってdo〜while使う必要あるのか?

121 :デフォルトの名無しさん:05/02/06 12:21:37
> if (func) {
これなんの意味があるの?


122 :デフォルトの名無しさん:05/02/06 12:24:40
>>120
二つ以上の文をマクロにするとき do {} while(0) で囲うのが
普通と思っていたんですが、実は普通じゃなかったんでしょうか・・・

123 :デフォルトの名無しさん:05/02/06 12:25:30
>>121
func に相当する処理が不要になるケースがあるので、
その場合 NULL を与えればそこを飛ばせるように、という
意図なんですが・・・

124 :デフォルトの名無しさん:05/02/06 12:27:12
>>122
do..whileはbreakで抜けたい時だけですよ…

125 :デフォルトの名無しさん:05/02/06 12:35:00
こっちいってくれ
C言語なら俺に聞け! Part 101
http://pc5.2ch.net/test/read.cgi/tech/1107128274/

126 :デフォルトの名無しさん:05/02/06 13:04:33
>>125
あ、そうですね 失礼しました

127 :デフォルトの名無しさん:05/02/06 13:31:11
>>122
セミコロンを要求する意図での使用は普通。
貴方は正しい。


128 :デフォルトの名無しさん:05/02/06 14:27:50
>>123
funcあり版となし版を用意する方が医院で内科医?

129 :デフォルトの名無しさん:05/02/06 21:17:44
gdcって統合されないのかな?

130 :デフォルトの名無しさん:05/02/06 21:23:20
これ以上肥大化させないでくれ……

131 :デフォルトの名無しさん:05/02/06 21:30:40
gcc.gnu.org 復活age

132 :デフォルトの名無しさん:05/02/07 13:46:29
MSも酷いことするよな。
いくらGCCが憎いからって・・・

133 :デフォルトの名無しさん:05/02/07 17:28:23
>>132
いつもやり方が同じなのが笑える

134 :デフォルトの名無しさん:05/02/07 22:27:38
gccは世界遺産に認定

135 :デフォルトの名無しさん:05/02/08 17:01:41
gccのバックエンドの書き方解説してるページはどこですか?

136 :デフォルトの名無しさん:05/02/08 18:09:29
バックエンドは知らん。

フロントエンドなら GCC Frontend HOWTO があるが。

137 :デフォルトの名無しさん:05/02/11 13:11:47
gcc4.0はいつリリースでつか?

138 :デフォルトの名無しさん:05/02/11 15:07:44
http://www.google.com/search?q=%22GCC+4.0%22+%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9
上から 2 番目。
検索エンジンぐらい使えよ、ボケ。

139 :デフォルトの名無しさん:05/02/18 04:23:38
AthlonXPのCPU使っていてフラグに-fprefetch-loop-arrays付けるとQuantiSpeedを使ってくれるよう最適化するのかな。

140 :デフォルトの名無しさん:05/02/22 13:38:49
GCC 4.0 Status Report (2005-02-03)
ttp://gcc.gnu.org/ml/gcc/2005-02/msg00079.html

141 :デフォルトの名無しさん:05/02/22 16:10:09
>>140
> Therefore, my current expectation for a GCC 4.0 release date is April 15th.
4/15に4.0リリース見込みか・・・まぁ伸びるだろうけど。

142 :デフォルトの名無しさん:05/03/01 10:11:05
Active development (mainline): will become GCC 4.1.0
http://gcc.gnu.org/gcc-4.1/changes.html


GCC 4.1 Projects
http://gcc.gnu.org/wiki/GCC%204.1%20Projects


What will be in 4.0
http://gcc.gnu.org/wiki/What%20will%20be%20in%204.0

143 :デフォルトの名無しさん:05/03/01 15:33:50
4.0の最適化がよくなってきたね。
20050222でやるとgcc3とほとんど同じ速さになった。(FC3 )
4.1のx86_64がコンパイルできない。
crti.o がないといっておこられる。
x86_64用のcrti.asmがないんだけど。

144 :デフォルトの名無しさん:05/03/01 15:40:49
>>143
以下へ進め!
http://gcc.gnu.org/bugzilla/

145 :デフォルトの名無しさん:05/03/01 17:53:13
ちょっとお聞きしたいんですが、以下のようなファイル
---ファイルここから---
--func.c--
#include <library1.h>

#ifdef BAR
#define FOO
#include <library2.h>
#endif
(以下略)
--library1.h
(略)
#include <library2.h>
(以下略)
--library2.h--
(略)
typedef _hoge hoge;

#ifdef FOO
struct _hoge {(構造体の中身:中略)
};
#endif
(以下略)
---ファイルここまで---

で、gcc -I(ライブラリヘッダファイルの場所) -DBAR -c fonc.c でコンパイルするようなfunc.cを
書くときに、func.cの中で構造体hogeは使用できるのがgccの仕様として正しいのでしょうか
それとも、できないのが正しいのでしょうか。
#実はgtk+-2.6.2 + ruby-gdkpixbuf2-0.11.0で上のようなところで
#hogeに対応する構造体が完全に定義されないためにエラーが出て困ってます。
#(cppを通してみたらstruct _hoge { }; の部分が出てこなかった。)
#gccはgentoo linuxの3.4.3.20050110というバージョンです。

146 :デフォルトの名無しさん:05/03/01 18:18:51
>>145
gcc かどうかって関係ないんでは。本当にこの通りだとすると、cpp の
出力に struct _hoge {...}; が含まれるでしょ?


147 :デフォルトの名無しさん:05/03/01 18:29:00
>>145
library2.hにインクルードガードが掛かってるとか?

148 :145:05/03/01 21:25:18
>>145,146
レスどうもです。いやぁ、マヌケかましてました。

>>146
>library2.hにインクルードガードが掛かってるとか?
まさにそれでした。
実際には
library1.h→gdk-pixbuf.h、library2.h→gdk-pixbuf-io.h、func.c→rbgdk-pixbuf-format.c
BAR→HAVE_GDK_PIXBUF_GDK_PIXBUF_IO_H、FOO→GDK_PIXBUF_ENABLE_BACKEND
hoge→GdkPixbufFormat
なのですが、gdk-pixbuf-io.hにしっかりインクルードガードがかかってました。
で、GDK_PIXBUF_ENALBE_BACKENDをdefineした後のgdk-pixbuf-io.hのインクルードは
ガードされてるので、_GdkPixbufFormatの定義ができないみたいです。

#gtk+-2.4から2.6バージョンが上がったときにgdk-pixbuf.h、gdk-pixbuf-io.h
#周りが変わって、gdk-pixbuf.hがgdk-pixbuf-io.hをインクルードするようになったっぽい。

ていうことは、gtk+-2.6じゃruby-gdkpixbuf2はコンパイルできないと言うことか...
#早く対応版をリリースして欲しいな...

149 :デフォルトの名無しさん:05/03/02 11:17:08
そういうコード書く奴が悪いと思うが。

150 :デフォルトの名無しさん:05/03/02 16:54:34
>>149
この場合の悪いやつとは誰?

1.Gtk+の開発者
2.ruby-gnome2の開発者


151 :デフォルトの名無しさん:05/03/02 21:29:33
Ruby!!!!!!!!!!!!!!!!

152 :デフォルトの名無しさん:05/03/04 00:26:58
>>151
バカはしゃしゃり出てこないように。

153 :デフォルトの名無しさん:05/03/04 04:06:21
Ruby!!!!!!!!!!!!!!!!

154 :デフォルトの名無しさん:05/03/05 06:22:40
gccってなんと読むのですか?

155 :デフォルトの名無しさん:05/03/05 12:31:26
>>154
みかか

gcc4の最適化が大分賢くなってきたね。gcc3.4より早くなるコードも出てきたよ。


156 :デフォルトの名無しさん:05/03/05 12:45:17
バグが怖くて使えないけどな〜

157 :デフォルトの名無しさん:05/03/05 14:30:52
>>155
きそそ

じゃないの?

158 :デフォルトの名無しさん:05/03/05 14:42:13
>>156
ま、僕も試してるだけだけど、
そうはいっても、どのバージョンにも少しずつ問題あるしなー。

>>157
歳がばれますね。(お互いに)


159 :デフォルトの名無しさん:05/03/05 15:59:00
JISかな配列と年齢に何の因果関係が?

160 :デフォルトの名無しさん:05/03/05 16:07:26
ぐっしっし

161 :デフォルトの名無しさん:05/03/05 16:25:22
Mudflapって、IBMのプロポリスみたいに、運用時のセキュリティ向上に使えるものなんでしょうか?
それとも、GCC BoundChecking patchみたいにデベロッパのデバッグ向け?


162 :デフォルトの名無しさん:05/03/05 19:09:04
>>161
遅くなるので、デバッグ以外の用途は厳しいような気がしますな。

163 :デフォルトの名無しさん:05/03/05 21:44:22
そりゃあんただけですな(苦笑

164 :デフォルトの名無しさん:05/03/06 02:15:30
>>162
MLを見るに、現状だとboundscheckingパッチ並み(かそれ以上)に遅いようですけど、
4.0の正式リリース時までに改善されたりする予定はないんでしょうか?

HeapOverrun対応ってことで、IBMのよりヨサゲなんですけども。。

165 :デフォルトの名無しさん:05/03/06 20:48:56
>>158
因みに、私は22ですよ
(みかかは知ってるけど、確かPC雑誌で読んだ知識で、普通に使われてた時代はネットしてなかった)
確かに友達はみんな知らんなぁ

166 :デフォルトの名無しさん:05/03/06 23:57:30
>>164
そう簡単には速くならんと思う。


167 :デフォルトの名無しさん:05/03/07 00:36:40
>>165
がびーん、おじさんは俺だけか・・・

>>164
多少早くなるかもしれんけど、劇的に変わることはないんじゃないかな。


168 :デフォルトの名無しさん:05/03/08 13:33:00
もせ

169 :デフォルトの名無しさん:05/03/13 19:55:42
【隔離】Cなら俺に訊け! Part.104【病棟】
http://pc5.2ch.net/test/read.cgi/tech/1110099763/584
から飛んできました。

584 :デフォルトの名無しさん :05/03/13 19:05:28
if (0 <=c && c<=127) とすると、コンパイラが
comparison is always true due to limited range of data type
と警告を出しました。コンパイラは gcc 3.3 です。

170 :デフォルトの名無しさん:05/03/13 20:15:58
>>169
元スレで結論は出てると思うが

171 :デフォルトの名無しさん:05/03/13 22:21:41
>>170 あ、元スレのほうにレスがついてました。
ありがとうございました。

172 :デフォルトの名無しさん:05/03/14 06:00:42
おそらく >>169 の処理系では, 先に CHAR_MAX=127 と定義されて
c <= 127 は >>169 の処理系では c <= CHAR_MAX と等価なので,
常に真になると警告してるような気がする。

CHAR_MAX は処理系定義なので CHAR_MAX が 128 以上に定義されてる
場合は警告は出ない鴨。

173 :デフォルトの名無しさん:05/03/14 06:09:35
>>172
元スレで結論が出てる話にいまさら「気がする」と書き込んでどうする。
ついでに言っておくが、 CHAR_MAX=255,CHAR_MIN=0 でも警告されるだろうな。

174 :デフォルトの名無しさん:05/03/14 06:12:25
>>173
CHAR_MAX=255の場合でも警告されるの?詳細希望。

175 :174:05/03/14 06:16:00
あ,CHAR_MIN=0の場合か。失敬。

176 :デフォルトの名無しさん:05/03/14 20:50:24
何故ここでC言語の文法の話なのだ?

177 :デフォルトの名無しさん:05/03/14 23:28:02
警告の話だろ

178 :デフォルトの名無しさん:05/03/15 00:27:33
>>177
出力された警告の通りでしょ。疑問なんかなんにもないじゃん。
で?

179 :デフォルトの名無しさん:05/03/15 01:18:44
gccのライブラリの話ってここでいいの?

180 :デフォルトの名無しさん:05/03/15 01:20:34
「gccのライブラリ」じゃぁ誰も分からん。

181 :デフォルトの名無しさん:05/03/15 01:25:51
わかんないなら答えなきゃいいのに。

182 :マイク ◆yrBrqfF1Ew :05/03/15 03:09:30
まあ馬鹿同士仲良くやれよ(▽

183 :デフォルトの名無しさん:05/03/15 03:14:13
馬鹿が集まってきたなw

184 :デフォルトの名無しさん:05/03/15 03:24:36
俺は、>>172の指摘したgccの警告は(・∀・)イイ!!と感じる。
ウザイと感じるのはVCでいっぱいいっぱいの初心者。

警告に関して言えば、gccの優れた点の一つだと思う。
printf系の書式指定する出力関数の書式チェックをある程度やってくれるのも(・∀・)イイ!!

185 :デフォルトの名無しさん:05/03/15 05:32:12
gccってなんて読むの?ぐっくっく?

186 :デフォルトの名無しさん:05/03/15 07:40:16
>>185
ゲェーツェーツェー

187 :デフォルトの名無しさん:05/03/15 23:28:31
>>185
本当はげしし

188 :デフォルトの名無しさん:05/03/16 01:19:23
期待と不安が交錯するオープンソースコンパイラの新バージョン開発
http://japan.cnet.com/news/ent/story/0,2000047623,20081333,00.htm

189 :デフォルトの名無しさん:05/03/16 01:55:18
>>185
げーしっく

190 :デフォルトの名無しさん:05/03/16 02:55:02
devel で rms が暴れててびびった。

191 :デフォルトの名無しさん:05/03/16 10:21:46
gcc3.3.3で安全かつ高速な最適化オプションってどうつければいいんでしょう。

-O3 -mcpu=pentium3 -march=pentium3 -msse -mfpmath=sse -fomit-frame-pointer -fmove-all-movables -ftracer -fforce-addr -freduce-all-givs -fno-branch-count-reg -foptimize-register-move -fsched-spec-load

Pentium3でこんな感じで最適化オプションを設定してます。

192 :デフォルトの名無しさん:05/03/16 10:30:22
>>191
最適化オプションが「安全」って、どういうことよ?

193 :デフォルトの名無しさん:05/03/16 11:25:59
コケたり妙な挙動しないかとか。

194 :デフォルトの名無しさん:05/03/16 11:40:17
単に何もわかってない最適化厨と思われ。



195 :デフォルトの名無しさん:05/03/16 13:12:45
>>191
何も付けない。

196 :デフォルトの名無しさん:05/03/16 15:16:16
最適化で動作がおかしくなるプログラムは、そのプログラムのソースが
元からおかしくて、最適化で問題が露呈するケースが多いように思う。


197 :デフォルトの名無しさん:05/03/16 15:50:46
>>190
rmsは今でも現役です。

198 :デフォルトの名無しさん:05/03/16 16:23:36
4.0のスケジュールはどこで確認できるの?

199 :デフォルトの名無しさん:05/03/16 16:49:57
>>198
大雑把にはコレ:
http://gcc.gnu.org/develop.html#timeline

細かいのは、gcc ML を読むしかない。
今はコレ:
http://gcc.gnu.org/ml/gcc/2005-03/msg00477.html
> the April 15th target for GCC 4.0


200 :デフォルトの名無しさん:05/03/16 17:27:09
生涯現役。あっちもバリバリです。

201 :デフォルトの名無しさん:05/03/17 00:25:11
>>196
確かに。

Strict aliasingのルールなんて、知ってる奴のほうが少ない。

202 :デフォルトの名無しさん:05/03/17 16:42:53
open64ってどう? 使ったことある人いる?
http://open64.sourceforge.net/

元はSGIのPro64というコンパイラで科学計算分野で使われていたらしい。GPL。



203 :デフォルトの名無しさん:05/03/17 19:36:37
crossjumping!


204 :デフォルトの名無しさん:05/03/18 00:53:37
gccでLD_LIBRARY_PATHを設定しなくても、実行時に/usr/lib以外の
ライブラリサーチバスを探してくれるオプションは何でしたっけ?

205 :デフォルトの名無しさん:05/03/18 01:02:07
-L/path/to/lib

206 :205:05/03/18 01:02:39
実行時か。

207 :デフォルトの名無しさん:05/03/18 03:26:58
>>204
よくわからんが、動的ライブラリにしたいのではなくて?

208 :デフォルトの名無しさん:05/03/18 04:58:37
>>204
-Rとか-rpathあたり。

209 :デフォルトの名無しさん:05/03/18 12:12:00
>>204
LD_PRELOAD


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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)