Linked by Thom Holwerda on Tue 14th Mar 2017 19:27 UTC
General Development

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.

Order by: Score:
Steady Progress
by FortranMan on Wed 15th Mar 2017 04:05 UTC
FortranMan
Member since:
2011-12-21

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.

Reply Score: 2

RE: Steady Progress
by acobar on Wed 15th Mar 2017 08:06 UTC in reply to "Steady Progress"
acobar Member since:
2005-11-15

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.

Reply Score: 2

RE[2]: Steady Progress
by FortranMan on Wed 15th Mar 2017 12:13 UTC in reply to "RE: Steady Progress"
FortranMan Member since:
2011-12-21

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.

Reply Score: 1

RE[3]: Steady Progress
by Kochise on Wed 15th Mar 2017 15:39 UTC in reply to "RE[2]: Steady Progress"
Kochise Member since:
2006-03-03
RE[4]: Steady Progress
by acobar on Wed 15th Mar 2017 18:47 UTC in reply to "RE[3]: Steady Progress"
acobar Member since:
2005-11-15

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

Reply Score: 2

RE[5]: Steady Progress
by Kochise on Wed 15th Mar 2017 18:59 UTC in reply to "RE[4]: Steady Progress"
Kochise Member since:
2006-03-03

Well, at least you only have to deal with parenthesis.

C, C++, C# and so are more into <,,>(,,,){ ; {,,,} ; ; ; { ; ; (;;){ ; ; ; } ; ; [] ; } ; ; { ; ; ; } ; ; { ; ; } ; }

Matter of taste.

Reply Score: 2

RE[5]: Steady Progress
by JLF65 on Wed 15th Mar 2017 21:15 UTC in reply to "RE[4]: Steady Progress"
JLF65 Member since:
2005-07-06

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.

Reply Score: 2

RE[6]: Steady Progress
by Rugxulo on Fri 17th Mar 2017 17:50 UTC in reply to "RE[5]: Steady Progress"
Rugxulo Member since:
2007-10-09

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.

Reply Score: 1

RE[5]: Steady Progress
by kwan_e on Wed 15th Mar 2017 23:05 UTC in reply to "RE[4]: Steady Progress"
kwan_e Member since:
2007-02-18

You'd think after all these years, editors should just write the parentheses for you.

Reply Score: 2

RE[6]: Steady Progress
by acobar on Thu 16th Mar 2017 02:21 UTC in reply to "RE[5]: Steady Progress"
acobar Member since:
2005-11-15

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.

Reply Score: 2

RE[7]: Steady Progress
by kwan_e on Thu 16th Mar 2017 08:27 UTC in reply to "RE[6]: Steady Progress"
kwan_e Member since:
2007-02-18

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.

Reply Score: 2

RE[3]: Steady Progress
by acobar on Wed 15th Mar 2017 18:42 UTC in reply to "RE[2]: Steady Progress"
acobar Member since:
2005-11-15

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.

Reply Score: 2

RE[4]: Steady Progress
by FortranMan on Wed 15th Mar 2017 22:16 UTC in reply to "RE[3]: Steady Progress"
FortranMan Member since:
2011-12-21

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.

Reply Score: 1

RE[5]: Steady Progress
by acobar on Thu 16th Mar 2017 02:19 UTC in reply to "RE[4]: Steady Progress"
acobar Member since:
2005-11-15

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.

Reply Score: 2