
F18 Fortran compiler and runtime project is accepted as part of LLVM project - ingve
https://lists.llvm.org/pipermail/llvm-dev/2019-April/131703.html
======
wycy
I write code in modern Fortran 2018, making extensive use of the new language
features, so this is welcome news. I use Intel Fortran Compiler 2019 at work
and gfortran-8 at home.

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](https://gitlab.com/bwearley/advent-of-
code-2018/tree/master)

~~~
igouy
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://salsa.debian.org/benchmarksgame-
team/benchmarksgame/blob/master/CONTRIBUTING.md)

[https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/faster/fortran.html)

------
CaliforniaKarl
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.

~~~
codesushi42
According to TIOBE, Fortran is more popular than Google's Dart and Mozilla's
Rust. Not to mention Kotlin, Lisp, and Erlang.

~~~
GolDDranks
Fortran used to be more popular. However, TIOBE is a lacking indicator, as
stated here:
[http://pypl.github.io/PYPL.html](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...](https://redmonk.com/sogrady/2019/03/20/language-
rankings-1-19/) ) show that both Dart and Rust are more popular than Fortran.
(Although each of them have their own set of biases.)

~~~
Nydhal
I think you mean lagging indicator.

~~~
aepiepaey
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.

------
mikorym
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](https://en.wikipedia.org/wiki/LLVM)

------
beezle
Great news! Curious - are there any selfhosting Fortran compilers?

~~~
TimTheTinker
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?

~~~
pjmlp
As the very first high level language, plenty of compilers were implemented in
FORTRAN during the 60's.

~~~
rbanffy
I'm not sure people used HLLs to write compilers at that time.

~~~
pjmlp
You just need to search for papers, quite a few available.

In fact, during the 60's Algol variants were already being used to write
compilers and OSes.

~~~
rbanffy
That's true. Not only compilers, but a lot of MCP was written in Algol.

------
Ericson2314
> 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!

~~~
DannyBee
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...](https://llvm.org/docs/GettingStarted.html#host-c-toolchain-
both-compiler-and-standard-library)

GCC is similar.

~~~
Ericson2314
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.

~~~
Joky
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...](https://github.com/llvm/llvm-
project/blob/master/llvm/include/llvm/ADT/STLExtras.h) (and others in the same
directory)

~~~
Ericson2314
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!

~~~
Joky
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.

