[Flang-dev] new Flang discussions?

David Greene dag at cray.com
Fri Oct 12 12:15:02 EDT 2018

When you say face-to-face, who was in that discussion?  flang and clang

Is it worth kicking off a cross-post cfe-dev/flang-dev discussion or do
we really think this is completely infeasible?

How many "real" Fortran code use these odd corners of the language?
Dusty decks might but maybe a 98% solution is good enough.  Doing things
like redefining constants just seems evil to me.  Keywords are a bit
easier to understand, as the committee likely didn't want to break old
codes when introducing new keywords.

I would like to better understand the AST mutating problem you mention
and how it relates to clang.  flang presumably has to do the
analysis/transformation already.  Is there something particularly
bad/difficult with requiring tooling to work on a post-cleanup AST?


"McCormick, Pat via flang-dev" <flang-dev at lists.flang-compiler.org>

> 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… 
> —Pat
>     On Oct 11, 2018, at 9:09 AM, Jeff Hammond <jeff.science at gmail.com>
>     wrote:
>     On Thu, Oct 11, 2018 at 8:03 AM Roger Ferrer Ibáñez
>     <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.
>     Jeff
>         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,
>         Roger
>         Missatge de David Greene <dag at cray.com> del dia dj., 11 d’oct.
>         2018 a les 16:41:
>         blubee blubeeme <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
>             project.
>             I do find it concerning that there's almost no discussion
>             about f18 on
>             this list. Where is that discussion happening?
>             -David
>             _______________________________________________
>             flang-dev mailing list
>             flang-dev at lists.flang-compiler.org
>             http://lists.flang-compiler.org/mailman/listinfo/flang-dev_
>             lists.flang-compiler.org
>         -- 
>         Roger Ferrer Ibáñez
>         _______________________________________________
>         flang-dev mailing list
>         flang-dev at lists.flang-compiler.org
>         http://lists.flang-compiler.org/mailman/listinfo/flang-dev_lists.
>         flang-compiler.org
>     -- 
>     Jeff Hammond
>     jeff.science at gmail.com
>     http://jeffhammond.github.io/
>     _______________________________________________
>     flang-dev mailing list
>     flang-dev at lists.flang-compiler.org
>     http://lists.flang-compiler.org/mailman/listinfo/flang-dev_lists.flang-
>     compiler.org
> _______________________________________________
> flang-dev mailing list
> flang-dev at lists.flang-compiler.org
> http://lists.flang-compiler.org/mailman/listinfo/flang-dev_lists.flang-compiler.org

More information about the flang-dev mailing list