1 日か 2 日考えた後、シンボル ノードがさまざまな種類の手順を表す方法について、ある程度根本的な変更を開始しました。これは、セクション 14.1.2 で説明されている解決ルールを実装するための準備です。このセクションを読んだことがあるなら、意味を理解し始める前に数回読む必要があることを知っています.
いずれにせよ、プロシージャの種類は、以前はシンボルの「フレーバー」フィールドに格納されていました。アイデアは、FL_PROCEDURE を除くすべてのプロシージャ関連のフレーバーを取り除くことです。シンボルが何らかの手続きである場合、proc ビットフィールドは手続きの型を保持します – 内部、ステートメント関数、モジュール手続き、組み込み手続き、外部手続きなど。
この方法で保存することの主な利点は、名前がプロシージャであるとコンパイラが認識する前に、それがどのようなプロシージャであるかを認識することが非常に頻繁にあることです。したがって、FL_PROCEDURE を FL_MODULE_PROC などに変更する代わりに、シンボルを FL_PROCEDURE としてマークすることから始め、情報が利用可能になるたびに proc を PROC_* に設定します。ステートメント関数は、解析時に最初に表示されたときに認識されます。内部プロシージャは、最初に表示された後しばらくしてから認識されます。組み込みおよび外部プロシージャは、解決フェーズでのみ決定されます。
これは Craig Burley が何年も前に書いたもので、Fortran コンパイラがどのように物事を「発見」するか、そしてなぜ最初のパスで GBE ツリー表現を構築することが不可能であったかを説明していました。
キャサリンは今週まだ休暇中なので、彼女が戻ってくる前に衝突する可能性が高いことをやっています.
7月14日
Nuno Pinhão さんは、モジュールが書かれているときの内部エラーを報告する別の電子メールを送信しました。問題を再現できず、以前の問題を修正していたときにソース ファイルを変更して問題を解決したのではないかと疑っています。元のソースファイルを再送信するよう彼に依頼しました。
Arnaud Desitter が数日前にパッチを送信し、私はそれを適用しました。彼が送信した変更の 1 つは、g95_free_data() サブルーチンを静的にしました。これは、名前空間構造が解放されたときに呼び出す必要があるという事実を浮き彫りにしました。そのため、部分的な変更ではなく、メモリ リークを塞ぐことになりました。
Toon Moene は、ラスベガスで 8 月 20 日月曜日の夜に開催された J3 委員会のミーティング #158 で、G95 Birds-Of-A-Feather ミーティングを発表しました。現在の進捗状況、ライブラリ、および g95 の開発に資金を提供するためのアイデアについて説明します。私はそこにいるために力強く努力するつもりです。論文は順調に進んでおり、弁護期日はまだ 8 月の予定です。
7月11日
Nuno Pinhão のコードで見つかった ELSEWHERE ステートメントのバグを修正しました。シンボル テーブルに加えられた変更がコミットされていないことが判明しました。最も一般的に使用される ELSEWHERE の形式はシンボル テーブルを変更しないため、これはほとんどの場合うまくいきました。
