does gcc meet these guidelines?

does gcc meet these guidelines?

[Andrew Shewmaker]

Hello, I'm looking at NACSE's guidelines for HPC software and I am
hoping someone can tell me if GCC supports 5.8, 5.9, 5.10, and 5.15 
of their requirements. Also, if I am wrong about any of the others, 
please let me know.

Here is what I have so far:

5. Compilers
N  5.1 compiler for ISO/IEC 1539-1:1197 Fortran
Y  5.2 compiler for ANSI/ISO 9899-1990 C
Y  5.3 compiler for ANSI/ISO/IEC 14882-1998 C++
N  5.4 OpenMP Fortran binding, version 1.0.
N  5.5 OpenMP C binding, version 1.0
N  5.6 OpenMP C++ binding, version 1.0
Y  5.7 ANSI/IEEE 1003.1c POSIX threads (pthreads)
?  5.8 all compilers list variable cross-ref
?  5.9 Fortran compiler with preprocessor directives
?  5.10 Fortran compiler generates COMMON block map
N  5.11 auto-parallelization within procedures
N  5.12 directives for overriding auto-parallelization
Y  5.13 target-specific compiler switch
N  5.14 Fortran compiler with Cray pointers
?  5.15 all compilers list pseudo-assembly-language
N  5.16 auto-parallel compiler lists pseudo-assembly
N  5.17 auto-parallelization across procedures


Thanks for the help in advance,

-Andrew


P.S. Here are their detailed descriptions:

http://www.nacse.org/distributions/HPCreqts/report/part4.html

5. Compilers

The items in this section refer to support traditionally provided
through compilers. Features marked with an asterisk (*) may optionally
be provided as part of a cross-platform development environment,
rather than on the target machine itself.

5.1 * Vendor-supported compiler for ISO/IEC 1539-1:1197 Fortran
(Fortran95, which subsumes Fortran77) following POSIX Fortran
Bindings
5.2 * Vendor-supported compiler for ANSI/ISO 9899-1990 C.
5.3 * Vendor-supported compiler for ANSI/ISO/IEC 14882-1998 C++.
5.4 * Vendor-supported implementation of OpenMP Fortran binding,
version 1.0. The vendor will describe the architectural scope of the
implementation (e.g., limited to a single node, spanning N nodes).
5.5 * Vendor-supported implementation of OpenMP C binding, version
1.0. The vendor will describe the architectural scope of the
implementation (e.g., limited to a single node, spanning N nodes).
5.6 * Vendor-supported implementation of OpenMP C++ binding, version
1.0. The vendor will describe the architectural scope of the
implementation (e.g., limited to a single node, spanning N nodes)
5.7 Vendor-supported implementation of ANSI/IEEE 1003.1c POSIX threads
(pthreads).
5.8 * Ability of Fortran/C/C++ compilers to list basic intraprocedural
information on symbol names (e.g., cross-reference listing,
distinction between read and write occurrences).
5.9 * Ability of Fortran compiler to handle ANSI-C-like preprocessor
directives for file inclusion, conditional compilation statements
accepting Fortran expressions, and macro expansions.
5.10 * Ability of Fortran compiler to provide an interprocedural
COMMON block map. This functionality may be provided through a
separate tool.
5.11 * Vendor-supported compiler with the ability to parallelize
automatically at the intraprocedural level, and report why particular
portions weren't parallelizable.
5.12 * Vendor-supported auto-parallelizing compiler with directives
for overriding both compiler conservatism and auto-parallelization.
5.13 * If the compiler supports more than one target machine,
availability of a target-specific switch that exploits the
characteristics of the target machine. Vendor will specify how this is
done.
5.14 * Ability of Fortran compiler to handle Cray pointers, as
described at
http://www.scd.ucar.edu/tcg/consweb/Fortran90/scnpoint.html .
5.15 * Ability of Fortran/C/C++ compilers to generate transformed
source code or pseudo-assembly-language listings. This functionality
may be provided through a separate tool, but the listing must be
clearly correlated with the original source code (e.g., comments
indicating which instructions map to a source statement).
5.16 * Vendor-supported parallelizing compiler with ability to produce
listing of transformed source or pseudo-assembly language code showing
the results of parallelization. This functionality may be provided
through a separate tool, but the listing must be clearly correlated
with the original source code (e.g., comments indicating which
instructions map to a source statement).
5.17 * Vendor-supported compiler with the ability to parallelize
across procedural boundaries, safely and automatically.


