As you may recall, the flang compiler by PGI is a new frontend for LLVM that, unlike past efforts, has the potential provide equal or even superior fortran support compared to other compilers (such as gfortran).
To add support for this new compiler, PGI needed to make certain modifications to the drivers that clang supports, particularly to allow clang to invoke the fortran frontend executables and the linker with the correct command-line arguments. We (myself as a lowly contributor and PGI) think that it makes sense to push these modifications upstream to ease and consolidate clang maintenance.
To be absolutely clear, this would NOT introduce a new burden on clang maintainers to also support a fortran compiler. To the extent that this would introduce a new burden, it would be limited to maintaining a stable command-line interface to the fortran frontend executables, the same as has been done for something like ‘link.exe’.
Please excuse incorrect formatting, as I am new to the cfe-dev list.
I did a review of the changes half a year ago. There was quite a bit of
unnecessary churn in the repo. The biggest problem from my perspective
is the massive use of magic numbers in the interface. I think that part
should be fixed on the flang side before talking about merging the
patches.
I did a review of the changes half a year ago. There was quite a bit of
unnecessary churn in the repo. The biggest problem from my perspective
is the massive use of magic numbers in the interface. I think that part
should be fixed on the flang side before talking about merging the
patches.
For the record, the churn has settled down quite a bit (maybe ~15 lines of changes per month now). The magic numbers still appear to be present though; that would need to be fixed. However, while that’s in progress, are there any other potential issues that need to be resolved as well (I’d like to tackle them all at once rather than iterating)?
> I did a review of the changes half a year ago. There was quite a bit of
> unnecessary churn in the repo. The biggest problem from my perspective
> is the massive use of magic numbers in the interface. I think that part
> should be fixed on the flang side before talking about merging the
> patches.
For the record, the churn has settled down quite a bit (maybe ~15 lines of
changes per month now).
I meant more that the clang fork contained quite a few purely cosmetical
changes, not that it changed regulary.
The magic numbers still appear to be present though; that would need to
be fixed. However, while that's in progress, are there any other
potential issues that need to be resolved as well (I'd like
to tackle them all at once rather than iterating)?
Iteration is likely unavoidable. Ideally, a large part of the option
handling should be table-driven and not hard-coded. The toolchain part
needed a lot of refactoring in the version I checked.
One high-level question is whether shoe-horning the
gfortran-compatibility interface into the clang driver is really
desirable. I.e. it is a mostly orthogonal set of command line flags and
that seems pretty bad from a design perspective. It's likely going to
repeat the problems of clang-cl.exe over and over again. I'd like some
input from folks like Hal on the impact on the UX here. In other words,
I wonder if having a consistent and integrated approach and maybe a
compat-wrapper script as flang isn't better long term.
I did a review of the changes half a year ago. There was quite a bit of
unnecessary churn in the repo. The biggest problem from my perspective
is the massive use of magic numbers in the interface. I think that part
should be fixed on the flang side before talking about merging the
patches.
For the record, the churn has settled down quite a bit (maybe ~15 lines of
changes per month now).
I meant more that the clang fork contained quite a few purely cosmetical
changes, not that it changed regulary.
I'm pretty sure that I had them remove those some months ago.
The magic numbers still appear to be present though; that would need to
be fixed. However, while that's in progress, are there any other
potential issues that need to be resolved as well (I'd like
to tackle them all at once rather than iterating)?
Iteration is likely unavoidable. Ideally, a large part of the option
handling should be table-driven and not hard-coded. The toolchain part
needed a lot of refactoring in the version I checked.
One high-level question is whether shoe-horning the
gfortran-compatibility interface into the clang driver is really
desirable. I.e. it is a mostly orthogonal set of command line flags and
that seems pretty bad from a design perspective. It's likely going to
repeat the problems of clang-cl.exe over and over again. I'd like some
input from folks like Hal on the impact on the UX here. In other words,
I wonder if having a consistent and integrated approach and maybe a
compat-wrapper script as flang isn't better long term.
First, Clang currently can serve as a gfortran driver. One question we need to answer, if we move forward to integrating Flang support into Clang, is what to do with the gfortran-driving capability. I'd recommend that, at least in the short/medium-term, we add some flag to switch which compiler is used by default for Fortran code. I don't think having "flang foo.f90" use flang and "clang foo.f90" use gfortran is desirable.
Flang needs a driver, and that driver needs to find system libraries, sanitizer libraries, include directories, and so on. It needs large parts, perhaps nearly all, of what Clang's driver does. As a result, I think that it makes sense to reuse that code. Given that Clang already processes gfortran options (because it can serve as a gfortran driver), extending the command-line options in this regard does not seem problematic. Regarding the orthogonality of the command-line options, we probably should segregate any Fortran-specific options into a separate .td file (regardless of what happens with Flang) - I agree that having them mixed in with everything else is suboptimal.
Regarding clang-cl, I actually find the command-line-options personality capability a strength of Clang (although it can be painful). Nevertheless, I don't think that's what we're talking about here.
Changes to user-facing command-line options for flang will be somewhat painful now and even more painful as we go along – flang has already been integrated into some upstream build systems with the expectation that compiler options will not change. Having said that, changing the command-line interface may still be justified but I’d like to pin this down now so that we can avoid even more future pain.
We'll need to come up with a plan for the style of command-line options and if/how to support other dialects. I'd recommend giving first priority to gfortran-compatible flags, as that's likely most convenient to both us (because we already support most of them, especially those common with gcc/g++) and a majority of our users (most of whom already have some build configuration that works with gfortran). New flags should be added consist with our general conventions.
The current mix of gfortran-style and PGI-style flags doesn't clearly serve anyone well. I agree, however, that we should nail this down sooner rather than later.