レスありがとう！

んでも
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 だろｊｋ

あと、もし 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が配布されているのでそれを使う。

最初のGCCはCで書かれていたわけでは無いらしい

ネタじゃないので聞いてください。
一番最初のccはどのようにコンパイルされたのですか？

最初のコンパイラは機械語で書いた

最初のコンパイラはA-0 Systemらしい。

gccをどうやってコンパイルするかを勉強してると
そのあたりまで平然と遡らされるよな

Z80アセンブラをN88-BASICで実装しようとしたのは良い思い出…

>>311
> 一番最初のccはどのようにコンパイルされたのですか？
当時一般的に使われていた, Unix 上の PCC 互換コンパイラでコンパイルされたんだが，
なんか問題あるの?

>>316
どこまで遡れるか大会だろ空気嫁よ

ネタじゃないので聞いてください。
一番最初のアセンブラはどのようにアセンブルされたのですか？

ネタじゃないならアセンブラスレで訊きましょう

２ｃｈは優秀な技術者が議論する場所

>>318
ハンドアセンブル

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 は試してみましたが、ダメでした。

man(2)

lint

>>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 コンパイルしたけど、エラーが２つでてインスコできんわ・・ｏｒｚ

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の使い方の質問ここでしたらスレチですか？

profとかcovはいいんじゃない?

ではお言葉に甘えて。
カバレッジを調べるため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ヶ月くらいプラグマバグでビルド出来なかったんだけどようやく修正された