メッセージに色を使用。WHENにより色使用時を指定 WHEN に指定可能な値 : 「never」「always」「auto」 色の値は環境変数GCC_COLORSで定義
メッセージに色を使用。WHENにより色使用時を指定 WHEN に指定可能な値 : 「never」「always」「auto」 色の値は環境変数GCC_COLORSで定義
#include <stdio.h> int main(void) { int n = 123456; char c1[5]; char c2[11]; char c3[12]; /* 出力の切り捨てが発生する可能性が無い関数呼び出し */ snprintf(c1, 5, "test"); printf("%s\n", c1); /* 出力の切り捨てが発生する関数呼び出し */ snprintf(c1, 5, "test\n"); printf("%s\n", c1); /* 生成される文字列長が最小でも出力の切り捨てが発生する関数呼び出し */ snprintf(c1, 5, "test%i", n); printf("%s\n", c1); /* 変数の値次第では出力の切り捨ての可能性が有る関数呼び出し */ snprintf(c2, 11, "%i", n); printf("%s\
VSCodeを使ってWindowsからLinuxアプリのデバッグ その1 目次: Linux その1、その2 同じことをしている人があまり居なさそうだったので、メモしておきます。 きっかけはGCCのコードをGDBのCUIモードで追っていて辛くなったことです。GCCのコードは超ぐちゃぐちゃの悲惨なコードで非常に追いづらく、GDBをもってしても何が起きているのか把握するのは困難です。せめてデバッガの画面くらいはGUIにして、見やすくできないか、と考えました。 WindowsからLinuxアプリのデバッグ、それぞれの役割 想定する構成は上記のとおりで、Linux側にはGUIがなく(ディスプレイを繋いでいない、など)、Windows側はデバッグのみで、Linux側でその他の全て(ビルドなど)を行う想定です。 Linux側の準備 この記事を読んでいるということは、既に何かデバッグしたいアプリケーショ
# 全ての警告メッセージを抑制したい場合 export CFLAGS="-w" export CXXFLAGS="-w" ./configure make # -Wnoを指定すれば、その警告は無効できる ## c # 暗黙の関数宣言 export CFLAGS="-Wno-implicit-function-declaration" # 廃止予定(deprecated) export CFLAGS="$CFLAGS -Wno-deprecated-declarations" # export CFLAGS="$CFLAGS -Wno-stringop-overflow" ## cpp # intからポインタへの変換 export CXXFLAGS="-Wno-int-to-pointer-cast" # export CXXFLAGS="$CXXFLAGS -Wno-class-memac
概要 プログラムがいきなり落ちた gcc の -fstack-usage オプション 現在のスタック領域のサイズを調べる 試してみる makefile github にサンプルプロジェクトをアップ 参照情報 概要 忘れないうちメモメモ。こういうのは知ってるのと知らないので手間が大きく変わりますね・・・。 プログラムがいきなり落ちた 自分が書いたプログラムではないんですが、動かしていると特定の処理パターンを通したときにいきなり死ぬという状況が発生。 C言語なので、本当にスンって死んでくれます・・w いろんなところをコメントアウトしたり、printfデバッグ入れたりして箇所は特定。 最終的にいろいろ調べたところの結果が「デフォルトのスタックサイズを超える割当をしてるのが原因」でした。これはアカン・・。 で、修正するのは良いとして、もうちょいマシな調べ方ないのかしら?って思いました。 手作業すぎ
C/C++でのユニットテストによるメモリリーク検出 - 千里霧中の補足。 メモリエラーの検出方法についてだけれど、最近のclangやgccだと、AddressSanitizerという動的解析ツールが組み込まれており、それを活用できる。 使用する場合はコンパイラオプション「-fsanitize=address」「-fsanitize=leak」等を指定する。 題材 例えば以下のコードを対象にする。 //main.c #include <stdio.h> #include <stdlib.h> void hoge(void) { int *a_buff = (int *)malloc(5 * sizeof(int)); a_buff[10] = 8; } int main(void) { printf("test\n"); hoge(); return 0; } これを普通にコンパイルして実行
処理系が用いるデータ型の大きさなどを定義するものであり、特にプログラミング環境で重要となる。 現在使われているプログラミング言語には、整数型の実際の大きさを保証しないものがあり、データ型モデルに応じて変化する。 ある特定のデータ型モデルに依存したプログラムも簡単に書くことができるが、そのようなものは移植性が無いということである。 16ビットから32ビットに移行する時代、Cなどでこの問題が頻発した。 16ビット環境では、変数長は次のようであった。 char: 8ビット short: 16ビット int: 16ビット long: 32ビット long long: 存在しない ポインター: 16ビット (far修飾子を付けると32ビット) 32ビット環境では、intとポインターが32ビット化された。 例えばこの当時、特にx86環境ではnearポインターとfarポインターがあり、実装によりhuge
#はじめに これは昔(2010年頃)自分が使っていた高速化技法について書いたものです. 今となってはレガシーだったり,通用しないものもあるかもしれませんが,こういう知識も無くなってしまったり,自分も忘れてしまう気がしたので,メモ代わりに書いておきます. ただ言えることは,「最適化はするな」ということです.最適化すると,保守性が大幅に失われる危険性があります.そして,これから書く項目を1つ1つ行って,高速化できたとしても,せいぜい2倍程度です.ただその2倍程度の速度も欲しい!そのためには悪魔に魂と保守性を売る!という方はご覧ください.これらの高速化は割といろいろな言語に当てはまることも多いですが,大体C++で書くことを念頭に置いていただければ,幸いです.あと,個人的には競技プログラミングだったり,計算科学をやっていた時期に見つけた経験則なので間違ってる場合もあります. #コンパイルオプション
GCCを起動すると、 通常は、 前処理(preprocessing)、 コンパイル、 アセンブル、 リンクが行われます。 「全体的(overall)オプション」によって、 この一連の処理を中途の段階で停止することができます。 例えば、 `-c'オプションはリンカを起動しないよう指示するものです。 この場合、 アセンブラによって生成されるオブジェクト・ファイルが出力となります。 他のオプションは、 一連の処理の中の1つの段階に渡されるものです。 オプションの中には、 プリプロセッサを制御するものもあり、 コンパイラ自体を制御するものもあります。 また、 アセンブラやリンカを制御するオプションもありますが、 それらのほとんどは、 ここではドキュメント化されていません。 というのは、 このようなオプションを使うことが必要になることはめったにないからです。 GCCにおいて使うことのできるコマンドラ
C 言語で書かれた静的ライブラリと共有ライブラリについて、いまいち理解がちゃんとしていなかったのでまとめておく。 ライブラリというのは、複数のアプリケーションで使われるような共通の機能をまとめたものをいう。 今回使った環境は次の通り $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=20.04 DISTRIB_CODENAME=focal DISTRIB_DESCRIPTION="Ubuntu 20.04.3 LTS" $ uname -rm 5.11.0-1021-gcp x86_64 $ gcc --version gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 Copyright (C) 2019 Free Software Foundation, Inc. This is free s
6月24日、Debian開発者のマティアス・クローゼ(Matthias Klose)氏はDebianの開発者メーリングリストに対し、2016年末に正式リリースが予定されているDebian GNU/Linux 9 "Stretch"のコンパイラに関して「GCC 6がStretchのデフォルトコンパイラになる」と投稿した。現在、テスト版(Debian Testing)とUnstable版のユーザであれば、GCC 6をデフォルトコンパイラとして利用し、バグフィクスなどをレポートすることができる。 GCC 6 & binutils for the Debian stretch release クローゼ氏は「StretchをGCC 4.9/GCC 5なしでリリースすることは僕のゴールだ」とも明言しており、StretchではGCC 6がデフォルトになるだけでなく、GCC 4.9およびGCC 5はStr
CERNが2つのチャームクォークを含む新物質「Ξcc++」を発見したとEPS会議で発表しました。これまで存在が予想されていた「2つの重いクォークを持つバリオン」が初めて発見された例です。 Observation of the doubly charmed baryon Xicc++ - lhcb_paper_2017.07.06.pdf (PDFファイル)http://press.web.cern.ch/sites/press.web.cern.ch/files/file/press/2017/07/lhcb_paper_2017.07.06.pdf LHCb announces a charming new particle | CERN https://home.cern/about/updates/2017/07/lhcb-announces-charming-new-particl
OpenMPとは? OpenMPとは、並列プログラミング用の 機能で、C/C++, Fortran で使用できます。並列プログラミングには色々とありますが、以下の様な利点があります。 通常のプログラムからOpenMPを使用するように書き直しやすい。 ハード(CPUのコア数)に依存しないプログラムが書きやすい。 Visual Studio(Pro2005以降), gcc(4.2以降), インテルコンパイラ(V9以降)などある程度マルチプラットフォームで使用できる。 逆に欠点としては以下があります。 記述に#pragmaディレクティブというコンパイラ専用の機能の記述に使用する方法を使用するので、プログラムが見にくくなる。 パフォーマンスは特にコア数が増えると今一歩のところがあるらしい。 現在OpenMP4.0まで出ているが、Visual StudioはOpenMP2.0まで、LLVMは現在Op
Cプリプロセッサというのはgcc, clang, MSVCなどの処理系ごとに微妙に異なります。 #pragmaディレクティブなどは、各コンパイラ等の独自拡張機能をサポートする為などに使われていますが、Cプリプロセッサの差というのはサポートする機能の有無やキーワードの違いだけには留まらないようです。 今日は、偶然MSVCが#pragma内のトークンを展開するという個人的に意外な挙動を発見したのでこれを書いておきます。 次のような例です。 #define print(msg) message(msg) int main() { #pragma print("hello world!") }; このように記述した場合、gccとclangでは warning: unknown pragma ignored [-Wunknown-pragmas] #pragma print("hello world
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く