OpenCores
URL https://opencores.org/ocsvn/scarts/scarts/trunk

Subversion Repositories scarts

[/] [scarts/] [trunk/] [toolchain/] [scarts-gcc/] [gcc-4.1.1/] [gcc/] [doc/] [trouble.texi] - Blame information for rev 12

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 12 jlechner
@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
2
@c 1999, 2000, 2001, 2003, 2004 Free Software Foundation, Inc.
3
@c This is part of the GCC manual.
4
@c For copying conditions, see the file gcc.texi.
5
 
6
@node Trouble
7
@chapter Known Causes of Trouble with GCC
8
@cindex bugs, known
9
@cindex installation trouble
10
@cindex known causes of trouble
11
 
12
This section describes known problems that affect users of GCC@.  Most
13
of these are not GCC bugs per se---if they were, we would fix them.
14
But the result for a user may be like the result of a bug.
15
 
16
Some of these problems are due to bugs in other software, some are
17
missing features that are too much work to add, and some are places
18
where people's opinions differ as to what is best.
19
 
20
@menu
21
* Actual Bugs::               Bugs we will fix later.
22
* Cross-Compiler Problems::   Common problems of cross compiling with GCC.
23
* Interoperation::      Problems using GCC with other compilers,
24
                           and with certain linkers, assemblers and debuggers.
25
* Incompatibilities::   GCC is incompatible with traditional C.
26
* Fixed Headers::       GCC uses corrected versions of system header files.
27
                           This is necessary, but doesn't always work smoothly.
28
* Standard Libraries::  GCC uses the system C library, which might not be
29
                           compliant with the ISO C standard.
30
* Disappointments::     Regrettable things we can't change, but not quite bugs.
31
* C++ Misunderstandings::     Common misunderstandings with GNU C++.
32
* Protoize Caveats::    Things to watch out for when using @code{protoize}.
33
* Non-bugs::            Things we think are right, but some others disagree.
34
* Warnings and Errors:: Which problems in your code get warnings,
35
                         and which get errors.
36
@end menu
37
 
38
@node Actual Bugs
39
@section Actual Bugs We Haven't Fixed Yet
40
 
41
@itemize @bullet
42
@item
43
The @code{fixincludes} script interacts badly with automounters; if the
44
directory of system header files is automounted, it tends to be
45
unmounted while @code{fixincludes} is running.  This would seem to be a
46
bug in the automounter.  We don't know any good way to work around it.
47
 
48
@item
49
The @code{fixproto} script will sometimes add prototypes for the
50
@code{sigsetjmp} and @code{siglongjmp} functions that reference the
51
@code{jmp_buf} type before that type is defined.  To work around this,
52
edit the offending file and place the typedef in front of the
53
prototypes.
54
@end itemize
55
 
56
@node Cross-Compiler Problems
57
@section Cross-Compiler Problems
58
 
59
You may run into problems with cross compilation on certain machines,
60
for several reasons.
61
 
62
@itemize @bullet
63
@item
64
At present, the program @file{mips-tfile} which adds debug
65
support to object files on MIPS systems does not work in a cross
66
compile environment.
67
@end itemize
68
 
69
@node Interoperation
70
@section Interoperation
71
 
72
This section lists various difficulties encountered in using GCC
73
together with other compilers or with the assemblers, linkers,
74
libraries and debuggers on certain systems.
75
 
76
@itemize @bullet
77
@item
78
On many platforms, GCC supports a different ABI for C++ than do other
79
compilers, so the object files compiled by GCC cannot be used with object
80
files generated by another C++ compiler.
81
 
82
An area where the difference is most apparent is name mangling.  The use
83
of different name mangling is intentional, to protect you from more subtle
84
problems.
85
Compilers differ as to many internal details of C++ implementation,
86
including: how class instances are laid out, how multiple inheritance is
87
implemented, and how virtual function calls are handled.  If the name
88
encoding were made the same, your programs would link against libraries
89
provided from other compilers---but the programs would then crash when
90
run.  Incompatible libraries are then detected at link time, rather than
91
at run time.
92
 
93
@item
94
On some BSD systems, including some versions of Ultrix, use of profiling
95
causes static variable destructors (currently used only in C++) not to
96
be run.
97
 
98
@item
99
On some SGI systems, when you use @option{-lgl_s} as an option,
100
it gets translated magically to @samp{-lgl_s -lX11_s -lc_s}.
101
Naturally, this does not happen when you use GCC@.
102
You must specify all three options explicitly.
103
 
104
@item
105
On a SPARC, GCC aligns all values of type @code{double} on an 8-byte
106
boundary, and it expects every @code{double} to be so aligned.  The Sun
107
compiler usually gives @code{double} values 8-byte alignment, with one
108
exception: function arguments of type @code{double} may not be aligned.
109
 
110
As a result, if a function compiled with Sun CC takes the address of an
111
argument of type @code{double} and passes this pointer of type
112
@code{double *} to a function compiled with GCC, dereferencing the
113
pointer may cause a fatal signal.
114
 
115
One way to solve this problem is to compile your entire program with GCC@.
116
Another solution is to modify the function that is compiled with
117
Sun CC to copy the argument into a local variable; local variables
118
are always properly aligned.  A third solution is to modify the function
119
that uses the pointer to dereference it via the following function
120
@code{access_double} instead of directly with @samp{*}:
121
 
122
@smallexample
123
inline double
124
access_double (double *unaligned_ptr)
125
@{
126
  union d2i @{ double d; int i[2]; @};
127
 
128
  union d2i *p = (union d2i *) unaligned_ptr;
129
  union d2i u;
130
 
131
  u.i[0] = p->i[0];
132
  u.i[1] = p->i[1];
133
 
134
  return u.d;
135
@}
136
@end smallexample
137
 
138
@noindent
139
Storing into the pointer can be done likewise with the same union.
140
 
141
@item
142
On Solaris, the @code{malloc} function in the @file{libmalloc.a} library
143
may allocate memory that is only 4 byte aligned.  Since GCC on the
144
SPARC assumes that doubles are 8 byte aligned, this may result in a
145
fatal signal if doubles are stored in memory allocated by the
146
@file{libmalloc.a} library.
147
 
148
The solution is to not use the @file{libmalloc.a} library.  Use instead
149
@code{malloc} and related functions from @file{libc.a}; they do not have
150
this problem.
151
 
152
@item
153
On the HP PA machine, ADB sometimes fails to work on functions compiled
154
with GCC@.  Specifically, it fails to work on functions that use
155
@code{alloca} or variable-size arrays.  This is because GCC doesn't
156
generate HP-UX unwind descriptors for such functions.  It may even be
157
impossible to generate them.
158
 
