Cool Tools - GCC for SPARC® Systems - Porting
Porting GCC Programs to GCC for SPARC Systems
This guide is intended to help developers use GCC for SPARC Systems to
compile programs that are currently compiled using GCC. It is
assumed that the developer is using GCC 3.3.2 or later.
Language
Because GCC for SPARC Systems is based on GCC 4.0.2 and later versions,
a transition from GCC 4.0 or later to GCC for SPARC Systems should require very few
changes to the source code being compiled. In most cases, no changes
will be needed.
If a release prior to GCC 4.0 is currently being used, the work needed to
transition to GCC for SPARC Systems will, in most cases, be the same as the work needed to
transition to GCC 4.0.
The following GCC release notes include information about the changes in C++:
GCC 4.0 and GCC for SPARC Systems accept more of the C++ language standard than GCC 3.3.2 or
GCC 3.3.3.
Incorrect C++ template usage is reported as a warning in GCC 3.4.
In GCC 4.0 and GCC for SPARC Systems, this is reported as an error.
Certain coding idioms accepted by GCC 3.4 and the Sun Studio compilers are
not accepted by GCC 4.0 and GCC for SPARC Systems:
- Local static function declarations cannot be used.
A function declaration should only appear at the file scope level.
The following code should be changed.
static void foo1(), foo2(); /* correct */
void test()
{
static void foo3(), foo4(); /* error with gcc 4.x */
}
- Array element types must be defined.
extern struct ABC my_array[]; /* was okay with gcc 3.x */
struct ABC { /* definition */ };
extern struct ABC my_array2[]; /* correct */
- An align pragma should appear before the first declaration of the variable being aligned.
extern my_type my_var;
/* warning: align appears after first declaration */
#pragma align 128(my_var)
my_type my_var;
- The printf format must match the argument types.
GCC 4.x checks printf format strings against the types of its arguments.
For long long int arguments, the correct printf format should be
'%lld' or '%llx'.
When '%ld' or '%lx'is used to print long long int values,
GCC 3.x did not generate warnings, but GCC 4.x does.
Similarly, for pointer types, the printf format should be %p, not %x.
The compiler back-end used by GCC for SPARC Systems differs from the one used by GCC.
Some applications currently compiled with GCC should be modified
to take advantage of features of the new back-end.
- Use automatic template instatiation.
Do not use manual template instantiation schemes such as "#pragma interface" and "-frepo".
GCC for SPARC Systems produces COMDAT linkage for all C++ templates, out-of-line inline functions, and other
one-definition-rule symbols. The use of COMDAT usually produces smaller and faster programs.
- Use consistent type declaration in mapfiles and source code.
In an object files generated by GCC for SPARC Systems, the linkage type for a variable symbol is OBJT. However, GCC and older Sun Studio compilers gave a variable symbol
a NOTY linkage type. A function symbol always has FUNC linkage type.
If an application declares one symbol as variable in one module but
defines the same symbol as a function in another module, it could be
linked without any error using GCC or older Sun Studio compilers.
That is because a NOTY symbol is linked with a FUNC symbol.
With GCC for SPARC Systems in this case, the Solaris system linker will give a warning
because an OBJT symbol is linked with a FUNC symbol.
For example, the following two files can be compiled and linked
without warning when GCC for SPARC Systems is not used.
/* file f1.c, declare symbol 'foo' as a variable */
typedef long address;
extern address foo;
int main() { return foo; }
/* file f2.c, define symbol 'foo' as a function */
void foo() { }
When GCC for SPARC Systems is used to compile and link above example, we will see the
following warning:
ld: warning: symbol `foo' has differing types:
(file f1.o type=OBJT; file f2.o type=FUNC);
Although GNU ld does not give such warnings, GCC for SPARC Systems is configured to
use Solaris system linker.
Such symbol mismatch could also happen in linker map files.
For example, a C source file might define a variable and the
variable name is declared as a function in linker mapfile to
make it visible. This worked with GCC and older Sun Studio compilers,
but will get a warning from Solaris system linker when
the C file is compiled by GCC for SPARC Systems or newer Sun Studio compilers.
Command Line Options
GCC for SPARC Systems accepts all of the GCC 4.0.2 command line
options for a SPARC target. Some of them have no effect.
These include the following:
- -pipe doesn't work by design. IR is passed to Sun backend via IR file
- -fforce*
- -fgcse*
- -falign*
- -fsched*
- -funroll*
- any other flag that change RTL generation doesn't have any effect on GCC for SPARC Systems
- profiling via gcc back-end is not supported. Users need to use
-xprofile flags instead of -fprofile*
Additional options control optimizations. These include the following:
For a complete list of command line options, execute the gcc, g++, or c++
command and specify the
--help
option.
See additional command line options for details on the options.
New Performance Features
The GCC for SPARC Systems compilers bring the world-class performance and
robustness of the SunStudio compiler backend components to GCC users.
As a result, users will find that their programs run correctly with higher
levels of optimizations. Also, users can utilize additional
optimizations that are not available with GCC:
- Traditional scalar optimizations
- Loop optimizations
- Prefetch
- Interprocedure optimization
- Automatic parallelization
- Inline assembler is optimized
Environment Variables
GCC for SPARC Systems compiled programs can work without environment variable
LD_LIBRARY_PATH. Programs linked with GCC for SPARC Systems contains
RPATH pointing to the GCC for SPARC Systems run-time libraries so that they
can run without LD_LIBRARY_PATH.
However, if LD_LIBRARY_PATH is set when running GCC for SPARC Systems, users
should make sure that its directory paths do not contain incompatible
libraries.
Libraries
GCC for SPARC Systems compiled programs use Solaris system <iconv.h> file and do not use libiconv.
Third-Party Web Sites
Sun is not responsible for the availability of third-party web
sites mentioned in this document. Sun does not endorse and is not
responsible or liable for any content, advertising, products, or
other materials that are available on or through such sites or
resources. Sun will not be responsible or liable for any actual or
alleged damage or loss caused by or in connection with the use of or
reliance on any such content, goods, or services that are available
on or through such sites or resources.
|
