[cfe-dev] [RFC] Adding support for the flang toolchain
Hal Finkel via cfe-dev
cfe-dev at lists.llvm.org
Tue Dec 19 22:05:23 PST 2017
On 12/18/2017 06:29 PM, Joerg Sonnenberger via cfe-dev wrote:
> On Mon, Dec 18, 2017 at 05:40:31PM -0600, xoviat wrote:
>>> 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
>> 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.
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
More information about the cfe-dev