159
@item
160
Debugging (@option{-g}) is not supported on the HP PA machine, unless you use
161
the preliminary GNU tools.
162
 
163
@item
164
Taking the address of a label may generate errors from the HP-UX
165
PA assembler.  GAS for the PA does not have this problem.
166
 
167
@item
168
Using floating point parameters for indirect calls to static functions
169
will not work when using the HP assembler.  There simply is no way for GCC
170
to specify what registers hold arguments for static functions when using
171
the HP assembler.  GAS for the PA does not have this problem.
172
 
173
@item
174
In extremely rare cases involving some very large functions you may
175
receive errors from the HP linker complaining about an out of bounds
176
unconditional branch offset.  This used to occur more often in previous
177
versions of GCC, but is now exceptionally rare.  If you should run
178
into it, you can work around by making your function smaller.
179
 
180
@item
181
GCC compiled code sometimes emits warnings from the HP-UX assembler of
182
the form:
183
 
184
@smallexample
185
(warning) Use of GR3 when
186
  frame >= 8192 may cause conflict.
187
@end smallexample
188
 
189
These warnings are harmless and can be safely ignored.
190
 
191
@item
192
In extremely rare cases involving some very large functions you may
193
receive errors from the AIX Assembler complaining about a displacement
194
that is too large.  If you should run into it, you can work around by
195
making your function smaller.
196
 
197
@item
198
The @file{libstdc++.a} library in GCC relies on the SVR4 dynamic
199
linker semantics which merges global symbols between libraries and
200
applications, especially necessary for C++ streams functionality.
201
This is not the default behavior of AIX shared libraries and dynamic
202
linking.  @file{libstdc++.a} is built on AIX with ``runtime-linking''
203
enabled so that symbol merging can occur.  To utilize this feature,
204
the application linked with @file{libstdc++.a} must include the
205
@option{-Wl,-brtl} flag on the link line.  G++ cannot impose this
206
because this option may interfere with the semantics of the user
207
program and users may not always use @samp{g++} to link his or her
208
application.  Applications are not required to use the
209
@option{-Wl,-brtl} flag on the link line---the rest of the
210
@file{libstdc++.a} library which is not dependent on the symbol
211
merging semantics will continue to function correctly.
212
 
213
@item
214
An application can interpose its own definition of functions for
215
functions invoked by @file{libstdc++.a} with ``runtime-linking''
216
enabled on AIX@.  To accomplish this the application must be linked
217
with ``runtime-linking'' option and the functions explicitly must be
218
exported by the application (@option{-Wl,-brtl,-bE:exportfile}).
219
 
220
@item
221
AIX on the RS/6000 provides support (NLS) for environments outside of
222
the United States.  Compilers and assemblers use NLS to support
223
locale-specific representations of various objects including
224
floating-point numbers (@samp{.} vs @samp{,} for separating decimal
225
fractions).  There have been problems reported where the library linked
226
with GCC does not produce the same floating-point formats that the
227
assembler accepts.  If you have this problem, set the @env{LANG}
228
environment variable to @samp{C} or @samp{En_US}.
229
 
230
@item
231
@opindex fdollars-in-identifiers
232
Even if you specify @option{-fdollars-in-identifiers},
233
you cannot successfully use @samp{$} in identifiers on the RS/6000 due
234
to a restriction in the IBM assembler.  GAS supports these
235
identifiers.
236
 
237
@cindex VAX calling convention
238
@cindex Ultrix calling convention
239
@item
240
@opindex fcall-saved
241
On Ultrix, the Fortran compiler expects registers 2 through 5 to be saved
242
by function calls.  However, the C compiler uses conventions compatible
243
with BSD Unix: registers 2 through 5 may be clobbered by function calls.
244
 
245
GCC uses the same convention as the Ultrix C compiler.  You can use
246
these options to produce code compatible with the Fortran compiler:
247
 
248
@smallexample
249
-fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5
250
@end smallexample
251
@end itemize
252
 
253
@node Incompatibilities
254
@section Incompatibilities of GCC
255
@cindex incompatibilities of GCC
256
@opindex traditional
257
 
258
There are several noteworthy incompatibilities between GNU C and K&R
259
(non-ISO) versions of C@.
260
 
261
@itemize @bullet
262
@cindex string constants
263
@cindex read-only strings
264
@cindex shared strings
265
@item
266
GCC normally makes string constants read-only.  If several
267
identical-looking string constants are used, GCC stores only one
268
copy of the string.
269
 
270
@cindex @code{mktemp}, and constant strings
271
One consequence is that you cannot call @code{mktemp} with a string
272
constant argument.  The function @code{mktemp} always alters the
273
string its argument points to.
274
 
275
@cindex @code{sscanf}, and constant strings
276
@cindex @code{fscanf}, and constant strings
277
@cindex @code{scanf}, and constant strings
278
Another consequence is that @code{sscanf} does not work on some very
279
old systems when passed a string constant as its format control string
280
or input.  This is because @code{sscanf} incorrectly tries to write
281
into the string constant.  Likewise @code{fscanf} and @code{scanf}.
282
 
283
The solution to these problems is to change the program to use
284
@code{char}-array variables with initialization strings for these
285
purposes instead of string constants.
286
 
287
@item
288
@code{-2147483648} is positive.
289
 
290
This is because 2147483648 cannot fit in the type @code{int}, so
291
(following the ISO C rules) its data type is @code{unsigned long int}.
292
Negating this value yields 2147483648 again.
293
 
294
@item
295
GCC does not substitute macro arguments when they appear inside of
296
string constants.  For example, the following macro in GCC
297
 
298
@smallexample
299
#define foo(a) "a"
300
@end smallexample
301
 
302
@noindent
303
will produce output @code{"a"} regardless of what the argument @var{a} is.
304
 
305
@cindex @code{setjmp} incompatibilities
306
@cindex @code{longjmp} incompatibilities
307
@item
308
When you use @code{setjmp} and @code{longjmp}, the only automatic
309
variables guaranteed to remain valid are those declared
310
@code{volatile}.  This is a consequence of automatic register
311
allocation.  Consider this function:
312
 
313
@smallexample
314
jmp_buf j;
315
 
316
foo ()
317
@{
318
  int a, b;
319
 
320
  a = fun1 ();
321
  if (setjmp (j))
322
    return a;
323
 
324
  a = fun2 ();
325
  /* @r{@code{longjmp (j)} may occur in @code{fun3}.} */
326
  return a + fun3 ();
327
@}
328
@end smallexample
329
 
