キャサリンは、チェック関数が失敗したときに理由を与えるようにチェック関数を拡張する作業を開始しました。メッセージを表示しなければならないこともあれば、静かに失敗を返すこともあるため、これは少し注意が必要です。
Tobi は、GCC 3.0 と最適化フラグを使用して g95 をコンパイルしようとしました。最適化パスにより、昨日書いた単純化関数と配列仕様コードにいくつかの問題が見つかりました。
Bryan Carpenter の f90 テストを試してみました。USE ステートメントに演算子の指定を追加し、空の SELECT ステートメントでメモリ ブロックを 2 回解放するという問題を解決しました。
また、テスト スイートの変更も検討しています。主に、新しいテスト ケースを簡単に挿入できるように、テスト プログラムを CVS の下に配置するだけです。もう 1 つの問題は、一部のテスト ソースの構文エラーの修正に関係しています。実際の構文エラーが多数存在するところまで来ています。
6月22日
g95_array_spec への参照を新しい g95_array_shape 構造体に分割します。パッチは十数個のファイルに分散され、かなりスムーズに進みました。テストスイートがどのように機能するかを見るのは興味深いでしょう…
6月21日
今日はコードはありませんが、いくつか考える必要があります。数日前に、式ノードから配列指定構造を切り離すのは間違いであることに気付きました。審議が遅れた理由は、1、2 か月前に配列参照型であったことを思い出し、それを配列仕様に変更したことです。
いくつかの熟考の後、配列仕様で十分ですが、やり過ぎです。ここでの考え方は、必要な形状情報を伝達するだけでなく、スカラーであるノードから配列型を持つ式ノードを区別することです。使用される唯一の指定は、AS_EXPLICIT です。これは、想定された形状、遅延、想定されたサイズ、および不明が適用されないためです。ここに実際に格納する必要がある情報は、ランクと形状、つまり各次元の要素数ですが、配列仕様が格納する境界ではありません。
対照的に、配列参照構造体は、要素、セクション、または完全な配列を指定します。一般に、これは、開始、終了、およびストライドを次元ごとに格納する必要があることを意味します。これは、配列の指定よりもやり過ぎです。
したがって、保存する必要があるものを保存するには、必要以上に一般的で混乱を招くような構造を使用するのではなく、特定の情報を保存する別の型を作成する必要があります。私はそれが私を混乱させたことを知っています。
