GCCについて part10
■ このスレッドは過去ログ倉庫に格納されています
brokenな日本語でも日本語の話者ならば補って理解できる。 実行される可能性がある未定義動作のコードが一行でも混じっていれば そのプログラムは起動直後からソースコードを一切無視してどういうふるまいをしても構わない。 過度の最適化ではない。 >>286 底辺職種に従事している人が多いからね そんな奴は脳レベルが低すぎてbrokenな日本語は理解不能 4.8、動かない以前にビルド通らんのが出てきたぞ バージョン上がる度に型チェック厳しくなる一方だぜ http://gcc.gnu.org/projects/cxx0x.html Rvalue references for *this : GCC 4.8.1 fast-mathオプションをつけるとisnanが機能しなくなるのだけど、何かいい手はない? そのファイルだけfast-mathを外してコンパイルする。 と、どうなるか試してほしい。 fast-mathつけなければ大丈夫。 fast-mathをつけると、isnan以外にも、a != aで判定する方法もダメ。 何かいい方法ないかな -ffast-math をばらして必要なオプションだけを指定してみたら? -ffast-math Sets -fno-math-errno, -funsafe-math-optimizations, -fno-trapping-math, -ffinite-math-only, -fno-rounding-math, -fno-signaling-nans and fcx-limited-range. -ffast-math -fno-finite-math-only の併用でok 4.8ビルドしようとするとgccでintl-printと__printf__が不明と怒られる 仕方ないのでconfig.hに#include <libintl.h>を書き足すと>>255 と同じ事 言われて怒られる、しかしgmp等はインスト済み これってx64のライブラリ以外にx86のライブラリも必要って事なのかな? コマンドラインまで >>255 と同じなら × --with-gmp-lib=/usr/local/lib64 ○ --with-gmp=/usr/local mpfr,mpc も同様 レスありがとう! んでも 64ビットのWindowsおよびgccだけSJLJ例外の32ビットベースのmultilibの バージョンについては#エラーがサポートされています。 って怒られた。。。ウチの環境はWin7x64、gccはTDM64です configureはこれ LIBS="-lintl -liconv " ../gcc-4.8-20130404/configure --prefix=/usr/gcc \ --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 \ --with-tune=generic --enable-threads=posix --disable-multilib --enable-static \ --enable-languages=c,c++,objc,obj-c++ --enable-libgomp --disable-sjlj-exceptions \ --with-dwarf2 --enable-version-specific-runtime-libs --disable-win32-registry \ --disable-werror --disable-nls --enable-lto --with-system-zlib \ --enable-libstdcxx-debug --enable-cxx-flags='-fno-function-sections -fno-data-sections' \ --enable-fully-dynamic-string --disable-libstdcxx-pch --disable-bootstrap \ --with-mpc-lib=/usr/tool/lib --with-mpc-include=/usr/tool/include \ --with-mpfr-include=/usr/tool/include --with-mpfr-lib=/usr/tool/lib \ --with-gmp-include=/usr/tool/include --with-gmp-lib=/usr/tool/lib \ --with-cloog-include=/usr/tool/include --with-cloog-lib=/usr/tool/lib \ --with-isl-include=/usr/tool/include --with-isl-lib=/usr/tool/lib --disable-multilibを消しても、やっぱりx64云々で蹴られますた ってかconfigureのログ見てると、intl=ok, iconv=okって言ってるのになんで intlの関数が不明って言われるのかなあ。 消すなら --disable-multilib ではなくて --disable-sjlj-exceptions だろjk あと、もし binutils を一緒にビルドしようとして、 gcc のフォルダ内に binutils/{なんやらかんやら} へのリンクを張ってるなら、 両者に共通のライブラリが、バージョン違って失敗するかも 消したけどダメ。。 ターゲット・ホスト・ビルドのx86_64-w64を消さないとどうしても 「はぁ?x64?」みたいな事言われるので消して、それでもintlで文句言われて config.hに<linintl.h>書き加えてビルド進めるとlibgccで Assembler messages: Error: invalid instruction suffix for `push' アセンブラ関連のエラーだと思うんだけど、ターゲットをx86_64-w64にすると怒 られ、libintlで怒られ…gccサイトのQ&A見ても「我々は悪くない、文句言われる テメーが悪い」みたいな事書いてあるし。。。。 もうネルソン! やっとでけたあああ 七誌さんそして>>300 ありがとう! 一応手順 gcc用のディレクトリを作成、binutilsをビルド→インストール gccをコンパイラのみビルドしてinstall-gcc ここでmsys上のmingwを今作ったgccに切り替え mingw-w64ランタイムをヘッダのみビルド→インストール ランタイムをビルド→インストール gccの残りをビルド→インストール 今まで通常使ってるmingwだけでビルドしようとしてたのが間違ってた?っぽい なんだかよく分からなかったけど強引に潰したエラー、3件 1.↓って言われる i386/cygming.h:358:2: error: #error For 64-bit windows and 32-bit based multilib version of gcc just SJLJ exceptions are supported. i386/mingw32.h:101:2: error: #error DW2 unwind is not available for 64-bit. i386/cygming.h:358:2: error: #error For 64-bit windows and 32-bit based multilib version of gcc just SJLJ exceptions are supported. i386/mingw32.h:101:2: error: #error DW2 unwind is not available for 64-bit. i386/cygming.h:358:2: error: #error For 64-bit windows and 32-bit based multilib version of gcc just SJLJ exceptions are supported. i386/mingw32.h:101:2: error: #error DW2 unwind is not available for 64-bit. コメントアウト 2. intl_printが不明 config.hに<libintl.h>を書き足す 3. libstdc++-v3/include/bits/basic_string.hでエラー call googleで外人さんのパッチをクローン +++ ./libstdc++-v3/config/os/mingw32-w64/os_defines.h +#include <_mingw_mac.h> +#if !defined (__MINGW64_VERSION_MAJOR) || (__MINGW64_VERSION_MAJOR < 3) #define _GLIBCXX_HAVE_BROKEN_VSWPRINTF 1 +#endif 3は、なんだか公式のmingw32使えみたいな事言ってた気がするけど1.2が分からんち 特に2番、なんでヘッダを要求されるのか。公式になんか書いても怖い人しかいないよう な雰囲気なので聞けない。。。 グダグダ書いたけど結局は>>302 のbinutils云々がヒントになってビルド出来た、ありがとね 追記:libintlがぶっこわれてた 今までどうやってビルド通ってたんだろ・・・・・・・・・ ネタじゃないので聞いてください。 一番最初のgccはどのようにコンパイルされたのですか? 別のコンパイラを使う。UNIXのccとか。 歴史の話じゃなくて実用的な意味でどうするかといえば、 オフィシャルでバイナリのgccが配布されているのでそれを使う。 ネタじゃないので聞いてください。 一番最初のccはどのようにコンパイルされたのですか? gccをどうやってコンパイルするかを勉強してると そのあたりまで平然と遡らされるよな Z80アセンブラをN88-BASICで実装しようとしたのは良い思い出… >>311 > 一番最初のccはどのようにコンパイルされたのですか? 当時一般的に使われていた, Unix 上の PCC 互換コンパイラでコンパイルされたんだが, なんか問題あるの? ネタじゃないので聞いてください。 一番最初のアセンブラはどのようにアセンブルされたのですか? multilib有効にしてGCCビルドしたら、ライブラリビルドでldちゃんが 32ライブラリに64libを合体させてしまいまする export -m32 -L/lib32 とかにしても言う事を聞いてくれませぬ ググっても、バカには無理みたいな風潮 TDMとか、どうやってmultilibなGCCビルドしてるんだろ? gccの2.95.3なんですが、 gccがコンパイルされたときの./configureに渡された設定など 調べる方法は無いでしょうか? gcc -vは? どうでもいいことだが、なぜそんな化石を使うのか聞いてみたい gccで、以下のような情報を得るためのコマンドラインオプション、あるいは ツール・手段はありませんでしょうか? 知りたいのは、どういう過程でライブラリがリンクされているかです。 例えば、main.cでprintf()が使われている時、 (1) main.o には未解決のシンボル'printf'がある (2) 未解決シンボル'printf'を解決するため、libc.a 内の lib_a-printf.o をリンクした (3) さらに lib_a-printf.o には未解決のシンボル'vfprintf'がある (4) 未解決シンボル'vfprintf'を解決するため、libc.a 内の lib_a-vfprintf.o をリンクした (5) さらに lib_a-vfprintf.o には未解決のシンボル・・・・ : のような情報が得たいのです。 目的は、組み込み用でコードサイズ小さくしたい場合に、想定外のライブラリがリンク されているような場合、何が起点になっているかを調べるためです。 (例えば、標準入出力は使ってないのに標準入出力関係のライブラリがごっそりリンクさ れてしまう場合に、sprintf()→vfprintf()→・・・と、sprintf()を使っているのが原因 であることを知りたい) -Wl,--verbose は試してみましたが、ダメでした。 >>325 スマートリンクを使った方がてっとりばやいんじゃね? >>328 レス、ありがとうございます。 スマートリンクもコードサイズ削減に効果が無くはありませんが、(newlibは結構細かく ソースが分けてあるので)効果は小さいと思われます。 例えば、newlibの場合newlib内で使用する静的変数を(マルチスレッド対応等が容易なよ うに)_reent構造体にまとめてありますが、これをリンクするような関数を一つでも使用 してしまうと_reent構造体に関連する関数が多数リンクされ、コードサイズが肥大します。 これは(実行時に呼ばれることは無くても)未定義シンボル解決には必要であり、 -Wl,--gc-sectionsでは防止できません。 コードサイズの肥大の起因となるライブラリ関数が(質問に記述のように)特定でき、これ がごく少数なら、この関数を使用しないようにプログラムを書き換えてしまえ、という わけです。 gccじゃなくてリンカの仕事 例えばAppleのldなら-why_liveとかあるから、とりあえずman ld 使ってる*.oをnmして未定義シンボルをリストして、 シンボルがどの*.aで定義されてるかnmして調べて、 *.aをar xして*.oにしてnmして、 以下収束するまで繰り返し。 多分機械的に出来るんじゃないか? Cの場合、使われる*.aは引数で与える必要があって、 最初から全リストが分かってるわけだし。 >>330 誤解を招く文章ですいません、ld(binutils)を含めてgccと書いていました。 -why_live(https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ld.1.html ) はまさに欲しているものでしたが、使用しているld(GNU ld version2.15 arm-elf/cygwin のクロス環境)には実装されていないようでした。 * ld.info(manがなかったので) * arm-elf-ld --help * http://sourceware.org/binutils/docs-2.15/ld/Options.html#Options で、why/live/chain/refferenceなどのキーワードで探してみましたが、同等のものは 見つけられませんでした。 >>331 はい、その方法(それを行うツールの作成)は最後の手段として考えています・・・ ld --help --cref 相互参照表を出力する -Wl,--cref >>332 ありがとうございます。 --crefで目的を達せそうです。 cygwinで gcc 4.8.1 コンパイルしたけど、エラーが2つでてインスコできんわ・・orz gcc -S -g で出力されるアセンブルコード中の.locの情報を 該当するCソースに置換するフィルタはどこかで公開してませんか? as --help -a[sub-option...] turn on listings Sub-options [default hls]: c omit false conditionals d omit debugging directives g include general info h include high-level source l include assembly m include macro expansions n omit forms processing s include symbols =FILE list to FILE (must be last sub-option) gcc -c -O2 hoge.c -Wa,-ahls=hoge.lst >>337 ありがとう。それに-gつけたら出来ました。 ではお言葉に甘えて。 カバレッジを調べるためgcovすると自分のソース以外の iostream.gcovとかも大量にできてしまいます。 これを指定のディレクトリ以外は生成しないようにできないものでしょうか? 今のところ-pをつけてファイルを生成し必要のないフォルダのものをrmで消してます。 gcov --help -o, --object-directory DIR|FILE オブジェクトファイルを DIR 内または呼び出し用 FILE 内で検索する >>342 使い方が間違っているのか期待した結果になりませんでした。 srcディレクトリに.h / .ccがあるので -o src と指定しましたがiostream.gcovは生成されました。 objディレクトリに .o があるので -o obj と指定すると obj/test.gcno:cannot open graph file といったエラーが表示されます。そこでobjにtest.gcnoをmvすると処理は通りますが 相変わらずiostream.gcovは生成されます。 ただlcovすると.gcovは消えるので気にしなければ済む問題かもしれません。 プリプロセッサの話ってここで大丈夫?スレチだったら流して gccの-EオプションでCライクな言語のプリプロセスかけてるんだけど、そのマクロの記述で #define get_pi(data) (6'(data)<<3)って感じの記述してて、 これの ' の部分が文字データ記述の開始として扱われてdataが置き換わらないんだけど、対策ないですかね? SystemVerilogかね? #define s ' #define get_pi(data) (6 s (data)<<3) 空白が入るけど動くよ。警告も出るけど。 規格上問題ないか、どのGCCバージョンでも動くかは分からん。 >>346 返信ありがとう御座います! 早速試したら出来ました。けどなぜ動くのかわからない… 因みに使ってるのNSLという言語です。ハードウェア記述言語なのは一緒ですかね >>347 dataが置換された後に再走査されてsが置換されるから動く。 だから#define s ' が動けば、問題なく動く。 >>348 プリプロセッサってプロトタイプ宣言みたいに上から順に〜ってわけではないのか。一緒だと思ってました gcc4.9のtrunk版、3ヶ月くらいプラグマバグでビルド出来なかったんだけどようやく修正された >>349 いやいや、上から順で正しい。再走査はマクロ展開時の話だよ。 マクロ引数dataが展開された後に、その結果に対して再走査されて 普通の地の文と同じようにsがマクロ展開される。 最初のやつがうまく動かないのは、Cプリプロセッサは文字置き換えでなくて トークンを置きえるから。 (6'(data)<<3) は (, 6, '(data)<<3) という3つのトークンになってしまう。 dev/nullを出力先に指定するとscanfなどで入力した内容が表示されなくなるという噂を聞きました どのように指定すると良いか教えてください >>355 入力した内容なら、必要に応じて"/dev/stderr"(stderr)にでも出力すればいいじゃん。 >>355 scanf を実行する前に標準出力を /dev/null につけかえるのでは、pipe(), pipe2() とかで? >>360 ウイーンドーズにも/dev/nullがあるんですか? 察するに、パスワード入力ではechoさせたくないとかそれ系の話だろ? 普通はtermiosやSetConsoleModeでやることで、標準出力を/dev/nullに付け替えるなんて教えた奴は凄いんだか意地悪なんだか >>363 標準出力のリダイレクトでは、その望みを叶えられないのだが。 凄くも何ともない。 int f(int n) { while (--n) ; return n} がgcc -O2 (4.6.3)で int f(int ) { retunr 0; } のようにコンパイルされました。 この最適化がヒューリスティック(パターンデータベースのようなもの)を使っているのか 知りたいのですが、どのへんを調べればいいのでしょうか? (質問の意図は、自作の最適化器にもこの手の処理をいれたいのですが、 場当たり的に入れるしかないのか、一般的な方法があるのかを知りたいということです。) ただの定数最適化に見える。 あなたのレベルを分かるようにしないと、ドラゴンブック読めとか言われちゃうよ。 すいません。ドラゴンブックは学生時代に買って眺めたことはあります。専攻はコンピュータ科学でした。 コンパイラ関係はあまり深く学ばなかったとの、なにぶん10年以上のブランクがあるので、 どの程度の難しさの問題なのかもわからないのです。 定数最適化、なんでしょうか? while文が終わるとすれば0しかありえないですが、while文の停止性まで最適化器が判断できるのか疑問だったのです。 追伸: int f(int n) { while (n=n-2) {} return n; } main() { f(-2); } とかだとnの偶奇(もっと一般のケースもいけるみたいです)で結果を変えるようです。 -O0 と -O2 で実行時間が全然違ってしまいますが速くなる分にはいいんですよね。 GCCはどうだか知りませんのでドラゴンブックレベルの一般論ですが、 ループ最適化は普通にやるので、条件式は判断します。 制約条件がそこではっきりするので最終的には通常の定数最適化 パスで消えてるんじゃないでしょうか。 ドラゴンブックに書いてなかったっけ? 停止性が判断できるかという疑問ですが、判断できなければ 最適化はやらないということになるはずです。 逆に聞きたいのですが、ヒューリスティックに何かできる んでしょうか? 実行時判断みたいなもの? 前半はなんとなくわかりました。ドラゴンブックは多分実家にあるので参照できませんが、、、 後半ですが、誤用かもしれませんが経験則の意味で使いました。 停止性は当然一般には判断できないので、どんな経験則を使ってるのかな、ってぐらいで、 深い意味はなかったです。 >>365 ブロック内の変数に関数外の部分から影響を受けるかどうか(volatileやrestrictじゃないメモリ参照とか)のフラグを用意して、 外部の影響を受けない変数や定数から構成された条件式は停止時の条件が計算できる可能が高いので最適化を試みるとか。 似たような考え方でブロックが(大域変数などに)副作用を与えるかどうかを判断すれば簡略化やコードの削除ができるんじゃない? >>371 中学生が大好きな架空の生物が掲載された魔導書だよ 恐れおののきつつも憧れを抱き、本棚の奥で埃を被っている一冊 忘れた頃に自分の娘がドラゴンを召喚して世界を崩壊へ誘ったりするアレ >>365 l1: --n; if (n != 0) goto l1; return n; 不変式解析で、 l1: --n; if (n != 0) goto l1; return 0; nの非到達性で、 return 0; libdwarfがELFに依存してて泣ける… Windows(MinGW)だとPE+DWARFだから使えないのが残念 MinGWのobjdump.exeは自力で解析してるから、ソースを参考にすれば なんとかなりそうだけどDWARFの知識が必要になるし… libdwarfをPE対応にしてupstreamにパッチ投げれば 他の人も幸せになれるんでないの 正直libdwarf内で最低限のELFエミュレーションをしようと思ってソース 見たけどめげた…ごめんよ とりあえずobjdump.exeがやってるDWARF解析部分を解析してみるよ それでDWARFになじんだらまたトライしてみたい どうでもいいがCentOS最近入れたらデフォルトではインスコされてないんだな gccのないLinuxなんてLinuxじゃないやい CentOSのGCCは糞古いから最初から入ってなくても問題無い ただ新しいのを入れるには色々手間は掛かる gccとg++は最近不具合があるから、clangに乗り換えることにした。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる