The IBM XL C/C++ Advanced Edition for Linux is a standards-based, command-line compiler for Linux running on Power Architecture processor-based systems. Besides exploiting the capabilities of the IBM POWER4™, POWER5™, and PowerPC® 970 processors, it also adds support for the new POWER5+™ processor. This article introduces the new features added in the XL C/C++ V8.0 for Linux compiler and highlights the various differences between the GNU gcc and g++ compilers (referred to as GCC) and XL C/C++.

This article refers to IBM XL C/C++ Advanced Edition V8.0 for Linux as XL C/C++. The term Linux on POWER refers to the Linux operating system running on IBM Power Architecture technology-based systems. (For more definitions, see the glossary below.)

XL C/C++ provides many optimization options tailored to Power Architecture chips, including the POWER5+ and PowerPC 970 processors. Applications built with XL C/C++ have, in many cases, shown significant performance improvements over the same applications built with GCC on Linux for Power Architecture processor-based systems. To take full advantage of Power Architecture technology's potential, we recommend using XL C/C++.

XL C/C++ is currently available on SUSE Linux Enterprise Server 10 (SLES 10) for Power Architecture processors and on Red Hat Enterprise Linux AS V4 (RHEL 4) for Power Architecture processors. More information can be found at the XL C/C++ product page (see the Resources section for a link).

For your reference, the appendix to this article provides a comparison of commonly used options from GCC and XL C/C++.

An overview of XL C/C++

XL C/C++ is an optimizing, standards-based, command-line compiler for Linux on POWER. You can use XL C/C++ as a C compiler for files with a .c (lowercase c) suffix, or as a C++ compiler for files with a .C (uppercase C), .cc, .cpp, or .cxx suffix. XL C/C++ supports the two ISO programming language specifications for C: C89 and C99. The C++ compiler supports the latest revised ISO C++ 2003 standard (ISO/IEC 14882:2003), as well as a subset of the C99 language functionality. Additionally, the compiler supports numerous language extensions, including a subset of the GNU gcc and g++ language extensions.

XL C/C++ creates binary or object files that are compatible with those produced by GCC. To achieve this compatibility, a program compiled with XL C/C++ includes the same headers as those used by GCC on the same system. XL C/C++ uses the GNU gcc and g++ headers, and the resulting application is linked with the C and C++ runtime libraries provided with GCC. Therefore, portions of an application can be built with XL C/C++ for optimization purposes and then combined with portions built with GCC to produce an application that functionally behaves as if it had been built solely by one compiler or the other. The relationship between XL C/C++ and GCC for Linux on POWER can be summarized as follows:

• Compilation uses the GNU gcc and g++ header files from the Linux distribution
• Compilation of .s files uses GNU assembler
• Linking uses the GNU linker
• The compiled program uses the GNU gcc and g++ runtime libraries
• Debugging uses gdb, the GNU debugger
• IBM built-in functions for Power Architecture processors coexist with GNU gcc/g++ built-ins

Back to top

XL C/C++ documentation

When you install XL C/C++, you get these PDF documents:

• Getting Started with XL C/C++ for Linux (getstart.pdf) will get you started.
• XL C/C++ for Linux Installation Guide (install.pdf) contains instructions for installing the compiler and enabling the man pages.
• XL C/C++ for Linux C/C++ Language Reference (language.pdf) contains information about the C and C++ language as supported by IBM.
• XL C/C++ for Linux Compiler Reference (compiler.pdf) contains information about the various compiler options, pragmas, macros, and built-in functions, including those used for parallel processing.
• XL C/C++ for Linux Programming Guide (proguide.pdf) contains information on advanced programming topics, including optimization.

These documents reside in:

• The /docs/LANG/pdf directory of the installation CD, where LANG represents the language and location code.
• The /opt/ibmcmp/vacpp/7.0/doc/LANG/pdf directory, after the compiler is installed.

