F18 Fortran compiler and runtime project is accepted as part of LLVM project(lists.llvm.org)
lists.llvm.org
F18 Fortran compiler and runtime project is accepted as part of LLVM project
https://lists.llvm.org/pipermail/llvm-dev/2019-April/131703.html
33 comments
I always feel that Fortran is under-represented on the benchmarks game, so let me take the opportunity to say fyi that we are usually happy to accept better programs.
If you wish to contribute a program then please follow these instructions:
https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
If you wish to contribute a program then please follow these instructions:
https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Yep, it even supports generics, go figure (pun intended).
This is awesome! Fortran is still in use in many of the "hard" sciences. It will probably take several years, but this may mean we could consider deprecating one of the compilers we have to maintain for people.
According to TIOBE, Fortran is more popular than Google's Dart and Mozilla's Rust. Not to mention Kotlin, Lisp, and Erlang.
Fortran used to be more popular. However, TIOBE is a lacking indicator, as stated here: http://pypl.github.io/PYPL.html (do a in-page-search with "Why is PYPL so different from TIOBE ?") Some other indicators such as Redmonk ( https://redmonk.com/sogrady/2019/03/20/language-rankings-1-1... ) show that both Dart and Rust are more popular than Fortran. (Although each of them have their own set of biases.)
I think you mean lagging indicator.
While the page they link to uses "lagging", "lacking" actually seems to fit better with the context it's used in there:
The paragraph it's used in ("Why is PYPL so different from TIOBE ?") seems to argue that TIOBE is lacking, not lagging.
The paragraph it's used in ("Why is PYPL so different from TIOBE ?") seems to argue that TIOBE is lacking, not lagging.
Any sufficiently lagging indicator is also a lacking indicator.
For those that don't know:
'The LLVM compiler infrastructure project is a "collection of modular and reusable compiler and toolchain technologies" used to develop compiler front ends and back ends.
LLVM is written in C++ and is designed for compile-time, link-time, run-time, and "idle-time" optimization of programs written in arbitrary programming languages.'[1]
[1] https://en.wikipedia.org/wiki/LLVM
'The LLVM compiler infrastructure project is a "collection of modular and reusable compiler and toolchain technologies" used to develop compiler front ends and back ends.
LLVM is written in C++ and is designed for compile-time, link-time, run-time, and "idle-time" optimization of programs written in arbitrary programming languages.'[1]
[1] https://en.wikipedia.org/wiki/LLVM
Great news! Curious - are there any selfhosting Fortran compilers?
I'm not sure that makes much sense;forth is typically a thin layer over a machine (historically physical, but also a VM, like the jvm) - so it'd generally make sense to implement the "compiler" is "assembler" (whatever that means for a given "machine")?
A forth in forth that is a cross compiler or something, doesn't quite "feel" like a forth system?
See also: https://www.forth.com/starting-forth/11-forth-compiler-defin...
A forth in forth that is a cross compiler or something, doesn't quite "feel" like a forth system?
See also: https://www.forth.com/starting-forth/11-forth-compiler-defin...
The article is about Fortran, not Forth.
Oh, thank you for pointing that out. Not sure how I missed that :)
Ed: now I'm kinda excited about an llvm forth...
Ed: now I'm kinda excited about an llvm forth...
If a Fortran compiler were self-hosting, I might think twice before using it... I can't imagine implementing a parser/lexer in Fortran of all languages. Considering that loops and procedures are the main supported models of indirection/abstraction, I expect the defect rate per kLoC would be rather high.
Edit: Looks like OOP support arrived in Fortran 2003. Does anyone know how much of a difference it made?
Edit: Looks like OOP support arrived in Fortran 2003. Does anyone know how much of a difference it made?
As the very first high level language, plenty of compilers were implemented in FORTRAN during the 60's.
I'm not sure people used HLLs to write compilers at that time.
I'm sure they did. I'd even expect most compilers were written in a HLL. Note that most refers to quantity: I expect most compilers were written as an academic exercise with no real intent to be used in production. I would expect the compilers that were intended for people to use to write production code were written in assembler because at the time compiler optimizations where not very good; computers were slow and expensive; and programmers were cheap: as such it would be worth the extra cost to write your compiler in a low level language.
Fortran has evolved a lot. You can practically use any programming paradigm with it. If you chose well a subset of all its features, you can actually write quite elegant code. I have never used it for this and do not have any example, but I would not expect it to be particularly worse than any other language.
> Considering that loops and procedures are the main supported models of indirection/abstraction
What does this mean, and how is this any different from e.g. C?
What does this mean, and how is this any different from e.g. C?
I’m guessing your parent comment is thinking along the lines of https://news.ycombinator.com/item?id=14123100
From the use-cases I've seen, OOP didn't make a massive difference. Many of the ideas from OOP were possible before, e.g. abstraction with modules and derived types (essentially C structs) from Fortran 90/95. Others, like polymorphism felt a bit bolted on and haven't gained widespread usage.
As for a self-hosting compiler, I'm not aware of one, although it's something I'd be interested in having a go at. I've written a regex engine in Fortran before, I just haven't had the time to sit down with the Fortran standard and a textbook on compiler design (I'm a physicist by trait, so I've not been taught this stuff formally).
As for a self-hosting compiler, I'm not aware of one, although it's something I'd be interested in having a go at. I've written a regex engine in Fortran before, I just haven't had the time to sit down with the Fortran standard and a textbook on compiler design (I'm a physicist by trait, so I've not been taught this stuff formally).
> The board also recommends that f18 evaluate (over time) whether it is reasonably possible to eliminate the dependence on C++’17 features.
Alright...
> Using C++’17 is not a blocker for inclusion into the project, but will be a blocker for certain other infrastructure (e.g. build bots and integration into official releases), but those may or may not be relevant now given the early state of f18.
C++'17 is too new for the developers of the premier C++ compiler to use in their CI? What is this hot garbage!
Alright...
> Using C++’17 is not a blocker for inclusion into the project, but will be a blocker for certain other infrastructure (e.g. build bots and integration into official releases), but those may or may not be relevant now given the early state of f18.
C++'17 is too new for the developers of the premier C++ compiler to use in their CI? What is this hot garbage!
LLVM, like a lot of compilers, tries not to require the latest version of itself to bootstrap.
See
https://llvm.org/docs/GettingStarted.html#host-c-toolchain-b...
GCC is similar.
GCC is similar.
They should still be able to CI it on the min version that does work. Eventually c++'17 will be old enough, so definitely the thing to do is just wait.
LLVM supports old platforms: some CI bots are targeting stable Debian, or Ubuntu 14.04.
LLVM is currently moving to C++14, which is a pain for some users like TensorFlow for instance which supports Ubuntu 14.04: the c++ standard library is too old. There are technical solutions for everything but for a component like LLVM, not pressuring its users into convoluted workflow is important.
Of course the LLVM developpers would love to just use the latest version of the standard all the time. For the library part of the standard, it is worked around by having its own: https://github.com/llvm/llvm-project/blob/master/llvm/includ... (and others in the same directory)
LLVM is currently moving to C++14, which is a pain for some users like TensorFlow for instance which supports Ubuntu 14.04: the c++ standard library is too old. There are technical solutions for everything but for a component like LLVM, not pressuring its users into convoluted workflow is important.
Of course the LLVM developpers would love to just use the latest version of the standard all the time. For the library part of the standard, it is worked around by having its own: https://github.com/llvm/llvm-project/blob/master/llvm/includ... (and others in the same directory)
The bootstrapping policy and the capabilities of the CI infra should be decoupled. I'm not not arguing the the policy.
In three years when LLVM bumps to C++'17 or whatever, then flang starts obeying.
But also I personally think is fine for parts of the project not needed to build C++ to use newer C++. Just use the newly built clang to build flang!
In three years when LLVM bumps to C++'17 or whatever, then flang starts obeying.
But also I personally think is fine for parts of the project not needed to build C++ to use newer C++. Just use the newly built clang to build flang!
This is ignoring that LLVM is first and before all designed as reusable libraries.
Bumping requirements is causing other problems than just being able to build with the just built compiler: namely deployment and integration in other products. For example, you may be forced to isolate components in dynamic library that talks with each others through C APIs and each statically link the C++ standard library. It can become fairly complicated when this does not fit your setup and you get forced into this because LLVM decided to bump their standard.
Bumping requirements is causing other problems than just being able to build with the just built compiler: namely deployment and integration in other products. For example, you may be forced to isolate components in dynamic library that talks with each others through C APIs and each statically link the C++ standard library. It can become fairly complicated when this does not fit your setup and you get forced into this because LLVM decided to bump their standard.
I saw here they have a document explaining which C++17 features they use and why:
https://github.com/flang-compiler/f18/blob/master/documentat...
Yeah I would cry and quit if I was previously using those and then had to stop doing so.
Modern Fortran looks completely different from the old school FORTRAN77 that most people envision when thinking of Fortran. For reference, I did this past year's Advent of Code contest all in Fortran[0].
[0] https://gitlab.com/bwearley/advent-of-code-2018/tree/master