330
Here @code{a} may or may not be restored to its first value when the
331
@code{longjmp} occurs.  If @code{a} is allocated in a register, then
332
its first value is restored; otherwise, it keeps the last value stored
333
in it.
334
 
335
@opindex W
336
If you use the @option{-W} option with the @option{-O} option, you will
337
get a warning when GCC thinks such a problem might be possible.
338
 
339
@item
340
Programs that use preprocessing directives in the middle of macro
341
arguments do not work with GCC@.  For example, a program like this
342
will not work:
343
 
344
@smallexample
345
@group
346
foobar (
347
#define luser
348
        hack)
349
@end group
350
@end smallexample
351
 
352
ISO C does not permit such a construct.
353
 
354
@item
355
K&R compilers allow comments to cross over an inclusion boundary
356
(i.e.@: started in an include file and ended in the including file).
357
 
358
@cindex external declaration scope
359
@cindex scope of external declarations
360
@cindex declaration scope
361
@item
362
Declarations of external variables and functions within a block apply
363
only to the block containing the declaration.  In other words, they
364
have the same scope as any other declaration in the same place.
365
 
366
In some other C compilers, a @code{extern} declaration affects all the
367
rest of the file even if it happens within a block.
368
 
369
@item
370
In traditional C, you can combine @code{long}, etc., with a typedef name,
371
as shown here:
372
 
373
@smallexample
374
typedef int foo;
375
typedef long foo bar;
376
@end smallexample
377
 
378
In ISO C, this is not allowed: @code{long} and other type modifiers
379
require an explicit @code{int}.
380
 
381
@cindex typedef names as function parameters
382
@item
383
PCC allows typedef names to be used as function parameters.
384
 
385
@item
386
Traditional C allows the following erroneous pair of declarations to
387
appear together in a given scope:
388
 
389
@smallexample
390
typedef int foo;
391
typedef foo foo;
392
@end smallexample
393
 
394
@item
395
GCC treats all characters of identifiers as significant.  According to
396
K&R-1 (2.2), ``No more than the first eight characters are significant,
397
although more may be used.''.  Also according to K&R-1 (2.2), ``An
398
identifier is a sequence of letters and digits; the first character must
399
be a letter.  The underscore _ counts as a letter.'', but GCC also
400
allows dollar signs in identifiers.
401
 
402
@cindex whitespace
403
@item
404
PCC allows whitespace in the middle of compound assignment operators
405
such as @samp{+=}.  GCC, following the ISO standard, does not
406
allow this.
407
 
408
@cindex apostrophes
409
@cindex '
410
@item
411
GCC complains about unterminated character constants inside of
412
preprocessing conditionals that fail.  Some programs have English
413
comments enclosed in conditionals that are guaranteed to fail; if these
414
comments contain apostrophes, GCC will probably report an error.  For
415
example, this code would produce an error:
416
 
417
@smallexample
418
#if 0
419
You can't expect this to work.
420
#endif
421
@end smallexample
422
 
423
The best solution to such a problem is to put the text into an actual
424
C comment delimited by @samp{/*@dots{}*/}.
425
 
426
@item
427
Many user programs contain the declaration @samp{long time ();}.  In the
428
past, the system header files on many systems did not actually declare
429
@code{time}, so it did not matter what type your program declared it to
430
return.  But in systems with ISO C headers, @code{time} is declared to
431
return @code{time_t}, and if that is not the same as @code{long}, then
432
@samp{long time ();} is erroneous.
433
 
434
The solution is to change your program to use appropriate system headers
435
(@code{<time.h>} on systems with ISO C headers) and not to declare
436
@code{time} if the system header files declare it, or failing that to
437
use @code{time_t} as the return type of @code{time}.
438
 
439
@cindex @code{float} as function value type
440
@item
441
When compiling functions that return @code{float}, PCC converts it to
442
a double.  GCC actually returns a @code{float}.  If you are concerned
443
with PCC compatibility, you should declare your functions to return
444
@code{double}; you might as well say what you mean.
445
 
446
@cindex structures
447
@cindex unions
448
@item
449
When compiling functions that return structures or unions, GCC
450
output code normally uses a method different from that used on most
451
versions of Unix.  As a result, code compiled with GCC cannot call
452
a structure-returning function compiled with PCC, and vice versa.
453
 
454
The method used by GCC is as follows: a structure or union which is
455
1, 2, 4 or 8 bytes long is returned like a scalar.  A structure or union
456
with any other size is stored into an address supplied by the caller
457
(usually in a special, fixed register, but on some machines it is passed
458
on the stack).  The target hook @code{TARGET_STRUCT_VALUE_RTX}
459
tells GCC where to pass this address.
460
 
461
By contrast, PCC on most target machines returns structures and unions
462
of any size by copying the data into an area of static storage, and then
463
returning the address of that storage as if it were a pointer value.
464
The caller must copy the data from that memory area to the place where
465
the value is wanted.  GCC does not use this method because it is
466
slower and nonreentrant.
467
 
468
On some newer machines, PCC uses a reentrant convention for all
469
structure and union returning.  GCC on most of these machines uses a
470
compatible convention when returning structures and unions in memory,
471
but still returns small structures and unions in registers.
472
 
473
@opindex fpcc-struct-return
474
You can tell GCC to use a compatible convention for all structure and
475
union returning with the option @option{-fpcc-struct-return}.
476
 
477
@cindex preprocessing tokens
478
@cindex preprocessing numbers
479
@item
480
GCC complains about program fragments such as @samp{0x74ae-0x4000}
481
which appear to be two hexadecimal constants separated by the minus
482
operator.  Actually, this string is a single @dfn{preprocessing token}.
483
Each such token must correspond to one token in C@.  Since this does not,
484
GCC prints an error message.  Although it may appear obvious that what
485
is meant is an operator and two values, the ISO C standard specifically
486
requires that this be treated as erroneous.
487
 
488
A @dfn{preprocessing token} is a @dfn{preprocessing number} if it
489
begins with a digit and is followed by letters, underscores, digits,
490
periods and @samp{e+}, @samp{e-}, @samp{E+}, @samp{E-}, @samp{p+},
491
@samp{p-}, @samp{P+}, or @samp{P-} character sequences.  (In strict C89
492
mode, the sequences @samp{p+}, @samp{p-}, @samp{P+} and @samp{P-} cannot
493
appear in preprocessing numbers.)
494
 
495
To make the above program fragment valid, place whitespace in front of
496
the minus sign.  This whitespace will end the preprocessing number.
497
@end itemize
498
 
499
@node Fixed Headers
500
@section Fixed Header Files
501
 
502
GCC needs to install corrected versions of some system header files.
503
This is because most target systems have some header files that won't
504
work with GCC unless they are changed.  Some have bugs, some are
505
incompatible with ISO C, and some depend on special features of other
506
compilers.
507
 
