LCC(1L) — Lucid MANUAL PAGES

NAME

lcc − Lucid K&R C / ANSI C / C++ compiler

SYNOPSIS

lcc [ option ] ... file ...

DESCRIPTION

lcc invokes the Lucid K&R C / ANSI C / C++ compiler to compile K&R C , ANSI C or C++ source programs into assembly or object modules suitable for execution on SPARC-based systems under the SunOS 4.x and SunOS 5.x (Solaris 2.x) Operating Systems.

lcc accepts a parameter list that consists of options and input file-names in any order. Each input file-name must have one of the following suffixes:

.C, .c, .cc, .cxx, .cpp, .h, .hh, .i
C++/C source code file. By convention, .C, .cc, .cxx, .cpp, and .hh files are used to denote C++ code while .c, .h and .i files are used for C source files. In the C++ modes, all files are compiled in the specified dialect, regardless of the suffix. However, in C modes, any file with a C++ suffix will be processed in the cfront-2.1 compatible C++ mode (-Xf).

.n intermediate code file.

.s SPARC assembler source code file

.o object file (output of previous compiler or assembler run, input to linker)

Any file with none of the above suffixes is assumed to contain object code and is given to the linker.

Unless otherwise specified, each .c, .C, .cc, .cpp, .cxx, .i and .h file is translated by the compiler front end into a .n intermediate code file.

Each .n file is translated by the compiler back end into a .o (object) or .s (assembly) file. Each .s file is translated by the system assembler into a .o file. Lastly, all the .o files are combined by the system linker, ld, into the executable result file. If the output file name is not overridden with the "-o" option, the executable result is left in "a.out".

With no parameters, or when no file names are present, lcc simply identifies itself, prints its version number, and displays a list of the most frequently needed options.

During its processing, lcc produces various intermediate files which are deleted after they are used. The -E, -X1, -S and -c options can be specified to terminate lcc processing at various intermediate points, leaving the corresponding intermediate files in the current working directory. By default lcc starts in the extended ANSI C mode (-Xa) for files with a C suffix and cfront 2.1 compatible C++ mode (-Xf) for files with a C++ suffix. In the absence of a C or C++ suffix, the compiler defaults to the extended ANSI C mode (e.g. for linking .o files).

The default dialect can be overridden by use of the -XF option which enforces the language defined by the Annotated C++ Reference Manual (ARM, or E&S, as it is sometimes called), -Xf option which enforces the cfront-2.1 compatible C++ mode, -XA option which invokes the strict ANSI C, -Xa option which invokes the extended ANSI C mode or the -Xk option which invokes the K&R mode. However, in any of the C modes, all .C, .cc, .cpp, .cxx, and .hh files will be compiled in C++ mode (-Xf, the cfront 2.1 compatible C++ mode). In the absence of a -c option, a C++ style "link" operation will be performed if any files are compiled in a C++ mode. The -Xf (or -XF) option must be used explicitly when linking .o files that are the result of a previous C++ compilation.

