llvm dev - Sep 2017 - fortran compiler merge?

Is there any updated information on the plans regarding merging the new
fortran compiler support into the existing svn llvm tree? Is that going to
happen in the llvm 6.0 time frame or is that being pushed off until llvm
7.0?
                Jack
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170905/fa1ee238/attachment.html>

Hi, Jack,

We'll need to have a community discussion about how to approach this 
issue. That hasn't happened yet.

Thanks again,
Hal

On 09/05/2017 09:40 AM, Jack Howarth via llvm-dev wrote:
>    Is there any updated information on the plans regarding merging the 
> new fortran compiler support into the existing svn llvm tree? Is that 
> going to happen in the llvm 6.0 time frame or is that being pushed off 
> until llvm 7.0?
>                 Jack
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170905/2f034233/attachment.html>

On Tue, Sep 05, 2017 at 11:30:22AM -0500, Hal Finkel via llvm-dev
wrote:
> We'll need to have a community discussion about how to approach this
issue.
> That hasn't happened yet.
I've checked an older clang driver diff. There are low-hanging fruits
that could be committed immediately like the addition of option help
texts. There are parts that clearly need to be redone like the include
path handling which seems to duplicate existing multilib logic in the
Linux driver. My biggest problem is that the interface between the
clang driver and the actual flang binaries, which seems to be heavily
based on magic numbers. That's not something I find acceptable from the
LLVM perspective.

Joerg