OpenE2K
/
gcc
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

cpp.texi: Clean up anachronistic C99 references and remove discussion of very old GCC... 

2016-12-19  Sandra Loosemore  <sandra@codesourcery.com>

	gcc/
	* doc/cpp.texi: Clean up anachronistic C99 references and remove 
	discussion of very old GCC versions.
	(Differences from previous versions): Delete entire section.

From-SVN: r243810
This commit is contained in:
Sandra Loosemore 2016-12-19 15:08:31 -05:00 committed by Sandra Loosemore
parent 5e51f5a55f
commit f56013e541
2 changed files with 52 additions and 219 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
gcc/ChangeLog
View File

@ -1,3 +1,9 @@
2016-12-19 Sandra Loosemore <sandra@codesourcery.com>
* doc/cpp.texi: Clean up anachronistic C99 references and remove
discussion of very old GCC versions.
(Differences from previous versions): Delete entire section.
2016-12-19 Will Schmidt <will_schmidt@vnet.ibm.com>
* config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Add handling for

265
gcc/doc/cpp.texi
View File

@ -163,7 +163,6 @@ Implementation Details
* Implementation-defined behavior::
* Implementation limits::
* Obsolete Features::
* Differences from previous versions::
Obsolete Features
@ -523,8 +522,8 @@ with an optional period, a required decimal digit, and then continue
with any sequence of letters, digits, underscores, periods, and
exponents. Exponents are the two-character sequences @samp{e+},
@samp{e-}, @samp{E+}, @samp{E-}, @samp{p+}, @samp{p-}, @samp{P+}, and
@samp{P-}. (The exponents that begin with @samp{p} or @samp{P} are new
to C99. They are used for hexadecimal floating-point constants.)
@samp{P-}. (The exponents that begin with @samp{p} or @samp{P} are
used for hexadecimal floating-point constants.)
The purpose of this unusual definition is to isolate the preprocessor
from the full complexity of numeric constants. It does not have to
@ -562,10 +561,8 @@ closing quote or angle bracket. The preprocessor looks for the header
file in different places depending on which form you use. @xref{Include
Operation}.
No string literal may extend past the end of a line. Older versions
of GCC accepted multi-line string constants. You may use continued
lines instead, or string constant concatenation. @xref{Differences
from previous versions}.
No string literal may extend past the end of a line. You may use continued
lines instead, or string constant concatenation.
@cindex punctuators
@cindex digraphs
@ -1754,39 +1751,23 @@ eprintf ("success!\n")
The above explanation is ambiguous about the case where the only macro
parameter is a variable arguments parameter, as it is meaningless to
try to distinguish whether no argument at all is an empty argument or
a missing argument. In this case the C99 standard is clear that the
comma must remain, however the existing GCC extension used to swallow
the comma. So CPP retains the comma when conforming to a specific C
standard, and drops it otherwise.
a missing argument.
CPP retains the comma when conforming to a specific C
standard. Otherwise the comma is dropped as an extension to the standard.
C99 mandates that the only place the identifier @code{@w{__VA_ARGS__}}
The C standard
mandates that the only place the identifier @code{@w{__VA_ARGS__}}
can appear is in the replacement list of a variadic macro. It may not
be used as a macro name, macro argument name, or within a different type
of macro. It may also be forbidden in open text; the standard is
ambiguous. We recommend you avoid using it except for its defined
purpose.
Variadic macros are a new feature in C99. GNU CPP has supported them
for a long time, but only with a named variable argument
(@samp{args@dots{}}, not @samp{@dots{}} and @code{@w{__VA_ARGS__}}). If you are
concerned with portability to previous versions of GCC, you should use
only named variable arguments. On the other hand, if you are concerned
with portability to other conforming implementations of C99, you should
use only @code{@w{__VA_ARGS__}}.
Previous versions of CPP implemented the comma-deletion extension
much more generally. We have restricted it in this release to minimize
the differences from C99. To get the same effect with both this and
previous versions of GCC, the token preceding the special @samp{##} must
be a comma, and there must be white space between that comma and
whatever comes immediately before it:
@smallexample
#define eprintf(format, args@dots{}) fprintf (stderr, format , ##args)
@end smallexample
@noindent
@xref{Differences from previous versions}, for the gory details.
Variadic macros became a standard part of the C language with C99.
GNU CPP previously supported them
with a named variable argument
(@samp{args@dots{}}, not @samp{@dots{}} and @code{@w{__VA_ARGS__}}), which
is still supported for backward compatibility.
@node Predefined Macros
@section Predefined Macros
@ -1854,7 +1835,7 @@ processing moves to the line after the @samp{#include}).
A @samp{#line} directive changes @code{__LINE__}, and may change
@code{__FILE__} as well. @xref{Line Control}.
C99 introduces @code{__func__}, and GCC has provided @code{__FUNCTION__}
C99 introduced @code{__func__}, and GCC has provided @code{__FUNCTION__}
for a long time. Both of these are strings containing the name of the
current function (there are slight semantic differences; see the GCC
manual). Neither of them is a macro; the preprocessor does not know the
@ -1971,14 +1952,11 @@ The GNU Fortran compiler defines this.
These macros are defined by all GNU compilers that use the C
preprocessor: C, C++, Objective-C and Fortran. Their values are the major
version, minor version, and patch level of the compiler, as integer
constants. For example, GCC 3.2.1 will define @code{__GNUC__} to 3,
@code{__GNUC_MINOR__} to 2, and @code{__GNUC_PATCHLEVEL__} to 1. These
constants. For example, GCC version @var{x}.@var{y}.@var{z}
defines @code{__GNUC__} to @var{x}, @code{__GNUC_MINOR__} to @var{y},
and @code{__GNUC_PATCHLEVEL__} to @var{z}. These
macros are also defined if you invoke the preprocessor directly.
@code{__GNUC_PATCHLEVEL__} is new to GCC 3.0; it is also present in the
widely-used development snapshots leading up to 3.0 (which identify
themselves as GCC 2.96 or 2.97, depending on which snapshot you have).
If all you need to know is whether or not your program is being compiled
by GCC, or a non-GCC compiler that claims to accept the GNU C dialects,
you can simply test @code{__GNUC__}. If you need to write code
@ -2021,9 +1999,8 @@ testing @code{@w{(__GNUC__ && __cplusplus)}}.
GCC defines this macro if and only if the @option{-ansi} switch, or a
@option{-std} switch specifying strict conformance to some version of ISO C
or ISO C++, was specified when GCC was invoked. It is defined to @samp{1}.
This macro exists primarily to direct GNU libc's header files to
restrict their definitions to the minimal set found in the 1989 C
standard.
This macro exists primarily to direct GNU libc's header files to use only
definitions found in standard C.
@item __BASE_FILE__
This macro expands to the name of the main input file, in the form
@ -2071,17 +2048,13 @@ definitions of any functions declared @code{extern inline}.
@item __GNUC_STDC_INLINE__
GCC defines this macro if functions declared @code{inline} will be
handled according to the ISO C99 standard. Object files will contain
handled according to the ISO C99 or later standards. Object files will contain
externally visible definitions of all functions declared @code{extern
inline}. They will not contain definitions of any functions declared
@code{inline} without @code{extern}.
If this macro is defined, GCC supports the @code{gnu_inline} function
attribute as a way to always get the gnu90 behavior. Support for
this and @code{__GNUC_GNU_INLINE__} was added in GCC 4.1.3. If
neither macro is defined, an older version of GCC is being used:
@code{inline} functions will be compiled in gnu90 mode, and the
@code{gnu_inline} function attribute will not be recognized.
attribute as a way to always get the gnu90 behavior.
@item __CHAR_UNSIGNED__
GCC defines this macro if and only if the data type @code{char} is
@ -2600,18 +2573,8 @@ preprocessor will only complain if the definitions do not match.
Occasionally it is convenient to use preprocessor directives within
the arguments of a macro. The C and C++ standards declare that
behavior in these cases is undefined.
Versions of CPP prior to 3.2 would reject such constructs with an
error message. This was the only syntactic difference between normal
functions and function-like macros, so it seemed attractive to remove
this limitation, and people would often be surprised that they could
not use macros in this way. Moreover, sometimes people would use
conditional compilation in the argument list to a normal library
function like @samp{printf}, only to find that after a library upgrade
@samp{printf} had changed to be a function-like macro, and their code
would no longer compile. So from version 3.2 we changed CPP to
successfully process arbitrary directives within macro arguments in
behavior in these cases is undefined. GNU CPP
processes arbitrary directives within macro arguments in
exactly the same way as it would have processed the directive were the
function-like macro invocation not present.
@ -3128,9 +3091,6 @@ course, you can only use this to exclude code, not type definitions or
other preprocessing directives, and you can only do it if the code
remains syntactically valid when it is not to be used.
GCC version 3 eliminates this kind of never-executed code even when
not optimizing. Older versions did it only when optimizing.
@menu
* Conditional Uses::
* Conditional Syntax::
@ -3560,10 +3520,6 @@ file it specifies, until something else happens to change that.
constant: backslash escapes are interpreted. This is different from
@samp{#include}.
Previous versions of CPP did not interpret escapes in @samp{#line};
we have changed it because the standard requires they be interpreted,
and most other compilers do.
@item #line @var{anything else}
@var{anything else} is checked for macro calls, which are expanded.
The result should match one of the above two forms.
@ -3572,60 +3528,21 @@ The result should match one of the above two forms.
@samp{#line} directives alter the results of the @code{__FILE__} and
@code{__LINE__} predefined macros from that point on. @xref{Standard
Predefined Macros}. They do not have any effect on @samp{#include}'s
idea of the directory containing the current file. This is a change
from GCC 2.95. Previously, a file reading
@smallexample
#line 1 "../src/gram.y"
#include "gram.h"
@end smallexample
would search for @file{gram.h} in @file{../src}, then the @option{-I}
chain; the directory containing the physical source file would not be
searched. In GCC 3.0 and later, the @samp{#include} is not affected by
the presence of a @samp{#line} referring to a different directory.
We made this change because the old behavior caused problems when
generated source files were transported between machines. For instance,
it is common practice to ship generated parsers with a source release,
so that people building the distribution do not need to have yacc or
Bison installed. These files frequently have @samp{#line} directives
referring to the directory tree of the system where the distribution was
created. If GCC tries to search for headers in those directories, the
build is likely to fail.
The new behavior can cause failures too, if the generated file is not
in the same directory as its source and it attempts to include a header
which would be visible searching from the directory containing the
source file. However, this problem is easily solved with an additional
@option{-I} switch on the command line. The failures caused by the old
semantics could sometimes be corrected only by editing the generated
files, which is difficult and error-prone.
idea of the directory containing the current file.
@node Pragmas
@chapter Pragmas
The @samp{#pragma} directive is the method specified by the C standard
for providing additional information to the compiler, beyond what is
conveyed in the language itself. Three forms of this directive
(commonly known as @dfn{pragmas}) are specified by the 1999 C standard.
A C compiler is free to attach any meaning it likes to other pragmas.
GCC has historically preferred to use extensions to the syntax of the
language, such as @code{__attribute__}, for this purpose. However, GCC
does define a few pragmas of its own. These mostly have effects on the
entire translation unit or source file.
In GCC version 3, all GNU-defined, supported pragmas have been given a
@code{GCC} prefix. This is in line with the @code{STDC} prefix on all
pragmas defined by C99. For backward compatibility, pragmas which were
recognized by previous versions are still recognized without the
@code{GCC} prefix, but that usage is deprecated. Some older pragmas are
deprecated in their entirety. They are not recognized with the
@code{GCC} prefix. @xref{Obsolete Features}.
conveyed in the language itself. The forms of this directive
(commonly known as @dfn{pragmas}) specified by C standard are prefixed with
@code{STDC}. A C compiler is free to attach any meaning it likes to other
pragmas. All GNU-defined, supported pragmas have been given a
@code{GCC} prefix.
@cindex @code{_Pragma}
C99 introduces the @code{@w{_Pragma}} operator. This feature addresses a
C99 introduced the @code{@w{_Pragma}} operator. This feature addresses a
major problem with @samp{#pragma}: being a directive, it cannot be
produced as the result of macro expansion. @code{@w{_Pragma}} is an
operator, much like @code{sizeof} or @code{defined}, and can be embedded
@ -3772,7 +3689,7 @@ to become a single space, with the exception that the first token on a
non-directive line is preceded with sufficient spaces that it appears in
the same column in the preprocessed output that it appeared in the
original source file. This is so the output is easy to read.
@xref{Differences from previous versions}. CPP does not insert any
CPP does not insert any
whitespace where there was none in the original source, except where
necessary to prevent an accidental token paste.
@ -3829,16 +3746,18 @@ the directive name.
@chapter Traditional Mode
Traditional (pre-standard) C preprocessing is rather different from
the preprocessing specified by the standard. When GCC is given the
the preprocessing specified by the standard. When the preprocessor
is invoked with the
@option{-traditional-cpp} option, it attempts to emulate a traditional
preprocessor.
preprocessor.
GCC versions 3.2 and later only support traditional mode semantics in
the preprocessor, and not in the compiler front ends. This chapter
outlines the traditional preprocessor semantics we implemented.
This mode is not useful for compiling C code with GCC,
but is intended for use with non-C preprocessing applications. Thus
traditional mode semantics are supported only when invoking
the preprocessor explicitly, and not in the compiler front ends.
The implementation does not correspond precisely to the behavior of
earlier versions of GCC, nor to any true traditional preprocessor.
early pre-standard versions of GCC, nor to any true traditional preprocessor.
After all, inconsistencies among traditional implementations were a
major motivation for C standardization. However, we intend that it
should be compatible with true traditional preprocessors in all ways
@ -4105,14 +4024,12 @@ affects its user-visible behavior. You should try to avoid undue
reliance on behavior described here, as it is possible that it will
change subtly in future implementations.
Also documented here are obsolete features and changes from previous
versions of CPP@.
Also documented here are obsolete features still supported by CPP@.
@menu
* Implementation-defined behavior::
* Implementation limits::
* Obsolete Features::
* Differences from previous versions::
@end menu
@node Implementation-defined behavior
@ -4139,9 +4056,9 @@ be controlled using the @option{-fexec-charset} and
@anchor{Identifier characters}
The C and C++ standards allow identifiers to be composed of @samp{_}
and the alphanumeric characters. C++ and C99 also allow universal
character names, and C99 further permits implementation-defined
characters.
and the alphanumeric characters. C++ also allows universal character
names. C99 and later C standards permit both universal character
names and implementation-defined characters.
GCC allows the @samp{$} character in identifiers as an extension for
most targets. This is true regardless of the @option{std=} switch,
@ -4174,8 +4091,8 @@ at a time, shifting the previous value left by the number of bits per
target character, and then or-ing in the bit-pattern of the new
character truncated to the width of a target character. The final
bit-pattern is given type @code{int}, and is therefore signed,
regardless of whether single characters are signed or not (a slight
change from versions 3.1 and earlier of GCC)@. If there are more
regardless of whether single characters are signed or not.
If there are more
characters in the constant than would fit in the target @code{int} the
compiler issues a warning, and the excess leading characters are
ignored.
@ -4363,96 +4280,6 @@ no effect.
You can also make or cancel assertions using command-line options.
@xref{Invocation}.
@node Differences from previous versions
@section Differences from previous versions
@cindex differences from previous versions
This section details behavior which has changed from previous versions
of CPP@. We do not plan to change it again in the near future, but
we do not promise not to, either.
The ``previous versions'' discussed here are 2.95 and before. The
behavior of GCC 3.0 is mostly the same as the behavior of the widely
used 2.96 and 2.97 development snapshots. Where there are differences,
they generally represent bugs in the snapshots.
@itemize @bullet
@item -I- deprecated
This option has been deprecated in 4.0. @option{-iquote} is meant to
replace the need for this option.
@item Order of evaluation of @samp{#} and @samp{##} operators
The standard does not specify the order of evaluation of a chain of
@samp{##} operators, nor whether @samp{#} is evaluated before, after, or
at the same time as @samp{##}. You should therefore not write any code
which depends on any specific ordering. It is possible to guarantee an
ordering, if you need one, by suitable use of nested macros.
An example of where this might matter is pasting the arguments @samp{1},
@samp{e} and @samp{-2}. This would be fine for left-to-right pasting,
but right-to-left pasting would produce an invalid token @samp{e-2}.
GCC 3.0 evaluates @samp{#} and @samp{##} at the same time and strictly
left to right. Older versions evaluated all @samp{#} operators first,
then all @samp{##} operators, in an unreliable order.
@item The form of whitespace between tokens in preprocessor output
@xref{Preprocessor Output}, for the current textual format. This is
also the format used by stringification. Normally, the preprocessor
communicates tokens directly to the compiler's parser, and whitespace
does not come up at all.
Older versions of GCC preserved all whitespace provided by the user and
inserted lots more whitespace of their own, because they could not
accurately predict when extra spaces were needed to prevent accidental
token pasting.
@item Optional argument when invoking rest argument macros
As an extension, GCC permits you to omit the variable arguments entirely
when you use a variable argument macro. This is forbidden by the 1999 C
standard, and will provoke a pedantic warning with GCC 3.0. Previous
versions accepted it silently.
@item @samp{##} swallowing preceding text in rest argument macros
Formerly, in a macro expansion, if @samp{##} appeared before a variable
arguments parameter, and the set of tokens specified for that argument
in the macro invocation was empty, previous versions of CPP would
back up and remove the preceding sequence of non-whitespace characters
(@strong{not} the preceding token). This extension is in direct
conflict with the 1999 C standard and has been drastically pared back.
In the current version of the preprocessor, if @samp{##} appears between
a comma and a variable arguments parameter, and the variable argument is
omitted entirely, the comma will be removed from the expansion. If the
variable argument is empty, or the token before @samp{##} is not a
comma, then @samp{##} behaves as a normal token paste.
@item @samp{#line} and @samp{#include}
The @samp{#line} directive used to change GCC's notion of the
``directory containing the current file'', used by @samp{#include} with
a double-quoted header file name. In 3.0 and later, it does not.
@xref{Line Control}, for further explanation.
@item Syntax of @samp{#line}
In GCC 2.95 and previous, the string constant argument to @samp{#line}
was treated the same way as the argument to @samp{#include}: backslash
escapes were not honored, and the string ended at the second @samp{"}.
This is not compliant with the C standard. In GCC 3.0, an attempt was
made to correct the behavior, so that the string was treated as a real
string constant, but it turned out to be buggy. In 3.1, the bugs have
been fixed. (We are not fixing the bugs in 3.0 because they affect
relatively few people and the fix is quite invasive.)
@end itemize
@node Invocation
@chapter Invocation
@cindex invocation