search for: f18

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 issue...

...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):...

.... > > 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 > --...

...like the frontend to be useful in the many ways that Clang is useful: not just as a frontend, but also for static analysis and tooling. Recognizing that the current flang's code base will not meet these needs, we started a ground-up rewrite of the frontend in modern C++. This effort is called f18. At this point, we have documented and implemented a healthy subset of the compiler for symbol tables and scoping, name resolution, USE statements and module files, constant representation, constant folding and much of declaration, label and expression semantics. The parser handles all of Fortran...

Hello, This is regarding recent/ongoing discussions about F18 being merged in LLVM. I was going through these threads, and I found few important points which were possibly left unanswered (or I might have missed few threads). URL: http://lists.llvm.org/pipermail/flang-dev/2019-December/000120.html Point: Is (3) AST -> FIR -> MLIR LLVM-IR -> LLVM...

On Mon, Feb 25, 2019 at 5:46 PM Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Feb 25, 2019 at 10:06 AM Stephen Scalpone via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> * The current f18 code will be committed to the new LLVM subproject. The >> f18 code is a set of libraries that implements the Fortran compiler. >> > > Awesome. This is an important aspect of the design of LLVM projects IMO -> > they build their functionality primarily as re-usable libraries...

Should I be concerned? [root@fs1 ~]# cobbler import --name=F18 --path=rsync://mirrors.kernel.org/fedora/releases/18/Fedora/x86_64/os --arch=x86_64 task started: 2013-01-18_062009_import task started (id=Media import, time=Fri Jan 18 06:20:09 2013) Found a redhat compatible signature: Packages adding distros creating new distro: F18-x86_64 creating new profil...

Hi llvm-dev It's been a few weeks since I last gave an update on F18 and our progress on readying it for inclusion into the monorepo. Last time we discussed this the community challenged us to make the F18 source code look more like an LLVM project and to come up with a plan and schedule for completing this work (http://lists.llvm.org/pipermail/llvm-dev/2020-January...

...during the MLIR landing discussion found at http://lists.llvm.org/pipermail/llvm-dev/2019-November/136813.html. As with MLIR, we rewrite the commits so that flang's work all appears to happen in the flang directory, starting with llvm-project master as it appears today. The topology of the f18 history was fairly interesting, which is why I ended up writing a new program to rewrite it rather than using an existing one. === Key links * Resulting tree of the rewrite: https://github.com/peterwaller-arm/f18/tree/rewritten-history-v2-llvm-project-merge * Rewritten history, with flang comm...

Following up on my earlier email. If there is a commitment to checking in f18 already, feel free to disregard it. I went and took a little bit closer look at the sources and want to share some of the findings in case if anyone is interested. Disclosure: I contribute to Fort <http://fort-compiler.org/> (fort-compiler.org), which is the fork of the front-end David Gr...

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:...

On Mon, Feb 25, 2019 at 2:45 PM Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Feb 25, 2019 at 10:06 AM Stephen Scalpone via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> * The current f18 code will be committed to the new LLVM subproject. The >> f18 code is a set of libraries that implements the Fortran compiler. >> > > Awesome. This is an important aspect of the design of LLVM projects IMO -> > they build their functionality primarily as re-usable libraries...

...think it could turn it from a fairly arduous task to one that's a little easier. Thanks! -eric On Thu, Feb 20, 2020 at 9:41 AM Richard Barton <Richard.Barton at arm.com<mailto:Richard.Barton at arm.com>> wrote: Hi llvm-dev It's been a few weeks since I last gave an update on F18 and our progress on readying it for inclusion into the monorepo. Last time we discussed this the community challenged us to make the F18 source code look more like an LLVM project and to come up with a plan and schedule for completing this work (http://lists.llvm.org/pipermail/llvm-dev/2020-January...

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 would not block a merge of F18 to the mo...

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...

...ring for code reuse is our default - > developing similar functionality without reusing existing, related > code is what, in general, requires specific justification. My experience with this question has been the same as Petr's. I keep asking about it and keep getting radio silence from f18 developers. Some other people (including Petr) have jumped into the discussion but frankly, I have not seen a lot of interest in f18 tooling from the f18 developers and I'm very concerned about that. f18 development so far has been opaque. There's a biweekly call (which I'm sure many...

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 LLVM project!", Chriss Lattner, April 10 2019: http://lists.llvm.org/pipermail/llvm-dev/2019-April/131703.html. I would lik...

Hi all, On a F18, I installed livecd-tools-18.15-1 I downloaded CenOS6.x minimal .iso and with livecd-iso-to-disk the resulting USB is never bootable: the computer doesnt boot on it. Tested on many computers. The fact is I succeded to install CentOS on a Netbook (no CD/DVD tray), but I dont remember how I invo...

...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 waiting until after the llvm 10 branch would probably be best at this point. That will give a lot of time for cleanup and to make f18 a much more reasonable "preview" including code generation in a forthcoming release in about 6 mos. Before this thread, I thought the progress of F18 was much further than it is. My initial comments assumed it. Now, I am surprised it's not using LLVM API yet (a clear and consistent...

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 concerns that folks have raised so far. I think all these have been addressed (please correct me if you think otherwise) 1. Audit trail/visibility of code review [Addressed by Pe...