An HTML version of the product documentation is installed in the /opt/ibmcmp/vacpp/7.0/doc/LANG/html directory. From this directory, open the file index.html to view the HTML version of the documentation.

Back to top

What's new in version 8

A subset of new features introduced in XL C/C++ are highlighted here. For a complete list of new features, please consult Getting Started with XL C/C++ for Linux (getstart.pdf).

Performance and optimization

• You can now perform function cloning according to architecture with the -qipa=clonearch option. With this option, you can tune the application for multiple architectures, with the target machine's characteristics detected at runtime. There is no need for multiple compilations with different -qarch values.

• Refinements to the -qarch and -qtune options include support for POWER5+ processors and processors that support the VMX instruction set; for example: -qarch=pwr5x or -qarch=ppc64v.

• The IBM Mathematics Acceleration Subsystem (MASS) vector libraries shipped with XL C/C++ introduce new scalar and vector functions, and new support for the POWER5 processor architecture.

• XL C/C++ also introduces the Basic Linear Algebra Subprograms (BLAS). These let you, for example, compute the matrix-vector product for a general matrix or its transpose, and perform combined matrix multiplication and addition for general matrices or their transposes.

• This version adds many new built-in functions for Power Architecture processors that enable the development of highly optimized applications. A built-in function is a coding extension to C and C++ that allows you to use the syntax of C function calls and C variables to access the instruction set of the processor of the compiling machine. For the list of new built-in functions, consult the XL C/C++ for Linux Compiler Reference (compiler.pdf)

Conformance to industry standards

• XL C/C++ supports the OpenMP API V2.5 standard. This latest level of the OpenMP specification combines the previous C/C++ and Fortran OpenMP specifications into a single specification, and resolves previous inconsistencies between them.

New features

• This new release of XL C/C++ provides the xlc_install and new_install utilities to assist you in installing and configuring the compiler for initial use on your system.

• IBM Tivoli® License Manager (ITLM) now supports XL C/C++. ITLM is a Web-based solution that can help you manage software usage metering and license allocation services. ITLM can detect both the installation of XL C/C++ and its usage.

Back to top

Compiler modes

The default location for XL C/C++ is /opt/ibmcmp. XL C/C++ consists of various invocation commands. All commands except for gxlc and gxlc++ have corresponding thread-safe versions. You should use the thread-safe version when building multithreaded applications. Table 1 shows the available invocation commands.

In most cases, you should use the xlC command to compile C++ source files and the xlc command to compile C source files. Use xlC to link if you have both C and C++ object files. Note that the invocation of xlc implied the option -qlanglvl=stdc89 in version 6.0, but implies -qlanglvl=extc89 in versions 7.0 and 8.0.

Back to top

Installing and configuring XL C/C++

You must install the GNU, Java™, and operating system packages outlined in Tables 2 or 3 (depending on the version of Linux you are using) before you install the XL C/C++ compiler.

In its latest release, XL C/C++ provides an interactive utility called xlc_install, which walks you through a basic installation. This utility is located in the root directory of the installation image. We recommend you use xlc_install if you install the compiler to the default location (/opt/ibmcmp/) and want to remove any previously installed XL C/C++ compiler.

After installing XL C/C++, if you need to reconfigure the compiler, we recommend that you run a tool called new_install (located at /opt/ibmcmp/vac/8.0/bin, by default). This tool will in turn execute the vac_configure script and create the appropriate configuration file.

A configuration file contains information about the location of the 32- and 64-bit GCC tools and runtime environment that XL C/C++ should use. This is necessary because there could be more than one instance of GCC installed on a single system; XL C/C++ needs to know which one to use. XL C/C++ provides a utility called vac_configure (located at /opt/ibmcmp/vac/8.0/bin, by default) to help create and update this configuration file.

For more information on installing the compiler, please consult the XL C/C++ for Linux Installation Guide.

Back to top

Optimization options in XL C/C++

