Doctor Fortran による「終わりは近い」

この記事は、インテル® デベロッパー・ゾーンに公開されている「Doctor Fortran in “The End is Nigh”」の日本語参考訳です。

2018 年 6 月にカリフォルニア州バークレーで開催された国際 Fortran 標準化委員会 (WG5) では、国際規格案 (DIS) の ISO 投票時に受理した 84 件のコメントに対応しました。これらのコメントの多くは編集に関するものでしたが、技術的な問題の明確化を求めるものや、小さな技術変更に関するものもいくつかありました。新しい FDIS (最終国際規格案) を作成するため、十分な編集作業が行われました。今後投票を経て、すべてが順調に進めば 2018 年中に Fortran 2018 標準が公開されるでしょう。すべてがうまく行くことを祈っています。

各コメントとそれぞれへの対応は、ISO ドキュメント N2153 (英語) をご覧ください。ほとんどの列は自明ですが、左端の「MB/NC」列は分かりづらいかもしれません。コメントは、一般に DIS のページ順に番号が付けられますが、ISO の並べ替え方法が原因で一部順番どおりではない個所があります (実際にご覧になって確かめてみてください)。番号の先頭には 2 文字の国コードまたは「**」 (ISO からのコメントの場合) が付けられます。右端の列は J3 の回答を示しており (米国の委員会である J3 は標準規格の文書化を担当しています)、それぞれのコメントに対応する特定の J3 文書へのリンクが含まれています。

この記事では、いくつかの興味深い技術変更について述べたいと思います。

コメント GB020 は、「a でプロセッサーがサポートしていないランクを [SELECT RANK 構文で] 指定しても、文に到達しないため無害です。ランクをサポートするプロセッサーへプログラムを移植できるように、このような記述は許可されるべきです。」というものです。現在のドラフトには、「ランクの SELECT CASE 構文内のスカラー整数定数式は、負ではなく、selector の最大ランク以下でなければならない」という制約が記載されています。なぜこれが問題となるのでしょうか?

標準規格で指定されている最大ランク 15 を超えるランクをサポートする Fortran コンパイラーについて考えてみます。例えば、インテル® Fortran コンパイラーは最大 31 ランクをサポートしています。この制約があると、ランク数が 15 を超えるケースを含む SELECT RANK 構文は、15 以下のランクをサポートするコンパイラーでは実行されないにもかかわらず、標準に準拠した方法で記述できません。また、コンパイラーは、プログラムが 15 次元を超える配列を作成しない場合であっても、そのようなケースを診断する必要があります。

委員会は、この「最大ランク」に関する制約が不必要であることに同意し、削除しました。そして、メモを追加しました。ほかの技術変更とは異なり、SELECT RANK は Fortran 2018 の新機能であるため、以前のエディションからの変更点が記載されている「Introduction」を編集する必要はありません。

コメント GB043、GB044、および GB045 は、新しい組込み関数 RANDOM_INIT の定義に関するものであり、1 つのイメージで RANDOM_INIT を呼び出した場合、別のイメージに影響するかどうかが明確ではないというものです(ここで「イメージ」とは、Co-Array を使用するプログラムのインスタンスを指します)。私はこの機能の共同開発者の 1 人であったため、これは私にとって特別な意味を持ちました。私は、これに回答する作業を引き受けました。幾度かの考察と数回の議論を経て、最終的に大幅な変更となりました。

最終的に、イメージごとに個別の疑似乱数ジェネレーター・ステートを持ち、RANDOM_INIT または RANDOM_SEED 呼び出しによってこのステートを変更できるようしました (もちろん RANDOM_NUMBER 呼び出しも使用できます)。また、「反復可能」の意味を明確にする必要があり、1 つのイメージの RANDOM_INIT 呼び出しは別のイメージに影響せず、そのため同期も不要であるとしました。これは、RANDOM_NUMBER の動作を「初期化」したいイメージごとに RANDOM_INIT を呼び出す必要があることを意味します。

会議の参加者全員がこの結論に納得したわけではありませんが、ほとんどの参加者はこれが実際的な定義であることに同意しました。すでに、次の標準規格での RANDOM_INIT の強化についていくつかの提案が上がっていました。

最後の技術変更は、コメント JP079 の CHANGE TEAM 構文で EXIT を許可しないことは、END TEAM 文へ分岐する GOTO 文で同じ効果が得られることから、馬鹿げているという指摘でした。解決策として、別の構造内にネストされている場合を除いて、CHANGE TEAM 構文と CRITICAL 構文の両方で EXIT による文の「終了」を許可しました。

バークレーでは Fortran 202X について議論する時間があまりありませんでしたが、ほとんどの参加者は、2 月に開催された J3 会議においてユーザー調査と議論を通して機能を選択し良いスタートが切れたことに同意していました。私は、各国の代表にそれぞれの国の F202X に対する要望リストの提出を求めました。2 月の J3 会議では、F202X で採用すべきかどうか不確かな 4 つの機能について「模擬投票」が行われ、そのうちの 3 つ (+= 演算子と *= 演算子、いくつかの構文での BLOCK なしの宣言文の許可、および初期化子/コンストラクター) は、十分な支持が得られませんでした。配列や割付けで Co-Array 要素を許可することについては、ほとんどの参加者がさらなる調査が必要であるとしました。

詳細とドキュメントは、WG5 Web サイト (英語) と J3 Web サイト (英語) をご覧ください。会議の公式の議事録は、準備ができ次第これらの Web サイトで公開されます。

コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。