数値定数の長さ制限の削除が完了しました。実際の定数では、これを行うコードは事実上すでにそこにあり、静的なサイズのバッファーを埋めるのはばかげていました。
デバッグ中に、16 進定数 z’abc’ を使用すると、誤って ‘z’ 記号が 2 か所に作成されることがわかりました。元のコードは、シンボルが見つからない場合に作成する g95_get_symbol() を呼び出しますが、これは間違いでした。新しいコードは名前に一致し、シンボル テーブルで名前を探します。
2月15日
最初に書いた論文コードに境界条件を誤って適用したので、ここ数日修正しています。この時点で、私はハックをそのままにしておいたでしょうが、正しい境界条件の計算はより洗練されており、メモリ フットプリントが約 3 分の 1 に削減されました。また、コードが大規模な実行で 250M を消費する場合、サイズを縮小する方法は常に歓迎されます。
「小さい」ことに重点を置いて、g95 にいくつかの小さな修正を加えました。また、任意の長さの数字文字列が受け入れられるように、定数一致コードの変更も開始しました。テスト スイートの 1 つに、大きすぎる定数を含むモジュールがあり、スイート内の他のすべてがそのモジュールを使用しています。
2月10日
Jean-Philippe Perois は、VC++ での g95 のコンパイルがほぼ成功したことを報告しました。この問題は、enum ビットフィールドを符号付き整数として扱う VC++ に関係していました。符号が拡張されると、内部コードが別の番号に変更され、すぐに内部エラーが発生しました。彼は、VC++ も実際にはビットフィールドをビットフィールドにパックしない (パックする必要はない) と述べています。これがどのように深刻な肥大化をもたらすかがわかります。
g95_code2string のようなサブルーチンを “int” の代わりに “unsigned” 値でプロトタイピングして、符号拡張が起こらないようにすることで、この問題を解決できると思います。彼はまた、ますますまれになっているコア ダンプを検出するプログラムを送信しました。
Rob Cermak は、一連の新しいプログラムをテスト スイートに追加しました。これらの新しいコードのほとんどは問題なくコンパイルされ、解析の成功率はほぼ 95% です。
組み込み型変換のオーバーホールを行いました。各変換関数をリストする代わりに、定数用のマスター変換関数が追加されました。do_simplify() サブルーチンは、宛先のタイプと種類を提供することにより、他のサブルーチンと比較して特別な方法でこれを扱います。考えられる変換ごとのintrinsic_symノードの構築も自動化されました。可能な型変換をそれぞれリストする代わりに、種類テーブルをループして、可能な変換をそれぞれ列挙します。
もう 1 つの大きな変更点は、組み込み関数のチェック関数です。これらは、関数呼び出しの型と種類を見て、参照が特定の組み込みシンボルに対して有効かどうかを判断する関数です。新しい規則は、現在の単純化関数とまったく同じです。各チェック関数に実引数リストを渡す代わりに、引数自体が渡されます。これにより、概念的に物事がはるかに簡単になります。
私は、HUGE や RANGE のような偽のジェネリック シンボルにされていたいくつかの関数を取り除きました。これらは独自のチェック関数に依存するようになりました。