XL C/C++ provides a portfolio of the optimization options tailored to IBM hardware. For Linux on POWER, applications compiled with XL C/C++ in many cases have shown significant performance improvements over those compiled with GCC. Note that not all optimizations are beneficial for all applications. A trade-off usually occurs between the degree of optimization performed by the compiler and the extra compile time accompanied by reduced debugging capability.

Optimization levels

Optimization levels are specified by compiler options. Table 4 summarizes the compiler behavior at each optimization level.

Optimizing for a particular processor architecture

Target machine options instruct the compiler to generate code for optimal execution on a given microprocessor or architecture family. By selecting appropriate target machine options, you can optimize to suit the broadest possible selection of target processors, a range of processors within a given family of processor architectures, or a specific processor. The options in Table 5 control optimizations affecting individual aspects of the target machine.

To get the most out of target machine options, you should try to specify with -qarch the smallest possible family of machines that will be expected to run your code well. Try to specify with -qtune the machine where performance should be best. For example, if your application will only be supported on POWER5 systems, use -O3 -qarch=pwr5 -qtune=pwr5. Modification of cache geometry may be useful in cases where the systems have configurable L2 or L3 cache options, or where the execution mode reduces the effective size of a shared level of cache (with two-core-per-chip SMP execution on POWER5 processors, for example).

Power Architecture platforms support machine instructions not available on other platforms. XL C/C++ provides a set of built-in functions that directly map to certain Power Architecture processor instructions. By using these functions, function call return costs, parameter passing, stack adjustment, and all the additional costs related to function invocations are eliminated. For the complete list of the supported built-in functions, please see the XL C/C++ for Linux Compiler Reference document.

Table 6 provides a side-by-side comparison of GNU compiler optimization options and those of XL C/C++.

Back to top

Checking reliance on GNU gcc and g++ language extensions

An application that conforms strictly to ISO language specifications maximizes portability. IBM XL C/C++ supports a subset of the GNU gcc and g++ extensions to C and C++. You may need to revisit code that relies on unsupported extensions. The GCC option -pedantic directs it to print a warning message if any extension is used. There is a complete list of GNU gcc/g++ extensions at the GNU.org site; see Resources for a link.

Back to top

Switching between 32- and 64-bit compiler mode

XL C/C++ can be set to generate either 32- or 64-bit objects by specifying the compiler options -q32 or -q64, or by setting the environment variable OBJECT_MODE. The -q32 and -q64 options override the value set by the OBJECT_MODE variable. If -q32 and -q64 are not specified and OBJECT_MODE is not set, the compiler defaults to 32-bit output mode. In 64-bit mode, the __64BIT__ preprocessor macro is defined.

32- and 64-bit objects cannot be bound together, so you need to ensure that all objects are compiled in the same mode. Your link options must also reflect the type of objects to which you are linking. If you have 64-bit objects, you must link these objects using 64-bit mode.

Back to top

Template instantiation

Template instantiation is one of the features of the C++ language that GCC and XL C/C++ handle differently. The compiler and the linker need to make sure that each template instance occurs exactly once in the executable. This section first discusses how GCC handles template instantiations, then discusses the options available in XL C/C++.

GCC does not support the notion of a template repository, an automatically maintained location where template instances are stored. However, the following options are offered:

• -frepo: With this option, the compiler will generate a file with the extension .rpo for each .cc file that has the template instantiated. This .rpo file contains a listing of template instantiations used in the corresponding object file. At link time, some object files might be recompiled and relinked so that duplication of symbols is avoided.

• -fno-implicit-templates: With this option, you decide which instances must be instantiated. XL C/C++ offers a compiler option, -qtmplinst=none, that gives users similar control over template instantiation. Consult the XL C/C++ for Linux Compiler Reference for the details.

There are a few other options, such as -fexternal-templates and -falt-external-templates, but they are now deprecated.

The following compiler options are available in XL C/C++:

