This release is the result of the community’s work over the past six months, including: use of profile data in ThinLTO, more aggressive dead code elimination, experimental support for coroutines, experimental AVR target, better GNU ld compatibility and significant performance improvements in LLD, as well as improved optimizations, many bug fixes and more.
The release notes have all the details.
Its great to see consistent progress for LLVM. I use gfortran for much of my development, but I’m eagerly awaiting the results of the DOE project to create a Fortran compiler on top of LLVM. Its always good to have two compilers implementing the same language, and better if they are both open source.
Many developers I know joke about the old, venerable, Fortran. They usually say that the thing should be left rot for good. Most of them have no idea how much it is still used on scientific fields and how it has evolved through all these years.
Many “hot” languages I know just put a “lipstick” (interface) around it and go for good. Sometimes it is stupid to follow this path instead of just make use of the original thing but, alas, we all have preferences and sometimes do illogical things just to honor them.
There are a few additions from newer programming languages that I wish would be added to the standard; these include case sensitivity for variable names and a ternary operator similar to the one in C. Overall though, I find that modern Fortran presents just the right balance of performance and ease of development for my tastes.
http://cl21.org/ ?
OK, LISP is also an ancient language, one I have to deal with in Autocad AutoLisp and, damn, after using it for some years I discovered why some say that LISP = “Lots of Irritating Superfluous (or, Spurious) Parentheses”.
Well, at least you only have to deal with parenthesis.
C, C++, C# and so are more into <,,>(,,,){ ; {,,,} ; ; ; { ; ; (;;){ ; ; ; } ; ; [] ; } ; ; { ; ; ; } ; ; { ; ; } ; }
Matter of taste.
We were taught it stood for “Lots of Idiotic, Stupid Parentheses”.
Anywho, I’d love to see a good FORTRAN compiler for it. FORTRAN is still the main language for engineers, and probably will remain so for some time. It’s also the primary language for standards bodies; for example, (nearly) every reference codec for compression is done in FORTRAN, and then run through a FORTRAN-to-C converter.
The other thing I’d like to see is more back-ends. If you’re into programming alternative systems (old consoles/computers, embedded systems, etc), you’re only real choice is GCC.
While not C/C++/Fortran, FPC (Free Pascal) does have quite a few backends. But perhaps you meant a different specific kind of cpu.
You’d think after all these years, editors should just write the parentheses for you.
They do but it does not help that much when you are refactoring code and must change the enclosing orders. Things can really become confuse.
There must be a way to write a LISP program that could do that refactoring though, right? Unless I overestimate LISP’s ability to treat its own programs as data structures? I kind of refuse to accept that languages like Java can have such superior refactoring abilities
Or maybe the kind of refactoring you want to do in LISP is even more complicated than the kind found in Java etc.
Ternary is present, even if a little weird:
x = merge(1.0, 2.0, k > 2)
See:
“http://fortraninacworld.blogspot.com.br/2012/12/ternary-operator.ht…
Case sensitivity, well, it would probably open a can of worms from hell for libraries compatibility and linking. It is probably better to leave the situation as it is right now.
I’d previously looked into the merge function, and found that it is really an array operation rather than a real equivalent to the ternary operator. I could create a function to do what I want, but the performance of an actual operator in the language can be better since the compiler has a better chance at optimizing it.
I agree with you assessment of the case-sensitivity; the right choice is to leave it alone. It would just be nice to have sometimes.
The “merge” function is an inline function and, as a such thing, has a drawback when compared to a true ternary operator: all its arguments are evaluated (no order defined, by what I read). Same thing happens on C++.
Insight highly repetitive loops, I would stick with “if” statement.