Arguments whose names end with `.c' (plus `.C' under Windows) are taken to be C source programs; they are preprocessed, compiled, and each object program is left on the file whose name is that of the source with `.o' (UNIX) or `.obj' (Windows) substituted for the extension. Arguments whose names end with `.i' are treated similarly, except they are not preprocessed. In the same way, arguments ending with `.s' (plus `.S', `.asm', and `.ASM', under Windows) are taken to be assembly source programs and are assembled, producing an object file. If there are no arguments, lcc summarizes its options on the standard error.
lcc deletes an object file if and only if exactly one source file is mentioned and no other file (source, object, library) or -l option is mentioned.
If the environment variable LCCINPUTS is set, lcc assumes it gives a semicolon- or colon-separated list of directories in which to look for source and object files whose names do not begin with `/'. These directories are also added to the list of directories searched for libraries. If LCCINPUTS is defined, it must contain `.' in order for the current directory to be searched for input files.
lcc uses ANSI/ISO Standard header files (see `FILES' below). Include files not found in the ANSI/ISO header files are taken from the normal default include areas, which usually includes /usr/include. Under Windows, if the environment variable INCLUDE is defined, it gives a semicolon-separated list of directories in which to search for header files.
GNU/POSIX style --option syntax is recognized as equivalent to -option.
This option may be abbreviated to any unique prefix at least as long as -co.
A second -A warns about unrecognized control lines, nonANSI/ISO language extensions and source characters in literals, unreferenced variables and static functions, declaring arrays of incomplete types, and exceeding some ANSI/ISO environmental limits, such as more than 257 cases in switches. It also arranges for duplicate global definitions in separately compiled files to cause loader errors.
If -M is given at least once, generate a list of dependencies on quoted header files (#include "myfile.h"), and write them on the standard output unit.
If -M is given more than once, the output also includes dependencies on angle-bracketed header files (#include <sysfile.h>).
This option is deprecated, and may disappear in a future release, since its job can be done by the -Wo,-rcc=path-to-alternate-rcc option, one of four that permit changing any of the compiler's internally-invoked components.
On Sun Solaris systems only, -Bstatic and -Bdynamic are recognized and passed to the loader; see ld(1). They are provided only for compatibility with native compilers; the lcc-standard options -dynamic or -static should normally be used in their place.
POSIX uses a comma in the fourth character; its use with lcc is optional. Documentation of other -W options here includes that comma.
lcc assigns the most frequently-referenced scalar parameters and locals to registers whenever possible. For each block, explicit register declarations are obeyed first; remaining registers are assigned to automatic locals if they are `referenced' at least 3 times. Each top-level occurrence of an identifier counts as 1 reference. Occurrences in a loop, either of the then/else arms of an if statement, or a case in a switch statement each count, respectively, as 10, 1/2, or 1/10 references. These values are adjusted accordingly for nested control structures.
alpha/linux Compaq/DEC Alpha, GNU/Linux alpha/osf Compaq/DEC Alpha, OSF/1 3.2, 4.x mips/irix big-endian MIPS Rx000, IRIX 5.2, 6.x mips/linux big-endian MIPS Rx000, GNU/Linux mips/ultrix little-endian MIPS Rx000, ULTRIX 4.3 null no output sparc/linux Sun SPARC, GNU/Linux sparc/solaris Sun SPARC, Solaris 2.x sparc/sun Sun SPARC, SunOS 4.x symbolic text rendition of the generated code symbolic/osf text rendition of the generated code for Compaq/DEC OSF/1 symbolic/irix text rendition of the generated code for SGI IRIX x86/freebsd Intel x86, FreeBSD x86/linux Intel x86, GNU/Linux x86/solaris Intel x86, Sun Solaris 2.x x86/win32 Intel x86, Windows NT 4.0/Windows 95/98/2000
Additional combinations that may be supported in the future, if code-generation support is completed, include
ia64/freebsd HP/Intel IA-64, FreeBSD ia64/linux HP/Intel IA-64, GNU/Linux ia64/win32 HP/Intel IA-64, Windows NT 4.0/Windows 95/98/2000 ia64/win64 HP/Intel IA-64, Windows-64 parisc/hpux HP PA-RISC, HP-UX 10.x, 11.x parisc/linux HP PA-RISC, GNU/Linux ppc/aix PowerPC, IBM AIX 4.x ppc/linux PowerPC, GNU/Linux ppc/macosx PowerPC, Mac OS X (Darwin, Rhapsody)
lcc can be built even on platforms for which no code generator is yet available. In this case, you can use it for fast syntax checking, e.g., with -Wf,-target=null -S, and for cross assembly. You can also use it to link existing object files produced by another C compiler.
For user convenience, when a -Wf,-target=xxx option requests nonnative code generation, assembly and linking are automatically suppressed, as if an explicit -S option had been given. With -Wf,-target=null, no .s file is produced at all.
By default, char is signed on all platforms on which lcc runs. Note that this may differ from the choice made by other C compilers on the same platform.
You can test at runtime for the signedness of char: the expression (char)(-1) will be negative if char is signed, and positive if it is signed.
An alternate test, using the sign of the value of SCHAR_MIN from <limits.h>, is known to fail with other compilers on a few platforms because of implementation errors. lcc handles that test correctly.
Since preprocessor symbol values in <limits.h>, and possibly typedefs as well, may depend on the signedness of char, care should be taken to ensure that the same value of this option is used if preprocessing is done separately from compilation.
By default, for lcc, wide characters are unsigned short int, and wchar_t is a typedef defined in <stddef.h>. The definition for wchar_t in <stddef.h> changes according to the setting of this option. For that reason, care should be taken to ensure that the same value of this option is used if preprocessing is done separately from compilation.
The default for both IRIX 5.x and 6.x is -o32.
lcc support for the -n32 model is incomplete, so although the option is recognized, and accepted, the resulting code is likely to fail at assembly or link time.
lcc does not yet have 64-bit code-generation support, so although -Wo,-64 is recognized, it raises an error.
For further description of these memory models, see cc(1).
The assembler can also be defined by setting the LCCAS environment variable, but any such value is overridden by an explicit command-line -Wo,-as=xxx option.
On many systems, the C preprocessor is not expected to be invoked directly by users, so it is not in the default PATH. Consequently, this option normally requires the full path to the C preprocessor.
The default lcc preprocessor strictly conforms to the ANSI/ISO C89 Standard, but some platforms have preprocessor language extensions in system header files, preventing their use by Standard-conformant preprocessors. The proper way to handle this is to write lcc-specific versions of those header files for installation in lcc's own include directory. However, until that can be done, during installation and bootstrapping on a new system with extended header files, this option provides a way to use an extended preprocessor. Once lcc has been properly installed, ordinary user programs should never require this option.
The preprocessor can also be defined by setting the LCCCPP environment variable, but any such value is overridden by an explicit command-line -Wo,-cpp=xxx option.
The preprocessor can also be defined by setting the LCCLD environment variable, but any such value is overridden by an explicit command-line -Wo,-ld=xxx option.
Because ld(1) implementations vary so widely in their command-line options, and because lcc has a long built-in list of options to pass to the loader, it is unlikely that this option will work, unless you choose a loader implementation that is command-line compatible with the default one, which you can determine by examining the output from the -v option.
The component can also be defined by setting the LCCRCC environment variable, but any such value is overridden by an explicit command-line -Wo,-rcc=xxx option.
This option may be abbreviated to any unique prefix at least as long as -ve.
Plain int bit fields are signed. Bit fields are aligned like unsigned integers but are otherwise laid out as by most Standard C compilers. Some compilers, such as the GNU C compiler, may choose other, incompatible layouts.
Likewise, calling conventions are intended to be compatible with the host C compiler, except possibly for passing and returning structures. Specifically, lcc passes and returns structures like host ANSI/ISO C compilers on most targets, but some older host C compilers use different conventions. Consequently, calls to/from such functions compiled with older C compilers may not work. Calling a function that returns a structure without declaring it as such violates the ANSI/ISO Standard and may cause a fault.
Under Microsoft Windows only, lcc recognizes two additional variables:
- LCCAS
- Path to alternate assembler. This can be overridden by an explicit command-line -Wo,-as=xxx option.
- LCCCPP
- Path to an alternate C preprocessor. This can be overridden by an explicit command-line -Wo,-cpp=xxx option.
- LCCDIR
- Alternate directory tree in which to find the preprocessor, compiler, and include directory. To see the default directory tree, run lcc with the -v option: cpp(1) and rcc(1) will share a common path that is the default.
LCCDIR is used before LCCAS, LCCCPP, LCCLD, and LCCRCC, so that they can override it.
- LCCINPUTS
- Directory search path, separated by colons or semicolons, in which to look for source and object files whose names do not begin with `/'. These directories are also added to the list of directories searched for libraries.
- LCCLD
- Path to an alternate loader. This can be overridden by an explicit command-line -Wo,-ld=xxx option.
- LCCRCC
- Path to an alternate lexer, parser, and code generator. This can be overridden by an explicit command-line -Wo,-rcc=xxx option.
- TEMP
- Directory in which temporary files should be written. If specified, this variable overrides the settings of any TMPDIR variable, but is itself overridden by TMP.
- TMP
- Directory in which temporary files should be written. If specified, this variable overrides the settings of any TEMP or TMPDIR variables.
- TMPDIR
- Directory in which temporary files should be written. This variable is overridden by both TMP and TEMP.
- INCLUDE
- Semicolon-separated list of directories in which to search for header files.
- LIB
- Semicolon-separated list of libraries to search.
file.{c,C} input file file.{s,asm} assembly-language file file.{o,obj} object file a.{out,exe} loaded output /tmp/lcc* temporary files $LCCDIR/cpp preprocessor $LCCDIR/rcc compiler (lexer, parser, and code generator) $LCCDIR/liblcc.{a,lib} lcc-specific library /lib/crt0.o runtime startup (UNIX) /lib/[gm]crt0.o startups for profiling (UNIX) /lib/libc.a standard library (UNIX) $LCCDIR/include ANSI/ISO Standard headers /usr/local/include local headers /usr/include traditional headers prof.out file produced for bprint(1) mon.out file produced for prof(1) gmon.out file produced for gprof(1)
lcc predefines the macro __LCC__ on all systems. It may also predefine some installation-dependent symbols; option -v exposes them. For a nice sorted list, try
csh/tcsh: lcc -v -v -E foo.c |& tr ' ' '\n' | grep -e - | sort sh/ksh/bash: lcc -v -v -E foo.c 2>&1 | tr ' ' '\n' | grep -e - | sort
C. W. Fraser and D. R. Hanson, A Addison-Wesley, 1995. ISBN 0-8053-1670-1.
The World-Wide Web page at http://www.cs.princeton.edu/software/lcc/.
S. P. Harbison and G. L. Steele, Jr., C: A Reference Manual, 4th ed., Prentice-Hall, 1995.
B. W. Kernighan and D. M. Ritchie, The C Programming Language, 2nd ed., Prentice-Hall, 1988.
American National Standards Inst., American National Standard for Information Systems---Programming Language---C, ANSI X3.159-1989, New York, 1990.
International Organization for Standardization, ISO/IEC 9899:1990: Programming languages --- C, Geneva, Switzerland, 1990.
The ANSI/ISO Standard headers conform to the specifications in the Standard, which may be too restrictive for some applications, but necessary for portability. Functions given in the ANSI headers may be missing from some local C libraries (e.g., wide-character functions) or may not correspond exactly to the local versions; for example, the ANSI/ISO Standard <stdio.h> specifies that printf, fprintf, and sprintf return the number of characters written to the file or array, but some existing libraries don't implement this convention.
On the MIPS and SPARC, old-style variadic functions must use <varargs.h> from MIPS or Sun. New-style is recommended.
With -b, files compiled without -b may cause bprint to print erroneous call graphs. For example, if f calls g calls h and f and h are compiled with -b, but g is not, bprint(1) will report that f called h. The total number of calls is correct, however.