• -qtempinc: With this option, XL C/C++ decides which template code to instantiate as a final step in the compile and link process. This keeps duplicate template instances out of the final executable or library.

  This option requires that your source code be organized in a certain way: the declaration and definition of the template must be in separate files. The definition of the template needs to be in the same directory and have the same name as the header but with a .cc (lower case c) suffix. Otherwise, the header file must use a #pragma implementation("...") statement to identify the corresponding definition file. For example, let's say we have List.h and ListDef.xx as the declaration and definition files, respectively, of the template class List. In the List.h file, there must be a statement #pragma implementation("ListDef.xx").

  When no directory is specified with -qtempinc, the compiler will create a directory called tempinc in the current directory to store the information on the templates to be generated. You can choose your own name and location for this directory so that the same directory may be used when creating an executable that consists of object files compiled in different directories. For example:

  xlC -c foo.cc -qtempinc=../mytemplates cd .. xlC -o app app.cc src/foo.o qtempinc=mytemplates

  
  

  Since template code is actually created at link time by the compiler, this becomes a problem when using templates with shared libraries, where no linking takes place. You should use the option -qmkshrobj with -qtempinc whenever you create shared objects that use templates.

  XL C/C++ will automatically enable the -qtempinc option if it detects the code layout structure mentioned above. If you want to prevent this and manually instantiate templates yourself, you can use the -qnotempinc option. The #pragma define or #pragma instantiate directives can also be used to force the instantiation, like so: #pragma define(List<long>);.

• -qtemplateregistry: This option is available in case you do not want to change your code layout, or do not want to add a #pragma implementation directive in your header files. It relies on a first-come, first-served type of algorithm. When a compilation unit instantiates a new instance for the first time, the compiler creates this instance and keeps the record in a registry file. The name of this registry file can be specified in the option. By default, a file named templateregistry is created in the current directory. When another compilation unit references the same instantiation and uses the same registry file as in the previous compilation unit, this instance will not be instantiated again. Thus, only one copy is generated for the entire program.

The -qtemplateregistry and -qtempinc options are mutually exclusive. Specifying -qtempinc implies -qnotemplateregistry. However, specifying -qnotempinc does not imply -qtemplateregistry.

If you change your source code and recompile only the affected parts, the -qtemplaterecompile option consults the template registry to determine whether changes to this source file require the recompilation of other compilation units. This can occur when the source file has changed in such a way that it no longer references a given instantiation and the corresponding object file previously contained the instantiation. If so, affected compilation units will be recompiled automatically.

If necessary, automatic recompilation of dependent units can be disabled with the -qnotemplaterecompile option. An example would be your automated build process moving object files from their original subdirectory.

Sample code

The code in following listings illustrates how to deal with C++ templates in XL C/C++.

-app/
     | main.cc
     |--- bar/
             |--- bar.cc
     |--- foo/
	 |--- foo.cc
     |--- stack/
	 |--- stack.cc
	 |--- stack.h

#ifndef STACK_H
#define STACK_H

#ifdef TEMPINC
//This is needed when building with -qtempinc 
#pragma implementation("stack.cc")
#endif

template <class T> class stack
{
	private:
		T* array ; 
		int top ;
		int sz ;
      public:
		stack( int ) ; 
		~stack()  ;
		void push( T ) ;
		T pop( );
};

#endif 

#include "stack.h"
#include<stdio.h>

template <class T> stack<T>::stack(int s)
{
	array = new T[sz = s];
	top = 0;
}
template <class T> stack<T>::~stack()
{	
	delete [] array;
}
template <class T> void stack<T>::push( T a )
{
	if ( top >= sz )
	{
		printf( "Out of stack range, push failed\n");
	}
	else
	{
		array[top++] = a ; 
	}
}
template <class T> T stack<T>::pop()
{
	if ( top <= 0 )
  {	
        printf( "out of stack range, pop failed\n");
        return 0;
 	}
	else
	{
		T ret = array[--top];
		return ret;
	}
}

#include "../stack/stack.h"
#include<stdio.h>

