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