C言語なら俺に聞け 147

**デフォルトの名無しさん** · 2018/08/16(木) 23:36:02.22

C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

C99
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
http://kikakurui.com/x3/X3010-2003-01.html

C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/

JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/

前
C言語なら俺に聞け 146
https://mevius.5ch.net/test/read.cgi/tech/1525031257/

**デフォルトの名無しさん** · 2018/09/08(土) 10:29:17.43

>>829
ぷろぐらみんぐのまえににほんごをがんばれ

**デフォルトの名無しさん** · 2018/09/08(土) 10:29:54.08

業務に関係なく完全に知的好奇心からのmalloc実装の想像だったので、やっぱりglibc読んでみよう。
色々レスくれた人、ありがとう。

**デフォルトの名無しさん** · 2018/09/08(土) 10:38:55.04

ファイルシステムの管理領域が大きくなりすぎて、
4KB以下のページサイズには出来ない

4MBで千個、4GBで百万個のページを管理しないといけないから、
管理領域だけでも、100MB以上になる

だから、ページサイズをもっと大きい、2MBにすると、
2GBで千個、2TBで百万個のページを管理できるから、今のHDD の容量に対応できる

**デフォルトの名無しさん** · 2018/09/08(土) 10:43:05.81

HDDだとシリンダ容量との親和性を考えないとね
だけどSSDが普及してる今どきの事情だとどうなんだろう

**デフォルトの名無しさん** · 2018/09/08(土) 10:55:59.74

>>833
> 4MBで千個、4GBで百万個のページを管理しないといけないから、
> 管理領域だけでも、100MB以上になる

管理領域ってどう計算してるの？

**デフォルトの名無しさん** · 2018/09/08(土) 10:58:20.45

一領域当たり100byte

**デフォルトの名無しさん** · 2018/09/08(土) 11:02:40.38

>>836
すまん、聞き方がアホだった
その1領域が100Byteになる理由を聞きたかった

**デフォルトの名無しさん** · 2018/09/08(土) 11:31:35.27

>>833
つHugePage

**デフォルトの名無しさん** · 2018/09/08(土) 16:08:33.18

utf8procというUnicodeライブラリを使いたいのですが、C99に準拠してるかどうかって分かりますか？
「emulate C99 bool」というコメントがソースコードにあったのでおそらくC89あたりからサポートしていると思うんですが。
https://github.com/JuliaStrings/utf8proc

**デフォルトの名無しさん** · 2018/09/08(土) 17:17:58.22

>>839
C99に準拠している
そのコメントの少し前に
「MSVC prior to 2013 lacked stdbool.h and inttypes.h」ってコメントがあるからWindowsの古い環境のためにboolとかを定義しているだけだね

**デフォルトの名無しさん** · 2018/09/08(土) 18:36:43.66

OSのすべての機能を学びたいなら、ムック本の
Linuxエンジニア養成読本、第3版、2016

カーネル、起動処理、仮想記憶、
ファイルシステム、シェルスクリプトなど

ファイルシステム・管理領域の仕組みなどを読んで

**デフォルトの名無しさん** · 2018/09/08(土) 18:44:21.19

タネンバウム先生の本でしょ
すごい弟子を育てた伝説の師匠

**デフォルトの名無しさん** · 2018/09/08(土) 18:49:46.85

なにそれ、すごい面白そう！
アラサーだけどまだまだ青二才だしとっても勉強になります！

**デフォルトの名無しさん** · 2018/09/08(土) 19:31:07.27

>>841
>>837にレス頼む

**デフォルトの名無しさん** · 2018/09/09(日) 05:27:49.39

>>840
ありがとうございます！
これでUnicodeが古い環境で心置きなく使えますわ。

**デフォルトの名無しさん** · 2018/09/09(日) 14:54:16.40

ここのスレの人はValgrindは
使っているんだろうか。
メモリリークとか考えれば
ぜひ使うべきツールだと思う。
https://qiita.com/tjun/items/e9d2f7da3c94eb0240d8

**デフォルトの名無しさん** · 2018/09/09(日) 15:31:42.46

便利だよね
ただ役に立ってるときはクソコードを触ってるときでもあると思う

**デフォルトの名無しさん** · 2018/09/09(日) 15:44:39.72

変数中の "1" のビット数を数える効率的方法ありますか？
aが32ビットとして
for (i = 0; i < 32; i++) {
j = j + a & 1;
a = a >> 1;
}
みたいに1ビットずつカウントするしかないでしょうか
あるいは、8bitとかで区切ってテーブルを引いて加算とかでしょうか(16ビットや32ビットのテーブルは現実的でないので)

