
Flang – A Fortran compiler targeting LLVM - swills
https://github.com/flang-compiler/flang
======
neurostimulant
Can we use it along with emscripten to compile fortran programs to js?

~~~
walshemj
Why would you want to do that ?

~~~
mtanski
legacy numeric applications / routines?

~~~
zakk
Except for some obscure edge case, it wouldn't really be a great idea to run
them on a JS vm... FORTRAN code still in use is computation-heavy stuff for
use cases where speed makes a big difference, the performance hit of a VM
wouldn't be acceptable.

~~~
jabl
There is a lot of battle-tested Fortran out there. If you're for one reason or
another in a situation where you have to deploy to the web platform and you
need some numerical algorithms, I can imagine it could make sense to pick some
routines from netlib instead of reinventing the wheel.

~~~
walshemj
Using python would possibly make more sense here

~~~
anentropic
python numeric code using numpy and the like ultimately depends on some
fortran libs underneath

~~~
marmaduke
Numpy has no Fortran whatsoever

~~~
jabl
The numpy.linalg module depends on LAPACK, which is Fortran.

Core numpy depends on BLAS, for which both Fortran and non-Fortran
implementations are available.

~~~
marmaduke
Go to the source, it's called lapacklite and it's C code translated from
Fortran

[https://github.com/numpy/numpy/tree/master/numpy/linalg](https://github.com/numpy/numpy/tree/master/numpy/linalg)

~~~
jabl
Hmm, seems you're right. Though that seems to be some fallback thing which is
used if the real thing isn't found during the build. At least on Ubuntu 16.04
the lapack_lite module links against the real (Fortran) lapack library:

    
    
      % ldd /usr/lib/python3/dist-packages/numpy/linalg/lapack_lite.cpython-35m-x86_64-linux-gnu.so|grep -E 'lapack|fortran'
    	liblapack.so.3 => /usr/lib/liblapack.so.3 (0x00007fb619ce7000)
    	libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007f5ae0911000)

------
kxyvr
One other nice benefit to this project is determining name mangling schemes
when linking to other Fortran projects using a pure LLVM toolchain.

Say we want to use BLAS and LAPACK in a C/C++ project that uses clang as the
compiler. All we have to do is write the appropriate prototype for the LAPACK
function in C and then link to BLAS/LAPACK. That said, there are four
different name mangling schemes that the BLAS/LAPACK could use, which are
combinations of upper case or with trailing underscores, e.g. gemm, GEMM,
gemm_, and GEMM_. Both Autotools and CMake will determine the mangling scheme
for us, but they need a Fortran compiler to determine that. Right now, that's
almost always GFortran. With this project, it could ostensibly be Flang, which
would eliminate the need for GCC to determine the mangling if a pure LLVM
toolchain is desired.

~~~
jabl
Modern LAPACK already comes with an official C binding, LAPACKE:
[http://www.netlib.org/lapack/lapacke.html](http://www.netlib.org/lapack/lapacke.html)

The C ABI is pretty stable, so if you're using LAPACKE you shouldn't need to
worry about which Fortran compiler was used to compile LAPACK.

Other than that, AFAIK the most common name mangling these days is lowercasing
+ trailing underscore. That being said, for "modern Fortran" with modules, OOP
etc. the issues are vastly more complex and AFAICS there is no commonly agreed
upon ABI.

------
ch_123
Judging by the copyright notices in the files, this is probably the PGI-
Fortran-on-LLVM compiler that was announced a year or two ago -
[https://www.llnl.gov/news/nnsa-national-labs-team-nvidia-
dev...](https://www.llnl.gov/news/nnsa-national-labs-team-nvidia-develop-open-
source-fortran-compiler-technology)

EDIT: Confirmed -
[https://developer.arm.com/-/media/developer/developers/hpc/f...](https://developer.arm.com/-/media/developer/developers/hpc/files/ARM-
HPC-UG-SC16-PGI.pdf)

------
nonsince
Ok, so the only reason anyone's using Fortran is for crazy speeds, what's the
codegen like compared to gfortran?

~~~
atemerev
Actually, modern Fortran is a pretty decent numeric programming language,
comparable (if not superior) to MATLAB, and much faster than it. The only
problem is that finding documentation on modern programming idioms and styles
is complicated among MEGATONS of legacy code lying around literally from Cold
War times (still perfectly working, of course, so if you urgently need to
write a Monte Carlo solver for neutron transport equations — you got it
covered).

~~~
nonsince
I'm really interested in Fortran because I love super down-to-the-metal
optimisation stuff, but I have no meaningful use-case for it. Where would you
recommend someone start if they wanted to get into modern Fortran?

~~~
alfalfasprout
To add to some of the answers, Fortran's strength is that a scientist can
write an algorithm for some numerical routine fairly easily and the output
code will be highly optimized.

This is possible because you don't have to deal with all the weird edge cases
you have in C/C++ like aliasing. The language is fairly simple so it can be
optimized to death and it's easy to add things like automatic vectorization,
etc.

~~~
prestonbriggs
I'm sure you meant to include scare quotes, as in "easy" :-)

~~~
orbifold
Compared to C++ / C even old fortran is suprisingly pleasant to use, when you
want to implement simple numerical algorithms, it feels a bit like a barebones
matlab

------
tachyonbeam
Am I the only one who thinks that Forlang would have been a better name? ;)

