NAME

cc − C compiler

SYNOPSIS

cc [ option ] ... file ... 

DESCRIPTION

Cc is the C compiler.  Cc accepts several types of arguments:

oArguments whose names end with .c or .i are taken to be C source programs; they are compiled, and each object program is left on the file whose name is that of the source with .o substituted for .c. The .o file is normally deleted, however, if a single C program is compiled and loaded all at one go. 

oArguments whose names end with .s are taken to be assembly source programs and are assembled, producing a .o file. 

oArguments whose names end with .o are assumed to be already compiled and are passed to ld without change. 

The order of arguments on the command line is significant − the arguments to the corresponding call to ld are in the same order, and ld is very order sensitive.  See ld(1).

OPTIONS

The following options are interpreted by cc. See ld(1) for load-time options.

−c Suppress the loading phase of the compilation, and force an object file to be produced even if only one program is compiled. 

−g Have the compiler produce additional symbol table information for dbx(1). Some optimisations are turned off by this option.

−w Suppress warning diagnostics. 

−p Arrange for the compiler to produce code which counts the number of times each routine is called.  If loading takes place, replace the standard startup routine by one which automatically calls monitor(3) at the start and arranges to write out a mon.out file at normal termination of execution of the object program.  An execution profile can then be generated by use of prof(1). The option causes the program to be linked with /usr/lib/mcrt0.o and the profiling version of the C library, /usr/lib/libc_p.a.

−pg Causes the compiler to produce counting code in the manner of −p, but invokes a run-time recording mechanism that keeps more extensive statistics and produces a gmon.out file at normal termination.  Again, a profiling library is searched, in lieu of the standard C library.  An execution profile can then be generated by  use of gprof(1).  The output is linked with the special startup file /usr/lib/gcrt0.o and the profiling library. 

−O Allows the compiler to perform additional optimisations.  Usually all optimisations are enabled anyway, except when compiling with the −g option. 

−R Make string-literals read-only (and, hence, sharable). 

−S Compile the named C programs, and leave the assembly-language output on corresponding files suffixed .s.

−M Run only the macro preprocessor on the named C programs, requesting it to generate Makefile dependencies and send the result to the standard output. 

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

−C prevent the macro preprocessor from eliding comments. 

−o output
Name the final output file output. If this option is not used the output of a load step will be produced in the file a.out. If used in conjunction with the −c option, −o name renames the generated object file. 

−Dname=def

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

−Uname
Remove any initial definition of name.

−Idir #include files whose names do not begin with ‘/’ are always sought first in the directory of the file argument, then in directories named in −I options, then in directories on a standard list.  If no dir argument is supplied the argument following −I is used. 

−jdir,dir,... 
Replace the standard list for −I by dir,....  If no list is provided the argument following −j is used.  To disable the standard list (to remove all entries from it) use −j followed by an empty argument. 

−e epsym
This option is passed to ld(1).

−Ldir Library archives are sought first in directories named in −L options, then in directories on a standard list.  This option is simply passed to ld(1).

−r This option is passed to ld(1).

−s This option is passed to ld(1).

−u symname
This option is passed to ld(1).

−llibrary
The option is passed through to ld(1). It causes ld to load the library whose name is liblibrary.a from the library load path. 

−b,−B

−f,−F

−k,−K

−x,−X

−zChars,−ZChars
Are all reserved to Acorn. Future compilers may interpret, or ignore these flags or may pass them on to ld. Unadorned −z is passed directly to ld (1). 

In addition to flag letters, the following keywords are recognised:

−help
Output a summary manual entry for cc. 

−list Generate a line-numbered compiler listing in a file with extension .lst.

−ansi Compile C to December 1989 ANSI Specification. 

−strict
Used in conjunction with −ansi.  It sets up neither X/Open nor BSD environments and guarantees only ANSI C and access to the ANSI library functions. 

Other arguments are taken to be either loader option arguments, or C-compatible object programs, typically produced by an earlier cc run, or perhaps libraries of C-compatible routines.  These programs, together with the results of any compilations specified, are loaded (in the order given) to produce an executable program with default name a.out. 

FILES

file.cinput file
file.oobject file
a.outloaded output
/usr/bin/cccompiler front-end (X/Open)
/usr/ucb/cccompiler front-end (BSD)
/usr/lib/cccompiler
/usr/lib/crt0.oruntime startoff
/usr/lib/mcrt0.ostartoff for profiling
/usr/lib/gcrt0.ostartoff for gprof-profiling
/usr/lib/libc.astandard library, see intro(3)
/usr/lib/libc_p.aprofiling library, see intro(3)
/usr/includestandard directory for #include files
mon.outfile produced for analysis by prof(1)
gmon.outfile produced for analysis by gprof(1)

SEE ALSO

B. W. Kernighan and D. M. Ritchie, The C Programming Language, Prentice-Hall, 1978
B. W. Kernighan, Programming in C-a tutorial
D. M. Ritchie, C Reference Manual
monitor(3), prof(1), gprof(1), adb(1), ld(1), dbx(1), as(1), aupcs(7), afp(7)