**デフォルトの名無しさん** · 2018/09/09(日) 15:50:52.78

a=(a&0a55555555)+(a>>1&0a55555555);
a=(a&0a33333333)+(a>>2&0a33333333);
a=(a&0a0F0F0F0F)+(a>>4&0a0F0F0F0F);
a=(a&0a00FF00FF)+(a>>8&0a00FF00FF);
a=(a&0a0000FFFF)+(a>>16&0a0000FFFF);

**デフォルトの名無しさん** · 2018/09/09(日) 15:53:41.89

a = (a & 0x55555555) + (a >> 1 & 0x55555555);
a = (a & 0x33333333) + (a >> 2 & 0x33333333);
a = (a & 0x0F0F0F0F) + (a >> 4 & 0x0F0F0F0F);
a = (a & 0x00FF00FF) + (a >> 8 & 0x00FF00FF);
a = (a & 0x0000FFFF) + (a >> 16 & 0x0000FFFF);

**デフォルトの名無しさん** · 2018/09/09(日) 16:07:17.49

32ビットだしその書き方良くないと思います

**デフォルトの名無しさん** · 2018/09/09(日) 16:54:40.77

https://ideone.com/FGqs1S
なにも問題ない
ﾚｽをｺﾋﾟﾍﾟで普通に動く

ｱﾎがいちいち車輪の再発明するよりとりあえず↓ｺﾚ使っとけば間違いない
http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
Built-in Function: int __builtin_popcount (unsigned int x)
　Returns the number of 1-bits in x.
Built-in Function: int __builtin_popcountl (unsigned long)
　Similar to __builtin_popcount, except the argument type is unsigned long.
Built-in Function: int __builtin_parityll (unsigned long long)
　Similar to __builtin_parity, except the argument type is unsigned long long.

**デフォルトの名無しさん** · 2018/09/09(日) 17:39:09.00

>>847
自作ツールで無茶苦茶
役に立ってしまった。
そうか、クソコードだったかw

それはさておき今回の発端>>757は、
メモリリークなんか気にしはじめたら
修正コストがどれくらいかかるか
わからない、それだったら現状で
問題は表面化してないし、
そのままでいいじゃん、みたいな
状況だと思う。

Vargrindを導入して
手軽にメモリリークを
チェックできれるようになれば、
上司にもとりあえず直しましょう
という説得ができる
チャンスもあるかも。

**デフォルトの名無しさん** · 2018/09/09(日) 17:57:06.08

>>850
うまいやり方だなぁ

**デフォルトの名無しさん** · 2018/09/09(日) 17:57:22.00

>>850 この式は初めて見ると訳の分からない呪文みたいだけど、
落ち着いて考えると分割統治の技法を並列処理してるんだよね。
これで1の立ってるビットの数が分かる理由を考えるのは良い教材かと。

**デフォルトの名無しさん** · 2018/09/09(日) 18:06:01.01

>>850
少なくとも最後の行だけは
a = (a + (a >> 16)) & 0x0000FFFF;
の方がよさそう。
正確には最大 32 にしかならないから & 0x0000001F でもよさそうだし、値の上限を考えながらだと途中の行ももう少し演算を減らせたりするかも？

**デフォルトの名無しさん** · 2018/09/09(日) 18:06:59.52

>>856
0x0000003F だったw

**デフォルトの名無しさん** · 2018/09/09(日) 20:35:00.38

>>850
a = (a & 0x55555555) + (a >> 1 & 0x55555555);
a = (a & 0x33333333) + (a >> 2 & 0x33333333);
a = (a + (a >> 4)) & 0x0F0F0F0F0F;
a += a >> 8;
a = (a + (a >> 16)) & 0x3F;

でも同じ結果が得られた。
最適化無しだと 9% くらい速くなった。

**デフォルトの名無しさん** · 2018/09/09(日) 20:36:22.47

>>858
0F 多すぎw
0x0F0F0F0F ね

**デフォルトの名無しさん** · 2018/09/09(日) 21:00:45.14

しね

**デフォルトの名無しさん** · 2018/09/09(日) 21:13:17.93

a = (a & 0x55555555) + (a >> 1 & 0x55555555);
a = (a & 0x33333333) + (a >> 2 & 0x33333333);
a = (a + (a >> 4)) & 0x0F0F0F0F;
a = (a * 0x101 * 0x10001) >> 24;