508
Installing GCC automatically creates and installs the fixed header
509
files, by running a program called @code{fixincludes}.  Normally, you
510
don't need to pay attention to this.  But there are cases where it
511
doesn't do the right thing automatically.
512
 
513
@itemize @bullet
514
@item
515
If you update the system's header files, such as by installing a new
516
system version, the fixed header files of GCC are not automatically
517
updated.  They can be updated using the @command{mkheaders} script
518
installed in
519
@file{@var{libexecdir}/gcc/@var{target}/@var{version}/install-tools/}.
520
 
521
@item
522
On some systems, header file directories contain
523
machine-specific symbolic links in certain places.  This makes it
524
possible to share most of the header files among hosts running the
525
same version of the system on different machine models.
526
 
527
The programs that fix the header files do not understand this special
528
way of using symbolic links; therefore, the directory of fixed header
529
files is good only for the machine model used to build it.
530
 
531
It is possible to make separate sets of fixed header files for the
532
different machine models, and arrange a structure of symbolic links so
533
as to use the proper set, but you'll have to do this by hand.
534
@end itemize
535
 
536
@node Standard Libraries
537
@section Standard Libraries
538
 
539
@opindex Wall
540
GCC by itself attempts to be a conforming freestanding implementation.
541
@xref{Standards,,Language Standards Supported by GCC}, for details of
542
what this means.  Beyond the library facilities required of such an
543
implementation, the rest of the C library is supplied by the vendor of
544
the operating system.  If that C library doesn't conform to the C
545
standards, then your programs might get warnings (especially when using
546
@option{-Wall}) that you don't expect.
547
 
548
For example, the @code{sprintf} function on SunOS 4.1.3 returns
549
@code{char *} while the C standard says that @code{sprintf} returns an
550
@code{int}.  The @code{fixincludes} program could make the prototype for
551
this function match the Standard, but that would be wrong, since the
552
function will still return @code{char *}.
553
 
554
If you need a Standard compliant library, then you need to find one, as
555
GCC does not provide one.  The GNU C library (called @code{glibc})
556
provides ISO C, POSIX, BSD, SystemV and X/Open compatibility for
557
GNU/Linux and HURD-based GNU systems; no recent version of it supports
558
other systems, though some very old versions did.  Version 2.2 of the
559
GNU C library includes nearly complete C99 support.  You could also ask
560
your operating system vendor if newer libraries are available.
561
 
562
@node Disappointments
563
@section Disappointments and Misunderstandings
564
 
565
These problems are perhaps regrettable, but we don't know any practical
566
way around them.
567
 
568
@itemize @bullet
569
@item
570
Certain local variables aren't recognized by debuggers when you compile
571
with optimization.
572
 
573
This occurs because sometimes GCC optimizes the variable out of
574
existence.  There is no way to tell the debugger how to compute the
575
value such a variable ``would have had'', and it is not clear that would
576
be desirable anyway.  So GCC simply does not mention the eliminated
577
variable when it writes debugging information.
578
 
579
You have to expect a certain amount of disagreement between the
580
executable and your source code, when you use optimization.
581
 
582
@cindex conflicting types
583
@cindex scope of declaration
584
@item
585
Users often think it is a bug when GCC reports an error for code
586
like this:
587
 
588
@smallexample
589
int foo (struct mumble *);
590
 
591
struct mumble @{ @dots{} @};
592
 
593
int foo (struct mumble *x)
594
@{ @dots{} @}
595
@end smallexample
596
 
597
This code really is erroneous, because the scope of @code{struct
598
mumble} in the prototype is limited to the argument list containing it.
599
It does not refer to the @code{struct mumble} defined with file scope
600
immediately below---they are two unrelated types with similar names in
601
different scopes.
602
 
603
But in the definition of @code{foo}, the file-scope type is used
604
because that is available to be inherited.  Thus, the definition and
605
the prototype do not match, and you get an error.
606
 
607
This behavior may seem silly, but it's what the ISO standard specifies.
608
It is easy enough for you to make your code work by moving the
609
definition of @code{struct mumble} above the prototype.  It's not worth
610
being incompatible with ISO C just to avoid an error for the example
611
shown above.
612
 
613
@item
614
Accesses to bit-fields even in volatile objects works by accessing larger
615
objects, such as a byte or a word.  You cannot rely on what size of
616
object is accessed in order to read or write the bit-field; it may even
617
vary for a given bit-field according to the precise usage.
618
 
619
If you care about controlling the amount of memory that is accessed, use
620
volatile but do not use bit-fields.
621
 
622
@item
623
GCC comes with shell scripts to fix certain known problems in system
624
header files.  They install corrected copies of various header files in
625
a special directory where only GCC will normally look for them.  The
626
scripts adapt to various systems by searching all the system header
627
files for the problem cases that we know about.
628
 
629
If new system header files are installed, nothing automatically arranges
630
to update the corrected header files.  They can be updated using the
631
@command{mkheaders} script installed in
632
@file{@var{libexecdir}/gcc/@var{target}/@var{version}/install-tools/}.
633
 
634
@item
635
@cindex floating point precision
636
On 68000 and x86 systems, for instance, you can get paradoxical results
637
if you test the precise values of floating point numbers.  For example,
638
you can find that a floating point value which is not a NaN is not equal
639
to itself.  This results from the fact that the floating point registers
640
hold a few more bits of precision than fit in a @code{double} in memory.
641
Compiled code moves values between memory and floating point registers
642
at its convenience, and moving them into memory truncates them.
643
 
644
@opindex ffloat-store
645
You can partially avoid this problem by using the @option{-ffloat-store}
646
option (@pxref{Optimize Options}).
647
 
648
@item
649
On AIX and other platforms without weak symbol support, templates
650
need to be instantiated explicitly and symbols for static members
651
of templates will not be generated.
652
 
653
@item
654
On AIX, GCC scans object files and library archives for static
655
constructors and destructors when linking an application before the
656
linker prunes unreferenced symbols.  This is necessary to prevent the
657
AIX linker from mistakenly assuming that static constructor or
658
destructor are unused and removing them before the scanning can occur.
659
All static constructors and destructors found will be referenced even
660
though the modules in which they occur may not be used by the program.
661
This may lead to both increased executable size and unexpected symbol
662
references.
663
@end itemize
664
 
665
@node C++ Misunderstandings
666
@section Common Misunderstandings with GNU C++
667
 
668
@cindex misunderstandings in C++
669
@cindex surprises in C++
670
@cindex C++ misunderstandings
671
C++ is a complex language and an evolving one, and its standard
672
definition (the ISO C++ standard) was only recently completed.  As a
673
result, your C++ compiler may occasionally surprise you, even when its
674
behavior is correct.  This section discusses some areas that frequently
675
give rise to questions of this sort.
676
 
677
@menu
678
* Static Definitions::  Static member declarations are not definitions
679
* Name lookup::         Name lookup, templates, and accessing members of base classes
680
* Temporaries::         Temporaries may vanish before you expect
681
* Copy Assignment::     Copy Assignment operators copy virtual bases twice
682
@end menu
683
 
684
@node Static Definitions
685
@subsection Declare @emph{and} Define Static Members
686
 
687
@cindex C++ static data, declaring and defining
688
@cindex static data in C++, declaring and defining
689
@cindex declaring static data in C++
690
@cindex defining static data in C++
691
When a class has static data members, it is not enough to @emph{declare}
692
the static member; you must also @emph{define} it.  For example:
693
 
694
@smallexample
695
class Foo
696
@{
697
  @dots{}
698
  void method();
699
  static int bar;
700
@};
701
@end smallexample
702
 
703
This declaration only establishes that the class @code{Foo} has an
704
@code{int} named @code{Foo::bar}, and a member function named
705
@code{Foo::method}.  But you still need to define @emph{both}
706
@code{method} and @code{bar} elsewhere.  According to the ISO
707
standard, you must supply an initializer in one (and only one) source
708
file, such as:
709
 
710
@smallexample
711
int Foo::bar = 0;
712
@end smallexample
713
 
714
Other C++ compilers may not correctly implement the standard behavior.
715
As a result, when you switch to @command{g++} from one of these compilers,
716
you may discover that a program that appeared to work correctly in fact
717
does not conform to the standard: @command{g++} reports as undefined
718
symbols any static data members that lack definitions.
719
 
720
 
721
@node Name lookup
722
@subsection Name lookup, templates, and accessing members of base classes
723
 
724
@cindex base class members
725
@cindex two-stage name lookup
726
@cindex dependent name lookup
727
 
728
The C++ standard prescribes that all names that are not dependent on
729
template parameters are bound to their present definitions when parsing
730
a template function or class.@footnote{The C++ standard just uses the
731
term ``dependent'' for names that depend on the type or value of
732
template parameters.  This shorter term will also be used in the rest of
733
this section.}  Only names that are dependent are looked up at the point
734
of instantiation.  For example, consider
735
 
736
@smallexample
737
  void foo(double);
738
 
739
  struct A @{
740
    template <typename T>
741
    void f () @{
742
      foo (1);        // @r{1}
743
      int i = N;      // @r{2}
744
      T t;
745
      t.bar();        // @r{3}
746
      foo (t);        // @r{4}
747
    @}
748
 
749
    static const int N;
750
  @};
751
@end smallexample
752
 
753
Here, the names @code{foo} and @code{N} appear in a context that does
754
not depend on the type of @code{T}.  The compiler will thus require that
755
they are defined in the context of use in the template, not only before
756
the point of instantiation, and will here use @code{::foo(double)} and
757
@code{A::N}, respectively.  In particular, it will convert the integer
758
value to a @code{double} when passing it to @code{::foo(double)}.
759
 
760
Conversely, @code{bar} and the call to @code{foo} in the fourth marked
761
line are used in contexts that do depend on the type of @code{T}, so
762
they are only looked up at the point of instantiation, and you can
763
provide declarations for them after declaring the template, but before
764
instantiating it.  In particular, if you instantiate @code{A::f<int>},
765
the last line will call an overloaded @code{::foo(int)} if one was
766
provided, even if after the declaration of @code{struct A}.
767
 
768
This distinction between lookup of dependent and non-dependent names is
769
called two-stage (or dependent) name lookup.  G++ implements it
770
since version 3.4.
771
 
772
Two-stage name lookup sometimes leads to situations with behavior
773
different from non-template codes.  The most common is probably this:
774
 
775
@smallexample
776
  template <typename T> struct Base @{
777
    int i;
778
  @};
779
 
780
  template <typename T> struct Derived : public Base<T> @{
781
    int get_i() @{ return i; @}
782
  @};
783
@end smallexample
784
 
785
In @code{get_i()}, @code{i} is not used in a dependent context, so the
786
compiler will look for a name declared at the enclosing namespace scope
787
(which is the global scope here).  It will not look into the base class,
788
since that is dependent and you may declare specializations of
789
@code{Base} even after declaring @code{Derived}, so the compiler can't
790
really know what @code{i} would refer to.  If there is no global
791
variable @code{i}, then you will get an error message.
792
 
793
In order to make it clear that you want the member of the base class,
794
you need to defer lookup until instantiation time, at which the base
795
class is known.  For this, you need to access @code{i} in a dependent
796
context, by either using @code{this->i} (remember that @code{this} is of
797
type @code{Derived<T>*}, so is obviously dependent), or using
798
@code{Base<T>::i}.  Alternatively, @code{Base<T>::i} might be brought
799
into scope by a @code{using}-declaration.
800
 
801
Another, similar example involves calling member functions of a base
802
class:
803
 
804
@smallexample
805
  template <typename T> struct Base @{
806
      int f();
807
  @};
808
 
809
  template <typename T> struct Derived : Base<T> @{
810
      int g() @{ return f(); @};
811
  @};
812
@end smallexample
813
 
814
Again, the call to @code{f()} is not dependent on template arguments
815
(there are no arguments that depend on the type @code{T}, and it is also
816
not otherwise specified that the call should be in a dependent context).
817
Thus a global declaration of such a function must be available, since
818
the one in the base class is not visible until instantiation time.  The
819
compiler will consequently produce the following error message:
820
 
821
@smallexample
822
  x.cc: In member function `int Derived<T>::g()':
823
  x.cc:6: error: there are no arguments to `f' that depend on a template
824
     parameter, so a declaration of `f' must be available
825
  x.cc:6: error: (if you use `-fpermissive', G++ will accept your code, but
826
     allowing the use of an undeclared name is deprecated)
827
@end smallexample
828
 
829
To make the code valid either use @code{this->f()}, or
830
@code{Base<T>::f()}.  Using the @option{-fpermissive} flag will also let
831
the compiler accept the code, by marking all function calls for which no
832
declaration is visible at the time of definition of the template for
833
later lookup at instantiation time, as if it were a dependent call.
834
We do not recommend using @option{-fpermissive} to work around invalid
835
code, and it will also only catch cases where functions in base classes
836
are called, not where variables in base classes are used (as in the
837
example above).
838
 
839
Note that some compilers (including G++ versions prior to 3.4) get these
840
examples wrong and accept above code without an error.  Those compilers
841
do not implement two-stage name lookup correctly.
842
 
843
 
844
@node Temporaries
845
@subsection Temporaries May Vanish Before You Expect
846
 
847
@cindex temporaries, lifetime of
848
@cindex portions of temporary objects, pointers to
849
It is dangerous to use pointers or references to @emph{portions} of a
850
temporary object.  The compiler may very well delete the object before
851
you expect it to, leaving a pointer to garbage.  The most common place
852
where this problem crops up is in classes like string classes,
853
especially ones that define a conversion function to type @code{char *}
854
or @code{const char *}---which is one reason why the standard
855
@code{string} class requires you to call the @code{c_str} member
856
function.  However, any class that returns a pointer to some internal
857
structure is potentially subject to this problem.
858
 
859
For example, a program may use a function @code{strfunc} that returns
860
@code{string} objects, and another function @code{charfunc} that
861
operates on pointers to @code{char}:
862
 
863
@smallexample
864
string strfunc ();
865
void charfunc (const char *);
866
 
867
void
868
f ()
869
@{
870
  const char *p = strfunc().c_str();
871
  @dots{}
872
  charfunc (p);
873
  @dots{}
874
  charfunc (p);
875
@}
876
@end smallexample
877
 
878
@noindent
879
In this situation, it may seem reasonable to save a pointer to the C
880
string returned by the @code{c_str} member function and use that rather
881
than call @code{c_str} repeatedly.  However, the temporary string
882
created by the call to @code{strfunc} is destroyed after @code{p} is
883
initialized, at which point @code{p} is left pointing to freed memory.
884
 
885
Code like this may run successfully under some other compilers,
886
particularly obsolete cfront-based compilers that delete temporaries
887
along with normal local variables.  However, the GNU C++ behavior is
888
standard-conforming, so if your program depends on late destruction of
889
temporaries it is not portable.
890
 
891
The safe way to write such code is to give the temporary a name, which
892
forces it to remain until the end of the scope of the name.  For
893
example:
894
 
895
@smallexample
896
const string& tmp = strfunc ();
897
charfunc (tmp.c_str ());
898
@end smallexample
899
 
900
@node Copy Assignment
901
@subsection Implicit Copy-Assignment for Virtual Bases
902
 
903
When a base class is virtual, only one subobject of the base class
904
belongs to each full object.  Also, the constructors and destructors are
905
invoked only once, and called from the most-derived class.  However, such
906
objects behave unspecified when being assigned.  For example:
907
 
908
@smallexample
909
struct Base@{
910
  char *name;
911
  Base(char *n) : name(strdup(n))@{@}
912
  Base& operator= (const Base& other)@{
913
   free (name);
914
   name = strdup (other.name);
915
  @}
916
@};
917
 
918
struct A:virtual Base@{
919
  int val;
920
  A():Base("A")@{@}
921
@};
922
 
923
struct B:virtual Base@{
924
  int bval;
925
  B():Base("B")@{@}
926
@};
927
 
928
struct Derived:public A, public B@{
929
  Derived():Base("Derived")@{@}
930
@};
931
 
932
void func(Derived &d1, Derived &d2)
933
@{
934
  d1 = d2;
935
@}
936
@end smallexample
937
 
938
The C++ standard specifies that @samp{Base::Base} is only called once
939
when constructing or copy-constructing a Derived object.  It is
940
unspecified whether @samp{Base::operator=} is called more than once when
941
the implicit copy-assignment for Derived objects is invoked (as it is
942
inside @samp{func} in the example).
943
 
944
G++ implements the ``intuitive'' algorithm for copy-assignment: assign all
945
direct bases, then assign all members.  In that algorithm, the virtual
946
base subobject can be encountered more than once.  In the example, copying
947
proceeds in the following order: @samp{val}, @samp{name} (via
948
@code{strdup}), @samp{bval}, and @samp{name} again.
949
 
950
If application code relies on copy-assignment, a user-defined
951
copy-assignment operator removes any uncertainties.  With such an
952
operator, the application can define whether and how the virtual base
953
subobject is assigned.
954
 
955
@node Protoize Caveats
956
@section Caveats of using @command{protoize}
957
 
958
The conversion programs @command{protoize} and @command{unprotoize} can
959
sometimes change a source file in a way that won't work unless you
960
rearrange it.
961
 
962
@itemize @bullet
963
@item
964
@command{protoize} can insert references to a type name or type tag before
965
the definition, or in a file where they are not defined.
966
 
967
If this happens, compiler error messages should show you where the new
968
references are, so fixing the file by hand is straightforward.
969
 
970
@item
971
There are some C constructs which @command{protoize} cannot figure out.
972
For example, it can't determine argument types for declaring a
973
pointer-to-function variable; this you must do by hand.  @command{protoize}
974
inserts a comment containing @samp{???} each time it finds such a
975
variable; so you can find all such variables by searching for this
976
string.  ISO C does not require declaring the argument types of
977
pointer-to-function types.
978
 
979
@item
980
Using @command{unprotoize} can easily introduce bugs.  If the program
981
relied on prototypes to bring about conversion of arguments, these
982
conversions will not take place in the program without prototypes.
983
One case in which you can be sure @command{unprotoize} is safe is when
984
you are removing prototypes that were made with @command{protoize}; if
985
the program worked before without any prototypes, it will work again
986
without them.
987
 
988
@opindex Wconversion
989
You can find all the places where this problem might occur by compiling
990
the program with the @option{-Wconversion} option.  It prints a warning
991
whenever an argument is converted.
992
 
993
@item
994
Both conversion programs can be confused if there are macro calls in and
995
around the text to be converted.  In other words, the standard syntax
996
for a declaration or definition must not result from expanding a macro.
997
This problem is inherent in the design of C and cannot be fixed.  If
998
only a few functions have confusing macro calls, you can easily convert
999
them manually.
1000
 
1001
@item
1002
@command{protoize} cannot get the argument types for a function whose
1003
definition was not actually compiled due to preprocessing conditionals.
1004
When this happens, @command{protoize} changes nothing in regard to such
1005
a function.  @command{protoize} tries to detect such instances and warn
1006
about them.
1007
 
1008
You can generally work around this problem by using @command{protoize} step
1009
by step, each time specifying a different set of @option{-D} options for
1010
compilation, until all of the functions have been converted.  There is
1011
no automatic way to verify that you have got them all, however.
1012
 
1013
@item
1014
Confusion may result if there is an occasion to convert a function
1015
declaration or definition in a region of source code where there is more
1016
than one formal parameter list present.  Thus, attempts to convert code
1017
containing multiple (conditionally compiled) versions of a single
1018
function header (in the same vicinity) may not produce the desired (or
1019
expected) results.
1020
 
