This is the mail archive of the
mailing list for the GCC project.
Re: does gcc meet these guidelines?
On Monday 26 August 2002 07:25, Andrew Shewmaker wrote:
> On Sat, 24 Aug 2002 18:09:18 +0000 (US/Pacific)
> email@example.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
> > firstname.lastname@example.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
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.