home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Fresh Fish 4
/
FreshFish_May-June1994.bin
/
gnu
/
info
/
gcc.info-8
(
.txt
)
< prev
next >
Wrap
GNU Info File
|
1994-02-20
|
51KB
|
897 lines
This is Info file gcc.info, produced by Makeinfo-1.55 from the input
file gcc.texi.
This file documents the use and the internals of the GNU compiler.
Published by the Free Software Foundation 675 Massachusetts Avenue
Cambridge, MA 02139 USA
Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "GNU General Public License" and "Protect
Your Freedom--Fight `Look And Feel'" are included exactly as in the
original, and provided that the entire resulting derived work is
distributed under the terms of a permission notice identical to this
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License" and "Protect Your Freedom--Fight `Look And Feel'", and this
permission notice, may be included in translations approved by the Free
Software Foundation instead of in the original English.
File: gcc.info, Node: Local Reg Vars, Prev: Global Reg Vars, Up: Explicit Reg Vars
Specifying Registers for Local Variables
----------------------------------------
You can define a local register variable with a specified register
like this:
register int *foo asm ("a5");
Here `a5' is the name of the register which should be used. Note that
this is the same syntax used for defining global register variables,
but for a local variable it would appear within a function.
Naturally the register name is cpu-dependent, but this is not a
problem, since specific registers are most often useful with explicit
assembler instructions (*note Extended Asm::.). Both of these things
generally require that you conditionalize your program according to cpu
type.
In addition, operating systems on one type of cpu may differ in how
they name the registers; then you would need additional conditionals.
For example, some 68000 operating systems call this register `%a5'.
Eventually there may be a way of asking the compiler to choose a
register automatically, but first we need to figure out how it should
choose and how to enable you to guide the choice. No solution is
evident.
Defining such a register variable does not reserve the register; it
remains available for other uses in places where flow control determines
the variable's value is not live. However, these registers are made
unavailable for use in the reload pass. I would not be surprised if
excessive use of this feature leaves the compiler too few available
registers to compile certain functions.
File: gcc.info, Node: Alternate Keywords, Next: Incomplete Enums, Prev: Explicit Reg Vars, Up: C Extensions
Alternate Keywords
==================
The option `-traditional' disables certain keywords; `-ansi'
disables certain others. This causes trouble when you want to use GNU C
extensions, or ANSI C features, in a general-purpose header file that
should be usable by all programs, including ANSI C programs and
traditional ones. The keywords `asm', `typeof' and `inline' cannot be
used since they won't work in a program compiled with `-ansi', while
the keywords `const', `volatile', `signed', `typeof' and `inline' won't
work in a program compiled with `-traditional'.
The way to solve these problems is to put `__' at the beginning and
end of each problematical keyword. For example, use `__asm__' instead
of `asm', `__const__' instead of `const', and `__inline__' instead of
`inline'.
Other C compilers won't accept these alternative keywords; if you
want to compile with another compiler, you can define the alternate
keywords as macros to replace them with the customary keywords. It
looks like this:
#ifndef __GNUC__
#define __asm__ asm
#endif
`-pedantic' causes warnings for many GNU C extensions. You can
prevent such warnings within one expression by writing `__extension__'
before the expression. `__extension__' has no effect aside from this.
File: gcc.info, Node: Incomplete Enums, Next: Function Names, Prev: Alternate Keywords, Up: C Extensions
Incomplete `enum' Types
=======================
You can define an `enum' tag without specifying its possible values.
This results in an incomplete type, much like what you get if you write
`struct foo' without describing the elements. A later declaration
which does specify the possible values completes the type.
You can't allocate variables or storage using the type while it is
incomplete. However, you can work with pointers to that type.
This extension may not be very useful, but it makes the handling of
`enum' more consistent with the way `struct' and `union' are handled.
File: gcc.info, Node: Function Names, Prev: Incomplete Enums, Up: C Extensions
Function Names as Strings
=========================
GNU CC predefines two string variables to be the name of the current
function. The variable `__FUNCTION__' is the name of the function as
it appears in the source. The variable `__PRETTY_FUNCTION__' is the
name of the function pretty printed in a language specific fashion.
These names are always the same in a C function, but in a C++
function they may be different. For example, this program:
extern "C" {
extern int printf (char *, ...);
}
class a {
public:
sub (int i)
{
printf ("__FUNCTION__ = %s\n", __FUNCTION__);
printf ("__PRETTY_FUNCTION__ = %s\n", __PRETTY_FUNCTION__);
}
};
int
main (void)
{
a ax;
ax.sub (0);
return 0;
}
gives this output:
__FUNCTION__ = sub
__PRETTY_FUNCTION__ = int a::sub (int)
File: gcc.info, Node: C++ Extensions, Next: Trouble, Prev: C Extensions, Up: Top
Extensions to the C++ Language
******************************
The GNU compiler provides these extensions to the C++ language (and
you can also use most of the C language extensions in your C++
programs). If you want to write code that checks whether these
features are available, you can test for the GNU compiler the same way
as for C programs: check for a predefined macro `__GNUC__'. You can
also use `__GNUG__' to test specifically for GNU C++ (*note Standard
Predefined Macros: (cpp.info)Standard Predefined.).
* Menu:
* Naming Results:: Giving a name to C++ function return values.
* Min and Max:: C++ Minimum and maximum operators.
* Destructors and Goto:: Goto is safe to use in C++ even when destructors
are needed.
* C++ Interface:: You can use a single C++ header file for both
declarations and definitions.
File: gcc.info, Node: Naming Results, Next: Min and Max, Up: C++ Extensions
Named Return Values in C++
==========================
GNU C++ extends the function-definition syntax to allow you to
specify a name for the result of a function outside the body of the
definition, in C++ programs:
TYPE
FUNCTIONNAME (ARGS) return RESULTNAME;
{
...
BODY
...
}
You can use this feature to avoid an extra constructor call when a
function result has a class type. For example, consider a function
`m', declared as `X v = m ();', whose result is of class `X':
X
m ()
{
X b;
b.a = 23;
return b;
}
Although `m' appears to have no arguments, in fact it has one
implicit argument: the address of the return value. At invocation, the
address of enough space to hold `v' is sent in as the implicit argument.
Then `b' is constructed and its `a' field is set to the value 23.
Finally, a copy constructor (a constructor of the form `X(X&)') is
applied to `b', with the (implicit) return value location as the
target, so that `v' is now bound to the return value.
But this is wasteful. The local `b' is declared just to hold
something that will be copied right out. While a com