にしたら >>850 より 24% 速くなった(pentiumM linux)。
でも gcc の速度最適化を入れるとどれも変わらないね。

**デフォルトの名無しさん** · 2018/09/09(日) 21:19:41.88

なに１人ではしゃいでんのこいつ。

**デフォルトの名無しさん** · 2018/09/09(日) 21:28:41.02

CPUにそういう命令なかったっけ？
使うところでは割と使いそうだけど

**デフォルトの名無しさん** · 2018/09/09(日) 21:45:09.16

>>863
AlphaとかM16Cとか古いCPUにはあった気がする。
最近はあんまり見ないね。

**デフォルトの名無しさん** · 2018/09/09(日) 21:54:33.81

ああ、SSEにpopcntがあるね

**デフォルトの名無しさん** · 2018/09/09(日) 22:32:42.62

ポックント

**デフォルトの名無しさん** · 2018/09/10(月) 02:37:34.95

ビットを数える・探すアルゴリズム
http://www.nminoru.jp/~nminoru/programming/bitcount.html

**デフォルトの名無しさん** · 2018/09/10(月) 10:36:25.17

ビット数の数えあげが欲しくなるのってパリティチェックで末尾付加したりするとき？

**デフォルトの名無しさん** · 2018/09/10(月) 10:44:53.73

ソケットみたいにフラグをビット管理してるときとかもほしくなるかな

**デフォルトの名無しさん** · 2018/09/10(月) 10:56:31.39

符号とか暗号とかの世界ではしょっちゅう使うよ。
1の数で最適なアルゴリズムが変わるってケースもあるし、
暗号にサイドチャネル攻撃仕掛けるにはハミング距離とか重要。

**デフォルトの名無しさん** · 2018/09/10(月) 11:27:01.59

>>870 はなんとなく理解できるけど　>>869 のほうは想像がつかないな
ﾋﾞｯﾄ管理されたﾌﾗｸﾞと ONしてるﾋﾞｯﾄ数による分岐や演算法が変わるのが直結しない感じ

**デフォルトの名無しさん** · 2018/09/10(月) 11:51:19.73

フラグは数えねえよな
性能重視でもなければビットフィールド使って読みやすくして欲しいわ

**デフォルトの名無しさん** · 2018/09/10(月) 11:54:23.84

バラで書くから読みにくいのであって
関数にしておけば外から見た仕様は変わらない

**デフォルトの名無しさん** · 2018/09/10(月) 12:16:32.03

普通の通信でエラー検出以外の目的でビット数を数える必要性がわからない。
そんな特定のCPU以外は必ず無駄な計算が必要になる方式をなぜ使う？

**デフォルトの名無しさん** · 2018/09/10(月) 12:46:33.22

>>874
エラー検出、訂正目的以外の通信のためにビットの数え上げするって誰かレスしてたっけ？

**デフォルトの名無しさん** · 2018/09/10(月) 15:09:59.53

>>875
>>869はそうではないのか？ならば居ないな。

**デフォルトの名無しさん** · 2018/09/10(月) 19:25:38.98

>>821
んーこの文章読むと、よく教科書的な本に書かれてる関数に対してexternを書きましょうってのは冗長で不要って話なのね。確かに実際の動きとは合うし勉強になりました。

>>822
書いてる意図を汲めてるのか自信ないけど、他のサイトにもリンカ依存とあって、この話が全ての環境に対して正しい話なのか･･･若干不安はある感じ？

**デフォルトの名無しさん** · 2018/09/10(月) 19:32:05.94

Common Lisp にビットを数える関数があるけどcでも同様のものがあったようなゔ

**デフォルトの名無しさん** · 2018/09/10(月) 20:00:47.59

int a=0;

printf("%p"　,a);

printf("%p",&a);

同じアドレスが表示されると思っていたのですが、上下で違う数字が出力されました。
アドレスを表示するのはどちらが正しいのでしょうか？
よろしくお願いします。

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2018/09/10(月) 20:06:35.73

下。

**デフォルトの名無しさん** · 2018/09/10(月) 20:07:47.31

>>879
&a の方。

ていうか同じになるわけがない。片方は printf() に a の内容である 0 を渡しているんだから。

**デフォルトの名無しさん** · 2018/09/10(月) 20:26:02.04

%p は　ポインタを要求しているが
ポインタのサイズと intのサイズが違ってたら　鼻から悪魔

**デフォルトの名無しさん** · 2018/09/10(月) 20:28:01.62

