Tobi Schlüter は、構成要素の 1 つが整数のように見えるリテラルである場合に、複素数の KIND を修正するパッチを送信しました。通常、私は多かれ少なかれ時系列でメールを処理しますが、パッチが優先されます。
Bill Wendling さんは、解決を制御する switch() のフォールスルーを修正するパッチを送信しました。DO 解決のケースが ALLOCATE 解決にフォールスルーしていました。
Dan Nicolaescu は数日前に COMPLEX 型の変数を出力しようとすると内部エラーで失敗したと指摘しました。これは修正しましたが、派生型の対応する修正は、コード生成に入るまで待つ必要があります。
Jos Bergervoet さんは、関数宣言の RESULT キーワードに関する問題を報告しました。’result’ 属性を実際に設定したサブルーチンのリターン コードが正しくチェックされていませんでした。彼はまた、配列コンストラクターが正しく解析されていないことも指摘しました。これは、間違った式の型を設定したことが原因であり、コンストラクター自体を解放しないという問題も明らかになりました。すべて修正。
また、非常に大きくなっていた expr.c を 2 つの小さな断片に分割する作業にも時間をかけました。最初の部分は新しいファイル primary.c で、整数、実数、複素数、論理、配列コンストラクターなどの一次式の一致を処理します。2 番目の部分は expr.c の残りの関数で構成され、多くの割り当て、コピーの解放、解決、単純化、変換などの一致しない式。
私が始めたもう 1 つの作業は、g95.h のプロトタイプのクリーンアップでした。私がこれを行ってから長い時間が経ちましたが、多くのプロトタイプが故障しているか、他のソース ファイルであるか、単に使用されていませんでした。私は symbol.c を通り抜けただけで、おそらくまだソースの 2/3 が残っています。
要するに、今日のいたるところに多くの変化があります。
8月31日
Michael Richmond は 3 日前にいくつかの問題を指摘するために書き込みましたが、そのうちのいくつかは既に認識され、修正されています。そうではなかったものから、彼は、行が読み取られたときに (意味のない) スペースが切り捨てられた場合、g95 が警告したことを指摘しました。これを変更して、スペース以外の文字が表示された場合にのみ警告するようにしました。彼はまた、FUNCTION 内の ENTRY 名には必要な「変数」属性が与えられていないことも指摘しました (また、RESULT キーワードの解析もおそらく存在しないと思います)。また、ENTRY ステートメントでさらに多くの作業が必要になることも明らかです。
