search for: scalpon

...ments For those who don’t like it, is the currently documented policy broken enough to be important to changing? I assume you wouldn’t recommend a massive rewrite of the codebase, so we’re going to be with this for quite some time. -Chris > On Jun 22, 2020, at 1:36 PM, Steve Scalpone via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Did this conversation reach a conclusion? > > My ad hoc tally says that a slight majority of the responders preferred to fully brace statements and no one wanted to totally eliminate braces. > > Th...

...ing LLVM build in any way. Patches to integrate the build system are expected in the near future, and be subject to the normal LLVM code review processes. I understand that code generation is a work in progress and is expected to start landing in the not too distant future. Other people (Steve Scalpone, cc'd, and others) can perhaps speak to this more than me. In terms of using LLVM ADTs, etc, I expect that once flang is part of the monorepo, there will be a greater usage of those things. > Chris's earlier acceptance aside I don't see any evidence of code > review as part of...

On 4/10/19, 12:15 PM, "llvm-dev on behalf of Chris Lattner via llvm-dev" wrote: > The foundation recommends considering a new name for the project (e.g. flang or simply fortran) > to be more accessible and obvious for new contributors - in addition to being the repository name, > it will also be the base stem for mailing lists and other project related material. The f18

Hi, everyone, As you may know, NVIDIA has developed an open-source Fortran frontend for LLVM (http://flang-compiler.org), which consists of the flang frontend itself along with the corresponding Fortran runtime library. The existing frontend's code is mostly written in C, and while a production-quality implementation, does not follow modern software-engineering practices. Our long-standing

Did this conversation reach a conclusion? My ad hoc tally says that a slight majority of the responders preferred to fully brace statements and no one wanted to totally eliminate braces. The technical arguments for fully braced statements were 1) it's considered a slightly safer coding style and 2) commit diffs with fully braced statements may be slightly more to the point. I didn't

On Tue, 23 Jun 2020 at 03:30, Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Mon, Jun 22, 2020 at 2:38 PM Steve Scalpone via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Me? I would modify the first sentence from: >> >> > When writing the body of an if, else, or loop statement, >> > omit the braces to avoid unnecessary line noise. However, >> > braces should...

...r those who don’t like it, is the currently documented policy broken enough to be important to changing? > > I assume you wouldn’t recommend a massive rewrite of the codebase, so we’re going to be with this for quite some time. > > -Chris > >> On Jun 22, 2020, at 1:36 PM, Steve Scalpone via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Did this conversation reach a conclusion? >> >> My ad hoc tally says that a slight majority of the responders preferred to fully brace statements and no one wanted to totally eliminate braces. >> >> Th...

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

...v at lists.llvm.org; Matt Arsenault <arsenm2 at gmail.com> >> Subject: Re: [llvm-dev] Codifying our Brace rules- >> >> On Tue, 23 Jun 2020 at 03:30, Mehdi AMINI via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> On Mon, Jun 22, 2020 at 2:38 PM Steve Scalpone via llvm-dev <llvm- >> dev at lists.llvm.org> wrote: >>>> Me? I would modify the first sentence from: >>>> >>>>> When writing the body of an if, else, or loop statement, >>>>> omit the braces to avoid unnecessary line noise. Howeve...

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

...oken > enough to be important to changing? > >> > >> I assume you wouldn’t recommend a massive rewrite of the codebase, so > we’re going to be with this for quite some time. > >> > >> -Chris > >> > >>> On Jun 22, 2020, at 1:36 PM, Steve Scalpone via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >>> > >>> Did this conversation reach a conclusion? > >>> > >>> My ad hoc tally says that a slight majority of the responders > preferred to fully brace statements and no one wanted to...

On 01/03/2019 17:26, Troy Johnson via llvm-dev wrote: > This RFC started a good discussion and I’d like to hear responses from its author > to all of the points that have been made so far. > >   > > FWIW, I’m also in favor of reusing as much from Clang as practical.  In fact, with> the combined repo now, it might make sense to factor out some common front end code > that

...uct while it is being developed. And then there is also the argument for reusing Clang tooling, which David Greene keeps making, though that idea does not seem to get a lot of interest. Best, Petr On 2/27/19 1:55 PM, Chris Lattner via llvm-dev wrote: > On Feb 25, 2019, at 10:06 AM, Stephen Scalpone via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> We're committed to developing LLVM's Fortran frontend for years to >> come, and together with other members of the LLVM community (e.g., >> ARM, US Dept of Energy)...

...f clang-dev, etc. is confusing to those outside of the community. I think that we should not repeat that kind of difference, and we should name the mailing lists, directories, etc. based on "flang" as well. Thanks again, Hal > > -David > > Stephen Scalpone via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> On 4/10/19, 12:15 PM, "llvm-dev on behalf of Chris Lattner via llvm-dev" wrote: >> >>> The foundation recommends considering a new name for the project (e.g. flang or simply fortran) >>> to be...

...iver/frontend code as possible (this was previously proposed in [2]). 2. We want to avoid dependencies from Flang to Clang, both long-term (strong requirement) and short-term (might be difficult to achieve). This has recently come up in a discussion on one of our early patches [3] (tl;dr Steve Scalpone, the code owner of Flang, would prefer us to avoid this dependency), and was also suggested before by Eric Christopher [10]. 3. We will move the code that can be shared between Flang and Clang (and other projects) to LLVM. This idea has already come up on llvm-dev before [7] (in a slightly di...

...ists.llvm.org; Matt Arsenault <arsenm2 at gmail.com> > > Subject: Re: [llvm-dev] Codifying our Brace rules- > > > > On Tue, 23 Jun 2020 at 03:30, Mehdi AMINI via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > > > On Mon, Jun 22, 2020 at 2:38 PM Steve Scalpone via llvm-dev <llvm- > > dev at lists.llvm.org> wrote: > > >> > > >> Me? I would modify the first sentence from: > > >> > > >> > When writing the body of an if, else, or loop statement, > > >> > omit the braces to avoid...

...previously proposed in [2]). >> >> 2. We want to avoid dependencies from Flang to Clang, both long-term >> (strong requirement) and short-term (might be difficult to achieve). >> This has recently come up in a discussion on one of our early patches >> [3] (tl;dr Steve Scalpone, the code owner of Flang, would prefer us to >> avoid this dependency), and was also suggested before by Eric >> Christopher [10]. >> >> 3. We will move the code that can be shared between Flang and Clang (and >> other projects) to LLVM. This idea has already come up...

...diagnostics to the corresponding namespaces (e.g. diagnostics from DiagnosticSemaKinds.td should live in the clang::sema namespace). Or is there more to it? On 03/06/2020 01:37, Richard Smith wrote: > One big asterisk on the above: will Flang want an integrated C > preprocessor? As S. Scalpone already mentioned, Flang has its own preprocessor. The idea of re-using Clang's C preprocessor is a bit out-of-scope for this RFC and we have not considered it. We definitely want to make sure that we don't create any unnecessary obstacles in case somebody decides to try this in the fu...

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