1021
If you plan on converting source files which contain such code, it is
1022
recommended that you first make sure that each conditionally compiled
1023
region of source code which contains an alternative function header also
1024
contains at least one additional follower token (past the final right
1025
parenthesis of the function header).  This should circumvent the
1026
problem.
1027
 
1028
@item
1029
@command{unprotoize} can become confused when trying to convert a function
1030
definition or declaration which contains a declaration for a
1031
pointer-to-function formal argument which has the same name as the
1032
function being defined or declared.  We recommend you avoid such choices
1033
of formal parameter names.
1034
 
1035
@item
1036
You might also want to correct some of the indentation by hand and break
1037
long lines.  (The conversion programs don't write lines longer than
1038
eighty characters in any case.)
1039
@end itemize
1040
 
1041
@node Non-bugs
1042
@section Certain Changes We Don't Want to Make
1043
 
1044
This section lists changes that people frequently request, but which
1045
we do not make because we think GCC is better without them.
1046
 
1047
@itemize @bullet
1048
@item
1049
Checking the number and type of arguments to a function which has an
1050
old-fashioned definition and no prototype.
1051
 
1052
Such a feature would work only occasionally---only for calls that appear
1053
in the same file as the called function, following the definition.  The
1054
only way to check all calls reliably is to add a prototype for the
1055
function.  But adding a prototype eliminates the motivation for this
1056
feature.  So the feature is not worthwhile.
1057
 
1058
@item
1059
Warning about using an expression whose type is signed as a shift count.
1060
 
1061
Shift count operands are probably signed more often than unsigned.
1062
Warning about this would cause far more annoyance than good.
1063
 
1064
@item
1065
Warning about assigning a signed value to an unsigned variable.
1066
 
1067
Such assignments must be very common; warning about them would cause
1068
more annoyance than good.
1069
 
1070
@item
1071
Warning when a non-void function value is ignored.
1072
 
1073
C contains many standard functions that return a value that most
1074
programs choose to ignore.  One obvious example is @code{printf}.
1075
Warning about this practice only leads the defensive programmer to
1076
clutter programs with dozens of casts to @code{void}.  Such casts are
1077
required so frequently that they become visual noise.  Writing those
1078
casts becomes so automatic that they no longer convey useful
1079
information about the intentions of the programmer.  For functions
1080
where the return value should never be ignored, use the
1081
@code{warn_unused_result} function attribute (@pxref{Function
1082
Attributes}).
1083
 
1084
@item
1085
@opindex fshort-enums
1086
Making @option{-fshort-enums} the default.
1087
 
1088
This would cause storage layout to be incompatible with most other C
1089
compilers.  And it doesn't seem very important, given that you can get
1090
the same result in other ways.  The case where it matters most is when
1091
the enumeration-valued object is inside a structure, and in that case
1092
you can specify a field width explicitly.
1093
 
1094
@item
1095
Making bit-fields unsigned by default on particular machines where ``the
1096
ABI standard'' says to do so.
1097
 
1098
The ISO C standard leaves it up to the implementation whether a bit-field
1099
declared plain @code{int} is signed or not.  This in effect creates two
1100
alternative dialects of C@.
1101
 
1102
@opindex fsigned-bitfields
1103
@opindex funsigned-bitfields
1104
The GNU C compiler supports both dialects; you can specify the signed
1105
dialect with @option{-fsigned-bitfields} and the unsigned dialect with
1106
@option{-funsigned-bitfields}.  However, this leaves open the question of
1107
which dialect to use by default.
1108
 
1109
Currently, the preferred dialect makes plain bit-fields signed, because
1110
this is simplest.  Since @code{int} is the same as @code{signed int} in
1111
every other context, it is cleanest for them to be the same in bit-fields
1112
as well.
1113
 
1114
Some computer manufacturers have published Application Binary Interface
1115
standards which specify that plain bit-fields should be unsigned.  It is
1116
a mistake, however, to say anything about this issue in an ABI@.  This is
1117
because the handling of plain bit-fields distinguishes two dialects of C@.
1118
Both dialects are meaningful on every type of machine.  Whether a
1119
particular object file was compiled using signed bit-fields or unsigned
1120
is of no concern to other object files, even if they access the same
1121
bit-fields in the same data structures.
1122
 
1123
A given program is written in one or the other of these two dialects.
1124
The program stands a chance to work on most any machine if it is
1125
compiled with the proper dialect.  It is unlikely to work at all if
1126
compiled with the wrong dialect.
1127
 
1128
Many users appreciate the GNU C compiler because it provides an
1129
environment that is uniform across machines.  These users would be
1130
inconvenienced if the compiler treated plain bit-fields differently on
1131
certain machines.
1132
 
1133
Occasionally users write programs intended only for a particular machine
1134
type.  On these occasions, the users would benefit if the GNU C compiler
1135
were to support by default the same dialect as the other compilers on
1136
that machine.  But such applications are rare.  And users writing a
1137
program to run on more than one type of machine cannot possibly benefit
1138
from this kind of compatibility.
1139
 
1140
This is why GCC does and will treat plain bit-fields in the same
1141
fashion on all types of machines (by default).
1142
 
1143
There are some arguments for making bit-fields unsigned by default on all
1144
machines.  If, for example, this becomes a universal de facto standard,
1145
it would make sense for GCC to go along with it.  This is something
1146
to be considered in the future.
1147
 
1148
(Of course, users strongly concerned about portability should indicate
1149
explicitly in each bit-field whether it is signed or not.  In this way,
1150
they write programs which have the same meaning in both C dialects.)
1151
 
1152
@item
1153
@opindex ansi
1154
@opindex std
1155
Undefining @code{__STDC__} when @option{-ansi} is not used.
1156
 
1157
Currently, GCC defines @code{__STDC__} unconditionally.  This provides
1158
good results in practice.
1159
 
1160
Programmers normally use conditionals on @code{__STDC__} to ask whether
1161
it is safe to use certain features of ISO C, such as function
1162
prototypes or ISO token concatenation.  Since plain @command{gcc} supports
1163
all the features of ISO C, the correct answer to these questions is
1164
``yes''.
1165
 
1166
Some users try to use @code{__STDC__} to check for the availability of
1167
certain library facilities.  This is actually incorrect usage in an ISO
1168
C program, because the ISO C standard says that a conforming
1169
freestanding implementation should define @code{__STDC__} even though it
1170
does not have the library facilities.  @samp{gcc -ansi -pedantic} is a
1171
conforming freestanding implementation, and it is therefore required to
1172
define @code{__STDC__}, even though it does not come with an ISO C
1173
library.
1174
 
