]>
Commit | Line | Data |
---|---|---|
e9a25f70 | 1 | \input texinfo @c -*-texinfo-*- |
861bb6c1 JL |
2 | @c %**start of header |
3 | @setfilename gcc.info | |
4 | @c @setfilename usegcc.info | |
5 | @c @setfilename portgcc.info | |
6 | @c To produce the full manual, use the "gcc.info" setfilename, and | |
7 | @c make sure the following do NOT begin with '@c' (and the @clear lines DO) | |
8 | @set INTERNALS | |
9 | @set USING | |
10 | @c To produce a user-only manual, use the "usegcc.info" setfilename, and | |
11 | @c make sure the following does NOT begin with '@c': | |
12 | @c @clear INTERNALS | |
13 | @c To produce a porter-only manual, use the "portgcc.info" setfilename, | |
14 | @c and make sure the following does NOT begin with '@c': | |
15 | @c @clear USING | |
16 | ||
17 | @c (For FSF printing, turn on smallbook, comment out finalout below; | |
18 | @c that is all that is needed.) | |
19 | ||
20 | @c 6/27/96 FSF DO wants smallbook fmt for 1st bound edition. | |
21 | @c @smallbook | |
22 | ||
23 | @c i also commented out the finalout command, so if there *are* any | |
24 | @c overfulls, you'll (hopefully) see the rectangle in the right hand | |
25 | @c margin. -mew 15june93 | |
26 | @c @finalout | |
27 | ||
28 | @c NOTE: checks/things to do: | |
29 | @c | |
30 | @c -have bob do a search in all seven files for "mew" (ideally --mew, | |
31 | @c but i may have forgotten the occasional "--"..). | |
32 | @c Just checked... all have `--'! Bob 22Jul96 | |
33 | @c Use this to search: grep -n '\-\-mew' *.texi | |
34 | @c -item/itemx, text after all (sub/sub)section titles, etc.. | |
35 | @c -consider putting the lists of options on pp 17--> etc in columns or | |
36 | @c some such. | |
37 | @c -spellcheck | |
38 | @c -continuity of phrasing; ie, bit-field vs bitfield in rtl.texi | |
39 | @c -overfulls. do a search for "mew" in the files, and you will see | |
40 | @c overfulls that i noted but could not deal with. | |
41 | @c -have to add text: beginning of chapter 8 | |
42 | ||
43 | @c | |
44 | @c anything else? --mew 10feb93 | |
45 | ||
46 | ||
47 | ||
48 | @ifset INTERNALS | |
49 | @ifset USING | |
50 | @settitle Using and Porting GNU CC | |
51 | @end ifset | |
52 | @end ifset | |
53 | @c seems reasonable to assume at least one of INTERNALS or USING is set... | |
54 | @ifclear INTERNALS | |
55 | @settitle Using GNU CC | |
56 | @end ifclear | |
57 | @ifclear USING | |
58 | @settitle Porting GNU CC | |
59 | @end ifclear | |
60 | ||
61 | @syncodeindex fn cp | |
62 | @syncodeindex vr cp | |
63 | @c %**end of header | |
64 | ||
65 | @c Use with @@smallbook. | |
66 | ||
67 | @c Cause even numbered pages to be printed on the left hand side of | |
68 | @c the page and odd numbered pages to be printed on the right hand | |
69 | @c side of the page. Using this, you can print on both sides of a | |
70 | @c sheet of paper and have the text on the same part of the sheet. | |
71 | ||
72 | @c The text on right hand pages is pushed towards the right hand | |
73 | @c margin and the text on left hand pages is pushed toward the left | |
74 | @c hand margin. | |
75 | @c (To provide the reverse effect, set bindingoffset to -0.75in.) | |
76 | ||
77 | @c @tex | |
78 | @c \global\bindingoffset=0.75in | |
79 | @c \global\normaloffset =0.75in | |
80 | @c @end tex | |
81 | ||
82 | @ifinfo | |
83 | @ifset INTERNALS | |
84 | @ifset USING | |
85 | This file documents the use and the internals of the GNU compiler. | |
86 | @end ifset | |
87 | @end ifset | |
88 | @ifclear USING | |
89 | This file documents the internals of the GNU compiler. | |
90 | @end ifclear | |
91 | @ifclear INTERNALS | |
92 | This file documents the use of the GNU compiler. | |
93 | @end ifclear | |
94 | ||
95 | Published by the Free Software Foundation | |
96 | 59 Temple Place - Suite 330 | |
97 | Boston, MA 02111-1307 USA | |
98 | ||
c85f7c16 | 99 | Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998 Free Software Foundation, Inc. |
861bb6c1 JL |
100 | |
101 | Permission is granted to make and distribute verbatim copies of | |
102 | this manual provided the copyright notice and this permission notice | |
103 | are preserved on all copies. | |
104 | ||
105 | @ignore | |
106 | Permission is granted to process this file through Tex and print the | |
107 | results, provided the printed document carries copying permission | |
108 | notice identical to this one except for the removal of this paragraph | |
109 | (this paragraph not being relevant to the printed manual). | |
110 | ||
111 | @end ignore | |
112 | Permission is granted to copy and distribute modified versions of this | |
113 | manual under the conditions for verbatim copying, provided also that the | |
e5e809f4 JL |
114 | sections entitled ``GNU General Public License'' and ``Funding for Free |
115 | Software'' are included exactly as in the original, and provided that | |
116 | the entire resulting derived work is distributed under the terms of a | |
117 | permission notice identical to this one. | |
861bb6c1 JL |
118 | |
119 | Permission is granted to copy and distribute translations of this manual | |
120 | into another language, under the above conditions for modified versions, | |
e5e809f4 JL |
121 | except that the sections entitled ``GNU General Public License'' and |
122 | ``Funding for Free Software'', and this permission notice, may be | |
123 | included in translations approved by the Free Software Foundation | |
124 | instead of in the original English. | |
861bb6c1 JL |
125 | @end ifinfo |
126 | ||
127 | @setchapternewpage odd | |
e5e809f4 | 128 | @c @finalout |
861bb6c1 JL |
129 | @titlepage |
130 | @ifset INTERNALS | |
131 | @ifset USING | |
132 | @center @titlefont{Using and Porting GNU CC} | |
133 | ||
134 | @end ifset | |
135 | @end ifset | |
136 | @ifclear INTERNALS | |
137 | @title Using GNU CC | |
138 | @end ifclear | |
139 | @ifclear USING | |
140 | @title Porting GNU CC | |
141 | @end ifclear | |
142 | @sp 2 | |
143 | @center Richard M. Stallman | |
144 | @sp 3 | |
e5e809f4 | 145 | @center Last updated 16 March 1998 |
861bb6c1 | 146 | @sp 1 |
e5e809f4 | 147 | @c The version number appears five times more in this file. |
861bb6c1 | 148 | |
f2d76545 | 149 | @center for egcs-1.0 |
861bb6c1 JL |
150 | @page |
151 | @vskip 0pt plus 1filll | |
e5e809f4 | 152 | Copyright @copyright{} 1988, 89, 92, 93, 94, 95, 96, 98 Free Software Foundation, Inc. |
861bb6c1 | 153 | @sp 2 |
f2d76545 | 154 | For EGCS Version 1.0@* |
861bb6c1 JL |
155 | @sp 1 |
156 | Published by the Free Software Foundation @* | |
157 | 59 Temple Place - Suite 330@* | |
158 | Boston, MA 02111-1307, USA@* | |
e5e809f4 | 159 | Last printed April, 1998.@* |
861bb6c1 | 160 | Printed copies are available for $50 each.@* |
e5e809f4 | 161 | ISBN 1-882114-37-X |
861bb6c1 JL |
162 | @sp 1 |
163 | Permission is granted to make and distribute verbatim copies of | |
164 | this manual provided the copyright notice and this permission notice | |
165 | are preserved on all copies. | |
166 | ||
167 | Permission is granted to copy and distribute modified versions of this | |
168 | manual under the conditions for verbatim copying, provided also that the | |
e5e809f4 JL |
169 | sections entitled ``GNU General Public License'' and ``Funding for Free |
170 | Software'' are included exactly as in the original, and provided that | |
171 | the entire resulting derived work is distributed under the terms of a | |
172 | permission notice identical to this one. | |
861bb6c1 JL |
173 | |
174 | Permission is granted to copy and distribute translations of this manual | |
175 | into another language, under the above conditions for modified versions, | |
e5e809f4 JL |
176 | except that the sections entitled ``GNU General Public License'' and |
177 | ``Funding for Free Software'', and this permission notice, may be | |
178 | included in translations approved by the Free Software Foundation | |
179 | instead of in the original English. | |
861bb6c1 JL |
180 | @end titlepage |
181 | @page | |
182 | ||
183 | @ifinfo | |
184 | ||
185 | @node Top, G++ and GCC,, (DIR) | |
186 | @top Introduction | |
187 | @cindex introduction | |
188 | ||
189 | @ifset INTERNALS | |
190 | @ifset USING | |
191 | This manual documents how to run, install and port the GNU | |
192 | compiler, as well as its new features and incompatibilities, and how to | |
f2d76545 | 193 | report bugs. It corresponds to EGCS version 1.0. |
861bb6c1 JL |
194 | @end ifset |
195 | @end ifset | |
196 | ||
197 | @ifclear INTERNALS | |
198 | This manual documents how to run and install the GNU compiler, | |
199 | as well as its new features and incompatibilities, and how to report | |
f2d76545 | 200 | bugs. It corresponds to EGCS version 1.0. |
861bb6c1 JL |
201 | @end ifclear |
202 | @ifclear USING | |
203 | This manual documents how to port the GNU compiler, | |
204 | as well as its new features and incompatibilities, and how to report | |
f2d76545 | 205 | bugs. It corresponds to EGCS version 1.0. |
861bb6c1 JL |
206 | @end ifclear |
207 | ||
208 | @end ifinfo | |
209 | @menu | |
210 | @ifset USING | |
211 | * G++ and GCC:: You can compile C or C++ programs. | |
212 | * Invoking GCC:: Command options supported by @samp{gcc}. | |
213 | * Installation:: How to configure, compile and install GNU CC. | |
214 | * C Extensions:: GNU extensions to the C language family. | |
215 | * C++ Extensions:: GNU extensions to the C++ language. | |
216 | * Gcov:: gcov: a GNU CC test coverage program. | |
217 | * Trouble:: If you have trouble installing GNU CC. | |
218 | * Bugs:: How, why and where to report bugs. | |
219 | * Service:: How to find suppliers of support for GNU CC. | |
220 | * Contributing:: How to contribute to testing and developing GNU CC. | |
221 | * VMS:: Using GNU CC on VMS. | |
222 | @end ifset | |
223 | @ifset INTERNALS | |
224 | * Portability:: Goals of GNU CC's portability features. | |
225 | * Interface:: Function-call interface of GNU CC output. | |
226 | * Passes:: Order of passes, what they do, and what each file is for. | |
227 | * RTL:: The intermediate representation that most passes work on. | |
228 | * Machine Desc:: How to write machine description instruction patterns. | |
229 | * Target Macros:: How to write the machine description C macros. | |
230 | * Config:: Writing the @file{xm-@var{machine}.h} file. | |
231 | * Fragments:: Writing the @file{t-@var{target}} and @file{x-@var{host}} files. | |
232 | @end ifset | |
233 | ||
234 | * Funding:: How to help assure funding for free software. | |
e5e809f4 | 235 | * GNU/Linux:: Linux and the GNU Project |
861bb6c1 JL |
236 | |
237 | * Copying:: GNU General Public License says | |
238 | how you can copy and share GNU CC. | |
239 | * Contributors:: People who have contributed to GNU CC. | |
240 | ||
241 | * Index:: Index of concepts and symbol names. | |
242 | @end menu | |
243 | ||
244 | @ifset USING | |
245 | @node G++ and GCC | |
246 | @chapter Compile C, C++, or Objective C | |
247 | ||
248 | @cindex Objective C | |
249 | The C, C++, and Objective C versions of the compiler are integrated; the | |
250 | GNU C compiler can compile programs written in C, C++, or Objective C. | |
251 | ||
252 | @cindex GCC | |
253 | ``GCC'' is a common shorthand term for the GNU C compiler. This is both | |
254 | the most general name for the compiler, and the name used when the | |
255 | emphasis is on compiling C programs. | |
256 | ||
257 | @cindex C++ | |
258 | @cindex G++ | |
259 | When referring to C++ compilation, it is usual to call the compiler | |
260 | ``G++''. Since there is only one compiler, it is also accurate to call | |
261 | it ``GCC'' no matter what the language context; however, the term | |
262 | ``G++'' is more useful when the emphasis is on compiling C++ programs. | |
263 | ||
264 | We use the name ``GNU CC'' to refer to the compilation system as a | |
265 | whole, and more specifically to the language-independent part of the | |
266 | compiler. For example, we refer to the optimization options as | |
267 | affecting the behavior of ``GNU CC'' or sometimes just ``the compiler''. | |
268 | ||
269 | Front ends for other languages, such as Ada 9X, Fortran, Modula-3, and | |
270 | Pascal, are under development. These front-ends, like that for C++, are | |
271 | built in subdirectories of GNU CC and link to it. The result is an | |
272 | integrated compiler that can compile programs written in C, C++, | |
273 | Objective C, or any of the languages for which you have installed front | |
274 | ends. | |
275 | ||
276 | In this manual, we only discuss the options for the C, Objective-C, and | |
277 | C++ compilers and those of the GNU CC core. Consult the documentation | |
278 | of the other front ends for the options to use when compiling programs | |
279 | written in other languages. | |
280 | ||
281 | @cindex compiler compared to C++ preprocessor | |
282 | @cindex intermediate C version, nonexistent | |
283 | @cindex C intermediate output, nonexistent | |
284 | G++ is a @emph{compiler}, not merely a preprocessor. G++ builds object | |
285 | code directly from your C++ program source. There is no intermediate C | |
286 | version of the program. (By contrast, for example, some other | |
287 | implementations use a program that generates a C program from your C++ | |
288 | source.) Avoiding an intermediate C representation of the program means | |
289 | that you get better object code, and better debugging information. The | |
290 | GNU debugger, GDB, works with this information in the object code to | |
291 | give you comprehensive C++ source-level editing capabilities | |
292 | (@pxref{C,,C and C++,gdb.info, Debugging with GDB}). | |
293 | ||
294 | @c FIXME! Someone who knows something about Objective C ought to put in | |
295 | @c a paragraph or two about it here, and move the index entry down when | |
296 | @c there is more to point to than the general mention in the 1st par. | |
297 | ||
298 | @include invoke.texi | |
299 | ||
300 | @include install.texi | |
301 | ||
302 | @include extend.texi | |
303 | ||
304 | @include gcov.texi | |
305 | ||
306 | @node Trouble | |
307 | @chapter Known Causes of Trouble with GNU CC | |
308 | @cindex bugs, known | |
309 | @cindex installation trouble | |
310 | @cindex known causes of trouble | |
311 | ||
312 | This section describes known problems that affect users of GNU CC. Most | |
313 | of these are not GNU CC bugs per se---if they were, we would fix them. | |
314 | But the result for a user may be like the result of a bug. | |
315 | ||
316 | Some of these problems are due to bugs in other software, some are | |
317 | missing features that are too much work to add, and some are places | |
318 | where people's opinions differ as to what is best. | |
319 | ||
320 | @menu | |
321 | * Actual Bugs:: Bugs we will fix later. | |
322 | * Installation Problems:: Problems that manifest when you install GNU CC. | |
323 | * Cross-Compiler Problems:: Common problems of cross compiling with GNU CC. | |
324 | * Interoperation:: Problems using GNU CC with other compilers, | |
325 | and with certain linkers, assemblers and debuggers. | |
326 | * External Bugs:: Problems compiling certain programs. | |
327 | * Incompatibilities:: GNU CC is incompatible with traditional C. | |
328 | * Fixed Headers:: GNU C uses corrected versions of system header files. | |
329 | This is necessary, but doesn't always work smoothly. | |
330 | * Standard Libraries:: GNU C uses the system C library, which might not be | |
331 | compliant with the ISO/ANSI C standard. | |
332 | * Disappointments:: Regrettable things we can't change, but not quite bugs. | |
333 | * C++ Misunderstandings:: Common misunderstandings with GNU C++. | |
334 | * Protoize Caveats:: Things to watch out for when using @code{protoize}. | |
335 | * Non-bugs:: Things we think are right, but some others disagree. | |
336 | * Warnings and Errors:: Which problems in your code get warnings, | |
337 | and which get errors. | |
338 | @end menu | |
339 | ||
340 | @node Actual Bugs | |
341 | @section Actual Bugs We Haven't Fixed Yet | |
342 | ||
343 | @itemize @bullet | |
344 | @item | |
345 | The @code{fixincludes} script interacts badly with automounters; if the | |
346 | directory of system header files is automounted, it tends to be | |
347 | unmounted while @code{fixincludes} is running. This would seem to be a | |
348 | bug in the automounter. We don't know any good way to work around it. | |
349 | ||
350 | @item | |
351 | The @code{fixproto} script will sometimes add prototypes for the | |
352 | @code{sigsetjmp} and @code{siglongjmp} functions that reference the | |
353 | @code{jmp_buf} type before that type is defined. To work around this, | |
354 | edit the offending file and place the typedef in front of the | |
355 | prototypes. | |
356 | ||
357 | @item | |
358 | There are several obscure case of mis-using struct, union, and | |
359 | enum tags that are not detected as errors by the compiler. | |
360 | ||
361 | @item | |
362 | When @samp{-pedantic-errors} is specified, GNU C will incorrectly give | |
363 | an error message when a function name is specified in an expression | |
364 | involving the comma operator. | |
365 | ||
366 | @item | |
367 | Loop unrolling doesn't work properly for certain C++ programs. This is | |
368 | a bug in the C++ front end. It sometimes emits incorrect debug info, and | |
369 | the loop unrolling code is unable to recover from this error. | |
370 | @end itemize | |
371 | ||
372 | @node Installation Problems | |
373 | @section Installation Problems | |
374 | ||
375 | This is a list of problems (and some apparent problems which don't | |
376 | really mean anything is wrong) that show up during installation of GNU | |
377 | CC. | |
378 | ||
379 | @itemize @bullet | |
380 | @item | |
381 | On certain systems, defining certain environment variables such as | |
382 | @code{CC} can interfere with the functioning of @code{make}. | |
383 | ||
384 | @item | |
385 | If you encounter seemingly strange errors when trying to build the | |
386 | compiler in a directory other than the source directory, it could be | |
387 | because you have previously configured the compiler in the source | |
388 | directory. Make sure you have done all the necessary preparations. | |
389 | @xref{Other Dir}. | |
390 | ||
391 | @item | |
392 | If you build GNU CC on a BSD system using a directory stored in a System | |
393 | V file system, problems may occur in running @code{fixincludes} if the | |
394 | System V file system doesn't support symbolic links. These problems | |
395 | result in a failure to fix the declaration of @code{size_t} in | |
396 | @file{sys/types.h}. If you find that @code{size_t} is a signed type and | |
397 | that type mismatches occur, this could be the cause. | |
398 | ||
399 | The solution is not to use such a directory for building GNU CC. | |
400 | ||
401 | @item | |
402 | In previous versions of GNU CC, the @code{gcc} driver program looked for | |
403 | @code{as} and @code{ld} in various places; for example, in files | |
404 | beginning with @file{/usr/local/lib/gcc-}. GNU CC version 2 looks for | |
405 | them in the directory | |
406 | @file{/usr/local/lib/gcc-lib/@var{target}/@var{version}}. | |
407 | ||
408 | Thus, to use a version of @code{as} or @code{ld} that is not the system | |
409 | default, for example @code{gas} or GNU @code{ld}, you must put them in | |
410 | that directory (or make links to them from that directory). | |
411 | ||
412 | @item | |
413 | Some commands executed when making the compiler may fail (return a | |
414 | non-zero status) and be ignored by @code{make}. These failures, which | |
415 | are often due to files that were not found, are expected, and can safely | |
416 | be ignored. | |
417 | ||
418 | @item | |
419 | It is normal to have warnings in compiling certain files about | |
420 | unreachable code and about enumeration type clashes. These files' names | |
421 | begin with @samp{insn-}. Also, @file{real.c} may get some warnings that | |
422 | you can ignore. | |
423 | ||
424 | @item | |
425 | Sometimes @code{make} recompiles parts of the compiler when installing | |
426 | the compiler. In one case, this was traced down to a bug in | |
427 | @code{make}. Either ignore the problem or switch to GNU Make. | |
428 | ||
429 | @item | |
430 | If you have installed a program known as purify, you may find that it | |
431 | causes errors while linking @code{enquire}, which is part of building | |
432 | GNU CC. The fix is to get rid of the file @code{real-ld} which purify | |
433 | installs---so that GNU CC won't try to use it. | |
434 | ||
435 | @item | |
956d6950 | 436 | On GNU/Linux SLS 1.01, there is a problem with @file{libc.a}: it does not |
861bb6c1 JL |
437 | contain the obstack functions. However, GNU CC assumes that the obstack |
438 | functions are in @file{libc.a} when it is the GNU C library. To work | |
439 | around this problem, change the @code{__GNU_LIBRARY__} conditional | |
440 | around line 31 to @samp{#if 1}. | |
441 | ||
442 | @item | |
443 | On some 386 systems, building the compiler never finishes because | |
444 | @code{enquire} hangs due to a hardware problem in the motherboard---it | |
445 | reports floating point exceptions to the kernel incorrectly. You can | |
446 | install GNU CC except for @file{float.h} by patching out the command to | |
447 | run @code{enquire}. You may also be able to fix the problem for real by | |
448 | getting a replacement motherboard. This problem was observed in | |
449 | Revision E of the Micronics motherboard, and is fixed in Revision F. | |
450 | It has also been observed in the MYLEX MXA-33 motherboard. | |
451 | ||
452 | If you encounter this problem, you may also want to consider removing | |
453 | the FPU from the socket during the compilation. Alternatively, if you | |
454 | are running SCO Unix, you can reboot and force the FPU to be ignored. | |
455 | To do this, type @samp{hd(40)unix auto ignorefpu}. | |
456 | ||
457 | @item | |
458 | On some 386 systems, GNU CC crashes trying to compile @file{enquire.c}. | |
459 | This happens on machines that don't have a 387 FPU chip. On 386 | |
460 | machines, the system kernel is supposed to emulate the 387 when you | |
461 | don't have one. The crash is due to a bug in the emulator. | |
462 | ||
463 | One of these systems is the Unix from Interactive Systems: 386/ix. | |
464 | On this system, an alternate emulator is provided, and it does work. | |
465 | To use it, execute this command as super-user: | |
466 | ||
467 | @example | |
468 | ln /etc/emulator.rel1 /etc/emulator | |
469 | @end example | |
470 | ||
471 | @noindent | |
472 | and then reboot the system. (The default emulator file remains present | |
473 | under the name @file{emulator.dflt}.) | |
474 | ||
475 | Try using @file{/etc/emulator.att}, if you have such a problem on the | |
476 | SCO system. | |
477 | ||
478 | Another system which has this problem is Esix. We don't know whether it | |
479 | has an alternate emulator that works. | |
480 | ||
481 | On NetBSD 0.8, a similar problem manifests itself as these error messages: | |
482 | ||
483 | @example | |
484 | enquire.c: In function `fprop': | |
485 | enquire.c:2328: floating overflow | |
486 | @end example | |
487 | ||
488 | @item | |
489 | On SCO systems, when compiling GNU CC with the system's compiler, | |
490 | do not use @samp{-O}. Some versions of the system's compiler miscompile | |
491 | GNU CC with @samp{-O}. | |
492 | ||
493 | @cindex @code{genflags}, crash on Sun 4 | |
494 | @item | |
495 | Sometimes on a Sun 4 you may observe a crash in the program | |
496 | @code{genflags} or @code{genoutput} while building GNU CC. This is said to | |
497 | be due to a bug in @code{sh}. You can probably get around it by running | |
498 | @code{genflags} or @code{genoutput} manually and then retrying the | |
499 | @code{make}. | |
500 | ||
501 | @item | |
502 | On Solaris 2, executables of GNU CC version 2.0.2 are commonly | |
503 | available, but they have a bug that shows up when compiling current | |
504 | versions of GNU CC: undefined symbol errors occur during assembly if you | |
505 | use @samp{-g}. | |
506 | ||
507 | The solution is to compile the current version of GNU CC without | |
508 | @samp{-g}. That makes a working compiler which you can use to recompile | |
509 | with @samp{-g}. | |
510 | ||
511 | @item | |
512 | Solaris 2 comes with a number of optional OS packages. Some of these | |
513 | packages are needed to use GNU CC fully. If you did not install all | |
514 | optional packages when installing Solaris, you will need to verify that | |
515 | the packages that GNU CC needs are installed. | |
516 | ||
517 | To check whether an optional package is installed, use | |
518 | the @code{pkginfo} command. To add an optional package, use the | |
519 | @code{pkgadd} command. For further details, see the Solaris | |
520 | documentation. | |
521 | ||
522 | For Solaris 2.0 and 2.1, GNU CC needs six packages: @samp{SUNWarc}, | |
523 | @samp{SUNWbtool}, @samp{SUNWesu}, @samp{SUNWhea}, @samp{SUNWlibm}, and | |
524 | @samp{SUNWtoo}. | |
525 | ||
526 | For Solaris 2.2, GNU CC needs an additional seventh package: @samp{SUNWsprot}. | |
527 | ||
528 | @item | |
529 | On Solaris 2, trying to use the linker and other tools in | |
530 | @file{/usr/ucb} to install GNU CC has been observed to cause trouble. | |
531 | For example, the linker may hang indefinitely. The fix is to remove | |
532 | @file{/usr/ucb} from your @code{PATH}. | |
533 | ||
534 | @item | |
535 | If you use the 1.31 version of the MIPS assembler (such as was shipped | |
536 | with Ultrix 3.1), you will need to use the -fno-delayed-branch switch | |
537 | when optimizing floating point code. Otherwise, the assembler will | |
538 | complain when the GCC compiler fills a branch delay slot with a | |
539 | floating point instruction, such as @code{add.d}. | |
540 | ||
541 | @item | |
542 | If on a MIPS system you get an error message saying ``does not have gp | |
543 | sections for all it's [sic] sectons [sic]'', don't worry about it. This | |
544 | happens whenever you use GAS with the MIPS linker, but there is not | |
545 | really anything wrong, and it is okay to use the output file. You can | |
546 | stop such warnings by installing the GNU linker. | |
547 | ||
548 | It would be nice to extend GAS to produce the gp tables, but they are | |
549 | optional, and there should not be a warning about their absence. | |
550 | ||
551 | @item | |
552 | In Ultrix 4.0 on the MIPS machine, @file{stdio.h} does not work with GNU | |
553 | CC at all unless it has been fixed with @code{fixincludes}. This causes | |
554 | problems in building GNU CC. Once GNU CC is installed, the problems go | |
555 | away. | |
556 | ||
557 | To work around this problem, when making the stage 1 compiler, specify | |
558 | this option to Make: | |
559 | ||
560 | @example | |
561 | GCC_FOR_TARGET="./xgcc -B./ -I./include" | |
562 | @end example | |
563 | ||
564 | When making stage 2 and stage 3, specify this option: | |
565 | ||
566 | @example | |
567 | CFLAGS="-g -I./include" | |
568 | @end example | |
569 | ||
570 | @item | |
571 | Users have reported some problems with version 2.0 of the MIPS | |
572 | compiler tools that were shipped with Ultrix 4.1. Version 2.10 | |
573 | which came with Ultrix 4.2 seems to work fine. | |
574 | ||
575 | Users have also reported some problems with version 2.20 of the | |
576 | MIPS compiler tools that were shipped with RISC/os 4.x. The earlier | |
577 | version 2.11 seems to work fine. | |
578 | ||
579 | @item | |
580 | Some versions of the MIPS linker will issue an assertion failure | |
581 | when linking code that uses @code{alloca} against shared | |
582 | libraries on RISC-OS 5.0, and DEC's OSF/1 systems. This is a bug | |
583 | in the linker, that is supposed to be fixed in future revisions. | |
584 | To protect against this, GNU CC passes @samp{-non_shared} to the | |
585 | linker unless you pass an explicit @samp{-shared} or | |
586 | @samp{-call_shared} switch. | |
587 | ||
588 | @item | |
589 | On System V release 3, you may get this error message | |
590 | while linking: | |
591 | ||
592 | @smallexample | |
593 | ld fatal: failed to write symbol name @var{something} | |
594 | in strings table for file @var{whatever} | |
595 | @end smallexample | |
596 | ||
597 | This probably indicates that the disk is full or your ULIMIT won't allow | |
598 | the file to be as large as it needs to be. | |
599 | ||
600 | This problem can also result because the kernel parameter @code{MAXUMEM} | |
601 | is too small. If so, you must regenerate the kernel and make the value | |
602 | much larger. The default value is reported to be 1024; a value of 32768 | |
603 | is said to work. Smaller values may also work. | |
604 | ||
605 | @item | |
606 | On System V, if you get an error like this, | |
607 | ||
608 | @example | |
609 | /usr/local/lib/bison.simple: In function `yyparse': | |
610 | /usr/local/lib/bison.simple:625: virtual memory exhausted | |
611 | @end example | |
612 | ||
613 | @noindent | |
614 | that too indicates a problem with disk space, ULIMIT, or @code{MAXUMEM}. | |
615 | ||
616 | @item | |
617 | Current GNU CC versions probably do not work on version 2 of the NeXT | |
618 | operating system. | |
619 | ||
620 | @item | |
621 | On NeXTStep 3.0, the Objective C compiler does not work, due, | |
622 | apparently, to a kernel bug that it happens to trigger. This problem | |
623 | does not happen on 3.1. | |
624 | ||
625 | @item | |
626 | On the Tower models 4@var{n}0 and 6@var{n}0, by default a process is not | |
627 | allowed to have more than one megabyte of memory. GNU CC cannot compile | |
628 | itself (or many other programs) with @samp{-O} in that much memory. | |
629 | ||
630 | To solve this problem, reconfigure the kernel adding the following line | |
631 | to the configuration file: | |
632 | ||
633 | @smallexample | |
634 | MAXUMEM = 4096 | |
635 | @end smallexample | |
636 | ||
637 | @item | |
638 | On HP 9000 series 300 or 400 running HP-UX release 8.0, there is a bug | |
639 | in the assembler that must be fixed before GNU CC can be built. This | |
640 | bug manifests itself during the first stage of compilation, while | |
641 | building @file{libgcc2.a}: | |
642 | ||
643 | @smallexample | |
644 | _floatdisf | |
645 | cc1: warning: `-g' option not supported on this version of GCC | |
646 | cc1: warning: `-g1' option not supported on this version of GCC | |
647 | ./xgcc: Internal compiler error: program as got fatal signal 11 | |
648 | @end smallexample | |
649 | ||
650 | A patched version of the assembler is available by anonymous ftp from | |
651 | @code{altdorf.ai.mit.edu} as the file | |
652 | @file{archive/cph/hpux-8.0-assembler}. If you have HP software support, | |
653 | the patch can also be obtained directly from HP, as described in the | |
654 | following note: | |
655 | ||
656 | @quotation | |
657 | This is the patched assembler, to patch SR#1653-010439, where the | |
658 | assembler aborts on floating point constants. | |
659 | ||
660 | The bug is not really in the assembler, but in the shared library | |
661 | version of the function ``cvtnum(3c)''. The bug on ``cvtnum(3c)'' is | |
662 | SR#4701-078451. Anyway, the attached assembler uses the archive | |
663 | library version of ``cvtnum(3c)'' and thus does not exhibit the bug. | |
664 | @end quotation | |
665 | ||
666 | This patch is also known as PHCO_4484. | |
667 | ||
668 | @item | |
669 | On HP-UX version 8.05, but not on 8.07 or more recent versions, | |
670 | the @code{fixproto} shell script triggers a bug in the system shell. | |
671 | If you encounter this problem, upgrade your operating system or | |
672 | use BASH (the GNU shell) to run @code{fixproto}. | |
673 | ||
674 | @item | |
675 | Some versions of the Pyramid C compiler are reported to be unable to | |
676 | compile GNU CC. You must use an older version of GNU CC for | |
677 | bootstrapping. One indication of this problem is if you get a crash | |
678 | when GNU CC compiles the function @code{muldi3} in file @file{libgcc2.c}. | |
679 | ||
680 | You may be able to succeed by getting GNU CC version 1, installing it, | |
681 | and using it to compile GNU CC version 2. The bug in the Pyramid C | |
682 | compiler does not seem to affect GNU CC version 1. | |
683 | ||
684 | @item | |
685 | There may be similar problems on System V Release 3.1 on 386 systems. | |
686 | ||
687 | @item | |
688 | On the Intel Paragon (an i860 machine), if you are using operating | |
689 | system version 1.0, you will get warnings or errors about redefinition | |
690 | of @code{va_arg} when you build GNU CC. | |
691 | ||
692 | If this happens, then you need to link most programs with the library | |
693 | @file{iclib.a}. You must also modify @file{stdio.h} as follows: before | |
694 | the lines | |
695 | ||
696 | @example | |
697 | #if defined(__i860__) && !defined(_VA_LIST) | |
698 | #include <va_list.h> | |
699 | @end example | |
700 | ||
701 | @noindent | |
702 | insert the line | |
703 | ||
704 | @example | |
705 | #if __PGC__ | |
706 | @end example | |
707 | ||
708 | @noindent | |
709 | and after the lines | |
710 | ||
711 | @example | |
712 | extern int vprintf(const char *, va_list ); | |
713 | extern int vsprintf(char *, const char *, va_list ); | |
714 | #endif | |
715 | @end example | |
716 | ||
717 | @noindent | |
718 | insert the line | |
719 | ||
720 | @example | |
721 | #endif /* __PGC__ */ | |
722 | @end example | |
723 | ||
724 | These problems don't exist in operating system version 1.1. | |
725 | ||
726 | @item | |
727 | On the Altos 3068, programs compiled with GNU CC won't work unless you | |
728 | fix a kernel bug. This happens using system versions V.2.2 1.0gT1 and | |
729 | V.2.2 1.0e and perhaps later versions as well. See the file | |
730 | @file{README.ALTOS}. | |
731 | ||
732 | @item | |
733 | You will get several sorts of compilation and linking errors on the | |
734 | we32k if you don't follow the special instructions. @xref{Configurations}. | |
735 | ||
736 | @item | |
737 | A bug in the HP-UX 8.05 (and earlier) shell will cause the fixproto | |
738 | program to report an error of the form: | |
739 | ||
740 | @example | |
741 | ./fixproto: sh internal 1K buffer overflow | |
742 | @end example | |
743 | ||
744 | To fix this, change the first line of the fixproto script to look like: | |
745 | ||
746 | @example | |
747 | #!/bin/ksh | |
748 | @end example | |
749 | @end itemize | |
750 | ||
751 | @node Cross-Compiler Problems | |
752 | @section Cross-Compiler Problems | |
753 | ||
754 | You may run into problems with cross compilation on certain machines, | |
755 | for several reasons. | |
756 | ||
757 | @itemize @bullet | |
758 | @item | |
759 | Cross compilation can run into trouble for certain machines because | |
760 | some target machines' assemblers require floating point numbers to be | |
761 | written as @emph{integer} constants in certain contexts. | |
762 | ||
763 | The compiler writes these integer constants by examining the floating | |
764 | point value as an integer and printing that integer, because this is | |
765 | simple to write and independent of the details of the floating point | |
766 | representation. But this does not work if the compiler is running on | |
767 | a different machine with an incompatible floating point format, or | |
768 | even a different byte-ordering. | |
769 | ||
770 | In addition, correct constant folding of floating point values | |
771 | requires representing them in the target machine's format. | |
772 | (The C standard does not quite require this, but in practice | |
773 | it is the only way to win.) | |
774 | ||
775 | It is now possible to overcome these problems by defining macros such | |
776 | as @code{REAL_VALUE_TYPE}. But doing so is a substantial amount of | |
777 | work for each target machine. | |
778 | @ifset INTERNALS | |
779 | @xref{Cross-compilation}. | |
780 | @end ifset | |
781 | @ifclear INTERNALS | |
782 | @xref{Cross-compilation,,Cross Compilation and Floating Point Format, | |
783 | gcc.info, Using and Porting GCC}. | |
784 | @end ifclear | |
785 | ||
786 | @item | |
787 | At present, the program @file{mips-tfile} which adds debug | |
788 | support to object files on MIPS systems does not work in a cross | |
789 | compile environment. | |
790 | @end itemize | |
791 | ||
792 | @node Interoperation | |
793 | @section Interoperation | |
794 | ||
795 | This section lists various difficulties encountered in using GNU C or | |
796 | GNU C++ together with other compilers or with the assemblers, linkers, | |
797 | libraries and debuggers on certain systems. | |
798 | ||
799 | @itemize @bullet | |
800 | @item | |
801 | Objective C does not work on the RS/6000. | |
802 | ||
803 | @item | |
804 | GNU C++ does not do name mangling in the same way as other C++ | |
805 | compilers. This means that object files compiled with one compiler | |
806 | cannot be used with another. | |
807 | ||
808 | This effect is intentional, to protect you from more subtle problems. | |
809 | Compilers differ as to many internal details of C++ implementation, | |
810 | including: how class instances are laid out, how multiple inheritance is | |
811 | implemented, and how virtual function calls are handled. If the name | |
812 | encoding were made the same, your programs would link against libraries | |
813 | provided from other compilers---but the programs would then crash when | |
814 | run. Incompatible libraries are then detected at link time, rather than | |
815 | at run time. | |
816 | ||
817 | @item | |
818 | Older GDB versions sometimes fail to read the output of GNU CC version | |
819 | 2. If you have trouble, get GDB version 4.4 or later. | |
820 | ||
821 | @item | |
822 | @cindex DBX | |
823 | DBX rejects some files produced by GNU CC, though it accepts similar | |
824 | constructs in output from PCC. Until someone can supply a coherent | |
825 | description of what is valid DBX input and what is not, there is | |
826 | nothing I can do about these problems. You are on your own. | |
827 | ||
828 | @item | |
829 | The GNU assembler (GAS) does not support PIC. To generate PIC code, you | |
830 | must use some other assembler, such as @file{/bin/as}. | |
831 | ||
832 | @item | |
833 | On some BSD systems, including some versions of Ultrix, use of profiling | |
834 | causes static variable destructors (currently used only in C++) not to | |
835 | be run. | |
836 | ||
837 | @item | |
838 | Use of @samp{-I/usr/include} may cause trouble. | |
839 | ||
840 | Many systems come with header files that won't work with GNU CC unless | |
841 | corrected by @code{fixincludes}. The corrected header files go in a new | |
842 | directory; GNU CC searches this directory before @file{/usr/include}. | |
843 | If you use @samp{-I/usr/include}, this tells GNU CC to search | |
844 | @file{/usr/include} earlier on, before the corrected headers. The | |
845 | result is that you get the uncorrected header files. | |
846 | ||
847 | Instead, you should use these options (when compiling C programs): | |
848 | ||
849 | @smallexample | |
850 | -I/usr/local/lib/gcc-lib/@var{target}/@var{version}/include -I/usr/include | |
851 | @end smallexample | |
852 | ||
853 | For C++ programs, GNU CC also uses a special directory that defines C++ | |
854 | interfaces to standard C subroutines. This directory is meant to be | |
855 | searched @emph{before} other standard include directories, so that it | |
856 | takes precedence. If you are compiling C++ programs and specifying | |
857 | include directories explicitly, use this option first, then the two | |
858 | options above: | |
859 | ||
860 | @example | |
861 | -I/usr/local/lib/g++-include | |
862 | @end example | |
863 | ||
864 | @ignore | |
865 | @cindex @code{vfork}, for the Sun-4 | |
866 | @item | |
867 | There is a bug in @code{vfork} on the Sun-4 which causes the registers | |
868 | of the child process to clobber those of the parent. Because of this, | |
869 | programs that call @code{vfork} are likely to lose when compiled | |
870 | optimized with GNU CC when the child code alters registers which contain | |
871 | C variables in the parent. This affects variables which are live in the | |
872 | parent across the call to @code{vfork}. | |
873 | ||
874 | If you encounter this, you can work around the problem by declaring | |
875 | variables @code{volatile} in the function that calls @code{vfork}, until | |
876 | the problem goes away, or by not declaring them @code{register} and not | |
877 | using @samp{-O} for those source files. | |
878 | @end ignore | |
879 | ||
880 | @item | |
881 | On some SGI systems, when you use @samp{-lgl_s} as an option, | |
882 | it gets translated magically to @samp{-lgl_s -lX11_s -lc_s}. | |
883 | Naturally, this does not happen when you use GNU CC. | |
884 | You must specify all three options explicitly. | |
885 | ||
886 | @item | |
887 | On a Sparc, GNU CC aligns all values of type @code{double} on an 8-byte | |
888 | boundary, and it expects every @code{double} to be so aligned. The Sun | |
889 | compiler usually gives @code{double} values 8-byte alignment, with one | |
890 | exception: function arguments of type @code{double} may not be aligned. | |
891 | ||
892 | As a result, if a function compiled with Sun CC takes the address of an | |
893 | argument of type @code{double} and passes this pointer of type | |
894 | @code{double *} to a function compiled with GNU CC, dereferencing the | |
895 | pointer may cause a fatal signal. | |
896 | ||
897 | One way to solve this problem is to compile your entire program with GNU | |
898 | CC. Another solution is to modify the function that is compiled with | |
899 | Sun CC to copy the argument into a local variable; local variables | |
900 | are always properly aligned. A third solution is to modify the function | |
901 | that uses the pointer to dereference it via the following function | |
902 | @code{access_double} instead of directly with @samp{*}: | |
903 | ||
904 | @smallexample | |
905 | inline double | |
906 | access_double (double *unaligned_ptr) | |
907 | @{ | |
908 | union d2i @{ double d; int i[2]; @}; | |
909 | ||
910 | union d2i *p = (union d2i *) unaligned_ptr; | |
911 | union d2i u; | |
912 | ||
913 | u.i[0] = p->i[0]; | |
914 | u.i[1] = p->i[1]; | |
915 | ||
916 | return u.d; | |
917 | @} | |
918 | @end smallexample | |
919 | ||
920 | @noindent | |
921 | Storing into the pointer can be done likewise with the same union. | |
922 | ||
923 | @item | |
924 | On Solaris, the @code{malloc} function in the @file{libmalloc.a} library | |
925 | may allocate memory that is only 4 byte aligned. Since GNU CC on the | |
926 | Sparc assumes that doubles are 8 byte aligned, this may result in a | |
927 | fatal signal if doubles are stored in memory allocated by the | |
928 | @file{libmalloc.a} library. | |
929 | ||
930 | The solution is to not use the @file{libmalloc.a} library. Use instead | |
931 | @code{malloc} and related functions from @file{libc.a}; they do not have | |
932 | this problem. | |
933 | ||
934 | @item | |
935 | Sun forgot to include a static version of @file{libdl.a} with some | |
936 | versions of SunOS (mainly 4.1). This results in undefined symbols when | |
937 | linking static binaries (that is, if you use @samp{-static}). If you | |
938 | see undefined symbols @code{_dlclose}, @code{_dlsym} or @code{_dlopen} | |
939 | when linking, compile and link against the file | |
940 | @file{mit/util/misc/dlsym.c} from the MIT version of X windows. | |
941 | ||
942 | @item | |
943 | The 128-bit long double format that the Sparc port supports currently | |
944 | works by using the architecturally defined quad-word floating point | |
945 | instructions. Since there is no hardware that supports these | |
946 | instructions they must be emulated by the operating system. Long | |
947 | doubles do not work in Sun OS versions 4.0.3 and earlier, because the | |
948 | kernel emulator uses an obsolete and incompatible format. Long doubles | |
949 | do not work in Sun OS version 4.1.1 due to a problem in a Sun library. | |
950 | Long doubles do work on Sun OS versions 4.1.2 and higher, but GNU CC | |
951 | does not enable them by default. Long doubles appear to work in Sun OS | |
952 | 5.x (Solaris 2.x). | |
953 | ||
954 | @item | |
955 | On HP-UX version 9.01 on the HP PA, the HP compiler @code{cc} does not | |
956 | compile GNU CC correctly. We do not yet know why. However, GNU CC | |
957 | compiled on earlier HP-UX versions works properly on HP-UX 9.01 and can | |
958 | compile itself properly on 9.01. | |
959 | ||
960 | @item | |
961 | On the HP PA machine, ADB sometimes fails to work on functions compiled | |
962 | with GNU CC. Specifically, it fails to work on functions that use | |
963 | @code{alloca} or variable-size arrays. This is because GNU CC doesn't | |
964 | generate HP-UX unwind descriptors for such functions. It may even be | |
965 | impossible to generate them. | |
966 | ||
967 | @item | |
968 | Debugging (@samp{-g}) is not supported on the HP PA machine, unless you use | |
969 | the preliminary GNU tools (@pxref{Installation}). | |
970 | ||
971 | @item | |
972 | Taking the address of a label may generate errors from the HP-UX | |
973 | PA assembler. GAS for the PA does not have this problem. | |
974 | ||
975 | @item | |
976 | Using floating point parameters for indirect calls to static functions | |
977 | will not work when using the HP assembler. There simply is no way for GCC | |
978 | to specify what registers hold arguments for static functions when using | |
979 | the HP assembler. GAS for the PA does not have this problem. | |
980 | ||
981 | @item | |
982 | In extremely rare cases involving some very large functions you may | |
983 | receive errors from the HP linker complaining about an out of bounds | |
984 | unconditional branch offset. This used to occur more often in previous | |
985 | versions of GNU CC, but is now exceptionally rare. If you should run | |
986 | into it, you can work around by making your function smaller. | |
987 | ||
988 | @item | |
989 | GNU CC compiled code sometimes emits warnings from the HP-UX assembler of | |
990 | the form: | |
991 | ||
992 | @smallexample | |
993 | (warning) Use of GR3 when | |
994 | frame >= 8192 may cause conflict. | |
995 | @end smallexample | |
996 | ||
997 | These warnings are harmless and can be safely ignored. | |
998 | ||
999 | @item | |
1000 | The current version of the assembler (@file{/bin/as}) for the RS/6000 | |
1001 | has certain problems that prevent the @samp{-g} option in GCC from | |
1002 | working. Note that @file{Makefile.in} uses @samp{-g} by default when | |
1003 | compiling @file{libgcc2.c}. | |
1004 | ||
1005 | IBM has produced a fixed version of the assembler. The upgraded | |
1006 | assembler unfortunately was not included in any of the AIX 3.2 update | |
1007 | PTF releases (3.2.2, 3.2.3, or 3.2.3e). Users of AIX 3.1 should request | |
1008 | PTF U403044 from IBM and users of AIX 3.2 should request PTF U416277. | |
1009 | See the file @file{README.RS6000} for more details on these updates. | |
1010 | ||
1011 | You can test for the presense of a fixed assembler by using the | |
1012 | command | |
1013 | ||
1014 | @smallexample | |
1015 | as -u < /dev/null | |
1016 | @end smallexample | |
1017 | ||
1018 | @noindent | |
1019 | If the command exits normally, the assembler fix already is installed. | |
1020 | If the assembler complains that "-u" is an unknown flag, you need to | |
1021 | order the fix. | |
1022 | ||
1023 | @item | |
1024 | On the IBM RS/6000, compiling code of the form | |
1025 | ||
1026 | @smallexample | |
1027 | extern int foo; | |
1028 | ||
1029 | @dots{} foo @dots{} | |
1030 | ||
1031 | static int foo; | |
1032 | @end smallexample | |
1033 | ||
1034 | @noindent | |
1035 | will cause the linker to report an undefined symbol @code{foo}. | |
1036 | Although this behavior differs from most other systems, it is not a | |
1037 | bug because redefining an @code{extern} variable as @code{static} | |
1038 | is undefined in ANSI C. | |
1039 | ||
1040 | @item | |
1041 | AIX on the RS/6000 provides support (NLS) for environments outside of | |
1042 | the United States. Compilers and assemblers use NLS to support | |
1043 | locale-specific representations of various objects including | |
1044 | floating-point numbers ("." vs "," for separating decimal fractions). | |
1045 | There have been problems reported where the library linked with GCC does | |
1046 | not produce the same floating-point formats that the assembler accepts. | |
1047 | If you have this problem, set the LANG environment variable to "C" or | |
1048 | "En_US". | |
1049 | ||
1050 | @item | |
1051 | Even if you specify @samp{-fdollars-in-identifiers}, | |
1052 | you cannot successfully use @samp{$} in identifiers on the RS/6000 due | |
1053 | to a restriction in the IBM assembler. GAS supports these | |
1054 | identifiers. | |
1055 | ||
1056 | @item | |
1057 | On the RS/6000, XLC version 1.3.0.0 will miscompile @file{jump.c}. XLC | |
1058 | version 1.3.0.1 or later fixes this problem. You can obtain XLC-1.3.0.2 | |
1059 | by requesting PTF 421749 from IBM. | |
1060 | ||
1061 | @item | |
1062 | There is an assembler bug in versions of DG/UX prior to 5.4.2.01 that | |
1063 | occurs when the @samp{fldcr} instruction is used. GNU CC uses | |
1064 | @samp{fldcr} on the 88100 to serialize volatile memory references. Use | |
1065 | the option @samp{-mno-serialize-volatile} if your version of the | |
1066 | assembler has this bug. | |
1067 | ||
1068 | @item | |
1069 | On VMS, GAS versions 1.38.1 and earlier may cause spurious warning | |
1070 | messages from the linker. These warning messages complain of mismatched | |
1071 | psect attributes. You can ignore them. @xref{VMS Install}. | |
1072 | ||
1073 | @item | |
1074 | On NewsOS version 3, if you include both of the files @file{stddef.h} | |
1075 | and @file{sys/types.h}, you get an error because there are two typedefs | |
1076 | of @code{size_t}. You should change @file{sys/types.h} by adding these | |
1077 | lines around the definition of @code{size_t}: | |
1078 | ||
1079 | @smallexample | |
1080 | #ifndef _SIZE_T | |
1081 | #define _SIZE_T | |
1082 | @var{actual typedef here} | |
1083 | #endif | |
1084 | @end smallexample | |
1085 | ||
1086 | @cindex Alliant | |
1087 | @item | |
1088 | On the Alliant, the system's own convention for returning structures | |
1089 | and unions is unusual, and is not compatible with GNU CC no matter | |
1090 | what options are used. | |
1091 | ||
1092 | @cindex RT PC | |
1093 | @cindex IBM RT PC | |
1094 | @item | |
1095 | On the IBM RT PC, the MetaWare HighC compiler (hc) uses a different | |
1096 | convention for structure and union returning. Use the option | |
1097 | @samp{-mhc-struct-return} to tell GNU CC to use a convention compatible | |
1098 | with it. | |
1099 | ||
1100 | @cindex Vax calling convention | |
1101 | @cindex Ultrix calling convention | |
1102 | @item | |
1103 | On Ultrix, the Fortran compiler expects registers 2 through 5 to be saved | |
1104 | by function calls. However, the C compiler uses conventions compatible | |
1105 | with BSD Unix: registers 2 through 5 may be clobbered by function calls. | |
1106 | ||
1107 | GNU CC uses the same convention as the Ultrix C compiler. You can use | |
1108 | these options to produce code compatible with the Fortran compiler: | |
1109 | ||
1110 | @smallexample | |
1111 | -fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5 | |
1112 | @end smallexample | |
1113 | ||
1114 | @item | |
1115 | On the WE32k, you may find that programs compiled with GNU CC do not | |
1116 | work with the standard shared C library. You may need to link with | |
1117 | the ordinary C compiler. If you do so, you must specify the following | |
1118 | options: | |
1119 | ||
1120 | @smallexample | |
e5e809f4 | 1121 | -L/usr/local/lib/gcc-lib/we32k-att-sysv/2.8.1 -lgcc -lc_s |
861bb6c1 JL |
1122 | @end smallexample |
1123 | ||
1124 | The first specifies where to find the library @file{libgcc.a} | |
1125 | specified with the @samp{-lgcc} option. | |
1126 | ||
1127 | GNU CC does linking by invoking @code{ld}, just as @code{cc} does, and | |
1128 | there is no reason why it @emph{should} matter which compilation program | |
1129 | you use to invoke @code{ld}. If someone tracks this problem down, | |
1130 | it can probably be fixed easily. | |
1131 | ||
1132 | @item | |
1133 | On the Alpha, you may get assembler errors about invalid syntax as a | |
1134 | result of floating point constants. This is due to a bug in the C | |
1135 | library functions @code{ecvt}, @code{fcvt} and @code{gcvt}. Given valid | |
1136 | floating point numbers, they sometimes print @samp{NaN}. | |
1137 | ||
1138 | @item | |
1139 | On Irix 4.0.5F (and perhaps in some other versions), an assembler bug | |
1140 | sometimes reorders instructions incorrectly when optimization is turned | |
1141 | on. If you think this may be happening to you, try using the GNU | |
1142 | assembler; GAS version 2.1 supports ECOFF on Irix. | |
1143 | ||
1144 | Or use the @samp{-noasmopt} option when you compile GNU CC with itself, | |
1145 | and then again when you compile your program. (This is a temporary | |
1146 | kludge to turn off assembler optimization on Irix.) If this proves to | |
1147 | be what you need, edit the assembler spec in the file @file{specs} so | |
1148 | that it unconditionally passes @samp{-O0} to the assembler, and never | |
1149 | passes @samp{-O2} or @samp{-O3}. | |
1150 | @end itemize | |
1151 | ||
1152 | @node External Bugs | |
1153 | @section Problems Compiling Certain Programs | |
1154 | ||
1155 | @c prevent bad page break with this line | |
1156 | Certain programs have problems compiling. | |
1157 | ||
1158 | @itemize @bullet | |
1159 | @item | |
1160 | Parse errors may occur compiling X11 on a Decstation running Ultrix 4.2 | |
1161 | because of problems in DEC's versions of the X11 header files | |
1162 | @file{X11/Xlib.h} and @file{X11/Xutil.h}. People recommend adding | |
1163 | @samp{-I/usr/include/mit} to use the MIT versions of the header files, | |
1164 | using the @samp{-traditional} switch to turn off ANSI C, or fixing the | |
1165 | header files by adding this: | |
1166 | ||
1167 | @example | |
1168 | #ifdef __STDC__ | |
1169 | #define NeedFunctionPrototypes 0 | |
1170 | #endif | |
1171 | @end example | |
1172 | ||
1173 | @item | |
1174 | If you have trouble compiling Perl on a SunOS 4 system, it may be | |
1175 | because Perl specifies @samp{-I/usr/ucbinclude}. This accesses the | |
1176 | unfixed header files. Perl specifies the options | |
1177 | ||
1178 | @example | |
1179 | -traditional -Dvolatile=__volatile__ | |
1180 | -I/usr/include/sun -I/usr/ucbinclude | |
1181 | -fpcc-struct-return | |
1182 | @end example | |
1183 | ||
1184 | @noindent | |
1185 | most of which are unnecessary with GCC 2.4.5 and newer versions. You | |
1186 | can make a properly working Perl by setting @code{ccflags} to | |
1187 | @samp{-fwritable-strings} (implied by the @samp{-traditional} in the | |
1188 | original options) and @code{cppflags} to empty in @file{config.sh}, then | |
1189 | typing @samp{./doSH; make depend; make}. | |
1190 | ||
1191 | @item | |
1192 | On various 386 Unix systems derived from System V, including SCO, ISC, | |
1193 | and ESIX, you may get error messages about running out of virtual memory | |
1194 | while compiling certain programs. | |
1195 | ||
1196 | You can prevent this problem by linking GNU CC with the GNU malloc | |
1197 | (which thus replaces the malloc that comes with the system). GNU malloc | |
1198 | is available as a separate package, and also in the file | |
1199 | @file{src/gmalloc.c} in the GNU Emacs 19 distribution. | |
1200 | ||
1201 | If you have installed GNU malloc as a separate library package, use this | |
1202 | option when you relink GNU CC: | |
1203 | ||
1204 | @example | |
1205 | MALLOC=/usr/local/lib/libgmalloc.a | |
1206 | @end example | |
1207 | ||
1208 | Alternatively, if you have compiled @file{gmalloc.c} from Emacs 19, copy | |
1209 | the object file to @file{gmalloc.o} and use this option when you relink | |
1210 | GNU CC: | |
1211 | ||
1212 | @example | |
1213 | MALLOC=gmalloc.o | |
1214 | @end example | |
1215 | @end itemize | |
1216 | ||
1217 | @node Incompatibilities | |
1218 | @section Incompatibilities of GNU CC | |
1219 | @cindex incompatibilities of GNU CC | |
1220 | ||
1221 | There are several noteworthy incompatibilities between GNU C and most | |
1222 | existing (non-ANSI) versions of C. The @samp{-traditional} option | |
1223 | eliminates many of these incompatibilities, @emph{but not all}, by | |
1224 | telling GNU C to behave like the other C compilers. | |
1225 | ||
1226 | @itemize @bullet | |
1227 | @cindex string constants | |
1228 | @cindex read-only strings | |
1229 | @cindex shared strings | |
1230 | @item | |
1231 | GNU CC normally makes string constants read-only. If several | |
1232 | identical-looking string constants are used, GNU CC stores only one | |
1233 | copy of the string. | |
1234 | ||
1235 | @cindex @code{mktemp}, and constant strings | |
1236 | One consequence is that you cannot call @code{mktemp} with a string | |
1237 | constant argument. The function @code{mktemp} always alters the | |
1238 | string its argument points to. | |
1239 | ||
1240 | @cindex @code{sscanf}, and constant strings | |
1241 | @cindex @code{fscanf}, and constant strings | |
1242 | @cindex @code{scanf}, and constant strings | |
1243 | Another consequence is that @code{sscanf} does not work on some systems | |
1244 | when passed a string constant as its format control string or input. | |
1245 | This is because @code{sscanf} incorrectly tries to write into the string | |
1246 | constant. Likewise @code{fscanf} and @code{scanf}. | |
1247 | ||
1248 | The best solution to these problems is to change the program to use | |
1249 | @code{char}-array variables with initialization strings for these | |
1250 | purposes instead of string constants. But if this is not possible, | |
1251 | you can use the @samp{-fwritable-strings} flag, which directs GNU CC | |
1252 | to handle string constants the same way most C compilers do. | |
1253 | @samp{-traditional} also has this effect, among others. | |
1254 | ||
1255 | @item | |
1256 | @code{-2147483648} is positive. | |
1257 | ||
1258 | This is because 2147483648 cannot fit in the type @code{int}, so | |
1259 | (following the ANSI C rules) its data type is @code{unsigned long int}. | |
1260 | Negating this value yields 2147483648 again. | |
1261 | ||
1262 | @item | |
1263 | GNU CC does not substitute macro arguments when they appear inside of | |
1264 | string constants. For example, the following macro in GNU CC | |
1265 | ||
1266 | @example | |
1267 | #define foo(a) "a" | |
1268 | @end example | |
1269 | ||
1270 | @noindent | |
1271 | will produce output @code{"a"} regardless of what the argument @var{a} is. | |
1272 | ||
1273 | The @samp{-traditional} option directs GNU CC to handle such cases | |
1274 | (among others) in the old-fashioned (non-ANSI) fashion. | |
1275 | ||
1276 | @cindex @code{setjmp} incompatibilities | |
1277 | @cindex @code{longjmp} incompatibilities | |
1278 | @item | |
1279 | When you use @code{setjmp} and @code{longjmp}, the only automatic | |
1280 | variables guaranteed to remain valid are those declared | |
1281 | @code{volatile}. This is a consequence of automatic register | |
1282 | allocation. Consider this function: | |
1283 | ||
1284 | @example | |
1285 | jmp_buf j; | |
1286 | ||
1287 | foo () | |
1288 | @{ | |
1289 | int a, b; | |
1290 | ||
1291 | a = fun1 (); | |
1292 | if (setjmp (j)) | |
1293 | return a; | |
1294 | ||
1295 | a = fun2 (); | |
1296 | /* @r{@code{longjmp (j)} may occur in @code{fun3}.} */ | |
1297 | return a + fun3 (); | |
1298 | @} | |
1299 | @end example | |
1300 | ||
1301 | Here @code{a} may or may not be restored to its first value when the | |
1302 | @code{longjmp} occurs. If @code{a} is allocated in a register, then | |
1303 | its first value is restored; otherwise, it keeps the last value stored | |
1304 | in it. | |
1305 | ||
1306 | If you use the @samp{-W} option with the @samp{-O} option, you will | |
1307 | get a warning when GNU CC thinks such a problem might be possible. | |
1308 | ||
1309 | The @samp{-traditional} option directs GNU C to put variables in | |
1310 | the stack by default, rather than in registers, in functions that | |
1311 | call @code{setjmp}. This results in the behavior found in | |
1312 | traditional C compilers. | |
1313 | ||
1314 | @item | |
1315 | Programs that use preprocessing directives in the middle of macro | |
1316 | arguments do not work with GNU CC. For example, a program like this | |
1317 | will not work: | |
1318 | ||
1319 | @example | |
1320 | foobar ( | |
1321 | #define luser | |
1322 | hack) | |
1323 | @end example | |
1324 | ||
1325 | ANSI C does not permit such a construct. It would make sense to support | |
1326 | it when @samp{-traditional} is used, but it is too much work to | |
1327 | implement. | |
1328 | ||
1329 | @cindex external declaration scope | |
1330 | @cindex scope of external declarations | |
1331 | @cindex declaration scope | |
1332 | @item | |
1333 | Declarations of external variables and functions within a block apply | |
1334 | only to the block containing the declaration. In other words, they | |
1335 | have the same scope as any other declaration in the same place. | |
1336 | ||
1337 | In some other C compilers, a @code{extern} declaration affects all the | |
1338 | rest of the file even if it happens within a block. | |
1339 | ||
1340 | The @samp{-traditional} option directs GNU C to treat all @code{extern} | |
1341 | declarations as global, like traditional compilers. | |
1342 | ||
1343 | @item | |
1344 | In traditional C, you can combine @code{long}, etc., with a typedef name, | |
1345 | as shown here: | |
1346 | ||
1347 | @example | |
1348 | typedef int foo; | |
1349 | typedef long foo bar; | |
1350 | @end example | |
1351 | ||
1352 | In ANSI C, this is not allowed: @code{long} and other type modifiers | |
1353 | require an explicit @code{int}. Because this criterion is expressed | |
1354 | by Bison grammar rules rather than C code, the @samp{-traditional} | |
1355 | flag cannot alter it. | |
1356 | ||
1357 | @cindex typedef names as function parameters | |
1358 | @item | |
1359 | PCC allows typedef names to be used as function parameters. The | |
1360 | difficulty described immediately above applies here too. | |
1361 | ||
1362 | @cindex whitespace | |
1363 | @item | |
1364 | PCC allows whitespace in the middle of compound assignment operators | |
1365 | such as @samp{+=}. GNU CC, following the ANSI standard, does not | |
1366 | allow this. The difficulty described immediately above applies here | |
1367 | too. | |
1368 | ||
1369 | @cindex apostrophes | |
1370 | @cindex ' | |
1371 | @item | |
1372 | GNU CC complains about unterminated character constants inside of | |
1373 | preprocessing conditionals that fail. Some programs have English | |
1374 | comments enclosed in conditionals that are guaranteed to fail; if these | |
1375 | comments contain apostrophes, GNU CC will probably report an error. For | |
1376 | example, this code would produce an error: | |
1377 | ||
1378 | @example | |
1379 | #if 0 | |
1380 | You can't expect this to work. | |
1381 | #endif | |
1382 | @end example | |
1383 | ||
1384 | The best solution to such a problem is to put the text into an actual | |
1385 | C comment delimited by @samp{/*@dots{}*/}. However, | |
1386 | @samp{-traditional} suppresses these error messages. | |
1387 | ||
1388 | @item | |
1389 | Many user programs contain the declaration @samp{long time ();}. In the | |
1390 | past, the system header files on many systems did not actually declare | |
1391 | @code{time}, so it did not matter what type your program declared it to | |
1392 | return. But in systems with ANSI C headers, @code{time} is declared to | |
1393 | return @code{time_t}, and if that is not the same as @code{long}, then | |
1394 | @samp{long time ();} is erroneous. | |
1395 | ||
1396 | The solution is to change your program to use @code{time_t} as the return | |
1397 | type of @code{time}. | |
1398 | ||
1399 | @cindex @code{float} as function value type | |
1400 | @item | |
1401 | When compiling functions that return @code{float}, PCC converts it to | |
1402 | a double. GNU CC actually returns a @code{float}. If you are concerned | |
1403 | with PCC compatibility, you should declare your functions to return | |
1404 | @code{double}; you might as well say what you mean. | |
1405 | ||
1406 | @cindex structures | |
1407 | @cindex unions | |
1408 | @item | |
1409 | When compiling functions that return structures or unions, GNU CC | |
1410 | output code normally uses a method different from that used on most | |
1411 | versions of Unix. As a result, code compiled with GNU CC cannot call | |
1412 | a structure-returning function compiled with PCC, and vice versa. | |
1413 | ||
1414 | The method used by GNU CC is as follows: a structure or union which is | |
1415 | 1, 2, 4 or 8 bytes long is returned like a scalar. A structure or union | |
1416 | with any other size is stored into an address supplied by the caller | |
1417 | (usually in a special, fixed register, but on some machines it is passed | |
1418 | on the stack). The machine-description macros @code{STRUCT_VALUE} and | |
1419 | @code{STRUCT_INCOMING_VALUE} tell GNU CC where to pass this address. | |
1420 | ||
1421 | By contrast, PCC on most target machines returns structures and unions | |
1422 | of any size by copying the data into an area of static storage, and then | |
1423 | returning the address of that storage as if it were a pointer value. | |
1424 | The caller must copy the data from that memory area to the place where | |
1425 | the value is wanted. GNU CC does not use this method because it is | |
1426 | slower and nonreentrant. | |
1427 | ||
1428 | On some newer machines, PCC uses a reentrant convention for all | |
1429 | structure and union returning. GNU CC on most of these machines uses a | |
1430 | compatible convention when returning structures and unions in memory, | |
1431 | but still returns small structures and unions in registers. | |
1432 | ||
1433 | You can tell GNU CC to use a compatible convention for all structure and | |
1434 | union returning with the option @samp{-fpcc-struct-return}. | |
1435 | ||
1436 | @cindex preprocessing tokens | |
1437 | @cindex preprocessing numbers | |
1438 | @item | |
1439 | GNU C complains about program fragments such as @samp{0x74ae-0x4000} | |
1440 | which appear to be two hexadecimal constants separated by the minus | |
1441 | operator. Actually, this string is a single @dfn{preprocessing token}. | |
1442 | Each such token must correspond to one token in C. Since this does not, | |
1443 | GNU C prints an error message. Although it may appear obvious that what | |
1444 | is meant is an operator and two values, the ANSI C standard specifically | |
1445 | requires that this be treated as erroneous. | |
1446 | ||
1447 | A @dfn{preprocessing token} is a @dfn{preprocessing number} if it | |
1448 | begins with a digit and is followed by letters, underscores, digits, | |
1449 | periods and @samp{e+}, @samp{e-}, @samp{E+}, or @samp{E-} character | |
1450 | sequences. | |
1451 | ||
1452 | To make the above program fragment valid, place whitespace in front of | |
1453 | the minus sign. This whitespace will end the preprocessing number. | |
1454 | @end itemize | |
1455 | ||
1456 | @node Fixed Headers | |
1457 | @section Fixed Header Files | |
1458 | ||
1459 | GNU CC needs to install corrected versions of some system header files. | |
1460 | This is because most target systems have some header files that won't | |
1461 | work with GNU CC unless they are changed. Some have bugs, some are | |
1462 | incompatible with ANSI C, and some depend on special features of other | |
1463 | compilers. | |
1464 | ||
1465 | Installing GNU CC automatically creates and installs the fixed header | |
1466 | files, by running a program called @code{fixincludes} (or for certain | |
1467 | targets an alternative such as @code{fixinc.svr4}). Normally, you | |
1468 | don't need to pay attention to this. But there are cases where it | |
1469 | doesn't do the right thing automatically. | |
1470 | ||
1471 | @itemize @bullet | |
1472 | @item | |
1473 | If you update the system's header files, such as by installing a new | |
1474 | system version, the fixed header files of GNU CC are not automatically | |
1475 | updated. The easiest way to update them is to reinstall GNU CC. (If | |
1476 | you want to be clever, look in the makefile and you can find a | |
1477 | shortcut.) | |
1478 | ||
1479 | @item | |
1480 | On some systems, in particular SunOS 4, header file directories contain | |
1481 | machine-specific symbolic links in certain places. This makes it | |
1482 | possible to share most of the header files among hosts running the | |
1483 | same version of SunOS 4 on different machine models. | |
1484 | ||
1485 | The programs that fix the header files do not understand this special | |
1486 | way of using symbolic links; therefore, the directory of fixed header | |
1487 | files is good only for the machine model used to build it. | |
1488 | ||
1489 | In SunOS 4, only programs that look inside the kernel will notice the | |
1490 | difference between machine models. Therefore, for most purposes, you | |
1491 | need not be concerned about this. | |
1492 | ||
1493 | It is possible to make separate sets of fixed header files for the | |
1494 | different machine models, and arrange a structure of symbolic links so | |
1495 | as to use the proper set, but you'll have to do this by hand. | |
1496 | ||
1497 | @item | |
1498 | On Lynxos, GNU CC by default does not fix the header files. This is | |
1499 | because bugs in the shell cause the @code{fixincludes} script to fail. | |
1500 | ||
1501 | This means you will encounter problems due to bugs in the system header | |
1502 | files. It may be no comfort that they aren't GNU CC's fault, but it | |
1503 | does mean that there's nothing for us to do about them. | |
1504 | @end itemize | |
1505 | ||
1506 | @node Standard Libraries | |
1507 | @section Standard Libraries | |
1508 | ||
1509 | GNU CC by itself attempts to be what the ISO/ANSI C standard calls a | |
1510 | @dfn{conforming freestanding implementation}. This means all ANSI | |
1511 | C language features are available, as well as the contents of | |
1512 | @file{float.h}, @file{limits.h}, @file{stdarg.h}, and | |
1513 | @file{stddef.h}. The rest of the C library is supplied by the | |
1514 | vendor of the operating system. If that C library doesn't conform to | |
1515 | the C standards, then your programs might get warnings (especially when | |
1516 | using @samp{-Wall}) that you don't expect. | |
1517 | ||
1518 | For example, the @code{sprintf} function on SunOS 4.1.3 returns | |
1519 | @code{char *} while the C standard says that @code{sprintf} returns an | |
1520 | @code{int}. The @code{fixincludes} program could make the prototype for | |
1521 | this function match the Standard, but that would be wrong, since the | |
1522 | function will still return @code{char *}. | |
1523 | ||
1524 | If you need a Standard compliant library, then you need to find one, as | |
1525 | GNU CC does not provide one. The GNU C library (called @code{glibc}) | |
1526 | has been ported to a number of operating systems, and provides ANSI/ISO, | |
1527 | POSIX, BSD and SystemV compatibility. You could also ask your operating | |
1528 | system vendor if newer libraries are available. | |
1529 | ||
1530 | @node Disappointments | |
1531 | @section Disappointments and Misunderstandings | |
1532 | ||
1533 | These problems are perhaps regrettable, but we don't know any practical | |
1534 | way around them. | |
1535 | ||
1536 | @itemize @bullet | |
1537 | @item | |
1538 | Certain local variables aren't recognized by debuggers when you compile | |
1539 | with optimization. | |
1540 | ||
1541 | This occurs because sometimes GNU CC optimizes the variable out of | |
1542 | existence. There is no way to tell the debugger how to compute the | |
1543 | value such a variable ``would have had'', and it is not clear that would | |
1544 | be desirable anyway. So GNU CC simply does not mention the eliminated | |
1545 | variable when it writes debugging information. | |
1546 | ||
1547 | You have to expect a certain amount of disagreement between the | |
1548 | executable and your source code, when you use optimization. | |
1549 | ||
1550 | @cindex conflicting types | |
1551 | @cindex scope of declaration | |
1552 | @item | |
1553 | Users often think it is a bug when GNU CC reports an error for code | |
1554 | like this: | |
1555 | ||
1556 | @example | |
1557 | int foo (struct mumble *); | |
1558 | ||
1559 | struct mumble @{ @dots{} @}; | |
1560 | ||
1561 | int foo (struct mumble *x) | |
1562 | @{ @dots{} @} | |
1563 | @end example | |
1564 | ||
1565 | This code really is erroneous, because the scope of @code{struct | |
1566 | mumble} in the prototype is limited to the argument list containing it. | |
1567 | It does not refer to the @code{struct mumble} defined with file scope | |
1568 | immediately below---they are two unrelated types with similar names in | |
1569 | different scopes. | |
1570 | ||
1571 | But in the definition of @code{foo}, the file-scope type is used | |
1572 | because that is available to be inherited. Thus, the definition and | |
1573 | the prototype do not match, and you get an error. | |
1574 | ||
1575 | This behavior may seem silly, but it's what the ANSI standard specifies. | |
1576 | It is easy enough for you to make your code work by moving the | |
1577 | definition of @code{struct mumble} above the prototype. It's not worth | |
1578 | being incompatible with ANSI C just to avoid an error for the example | |
1579 | shown above. | |
1580 | ||
1581 | @item | |
1582 | Accesses to bitfields even in volatile objects works by accessing larger | |
1583 | objects, such as a byte or a word. You cannot rely on what size of | |
1584 | object is accessed in order to read or write the bitfield; it may even | |
1585 | vary for a given bitfield according to the precise usage. | |
1586 | ||
1587 | If you care about controlling the amount of memory that is accessed, use | |
1588 | volatile but do not use bitfields. | |
1589 | ||
1590 | @item | |
1591 | GNU CC comes with shell scripts to fix certain known problems in system | |
1592 | header files. They install corrected copies of various header files in | |
1593 | a special directory where only GNU CC will normally look for them. The | |
1594 | scripts adapt to various systems by searching all the system header | |
1595 | files for the problem cases that we know about. | |
1596 | ||
1597 | If new system header files are installed, nothing automatically arranges | |
1598 | to update the corrected header files. You will have to reinstall GNU CC | |
1599 | to fix the new header files. More specifically, go to the build | |
1600 | directory and delete the files @file{stmp-fixinc} and | |
1601 | @file{stmp-headers}, and the subdirectory @code{include}; then do | |
1602 | @samp{make install} again. | |
1603 | ||
1604 | @item | |
1605 | @cindex floating point precision | |
1606 | On 68000 and x86 systems, for instance, you can get paradoxical results | |
1607 | if you test the precise values of floating point numbers. For example, | |
1608 | you can find that a floating point value which is not a NaN is not equal | |
1609 | to itself. This results from the fact that the floating point registers | |
1610 | hold a few more bits of precision than fit in a @code{double} in memory. | |
1611 | Compiled code moves values between memory and floating point registers | |
1612 | at its convenience, and moving them into memory truncates them. | |
1613 | ||
1614 | You can partially avoid this problem by using the @samp{-ffloat-store} | |
1615 | option (@pxref{Optimize Options}). | |
1616 | ||
1617 | @item | |
1618 | On the MIPS, variable argument functions using @file{varargs.h} | |
1619 | cannot have a floating point value for the first argument. The | |
1620 | reason for this is that in the absence of a prototype in scope, | |
1621 | if the first argument is a floating point, it is passed in a | |
1622 | floating point register, rather than an integer register. | |
1623 | ||
1624 | If the code is rewritten to use the ANSI standard @file{stdarg.h} | |
1625 | method of variable arguments, and the prototype is in scope at | |
1626 | the time of the call, everything will work fine. | |
1627 | ||
1628 | @item | |
1629 | On the H8/300 and H8/300H, variable argument functions must be | |
1630 | implemented using the ANSI standard @file{stdarg.h} method of | |
1631 | variable arguments. Furthermore, calls to functions using @file{stdarg.h} | |
1632 | variable arguments must have a prototype for the called function | |
1633 | in scope at the time of the call. | |
1634 | @end itemize | |
1635 | ||
1636 | @node C++ Misunderstandings | |
1637 | @section Common Misunderstandings with GNU C++ | |
1638 | ||
1639 | @cindex misunderstandings in C++ | |
1640 | @cindex surprises in C++ | |
1641 | @cindex C++ misunderstandings | |
1642 | C++ is a complex language and an evolving one, and its standard definition | |
1643 | (the ANSI C++ draft standard) is also evolving. As a result, | |
1644 | your C++ compiler may occasionally surprise you, even when its behavior is | |
1645 | correct. This section discusses some areas that frequently give rise to | |
1646 | questions of this sort. | |
1647 | ||
1648 | @menu | |
1649 | * Static Definitions:: Static member declarations are not definitions | |
1650 | * Temporaries:: Temporaries may vanish before you expect | |
1651 | @end menu | |
1652 | ||
1653 | @node Static Definitions | |
1654 | @subsection Declare @emph{and} Define Static Members | |
1655 | ||
1656 | @cindex C++ static data, declaring and defining | |
1657 | @cindex static data in C++, declaring and defining | |
1658 | @cindex declaring static data in C++ | |
1659 | @cindex defining static data in C++ | |
1660 | When a class has static data members, it is not enough to @emph{declare} | |
1661 | the static member; you must also @emph{define} it. For example: | |
1662 | ||
1663 | @example | |
1664 | class Foo | |
1665 | @{ | |
1666 | @dots{} | |
1667 | void method(); | |
1668 | static int bar; | |
1669 | @}; | |
1670 | @end example | |
1671 | ||
1672 | This declaration only establishes that the class @code{Foo} has an | |
1673 | @code{int} named @code{Foo::bar}, and a member function named | |
1674 | @code{Foo::method}. But you still need to define @emph{both} | |
1675 | @code{method} and @code{bar} elsewhere. According to the draft ANSI | |
1676 | standard, you must supply an initializer in one (and only one) source | |
1677 | file, such as: | |
1678 | ||
1679 | @example | |
1680 | int Foo::bar = 0; | |
1681 | @end example | |
1682 | ||
1683 | Other C++ compilers may not correctly implement the standard behavior. | |
1684 | As a result, when you switch to @code{g++} from one of these compilers, | |
1685 | you may discover that a program that appeared to work correctly in fact | |
1686 | does not conform to the standard: @code{g++} reports as undefined | |
1687 | symbols any static data members that lack definitions. | |
1688 | ||
1689 | @node Temporaries | |
1690 | @subsection Temporaries May Vanish Before You Expect | |
1691 | ||
1692 | @cindex temporaries, lifetime of | |
1693 | @cindex portions of temporary objects, pointers to | |
1694 | It is dangerous to use pointers or references to @emph{portions} of a | |
1695 | temporary object. The compiler may very well delete the object before | |
1696 | you expect it to, leaving a pointer to garbage. The most common place | |
1697 | where this problem crops up is in classes like the libg++ | |
1698 | @code{String} class, that define a conversion function to type | |
1699 | @code{char *} or @code{const char *}. However, any class that returns | |
1700 | a pointer to some internal structure is potentially subject to this | |
1701 | problem. | |
1702 | ||
1703 | For example, a program may use a function @code{strfunc} that returns | |
1704 | @code{String} objects, and another function @code{charfunc} that | |
1705 | operates on pointers to @code{char}: | |
1706 | ||
1707 | @example | |
1708 | String strfunc (); | |
1709 | void charfunc (const char *); | |
1710 | @end example | |
1711 | ||
1712 | @noindent | |
1713 | In this situation, it may seem natural to write @w{@samp{charfunc | |
1714 | (strfunc ());}} based on the knowledge that class @code{String} has an | |
1715 | explicit conversion to @code{char} pointers. However, what really | |
1716 | happens is akin to @samp{charfunc (@w{strfunc ()}.@w{convert ()});}, | |
1717 | where the @code{convert} method is a function to do the same data | |
1718 | conversion normally performed by a cast. Since the last use of the | |
1719 | temporary @code{String} object is the call to the conversion function, | |
1720 | the compiler may delete that object before actually calling | |
1721 | @code{charfunc}. The compiler has no way of knowing that deleting the | |
1722 | @code{String} object will invalidate the pointer. The pointer then | |
1723 | points to garbage, so that by the time @code{charfunc} is called, it | |
1724 | gets an invalid argument. | |
1725 | ||
1726 | Code like this may run successfully under some other compilers, | |
1727 | especially those that delete temporaries relatively late. However, the | |
1728 | GNU C++ behavior is also standard-conforming, so if your program depends | |
1729 | on late destruction of temporaries it is not portable. | |
1730 | ||
1731 | If you think this is surprising, you should be aware that the ANSI C++ | |
1732 | committee continues to debate the lifetime-of-temporaries problem. | |
1733 | ||
1734 | For now, at least, the safe way to write such code is to give the | |
1735 | temporary a name, which forces it to remain until the end of the scope of | |
1736 | the name. For example: | |
1737 | ||
1738 | @example | |
1739 | String& tmp = strfunc (); | |
1740 | charfunc (tmp); | |
1741 | @end example | |
1742 | ||
1743 | @node Protoize Caveats | |
1744 | @section Caveats of using @code{protoize} | |
1745 | ||
1746 | The conversion programs @code{protoize} and @code{unprotoize} can | |
1747 | sometimes change a source file in a way that won't work unless you | |
1748 | rearrange it. | |
1749 | ||
1750 | @itemize @bullet | |
1751 | @item | |
1752 | @code{protoize} can insert references to a type name or type tag before | |
1753 | the definition, or in a file where they are not defined. | |
1754 | ||
1755 | If this happens, compiler error messages should show you where the new | |
1756 | references are, so fixing the file by hand is straightforward. | |
1757 | ||
1758 | @item | |
1759 | There are some C constructs which @code{protoize} cannot figure out. | |
1760 | For example, it can't determine argument types for declaring a | |
1761 | pointer-to-function variable; this you must do by hand. @code{protoize} | |
1762 | inserts a comment containing @samp{???} each time it finds such a | |
1763 | variable; so you can find all such variables by searching for this | |
1764 | string. ANSI C does not require declaring the argument types of | |
1765 | pointer-to-function types. | |
1766 | ||
1767 | @item | |
1768 | Using @code{unprotoize} can easily introduce bugs. If the program | |
1769 | relied on prototypes to bring about conversion of arguments, these | |
1770 | conversions will not take place in the program without prototypes. | |
1771 | One case in which you can be sure @code{unprotoize} is safe is when | |
1772 | you are removing prototypes that were made with @code{protoize}; if | |
1773 | the program worked before without any prototypes, it will work again | |
1774 | without them. | |
1775 | ||
1776 | You can find all the places where this problem might occur by compiling | |
1777 | the program with the @samp{-Wconversion} option. It prints a warning | |
1778 | whenever an argument is converted. | |
1779 | ||
1780 | @item | |
1781 | Both conversion programs can be confused if there are macro calls in and | |
1782 | around the text to be converted. In other words, the standard syntax | |
1783 | for a declaration or definition must not result from expanding a macro. | |
1784 | This problem is inherent in the design of C and cannot be fixed. If | |
1785 | only a few functions have confusing macro calls, you can easily convert | |
1786 | them manually. | |
1787 | ||
1788 | @item | |
1789 | @code{protoize} cannot get the argument types for a function whose | |
1790 | definition was not actually compiled due to preprocessing conditionals. | |
1791 | When this happens, @code{protoize} changes nothing in regard to such | |
1792 | a function. @code{protoize} tries to detect such instances and warn | |
1793 | about them. | |
1794 | ||
1795 | You can generally work around this problem by using @code{protoize} step | |
1796 | by step, each time specifying a different set of @samp{-D} options for | |
1797 | compilation, until all of the functions have been converted. There is | |
1798 | no automatic way to verify that you have got them all, however. | |
1799 | ||
1800 | @item | |
1801 | Confusion may result if there is an occasion to convert a function | |
1802 | declaration or definition in a region of source code where there is more | |
1803 | than one formal parameter list present. Thus, attempts to convert code | |
1804 | containing multiple (conditionally compiled) versions of a single | |
1805 | function header (in the same vicinity) may not produce the desired (or | |
1806 | expected) results. | |
1807 | ||
1808 | If you plan on converting source files which contain such code, it is | |
1809 | recommended that you first make sure that each conditionally compiled | |
1810 | region of source code which contains an alternative function header also | |
1811 | contains at least one additional follower token (past the final right | |
1812 | parenthesis of the function header). This should circumvent the | |
1813 | problem. | |
1814 | ||
1815 | @item | |
1816 | @code{unprotoize} can become confused when trying to convert a function | |
1817 | definition or declaration which contains a declaration for a | |
1818 | pointer-to-function formal argument which has the same name as the | |
1819 | function being defined or declared. We recommand you avoid such choices | |
1820 | of formal parameter names. | |
1821 | ||
1822 | @item | |
1823 | You might also want to correct some of the indentation by hand and break | |
1824 | long lines. (The conversion programs don't write lines longer than | |
1825 | eighty characters in any case.) | |
1826 | @end itemize | |
1827 | ||
1828 | @node Non-bugs | |
1829 | @section Certain Changes We Don't Want to Make | |
1830 | ||
1831 | This section lists changes that people frequently request, but which | |
1832 | we do not make because we think GNU CC is better without them. | |
1833 | ||
1834 | @itemize @bullet | |
1835 | @item | |
1836 | Checking the number and type of arguments to a function which has an | |
1837 | old-fashioned definition and no prototype. | |
1838 | ||
1839 | Such a feature would work only occasionally---only for calls that appear | |
1840 | in the same file as the called function, following the definition. The | |
1841 | only way to check all calls reliably is to add a prototype for the | |
1842 | function. But adding a prototype eliminates the motivation for this | |
1843 | feature. So the feature is not worthwhile. | |
1844 | ||
1845 | @item | |
1846 | Warning about using an expression whose type is signed as a shift count. | |
1847 | ||
1848 | Shift count operands are probably signed more often than unsigned. | |
1849 | Warning about this would cause far more annoyance than good. | |
1850 | ||
1851 | @item | |
1852 | Warning about assigning a signed value to an unsigned variable. | |
1853 | ||
1854 | Such assignments must be very common; warning about them would cause | |
1855 | more annoyance than good. | |
1856 | ||
1857 | @item | |
1858 | Warning about unreachable code. | |
1859 | ||
1860 | It's very common to have unreachable code in machine-generated | |
1861 | programs. For example, this happens normally in some files of GNU C | |
1862 | itself. | |
1863 | ||
1864 | @item | |
1865 | Warning when a non-void function value is ignored. | |
1866 | ||
1867 | Coming as I do from a Lisp background, I balk at the idea that there is | |
1868 | something dangerous about discarding a value. There are functions that | |
1869 | return values which some callers may find useful; it makes no sense to | |
1870 | clutter the program with a cast to @code{void} whenever the value isn't | |
1871 | useful. | |
1872 | ||
1873 | @item | |
1874 | Assuming (for optimization) that the address of an external symbol is | |
1875 | never zero. | |
1876 | ||
1877 | This assumption is false on certain systems when @samp{#pragma weak} is | |
1878 | used. | |
1879 | ||
1880 | @item | |
1881 | Making @samp{-fshort-enums} the default. | |
1882 | ||
1883 | This would cause storage layout to be incompatible with most other C | |
1884 | compilers. And it doesn't seem very important, given that you can get | |
1885 | the same result in other ways. The case where it matters most is when | |
1886 | the enumeration-valued object is inside a structure, and in that case | |
1887 | you can specify a field width explicitly. | |
1888 | ||
1889 | @item | |
1890 | Making bitfields unsigned by default on particular machines where ``the | |
1891 | ABI standard'' says to do so. | |
1892 | ||
1893 | The ANSI C standard leaves it up to the implementation whether a bitfield | |
1894 | declared plain @code{int} is signed or not. This in effect creates two | |
1895 | alternative dialects of C. | |
1896 | ||
1897 | The GNU C compiler supports both dialects; you can specify the signed | |
1898 | dialect with @samp{-fsigned-bitfields} and the unsigned dialect with | |
1899 | @samp{-funsigned-bitfields}. However, this leaves open the question of | |
1900 | which dialect to use by default. | |
1901 | ||
1902 | Currently, the preferred dialect makes plain bitfields signed, because | |
1903 | this is simplest. Since @code{int} is the same as @code{signed int} in | |
1904 | every other context, it is cleanest for them to be the same in bitfields | |
1905 | as well. | |
1906 | ||
1907 | Some computer manufacturers have published Application Binary Interface | |
1908 | standards which specify that plain bitfields should be unsigned. It is | |
1909 | a mistake, however, to say anything about this issue in an ABI. This is | |
1910 | because the handling of plain bitfields distinguishes two dialects of C. | |
1911 | Both dialects are meaningful on every type of machine. Whether a | |
1912 | particular object file was compiled using signed bitfields or unsigned | |
1913 | is of no concern to other object files, even if they access the same | |
1914 | bitfields in the same data structures. | |
1915 | ||
1916 | A given program is written in one or the other of these two dialects. | |
1917 | The program stands a chance to work on most any machine if it is | |
1918 | compiled with the proper dialect. It is unlikely to work at all if | |
1919 | compiled with the wrong dialect. | |
1920 | ||
1921 | Many users appreciate the GNU C compiler because it provides an | |
1922 | environment that is uniform across machines. These users would be | |
1923 | inconvenienced if the compiler treated plain bitfields differently on | |
1924 | certain machines. | |
1925 | ||
1926 | Occasionally users write programs intended only for a particular machine | |
1927 | type. On these occasions, the users would benefit if the GNU C compiler | |
1928 | were to support by default the same dialect as the other compilers on | |
1929 | that machine. But such applications are rare. And users writing a | |
1930 | program to run on more than one type of machine cannot possibly benefit | |
1931 | from this kind of compatibility. | |
1932 | ||
1933 | This is why GNU CC does and will treat plain bitfields in the same | |
1934 | fashion on all types of machines (by default). | |
1935 | ||
1936 | There are some arguments for making bitfields unsigned by default on all | |
1937 | machines. If, for example, this becomes a universal de facto standard, | |
1938 | it would make sense for GNU CC to go along with it. This is something | |
1939 | to be considered in the future. | |
1940 | ||
1941 | (Of course, users strongly concerned about portability should indicate | |
1942 | explicitly in each bitfield whether it is signed or not. In this way, | |
1943 | they write programs which have the same meaning in both C dialects.) | |
1944 | ||
1945 | @item | |
1946 | Undefining @code{__STDC__} when @samp{-ansi} is not used. | |
1947 | ||
1948 | Currently, GNU CC defines @code{__STDC__} as long as you don't use | |
1949 | @samp{-traditional}. This provides good results in practice. | |
1950 | ||
1951 | Programmers normally use conditionals on @code{__STDC__} to ask whether | |
1952 | it is safe to use certain features of ANSI C, such as function | |
1953 | prototypes or ANSI token concatenation. Since plain @samp{gcc} supports | |
1954 | all the features of ANSI C, the correct answer to these questions is | |
1955 | ``yes''. | |
1956 | ||
1957 | Some users try to use @code{__STDC__} to check for the availability of | |
1958 | certain library facilities. This is actually incorrect usage in an ANSI | |
1959 | C program, because the ANSI C standard says that a conforming | |
1960 | freestanding implementation should define @code{__STDC__} even though it | |
1961 | does not have the library facilities. @samp{gcc -ansi -pedantic} is a | |
1962 | conforming freestanding implementation, and it is therefore required to | |
1963 | define @code{__STDC__}, even though it does not come with an ANSI C | |
1964 | library. | |
1965 | ||
1966 | Sometimes people say that defining @code{__STDC__} in a compiler that | |
1967 | does not completely conform to the ANSI C standard somehow violates the | |
1968 | standard. This is illogical. The standard is a standard for compilers | |
1969 | that claim to support ANSI C, such as @samp{gcc -ansi}---not for other | |
1970 | compilers such as plain @samp{gcc}. Whatever the ANSI C standard says | |
1971 | is relevant to the design of plain @samp{gcc} without @samp{-ansi} only | |
1972 | for pragmatic reasons, not as a requirement. | |
1973 | ||
e9a25f70 JL |
1974 | GNU CC normally defines @code{__STDC__} to be 1, and in addition |
1975 | defines @code{__STRICT_ANSI__} if you specify the @samp{-ansi} option. | |
1976 | On some hosts, system include files use a different convention, where | |
1977 | @code{__STDC__} is normally 0, but is 1 if the user specifies strict | |
1978 | conformance to the C Standard. GNU CC follows the host convention when | |
1979 | processing system include files, but when processing user files it follows | |
1980 | the usual GNU C convention. | |
1981 | ||
861bb6c1 JL |
1982 | @item |
1983 | Undefining @code{__STDC__} in C++. | |
1984 | ||
1985 | Programs written to compile with C++-to-C translators get the | |
1986 | value of @code{__STDC__} that goes with the C compiler that is | |
1987 | subsequently used. These programs must test @code{__STDC__} | |
1988 | to determine what kind of C preprocessor that compiler uses: | |
1989 | whether they should concatenate tokens in the ANSI C fashion | |
1990 | or in the traditional fashion. | |
1991 | ||
1992 | These programs work properly with GNU C++ if @code{__STDC__} is defined. | |
1993 | They would not work otherwise. | |
1994 | ||
1995 | In addition, many header files are written to provide prototypes in ANSI | |
1996 | C but not in traditional C. Many of these header files can work without | |
1997 | change in C++ provided @code{__STDC__} is defined. If @code{__STDC__} | |
1998 | is not defined, they will all fail, and will all need to be changed to | |
1999 | test explicitly for C++ as well. | |
2000 | ||
2001 | @item | |
2002 | Deleting ``empty'' loops. | |
2003 | ||
2004 | GNU CC does not delete ``empty'' loops because the most likely reason | |
2005 | you would put one in a program is to have a delay. Deleting them will | |
2006 | not make real programs run any faster, so it would be pointless. | |
2007 | ||
2008 | It would be different if optimization of a nonempty loop could produce | |
2009 | an empty one. But this generally can't happen. | |
2010 | ||
2011 | @item | |
2012 | Making side effects happen in the same order as in some other compiler. | |
2013 | ||
2014 | @cindex side effects, order of evaluation | |
2015 | @cindex order of evaluation, side effects | |
2016 | It is never safe to depend on the order of evaluation of side effects. | |
2017 | For example, a function call like this may very well behave differently | |
2018 | from one compiler to another: | |
2019 | ||
2020 | @example | |
2021 | void func (int, int); | |
2022 | ||
2023 | int i = 2; | |
2024 | func (i++, i++); | |
2025 | @end example | |
2026 | ||
2027 | There is no guarantee (in either the C or the C++ standard language | |
2028 | definitions) that the increments will be evaluated in any particular | |
2029 | order. Either increment might happen first. @code{func} might get the | |
2030 | arguments @samp{2, 3}, or it might get @samp{3, 2}, or even @samp{2, 2}. | |
2031 | ||
2032 | @item | |
2033 | Not allowing structures with volatile fields in registers. | |
2034 | ||
2035 | Strictly speaking, there is no prohibition in the ANSI C standard | |
2036 | against allowing structures with volatile fields in registers, but | |
2037 | it does not seem to make any sense and is probably not what you wanted | |
2038 | to do. So the compiler will give an error message in this case. | |
2039 | @end itemize | |
2040 | ||
2041 | @node Warnings and Errors | |
2042 | @section Warning Messages and Error Messages | |
2043 | ||
2044 | @cindex error messages | |
2045 | @cindex warnings vs errors | |
2046 | @cindex messages, warning and error | |
2047 | The GNU compiler can produce two kinds of diagnostics: errors and | |
2048 | warnings. Each kind has a different purpose: | |
2049 | ||
2050 | @itemize @w{} | |
2051 | @item | |
2052 | @emph{Errors} report problems that make it impossible to compile your | |
2053 | program. GNU CC reports errors with the source file name and line | |
2054 | number where the problem is apparent. | |
2055 | ||
2056 | @item | |
2057 | @emph{Warnings} report other unusual conditions in your code that | |
2058 | @emph{may} indicate a problem, although compilation can (and does) | |
2059 | proceed. Warning messages also report the source file name and line | |
2060 | number, but include the text @samp{warning:} to distinguish them | |
2061 | from error messages. | |
2062 | @end itemize | |
2063 | ||
2064 | Warnings may indicate danger points where you should check to make sure | |
2065 | that your program really does what you intend; or the use of obsolete | |
2066 | features; or the use of nonstandard features of GNU C or C++. Many | |
2067 | warnings are issued only if you ask for them, with one of the @samp{-W} | |
2068 | options (for instance, @samp{-Wall} requests a variety of useful | |
2069 | warnings). | |
2070 | ||
2071 | GNU CC always tries to compile your program if possible; it never | |
2072 | gratuitously rejects a program whose meaning is clear merely because | |
2073 | (for instance) it fails to conform to a standard. In some cases, | |
2074 | however, the C and C++ standards specify that certain extensions are | |
2075 | forbidden, and a diagnostic @emph{must} be issued by a conforming | |
2076 | compiler. The @samp{-pedantic} option tells GNU CC to issue warnings in | |
2077 | such cases; @samp{-pedantic-errors} says to make them errors instead. | |
2078 | This does not mean that @emph{all} non-ANSI constructs get warnings | |
2079 | or errors. | |
2080 | ||
2081 | @xref{Warning Options,,Options to Request or Suppress Warnings}, for | |
2082 | more detail on these and related command-line options. | |
2083 | ||
2084 | @node Bugs | |
2085 | @chapter Reporting Bugs | |
2086 | @cindex bugs | |
2087 | @cindex reporting bugs | |
2088 | ||
2089 | Your bug reports play an essential role in making GNU CC reliable. | |
2090 | ||
2091 | When you encounter a problem, the first thing to do is to see if it is | |
2092 | already known. @xref{Trouble}. If it isn't known, then you should | |
2093 | report the problem. | |
2094 | ||
2095 | Reporting a bug may help you by bringing a solution to your problem, or | |
2096 | it may not. (If it does not, look in the service directory; see | |
2097 | @ref{Service}.) In any case, the principal function of a bug report is | |
2098 | to help the entire community by making the next version of GNU CC work | |
2099 | better. Bug reports are your contribution to the maintenance of GNU CC. | |
2100 | ||
2101 | Since the maintainers are very overloaded, we cannot respond to every | |
2102 | bug report. However, if the bug has not been fixed, we are likely to | |
2103 | send you a patch and ask you to tell us whether it works. | |
2104 | ||
2105 | In order for a bug report to serve its purpose, you must include the | |
2106 | information that makes for fixing the bug. | |
2107 | ||
2108 | @menu | |
2109 | * Criteria: Bug Criteria. Have you really found a bug? | |
2110 | * Where: Bug Lists. Where to send your bug report. | |
2111 | * Reporting: Bug Reporting. How to report a bug effectively. | |
2112 | * Patches: Sending Patches. How to send a patch for GNU CC. | |
2113 | * Known: Trouble. Known problems. | |
2114 | * Help: Service. Where to ask for help. | |
2115 | @end menu | |
2116 | ||
2117 | @node Bug Criteria | |
2118 | @section Have You Found a Bug? | |
2119 | @cindex bug criteria | |
2120 | ||
2121 | If you are not sure whether you have found a bug, here are some guidelines: | |
2122 | ||
2123 | @itemize @bullet | |
2124 | @cindex fatal signal | |
2125 | @cindex core dump | |
2126 | @item | |
2127 | If the compiler gets a fatal signal, for any input whatever, that is a | |
2128 | compiler bug. Reliable compilers never crash. | |
2129 | ||
2130 | @cindex invalid assembly code | |
2131 | @cindex assembly code, invalid | |
2132 | @item | |
2133 | If the compiler produces invalid assembly code, for any input whatever | |
2134 | (except an @code{asm} statement), that is a compiler bug, unless the | |
2135 | compiler reports errors (not just warnings) which would ordinarily | |
2136 | prevent the assembler from being run. | |
2137 | ||
2138 | @cindex undefined behavior | |
2139 | @cindex undefined function value | |
2140 | @cindex increment operators | |
2141 | @item | |
2142 | If the compiler produces valid assembly code that does not correctly | |
2143 | execute the input source code, that is a compiler bug. | |
2144 | ||
2145 | However, you must double-check to make sure, because you may have run | |
2146 | into an incompatibility between GNU C and traditional C | |
2147 | (@pxref{Incompatibilities}). These incompatibilities might be considered | |
2148 | bugs, but they are inescapable consequences of valuable features. | |
2149 | ||
2150 | Or you may have a program whose behavior is undefined, which happened | |
2151 | by chance to give the desired results with another C or C++ compiler. | |
2152 | ||
2153 | For example, in many nonoptimizing compilers, you can write @samp{x;} | |
2154 | at the end of a function instead of @samp{return x;}, with the same | |
2155 | results. But the value of the function is undefined if @code{return} | |
2156 | is omitted; it is not a bug when GNU CC produces different results. | |
2157 | ||
2158 | Problems often result from expressions with two increment operators, | |
2159 | as in @code{f (*p++, *p++)}. Your previous compiler might have | |
2160 | interpreted that expression the way you intended; GNU CC might | |
2161 | interpret it another way. Neither compiler is wrong. The bug is | |
2162 | in your code. | |
2163 | ||
2164 | After you have localized the error to a single source line, it should | |
2165 | be easy to check for these things. If your program is correct and | |
2166 | well defined, you have found a compiler bug. | |
2167 | ||
2168 | @item | |
2169 | If the compiler produces an error message for valid input, that is a | |
2170 | compiler bug. | |
2171 | ||
2172 | @cindex invalid input | |
2173 | @item | |
2174 | If the compiler does not produce an error message for invalid input, | |
2175 | that is a compiler bug. However, you should note that your idea of | |
2176 | ``invalid input'' might be my idea of ``an extension'' or ``support | |
2177 | for traditional practice''. | |
2178 | ||
2179 | @item | |
2180 | If you are an experienced user of C or C++ compilers, your suggestions | |
2181 | for improvement of GNU CC or GNU C++ are welcome in any case. | |
2182 | @end itemize | |
2183 | ||
2184 | @node Bug Lists | |
2185 | @section Where to Report Bugs | |
2186 | @cindex bug report mailing lists | |
f2d76545 JL |
2187 | @kindex egcs-bugs@@cygnus.com |
2188 | Send bug reports for GNU C to @samp{egcs-bugs@@cygnus.com}. | |
861bb6c1 | 2189 | |
f2d76545 JL |
2190 | @kindex egcs-bugs@@cygnus.com |
2191 | @kindex egcs-bugs@@cygnus.com | |
2192 | Send bug reports for GNU C++ and the C++ runtime libraries to | |
2193 | @samp{egcs-bugs@@cygnus.com}. | |
861bb6c1 JL |
2194 | |
2195 | Often people think of posting bug reports to the newsgroup instead of | |
2196 | mailing them. This appears to work, but it has one problem which can be | |
2197 | crucial: a newsgroup posting does not contain a mail path back to the | |
2198 | sender. Thus, if maintainers need more information, they may be unable | |
2199 | to reach you. For this reason, you should always send bug reports by | |
2200 | mail to the proper mailing list. | |
2201 | ||
2202 | As a last resort, send bug reports on paper to: | |
2203 | ||
2204 | @example | |
2205 | GNU Compiler Bugs | |
2206 | Free Software Foundation | |
2207 | 59 Temple Place - Suite 330 | |
2208 | Boston, MA 02111-1307, USA | |
2209 | @end example | |
2210 | ||
2211 | @node Bug Reporting | |
2212 | @section How to Report Bugs | |
2213 | @cindex compiler bugs, reporting | |
2214 | ||
2215 | The fundamental principle of reporting bugs usefully is this: | |
2216 | @strong{report all the facts}. If you are not sure whether to state a | |
2217 | fact or leave it out, state it! | |
2218 | ||
2219 | Often people omit facts because they think they know what causes the | |
2220 | problem and they conclude that some details don't matter. Thus, you might | |
2221 | assume that the name of the variable you use in an example does not matter. | |
2222 | Well, probably it doesn't, but one cannot be sure. Perhaps the bug is a | |
2223 | stray memory reference which happens to fetch from the location where that | |
2224 | name is stored in memory; perhaps, if the name were different, the contents | |
2225 | of that location would fool the compiler into doing the right thing despite | |
2226 | the bug. Play it safe and give a specific, complete example. That is the | |
2227 | easiest thing for you to do, and the most helpful. | |
2228 | ||
2229 | Keep in mind that the purpose of a bug report is to enable someone to | |
2230 | fix the bug if it is not known. It isn't very important what happens if | |
2231 | the bug is already known. Therefore, always write your bug reports on | |
2232 | the assumption that the bug is not known. | |
2233 | ||
2234 | Sometimes people give a few sketchy facts and ask, ``Does this ring a | |
2235 | bell?'' This cannot help us fix a bug, so it is basically useless. We | |
2236 | respond by asking for enough details to enable us to investigate. | |
2237 | You might as well expedite matters by sending them to begin with. | |
2238 | ||
2239 | Try to make your bug report self-contained. If we have to ask you for | |
2240 | more information, it is best if you include all the previous information | |
2241 | in your response, as well as the information that was missing. | |
2242 | ||
2243 | Please report each bug in a separate message. This makes it easier for | |
2244 | us to track which bugs have been fixed and to forward your bugs reports | |
2245 | to the appropriate maintainer. | |
2246 | ||
2247 | Do not compress and encode any part of your bug report using programs | |
2248 | such as @file{uuencode}. If you do so it will slow down the processing | |
2249 | of your bug. If you must submit multiple large files, use @file{shar}, | |
2250 | which allows us to read your message without having to run any | |
2251 | decompression programs. | |
2252 | ||
2253 | To enable someone to investigate the bug, you should include all these | |
2254 | things: | |
2255 | ||
2256 | @itemize @bullet | |
2257 | @item | |
2258 | The version of GNU CC. You can get this by running it with the | |
2259 | @samp{-v} option. | |
2260 | ||
2261 | Without this, we won't know whether there is any point in looking for | |
2262 | the bug in the current version of GNU CC. | |
2263 | ||
2264 | @item | |
2265 | A complete input file that will reproduce the bug. If the bug is in the | |
2266 | C preprocessor, send a source file and any header files that it | |
2267 | requires. If the bug is in the compiler proper (@file{cc1}), run your | |
2268 | source file through the C preprocessor by doing @samp{gcc -E | |
2269 | @var{sourcefile} > @var{outfile}}, then include the contents of | |
2270 | @var{outfile} in the bug report. (When you do this, use the same | |
2271 | @samp{-I}, @samp{-D} or @samp{-U} options that you used in actual | |
2272 | compilation.) | |
2273 | ||
2274 | A single statement is not enough of an example. In order to compile it, | |
2275 | it must be embedded in a complete file of compiler input; and the bug | |
2276 | might depend on the details of how this is done. | |
2277 | ||
2278 | Without a real example one can compile, all anyone can do about your bug | |
2279 | report is wish you luck. It would be futile to try to guess how to | |
2280 | provoke the bug. For example, bugs in register allocation and reloading | |
2281 | frequently depend on every little detail of the function they happen in. | |
2282 | ||
2283 | Even if the input file that fails comes from a GNU program, you should | |
2284 | still send the complete test case. Don't ask the GNU CC maintainers to | |
2285 | do the extra work of obtaining the program in question---they are all | |
2286 | overworked as it is. Also, the problem may depend on what is in the | |
2287 | header files on your system; it is unreliable for the GNU CC maintainers | |
2288 | to try the problem with the header files available to them. By sending | |
2289 | CPP output, you can eliminate this source of uncertainty and save us | |
2290 | a certain percentage of wild goose chases. | |
2291 | ||
2292 | @item | |
2293 | The command arguments you gave GNU CC or GNU C++ to compile that example | |
2294 | and observe the bug. For example, did you use @samp{-O}? To guarantee | |
2295 | you won't omit something important, list all the options. | |
2296 | ||
2297 | If we were to try to guess the arguments, we would probably guess wrong | |
2298 | and then we would not encounter the bug. | |
2299 | ||
2300 | @item | |
2301 | The type of machine you are using, and the operating system name and | |
2302 | version number. | |
2303 | ||
2304 | @item | |
2305 | The operands you gave to the @code{configure} command when you installed | |
2306 | the compiler. | |
2307 | ||
2308 | @item | |
2309 | A complete list of any modifications you have made to the compiler | |
2310 | source. (We don't promise to investigate the bug unless it happens in | |
2311 | an unmodified compiler. But if you've made modifications and don't tell | |
2312 | us, then you are sending us on a wild goose chase.) | |
2313 | ||
2314 | Be precise about these changes. A description in English is not | |
2315 | enough---send a context diff for them. | |
2316 | ||
2317 | Adding files of your own (such as a machine description for a machine we | |
2318 | don't support) is a modification of the compiler source. | |
2319 | ||
2320 | @item | |
2321 | Details of any other deviations from the standard procedure for installing | |
2322 | GNU CC. | |
2323 | ||
2324 | @item | |
2325 | A description of what behavior you observe that you believe is | |
2326 | incorrect. For example, ``The compiler gets a fatal signal,'' or, | |
2327 | ``The assembler instruction at line 208 in the output is incorrect.'' | |
2328 | ||
2329 | Of course, if the bug is that the compiler gets a fatal signal, then one | |
2330 | can't miss it. But if the bug is incorrect output, the maintainer might | |
2331 | not notice unless it is glaringly wrong. None of us has time to study | |
2332 | all the assembler code from a 50-line C program just on the chance that | |
2333 | one instruction might be wrong. We need @emph{you} to do this part! | |
2334 | ||
2335 | Even if the problem you experience is a fatal signal, you should still | |
2336 | say so explicitly. Suppose something strange is going on, such as, your | |
2337 | copy of the compiler is out of synch, or you have encountered a bug in | |
2338 | the C library on your system. (This has happened!) Your copy might | |
2339 | crash and the copy here would not. If you @i{said} to expect a crash, | |
2340 | then when the compiler here fails to crash, we would know that the bug | |
2341 | was not happening. If you don't say to expect a crash, then we would | |
2342 | not know whether the bug was happening. We would not be able to draw | |
2343 | any conclusion from our observations. | |
2344 | ||
2345 | If the problem is a diagnostic when compiling GNU CC with some other | |
2346 | compiler, say whether it is a warning or an error. | |
2347 | ||
2348 | Often the observed symptom is incorrect output when your program is run. | |
2349 | Sad to say, this is not enough information unless the program is short | |
2350 | and simple. None of us has time to study a large program to figure out | |
2351 | how it would work if compiled correctly, much less which line of it was | |
2352 | compiled wrong. So you will have to do that. Tell us which source line | |
2353 | it is, and what incorrect result happens when that line is executed. A | |
2354 | person who understands the program can find this as easily as finding a | |
2355 | bug in the program itself. | |
2356 | ||
2357 | @item | |
2358 | If you send examples of assembler code output from GNU CC or GNU C++, | |
2359 | please use @samp{-g} when you make them. The debugging information | |
2360 | includes source line numbers which are essential for correlating the | |
2361 | output with the input. | |
2362 | ||
2363 | @item | |
2364 | If you wish to mention something in the GNU CC source, refer to it by | |
2365 | context, not by line number. | |
2366 | ||
2367 | The line numbers in the development sources don't match those in your | |
2368 | sources. Your line numbers would convey no useful information to the | |
2369 | maintainers. | |
2370 | ||
2371 | @item | |
2372 | Additional information from a debugger might enable someone to find a | |
2373 | problem on a machine which he does not have available. However, you | |
2374 | need to think when you collect this information if you want it to have | |
2375 | any chance of being useful. | |
2376 | ||
2377 | @cindex backtrace for bug reports | |
2378 | For example, many people send just a backtrace, but that is never | |
2379 | useful by itself. A simple backtrace with arguments conveys little | |
2380 | about GNU CC because the compiler is largely data-driven; the same | |
2381 | functions are called over and over for different RTL insns, doing | |
2382 | different things depending on the details of the insn. | |
2383 | ||
2384 | Most of the arguments listed in the backtrace are useless because they | |
2385 | are pointers to RTL list structure. The numeric values of the | |
2386 | pointers, which the debugger prints in the backtrace, have no | |
2387 | significance whatever; all that matters is the contents of the objects | |
2388 | they point to (and most of the contents are other such pointers). | |
2389 | ||
2390 | In addition, most compiler passes consist of one or more loops that | |
2391 | scan the RTL insn sequence. The most vital piece of information about | |
2392 | such a loop---which insn it has reached---is usually in a local variable, | |
2393 | not in an argument. | |
2394 | ||
2395 | @findex debug_rtx | |
2396 | What you need to provide in addition to a backtrace are the values of | |
2397 | the local variables for several stack frames up. When a local | |
2398 | variable or an argument is an RTX, first print its value and then use | |
2399 | the GDB command @code{pr} to print the RTL expression that it points | |
2400 | to. (If GDB doesn't run on your machine, use your debugger to call | |
2401 | the function @code{debug_rtx} with the RTX as an argument.) In | |
2402 | general, whenever a variable is a pointer, its value is no use | |
2403 | without the data it points to. | |
2404 | @end itemize | |
2405 | ||
2406 | Here are some things that are not necessary: | |
2407 | ||
2408 | @itemize @bullet | |
2409 | @item | |
2410 | A description of the envelope of the bug. | |
2411 | ||
2412 | Often people who encounter a bug spend a lot of time investigating | |
2413 | which changes to the input file will make the bug go away and which | |
2414 | changes will not affect it. | |
2415 | ||
2416 | This is often time consuming and not very useful, because the way we | |
2417 | will find the bug is by running a single example under the debugger with | |
2418 | breakpoints, not by pure deduction from a series of examples. You might | |
2419 | as well save your time for something else. | |
2420 | ||
2421 | Of course, if you can find a simpler example to report @emph{instead} of | |
2422 | the original one, that is a convenience. Errors in the output will be | |
2423 | easier to spot, running under the debugger will take less time, etc. | |
2424 | Most GNU CC bugs involve just one function, so the most straightforward | |
2425 | way to simplify an example is to delete all the function definitions | |
2426 | except the one where the bug occurs. Those earlier in the file may be | |
2427 | replaced by external declarations if the crucial function depends on | |
2428 | them. (Exception: inline functions may affect compilation of functions | |
2429 | defined later in the file.) | |
2430 | ||
2431 | However, simplification is not vital; if you don't want to do this, | |
2432 | report the bug anyway and send the entire test case you used. | |
2433 | ||
2434 | @item | |
2435 | In particular, some people insert conditionals @samp{#ifdef BUG} around | |
2436 | a statement which, if removed, makes the bug not happen. These are just | |
2437 | clutter; we won't pay any attention to them anyway. Besides, you should | |
2438 | send us cpp output, and that can't have conditionals. | |
2439 | ||
2440 | @item | |
2441 | A patch for the bug. | |
2442 | ||
2443 | A patch for the bug is useful if it is a good one. But don't omit the | |
2444 | necessary information, such as the test case, on the assumption that a | |
2445 | patch is all we need. We might see problems with your patch and decide | |
2446 | to fix the problem another way, or we might not understand it at all. | |
2447 | ||
2448 | Sometimes with a program as complicated as GNU CC it is very hard to | |
2449 | construct an example that will make the program follow a certain path | |
2450 | through the code. If you don't send the example, we won't be able to | |
2451 | construct one, so we won't be able to verify that the bug is fixed. | |
2452 | ||
2453 | And if we can't understand what bug you are trying to fix, or why your | |
2454 | patch should be an improvement, we won't install it. A test case will | |
2455 | help us to understand. | |
2456 | ||
2457 | @xref{Sending Patches}, for guidelines on how to make it easy for us to | |
2458 | understand and install your patches. | |
2459 | ||
2460 | @item | |
2461 | A guess about what the bug is or what it depends on. | |
2462 | ||
2463 | Such guesses are usually wrong. Even I can't guess right about such | |
2464 | things without first using the debugger to find the facts. | |
2465 | ||
2466 | @item | |
2467 | A core dump file. | |
2468 | ||
2469 | We have no way of examining a core dump for your type of machine | |
2470 | unless we have an identical system---and if we do have one, | |
2471 | we should be able to reproduce the crash ourselves. | |
2472 | @end itemize | |
2473 | ||
2474 | @node Sending Patches,, Bug Reporting, Bugs | |
2475 | @section Sending Patches for GNU CC | |
2476 | ||
2477 | If you would like to write bug fixes or improvements for the GNU C | |
2478 | compiler, that is very helpful. Send suggested fixes to the bug report | |
f2d76545 | 2479 | mailing list, @code{egcs-bugs@@cygnus.com}. |
861bb6c1 JL |
2480 | |
2481 | Please follow these guidelines so we can study your patches efficiently. | |
2482 | If you don't follow these guidelines, your information might still be | |
2483 | useful, but using it will take extra work. Maintaining GNU C is a lot | |
2484 | of work in the best of circumstances, and we can't keep up unless you do | |
2485 | your best to help. | |
2486 | ||
2487 | @itemize @bullet | |
2488 | @item | |
2489 | Send an explanation with your changes of what problem they fix or what | |
2490 | improvement they bring about. For a bug fix, just include a copy of the | |
2491 | bug report, and explain why the change fixes the bug. | |
2492 | ||
2493 | (Referring to a bug report is not as good as including it, because then | |
2494 | we will have to look it up, and we have probably already deleted it if | |
2495 | we've already fixed the bug.) | |
2496 | ||
2497 | @item | |
2498 | Always include a proper bug report for the problem you think you have | |
2499 | fixed. We need to convince ourselves that the change is right before | |
2500 | installing it. Even if it is right, we might have trouble judging it if | |
2501 | we don't have a way to reproduce the problem. | |
2502 | ||
2503 | @item | |
2504 | Include all the comments that are appropriate to help people reading the | |
2505 | source in the future understand why this change was needed. | |
2506 | ||
2507 | @item | |
2508 | Don't mix together changes made for different reasons. | |
2509 | Send them @emph{individually}. | |
2510 | ||
2511 | If you make two changes for separate reasons, then we might not want to | |
2512 | install them both. We might want to install just one. If you send them | |
2513 | all jumbled together in a single set of diffs, we have to do extra work | |
2514 | to disentangle them---to figure out which parts of the change serve | |
2515 | which purpose. If we don't have time for this, we might have to ignore | |
2516 | your changes entirely. | |
2517 | ||
2518 | If you send each change as soon as you have written it, with its own | |
2519 | explanation, then the two changes never get tangled up, and we can | |
2520 | consider each one properly without any extra work to disentangle them. | |
2521 | ||
2522 | Ideally, each change you send should be impossible to subdivide into | |
2523 | parts that we might want to consider separately, because each of its | |
2524 | parts gets its motivation from the other parts. | |
2525 | ||
2526 | @item | |
2527 | Send each change as soon as that change is finished. Sometimes people | |
2528 | think they are helping us by accumulating many changes to send them all | |
2529 | together. As explained above, this is absolutely the worst thing you | |
2530 | could do. | |
2531 | ||
2532 | Since you should send each change separately, you might as well send it | |
2533 | right away. That gives us the option of installing it immediately if it | |
2534 | is important. | |
2535 | ||
2536 | @item | |
2537 | Use @samp{diff -c} to make your diffs. Diffs without context are hard | |
2538 | for us to install reliably. More than that, they make it hard for us to | |
2539 | study the diffs to decide whether we want to install them. Unidiff | |
2540 | format is better than contextless diffs, but not as easy to read as | |
2541 | @samp{-c} format. | |
2542 | ||
2543 | If you have GNU diff, use @samp{diff -cp}, which shows the name of the | |
2544 | function that each change occurs in. | |
2545 | ||
2546 | @item | |
2547 | Write the change log entries for your changes. We get lots of changes, | |
2548 | and we don't have time to do all the change log writing ourselves. | |
2549 | ||
2550 | Read the @file{ChangeLog} file to see what sorts of information to put | |
2551 | in, and to learn the style that we use. The purpose of the change log | |
2552 | is to show people where to find what was changed. So you need to be | |
2553 | specific about what functions you changed; in large functions, it's | |
2554 | often helpful to indicate where within the function the change was. | |
2555 | ||
2556 | On the other hand, once you have shown people where to find the change, | |
2557 | you need not explain its purpose. Thus, if you add a new function, all | |
2558 | you need to say about it is that it is new. If you feel that the | |
2559 | purpose needs explaining, it probably does---but the explanation will be | |
2560 | much more useful if you put it in comments in the code. | |
2561 | ||
2562 | If you would like your name to appear in the header line for who made | |
2563 | the change, send us the header line. | |
2564 | ||
2565 | @item | |
2566 | When you write the fix, keep in mind that we can't install a change that | |
2567 | would break other systems. | |
2568 | ||
2569 | People often suggest fixing a problem by changing machine-independent | |
2570 | files such as @file{toplev.c} to do something special that a particular | |
2571 | system needs. Sometimes it is totally obvious that such changes would | |
2572 | break GNU CC for almost all users. We can't possibly make a change like | |
2573 | that. At best it might tell us how to write another patch that would | |
2574 | solve the problem acceptably. | |
2575 | ||
2576 | Sometimes people send fixes that @emph{might} be an improvement in | |
2577 | general---but it is hard to be sure of this. It's hard to install | |
2578 | such changes because we have to study them very carefully. Of course, | |
2579 | a good explanation of the reasoning by which you concluded the change | |
2580 | was correct can help convince us. | |
2581 | ||
2582 | The safest changes are changes to the configuration files for a | |
2583 | particular machine. These are safe because they can't create new bugs | |
2584 | on other machines. | |
2585 | ||
2586 | Please help us keep up with the workload by designing the patch in a | |
2587 | form that is good to install. | |
2588 | @end itemize | |
2589 | ||
2590 | @node Service | |
2591 | @chapter How To Get Help with GNU CC | |
2592 | ||
2593 | If you need help installing, using or changing GNU CC, there are two | |
2594 | ways to find it: | |
2595 | ||
2596 | @itemize @bullet | |
2597 | @item | |
2598 | Send a message to a suitable network mailing list. First try | |
f2d76545 JL |
2599 | @code{egcs-bugs@@cygnus.com}, and if that brings no response, try |
2600 | @code{egcs@@cygnus.com}. | |
861bb6c1 JL |
2601 | |
2602 | @item | |
2603 | Look in the service directory for someone who might help you for a fee. | |
2604 | The service directory is found in the file named @file{SERVICE} in the | |
2605 | GNU CC distribution. | |
2606 | @end itemize | |
2607 | ||
2608 | @node Contributing | |
2609 | @chapter Contributing to GNU CC Development | |
2610 | ||
2611 | If you would like to help pretest GNU CC releases to assure they work | |
2612 | well, or if you would like to work on improving GNU CC, please contact | |
f2d76545 | 2613 | the maintainers at @code{egcs@@cygnus.com}. A pretester should |
861bb6c1 JL |
2614 | be willing to try to investigate bugs as well as report them. |
2615 | ||
2616 | If you'd like to work on improvements, please ask for suggested projects | |
2617 | or suggest your own ideas. If you have already written an improvement, | |
2618 | please tell us about it. If you have not yet started work, it is useful | |
f2d76545 | 2619 | to contact @code{egcs@@cygnus.com} before you start; the |
861bb6c1 JL |
2620 | maintainers may be able to suggest ways to make your extension fit in |
2621 | better with the rest of GNU CC and with other development plans. | |
2622 | ||
2623 | @node VMS | |
2624 | @chapter Using GNU CC on VMS | |
2625 | ||
2626 | @c prevent bad page break with this line | |
2627 | Here is how to use GNU CC on VMS. | |
2628 | ||
2629 | @menu | |
2630 | * Include Files and VMS:: Where the preprocessor looks for the include files. | |
2631 | * Global Declarations:: How to do globaldef, globalref and globalvalue with | |
2632 | GNU CC. | |
2633 | * VMS Misc:: Misc information. | |
2634 | @end menu | |
2635 | ||
2636 | @node Include Files and VMS | |
2637 | @section Include Files and VMS | |
2638 | ||
2639 | @cindex include files and VMS | |
2640 | @cindex VMS and include files | |
2641 | @cindex header files and VMS | |
2642 | Due to the differences between the filesystems of Unix and VMS, GNU CC | |
2643 | attempts to translate file names in @samp{#include} into names that VMS | |
2644 | will understand. The basic strategy is to prepend a prefix to the | |
2645 | specification of the include file, convert the whole filename to a VMS | |
2646 | filename, and then try to open the file. GNU CC tries various prefixes | |
2647 | one by one until one of them succeeds: | |
2648 | ||
2649 | @enumerate | |
2650 | @item | |
2651 | The first prefix is the @samp{GNU_CC_INCLUDE:} logical name: this is | |
2652 | where GNU C header files are traditionally stored. If you wish to store | |
2653 | header files in non-standard locations, then you can assign the logical | |
2654 | @samp{GNU_CC_INCLUDE} to be a search list, where each element of the | |
2655 | list is suitable for use with a rooted logical. | |
2656 | ||
2657 | @item | |
2658 | The next prefix tried is @samp{SYS$SYSROOT:[SYSLIB.]}. This is where | |
2659 | VAX-C header files are traditionally stored. | |
2660 | ||
2661 | @item | |
2662 | If the include file specification by itself is a valid VMS filename, the | |
2663 | preprocessor then uses this name with no prefix in an attempt to open | |
2664 | the include file. | |
2665 | ||
2666 | @item | |
2667 | If the file specification is not a valid VMS filename (i.e. does not | |
2668 | contain a device or a directory specifier, and contains a @samp{/} | |
2669 | character), the preprocessor tries to convert it from Unix syntax to | |
2670 | VMS syntax. | |
2671 | ||
2672 | Conversion works like this: the first directory name becomes a device, | |
2673 | and the rest of the directories are converted into VMS-format directory | |
2674 | names. For example, the name @file{X11/foobar.h} is | |
2675 | translated to @file{X11:[000000]foobar.h} or @file{X11:foobar.h}, | |
2676 | whichever one can be opened. This strategy allows you to assign a | |
2677 | logical name to point to the actual location of the header files. | |
2678 | ||
2679 | @item | |
2680 | If none of these strategies succeeds, the @samp{#include} fails. | |
2681 | @end enumerate | |
2682 | ||
2683 | Include directives of the form: | |
2684 | ||
2685 | @example | |
2686 | #include foobar | |
2687 | @end example | |
2688 | ||
2689 | @noindent | |
2690 | are a common source of incompatibility between VAX-C and GNU CC. VAX-C | |
2691 | treats this much like a standard @code{#include <foobar.h>} directive. | |
2692 | That is incompatible with the ANSI C behavior implemented by GNU CC: to | |
2693 | expand the name @code{foobar} as a macro. Macro expansion should | |
2694 | eventually yield one of the two standard formats for @code{#include}: | |
2695 | ||
2696 | @example | |
2697 | #include "@var{file}" | |
2698 | #include <@var{file}> | |
2699 | @end example | |
2700 | ||
2701 | If you have this problem, the best solution is to modify the source to | |
2702 | convert the @code{#include} directives to one of the two standard forms. | |
2703 | That will work with either compiler. If you want a quick and dirty fix, | |
2704 | define the file names as macros with the proper expansion, like this: | |
2705 | ||
2706 | @example | |
2707 | #define stdio <stdio.h> | |
2708 | @end example | |
2709 | ||
2710 | @noindent | |
2711 | This will work, as long as the name doesn't conflict with anything else | |
2712 | in the program. | |
2713 | ||
2714 | Another source of incompatibility is that VAX-C assumes that: | |
2715 | ||
2716 | @example | |
2717 | #include "foobar" | |
2718 | @end example | |
2719 | ||
2720 | @noindent | |
2721 | is actually asking for the file @file{foobar.h}. GNU CC does not | |
2722 | make this assumption, and instead takes what you ask for literally; | |
2723 | it tries to read the file @file{foobar}. The best way to avoid this | |
2724 | problem is to always specify the desired file extension in your include | |
2725 | directives. | |
2726 | ||
2727 | GNU CC for VMS is distributed with a set of include files that is | |
2728 | sufficient to compile most general purpose programs. Even though the | |
2729 | GNU CC distribution does not contain header files to define constants | |
2730 | and structures for some VMS system-specific functions, there is no | |
2731 | reason why you cannot use GNU CC with any of these functions. You first | |
2732 | may have to generate or create header files, either by using the public | |
2733 | domain utility @code{UNSDL} (which can be found on a DECUS tape), or by | |
2734 | extracting the relevant modules from one of the system macro libraries, | |
2735 | and using an editor to construct a C header file. | |
2736 | ||
2737 | A @code{#include} file name cannot contain a DECNET node name. The | |
2738 | preprocessor reports an I/O error if you attempt to use a node name, | |
2739 | whether explicitly, or implicitly via a logical name. | |
2740 | ||
2741 | @node Global Declarations | |
2742 | @section Global Declarations and VMS | |
2743 | ||
2744 | @findex GLOBALREF | |
2745 | @findex GLOBALDEF | |
2746 | @findex GLOBALVALUEDEF | |
2747 | @findex GLOBALVALUEREF | |
2748 | GNU CC does not provide the @code{globalref}, @code{globaldef} and | |
2749 | @code{globalvalue} keywords of VAX-C. You can get the same effect with | |
2750 | an obscure feature of GAS, the GNU assembler. (This requires GAS | |
2751 | version 1.39 or later.) The following macros allow you to use this | |
2752 | feature in a fairly natural way: | |
2753 | ||
2754 | @smallexample | |
2755 | #ifdef __GNUC__ | |
2756 | #define GLOBALREF(TYPE,NAME) \ | |
2757 | TYPE NAME \ | |
2758 | asm ("_$$PsectAttributes_GLOBALSYMBOL$$" #NAME) | |
2759 | #define GLOBALDEF(TYPE,NAME,VALUE) \ | |
2760 | TYPE NAME \ | |
2761 | asm ("_$$PsectAttributes_GLOBALSYMBOL$$" #NAME) \ | |
2762 | = VALUE | |
2763 | #define GLOBALVALUEREF(TYPE,NAME) \ | |
2764 | const TYPE NAME[1] \ | |
2765 | asm ("_$$PsectAttributes_GLOBALVALUE$$" #NAME) | |
2766 | #define GLOBALVALUEDEF(TYPE,NAME,VALUE) \ | |
2767 | const TYPE NAME[1] \ | |
2768 | asm ("_$$PsectAttributes_GLOBALVALUE$$" #NAME) \ | |
2769 | = @{VALUE@} | |
2770 | #else | |
2771 | #define GLOBALREF(TYPE,NAME) \ | |
2772 | globalref TYPE NAME | |
2773 | #define GLOBALDEF(TYPE,NAME,VALUE) \ | |
2774 | globaldef TYPE NAME = VALUE | |
2775 | #define GLOBALVALUEDEF(TYPE,NAME,VALUE) \ | |
2776 | globalvalue TYPE NAME = VALUE | |
2777 | #define GLOBALVALUEREF(TYPE,NAME) \ | |
2778 | globalvalue TYPE NAME | |
2779 | #endif | |
2780 | @end smallexample | |
2781 | ||
2782 | @noindent | |
2783 | (The @code{_$$PsectAttributes_GLOBALSYMBOL} prefix at the start of the | |
2784 | name is removed by the assembler, after it has modified the attributes | |
2785 | of the symbol). These macros are provided in the VMS binaries | |
2786 | distribution in a header file @file{GNU_HACKS.H}. An example of the | |
2787 | usage is: | |
2788 | ||
2789 | @example | |
2790 | GLOBALREF (int, ijk); | |
2791 | GLOBALDEF (int, jkl, 0); | |
2792 | @end example | |
2793 | ||
2794 | The macros @code{GLOBALREF} and @code{GLOBALDEF} cannot be used | |
2795 | straightforwardly for arrays, since there is no way to insert the array | |
2796 | dimension into the declaration at the right place. However, you can | |
2797 | declare an array with these macros if you first define a typedef for the | |
2798 | array type, like this: | |
2799 | ||
2800 | @example | |
2801 | typedef int intvector[10]; | |
2802 | GLOBALREF (intvector, foo); | |
2803 | @end example | |
2804 | ||
2805 | Array and structure initializers will also break the macros; you can | |
2806 | define the initializer to be a macro of its own, or you can expand the | |
2807 | @code{GLOBALDEF} macro by hand. You may find a case where you wish to | |
2808 | use the @code{GLOBALDEF} macro with a large array, but you are not | |
2809 | interested in explicitly initializing each element of the array. In | |
2810 | such cases you can use an initializer like: @code{@{0,@}}, which will | |
2811 | initialize the entire array to @code{0}. | |
2812 | ||
2813 | A shortcoming of this implementation is that a variable declared with | |
2814 | @code{GLOBALVALUEREF} or @code{GLOBALVALUEDEF} is always an array. For | |
2815 | example, the declaration: | |
2816 | ||
2817 | @example | |
2818 | GLOBALVALUEREF(int, ijk); | |
2819 | @end example | |
2820 | ||
2821 | @noindent | |
2822 | declares the variable @code{ijk} as an array of type @code{int [1]}. | |
2823 | This is done because a globalvalue is actually a constant; its ``value'' | |
2824 | is what the linker would normally consider an address. That is not how | |
2825 | an integer value works in C, but it is how an array works. So treating | |
2826 | the symbol as an array name gives consistent results---with the | |
2827 | exception that the value seems to have the wrong type. @strong{Don't | |
2828 | try to access an element of the array.} It doesn't have any elements. | |
2829 | The array ``address'' may not be the address of actual storage. | |
2830 | ||
2831 | The fact that the symbol is an array may lead to warnings where the | |
2832 | variable is used. Insert type casts to avoid the warnings. Here is an | |
2833 | example; it takes advantage of the ANSI C feature allowing macros that | |
2834 | expand to use the same name as the macro itself. | |
2835 | ||
2836 | @example | |
2837 | GLOBALVALUEREF (int, ss$_normal); | |
2838 | GLOBALVALUEDEF (int, xyzzy,123); | |
2839 | #ifdef __GNUC__ | |
2840 | #define ss$_normal ((int) ss$_normal) | |
2841 | #define xyzzy ((int) xyzzy) | |
2842 | #endif | |
2843 | @end example | |
2844 | ||
2845 | Don't use @code{globaldef} or @code{globalref} with a variable whose | |
2846 | type is an enumeration type; this is not implemented. Instead, make the | |
2847 | variable an integer, and use a @code{globalvaluedef} for each of the | |
2848 | enumeration values. An example of this would be: | |
2849 | ||
2850 | @example | |
2851 | #ifdef __GNUC__ | |
2852 | GLOBALDEF (int, color, 0); | |
2853 | GLOBALVALUEDEF (int, RED, 0); | |
2854 | GLOBALVALUEDEF (int, BLUE, 1); | |
2855 | GLOBALVALUEDEF (int, GREEN, 3); | |
2856 | #else | |
2857 | enum globaldef color @{RED, BLUE, GREEN = 3@}; | |
2858 | #endif | |
2859 | @end example | |
2860 | ||
2861 | @node VMS Misc | |
2862 | @section Other VMS Issues | |
2863 | ||
2864 | @cindex exit status and VMS | |
2865 | @cindex return value of @code{main} | |
2866 | @cindex @code{main} and the exit status | |
2867 | GNU CC automatically arranges for @code{main} to return 1 by default if | |
2868 | you fail to specify an explicit return value. This will be interpreted | |
2869 | by VMS as a status code indicating a normal successful completion. | |
2870 | Version 1 of GNU CC did not provide this default. | |
2871 | ||
2872 | GNU CC on VMS works only with the GNU assembler, GAS. You need version | |
2873 | 1.37 or later of GAS in order to produce value debugging information for | |
2874 | the VMS debugger. Use the ordinary VMS linker with the object files | |
2875 | produced by GAS. | |
2876 | ||
2877 | @cindex shared VMS run time system | |
2878 | @cindex @file{VAXCRTL} | |
2879 | Under previous versions of GNU CC, the generated code would occasionally | |
2880 | give strange results when linked to the sharable @file{VAXCRTL} library. | |
2881 | Now this should work. | |
2882 | ||
2883 | A caveat for use of @code{const} global variables: the @code{const} | |
2884 | modifier must be specified in every external declaration of the variable | |
2885 | in all of the source files that use that variable. Otherwise the linker | |
2886 | will issue warnings about conflicting attributes for the variable. Your | |
2887 | program will still work despite the warnings, but the variable will be | |
2888 | placed in writable storage. | |
2889 | ||
2890 | @cindex name augmentation | |
2891 | @cindex case sensitivity and VMS | |
2892 | @cindex VMS and case sensitivity | |
2893 | Although the VMS linker does distinguish between upper and lower case | |
2894 | letters in global symbols, most VMS compilers convert all such symbols | |
2895 | into upper case and most run-time library routines also have upper case | |
2896 | names. To be able to reliably call such routines, GNU CC (by means of | |
2897 | the assembler GAS) converts global symbols into upper case like other | |
2898 | VMS compilers. However, since the usual practice in C is to distinguish | |
2899 | case, GNU CC (via GAS) tries to preserve usual C behavior by augmenting | |
2900 | each name that is not all lower case. This means truncating the name | |
2901 | to at most 23 characters and then adding more characters at the end | |
2902 | which encode the case pattern of those 23. Names which contain at | |
2903 | least one dollar sign are an exception; they are converted directly into | |
2904 | upper case without augmentation. | |
2905 | ||
2906 | Name augmentation yields bad results for programs that use precompiled | |
2907 | libraries (such as Xlib) which were generated by another compiler. You | |
2908 | can use the compiler option @samp{/NOCASE_HACK} to inhibit augmentation; | |
2909 | it makes external C functions and variables case-independent as is usual | |
2910 | on VMS. Alternatively, you could write all references to the functions | |
2911 | and variables in such libraries using lower case; this will work on VMS, | |
2912 | but is not portable to other systems. The compiler option @samp{/NAMES} | |
2913 | also provides control over global name handling. | |
2914 | ||
2915 | Function and variable names are handled somewhat differently with GNU | |
2916 | C++. The GNU C++ compiler performs @dfn{name mangling} on function | |
2917 | names, which means that it adds information to the function name to | |
2918 | describe the data types of the arguments that the function takes. One | |
2919 | result of this is that the name of a function can become very long. | |
2920 | Since the VMS linker only recognizes the first 31 characters in a name, | |
2921 | special action is taken to ensure that each function and variable has a | |
2922 | unique name that can be represented in 31 characters. | |
2923 | ||
2924 | If the name (plus a name augmentation, if required) is less than 32 | |
2925 | characters in length, then no special action is performed. If the name | |
2926 | is longer than 31 characters, the assembler (GAS) will generate a | |
2927 | hash string based upon the function name, truncate the function name to | |
2928 | 23 characters, and append the hash string to the truncated name. If the | |
2929 | @samp{/VERBOSE} compiler option is used, the assembler will print both | |
2930 | the full and truncated names of each symbol that is truncated. | |
2931 | ||
2932 | The @samp{/NOCASE_HACK} compiler option should not be used when you are | |
2933 | compiling programs that use libg++. libg++ has several instances of | |
2934 | objects (i.e. @code{Filebuf} and @code{filebuf}) which become | |
2935 | indistinguishable in a case-insensitive environment. This leads to | |
2936 | cases where you need to inhibit augmentation selectively (if you were | |
2937 | using libg++ and Xlib in the same program, for example). There is no | |
2938 | special feature for doing this, but you can get the result by defining a | |
2939 | macro for each mixed case symbol for which you wish to inhibit | |
2940 | augmentation. The macro should expand into the lower case equivalent of | |
2941 | itself. For example: | |
2942 | ||
2943 | @example | |
2944 | #define StuDlyCapS studlycaps | |
2945 | @end example | |
2946 | ||
2947 | These macro definitions can be placed in a header file to minimize the | |
2948 | number of changes to your source code. | |
2949 | @end ifset | |
2950 | ||
2951 | @ifset INTERNALS | |
2952 | @node Portability | |
2953 | @chapter GNU CC and Portability | |
2954 | @cindex portability | |
2955 | @cindex GNU CC and portability | |
2956 | ||
2957 | The main goal of GNU CC was to make a good, fast compiler for machines in | |
2958 | the class that the GNU system aims to run on: 32-bit machines that address | |
2959 | 8-bit bytes and have several general registers. Elegance, theoretical | |
2960 | power and simplicity are only secondary. | |
2961 | ||
2962 | GNU CC gets most of the information about the target machine from a machine | |
2963 | description which gives an algebraic formula for each of the machine's | |
2964 | instructions. This is a very clean way to describe the target. But when | |
2965 | the compiler needs information that is difficult to express in this | |
2966 | fashion, I have not hesitated to define an ad-hoc parameter to the machine | |
2967 | description. The purpose of portability is to reduce the total work needed | |
2968 | on the compiler; it was not of interest for its own sake. | |
2969 | ||
2970 | @cindex endianness | |
2971 | @cindex autoincrement addressing, availability | |
2972 | @findex abort | |
2973 | GNU CC does not contain machine dependent code, but it does contain code | |
2974 | that depends on machine parameters such as endianness (whether the most | |
2975 | significant byte has the highest or lowest address of the bytes in a word) | |
2976 | and the availability of autoincrement addressing. In the RTL-generation | |
2977 | pass, it is often necessary to have multiple strategies for generating code | |
2978 | for a particular kind of syntax tree, strategies that are usable for different | |
2979 | combinations of parameters. Often I have not tried to address all possible | |
2980 | cases, but only the common ones or only the ones that I have encountered. | |
2981 | As a result, a new target may require additional strategies. You will know | |
2982 | if this happens because the compiler will call @code{abort}. Fortunately, | |
2983 | the new strategies can be added in a machine-independent fashion, and will | |
2984 | affect only the target machines that need them. | |
2985 | @end ifset | |
2986 | ||
2987 | @ifset INTERNALS | |
2988 | @node Interface | |
2989 | @chapter Interfacing to GNU CC Output | |
2990 | @cindex interfacing to GNU CC output | |
2991 | @cindex run-time conventions | |
2992 | @cindex function call conventions | |
2993 | @cindex conventions, run-time | |
2994 | ||
2995 | GNU CC is normally configured to use the same function calling convention | |
2996 | normally in use on the target system. This is done with the | |
2997 | machine-description macros described (@pxref{Target Macros}). | |
2998 | ||
2999 | @cindex unions, returning | |
3000 | @cindex structures, returning | |
3001 | @cindex returning structures and unions | |
3002 | However, returning of structure and union values is done differently on | |
3003 | some target machines. As a result, functions compiled with PCC | |
3004 | returning such types cannot be called from code compiled with GNU CC, | |
3005 | and vice versa. This does not cause trouble often because few Unix | |
3006 | library routines return structures or unions. | |
3007 | ||
3008 | GNU CC code returns structures and unions that are 1, 2, 4 or 8 bytes | |
3009 | long in the same registers used for @code{int} or @code{double} return | |
3010 | values. (GNU CC typically allocates variables of such types in | |
3011 | registers also.) Structures and unions of other sizes are returned by | |
3012 | storing them into an address passed by the caller (usually in a | |
3013 | register). The machine-description macros @code{STRUCT_VALUE} and | |
3014 | @code{STRUCT_INCOMING_VALUE} tell GNU CC where to pass this address. | |
3015 | ||
3016 | By contrast, PCC on most target machines returns structures and unions | |
3017 | of any size by copying the data into an area of static storage, and then | |
3018 | returning the address of that storage as if it were a pointer value. | |
3019 | The caller must copy the data from that memory area to the place where | |
3020 | the value is wanted. This is slower than the method used by GNU CC, and | |
3021 | fails to be reentrant. | |
3022 | ||
3023 | On some target machines, such as RISC machines and the 80386, the | |
3024 | standard system convention is to pass to the subroutine the address of | |
3025 | where to return the value. On these machines, GNU CC has been | |
3026 | configured to be compatible with the standard compiler, when this method | |
3027 | is used. It may not be compatible for structures of 1, 2, 4 or 8 bytes. | |
3028 | ||
3029 | @cindex argument passing | |
3030 | @cindex passing arguments | |
3031 | GNU CC uses the system's standard convention for passing arguments. On | |
3032 | some machines, the first few arguments are passed in registers; in | |
3033 | others, all are passed on the stack. It would be possible to use | |
3034 | registers for argument passing on any machine, and this would probably | |
3035 | result in a significant speedup. But the result would be complete | |
3036 | incompatibility with code that follows the standard convention. So this | |
3037 | change is practical only if you are switching to GNU CC as the sole C | |
3038 | compiler for the system. We may implement register argument passing on | |
3039 | certain machines once we have a complete GNU system so that we can | |
3040 | compile the libraries with GNU CC. | |
3041 | ||
3042 | On some machines (particularly the Sparc), certain types of arguments | |
3043 | are passed ``by invisible reference''. This means that the value is | |
3044 | stored in memory, and the address of the memory location is passed to | |
3045 | the subroutine. | |
3046 | ||
3047 | @cindex @code{longjmp} and automatic variables | |
3048 | If you use @code{longjmp}, beware of automatic variables. ANSI C says that | |
3049 | automatic variables that are not declared @code{volatile} have undefined | |
3050 | values after a @code{longjmp}. And this is all GNU CC promises to do, | |
3051 | because it is very difficult to restore register variables correctly, and | |
3052 | one of GNU CC's features is that it can put variables in registers without | |
3053 | your asking it to. | |
3054 | ||
3055 | If you want a variable to be unaltered by @code{longjmp}, and you don't | |
3056 | want to write @code{volatile} because old C compilers don't accept it, | |
3057 | just take the address of the variable. If a variable's address is ever | |
3058 | taken, even if just to compute it and ignore it, then the variable cannot | |
3059 | go in a register: | |
3060 | ||
3061 | @example | |
3062 | @{ | |
3063 | int careful; | |
3064 | &careful; | |
3065 | @dots{} | |
3066 | @} | |
3067 | @end example | |
3068 | ||
3069 | @cindex arithmetic libraries | |
3070 | @cindex math libraries | |
3071 | Code compiled with GNU CC may call certain library routines. Most of | |
3072 | them handle arithmetic for which there are no instructions. This | |
3073 | includes multiply and divide on some machines, and floating point | |
3074 | operations on any machine for which floating point support is disabled | |
3075 | with @samp{-msoft-float}. Some standard parts of the C library, such as | |
3076 | @code{bcopy} or @code{memcpy}, are also called automatically. The usual | |
3077 | function call interface is used for calling the library routines. | |
3078 | ||
3079 | These library routines should be defined in the library @file{libgcc.a}, | |
3080 | which GNU CC automatically searches whenever it links a program. On | |
3081 | machines that have multiply and divide instructions, if hardware | |
3082 | floating point is in use, normally @file{libgcc.a} is not needed, but it | |
3083 | is searched just in case. | |
3084 | ||
3085 | Each arithmetic function is defined in @file{libgcc1.c} to use the | |
3086 | corresponding C arithmetic operator. As long as the file is compiled | |
3087 | with another C compiler, which supports all the C arithmetic operators, | |
3088 | this file will work portably. However, @file{libgcc1.c} does not work if | |
3089 | compiled with GNU CC, because each arithmetic function would compile | |
3090 | into a call to itself! | |
3091 | @end ifset | |
3092 | ||
3093 | @ifset INTERNALS | |
3094 | @node Passes | |
3095 | @chapter Passes and Files of the Compiler | |
3096 | @cindex passes and files of the compiler | |
3097 | @cindex files and passes of the compiler | |
3098 | @cindex compiler passes and files | |
3099 | ||
3100 | @cindex top level of compiler | |
3101 | The overall control structure of the compiler is in @file{toplev.c}. This | |
3102 | file is responsible for initialization, decoding arguments, opening and | |
3103 | closing files, and sequencing the passes. | |
3104 | ||
3105 | @cindex parsing pass | |
3106 | The parsing pass is invoked only once, to parse the entire input. The RTL | |
3107 | intermediate code for a function is generated as the function is parsed, a | |
3108 | statement at a time. Each statement is read in as a syntax tree and then | |
3109 | converted to RTL; then the storage for the tree for the statement is | |
3110 | reclaimed. Storage for types (and the expressions for their sizes), | |
3111 | declarations, and a representation of the binding contours and how they nest, | |
3112 | remain until the function is finished being compiled; these are all needed | |
3113 | to output the debugging information. | |
3114 | ||
3115 | @findex rest_of_compilation | |
3116 | @findex rest_of_decl_compilation | |
3117 | Each time the parsing pass reads a complete function definition or | |
3118 | top-level declaration, it calls either the function | |
3119 | @code{rest_of_compilation}, or the function | |
3120 | @code{rest_of_decl_compilation} in @file{toplev.c}, which are | |
3121 | responsible for all further processing necessary, ending with output of | |
3122 | the assembler language. All other compiler passes run, in sequence, | |
3123 | within @code{rest_of_compilation}. When that function returns from | |
3124 | compiling a function definition, the storage used for that function | |
3125 | definition's compilation is entirely freed, unless it is an inline | |
3126 | function | |
3127 | @ifset USING | |
3128 | (@pxref{Inline,,An Inline Function is As Fast As a Macro}). | |
3129 | @end ifset | |
3130 | @ifclear USING | |
3131 | (@pxref{Inline,,An Inline Function is As Fast As a Macro,gcc.texi,Using GCC}). | |
3132 | @end ifclear | |
3133 | ||
3134 | Here is a list of all the passes of the compiler and their source files. | |
3135 | Also included is a description of where debugging dumps can be requested | |
3136 | with @samp{-d} options. | |
3137 | ||
3138 | @itemize @bullet | |
3139 | @item | |
3140 | Parsing. This pass reads the entire text of a function definition, | |
3141 | constructing partial syntax trees. This and RTL generation are no longer | |
3142 | truly separate passes (formerly they were), but it is easier to think | |
3143 | of them as separate. | |
3144 | ||
3145 | The tree representation does not entirely follow C syntax, because it is | |
3146 | intended to support other languages as well. | |
3147 | ||
3148 | Language-specific data type analysis is also done in this pass, and every | |
3149 | tree node that represents an expression has a data type attached. | |
3150 | Variables are represented as declaration nodes. | |
3151 | ||
3152 | @cindex constant folding | |
3153 | @cindex arithmetic simplifications | |
3154 | @cindex simplifications, arithmetic | |
3155 | Constant folding and some arithmetic simplifications are also done | |
3156 | during this pass. | |
3157 | ||
3158 | The language-independent source files for parsing are | |
3159 | @file{stor-layout.c}, @file{fold-const.c}, and @file{tree.c}. | |
3160 | There are also header files @file{tree.h} and @file{tree.def} | |
3161 | which define the format of the tree representation.@refill | |
3162 | ||
3163 | @c Avoiding overfull is tricky here. | |
3164 | The source files to parse C are | |
3165 | @file{c-parse.in}, | |
3166 | @file{c-decl.c}, | |
3167 | @file{c-typeck.c}, | |
3168 | @file{c-aux-info.c}, | |
3169 | @file{c-convert.c}, | |
3170 | and @file{c-lang.c} | |
3171 | along with header files | |
3172 | @file{c-lex.h}, and | |
3173 | @file{c-tree.h}. | |
3174 | ||
3175 | The source files for parsing C++ are @file{cp-parse.y}, | |
3176 | @file{cp-class.c},@* | |
3177 | @file{cp-cvt.c}, @file{cp-decl.c}, @file{cp-decl2.c}, | |
3178 | @file{cp-dem.c}, @file{cp-except.c},@* | |
3179 | @file{cp-expr.c}, @file{cp-init.c}, @file{cp-lex.c}, | |
3180 | @file{cp-method.c}, @file{cp-ptree.c},@* | |
3181 | @file{cp-search.c}, @file{cp-tree.c}, @file{cp-type2.c}, and | |
3182 | @file{cp-typeck.c}, along with header files @file{cp-tree.def}, | |
3183 | @file{cp-tree.h}, and @file{cp-decl.h}. | |
3184 | ||
3185 | The special source files for parsing Objective C are | |
3186 | @file{objc-parse.y}, @file{objc-actions.c}, @file{objc-tree.def}, and | |
3187 | @file{objc-actions.h}. Certain C-specific files are used for this as | |
3188 | well. | |
3189 | ||
3190 | The file @file{c-common.c} is also used for all of the above languages. | |
3191 | ||
3192 | @cindex RTL generation | |
3193 | @item | |
3194 | RTL generation. This is the conversion of syntax tree into RTL code. | |
3195 | It is actually done statement-by-statement during parsing, but for | |
3196 | most purposes it can be thought of as a separate pass. | |
3197 | ||
3198 | @cindex target-parameter-dependent code | |
3199 | This is where the bulk of target-parameter-dependent code is found, | |
3200 | since often it is necessary for strategies to apply only when certain | |
3201 | standard kinds of instructions are available. The purpose of named | |
3202 | instruction patterns is to provide this information to the RTL | |
3203 | generation pass. | |
3204 | ||
3205 | @cindex tail recursion optimization | |
3206 | Optimization is done in this pass for @code{if}-conditions that are | |
3207 | comparisons, boolean operations or conditional expressions. Tail | |
3208 | recursion is detected at this time also. Decisions are made about how | |
3209 | best to arrange loops and how to output @code{switch} statements. | |
3210 | ||
3211 | @c Avoiding overfull is tricky here. | |
3212 | The source files for RTL generation include | |
3213 | @file{stmt.c}, | |
3214 | @file{calls.c}, | |
3215 | @file{expr.c}, | |
3216 | @file{explow.c}, | |
3217 | @file{expmed.c}, | |
3218 | @file{function.c}, | |
3219 | @file{optabs.c} | |
3220 | and @file{emit-rtl.c}. | |
3221 | Also, the file | |
3222 | @file{insn-emit.c}, generated from the machine description by the | |
3223 | program @code{genemit}, is used in this pass. The header file | |
3224 | @file{expr.h} is used for communication within this pass.@refill | |
3225 | ||
3226 | @findex genflags | |
3227 | @findex gencodes | |
3228 | The header files @file{insn-flags.h} and @file{insn-codes.h}, | |
3229 | generated from the machine description by the programs @code{genflags} | |
3230 | and @code{gencodes}, tell this pass which standard names are available | |
3231 | for use and which patterns correspond to them.@refill | |
3232 | ||
3233 | Aside from debugging information output, none of the following passes | |
3234 | refers to the tree structure representation of the function (only | |
3235 | part of which is saved). | |
3236 | ||
3237 | @cindex inline, automatic | |
3238 | The decision of whether the function can and should be expanded inline | |
3239 | in its subsequent callers is made at the end of rtl generation. The | |
3240 | function must meet certain criteria, currently related to the size of | |
3241 | the function and the types and number of parameters it has. Note that | |
3242 | this function may contain loops, recursive calls to itself | |
3243 | (tail-recursive functions can be inlined!), gotos, in short, all | |
3244 | constructs supported by GNU CC. The file @file{integrate.c} contains | |
3245 | the code to save a function's rtl for later inlining and to inline that | |
3246 | rtl when the function is called. The header file @file{integrate.h} | |
3247 | is also used for this purpose. | |
3248 | ||
3249 | The option @samp{-dr} causes a debugging dump of the RTL code after | |
3250 | this pass. This dump file's name is made by appending @samp{.rtl} to | |
3251 | the input file name. | |
3252 | ||
3253 | @cindex jump optimization | |
3254 | @cindex unreachable code | |
3255 | @cindex dead code | |
3256 | @item | |
3257 | Jump optimization. This pass simplifies jumps to the following | |
3258 | instruction, jumps across jumps, and jumps to jumps. It deletes | |
3259 | unreferenced labels and unreachable code, except that unreachable code | |
3260 | that contains a loop is not recognized as unreachable in this pass. | |
3261 | (Such loops are deleted later in the basic block analysis.) It also | |
3262 | converts some code originally written with jumps into sequences of | |
3263 | instructions that directly set values from the results of comparisons, | |
3264 | if the machine has such instructions. | |
3265 | ||
3266 | Jump optimization is performed two or three times. The first time is | |
3267 | immediately following RTL generation. The second time is after CSE, | |
3268 | but only if CSE says repeated jump optimization is needed. The | |
3269 | last time is right before the final pass. That time, cross-jumping | |
3270 | and deletion of no-op move instructions are done together with the | |
3271 | optimizations described above. | |
3272 | ||
3273 | The source file of this pass is @file{jump.c}. | |
3274 | ||
3275 | The option @samp{-dj} causes a debugging dump of the RTL code after | |
3276 | this pass is run for the first time. This dump file's name is made by | |
3277 | appending @samp{.jump} to the input file name. | |
3278 | ||
3279 | @cindex register use analysis | |
3280 | @item | |
3281 | Register scan. This pass finds the first and last use of each | |
3282 | register, as a guide for common subexpression elimination. Its source | |
3283 | is in @file{regclass.c}. | |
3284 | ||
3285 | @cindex jump threading | |
3286 | @item | |
3287 | Jump threading. This pass detects a condition jump that branches to an | |
3288 | identical or inverse test. Such jumps can be @samp{threaded} through | |
3289 | the second conditional test. The source code for this pass is in | |
3290 | @file{jump.c}. This optimization is only performed if | |
3291 | @samp{-fthread-jumps} is enabled. | |
3292 | ||
3293 | @cindex common subexpression elimination | |
3294 | @cindex constant propagation | |
3295 | @item | |
3296 | Common subexpression elimination. This pass also does constant | |
3297 | propagation. Its source file is @file{cse.c}. If constant | |
3298 | propagation causes conditional jumps to become unconditional or to | |
3299 | become no-ops, jump optimization is run again when CSE is finished. | |
3300 | ||
3301 | The option @samp{-ds} causes a debugging dump of the RTL code after | |
3302 | this pass. This dump file's name is made by appending @samp{.cse} to | |
3303 | the input file name. | |
3304 | ||
3305 | @cindex loop optimization | |
3306 | @cindex code motion | |
3307 | @cindex strength-reduction | |
3308 | @item | |
3309 | Loop optimization. This pass moves constant expressions out of loops, | |
3310 | and optionally does strength-reduction and loop unrolling as well. | |
3311 | Its source files are @file{loop.c} and @file{unroll.c}, plus the header | |
3312 | @file{loop.h} used for communication between them. Loop unrolling uses | |
3313 | some functions in @file{integrate.c} and the header @file{integrate.h}. | |
3314 | ||
3315 | The option @samp{-dL} causes a debugging dump of the RTL code after | |
3316 | this pass. This dump file's name is made by appending @samp{.loop} to | |
3317 | the input file name. | |
3318 | ||
3319 | @item | |
3320 | If @samp{-frerun-cse-after-loop} was enabled, a second common | |
3321 | subexpression elimination pass is performed after the loop optimization | |
3322 | pass. Jump threading is also done again at this time if it was specified. | |
3323 | ||
3324 | The option @samp{-dt} causes a debugging dump of the RTL code after | |
3325 | this pass. This dump file's name is made by appending @samp{.cse2} to | |
3326 | the input file name. | |
3327 | ||
3328 | @cindex register allocation, stupid | |
3329 | @cindex stupid register allocation | |
3330 | @item | |
3331 | Stupid register allocation is performed at this point in a | |
3332 | nonoptimizing compilation. It does a little data flow analysis as | |
3333 | well. When stupid register allocation is in use, the next pass | |
3334 | executed is the reloading pass; the others in between are skipped. | |
3335 | The source file is @file{stupid.c}. | |
3336 | ||
3337 | @cindex data flow analysis | |
3338 | @cindex analysis, data flow | |
3339 | @cindex basic blocks | |
3340 | @item | |
3341 | Data flow analysis (@file{flow.c}). This pass divides the program | |
3342 | into basic blocks (and in the process deletes unreachable loops); then | |
3343 | it computes which pseudo-registers are live at each point in the | |
3344 | program, and makes the first instruction that uses a value point at | |
3345 | the instruction that computed the value. | |
3346 | ||
3347 | @cindex autoincrement/decrement analysis | |
3348 | This pass also deletes computations whose results are never used, and | |
3349 | combines memory references with add or subtract instructions to make | |
3350 | autoincrement or autodecrement addressing. | |
3351 | ||
3352 | The option @samp{-df} causes a debugging dump of the RTL code after | |
3353 | this pass. This dump file's name is made by appending @samp{.flow} to | |
3354 | the input file name. If stupid register allocation is in use, this | |
3355 | dump file reflects the full results of such allocation. | |
3356 | ||
3357 | @cindex instruction combination | |
3358 | @item | |
3359 | Instruction combination (@file{combine.c}). This pass attempts to | |
3360 | combine groups of two or three instructions that are related by data | |
3361 | flow into single instructions. It combines the RTL expressions for | |
3362 | the instructions by substitution, simplifies the result using algebra, | |
3363 | and then attempts to match the result against the machine description. | |
3364 | ||
3365 | The option @samp{-dc} causes a debugging dump of the RTL code after | |
3366 | this pass. This dump file's name is made by appending @samp{.combine} | |
3367 | to the input file name. | |
3368 | ||
3369 | @cindex instruction scheduling | |
3370 | @cindex scheduling, instruction | |
3371 | @item | |
3372 | Instruction scheduling (@file{sched.c}). This pass looks for | |
3373 | instructions whose output will not be available by the time that it is | |
3374 | used in subsequent instructions. (Memory loads and floating point | |
3375 | instructions often have this behavior on RISC machines). It re-orders | |
3376 | instructions within a basic block to try to separate the definition and | |
3377 | use of items that otherwise would cause pipeline stalls. | |
3378 | ||
3379 | Instruction scheduling is performed twice. The first time is immediately | |
3380 | after instruction combination and the second is immediately after reload. | |
3381 | ||
3382 | The option @samp{-dS} causes a debugging dump of the RTL code after this | |
3383 | pass is run for the first time. The dump file's name is made by | |
3384 | appending @samp{.sched} to the input file name. | |
3385 | ||
3386 | @cindex register class preference pass | |
3387 | @item | |
3388 | Register class preferencing. The RTL code is scanned to find out | |
3389 | which register class is best for each pseudo register. The source | |
3390 | file is @file{regclass.c}. | |
3391 | ||
3392 | @cindex register allocation | |
3393 | @cindex local register allocation | |
3394 | @item | |
3395 | Local register allocation (@file{local-alloc.c}). This pass allocates | |
3396 | hard registers to pseudo registers that are used only within one basic | |
3397 | block. Because the basic block is linear, it can use fast and | |
3398 | powerful techniques to do a very good job. | |
3399 | ||
3400 | The option @samp{-dl} causes a debugging dump of the RTL code after | |
3401 | this pass. This dump file's name is made by appending @samp{.lreg} to | |
3402 | the input file name. | |
3403 | ||
3404 | @cindex global register allocation | |
3405 | @item | |
3406 | Global register allocation (@file{global.c}). This pass | |
3407 | allocates hard registers for the remaining pseudo registers (those | |
3408 | whose life spans are not contained in one basic block). | |
3409 | ||
3410 | @cindex reloading | |
3411 | @item | |
3412 | Reloading. This pass renumbers pseudo registers with the hardware | |
3413 | registers numbers they were allocated. Pseudo registers that did not | |
3414 | get hard registers are replaced with stack slots. Then it finds | |
3415 | instructions that are invalid because a value has failed to end up in | |
3416 | a register, or has ended up in a register of the wrong kind. It fixes | |
3417 | up these instructions by reloading the problematical values | |
3418 | temporarily into registers. Additional instructions are generated to | |
3419 | do the copying. | |
3420 | ||
3421 | The reload pass also optionally eliminates the frame pointer and inserts | |
3422 | instructions to save and restore call-clobbered registers around calls. | |
3423 | ||
3424 | Source files are @file{reload.c} and @file{reload1.c}, plus the header | |
3425 | @file{reload.h} used for communication between them. | |
3426 | ||
3427 | The option @samp{-dg} causes a debugging dump of the RTL code after | |
3428 | this pass. This dump file's name is made by appending @samp{.greg} to | |
3429 | the input file name. | |
3430 | ||
3431 | @cindex instruction scheduling | |
3432 | @cindex scheduling, instruction | |
3433 | @item | |
3434 | Instruction scheduling is repeated here to try to avoid pipeline stalls | |
3435 | due to memory loads generated for spilled pseudo registers. | |
3436 | ||
3437 | The option @samp{-dR} causes a debugging dump of the RTL code after | |
3438 | this pass. This dump file's name is made by appending @samp{.sched2} | |
3439 | to the input file name. | |
3440 | ||
3441 | @cindex cross-jumping | |
3442 | @cindex no-op move instructions | |
3443 | @item | |
3444 | Jump optimization is repeated, this time including cross-jumping | |
3445 | and deletion of no-op move instructions. | |
3446 | ||
3447 | The option @samp{-dJ} causes a debugging dump of the RTL code after | |
3448 | this pass. This dump file's name is made by appending @samp{.jump2} | |
3449 | to the input file name. | |
3450 | ||
3451 | @cindex delayed branch scheduling | |
3452 | @cindex scheduling, delayed branch | |
3453 | @item | |
3454 | Delayed branch scheduling. This optional pass attempts to find | |
3455 | instructions that can go into the delay slots of other instructions, | |
3456 | usually jumps and calls. The source file name is @file{reorg.c}. | |
3457 | ||
3458 | The option @samp{-dd} causes a debugging dump of the RTL code after | |
3459 | this pass. This dump file's name is made by appending @samp{.dbr} | |
3460 | to the input file name. | |
3461 | ||
3462 | @cindex register-to-stack conversion | |
3463 | @item | |
3464 | Conversion from usage of some hard registers to usage of a register | |
3465 | stack may be done at this point. Currently, this is supported only | |
3466 | for the floating-point registers of the Intel 80387 coprocessor. The | |
3467 | source file name is @file{reg-stack.c}. | |
3468 | ||
3469 | The options @samp{-dk} causes a debugging dump of the RTL code after | |
3470 | this pass. This dump file's name is made by appending @samp{.stack} | |
3471 | to the input file name. | |
3472 | ||
3473 | @cindex final pass | |
3474 | @cindex peephole optimization | |
3475 | @item | |
3476 | Final. This pass outputs the assembler code for the function. It is | |
3477 | also responsible for identifying spurious test and compare | |
3478 | instructions. Machine-specific peephole optimizations are performed | |
3479 | at the same time. The function entry and exit sequences are generated | |
3480 | directly as assembler code in this pass; they never exist as RTL. | |
3481 | ||
3482 | The source files are @file{final.c} plus @file{insn-output.c}; the | |
3483 | latter is generated automatically from the machine description by the | |
3484 | tool @file{genoutput}. The header file @file{conditions.h} is used | |
3485 | for communication between these files. | |
3486 | ||
3487 | @cindex debugging information generation | |
3488 | @item | |
3489 | Debugging information output. This is run after final because it must | |
3490 | output the stack slot offsets for pseudo registers that did not get | |
3491 | hard registers. Source files are @file{dbxout.c} for DBX symbol table | |
3492 | format, @file{sdbout.c} for SDB symbol table format, and | |
3493 | @file{dwarfout.c} for DWARF symbol table format. | |
3494 | @end itemize | |
3495 | ||
3496 | Some additional files are used by all or many passes: | |
3497 | ||
3498 | @itemize @bullet | |
3499 | @item | |
3500 | Every pass uses @file{machmode.def} and @file{machmode.h} which define | |
3501 | the machine modes. | |
3502 | ||
3503 | @item | |
3504 | Several passes use @file{real.h}, which defines the default | |
3505 | representation of floating point constants and how to operate on them. | |
3506 | ||
3507 | @item | |
3508 | All the passes that work with RTL use the header files @file{rtl.h} | |
3509 | and @file{rtl.def}, and subroutines in file @file{rtl.c}. The tools | |
3510 | @code{gen*} also use these files to read and work with the machine | |
3511 | description RTL. | |
3512 | ||
3513 | @findex genconfig | |
3514 | @item | |
3515 | Several passes refer to the header file @file{insn-config.h} which | |
3516 | contains a few parameters (C macro definitions) generated | |
3517 | automatically from the machine description RTL by the tool | |
3518 | @code{genconfig}. | |
3519 | ||
3520 | @cindex instruction recognizer | |
3521 | @item | |
3522 | Several passes use the instruction recognizer, which consists of | |
3523 | @file{recog.c} and @file{recog.h}, plus the files @file{insn-recog.c} | |
3524 | and @file{insn-extract.c} that are generated automatically from the | |
3525 | machine description by the tools @file{genrecog} and | |
3526 | @file{genextract}.@refill | |
3527 | ||
3528 | @item | |
3529 | Several passes use the header files @file{regs.h} which defines the | |
3530 | information recorded about pseudo register usage, and @file{basic-block.h} | |
3531 | which defines the information recorded about basic blocks. | |
3532 | ||
3533 | @item | |
3534 | @file{hard-reg-set.h} defines the type @code{HARD_REG_SET}, a bit-vector | |
3535 | with a bit for each hard register, and some macros to manipulate it. | |
3536 | This type is just @code{int} if the machine has few enough hard registers; | |
3537 | otherwise it is an array of @code{int} and some of the macros expand | |
3538 | into loops. | |
3539 | ||
3540 | @item | |
3541 | Several passes use instruction attributes. A definition of the | |
3542 | attributes defined for a particular machine is in file | |
3543 | @file{insn-attr.h}, which is generated from the machine description by | |
3544 | the program @file{genattr}. The file @file{insn-attrtab.c} contains | |
3545 | subroutines to obtain the attribute values for insns. It is generated | |
3546 | from the machine description by the program @file{genattrtab}.@refill | |
3547 | @end itemize | |
3548 | @end ifset | |
3549 | ||
3550 | @ifset INTERNALS | |
3551 | @include rtl.texi | |
3552 | @include md.texi | |
3553 | @include tm.texi | |
3554 | @end ifset | |
3555 | ||
3556 | @ifset INTERNALS | |
3557 | @node Config | |
3558 | @chapter The Configuration File | |
3559 | @cindex configuration file | |
3560 | @cindex @file{xm-@var{machine}.h} | |
3561 | ||
3562 | The configuration file @file{xm-@var{machine}.h} contains macro | |
3563 | definitions that describe the machine and system on which the compiler | |
3564 | is running, unlike the definitions in @file{@var{machine}.h}, which | |
3565 | describe the machine for which the compiler is producing output. Most | |
3566 | of the values in @file{xm-@var{machine}.h} are actually the same on all | |
3567 | machines that GNU CC runs on, so large parts of all configuration files | |
3568 | are identical. But there are some macros that vary: | |
3569 | ||
3570 | @table @code | |
3571 | @findex USG | |
3572 | @item USG | |
3573 | Define this macro if the host system is System V. | |
3574 | ||
3575 | @findex VMS | |
3576 | @item VMS | |
3577 | Define this macro if the host system is VMS. | |
3578 | ||
3579 | @findex FATAL_EXIT_CODE | |
3580 | @item FATAL_EXIT_CODE | |
3581 | A C expression for the status code to be returned when the compiler | |
3582 | exits after serious errors. | |
3583 | ||
3584 | @findex SUCCESS_EXIT_CODE | |
3585 | @item SUCCESS_EXIT_CODE | |
3586 | A C expression for the status code to be returned when the compiler | |
3587 | exits without serious errors. | |
3588 | ||
3589 | @findex HOST_WORDS_BIG_ENDIAN | |
3590 | @item HOST_WORDS_BIG_ENDIAN | |
3591 | Defined if the host machine stores words of multi-word values in | |
3592 | big-endian order. (GNU CC does not depend on the host byte ordering | |
3593 | within a word.) | |
3594 | ||
3595 | @findex HOST_FLOAT_WORDS_BIG_ENDIAN | |
3596 | @item HOST_FLOAT_WORDS_BIG_ENDIAN | |
3597 | Define this macro to be 1 if the host machine stores @code{DFmode}, | |
3598 | @code{XFmode} or @code{TFmode} floating point numbers in memory with the | |
3599 | word containing the sign bit at the lowest address; otherwise, define it | |
3600 | to be zero. | |
3601 | ||
3602 | This macro need not be defined if the ordering is the same as for | |
3603 | multi-word integers. | |
3604 | ||
3605 | @findex HOST_FLOAT_FORMAT | |
3606 | @item HOST_FLOAT_FORMAT | |
3607 | A numeric code distinguishing the floating point format for the host | |
3608 | machine. See @code{TARGET_FLOAT_FORMAT} in @ref{Storage Layout} for the | |
3609 | alternatives and default. | |
3610 | ||
3611 | @findex HOST_BITS_PER_CHAR | |
3612 | @item HOST_BITS_PER_CHAR | |
3613 | A C expression for the number of bits in @code{char} on the host | |
3614 | machine. | |
3615 | ||
3616 | @findex HOST_BITS_PER_SHORT | |
3617 | @item HOST_BITS_PER_SHORT | |
3618 | A C expression for the number of bits in @code{short} on the host | |
3619 | machine. | |
3620 | ||
3621 | @findex HOST_BITS_PER_INT | |
3622 | @item HOST_BITS_PER_INT | |
3623 | A C expression for the number of bits in @code{int} on the host | |
3624 | machine. | |
3625 | ||
3626 | @findex HOST_BITS_PER_LONG | |
3627 | @item HOST_BITS_PER_LONG | |
3628 | A C expression for the number of bits in @code{long} on the host | |
3629 | machine. | |
3630 | ||
3631 | @findex ONLY_INT_FIELDS | |
3632 | @item ONLY_INT_FIELDS | |
3633 | Define this macro to indicate that the host compiler only supports | |
3634 | @code{int} bit fields, rather than other integral types, including | |
3635 | @code{enum}, as do most C compilers. | |
3636 | ||
3637 | @findex OBSTACK_CHUNK_SIZE | |
3638 | @item OBSTACK_CHUNK_SIZE | |
3639 | A C expression for the size of ordinary obstack chunks. | |
3640 | If you don't define this, a usually-reasonable default is used. | |
3641 | ||
3642 | @findex OBSTACK_CHUNK_ALLOC | |
3643 | @item OBSTACK_CHUNK_ALLOC | |
3644 | The function used to allocate obstack chunks. | |
3645 | If you don't define this, @code{xmalloc} is used. | |
3646 | ||
3647 | @findex OBSTACK_CHUNK_FREE | |
3648 | @item OBSTACK_CHUNK_FREE | |
3649 | The function used to free obstack chunks. | |
3650 | If you don't define this, @code{free} is used. | |
3651 | ||
3652 | @findex USE_C_ALLOCA | |
3653 | @item USE_C_ALLOCA | |
3654 | Define this macro to indicate that the compiler is running with the | |
3655 | @code{alloca} implemented in C. This version of @code{alloca} can be | |
3656 | found in the file @file{alloca.c}; to use it, you must also alter the | |
3657 | @file{Makefile} variable @code{ALLOCA}. (This is done automatically | |
3658 | for the systems on which we know it is needed.) | |
3659 | ||
3660 | If you do define this macro, you should probably do it as follows: | |
3661 | ||
3662 | @example | |
3663 | #ifndef __GNUC__ | |
3664 | #define USE_C_ALLOCA | |
3665 | #else | |
3666 | #define alloca __builtin_alloca | |
3667 | #endif | |
3668 | @end example | |
3669 | ||
3670 | @noindent | |
3671 | so that when the compiler is compiled with GNU CC it uses the more | |
3672 | efficient built-in @code{alloca} function. | |
3673 | ||
3674 | @item FUNCTION_CONVERSION_BUG | |
3675 | @findex FUNCTION_CONVERSION_BUG | |
3676 | Define this macro to indicate that the host compiler does not properly | |
3677 | handle converting a function value to a pointer-to-function when it is | |
3678 | used in an expression. | |
3679 | ||
861bb6c1 JL |
3680 | @findex MULTIBYTE_CHARS |
3681 | @item MULTIBYTE_CHARS | |
3682 | Define this macro to enable support for multibyte characters in the | |
3683 | input to GNU CC. This requires that the host system support the ANSI C | |
3684 | library functions for converting multibyte characters to wide | |
3685 | characters. | |
3686 | ||
861bb6c1 JL |
3687 | @findex POSIX |
3688 | @item POSIX | |
3689 | Define this if your system is POSIX.1 compliant. | |
3690 | ||
861bb6c1 JL |
3691 | @findex NO_SYS_SIGLIST |
3692 | @item NO_SYS_SIGLIST | |
3693 | Define this if your system @emph{does not} provide the variable | |
3694 | @code{sys_siglist}. | |
3695 | ||
e9a25f70 JL |
3696 | @vindex sys_siglist |
3697 | Some systems do provide this variable, but with a different name such | |
3698 | as @code{_sys_siglist}. On these systems, you can define | |
3699 | @code{sys_siglist} as a macro which expands into the name actually | |
3700 | provided. | |
3701 | ||
3702 | Autoconf normally defines @code{SYS_SIGLIST_DECLARED} when it finds a | |
3703 | declaration of @code{sys_siglist} in the system header files. | |
3704 | However, when you define @code{sys_siglist} to a different name | |
3705 | autoconf will not automatically define @code{SYS_SIGLIST_DECLARED}. | |
3706 | Therefore, if you define @code{sys_siglist}, you should also define | |
3707 | @code{SYS_SIGLIST_DECLARED}. | |
3708 | ||
861bb6c1 JL |
3709 | @findex USE_PROTOTYPES |
3710 | @item USE_PROTOTYPES | |
3711 | Define this to be 1 if you know that the host compiler supports | |
3712 | prototypes, even if it doesn't define __STDC__, or define | |
3713 | it to be 0 if you do not want any prototypes used in compiling | |
3714 | GNU CC. If @samp{USE_PROTOTYPES} is not defined, it will be | |
3715 | determined automatically whether your compiler supports | |
3716 | prototypes by checking if @samp{__STDC__} is defined. | |
3717 | ||
3718 | @findex NO_MD_PROTOTYPES | |
3719 | @item NO_MD_PROTOTYPES | |
3720 | Define this if you wish suppression of prototypes generated from | |
3721 | the machine description file, but to use other prototypes within | |
3722 | GNU CC. If @samp{USE_PROTOTYPES} is defined to be 0, or the | |
3723 | host compiler does not support prototypes, this macro has no | |
3724 | effect. | |
3725 | ||
3726 | @findex MD_CALL_PROTOTYPES | |
3727 | @item MD_CALL_PROTOTYPES | |
3728 | Define this if you wish to generate prototypes for the | |
3729 | @code{gen_call} or @code{gen_call_value} functions generated from | |
3730 | the machine description file. If @samp{USE_PROTOTYPES} is | |
3731 | defined to be 0, or the host compiler does not support | |
3732 | prototypes, or @samp{NO_MD_PROTOTYPES} is defined, this macro has | |
3733 | no effect. As soon as all of the machine descriptions are | |
3734 | modified to have the appropriate number of arguments, this macro | |
3735 | will be removed. | |
3736 | ||
861bb6c1 JL |
3737 | @findex NO_STAB_H |
3738 | @item NO_STAB_H | |
3739 | Define this if your system does not have the include file | |
3740 | @file{stab.h}. If @samp{USG} is defined, @samp{NO_STAB_H} is | |
3741 | assumed. | |
3742 | ||
3743 | @findex PATH_SEPARATOR | |
3744 | @item PATH_SEPARATOR | |
3745 | Define this macro to be a C character constant representing the | |
e9a25f70 | 3746 | character used to separate components in paths. The default value is |
861bb6c1 JL |
3747 | the colon character |
3748 | ||
3749 | @findex DIR_SEPARATOR | |
3750 | @item DIR_SEPARATOR | |
3751 | If your system uses some character other than slash to separate | |
3752 | directory names within a file specification, define this macro to be a C | |
3753 | character constant specifying that character. When GNU CC displays file | |
3754 | names, the character you specify will be used. GNU CC will test for | |
3755 | both slash and the character you specify when parsing filenames. | |
3756 | ||
3757 | @findex OBJECT_SUFFIX | |
3758 | @item OBJECT_SUFFIX | |
3759 | Define this macro to be a C string representing the suffix for object | |
3760 | files on your machine. If you do not define this macro, GNU CC will use | |
3761 | @samp{.o} as the suffix for object files. | |
3762 | ||
3763 | @findex EXECUTABLE_SUFFIX | |
3764 | @item EXECUTABLE_SUFFIX | |
3765 | Define this macro to be a C string representing the suffix for executable | |
3766 | files on your machine. If you do not define this macro, GNU CC will use | |
3767 | the null string as the suffix for object files. | |
3768 | ||
3769 | @findex COLLECT_EXPORT_LIST | |
3770 | @item COLLECT_EXPORT_LIST | |
3771 | If defined, @code{collect2} will scan the individual object files | |
3772 | specified on its command line and create an export list for the linker. | |
3773 | Define this macro for systems like AIX, where the linker discards | |
3774 | object files that are not referenced from @code{main} and uses export | |
3775 | lists. | |
3776 | @end table | |
3777 | ||
3778 | @findex bzero | |
3779 | @findex bcmp | |
3780 | In addition, configuration files for system V define @code{bcopy}, | |
3781 | @code{bzero} and @code{bcmp} as aliases. Some files define @code{alloca} | |
3782 | as a macro when compiled with GNU CC, in order to take advantage of the | |
3783 | benefit of GNU CC's built-in @code{alloca}. | |
3784 | ||
3785 | @node Fragments | |
3786 | @chapter Makefile Fragments | |
3787 | @cindex makefile fragment | |
3788 | ||
3789 | When you configure GNU CC using the @file{configure} script | |
3790 | (@pxref{Installation}), it will construct the file @file{Makefile} from | |
3791 | the template file @file{Makefile.in}. When it does this, it will | |
3792 | incorporate makefile fragment files from the @file{config} directory, | |
3793 | named @file{t-@var{target}} and @file{x-@var{host}}. If these files do | |
3794 | not exist, it means nothing needs to be added for a given target or | |
3795 | host. | |
3796 | ||
3797 | @menu | |
3798 | * Target Fragment:: Writing the @file{t-@var{target}} file. | |
3799 | * Host Fragment:: Writing the @file{x-@var{host}} file. | |
3800 | @end menu | |
3801 | ||
3802 | @node Target Fragment | |
3803 | @section The Target Makefile Fragment | |
3804 | @cindex target makefile fragment | |
3805 | @cindex @file{t-@var{target}} | |
3806 | ||
3807 | The target makefile fragment, @file{t-@var{target}}, defines special | |
3808 | target dependent variables and targets used in the @file{Makefile}: | |
3809 | ||
3810 | @table @code | |
3811 | @findex LIBGCC1 | |
3812 | @item LIBGCC1 | |
3813 | The rule to use to build @file{libgcc1.a}. | |
3814 | If your target does not need to use the functions in @file{libgcc1.a}, | |
3815 | set this to empty. | |
3816 | @xref{Interface}. | |
3817 | ||
3818 | @findex CROSS_LIBGCC1 | |
3819 | @item CROSS_LIBGCC1 | |
3820 | The rule to use to build @file{libgcc1.a} when building a cross | |
3821 | compiler. If your target does not need to use the functions in | |
3822 | @file{libgcc1.a}, set this to empty. @xref{Cross Runtime}. | |
3823 | ||
3824 | @findex LIBGCC2_CFLAGS | |
3825 | @item LIBGCC2_CFLAGS | |
3826 | Compiler flags to use when compiling @file{libgcc2.c}. | |
3827 | ||
3828 | @findex LIB2FUNCS_EXTRA | |
3829 | @item LIB2FUNCS_EXTRA | |
3830 | A list of source file names to be compiled or assembled and inserted | |
3831 | into @file{libgcc.a}. | |
3832 | ||
3833 | @findex CRTSTUFF_T_CFLAGS | |
3834 | @item CRTSTUFF_T_CFLAGS | |
3835 | Special flags used when compiling @file{crtstuff.c}. | |
3836 | @xref{Initialization}. | |
3837 | ||
3838 | @findex CRTSTUFF_T_CFLAGS_S | |
3839 | @item CRTSTUFF_T_CFLAGS_S | |
3840 | Special flags used when compiling @file{crtstuff.c} for shared | |
3841 | linking. Used if you use @file{crtbeginS.o} and @file{crtendS.o} | |
3842 | in @code{EXTRA-PARTS}. | |
3843 | @xref{Initialization}. | |
3844 | ||
3845 | @findex MULTILIB_OPTIONS | |
3846 | @item MULTILIB_OPTIONS | |
3847 | For some targets, invoking GNU CC in different ways produces objects | |
3848 | that can not be linked together. For example, for some targets GNU CC | |
3849 | produces both big and little endian code. For these targets, you must | |
3850 | arrange for multiple versions of @file{libgcc.a} to be compiled, one for | |
3851 | each set of incompatible options. When GNU CC invokes the linker, it | |
3852 | arranges to link in the right version of @file{libgcc.a}, based on | |
3853 | the command line options used. | |
3854 | ||
3855 | The @code{MULTILIB_OPTIONS} macro lists the set of options for which | |
3856 | special versions of @file{libgcc.a} must be built. Write options that | |
3857 | are mutually incompatible side by side, separated by a slash. Write | |
3858 | options that may be used together separated by a space. The build | |
3859 | procedure will build all combinations of compatible options. | |
3860 | ||
3861 | For example, if you set @code{MULTILIB_OPTIONS} to @samp{m68000/m68020 | |
3862 | msoft-float}, @file{Makefile} will build special versions of | |
e5e809f4 JL |
3863 | @file{libgcc.a} using the following sets of options: @samp{-m68000}, |
3864 | @samp{-m68020}, @samp{-msoft-float}, @samp{-m68000 -msoft-float}, and | |
3865 | @samp{-m68020 -msoft-float}. | |
861bb6c1 JL |
3866 | |
3867 | @findex MULTILIB_DIRNAMES | |
3868 | @item MULTILIB_DIRNAMES | |
3869 | If @code{MULTILIB_OPTIONS} is used, this variable specifies the | |
3870 | directory names that should be used to hold the various libraries. | |
3871 | Write one element in @code{MULTILIB_DIRNAMES} for each element in | |
3872 | @code{MULTILIB_OPTIONS}. If @code{MULTILIB_DIRNAMES} is not used, the | |
3873 | default value will be @code{MULTILIB_OPTIONS}, with all slashes treated | |
3874 | as spaces. | |
3875 | ||
e5e809f4 | 3876 | For example, if @code{MULTILIB_OPTIONS} is set to @samp{m68000/m68020 |
861bb6c1 JL |
3877 | msoft-float}, then the default value of @code{MULTILIB_DIRNAMES} is |
3878 | @samp{m68000 m68020 msoft-float}. You may specify a different value if | |
3879 | you desire a different set of directory names. | |
3880 | ||
3881 | @findex MULTILIB_MATCHES | |
3882 | @item MULTILIB_MATCHES | |
3883 | Sometimes the same option may be written in two different ways. If an | |
3884 | option is listed in @code{MULTILIB_OPTIONS}, GNU CC needs to know about | |
3885 | any synonyms. In that case, set @code{MULTILIB_MATCHES} to a list of | |
3886 | items of the form @samp{option=option} to describe all relevant | |
3887 | synonyms. For example, @samp{m68000=mc68000 m68020=mc68020}. | |
3888 | ||
3889 | @findex MULTILIB_EXCEPTIONS | |
3890 | @item MULTILIB_EXCEPTIONS | |
3891 | Sometimes when there are multiple sets of @code{MULTILIB_OPTIONS} being | |
3892 | specified, there are combinations that should not be built. In that | |
3893 | case, set @code{MULTILIB_EXCEPTIONS} to be all of the switch exceptions | |
3894 | in shell case syntax that should not be built. | |
3895 | ||
3896 | For example, in the PowerPC embedded ABI support, it was not desirable | |
3897 | to build libraries that compiled with the @samp{-mcall-aixdesc} option | |
3898 | and either of the @samp{-mcall-aixdesc} or @samp{-mlittle} options at | |
3899 | the same time, and therefore @code{MULTILIB_EXCEPTIONS} is set to | |
3900 | @code{*mrelocatable/*mcall-aixdesc* *mlittle/*mcall-aixdesc*}. | |
3901 | ||
3902 | @findex MULTILIB_EXTRA_OPTS | |
3903 | @item MULTILIB_EXTRA_OPTS | |
3904 | Sometimes it is desirable that when building multiple versions of | |
3905 | @file{libgcc.a} certain options should always be passed on to the | |
3906 | compiler. In that case, set @code{MULTILIB_EXTRA_OPTS} to be the list | |
3907 | of options to be used for all builds. | |
3908 | @end table | |
3909 | ||
3910 | @node Host Fragment | |
3911 | @section The Host Makefile Fragment | |
3912 | @cindex host makefile fragment | |
3913 | @cindex @file{x-@var{host}} | |
3914 | ||
3915 | The host makefile fragment, @file{x-@var{host}}, defines special host | |
3916 | dependent variables and targets used in the @file{Makefile}: | |
3917 | ||
3918 | @table @code | |
3919 | @findex CC | |
3920 | @item CC | |
3921 | The compiler to use when building the first stage. | |
3922 | ||
3923 | @findex CLIB | |
3924 | @item CLIB | |
3925 | Additional host libraries to link with. | |
3926 | ||
3927 | @findex OLDCC | |
3928 | @item OLDCC | |
3929 | The compiler to use when building @file{libgcc1.a} for a native | |
3930 | compilation. | |
3931 | ||
3932 | @findex OLDAR | |
3933 | @item OLDAR | |
3934 | The version of @code{ar} to use when building @file{libgcc1.a} for a native | |
3935 | compilation. | |
3936 | ||
3937 | @findex INSTALL | |
3938 | @item INSTALL | |
3939 | The install program to use. | |
3940 | @end table | |
3941 | ||
3942 | @node Funding | |
3943 | @unnumbered Funding Free Software | |
3944 | ||
3945 | If you want to have more free software a few years from now, it makes | |
3946 | sense for you to help encourage people to contribute funds for its | |
3947 | development. The most effective approach known is to encourage | |
3948 | commercial redistributors to donate. | |
3949 | ||
3950 | Users of free software systems can boost the pace of development by | |
3951 | encouraging for-a-fee distributors to donate part of their selling price | |
3952 | to free software developers---the Free Software Foundation, and others. | |
3953 | ||
3954 | The way to convince distributors to do this is to demand it and expect | |
3955 | it from them. So when you compare distributors, judge them partly by | |
3956 | how much they give to free software development. Show distributors | |
3957 | they must compete to be the one who gives the most. | |
3958 | ||
3959 | To make this approach work, you must insist on numbers that you can | |
3960 | compare, such as, ``We will donate ten dollars to the Frobnitz project | |
3961 | for each disk sold.'' Don't be satisfied with a vague promise, such as | |
3962 | ``A portion of the profits are donated,'' since it doesn't give a basis | |
3963 | for comparison. | |
3964 | ||
3965 | Even a precise fraction ``of the profits from this disk'' is not very | |
3966 | meaningful, since creative accounting and unrelated business decisions | |
3967 | can greatly alter what fraction of the sales price counts as profit. | |
3968 | If the price you pay is $50, ten percent of the profit is probably | |
3969 | less than a dollar; it might be a few cents, or nothing at all. | |
3970 | ||
3971 | Some redistributors do development work themselves. This is useful too; | |
3972 | but to keep everyone honest, you need to inquire how much they do, and | |
3973 | what kind. Some kinds of development make much more long-term | |
3974 | difference than others. For example, maintaining a separate version of | |
3975 | a program contributes very little; maintaining the standard version of a | |
3976 | program for the whole community contributes much. Easy new ports | |
3977 | contribute little, since someone else would surely do them; difficult | |
3978 | ports such as adding a new CPU to the GNU C compiler contribute more; | |
3979 | major new features or packages contribute the most. | |
3980 | ||
3981 | By establishing the idea that supporting further development is ``the | |
3982 | proper thing to do'' when distributing free software for a fee, we can | |
3983 | assure a steady flow of resources into making more free software. | |
3984 | ||
3985 | @display | |
3986 | Copyright (C) 1994 Free Software Foundation, Inc. | |
3987 | Verbatim copying and redistribution of this section is permitted | |
3988 | without royalty; alteration is not permitted. | |
3989 | @end display | |
3990 | ||
e5e809f4 JL |
3991 | @node GNU/Linux |
3992 | @unnumbered Linux and the GNU Project | |
3993 | ||
3994 | Many computer users run a modified version of the GNU system every | |
3995 | day, without realizing it. Through a peculiar turn of events, the | |
3996 | version of GNU which is widely used today is more often known as | |
3997 | ``Linux'', and many users are not aware of the extent of its | |
3998 | connection with the GNU Project. | |
3999 | ||
4000 | There really is a Linux; it is a kernel, and these people are using | |
4001 | it. But you can't use a kernel by itself; a kernel is useful only as | |
4002 | part of a whole system. The system in which Linux is typically used | |
4003 | is a modified variant of the GNU system---in other words, a Linux-based | |
4004 | GNU system. | |
4005 | ||
4006 | Many users are not fully aware of the distinction between the kernel, | |
4007 | which is Linux, and the whole system, which they also call ``Linux''. | |
4008 | The ambiguous use of the name doesn't promote understanding. | |
4009 | ||
4010 | Programmers generally know that Linux is a kernel. But since they | |
4011 | have generally heard the whole system called ``Linux'' as well, they | |
4012 | often envisage a history which fits that name. For example, many | |
4013 | believe that once Linus Torvalds finished writing the kernel, his | |
4014 | friends looked around for other free software, and for no particular | |
4015 | reason most everything necessary to make a Unix-like system was | |
4016 | already available. | |
4017 | ||
4018 | What they found was no accident---it was the GNU system. The available | |
4019 | free software added up to a complete system because the GNU Project | |
4020 | had been working since 1984 to make one. The GNU Manifesto | |
4021 | had set forth the goal of developing a free Unix-like system, called | |
4022 | GNU. By the time Linux was written, the system was almost finished. | |
4023 | ||
4024 | Most free software projects have the goal of developing a particular | |
4025 | program for a particular job. For example, Linus Torvalds set out to | |
4026 | write a Unix-like kernel (Linux); Donald Knuth set out to write a text | |
4027 | formatter (TeX); Bob Scheifler set out to develop a window system (X | |
4028 | Windows). It's natural to measure the contribution of this kind of | |
4029 | project by specific programs that came from the project. | |
4030 | ||
4031 | If we tried to measure the GNU Project's contribution in this way, | |
4032 | what would we conclude? One CD-ROM vendor found that in their ``Linux | |
4033 | distribution'', GNU software was the largest single contingent, around | |
4034 | 28% of the total source code, and this included some of the essential | |
4035 | major components without which there could be no system. Linux itself | |
4036 | was about 3%. So if you were going to pick a name for the system | |
4037 | based on who wrote the programs in the system, the most appropriate | |
4038 | single choice would be ``GNU''. | |
4039 | ||
4040 | But we don't think that is the right way to consider the question. | |
4041 | The GNU Project was not, is not, a project to develop specific | |
4042 | software packages. It was not a project to develop a C compiler, | |
4043 | although we did. It was not a project to develop a text editor, | |
4044 | although we developed one. The GNU Project's aim was to develop | |
4045 | @emph{a complete free Unix-like system}. | |
4046 | ||
4047 | Many people have made major contributions to the free software in the | |
4048 | system, and they all deserve credit. But the reason it is @emph{a | |
4049 | system}---and not just a collection of useful programs---is because the | |
4050 | GNU Project set out to make it one. We wrote the programs that were | |
4051 | needed to make a @emph{complete} free system. We wrote essential but | |
4052 | unexciting major components, such as the assembler and linker, because | |
4053 | you can't have a system without them. A complete system needs more | |
4054 | than just programming tools, so we wrote other components as well, | |
4055 | such as the Bourne Again SHell, the PostScript interpreter | |
4056 | Ghostscript, and the GNU C library. | |
4057 | ||
4058 | By the early 90s we had put together the whole system aside from the | |
4059 | kernel (and we were also working on a kernel, the GNU Hurd, which runs | |
4060 | on top of Mach). Developing this kernel has been a lot harder than we | |
4061 | expected, and we are still working on finishing it. | |
4062 | ||
4063 | Fortunately, you don't have to wait for it, because Linux is working | |
4064 | now. When Linus Torvalds wrote Linux, he filled the last major gap. | |
4065 | People could then put Linux together with the GNU system to make a | |
4066 | complete free system: a Linux-based GNU system (or GNU/Linux system, | |
4067 | for short). | |
4068 | ||
4069 | Putting them together sounds simple, but it was not a trivial job. | |
4070 | The GNU C library (called glibc for short) needed substantial changes. | |
4071 | Integrating a complete system as a distribution that would work ``out | |
4072 | of the box'' was a big job, too. It required addressing the issue of | |
4073 | how to install and boot the system---a problem we had not tackled, | |
4074 | because we hadn't yet reached that point. The people who developed | |
4075 | the various system distributions made a substantial contribution. | |
4076 | ||
4077 | The GNU Project supports GNU/Linux systems as well as @emph{the} | |
4078 | GNU system---even with funds. We funded the rewriting of the | |
4079 | Linux-related extensions to the GNU C library, so that now they are | |
4080 | well integrated, and the newest GNU/Linux systems use the current | |
4081 | library release with no changes. We also funded an early stage of the | |
4082 | development of Debian GNU/Linux. | |
4083 | ||
4084 | We use Linux-based GNU systems today for most of our work, and we hope | |
4085 | you use them too. But please don't confuse the public by using the | |
4086 | name ``Linux'' ambiguously. Linux is the kernel, one of the essential | |
4087 | major components of the system. The system as a whole is more or less | |
4088 | the GNU system. | |
861bb6c1 JL |
4089 | |
4090 | @node Copying | |
4091 | @unnumbered GNU GENERAL PUBLIC LICENSE | |
4092 | @center Version 2, June 1991 | |
4093 | ||
4094 | @display | |
4095 | Copyright @copyright{} 1989, 1991 Free Software Foundation, Inc. | |
4096 | 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA | |
4097 | ||
4098 | Everyone is permitted to copy and distribute verbatim copies | |
4099 | of this license document, but changing it is not allowed. | |
4100 | @end display | |
4101 | ||
4102 | @unnumberedsec Preamble | |
4103 | ||
4104 | The licenses for most software are designed to take away your | |
4105 | freedom to share and change it. By contrast, the GNU General Public | |
4106 | License is intended to guarantee your freedom to share and change free | |
4107 | software---to make sure the software is free for all its users. This | |
4108 | General Public License applies to most of the Free Software | |
4109 | Foundation's software and to any other program whose authors commit to | |
4110 | using it. (Some other Free Software Foundation software is covered by | |
4111 | the GNU Library General Public License instead.) You can apply it to | |
4112 | your programs, too. | |
4113 | ||
4114 | When we speak of free software, we are referring to freedom, not | |
4115 | price. Our General Public Licenses are designed to make sure that you | |
4116 | have the freedom to distribute copies of free software (and charge for | |
4117 | this service if you wish), that you receive source code or can get it | |
4118 | if you want it, that you can change the software or use pieces of it | |
4119 | in new free programs; and that you know you can do these things. | |
4120 | ||
4121 | To protect your rights, we need to make restrictions that forbid | |
4122 | anyone to deny you these rights or to ask you to surrender the rights. | |
4123 | These restrictions translate to certain responsibilities for you if you | |
4124 | distribute copies of the software, or if you modify it. | |
4125 | ||
4126 | For example, if you distribute copies of such a program, whether | |
4127 | gratis or for a fee, you must give the recipients all the rights that | |
4128 | you have. You must make sure that they, too, receive or can get the | |
4129 | source code. And you must show them these terms so they know their | |
4130 | rights. | |
4131 | ||
4132 | We protect your rights with two steps: (1) copyright the software, and | |
4133 | (2) offer you this license which gives you legal permission to copy, | |
4134 | distribute and/or modify the software. | |
4135 | ||
4136 | Also, for each author's protection and ours, we want to make certain | |
4137 | that everyone understands that there is no warranty for this free | |
4138 | software. If the software is modified by someone else and passed on, we | |
4139 | want its recipients to know that what they have is not the original, so | |
4140 | that any problems introduced by others will not reflect on the original | |
4141 | authors' reputations. | |
4142 | ||
4143 | Finally, any free program is threatened constantly by software | |
4144 | patents. We wish to avoid the danger that redistributors of a free | |
4145 | program will individually obtain patent licenses, in effect making the | |
4146 | program proprietary. To prevent this, we have made it clear that any | |
4147 | patent must be licensed for everyone's free use or not licensed at all. | |
4148 | ||
4149 | The precise terms and conditions for copying, distribution and | |
4150 | modification follow. | |
4151 | ||
4152 | @iftex | |
4153 | @unnumberedsec TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION | |
4154 | @end iftex | |
4155 | @ifinfo | |
4156 | @center TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION | |
4157 | @end ifinfo | |
4158 | ||
4159 | @enumerate 0 | |
4160 | @item | |
4161 | This License applies to any program or other work which contains | |
4162 | a notice placed by the copyright holder saying it may be distributed | |
4163 | under the terms of this General Public License. The ``Program'', below, | |
4164 | refers to any such program or work, and a ``work based on the Program'' | |
4165 | means either the Program or any derivative work under copyright law: | |
4166 | that is to say, a work containing the Program or a portion of it, | |
4167 | either verbatim or with modifications and/or translated into another | |
4168 | language. (Hereinafter, translation is included without limitation in | |
4169 | the term ``modification''.) Each licensee is addressed as ``you''. | |
4170 | ||
4171 | Activities other than copying, distribution and modification are not | |
4172 | covered by this License; they are outside its scope. The act of | |
4173 | running the Program is not restricted, and the output from the Program | |
4174 | is covered only if its contents constitute a work based on the | |
4175 | Program (independent of having been made by running the Program). | |
4176 | Whether that is true depends on what the Program does. | |
4177 | ||
4178 | @item | |
4179 | You may copy and distribute verbatim copies of the Program's | |
4180 | source code as you receive it, in any medium, provided that you | |
4181 | conspicuously and appropriately publish on each copy an appropriate | |
4182 | copyright notice and disclaimer of warranty; keep intact all the | |
4183 | notices that refer to this License and to the absence of any warranty; | |
4184 | and give any other recipients of the Program a copy of this License | |
4185 | along with the Program. | |
4186 | ||
4187 | You may charge a fee for the physical act of transferring a copy, and | |
4188 | you may at your option offer warranty protection in exchange for a fee. | |
4189 | ||
4190 | @item | |
4191 | You may modify your copy or copies of the Program or any portion | |
4192 | of it, thus forming a work based on the Program, and copy and | |
4193 | distribute such modifications or work under the terms of Section 1 | |
4194 | above, provided that you also meet all of these conditions: | |
4195 | ||
4196 | @enumerate a | |
4197 | @item | |
4198 | You must cause the modified files to carry prominent notices | |
4199 | stating that you changed the files and the date of any change. | |
4200 | ||
4201 | @item | |
4202 | You must cause any work that you distribute or publish, that in | |
4203 | whole or in part contains or is derived from the Program or any | |
4204 | part thereof, to be licensed as a whole at no charge to all third | |
4205 | parties under the terms of this License. | |
4206 | ||
4207 | @item | |
4208 | If the modified program normally reads commands interactively | |
4209 | when run, you must cause it, when started running for such | |
4210 | interactive use in the most ordinary way, to print or display an | |
4211 | announcement including an appropriate copyright notice and a | |
4212 | notice that there is no warranty (or else, saying that you provide | |
4213 | a warranty) and that users may redistribute the program under | |
4214 | these conditions, and telling the user how to view a copy of this | |
4215 | License. (Exception: if the Program itself is interactive but | |
4216 | does not normally print such an announcement, your work based on | |
4217 | the Program is not required to print an announcement.) | |
4218 | @end enumerate | |
4219 | ||
4220 | These requirements apply to the modified work as a whole. If | |
4221 | identifiable sections of that work are not derived from the Program, | |
4222 | and can be reasonably considered independent and separate works in | |
4223 | themselves, then this License, and its terms, do not apply to those | |
4224 | sections when you distribute them as separate works. But when you | |
4225 | distribute the same sections as part of a whole which is a work based | |
4226 | on the Program, the distribution of the whole must be on the terms of | |
4227 | this License, whose permissions for other licensees extend to the | |
4228 | entire whole, and thus to each and every part regardless of who wrote it. | |
4229 | ||
4230 | Thus, it is not the intent of this section to claim rights or contest | |
4231 | your rights to work written entirely by you; rather, the intent is to | |
4232 | exercise the right to control the distribution of derivative or | |
4233 | collective works based on the Program. | |
4234 | ||
4235 | In addition, mere aggregation of another work not based on the Program | |
4236 | with the Program (or with a work based on the Program) on a volume of | |
4237 | a storage or distribution medium does not bring the other work under | |
4238 | the scope of this License. | |
4239 | ||
4240 | @item | |
4241 | You may copy and distribute the Program (or a work based on it, | |
4242 | under Section 2) in object code or executable form under the terms of | |
4243 | Sections 1 and 2 above provided that you also do one of the following: | |
4244 | ||
4245 | @enumerate a | |
4246 | @item | |
4247 | Accompany it with the complete corresponding machine-readable | |
4248 | source code, which must be distributed under the terms of Sections | |
4249 | 1 and 2 above on a medium customarily used for software interchange; or, | |
4250 | ||
4251 | @item | |
4252 | Accompany it with a written offer, valid for at least three | |
4253 | years, to give any third party, for a charge no more than your | |
4254 | cost of physically performing source distribution, a complete | |
4255 | machine-readable copy of the corresponding source code, to be | |
4256 | distributed under the terms of Sections 1 and 2 above on a medium | |
4257 | customarily used for software interchange; or, | |
4258 | ||
4259 | @item | |
4260 | Accompany it with the information you received as to the offer | |
4261 | to distribute corresponding source code. (This alternative is | |
4262 | allowed only for noncommercial distribution and only if you | |
4263 | received the program in object code or executable form with such | |
4264 | an offer, in accord with Subsection b above.) | |
4265 | @end enumerate | |
4266 | ||
4267 | The source code for a work means the preferred form of the work for | |
4268 | making modifications to it. For an executable work, complete source | |
4269 | code means all the source code for all modules it contains, plus any | |
4270 | associated interface definition files, plus the scripts used to | |
4271 | control compilation and installation of the executable. However, as a | |
4272 | special exception, the source code distributed need not include | |
4273 | anything that is normally distributed (in either source or binary | |
4274 | form) with the major components (compiler, kernel, and so on) of the | |
4275 | operating system on which the executable runs, unless that component | |
4276 | itself accompanies the executable. | |
4277 | ||
4278 | If distribution of executable or object code is made by offering | |
4279 | access to copy from a designated place, then offering equivalent | |
4280 | access to copy the source code from the same place counts as | |
4281 | distribution of the source code, even though third parties are not | |
4282 | compelled to copy the source along with the object code. | |
4283 | ||
4284 | @item | |
4285 | You may not copy, modify, sublicense, or distribute the Program | |
4286 | except as expressly provided under this License. Any attempt | |
4287 | otherwise to copy, modify, sublicense or distribute the Program is | |
4288 | void, and will automatically terminate your rights under this License. | |
4289 | However, parties who have received copies, or rights, from you under | |
4290 | this License will not have their licenses terminated so long as such | |
4291 | parties remain in full compliance. | |
4292 | ||
4293 | @item | |
4294 | You are not required to accept this License, since you have not | |
4295 | signed it. However, nothing else grants you permission to modify or | |
4296 | distribute the Program or its derivative works. These actions are | |
4297 | prohibited by law if you do not accept this License. Therefore, by | |
4298 | modifying or distributing the Program (or any work based on the | |
4299 | Program), you indicate your acceptance of this License to do so, and | |
4300 | all its terms and conditions for copying, distributing or modifying | |
4301 | the Program or works based on it. | |
4302 | ||
4303 | @item | |
4304 | Each time you redistribute the Program (or any work based on the | |
4305 | Program), the recipient automatically receives a license from the | |
4306 | original licensor to copy, distribute or modify the Program subject to | |
4307 | these terms and conditions. You may not impose any further | |
4308 | restrictions on the recipients' exercise of the rights granted herein. | |
4309 | You are not responsible for enforcing compliance by third parties to | |
4310 | this License. | |
4311 | ||
4312 | @item | |
4313 | If, as a consequence of a court judgment or allegation of patent | |
4314 | infringement or for any other reason (not limited to patent issues), | |
4315 | conditions are imposed on you (whether by court order, agreement or | |
4316 | otherwise) that contradict the conditions of this License, they do not | |
4317 | excuse you from the conditions of this License. If you cannot | |
4318 | distribute so as to satisfy simultaneously your obligations under this | |
4319 | License and any other pertinent obligations, then as a consequence you | |
4320 | may not distribute the Program at all. For example, if a patent | |
4321 | license would not permit royalty-free redistribution of the Program by | |
4322 | all those who receive copies directly or indirectly through you, then | |
4323 | the only way you could satisfy both it and this License would be to | |
4324 | refrain entirely from distribution of the Program. | |
4325 | ||
4326 | If any portion of this section is held invalid or unenforceable under | |
4327 | any particular circumstance, the balance of the section is intended to | |
4328 | apply and the section as a whole is intended to apply in other | |
4329 | circumstances. | |
4330 | ||
4331 | It is not the purpose of this section to induce you to infringe any | |
4332 | patents or other property right claims or to contest validity of any | |
4333 | such claims; this section has the sole purpose of protecting the | |
4334 | integrity of the free software distribution system, which is | |
4335 | implemented by public license practices. Many people have made | |
4336 | generous contributions to the wide range of software distributed | |
4337 | through that system in reliance on consistent application of that | |
4338 | system; it is up to the author/donor to decide if he or she is willing | |
4339 | to distribute software through any other system and a licensee cannot | |
4340 | impose that choice. | |
4341 | ||
4342 | This section is intended to make thoroughly clear what is believed to | |
4343 | be a consequence of the rest of this License. | |
4344 | ||
4345 | @item | |
4346 | If the distribution and/or use of the Program is restricted in | |
4347 | certain countries either by patents or by copyrighted interfaces, the | |
4348 | original copyright holder who places the Program under this License | |
4349 | may add an explicit geographical distribution limitation excluding | |
4350 | those countries, so that distribution is permitted only in or among | |
4351 | countries not thus excluded. In such case, this License incorporates | |
4352 | the limitation as if written in the body of this License. | |
4353 | ||
4354 | @item | |
4355 | The Free Software Foundation may publish revised and/or new versions | |
4356 | of the General Public License from time to time. Such new versions will | |
4357 | be similar in spirit to the present version, but may differ in detail to | |
4358 | address new problems or concerns. | |
4359 | ||
4360 | Each version is given a distinguishing version number. If the Program | |
4361 | specifies a version number of this License which applies to it and ``any | |
4362 | later version'', you have the option of following the terms and conditions | |
4363 | either of that version or of any later version published by the Free | |
4364 | Software Foundation. If the Program does not specify a version number of | |
4365 | this License, you may choose any version ever published by the Free Software | |
4366 | Foundation. | |
4367 | ||
4368 | @item | |
4369 | If you wish to incorporate parts of the Program into other free | |
4370 | programs whose distribution conditions are different, write to the author | |
4371 | to ask for permission. For software which is copyrighted by the Free | |
4372 | Software Foundation, write to the Free Software Foundation; we sometimes | |
4373 | make exceptions for this. Our decision will be guided by the two goals | |
4374 | of preserving the free status of all derivatives of our free software and | |
4375 | of promoting the sharing and reuse of software generally. | |
4376 | ||
4377 | @iftex | |
4378 | @heading NO WARRANTY | |
4379 | @end iftex | |
4380 | @ifinfo | |
4381 | @center NO WARRANTY | |
4382 | @end ifinfo | |
4383 | ||
4384 | @item | |
4385 | BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY | |
4386 | FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN | |
4387 | OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES | |
4388 | PROVIDE THE PROGRAM ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED | |
4389 | OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF | |
4390 | MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS | |
4391 | TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE | |
4392 | PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, | |
4393 | REPAIR OR CORRECTION. | |
4394 | ||
4395 | @item | |
4396 | IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING | |
4397 | WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR | |
4398 | REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, | |
4399 | INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING | |
4400 | OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED | |
4401 | TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY | |
4402 | YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER | |
4403 | PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE | |
4404 | POSSIBILITY OF SUCH DAMAGES. | |
4405 | @end enumerate | |
4406 | ||
4407 | @iftex | |
4408 | @heading END OF TERMS AND CONDITIONS | |
4409 | @end iftex | |
4410 | @ifinfo | |
4411 | @center END OF TERMS AND CONDITIONS | |
4412 | @end ifinfo | |
4413 | ||
4414 | @page | |
4415 | @unnumberedsec How to Apply These Terms to Your New Programs | |
4416 | ||
4417 | If you develop a new program, and you want it to be of the greatest | |
4418 | possible use to the public, the best way to achieve this is to make it | |
4419 | free software which everyone can redistribute and change under these terms. | |
4420 | ||
4421 | To do so, attach the following notices to the program. It is safest | |
4422 | to attach them to the start of each source file to most effectively | |
4423 | convey the exclusion of warranty; and each file should have at least | |
4424 | the ``copyright'' line and a pointer to where the full notice is found. | |
4425 | ||
4426 | @smallexample | |
4427 | @var{one line to give the program's name and a brief idea of what it does.} | |
4428 | Copyright (C) 19@var{yy} @var{name of author} | |
4429 | ||
4430 | This program is free software; you can redistribute it and/or modify | |
4431 | it under the terms of the GNU General Public License as published by | |
4432 | the Free Software Foundation; either version 2 of the License, or | |
4433 | (at your option) any later version. | |
4434 | ||
4435 | This program is distributed in the hope that it will be useful, | |
4436 | but WITHOUT ANY WARRANTY; without even the implied warranty of | |
4437 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | |
4438 | GNU General Public License for more details. | |
4439 | ||
4440 | You should have received a copy of the GNU General Public License | |
4441 | along with this program; if not, write to the Free Software | |
4442 | Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. | |
4443 | @end smallexample | |
4444 | ||
4445 | Also add information on how to contact you by electronic and paper mail. | |
4446 | ||
4447 | If the program is interactive, make it output a short notice like this | |
4448 | when it starts in an interactive mode: | |
4449 | ||
4450 | @smallexample | |
4451 | Gnomovision version 69, Copyright (C) 19@var{yy} @var{name of author} | |
4452 | Gnomovision comes with ABSOLUTELY NO WARRANTY; for details | |
4453 | type `show w'. | |
4454 | This is free software, and you are welcome to redistribute it | |
4455 | under certain conditions; type `show c' for details. | |
4456 | @end smallexample | |
4457 | ||
4458 | The hypothetical commands @samp{show w} and @samp{show c} should show | |
4459 | the appropriate parts of the General Public License. Of course, the | |
4460 | commands you use may be called something other than @samp{show w} and | |
4461 | @samp{show c}; they could even be mouse-clicks or menu items---whatever | |
4462 | suits your program. | |
4463 | ||
4464 | You should also get your employer (if you work as a programmer) or your | |
4465 | school, if any, to sign a ``copyright disclaimer'' for the program, if | |
4466 | necessary. Here is a sample; alter the names: | |
4467 | ||
4468 | @smallexample | |
4469 | Yoyodyne, Inc., hereby disclaims all copyright interest in the program | |
4470 | `Gnomovision' (which makes passes at compilers) written by James Hacker. | |
4471 | ||
4472 | @var{signature of Ty Coon}, 1 April 1989 | |
4473 | Ty Coon, President of Vice | |
4474 | @end smallexample | |
4475 | ||
4476 | This General Public License does not permit incorporating your program into | |
4477 | proprietary programs. If your program is a subroutine library, you may | |
4478 | consider it more useful to permit linking proprietary applications with the | |
4479 | library. If this is what you want to do, use the GNU Library General | |
4480 | Public License instead of this License. | |
4481 | ||
4482 | @node Contributors | |
4483 | @unnumbered Contributors to GNU CC | |
4484 | @cindex contributors | |
4485 | ||
4486 | In addition to Richard Stallman, several people have written parts | |
4487 | of GNU CC. | |
4488 | ||
4489 | @itemize @bullet | |
4490 | @item | |
4491 | The idea of using RTL and some of the optimization ideas came from the | |
4492 | program PO written at the University of Arizona by Jack Davidson and | |
4493 | Christopher Fraser. See ``Register Allocation and Exhaustive Peephole | |
4494 | Optimization'', Software Practice and Experience 14 (9), Sept. 1984, | |
4495 | 857-866. | |
4496 | ||
4497 | @item | |
4498 | Paul Rubin wrote most of the preprocessor. | |
4499 | ||
4500 | @item | |
4501 | Leonard Tower wrote parts of the parser, RTL generator, and RTL | |
4502 | definitions, and of the Vax machine description. | |
4503 | ||
4504 | @item | |
4505 | Ted Lemon wrote parts of the RTL reader and printer. | |
4506 | ||
4507 | @item | |
4508 | Jim Wilson implemented loop strength reduction and some other | |
4509 | loop optimizations. | |
4510 | ||
4511 | @item | |
4512 | Nobuyuki Hikichi of Software Research Associates, Tokyo, contributed | |
4513 | the support for the Sony NEWS machine. | |
4514 | ||
4515 | @item | |
4516 | Charles LaBrec contributed the support for the Integrated Solutions | |
4517 | 68020 system. | |
4518 | ||
4519 | @item | |
4520 | Michael Tiemann of Cygnus Support wrote the front end for C++, as well | |
4521 | as the support for inline functions and instruction scheduling. Also | |
4522 | the descriptions of the National Semiconductor 32000 series cpu, the | |
4523 | SPARC cpu and part of the Motorola 88000 cpu. | |
4524 | ||
4525 | @item | |
4526 | Gerald Baumgartner added the signature extension to the C++ front-end. | |
4527 | ||
4528 | @item | |
4529 | Jan Stein of the Chalmers Computer Society provided support for | |
4530 | Genix, as well as part of the 32000 machine description. | |
4531 | ||
4532 | @item | |
4533 | Randy Smith finished the Sun FPA support. | |
4534 | ||
4535 | @item | |
4536 | Robert Brown implemented the support for Encore 32000 systems. | |
4537 | ||
4538 | @item | |
4539 | David Kashtan of SRI adapted GNU CC to VMS. | |
4540 | ||
4541 | @item | |
4542 | Alex Crain provided changes for the 3b1. | |
4543 | ||
4544 | @item | |
4545 | Greg Satz and Chris Hanson assisted in making GNU CC work on HP-UX for | |
4546 | the 9000 series 300. | |
4547 | ||
4548 | @item | |
4549 | William Schelter did most of the work on the Intel 80386 support. | |
4550 | ||
4551 | @item | |
4552 | Christopher Smith did the port for Convex machines. | |
4553 | ||
4554 | @item | |
4555 | Paul Petersen wrote the machine description for the Alliant FX/8. | |
4556 | ||
4557 | @item | |
4558 | Dario Dariol contributed the four varieties of sample programs | |
4559 | that print a copy of their source. | |
4560 | ||
4561 | @item | |
4562 | Alain Lichnewsky ported GNU CC to the Mips cpu. | |
4563 | ||
4564 | @item | |
4565 | Devon Bowen, Dale Wiles and Kevin Zachmann ported GNU CC to the Tahoe. | |
4566 | ||
4567 | @item | |
4568 | Jonathan Stone wrote the machine description for the Pyramid computer. | |
4569 | ||
4570 | @item | |
4571 | Gary Miller ported GNU CC to Charles River Data Systems machines. | |
4572 | ||
4573 | @item | |
4574 | Richard Kenner of the New York University Ultracomputer Research | |
4575 | Laboratory wrote the machine descriptions for the AMD 29000, the DEC | |
4576 | Alpha, the IBM RT PC, and the IBM RS/6000 as well as the support for | |
4577 | instruction attributes. He also made changes to better support RISC | |
4578 | processors including changes to common subexpression elimination, | |
4579 | strength reduction, function calling sequence handling, and condition | |
4580 | code support, in addition to generalizing the code for frame pointer | |
4581 | elimination. | |
4582 | ||
4583 | @item | |
4584 | Richard Kenner and Michael Tiemann jointly developed reorg.c, the delay | |
4585 | slot scheduler. | |
4586 | ||
4587 | @item | |
4588 | Mike Meissner and Tom Wood of Data General finished the port to the | |
4589 | Motorola 88000. | |
4590 | ||
4591 | @item | |
4592 | Masanobu Yuhara of Fujitsu Laboratories implemented the machine | |
4593 | description for the Tron architecture (specifically, the Gmicro). | |
4594 | ||
4595 | @item | |
4596 | NeXT, Inc.@: donated the front end that supports the Objective C | |
4597 | language. | |
4598 | @c We need to be careful to make it clear that "Objective C" | |
4599 | @c is the name of a language, not that of a program or product. | |
4600 | ||
4601 | @item | |
4602 | James van Artsdalen wrote the code that makes efficient use of | |
4603 | the Intel 80387 register stack. | |
4604 | ||
4605 | @item | |
4606 | Mike Meissner at the Open Software Foundation finished the port to the | |
4607 | MIPS cpu, including adding ECOFF debug support, and worked on the | |
4608 | Intel port for the Intel 80386 cpu. Later at Cygnus Support, he worked | |
4609 | on the rs6000 and PowerPC ports. | |
4610 | ||
4611 | @item | |
4612 | Ron Guilmette implemented the @code{protoize} and @code{unprotoize} | |
4613 | tools, the support for Dwarf symbolic debugging information, and much of | |
4614 | the support for System V Release 4. He has also worked heavily on the | |
4615 | Intel 386 and 860 support. | |
4616 | ||
4617 | @item | |
4618 | Torbjorn Granlund implemented multiply- and divide-by-constant | |
4619 | optimization, improved long long support, and improved leaf function | |
4620 | register allocation. | |
4621 | ||
4622 | @item | |
4623 | Mike Stump implemented the support for Elxsi 64 bit CPU. | |
4624 | ||
4625 | @item | |
4626 | John Wehle added the machine description for the Western Electric 32000 | |
4627 | processor used in several 3b series machines (no relation to the | |
4628 | National Semiconductor 32000 processor). | |
4629 | ||
4630 | @ignore @c These features aren't advertised yet, since they don't fully work. | |
4631 | @item | |
4632 | Analog Devices helped implement the support for complex data types | |
4633 | and iterators. | |
4634 | @end ignore | |
4635 | ||
4636 | @item | |
4637 | Holger Teutsch provided the support for the Clipper cpu. | |
4638 | ||
4639 | @item | |
4640 | Kresten Krab Thorup wrote the run time support for the Objective C | |
4641 | language. | |
4642 | ||
4643 | @item | |
4644 | Stephen Moshier contributed the floating point emulator that assists in | |
4645 | cross-compilation and permits support for floating point numbers wider | |
4646 | than 64 bits. | |
4647 | ||
4648 | @item | |
4649 | David Edelsohn contributed the changes to RS/6000 port to make it | |
4650 | support the PowerPC and POWER2 architectures. | |
4651 | ||
4652 | @item | |
4653 | Steve Chamberlain wrote the support for the Hitachi SH processor. | |
4654 | ||
4655 | @item | |
4656 | Peter Schauer wrote the code to allow debugging to work on the Alpha. | |
4657 | ||
4658 | @item | |
4659 | Oliver M. Kellogg of Deutsche Aerospace contributed the port to the | |
4660 | MIL-STD-1750A. | |
4661 | ||
4662 | @item | |
4663 | Michael K. Gschwind contributed the port to the PDP-11. | |
4664 | ||
4665 | @item | |
4666 | David Reese of Sun Microsystems contributed to the Solaris on PowerPC | |
4667 | port. | |
4668 | @end itemize | |
4669 | ||
4670 | @node Index | |
4671 | @unnumbered Index | |
4672 | @end ifset | |
4673 | ||
4674 | @ifclear INTERNALS | |
4675 | @node Index | |
4676 | @unnumbered Index | |
4677 | @end ifclear | |
4678 | ||
4679 | @printindex cp | |
4680 | ||
4681 | @summarycontents | |
4682 | @contents | |
4683 | @bye |