-- 
Andrew Shewmaker
Associate Engineer
Phone:  208.526.1415
Fax:  208.526.4017

Idaho National Engineering and Environmental Laboratory
2525 Fremont Ave.
Idaho Falls, ID 83415-3605

Re: does gcc meet these guidelines?

[Fergus Henderson]

On 23-Aug-2002, Andrew Shewmaker <shewa@inel.gov> wrote:
> Y  5.3 compiler for ANSI/ISO/IEC 14882-1998 C++

GNU C++ does not yet fully conform to the 1998 C++ standard.
For example, it does not support the "export" keyword.

(Fully-conforming C++ implementations are currently still
few and far between.)

> Y  5.7 ANSI/IEEE 1003.1c POSIX threads (pthreads)

This is a library issue, rather than a gcc issue.
Support for POSIX threads varies between different platforms.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: does gcc meet these guidelines?

[Gabriel Dos Reis]

Fergus Henderson <fjh@cs.mu.oz.au> writes:

| On 23-Aug-2002, Andrew Shewmaker <shewa@inel.gov> wrote:
| > Y  5.3 compiler for ANSI/ISO/IEC 14882-1998 C++
| 
| GNU C++ does not yet fully conform to the 1998 C++ standard.
| For example, it does not support the "export" keyword.

Well, "export" is recognized as a keyword -- it is just that ignored
:-) :-)

-- Gaby

Re: does gcc meet these guidelines?

[Tim Prince]

On Monday 26 August 2002 07:25, Andrew Shewmaker wrote:
> On Sat, 24 Aug 2002 18:09:18 +0000 (US/Pacific)
>
> tprince@ywave.com wrote:
> > 5.9 clearly is satisfied.  Use either g77 preprocessing option or the .F
> > series of file naming to get tradcpp preprocessing.
> > 5.15 is satisfied, to the extent that you can always save the code which
> > is passed to the assembler.  As for making the assembler code key to the
> > source, that is more than any compiler can do completely with fully
> > optimized code.  The ability of gcc to get interspersed source and
> > assembler is good on certain targets, including ia32 (e.g. by compiling
> > with -g -c and using objdump -S), non-existent on others.
> > Several competent compiler vendors make compilers with a high degree of
> > compatibility with gcc, which cover many of your parallel computing
> > points.
> >
> > Tim
> > tprince@computer.org
> >

> Thank you for your help. If it isn't much trouble, could you (or someone
> else) comment on these requirements? I realize some of these aren't
> strictly about the compiler, but I would really appreciate even being
> told where to look or who to ask.
>
> 7.5 If the target machine supports non-IEEE format, vendor-supported
> mechanism to transparently perform the appropriate conversions to IEEE
> format.

I don't know of any current machines which are (a) relevant to parallel 
computing and (b) supported by gcc/g77/g95, which support non-IEEE format.  
Ask about particular architectures; possibly someone will be able to answer.
>
> 7.12 Vendor-supported mechanism to correctly convert 32-bit IEEE
> floating- point numbers to 64-bit IEEE values, and vice versa, during
> unformatted Fortran read and write operations.
g77 doesn't have much support for reading unformatted files written by 
another compiler or even by g77 on a system with a different binary format.
I think this subject has been discussed in the light of g95, but any final 
solution is in the future.
>
> 7.13 Vendor-supported mechanism to accommodate big/little-endian
> conversion during unformatted Fortran read and write operations.
Unfortunately, no, even on some systems where the proprietary compilers 
convert between internal byte order and big-endian file formats, g77 does not.
>
> 8.4 Vendor-supported linker capable of resolving all symbol references
> without the need to specify a particular object multiple times in the
> argument list (as in multipass linking).
gcc/g77 don't provide their own linker.  They generally use the linker 
associated with the operating system.  No answer fits all gcc targets.  Under 
normal circumstances, it isn't necessary to search any library more than once.
>
> 8.5 Vendor-supported linker or tool capable of generating a complete
> load map of any executable or shared object, including names of
> external symbols, their addresses, and the compilation unit where
> each was defined.
Also a function of the operating system.  Nearly all targets provide at least 
most of this functionality. cf gnu binutils 'ld --print-map'
>
> 8.7 Accurate versioning information for preprocessors, compilers, ar,
> and linker, with ability to associate this information in some way
> with each user object file and executable.
Objects and executables marked with all those version details?  Not to my 
knowledge.  Certainly, it's possible to set up a build to save this 
information into a text file.
>
> 8.13 Vendor-supported linker that can replace just selected object
> or library modules within an executable.
Not commonly available, to my knowledge.
>
> Andrew

