experchange > fortran

JRR (02-11-19, 07:56 PM)
Following the recent release of the new major release v19.1 of the
Portland Fortran Compiler, I tested this compiler again with our code.
It seems to be moving to the underlying LLVM as a default now.
However, in the general structure of the compiler not much seems to have
changed. It is advertised since many years as a F2003 compiler, but in
fact it isn't.
The detection of coding errors is not very good, and many F2003 features
do not work. The compiler very often delivers ICEs. Of course, general
statements are always difficult and subjective, but personally I would
rate that compiler one order of magnitude below competitors like
gfortan, Intel or NAG.
ftinetti (02-11-19, 09:19 PM)
Hi,

IĀ“curious about
> ...many F2003 features do not work...


Would you share which ones?

TIA,

Fernando.

On Monday, February 11, 2019 at 2:56:25 PM UTC-3, JRR wrote:
[..]
JRR (02-12-19, 02:38 AM)
Pointers to polymorphic DT e.g. which we are using to avoid
copying our data. Besides this, the compiler always assumes
routines to be provided externally and so only fails during
linking with the weirdest possible error messages. The compilation
time is humongous. There is a recent problem in bind(C):
$ pgfortran_2019 -c foo.f90
/x86_64/opt/pgi/2019/linux86-64-llvm/19.1/share/llvm/bin/llc: error:
/afs/desy.de/UBU/16/x86_64/opt/pgi/2019/linux86-64-llvm/19.1/share/llvm/bin/llc:
/tmp/pgfortranSK6xeVTUFvs_.ll:23:6: error: value doesn't match function
result type 'i64'
ret i8* %5, !dbg !24
^

on the following simple code
function f1 (proc_id, foo) bind(C)
use iso_c_binding
type(c_ptr) :: f1
integer(c_int), value :: foo
f1 = c_null_ptr
end function f1

And some of the errors I reported more than 2 years ago.

On 11.02.19 20:19, ftinetti wrote:
[..]
Similar Threads