1 | This is Info file gcc.info, produced by Makeinfo version 1.67 from the |
---|
2 | input file gcc.texi. |
---|
3 | |
---|
4 | This file documents the use and the internals of the GNU compiler. |
---|
5 | |
---|
6 | Published by the Free Software Foundation 59 Temple Place - Suite 330 |
---|
7 | Boston, MA 02111-1307 USA |
---|
8 | |
---|
9 | Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998 |
---|
10 | Free Software Foundation, Inc. |
---|
11 | |
---|
12 | Permission is granted to make and distribute verbatim copies of this |
---|
13 | manual provided the copyright notice and this permission notice are |
---|
14 | preserved on all copies. |
---|
15 | |
---|
16 | Permission is granted to copy and distribute modified versions of |
---|
17 | this manual under the conditions for verbatim copying, provided also |
---|
18 | that the sections entitled "GNU General Public License," "Funding for |
---|
19 | Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are |
---|
20 | included exactly as in the original, and provided that the entire |
---|
21 | resulting derived work is distributed under the terms of a permission |
---|
22 | notice identical to this one. |
---|
23 | |
---|
24 | Permission is granted to copy and distribute translations of this |
---|
25 | manual into another language, under the above conditions for modified |
---|
26 | versions, except that the sections entitled "GNU General Public |
---|
27 | License," "Funding for Free Software," and "Protect Your Freedom--Fight |
---|
28 | `Look And Feel'", and this permission notice, may be included in |
---|
29 | translations approved by the Free Software Foundation instead of in the |
---|
30 | original English. |
---|
31 | |
---|
32 | |
---|
33 | File: gcc.info, Node: External Bugs, Next: Incompatibilities, Prev: Interoperation, Up: Trouble |
---|
34 | |
---|
35 | Problems Compiling Certain Programs |
---|
36 | =================================== |
---|
37 | |
---|
38 | Certain programs have problems compiling. |
---|
39 | |
---|
40 | * Parse errors may occur compiling X11 on a Decstation running |
---|
41 | Ultrix 4.2 because of problems in DEC's versions of the X11 header |
---|
42 | files `X11/Xlib.h' and `X11/Xutil.h'. People recommend adding |
---|
43 | `-I/usr/include/mit' to use the MIT versions of the header files, |
---|
44 | using the `-traditional' switch to turn off ANSI C, or fixing the |
---|
45 | header files by adding this: |
---|
46 | |
---|
47 | #ifdef __STDC__ |
---|
48 | #define NeedFunctionPrototypes 0 |
---|
49 | #endif |
---|
50 | |
---|
51 | * If you have trouble compiling Perl on a SunOS 4 system, it may be |
---|
52 | because Perl specifies `-I/usr/ucbinclude'. This accesses the |
---|
53 | unfixed header files. Perl specifies the options |
---|
54 | |
---|
55 | -traditional -Dvolatile=__volatile__ |
---|
56 | -I/usr/include/sun -I/usr/ucbinclude |
---|
57 | -fpcc-struct-return |
---|
58 | |
---|
59 | most of which are unnecessary with GCC 2.4.5 and newer versions. |
---|
60 | You can make a properly working Perl by setting `ccflags' to |
---|
61 | `-fwritable-strings' (implied by the `-traditional' in the |
---|
62 | original options) and `cppflags' to empty in `config.sh', then |
---|
63 | typing `./doSH; make depend; make'. |
---|
64 | |
---|
65 | * On various 386 Unix systems derived from System V, including SCO, |
---|
66 | ISC, and ESIX, you may get error messages about running out of |
---|
67 | virtual memory while compiling certain programs. |
---|
68 | |
---|
69 | You can prevent this problem by linking GNU CC with the GNU malloc |
---|
70 | (which thus replaces the malloc that comes with the system). GNU |
---|
71 | malloc is available as a separate package, and also in the file |
---|
72 | `src/gmalloc.c' in the GNU Emacs 19 distribution. |
---|
73 | |
---|
74 | If you have installed GNU malloc as a separate library package, |
---|
75 | use this option when you relink GNU CC: |
---|
76 | |
---|
77 | MALLOC=/usr/local/lib/libgmalloc.a |
---|
78 | |
---|
79 | Alternatively, if you have compiled `gmalloc.c' from Emacs 19, copy |
---|
80 | the object file to `gmalloc.o' and use this option when you relink |
---|
81 | GNU CC: |
---|
82 | |
---|
83 | MALLOC=gmalloc.o |
---|
84 | |
---|
85 | |
---|
86 | File: gcc.info, Node: Incompatibilities, Next: Fixed Headers, Prev: External Bugs, Up: Trouble |
---|
87 | |
---|
88 | Incompatibilities of GNU CC |
---|
89 | =========================== |
---|
90 | |
---|
91 | There are several noteworthy incompatibilities between GNU C and most |
---|
92 | existing (non-ANSI) versions of C. The `-traditional' option |
---|
93 | eliminates many of these incompatibilities, *but not all*, by telling |
---|
94 | GNU C to behave like the other C compilers. |
---|
95 | |
---|
96 | * GNU CC normally makes string constants read-only. If several |
---|
97 | identical-looking string constants are used, GNU CC stores only one |
---|
98 | copy of the string. |
---|
99 | |
---|
100 | One consequence is that you cannot call `mktemp' with a string |
---|
101 | constant argument. The function `mktemp' always alters the string |
---|
102 | its argument points to. |
---|
103 | |
---|
104 | Another consequence is that `sscanf' does not work on some systems |
---|
105 | when passed a string constant as its format control string or |
---|
106 | input. This is because `sscanf' incorrectly tries to write into |
---|
107 | the string constant. Likewise `fscanf' and `scanf'. |
---|
108 | |
---|
109 | The best solution to these problems is to change the program to use |
---|
110 | `char'-array variables with initialization strings for these |
---|
111 | purposes instead of string constants. But if this is not possible, |
---|
112 | you can use the `-fwritable-strings' flag, which directs GNU CC to |
---|
113 | handle string constants the same way most C compilers do. |
---|
114 | `-traditional' also has this effect, among others. |
---|
115 | |
---|
116 | * `-2147483648' is positive. |
---|
117 | |
---|
118 | This is because 2147483648 cannot fit in the type `int', so |
---|
119 | (following the ANSI C rules) its data type is `unsigned long int'. |
---|
120 | Negating this value yields 2147483648 again. |
---|
121 | |
---|
122 | * GNU CC does not substitute macro arguments when they appear inside |
---|
123 | of string constants. For example, the following macro in GNU CC |
---|
124 | |
---|
125 | #define foo(a) "a" |
---|
126 | |
---|
127 | will produce output `"a"' regardless of what the argument A is. |
---|
128 | |
---|
129 | The `-traditional' option directs GNU CC to handle such cases |
---|
130 | (among others) in the old-fashioned (non-ANSI) fashion. |
---|
131 | |
---|
132 | * When you use `setjmp' and `longjmp', the only automatic variables |
---|
133 | guaranteed to remain valid are those declared `volatile'. This is |
---|
134 | a consequence of automatic register allocation. Consider this |
---|
135 | function: |
---|
136 | |
---|
137 | jmp_buf j; |
---|
138 | |
---|
139 | foo () |
---|
140 | { |
---|
141 | int a, b; |
---|
142 | |
---|
143 | a = fun1 (); |
---|
144 | if (setjmp (j)) |
---|
145 | return a; |
---|
146 | |
---|
147 | a = fun2 (); |
---|
148 | /* `longjmp (j)' may occur in `fun3'. */ |
---|
149 | return a + fun3 (); |
---|
150 | } |
---|
151 | |
---|
152 | Here `a' may or may not be restored to its first value when the |
---|
153 | `longjmp' occurs. If `a' is allocated in a register, then its |
---|
154 | first value is restored; otherwise, it keeps the last value stored |
---|
155 | in it. |
---|
156 | |
---|
157 | If you use the `-W' option with the `-O' option, you will get a |
---|
158 | warning when GNU CC thinks such a problem might be possible. |
---|
159 | |
---|
160 | The `-traditional' option directs GNU C to put variables in the |
---|
161 | stack by default, rather than in registers, in functions that call |
---|
162 | `setjmp'. This results in the behavior found in traditional C |
---|
163 | compilers. |
---|
164 | |
---|
165 | * Programs that use preprocessing directives in the middle of macro |
---|
166 | arguments do not work with GNU CC. For example, a program like |
---|
167 | this will not work: |
---|
168 | |
---|
169 | foobar ( |
---|
170 | #define luser |
---|
171 | hack) |
---|
172 | |
---|
173 | ANSI C does not permit such a construct. It would make sense to |
---|
174 | support it when `-traditional' is used, but it is too much work to |
---|
175 | implement. |
---|
176 | |
---|
177 | * Declarations of external variables and functions within a block |
---|
178 | apply only to the block containing the declaration. In other |
---|
179 | words, they have the same scope as any other declaration in the |
---|
180 | same place. |
---|
181 | |
---|
182 | In some other C compilers, a `extern' declaration affects all the |
---|
183 | rest of the file even if it happens within a block. |
---|
184 | |
---|
185 | The `-traditional' option directs GNU C to treat all `extern' |
---|
186 | declarations as global, like traditional compilers. |
---|
187 | |
---|
188 | * In traditional C, you can combine `long', etc., with a typedef |
---|
189 | name, as shown here: |
---|
190 | |
---|
191 | typedef int foo; |
---|
192 | typedef long foo bar; |
---|
193 | |
---|
194 | In ANSI C, this is not allowed: `long' and other type modifiers |
---|
195 | require an explicit `int'. Because this criterion is expressed by |
---|
196 | Bison grammar rules rather than C code, the `-traditional' flag |
---|
197 | cannot alter it. |
---|
198 | |
---|
199 | * PCC allows typedef names to be used as function parameters. The |
---|
200 | difficulty described immediately above applies here too. |
---|
201 | |
---|
202 | * PCC allows whitespace in the middle of compound assignment |
---|
203 | operators such as `+='. GNU CC, following the ANSI standard, does |
---|
204 | not allow this. The difficulty described immediately above |
---|
205 | applies here too. |
---|
206 | |
---|
207 | * GNU CC complains about unterminated character constants inside of |
---|
208 | preprocessing conditionals that fail. Some programs have English |
---|
209 | comments enclosed in conditionals that are guaranteed to fail; if |
---|
210 | these comments contain apostrophes, GNU CC will probably report an |
---|
211 | error. For example, this code would produce an error: |
---|
212 | |
---|
213 | #if 0 |
---|
214 | You can't expect this to work. |
---|
215 | #endif |
---|
216 | |
---|
217 | The best solution to such a problem is to put the text into an |
---|
218 | actual C comment delimited by `/*...*/'. However, `-traditional' |
---|
219 | suppresses these error messages. |
---|
220 | |
---|
221 | * Many user programs contain the declaration `long time ();'. In the |
---|
222 | past, the system header files on many systems did not actually |
---|
223 | declare `time', so it did not matter what type your program |
---|
224 | declared it to return. But in systems with ANSI C headers, `time' |
---|
225 | is declared to return `time_t', and if that is not the same as |
---|
226 | `long', then `long time ();' is erroneous. |
---|
227 | |
---|
228 | The solution is to change your program to use `time_t' as the |
---|
229 | return type of `time'. |
---|
230 | |
---|
231 | * When compiling functions that return `float', PCC converts it to a |
---|
232 | double. GNU CC actually returns a `float'. If you are concerned |
---|
233 | with PCC compatibility, you should declare your functions to return |
---|
234 | `double'; you might as well say what you mean. |
---|
235 | |
---|
236 | * When compiling functions that return structures or unions, GNU CC |
---|
237 | output code normally uses a method different from that used on most |
---|
238 | versions of Unix. As a result, code compiled with GNU CC cannot |
---|
239 | call a structure-returning function compiled with PCC, and vice |
---|
240 | versa. |
---|
241 | |
---|
242 | The method used by GNU CC is as follows: a structure or union |
---|
243 | which is 1, 2, 4 or 8 bytes long is returned like a scalar. A |
---|
244 | structure or union with any other size is stored into an address |
---|
245 | supplied by the caller (usually in a special, fixed register, but |
---|
246 | on some machines it is passed on the stack). The |
---|
247 | machine-description macros `STRUCT_VALUE' and |
---|
248 | `STRUCT_INCOMING_VALUE' tell GNU CC where to pass this address. |
---|
249 | |
---|
250 | By contrast, PCC on most target machines returns structures and |
---|
251 | unions of any size by copying the data into an area of static |
---|
252 | storage, and then returning the address of that storage as if it |
---|
253 | were a pointer value. The caller must copy the data from that |
---|
254 | memory area to the place where the value is wanted. GNU CC does |
---|
255 | not use this method because it is slower and nonreentrant. |
---|
256 | |
---|
257 | On some newer machines, PCC uses a reentrant convention for all |
---|
258 | structure and union returning. GNU CC on most of these machines |
---|
259 | uses a compatible convention when returning structures and unions |
---|
260 | in memory, but still returns small structures and unions in |
---|
261 | registers. |
---|
262 | |
---|
263 | You can tell GNU CC to use a compatible convention for all |
---|
264 | structure and union returning with the option |
---|
265 | `-fpcc-struct-return'. |
---|
266 | |
---|
267 | * GNU C complains about program fragments such as `0x74ae-0x4000' |
---|
268 | which appear to be two hexadecimal constants separated by the minus |
---|
269 | operator. Actually, this string is a single "preprocessing token". |
---|
270 | Each such token must correspond to one token in C. Since this |
---|
271 | does not, GNU C prints an error message. Although it may appear |
---|
272 | obvious that what is meant is an operator and two values, the ANSI |
---|
273 | C standard specifically requires that this be treated as erroneous. |
---|
274 | |
---|
275 | A "preprocessing token" is a "preprocessing number" if it begins |
---|
276 | with a digit and is followed by letters, underscores, digits, |
---|
277 | periods and `e+', `e-', `E+', or `E-' character sequences. |
---|
278 | |
---|
279 | To make the above program fragment valid, place whitespace in |
---|
280 | front of the minus sign. This whitespace will end the |
---|
281 | preprocessing number. |
---|
282 | |
---|
283 | |
---|
284 | File: gcc.info, Node: Fixed Headers, Next: Standard Libraries, Prev: Incompatibilities, Up: Trouble |
---|
285 | |
---|
286 | Fixed Header Files |
---|
287 | ================== |
---|
288 | |
---|
289 | GNU CC needs to install corrected versions of some system header |
---|
290 | files. This is because most target systems have some header files that |
---|
291 | won't work with GNU CC unless they are changed. Some have bugs, some |
---|
292 | are incompatible with ANSI C, and some depend on special features of |
---|
293 | other compilers. |
---|
294 | |
---|
295 | Installing GNU CC automatically creates and installs the fixed header |
---|
296 | files, by running a program called `fixincludes' (or for certain |
---|
297 | targets an alternative such as `fixinc.svr4'). Normally, you don't |
---|
298 | need to pay attention to this. But there are cases where it doesn't do |
---|
299 | the right thing automatically. |
---|
300 | |
---|
301 | * If you update the system's header files, such as by installing a |
---|
302 | new system version, the fixed header files of GNU CC are not |
---|
303 | automatically updated. The easiest way to update them is to |
---|
304 | reinstall GNU CC. (If you want to be clever, look in the makefile |
---|
305 | and you can find a shortcut.) |
---|
306 | |
---|
307 | * On some systems, in particular SunOS 4, header file directories |
---|
308 | contain machine-specific symbolic links in certain places. This |
---|
309 | makes it possible to share most of the header files among hosts |
---|
310 | running the same version of SunOS 4 on different machine models. |
---|
311 | |
---|
312 | The programs that fix the header files do not understand this |
---|
313 | special way of using symbolic links; therefore, the directory of |
---|
314 | fixed header files is good only for the machine model used to |
---|
315 | build it. |
---|
316 | |
---|
317 | In SunOS 4, only programs that look inside the kernel will notice |
---|
318 | the difference between machine models. Therefore, for most |
---|
319 | purposes, you need not be concerned about this. |
---|
320 | |
---|
321 | It is possible to make separate sets of fixed header files for the |
---|
322 | different machine models, and arrange a structure of symbolic |
---|
323 | links so as to use the proper set, but you'll have to do this by |
---|
324 | hand. |
---|
325 | |
---|
326 | * On Lynxos, GNU CC by default does not fix the header files. This |
---|
327 | is because bugs in the shell cause the `fixincludes' script to |
---|
328 | fail. |
---|
329 | |
---|
330 | This means you will encounter problems due to bugs in the system |
---|
331 | header files. It may be no comfort that they aren't GNU CC's |
---|
332 | fault, but it does mean that there's nothing for us to do about |
---|
333 | them. |
---|
334 | |
---|
335 | |
---|
336 | File: gcc.info, Node: Standard Libraries, Next: Disappointments, Prev: Fixed Headers, Up: Trouble |
---|
337 | |
---|
338 | Standard Libraries |
---|
339 | ================== |
---|
340 | |
---|
341 | GNU CC by itself attempts to be what the ISO/ANSI C standard calls a |
---|
342 | "conforming freestanding implementation". This means all ANSI C |
---|
343 | language features are available, as well as the contents of `float.h', |
---|
344 | `limits.h', `stdarg.h', and `stddef.h'. The rest of the C library is |
---|
345 | supplied by the vendor of the operating system. If that C library |
---|
346 | doesn't conform to the C standards, then your programs might get |
---|
347 | warnings (especially when using `-Wall') that you don't expect. |
---|
348 | |
---|
349 | For example, the `sprintf' function on SunOS 4.1.3 returns `char *' |
---|
350 | while the C standard says that `sprintf' returns an `int'. The |
---|
351 | `fixincludes' program could make the prototype for this function match |
---|
352 | the Standard, but that would be wrong, since the function will still |
---|
353 | return `char *'. |
---|
354 | |
---|
355 | If you need a Standard compliant library, then you need to find one, |
---|
356 | as GNU CC does not provide one. The GNU C library (called `glibc') has |
---|
357 | been ported to a number of operating systems, and provides ANSI/ISO, |
---|
358 | POSIX, BSD and SystemV compatibility. You could also ask your operating |
---|
359 | system vendor if newer libraries are available. |
---|
360 | |
---|
361 | |
---|
362 | File: gcc.info, Node: Disappointments, Next: C++ Misunderstandings, Prev: Standard Libraries, Up: Trouble |
---|
363 | |
---|
364 | Disappointments and Misunderstandings |
---|
365 | ===================================== |
---|
366 | |
---|
367 | These problems are perhaps regrettable, but we don't know any |
---|
368 | practical way around them. |
---|
369 | |
---|
370 | * Certain local variables aren't recognized by debuggers when you |
---|
371 | compile with optimization. |
---|
372 | |
---|
373 | This occurs because sometimes GNU CC optimizes the variable out of |
---|
374 | existence. There is no way to tell the debugger how to compute the |
---|
375 | value such a variable "would have had", and it is not clear that |
---|
376 | would be desirable anyway. So GNU CC simply does not mention the |
---|
377 | eliminated variable when it writes debugging information. |
---|
378 | |
---|
379 | You have to expect a certain amount of disagreement between the |
---|
380 | executable and your source code, when you use optimization. |
---|
381 | |
---|
382 | * Users often think it is a bug when GNU CC reports an error for code |
---|
383 | like this: |
---|
384 | |
---|
385 | int foo (struct mumble *); |
---|
386 | |
---|
387 | struct mumble { ... }; |
---|
388 | |
---|
389 | int foo (struct mumble *x) |
---|
390 | { ... } |
---|
391 | |
---|
392 | This code really is erroneous, because the scope of `struct |
---|
393 | mumble' in the prototype is limited to the argument list |
---|
394 | containing it. It does not refer to the `struct mumble' defined |
---|
395 | with file scope immediately below--they are two unrelated types |
---|
396 | with similar names in different scopes. |
---|
397 | |
---|
398 | But in the definition of `foo', the file-scope type is used |
---|
399 | because that is available to be inherited. Thus, the definition |
---|
400 | and the prototype do not match, and you get an error. |
---|
401 | |
---|
402 | This behavior may seem silly, but it's what the ANSI standard |
---|
403 | specifies. It is easy enough for you to make your code work by |
---|
404 | moving the definition of `struct mumble' above the prototype. |
---|
405 | It's not worth being incompatible with ANSI C just to avoid an |
---|
406 | error for the example shown above. |
---|
407 | |
---|
408 | * Accesses to bitfields even in volatile objects works by accessing |
---|
409 | larger objects, such as a byte or a word. You cannot rely on what |
---|
410 | size of object is accessed in order to read or write the bitfield; |
---|
411 | it may even vary for a given bitfield according to the precise |
---|
412 | usage. |
---|
413 | |
---|
414 | If you care about controlling the amount of memory that is |
---|
415 | accessed, use volatile but do not use bitfields. |
---|
416 | |
---|
417 | * GNU CC comes with shell scripts to fix certain known problems in |
---|
418 | system header files. They install corrected copies of various |
---|
419 | header files in a special directory where only GNU CC will |
---|
420 | normally look for them. The scripts adapt to various systems by |
---|
421 | searching all the system header files for the problem cases that |
---|
422 | we know about. |
---|
423 | |
---|
424 | If new system header files are installed, nothing automatically |
---|
425 | arranges to update the corrected header files. You will have to |
---|
426 | reinstall GNU CC to fix the new header files. More specifically, |
---|
427 | go to the build directory and delete the files `stmp-fixinc' and |
---|
428 | `stmp-headers', and the subdirectory `include'; then do `make |
---|
429 | install' again. |
---|
430 | |
---|
431 | * On 68000 and x86 systems, for instance, you can get paradoxical |
---|
432 | results if you test the precise values of floating point numbers. |
---|
433 | For example, you can find that a floating point value which is not |
---|
434 | a NaN is not equal to itself. This results from the fact that the |
---|
435 | floating point registers hold a few more bits of precision than |
---|
436 | fit in a `double' in memory. Compiled code moves values between |
---|
437 | memory and floating point registers at its convenience, and moving |
---|
438 | them into memory truncates them. |
---|
439 | |
---|
440 | You can partially avoid this problem by using the `-ffloat-store' |
---|
441 | option (*note Optimize Options::.). |
---|
442 | |
---|
443 | * On the MIPS, variable argument functions using `varargs.h' cannot |
---|
444 | have a floating point value for the first argument. The reason |
---|
445 | for this is that in the absence of a prototype in scope, if the |
---|
446 | first argument is a floating point, it is passed in a floating |
---|
447 | point register, rather than an integer register. |
---|
448 | |
---|
449 | If the code is rewritten to use the ANSI standard `stdarg.h' |
---|
450 | method of variable arguments, and the prototype is in scope at the |
---|
451 | time of the call, everything will work fine. |
---|
452 | |
---|
453 | * On the H8/300 and H8/300H, variable argument functions must be |
---|
454 | implemented using the ANSI standard `stdarg.h' method of variable |
---|
455 | arguments. Furthermore, calls to functions using `stdarg.h' |
---|
456 | variable arguments must have a prototype for the called function |
---|
457 | in scope at the time of the call. |
---|
458 | |
---|
459 | |
---|
460 | File: gcc.info, Node: C++ Misunderstandings, Next: Protoize Caveats, Prev: Disappointments, Up: Trouble |
---|
461 | |
---|
462 | Common Misunderstandings with GNU C++ |
---|
463 | ===================================== |
---|
464 | |
---|
465 | C++ is a complex language and an evolving one, and its standard |
---|
466 | definition (the ANSI C++ draft standard) is also evolving. As a result, |
---|
467 | your C++ compiler may occasionally surprise you, even when its behavior |
---|
468 | is correct. This section discusses some areas that frequently give |
---|
469 | rise to questions of this sort. |
---|
470 | |
---|
471 | * Menu: |
---|
472 | |
---|
473 | * Static Definitions:: Static member declarations are not definitions |
---|
474 | * Temporaries:: Temporaries may vanish before you expect |
---|
475 | |
---|
476 | |
---|
477 | File: gcc.info, Node: Static Definitions, Next: Temporaries, Up: C++ Misunderstandings |
---|
478 | |
---|
479 | Declare *and* Define Static Members |
---|
480 | ----------------------------------- |
---|
481 | |
---|
482 | When a class has static data members, it is not enough to *declare* |
---|
483 | the static member; you must also *define* it. For example: |
---|
484 | |
---|
485 | class Foo |
---|
486 | { |
---|
487 | ... |
---|
488 | void method(); |
---|
489 | static int bar; |
---|
490 | }; |
---|
491 | |
---|
492 | This declaration only establishes that the class `Foo' has an `int' |
---|
493 | named `Foo::bar', and a member function named `Foo::method'. But you |
---|
494 | still need to define *both* `method' and `bar' elsewhere. According to |
---|
495 | the draft ANSI standard, you must supply an initializer in one (and |
---|
496 | only one) source file, such as: |
---|
497 | |
---|
498 | int Foo::bar = 0; |
---|
499 | |
---|
500 | Other C++ compilers may not correctly implement the standard |
---|
501 | behavior. As a result, when you switch to `g++' from one of these |
---|
502 | compilers, you may discover that a program that appeared to work |
---|
503 | correctly in fact does not conform to the standard: `g++' reports as |
---|
504 | undefined symbols any static data members that lack definitions. |
---|
505 | |
---|
506 | |
---|
507 | File: gcc.info, Node: Temporaries, Prev: Static Definitions, Up: C++ Misunderstandings |
---|
508 | |
---|
509 | Temporaries May Vanish Before You Expect |
---|
510 | ---------------------------------------- |
---|
511 | |
---|
512 | It is dangerous to use pointers or references to *portions* of a |
---|
513 | temporary object. The compiler may very well delete the object before |
---|
514 | you expect it to, leaving a pointer to garbage. The most common place |
---|
515 | where this problem crops up is in classes like the libg++ `String' |
---|
516 | class, that define a conversion function to type `char *' or `const |
---|
517 | char *'. However, any class that returns a pointer to some internal |
---|
518 | structure is potentially subject to this problem. |
---|
519 | |
---|
520 | For example, a program may use a function `strfunc' that returns |
---|
521 | `String' objects, and another function `charfunc' that operates on |
---|
522 | pointers to `char': |
---|
523 | |
---|
524 | String strfunc (); |
---|
525 | void charfunc (const char *); |
---|
526 | |
---|
527 | In this situation, it may seem natural to write |
---|
528 | `charfunc (strfunc ());' based on the knowledge that class `String' has |
---|
529 | an explicit conversion to `char' pointers. However, what really |
---|
530 | happens is akin to `charfunc (strfunc ().convert ());', where the |
---|
531 | `convert' method is a function to do the same data conversion normally |
---|
532 | performed by a cast. Since the last use of the temporary `String' |
---|
533 | object is the call to the conversion function, the compiler may delete |
---|
534 | that object before actually calling `charfunc'. The compiler has no |
---|
535 | way of knowing that deleting the `String' object will invalidate the |
---|
536 | pointer. The pointer then points to garbage, so that by the time |
---|
537 | `charfunc' is called, it gets an invalid argument. |
---|
538 | |
---|
539 | Code like this may run successfully under some other compilers, |
---|
540 | especially those that delete temporaries relatively late. However, the |
---|
541 | GNU C++ behavior is also standard-conforming, so if your program depends |
---|
542 | on late destruction of temporaries it is not portable. |
---|
543 | |
---|
544 | If you think this is surprising, you should be aware that the ANSI |
---|
545 | C++ committee continues to debate the lifetime-of-temporaries problem. |
---|
546 | |
---|
547 | For now, at least, the safe way to write such code is to give the |
---|
548 | temporary a name, which forces it to remain until the end of the scope |
---|
549 | of the name. For example: |
---|
550 | |
---|
551 | String& tmp = strfunc (); |
---|
552 | charfunc (tmp); |
---|
553 | |
---|
554 | |
---|
555 | File: gcc.info, Node: Protoize Caveats, Next: Non-bugs, Prev: C++ Misunderstandings, Up: Trouble |
---|
556 | |
---|
557 | Caveats of using `protoize' |
---|
558 | =========================== |
---|
559 | |
---|
560 | The conversion programs `protoize' and `unprotoize' can sometimes |
---|
561 | change a source file in a way that won't work unless you rearrange it. |
---|
562 | |
---|
563 | * `protoize' can insert references to a type name or type tag before |
---|
564 | the definition, or in a file where they are not defined. |
---|
565 | |
---|
566 | If this happens, compiler error messages should show you where the |
---|
567 | new references are, so fixing the file by hand is straightforward. |
---|
568 | |
---|
569 | * There are some C constructs which `protoize' cannot figure out. |
---|
570 | For example, it can't determine argument types for declaring a |
---|
571 | pointer-to-function variable; this you must do by hand. `protoize' |
---|
572 | inserts a comment containing `???' each time it finds such a |
---|
573 | variable; so you can find all such variables by searching for this |
---|
574 | string. ANSI C does not require declaring the argument types of |
---|
575 | pointer-to-function types. |
---|
576 | |
---|
577 | * Using `unprotoize' can easily introduce bugs. If the program |
---|
578 | relied on prototypes to bring about conversion of arguments, these |
---|
579 | conversions will not take place in the program without prototypes. |
---|
580 | One case in which you can be sure `unprotoize' is safe is when you |
---|
581 | are removing prototypes that were made with `protoize'; if the |
---|
582 | program worked before without any prototypes, it will work again |
---|
583 | without them. |
---|
584 | |
---|
585 | You can find all the places where this problem might occur by |
---|
586 | compiling the program with the `-Wconversion' option. It prints a |
---|
587 | warning whenever an argument is converted. |
---|
588 | |
---|
589 | * Both conversion programs can be confused if there are macro calls |
---|
590 | in and around the text to be converted. In other words, the |
---|
591 | standard syntax for a declaration or definition must not result |
---|
592 | from expanding a macro. This problem is inherent in the design of |
---|
593 | C and cannot be fixed. If only a few functions have confusing |
---|
594 | macro calls, you can easily convert them manually. |
---|
595 | |
---|
596 | * `protoize' cannot get the argument types for a function whose |
---|
597 | definition was not actually compiled due to preprocessing |
---|
598 | conditionals. When this happens, `protoize' changes nothing in |
---|
599 | regard to such a function. `protoize' tries to detect such |
---|
600 | instances and warn about them. |
---|
601 | |
---|
602 | You can generally work around this problem by using `protoize' step |
---|
603 | by step, each time specifying a different set of `-D' options for |
---|
604 | compilation, until all of the functions have been converted. |
---|
605 | There is no automatic way to verify that you have got them all, |
---|
606 | however. |
---|
607 | |
---|
608 | * Confusion may result if there is an occasion to convert a function |
---|
609 | declaration or definition in a region of source code where there |
---|
610 | is more than one formal parameter list present. Thus, attempts to |
---|
611 | convert code containing multiple (conditionally compiled) versions |
---|
612 | of a single function header (in the same vicinity) may not produce |
---|
613 | the desired (or expected) results. |
---|
614 | |
---|
615 | If you plan on converting source files which contain such code, it |
---|
616 | is recommended that you first make sure that each conditionally |
---|
617 | compiled region of source code which contains an alternative |
---|
618 | function header also contains at least one additional follower |
---|
619 | token (past the final right parenthesis of the function header). |
---|
620 | This should circumvent the problem. |
---|
621 | |
---|
622 | * `unprotoize' can become confused when trying to convert a function |
---|
623 | definition or declaration which contains a declaration for a |
---|
624 | pointer-to-function formal argument which has the same name as the |
---|
625 | function being defined or declared. We recommand you avoid such |
---|
626 | choices of formal parameter names. |
---|
627 | |
---|
628 | * You might also want to correct some of the indentation by hand and |
---|
629 | break long lines. (The conversion programs don't write lines |
---|
630 | longer than eighty characters in any case.) |
---|
631 | |
---|
632 | |
---|
633 | File: gcc.info, Node: Non-bugs, Next: Warnings and Errors, Prev: Protoize Caveats, Up: Trouble |
---|
634 | |
---|
635 | Certain Changes We Don't Want to Make |
---|
636 | ===================================== |
---|
637 | |
---|
638 | This section lists changes that people frequently request, but which |
---|
639 | we do not make because we think GNU CC is better without them. |
---|
640 | |
---|
641 | * Checking the number and type of arguments to a function which has |
---|
642 | an old-fashioned definition and no prototype. |
---|
643 | |
---|
644 | Such a feature would work only occasionally--only for calls that |
---|
645 | appear in the same file as the called function, following the |
---|
646 | definition. The only way to check all calls reliably is to add a |
---|
647 | prototype for the function. But adding a prototype eliminates the |
---|
648 | motivation for this feature. So the feature is not worthwhile. |
---|
649 | |
---|
650 | * Warning about using an expression whose type is signed as a shift |
---|
651 | count. |
---|
652 | |
---|
653 | Shift count operands are probably signed more often than unsigned. |
---|
654 | Warning about this would cause far more annoyance than good. |
---|
655 | |
---|
656 | * Warning about assigning a signed value to an unsigned variable. |
---|
657 | |
---|
658 | Such assignments must be very common; warning about them would |
---|
659 | cause more annoyance than good. |
---|
660 | |
---|
661 | * Warning about unreachable code. |
---|
662 | |
---|
663 | It's very common to have unreachable code in machine-generated |
---|
664 | programs. For example, this happens normally in some files of GNU |
---|
665 | C itself. |
---|
666 | |
---|
667 | * Warning when a non-void function value is ignored. |
---|
668 | |
---|
669 | Coming as I do from a Lisp background, I balk at the idea that |
---|
670 | there is something dangerous about discarding a value. There are |
---|
671 | functions that return values which some callers may find useful; |
---|
672 | it makes no sense to clutter the program with a cast to `void' |
---|
673 | whenever the value isn't useful. |
---|
674 | |
---|
675 | * Assuming (for optimization) that the address of an external symbol |
---|
676 | is never zero. |
---|
677 | |
---|
678 | This assumption is false on certain systems when `#pragma weak' is |
---|
679 | used. |
---|
680 | |
---|
681 | * Making `-fshort-enums' the default. |
---|
682 | |
---|
683 | This would cause storage layout to be incompatible with most other |
---|
684 | C compilers. And it doesn't seem very important, given that you |
---|
685 | can get the same result in other ways. The case where it matters |
---|
686 | most is when the enumeration-valued object is inside a structure, |
---|
687 | and in that case you can specify a field width explicitly. |
---|
688 | |
---|
689 | * Making bitfields unsigned by default on particular machines where |
---|
690 | "the ABI standard" says to do so. |
---|
691 | |
---|
692 | The ANSI C standard leaves it up to the implementation whether a |
---|
693 | bitfield declared plain `int' is signed or not. This in effect |
---|
694 | creates two alternative dialects of C. |
---|
695 | |
---|
696 | The GNU C compiler supports both dialects; you can specify the |
---|
697 | signed dialect with `-fsigned-bitfields' and the unsigned dialect |
---|
698 | with `-funsigned-bitfields'. However, this leaves open the |
---|
699 | question of which dialect to use by default. |
---|
700 | |
---|
701 | Currently, the preferred dialect makes plain bitfields signed, |
---|
702 | because this is simplest. Since `int' is the same as `signed int' |
---|
703 | in every other context, it is cleanest for them to be the same in |
---|
704 | bitfields as well. |
---|
705 | |
---|
706 | Some computer manufacturers have published Application Binary |
---|
707 | Interface standards which specify that plain bitfields should be |
---|
708 | unsigned. It is a mistake, however, to say anything about this |
---|
709 | issue in an ABI. This is because the handling of plain bitfields |
---|
710 | distinguishes two dialects of C. Both dialects are meaningful on |
---|
711 | every type of machine. Whether a particular object file was |
---|
712 | compiled using signed bitfields or unsigned is of no concern to |
---|
713 | other object files, even if they access the same bitfields in the |
---|
714 | same data structures. |
---|
715 | |
---|
716 | A given program is written in one or the other of these two |
---|
717 | dialects. The program stands a chance to work on most any machine |
---|
718 | if it is compiled with the proper dialect. It is unlikely to work |
---|
719 | at all if compiled with the wrong dialect. |
---|
720 | |
---|
721 | Many users appreciate the GNU C compiler because it provides an |
---|
722 | environment that is uniform across machines. These users would be |
---|
723 | inconvenienced if the compiler treated plain bitfields differently |
---|
724 | on certain machines. |
---|
725 | |
---|
726 | Occasionally users write programs intended only for a particular |
---|
727 | machine type. On these occasions, the users would benefit if the |
---|
728 | GNU C compiler were to support by default the same dialect as the |
---|
729 | other compilers on that machine. But such applications are rare. |
---|
730 | And users writing a program to run on more than one type of |
---|
731 | machine cannot possibly benefit from this kind of compatibility. |
---|
732 | |
---|
733 | This is why GNU CC does and will treat plain bitfields in the same |
---|
734 | fashion on all types of machines (by default). |
---|
735 | |
---|
736 | There are some arguments for making bitfields unsigned by default |
---|
737 | on all machines. If, for example, this becomes a universal de |
---|
738 | facto standard, it would make sense for GNU CC to go along with |
---|
739 | it. This is something to be considered in the future. |
---|
740 | |
---|
741 | (Of course, users strongly concerned about portability should |
---|
742 | indicate explicitly in each bitfield whether it is signed or not. |
---|
743 | In this way, they write programs which have the same meaning in |
---|
744 | both C dialects.) |
---|
745 | |
---|
746 | * Undefining `__STDC__' when `-ansi' is not used. |
---|
747 | |
---|
748 | Currently, GNU CC defines `__STDC__' as long as you don't use |
---|
749 | `-traditional'. This provides good results in practice. |
---|
750 | |
---|
751 | Programmers normally use conditionals on `__STDC__' to ask whether |
---|
752 | it is safe to use certain features of ANSI C, such as function |
---|
753 | prototypes or ANSI token concatenation. Since plain `gcc' supports |
---|
754 | all the features of ANSI C, the correct answer to these questions |
---|
755 | is "yes". |
---|
756 | |
---|
757 | Some users try to use `__STDC__' to check for the availability of |
---|
758 | certain library facilities. This is actually incorrect usage in |
---|
759 | an ANSI C program, because the ANSI C standard says that a |
---|
760 | conforming freestanding implementation should define `__STDC__' |
---|
761 | even though it does not have the library facilities. `gcc -ansi |
---|
762 | -pedantic' is a conforming freestanding implementation, and it is |
---|
763 | therefore required to define `__STDC__', even though it does not |
---|
764 | come with an ANSI C library. |
---|
765 | |
---|
766 | Sometimes people say that defining `__STDC__' in a compiler that |
---|
767 | does not completely conform to the ANSI C standard somehow |
---|
768 | violates the standard. This is illogical. The standard is a |
---|
769 | standard for compilers that claim to support ANSI C, such as `gcc |
---|
770 | -ansi'--not for other compilers such as plain `gcc'. Whatever the |
---|
771 | ANSI C standard says is relevant to the design of plain `gcc' |
---|
772 | without `-ansi' only for pragmatic reasons, not as a requirement. |
---|
773 | |
---|
774 | GNU CC normally defines `__STDC__' to be 1, and in addition |
---|
775 | defines `__STRICT_ANSI__' if you specify the `-ansi' option. On |
---|
776 | some hosts, system include files use a different convention, where |
---|
777 | `__STDC__' is normally 0, but is 1 if the user specifies strict |
---|
778 | conformance to the C Standard. GNU CC follows the host convention |
---|
779 | when processing system include files, but when processing user |
---|
780 | files it follows the usual GNU C convention. |
---|
781 | |
---|
782 | * Undefining `__STDC__' in C++. |
---|
783 | |
---|
784 | Programs written to compile with C++-to-C translators get the |
---|
785 | value of `__STDC__' that goes with the C compiler that is |
---|
786 | subsequently used. These programs must test `__STDC__' to |
---|
787 | determine what kind of C preprocessor that compiler uses: whether |
---|
788 | they should concatenate tokens in the ANSI C fashion or in the |
---|
789 | traditional fashion. |
---|
790 | |
---|
791 | These programs work properly with GNU C++ if `__STDC__' is defined. |
---|
792 | They would not work otherwise. |
---|
793 | |
---|
794 | In addition, many header files are written to provide prototypes |
---|
795 | in ANSI C but not in traditional C. Many of these header files |
---|
796 | can work without change in C++ provided `__STDC__' is defined. If |
---|
797 | `__STDC__' is not defined, they will all fail, and will all need |
---|
798 | to be changed to test explicitly for C++ as well. |
---|
799 | |
---|
800 | * Deleting "empty" loops. |
---|
801 | |
---|
802 | GNU CC does not delete "empty" loops because the most likely reason |
---|
803 | you would put one in a program is to have a delay. Deleting them |
---|
804 | will not make real programs run any faster, so it would be |
---|
805 | pointless. |
---|
806 | |
---|
807 | It would be different if optimization of a nonempty loop could |
---|
808 | produce an empty one. But this generally can't happen. |
---|
809 | |
---|
810 | * Making side effects happen in the same order as in some other |
---|
811 | compiler. |
---|
812 | |
---|
813 | It is never safe to depend on the order of evaluation of side |
---|
814 | effects. For example, a function call like this may very well |
---|
815 | behave differently from one compiler to another: |
---|
816 | |
---|
817 | void func (int, int); |
---|
818 | |
---|
819 | int i = 2; |
---|
820 | func (i++, i++); |
---|
821 | |
---|
822 | There is no guarantee (in either the C or the C++ standard language |
---|
823 | definitions) that the increments will be evaluated in any |
---|
824 | particular order. Either increment might happen first. `func' |
---|
825 | might get the arguments `2, 3', or it might get `3, 2', or even |
---|
826 | `2, 2'. |
---|
827 | |
---|
828 | * Not allowing structures with volatile fields in registers. |
---|
829 | |
---|
830 | Strictly speaking, there is no prohibition in the ANSI C standard |
---|
831 | against allowing structures with volatile fields in registers, but |
---|
832 | it does not seem to make any sense and is probably not what you |
---|
833 | wanted to do. So the compiler will give an error message in this |
---|
834 | case. |
---|
835 | |
---|
836 | |
---|
837 | File: gcc.info, Node: Warnings and Errors, Prev: Non-bugs, Up: Trouble |
---|
838 | |
---|
839 | Warning Messages and Error Messages |
---|
840 | =================================== |
---|
841 | |
---|
842 | The GNU compiler can produce two kinds of diagnostics: errors and |
---|
843 | warnings. Each kind has a different purpose: |
---|
844 | |
---|
845 | *Errors* report problems that make it impossible to compile your |
---|
846 | program. GNU CC reports errors with the source file name and line |
---|
847 | number where the problem is apparent. |
---|
848 | |
---|
849 | *Warnings* report other unusual conditions in your code that *may* |
---|
850 | indicate a problem, although compilation can (and does) proceed. |
---|
851 | Warning messages also report the source file name and line number, |
---|
852 | but include the text `warning:' to distinguish them from error |
---|
853 | messages. |
---|
854 | |
---|
855 | Warnings may indicate danger points where you should check to make |
---|
856 | sure that your program really does what you intend; or the use of |
---|
857 | obsolete features; or the use of nonstandard features of GNU C or C++. |
---|
858 | Many warnings are issued only if you ask for them, with one of the `-W' |
---|
859 | options (for instance, `-Wall' requests a variety of useful warnings). |
---|
860 | |
---|
861 | GNU CC always tries to compile your program if possible; it never |
---|
862 | gratuitously rejects a program whose meaning is clear merely because |
---|
863 | (for instance) it fails to conform to a standard. In some cases, |
---|
864 | however, the C and C++ standards specify that certain extensions are |
---|
865 | forbidden, and a diagnostic *must* be issued by a conforming compiler. |
---|
866 | The `-pedantic' option tells GNU CC to issue warnings in such cases; |
---|
867 | `-pedantic-errors' says to make them errors instead. This does not |
---|
868 | mean that *all* non-ANSI constructs get warnings or errors. |
---|
869 | |
---|
870 | *Note Options to Request or Suppress Warnings: Warning Options, for |
---|
871 | more detail on these and related command-line options. |
---|
872 | |
---|
873 | |
---|
874 | File: gcc.info, Node: Bugs, Next: Service, Prev: Trouble, Up: Top |
---|
875 | |
---|
876 | Reporting Bugs |
---|
877 | ************** |
---|
878 | |
---|
879 | Your bug reports play an essential role in making GNU CC reliable. |
---|
880 | |
---|
881 | When you encounter a problem, the first thing to do is to see if it |
---|
882 | is already known. *Note Trouble::. If it isn't known, then you should |
---|
883 | report the problem. |
---|
884 | |
---|
885 | Reporting a bug may help you by bringing a solution to your problem, |
---|
886 | or it may not. (If it does not, look in the service directory; see |
---|
887 | *Note Service::.) In any case, the principal function of a bug report |
---|
888 | is to help the entire community by making the next version of GNU CC |
---|
889 | work better. Bug reports are your contribution to the maintenance of |
---|
890 | GNU CC. |
---|
891 | |
---|
892 | Since the maintainers are very overloaded, we cannot respond to every |
---|
893 | bug report. However, if the bug has not been fixed, we are likely to |
---|
894 | send you a patch and ask you to tell us whether it works. |
---|
895 | |
---|
896 | In order for a bug report to serve its purpose, you must include the |
---|
897 | information that makes for fixing the bug. |
---|
898 | |
---|
899 | * Menu: |
---|
900 | |
---|
901 | * Criteria: Bug Criteria. Have you really found a bug? |
---|
902 | * Where: Bug Lists. Where to send your bug report. |
---|
903 | * Reporting: Bug Reporting. How to report a bug effectively. |
---|
904 | * Patches: Sending Patches. How to send a patch for GNU CC. |
---|
905 | * Known: Trouble. Known problems. |
---|
906 | * Help: Service. Where to ask for help. |
---|
907 | |
---|
908 | |
---|
909 | File: gcc.info, Node: Bug Criteria, Next: Bug Lists, Up: Bugs |
---|
910 | |
---|
911 | Have You Found a Bug? |
---|
912 | ===================== |
---|
913 | |
---|
914 | If you are not sure whether you have found a bug, here are some |
---|
915 | guidelines: |
---|
916 | |
---|
917 | * If the compiler gets a fatal signal, for any input whatever, that |
---|
918 | is a compiler bug. Reliable compilers never crash. |
---|
919 | |
---|
920 | * If the compiler produces invalid assembly code, for any input |
---|
921 | whatever (except an `asm' statement), that is a compiler bug, |
---|
922 | unless the compiler reports errors (not just warnings) which would |
---|
923 | ordinarily prevent the assembler from being run. |
---|
924 | |
---|
925 | * If the compiler produces valid assembly code that does not |
---|
926 | correctly execute the input source code, that is a compiler bug. |
---|
927 | |
---|
928 | However, you must double-check to make sure, because you may have |
---|
929 | run into an incompatibility between GNU C and traditional C (*note |
---|
930 | Incompatibilities::.). These incompatibilities might be considered |
---|
931 | bugs, but they are inescapable consequences of valuable features. |
---|
932 | |
---|
933 | Or you may have a program whose behavior is undefined, which |
---|
934 | happened by chance to give the desired results with another C or |
---|
935 | C++ compiler. |
---|
936 | |
---|
937 | For example, in many nonoptimizing compilers, you can write `x;' |
---|
938 | at the end of a function instead of `return x;', with the same |
---|
939 | results. But the value of the function is undefined if `return' |
---|
940 | is omitted; it is not a bug when GNU CC produces different results. |
---|
941 | |
---|
942 | Problems often result from expressions with two increment |
---|
943 | operators, as in `f (*p++, *p++)'. Your previous compiler might |
---|
944 | have interpreted that expression the way you intended; GNU CC might |
---|
945 | interpret it another way. Neither compiler is wrong. The bug is |
---|
946 | in your code. |
---|
947 | |
---|
948 | After you have localized the error to a single source line, it |
---|
949 | should be easy to check for these things. If your program is |
---|
950 | correct and well defined, you have found a compiler bug. |
---|
951 | |
---|
952 | * If the compiler produces an error message for valid input, that is |
---|
953 | a compiler bug. |
---|
954 | |
---|
955 | * If the compiler does not produce an error message for invalid |
---|
956 | input, that is a compiler bug. However, you should note that your |
---|
957 | idea of "invalid input" might be my idea of "an extension" or |
---|
958 | "support for traditional practice". |
---|
959 | |
---|
960 | * If you are an experienced user of C or C++ compilers, your |
---|
961 | suggestions for improvement of GNU CC or GNU C++ are welcome in |
---|
962 | any case. |
---|
963 | |
---|
964 | |
---|
965 | File: gcc.info, Node: Bug Lists, Next: Bug Reporting, Prev: Bug Criteria, Up: Bugs |
---|
966 | |
---|
967 | Where to Report Bugs |
---|
968 | ==================== |
---|
969 | |
---|
970 | Send bug reports for GNU C to `bug-gcc@prep.ai.mit.edu'. |
---|
971 | |
---|
972 | Send bug reports for GNU C++ to `bug-g++@prep.ai.mit.edu'. If your |
---|
973 | bug involves the C++ class library libg++, send mail instead to the |
---|
974 | address `bug-lib-g++@prep.ai.mit.edu'. If you're not sure, you can |
---|
975 | send the bug report to both lists. |
---|
976 | |
---|
977 | *Do not send bug reports to `help-gcc@prep.ai.mit.edu' or to the |
---|
978 | newsgroup `gnu.gcc.help'.* Most users of GNU CC do not want to receive |
---|
979 | bug reports. Those that do, have asked to be on `bug-gcc' and/or |
---|
980 | `bug-g++'. |
---|
981 | |
---|
982 | The mailing lists `bug-gcc' and `bug-g++' both have newsgroups which |
---|
983 | serve as repeaters: `gnu.gcc.bug' and `gnu.g++.bug'. Each mailing list |
---|
984 | and its newsgroup carry exactly the same messages. |
---|
985 | |
---|
986 | Often people think of posting bug reports to the newsgroup instead of |
---|
987 | mailing them. This appears to work, but it has one problem which can be |
---|
988 | crucial: a newsgroup posting does not contain a mail path back to the |
---|
989 | sender. Thus, if maintainers need more information, they may be unable |
---|
990 | to reach you. For this reason, you should always send bug reports by |
---|
991 | mail to the proper mailing list. |
---|
992 | |
---|
993 | As a last resort, send bug reports on paper to: |
---|
994 | |
---|
995 | GNU Compiler Bugs |
---|
996 | Free Software Foundation |
---|
997 | 59 Temple Place - Suite 330 |
---|
998 | Boston, MA 02111-1307, USA |
---|
999 | |
---|