[Flang-dev] new Flang discussions?

Roger Ferrer Ibáñez rofirrim at gmail.com
Thu Oct 11 11:23:32 EDT 2018

Hi Jeff,

my concern was more about the extra expressivity of Fortran in some aspects
compared to C/C++: things like array-sections, sophisticated constructs
like WHERE or FORALL, statements like ALLOCATE/DEALLOCATE, the extra
semantics of the DO-construct when the step is nonconstant, the
IO-statements might mean that you end with a superset of nodes including
every single specific construct of the language in the AST. Sure, you can
lower all of them into C/C++ (and use C/C++ ASTs for that), it is just I am
not sure I would like to see this happen early.

I am not concerned about the physical representation in memory, though.

Perhaps I misunderstood David's original concern!

Kind regards,

Missatge de Jeff Hammond <jeff.science at gmail.com> del dia dj., 11 d’oct.
2018 a les 17:09:

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

Roger Ferrer Ibáñez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.flang-compiler.org/pipermail/flang-dev_lists.flang-compiler.org/attachments/20181011/42eae16a/attachment.html>

More information about the flang-dev mailing list