[cfe-dev] [RFC] Adding support for the flang toolchain

[Hal Finkel via cfe-dev]

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
>>> 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.

Thanks again,
Hal

>
> Joerg
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory