SIZEOF() extension in Flang - fortran

Does anyone know whether the "new" Flang LLVM Fortran frontend (available since LLVM 12) or the "old"/"classic" Flang compiler (based on PGI/NVIDIA) support the SIZEOF() function as a Fortran extension?
This inquiry function is not in the Fortran standard. A lot of compilers support it as an extension (not an exhaustive list): GFortran, Intel Fortran Classic (ifort), IBM XL Fortran, PGI (rest in pieces), NVIDIA HPC SDK.

Related

PGI equivalent of "use ifcore" with Intel compilers

I am currently working on compiling a model with PGI, originally designed for Intel compilers. One of the scripts uses use ifcore which is an Intel-specific command that links in miscellaneous run-time libraries. I am having trouble finding the PGI equivalent (for a linux machine)...any ideas?
I was looking at dflib but that appears to be windows-specific.
I am using mpif90 to compile the model currently.

Fortran subroutine overloading with submodules

I'm learning Fortran and using the Intel compiler.
Here is some code that I wrote. I want to define the print_array interface in the arraytools module, and all the specific implementations (e.g. print_array_rp) should go into a seperate sub-module. The following works, but if I split the implementation into a submodule, I get a huge amount of compiler errors (I suppose it cant find the implementation anymore).
module arraytools
use precision
implicit none
interface print_array
module procedure print_array_rp
end interface
contains
subroutine print_array_rp(arr, fmt_in)
! ... Implementation not important
end subroutine
end module
How do I split print_array_rp off into a sub-module? I don't want to use #include instead.
Submodules are not implemented in current Fortran compilers (unless you happen to be using the Cray compiler).
Only the Cray Fortran compiler implements the entire Fortran 2008 standard (thanks to VladimirF for pointing this out). Among the most poorly supported features among the other compilers are submodules.
The Fortran 2008 status wiki page (last modified Nov 2014 at the time of this post) lists Cray Fortran 8.1.1 as supporting submodules and Absoft 14, gfortran 4.8, HP, ifort 14.1, NAG 5.3.1, Oracle, Pathscale 4 and pgi 14.1 as not supporting submodules. As far as I am aware, none of these compilers has added support for submodules since then.
As noted in the comments below by Steve "Dr. Fortran" Lionel, Intel Fortran will gain submodule support in version 16 to be released later this year.

C++ / Fortran inter language ABI issues with older versions of GCC

We have managed to get our code building and running on Ubuntu 10.10. The code uses both C++ compiled with GCC 4.5 and fortran compiled with the latest version of ifort. We may be required to support an older embedded linux platform with a version of GCC several years old (still awaiting specs from client). Unfortunately their software and hardware has been speced for military use so it can't be upgraded. My question is are we likely to face ABI issues building our application with the older version of GCC and linking it with libraries compiled with the latest version of ifort?
Are you trying to call the Fortran code from C++, call the C++ code from Fortran, or both? If you're calling Fortran code from C++, I don't think you'll have a problem, especially if you're using the same Fortran compiler.
If you're trying to access C++ code from Fortran, this will depend on the nature of the C++ code. If the Fortran-accessible functions use C linkage, then you should be okay, because the C ABI is standardized. If the functions use C++ linkage, I would expect to have some trouble, because the C++ ABI isn't standardized and I'm sure GCC has made minor (and possibly major) changes to their ABI over the years.

C++ compilers and back/front ends

For my own education I am curious what compilers use which C++ front-end and back-end.
Can you enlighten me where the following technologies are used and what hallmarks/advantages they have if any?
Open64 - is it back-end, front-end, or both? Which compilers use it? I encounter it in CUDA compiler.
EDG - as far as I can tell this is a front-end use by Intel compilers and Comeau. do other compilers use it? I found quite a few references to it in boost source code.
ANTLR - this is general parser. Do any common compilers use it?
Regarding compilers:
with front-end/back-end does gcc compiler suite uses? does it have common heritage with any other compiler?
what front-end/back-end PGI and PathScale compilers use?
what front-end/back-end XL compiler uses (IBM offering).
in-depth links on the Internet or your personal know-how would be great.
I did some Google searching, but information I generally encountered was rather superficial.
Thanks.
EDG is a front-end used by Intel and Comeau. See EDG's list of customers for other users.
ANTLR is a parser generator. I'm not aware of any C++ compiler built around a parser that was built with ANTLR (that doesn't mean it couldn't exist though).
GCC is a suite of compilers, with front ends for C, C++, Fortran, Ada, Java, etc., and back-ends for more processors than I'd care to think about.
Open64 is also a suite of compilers including several front-ends (for C, C++, Fortran, and possibly others I don't remember at the moment) and back-ends (targeting X64, Itanium, ARM, and, again, probably others I don't remember and/or don't know about). I believe its origin (pun noted by not intended) is SGI's compiler(s). I seem to remember reading something hinting that Open64 was derived from some version of the GCC front end(s), but offhand I don't know 1) how similar it remains to GCC internally, or 2) the version of GCC from which it derived -- but it's been around long enough that I'd guess it was GCC 3.x at the most recent, and quite possibly GCC 2.x.
I believe PathScale has created at least one compiler derived from Open64, but they may have others as well.
As far as I know, IBM's compiler is entirely their own creation. I'd guess IBM's (now discontinued) VisualAge for C++ shared some heritage/development/code with XL C++, but don't know that for sure, and can't even begin to guess at the extent of it, even assuming it's true.
The Clang project provides new front-ends for C/C++/Objective C on top of the LLVM backend. The LLVM project also provide a LLVM-gcc, using the GCC front end and the LLVM backend. The DragonEgg project seeks to replace the GCC backend with LLVM.
The Codeplay VectorC, Sieve and Offload compilers use a custom front-end and back-end
with front-end/backend does gcc compiler suite uses? does it have common heritage with any other compiler?
The acronym “GCC” stands for “GNU compiler collection” (originally “GNU C compiler”) and this already gives a hint: GNU compilers are a collection of compilers, most notably for C and C++ but also for Fortran, Objective-C and others. They share a common back-end and intermediate representation that was developed for GCC specifically.
The front-ends are all custom-written for the GCC. Some were contributed by third parties, most notably the Objective-C front-end, which was contributed by Apple.
Visual studio uses EDG for its intellisense engine.

What C/C++ compilers are available for VxWorks?

I'm new to the VxWorks environment, I'm wondering what C and C++ compilers are available for use with VxWorks?
There are two: gcc and diab. They will be provided with your WindRiver platform (such as "General Purpose Platform 3.6"). The gcc is modified by WindRiver (and/or CodeSourcery) to work with VxWorks.
Now with VxWorks 6.9 there is a third option: Intel C++ compiler (for Intel target architectures only, 32 and 64 bit) -- diab will not target 64-bit
Greenhills development tools also supported the VXWorks environment in the past.
In addition to the customary Diab ("Wind River Compiler") and GNU, VxWorks 6.9 added Intel C Compiler (ICC), but ICC seems to have been dropped from version 7.
VxWorks version 7 adds LLVM/Clang.
As far as i know Tornado VxWorks IDE using gcc toolchain.
Any way i suggest to use the compiler provided by WindRiver (which i believe their version
of gcc) to avoid compatibility problems.
It's probably worth to menation the VxWorks version you having in mind.
I guess gcc version will be depend on VxWorks version and probably on target platform.