|
|
1.1 root 1:
2:
3: File: internals, Node: Top, Next: Copying, Up: (DIR)
4:
5: Introduction
6: ************
7:
8: This manual documents how to run, install and port the GNU C compiler, as
9: well as its new features and incompatibilities, and how to report bugs.
10:
11: * Menu:
12:
13: * Copying:: GNU CC General Public License says
14: how you can copy and share GNU CC.
15: * Contributors:: People who have contributed to GNU CC.
16: * Options:: Command options supported by `gcc'.
17: * Installation:: How to configure, compile and install GNU CC.
18: * Trouble:: If you have trouble installing GNU CC.
19: * Incompatibilities:: Incompatibilities of GNU CC.
20: * Extensions:: GNU extensions to the C language.
21: * Bugs:: How to report bugs (if you want to get them fixed).
22: * Portability:: Goals of GNU CC's portability features.
23: * Interface:: Function-call interface of GNU CC output.
24: * Passes:: Order of passes, what they do, and what each file is for.
25: * RTL:: The intermediate representation that most passes work on.
26: * Machine Desc:: How to write machine description instruction patterns.
27: * Machine Macros:: How to write the machine description C macros.
28:
29:
30:
31: File: internals, Node: Copying, Next: Contributors, Prev: Top, Up: Top
32:
33: GNU CC GENERAL PUBLIC LICENSE
34: *****************************
35:
36: (Clarified 11 Feb 1988)
37:
38: The license agreements of most software companies keep you at the mercy
39: of those companies. By contrast, our general public license is intended to
40: give everyone the right to share GNU CC. To make sure that you get the
41: rights we want you to have, we need to make restrictions that forbid anyone
42: to deny you these rights or to ask you to surrender the rights. Hence this
43: license agreement.
44:
45: Specifically, we want to make sure that you have the right to give away
46: copies of GNU CC, that you receive source code or else can get it if you
47: want it, that you can change GNU CC or use pieces of it in new free
48: programs, and that you know you can do these things.
49:
50: To make sure that everyone has such rights, we have to forbid you to
51: deprive anyone else of these rights. For example, if you distribute copies
52: of GNU CC, you must give the recipients all the rights that you have. You
53: must make sure that they, too, receive or can get the source code. And you
54: must tell them their rights.
55:
56: Also, for our own protection, we must make certain that everyone finds
57: out that there is no warranty for GNU CC. If GNU CC is modified by someone
58: else and passed on, we want its recipients to know that what they have is
59: not what we distributed, so that any problems introduced by others will not
60: reflect on our reputation.
61:
62: Therefore we (Richard Stallman and the Free Software Foundation, Inc.)
63: make the following terms which say what you must do to be allowed to
64: distribute or change GNU CC.
65:
66: COPYING POLICIES
67: ================
68:
69: 1. You may copy and distribute verbatim copies of GNU CC source code as you
70: receive it, in any medium, provided that you conspicuously and
71: appropriately publish on each copy a valid copyright notice
72: ``Copyright (C) 1988 Free Software Foundation, Inc.'' (or with
73: whatever year is appropriate); keep intact the notices on all files
74: that refer to this License Agreement and to the absence of any
75: warranty; and give any other recipients of the GNU CC program a copy
76: of this License Agreement along with the program. You may charge a
77: distribution fee for the physical act of transferring a copy.
78:
79: 2. You may modify your copy or copies of GNU CC or any portion of it, and
80: copy and distribute such modifications under the terms of Paragraph 1
81: above, provided that you also do the following:
82:
83: * cause the modified files to carry prominent notices stating that
84: you changed the files and the date of any change; and
85:
86: * cause the whole of any work that you distribute or publish, that
87: in whole or in part contains or is a derivative of GNU CC or any
88: part thereof, to be licensed at no charge to all third parties on
89: terms identical to those contained in this License Agreement
90: (except that you may choose to grant more extensive warranty
91: protection to some or all third parties, at your option).
92:
93: * You may charge a distribution fee for the physical act of
94: transferring a copy, and you may at your option offer warranty
95: protection in exchange for a fee.
96:
97: Mere aggregation of another unrelated program with this program (or
98: its derivative) on a volume of a storage or distribution medium does
99: not bring the other program under the scope of these terms.
100:
101: 3. You may copy and distribute GNU CC (or a portion or derivative of it,
102: under Paragraph 2) in object code or executable form under the terms
103: of Paragraphs 1 and 2 above provided that you also do one of the
104: following:
105:
106: * accompany it with the complete corresponding machine-readable
107: source code, which must be distributed under the terms of
108: Paragraphs 1 and 2 above; or,
109:
110: * accompany it with a written offer, valid for at least three
111: years, to give any third party free (except for a nominal
112: shipping charge) a complete machine-readable copy of the
113: corresponding source code, to be distributed under the terms of
114: Paragraphs 1 and 2 above; or,
115:
116: * accompany it with the information you received as to where the
117: corresponding source code may be obtained. (This alternative is
118: allowed only for noncommercial distribution and only if you
119: received the program in object code or executable form alone.)
120:
121: For an executable file, complete source code means all the source code
122: for all modules it contains; but, as a special exception, it need not
123: include source code for modules which are standard libraries that
124: accompany the operating system on which the executable file runs.
125:
126: 4. You may not copy, sublicense, distribute or transfer GNU CC except as
127: expressly provided under this License Agreement. Any attempt
128: otherwise to copy, sublicense, distribute or transfer GNU CC is void
129: and your rights to use the program under this License agreement shall
130: be automatically terminated. However, parties who have received
131: computer software programs from you with this License Agreement will
132: not have their licenses terminated so long as such parties remain in
133: full compliance.
134:
135: 5. If you wish to incorporate parts of GNU CC into other free programs
136: whose distribution conditions are different, write to the Free
137: Software Foundation at 675 Mass Ave, Cambridge, MA 02139. We have not
138: yet worked out a simple rule that can be stated here, but we will
139: often permit this. We will be guided by the two goals of preserving
140: the free status of all derivatives of our free software and of
141: promoting the sharing and reuse of software.
142:
143: Your comments and suggestions about our licensing policies and our software
144: are welcome! Please contact the Free Software Foundation, Inc., 675 Mass
145: Ave, Cambridge, MA 02139, or call (617) 876-3296.
146:
147: NO WARRANTY
148: ===========
149:
150: BECAUSE GNU CC IS LICENSED FREE OF CHARGE, WE PROVIDE ABSOLUTELY NO
151: WARRANTY, TO THE EXTENT PERMITTED BY APPLICABLE STATE LAW. EXCEPT WHEN
152: OTHERWISE STATED IN WRITING, FREE SOFTWARE FOUNDATION, INC, RICHARD M.
153: STALLMAN AND/OR OTHER PARTIES PROVIDE GNU CC "AS IS" WITHOUT WARRANTY OF
154: ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
155: IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
156: THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF GNU CC IS WITH YOU.
157: SHOULD GNU CC PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
158: SERVICING, REPAIR OR CORRECTION.
159:
160: IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW WILL RICHARD M. STALLMAN,
161: THE FREE SOFTWARE FOUNDATION, INC., AND/OR ANY OTHER PARTY WHO MAY MODIFY
162: AND REDISTRIBUTE GNU CC AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
163: INCLUDING ANY LOST PROFITS, LOST MONIES, OR OTHER SPECIAL, INCIDENTAL OR
164: CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE (INCLUDING
165: BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES
166: SUSTAINED BY THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY
167: OTHER PROGRAMS) GNU CC, EVEN IF YOU HAVE BEEN ADVISED OF THE POSSIBILITY OF
168: SUCH DAMAGES, OR FOR ANY CLAIM BY ANY OTHER PARTY.
169:
170:
171: File: internals, Node: Contributors, Next: Options, Prev: Copying, Up: Top
172:
173: Contributors to GNU CC
174: **********************
175:
176: In addition to Richard Stallman, several people have written parts of GNU CC.
177:
178: * The idea of using RTL and some of the optimization ideas came from the
179: U. of Arizona Portable Optimizer, written by Jack Davidson and
180: Christopher Fraser. See ``Register Allocation and Exhaustive Peephole
181: Optimization'', Software Practice and Experience 14 (9), Sept. 1984,
182: 857-866.
183:
184: * Paul Rubin wrote most of the preprocessor.
185:
186: * Leonard Tower wrote parts of the parser, RTL generator, RTL
187: definitions, and of the Vax machine description.
188:
189: * Ted Lemon wrote parts of the RTL reader and printer.
190:
191: * Nobuyuki Hikichi of Software Research Associates, Tokyo, contributed
192: the support for the SONY NEWS machine.
193:
194: * Charles LaBrec contributed the support for the Integrated Solutions
195: 68020 system.
196:
197: * Michael Tiemann of MCC wrote the description of the National
198: Semiconductor 32000 series cpu, with some contributions from Jan Stein
199: of the Chalmers Computer Club. Tiemann also wrote the code for inline
200: function integration.
201:
202: * Robert Brown implemented the support for Encore 32000 systems.
203:
204: * Michael Kashtan of SRI adapted GNU CC to the Vomit-Making System.
205:
206: * Alex Crain provided changes for the 3b1.
207:
208: * Chris Hanson and another person who should remind me of his name
209: assisted in making GNU CC work on HP-UX for the 9000 series 300.
210:
211:
212: File: internals, Node: Options, Next: Installation, Prev: Contributors, Up: Top
213:
214: GNU CC Command Options
215: **********************
216:
217: The GNU C compiler uses a command syntax much like the Unix C compiler.
218: The `gcc' program accepts options and file names as operands. Multiple
219: single-letter options may *not* be grouped: `-dr' is very different from
220: `-d -r'.
221:
222: When you invoke GNU CC, it normally does preprocessing, compilation,
223: assembly and linking. File names which end in `.c' are taken as C source
224: to be preprocessed and compiled; compiler output files plus any input files
225: with names ending in `.s' are assembled; then the resulting object files,
226: plus any other input files, are linked together to produce an executable.
227:
228: Command options allow you to stop this process at an intermediate stage.
229: For example, the `-c' option says not to run the linker. Then the output
230: consists of object files output by the assembler.
231:
232: Other command options are passed on to one stage. Some options control the
233: preprocessor and others the compiler itself. Yet other options control the
234: assembler and linker; these are not documented here because the GNU
235: assembler and linker are not yet released.
236:
237: Here are the options to control the overall compilation process, including
238: those that say whether to link, whether to assemble, and so on.
239:
240: `-o FILE'
241: Place output in file FILE. This applies regardless to whatever sort
242: of output is being produced, whether it be an executable file, an
243: object file, an assembler file or preprocessed C code.
244:
245: If `-o' is not specified, the default is to put an executable file in
246: `a.out', the object file `SOURCE.c' in `SOURCE.o', an assembler file
247: in `SOURCE.s', and preprocessed C on standard output.
248:
249: `-c'
250: Compile or assemble the source files, but do not link. Produce object
251: files with names made by replacing `.c' or `.s' with `.o' at the end
252: of the input file names. Do nothing at all for object files specified
253: as input.
254:
255: `-S'
256: Compile into assembler code but do not assemble. The assembler output
257: file name is made by replacing `.c' with `.s' at the end of the input
258: file name. Do nothing at all for assembler source files or object
259: files specified as input.
260:
261: `-E'
262: Run only the C preprocessor. Preprocess all the C source files
263: specified and output the results to standard output.
264:
265: `-v'
266: Compiler driver program prints the commands it executes as it runs the
267: preprocessor, compiler proper, assembler and linker. Some of these
268: are directed to print their own version numbers.
269:
270: `-BPREFIX'
271: Compiler driver program tries PREFIX as a prefix for each program it
272: tries to run. These programs are `cpp', `cc1', `as' and `ld'.
273:
274: For each subprogram to be run, the compiler driver first tries the
275: `-B' prefix, if any. If that name is not found, or if `-B' was not
276: specified, the driver tries two standard prefixes, which are
277: `/usr/lib/gcc-' and `/usr/local/lib/gcc-'. If neither of those
278: results in a file name that is found, the unmodified program name is
279: searched for using the directories specified in your `PATH'
280: environment variable.
281:
282: The run-time support file `gnulib' is also searched for using the `-B'
283: prefix, if needed. If it is not found there, the two standard
284: prefixes above are tried, and that is all. The file is left out of
285: the link if it is not found by those means. Most of the time, on most
286: machines, you can do without it.
287:
288: These options control the details of C compilation itself.
289:
290: `-ansi'
291: Support all ANSI standard C programs.
292:
293: This turns off certain features of GNU C that are incompatible with
294: ANSI C, such as the `asm', `inline' and `typeof' keywords, and
295: predefined macros such as `unix' and `vax' that identify the type of
296: system you are using. It also enables the undesirable and rarely used
297: ANSI trigraph feature.
298:
299: The `-ansi' option does not cause non-ANSI programs to be rejected
300: gratuitously. For that, `-pedantic' is required in addition to `-ansi'.
301:
302: The macro `__STRICT_ANSI__' is predefined when the `-ansi' option is
303: used. Some header files may notice this macro and refrain from
304: declaring certain functions or defining certain macros that the ANSI
305: standard doesn't call for; this is to avoid interfering with any
306: programs that might use these names for other things.
307:
308: `-traditional'
309: Attempt to support some aspects of traditional C compilers.
310: Specifically:
311:
312: * All `extern' declarations take effect globally even if they are
313: written inside of a function definition. This includes implicit
314: declarations of functions.
315:
316: * The keywords `typeof', `inline', `signed', `const' and `volatile'
317: are not recognized.
318:
319: * Comparisons between pointers and integers are always allowed.
320:
321: * Integer types `unsigned short' and `unsigned char' promote to
322: `unsigned int'.
323:
324: * In the preprocessor, comments convert to nothing at all, rather
325: than to a space. This allows traditional token concatenation.
326:
327: * In the preprocessor, single and double quote characters are
328: ignored when scanning macro definitions, so that macro arguments
329: can be replaced even within a string or character constant.
330: Quote characters are also ignored when skipping text inside a
331: failing conditional directive.
332:
333: `-O'
334: Optimize. Optimizing compilation takes somewhat more time, and a lot
335: more memory for a large function.
336:
337: Without `-O', the compiler's goal is to reduce the cost of compilation
338: and to make debugging produce the expected results. Statements are
339: independent: if you stop the program with a breakpoint between
340: statements, you can then assign a new value to any variable or change
341: the program counter to any other statement in the function and get
342: exactly the results you would expect from the source code.
343:
344: Without `-O', only variables declared `register' are allocated in
345: registers. The resulting compiled code is a little worse than
346: produced by PCC without `-O'.
347:
348: With `-O', the compiler tries to reduce code size and execution time.
349:
350: Some of the `-f' options described below turn specific kinds of
351: optimization on or off.
352:
353: `-g'
354: Produce debugging information in DBX format.
355:
356: Unlike most other C compilers, GNU CC allows you to use `-g' with
357: `-O'. The shortcuts taken by optimized code may occasionally produce
358: surprising results: some variables you declared may not exist at all;
359: flow of control may briefly move where you did not expect it; some
360: statements may not be executed because they compute constant results
361: or their values were already at hand; some statements may execute in
362: different places because they were moved out of loops. Nevertheless
363: it proves possible to debug optimized output. This makes it
364: reasonable to use the optimizer for programs that might have bugs.
365:
366: `-gg'
367: Produce debugging information in GDB's own format. This requires the
368: GNU assembler and linker in order to work.
369:
370: `-w'
371: Inhibit all warning messages.
372:
373: `-W'
374: Print extra warning messages for these events:
375:
376: * An automatic variable is used without first being initialized.
377:
378: These warnings are possible only in optimizing compilation,
379: because they require data flow information that is computed only
380: when optimizing. They occur only for variables that are
381: candidates for register allocation. Therefore, they do not occur
382: for a variable that is declared `volatile', or whose address is
383: taken, or whose size is other than 1, 2, 4 or 8 bytes. Also,
384: they do not occur for structures, unions or arrays, even when
385: they are in registers.
386:
387: Note that there may be no warning about a variable that is used
388: only to compute a value that itself is never used, because such
389: computations may be deleted by the flow analysis pass before the
390: warnings are printed.
391:
392: These warnings are made optional because GNU CC is not smart
393: enough to see all the reasons why the code might be correct
394: despite appearing to have an error. Here is one example of how
395: this can happen:
396:
397: {
398: int x;
399: switch (y)
400: {
401: case 1: x = 1;
402: break;
403: case 2: x = 4;
404: break;
405: case 3: x = 5;
406: }
407: foo (x);
408: }
409:
410: If the value of `y' is always 1, 2 or 3, then `x' is always
411: initialized, but GNU CC doesn't know this. Here is another
412: common case:
413:
414: {
415: int save_y;
416: if (change_y) save_y = y, y = new_y;
417: ...
418: if (change_y) y = save_y;
419: }
420:
421: This has no bug because `x' is used only if it is set.
422:
423: * A nonvolatile automatic variable might be changed by a call to
424: `longjmp'. These warnings as well are possible only in
425: optimizing compilation.
426:
427: The compiler sees only the calls to `setjmp'. It cannot know
428: where `longjmp' will be called; in fact, a signal handler could
429: call it at any point in the code. As a result, you may get a
430: warning even when there is in fact no problem because `longjmp'
431: cannot in fact be called at the place which would cause a problem.
432:
433: * A function can return either with or without a value. (Falling
434: off the end of the function body is considered returning without
435: a value.) For example, this function would inspire such a warning:
436:
437: foo (a)
438: {
439: if (a > 0)
440: return a;
441: }
442:
443: Spurious warnings can occur because GNU CC does not realize that
444: certain functions (including `abort' and `longjmp') will never
445: return.
446:
447: In the future, other useful warnings may also be enabled by this option.
448:
449: `-Wimplicit'
450: Warn whenever a function is implicitly declared.
451:
452: `-Wreturn-type'
453: Warn whenever a function is defined with a return-type that defaults
454: to `int'. Also warn about any `return' statement with no return-value
455: in a function whose return-type is not `void'.
456:
457: `-Wcomment'
458: Warn whenever a comment-start sequence `/*' appears in a comment.
459:
460: `-Wall'
461: All of the above `-W' options combined.
462:
463: `-p'
464: Generate extra code to write profile information suitable for the
465: analysis program `prof'.
466:
467: `-pg'
468: Generate extra code to write profile information suitable for the
469: analysis program `gprof'.
470:
471: `-lLIBRARY'
472: Search a standard list of directories for a library named LIBRARY,
473: which is actually a file named `libLIBRARY.a'. The linker uses this
474: file as if it had been specified precisely by name.
475:
476: The directories searched include several standard system directories
477: plus any that you specify with `-L'.
478:
479: Normally the files found this way are library files---archive files
480: whose members are object files. The linker handles an archive file by
481: through it for members which define symbols that have so far been
482: referenced but not defined. But if the file that is found is an
483: ordinary object file, it is linked in the usual fashion. The only
484: difference between an `-l' option and the full file name of the file
485: that is found is syntactic and the fact that several directories are
486: searched.
487:
488: `-LDIR'
489: Add directory DIR to the list of directories to be searched for `-l'.
490:
491: `-nostdlib'
492: Don't use the standard system libraries and startup files when
493: linking. Only the files you specify (plus `gnulib') will be passed to
494: the linker.
495:
496: `-mMACHINESPEC'
497: Machine-dependent option specifying something about the type of target
498: machine. These options are defined by the macro `TARGET_SWITCHES' in
499: the machine description. The default for the options is also defined
500: by that macro, which enables you to change the defaults.
501:
502: These are the `-m' options defined in the 68000 machine description:
503:
504: `-m68020'
505: Generate output for a 68020 (rather than a 68000). This is the
506: default if you use the unmodified sources.
507:
508: `-m68000'
509: Generate output for a 68000 (rather than a 68020).
510:
511: `-m68881'
512: Generate output containing 68881 instructions for floating point.
513: This is the default if you use the unmodified sources.
514:
515: `-msoft-float'
516: Generate output containing library calls for floating point.
517:
518: `-mshort'
519: Consider type `int' to be 16 bits wide, like `short int'.
520:
521: `-mnobitfield'
522: Do not use the bit-field instructions. `-m68000' implies
523: `-mnobitfield'.
524:
525: `-mbitfield'
526: Do use the bit-field instructions. `-m68020' implies
527: `-mbitfield'. This is the default if you use the unmodified
528: sources.
529:
530: `-mrtd'
531: Use a different function-calling convention, in which functions
532: that take a fixed number of arguments return with the `rtd'
533: instruction, which pops their arguments while returning. This
534: saves one instruction in the caller since there is no need to pop
535: the arguments there.
536:
537: This calling convention is incompatible with the one normally
538: used on Unix, so you cannot use it if you need to call libraries
539: compiled with the Unix compiler.
540:
541: Also, you must provide function prototypes for all functions that
542: take variable numbers of arguments (including `printf');
543: otherwise incorrect code will be generated for calls to those
544: functions.
545:
546: In addition, seriously incorrect code will result if you call a
547: function with too many arguments. (Normally, extra arguments are
548: harmlessly ignored.)
549:
550: The `rtd' instruction is supported by the 68010 and 68020
551: processors, but not by the 68000.
552:
553: These `-m' options are defined in the Vax machine description:
554:
555: `-munix'
556: Do not output certain jump instructions (`aobleq' and so on) that
557: the Unix assembler for the Vax cannot handle across long ranges.
558:
559: `-mgnu'
560: Do output those jump instructions, on the assumption that you
561: will assemble with the GNU assembler.
562:
563: `-mg'
564: Output code for g-format floating point numbers instead of
565: d-format.
566:
567: `-fFLAG'
568: Specify machine-independent flags. These are the flags:
569:
570: `-ffloat-store'
571: Do not store floating-point variables in registers. This
572: prevents undesirable excess precision on machines such as the
573: 68000 where the floating registers (of the 68881) keep more
574: precision than a `double' is supposed to have.
575:
576: For most programs, the excess precision does only good, but a few
577: programs rely on the precise definition of IEEE floating point.
578: Use `-ffloat-store' for such programs.
579:
580: `-fno-asm'
581: Do not recognize `asm', `inline' or `typeof' as a keyword. These
582: words may then be used as identifiers.
583:
584: `-fno-defer-pop'
585: Always pop the arguments to each function call as soon as that
586: function returns. Normally the compiler (when optimizing) lets
587: arguments accumulate on the stack for several function calls and
588: pops them all at once.
589:
590: `-fcombine-regs'
591: Allow the combine pass to combine an instruction that copies one
592: register into another. This might or might not produce better
593: code when used in addition to `-O'. I am interested in hearing
594: about the difference this makes.
595:
596: `-fforce-mem'
597: Force memory operands to be copied into registers before doing
598: arithmetic on them. This may produce better code by making all
599: memory references potential common subexpressions. When they are
600: not common subexpressions, instruction combination should
601: eliminate the separate register-load. I am interested in hearing
602: about the difference this makes.
603:
604: `-fforce-addr'
605: Force memory address constants to be copied into registers before
606: doing arithmetic on them. This may produce better code just as
607: `-fforce-mem' may. I am interested in hearing about the
608: difference this makes.
609:
610: `-fomit-frame-pointer'
611: Don't keep the frame pointer in a register for functions that
612: don't need one. This avoids the instructions to save, set up and
613: restore frame pointers; it also makes an extra register available
614: in many functions. *It also makes debugging impossible.*
615:
616: On some machines, such as the Vax, this flag has no effect,
617: because the standard calling sequence automatically handles the
618: frame pointer and nothing is saved by pretending it doesn't
619: exist. The machine-description macro `FRAME_POINTER_REQUIRED'
620: controls whether a target machine supports this flag. *note
621: Registers::.
622:
623: `-finline-functions'
624: Integrate all simple functions into their callers. The compiler
625: heuristically decides which functions are simple enough to be
626: worth integrating in this way.
627:
628: If all calls to a given function are integrated, and the function
629: is declared `static', then the function is normally not output as
630: assembler code in its own right.
631:
632: `-fkeep-inline-functions'
633: Even if all calls to a given function are integrated, and the
634: function is declared `static', nevertheless output a separate
635: run-time callable version of the function.
636:
637: `-fwritable-strings'
638: Store string constants in the writable data segment and don't
639: uniquize them. This is for compatibility with old programs which
640: assume they can write into string constants. Writing into string
641: constants is a very bad idea; ``constants'' should be constant.
642:
643: `-fno-function-cse'
644: Do not put function addresses in registers; make each instruction
645: that calls a constant function contain the function's address
646: explicitly.
647:
648: This option results in less efficient code, but some strange
649: hacks that alter the assembler output may be confused by the
650: optimizations performed when this option is not used.
651:
652: `-fvolatile'
653: Consider all memory references through pointers to be volatile.
654:
655: `-funsigned-char'
656: Let the type `char' be the unsigned, like `unsigned char'.
657:
658: Each kind of machine has a default for what `char' should be. It
659: is either like `unsigned char' by default or like `signed char'
660: by default. (Actually, at present, the default is always signed.)
661:
662: The type `char' is always a distinct type from either `signed
663: char' or `unsigned char', even though its behavior is always just
664: like one of those two.
665:
666: `-fsigned-char'
667: Let the type `char' be signed, like `signed char'.
668:
669: `-ffixed-REG'
670: Treat the register named REG as a fixed register; generated code
671: should never refer to it (except perhaps as a stack pointer,
672: frame pointer or in some other fixed role).
673:
674: REG must be the name of a register. The register names accepted
675: are machine-specific and are defined in the `REGISTER_NAMES'
676: macro in the machine description macro file.
677:
678: `-fcall-used-REG'
679: Treat the register named REG as an allocatable register that is
680: clobbered by function calls. It may be allocated for temporaries
681: or variables that do not live across a call. Functions compiled
682: this way will not save and restore the register REG.
683:
684: Use of this flag for a register that has a fixed pervasive role
685: in the machine's execution model, such as the stack pointer or
686: frame pointer, will produce disastrous results.
687:
688: `-fcall-saved-REG'
689: Treat the register named REG as an allocatable register saved by
690: functions. It may be allocated even for temporaries or variables
691: that live across a call. Functions compiled this way will save
692: and restore the register REG if they use it.
693:
694: Use of this flag for a register that has a fixed pervasive role
695: in the machine's execution model, such as the stack pointer or
696: frame pointer, will produce disastrous results.
697:
698: A different sort of disaster will result from the use of this
699: flag for a register in which function values are may be returned.
700:
701: `-dLETTERS'
702: Says to make debugging dumps at times specified by LETTERS. Here are
703: the possible letters:
704:
705: `r'
706: Dump after RTL generation.
707: `j'
708: Dump after first jump optimization.
709: `J'
710: Dump after last jump optimization.
711: `s'
712: Dump after CSE (including the jump optimization that sometimes
713: follows CSE).
714: `L'
715: Dump after loop optimization.
716: `f'
717: Dump after flow analysis.
718: `c'
719: Dump after instruction combination.
720: `l'
721: Dump after local register allocation.
722: `g'
723: Dump after global register allocation.
724: `m'
725: Print statistics on memory usage, at the end of the run.
726:
727: `-pedantic'
728: Issue all the warnings demanded by strict ANSI standard C; reject all
729: programs that use forbidden extensions.
730:
731: Valid ANSI standard C programs should compile properly with or without
732: this option (though a rare few will require `-ansi'). However,
733: without this option, certain GNU extensions and traditional C features
734: are supported as well. With this option, they are rejected. There is
735: no reason to use this option; it exists only to satisfy pedants.
736:
737: These options control the C preprocessor, which is run on each C source
738: file before actual compilation. If you use the `-E' option, nothing is
739: done except C preprocessing. Some of these options make sense only
740: together with `-E' because they request preprocessor output that is not
741: suitable for actual compilation.
742:
743: `-C'
744: Tell the preprocessor not to discard comments. Used with the `-E'
745: option.
746:
747: `-IDIR'
748: Search directory DIR for include files.
749:
750: `-I-'
751: Any directories specified with `-I' options before the `-I-' option
752: are searched only for the case of `#include "FILE"'; they are not
753: searched for `#include <FILE>'.
754:
755: If additional directories are specified with `-I' options after the
756: `-I-', these directories are searched for all `#include' directives.
757: (Ordinarily *all* `-I' directories are used this way.)
758:
759: In addition, the `-I-' option inhibits the use of the current
760: directory as the first search directory for `#include "FILE"'.
761: Therefore, the current directory is searched only if it is requested
762: explicitly with `-I.'. Specifying both `-I-' and `-I.' allows you to
763: control precisely which directories are searched before the current
764: one and which are searched after.
765:
766: `-nostdinc'
767: Do not search the standard system directories for header files. Only
768: the directories you have specified with `-I' options (and the current
769: directory, if appropriate) are searched.
770:
771: Between `-nostdinc' and `-I-', you can eliminate all directories from
772: the search path except those you specify.
773:
774: `-M'
775: Tell the preprocessor to output a rule suitable for `make' describing
776: the dependencies of each source file. For each source file, the
777: preprocessor outputs one `make'-rule whose target is the object file
778: name for that source file and whose dependencies are all the files
779: `#include'd in it. This rule may be a single line or may be continued
780: with `\'-newline if it is long.
781:
782: `-M' implies `-E'.
783:
784: `-MM'
785: Like `-M' but the output mentions only the user-header files included
786: with `#include "FILE"'. System header files included with `#include
787: <FILE>' are omitted.
788:
789: `-MM' implies `-E'.
790:
791: `-DMACRO'
792: Define macro MACRO with the empty string as its definition.
793:
794: `-DMACRO=DEFN'
795: Define macro MACRO as DEFN.
796:
797: `-UMACRO'
798: Undefine macro MACRO.
799:
800: `-T'
801: Support ANSI C trigraphs. You don't want to know about this
802: brain-damage. The `-ansi' option also has this effect.
803:
804:
805: File: internals, Node: Installation, Next: Trouble, Prev: Options, Up: Top
806:
807: Installing GNU CC
808: *****************
809:
810: Here is the procedure for installing GNU CC on a Unix system.
811:
812: * Menu:
813:
814: * VMS Install:: See below for installation on VMS.
815:
816:
817: 1. Edit `Makefile'. If you are using HPUX, you must make a few changes
818: described in comments at the beginning of the file.
819:
820: 2. Choose configuration files.
821:
822: * Make a symbolic link named `config.h' to the top-level config
823: file for the machine you are using (*Note Config::.). This file
824: is responsible for defining information about the host machine.
825: It includes `tm.h'.
826:
827: The file's name should be `config-MACHINE.h'. On VMS, use
828: `config-vms.h' rather than `config-vax.h'. On the HP 9000 series
829: 300, use `config-hp9k3.h' rather than `config-m68k.h'.
830:
831: If your system does not support symbolic links, you might want to
832: set up `config.h' to contain a `#include' command which refers to
833: the appropriate file.
834:
835: * Make a symbolic link named `tm.h' to the machine-description
836: macro file for your machine (its name should be `tm-MACHINE.h').
837:
838: For the 68000/68020, do not use `tm-m68k.h' directly; instead use
839: one of the files `tm-sun3.h', `tm-sun2.h', `tm-isi68.h',
840: `tm-news800.h' or `tm-3b1.h'. Each of those files includes
841: `tm-m68k.h' but sets up a few things differently as appropriate
842: to the specific model of machine.
843:
844: There are two files you can use for a 680x0 running HPUX:
845: `tm-hp9k320.h' and `tm-hp9k320g.h'. Use the former if you are
846: installing GNU CC alone. The latter is for another option where
847: GNU CC together with the GNU assembler, linker, debugger and
848: other utilities are used to replace all of HPUX that deals with
849: compilation. Not all of the pieces of GNU software needed for
850: this mode of operation are as yet in distribution; full
851: instructions will appear here in the future.
852:
853: For the 32000, use `tm-sequent.h' if you are using a Sequent
854: machine, or `tm-encore.h' for an Encore machine; otherwise,
855: perhaps `tm-ns32k.h' will work for you.
856:
857: For the vax, use `tm-vax.h' on Unix, or `tm-vms.h' on VMS.
858:
859: * Make a symbolic link named `md' to the machine description
860: pattern file (its name should be `MACHINE.md').
861:
862: * Make a symbolic link named `aux-output.c' to the output
863: subroutine file for your machine (its name should be
864: `OUTPUT-MACHINE.c').
865:
866: 3. Make sure the Bison parser generator is installed. (This is unnecessary
867: if the Bison output file `parse.tab.c' is more recent than `parse.y'
868: and you do not plan to change `parse.y'.)
869:
870: Note that if you have an old version of Bison you may get an error
871: from the line with the `%expect' directive. If so, simply remove that
872: line from `parse.y' and proceed.
873:
874: 4. If you are using a Sun, make sure the environment variable
875: `FLOAT_OPTION' is not set. If this option were set to `f68881' when
876: `gnulib' is compiled, the resulting code would demand to be linked
877: with a special startup file and will not link properly without special
878: pains.
879:
880: 5. Build the compiler. Just type `make' in the compiler directory.
881:
882: 6. Move the first-stage object files and executables into a subdirectory
883: with this command:
884:
885: make stage1
886:
887: The files are moved into a subdirectory named `stage1'. Once
888: installation is complete, you may wish to delete these files with `rm
889: -r stage1'.
890:
891: 7. Recompile the compiler with itself, with this command:
892:
893: make CC=stage1/gcc CFLAGS="-g -O -Bstage1/"
894:
895: On a 68000 or 68020 system lacking floating point hardware, unless you
896: have selected a `tm.h' file that expects by default that there is no
897: such hardware, do this instead:
898:
899: make CC=stage1/gcc CFLAGS="-g -O -Bstage1/ -msoft-float"
900:
901: 8. If you wish to test the compiler by compiling it with itself one more
902: time, do this:
903:
904: make stage2
905: make CC=stage2/gcc CFLAGS="-g -O -Bstage2/"
906: foreach file (*.o)
907: cmp $file stage2/$file
908: end
909:
910: This will notify you if any of these stage 3 object files differs from
911: those of stage 2. Any difference, no matter how innocuous, indicates
912: that the stage 2 compiler has compiled GNU CC incorrectly, and is
913: therefore a potentially serious bug which you should investigate and
914: report (*Note Bugs::.).
915:
916: 9. Install the compiler driver, the compiler's passes and run-time support.
917: You can use the following command:
918:
919: make install
920:
921: This copies the files `cc1', `cpp' and `gnulib' to files `gcc-cc1',
922: `gcc-cpp' and `gcc-gnulib' in directory `/usr/local/lib', which is
923: where the compiler driver program looks for them. It also copies the
924: driver program `gcc' into the directory `/usr/local', so that it
925: appears in typical execution search paths.
926:
927: *Warning: the GNU CPP may not work for `ioctl.h', `ttychars.h' and
928: other system header files unless the `-traditional' option is used.*
929: The bug is in the header files: at least on some machines, they rely
930: on behavior that is incompatible with ANSI C. This behavior consists
931: of substituting for macro argument names when they appear inside of
932: character constants. The `-traditional' option tells GNU CC to behave
933: the way these headers expect.
934:
935: Because of this problem, you might prefer to configure GNU CC to use
936: the system's own C preprocessor. To do so, make the file
937: `/usr/local/lib/gcc-cpp' a link to `/lib/cpp'.
938:
939: Alternatively, on Sun systems and 4.3BSD at least, you can correct the
940: include files by running the shell script `fixincludes'. This
941: installs modified, corrected copies of the files `ioctl.h' and
942: `ttychars.h' in a special directory where only GNU CC will normally
943: look for them.
944:
945: The file `/usr/include/vaxuba/qvioctl.h' used in the X window system
946: needs a similar correction.
947:
948: If you cannot install the compiler's passes and run-time support in
949: `/usr/local/lib', you can alternatively use the `-B' option to specify a
950: prefix by which they may be found. The compiler concatenates the prefix
951: with the names `cpp', `cc1' and `gnulib'. Thus, you can put the files in
952: a directory `/usr/foo/gcc' and specify `-B/usr/foo/gcc/' when you run GNU CC.
953:
954:
955: File: internals, Node: VMS Install, Prev: Installation, Up: Installation
956:
957: Installing GNU CC on VMS
958: ========================
959:
960: The VMS version of GNU CC is distributed in an unusual tape format which
961: consists of several tape files. The first is a command file; the second is
962: an executable program which reads Unix tar format; the third is another
963: command file which uses this program to read the remainder of the tape.
964:
965: To load the tape, it suffices to mount it `/foreign' and then do `@mta0:'
966: to execute the command file at the beginning of the tape.
967:
968: The tape contains executables and object files as well as sources, so no
969: compilation is necessary unless you change the sources. (This is a good
970: thing, since you probably don't have any other C compiler.) If you must
971: recompile, here is how:
972:
973: 1. Copy the file `tm-vms.h' to `tm.h', `config-vms.h' to `config.h',
974: `vax.md' to `md.' and `output-vax.c' to `aux-output.c'.
975:
976: 2. Type `@make' to do recompile everything.
977:
978: To install the `GCC' command so you can use the compiler easily, in the
979: same manner as you use the VMS C compiler, you must install the VMS CLD
980: file for GNU CC as follows:
981:
982: 1. Define the VMS logical names `GNU_CC' and `GNU_CC_INCLUDE' to point to
983: the directories where the GNU CC executables (`gcc-cpp', `gcc-cc1',
984: etc.) and the C include files are kept. This should be done with the
985: commands:
986:
987: $ assign /super /system disk:[gcc] gnu_cc
988: $ assign /super /system disk:[gcc.include] gnu_cc_include
989:
990: with the appropriate disk and directory names. These commands can be
991: placed in your system startup file so they will be executed whenever
992: the machine is rebooted.
993:
994: 2. Install the `GCC' command with the command line:
995:
996: $ set command /table=sys$library:dcltables gnu_cc:gcc
997:
998: Now you can invoke the compiler with a command like `gcc /verbose
999: file.c', which is equivalent to the command `gcc -v -c file.c' in Unix.
1000:
1001:
1002: File: internals, Node: Trouble, Next: Incompatibilities, Prev: Installation, Up: Top
1003:
1004: Trouble in Installation
1005: ***********************
1006:
1007: Here are some of the things that have caused trouble for people installing
1008: GNU CC.
1009:
1010:
1011:
1012: On certain systems, defining certain environment variables such as
1013: `CC' can interfere with the functioning of `make'.
1014:
1015:
1016: File: internals, Node: Incompatibilities, Next: Extensions, Prev: Trouble, Up: Top
1017:
1018: Incompatibilities of GNU CC
1019: ***************************
1020:
1021: There are several noteworthy incompatibilities between GNU C and most
1022: existing (non-ANSI) versions of C.
1023:
1024: Ultimately our intention is that the `-traditional' option will eliminate
1025: most of these incompatibilities by telling GNU C to behave like the other C
1026: compilers.
1027:
1028: * GNU CC normally makes string constants read-only. If several
1029: identical-looking string constants are used, GNU CC stores only one
1030: copy of the string.
1031:
1032: One consequence is that you cannot call `mktemp' with a string
1033: constant argument. The function `mktemp' always alters the string its
1034: argument points to.
1035:
1036: Another consequence is that `sscanf' does not work on some systems
1037: when passed a string constant as its format control string. This is
1038: because `sscanf' incorrectly tries to write into the string constant.
1039:
1040: The best solution to these problems is to change the program to use
1041: `char'-array variables with initialization strings for these purposes
1042: instead of string constants. But if this is not possible, you can use
1043: the `-fwritable-strings' flag, which directs GNU CC to handle string
1044: constants the same way most C compilers do.
1045:
1046: * GNU CC does not substitute macro arguments when they appear inside of
1047: string constants. For example, the following macro in GNU CC
1048:
1049: #define foo(a) "a"
1050:
1051: will produce output `"a"' regardless of what the argument A is.
1052:
1053: The `-traditional' option directs GNU CC to handle such cases (among
1054: others) in the old-fashioned (non-ANSI) fashion.
1055:
1056: * When you use `setjmp' and `longjmp', the only automatic variables
1057: guaranteed to remain valid are those declared `volatile'. This is a
1058: consequence of automatic register allocation. Consider this function:
1059:
1060: jmp_buf j;
1061:
1062: foo ()
1063: {
1064: int a, b;
1065:
1066: a = fun1 ();
1067: if (setjmp (j))
1068: return a;
1069:
1070: a = fun2 ();
1071: /* `longjmp (j)' may be occur in `fun3'. */
1072: return a + fun3 ();
1073: }
1074:
1075: Here `a' may or may not be restored to its first value when the
1076: `longjmp' occurs. If `a' is allocated in a register, then its first
1077: value is restored; otherwise, it keeps the last value stored in it.
1078:
1079: If you use the `-W' option with the `-O' option, you will get a
1080: warning when GNU CC thinks such a problem might be possible.
1081:
1082: * Declarations of external variables and functions within a block apply
1083: only to the block containing the declaration. In other words, they
1084: have the same scope as any other declaration in the same place.
1085:
1086: In some other C compilers, a `extern' declaration affects all the rest
1087: of the file even if it happens within a block.
1088:
1089: The `-traditional' option directs GNU C to treat all `extern'
1090: declarations as global, like traditional compilers.
1091:
1092: * In traditional C, you can combine `long', etc., with a typedef name,
1093: as shown here:
1094:
1095: typedef int foo;
1096: typedef long foo bar;
1097:
1098: In ANSI C, this is not allowed: `long' and other type modifiers
1099: require an explicit `int'. Because this criterion is expressed by
1100: Bison grammar rules rather than C code, the `-traditional' flag cannot
1101: alter it.
1102:
1103: * When compiling functions that return structures or unions, GNU CC
1104: output code uses a method different from that used on most versions of
1105: Unix. As a result, code compiled with GNU CC cannot call a
1106: structure-returning function compiled with PCC, and vice versa.
1107:
1108: The method used by GCC is as follows: a structure or union which is 1,
1109: 2, 4 or 8 bytes long is returned like a scalar. A structure or union
1110: with any other size is stored into an address supplied by the caller
1111: in a special, fixed register.
1112:
1113: PCC usually handles all sizes of structures and unions by returning
1114: the address of a block of static storage containing the value. This
1115: method is not used in GCC because it is slower and nonreentrant.
1116:
1117: On systems where PCC works this way, you may be able to make
1118: GCC-compiled code call such functions that were compiled with PCC by
1119: declaring them to return a pointer to the structure or union instead
1120: of the structure or union itself. For example, instead of this:
1121:
1122: struct foo nextfoo ();
1123:
1124: write this:
1125:
1126: struct foo *nextfoo ();
1127: #define nextfoo *nextfoo
1128:
1129: (Note that this assumes you are using the GNU preprocessor, so that
1130: the ANSI antirecursion rules for macro expansions are effective.)
1131:
1132:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.