#ifdef REGISTRY
#include "../stack/stack.cc"
#endif

stack<int> barstack( 2 ) ;

void bar ()
{
	barstack.push( 5 );
	barstack.push( 6 );
	int p = barstack.pop();
	printf("Pop from barstack is %d\n", p);
}

#include "../stack/stack.h"
#include<stdio.h>

#ifdef REGISTRY
#include "../stack/stack.cc"
#endif


stack<int> foostack( 2 );

void foo ()
{
	foostack.push ( 11 );
	foostack.push ( 12 );
	int p = foostack.pop();
	printf("Pop from foostack is %d\n", p);
}

extern void foo(void);
extern void bar(void);

main(){
	foo();
	bar();   
  return 0 ;
}

To build main using the -qtempinc option, you would issue the following commands :

1. cd stack/
2. xlC -c stack.cc
3. cd ../bar
4. xlC -c bar.cc -DTEMPINC -qtempinc=../mytemp
5. cd ../foo
6. xlC -c foo.cc -DTEMPINC -qtempinc=../mytemp
7. cd ..
8. xlC -o main main.cc -qtempinc=mytemp stack/stack.o bar/bar.o foo/foo.o

Note that bar.cc, foo.cc, and main.cc share the same tempinc directory, named mytemp. As a result, there is only one instance of stack<int> created. Under the mytemp directory, there are two files, stack.C and stack.o. The contents of stack.C are shown in Listing 7.

/*1053113184*/#include "/home/chakarat/Template_va/foo/../stack/stack.h"
/*0000000000*/#include "/home/chakarat/Template_va/stack/stack.cc"
/*1053113184*/#include "/home/chakarat/Template_va/bar/../stack/stack.h"
template stack<int>::stack(int);
template stack<int>::~stack();
template void stack<int>::push(int);
template int stack<int>::pop();

To use the -qtemplateregistry option:

1. cd stack/
2. xlC -c stack.cc
3. cd ../bar
4. xlC -c bar.cc -DREGISTRY -qtemplateregistry=../registry
5. cd ../foo
6. xlC -c foo.cc -DREGISTRY -qtemplateregistry=../registry
7. cd ..
8. xlC -o main main.cc -qtemplateregistry=registry stack/stack.o bar/bar.o foo/foo.o

For more information about the C++ template on XL C/C++, please consult the XL C/C++ for Linux Programming Guide.

Back to top

Runtime linking

Runtime linking is the ability to resolve undefined and undeferred symbols in shared modules after program execution has already begun. Listing 8 is a sample sequence of GCC commands used to build an executable named test with the shared libraries libfoo.so and libbar.so. All of these are enabled for runtime linking.

gcc -c foo.c
gcc -c bar.c
gcc -o libfoo.so foo.o -shared
gcc -o libbar.so bar.o -shared
gcc -o test test.c -L. -lfoo -lbar

To execute test, the environment variable LD_LIBRARY_PATH must include the directories where libfoo.so and libbar.so are located. Alternatively, you can use the option -Wl,-rpath instead of adding the search locations to LD_LIBRARY_PATH. In this case, use this command:

gcc -o test test.c -L. -lfoo -lbar -Wl,-rpath=/home/app

Here, /home/app is the location of libfoo.so and libbar.so.

For XL C/C++, the option -shared must be replaced with the option -qmkshrobj, as in Listing 9.

xlc -c -qpic foo.c
xlc -c -qpic bar.c
xlc -o libfoo.so foo.o -qmkshrobj
xlc -o libbar.so bar.o -qmkshrobj
xlc -o test test.c -L. -lfoo -lbar

XL C/C++ uses the GNU linker; therefore, you can also use the -Wl,-rpath or -R options in XL C/C++ to specify the location of the shared library at link time. You do not have to set the LD_ LIBRARY_PATH variable if you use the -Wl,-rpath or -R options at link time. This embeds the location of the shared library in the executable when it is linked, and so the library is automatically found at runtime.