>>880
>>881
>>882

指定子Ｐで＆が付いてない方も変換されると思っていました。
ただの数値が表示されるだけなんですね。

int *a;
int b=0;

a=&b;

printf("%p",a);
この場合は＆が付いてなくてもアドレスを渡してるのでｏｋなんですね。

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

**デフォルトの名無しさん** · 2018/09/10(月) 20:29:18.90

天文学的な値が出るかも知れんね

**デフォルトの名無しさん** · 2018/09/10(月) 20:30:01.84

>>883
そうそう。そういうこと。

**デフォルトの名無しさん** · 2018/09/10(月) 20:43:33.30

>>869
それはどっちかって言うとビットサーチだね
68020 とかの BFFFO 命令とか

**デフォルトの名無しさん** · 2018/09/10(月) 21:01:01.97

https://ideone.com/bsjclG

また、低学歴知恵遅れのｸﾙｸﾙﾊﾟｰがｳｿ書いてるわ。。。
64bitのｱﾄﾞﾚｽ空間を持ってて、intのｻｲｽﾞが32bitならちゃんと動くﾜｹがないからな

**デフォルトの名無しさん** · 2018/09/10(月) 21:07:42.09

>>887
どの書き込みに対してのレス？

**デフォルトの名無しさん** · 2018/09/10(月) 21:11:41.72

>>887
これまたチンケな知識でマウント取りに来たな w

**デフォルトの名無しさん** · 2018/09/10(月) 21:12:59.71

ID:WGo2tHWR　←　ｺｲﾂにきまってんだろ

なあにが

　そうそう。そういうこと。

だ

なにも知らないﾑｸなﾔﾂ相手に
低学歴知恵遅れの分際でﾃｷﾄｰなことばっかり書き込んでる

**デフォルトの名無しさん** · 2018/09/10(月) 21:16:56.02

ん？これのこと？
> printf() に a の内容である 0 を渡している

**デフォルトの名無しさん** · 2018/09/10(月) 21:19:04.26

こんなにでかい釣り針だと
鯨が釣れるかも

**デフォルトの名無しさん** · 2018/09/10(月) 21:19:36.92

>>883　←　ﾑｸな初心者
>>885　←　低学歴知恵遅れ　ID:WGo2tHWR 「そうそう。そういうこと。」　←　ｺﾚのｺﾄだ

低学歴知恵遅れはﾚｽもおえないの？

**デフォルトの名無しさん** · 2018/09/10(月) 21:21:51.21

あれ？
int *a;
int b=0;
a=&b;
printf("%p",a);
って別に正しくね？

**デフォルトの名無しさん** · 2018/09/10(月) 21:22:53.59

https://ideone.com/bsjclG

この処理結果みても分からないなら
ｵﾂﾑに相当な問題がある

**デフォルトの名無しさん** · 2018/09/10(月) 21:25:52.44

ううむ、俺にはaは64ビット環境だと64ビット長に見えるのだが違うのか？

**デフォルトの名無しさん** · 2018/09/10(月) 21:27:36.20

で、処理結果みた？
で、処理結果みた？
で、処理結果みた？

**デフォルトの名無しさん** · 2018/09/10(月) 21:29:43.88

おたくのサンプルは64ビットアドレスをintにキャストしちゃてるやん。そりゃ実行結果違うわ。

**デフォルトの名無しさん** · 2018/09/10(月) 21:31:35.87

https://ideone.com/PGwK6j
ｷｬｽﾄはずしたったぞ
当然、結果はかわらない

やっぱりなこの板は低学歴知恵遅れしかいない
この程度のこともわからずにいきってﾚｽしてるﾜｹだからな

**デフォルトの名無しさん** · 2018/09/10(月) 21:31:51.59

たまたま　足りない分 0 を引っ張ってきてるけど（レジスタで渡ったから？）
スタックに積んでるリターンアドレスの一部から足りないのを補ってると、もっとわけわかな数値に
未定儀の挙動を推測すすのもまたオツなもの　か

**デフォルトの名無しさん** · 2018/09/10(月) 21:32:51.39

いやいや、883のaはポインタなんだってw
なんでintに入れちゃうのw

**デフォルトの名無しさん** · 2018/09/10(月) 21:33:36.29

そんなことｵﾚのしったことじゃないからな

　>>883　←　ﾑｸな初心者
　>>885　←　低学歴知恵遅れ　ID:WGo2tHWR 「そうそう。そういうこと。」　←　ｺﾚのｺﾄだ

