This is the mail archive of the
mailing list for the GCC project.
Re: does gcc meet these guidelines?
- From: Andrew Shewmaker <shewa at inel dot gov>
- To: tprince at ywave dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 26 Aug 2002 08:25:49 -0600
- Subject: Re: does gcc meet these guidelines?
- Organization: INEEL
- References: <20020825010918.292012CD83@inet1.ywave.com>
On Sat, 24 Aug 2002 18:09:18 +0000 (US/Pacific)
> 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.
> This message was sent using Endymion 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
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.
Idaho National Engineering and Environmental Laboratory
2525 Fremont Ave.
Idaho Falls, ID 83415-3605