GCC Error Messages
This page has been converted from a Wiki formatted article. If I’ve missed anything in the conversion process, please tell. Sometimes GCC emits something that can be described as Haiku poems – and you have no clue as to what it really is complaining about. This page is a collection of such gems, their meaning in English and how to solve the problem. If you run into an error that you feel belongs h
memcpy 最適化 - kazuhoのメモ置き場
バイト単位でコピーするアホなコードの方が、勝手にベクトル化される分、gcc 内蔵のヤツより最大３倍高速なんだってwww memcpy() compiled with vectorizing compilers All current compilers for linux should support SSE2 auto-vectorization with #include <string.h> void *(memcpy)(void *restrict b, const void *restrict a, size_t n){ char *s1 = b; const char *s2 = a; for(; 0<n; --n)*s1++ = *s2++; return b; }(中略) x86-64 gcc memcpy() (中略) Linking in a user-compiled
yunoの雑記帳 - gcc/attribute
gcc4.1の__attribute__のメモ。 関数属性 † __attribute__((alias("name"))) 関数を他の関数のエイリアスにする。 void foo() __attribute__((alias("bar"))); __attribute__((always_inline)) 最適化がオフのときでも、関数をインライン展開する。 __attribute__((flatten)) 関数のサイズやインライン化パラメータを無視して、常にインライン展開する。 __attribute__((cdecl)) 386専用。 __attribute__((const)) 関数に副作用がなく、戻り値が引数のみに依存すると仮定する。 __attribute__((constructor)) 関数がmainに入る前に自動的に呼ばれるようにする。 __attribute__((dest
関数呼び出し規約(on IA-32)について
Written by Yashiro Takeshi <yashiromann@nifty.com> 2004/1/14 IA-32(x86)上のgccでの関数呼び出し規約について、まとまっている文書がgoogleで検索してもなかなか見つからず苦労したので、他のものと一緒についでにまとめておくことにします。私もよく分かっていないので、何か間違いがありましたら(掲示板でもメールでも)教えてください。 確認の際、抜けがないようにここにも書いておくと、関数呼び出し規約とは、 関数呼び出しの前後で保存されなければならないレジスタ 引数渡しの方法 (ex. レジスタ渡し・スタック渡し・共有メモリ渡し) 引数渡しの順序 関数呼び出し前後でのスタックポインタの保存方法 返り値の戻し方 の全てをあわせたものであって、どれか一つでも曖昧にしてミスしてしまうと思わぬところでエラーが発生してしまいます。(私の
呼出規約 - Calling Convention(コーリングコンベンション)
キーワード C言語, コンパイラ, 引数, 返却値, スタック, スクラッチレジスタ これだけは覚えよう C言語プログラムとアセンブリ言語プログラムをつなげるには、呼出規約を知らないといけない。 呼出規約は、コンパイラ毎に変化する。 関数呼出 C言語やPascalなどの高級言語の多くは、関数を作ることができます。ある程度の処理をひとつの関数(手続き)として分離することで、問題を簡単にしたり、使い回ししやすくしたり、コードの見栄えを良くしたりできます。呼び出す側は処理に必要な情報を与え、呼び出された側は渡された情報のみ(※)を用いて処理を行って答えを返します。 プログラムが計算を行うためには、レジスタを使用する必要があります。しかし、呼出元も呼出先もレジスタを使用するので、そのままではレジスタを取り合ってケンカがおきます。これを調停するのが呼出規約です。 呼出規約の中には、次のような決め事が
初めてのC言語 - 第9回 リンカスクリプト
目的 メモリマップを自分で決めて、リンカスクリプトを(途中まで)記述する メモリマップ これまで普通にC言語を使ってきたときには、OSがありました。第1回の時にもプログラムを動かしていたのはLinuxでした。 プログラムはOSによって、様々なリソース割当を行われます。CPU時間もそのひとつですが、最も重要なのがメモリ割当です。実際にプログラムが使うメモリを予約して、その空間に適切な形でプログラムを読出し、プログラムを実行します。必要に応じてアドレス変換やメモリ保護なども行います。 しかし、この「始めてのC言語」ではOSはありません。メモリ割当は自分で行う必要があります。このメモリ割当を行うために必要なのがリンカスクリプトです。 リンカスクリプトを作る前に、ターゲットコンピュータのメモリマップを知る必要があります。メモリマップとは、どのアドレスに何が置いてあるかの表みたいなものです。今回対象
DWARF Debugging Information Format
Welcome to the DWARF Debugging Standard Website DWARF is a debugging information file format used by many compilers and debuggers to support source level debugging. It addresses the requirements of a number of procedural languages, such as C, C++, and Fortran, and is designed to be extensible to other languages. DWARF is architecture independent and applicable to any processor or operating system.
gcc のデバッグ術
Unix系コマンドラインユーザーのための、 gcc/g++/g77 による開発におけるデバッグ術を簡単に紹介します。 以下の内容は gcc 2.7.2.3 での動作は確認しています。 g++/g77 でも恐らくは通用すると思うのですが、 ひょっとすると異なる部分があるかもしれません。 筆者は g++/g77 の使用経験がないので、その場合は御容赦を願います。 実行前 キーワード「コンパイルオプション, -Wall, -O2, -O4」 まずは gcc にオプション opt'-Wall' を付けてコンパイルし、 警告がなくなるまでソースを修正します。 これは 常識 です。 次に opt'-O4 -Wall' でコンパイルします。 「未初期化変数の使用」の警告 (`foo' might be used uninitialized in this function) は、 opt'-O4' を付
J (2006-08-08)堕落したCプログラマのレベル10
「偽札対応済み」って書いてある両替機。 川口市立中央図書館…本屋の上にある図書館。に行ってきた。特に何もないけど。あと、マイコンショップ川口つぶれてた。 ある程度能力を持ってるなら、成果を残せるか残せないかは自信を持ってるか持ってないかの違いだけかもしれないというような話。 最近思うのだけど、使えない奴（例えば、僕のような）の特徴として、「どうせ自分が何をどうやっても、何もどうにもならない」的な思考があると思う。 例えば、上の一行で言うと、「使えない奴（例えば僕」とか、そういったような思考。 こういった思考は、いったん根付いてしまうと、循環するので、なかなかやめられない。「どうせ自分は何もできないんだ→何もできないから何もやらない→何も成果を残せない→どうせ自分は何もできないんだ」とかいった感じで。 矯正しようと思っても、「いや、こういう性格だから、矯正は無理だし。」と、いう思考になってし
組込み技術者向け「初めてのC言語」
注意 : このページはC言語初心者向けではなく、組込み開発初心者を対象としています。理解には、C言語に関する十分な知識 および 組込み機器開発に関する多少の知識を必要とします。 このページは、これまで避けて通ってきたC言語の嫌な部分と直面し、C言語プログラマとしての自立を促すモノです。C言語の本質が知りたい方や、ちゃんとした資料をお探しの方はお勧めしません。また、「初めてのC言語」というタイトルは、「C言語を初めてやる」という意味ではありませんので、C言語がわからない方はご遠慮ください。ターゲットはIntelでもWindowsでもLinuxでもありません。聞いたこともないようなプロセッサが相手です。 スポラディック連載なので、作者にひまが出来次第追加していきます。 第一部 - 初めてのHelloWorld この章では こんなこと やります
HackingWithGnu - enbug.org
はっきんぐ・うぃず・ぐにゅー GNU を使って開発しようっていう不定期な連載です。 いつ書かれるかも分からないし、いつ終わるかも、いつ改訂されるかも不明です。 もちろん、ここは全然公式なページじゃありません。 嘘は出来る限り書かないように努力しますが、絶対信頼してはいけません。 これらは、かなり昔に私自身が執筆していた記事を掘り返した物です。 古くなって、現状に当てはまらない部分を更新していますが、十分ではないかもしれません。 第一回 GNU C の書き方 (1) 第二回 GNU C の書き方 (2) 第三回 GNU C の書き方 (3) 第四回 GNU Make の初歩 第五回 GNU Automake の概要 第六回 GNU Autoconf (1) 第七回 GNU Autoconf (2) 第十二回までありますよ...
J
Cで汎用ライブラリをつくってると、void*の嵐になって型安全が無くなると思う。 ちょっとした手間で、それをなんとかする話。 struct varray { int nelem; void *values; }; #define VSET( t, a, i, e ) (((t*)a##t.values)[i] = e) #define VDECL( t, name ) struct varray name##tこんなふうにして。 int main() { VDECL( int, a ); VSET( int, a, 0, 4 ); }こんなふうにする。 変数宣言がちょっとキモくなるのと、配列アクセスが、キモくなる。のと、配列アクセスするときに型の名前がいる。 のだけど、 int main() { VDECL( int, a ); VSET( float, a, 0, 4.0 ); }こうい
ホワット・ア・ワンダフル・ワールド 現状，最も DSL が作りやすい汎用言語は, L ナントカでも H ナントカでも無く，実は GCC なのではないか ?
最上の日々 06年12月 24日（日） ▼ DSL（ドメイン特化言語）というのは拡張され続けた結果として、かならず汎用言語になってしまうものだ。けど、最初から計画されていた訳ではないから、汎用言語にとって大事な首尾一貫性にはこういう調子で欠けることに必ずなってしまう。これをさけるためにはどうしたら良いだろうか。 すでに出来てしまった物は仕方ないけど、これからDSLを作ろうと言う人は、新たにDSLを作るのはやめて汎用言語のサブセットにする方が良いと思う。そうして将来の拡張に備えるという方法論をとったら良いと思う。 DSLは汎用言語よりもドメイン内では簡潔に書ける言うけど、大抵それは、ドメインに特化したデータ構造とライブラリのおかげでだと思う。文法などが寄与している場合は困るけど、私の感じではそれほど多くは無いと思う。（ユーザが新しい型を定義できて演算子などをオーバーロードできる汎用言語で無く
WhirlwindTutorialOnCreatingReallyTeensyElfExecutablesForLinux -
WhirlwindTutorialOnCreatingReallyTeensyElfExecutablesForLinux - 目次 Linux で動く極小 ELF 実行ファイルをつくる怒涛のチュートリアル (あるいは "Size Is Everything") コメント 以下の文章の日本語訳です: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html gcc の info の日本語は以下のページから拝借しました: http://www.asahi-net.or.jp/~wg5k-ickw/html/online/gcc-2.95.2/gcc_2.html#SEC13 Linux で動く極小 ELF 実行ファイルをつくる怒涛のチュートリアル (あるいは "Size Is Everything") She studied
いやなブログ: Linux の共有ライブラリを作るとき PIC でコンパイルするのはなぜか
Linux の共有ライブラリを作るとき PIC でコンパイルするのはなぜか 通常、Linux の共有ライブラリを作るときは各 .c ファイルを PIC (Position Independent Code) となるようコンパイルします。しかし、実は PIC でコンパイルしなくても共有ライブラリは作れます。それでは PIC にする意味はあるのでしょうか。 さっそく実験してみます。 int func () { printf(""); printf(""); printf(""); } PIC でコンパイルするには gcc に -fpic または -fPIC を渡します。-fpic の方が小さく高速なコードを生成する可能性がありますが、プロセッサによっては -fpic で生成できる GOT (Global Offset Table) のサイズに制限があります。一方、-fPIC はどのプロセッサで
ライブラリの外に公開するシンボルを制限する - bkブログ
ライブラリの外に公開するシンボルを制限する C言語にはファイル内 (コンパイル単位) からしかアクセスできない static 関数と、別のファイルからもアクセスできる非static 関数があります。しかし、ライブラリを作成する上では、この2つのスコープだけでは不十分なときがあります。 本記事では GNUの開発環境において、ライブラリの外に公開するシンボルを制限する方法を紹介します。 次のような例を考えてみます。 % cat a.c // foo() は libfoo の主役の関数なので公開したい void foo() { bar(); } % cat b.c // bar() はライブラリの中だけで使われるべきなので本当は公開 // したくない。しかし別のファイルに含まれる foo() から使われ // ているので、非staticにせざるをえない void bar() { } このようなコ
GCC の最適化で printf が puts になる場合 - bkブログ
GCC の最適化で printf が puts になる場合 GCC の最適化により printf の呼び出しが puts に置き換わることがある、と 先日、教えてもらったので試してみました。 次のような hello.c をまず最適化なしでコンパイルします。 #include <stdio.h> int main () { printf("hello, world\n"); return 0; } % gcc -o hello hello.c そして、実行可能ファイル hello を readelf コマンドで覗いてみると、 printf という文字列が見つかります。 puts は見あたりません。 % readelf -a hello | egrep 'printf|puts' 080495d0 00000207 R_386_JUMP_SLOT 00000000 printf 2: 0000
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
¢°¨«°¢(£°«) - val it : α → α = fun
組み込み向けクロス開発環境の構築
Infoseek[インフォシーク] - 楽天が運営するポータルサイト![Infoseek[インフォシーク] - 楽天が運営するポータルサイト](https://cdn-ak-scissors.b.st-hatena.com/image/square/67a82fbafb5e06f77d53cedfd9ceb7f789258213/height=288;version=1;width=512/https%3A%2F%2Fimage.infoseek.rakuten.co.jp%2Fcontent%2Ftop-ajax%2Fmobile%2Flogo.png)
