Earlier quoted context omitted.
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?
As the very first high level language, plenty of compilers were implemented in FORTRAN during the 60's.
F18 Fortran compiler and runtime project is accepted as part of LLVM project
21–30 of 34 posts
Re: F18 Fortran compiler and runtime project is accepted as part of LLVM project
#22Earlier quoted context omitted.
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.
In fact, during the 60's Algol variants were already being used to write compilers and OSes.
Re: F18 Fortran compiler and runtime project is accepted as part of LLVM project
#23Earlier quoted context omitted.
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.
Re: F18 Fortran compiler and runtime project is accepted as part of LLVM project
#24I 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/adven…
Re: F18 Fortran compiler and runtime project is accepted as part of LLVM project
#25Earlier quoted context omitted.
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.
The paragraph it's used in ("Why is PYPL so different from TIOBE ?") seems to argue that TIOBE is lacking, not lagging.
Re: F18 Fortran compiler and runtime project is accepted as part of LLVM project
#26Earlier quoted context omitted.
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.
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 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)
Re: F18 Fortran compiler and runtime project is accepted as part of LLVM project
#27Earlier quoted context omitted.
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…
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!
Re: F18 Fortran compiler and runtime project is accepted as part of LLVM project
#28Great news! Curious - are there any selfhosting Fortran compilers?
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...
Re: F18 Fortran compiler and runtime project is accepted as part of LLVM project
#29Great 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-def…
Re: F18 Fortran compiler and runtime project is accepted as part of LLVM project
#30I 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/adven…
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/...