Hacker Newsで話題になっていて知ったのだが、GCCがいつのまにか、C++17の現ドラフトの全コア言語機能を実装している。C++ Standards Support in GCC - GNU Project - Free Software Foundation (FSF) とうとう、なかなか実装されなかったクラステンプレートのコンストラクターからの実引数推定も試すことが出来た。 #include <iterator>template < typename T > struct X { X( T t ) { }template < typenameIterator > X(Iterator first,Iterator last ) { } } ; // deductionguidetemplate < typenameIterator > X(Iterator,
Phoronixで知ったが、Linus TorvaldsがGCC 4.9.0のコード生成にブチ切れている。 問題はLinuxカーネルのload_balance()がランダムにパニックを起こすというもので、その原因は、報告者の使っているコンパイラーであるGCC 4.9.0のコード生成がおかしかったという話だ。Linus様は御自ら生成されたコードを読み給い、平生と変わらぬ調子で物事の道理を示された。Linux-KernelArchive: Re: Random panic in load_balance() with 3.16-rc From:Linus Torvalds Date: Thu Jul 24 2014 - 14:47:25 EST On Wed, Jul 23, 2014 at 6:43PM, Michel DÃnzer <michel@xxxxxxxxxxx> wro
オープンソースで有名なEric S. Raymondが、自由ソフトウェアで有名なRichard Stallmanに、GCCのアンチプラグインポリシーについて突っ込んでいる。 GCCは、長年、コンパイラーのモジュール化を政治的な理由で行っていなかった。もし、例えばパーサーや意味解析だけを分離して使えるようにしたり、内部表現を規格化したりしてしまうと、GCCの一部が、不自由なソフトウェアに取り込まれたり、あるいは不自由なソフトウェアがGCCのプラグインという形で入り込むことになってしまう。これは、利用者の自由を第一とする自由ソフトウェアにとって、悪夢のような未来である。そのような未来を未然に防ぐために、政治的な理由で、GCCのはプラグインに反対するポリシーを採用している。もし、GCCを改良したければ、自由なソフトウェアとなるべきなのだ。そして、GCCのプロジェクトに参加するべきなのだ。 とはい
_FORTIFY_SOURCEというバッファーオーバーフロー攻撃を防ぐのにとても有用なマクロがある。 知らなかった人は以下のmanでもまず見てください http://linuxjm.sourceforge.jp/html/LDP_man-pages/man7/feature_test_macros.7.html _FORTIFY_SOURCE (glibc 2.3.4 以降) このマクロを定義すると、文字列やメモリの操作を行う様々な関数を 使用する際にバッファオーバーフローを検出するための軽めのチェックが 実行されるようになる。すべてのバッファオーバーフローが検出される わけではなく、あくまでよくある例についてだけである。 現在の実装では、以下の関数にチェックが追加されている: memcpy(3), mempcpy(3), memmove(3), memset(3), stpcpy(3),
gccの__attribute__((cleanup(fn))) が便利すぎる件について。C++でコードを書くときは、RAIIとか呼ばれているイディオムを使えば、ご存じの通り、ロックしたmutexを手動で開放する必要もないですし、newしたオブジェクトを手動でdeleteする必要もないです。 void Baz::boo() const { boost::mutex::scoped_lock lock(mutex); // ... return; // lock変数のデストラクタで自動開放。手動での開放不要 }でもC言語だと、当然ながら手動で開放しないといけません。複数箇所でreturnしている場合など、タイプが面倒臭すぎ。 int foo() { pthread_mutex_lock(&mutex); // ... if (hogehoge) { pthread_mutex_unlock
GCC 4.4ぐらいから見たいなのですが、-Qオプションを使うと、 最適化等でどのオプションが有効になるかがわかるみたいです。 具体的には以下のようなコマンドです。 % gcc -O2 -Q --help=optimize # 個々のオプションについて 'enabled' or 'disabled'が確認できるそれで各レベルでの違いを見てみた。 まとめるのが面倒なので以下のようなスクリプトを走らせる #!/usr/bin/envperl use strict; use warnings; my @levels = qw(-O0 -O1 -O2 -O3 -Os); my @base = qw(gcc -- -Q --help=optimize); my %optimize; for my $level (@levels) { my @cmd = @base; $cmd[1] = $leve
5.44 Built-in functions for atomic memory access The following builtins are intended to be compatible with those described in the IntelItanium Processor-specific Application Binary Interface, section 7.4. As such, they depart from the normal GCC practice of using the “__builtin_” prefix, and further that they are overloaded such that they work on multiple types. The definition given in the Intel
ソートが遅くて困っていたので、OpenMPを使ったBitonic Sortを書いたところ、std::sortよりも遅くてショックを受け、インターネットでいろいろ調べていたら、gccだとコンパイラのオプションだけで並列化できることを知りました。 Chapter 18. Parallel Mode g++のオプションに -D_GLIBCXX_PARALLEL -fopenmpをつけると、_GLIBCXX_PARALLELが定義されてstd::sortが__gnu_parallel::sortになり、OpenMPも有効になって並列化されます。コレで十分でした。 試す。 #include <algorithm> #include <vector> #include <iostream> #include <time.h> #include <sys/time.h> #include <assert
GNAT(グナット)は、GCCの一部であるAdaコンパイラ をいう。フロントエンドやランタイム自体もAdaで実装されている。GNATという名称の由来は、当初GNATがAdaからCへのトランスレータとして開発されたため、GNU NYU Ada Translatorと呼称されたためである。 GNATプロジェクトは、Ada 9Xの標準化過程を助成するため、米空軍がニューヨーク大学 (NYU) に対して、1992年よりオープン・ソースのAdaのコンパイラ開発を委託したことに端を発している。同契約では、開発のすべてがGNU GPLであることを要求していた。 1994年には、GNATの開発を継続し商用サポートを行うため、Ada CoreTechnologies社が設立された。この頃よりフロントエンドがAdaで再実装され、GCCの中間形式を生成するコンパイラとなった。なお、GNATの最初の公式コンパイ
以下,エイプリルフールの記事として書いたものなので現代において読む価値はありません. ブログには地震後初めて記事を書く事になって、生存報告としては明らかに遅いですね…。でも、twitterでは元気にやっていました。今は実家にいます。 さて、つい先日東京で言語雑談会というイベントがあって、その折につくばのお家の現状を見て来ました。特別大変な事が起こっていたわけでもなく心底ホッとしました。 その翌日には、彼女と東京は新宿バルト9でサヨナラノツバサを観たのですが、その折にgcc-4.6( http://gcc.gnu.org/gcc-4.6/changes.html )の話がでました。 gccの話が出たのはCランゲッジの話をしていたからなのですが、sequence pointをどうして副作用完了点と訳したのでしょうか、とかそういう疑問が発端だった気がします。 "副作用完了点"を認識した事の無い方
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く