~~~
Someone
[http://www.phoronix.com/scan.php?page=news_item&px=LLVM-
NVID...](http://www.phoronix.com/scan.php?page=news_item&px=LLVM-NVIDIA-
Fortran-Flang): _" Flang is to Fortran as Clang is to C/C++."_

This is a NVIDIA project.

------
0x09
Apparently unrelated to Flang the 2013 LLVM GSOC project to implement a
Fortran frontend.

[https://github.com/hyp/flang](https://github.com/hyp/flang)

The name re-use was a bit confusing.

------
rhabarba
Now how about a COBOL version? :-)

~~~
atemerev
I would love to see a modernized COBOL in the same way they have modernized
Fortran. It'd be an instant hit in enterprise IT environments.

------
hawski
Is it sensible to implement math heavy part of C application in Fortran and
call it via FFI? Or is -Ofast enough in most cases without the costs
(multiple, because performance may be one of them) of FFI?

~~~
jabl
Not for speed reasons alone. It's certainly possible to tune C code to have
roughly equivalent performance to Fortran.

The real appeal for using Fortran is that for beginners it's a much easier
language to pick up than C (much less footguns, for one), and that working
with (dense) multidimensional arrays is very nice, roughly on par with high-
level languages like numpy, R, or MATLAB.

~~~
m_mueller
To expand on this, I think the footguns you're talking about are specifically
performance related.

Just an example: How do you specify a fast readonly array in C? If I recall
correctly it's

restrict const * const int my_array[n]

In Fortran?

integer(4), intent(in) :: my_array(n)

Not even starting with array ops, multidimensionals, array slicing etc.,
that's already a big win in readability. Having a pass-by-reference language
by default is refreshing for HPC purposes.

That being said there are disadvantages compared to C. Biggest one IMO is the
lack of inline declarations, which especially makes privatizing things in
OpenMP and OpenACC code a bit more tricky, i.e. it needs to be explicit.

~~~
smitherfield
_> How do you specify a fast readonly array in C?_

Generally in the function declaration rather than the variable declaration,
but to declare a non-aliasing pointer to array of constant ints would be

    
    
      const int (restrict *my_array)[N];
    

or

    
    
      int const (*restrict my_array)[N];
    

and the other two variations thereof.

~~~
int_19h
Gentle reminder to future language designers: whatever else you decide to take
from C, please, _please_ don't take declarator syntax. This thread showcases
why.

------
santaclaus
How easy is it to do OpenMP from LLVM front-ends, at the moment? Fortran
without OpenMP would be a bit limiting.

Edit: It looks like Clang 3.8.0 supports OpenMP, so this should be doable.

------
walshemj
what advantages over gfortran does this have and if its performance why not
just pony up for the intel fortran

~~~
unit91
> why not just pony up for the intel fortran

I used to work in a government research lab. We mostly used GFortran instead
of Intel for political stability reasons. Your budget can change drastically
from year-to-year (even if there's no change at the congressional level)
because every dollar has to go through the entire bureaucracy before it makes
it to your cubicle. The budget wars are constant at every level in the org
pyramid.

GFortran is free, and always will be. Whether we can pony up for Intel is
completely unknown 5 or 50 years from now. And a _lot_ of people in the
Fortran world are ultimately funded by Uncle Sam.

~~~
walshemj
so your counting your power bill / cost per gflop when you do your budgeting
and exactly how many licences would you need? you'd be building on a server
not on everyone's desktop pc right?

~~~
cat199
Not OP, but In these types of scenarios power/utilities probably come out of
someone elses budget with at least one layer of competing bureaucracy walling
off anyone from asking that question, let alone investigating it and factoring
it into the decision making process..

~~~
unit91
Exactly. Anything that comes out of somebody else's budget is "free". :-/