DIAGNOSTICS

The diagnostics produced by C itself are intended to be self-explanatory.  Occasional messages may be produced by the assembler or loader.  By default cc links with the shared library version of libc, /lib/libc.a. This can lead to symbol clashes which would not occur in a non-shared environment.  It is possible to link with the non-shared version of the library /lib/libc_n.a using ld but it is better to remove the symbol clashes from the program in question. 

DIFFERENCES BETWEEN ACORN CC AND BSD CC

−go is not supported (no support for sdb). 

−R makes string and floating point literals read-only and sharable, rather than making all initialised variables read-only and sharable (by putting them in the text segment). 

−f is not supported: float expressions are always converted to double (but register float variables work anyway). 

−B −t
are not supported: there are no separate compiler passes, and there are no substitutes.

PREPROCESSOR DIFFERENCES

oWhitespace and line breaks are treated differently. This principally affects cc −E and cpp: their output may have line breaks in different places and may be differently spaced. The outputs of RISC iX’s cc −E and cpp commands cannot be compared directly with those of the 4.3BSD UNIX’s cc −E and cpp commands. 

oThe white-space control characters vertical-tab (VT), form-feed (FF), and carriage-return (CR) (ASCII codes 11, 12, and 13) are silently converted to newline (NL).  Literal VT, FF, and CR should not be used in character and string literals. 

oThe ANSI #elif construct is permitted. 

oThe ANSI #error construct is permitted. 

oThe ANSI #pragma construct is permitted. 

oThe ANSI #if defined ...  construct is permitted. 

oThe following ANSI pre-defined macros can be used (and can be re-defined): __DATE__, __FILE__, __LINE__, and __TIME__; __arm and __unix are defined (and can be re-defined); __STDC__ is defined by cc −ansi; one of _BSD_C and _XOPEN_C will be defined unless cc −ansi −strict is used (depending on how the compiler is invoked). 

LEXICAL AND SYNTACTIC DIFFERENCES

oThe archaic =+ is not accepted in place of +=; similarly =-, =∗, etc. 

oThe keywords asm, entry and fortran are faulted. 

oThe ANSI modifiers f (or F) and u (or U) can be used in conjunction with l (or L) to denote floating, unsigned, and long values, respectively. For example: 2lf (double 2.0); 3u (unsigned 3); 4l (long 4). 

oThe ANSI implicit concatenation of adjacent string segments is permitted.  Thus "Hello" "World" is treated as "HelloWorld". 

oThe ANSI escape sequences \a and \xnn can be used within strings and character constants to denote the ASCII BEL character and a hexadecimal character code, respectively. As \a and \x are meaningless in pcc-style C, existing usage can only be accidental. 

oANSI function prototypes may be used. These give precise information about a function’s arguments and result type.  Such prototypes may include use of the ANSI “...” to denote a variable number of arguments following. For example:

extern int funct(int a, float b, ... );

oUse of the ANSI generic pointer type void ∗ is permitted. 

SEMANTIC, SCOPE, AND OTHER DIFFERENCES

An identifier declared with storage class extern has normal scope. If such an identifier is not declared at the outermost level then it does not have file scope. 

A function’s formal arguments are considered to be defined at the head of the outermost block of the function. Thus, they may not be redefined within this block. 

A struct or union field name may only be used to select a component from an expression of the appropriate type. The archaic and abominable:

struct {int a, b;};
double d;
d.b = 0;
...

is faulted. 

New type names defined using typedef may not have modifiers applied to them. Thus code such as:

typedef int t1;
unsigned t1 a;

is faulted. 

The type of a variable may not be multiply defined or redefined. Thus, code such as:

long x[3];
int x[3];

is faulted. 

The braces around a struct or array initialiser may not be partly omitted.  For example, consider:

typedef struct {
struct {
int a,b;
} c[3];
} T;

The following initialisers are accepted:

static T v1 = {1,2,3,4,5,6};
static T v2 = {{{1,2}, {3,4}, {5,6}}};

However, the initialiser:

static T v3 = {{1,2}, {3,4}, {5,6}};

is faulted. 

As in  ANSI C, union types may be initialised. The initialisation applies to the first arm of the union. 

As in  ANSI C, the extended precision floating-point type long double is available. 

BUGS

In −ansi −strict mode, empty initialisers are not faulted. For example:

int x[3] = {} ; /∗ un-caught constraint violation ∗/

Signed constant integer overflow is also not faulted. For example:

case LONG_MAX ∗4 : /∗ un-caught constraint violation ∗/

A cast to a pointer to volatile T loses the volatile qualifier. For example:

y = ∗ (( volatile int ∗)x) ;
y = ∗ (( volatile int ∗)x) ; /∗ CSE’d with above, not treated as volatile ∗/

RISC iX  —  Revision 1.12 of 26/11/90