21–28 of 28 posts
How compatible is it with the current code bases developped under proprietary compilers ?
> Whilst many alternative programming languages have come and gone, it [Fortran] has regained its popularity for writing high performance codes. I don't understand why sometimes people pluralize "code". It sounds a bit silly but maybe it's just me.
I'm seeing it here for the first time, and from multiple people. Maybe it's specific to the Fortran community?
There doesn't appear to be a link to the release notes, it would be nice to know what are the current limitations.
> Whilst many alternative programming languages have come and gone, it [Fortran] has regained its popularity for writing high performance codes. I don't understand why sometimes people pluralize "code". It sounds a bit silly but maybe it's just me.
it's a fairly common usage in numeric computing. If you read, for example, the wikipedia entries for "computational fluid dynamics" you'll see that they consistently speak of "codes" when referring to programs. https://en.wikipedia.org/wiki/Computational_fluid_dynamics
Earlier quoted context omitted.
Q from out of the loop: what are you referring to? and if you could enlighten me how that then is a problem?
Not the OP, but I'll take a stab at it. In C99, C added the 'restrict' qualifier for pointers, which would make function arguments marked with it behave a bit like procedure arguments in Fortran. Idea being to allow the compiler to optimize more aggressively. Not specifically about making C more like Fortran, but there's been a lot of work over the years clarifying what compilers can and cannot assume. More recently,…
and as long as C gets features you may but don't have to use, so what?
There doesn't appear to be a link to the release notes, it would be nice to know what are the current limitations.
Language-wise, it's all of F'2018 less coarrays and "LEN" derived type parameters, plus a pile of portable &/or popular language extensions.
Earlier quoted context omitted.
Language-wise, it's all of F'2018 less coarrays and "LEN" derived type parameters, plus a pile of portable &/or popular language extensions.
Also, it would be good to know how well it handles older codes of the f77/g77 era (as gfortran is not always well behaved on those).
Congratulations, next is COBOL ? I am serious, we really need a free COBOL compiler. Yes, GNU now has a front end for COBOL, so LLVM turn. Maybe IBM and the Navy Department will help.