Back to top

Migrating from GCC to XL C/C++

Moving from GCC to XL C/C++ for Linux on POWER is generally a straightforward task. To assist with this task, XL C/C++ provides an option, -qinfo=por, to help you filter the emitted diagnostic messages to show only those that pertain to portability issues.

In addition, XL C/C++ provides utilities called gxlc and gxlc++ to facilitate the reuse of makefiles created for applications developed with GCC. Each of these utilities takes GNU C or C++ compiler options and translates them into comparable XL C/C++ options. The operations of gxlc and gxlc++ are controlled by the configuration file gxlc.cfg. Not every GNU option has a corresponding XL C/C++ option. gxlc and gxlc++ return warnings for input options that are not translated.

The gxlc and gxlc++ option mappings are modifiable. For information on adding to or editing the gxlc and gxlc++ configuration file, see the XL C/C++ Compiler Reference. A complete list of the option mappings is also available at IBM's Web site; see Resources for a link.

The following actions are recommended when migrating from GCC to the XL C/C++ compiler:

• Use the -qlanglvl=extc99 language level because it mirrors GCC behavior more closely.
  
  
• Define -Dlinux and -Dunix macros. You should do this because GCC predefines them, but XL C/C++ does not.
  
  
• Define -Dinline=__inline__ to force the use of the GCC inline semantics (which are different from the C99 inline semantics).
  
  
• Set the -qnokeyword=_inline option. _inline is recognized as a keyword by XL C/C++, but is parsed as an identifier by GCC.
  
  
• Set the -qkeyword=typeof option. GCC recognizes the identifier typeof as a keyword, while XL C/C++ does not because it invades the user namespace.

Back to top

Redistributable libraries

Your application may require one or more of the runtime libraries from the XL C/C++ compiler packages. When you deliver the application, you need to ensure that the users of the application have the packages containing these libraries, which you can do in one of the following ways:

• You can ship the required packages with the application. The packages should be stored under the rpms directory under the appropriate Linux distribution directory on the installation CD.
• The user can download the packages that contain the libraries from the XL C/C++ support Web site (see Resources for a link).

Back to top

Diagnostics for runtime errors

A program might compile and link successfully, but produce unexpected results during execution. This section describes some common errors, and how to detect and correct them.

Uninitialized variables

An object is not implicitly initialized, and therefore its initial value is indeterminate. If an auto variable is used before it is set, it may not produce the same results every time. -qinitauto=value instructs the compiler to initialize each uninitialized automatic variable to the specified value. The -qinfo=gen option only asks the compiler to report where it finds that an automatic variable has not been initialized.

Runtime checking

The suboptions of -qcheck specify checking for null pointers, indexing outside of array bounds, and division by zero. We recommend that you use the -qcheck option only for debugging because it degrades the runtime performance of the application.

ANSI aliasing

The ANSI aliasing rule states that a pointer can be dereferenced only to an object of the same type or a compatible type. The common coding practice of casting a pointer to an incompatible type and then dereferencing it violates this rule. Setting -qalias=noansi may correct program behavior, but doing so reduces the opportunities for the compiler to optimize the application. We recommend changing your code to conform to the ANSI aliasing rule.

#pragma option_override

Sometimes an error appears only when optimization is used. It can be worthwhile to turn off optimization for a function known to contain a programming error, while allowing the rest of the program to be optimized. This directive allows you to specify alternate optimization options for specific functions. You can also use it to determine which function is causing the problem by selectively turning off optimization for each function in a complex program.

Back to top

Summary

This article aims to facilitate migration from the GNU C/C++ to XL C/C++ compilers. XL C/C++ provides a large set of optimization options tailored to Power Architecture processors, including POWER5+ and PowerPC 970 processors. We recommend using XL C/C++ when you would like to take full advantage of Power Architecture technology's potential.

Back to top

Appendix

Table 7 compares commonly used compiler options from GCC and XL C/C++.