1175
Sometimes people say that defining @code{__STDC__} in a compiler that
1176
does not completely conform to the ISO C standard somehow violates the
1177
standard.  This is illogical.  The standard is a standard for compilers
1178
that claim to support ISO C, such as @samp{gcc -ansi}---not for other
1179
compilers such as plain @command{gcc}.  Whatever the ISO C standard says
1180
is relevant to the design of plain @command{gcc} without @option{-ansi} only
1181
for pragmatic reasons, not as a requirement.
1182
 
1183
GCC normally defines @code{__STDC__} to be 1, and in addition
1184
defines @code{__STRICT_ANSI__} if you specify the @option{-ansi} option,
1185
or a @option{-std} option for strict conformance to some version of ISO C@.
1186
On some hosts, system include files use a different convention, where
1187
@code{__STDC__} is normally 0, but is 1 if the user specifies strict
1188
conformance to the C Standard.  GCC follows the host convention when
1189
processing system include files, but when processing user files it follows
1190
the usual GNU C convention.
1191
 
1192
@item
1193
Undefining @code{__STDC__} in C++.
1194
 
1195
Programs written to compile with C++-to-C translators get the
1196
value of @code{__STDC__} that goes with the C compiler that is
1197
subsequently used.  These programs must test @code{__STDC__}
1198
to determine what kind of C preprocessor that compiler uses:
1199
whether they should concatenate tokens in the ISO C fashion
1200
or in the traditional fashion.
1201
 
1202
These programs work properly with GNU C++ if @code{__STDC__} is defined.
1203
They would not work otherwise.
1204
 
1205
In addition, many header files are written to provide prototypes in ISO
1206
C but not in traditional C@.  Many of these header files can work without
1207
change in C++ provided @code{__STDC__} is defined.  If @code{__STDC__}
1208
is not defined, they will all fail, and will all need to be changed to
1209
test explicitly for C++ as well.
1210
 
1211
@item
1212
Deleting ``empty'' loops.
1213
 
1214
Historically, GCC has not deleted ``empty'' loops under the
1215
assumption that the most likely reason you would put one in a program is
1216
to have a delay, so deleting them will not make real programs run any
1217
faster.
1218
 
1219
However, the rationale here is that optimization of a nonempty loop
1220
cannot produce an empty one. This held for carefully written C compiled
1221
with less powerful optimizers but is not always the case for carefully
1222
written C++ or with more powerful optimizers.
1223
Thus GCC will remove operations from loops whenever it can determine
1224
those operations are not externally visible (apart from the time taken
1225
to execute them, of course).  In case the loop can be proved to be finite,
1226
GCC will also remove the loop itself.
1227
 
1228
Be aware of this when performing timing tests, for instance the
1229
following loop can be completely removed, provided
1230
@code{some_expression} can provably not change any global state.
1231
 
1232
@smallexample
1233
@{
1234
   int sum = 0;
1235
   int ix;
1236
 
1237
   for (ix = 0; ix != 10000; ix++)
1238
      sum += some_expression;
1239
@}
1240
@end smallexample
1241
 
1242
Even though @code{sum} is accumulated in the loop, no use is made of
1243
that summation, so the accumulation can be removed.
1244
 
1245
@item
1246
Making side effects happen in the same order as in some other compiler.
1247
 
1248
@cindex side effects, order of evaluation
1249
@cindex order of evaluation, side effects
1250
It is never safe to depend on the order of evaluation of side effects.
1251
For example, a function call like this may very well behave differently
1252
from one compiler to another:
1253
 
1254
@smallexample
1255
void func (int, int);
1256
 
1257
int i = 2;
1258
func (i++, i++);
1259
@end smallexample
1260
 
1261
There is no guarantee (in either the C or the C++ standard language
1262
definitions) that the increments will be evaluated in any particular
1263
order.  Either increment might happen first.  @code{func} might get the
1264
arguments @samp{2, 3}, or it might get @samp{3, 2}, or even @samp{2, 2}.
1265
 
1266
@item
1267
Making certain warnings into errors by default.
1268
 
1269
Some ISO C testsuites report failure when the compiler does not produce
1270
an error message for a certain program.
1271
 
1272
@opindex pedantic-errors
1273
ISO C requires a ``diagnostic'' message for certain kinds of invalid
1274
programs, but a warning is defined by GCC to count as a diagnostic.  If
1275
GCC produces a warning but not an error, that is correct ISO C support.
1276
If testsuites call this ``failure'', they should be run with the GCC
1277
option @option{-pedantic-errors}, which will turn these warnings into
1278
errors.
1279
 
1280
@end itemize
1281
 
1282
@node Warnings and Errors
1283
@section Warning Messages and Error Messages
1284
 
1285
@cindex error messages
1286
@cindex warnings vs errors
1287
@cindex messages, warning and error
1288
The GNU compiler can produce two kinds of diagnostics: errors and
1289
warnings.  Each kind has a different purpose:
1290
 
1291
@itemize @w{}
1292
@item
1293
@dfn{Errors} report problems that make it impossible to compile your
1294
program.  GCC reports errors with the source file name and line
1295
number where the problem is apparent.
1296
 
1297
@item
1298
@dfn{Warnings} report other unusual conditions in your code that
1299
@emph{may} indicate a problem, although compilation can (and does)
1300
proceed.  Warning messages also report the source file name and line
1301
number, but include the text @samp{warning:} to distinguish them
1302
from error messages.
1303
@end itemize
1304
 
1305
Warnings may indicate danger points where you should check to make sure
1306
that your program really does what you intend; or the use of obsolete
1307
features; or the use of nonstandard features of GNU C or C++.  Many
1308
warnings are issued only if you ask for them, with one of the @option{-W}
1309
options (for instance, @option{-Wall} requests a variety of useful
1310
warnings).
1311
 
1312
@opindex pedantic
1313
@opindex pedantic-errors
1314
GCC always tries to compile your program if possible; it never
1315
gratuitously rejects a program whose meaning is clear merely because
1316
(for instance) it fails to conform to a standard.  In some cases,
1317
however, the C and C++ standards specify that certain extensions are
1318
forbidden, and a diagnostic @emph{must} be issued by a conforming
1319
compiler.  The @option{-pedantic} option tells GCC to issue warnings in
1320
such cases; @option{-pedantic-errors} says to make them errors instead.
1321
This does not mean that @emph{all} non-ISO constructs get warnings
1322
or errors.
1323
 
1324
@xref{Warning Options,,Options to Request or Suppress Warnings}, for
1325
more detail on these and related command-line options.

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.