-- 
Tim Prince

Re: does gcc meet these guidelines?

[Andrew Shewmaker]

On Sat, 24 Aug 2002 18:09:18 +0000 (US/Pacific)
tprince@ywave.com wrote:

> 5.9 clearly is satisfied.  Use either g77 preprocessing option or the .F 
> series of file naming to get tradcpp preprocessing.
> 5.15 is satisfied, to the extent that you can always save the code which 
> is passed to the assembler.  As for making the assembler code key to the 
> source, that is more than any compiler can do completely with fully 
> optimized code.  The ability of gcc to get interspersed source and 
> assembler is good on certain targets, including ia32 (e.g. by compiling 
> with -g -c and using objdump -S), non-existent on others.
> Several competent compiler vendors make compilers with a high degree of 
> compatibility with gcc, which cover many of your parallel computing points.
> 
> Tim
> tprince@computer.org
> 
> ---------------------------------------------
> This message was sent using Endymion MailMan.
> http://www.endymion.com/products/mailman/
 

Thank you for your help. If it isn't much trouble, could you (or someone 
else) comment on these requirements? I realize some of these aren't 
strictly about the compiler, but I would really appreciate even being 
told where to look or who to ask.

7.5 If the target machine supports non-IEEE format, vendor-supported 
mechanism to transparently perform the appropriate conversions to IEEE 
format.

7.12 Vendor-supported mechanism to correctly convert 32-bit IEEE 
floating- point numbers to 64-bit IEEE values, and vice versa, during 
unformatted Fortran read and write operations. 

7.13 Vendor-supported mechanism to accommodate big/little-endian 
conversion during unformatted Fortran read and write operations.

8.4 Vendor-supported linker capable of resolving all symbol references 
without the need to specify a particular object multiple times in the 
argument list (as in multipass linking). 

8.5 Vendor-supported linker or tool capable of generating a complete 
load map of any executable or shared object, including names of 
external symbols, their addresses, and the compilation unit where 
each was defined.

8.7 Accurate versioning information for preprocessors, compilers, ar, 
and linker, with ability to associate this information in some way 
with each user object file and executable.

8.13 Vendor-supported linker that can replace just selected object 
or library modules within an executable.

Andrew

-- 
Andrew Shewmaker
Associate Engineer
Phone:  208.526.1415
Fax:  208.526.4017

Idaho National Engineering and Environmental Laboratory
2525 Fremont Ave.
Idaho Falls, ID 83415-3605

Re: does gcc meet these guidelines?

[tprince]

