[Flang-dev] new Flang discussions?

McCormick, Pat pat at lanl.gov
Thu Oct 11 12:27:58 EDT 2018

This is a fun can of worms…

We've had some face-to-face discussions about this and unfortunately I can’t remember the full laundry list of details.  One aspect of Fortran that stuck in my brain that has rarely become evident to me when looking at code is that Fortran keywords are specifically not reserved words.  It is in the standard(s)…   Someone from PGI/NVIDIA will have to help refresh my memory about our full discussions in this regard; they have way more experience dealing with such nuances of Fortran than I do.

My take (but I’m rusty) is that this introduces some oddities/subtleties and corner cases that are potentially messy in borrowing some infrastructure from Clang — it would seem a Fortran AST would only be sound after a second evaluation pass (i.e. you have to have a full construct to “understand" it).  In the end, you potentially have to mutate node types and maybe even the overall AST structure to address this.

I honestly can’t come up with a (good) reason why I would want to program this way — maybe someone else knows the motivations behind this decision in the standard(s)?   Anyways, my eventual take away was this seems to fundamentally be at odds with some of the Clang design philosophies.  Someone can refresh my memory here if I’ve missed something…

All that said, the tooling aspects of this thread are extremely high on our “wish list" — it is actually the most requested feature and the fundamental reason our application teams are excited about Flang.   It would be good to get a laundry list from the community about some requirements and features in this area…


On Oct 11, 2018, at 9:09 AM, Jeff Hammond <jeff.science at gmail.com<mailto:jeff.science at gmail.com>> wrote:

On Thu, Oct 11, 2018 at 8:03 AM Roger Ferrer Ibáñez <rofirrim at gmail.com<mailto:rofirrim at gmail.com>> wrote:
Hi all,

I'm also very interested in the source-level tooling opportunities that may arise due to f18.

I work in a supercomputing center where several HPC applications are written by domain experts, but not necessarily experts in Fortran, whose work can benefit a lot from tools that operate at the source-level.

Having taken the approach in the past of trying to reuse as much as C/C++ ASTs for Fortran in our in-house tools, I have to admit I'm not really enticed by the idea. After all the two languages are very different. In terms of memory/storage representation I guess this makes sense, but trying to mold Fortran language parts into "similar enough" C/C++ trees appeals less so to me. At least that has been my experience in the past. However, I also understand that in circumstances where the functionality to implement is the same as for C/C++, not being able to reuse code due to language-specific differences can be seen as a burden.

Can you give some examples of how the languages are very different in a way that would make reuse of the C/C++ AST ineffective?  I understand how the syntax is different, but I don't see major semantic differences that would prevent AST reuse.

While C/C++ might not have a feature equivalent to coarrays (which aren't supported in Flang yet anyways), LLVM supports the concept of an address space already and thus should be able to support tooling for that if necessary.


Regarding the command-line, looks very reasonable to me to make them closer to clang (in a fashion similar to what gfortran can do respect to gcc/g++), but Fortran users are (unavoidably) used to have to deal with different compilers each one having their own style and sets of command-line parameters, so perhaps there is less interest here.

Reusing as much infrastructure as possible as long as it does not concern strictly to the source language also makes sense to me.

Kind regards,

Missatge de David Greene <dag at cray.com<mailto:dag at cray.com>> del dia dj., 11 d’oct. 2018 a les 16:41:
blubee blubeeme <gurenchan at gmail.com<mailto:gurenchan at gmail.com>> writes:

> I think this new version of F18 will still parse and generate token
> streams but then instead of manually generating the lower level code,
> it'll be turned into LLVM IR so that any platform that supports LLVM
> will have an easier time implementing new features, fixes, etc..

I was hoping f18 would lower to something akin to clang's AST.
Obviously clang's AST doesn't directly apply to Fortran but perhaps some
kind of common interface could exist so that clang tools could work with
Fortran codes.  It would be great to have things like the clang static
analyzer and clang-doc for Fortran.

Some tools will be language-specific of course but it seems like Fortran
and C-family languages share enough common concepts that some tooling
could work with both, given a common interface.  Language-specific tools
would work with a more language-specific interface.

My impression from the presentation is that there's a lot more that
could be shared with clang.  The messaging system and command-line
options infrastructure should be shareable, for example.  Maybe there's
already work being done in these areas to make f18 a first-class LLVM

I do find it concerning that there's almost no discussion about f18 on
this list.  Where is that discussion happening?


flang-dev mailing list
flang-dev at lists.flang-compiler.org<mailto:flang-dev at lists.flang-compiler.org>

Roger Ferrer Ibáñez
flang-dev mailing list
flang-dev at lists.flang-compiler.org<mailto:flang-dev at lists.flang-compiler.org>

Jeff Hammond
jeff.science at gmail.com<mailto:jeff.science at gmail.com>
flang-dev mailing list
flang-dev at lists.flang-compiler.org<mailto:flang-dev at lists.flang-compiler.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.flang-compiler.org/pipermail/flang-dev_lists.flang-compiler.org/attachments/20181011/fc10c92e/attachment-0001.html>

More information about the flang-dev mailing list