私の RK コードでは、変数式の格納方法に欠陥がありました。「VAR%NAME」のようなものは、「VAR」の属性ではなく、そのメンバー「NAME」の属性を持っています。式ノードに別のメンバーを作成して修正しましたが、必要に応じて計算されるサブルーチン呼び出しに変更するだけだと思います。
Tobi は、彼が最近取り組んでいる組み込み関数に関連する一連の小さなパッチを送信しました。この部分も少し加工が必要です。
7月29日
今日はネタばっかり。最大の変更点は解析モジュールにありました。適切なステートメントの順序付けのチェックが 1 か所で行われるようになり、これによりいくつかのプログラム ユニット パーサーが大幅に小さくなりました。
USE ステートメント用に、最後のステートメント マッチャーを実装しました。その後、約 16k 行の長さの fortran 90 Runge-Kutta インテグレーターで g95 を実行し始めました。これにより、以前は発見されていなかった多くの問題が指摘されました。USE ステートメントが実際には何もしないという事実を回避した後、約 500 行にたどり着くことができます 。
また、Tobi から送られてきた小さなパッチを適用しました。おそらく Kate の floatlib パッチですぐに開始されるでしょう。
7月27日
gmp/floatlib の計画について誰もコメントしていないので、かなり良いアイデアだったに違いありません。
含まれているサブプログラムを解析するためのサブルーチンのデバッグが完了しました。まだデバッグされていない MODULE ステートメントのパーサーが追加されました。これは、作成する必要がある最後のステートメント マッチャーになる可能性があると思います。すべてのステートメント (ただし、すべての fortran 95 コンストラクトではない) が一致したらすぐに、誰でもテストできるバイナリ リリースの投稿を開始します。
これが終わった後に私がすることは、マッチングとコード生成の両方の観点から、他の人が貢献しやすくなるように、g95 の内部構造をより適切に文書化することだと思います。
7月26日
現在の GMP/floatlib のジレンマをどうするかを決定しました: 実数には floatlib を使用し (新しいバージョンは私が思っていたよりも多くのことを行います)、整数には GMP を維持します。
Tobi が数日前に送ったパッチを適用しましたが、これはよくわかりませんでした。また、sort_actual 関数を intrisic.c 内に移動して、引数のチェックを簡単にしました。
含まれているサブルーチンを解析するためのコードを追加しました。現在は呼び出されていますが、テストされていません。
