元スレGCCについて part8

gcc覧 / PC版 /

みんなの評価 : ☆

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

152 = :

__GNU__?

153 = :

__GNUC__
__GNUC_MINOR__
__GNUC_PATCHLEVEL__

154 = :

#if defined( __GNUC__ )
#if ( __GNUC__ >= 4 )

かな

155 = :

>>152
>>153
>>154

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

156 = :

IntelのCコンパイラだとデフォルトでは>>153をdefineしている（オプションで変更可）
特殊かもしれんが

157 = :

RHLE version3 のサポートが終了してしまうので、
gcc 2.9.6
gcc 3.2.3
から、
RELE version5のgcc 4..xに変更したんだけど、コードの修正メンドくせー、
互換性無いのって悲しいね。

158 = :

×互換性が無い
○コードが汚い

ザルだった文法チェックに救われていただけ

159 = :

普通に書いていれば修正なんてほとんど要らんだろ

160 = :

>>157じゃないが、
Cだとgccの移行は簡単だけど、C++だと悲惨。
2->4なんて。

コンパイルエラー/ウォーニングになるのはいいけど、
コンパイラが検出できない奴など。
例えばlookupのルール変更とか。
ADLは便利だけど、難しいから。

161 = :

>>160
馬鹿コーディングだから移行が難しいんだよ。
俺も新人だった頃の自分のコードを呪ったよ。
きちんとしたコードはすぐ移行できた。

164 = :

意外と使われてるのに…

165 = :

http://gcc.gnu.org/ml/gcc/2008-01/msg00023.html
バグ潰し終わらねー感じ

使ってみてもICEとかc++のスコープとか色々おかしい印象がある
開発者がんばってくれー

166 = :

>>165
mudflapというオプションを初めて知った。　ひで～ネーミングだな。

167 = :

速度云々を無視しよう
という条件下だと、fPICって常に付与してていいもんなのか？

169 = :

CスレでGCCの範囲だから、すれ違いと言われてここに来ました。
http://homepage2.nifty.com/m_kamada/fractalp.htm#mandelbmp_c
のサイトにある、complex.hを読んでいるんですが、
gccでマクロを展開してここのソースを読むと、
/* setjmp(cjmpenv)の返却値 */
#define C_DIVIDE_BY_ZERO 1 /* 0で除算しようとした */
#define C_ARG_ZERO 2 /* 0の角度を求めようとした */
略
#endif
#if __GNUC__==2
#define complex __complex__
#define Re(z) (__real__ (z))
#define Im(z) (__imag__ (z))
#else
typedef struct {
double re;
double im;
} complex;

などごっそり書いてあった部分が、
/* setjmp(cjmpenv)の返却値 */
# 24 "complex.h"
typedef struct {
double re;
double im;
} complex;
# 77 "complex.h"
/* xの実数部にsを加える */
# 89 "complex.h"
/* xの虚数部にsを加える */
と、# 24 "complex.h"や# 77 "complex.h"などに置き換えられているようです。
この#24や#77はどういう意味なのでしょうか?

172 = :

>>169
マクロ展開前の行番号。コンパイル時にエラー行を表示するためにそう
いう情報を残す必要がある。

>>171
sizeof と同じような形式の演算子だと思えばいいんじゃない？
__は単に名前の一部。

173 = :

普通の名前と喧嘩しないように __ を付けるのは慣例

174 = :

慣例じゃなくて予約されているんだが

175 = :

>>172,173,174
お返事有り難うございます。
>普通の名前と喧嘩しないように __ を付けるのは慣例
>慣例じゃなくて予約されているんだが
確かに__って普通の変数には付けないですからね。
どうも有り難うございました。

176 = :

あ失礼，そうだった．＜慣例

178 = :

gdb+gccなんですがクロスコンパイルしてます。
Aでコンパイル
Bで実行。

Bで、はいたコアダンプを冢ってgdbを使いたい場合は
Aでmakefile(自動生成)使ってまっす。

どうしたら、ディレクトリ構造とか再現してソース追っかけながらデバッグできますか?
makefileに答え有りますか?

179 = :

Bで、はいたコアダンプを冢ってgdbを使いたい場合はどうしたら良いですか?

文が変だた

180 = :

>>178
Bでgdbserver走らせるのが一番楽じゃない？

181 = :

>>180
おとなの事情というか会社の事情で無理なんです

183 = :

>>180
あ、ごめん、コアの話しか。　そういう機能はgdbserverにはないね。

184 = :

だめだ。
__real__って何なんだ?
関数ではないしcomplex.hにも定義されていない。
gcc機能拡張ってのがよくまずわからない。
特殊な演算子なんですか?

185 = :

>>184
わからないなら自前の構造体定義すれば?

186 = :

>>184
何をわかる必要があるというんだろう。sizeof だってどこかのヘッダで
定義してあるわけじゃないけど使えるでしょ？

infoの説明はこれだけしかないけど、これで十分つかえるじゃないか。
> To extract the real part of a complex-valued expression EXP, write
> `__real__ EXP'. Likewise, use `__imag__' to extract the imaginary
> part.

187 = :

>>184
http://www.asahi-net.or.jp/~wg5k-ickw/html/online/gcc-2.95.2/gcc_4.html#SEC72

194 = :

デバッグトレースした方が便利な事もあるぜ。

195 = :

デバッグトレースって何さ

197 = :

社内用語乙。

199 = :

でもまー、ふつー「バックトレース」

200 = :

違った。

つか「デバッグトレース」って、デバッグ目的のトレース実行とか、
呼び出し順の出力のことじゃね？