適切なライブラリ サブルーチンに解決する単純化関数

Steve Kargl さんは、g95 が freebsd の下にある彼の個人的なライブラリの多くを解析して解決するようになったと報告しました。彼は、SUM 組み込みの問題を報告しましたが、それは、私がそれを見るようになるまでに不思議なことに消えてしまいました…おそらくノームがそれを修正したのでしょう。SUM 呼び出しを適切なライブラリ サブルーチンに解決する単純化関数を SUM に追加しました。

Laurent Klinger と Steven Bossher は、変数がディメンション属性を持っていた場合の ASSOCIATED の問題を報告しました。check 関数に関連付けられたコードはかなり古臭く、g95_variable_attr() の呼び出しに置き換えました。これは、変数式の属性をシンボルであるかのように返し、機能しているように見えます。

また、単一の文字に一致する新しい一致関数 g95_match_char() も追加しました。g95_match() の呼び出しのほぼ 3 分の 2 は、単一の文字列に一致するものでした。私が g95 を始めたとき、g95_match() をほとんどの状況に対応できる汎用性の高い関数にすることを計画しました。エラー報告が原因で、あまり良くないことが判明しました。試合中に何か問題が発生した場合、MATCH_NO を返すか、MATCH_ERROR を返すかはトスアップでした。

最終的には、個々のマッチャーを呼び出して、問題が発生したときに対処する方が簡単でした。いつか戻って、現在使用されていない g95_match() の機能を削除します。

私は寝なければならない。オランダの朝です。Steven は目を覚まし、さらに多くのバグ レポートを送信しています…..

1月21日
キャサリンは逆正接の精度損失の問題を修正しました。Arctan は、他の計算が行われていた桁の半分で計算されたバージョンの pi を使用していました。

スティーブンは、組み込み関数とサブルーチンの使い方に問題があることを発見しました。元のスキームでは、関数とサブルーチンを戻り値の型 (サブルーチンの場合は BT_UNKNOWN) で区別していました。問題は、BT_UNKNOWN を返すように関数を設定していたことです。特に、引数に応じてすべての異なる型を返す関数がそうでした。新しいパッチは、物事を正しくカウントします。

1月19日
LAPACK でチェッカー化された g95 を実行して、午後のほとんどを Claus Fischer の Web サーバーで過ごしました。LAPACK を選択したのは、それが fortran 77 であり、既にエラーなしで解析および解決されているためです。最初の問題は、g95_code 構造体のトラバーサルのバグで、構文ツリーのほとんどが最終的にリークしてしまいました。そこから、いくつかの非常に些細なリークを追跡し、金を打ちました。

リークは、シンボルが解放されずに保存されました。Fortran を難しくしている理由の 1 つは、パーサーが何かが間違っていることに気づき、別のことを試みるためにバックアップしなければならない前に、潜在的に多くの変更がシンボルにある可能性があることです。パーサーがシンボルを検索すると、シンボルの元の状態が保存され、シンボルは単一リンク リストに配置されます。

ステートメントの一致が成功すると、リストが走査され、古い情報が削除されます。ステートメントの一致が失敗した場合、リストはトラバースされますが、シンボルが既に存在する場合は古い情報が復元され、そのステートメントでシンボルが作成されたばかりの場合はシンボルが削除されます。これで、シンボルが作成された後に2回目に検索されると、バグが発生 します。シンボルが変更されたシンボルのリストにリンクされたのは 2 回目だったため、既にリストに存在していたため、リストが破損していました。

ステートメントの一致は通常成功するため、このバグは今まで気付かれませんでした。成功すると、リスト全体が解放されず、リークが発生しました。失敗した場合、シンボルに関する情報は正しく元に戻されませんでした。これは問題ではありませんでしたが、シンボルが間違った属性を取得することに簡単につながる可能性がありました。解決策は、保存された情報へのポインターとは無関係に、シンボルが新しいかどうかを示すビットをシンボル構造に追加することでした。

いずれにせよ、g95 は 1 日中、Claus のマシンで実行されており、おそらく夜中も続くでしょう。チェッカー化されたバージョンは非常に遅いです…

タイトルとURLをコピーしました