合計 6 か所で発生した をgrep した後FLAVOR_VARIABLE、変数属性を独自のビットに移動することはそれほど問題ではないことがわかりました。関数の戻り値に代入できるようになりました。
Toon Moene がさらにいくつかの失敗を送信しました。 READand WRITEステートメントが正しく失敗するようになりました。ステートメントによって出力されたステータス メッセージを削除し、IMPLICITステートメントを追加しましたRETURN。
“#include <string.h>”への参照が含まれているため、error.c にも追加しましたstrlen()。私の x86 Linux-pedantic -Wallでは を使用しても問題なくコンパイルされましたが、プロトタイプがどこにも見つかりません。gcc が の内部最適化バージョンを使用していると思われstrlen()ます。言い換えれば、gcc はそれ自体の利益のために少し賢くなりすぎています。
READ最近の転用を促したandWRITE ステートメント の作業を再開しました。よく考えた結果、イテレータを含む完全な IO リストに一致する関数のセットになりました。
アイデアは、特別な構造を構築することではなく、g95_code ステートメントのツリーを生成することです。これは、IO-start ステートメントへの呼び出し、次にループに関与する可能性のある式のリスト、そして最後に IO-end ステートメントへの呼び出しになります。
最終的に、ほとんどの IO ステートメントは同様のハンドラーに置き換えられます。最初に既存の IO 構造が埋められ、次にステートメントが構文的に正しい場合に呼び出しが生成されます。
G95 は現在 14,000 行の長さです。
4月23日
Toon Moene は彼のアルファ版で g95 のコンパイルに成功しました。彼はいくつかの問題を指摘した。1 つ目は、(まだ実装されていない) COMMON ステートメントが適切に失敗しなかったことです。これについては、さらに調査が必要です。x86 Linux ボックスでは、同じコードが正しく機能しません。明らかに、アーキテクチャに依存する何かが起こっています。
変数参照に関する 2 つ目の問題は、数日前に書いた多くの変数参照コードをデバッグしたときに修正されました。
最後の問題は、シンボル属性を調べたときに犯した悪い間違いを明らかにします。問題は、関数名が変数名にもなり得ることです。現在の実装では、シンボルを同時に「変数名」と「関数名」にすることはできません。起こらなければならないことは、「変数」がフレーバー列挙から出てきて、それ自体で単一ビットになることです。このビットはほとんどのフレーバーと互換性がありませんが、関数名と互換性があります。もう 1 つの意味は、まだ FLAVOR_UNKNOWN を持つシンボルになってしまうということですが、これは大したことではないようです。
4月22日
Katherine Holcomb は、fortran 95 にあるすべての組み込みサブルーチン (かなりの数があります) を入力することに関心を示したので、私は 1 日の一部を費やして、intrinsic.c を変更して、より多くの入力プロジェクトにしました。ファイルの解析を開始する前に g95_internal_error() を呼び出せるように、error.ca ビットを変更しました。
4月20日
g95_show_array_ref() を array.c に追加し、それを呼び出すように g95_show_expr() を更新しました。参照構造の空きリストに g95_free_ref_list() を追加しました。g95_code 構造を 2 つの式を持つように変更しました。代入は 2 つの式で定義され、そのうちの 1 つは EXPR_VARIABLE です。
ここ数日で書かれたもののデバッグを開始しました。いくつかのバグを修正し、深刻な更新が必要な g95_match_assignment() への 2 回解放されたメモリの問題を追跡しました。そこから始めましたが、必ずしも単一のシンボルではないもの (構造) を処理するために、check_assignment() サブルーチンを更新する必要があります。
