This chapter provides information about the following:
This section provides a brief overview of the new C compiler features and functionality introduced in the Sun Studio 12 C++ 5.9 Compiler release. For specific explanations, follow the cross references provided for each item.
The C compiler is now available on the following Linux distributions (x86 and x64)
SuSE Linux Enterprise Server 9 with Service Pack 3 (or later).
Red Hat Enterprise Linux 4.
Other Linux distributions based on the 2.6 kernel though these are not officially supported.
New -m32|-m64 options to determine the memory model.
New flags for -xarch replace obsolete flags.
New values for -xtarget and -xchip provide code generation for the UltraSPARC T2 and SPARC64vi processors.
New flag -fma=fused to enable generation of fused multiply-add instructions on processors that support them.
Explicit prefetch macros accepted on x86 platforms as well as SPARC platforms. (-xprefetch=explicit)
The way to specify compilation of a 32-bit or 64-bit binary has changed in this release. The A.2.107 –xarch=isaoption no longer carries an implicit memory model, 32-bit ILP32 or 64-bit LP64, with each definition, and is now used only to specify the instruction set of the target processor.
Use the new A.2.50 -m32|-m64 options to specify the memory model of the target compilation.
The ILP32 model specifies that C-language int, long, and pointer data types are all 32-bits wide. The LP64 model specifies that long and pointer data types are all 64-bits wide. The Solaris and Linux OS also support large files and large arrays under the LP64 memory model.
When you compile with -m64, the resulting executable works only on 64-bit UltraSPARC(R) or x86 processors under Solaris OS or Linux OS running a 64-bit kernel. Compilation, linking, and execution of 64-bit objects can only take place in a Solaris or Linux OS that supports 64-bit execution.
There are some important issues to be aware of when compiling for x86 Solaris platforms.
The legacy Sun-style parallelization pragmas are not available on x86. Use OpenMP instead. See the Sun Studio 12: OpenMP API User’s Guide for information on converting legacy parallelization directives to OpenMP.
Programs compiled with -xarch set to sse, sse2, sse2a, or sse3 must be run only on platforms that provide these extensions and features.
Solaris OS releases starting with Solaris 9 4/04 are SSE/SSE2-enabled on Pentium 4-compatible platforms. Earlier versions of Solaris OS are not SSE/SSE2-enabled. If an instruction set selected by -xarch is not enabled in the running Solaris OS, the compiler will not be able to generate or link code for that instruction set.
If you compile and link in separate steps, always link using the compiler and with same -xarch setting to ensure that the correct startup routine is linked.
Numerical results on x86 might differ from results on SPARC due to the x86 80-bit floating-point registers. To minimize these differences, use the -fstore option or compile with x-arch=sse2 if the hardware supports SSE2.
Numerical results can also differ between Solaris and Linux because the intrinsic math libraries (for example, sin(x)) are not the same.
Starting with Sun Studio 11 and the Solaris 10 OS, program binaries compiled and built using these specialized -xarch hardware flags are verified that they are being run on the appropriate platform.
On systems prior to Solaris 10, no verification is done and it is the user's responsibility to ensure objects built using these flags are deployed on suitable hardware.
Running programs compiled with these -xarch options on platforms that are not enabled with the appropriate features or instruction set extensions could result in segmentation faults or incorrect results occurring without any explicit warning messages.
This warning extends also to programs that employ .il inline assembly language functions or __asm() assembler code that utilize SSE, SSE2, SSE2a, and SSE3 instructions and extensions.
The C++ compiler (CC) supports the ISO International Standard for C++, ISO IS 14882:1998, Programming Language—C++. The readme file that accompanies the current release describes any departures from requirements in the standard.
On SPARCTM platforms, the compiler provides support for the optimization-exploiting features of SPARC V8 and SPARC V9, including the UltraSPARCTM implementation. These features are defined in the SPARC Architecture Manuals, Version 8 (ISBN 0-13-825001-4), and Version 9 (ISBN 0-13-099227-5), published by Prentice-Hall for SPARC International.
In this document, “Standard” means conforming to the versions of the standards listed above. “Nonstandard” or “Extension” refers to features that go beyond these versions of these standards.
The responsible standards bodies may revise these standards from time to time. The versions of the applicable standards to which the C++ compiler conforms may be revised or replaced, resulting in features in future releases of the Sun C++ compiler that create incompatibilities with earlier releases.
The C++ compiler’s readme file highlights important information about the compiler, including:
Information discovered after the manuals were printed
New and changed features
Software corrections
Problems and workarounds
Limitations and incompatibilities
Shippable libraries
Standards not implemented
To view the text version of the C++ readme file, type the following at a command prompt:
example% CC -xhelp=readme |
To access the HTML version of the readme, in your Netscape Communicator 4.0 or compatible version browser, open the following file:
/opt/SUNWspro/docs/index.html
(If your C++ compiler-software is not installed in the /opt directory, ask your system administrator for the equivalent path on your system.) Your browser displays an index of HTML documents. To open the readme, find its entry in the index, then click the title.
Online manual (man) pages provide immediate documentation about a command, function, subroutine, or collection of such things.
You can display a man page by running the command:
example% man topic |
Throughout the C++ documentation, man page references appear with the topic name and man section number: CC(1) is accessed with man CC. Other sections, denoted by ieee_flags(3M) for example, are accessed using the -s option on the man command:
example% man -s 3M ieee_flags |
The following C++ utilities are now incorporated into traditional UNIX® tools and are bundled with the UNIX operating system:
lex—Generates programs used in simple lexical analysis of text
yacc—Generates a C function to parse the input stream according to syntax
prof—Produces an execution profile of modules in a program
gprof—Profiles program runtime performance by procedure
tcov—Profiles program runtime performance by statement
See Program Performance Analysis Tools and associated man pages for further information on these UNIX tools.
This release of C++ supports the development of applications in languages other than English, including most European languages and Japanese. As a result, you can easily switch your application from one native language to another. This feature is known as internationalization.
In general, the C++ compiler implements internationalization as follows:
C++ recognizes ASCII characters from international keyboards (in other words, it has keyboard independence and is 8-bit clean).
C++ allows the printing of some messages in the native language.
C++ allows native-language characters in comments, strings, and data.
C++ supports only Extended UNIX Character (EUC) compliant character sets - a character set in which every null byte in a string is the null character and every byte in the string with the ascii value of ’/’ is the ’/’ character.
Variable names cannot be internationalized and must be in the English character set.
You can change your application from one native language to another by setting the locale. For information on this and other native-language support features, see the operating system documentation.
This chapter describes how to use the C++ compiler.
The principal use of any compiler is to transform a program written in a high-level language like C++ into a data file that is executable by the target computer hardware. You can use the C++ compiler to:
Transform source files into relocatable binary (.o) files, to be linked later into an executable file, a static (archive) library (.a) file (using– xar), or a dynamic (shared) library (.so) file
Link or relink object files or library files (or both) into an executable file
Compile an executable file with runtime debugging enabled (-g)
Compile an executable file with runtime statement or procedure-level profiling (-pg)
This section gives you a brief overview of how to use the C++ compiler to compile and run C++ programs. See 16.8 Using dlopen to Access a C++ Library From a C Program for a full reference to the command-line options.
The command-line examples in this chapter show CC usages. Printed output might be slightly different.
The basic steps for building and running a C++ program involve:
Using an editor to create a C++ source file with one of the valid suffixes listed in Table 2–1
Invoking the compiler to produce an executable file
Launching the program into execution by typing the name of the executable file
The following program displays a message on the screen:
example% cat greetings.cc #include <iostream> int main() { std::cout << “Real programmers write C++!” << std::endl; return 0; } example% CC greetings.cc example% a.out Real programmers write C++! example% |
In this example, CC compiles the source file greetings.cc and, by default, compiles the executable program onto the file, a.out. To launch the program, type the name of the executable file, a.out, at the command prompt.
Traditionally, UNIX compilers name the executable file a.out. It can be awkward to have each compilation write to the same file. Moreover, if such a file already exists, it will be overwritten the next time you run the compiler. Instead, use the -o compiler option to specify the name of the executable output file, as in the following example:
example% CC– o greetings greetings.cc |
In this example, the -o option tells the compiler to write the executable code to the file greetings. (It is common to give a program consisting of a single source file the name of the source file without the suffix.)
Alternatively, you could rename the default a.out file using the mv command after each compilation. Either way, run the program by typing the name of the executable file:
example% greetings Real programmers write C++! example% |
The remainder of this chapter discuss the conventions used by the CC command, compiler source line directives, and other issues concerning the use of the compiler.
The general syntax of a compiler command line is as follows:
CC [options] [source-files] [object-files] [libraries] |
An option is an option keyword prefixed by either a dash (–) or a plus sign (+). Some options take arguments.
In general, the processing of the compiler options is from left to right, allowing selective overriding of macro options (options that include other options). In most cases, if you specify the same option more than once, the rightmost assignment overrides and there is no accumulation. Note the following exceptions:
All linker options and the -features, –I -l,– L, -library, –pti, –R, -staticlib, -U, -verbose, -xdumpmacros, and -xprefetch options accumulate, they do not override.
All –U options are processed after all –D options.
Source files, object files, and libraries are compiled and linked in the order in which they appear on the command line.
In the following example, CC is used to compile two source files (growth.C and fft.C) to produce an executable file named growth with runtime debugging enabled:
example% CC -g -o growth growth.C fft.C |
The suffix attached to a file name appearing on the command line determines how the compiler processes the file. A file name with a suffix other than those listed in the following table, or without a suffix, is passed to the linker.
Table 2–1 File Name Suffixes Recognized by the C++ Compiler
Suffix |
Language |
Action |
---|---|---|
C++ |
Compile as C++ source files, put object files in current directory; default name of object file is that of the source but with an .o suffix. |
|
C++ |
Same action as .c suffix. |
|
C++ |
Same action as .c suffix. |
|
C++ |
Same action as .c suffix. |
|
C++ |
Same action as .c suffix. |
|
C++ |
Same action as .c suffix. |
|
C++ |
Preprocessor output file treated as C++ source file. Same action as .c suffix. |
|
Assembler |
Assemble source files using the assembler. |
|
Assembler |
Assemble source files using both the C language preprocessor and the assembler. |
|
Inline expansion |
Process assembly inline-template files for inline expansion. The compiler will use templates to expand inline calls to selected routines. (Inline-template files are special assembler files. See the inline(1) man page.) |
|
Object files |
Pass object files through to the linker. |
|
Static (archive) library |
Pass object library names to the linker. |
|
Dynamic (shared) library |
Pass names of shared objects to the linker. |
The C++ compiler accepts multiple source files on the command line. A single source file compiled by the compiler, together with any files that it directly or indirectly supports, is referred to as a compilation unit. C++ treats each source as a separate compilation unit.
Beginning with the C++ 5.1 compiler, the compiler marks a template cache directory with a string that identifies the template cache’s version.
This compiler does not use the cache by default. It only uses the cache if you specify -instances=extern. If the compiler makes use of the cache, it checks the cache directory’s version and issues error messages whenever it encounters cache version problems. Future C++ compilers will also check cache versions. For example, a future compiler that has a different template cache version identification and that processes a cache directory produced by this release of the compiler might issue an error that is similar to the following message:
Template Database at ./SunWS_cache is incompatible with this compiler |
Similarly, the compiler issues an error if it encounters a cache directory that was produced by a later version of the compiler.
Although the template cache directories produced by the C++ 5.0 compiler are not marked with version identifiers, the current compiler processes the 5.0 cache directories without an error or a warning. The compiler converts the 5.0 cache directories to the directory format that it uses.
The C++ 5.0 compiler cannot use a cache directory that is produced by a later release of the compiler. The C++ 5.0 compiler is not capable of recognizing format differences and it will issue an assertion when it encounters a cache directory that is produced by the C++ 5.1 compiler or by a later release.
When you upgrade your compiler, it is always good practice to clean the cache. Run CCadmin -clean on every directory that contains a template cache directory (in most cases, a template cache directory is named SunWS_cache). Alternatively, you can use rm -rf SunWS_cache.
This section describes some aspects of compiling and linking programs. In the following example, CC is used to compile three source files and to link the object files to produce an executable file named prgrm.
example% CC file1.cc file2.cc file3.cc -o prgrm |
In the previous example, the compiler automatically generates the loader object files (file1.o, file2.o and file3.o) and then invokes the system linker to create the executable program for the file prgrm.
After compilation, the object files (file1.o, file2.o,and file3.o) remain. This convention permits you to easily relink and recompile your files.
If only one source file is compiled and a program is linked in the same operation, the corresponding .o file is deleted automatically. To preserve all .o files, do not compile and link in the same operation unless more than one source file gets compiled.
If the compilation fails, you will receive a message for each error. No .o files are generated for those source files with errors, and no executable program is written.
You can compile and link in separate steps. The -c option compiles source files and generates .o object files, but does not create an executable. Without the -c option, the compiler invokes the linker. By splitting the compile and link steps, a complete recompilation is not needed just to fix one file. The following example shows how to compile one file and link with others in separate steps:
example% CC -c file1.cc Make new object file example% CC -o prgrm file1.o file2.o file3.o Make executable file |
Be sure that the link step lists all the object files needed to make the complete program. If any object files are missing from this step, the link will fail with “undefined external reference” errors (missing routines).
If you do compile and link in separate steps, consistent compiling and linking is critical when using the following compiler options:
-B
-compat
–fast
-g
-g0
-library
-misalign
-mt
-p
-xa
-xarch
–xcg92 and -xcg89
-xipo
-xpagesize
-xpg
-xprofile
-xtarget
If you compile any subprogram using any of these options, be sure to link using the same option as well:
In the case of the -library, -fast, -xtarget, and -xarch options, you must be sure to include the linker options that would have been passed if you had compiled and linked together.
With -p, -xpg, and -xprofile, including the option in one phase and excluding it from the other phase will not affect the correctness of the program, but you will not be able to do profiling.
With -g and -g0, including the option in one phase and excluding it from the other phase will not affect the correctness of the program, but it will affect the ability to debug the program. Any module that is not compiled with either of these options, but is linked with -g or -g0 will not be prepared properly for debugging. Note that compiling the module that contains the function main with the -g option or the -g0 option is usually necessary for debugging.
In the following example, the programs are compiled using the -xcg92 compiler option. This option is a macro for -xtarget=ss1000 and expands to: -xarch=v8 -xchip=super -xcache=16/64/4:1024/64/1.
example% CC -c -xcg92 sbr.cc example% CC -c -xcg92 smain.cc example% CC -xcg92 sbr.o smain.o |
If the program uses templates, it is possible that some templates will get instantiated at link time. In that case the command line options from the last line (the link line) will be used to compile the instantiated templates.
The compilation, linking, and execution of 64-bit objects is supported only in a V9 SPARC, Solaris 8 operating system with a 64-bit kernel running. Compilation for 64-bits is indicated by the –xarch=v9, –xarch=v9a, and -xarch=v9b options.
You can use the –verbose option to display helpful information while compiling a program, such as the names and version numbers of the programs that it invokes and the command line for each compilation phase.
Any arguments on the command line that the compiler does not recognize are interpreted as linker options, object program file names, or library names.
The basic distinctions are:
Unrecognized options, which are preceded by a dash (–) or a plus sign (+), generate warnings.
Unrecognized nonoptions, which are not preceded by a dash or a plus sign, generate no warnings. (However, they are passed to the linker. If the linker does not recognize them, they generate linker error messages.)
In the following example, note that -bit is not recognized by CC and the option is passed on to the linker (ld), which tries to interpret it. Because single letter ld options can be strung together, the linker sees -bit as -b -i -t, all of which are legitimate ld options. This might not be what you intend or expect:
example% CC -bit move.cc < - -bit is not a recognized CC option CC: Warning: Option -bit passed to ld, if ld is invoked, ignored otherwise |
In the next example, the user intended to type the CC option -fast but omitted the leading dash. The compiler again passes the argument to the linker, which in turn interprets it as a file name:
example% CC fast move.cc < - The user meant to type -fast move.CC: ld: fatal: file fast: cannot open file; errno=2 ld: fatal: File processing errors. No output written to a.out |
The C++ compiler package consists of a front end, optimizer, code generator, assembler, template prelinker, and link editor. The CC command invokes each of these components automatically unless you use command-line options to specify otherwise.
Because any of these components may generate an error, and the components perform different tasks, it may be helpful to identify the component that generates an error. Use the -v and -dryrun options to help with this.
As shown in the following table, input files to the various compiler components have different file name suffixes. The suffix establishes the kind of compilation that is done. Refer to Table 2–1 for the meanings of the file suffixes.
Table 2–2 Components of the C++ Compilation System
Component |
Description |
Notes on Use |
---|---|---|
Front end (compiler preprocessor and compiler) | ||
SPARC: Code optimizer |
-xO[2-5], -fast |
|
x86: Intermediate language translator |
-xO[2-5], -fast |
|
SPARC: Inline expansion of assembly language templates |
.il file specified |
|
x86: Interprocedural analyzer |
-xcrossfile=1 with -xO4, -xO5, or -fast |
|
Assembler | ||
SPARC: Code generator, inliner, assembler |
|
|
ube |
x86: Code generator |
-xO[2-5], -fast |
Template pre-linker | ||
Nonincremental link editor |
This section discusses information about preprocessing directives that is specific to the C++ compiler.
The preprocessor keyword pragma is part of the C++ standard, but the form, content, and meaning of pragmas is different for every compiler. See A.2.185 -z[ ]arg for a list of the pragmas that the C++ compiler recognizes.
The C++ compiler accepts #define preprocessor directives of the following form.
#define identifier (...) replacement_list #define identifier (identifier_list, ...) replacement_list |
If the macro parameter list ends with an ellipsis, an invocation of the macro is allowed to have more arguments than there are macro parameters. The additional arguments are collected into a single string, including commas, that can be referenced by the name __VA_ARGS__ in the macro replacement list. The following example demonstrates how to use a variable-argument-list macro.
#define debug(...) fprintf(stderr, __VA_ARGS__) #define showlist(...) puts(#__VA_ARGS__) #define report(test, ...) ((test)?puts(#test):\ printf(__VA_ARGS__)) debug(“Flag”); debug(“X = %d\n”,x); showlist(The first, second, and third items.); report(x>y, “x is %d but y is %d”, x, y); |
which results in the following:
fprintf(stderr, “Flag”); fprintf(stderr, “X = %d\n”, x); puts(“The first, second, and third items.”); ((x>y)?puts(“x>y”):printf(“x is %d but y is %d”, x, y)); |
Table A–2 in the appendix shows the predefined macros. You can use these values in such preprocessor conditionals as #ifdef.The +p option prevents the automatic definition of the sun, unix, sparc, and i386 predefined macros.
The #error directive no longer continues compilation after issuing a warning. The previous behavior of the directive was to issue a warning and continue compilation. The new behavior, consistent with other compilers, is to issue an error message and immediately halt compilation. The compiler quits and reports the failure.
The amount of memory a compilation requires depends on several parameters, including:
Size of each procedure
Level of optimization
Limits set for virtual memory
Size of the disk swap file
On the SPARC platform, if the optimizer runs out of memory, it tries to recover by retrying the current procedure at a lower level of optimization. The optimizer then resumes subsequent routines at the original level specified in the -xOlevel option on the command line.
If you compile a single source file that contains many routines, the compiler might run out of memory or swap space. If the compiler runs out of memory, try reducing the level of optimization. Alternately, split multiple-routine source files into files with one routine per file.
The swap -s command displays available swap space. See the swap(1M) man page for more information.
The following example demonstrates the use of the swap command:
example% swap -s total: 40236k bytes allocated + 7280k reserved = 47516k used, 1058708k available |
Use mkfile(1M) and swap (1M) to increase the size of the swap space on a workstation. (You must become superuser to do this.) The mkfile command creates a file of a specific size, and swap -a adds the file to the system swap space:
example# mkfile -v 90m /home/swapfile /home/swapfile 94317840 bytes example# /usr/sbin/swap -a /home/swapfile |
Compiling very large routines (thousands of lines of code in a single procedure) at -xO3 or higher can require a large amount of memory. In such cases, performance of the system might degrade. You can control this by limiting the amount of virtual memory available to a single process.
To limit virtual memory in an sh shell, use the ulimit command. See the sh(1) man page for more information.
The following example shows how to limit virtual memory to 16 Mbytes:
example$ ulimit -d 16000 |
In a csh shell, use the limit command to limit virtual memory. See the csh(1) man page for more information.
The next example also shows how to limit virtual memory to 16 Mbytes:
example% limit datasize 16M |
Each of these examples causes the optimizer to try to recover at 16 Mbytes of data space.
The limit on virtual memory cannot be greater than the system’s total available swap space and, in practice, must be small enough to permit normal use of the system while a large compilation is in progress.
Be sure that no compilation consumes more than half the swap space.
With 32 Mbytes of swap space, use the following commands:
In an sh shell:
example$ ulimit -d 16000 |
In a csh shell:
example% limit datasize 16M |
The best setting depends on the degree of optimization requested and the amount of real memory and virtual memory available.
A workstation should have at least 64 megabytes of memory; 128 Mbytes are recommended.
To determine the actual real memory, use the following command:
example% /usr/sbin/dmesg | grep mem mem = 655360K (0x28000000) avail mem = 602476544 |
You can simplify complicated compiler commands by defining special shell aliases, using the CCFLAGS environment variable, or by using make.
The following example defines an alias for a command with frequently used options.
example% alias CCfx "CC -fast -xnolibmil" |
The next example uses the alias CCfx.
example% CCfx any.C |
The command CCfx is now the same as:
example% CC -fast -xnolibmil any.C |
You can specify options by setting the CCFLAGS variable.
The CCFLAGS variable can be used explicitly in the command line. The following example shows how to set CCFLAGS (C Shell):
example% setenv CCFLAGS ’-xO2 -xsb’ |
The next example uses CCFLAGS explicitly.
example% CC $CCFLAGS any.cc |
When you use make, if the CCFLAGS variable is set as in the preceding example and the makefile’s compilation rules are implicit, then invoking make will result in a compilation equivalent to:
CC -xO2 -xsb files...
The make utility is a very powerful program development tool that you can easily use with all Sun compilers. See the make(1S) man page for additional information.
When you are using the implicit compilation rules of the makefile (that is, there is no C++ compile line), the make program uses CCFLAGS automatically.
You can incorporate different file suffixes into C++ by adding them to your makefile. The following example adds .cpp as a valid suffix for C++ files. Add the SUFFIXES macro to your makefile:
SUFFIXES: .cpp .cpp~
(This line can be located anywhere in the makefile.)
Add the following lines to your makefile. Indented lines must start with a tab.
.cpp: $(LINK.cc) -o $@ $< $(LDLIBS) .cpp~: $(GET) $(GFLAGS) -p $< > $*.cpp $(LINK.cc) -o $@ $*.cpp $(LDLIBS) .cpp.o: $(COMPILE.cc) $(OUTPUT_OPTION) $< .cpp~.o: $(GET) $(GFLAGS) -p $< > $*.cpp $(COMPILE.cc) $(OUTPUT_OPTION) $< .cpp.a: $(COMPILE.cc) -o $% $< $(COMPILE.cc) -xar $@ $% $(RM) $% .cpp~.a: $(GET) $(GFLAGS) -p $< > $*.cpp $(COMPILE.cc) -o $% $< $(COMPILE.cc) -xar $@ $% $(RM) $% |
The standard library file names do not have .h suffixes. Instead, they are named istream, fstream, and so forth. In addition, the template source files are named istream.cc, fstream.cc, and so forth.
This chapter explains how to use the command-line C++ compiler options and then summarizes their use by function. Detailed explanations of the options are provided in 16.8 Using dlopen to Access a C++ Library From a C Program.
The following table shows examples of typical option syntax formats that are used in this book.
Table 3–1 Option Syntax Format Examples
Syntax Format |
Example |
---|---|
-option |
–E |
–optionvalue |
–Ipathname |
–option=value |
–xunroll=4 |
–option value |
–o filename |
Parentheses, braces, brackets, pipe characters, and ellipses are metacharacters used in the descriptions of the options and are not part of the options themselves. See the typographical conventions in “Before You Begin” at the front of this manual for a detailed explanation of the usage syntax.
Some general guidelines for the C++ compiler options are:
The– llib option links with library liblib.a (or liblib.so). It is always safer to put– llib after the source and object files to ensure the order in which libraries are searched.
In general, processing of the compiler options is from left to right (with the exception that– U options are processed after all– D options), allowing selective overriding of macro options (options that include other options). This rule does not apply to linker options.
The -features,–I -l, –L, -library, –pti, –R, -staticlib, -U, -verbose, and -xprefetch options accumulate, they do not override.
The -D option accumulates, However, multiple -D options for the same name override each other.
Source files, object files, and libraries are compiled and linked in the order in which they appear on the command line.
In this section, the compiler options are grouped by function to provide a quick reference. For a detailed description of each option, refer to 16.8 Using dlopen to Access a C++ Library From a C Program.
The options apply to all platforms except as noted; features that are unique to the Solaris OS on SPARC-based systems are identified as SPARC, and the features that are unique to the Solaris OS on x86-based systems are identified as x86.
Option |
Action |
---|---|
–compat |
Sets the major release compatibility mode of the compiler. |
+e{0|1} |
Controls virtual table generation. |
–g |
Compiles for use with the debugger. |
–KPIC |
Produces position-independent code. |
–Kpic |
Produces position-independent code. |
–mt |
Compiles and links for multithreaded code. |
–xcode=a |
(SPARC) Specifies the code address space. |
–xMerge |
(SPARC) Merges the data segment with the text segment. |
–xmodel |
Modifies the form of 64-bit objects for the Solaris x86 platforms |
+w |
Identifies code that might have unintended consequences. |
+w2 |
Emits all the warnings emitted by +w plus warnings about technical violations that are probably harmless, but that might reduce the maximum portability of your program. |
-xregs |
The compiler can generate faster code if it has more registers available for temporary storage (scratch registers). This option makes available additional scratch registers that might not always be appropriate. |
-z arg |
Linker option. |
Option |
Action |
---|---|
–instlib |
Inhibits the generation of template instances that are already present in the designated library. |
-m32|-m64 |
Specifies the memory model for the compiled binary object. |
-xinstrument |
Compiles and instruments your program for analysis by the Thread Analyzer. |
–xjobs |
Sets the number of processes the compiler can create to complete its work. |
–xpch |
May reduce compile time for applications whose source files share a common set of include files. |
–xpchstop |
Specifies the last include file to be considered in creating a pre-compiled header file with -xpch. |
–xprofile_ircache |
(SPARC) Reuses compilation data saved during -xprofile=collect. |
–xprofile_pathmap |
(SPARC) Support for multiple programs or shared libraries in a single profile directory. |
The following table lists the options that must be specified both at link-time and at compile-time.
Table 3–4 Compile-Time and Link-Time Options
Option |
Action |
---|---|
+d |
Does not expand C++ inline functions. |
–dryrun |
Shows options passed by the driver to the compiler, but does not compile. |
–E |
Runs only the preprocessor on the C++ source files and sends result to stdout. Does not compile. |
–g |
Compiles for use with the debugger. |
–g0 |
Compiles for debugging, but doesn’t disable inlining. |
–H |
Prints path names of included files. |
–keeptmp |
Retains temporary files created during compilation. |
–migration |
Explains where to get information about migrating from earlier compilers. |
–P |
Only preprocesses source; outputs to .i file. |
–Qoption |
Passes an option directly to a compilation phase. |
–readme |
Displays the content of the online README file. |
–s |
Strips the symbol table out of the executable file, thus preventing the ability to debug code. |
–temp=dir |
Defines directory for temporary files. |
–verbose=vlst |
Controls compiler verbosity. |
-xcheck |
Adds a runtime check for stack overflow. |
-xdumpmacros |
Prints information about macros such as definition, location defined and undefined, and locations used. |
–xe |
Only checks for syntax and semantic errors. |
–xhelp=flags |
Displays a summary list of compiler options. |
–xport64 |
Warns against common problems during a port from a 32-bit architecture to a 64-bit architecture. |
–xs |
Allows debugging with dbx without object (.o) files. |
–xsb |
Produces table information for the source browser. |
–xsbfast |
Produces only source browser information, no compilation. |
Option |
Action |
---|---|
-fma |
(SPARC) Enables automatic generation of floating-point, fused, multiply-add instructions. |
–fns[={no|yes}] |
(SPARC) Disables or enables the SPARC nonstandard floating-point mode. |
–fprecision=p |
x86: Sets floating-point precision mode. |
–fround=r |
Sets IEEE rounding mode in effect at startup. |
–fsimple=n |
Sets floating-point optimization preferences. |
–fstore |
x86: Forces precision of floating-point expressions. |
–ftrap=tlst |
Sets IEEE trapping mode in effect at startup. |
–nofstore |
x86: Disables forced precision of expression. |
–xlibmieee |
Causes libm to return IEEE 754 values for math routines in exceptional cases. |
Option |
Action |
---|---|
–compat |
Sets the major release compatibility mode of the compiler. |
–features=alst |
Enables or disables various C++ language features. |
-xchar |
Eases the migration of code from systems where the char type is defined as unsigned. |
–xldscope |
Controls the default linker scope of variable and function definitions to create faster and safer shared libraries. |
–xthreadvar |
(SPARC) Changes the default thread-local storage access mode. |
-xtrigraphs |
Enables recognition of trigraph sequences. |
–xustr |
Enables recognition of string literals composed of sixteen-bit characters. |
Option |
Action |
---|---|
–Bbinding |
Requests symbolic, dynamic, or static library linking. |
–d{y|n} |
Allows or disallows dynamic libraries for the entire executable. |
–G |
Builds a dynamic shared library instead of an executable file. |
–hname |
Assigns a name to the generated dynamic shared library. |
–i |
Tells ld(1) to ignore any LD_LIBRARY_PATH setting. |
–Ldir |
Adds dir to the list of directories to be searched for libraries. |
–llib |
Adds liblib.a or liblib.so to the linker’s library search list. |
–library=llst |
Forces inclusion of specific libraries and associated files into compilation and linking. |
–mt |
Compiles and links for multithreaded code. |
–norunpath |
Does not build path for libraries into executable. |
–Rplst |
Builds dynamic library search paths into the executable file. |
–staticlib=llst |
Indicates which C++ libraries are to be linked statically. |
–xar |
Creates archive libraries. |
-xbuiltin[=opt] |
Enables or disables better optimization of standard library calls |
-xia |
(SPARC) Links the appropriate interval arithmetic libraries and sets a suitable floating-point environment. |
-xlang=l[,l] |
Includes the appropriate runtime libraries and ensures the proper runtime environment for the specified language. |
–xlibmieee |
Causes libm to return IEEE 754 values for math routines in exceptional cases. |
–xlibmil |
Inlines selected libm library routines for optimization. |
–xlibmopt |
Uses library of optimized math routines. |
-xlic_lib=sunperf |
(SPARC) Links in the Sun Performance LibraryTM. Note that for C++, -library=sunperf is the preferable method for linking in this library. |
-xnativeconnect |
Includes interface information inside object files and subsequent shared libraries so that the shared library can interface with code written in the JavaTM programming language. |
–xnolib |
Disables linking with default system libraries. |
–xnolibmil |
Cancels– xlibmil on the command line. |
–xnolibmopt |
Does not use the math routine library. |
Option |
Action |
---|---|
–xlic_lib=sunperf |
(SPARC) Links in the Sun Performance Library. Note that for C++, -library=sunperf is the preferable method for linking in this library. |
–xlicinfo |
Shows license server information. |
The following options are either currently obsolete and so no longer accepted by the compiler, or they will be removed in a future release.
Option |
Action |
---|---|
-library=%all |
Obsolete option that will be removed in a future release. |
–noqueue |
Disables license queueing. |
-ptr |
Ignored by the compiler. A future release of the compiler may reuse this option using a different behavior. |
-vdelx |
Obsolete option that will be removed in a future release. |
-xcg89 |
Use -xtarget=ss2 |
-xnativeconnect |
Obsolete, there is no alternative option. |
-xprefetch=yes |
Use -xprefetch=auto,explicit instead. |
-xprefetch=no |
Use -xprefetch=no%auto,no%explicit instead. |
-xvector=yes |
Use -xvector=lib instead. |
-xvector=no |
Use -xvecttor=none instead. |
Option |
Action |
---|---|
–c |
Compiles only; produces object (.o) files, but suppresses linking. |
–dryrun |
Shows options passed by the driver to the compiler, but does not compile. |
–E |
Runs only the preprocessor on the C++ source files and sends result to stdout. Does not compile. |
-erroff |
Suppresses compiler warning messages. |
-errtags |
Displays the message tag for each warning message. |
-errwarn |
If the indicated warning message is issued, cc exits with a failure status. |
-filt |
Suppresses the filtering that the compiler applies to linker error messages. |
–G |
Builds a dynamic shared library instead of an executable file. |
–H |
Prints path names of included files. |
–migration |
Explains where to get information about migrating from earlier compilers. |
–o filename |
Sets name of the output or executable file to filename. |
–P |
Only preprocesses source; outputs to .i file. |
–Qproduce sourcetype |
Causes the CC driver to produce output of the type sourcetype. |
–s |
Strips the symbol table out of the executable file. |
–verbose=vlst |
Controls compiler verbosity. |
+w |
Prints extra warnings where necessary. |
–w |
Suppresses warning messages. |
-xdumpmacros |
Prints information about macros such as definition, location defined and undefined, and locations used. |
-xe |
Performs only syntax and semantic checking on the source file, but does not produce any object or executable code. |
–xhelp=flags |
Displays a summary list of compiler options |
–xhelp=readme |
Displays the contents of the online README file. |
–xM |
Outputs makefile dependency information. |
–xM1 |
Generates dependency information, but excludes /usr/include. |
–xsb |
Produces table information for the source browser. |
–xsbfast |
Produces only source browser information, no compilation. |
–xtime |
Reports execution time for each compilation phase. |
–xwe |
Converts all warnings to errors by returning non-zero exit status. |
-z arg |
Option |
Action |
---|---|
–fast |
Selects a combination of compilation options for optimum execution speed for some programs. |
-fma |
(SPARC) Enables automatic generation of floating-point, fused, multiply-add instructions. |
-g |
Instructs both the compiler and the linker to prepare the program for performance analysis (and for debugging). |
–s |
Strips the symbol table out of the executable. |
-m32|-m64 |
Specifies the memory model for the compiled binary object. |
-xalias_level |
Enables the compiler to perform type-based alias analysis and optimizations. |
–xarch=isa |
Specifies target architecture instruction set. |
-xbinopt |
Prepares the binary for later optimizations, transformations and analysis. |
-xbuiltin[=opt] |
Enables or disables better optimization of standard library calls |
–xcache=c |
(SPARC) Defines target cache properties for the optimizer. |
–xcg89 |
Compiles for generic SPARC architecture. |
–xcg92 |
Compiles for SPARC V8 architecture. |
–xchip=c |
Specifies target processor chip. |
–xF |
Enables linker reordering of functions and variables. |
-xinline=flst |
Specifies which user-written routines can be inlined by the optimizer |
-xipo |
Performs interprocedural optimizations. |
–xlibmil |
Inlines selected libm library routines for optimization. |
–xlibmopt |
Uses a library of optimized math routines. |
–xlinkopt |
(SPARC) Performs link-time optimization on the resulting executable or dynamic library over and above any optimizations in the object files. |
–xmemalign=ab |
(SPARC) Specify maximum assumed memory alignment and behavior of misaligned data accesses. |
–xnolibmil |
Cancels– xlibmil on the command line. |
–xnolibmopt |
Does not use the math routine library. |
–xOlevel |
Specifies optimization level to level. |
–xpagesize |
Sets the preferred page size for the stack and the heap. |
-xpagesize_heap |
Sets the preferred page size for the heap. |
-xpagesize_stack |
Sets the preferred page size for the stack. |
-xprefetch[=lst] |
(SPARC) Enables prefetch instructions on architectures that support prefetch. |
-xprefetch_level |
Control the aggressiveness of automatic insertion of prefetch instructions as set by -xprefetch=auto |
–xprofile |
(SPARC) Collects or optimizes using runtime profiling data. |
–xregs=rlst |
(SPARC) Controls scratch register use. |
–xsafe=mem |
(SPARC) Allows no memory-based traps. |
–xspace |
(SPARC) Does not allow optimizations that increase code size. |
–xtarget=t |
Specifies a target instruction set and optimization system. |
–xthreadvar |
(SPARC) Changes the default thread-local storage access mode. |
–xunroll=n |
Enables unrolling of loops where possible. |
–xvis |
(SPARC) Enables compiler recognition of the assembly-language templates defined in the VISTM instruction set |
Option |
Action |
---|---|
–Dname[=def] |
Defines symbol name to the preprocessor. |
–E |
Runs only the preprocessor on the C++ source files and sends result to stdout. Does not compile. |
-H |
Prints path names of included files. |
–P |
Only preprocesses source; outputs to .i file. |
–Uname |
Deletes initial definition of preprocessor symbol name. |
–xM |
Outputs makefile dependency information. |
–xM1 |
Generates dependency information, but excludes /usr/include. |
Option |
Action |
---|---|
–p |
Prepares the object code to collect data for profiling using prof. |
–xa |
Generates code for profiling. |
–xpg |
Compiles for profiling with the gprof profiler. |
–xprofile |
(SPARC) Collects or optimizes using runtime profiling data. |
Option |
Action |
---|---|
–migration |
Explains where to get information about migrating from earlier compilers. |
–xhelp=flags |
Displays a summary list of compiler options. |
–xhelp=readme |
Displays the contents of the online README file. |
Option |
Action |
---|---|
-H |
Prints path names of included files. |
–Ipathname |
Adds pathname to the include file search path. |
-I- |
Changes the include-file search rules |
–xM |
Outputs makefile dependency information. |
–xM1 |
Generates dependency information, but excludes /usr/include. |
Option |
Action |
---|---|
–instances=a |
Controls the placement and linkage of template instances. |
–ptipath |
Specifies an additional search directory for the template source. |
–template=wlst |
Enables or disables various template options. |
Option |
Action |
---|---|
–mt |
Compiles and links for multithreaded code. |
–xsafe=mem |
(SPARC) Allows no memory-based traps. |
–xthreadvar |
(SPARC) Changes the default thread-local storage access mode. |