Flang Development Priorities

[John Leidel]

All, as promised, we crafted a basic list of development items that are of interest.  We generated these items by analyzing the current code base and selecting items of high value to the list of known user communities.  This document is not designed to be the end list of development items.  However, it does serve as an excellent starting point to pushing Flang development forward.  If you have comments, edits or would like to own any of the items documented in the list, please respond to the overall mailing list such that we can capture the discussion.  

Thanks again to Carlo Bertolli and Kevin O'Brien for help in crafting and reviewing this list!

Best Regards,

John Leidel 

[Damian Rouson]

All,

Looking at the Flang Development Tasks document, I wonder if there are sensible alternatives to the chronological approach of focusing first on standards that are 20 or more years old.  For a project in its nascent phase, would there be any value in taking a more holistic view from the vantage point of modern Fortran rather than focusing on an older subset of the language first?  More specifically, are there (1) toolkits that can help you leapfrog the stages in which you might get stuck with the chronological approach and are there (2) common pitfalls likely to befall you if decisions based on older standards calcify in a design that makes it harder to evolve to support the newer standards?

Regarding (1) above, I'm thinking about tools such as the Open Fortran Parser (OFP).  Section 2.3 of  the Flang Development Tasks document is labeled Parser.  The OFP's web site (http://fortran-parser.sourceforge.net) states that it supports the Fortran 2008 standard.  Could that save you some time?  Likewise, the OpenCoarrays library (www.opencoarrays.org) provides an open-source runtime library for coarray Fortran (CAF) compilers.  OpenCoarrays already supports most of the Fortran 2008 standard and several features of the draft Fortran 2015 standard.  (Full disclosure: my company contributes to the development of OpenCoarrays).  These new Fortran 2015 features in particular have some enticing performance benefits over rolling your own parallelism, whether by the more common MPI/OpenMP approaches or by Fortran 2008 CAF. 

Section 2.6.2 of the Flang Development Tasks document states that support for CAF is a low priority.  This worries me greatly.  I have taught modern Fortran short courses, tutorials, and graduate courses to what I would roughly estimate are upwards of 500 developers at conferences, job sites, and universities worldwide and I would gladly share survey data from recent courses indicating that interest in CAF is high amongst people who have taken my classes.  You don't need to support all of Fortran 2008 or even all of Fortran 2003 to support important aspects of CAF.  The g95 compiler project, for example, layered CAF support on top of Fortran 95 and the GNU Fortran compiler layers CAF support on top of its currently partial support of Fortran 95, 2003 and 2008.   In the multicore/many-core era, parallelism is of paramount importance and CAF offers a much cleaner, more portable alternative to the dominant approach of embedding MPI and OpenMP in source code.  If you want to make a game-changing splash, I'd consider supporting it earlier in your development than it appears you're currently thinking.

Likewise, now that Fortran is a modern, object-oriented programming (OOP) language and four compiler teams have announced full Fortran 2003 support (IBM, Cray, Intel, and Portland Group), anything that can help you jump quickly to supporting OOP will go a long way toward supporting present-day development.  Even conservative development projects that mandate multi-compiler support as a minimum standard are now dropping support for compilers that don't at least support Fortran 2003 (e.g., http://cgns.sourceforge.net/news.html).

As a user who has been submitting multiple compiler bug reports or standards-based feature requests each month across a half-dozen compilers over the past 5-10 years, my outside viewpoint is that the biggest hurdle some of the compiler teams face stems from the fact that they are developing on top of a code base that dates back decades.  You don't face that challenge.  To take maximal advantage of it, you might consider tackling some of the more salient newer features of the language early rather than trotting along the well-worn path of supporting the standards in chronological order.

Damian

[Hal Finkel]

----- Original Message -----
> From: "Damian Rouson" <dam...@rouson.net>
> To: flan...@googlegroups.com
> Sent: Wednesday, May 20, 2015 12:19:08 AM
> Subject: [flang-dev] Re: Flang Development Priorities
>
>
> All,
>
>
> Looking at the Flang Development Tasks document, I wonder if there
> are sensible alternatives to the chronological approach of focusing
> first on standards that are 20 or more years old. For a project in
> its nascent phase, would there be any value in taking a more
> holistic view from the vantage point of modern Fortran rather than
> focusing on an older subset of the language first? More
> specifically, are there (1) toolkits that can help you leapfrog the
> stages in which you might get stuck with the chronological approach
> and are there (2) common pitfalls likely to befall you if decisions
> based on older standards calcify in a design that makes it harder to
> evolve to support the newer standards?
>
>
> Regarding (1) above, I'm thinking about tools such as the Open
> Fortran Parser (OFP). Section 2.3 of the Flang Development Tasks
> document is labeled Parser. The OFP's web site
> (http://fortran-parser.sourceforge.net) states that it supports the
> Fortran 2008 standard. Could that save you some time?

I'm strongly against using OFP as our parser (with the exception that, assuming the licensing is acceptable, adapting regression tests from OFP could be a good idea). We really need to construct our own parser, following the best practices developed by Clang. These are the surest path to success in the long term. OFP's source quality is no where near Clang's (IMHO), brings in a dependency on ANTLR, and has a number of other issues. We already have a parser which supports large parts of F77 and F90, let's build on that.

> Likewise, the
> OpenCoarrays library (www.opencoarrays.org) provides an open-source
> runtime library for coarray Fortran (CAF) compilers. OpenCoarrays
> already supports most of the Fortran 2008 standard and several
> features of the draft Fortran 2015 standard. (Full disclosure: my
> company contributes to the development of OpenCoarrays). These new
> Fortran 2015 features in particular have some enticing performance
> benefits over rolling your own parallelism, whether by the more
> common MPI/OpenMP approaches or by Fortran 2008 CAF.

This, on the other hand, is likely a very good idea.

>
>
> Section 2.6.2 of the Flang Development Tasks document states that
> support for CAF is a low priority. This worries me greatly. I have
> taught modern Fortran short courses, tutorials, and graduate courses
> to what I would roughly estimate are upwards of 500 developers at
> conferences, job sites, and universities worldwide and I would
> gladly share survey data from recent courses indicating that
> interest in CAF is high amongst people who have taken my classes.
> You don't need to support all of Fortran 2008 or even all of Fortran
> 2003 to support important aspects of CAF. The g95 compiler project,
> for example, layered CAF support on top of Fortran 95 and the GNU
> Fortran compiler layers CAF support on top of its currently partial
> support of Fortran 95, 2003 and 2008. In the multicore/many-core
> era, parallelism is of paramount importance and CAF offers a much
> cleaner, more portable alternative to the dominant approach of
> embedding MPI and OpenMP in source code. If you want to make a
> game-changing splash, I'd consider supporting it earlier in your
> development than it appears you're currently thinking.

Frankly, I think the only way we can make this a priority is if we have contributors (like you) who understand how CAF should be implemented. If we have people who understand how to do this "right", we can do it soon. Otherwise, it will take time.

>
>
> Likewise, now that Fortran is a modern, object-oriented programming
> (OOP) language and four compiler teams have announced full Fortran
> 2003 support (IBM, Cray, Intel, and Portland Group), anything that
> can help you jump quickly to supporting OOP will go a long way
> toward supporting present-day development. Even conservative
> development projects that mandate multi-compiler support as a
> minimum standard are now dropping support for compilers that don't
> at least support Fortran 2003 (e.g.,
> http://cgns.sourceforge.net/news.html).
>
>
> As a user who has been submitting multiple compiler bug reports or
> standards-based feature requests each month across a half-dozen
> compilers over the past 5-10 years, my outside viewpoint is that the
> biggest hurdle some of the compiler teams face stems from the fact
> that they are developing on top of a code base that dates back
> decades. You don't face that challenge. To take maximal advantage of
> it, you might consider tackling some of the more salient newer
> features of the language early rather than trotting along the
> well-worn path of supporting the standards in chronological order.

I don't disagree. Doing what you suggest, however, requires more work. So let's do it now. Following in chronological order has the advantage of providing a clear ordering of development tasks. This may be suboptimal, agreed, but then we need to replace it with something better. What do you suggest?

When I was supervising Alex's GSOC flang project, I suggested a set of goals based on target applications. Specifically we targeted netlib BLAS and LAPACK (and then, as a finishing touch, the F77 MPI header). That was all there was time for, but did result in supporting a mix of F77 and F90. I'm fine with continuing in this vein. But requires analyzing codes we wish to target to determine what features are necessary, and then developing a task list from that.

Thanks,
Hal

>
>
> Damian
>
>
>
>
> On Tuesday, May 19, 2015 at 8:36:09 AM UTC-7, John Leidel wrote:
>
>
> All, as promised, we crafted a basic list of development items that
> are of interest. We generated these items by analyzing the current
> code base and selecting items of high value to the list of known
> user communities. This document is not designed to be the end list
> of development items. However, it does serve as an excellent
> starting point to pushing Flang development forward. If you have
> comments, edits or would like to own any of the items documented in
> the list, please respond to the overall mailing list such that we
> can capture the discussion.
>
>
> Thanks again to Carlo Bertolli and Kevin O'Brien for help in crafting
> and reviewing this list!
>
>
> Best Regards,
> John Leidel
>
>
>
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "flang-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to flang-dev+...@googlegroups.com .
> To post to this group, send email to flan...@googlegroups.com .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/flang-dev/a7242d9c-a96e-40b2-9f3d-8ed9a3b978b2%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout .
>

--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

[Hal Finkel]

Hi John,

Thanks for working on this. A could of quick comments:

Runtime Test Infrastructure: This should be priority of HIGH? All code added to the runtime library must have tests, and we need to develop tests for the existing functionality. We must establish a strict policy, as with other LLVM projects, that all commits have regression tests (including commits of the runtime library). This is not difficult, we can use the lit infrastructure just like compiler-rt does.

Also, as we've discussed, I'd like to add this:

Integrated C preprocessor: Priority MEDIUM
A large body of Fortran code expects to be run through the C preprocessor. We should integrate Clang's preprocessor for this purpose, and accurately track original source locations, and provide macro-expansion trace-back capability, as Clang does, to generate more-informative diagnostic messages.

-Hal

> --
> You received this message because you are subscribed to the Google
> Groups "flang-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to flang-dev+...@googlegroups.com .
> To post to this group, send email to flan...@googlegroups.com .
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/flang-dev/CAC6GRO9LmBknf7j2YqsKfeDOkYRVWxNzd-_VpUs3FnQ2_RVXww%40mail.gmail.com

[John Leidel]

On Wed, May 20, 2015 at 10:44 AM, Hal Finkel <hfi...@anl.gov> wrote:

----- Original Message -----
> From: "Damian Rouson" <dam...@rouson.net>
> To: flan...@googlegroups.com
> Sent: Wednesday, May 20, 2015 12:19:08 AM
> Subject: [flang-dev] Re: Flang Development Priorities
>
>
> All,
>
>
> Looking at the Flang Development Tasks document, I wonder if there
> are sensible alternatives to the chronological approach of focusing
> first on standards that are 20 or more years old. For a project in
> its nascent phase, would there be any value in taking a more
> holistic view from the vantage point of modern Fortran rather than
> focusing on an older subset of the language first? More
> specifically, are there (1) toolkits that can help you leapfrog the
> stages in which you might get stuck with the chronological approach
> and are there (2) common pitfalls likely to befall you if decisions
> based on older standards calcify in a design that makes it harder to
> evolve to support the newer standards?
>
>
> Regarding (1) above, I'm thinking about tools such as the Open
> Fortran Parser (OFP). Section 2.3 of the Flang Development Tasks
> document is labeled Parser. The OFP's web site
> (http://fortran-parser.sourceforge.net) states that it supports the
> Fortran 2008 standard. Could that save you some time?

I'm strongly against using OFP as our parser (with the exception that, assuming the licensing is acceptable, adapting regression tests from OFP could be a good idea). We really need to construct our own parser, following the best practices developed by Clang. These are the surest path to success in the long term. OFP's source quality is no where near Clang's (IMHO), brings in a dependency on ANTLR, and has a number of other issues. We already have a parser which supports large parts of F77 and F90, let's build on that.

I agree with Hal on this point.  Having looked through the OFP code, the changes necessary to integrate it would effectively force us to depart from many of the positives things in the current approach.  

 

> Likewise, the
> OpenCoarrays library (www.opencoarrays.org) provides an open-source
> runtime library for coarray Fortran (CAF) compilers. OpenCoarrays
> already supports most of the Fortran 2008 standard and several
> features of the draft Fortran 2015 standard. (Full disclosure: my
> company contributes to the development of OpenCoarrays). These new
> Fortran 2015 features in particular have some enticing performance
> benefits over rolling your own parallelism, whether by the more
> common MPI/OpenMP approaches or by Fortran 2008 CAF.

This, on the other hand, is likely a very good idea.

I also agree that this is not a bad idea.  Building the ability to utilize/link external runtime libraries will definitely help in promoting this as a long-term effort.  Damian, if you're willing, I would suggest starting a thread on this mailing list with exactly this in mind.  Any pointers and mindful guidelines to take this on would be greatly appreciated.  

 

>
>
> Section 2.6.2 of the Flang Development Tasks document states that
> support for CAF is a low priority. This worries me greatly. I have
> taught modern Fortran short courses, tutorials, and graduate courses
> to what I would roughly estimate are upwards of 500 developers at
> conferences, job sites, and universities worldwide and I would
> gladly share survey data from recent courses indicating that
> interest in CAF is high amongst people who have taken my classes.
> You don't need to support all of Fortran 2008 or even all of Fortran
> 2003 to support important aspects of CAF. The g95 compiler project,
> for example, layered CAF support on top of Fortran 95 and the GNU
> Fortran compiler layers CAF support on top of its currently partial
> support of Fortran 95, 2003 and 2008. In the multicore/many-core
> era, parallelism is of paramount importance and CAF offers a much
> cleaner, more portable alternative to the dominant approach of
> embedding MPI and OpenMP in source code. If you want to make a
> game-changing splash, I'd consider supporting it earlier in your
> development than it appears you're currently thinking.

Frankly, I think the only way we can make this a priority is if we have contributors (like you) who understand how CAF should be implemented. If we have people who understand how to do this "right", we can do it soon. Otherwise, it will take time.

+1 to this note.  I personally have no experience constructing code using CAF or developing CAF runtimes.  This was marked as a low priority as 1) we haven't yet been pushed on the issue and 2) very few of the early developers have extensive experience here.  If someone is willing to step up and champion the effort, I'm certainly willing to accept additional contributors.  

 

>
>
> Likewise, now that Fortran is a modern, object-oriented programming
> (OOP) language and four compiler teams have announced full Fortran
> 2003 support (IBM, Cray, Intel, and Portland Group), anything that
> can help you jump quickly to supporting OOP will go a long way
> toward supporting present-day development. Even conservative
> development projects that mandate multi-compiler support as a
> minimum standard are now dropping support for compilers that don't
> at least support Fortran 2003 (e.g.,
> http://cgns.sourceforge.net/news.html).
>
>
> As a user who has been submitting multiple compiler bug reports or
> standards-based feature requests each month across a half-dozen
> compilers over the past 5-10 years, my outside viewpoint is that the
> biggest hurdle some of the compiler teams face stems from the fact
> that they are developing on top of a code base that dates back
> decades. You don't face that challenge. To take maximal advantage of
> it, you might consider tackling some of the more salient newer
> features of the language early rather than trotting along the
> well-worn path of supporting the standards in chronological order.

I don't disagree. Doing what you suggest, however, requires more work. So let's do it now. Following in chronological order has the advantage of providing a clear ordering of development tasks. This may be suboptimal, agreed, but then we need to replace it with something better. What do you suggest?

When I was supervising Alex's GSOC flang project, I suggested a set of goals based on target applications. Specifically we targeted netlib BLAS and LAPACK (and then, as a finishing touch, the F77 MPI header). That was all there was time for, but did result in supporting a mix of F77 and F90. I'm fine with continuing in this vein. But requires analyzing codes we wish to target to determine what features are necessary, and then developing a task list from that.

This definitely requires additional analysis from the user community.  I've had some initial mail from Jeff Hammond stating his initial thoughts on early Fortran application targets.  We're certainly willing to field more requests.  I would very much prefer that, once reasonably stable, the long-term Flang development is heavily user-driven (it terms of performance, features and functionality).  

 

To view this discussion on the web visit https://groups.google.com/d/msgid/flang-dev/29849167.1623.1432136684731.JavaMail.javamailuser%40localhost.

[John Leidel]

Hal, I initially marked this as a high priority item in order to ensure the precedent of adding regression tests is enforced early on.  I often worry about collisions in runtime routines, but I believe this is less of a problem in Fortran than it is in C/CXX.  

Good catch on the C preprocessor.  I'll add this to the current list.    

[Damian Rouson]

> On May 20, 2015, at 8:44 AM, Hal Finkel <hfi...@anl.gov> wrote:
>
> ----- Original Message -----
>> From: "Damian Rouson" <dam...@rouson.net>
>> To: flan...@googlegroups.com
>> Sent: Wednesday, May 20, 2015 12:19:08 AM
>> Subject: [flang-dev] Re: Flang Development Priorities
>>

Hi Hal,

Thanks for considering my suggestions and making thoughtful responses.

>
> I'm strongly against using OFP as our parser (with the exception that, assuming the licensing is acceptable, adapting regression tests from OFP could be a good idea). We really need to construct our own parser, following the best practices developed by Clang. These are the surest path to success in the long term. OFP's source quality is no where near Clang's (IMHO), brings in a dependency on ANTLR, and has a number of other issues. We already have a parser which supports large parts of F77 and F90, let's build on that.

I have no personal experience with OFP and therefore no further opinion. I’m glad to hear you’re knowledgeable about OFP and confident in your path.

>
>> Likewise, the
>> OpenCoarrays library (www.opencoarrays.org) provides an open-source
>> runtime library for coarray Fortran (CAF) compilers. OpenCoarrays
>> already supports most of the Fortran 2008 standard and several
>> features of the draft Fortran 2015 standard. (Full disclosure: my
>> company contributes to the development of OpenCoarrays). These new
>> Fortran 2015 features in particular have some enticing performance
>> benefits over rolling your own parallelism, whether by the more
>> common MPI/OpenMP approaches or by Fortran 2008 CAF.
>
> This, on the other hand, is likely a very good idea.

Great! Members of the OpenCoarrays team will be glad to help however we can. The number one reason we developed OpenCoarrays separately from GNU Fortran (which uses OpenCoarrays as of release 5.1) was to adopt a license that could make OpenCoarrays attractive to other compiler development teams. We can be reached at openco...@googlegroups.com. We occasionally have teleconferences and I’m sure some of us could join any teleconferences you have. I will be monitoring your mailing list and have let other members of the OpenCoarrays team know about your mailing list.

>
> Frankly, I think the only way we can make this a priority is if we have contributors (like you) who understand how CAF should be implemented. If we have people who understand how to do this "right", we can do it soon. Otherwise, it will take time.

Although I have not contributed a single line of source code to a compiler, I’m pretty certain that code I’ve written is in the test suit of at least six compilers . I generally submit very tight tests that shine a spotlight on bugs or requested features. Most tests I submit are no more than 25 lines long and almost all are no more than 50 lines long. I can probably help best in a test-driven development mode. We are working on unit test for OpenCoarrys in the form small coarray Fortran codes. These could be useful to you. For now, our tests are mostly what I’d call “applets.” They sole a real-world problem (e.g., a partial differential equation) in a few hundred lines of code. I’m sure unit tests will be more useful to you.

As for contributing source directly to flang, you could approach Tobias Burnus who has written the compiler-side code that calls OpenCoarrays. My guess is his time is spoken for but he would be an awesome advisor. The speed with which he has implemented Fortran 2008 and even Fortran 2015 coarray features has been impressive.

>>
>> As a user who has been submitting multiple compiler bug reports or
>> standards-based feature requests each month across a half-dozen
>> compilers over the past 5-10 years, my outside viewpoint is that the
>> biggest hurdle some of the compiler teams face stems from the fact
>> that they are developing on top of a code base that dates back
>> decades. You don't face that challenge. To take maximal advantage of
>> it, you might consider tackling some of the more salient newer
>> features of the language early rather than trotting along the
>> well-worn path of supporting the standards in chronological order.
>
> I don't disagree. Doing what you suggest, however, requires more work. So let's do it now. Following in chronological order has the advantage of providing a clear ordering of development tasks. This may be suboptimal, agreed, but then we need to replace it with something better. What do you suggest?

Here’s a suggestion from a member of the Fortran committee who has several years of experience in commercial compiler support:

"I would add that consulting the F77 standard will lead [to implementing features that have been subsequently] deleted from Fortran (PAUSE statement, ASSIGNED GOTO…) - List is in B.1 of the standard. Subsequent standards have modified syntax for some statements. If you start with old standards you end up implementing syntax that then has to be redone later. This is not an efficient way to spend your effort. Better to start with the F2008 syntax (or even F2015) and then just flag the parts that are not operational yet. Annex D of F2008 does have the full syntax consolidated in one place.”

I would edit F2008 above to read “F2008 plus the combined corrigenda (Document N2005) available at the bottom of the following page: http://www.nag.co.uk/sc22wg5/links.html”

The committee also has a reasonably advanced draft of the Fortran 2015 standard, the title page of which includes the text "This is an internal working document of J3 and WG5.” I would be glad to inquire whether the document can be provided to those not on the committee if so desired.

>
> When I was supervising Alex's GSOC flang project, I suggested a set of goals based on target applications. Specifically we targeted netlib BLAS and LAPACK (and then, as a finishing touch, the F77 MPI header). That was all there was time for, but did result in supporting a mix of F77 and F90. I'm fine with continuing in this vein. But requires analyzing codes we wish to target to determine what features are necessary, and then developing a task list from that.

Keeping with the theme of numerical linear algebra being broadly useful, I suggest a good Fortran 2003 project to target is PSBLAS (http://people.uniroma2.it/salvatore.filippone/psblas/). As for Fortran 2008, the PSBLAS project lead Salvatore Filippone and I are working on a Fortran 2008 successor to NEMO (http://www.ce.uniroma2.it/nemo/) that will be useful to you when we are ready to open the source, but that is months away or more. Otherwise, I don’t know of any significant Fortran 2008 projects other than coarray Fortran codes so the OpenCoarrays test suite is a good place to start.

I hope these comments are helpful.

Damian

[Damian Rouson]

> On May 20, 2015, at 12:29 PM, Damian Rouson <dam...@rouson.net> wrote:
>
> Here’s a suggestion from a member of the Fortran committee who has several years of experience in commercial compiler support:
>
> "I would add that consulting the F77 standard will lead [to implementing features that have been subsequently] deleted from Fortran (PAUSE statement, ASSIGNED GOTO…) - List is in B.1 of the standard. Subsequent standards have modified syntax for some statements. If you start with old standards you end up implementing syntax that then has to be redone later. This is not an efficient way to spend your effort. Better to start with the F2008 syntax (or even F2015) and then just flag the parts that are not operational yet. Annex D of F2008 does have the full syntax consolidated in one place.”

Each standard also optionally declares some features “obsolescent,” which are described as those for which better methods exist in more recent standards. The standards advise that future standards might delete obsolescent features. Annex B of the draft Fortran 2015 standard includes a five-page list of deleted and obsolescent features.

Also, the textbook Modern Fortran Explained has a 20-page appendix describing features that the authors personally deprecate. Two of the authors are current members of the Fortran standards committee and the third author is a former member.

The union of the modified, deleted, and deprecated features forms a reasonable starting point for things to give a low priority if you decide to start from the draft 2015 standard or the 2008 standard plus corrigenda.

Lastly, I was remiss in not starting my first email by expressing my great enthusiasm for what you’re doing. Over the past year, I’ve begun to sense the emergence of a tiny but vibrant and growing ecosystem of tools for Fortran. It’s really exciting to see a new Fortran compiler project taking off and I’m glad you’re entertaining my suggestions.

Damian

[Carlo Bertolli]

Hi Damian (and everyone else in the list)

Let me add some thoughts about old Fortran, which someone else may have voiced previously in different ways.

There are plenty of existing legacy codes that are still used in computational science, some of them dating back to F66, some other F77.

For instance, I know that rolls-royce has production code in F77 and they are still doing some development in it.

It is remarkably important for these companies to be able to access a F77 compiler that supports everything that they already have in their codes.

One clear example is a F77 extension, called "Cray pointers" - they should not exist because they are an extension, but there is code out there using them and I believe it is a non starter to exclude those codes form Flang's user basis.

That said, I personally think that all these obsolescent abstractions should just go away.

Thanks for all your comments

-- Carlo

Damian

--
You received this message because you are subscribed to the Google Groups "flang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flang-dev+...@googlegroups.com.
To post to this group, send email to flan...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/flang-dev/E95683A8-E5FE-484C-8A17-0CCAE24035CA%40rouson.net.

[Hal Finkel]

Both would be useful. For Clang, we have both regression tests, and a "test suite" (which has real applications, benchmarks, etc.) used to monitor high-level correctness and performance issues. The small tests could be useful as regression tests, and the "applets" useful for our test suite.

Thanks for the suggestions!

-Hal

>
> I hope these comments are helpful.
>
> Damian

[Hal Finkel]

----- Original Message -----
> From: "Carlo Bertolli" <carlo.b...@gmail.com>
> To: "Damian Rouson" <dam...@rouson.net>
> Cc: "Hal Finkel" <hfi...@anl.gov>, flan...@googlegroups.com
> Sent: Wednesday, May 20, 2015 3:22:11 PM
> Subject: Re: [flang-dev] Flang Development Priorities
>
>

> Hi Damian (and everyone else in the list)
>
>
> Let me add some thoughts about old Fortran, which someone else may
> have voiced previously in different ways.
> There are plenty of existing legacy codes that are still used in
> computational science, some of them dating back to F66, some other
> F77.
> For instance, I know that rolls-royce has production code in F77 and
> they are still doing some development in it.
> It is remarkably important for these companies to be able to access a
> F77 compiler that supports everything that they already have in
> their codes.
>
>
> One clear example is a F77 extension, called "Cray pointers" - they
> should not exist because they are an extension, but there is code
> out there using them and I believe it is a non starter to exclude
> those codes form Flang's user basis.

Indeed; we have a number of these too. Support for cray pointers should be on our list of things to do (probably not a high priority, but on the list).

-Hal

> https://groups.google.com/d/msgid/flang-dev/CABxkWLjbY_%2Bn-ci%3Dn70ofDs4Vzw0BaYn0covdXn00g8jG9ospg%40mail.gmail.com
> .

> For more options, visit https://groups.google.com/d/optout .
>

[John Leidel]

I agree entirely with Hal.  We'll have small regression tests and full (eg, LIT) application tests.  The latter must be organized carefully such that all the potential licensing concerns are mitigated. It may be that we have build placeholders for packages whose licenses are not friendly to including an LLVM source tree.  No magic here... just making everyone aware of the process.  

--
You received this message because you are subscribed to the Google Groups "flang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flang-dev+...@googlegroups.com.
To post to this group, send email to flan...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/flang-dev/16986012.2045.1432154259856.JavaMail.javamailuser%40localhost.

[Jeff Hammond]

I tried to read the whole thread carefully, but it's impossible to respond inline to everything in the right place, so here are my high-level comments:

1) The common features of Fortran 77 are still in wide use today, both as "classic Fortran" (almost no code actually complies with ANSI Fortran 77, so it is a misnomer to call this F77) and as part of "modern Fortran" (aka Fortran 90+).  We should start with "classic Fortran" since it is a relatively small language and covers a huge amount of code.

2) OpenCoarrays is the right way to approach Fortran 2008 coarrays.  I have personally contributed to the communication back end and it is the most viable option for now.  There's a lot of value in having the community rally behind this project.

3) Cray pointers are a requirement in every supercomputer procurement I have seen.  They should be supported in order to gain traction with the HPC community.

4) Supporting widely used GCC extensions to "classic Fortran" - e.g. iargc() and getarg() - even though modern Fortran offers superior alternatives is a necessary evil in terms of getting users.  For example, NWChem relies heavily upon GCC extensions, many of which are supported by vendor compilers, but only yesterday did I start adding optional support for the ISO standard replacements.

5) It may seem silly, but if there's a way to support inline assembly in flang, that would be a novel feature relative to every other Fortran compiler I have used, and might attract power users.

6) I would raise the priority of "classic OpenMP" (often associated with the 2.5 spec) relative to the whole set.  It's high-value to support the basic constructs from the standpoint of attracting users.

Jeff