低学歴知恵遅れはﾚｽもおえないの？

**デフォルトの名無しさん** · 2018/09/10(月) 21:40:38.56

半角クンていつも周りを見ずに自分の思い込みだけでレスしちゃって誤り訂正できないから、恥ずかしい(*/□＼*)

直進しかできない目隠しされたイノシシみたい

**デフォルトの名無しさん** · 2018/09/10(月) 21:42:09.42

なにが間違いなわけ
指摘してみ

一切間違ったこと書いてないからな
低学歴知恵遅れはそもそも認知能力に問題がある

**デフォルトの名無しさん** · 2018/09/10(月) 21:47:36.63

なぜ64ビットポインタをintに入れたの？
883ではそんなこと一切してないんだけど。

逆に
>printf() に a の内容である 0 を渡している
は整数リテラルがintなのに%pで受けてるので、64ビット環境なら4バイト分スタックのゴミを拾ってきそうだけど。

**デフォルトの名無しさん** · 2018/09/10(月) 21:48:46.40

はずかしくなって
こっち側にこようとしても
もう手遅れだからな

**デフォルトの名無しさん** · 2018/09/10(月) 21:50:57.43

なんだ、結局はaがポインタだってことを見逃しただけかよw

**デフォルトの名無しさん** · 2018/09/10(月) 21:55:18.07

>>906
つ鏡

**デフォルトの名無しさん** · 2018/09/11(火) 00:11:24.08

>>887
>>883はちゃんと動くよ。

**デフォルトの名無しさん** · 2018/09/11(火) 06:35:01.60

>>909
半角野郎が数行のプログラムも理解できないくせに自分で改竄したコードが動かねぇって騒いでただけ。
半角野郎こそ低学歴知恵遅れクルクルパーで認知能力とオツムに相当な問題があるってことが証明されただけなので気にするな。
本人は顔真っ赤にして逃げたみたいだけど。

**デフォルトの名無しさん** · 2018/09/11(火) 07:57:47.34

ポインタを受け取るべき%p変換指定子に、ポインタでない値を与えることの
危険性は >>882 ですでに指摘されてるのに、後乗りで書いた >>887 で
こんだけ引っ張れるのは、ある意味で才能かもな。

汚い言葉遣いを我慢しながら拝聴するほど啓蒙的な内容でもないし。

**デフォルトの名無しさん** · 2018/09/11(火) 08:11:06.15

>>911
半角クンのレスは、5%の真実と15%の間違い・思い込みと80%の繰り言・罵詈雑言でできてるからね。まっとうに読む価値はない。

**デフォルトの名無しさん** · 2018/09/11(火) 09:54:24.68

まれにいいこと言う
850とか

**デフォルトの名無しさん** · 2018/09/11(火) 10:00:02.68

釣り針が大きすぎて、クジラじゃないと釣れない

**デフォルトの名無しさん** · 2018/09/11(火) 11:44:57.89

musl-libcのiconvコマンドの本体ってここを見ればいいよね？
https://git.musl-libc.org/cgit/musl/tree/src/locale/iconv.c

**デフォルトの名無しさん** · 2018/09/11(火) 20:05:08.62

処理系って何？
cpuかコンパイラの事かなと思ってるんだけど。
間違ってる？

**デフォルトの名無しさん** · 2018/09/11(火) 20:29:34.46

処理系は、翻訳環境と、実行環境に大別される
翻訳環境とはコンパイラ等開発ツールを実行する環境
実行環境とはコンパイル結果のバイナリが稼働する環境、客先と言ってもよい

**デフォルトの名無しさん** · 2018/09/11(火) 20:36:50.64

>>917
バイナリが稼働する環境はcpuってことかな
どうもお世話になりました

**デフォルトの名無しさん** · 2018/09/11(火) 20:45:37.73

cpuだけじゃないメモリが実装されているアドレス
i/oが実装されているアドレス
osの挙動
など様々な要因が絡む

**デフォルトの名無しさん** · 2018/09/11(火) 21:01:49.97

CPUが同じであっても、
Windowsでは動かせてもmacOSでは動かないとか
同じWindowsでも、64bit環境では動いても32bit環境だと動かないとか

**デフォルトの名無しさん** · 2018/09/11(火) 21:12:52.13

半角くん、いたの?
lynx で見てるから何言ってるかわからない。

**デフォルトの名無しさん** · 2018/09/11(火) 21:17:38.28

ゴミPC早く捨てろ