See the description of these options for definitions of each dialect as well as how the selected dialect can change while processing header (#include) files.

The following options are supported. All other options, unless prefixed with -X, are passed to the linker without any processing. Options for use with the template-instantiation subsystem in lcc 3.0 are listed separately at the end.

−Bstatic
Statically link the executable file, if one is created. This will only affect the link phase and is used to suppress the default (dynamic) linking invoked by the compiler.

−c Suppress the loading phase of the compilation and leave the object module files (one .o file for each input file) in the current working directory.

−C Leave the comments in the output of the preprocessor. This is ignored if the -E option is not specified.

−dalign Assume all double type objects are properly aligned on two word boundaries. Using this option can improve the runtime performance of floating point intensive applications, but it can be used when the assumption is uniformly followed. Both lcc and cc follow this rule for double type objects that they allocate but the rule is not always followed for objects explicitly allocated in the user code or libraries built by other compilers.

−dryrun Show the user what commands would be executed to for the given compile line. Nothing actually gets executed, changed, or removed.

−Dname=def

−Dname Define name to the preprocessor, as if by #define. If no definition is given, name is defined as 1.

−E Run only the preprocessor on the named C programs and send the result to the standard output.

−g Produce additional symbol table information for use by a debugger. This inhibits most optimizations, including inline expansion of calls to library functions and C++ inline functions, and forces stack frames to be generated for all functions so the debugger can generate stack tracebacks. Unlike other conflicting options, this switch will always override any explicit -O options on the same command line, independent of the order in which they are listed.

−H[S] Produce a listing on stderr of all the #include directives the compiler actually processes. Each #include is preceded by the nesting level at which it was encountered. If a #include is skipped because it is in conditional code that is skipped, it is not listed. If a #include is skipped because the include file has already been included and was guarded against multiple inclusion by #ifndef XXXX #define XXXX .... #endif with nothing but whitespace before the #ifndef and after the #endif, then it will not be listed unless the optional "S" is specified.

This option can aid in the creation of a "universe.h" file to be used with precompiled headers.

−h Show help information for the lcc command. This also occurs if no file names are specified.

−i[file-name] Do an implicit #include "file-name" just before compiling the first line of the program. The rules for locating the file to include are the same as if this #include were the first line in the program.

If precompiled headers are selected by the -XH option, then a precompiled header will be created just after the #include "file-name" is compiled. Any future compilations that specify the same -i and -XH options will use the precompiled header, provided that the rest of the options are compatible. The -i option turns on warning messages about unguarded include files, -wg. These warnings can be suppressed by use of the -wuc option. At most one -ifile-name option can appear on the command line. If a -i option with no file-name appears, it cancels the effect of a -ifile-name option that appears to its left on the command line.

−Idir If neither −I− nor −Xsearch_cwd options are present, #include files whose names do not begin with / and are enclosed in quotes (") are sought first in the directory in which the including file resides, then in directories named in −I options. Next, and only in ANSI C and C++ modes, the files are sought in the Lucid ANSI C header directory, and then in the Lucid C++ header directory (C++ mode only). Lastly, /usr/include is searched. The same rules apply for include files whose names are enclosed in < and >, except that the including file’s directory is not searched.

−I− Modifies the normal search rules for #include files. Names that do not begin with / and are enclosed in quotes (") are not searched for in the directory in which the including file resides. The search for names that do not begin with / and are enclosed in "<" and ">" starts with directories specified by −I options after the −I− and does not look at those specified before −I−.

−lname Use the library libname.a to resolve any unresolved externals from all the files listed before this -l option. See ld(1) for more information. In ANSI C modes, the Lucid ANSI C library is automatically included after the last file-name to cause this library to be automatically searched. In C++ modes, the options -liostream and -lcplus are automatically supplied just before the Lucid library to cause the Lucid C++ libraries to be searched. In all modes, the option -lc as well as -lm are included at the end to cause the system C and Math libraries to be searched. The Lucid ANSI C library and the C++ iostream library can be excluded from the link process by the use of -X- option. If profiling is selected by the -p option, "_p" is appended to the automatically generated -l options to cause the "profile" versions of the libraries to be searched and loaded.

−Ldir Add dir to the list of directories in which to search for libraries at link time. In ANSI and C++ modes, a -L option specifying the path name of the directory in which the Lucid libraries reside is automatically included after any -L options specified by the user. See ld(1) for more information.

−o output
Name the final output file output. If this parameter is not specified, the name of the final executable output will be a.out. When compiling one file, this option can be used to name the resulting .o or .s file, if -c or -S is used.

−O This is the recommended optimization selection switch and is shorthand for "-O3". See the description of "-O3" below.

−O− Turn all optimizations off.

−O0 Perform local optimizations on "extended" basic blocks as well as global register allocation. This is the same as "-Oler" and is also the default optimization mode used if no "-O" options are specified.

−O1 Perform all local optimizations, global register allocation, global constant propagation as well as code hoisting and induction variable elimination on inner loops (i.e. elimination of partial and total redundancies within loops). This is shorthand for "-Olerg1".

−O2 In addition to the "O1" optimizations, perform redundant store elimination and perform loop optimizations (code hoisting, induction variable elimination) on loop nests. This is shorthand for the "-Olerg2".

−O3 This is similar to the previous level except that it performs global copy propagation and extends the scope of elimination of partial and total redundancies to include entire functions, as opposed to loops. This is the default for "-O" and is also shorthand for "-Olerg3s".

−O4 This is similar to the previous level except that the global copy propagation and redundant store elimination phases are applied repeatedly (in practice up to 3 times) to each function, as long as each application results in further improvement of the generated code. "-O4" is shorthand for "-Olerg4s".

−O5 In addition to -O4 optimizations, make processor registers %g2-%g7 available for use by the optimizer. This is equivalent to the combination of options, -O4 -OG. See the description of -OG below.

−O{ l,e,r,g,g1,g2,g3,g4,g5,s} This is a more detailed interface to the optimizer than the preferred "-O{-,0,1,2,3,4,5}" mechanism. "l" is the local optimizer, "e" is the extended basic block optimizer, "r" is the global register allocator, "g" is the global optimizer, and "s" is the instruction scheduler. "g1" thorough "g5" select increasingly higher level of global optimizations as described above, with "g" being shorthand for "g3". Any combination of these options is acceptable (for example, "-Olge"). In case of conflicts the last option encountered is used. If no "-O" option is used, then the compiler performs local optimizations and global register allocation, as if"-Oler" had been specified. Also note that compilation time tends to increase with increased optimization level.

−OG Consider all of the processor registers as available during the register-allocation phase. Ordinarily, and to be compatible with the Sun C compiler code generation conventions, the lcc code generator will not use global registers %g2-%g7 within functions that require a register window (non-leaf function). Relaxing this restriction may result in better code (performance) if compatibility is not a concern.

−Oi− Disable source (language) level function inlining. This does not affect (intrinsic) library function inlining which is controlled by the -Xx option.

−Oi0 Re-enable inline-expansion of "inline" declared C++ functions. This option can be used with debug (-g) or profile (-p, -pg) options which would otherwise disable all inlining.

−Oi

−Oi[1-4] Perform inlining optimizations. This causes the compiler to expand function calls inline if the function body is present in the same file as the call, and if the compiler considers the inlining to be worthwhile. Finer control over the size of the functions that are considered for inlining is possible by supplying a single digit inlining level-number (1-4) following the option key. Higher numbers result in larger functions to be inlined, possibly resulting in larger object files and executables. The unqualified -Oi form corresponds to -Oi2.

Note that the -Oi flag enables inlining of all functions, whether declared "inline" or not.

−Ou Perform the "loop unrolling" optimization. This may have an impact on the size and layout of the generated code (i.e. beware of timing anomalies due to processor cache)

−p Produce "profiling" code that counts the number of times each routine is called, for use with system tool prof(1). This option is not supported on the Solaris Operating System.

−pg Produce counting code in the manner of −p, but invoke a run-time recording mechanism that keeps more extensive statistics at normal termination, for use with system tool gprof(1). This option is not supported on the Solaris Operating System.

−pic Generate position independent code in the "pic" model. Position independent code is necessary for object modules that are to be part of a shared library.

−PIC Generate position independent code in the "PIC" model. Position independent code is necessary for object modules that are to be part of a shared library.

−P Run only the preprocessor on the named C programs and send the results to the corresponding .i files.

−R Directs the Lucid compiler driver to define read-only data. If a .s file is named in the command line, the driver passes -R to "as" to assemble the .s file with the -R option. Otherwise, if -Xu is also specified, the driver passes -R to "cc". If -R is specified in any other contexts, the driver ignores it.

−S Stop the compilation after generating assembly code, leaving the assembly language .s file(s) in the current working directory.

−Uname Remove any initial definition of name from the compilation environment. This can be used to remove the compiler predefined preprocessor symbols (identifying the target, the compiler, etc.) from the compilation environment.

The predefined symbols for each compiler dialect are as follows:

K&R	ANSI C	Extended ANSI C	C++

__LUCID_KR_PP__	__LUCID_ANSI_PP__	__LUCID_ANSI_PP__	(∗)
__KR__	__STDC_EXTENDED__	__STDC_EXTENDED__
	__NOT_KR	__NOT_KR	__NOT_KR
	__STDC__	__STDC__	(∗)
			__cplusplus
__lucid	__lucid	__lucid	__lucid
__sparc	__sparc	__sparc	__sparc
__sun	__sun	__sun	__sun
__unix	__unix	__unix	__unix
sparc		sparc	sparc
sun	sun	sun
unix		unix	unix

(∗) The symbol __STDC__ is defined as (decimal constant) 1 in the strict ANSI C mode, 2 in the extended ANSI C mode and 3 in the strict (ARM compatible) C++ mode. It is not defined in the cfront-2.1 compatible mode for the SunOS4.x compiler but, for compatibility with the Solaris system header files, it is defined with the value 0 in the Solaris version. Similarly, the symbol __cplusplus is defined as having the value 1 in the strict C++ mode and 2 in the cfront-2.1 compatible mode. Also, note that the dialect-specific symbol __STDC__, defined for the ANSI C modes, and __cplusplus, defined for the C++ mode, as well as the symbols __DATE__, __FILE__, __LINE__, and __TIME__ which are defined for all dialects, cannot be manipulated with the -U option.

(+) The symbol __LUCID_KR_PP__ is defined whenever K&R preprocessing is in effect and __LUCID_ANSI_PP__ is defined for ANSI C preprocessing. Note that the preprocessor can be optionally controlled with the -XAp and -XKp switches, separate from the language dialect. Refer to the description of -Xf and -XF options for the default preprocessing in the two C++ modes.

−v Verbose mode. Print out each top-level command that is executed by the compiler "driver" in invoking various compilation, assembly or link steps.

−Wc,arg1[,arg2...] Hand off the argument[s] argi to pass c where c is one of [p02alck] indicating the front-end/preprocessor, front-end, back-end, assembler, link editor, template "name map" (defaultmap) processor or template link simulator, respectively. For example: -Wa,-m passes -m to the assembler.

−w {a,c,d,g,p,q,u} Control warning diagnostics. -w may be followed by one or more letters to selectively turn on various classes of warnings. Specifically:

a       enables all warnings to be printed
c       indicates conformance warnings
d       indicates warnings for implicit "int" declarations
g       indicates warnings on potentially unguarded include files,
p       enables warnings for functions without prototype
q       warns about "quiet change" constructs
u       indicates ordinary (i.e. "questionable usage") warnings

If -w appears by itself with no following letters, then no warning messages will be printed. Conformance warnings are dialect-specific warnings that are issued for usages that do not conform to the selected dialect. For example, any text other than a comment following the #endif preprocessor directive on the same line is not permitted in ANSI C and will result in a compiler warning in -Xa or -XA modes. The quiet change warnings are issues for usages that, compared to K&R C have new semantics under ANSI C.

The default warning option is −wu for -Xa mode −wuc for all other modes.

−X− Do not supply the Lucid "include" directories for compilation or the Lucid libraries for linking. This is to permit the user to specify desired include search directories or libraries (i.e. -I, -L and -l options) without possible interference from those (implicitly) supplied by the compiler. The system C library (-lc) will continue to be linked in with the code, though, when there are any unresolved references to the library elements.

−X1 Stop compilation after the compiler front-end. This results in syntax and semantic checking of the source and generation of compiler intermediate files. No object or assembly code will be generated.

−XAIdir Indicates that the header files in dir and its subdirectories are written in ANSI C. The companion -XKI option performs a similar function for K&R based include directories. These are primarily for use in situations where the header files, developed independent from the application that include them, happen to belong to a different dialect. Note that a directory can be specified for processing in one dialect while some of its subdirectories can be specified with a different dialect. -XAI does not substitute for -I, it only affects the treatment of files that are included, not what directories are searched. In C dialects the compiler processes files subject to -XAI as ANSI C, but in C++ dialects it modifies its behavior only slightly. Specifically it ignores declarations involving function types without prototypes and treats all other top-level declarations as if they had an extern "C" linkage specification.

−XA Conform to the ANSI C language and run-time library definition. This is the recommended mode for "strictly" conforming applications that largely stay within the ANSI C specified run-time library in their interface to the system. In general, access to other library functions should be harmless. In some rare situations, however, link time problems (multiple definitions) or incorrect results at run time might occur due to duplication of internal data structures in the ANSI C specified functions and some of the system libraries.

−Xa Supports the ANSI C dialect but primarily relies on the system (UNIX) C run-time library. The library does not strictly conform to the ANSI C definition in a few minor aspects. It does, however, provide consistent access to the entire (system) run-time library, the bulk of which is beyond that defined for ANSI C. This is also referred to as the "extended ANSI C" dialect and is the compiler’s default mode. Header files included from the /usr/include directory will be processed in K&R mode unless overridden with the use of the -XAI switch.

−XAp Use ANSI C preprocessing for this compilation, instead of that implied by the language dialect in effect. This does not affect the preprocessing of those header files covered by -XKI option switch.

−Xarch=sparcv8 Customize the generated code for version 8 of the SPARC processor architecture (e.g. using the hardware integer multiply and divide instructions). This can help improve the running time of certain programs provided the resulting executables are only to run on SparcStation10-class systems. Programs compiled with this option would continue to work on the older, version 7, SPARC processors but they may run significantly slower there. The default for this option is to assume version 7 of the SPARC processor (Xarch=sparcv7).

−Xcorrect_mangling Use the "correct mangling" for type names such that the resulting mangling would correctly and uniquely identify the "type" from which it was derived. This can potentially result in link-time incompatibility with cfront compiled object files and libraries but is needed for successful build of some programs as well as for proper display of types of objects under the Energize browser. This is the default name mangling used in the ARM compatible C++ mode (-XF).

−Xcfront2.1_mangling Use cfront-compatible mangling of type names even in those cases that the resulting name does not correctly describe the actual type denoted by the mangled name. This is to be link-compatible with cfront-2.1 object files and is the default under the cfront-compatible C++ mode (-Xf).

The distinction mainly occurs when cfront 2.1 compiles a class declaration which defines a local typedef, enum, or class name, and there is no existing global definition of the same name. For example:

    struct OUTER
    {
        enum TD { a, b};
        void gus( TD);
    };

cfront 2.1 will mangle the name of ’gus’ into

     _gus__5OUTERF2TD
whereas the correct mangling produced by lcc and cfront 3.0 is

     _gus__5OUTERFQ2_5OUTER2TD
The ’Q2_5OUTER’ that is missing from the cfront 2.1 mangled name identifies TD as being local to class OUTER. Thus, the cfront 2.1 name identifies TD as a global name instead of a local name.

−Xez Connect the compiler to the Energize server. For information regarding Energize, refer to the User’s Guide for the Energize Programming System.

−Xd Issue a warning message if a default (implicit) "int" type is used in the program. This is useful in converting old programs to bring them to the ANSI C level.

−Xdouble_args For functions with prototype, promote and pass float type parameters as double values (instead of passing them as "float"). C++, and, ANSI C in the presence of prototype, permit a more efficient implementation by passing these parameters unpromoted, as "floats". But given that cfront normally relies on K&R C compiler as its base, to be compatible with cfront compiled libraries and object code, this is also the default "float" passing protocol used in C++ modes. As this is not the default for the ANSI C modes, use of this flag may be necessary in compiling C files that are to be linked into C++ programs.

Furthermore, as this option results in a different parameter passing protocol for a function with float parameters, compared to a similar compilation that uses -Xfloat_args option, In C++ modes (and consistent with cfront), the letter "f" is used to denote float valued parameters in the mangled function name, instead of "D" used for the same type arguments when -Xfloat_args option is used.

−Xfloat_args: For functions with prototype, pass float type parameters as specified, instead of promoting them to double. This is a more efficient implementation for passing such arguments but the resulting calling protocol is not compatible with K&R compiled code nor with the C++ modes (-Xf, -XF). This is the default parameter passing protocol in ANSI C modes.

In C++ modes, the name of the functions with such parameters are accurately mangled to reflect this point but in C modes the user should be aware of the potential incompatibility, as no link-time errors would occur.
When this option is used explicitly in C++ modes (-Xf, -XF), in mangling the name of functions with "float" parameters, the letter "D" is used to denote float valued parameters. With the alternate option, -Xfloat_args, "f" is used to denote the same type parameter in order to construct a cfront-compatible mangled name for the same function.

As the -Xdouble_args is the default parameter passing mechanism (for cfront-compatibility), the -Xfloat_args option is mainly to provide an override mechanism for the C++ default behavior.

−XE Output the incorrect source line as part of error messages. This is the default error reporting format.

−Xe Do not output the source line in error messages.

−XEL=nn Change the error limit to (the decimal value) nn. Error limit is the number of errors that the compiler will report for a source file before it quits compiling that file. By default the compiler reports 20 errors per file. This limit can also be changed at compiler installation time.

−XF Run the full feature (C++) compiler. This dialect enforces the rules of E&S (Annotated C++ Reference Manual). It does not accept anachronisms and ANSI C preprocessing is in effect.

−Xf Run the full feature (C++) compiler. This dialect conforms to AT&T cfront 2.1 release. It also accepts anachronisms and some code that is illegal according to the reference manual but is accepted by cfront 2.1. For compatibility with cfront2.1 which generally relies on the UNIX (K&R) preprocessor, this mode also sets the compiler’s preprocessor to K&R in the SunOS version of lcc. In the Solaris version, ANSI C preprocessing is the default.

−XH[v][=dir] Create/use precompiled headers. dir names the precompiled header repository directory which will be searched for precompiled headers and in which new precompiled headers will be stored. If =dir is not specified, the value of the environment variable LCC_HREPOSITORY is used. If this variable is not defined, then ./lcc_hrepository is used.

This option is currently ignored if the -i option is not also specified. The optional "v" specifies verbose mode which causes notes about precompiled header usage/creation to be written to stderr.

−XIdir For the (header) files included from the dir directory and its subdirectories, cancel the effect of any enclosing (covering) -XKI or -XAI switch, effectively reverting to the language dialect in effect outside any include files. This is to enable the compiler to use the correct language dialect in compiling C++ or ANSI C header files installed in subdirectories under directories that may otherwise contain K&R style header files (e.g. /usr/include) and for which a -XKI option is specified.

−Xi Turn C++ function inlining off. This option is superseded by the −Oi- flag and will be eliminated in the future releases of the compiler.

−XKIdir This is similar to the -XAI option but indicates that the header files are written in K&R C.

−Xk Enforce the K&R C language definition, flagging non K&R constructs with warning messages. Header files included from directories given with -XAI will be processed in the ANSI C mode. The -Xk option is recommended for use with older, pre-ANSI C programs to avoid undue aggravation. (The K&R C definition is primarily determined by the behavior of the pcc, the Portable C Compiler rather than Kernighan and Ritchie’s text.)

−XKp Use K&R style preprocessing for this compilation, instead of that implied by the language dialect in effect. This does not affect the preprocessing of those header files covered by a -XAI option switch.

−Xl

−Xli Sends a source listing file to standard output. If "i" is present, the preprocessor include files are also listed.

−XL

−XLi Similar to -Xl and -Xli, but the listing is left in a ".lst" file. Diagnostics will still appear on standard error as well as in the listing file.

−Xn Permit nesting of comments.

−Xquiet Issue warnings for language usages that fall under the "quiet" change category of the ANSI C vs K&R C dialects. These are constructs that are legal in both K&R C and ANSI C but which are interpreted differently in each dialect. For example, the character constant ’\a’ is interpreted as the "alert" (BEL) character (ASCII 0x07) under ANSI C but is assumed to be identical to ’a’ (ASCII 0x41) in K&R mode. This option is superseded by the -wq form .

−Xr Relax some of the C++ type checking rules. Some existing programs that have been compiled with cfront 2.0 or 2.1 may require this option to be accepted by lcc.

−Xs Truncate all symbols to 8 characters and issue error messages for name collisions due to this truncation. This is valid only with the -Xk (K&R C) switch.

−Xsearch_cwd Modifies the rules used in searching for #include files. In cases where the ordinary rules would look in the directory of the including file, the modified rule looks instead in the current working directory (where the compiler started).

−Xtemp=prefix Use prefix as the prefix for the names of intermediate files. If this parameter is not specified, a prefix of /tmp/ptmpid is used where pid is the current process id.

−Xt Print the time (elapsed, user, system) spent in each compilation phase.

−Xu Invoke the native UNIX C compiler, passing along all arguments except the -Xu option.

−Xv Print the compiler’s version and serial number.

−Xwpat Suppress compiler front-end warning messages that contain a string matching the specified pat where pat can be any grep(1) style "regular expression". The option -Xwanachronism, for example, will suppress all warning messages containing the string "anachronism". If any warnings are actually suppressed due to this flag, the end of compilation message will report the count of suppressed messages.

This option is not applied to the template instantiation processes pacctcomp or pacctlink.

−XWpat The same as −Xwpat except that suppressed warnings are not counted in the summary of errors and warnings that lcc prints at the end of compiles.

−Xx Suppress inline expansion of certain (intrinsic) library functions. In the absence of this flag, such functions are always expanded inline.

−Xz Causes storage for file-scope variables defined with no explicit storage class specifier (e.g. "int i;" outside any function body) to be allocated as "common". This permits multiple definitions with no explicit storage class specifier to coexist. Although both ANSI and K&R explicitly prohibit doing this, UNIX compilers have traditionally permitted it and many existing programs unknowingly depend upon it. This also applies to C++ programs in which none of the declarations of an object of a class with static members are supplied with an initializer for the object.

To accommodate the existing practice, the -Xz switch is implicitly supplied for all dialects except for the strict ANSI C mode.

−Y [p02alhSILU],dirname Specify a new path name, dirname, for the locations of the tools and directories designated in the first argument. [p02alhSILU],dirname represents:

p       front-end (including the preprocessor)
0       front-end
2       back-end
a       assembler
l       link editor
h       C++ mode patch program (SunOS 4.x only)
S       directory containing the start-up routines
I       default library directory searched by ld
U       second default library directory searched by ld

If the location of a tool is being specified, then the new path name for the tool will be dirname/tool. If more than one -Y option is applied to any one tool or directory, then the last occurrence holds. Note that "p" and "0" select the same component, namely the location of the combined front-end and preprocessor.

−fe file-name Use file-name as the compiler front-end instead of the normal front-end.

−be file-name Use file-name as the compiler back-end instead of the normal back-end.

−as file-name Use file-name as the assembler instead of the normal assembler.

−Xld file-name Use file-name as the linker instead of the normal linker.

The following options are for use with the C++ template-instantiation subsystem available only in the 3.0 version of the compiler. The template instantiation system can be disabled with the -Xpt- option.

−ptv Selects verbose mode for the instantiation system programs ltcomp and ltlink. In verbose mode, ltcomp and ltlink will display messages for each instantiation step, including at least the the elapsed time for each instantiation step. Note: The -v option will also cause ltcomp and ltlink to produce verbose output (in addition to all the other verbose output of the -v option).

−pta Force all symbols of a template class, even those unreferenced, to be instantiated for each template class instantiation.

−ptn The default for compiling and linking a single (application) file named on the command line in one step is to do the template instantiation immediately in the object file. With only one object, there is no danger of multiple definitions, so this direct approach saves time. The "-ptn" option, when used with such a one file program, inhibits the default immediate template instantiations in order to force the "directed" instantiation system (ltlink) to resolve template references.

−pts The default grouping for template classes is just one object file to contain all instantiations for that class. The "-pts" option forces the directed instantiation system to group template class instantiations more finely. One object file is created for each overloaded function set. Also a single object file is created containing all virtual functions and all static class data.

−ptrrepository Specify a repository named repository for use by the instantiation system. The default repository name is "./lcc_trepository".

Specifying multiple repositories (with multiple -ptr’s) will currently result in only the last repository specified being used, with no warning that the others are being ignored.

−ptt This option is accepted silently but not supported. Dependency management follows the scheme outlined by Glenn McClusky and Robert B. Murray as given in ACM SIGPLAN Notices, Volume 27, Number 12, December 12, 1992

−Xpt- Disable automatic template instantiation; the processes pacctcomp and pacctlink will not be run.

−Xpt Enable the automatic template instantiation subsystem. Unless otherwise specified. the "narrow" instantiation mode (-Xptn) is used by the instantiator.

−Xpte:decl_file_ext:def_file_ext Specify alternate file name suffixes for template declaration and template definition files. By default, definition for a template referenced in a .h or .H template declaration file is looked up in the corresponding .C and, if not there, in a .c file. If the declaration file has a .hxx suffix, then the matching .cxx definition file is looked up. Conversely, declarations for templates defined in .C or .c files are looked up in the corresponding .h, and if not there, a .H file ( in that order). Similarly, .cxx definition files are mapped to .hxx declaration files.

The -Xpte option can be used to change the default declaration/definition file association. For example, the -Xpte:hxx:C option, will cause the instantiator to look for the declarations in .hxx and the corresponding definitions in .C files. If -Xpte is used, all unknown template declaration files will be assumed to have the extension specified by the decl_file_ext and all unknown template definition files will be assumed to have the def_file_ext extension.

−Xptf Use advisory file locking, instead of NFS advisory locks, to lock the template repository. Repository locking is transparent to the user but is necessary to insure the integrity of the repository when multiple compiles are in progress. NFS advisory locks provide network-wide locking but under the SunOS 4.x system, unless you have installed the SunOS patch # 100075-08, and, in some limited cases, compilations may hang if this kind of locking is used. File locking (flock(2)) is effective only for one (local) system but does not suffer the the above drawback. Use this option only if you experience "rpc error" during your compiles.

−Xpti:nn This option is passed directly to the template instantiator and sets the limit on the number of instantiation-iteration. The default iteration limit is 64 and corresponds to the -Xpti:64 option.

−Xptk Instructs tlink to complete the round of instantiation compiles (i.e. up until the next link simulation) upon an instantiation compile failure.

−Xptm Use the nm(1) utility to construct the "unresolved" name list during the template instantiation phase. The default is to use the instantiator’s own object file scanner which is more efficient. Due to differences in the object file format, -Xptm is the default (and the only supported mode) in the Solaris compiler.

−Xptn Default to "narrow" instantiation; the instantiator is run if any of the files being compiled contain templates. This is the compiler default with respect to template instantiation.

−Xptw Use the "wide" instantiation model; the instantiator would run if a repository (default or user specified) is available, or if any of the files being compiled contain templates.

FILES

The following file types are either input files or are intermediate files whose names are derived from input files by deleting the prefix directories and changing the suffix. The directories LucidInclude and LucidLib are configuration specific directories that are determined at the compiler installation time.

file.s Assembler source code file

file.c C source code file

file.i Preprocessor output C source code file

file.lst Compiler generated listing file

file.n Compiler intermediate file output by the compiler front-end

file.o Object module (assembler output, linker input)

a.out (absolute) result file produced when the -o option is not used.

./lcc_hrepository/ Default directory created automatically for pre-compiled header files, as needed.

./lcc_trepository/ Default directory created automatically for template instantiation files, when needed.

OTHER FILES

/usr/include standard directory containing system header files.

LucidInclude standard directory for ‘#include <...>’ files in the ANSI C modes (the exact name of this directory is determined at the compiler installation time). /usr/include will still be searched after other implicit "include" directories.

LucidInclude/c++incl standard directory for ‘#include <...>’ files in C++ mode (the exact name of this directory is determined at the compiler installation time). This is the first implicit header file directory preceding LucidInclude which contains the ANSI C header files.

LucidInclude/solaris the base directory for a few headers included by ‘#include <...>’ directive in the Solaris version of the compiler. These files substitute for the missing, or complement the deficient headers under /usr/include on Solaris systems.

LucidLib standard directory for liblucid.a, ANSI-C run-time library, liblucidx.a, extended ANSI C library, libiostream.a, C++ iostream library, libcomplex.a, C++ complex arithmetic library, libtask.a, C++ "task" library, and libcplus.a, C++ run-time startup code linked in for every C++ program (the exact name of this directory is determined at the compiler installation time). The compiler driver does not (implicitly) include the complex or task library in C++ links, as it does with the other C++ libraries. Explicit -l options are needed to link with these libraries.

DIAGNOSTICS

In some cases, an erroneous statement may cause additional errors to be reported on subsequent statements where none exists. Compilation is terminated if a preset number of errors (currently 20) are reported. By default, the compiler’s error messages and warnings are somewhat verbose; use -Xe for terse messages. The compilation unit containing main() for a program that contains any C++ modules must also be compiled in C++ mode. Furthermore C++ programs must be linked using the compiler driver, lcc. Otherwise, unless all the internal steps are explicitly performed, direct use of the linker, ld, cannot produce correctly running executables.

BUGS

If compilation and link steps are performed separately, the same dialect selection option should be in effect. Otherwise wrong/incompatible libraries may be used during the link step. In particular, when invoked only on .o, .s and .a files with no explicit dialect selection option, the extended ANSI C library will be used for linking. The -Xf (or -XF) option must be used explicitly when linking .o files that are the result of a previous C++ compilation.

OTHER FEATURES

In developing new C++ code, the -XF switch is the recommended option but, by default, the cfront2.1 compatible dialect (-Xf) is invoked on files with C++ suffix. For most ANSI C applications, unless strict compliance with the ANSI C run-time library definition is necessary, extended ANSI C is the recommended dialect. The strict mode may run into conflict with the non-ANSI C based system libraries, if the application refers to incompatible (non-ANSI C) UNIX library functions. Refer to the description of -XA, -Xa and -Xk options for the differences between these dialects. Also, the -wq option can be used to help in migrating from K&R C to ANSI C.

Lucid C/C++ Rev. 3.0 — Last change: 8/15/93

Museum

Related Articles