Mehdi AMINI via llvm-dev
2020-Apr-07 23:22 UTC
[llvm-dev] F18 ready to be merged + preview of merge
Attached is the log. I'm building with: clang version 10.0.0 (https://github.com/llvm/llvm-project/ 3a6da1122b990386edeba0987d0d1fdc9c8dc53d) Target: x86_64-unknown-linux-gnu Thread model: posix On some Ubuntu-like distribution. I also ran with ASAN once and it found a bunch of leaks in bin/tco. Best, -- Mehdi On Tue, Apr 7, 2020 at 4:36 AM Richard Barton <Richard.Barton at arm.com> wrote:> Hi Medhi > > > > Definitely not expected, the tests should all pass. > > > > As well as what David asked, the verbose output from lit would be helpful > for debugging too. > > > > Thanks for giving it a try. > > Rich > > > > *From:* David Truby <David.Truby at arm.com> > *Sent:* 7 April, 2020 11:49 > *To:* Richard Barton <Richard.Barton at arm.com>; Mehdi AMINI < > joker.eph at gmail.com> > *Cc:* llvm-dev at lists.llvm.org > *Subject:* Re: [llvm-dev] F18 ready to be merged + preview of merge > > > > Hi Mehdi, > > > > I can't replicate those failures at my end, could you let me know what OS, > compiler and CMake flags you're using so I can try and reproduce? > > > > Thanks! > > David Truby > ------------------------------ > > *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Mehdi > AMINI via llvm-dev <llvm-dev at lists.llvm.org> > *Sent:* 07 April 2020 06:44 > *To:* Richard Barton <Richard.Barton at arm.com> > *Cc:* llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> > *Subject:* Re: [llvm-dev] F18 ready to be merged + preview of merge > > > > 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/ > > > > 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). > > · 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 > > > > 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/20200407/69ccaf29/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: flang-fail.log Type: application/octet-stream Size: 18688 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200407/69ccaf29/attachment.obj>
David Truby via llvm-dev
2020-Apr-07 23:50 UTC
[llvm-dev] F18 ready to be merged + preview of merge
Hi Mehdi,
This looks like an issue somewhere in how CMake/lit is configuring the tests.
Could you provide me with your CMake command line?
I'll take a look at this first thing tomorrow but I need to know the CMake
options used to reproduce it.
Thanks
David
________________________________
From: Mehdi AMINI <joker.eph at gmail.com>
Sent: 08 April 2020 00:22
To: Richard Barton <Richard.Barton at arm.com>
Cc: David Truby <David.Truby at arm.com>; llvm-dev at lists.llvm.org
<llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] F18 ready to be merged + preview of merge
Attached is the log.
I'm building with:
clang version 10.0.0 (https://github.com/llvm/llvm-project/
3a6da1122b990386edeba0987d0d1fdc9c8dc53d)
Target: x86_64-unknown-linux-gnu
Thread model: posix
On some Ubuntu-like distribution.
I also ran with ASAN once and it found a bunch of leaks in bin/tco.
Best,
--
Mehdi
On Tue, Apr 7, 2020 at 4:36 AM Richard Barton <Richard.Barton at
arm.com<mailto:Richard.Barton at arm.com>> wrote:
Hi Medhi
Definitely not expected, the tests should all pass.
As well as what David asked, the verbose output from lit would be helpful for
debugging too.
Thanks for giving it a try.
Rich
From: David Truby <David.Truby at arm.com<mailto:David.Truby at
arm.com>>
Sent: 7 April, 2020 11:49
To: Richard Barton <Richard.Barton at arm.com<mailto:Richard.Barton at
arm.com>>; Mehdi AMINI <joker.eph at gmail.com<mailto:joker.eph at
gmail.com>>
Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] F18 ready to be merged + preview of merge
Hi Mehdi,
I can't replicate those failures at my end, could you let me know what OS,
compiler and CMake flags you're using so I can try and reproduce?
Thanks!
David Truby
________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces
at lists.llvm.org>> on behalf of Mehdi AMINI via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
Sent: 07 April 2020 06:44
To: Richard Barton <Richard.Barton at arm.com<mailto:Richard.Barton at
arm.com>>
Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
<llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
Subject: Re: [llvm-dev] F18 ready to be merged + preview of merge
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<mailto: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/
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).
* 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
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<mailto: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/20200407/58340c45/attachment-0001.html>
David Truby via llvm-dev
2020-Apr-08 21:20 UTC
[llvm-dev] F18 ready to be merged + preview of merge
Hi Mehdi,
I'm unable to reproduce this issue right now. Are you ok with us going ahead
with the merge (given that flang will not be built by default!) and fixing these
build issues with a high priority post merge? The advantage of that will be that
we will all be on the same commit of LLVM+flang, rather than trying to match
commit versions across the two, so build issues will be much easier to debug!
Thanks
David Truby
________________________________
From: Mehdi AMINI <joker.eph at gmail.com>
Sent: 08 April 2020 00:22
To: Richard Barton <Richard.Barton at arm.com>
Cc: David Truby <David.Truby at arm.com>; llvm-dev at lists.llvm.org
<llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] F18 ready to be merged + preview of merge
Attached is the log.
I'm building with:
clang version 10.0.0 (https://github.com/llvm/llvm-project/
3a6da1122b990386edeba0987d0d1fdc9c8dc53d)
Target: x86_64-unknown-linux-gnu
Thread model: posix
On some Ubuntu-like distribution.
I also ran with ASAN once and it found a bunch of leaks in bin/tco.
Best,
--
Mehdi
On Tue, Apr 7, 2020 at 4:36 AM Richard Barton <Richard.Barton at
arm.com<mailto:Richard.Barton at arm.com>> wrote:
Hi Medhi
Definitely not expected, the tests should all pass.
As well as what David asked, the verbose output from lit would be helpful for
debugging too.
Thanks for giving it a try.
Rich
From: David Truby <David.Truby at arm.com<mailto:David.Truby at
arm.com>>
Sent: 7 April, 2020 11:49
To: Richard Barton <Richard.Barton at arm.com<mailto:Richard.Barton at
arm.com>>; Mehdi AMINI <joker.eph at gmail.com<mailto:joker.eph at
gmail.com>>
Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] F18 ready to be merged + preview of merge
Hi Mehdi,
I can't replicate those failures at my end, could you let me know what OS,
compiler and CMake flags you're using so I can try and reproduce?
Thanks!
David Truby
________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces
at lists.llvm.org>> on behalf of Mehdi AMINI via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
Sent: 07 April 2020 06:44
To: Richard Barton <Richard.Barton at arm.com<mailto:Richard.Barton at
arm.com>>
Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
<llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
Subject: Re: [llvm-dev] F18 ready to be merged + preview of merge
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<mailto: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/
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).
* 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
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<mailto: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/20200408/c77f072e/attachment.html>
Mehdi AMINI via llvm-dev
2020-Apr-09 01:03 UTC
[llvm-dev] F18 ready to be merged + preview of merge
Hi, My cmake invocation was a simple as it can be and I invoked `ninja check-flang` (after building FileCheck explicitly since you were missing a dependency). However it works if I run first `ninja` and then `ninja check-flang`, so it seems like the test target is missing dependencies. This is not a blocker to me, it is perfectly fine to fix incrementally in tree. Best, -- Mehdi On Wed, Apr 8, 2020 at 2:20 PM David Truby <David.Truby at arm.com> wrote:> Hi Mehdi, > > I'm unable to reproduce this issue right now. Are you ok with us going > ahead with the merge (given that flang will not be built by default!) and > fixing these build issues with a high priority post merge? The advantage of > that will be that we will all be on the same commit of LLVM+flang, rather > than trying to match commit versions across the two, so build issues will > be much easier to debug! > > Thanks > David Truby > ------------------------------ > *From:* Mehdi AMINI <joker.eph at gmail.com> > *Sent:* 08 April 2020 00:22 > *To:* Richard Barton <Richard.Barton at arm.com> > *Cc:* David Truby <David.Truby at arm.com>; llvm-dev at lists.llvm.org < > llvm-dev at lists.llvm.org> > *Subject:* Re: [llvm-dev] F18 ready to be merged + preview of merge > > Attached is the log. > I'm building with: > > clang version 10.0.0 (https://github.com/llvm/llvm-project/ > 3a6da1122b990386edeba0987d0d1fdc9c8dc53d) > Target: x86_64-unknown-linux-gnu > Thread model: posix > > On some Ubuntu-like distribution. > > I also ran with ASAN once and it found a bunch of leaks in bin/tco. > > Best, > > -- > Mehdi > > > > On Tue, Apr 7, 2020 at 4:36 AM Richard Barton <Richard.Barton at arm.com> > wrote: > > Hi Medhi > > > > Definitely not expected, the tests should all pass. > > > > As well as what David asked, the verbose output from lit would be helpful > for debugging too. > > > > Thanks for giving it a try. > > Rich > > > > *From:* David Truby <David.Truby at arm.com> > *Sent:* 7 April, 2020 11:49 > *To:* Richard Barton <Richard.Barton at arm.com>; Mehdi AMINI < > joker.eph at gmail.com> > *Cc:* llvm-dev at lists.llvm.org > *Subject:* Re: [llvm-dev] F18 ready to be merged + preview of merge > > > > Hi Mehdi, > > > > I can't replicate those failures at my end, could you let me know what OS, > compiler and CMake flags you're using so I can try and reproduce? > > > > Thanks! > > David Truby > ------------------------------ > > *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Mehdi > AMINI via llvm-dev <llvm-dev at lists.llvm.org> > *Sent:* 07 April 2020 06:44 > *To:* Richard Barton <Richard.Barton at arm.com> > *Cc:* llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> > *Subject:* Re: [llvm-dev] F18 ready to be merged + preview of merge > > > > 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/ > > > > 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). > > · 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 > > > > 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/20200408/8cd8da12/attachment-0001.html>