Michael Richmond は微妙な問題を報告しました。関数の結果を実引数リストで使用すると、手続きの引数として解析されました。非結果句を持つ関数の場合、関数の結果として解釈する必要があります。修理済み。
2月11日
Laurent Klinger は、g95 はまだ要素関数を扱っていないことを指摘しました。固有のテーブルにエレメンタルのフラグがありますが、現時点では使用されていません。彼は、g95 がすべてのコードを解決して解析できるようになったら、スイス チョコレートを送ってくれると言っており、私はそれを楽しみにしています。
スティーブン ボッシャーのチョコレートがファッジになりました。それは本当においしかったし、熟した2日後には、新鮮なときよりもさらに良くなるはずです。
プロシージャ シンボル ノードの格納方法に重要な変更を加えました。プログラム単位に親がある場合、プロシージャ名は親に作成されます。現在のユニットは、symtree ノードを持つノードも指しています。これにより、モジュール プロシージャ、インターフェイス、および内部プロシージャが適切になります。また、問題の名前がホストに関連付けられているように見え、通常のエラー メッセージの例外を g95_get_symbol() で切り出す必要があるため、プロシージャ内の宣言が親空間のシンボルに影響を与える可能性があります。例えば：
モジュール test
には
サブルーチン ff(x)
if (tt(x)) print *, ‘Hi’
end サブルーチン ff
function tt(x)
logical tt
tt = .TRUE. が含まれています。
関数終了 tt
モジュールテスト終了
「論理 tt」は「tt」のタイプに影響を与え、解決されたときに「ff」がそれを認識できるようにする必要があります。動作しているように見えますが、さらに微調整が必要になると思います。関数ノードを表すシンボル ノードの格納方法にもいくつかの変更がありました。
長い間、名前は親ユニットではプロシージャとして作成され、現在のユニットでは変数として作成されていました (RESULT 句のない関数の場合)。これにより、正常に動作しましたが、データ宣言ステートメントで関数の型が指定されている場合、まったくうまく動作しませんでした。型は、他のモジュール プロシージャが参照できるようにする必要がある親プログラム ユニットに伝達されませんでした。
これが、デュアル シンボル ストレージを廃止する主な理由でした。ここで、懸念すべきエンティティが 1 つだけあります。これは、あるべき姿です。
この変更は、LAPACK が非常に標準的な F77 コードであり、プログラム単位が含まれていないため、LAPACK を問題なく通過します。そこで、小さな f90/f95 の例がたくさんある meissner スイートに移りました。
いくつかの問題がすぐに現れました。配列参照の次元が正しくなく、これらを格納するための現在のスキームでは、すべてのケースでランクを計算できませんでした。そこで、配列参照構造にいくつかのフィールドを追加しました。これにより、各種類の添え字 (単一要素、範囲、またはベクトル添え字) を簡単に判別できるようになりました。これにより、計算がはるかに簡単になります。
バグのある READ および WRITE ステートメントの名前リストにも問題があり、同様に修正されました。
