[PATCH] D105811: [flang][driver] Delete `f18` (i.e. the old Flang driver)

[Kiran Chandramohan via Phabricator via llvm-commits]

kiranchandramohan added a comment.

In D105811#2892928 <https://reviews.llvm.org/D105811#2892928>, @awarzynski wrote:

> In D105811#2891108 <https://reviews.llvm.org/D105811#2891108>, @kiranchandramohan wrote:
>
>> I get some build errors like the following with this patch.
>>
>>   c++ -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/flang/lib/Frontend -I/home/kircha02/llvm-project/flang/lib/Frontend -I/home/kircha02/llvm-project/flang/include -Itools/flang/include -Iinclude -I/home/kircha02/llvm-project/llvm/include -isystem /home/kircha02/llvm-project/llvm/../mlir/include -isystem tools/mlir/include -isystem tools/clang/include -isystem /home/kircha02/llvm-project/llvm/../clang/include -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wmisleading-indentation -fdiagnostics-color -ffunction-sections -fdata-sections -Wno-deprecated-copy -fno-strict-aliasing -fno-semantic-interposition -O3 -DNDEBUG  -fno-exceptions -fno-rtti -std=c++17 -MD -MT tools/flang/lib/Frontend/CMakeFiles/obj.flangFrontend.dir/CompilerInvocation.cpp.o -MF tools/flang/lib/Frontend/CMakeFiles/obj.flangFrontend.dir/CompilerInvocation.cpp.o.d -o tools/flang/lib/Frontend/CMakeFiles/obj.flangFrontend.dir/CompilerInvocation.cpp.o -c /home/kircha02/llvm-project/flang/lib/Frontend/CompilerInvocation.cpp
>>   /home/kircha02/llvm-project/flang/lib/Frontend/CompilerInvocation.cpp: In function 'bool ParseFrontendArgs(Fortran::frontend::FrontendOptions&, llvm::opt::ArgList&, clang::DiagnosticsEngine&)':
>>   /home/kircha02/llvm-project/flang/lib/Frontend/CompilerInvocation.cpp:105:36: error: 'class clang::DiagnosticsEngine' has no member named 'getNumErrors'; did you mean 'unsigned int clang::DiagnosticsEngine::NumErrors'? (not accessible from this context)
>>     105 |   unsigned numErrorsBefore = diags.getNumErrors();
>>
>> Build steps used,
>>
>>   cmake -G Ninja ../llvm -DLLVM_ENABLE_PROJECTS="flang;clang;mlir;openmp" -DLLVM_TARGETS_TO_BUILD=AArch64 -DCMAKE_BUILD_TYPE=Release
>>   nice -n 10 ninja
>
> @kiranchandramohan I am not able to reproduce this :/ Also, the pre-merge CI seems fine and this patch does not modify `flang/lib/Frontend/CompilerInvocation.cpp`. Very odd! The error message seems incorrect though:
>
> - the failing line of code: https://github.com/llvm/llvm-project/blob/main/flang/lib/Frontend/CompilerInvocation.cpp#L105 (calls `clang::DiagnosticsEngine::getNumErrors`)
> - the declaration of `clang::DiagnosticsEngine::getNumErrors` (public member method): https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/Diagnostic.h#L1716
>
> Perhaps there was another error earlier?

Works fine on a fresh build.

>> 1. I am guessing the default assumption is that the dependency on Clang will be permanent and there are no plans to remove the dependency.
>
> No. Lifting `clangDriver` would be good for both Flang and Clang, but it will require a non-trivial amount of effort. It's been deprioritised in favour of other work items that are likely to bring comparable benefits at a lower cost (e.g. code-gen support).

I am guessing that upstreaming flang, feature-parity with classic-flang (Fortran + OpenMP) and productisation of llvm/flang are always going to be more important than removing the dependency. So the dependency is likely to stay.

>> 1. Will this cause MLIR to have a dependency on Clang too (which might run into issues with the MLIR team)? Or is this again a driver induced dependency?
>
> I am not too familiar with Flang's dependency on MLIR, but I don't see why Flang's dependency on Clang would make MLIR require Clang to build. As long as MLIR does not require Flang to build, all should be fine :) Perhaps I misunderstood your question?

Flang and MLIR have OpenMP support through the OpenMP dialect. If for OpenMP based offloading, flang has a dependency on clang then it might be the case that MLIR has as well.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105811/new/

https://reviews.llvm.org/D105811