similar to: Plan for landing flang in monorepo

Can you elaborate on this? - to move the std::string/string_view/StringRef changes to pre-merge unless you're going to have someone dedicated to handling them post-merge (rather than "time permits"). The C vs C++ ism here is fairly strong and I'd like to get the C-style string handling out fairly quickly. I understood this item to be looking into replacing uses of std::string

Hi Eric, Old flang certainly uses C-style strings but f18 uses std::string with few exceptions. Most of the instances in f18 of “char *” aren’t really strings in the C sense – they’re not null terminated and are really just pointers into raw or cooked source files/streams. I can’t think of an instance where the compiler dynamically allocates an array of characters and uses it as a C string. -

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

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

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

Hi Eric, Renato Thanks again for the engagement and challenge on this, it is really useful feedback to know what we need to do to get F18 into the project in a way that everyone is happy with. I have tried to give timelines on the points addressed below where I can today. Clearly we need to do some work on points 8-11, but are the above plans/answers to points 1-7 sufficient at this stage and

Hi llvm-dev We have not been able to complete all the work we need to do before merging F18 into LLVM as Flang so we will not be dong that today as previously announced. We propose to slip this back a week to let us finish off the last bits of work. All code changes are in review as of Friday. If you want more detail, you can see the exact status here:

Hi all Thanks for all the replies and engagement on this issue. First point, given the state of discussions today I would like to propose that we don't start the merge at 10:00 GMT on Monday 13th as proposed and we delay by at least 24 hours until after the scheduled F18 technical call on Monday afternoon. In order to help compile a plan of action, I've tried to compile a list of the

Hi Eric, Apologies, I failed to disambiguate clearly, because there are multiple projects named flang. I was referring to the "new" flang, whose repository is currently found at https://github.com/flang-compiler/f18. It will land in the monorepo under a directory called "/flang/". f18 has been approved to join, for reference see "[llvm-dev] f18 is accepted as part of

Hi All, The flang project (a Fortran compiler) is getting ready to join the monorepo. We intend to preserve the existing history by rewriting the existing commits as a linear series of commits on top of llvm-project. I understand the flang community would like to do this before the LLVM 10 branch in due in mid January, so please speak up soon if you see anything needing fixing in what I

Hi Hal, On Tue, Jan 7, 2020 at 3:38 PM Finkel, Hal J. via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 1/7/20 4:38 PM, Doerfert, Johannes via llvm-dev wrote: > > On 01/07, David Blaikie via llvm-dev wrote: > > Hey Peter - would you be able to link to/describe the history on this > process/decision. I can find one old thread where this was first proposed

Hal, Eric, Johannes, David and Peter, I lead the development of OpenMP for AMD GPUs and work with others at AMD who support OpenMP on AMD CPUs. On behalf of our development teams, we greatly appreciate your efforts to move the development of flang into a subproject in the llvm-project repository and to integrate this development effort into the overall LLVM development community. Like most

Hi, On Wed, Jan 8, 2020 at 6:54 PM Finkel, Hal J. via llvm-dev < llvm-dev at lists.llvm.org> wrote: > FYI to everyone: If you have things that you would like to see done > before a merge of Flang, please reply with as many details as you have > time to provide (and if you have things that you would like to see done > soon, but you're comfortable with them happening after

On 18/12/2019 21:49, Eric Christopher wrote: > Yes, I looked through those sources and a number of my questions > around which clang versions have been supported and directory > structure. I think the only difference is removing the direct > questions about earlier flang, but I still don't see code generation > or uses of llvm libraries that would conform to "written in

On 01/07, David Blaikie via llvm-dev wrote: > Hey Peter - would you be able to link to/describe the history on this > process/decision. I can find one old thread where this was first proposed ( > http://lists.llvm.org/pipermail/llvm-dev/2019-February/130497.html ) with > some general positive responses and a lot of questions. > > I see there's a flang-dev list, though

On Mon, 13 Jan 2020 at 06:50, Eric Christopher <echristo at gmail.com> wrote: > I don't really consider this addressed without a plan of action (before merge) that contains a list of standard llvm support libraries that would be used in addition to things being removed (pretty much all use of C++ c* headers and more?) as well as staffing and approximate ETAs. Agreed. > I think

Hi All, As discussed before Christmas, this is a reminder that we intend to merge flang on the 13th January (next Monday) before the llvm-10 branch. At the moment I'm proposing to do it at 10am GMT. I can be flexible on this point if it requires close coordination with anyone in another timezone, just let me know. Previous discussion was in [llvm-dev] Flang landing in the monorepo

Hi all F18 merging has finished so commit access should be back to normal. Thanks Rich > -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Richard > Barton via llvm-dev > Sent: 9 April, 2020 16:08 > To: llvm-dev at lists.llvm.org > Subject: [llvm-dev] F18 upstreaming Now! > > Hi all > > We are about to merge F18

I think it would probably make the most sense to land this as a single merge-commit (from the 2700-commit rewritten history you've created) onto llvm-project master, rather than as 2700 individual toplevel commits to master. (Which means: disable the merge-commit prohibition in the github configuration, temporarily, push this commit, and then enable it again). On Tue, Dec 17, 2019 at 5:10 PM

On Wed, 8 Jan 2020 at 01:48, Eric Christopher via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I am in favor of having a flang front end in tree. I have concerns about the design of flang versus other front ends, the lack of llvm based library use, and a number of other things that I tried to enumerate in previous emails. I don't know if anything has changed and the responses I got