**デフォルトの名無しさん** · 2018/09/11(火) 21:28:47.48

処理系ってC99に関してはJISで定義されてたよね。

**デフォルトの名無しさん** · 2018/09/13(木) 21:21:47.72

昔の教科書には
C言語の原稿
↓プリプロセッサ
マクロ・ヘッダファイルが展開された原稿
↓翻訳機
アセンブリ言語の原稿
↓アセンブラ
機械語
↓リンカ
実行可能ファイル

っていう図がよく描かれてて，今でもWebを検索するとよく見掛けるんだけど，ほんとに今現在のコンパイラってこういうことやってんの？
gccやclangって，もはやC言語の原稿からほぼほぼ直接に実行可能ファイルを生成してるんじゃない？
さすがにプリプロセッサくらいはあるかもしれんが。

**デフォルトの名無しさん** · 2018/09/13(木) 21:32:27.37

-vつけて起動してみ。
プリプロcppはcc1に統合された。
gccだと、cc1とかasとかcollect2とかが動いてるはず。
clangはデフォルトだとasなしかも。

**デフォルトの名無しさん** · 2018/09/13(木) 21:54:33.53

>>925
あざす
やっぱり減ってはいるんだな。
結構ああいう図を見掛けるんで，なんか（ほんとにこんな段階踏んでんのか？）ってモヤモヤしてた。
素人考えだが，あんな風に幾つも重ねてビルドしてたら最適化しにくい気がするし。

**デフォルトの名無しさん** · 2018/09/13(木) 22:33:23.35

処理としてはわかれてるよそりゃ

**デフォルトの名無しさん** · 2018/09/13(木) 23:18:13.03

えそうなん
と思って空のファイルをgcc -vで処理したら
たしかにある程度進んでリンカの段階でエラーになったわ。

**デフォルトの名無しさん** · 2018/09/13(木) 23:28:49.69

bash-4.3$ gcc -v -o aho aho.c　←開始
/usr/lib/gcc/i586-slackware-linux/5.3.0/specs から spec を読み込んでいます
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i586-slackware-linux/5.3.0/lto-wrapper
ターゲット: i586-slackware-linux
configure 設定: ../gcc-5.3.0/configure --prefix=/usr --libdir=/usr/lib --mandir
=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap --enable-langu
ages=ada,c,c++,fortran,go,java,lto,objc --enable-threads=posix --enable-checkin
g=release --enable-objc-gc --with-system-zlib --with-python-dir=/lib/python2.7/
site-packages --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=gcc4-com
patible --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --
enable-lto --disable-install-libiberty --with-gnu-ld --verbose --enable-java-ho
me --with-java-home=/usr/lib/jvm/jre --with-jvm-root-dir=/usr/lib/jvm --with-jv
m-jar-dir=/usr/lib/jvm/jvm-exports --with-arch-directory=i386 --with-antlr-jar=
/root/slackware-current/source/d/gcc/antlr-runtime-3.4.jar --enable-java-awt=gt
k --disable-gtktest --with-arch=i586 --target=i586-slackware-linux --build=i586
-slackware-linux --host=i586-slackware-linux
スレッドモデル: posix
gcc バージョン 5.3.0 (GCC)
（-続く-）

**デフォルトの名無しさん** · 2018/09/13(木) 23:29:23.47

（-続き-）
COLLECT_GCC_OPTIONS='-v' '-o' 'aho' '-mtune=pentium' '-march=i586'
/usr/libexec/gcc/i586-slackware-linux/5.3.0/cc1 -quiet -v aho.c -quiet -dumpba
se aho.c -mtune=pentium -march=i586 -auxbase aho -version -o /tmp/ccVi37md.s ← ①ﾌﾟﾘﾌﾟﾛｾｽ
GNU C11 (GCC) version 5.3.0 (i586-slackware-linux)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version 3.1.4, MPC
version 1.0.3
warning: GMP header version 6.1.0 differs from library version 6.1.2.
GGC heuristics: --param ggc-min-expand=63 --param ggc-min-heapsize=62246
存在しないディレクトリ "/usr/lib/gcc/i586-slackware-linux/5.3.0/../../../../i58
6-slackware-linux/include" を無視します
#include "..." の探索はここから始まります:
#include <...> の探索はここから始まります:
/usr/lib/gcc/i586-slackware-linux/5.3.0/include
/usr/local/include
/usr/lib/gcc/i586-slackware-linux/5.3.0/include-fixed
/usr/include
探索リストの終わりです。
（-続く-）