LLOCATE ステートメント内のベクトル部分式のスカラー化に関する複数の問題

Anders Ålund さんは、修正された ALLOCATE ステートメント内のベクトル部分式のスカラー化に関する複数の問題を発見しました。

Charles Rendleman は、新しい g95 が彼のコードを再びコンパイルして実行すると報告しました…

Harald Anlauf さんが、クラッシュを引き起こしたコードを送信しました。私はここにそれを再現する自由を取りました:

プログラム
  整数、パラメータ、次元 (31) :: I = (/&
     10,32,44,45,46,59,67,79,97,98,99,100,101,102,103,104,105,107,108,109,110,111,112,&
     114,115,116,117,118,119,120,121 /)
  整数、パラメータ、次元 (392) :: J = (/ &
     8,21,2,26,16,13,2,14,17,24,25,26,2,25,13,​​11,22,21,12,2,26,16,17,24,12, 2,14,22,27,24,26,16,2,14,17,14,26,&
     16,2,25,17,30,26,16,2,25,13,​​28,13,21,26,16,2,13,17,15,16,26,16,2,21,17, 21,26,16,2,26,13,21,26,16,2,13,19,&
     13,28,13,21,26,16,2,26,29,13,19,14,26,16,2,12,9,31,2,22,14,2,7,16,24, 17,25,26,20,9,25,2,20,31,2,26,24,27,&
     13,2,19,22,28,13,2,15,9,28,13,2,26,22,2,20,13,1,26,29,13,19,28,13,2, 12,24,27,20,20,13,24,25,2,12,24,27,20,&
     20,17,21,15,3,2,13,19,13,28,13,21,2,23,17,23,13,24,25,2,23,17,23,17,21, 15,3,2,26,13,21,2,19,22,24,12,25,2,&
     9,4,19,13,9,23,17,21,15,3,1,21,17,21,13,2,19,9,12,17,13,25,2,12,9, 21,11,17,21,15,3,2,13,17,15,16,26,2,20,9,&
     17,12,25,2,9,4,20,17,19,18,17,21,15,3,2,25,13,​​28,13,21,2,25,29,9,21, 25,2,9,4,25,29,17,20,20,17,21,15,3,1,&
     25,17,30,2,15,13,​​13,25,13,​​2,9,4,19,9,31,17,21,15,3,2,14,17,28,13,2, 15,22,19,12,2,24,17,21,15,25,6,1,14,22,&
     27,24,2,11,9,19,19,17,21,15,2,10,17,24,12,25,3,2,26,16,24,13,13,2,14, 24,13,21,11,16,2,16,13,21,25,3,2,26,&
     29,22,2,26,27,24,26,19,13,2,12,22,28,13,25,1,9,21,12,2,9,2,23,9,24, 26,24,17,12,15,13,​​2,17,21,2,9,2,23,13,9,&
     24,2,26,24,13,13,5,1 /)
  整数、パラメータ、次元 (12) :: K = (/8,14,21,27,34,40,46,54,61,67,73,82 /), &
     L = (/13,20,26,33,39,45,53,60,66,72,81,89/) &
     M = (/365,344,325,305,288,268,244,221,200,179,157,131/)
  整数 :: n
  n = 1、12を行います
   print*, achar( I((/J(1:7), J(K(n):L(n)), J(90:130), J(M(n):) /)) )
  終了する
プログラム終了

つまり、いくつかの非常にドライなコードの退屈なバグです。問題は、長さが指定されていない ACHAR() 組み込み関数のスカラー化にあることが判明しました。これと、CHAR() の類似の問題を修正しました。コンパイルして、実行すると床に倒れそうになりました。

Kozma Endre さんから、モジュール プロシージャの文字の長さが一定でないという問題が報告されました。この問題は、1 日か 2 日前に文字型ノードの修正で修正されたようです。

Martin Dix さんは、十分な値を持たない整数配列を読み込むと、十分に早く終了しないという名前リストの問題を発見しました。これは、文字変数と論理変数に対する同様の修正によって壊れていました。他のすべてのタイプでも機能するはずです。

Tim Geise はまた、g95 をクラッシュさせる Fortran での Mersenne Twister の実装を送りました。ISHFT() が種類 8 の整数に対して正しく機能していないことが判明しました。修理済み。

 


6月8日

g95は今、床から戻ってきたと思います。

元の問題は、Tim Giese によって発見された複数のバグでした。文字配列の引数を渡すには、長さも別々に渡す必要があり、文字の結果を返す関数は、その長さを兄弟手続きから隠蔽する必要があり、実際の引数リスト内の完全な文字型は使用できません。内部プロシージャのリストを最初に通過するときに完全に構​​築されます。

何人かの人々が放射性降下物に関する問題を送ってきました — Doug Cox は複素数の足し算の問題を指摘し、ENTRY の失敗も Burkhard Bunk によって指摘されました。

Matt Kennel は、 –version が与えられたときの時代遅れのメッセージに注目しました。更新されました。彼はまた、他の破損で解決した問題を発見しました。

Anders Ålund さんは CONJG() の問題を報告しましたが、これも蒸発しました。

Charles Rendleman は、同じことを行うモジュールとポインタに関する問題を送信しました。

Joost Vandevondele さんは、モジュールに別の問題があることを発見しましたが、それが実際のものであることが判明しました。破損は元の修正によるものでした。

Jürgen Wieferink は、内部ファイルへの書き込みが標準エラーになるという問題を発見しました…これを発生させるには、最初に stderr に何かを書き込んでいたことが判明しました。これで修正されました。

 


6月6日

Charles Rendleman と私は、名前リストの問題を追跡するために大量の電子メールを交換しましたが、最終的には消えてしまいました。その過程で、非常に壊れた g95 をアップロードしました。私は他のことで忙しくしていましたが、同時にバックエンドで非常に厄介な問題を抱えていました。その結果、今では多くのものが壊れています。g95 を今すぐダウンロードすることはお勧めしません。

 


6月2日

Anders Ålund さんは、もう 1 組のスカラー化問題を提出しました。最初のケースでは、サイズを提供する式に最初の次元にないベクトル添え字が含まれている場合、一時配列のサイズが正しく計算されませんでした。2 番目の問題は、範囲が最初の次元にもない場合に、配列コンストラクターの範囲をループに適切に変換することにありました。両方固定。

Dominique Orban さんは、数学的プログラミングの環境である彼のCUTErパッケージ のコンパイルと実行に成功したと報告しました 。

Ingo Thomas は、PARAMETER 変数が初期化されていない場合にクラッシュすることを発見しました。問題は、エラー メッセージを台無しにしてしまったコードの最近の書き直しでした。

Doug Cox さんは、g95 が ifort と異なる IOLENGTH の問題を報告しました。よく調べてみると、IOLENGTH の結果はプロセッサー依存の結果であり、OPEN ステートメントの RECL パラメーターと一致している必要があります。

Vivek Rao さんは、g95 が割り当て可能な配列引数をサポートしていないことを指摘しました。これは TR 15581 の一部です。これは、私がサポートする予定の f95 のオプションの拡張機能です。割付け配列の引数と割付け配列の戻り値の初期サポートを追加しました。-Wstd=f95 オプションが指定されている場合 (厳密な f95)、これは機能しません。実際の TR は、今日行ったものよりもはるかに精巧です。

 

タイトルとURLをコピーしました