> Hello, I'm looking at NACSE's guidelines for HPC software and I am
> hoping someone can tell me if GCC supports 5.8, 5.9, 5.10, and 5.15 
> of their requirements. Also, if I am wrong about any of the others, 
> please let me know.
> 
> Here is what I have so far:
> 
> 5. Compilers
> N  5.1 compiler for ISO/IEC 1539-1:1197 Fortran
> Y  5.2 compiler for ANSI/ISO 9899-1990 C
> Y  5.3 compiler for ANSI/ISO/IEC 14882-1998 C++
> N  5.4 OpenMP Fortran binding, version 1.0.
> N  5.5 OpenMP C binding, version 1.0
> N  5.6 OpenMP C++ binding, version 1.0
> Y  5.7 ANSI/IEEE 1003.1c POSIX threads (pthreads)
> ?  5.8 all compilers list variable cross-ref
> ?  5.9 Fortran compiler with preprocessor directives
> ?  5.10 Fortran compiler generates COMMON block map
> N  5.11 auto-parallelization within procedures
> N  5.12 directives for overriding auto-parallelization
> Y  5.13 target-specific compiler switch
> N  5.14 Fortran compiler with Cray pointers
> ?  5.15 all compilers list pseudo-assembly-language
> N  5.16 auto-parallel compiler lists pseudo-assembly
> N  5.17 auto-parallelization across procedures
> 
> 
> Thanks for the help in advance,
> 
> -Andrew
> 
> 
> P.S. Here are their detailed descriptions:
> 
> http://www.nacse.org/distributions/HPCreqts/report/part4.html
> 
> 5. Compilers
> 
> The items in this section refer to support traditionally provided
> through compilers. Features marked with an asterisk (*) may optionally
> be provided as part of a cross-platform development environment,
> rather than on the target machine itself.
> 
> 5.1 * Vendor-supported compiler for ISO/IEC 1539-1:1197 Fortran
> (Fortran95, which subsumes Fortran77) following POSIX Fortran
> Bindings
> 5.2 * Vendor-supported compiler for ANSI/ISO 9899-1990 C.
> 5.3 * Vendor-supported compiler for ANSI/ISO/IEC 14882-1998 C++.
> 5.4 * Vendor-supported implementation of OpenMP Fortran binding,
> version 1.0. The vendor will describe the architectural scope of the
> implementation (e.g., limited to a single node, spanning N nodes).
> 5.5 * Vendor-supported implementation of OpenMP C binding, version
> 1.0. The vendor will describe the architectural scope of the
> implementation (e.g., limited to a single node, spanning N nodes).
> 5.6 * Vendor-supported implementation of OpenMP C++ binding, version
> 1.0. The vendor will describe the architectural scope of the
> implementation (e.g., limited to a single node, spanning N nodes)
> 5.7 Vendor-supported implementation of ANSI/IEEE 1003.1c POSIX threads
> (pthreads).
> 5.8 * Ability of Fortran/C/C++ compilers to list basic intraprocedural
> information on symbol names (e.g., cross-reference listing,
> distinction between read and write occurrences).
> 5.9 * Ability of Fortran compiler to handle ANSI-C-like preprocessor
> directives for file inclusion, conditional compilation statements
> accepting Fortran expressions, and macro expansions.
> 5.10 * Ability of Fortran compiler to provide an interprocedural
> COMMON block map. This functionality may be provided through a
> separate tool.
> 5.11 * Vendor-supported compiler with the ability to parallelize
> automatically at the intraprocedural level, and report why particular
> portions weren't parallelizable.
> 5.12 * Vendor-supported auto-parallelizing compiler with directives
> for overriding both compiler conservatism and auto-parallelization.
> 5.13 * If the compiler supports more than one target machine,
> availability of a target-specific switch that exploits the
> characteristics of the target machine. Vendor will specify how this is
> done.
> 5.14 * Ability of Fortran compiler to handle Cray pointers, as
> described at
> http://www.scd.ucar.edu/tcg/consweb/Fortran90/scnpoint.html .
> 5.15 * Ability of Fortran/C/C++ compilers to generate transformed
> source code or pseudo-assembly-language listings. This functionality
> may be provided through a separate tool, but the listing must be
> clearly correlated with the original source code (e.g., comments
> indicating which instructions map to a source statement).
> 5.16 * Vendor-supported parallelizing compiler with ability to produce
> listing of transformed source or pseudo-assembly language code showing
> the results of parallelization. This functionality may be provided
> through a separate tool, but the listing must be clearly correlated
> with the original source code (e.g., comments indicating which
> instructions map to a source statement).
> 5.17 * Vendor-supported compiler with the ability to parallelize
> across procedural boundaries, safely and automatically.
> 
> 
> -- 
> Andrew Shewmaker
> Associate Engineer
> Phone:  208.526.1415
> Fax:  208.526.4017
> 
> Idaho National Engineering and Environmental Laboratory
> 2525 Fremont Ave.
> Idaho Falls, ID 83415-3605
5.9 clearly is satisfied.  Use either g77 preprocessing option or the .F 
series of file naming to get tradcpp preprocessing.
5.15 is satisfied, to the extent that you can always save the code which 
is passed to the assembler.  As for making the assembler code key to the 
source, that is more than any compiler can do completely with fully 
optimized code.  The ability of gcc to get interspersed source and 
assembler is good on certain targets, including ia32 (e.g. by compiling 
with -g -c and using objdump -S), non-existent on others.
Several competent compiler vendors make compilers with a high degree of 
compatibility with gcc, which cover many of your parallel computing points.

Tim
tprince@computer.org

---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/