ToDo:
バグ報告が上がってるんだけど、開発環境とか KEKB標準のコンパイル環境(PowerMac G5/Mac Pro)では再現しない。
多分、報告者の環境固有の問題臭いんですけど、 どんな環境で実行したのか書いてないから誰も追試出来ない罠。
つーか、ソース配布なんだからビルド環境の問題とソース側の問題の 切り分けが出来ていないなら、ビルド環境の状態を報告してくれないと 追試が出来ない。 もっとも、予想通り MacOSXだとしたら手元に環境を自由にいじれる 試験機が無いので調べようがない。
原因が分からなければ、DarwinにBROKEN付けて終了かな？
報告者のコンパイル環境の不良が原因だったらしぃ
なんか、最近のSADのバグ報告は GCCに含まれる Fortranコンパイラの 特定環境での不良絡みが上がってくるのですが、Cコンパイラの場合は 自分で自分をビルドするので、自己生成の結果を世代間で比較することで、 コンパイラ自身のバグが発覚しやすいのですが... 自己生成でないコンパイラは、テストセットを走らせない限り ほとんど発覚する機会が無い罠
みんなコンパイラツールチェーンをきちんと検証しようぜ(特に、Fortran)！
カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記
>みんなコンパイラツールチェーンをきちんと検証しようぜ(特に、Fortran)！<br>是非検証のやりかたを教えてください。
検証のやり方って...<br><br>やるべきことは、出来たバイトコードが意味論的に<br>C/Fortranの元の記述と同じ内容を実現しているかを<br>確かめることですよ？<br><br>方法論は、大別して２系統に分類できると思います。<br>分りやすいのは、テストケースを列挙してゆくやり方で<br>「有意なプログラム集合の全ての元を検証する」という<br>絨毯爆撃的な手法(有限集合なら終わる)です。<br>(実際には、ある種の連続性を仮定して手を抜くわけですが)<br><br>別の方針は、入力プログラムをある種の命題だと見なして<br>コンパイラはある命題Pを異なる記述で表記された<br>同値の命題P'へ変換する操作であると考えたとき、<br>コンパイラの動作記述自体が 任意の有効な入力に<br>対して PとP'の同値性を保証することを証明するという<br>戦術で、定理の自動証明とかに類する手法です。<br><br>が、どちらにしろ可能なプログラム集合全域に対して<br>動作を検証ないし証明するのは事実上不可能で、<br>実用上は代表的なテストケースを大量に記述して<br>コンパイル結果が正しく動作するかどうかを網羅的に<br>検査するわけです。<br><br>GCCとかだと、testsuiteが付属するはずなので、<br>これでエラーが出るようだと少なくとも何らかの<br>既知の不具合をコンパイラが内包することが分ります。<br><br>あと、最適化オプションに関しては生成コードの動作の<br>同一性は保証されない場合、厳密には最適化オプションの<br>組み合わせ毎に検証が必要です。<br><br>検証自体が結構大変な作業なんで、私がよくやる手抜きは<br>複数系統のコンパイラを常備して生成したバイトコードの<br>動作を相互比較するという手ですが<br>(複数の独立したコンパイラが、同じようにバイトコードを間違えて生成する可能性は小さいという仮定に基づく)