[llvm-dev] F18 ready to be merged + preview of merge

Mon Apr 6 22:44:34 PDT 2020

Hi,

This sounds reasonable to me overall. There are some CMake issue to go
through (I need to dig into it a bit).

When I run `ninja check-flang` at the moment (after fixing CMake) I end up
with:

Testing Time: 16.22s
********************
Failing Tests (12):
    Flang :: Lower/pre-fir-tree04.f90
    Flang :: Semantics/allocate11.f90
    Flang :: Semantics/allocate13.f90
    Flang :: Semantics/c_f_pointer.f90
    Flang :: Semantics/call04.f90
    Flang :: Semantics/canondo16.f90
    Flang :: Semantics/coarrays01.f90
    Flang :: Semantics/critical02.f90
    Flang :: Semantics/doconcurrent01.f90
    Flang :: Semantics/dosemantics11.f90
    Flang :: Semantics/resolve50.f90
    Flang :: Semantics/resolve87.f90

Are these known issues?

-- 
Mehdi

On Mon, Apr 6, 2020 at 7:27 AM Richard Barton via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi llvm-dev
>
> We believe we have completed enough of the agreed pre-upstreaming changes
> to start talking about merging F18 into LLVM. The live status is tracked at
> [1]. There are a few details that we have not managed to hammer out and we
> propose to tackle inside the LLVM monorepo. I have put a summary of these
> at the bottom of this mail.
>
> Does anyone have any objections to flang being merged into LLVM with these
> issues still in-flight? Obviously we remain committed to solving them after
> merging into LLVM?
>
> If that is all good then, as previously agreed, we want to give folks
> something more concrete to review and a bit of time to give feedback on it
> before we commit. David Truby has just now created a preview of what the
> LLVM project would look like with F18 merged in as flang. The obvious
> caveat is that both LLVM and F18 are continuing development so there will
> be additional commits on both sides of the real merge when it happens.
>
> Here is the merge preview: *https://github.com/DavidTruby/llvm-project/*
> <https://github.com/DavidTruby/llvm-project/>
>
> This branch shows:
>
>    - The commit history of F18 re-written as a straight line branch by
>    Peter Waller's script.
>    - A commit that tweaks F18's README to rename it as flang and make it
>    more relevant inside the monorepo (being reviewed under
>    *https://github.com/flang-compiler/f18/pull/909*
>    <https://github.com/flang-compiler/f18/pull/909>).
>    - The merge commit that adds F18 to the monorepo as flang
>    - A patch to the monorepo cmake that adds flang as an optionally built
>    target - see also *https://reviews.llvm.org/D72416*
>    <https://reviews.llvm.org/D72416>
>
>
> I really encourage all folks maintaining buildbots or downstream builds to
> give this a look over to make sure it works for you. For everyone else, I
> hope this looks good to you too. All feedback very welcome.
>
> If everyone is happy with that, we'll agree on a new date in the regular
> F18 community call on Monday. I'll be back in touch after that.
>
> Thanks
> Rich
>
> Remaining Details still in-progress
>
> [1] clang-format
> F18's clang-format file will have a few differences to the global
> formatting style. These are mainly ones that control alignment of code. We
> have not come to an agreement as a community on the best way forward here.
> This *flang-dev thread*
> <http://lists.llvm.org/pipermail/flang-dev/2020-March/000243.html>
> summarises the debate. We would like to continue this debate after F18
> becomes part of the monorepo.
>
> [2] llvm_unreachable
> Previously we stated that we would try to use llvm_unreachable in F18
> whenever possible. Presently, F18 has a similar function called die, but
> this is used to cover multiple run-time error cases only some of which
> should be covered by llvm_unreachable. We would like to handle all cases
> together which also means coming up with a good system for reporting ICEs.
> See *these code review comments*
> <https://github.com/flang-compiler/f18/issues/966> for details. We
> propose to start fresh on this work after F18 becomes part of the monorepo.
>
> [3] remove_if vs RemoveCarriageReturns
> Whilst removing code that manipulated C-style strings we hit upon a case
> which seemed to show that std::remove_if was a regression on certain
> targets over the current algorithm using C standard memmove. This *flang-dev
> thread* <http://lists.llvm.org/pipermail/flang-dev/2020-April/000265.html>
> summarises the situation and we are gathering further data before deciding
> what to do. We propose to continue to investigate this and make any
> necessary changes after F18 becomes part of the monorepo.
>
> [4] Doxygen infrastructure
> We are still working through the final comments on *this patch*
> <https://github.com/flang-compiler/f18/pull/1065> and hope to have it
> merged before we become part of LLVM. As this patch simply adds the
> infrastructure to add doxygen comments and there are no doxygen comments in
> F18 source at present, we think that this should not block F18's inclusion
> in the monorepo. We commit to finishing this off once F18 becomes part of
> the monorepo.
>
> Created with Microsoft OneNote 2016.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200406/33476c49/attachment.html>