Back to top

Glossary

• Linux on POWER: The Linux operating system runs on POWER systems. In this article, Linux on POWER refers explicitly to IBM eServer pSeries, including eServer p5, eServer iSeries including eServer i5, eServer OpenPower, and eServer BladeCenter JS20 servers.

• Power Architecture technology: The RISC-based chip technology resulted from the partnership between IBM, Motorola, and Apple. A sample of IBM processors based on Power Architecture technology includes RS64 IV, POWER3, POWER4, PowerPC 970, and POWER5.

• p5 or pSeries: IBM's UNIX-based servers running AIX® and/or Linux.

• i5 or iSeries: IBM's integrated servers running OS/400 and Linux.

• GNU Compiler Collection (GCC): The open source GNU Compiler Set, including gcc, the GNU C Compiler, g++, the GNU C++ compiler, and g77, the GNU Fortran77 compiler.

• SUSE Linux Enterprise Server 10 (SLES 10): SUSE LINUX Enterprise Server version 10. This is the most recent enterprise Linux offering from SUSE Linux. In the context of this article, SLES 10 refers to SLES 10 for Power Architecture processors.

• Red Hat Enterprise Linux AS 4 (RHEL 4): Red Hat Enterprise Linux AS version 4. This is the most recent enterprise Linux offering from Red Hat. In the context of this article, RHEL 4 refers to RHEL 4 for Power Architecture processors.

• OpenMP: OpenMP is an industrial standard describing a common set of APIs for symmetric multiprocessing (SMP) programming in C, C++, and Fortran on all architectures, including UNIX and Microsoft Windows NT platforms. See XL C/C++ for Linux Compiler Reference for more information on how XL C/C++ supports the OpenMP specification.

Back to top

Acknowledgments

The authors are most grateful to the IBM compiler team and Solutions Enablement team for their helpful reviews and contributions.

Resources

Learn

• "AIX Linking and Loading Mechanisms," Bradford Cobb, Gary Hook, Christopher Strauss, Ashok Ambati, Anita Govindjee, Wayne Huang, and Vandana Kumar (May 2001): Learn more about linking and loading. (Document is a PDF.)
  
  
• Using the GNU Compiler Collection: The GCC online manual.
  
  
• "Application Development on Linux Power," Matt Davis, Anita Govindjee, and Vandana Kumar (developerWorks, March 2003): Learn how to develop and deploy your applications on Linux on IBM's Power Architecture processor-based servers.
  
  
• Why Linux on POWER?: The Linux on POWER ISV resource center.
  
  
• Linux on Power Architecture: The developer's corner.
  
  
• GNU Compiler Collection home page: Includes a complete list of GNU gcc/g++ extensions.
  
  
• Option mappings for gxlc and gxlc++ utilities: XL C/C++ Enterprise Edition V8.0 for AIX: A complete list of the gxlc and gxlc++ option mappings.
  
  
• In the developerWorks Linux zone, find more resources for Linux developers.
  
  
• Stay current with developerWorks technical events and Webcasts.
  
  

Get products and technologies

• XL C/C++ Advanced Edition for Linux: Learn more at the product page.
  
  
• IBM XL C/C++ Advanced Edition V8.0 for Linux Runtime Environment Component: Download the runtime libraries for XL C/C++.
  
  
• With IBM trial software, available for download directly from developerWorks, build your next development project on Linux.
  
  

Discuss

• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• An overview of XL C/C++
• XL C/C++ documentation
• What's new in version 8
• Compiler modes
• Installing and configuring XL C/C++
• Optimization options in XL C/C++
• Checking reliance on GNU gcc and g++ language extensions
• Switching between 32- and 64-bit compiler mode
• Template instantiation
• Runtime linking
• Migrating from GCC to XL C/C++
• Redistributable libraries
• Diagnostics for runtime errors
• Summary
• Appendix
• Glossary
• Acknowledgments
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Linux on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers