A PR was posted that seeks to add support for -Mextend to flang. This is an option from classic flang. As far as I am aware, there is no precedent for supporting classic flang options in flang-new. I have attempted to list the pros and cons of supporting classic flang driver options below”
Pros
Convenient for uses migrating from classic flang to flang
Cons
The spellings of classic flang options are not consistent with flang’s spellings. flang’s spellings are more consistent with clang and gfortran
flang is not backwards-compatible with classic flang, so this may raise questions of why we have some compatibility in driver options, but not much else
To try something different, I have added a simple poll that you can vote on. The poll is intended to gauge the degree of support/opposition for this proposal; the results are not automatically binding. This will be discussed at the next flang call as well.
While there is a poll, comments are more than welcome.
Which classic flang driver options should be supported in flang?
I’m interpreting “support” to mean we do something other than silently ignore it.
-Mextend Allow source lines up to 132 characters
This would seem to be deprecated as the current Fortran standard allows 10k characters per line. I see no problem in silently ignoring it, but we should not actually support it.
Edit: Ah - It’s specifically a fixed format option. My opinion doesn’t change, however. Fixed form has been officially obsolete for many years now, and the current standard recommends against using fixed source form.
The minimum, and somewhat unhelpful, interpretation of “support” would be “don’t raise an ‘unknown option’ error”. There are some options that the driver accepts, then ignores after issuing an appropriate warning. However, we generally only do this if clang already does so. We don’t do this unconditionally for non-clang options. The consensus recently has been that we are not necessarily aiming for command-line compatibility with gfortran either - even though clang goes a lot further in command-line compatibility with gcc.
-Mextend is just what the one PR happens to be interested in adding to flang. The purpose of this RFC is to determine if we want to support driver options from classic flang more broadly.
Thanks for starting this discussion. Based on the PR work and user needs, here’s a proposed list of classic flang options that could be considered for support:
Column 1
Column 2
Column 3
Column 4
PGI (classic flang) Compilation Option
New Flang Compilation Option
Function Description
Explanation
-Mfreeform
-ffree-form
Specify the Fortran source file as free format (non-fixed format)
Functionally identical; can also be automatically recognized via file extensions such as .f90/.f95.
-Mfixed
-ffixed-form
Specify the Fortran source file as fixed format (traditional format, where code begins at column 6)
Corresponds to fixed‑format parsing; .f/.for extensions are enabled by default.
-Mextend
-ffixed-line-length=132
Allow fixed‑format lines up to 132 columns
-mp
-fopenmp
Enable OpenMP functionality
-nomp
-fno-openmp
Disable OpenMP functionality
-module
-J
Specify the .mod file path (module path)
-fdefault-integer-8 / -i8
-fdefault-integer-8
Set INTEGER/LOGICAL to 8 bytes
-fdefault-real-8 / -r8
-fdefault-real-8
Set REAL to 8 bytes
-Mbyteswapio
-fconvert=swap 1. swap means swap 2. native means process with the current architecture’s byte order 3. little‑endian 4. big‑endian
Automatically swap byte order when reading/writing unformatted files (cross‑architecture compatibility)
Flang currently lacks this option; byte‑order conversion must be performed manually.
-Mlarge_arrays
-mcmodel=medium or -mcmodel=large
Allow array sizes exceeding 2 GB (support for large arrays)
Support for large arrays via the memory‑model option; the exact setting depends on the target architecture.
Supporting “Classic Flang” options in “LLVM Flang”,
Supporting “Classing Flang” options in flang (the current “LLVM Flang” driver).
flang should remain compatible with GFortran and only support GFortran spellings. Mixing GFortran and Classic Flang spellings would be too confusing - folks would start mixing both types of flags and we would end-up in some “in-between” state. For these reasons I am against the approach taken in #173833, which implements Option 2.
Instead, “LLVM Flang” could implement a compatibility mode, similar to clang-cl. That would mean supporting Option 1, which would provide a very clean separation between “GFortran” and “Classic Flang” modes.