You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
274 lines
14 KiB
HTML
274 lines
14 KiB
HTML
4 years ago
|
<html lang="en">
|
||
|
|
<head>
|
||
|
|
<title>Non-bugs - Using the GNU Compiler Collection (GCC)</title>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html">
|
||
|
|
<meta name="description" content="Using the GNU Compiler Collection (GCC)">
|
||
|
|
<meta name="generator" content="makeinfo 4.13">
|
||
|
|
<link title="Top" rel="start" href="index.html#Top">
|
||
|
|
<link rel="up" href="Trouble.html#Trouble" title="Trouble">
|
||
|
|
<link rel="prev" href="C_002b_002b-Misunderstandings.html#C_002b_002b-Misunderstandings" title="C++ Misunderstandings">
|
||
|
|
<link rel="next" href="Warnings-and-Errors.html#Warnings-and-Errors" title="Warnings and Errors">
|
||
|
|
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||
|
|
<!--
|
||
|
|
Copyright (C) 1988-2015 Free Software Foundation, Inc.
|
||
|
|
|
||
|
|
Permission is granted to copy, distribute and/or modify this document
|
||
|
|
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||
|
|
any later version published by the Free Software Foundation; with the
|
||
|
|
Invariant Sections being ``Funding Free Software'', the Front-Cover
|
||
|
|
Texts being (a) (see below), and with the Back-Cover Texts being (b)
|
||
|
|
(see below). A copy of the license is included in the section entitled
|
||
|
|
``GNU Free Documentation License''.
|
||
|
|
|
||
|
|
(a) The FSF's Front-Cover Text is:
|
||
|
|
|
||
|
|
A GNU Manual
|
||
|
|
|
||
|
|
(b) The FSF's Back-Cover Text is:
|
||
|
|
|
||
|
|
You have freedom to copy and modify this GNU Manual, like GNU
|
||
|
|
software. Copies published by the Free Software Foundation raise
|
||
|
|
funds for GNU development.-->
|
||
|
|
<meta http-equiv="Content-Style-Type" content="text/css">
|
||
|
|
<style type="text/css"><!--
|
||
|
|
pre.display { font-family:inherit }
|
||
|
|
pre.format { font-family:inherit }
|
||
|
|
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||
|
|
pre.smallformat { font-family:inherit; font-size:smaller }
|
||
|
|
pre.smallexample { font-size:smaller }
|
||
|
|
pre.smalllisp { font-size:smaller }
|
||
|
|
span.sc { font-variant:small-caps }
|
||
|
|
span.roman { font-family:serif; font-weight:normal; }
|
||
|
|
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||
|
|
--></style>
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
<div class="node">
|
||
|
|
<a name="Non-bugs"></a>
|
||
|
|
<a name="Non_002dbugs"></a>
|
||
|
|
<p>
|
||
|
|
Next: <a rel="next" accesskey="n" href="Warnings-and-Errors.html#Warnings-and-Errors">Warnings and Errors</a>,
|
||
|
|
Previous: <a rel="previous" accesskey="p" href="C_002b_002b-Misunderstandings.html#C_002b_002b-Misunderstandings">C++ Misunderstandings</a>,
|
||
|
|
Up: <a rel="up" accesskey="u" href="Trouble.html#Trouble">Trouble</a>
|
||
|
|
<hr>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<h3 class="section">12.8 Certain Changes We Don't Want to Make</h3>
|
||
|
|
|
||
|
|
<p>This section lists changes that people frequently request, but which
|
||
|
|
we do not make because we think GCC is better without them.
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li>Checking the number and type of arguments to a function which has an
|
||
|
|
old-fashioned definition and no prototype.
|
||
|
|
|
||
|
|
<p>Such a feature would work only occasionally—only for calls that appear
|
||
|
|
in the same file as the called function, following the definition. The
|
||
|
|
only way to check all calls reliably is to add a prototype for the
|
||
|
|
function. But adding a prototype eliminates the motivation for this
|
||
|
|
feature. So the feature is not worthwhile.
|
||
|
|
|
||
|
|
<li>Warning about using an expression whose type is signed as a shift count.
|
||
|
|
|
||
|
|
<p>Shift count operands are probably signed more often than unsigned.
|
||
|
|
Warning about this would cause far more annoyance than good.
|
||
|
|
|
||
|
|
<li>Warning about assigning a signed value to an unsigned variable.
|
||
|
|
|
||
|
|
<p>Such assignments must be very common; warning about them would cause
|
||
|
|
more annoyance than good.
|
||
|
|
|
||
|
|
<li>Warning when a non-void function value is ignored.
|
||
|
|
|
||
|
|
<p>C contains many standard functions that return a value that most
|
||
|
|
programs choose to ignore. One obvious example is <code>printf</code>.
|
||
|
|
Warning about this practice only leads the defensive programmer to
|
||
|
|
clutter programs with dozens of casts to <code>void</code>. Such casts are
|
||
|
|
required so frequently that they become visual noise. Writing those
|
||
|
|
casts becomes so automatic that they no longer convey useful
|
||
|
|
information about the intentions of the programmer. For functions
|
||
|
|
where the return value should never be ignored, use the
|
||
|
|
<code>warn_unused_result</code> function attribute (see <a href="Function-Attributes.html#Function-Attributes">Function Attributes</a>).
|
||
|
|
|
||
|
|
<li><a name="index-fshort_002denums-4287"></a>Making <samp><span class="option">-fshort-enums</span></samp> the default.
|
||
|
|
|
||
|
|
<p>This would cause storage layout to be incompatible with most other C
|
||
|
|
compilers. And it doesn't seem very important, given that you can get
|
||
|
|
the same result in other ways. The case where it matters most is when
|
||
|
|
the enumeration-valued object is inside a structure, and in that case
|
||
|
|
you can specify a field width explicitly.
|
||
|
|
|
||
|
|
<li>Making bit-fields unsigned by default on particular machines where “the
|
||
|
|
ABI standard” says to do so.
|
||
|
|
|
||
|
|
<p>The ISO C standard leaves it up to the implementation whether a bit-field
|
||
|
|
declared plain <code>int</code> is signed or not. This in effect creates two
|
||
|
|
alternative dialects of C.
|
||
|
|
|
||
|
|
<p><a name="index-fsigned_002dbitfields-4288"></a><a name="index-funsigned_002dbitfields-4289"></a>The GNU C compiler supports both dialects; you can specify the signed
|
||
|
|
dialect with <samp><span class="option">-fsigned-bitfields</span></samp> and the unsigned dialect with
|
||
|
|
<samp><span class="option">-funsigned-bitfields</span></samp>. However, this leaves open the question of
|
||
|
|
which dialect to use by default.
|
||
|
|
|
||
|
|
<p>Currently, the preferred dialect makes plain bit-fields signed, because
|
||
|
|
this is simplest. Since <code>int</code> is the same as <code>signed int</code> in
|
||
|
|
every other context, it is cleanest for them to be the same in bit-fields
|
||
|
|
as well.
|
||
|
|
|
||
|
|
<p>Some computer manufacturers have published Application Binary Interface
|
||
|
|
standards which specify that plain bit-fields should be unsigned. It is
|
||
|
|
a mistake, however, to say anything about this issue in an ABI. This is
|
||
|
|
because the handling of plain bit-fields distinguishes two dialects of C.
|
||
|
|
Both dialects are meaningful on every type of machine. Whether a
|
||
|
|
particular object file was compiled using signed bit-fields or unsigned
|
||
|
|
is of no concern to other object files, even if they access the same
|
||
|
|
bit-fields in the same data structures.
|
||
|
|
|
||
|
|
<p>A given program is written in one or the other of these two dialects.
|
||
|
|
The program stands a chance to work on most any machine if it is
|
||
|
|
compiled with the proper dialect. It is unlikely to work at all if
|
||
|
|
compiled with the wrong dialect.
|
||
|
|
|
||
|
|
<p>Many users appreciate the GNU C compiler because it provides an
|
||
|
|
environment that is uniform across machines. These users would be
|
||
|
|
inconvenienced if the compiler treated plain bit-fields differently on
|
||
|
|
certain machines.
|
||
|
|
|
||
|
|
<p>Occasionally users write programs intended only for a particular machine
|
||
|
|
type. On these occasions, the users would benefit if the GNU C compiler
|
||
|
|
were to support by default the same dialect as the other compilers on
|
||
|
|
that machine. But such applications are rare. And users writing a
|
||
|
|
program to run on more than one type of machine cannot possibly benefit
|
||
|
|
from this kind of compatibility.
|
||
|
|
|
||
|
|
<p>This is why GCC does and will treat plain bit-fields in the same
|
||
|
|
fashion on all types of machines (by default).
|
||
|
|
|
||
|
|
<p>There are some arguments for making bit-fields unsigned by default on all
|
||
|
|
machines. If, for example, this becomes a universal de facto standard,
|
||
|
|
it would make sense for GCC to go along with it. This is something
|
||
|
|
to be considered in the future.
|
||
|
|
|
||
|
|
<p>(Of course, users strongly concerned about portability should indicate
|
||
|
|
explicitly in each bit-field whether it is signed or not. In this way,
|
||
|
|
they write programs which have the same meaning in both C dialects.)
|
||
|
|
|
||
|
|
<li><a name="index-ansi-4290"></a><a name="index-std-4291"></a>Undefining <code>__STDC__</code> when <samp><span class="option">-ansi</span></samp> is not used.
|
||
|
|
|
||
|
|
<p>Currently, GCC defines <code>__STDC__</code> unconditionally. This provides
|
||
|
|
good results in practice.
|
||
|
|
|
||
|
|
<p>Programmers normally use conditionals on <code>__STDC__</code> to ask whether
|
||
|
|
it is safe to use certain features of ISO C, such as function
|
||
|
|
prototypes or ISO token concatenation. Since plain <samp><span class="command">gcc</span></samp> supports
|
||
|
|
all the features of ISO C, the correct answer to these questions is
|
||
|
|
“yes”.
|
||
|
|
|
||
|
|
<p>Some users try to use <code>__STDC__</code> to check for the availability of
|
||
|
|
certain library facilities. This is actually incorrect usage in an ISO
|
||
|
|
C program, because the ISO C standard says that a conforming
|
||
|
|
freestanding implementation should define <code>__STDC__</code> even though it
|
||
|
|
does not have the library facilities. ‘<samp><span class="samp">gcc -ansi -pedantic</span></samp>’ is a
|
||
|
|
conforming freestanding implementation, and it is therefore required to
|
||
|
|
define <code>__STDC__</code>, even though it does not come with an ISO C
|
||
|
|
library.
|
||
|
|
|
||
|
|
<p>Sometimes people say that defining <code>__STDC__</code> in a compiler that
|
||
|
|
does not completely conform to the ISO C standard somehow violates the
|
||
|
|
standard. This is illogical. The standard is a standard for compilers
|
||
|
|
that claim to support ISO C, such as ‘<samp><span class="samp">gcc -ansi</span></samp>’—not for other
|
||
|
|
compilers such as plain <samp><span class="command">gcc</span></samp>. Whatever the ISO C standard says
|
||
|
|
is relevant to the design of plain <samp><span class="command">gcc</span></samp> without <samp><span class="option">-ansi</span></samp> only
|
||
|
|
for pragmatic reasons, not as a requirement.
|
||
|
|
|
||
|
|
<p>GCC normally defines <code>__STDC__</code> to be 1, and in addition
|
||
|
|
defines <code>__STRICT_ANSI__</code> if you specify the <samp><span class="option">-ansi</span></samp> option,
|
||
|
|
or a <samp><span class="option">-std</span></samp> option for strict conformance to some version of ISO C.
|
||
|
|
On some hosts, system include files use a different convention, where
|
||
|
|
<code>__STDC__</code> is normally 0, but is 1 if the user specifies strict
|
||
|
|
conformance to the C Standard. GCC follows the host convention when
|
||
|
|
processing system include files, but when processing user files it follows
|
||
|
|
the usual GNU C convention.
|
||
|
|
|
||
|
|
<li>Undefining <code>__STDC__</code> in C++.
|
||
|
|
|
||
|
|
<p>Programs written to compile with C++-to-C translators get the
|
||
|
|
value of <code>__STDC__</code> that goes with the C compiler that is
|
||
|
|
subsequently used. These programs must test <code>__STDC__</code>
|
||
|
|
to determine what kind of C preprocessor that compiler uses:
|
||
|
|
whether they should concatenate tokens in the ISO C fashion
|
||
|
|
or in the traditional fashion.
|
||
|
|
|
||
|
|
<p>These programs work properly with GNU C++ if <code>__STDC__</code> is defined.
|
||
|
|
They would not work otherwise.
|
||
|
|
|
||
|
|
<p>In addition, many header files are written to provide prototypes in ISO
|
||
|
|
C but not in traditional C. Many of these header files can work without
|
||
|
|
change in C++ provided <code>__STDC__</code> is defined. If <code>__STDC__</code>
|
||
|
|
is not defined, they will all fail, and will all need to be changed to
|
||
|
|
test explicitly for C++ as well.
|
||
|
|
|
||
|
|
<li>Deleting “empty” loops.
|
||
|
|
|
||
|
|
<p>Historically, GCC has not deleted “empty” loops under the
|
||
|
|
assumption that the most likely reason you would put one in a program is
|
||
|
|
to have a delay, so deleting them will not make real programs run any
|
||
|
|
faster.
|
||
|
|
|
||
|
|
<p>However, the rationale here is that optimization of a nonempty loop
|
||
|
|
cannot produce an empty one. This held for carefully written C compiled
|
||
|
|
with less powerful optimizers but is not always the case for carefully
|
||
|
|
written C++ or with more powerful optimizers.
|
||
|
|
Thus GCC will remove operations from loops whenever it can determine
|
||
|
|
those operations are not externally visible (apart from the time taken
|
||
|
|
to execute them, of course). In case the loop can be proved to be finite,
|
||
|
|
GCC will also remove the loop itself.
|
||
|
|
|
||
|
|
<p>Be aware of this when performing timing tests, for instance the
|
||
|
|
following loop can be completely removed, provided
|
||
|
|
<code>some_expression</code> can provably not change any global state.
|
||
|
|
|
||
|
|
<pre class="smallexample"> {
|
||
|
|
int sum = 0;
|
||
|
|
int ix;
|
||
|
|
|
||
|
|
for (ix = 0; ix != 10000; ix++)
|
||
|
|
sum += some_expression;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
<p>Even though <code>sum</code> is accumulated in the loop, no use is made of
|
||
|
|
that summation, so the accumulation can be removed.
|
||
|
|
|
||
|
|
<li>Making side effects happen in the same order as in some other compiler.
|
||
|
|
|
||
|
|
<p><a name="index-side-effects_002c-order-of-evaluation-4292"></a><a name="index-order-of-evaluation_002c-side-effects-4293"></a>It is never safe to depend on the order of evaluation of side effects.
|
||
|
|
For example, a function call like this may very well behave differently
|
||
|
|
from one compiler to another:
|
||
|
|
|
||
|
|
<pre class="smallexample"> void func (int, int);
|
||
|
|
|
||
|
|
int i = 2;
|
||
|
|
func (i++, i++);
|
||
|
|
</pre>
|
||
|
|
<p>There is no guarantee (in either the C or the C++ standard language
|
||
|
|
definitions) that the increments will be evaluated in any particular
|
||
|
|
order. Either increment might happen first. <code>func</code> might get the
|
||
|
|
arguments ‘<samp><span class="samp">2, 3</span></samp>’, or it might get ‘<samp><span class="samp">3, 2</span></samp>’, or even ‘<samp><span class="samp">2, 2</span></samp>’.
|
||
|
|
|
||
|
|
<li>Making certain warnings into errors by default.
|
||
|
|
|
||
|
|
<p>Some ISO C testsuites report failure when the compiler does not produce
|
||
|
|
an error message for a certain program.
|
||
|
|
|
||
|
|
<p><a name="index-pedantic_002derrors-4294"></a>ISO C requires a “diagnostic” message for certain kinds of invalid
|
||
|
|
programs, but a warning is defined by GCC to count as a diagnostic. If
|
||
|
|
GCC produces a warning but not an error, that is correct ISO C support.
|
||
|
|
If testsuites call this “failure”, they should be run with the GCC
|
||
|
|
option <samp><span class="option">-pedantic-errors</span></samp>, which will turn these warnings into
|
||
|
|
errors.
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
</body></html>
|
||
|
|
|