init: init nachos hw01
This commit is contained in:
AFS_TA
Executable
BIN
Binary file not shown.
BIN
Binary file not shown.
Executable
BIN
Binary file not shown.
Executable
BIN
Binary file not shown.
BIN
Binary file not shown.
Executable
BIN
Binary file not shown.
Executable
BIN
Binary file not shown.
Executable
BIN
Binary file not shown.
Executable
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
Executable
BIN
Binary file not shown.
BIN
Binary file not shown.
Executable
BIN
Binary file not shown.
BIN
Binary file not shown.
Executable
BIN
Binary file not shown.
Executable
BIN
Binary file not shown.
Executable
BIN
Binary file not shown.
Executable
BIN
Binary file not shown.
Executable
BIN
Binary file not shown.
Executable
BIN
Binary file not shown.
BIN
Binary file not shown.
Executable
BIN
Binary file not shown.
@@ -0,0 +1,52 @@
|
||||
OUTPUT_FORMAT("ecoff-littlemips", "ecoff-bigmips",
|
||||
"ecoff-littlemips")
|
||||
SEARCH_DIR(/usr/local/nachos/decstation-ultrix/lib);
|
||||
ENTRY(__start)
|
||||
SECTIONS
|
||||
{
|
||||
. = 0x400000 + SIZEOF_HEADERS;
|
||||
.text : {
|
||||
_ftext = . ;
|
||||
*(.init)
|
||||
eprol = .;
|
||||
*(.text)
|
||||
PROVIDE (__runtime_reloc_start = .);
|
||||
*(.rel.sdata)
|
||||
PROVIDE (__runtime_reloc_stop = .);
|
||||
*(.fini)
|
||||
etext = .;
|
||||
_etext = .;
|
||||
}
|
||||
. = 0x10000000;
|
||||
.rdata : {
|
||||
*(.rdata)
|
||||
}
|
||||
_fdata = ALIGN(16);
|
||||
.data : {
|
||||
*(.data)
|
||||
CONSTRUCTORS
|
||||
}
|
||||
_gp = ALIGN(16) + 0x8000;
|
||||
.lit8 : {
|
||||
*(.lit8)
|
||||
}
|
||||
.lit4 : {
|
||||
*(.lit4)
|
||||
}
|
||||
.sdata : {
|
||||
*(.sdata)
|
||||
}
|
||||
edata = .;
|
||||
_edata = .;
|
||||
_fbss = .;
|
||||
.sbss : {
|
||||
*(.sbss)
|
||||
*(.scommon)
|
||||
}
|
||||
.bss : {
|
||||
*(.bss)
|
||||
*(COMMON)
|
||||
}
|
||||
end = .;
|
||||
_end = .;
|
||||
}
|
||||
@@ -0,0 +1,52 @@
|
||||
OUTPUT_FORMAT("ecoff-littlemips", "ecoff-bigmips",
|
||||
"ecoff-littlemips")
|
||||
SEARCH_DIR(/usr/local/nachos/decstation-ultrix/lib);
|
||||
ENTRY(__start)
|
||||
SECTIONS
|
||||
{
|
||||
. = 0x400000 + SIZEOF_HEADERS;
|
||||
.text : {
|
||||
_ftext = . ;
|
||||
*(.init)
|
||||
eprol = .;
|
||||
*(.text)
|
||||
PROVIDE (__runtime_reloc_start = .);
|
||||
*(.rel.sdata)
|
||||
PROVIDE (__runtime_reloc_stop = .);
|
||||
*(.fini)
|
||||
etext = .;
|
||||
_etext = .;
|
||||
}
|
||||
. = .;
|
||||
.rdata : {
|
||||
*(.rdata)
|
||||
}
|
||||
_fdata = ALIGN(16);
|
||||
.data : {
|
||||
*(.data)
|
||||
CONSTRUCTORS
|
||||
}
|
||||
_gp = ALIGN(16) + 0x8000;
|
||||
.lit8 : {
|
||||
*(.lit8)
|
||||
}
|
||||
.lit4 : {
|
||||
*(.lit4)
|
||||
}
|
||||
.sdata : {
|
||||
*(.sdata)
|
||||
}
|
||||
edata = .;
|
||||
_edata = .;
|
||||
_fbss = .;
|
||||
.sbss : {
|
||||
*(.sbss)
|
||||
*(.scommon)
|
||||
}
|
||||
.bss : {
|
||||
*(.bss)
|
||||
*(COMMON)
|
||||
}
|
||||
end = .;
|
||||
_end = .;
|
||||
}
|
||||
@@ -0,0 +1,52 @@
|
||||
OUTPUT_FORMAT("ecoff-littlemips", "ecoff-bigmips",
|
||||
"ecoff-littlemips")
|
||||
SEARCH_DIR(/usr/local/nachos/decstation-ultrix/lib);
|
||||
ENTRY(__start)
|
||||
SECTIONS
|
||||
{
|
||||
. = 0x400000 + SIZEOF_HEADERS;
|
||||
.text : {
|
||||
_ftext = . ;
|
||||
*(.init)
|
||||
eprol = .;
|
||||
*(.text)
|
||||
PROVIDE (__runtime_reloc_start = .);
|
||||
*(.rel.sdata)
|
||||
PROVIDE (__runtime_reloc_stop = .);
|
||||
*(.fini)
|
||||
etext = .;
|
||||
_etext = .;
|
||||
}
|
||||
. = .;
|
||||
.rdata : {
|
||||
*(.rdata)
|
||||
}
|
||||
_fdata = ALIGN(16);
|
||||
.data : {
|
||||
*(.data)
|
||||
CONSTRUCTORS
|
||||
}
|
||||
_gp = ALIGN(16) + 0x8000;
|
||||
.lit8 : {
|
||||
*(.lit8)
|
||||
}
|
||||
.lit4 : {
|
||||
*(.lit4)
|
||||
}
|
||||
.sdata : {
|
||||
*(.sdata)
|
||||
}
|
||||
edata = .;
|
||||
_edata = .;
|
||||
_fbss = .;
|
||||
.sbss : {
|
||||
*(.sbss)
|
||||
*(.scommon)
|
||||
}
|
||||
.bss : {
|
||||
*(.bss)
|
||||
*(COMMON)
|
||||
}
|
||||
end = .;
|
||||
_end = .;
|
||||
}
|
||||
@@ -0,0 +1,40 @@
|
||||
OUTPUT_FORMAT("ecoff-littlemips", "ecoff-bigmips",
|
||||
"ecoff-littlemips")
|
||||
SEARCH_DIR(/usr/local/nachos/decstation-ultrix/lib);
|
||||
ENTRY(__start)
|
||||
SECTIONS
|
||||
{
|
||||
.text : {
|
||||
;
|
||||
*(.init)
|
||||
;
|
||||
*(.text)
|
||||
*(.rel.sdata)
|
||||
*(.fini)
|
||||
;
|
||||
;
|
||||
}
|
||||
.rdata : {
|
||||
*(.rdata)
|
||||
}
|
||||
.data : {
|
||||
*(.data)
|
||||
}
|
||||
.lit8 : {
|
||||
*(.lit8)
|
||||
}
|
||||
.lit4 : {
|
||||
*(.lit4)
|
||||
}
|
||||
.sdata : {
|
||||
*(.sdata)
|
||||
}
|
||||
.sbss : {
|
||||
*(.sbss)
|
||||
*(.scommon)
|
||||
}
|
||||
.bss : {
|
||||
*(.bss)
|
||||
*(COMMON)
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,41 @@
|
||||
OUTPUT_FORMAT("ecoff-littlemips", "ecoff-bigmips",
|
||||
"ecoff-littlemips")
|
||||
SEARCH_DIR(/usr/local/nachos/decstation-ultrix/lib);
|
||||
ENTRY(__start)
|
||||
SECTIONS
|
||||
{
|
||||
.text : {
|
||||
;
|
||||
*(.init)
|
||||
;
|
||||
*(.text)
|
||||
*(.rel.sdata)
|
||||
*(.fini)
|
||||
;
|
||||
;
|
||||
}
|
||||
.rdata : {
|
||||
*(.rdata)
|
||||
}
|
||||
.data : {
|
||||
*(.data)
|
||||
CONSTRUCTORS
|
||||
}
|
||||
.lit8 : {
|
||||
*(.lit8)
|
||||
}
|
||||
.lit4 : {
|
||||
*(.lit4)
|
||||
}
|
||||
.sdata : {
|
||||
*(.sdata)
|
||||
}
|
||||
.sbss : {
|
||||
*(.sbss)
|
||||
*(.scommon)
|
||||
}
|
||||
.bss : {
|
||||
*(.bss)
|
||||
*(COMMON)
|
||||
}
|
||||
}
|
||||
Executable
+224
@@ -0,0 +1,224 @@
|
||||
/* ANSI and traditional C compatability macros
|
||||
Copyright 1991, 1992, 1996, 1999 Free Software Foundation, Inc.
|
||||
This file is part of the GNU C Library.
|
||||
|
||||
This program is free software; you can redistribute it and/or modify
|
||||
it under the terms of the GNU General Public License as published by
|
||||
the Free Software Foundation; either version 2 of the License, or
|
||||
(at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */
|
||||
|
||||
/* ANSI and traditional C compatibility macros
|
||||
|
||||
ANSI C is assumed if __STDC__ is #defined.
|
||||
|
||||
Macro ANSI C definition Traditional C definition
|
||||
----- ---- - ---------- ----------- - ----------
|
||||
PTR `void *' `char *'
|
||||
LONG_DOUBLE `long double' `double'
|
||||
VOLATILE `volatile' `'
|
||||
SIGNED `signed' `'
|
||||
PTRCONST `void *const' `char *'
|
||||
ANSI_PROTOTYPES 1 not defined
|
||||
|
||||
CONST is also defined, but is obsolete. Just use const.
|
||||
|
||||
obsolete -- DEFUN (name, arglist, args)
|
||||
|
||||
Defines function NAME.
|
||||
|
||||
ARGLIST lists the arguments, separated by commas and enclosed in
|
||||
parentheses. ARGLIST becomes the argument list in traditional C.
|
||||
|
||||
ARGS list the arguments with their types. It becomes a prototype in
|
||||
ANSI C, and the type declarations in traditional C. Arguments should
|
||||
be separated with `AND'. For functions with a variable number of
|
||||
arguments, the last thing listed should be `DOTS'.
|
||||
|
||||
obsolete -- DEFUN_VOID (name)
|
||||
|
||||
Defines a function NAME, which takes no arguments.
|
||||
|
||||
obsolete -- EXFUN (name, (prototype)) -- obsolete.
|
||||
|
||||
Replaced by PARAMS. Do not use; will disappear someday soon.
|
||||
Was used in external function declarations.
|
||||
In ANSI C it is `NAME PROTOTYPE' (so PROTOTYPE should be enclosed in
|
||||
parentheses). In traditional C it is `NAME()'.
|
||||
For a function that takes no arguments, PROTOTYPE should be `(void)'.
|
||||
|
||||
obsolete -- PROTO (type, name, (prototype) -- obsolete.
|
||||
|
||||
This one has also been replaced by PARAMS. Do not use.
|
||||
|
||||
PARAMS ((args))
|
||||
|
||||
We could use the EXFUN macro to handle prototype declarations, but
|
||||
the name is misleading and the result is ugly. So we just define a
|
||||
simple macro to handle the parameter lists, as in:
|
||||
|
||||
static int foo PARAMS ((int, char));
|
||||
|
||||
This produces: `static int foo();' or `static int foo (int, char);'
|
||||
|
||||
EXFUN would have done it like this:
|
||||
|
||||
static int EXFUN (foo, (int, char));
|
||||
|
||||
but the function is not external...and it's hard to visually parse
|
||||
the function name out of the mess. EXFUN should be considered
|
||||
obsolete; new code should be written to use PARAMS.
|
||||
|
||||
DOTS is also obsolete.
|
||||
|
||||
Examples:
|
||||
|
||||
extern int printf PARAMS ((const char *format, ...));
|
||||
*/
|
||||
|
||||
#ifndef _ANSIDECL_H
|
||||
|
||||
#define _ANSIDECL_H 1
|
||||
|
||||
|
||||
/* Every source file includes this file,
|
||||
so they will all get the switch for lint. */
|
||||
/* LINTLIBRARY */
|
||||
|
||||
|
||||
#if defined (__STDC__) || defined (_AIX) || (defined (__mips) && defined (_SYSTYPE_SVR4)) || defined(_WIN32)
|
||||
/* All known AIX compilers implement these things (but don't always
|
||||
define __STDC__). The RISC/OS MIPS compiler defines these things
|
||||
in SVR4 mode, but does not define __STDC__. */
|
||||
|
||||
#define PTR void *
|
||||
#define PTRCONST void *CONST
|
||||
#define LONG_DOUBLE long double
|
||||
|
||||
#ifndef IN_GCC
|
||||
#define AND ,
|
||||
#define NOARGS void
|
||||
#define VOLATILE volatile
|
||||
#define SIGNED signed
|
||||
#endif /* ! IN_GCC */
|
||||
|
||||
#define PARAMS(paramlist) paramlist
|
||||
#define ANSI_PROTOTYPES 1
|
||||
|
||||
#define VPARAMS(ARGS) ARGS
|
||||
#define VA_START(va_list,var) va_start(va_list,var)
|
||||
|
||||
/* These are obsolete. Do not use. */
|
||||
#ifndef IN_GCC
|
||||
#define CONST const
|
||||
#define DOTS , ...
|
||||
#define PROTO(type, name, arglist) type name arglist
|
||||
#define EXFUN(name, proto) name proto
|
||||
#define DEFUN(name, arglist, args) name(args)
|
||||
#define DEFUN_VOID(name) name(void)
|
||||
#endif /* ! IN_GCC */
|
||||
|
||||
#else /* Not ANSI C. */
|
||||
|
||||
#define PTR char *
|
||||
#define PTRCONST PTR
|
||||
#define LONG_DOUBLE double
|
||||
|
||||
#ifndef IN_GCC
|
||||
#define AND ;
|
||||
#define NOARGS
|
||||
#define VOLATILE
|
||||
#define SIGNED
|
||||
#endif /* !IN_GCC */
|
||||
|
||||
#ifndef const /* some systems define it in header files for non-ansi mode */
|
||||
#define const
|
||||
#endif
|
||||
|
||||
#define PARAMS(paramlist) ()
|
||||
|
||||
#define VPARAMS(ARGS) (va_alist) va_dcl
|
||||
#define VA_START(va_list,var) va_start(va_list)
|
||||
|
||||
/* These are obsolete. Do not use. */
|
||||
#ifndef IN_GCC
|
||||
#define CONST
|
||||
#define DOTS
|
||||
#define PROTO(type, name, arglist) type name ()
|
||||
#define EXFUN(name, proto) name()
|
||||
#define DEFUN(name, arglist, args) name arglist args;
|
||||
#define DEFUN_VOID(name) name()
|
||||
#endif /* ! IN_GCC */
|
||||
|
||||
#endif /* ANSI C. */
|
||||
|
||||
/* Using MACRO(x,y) in cpp #if conditionals does not work with some
|
||||
older preprocessors. Thus we can't define something like this:
|
||||
|
||||
#define HAVE_GCC_VERSION(MAJOR, MINOR) \
|
||||
(__GNUC__ > (MAJOR) || (__GNUC__ == (MAJOR) && __GNUC_MINOR__ >= (MINOR)))
|
||||
|
||||
and then test "#if HAVE_GCC_VERSION(2,7)".
|
||||
|
||||
So instead we use the macro below and test it against specific values. */
|
||||
|
||||
/* This macro simplifies testing whether we are using gcc, and if it
|
||||
is of a particular minimum version. (Both major & minor numbers are
|
||||
significant.) This macro will evaluate to 0 if we are not using
|
||||
gcc at all. */
|
||||
#ifndef GCC_VERSION
|
||||
#define GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__)
|
||||
#endif /* GCC_VERSION */
|
||||
|
||||
/* Define macros for some gcc attributes. This permits us to use the
|
||||
macros freely, and know that they will come into play for the
|
||||
version of gcc in which they are supported. */
|
||||
|
||||
#if (GCC_VERSION < 2007)
|
||||
# define __attribute__(x)
|
||||
#endif
|
||||
|
||||
/* Attribute __malloc__ on functions was valid as of gcc 2.96. */
|
||||
#ifndef ATTRIBUTE_MALLOC
|
||||
# if (GCC_VERSION >= 2096)
|
||||
# define ATTRIBUTE_MALLOC __attribute__ ((__malloc__))
|
||||
# else
|
||||
# define ATTRIBUTE_MALLOC
|
||||
# endif /* GNUC >= 2.96 */
|
||||
#endif /* ATTRIBUTE_MALLOC */
|
||||
|
||||
/* Attributes on labels were valid as of gcc 2.93. */
|
||||
#ifndef ATTRIBUTE_UNUSED_LABEL
|
||||
# if (GCC_VERSION >= 2093)
|
||||
# define ATTRIBUTE_UNUSED_LABEL ATTRIBUTE_UNUSED
|
||||
# else
|
||||
# define ATTRIBUTE_UNUSED_LABEL
|
||||
# endif /* GNUC >= 2.93 */
|
||||
#endif /* ATTRIBUTE_UNUSED_LABEL */
|
||||
|
||||
#ifndef ATTRIBUTE_UNUSED
|
||||
#define ATTRIBUTE_UNUSED __attribute__ ((__unused__))
|
||||
#endif /* ATTRIBUTE_UNUSED */
|
||||
|
||||
#ifndef ATTRIBUTE_NORETURN
|
||||
#define ATTRIBUTE_NORETURN __attribute__ ((__noreturn__))
|
||||
#endif /* ATTRIBUTE_NORETURN */
|
||||
|
||||
#ifndef ATTRIBUTE_PRINTF
|
||||
#define ATTRIBUTE_PRINTF(m, n) __attribute__ ((__format__ (__printf__, m, n)))
|
||||
#define ATTRIBUTE_PRINTF_1 ATTRIBUTE_PRINTF(1, 2)
|
||||
#define ATTRIBUTE_PRINTF_2 ATTRIBUTE_PRINTF(2, 3)
|
||||
#define ATTRIBUTE_PRINTF_3 ATTRIBUTE_PRINTF(3, 4)
|
||||
#define ATTRIBUTE_PRINTF_4 ATTRIBUTE_PRINTF(4, 5)
|
||||
#define ATTRIBUTE_PRINTF_5 ATTRIBUTE_PRINTF(5, 6)
|
||||
#endif /* ATTRIBUTE_PRINTF */
|
||||
|
||||
#endif /* ansidecl.h */
|
||||
Executable
+3231
File diff suppressed because it is too large
Load Diff
Executable
+530
@@ -0,0 +1,530 @@
|
||||
/* bfdlink.h -- header file for BFD link routines
|
||||
Copyright 1993, 94, 95, 96, 97, 1999 Free Software Foundation, Inc.
|
||||
Written by Steve Chamberlain and Ian Lance Taylor, Cygnus Support.
|
||||
|
||||
This file is part of BFD, the Binary File Descriptor library.
|
||||
|
||||
This program is free software; you can redistribute it and/or modify
|
||||
it under the terms of the GNU General Public License as published by
|
||||
the Free Software Foundation; either version 2 of the License, or
|
||||
(at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */
|
||||
|
||||
#ifndef BFDLINK_H
|
||||
#define BFDLINK_H
|
||||
|
||||
/* Which symbols to strip during a link. */
|
||||
enum bfd_link_strip
|
||||
{
|
||||
strip_none, /* Don't strip any symbols. */
|
||||
strip_debugger, /* Strip debugging symbols. */
|
||||
strip_some, /* keep_hash is the list of symbols to keep. */
|
||||
strip_all /* Strip all symbols. */
|
||||
};
|
||||
|
||||
/* Which local symbols to discard during a link. This is irrelevant
|
||||
if strip_all is used. */
|
||||
enum bfd_link_discard
|
||||
{
|
||||
discard_none, /* Don't discard any locals. */
|
||||
discard_l, /* Discard local temporary symbols. */
|
||||
discard_all /* Discard all locals. */
|
||||
};
|
||||
|
||||
/* These are the possible types of an entry in the BFD link hash
|
||||
table. */
|
||||
|
||||
enum bfd_link_hash_type
|
||||
{
|
||||
bfd_link_hash_new, /* Symbol is new. */
|
||||
bfd_link_hash_undefined, /* Symbol seen before, but undefined. */
|
||||
bfd_link_hash_undefweak, /* Symbol is weak and undefined. */
|
||||
bfd_link_hash_defined, /* Symbol is defined. */
|
||||
bfd_link_hash_defweak, /* Symbol is weak and defined. */
|
||||
bfd_link_hash_common, /* Symbol is common. */
|
||||
bfd_link_hash_indirect, /* Symbol is an indirect link. */
|
||||
bfd_link_hash_warning /* Like indirect, but warn if referenced. */
|
||||
};
|
||||
|
||||
/* The linking routines use a hash table which uses this structure for
|
||||
its elements. */
|
||||
|
||||
struct bfd_link_hash_entry
|
||||
{
|
||||
/* Base hash table entry structure. */
|
||||
struct bfd_hash_entry root;
|
||||
/* Type of this entry. */
|
||||
enum bfd_link_hash_type type;
|
||||
|
||||
/* Undefined and common symbols are kept in a linked list through
|
||||
this field. This field is not in the union because that would
|
||||
force us to remove entries from the list when we changed their
|
||||
type, which would force the list to be doubly linked, which would
|
||||
waste more memory. When an undefined or common symbol is
|
||||
created, it should be added to this list, the head of which is in
|
||||
the link hash table itself. As symbols are defined, they need
|
||||
not be removed from the list; anything which reads the list must
|
||||
doublecheck the symbol type.
|
||||
|
||||
Weak symbols are not kept on this list.
|
||||
|
||||
Defined and defweak symbols use this field as a reference marker.
|
||||
If the field is not NULL, or this structure is the tail of the
|
||||
undefined symbol list, the symbol has been referenced. If the
|
||||
symbol is undefined and becomes defined, this field will
|
||||
automatically be non-NULL since the symbol will have been on the
|
||||
undefined symbol list. */
|
||||
struct bfd_link_hash_entry *next;
|
||||
/* A union of information depending upon the type. */
|
||||
union
|
||||
{
|
||||
/* Nothing is kept for bfd_hash_new. */
|
||||
/* bfd_link_hash_undefined, bfd_link_hash_undefweak. */
|
||||
struct
|
||||
{
|
||||
bfd *abfd; /* BFD symbol was found in. */
|
||||
} undef;
|
||||
/* bfd_link_hash_defined, bfd_link_hash_defweak. */
|
||||
struct
|
||||
{
|
||||
bfd_vma value; /* Symbol value. */
|
||||
asection *section; /* Symbol section. */
|
||||
} def;
|
||||
/* bfd_link_hash_indirect, bfd_link_hash_warning. */
|
||||
struct
|
||||
{
|
||||
struct bfd_link_hash_entry *link; /* Real symbol. */
|
||||
const char *warning; /* Warning (bfd_link_hash_warning only). */
|
||||
} i;
|
||||
/* bfd_link_hash_common. */
|
||||
struct
|
||||
{
|
||||
/* The linker needs to know three things about common
|
||||
symbols: the size, the alignment, and the section in
|
||||
which the symbol should be placed. We store the size
|
||||
here, and we allocate a small structure to hold the
|
||||
section and the alignment. The alignment is stored as a
|
||||
power of two. We don't store all the information
|
||||
directly because we don't want to increase the size of
|
||||
the union; this structure is a major space user in the
|
||||
linker. */
|
||||
bfd_size_type size; /* Common symbol size. */
|
||||
struct bfd_link_hash_common_entry
|
||||
{
|
||||
unsigned int alignment_power; /* Alignment. */
|
||||
asection *section; /* Symbol section. */
|
||||
} *p;
|
||||
} c;
|
||||
} u;
|
||||
};
|
||||
|
||||
/* This is the link hash table. It is a derived class of
|
||||
bfd_hash_table. */
|
||||
|
||||
struct bfd_link_hash_table
|
||||
{
|
||||
/* The hash table itself. */
|
||||
struct bfd_hash_table table;
|
||||
/* The back end which created this hash table. This indicates the
|
||||
type of the entries in the hash table, which is sometimes
|
||||
important information when linking object files of different
|
||||
types together. */
|
||||
const bfd_target *creator;
|
||||
/* A linked list of undefined and common symbols, linked through the
|
||||
next field in the bfd_link_hash_entry structure. */
|
||||
struct bfd_link_hash_entry *undefs;
|
||||
/* Entries are added to the tail of the undefs list. */
|
||||
struct bfd_link_hash_entry *undefs_tail;
|
||||
};
|
||||
|
||||
/* Look up an entry in a link hash table. If FOLLOW is true, this
|
||||
follows bfd_link_hash_indirect and bfd_link_hash_warning links to
|
||||
the real symbol. */
|
||||
extern struct bfd_link_hash_entry *bfd_link_hash_lookup
|
||||
PARAMS ((struct bfd_link_hash_table *, const char *, boolean create,
|
||||
boolean copy, boolean follow));
|
||||
|
||||
/* Look up an entry in the main linker hash table if the symbol might
|
||||
be wrapped. This should only be used for references to an
|
||||
undefined symbol, not for definitions of a symbol. */
|
||||
|
||||
extern struct bfd_link_hash_entry *bfd_wrapped_link_hash_lookup
|
||||
PARAMS ((bfd *, struct bfd_link_info *, const char *, boolean, boolean,
|
||||
boolean));
|
||||
|
||||
/* Traverse a link hash table. */
|
||||
extern void bfd_link_hash_traverse
|
||||
PARAMS ((struct bfd_link_hash_table *,
|
||||
boolean (*) (struct bfd_link_hash_entry *, PTR),
|
||||
PTR));
|
||||
|
||||
/* Add an entry to the undefs list. */
|
||||
extern void bfd_link_add_undef
|
||||
PARAMS ((struct bfd_link_hash_table *, struct bfd_link_hash_entry *));
|
||||
|
||||
/* This structure holds all the information needed to communicate
|
||||
between BFD and the linker when doing a link. */
|
||||
|
||||
struct bfd_link_info
|
||||
{
|
||||
/* Function callbacks. */
|
||||
const struct bfd_link_callbacks *callbacks;
|
||||
/* true if BFD should generate a relocateable object file. */
|
||||
boolean relocateable;
|
||||
/* true if BFD should generate a "task linked" object file,
|
||||
similar to relocatable but also with globals converted to statics. */
|
||||
boolean task_link;
|
||||
/* true if BFD should generate a shared object. */
|
||||
boolean shared;
|
||||
/* true if BFD should pre-bind symbols in a shared object. */
|
||||
boolean symbolic;
|
||||
/* true if shared objects should be linked directly, not shared. */
|
||||
boolean static_link;
|
||||
/* true if the output file should be in a traditional format. This
|
||||
is equivalent to the setting of the BFD_TRADITIONAL_FORMAT flag
|
||||
on the output file, but may be checked when reading the input
|
||||
files. */
|
||||
boolean traditional_format;
|
||||
/* true if we want to produced optimized output files. This might
|
||||
need much more time and therefore must be explicitly selected. */
|
||||
boolean optimize;
|
||||
/* true if BFD should generate errors for undefined symbols
|
||||
even if generating a shared object. */
|
||||
boolean no_undefined;
|
||||
/* Which symbols to strip. */
|
||||
enum bfd_link_strip strip;
|
||||
/* Which local symbols to discard. */
|
||||
enum bfd_link_discard discard;
|
||||
/* true if symbols should be retained in memory, false if they
|
||||
should be freed and reread. */
|
||||
boolean keep_memory;
|
||||
/* The list of input BFD's involved in the link. These are chained
|
||||
together via the link_next field. */
|
||||
bfd *input_bfds;
|
||||
/* If a symbol should be created for each input BFD, this is section
|
||||
where those symbols should be placed. It must be a section in
|
||||
the output BFD. It may be NULL, in which case no such symbols
|
||||
will be created. This is to support CREATE_OBJECT_SYMBOLS in the
|
||||
linker command language. */
|
||||
asection *create_object_symbols_section;
|
||||
/* Hash table handled by BFD. */
|
||||
struct bfd_link_hash_table *hash;
|
||||
/* Hash table of symbols to keep. This is NULL unless strip is
|
||||
strip_some. */
|
||||
struct bfd_hash_table *keep_hash;
|
||||
/* true if every symbol should be reported back via the notice
|
||||
callback. */
|
||||
boolean notice_all;
|
||||
/* Hash table of symbols to report back via the notice callback. If
|
||||
this is NULL, and notice_all is false, then no symbols are
|
||||
reported back. */
|
||||
struct bfd_hash_table *notice_hash;
|
||||
/* Hash table of symbols which are being wrapped (the --wrap linker
|
||||
option). If this is NULL, no symbols are being wrapped. */
|
||||
struct bfd_hash_table *wrap_hash;
|
||||
/* If a base output file is wanted, then this points to it */
|
||||
PTR base_file;
|
||||
|
||||
/* If non-zero, specifies that branches which are problematic for the
|
||||
MPC860 C0 (or earlier) should be checked for and modified. It gives the
|
||||
number of bytes that should be checked at the end of each text page. */
|
||||
int mpc860c0;
|
||||
|
||||
/* The function to call when the executable or shared object is
|
||||
loaded. */
|
||||
const char *init_function;
|
||||
/* The function to call when the executable or shared object is
|
||||
unloaded. */
|
||||
const char *fini_function;
|
||||
};
|
||||
|
||||
/* This structures holds a set of callback functions. These are
|
||||
called by the BFD linker routines. The first argument to each
|
||||
callback function is the bfd_link_info structure being used. Each
|
||||
function returns a boolean value. If the function returns false,
|
||||
then the BFD function which called it will return with a failure
|
||||
indication. */
|
||||
|
||||
struct bfd_link_callbacks
|
||||
{
|
||||
/* A function which is called when an object is added from an
|
||||
archive. ABFD is the archive element being added. NAME is the
|
||||
name of the symbol which caused the archive element to be pulled
|
||||
in. */
|
||||
boolean (*add_archive_element) PARAMS ((struct bfd_link_info *,
|
||||
bfd *abfd,
|
||||
const char *name));
|
||||
/* A function which is called when a symbol is found with multiple
|
||||
definitions. NAME is the symbol which is defined multiple times.
|
||||
OBFD is the old BFD, OSEC is the old section, OVAL is the old
|
||||
value, NBFD is the new BFD, NSEC is the new section, and NVAL is
|
||||
the new value. OBFD may be NULL. OSEC and NSEC may be
|
||||
bfd_com_section or bfd_ind_section. */
|
||||
boolean (*multiple_definition) PARAMS ((struct bfd_link_info *,
|
||||
const char *name,
|
||||
bfd *obfd,
|
||||
asection *osec,
|
||||
bfd_vma oval,
|
||||
bfd *nbfd,
|
||||
asection *nsec,
|
||||
bfd_vma nval));
|
||||
/* A function which is called when a common symbol is defined
|
||||
multiple times. NAME is the symbol appearing multiple times.
|
||||
OBFD is the BFD of the existing symbol; it may be NULL if this is
|
||||
not known. OTYPE is the type of the existing symbol, which may
|
||||
be bfd_link_hash_defined, bfd_link_hash_defweak,
|
||||
bfd_link_hash_common, or bfd_link_hash_indirect. If OTYPE is
|
||||
bfd_link_hash_common, OSIZE is the size of the existing symbol.
|
||||
NBFD is the BFD of the new symbol. NTYPE is the type of the new
|
||||
symbol, one of bfd_link_hash_defined, bfd_link_hash_common, or
|
||||
bfd_link_hash_indirect. If NTYPE is bfd_link_hash_common, NSIZE
|
||||
is the size of the new symbol. */
|
||||
boolean (*multiple_common) PARAMS ((struct bfd_link_info *,
|
||||
const char *name,
|
||||
bfd *obfd,
|
||||
enum bfd_link_hash_type otype,
|
||||
bfd_vma osize,
|
||||
bfd *nbfd,
|
||||
enum bfd_link_hash_type ntype,
|
||||
bfd_vma nsize));
|
||||
/* A function which is called to add a symbol to a set. ENTRY is
|
||||
the link hash table entry for the set itself (e.g.,
|
||||
__CTOR_LIST__). RELOC is the relocation to use for an entry in
|
||||
the set when generating a relocateable file, and is also used to
|
||||
get the size of the entry when generating an executable file.
|
||||
ABFD, SEC and VALUE identify the value to add to the set. */
|
||||
boolean (*add_to_set) PARAMS ((struct bfd_link_info *,
|
||||
struct bfd_link_hash_entry *entry,
|
||||
bfd_reloc_code_real_type reloc,
|
||||
bfd *abfd, asection *sec, bfd_vma value));
|
||||
/* A function which is called when the name of a g++ constructor or
|
||||
destructor is found. This is only called by some object file
|
||||
formats. CONSTRUCTOR is true for a constructor, false for a
|
||||
destructor. This will use BFD_RELOC_CTOR when generating a
|
||||
relocateable file. NAME is the name of the symbol found. ABFD,
|
||||
SECTION and VALUE are the value of the symbol. */
|
||||
boolean (*constructor) PARAMS ((struct bfd_link_info *,
|
||||
boolean constructor,
|
||||
const char *name, bfd *abfd, asection *sec,
|
||||
bfd_vma value));
|
||||
/* A function which is called to issue a linker warning. For
|
||||
example, this is called when there is a reference to a warning
|
||||
symbol. WARNING is the warning to be issued. SYMBOL is the name
|
||||
of the symbol which triggered the warning; it may be NULL if
|
||||
there is none. ABFD, SECTION and ADDRESS identify the location
|
||||
which trigerred the warning; either ABFD or SECTION or both may
|
||||
be NULL if the location is not known. */
|
||||
boolean (*warning) PARAMS ((struct bfd_link_info *,
|
||||
const char *warning, const char *symbol,
|
||||
bfd *abfd, asection *section,
|
||||
bfd_vma address));
|
||||
/* A function which is called when a relocation is attempted against
|
||||
an undefined symbol. NAME is the symbol which is undefined.
|
||||
ABFD, SECTION and ADDRESS identify the location from which the
|
||||
reference is made. FATAL indicates whether an undefined symbol is
|
||||
a fatal error or not. In some cases SECTION may be NULL. */
|
||||
boolean (*undefined_symbol) PARAMS ((struct bfd_link_info *,
|
||||
const char *name, bfd *abfd,
|
||||
asection *section,
|
||||
bfd_vma address,
|
||||
boolean fatal));
|
||||
/* A function which is called when a reloc overflow occurs. NAME is
|
||||
the name of the symbol or section the reloc is against,
|
||||
RELOC_NAME is the name of the relocation, and ADDEND is any
|
||||
addend that is used. ABFD, SECTION and ADDRESS identify the
|
||||
location at which the overflow occurs; if this is the result of a
|
||||
bfd_section_reloc_link_order or bfd_symbol_reloc_link_order, then
|
||||
ABFD will be NULL. */
|
||||
boolean (*reloc_overflow) PARAMS ((struct bfd_link_info *,
|
||||
const char *name,
|
||||
const char *reloc_name, bfd_vma addend,
|
||||
bfd *abfd, asection *section,
|
||||
bfd_vma address));
|
||||
/* A function which is called when a dangerous reloc is performed.
|
||||
The canonical example is an a29k IHCONST reloc which does not
|
||||
follow an IHIHALF reloc. MESSAGE is an appropriate message.
|
||||
ABFD, SECTION and ADDRESS identify the location at which the
|
||||
problem occurred; if this is the result of a
|
||||
bfd_section_reloc_link_order or bfd_symbol_reloc_link_order, then
|
||||
ABFD will be NULL. */
|
||||
boolean (*reloc_dangerous) PARAMS ((struct bfd_link_info *,
|
||||
const char *message,
|
||||
bfd *abfd, asection *section,
|
||||
bfd_vma address));
|
||||
/* A function which is called when a reloc is found to be attached
|
||||
to a symbol which is not being written out. NAME is the name of
|
||||
the symbol. ABFD, SECTION and ADDRESS identify the location of
|
||||
the reloc; if this is the result of a
|
||||
bfd_section_reloc_link_order or bfd_symbol_reloc_link_order, then
|
||||
ABFD will be NULL. */
|
||||
boolean (*unattached_reloc) PARAMS ((struct bfd_link_info *,
|
||||
const char *name,
|
||||
bfd *abfd, asection *section,
|
||||
bfd_vma address));
|
||||
/* A function which is called when a symbol in notice_hash is
|
||||
defined or referenced. NAME is the symbol. ABFD, SECTION and
|
||||
ADDRESS are the value of the symbol. If SECTION is
|
||||
bfd_und_section, this is a reference. */
|
||||
boolean (*notice) PARAMS ((struct bfd_link_info *, const char *name,
|
||||
bfd *abfd, asection *section, bfd_vma address));
|
||||
};
|
||||
|
||||
/* The linker builds link_order structures which tell the code how to
|
||||
include input data in the output file. */
|
||||
|
||||
/* These are the types of link_order structures. */
|
||||
|
||||
enum bfd_link_order_type
|
||||
{
|
||||
bfd_undefined_link_order, /* Undefined. */
|
||||
bfd_indirect_link_order, /* Built from a section. */
|
||||
bfd_fill_link_order, /* Fill with a 16 bit constant. */
|
||||
bfd_data_link_order, /* Set to explicit data. */
|
||||
bfd_section_reloc_link_order, /* Relocate against a section. */
|
||||
bfd_symbol_reloc_link_order /* Relocate against a symbol. */
|
||||
};
|
||||
|
||||
/* This is the link_order structure itself. These form a chain
|
||||
attached to the section whose contents they are describing. */
|
||||
|
||||
struct bfd_link_order
|
||||
{
|
||||
/* Next link_order in chain. */
|
||||
struct bfd_link_order *next;
|
||||
/* Type of link_order. */
|
||||
enum bfd_link_order_type type;
|
||||
/* Offset within output section. */
|
||||
bfd_vma offset;
|
||||
/* Size within output section. */
|
||||
bfd_size_type size;
|
||||
/* Type specific information. */
|
||||
union
|
||||
{
|
||||
struct
|
||||
{
|
||||
/* Section to include. If this is used, then
|
||||
section->output_section must be the section the
|
||||
link_order is attached to, section->output_offset must
|
||||
equal the link_order offset field, and section->_raw_size
|
||||
must equal the link_order size field. Maybe these
|
||||
restrictions should be relaxed someday. */
|
||||
asection *section;
|
||||
} indirect;
|
||||
struct
|
||||
{
|
||||
/* Value to fill with. */
|
||||
unsigned int value;
|
||||
} fill;
|
||||
struct
|
||||
{
|
||||
/* Data to put into file. The size field gives the number
|
||||
of bytes which this field points to. */
|
||||
bfd_byte *contents;
|
||||
} data;
|
||||
struct
|
||||
{
|
||||
/* Description of reloc to generate. Used for
|
||||
bfd_section_reloc_link_order and
|
||||
bfd_symbol_reloc_link_order. */
|
||||
struct bfd_link_order_reloc *p;
|
||||
} reloc;
|
||||
} u;
|
||||
};
|
||||
|
||||
/* A linker order of type bfd_section_reloc_link_order or
|
||||
bfd_symbol_reloc_link_order means to create a reloc against a
|
||||
section or symbol, respectively. This is used to implement -Ur to
|
||||
generate relocs for the constructor tables. The
|
||||
bfd_link_order_reloc structure describes the reloc that BFD should
|
||||
create. It is similar to a arelent, but I didn't use arelent
|
||||
because the linker does not know anything about most symbols, and
|
||||
any asymbol structure it creates will be partially meaningless.
|
||||
This information could logically be in the bfd_link_order struct,
|
||||
but I didn't want to waste the space since these types of relocs
|
||||
are relatively rare. */
|
||||
|
||||
struct bfd_link_order_reloc
|
||||
{
|
||||
/* Reloc type. */
|
||||
bfd_reloc_code_real_type reloc;
|
||||
|
||||
union
|
||||
{
|
||||
/* For type bfd_section_reloc_link_order, this is the section
|
||||
the reloc should be against. This must be a section in the
|
||||
output BFD, not any of the input BFDs. */
|
||||
asection *section;
|
||||
/* For type bfd_symbol_reloc_link_order, this is the name of the
|
||||
symbol the reloc should be against. */
|
||||
const char *name;
|
||||
} u;
|
||||
|
||||
/* Addend to use. The object file should contain zero. The BFD
|
||||
backend is responsible for filling in the contents of the object
|
||||
file correctly. For some object file formats (e.g., COFF) the
|
||||
addend must be stored into in the object file, and for some
|
||||
(e.g., SPARC a.out) it is kept in the reloc. */
|
||||
bfd_vma addend;
|
||||
};
|
||||
|
||||
/* Allocate a new link_order for a section. */
|
||||
extern struct bfd_link_order *bfd_new_link_order PARAMS ((bfd *, asection *));
|
||||
|
||||
/* These structures are used to describe version information for the
|
||||
ELF linker. These structures could be manipulated entirely inside
|
||||
BFD, but it would be a pain. Instead, the regular linker sets up
|
||||
these structures, and then passes them into BFD. */
|
||||
|
||||
/* Regular expressions for a version. */
|
||||
|
||||
struct bfd_elf_version_expr
|
||||
{
|
||||
/* Next regular expression for this version. */
|
||||
struct bfd_elf_version_expr *next;
|
||||
/* Regular expression. */
|
||||
const char *pattern;
|
||||
/* Matching function. */
|
||||
int (*match) PARAMS((struct bfd_elf_version_expr *, const char *));
|
||||
};
|
||||
|
||||
/* Version dependencies. */
|
||||
|
||||
struct bfd_elf_version_deps
|
||||
{
|
||||
/* Next dependency for this version. */
|
||||
struct bfd_elf_version_deps *next;
|
||||
/* The version which this version depends upon. */
|
||||
struct bfd_elf_version_tree *version_needed;
|
||||
};
|
||||
|
||||
/* A node in the version tree. */
|
||||
|
||||
struct bfd_elf_version_tree
|
||||
{
|
||||
/* Next version. */
|
||||
struct bfd_elf_version_tree *next;
|
||||
/* Name of this version. */
|
||||
const char *name;
|
||||
/* Version number. */
|
||||
unsigned int vernum;
|
||||
/* Regular expressions for global symbols in this version. */
|
||||
struct bfd_elf_version_expr *globals;
|
||||
/* Regular expressions for local symbols in this version. */
|
||||
struct bfd_elf_version_expr *locals;
|
||||
/* List of versions which this version depends upon. */
|
||||
struct bfd_elf_version_deps *deps;
|
||||
/* Index of the version name. This is used within BFD. */
|
||||
unsigned int name_indx;
|
||||
/* Whether this version tree was used. This is used within BFD. */
|
||||
int used;
|
||||
};
|
||||
|
||||
#endif
|
||||
Executable
+80
@@ -0,0 +1,80 @@
|
||||
This is Info file cpp.info, produced by Makeinfo version 1.68 from the
|
||||
input file ../../gcc-2.95.2/gcc/cpp.texi.
|
||||
|
||||
INFO-DIR-SECTION Programming
|
||||
START-INFO-DIR-ENTRY
|
||||
* Cpp: (cpp). The GNU C preprocessor.
|
||||
END-INFO-DIR-ENTRY
|
||||
|
||||
This file documents the GNU C Preprocessor.
|
||||
|
||||
Copyright 1987, 1989, 1991, 1992, 1993, 1994, 1995, 1997, 1998 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 entire resulting derived work is distributed under the terms
|
||||
of a permission notice identical to this one.
|
||||
|
||||
Permission is granted to copy and distribute translations of this
|
||||
manual into another language, under the above conditions for modified
|
||||
versions.
|
||||
|
||||
|
||||
Indirect:
|
||||
cpp.info-1: 947
|
||||
cpp.info-2: 50078
|
||||
cpp.info-3: 91263
|
||||
|
||||
Tag Table:
|
||||
(Indirect)
|
||||
Node: Top947
|
||||
Node: Global Actions3856
|
||||
Node: Directives6376
|
||||
Node: Header Files8063
|
||||
Node: Header Uses8722
|
||||
Node: Include Syntax10214
|
||||
Node: Include Operation13356
|
||||
Node: Once-Only15218
|
||||
Node: Inheritance17643
|
||||
Node: Macros20176
|
||||
Node: Simple Macros21090
|
||||
Node: Argument Macros24078
|
||||
Node: Predefined29876
|
||||
Node: Standard Predefined30306
|
||||
Node: Nonstandard Predefined37964
|
||||
Node: Stringification41540
|
||||
Node: Concatenation44466
|
||||
Node: Undefining47739
|
||||
Node: Redefining48778
|
||||
Node: Macro Pitfalls50078
|
||||
Node: Misnesting51182
|
||||
Node: Macro Parentheses52196
|
||||
Node: Swallow Semicolon54064
|
||||
Node: Side Effects55962
|
||||
Node: Self-Reference57660
|
||||
Node: Argument Prescan59936
|
||||
Node: Cascaded Macros64938
|
||||
Node: Newlines in Args66083
|
||||
Node: Conditionals67428
|
||||
Node: Conditional Uses68780
|
||||
Node: Conditional Syntax70203
|
||||
Node: #if Directive70789
|
||||
Node: #else Directive73078
|
||||
Node: #elif Directive73745
|
||||
Node: Deleted Code75123
|
||||
Node: Conditionals-Macros76184
|
||||
Node: Assertions79869
|
||||
Node: #error Directive84104
|
||||
Node: Combining Sources85589
|
||||
Node: Other Directives88500
|
||||
Node: Output89954
|
||||
Node: Invocation91263
|
||||
Node: Concept Index106047
|
||||
Node: Index109059
|
||||
|
||||
End Tag Table
|
||||
Executable
+1186
File diff suppressed because it is too large
Load Diff
Executable
+1063
File diff suppressed because it is too large
Load Diff
Executable
+558
@@ -0,0 +1,558 @@
|
||||
This is Info file cpp.info, produced by Makeinfo version 1.68 from the
|
||||
input file ../../gcc-2.95.2/gcc/cpp.texi.
|
||||
|
||||
INFO-DIR-SECTION Programming
|
||||
START-INFO-DIR-ENTRY
|
||||
* Cpp: (cpp). The GNU C preprocessor.
|
||||
END-INFO-DIR-ENTRY
|
||||
|
||||
This file documents the GNU C Preprocessor.
|
||||
|
||||
Copyright 1987, 1989, 1991, 1992, 1993, 1994, 1995, 1997, 1998 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 entire resulting derived work is distributed under the terms
|
||||
of a permission notice identical to this one.
|
||||
|
||||
Permission is granted to copy and distribute translations of this
|
||||
manual into another language, under the above conditions for modified
|
||||
versions.
|
||||
|
||||
|
||||
File: cpp.info, Node: Invocation, Next: Concept Index, Prev: Output, Up: Top
|
||||
|
||||
Invoking the C Preprocessor
|
||||
===========================
|
||||
|
||||
Most often when you use the C preprocessor you will not have to
|
||||
invoke it explicitly: the C compiler will do so automatically.
|
||||
However, the preprocessor is sometimes useful on its own.
|
||||
|
||||
The C preprocessor expects two file names as arguments, INFILE and
|
||||
OUTFILE. The preprocessor reads INFILE together with any other files
|
||||
it specifies with `#include'. All the output generated by the combined
|
||||
input files is written in OUTFILE.
|
||||
|
||||
Either INFILE or OUTFILE may be `-', which as INFILE means to read
|
||||
from standard input and as OUTFILE means to write to standard output.
|
||||
Also, if OUTFILE or both file names are omitted, the standard output
|
||||
and standard input are used for the omitted file names.
|
||||
|
||||
Here is a table of command options accepted by the C preprocessor.
|
||||
These options can also be given when compiling a C program; they are
|
||||
passed along automatically to the preprocessor when it is invoked by the
|
||||
compiler.
|
||||
|
||||
`-P'
|
||||
Inhibit generation of `#'-lines with line-number information in
|
||||
the output from the preprocessor (*note Output::.). This might be
|
||||
useful when running the preprocessor on something that is not C
|
||||
code and will be sent to a program which might be confused by the
|
||||
`#'-lines.
|
||||
|
||||
`-C'
|
||||
Do not discard comments: pass them through to the output file.
|
||||
Comments appearing in arguments of a macro call will be copied to
|
||||
the output before the expansion of the macro call.
|
||||
|
||||
`-traditional'
|
||||
Try to imitate the behavior of old-fashioned C, as opposed to ANSI
|
||||
C.
|
||||
|
||||
* Traditional macro expansion pays no attention to singlequote
|
||||
or doublequote characters; macro argument symbols are
|
||||
replaced by the argument values even when they appear within
|
||||
apparent string or character constants.
|
||||
|
||||
* Traditionally, it is permissible for a macro expansion to end
|
||||
in the middle of a string or character constant. The
|
||||
constant continues into the text surrounding the macro call.
|
||||
|
||||
* However, traditionally the end of the line terminates a
|
||||
string or character constant, with no error.
|
||||
|
||||
* In traditional C, a comment is equivalent to no text at all.
|
||||
(In ANSI C, a comment counts as whitespace.)
|
||||
|
||||
* Traditional C does not have the concept of a "preprocessing
|
||||
number". It considers `1.0e+4' to be three tokens: `1.0e',
|
||||
`+', and `4'.
|
||||
|
||||
* A macro is not suppressed within its own definition, in
|
||||
traditional C. Thus, any macro that is used recursively
|
||||
inevitably causes an error.
|
||||
|
||||
* The character `#' has no special meaning within a macro
|
||||
definition in traditional C.
|
||||
|
||||
* In traditional C, the text at the end of a macro expansion
|
||||
can run together with the text after the macro call, to
|
||||
produce a single token. (This is impossible in ANSI C.)
|
||||
|
||||
* Traditionally, `\' inside a macro argument suppresses the
|
||||
syntactic significance of the following character.
|
||||
|
||||
Use the `-traditional' option when preprocessing Fortran code, so
|
||||
that singlequotes and doublequotes within Fortran comment lines
|
||||
(which are generally not recognized as such by the preprocessor)
|
||||
do not cause diagnostics about unterminated character or string
|
||||
constants.
|
||||
|
||||
However, this option does not prevent diagnostics about
|
||||
unterminated comments when a C-style comment appears to start, but
|
||||
not end, within Fortran-style commentary.
|
||||
|
||||
So, the following Fortran comment lines are accepted with
|
||||
`-traditional':
|
||||
|
||||
C This isn't an unterminated character constant
|
||||
C Neither is "20000000000, an octal constant
|
||||
C in some dialects of Fortran
|
||||
|
||||
However, this type of comment line will likely produce a
|
||||
diagnostic, or at least unexpected output from the preprocessor,
|
||||
due to the unterminated comment:
|
||||
|
||||
C Some Fortran compilers accept /* as starting
|
||||
C an inline comment.
|
||||
|
||||
Note that `g77' automatically supplies the `-traditional' option
|
||||
when it invokes the preprocessor. However, a future version of
|
||||
`g77' might use a different, more-Fortran-aware preprocessor in
|
||||
place of `cpp'.
|
||||
|
||||
`-trigraphs'
|
||||
Process ANSI standard trigraph sequences. These are
|
||||
three-character sequences, all starting with `??', that are
|
||||
defined by ANSI C to stand for single characters. For example,
|
||||
`??/' stands for `\', so `'??/n'' is a character constant for a
|
||||
newline. Strictly speaking, the GNU C preprocessor does not
|
||||
support all programs in ANSI Standard C unless `-trigraphs' is
|
||||
used, but if you ever notice the difference it will be with relief.
|
||||
|
||||
You don't want to know any more about trigraphs.
|
||||
|
||||
`-pedantic'
|
||||
Issue warnings required by the ANSI C standard in certain cases
|
||||
such as when text other than a comment follows `#else' or `#endif'.
|
||||
|
||||
`-pedantic-errors'
|
||||
Like `-pedantic', except that errors are produced rather than
|
||||
warnings.
|
||||
|
||||
`-Wtrigraphs'
|
||||
Warn if any trigraphs are encountered. Currently this only works
|
||||
if you have turned trigraphs on with `-trigraphs' or `-ansi'; in
|
||||
the future this restriction will be removed.
|
||||
|
||||
`-Wcomment'
|
||||
Warn whenever a comment-start sequence `/*' appears in a `/*'
|
||||
comment, or whenever a Backslash-Newline appears in a `//' comment.
|
||||
|
||||
`-Wall'
|
||||
Requests both `-Wtrigraphs' and `-Wcomment' (but not
|
||||
`-Wtraditional' or `-Wundef').
|
||||
|
||||
`-Wtraditional'
|
||||
Warn about certain constructs that behave differently in
|
||||
traditional and ANSI C.
|
||||
|
||||
`-Wundef'
|
||||
Warn if an undefined identifier is evaluated in an `#if' directive.
|
||||
|
||||
`-I DIRECTORY'
|
||||
Add the directory DIRECTORY to the head of the list of directories
|
||||
to be searched for header files (*note Include Syntax::.). This
|
||||
can be used to override a system header file, substituting your
|
||||
own version, since these directories are searched before the system
|
||||
header file directories. If you use more than one `-I' option,
|
||||
the directories are scanned in left-to-right order; the standard
|
||||
system directories come after.
|
||||
|
||||
`-I-'
|
||||
Any directories specified with `-I' options before the `-I-'
|
||||
option are searched only for the case of `#include "FILE"'; they
|
||||
are not searched for `#include <FILE>'.
|
||||
|
||||
If additional directories are specified with `-I' options after
|
||||
the `-I-', these directories are searched for all `#include'
|
||||
directives.
|
||||
|
||||
In addition, the `-I-' option inhibits the use of the current
|
||||
directory as the first search directory for `#include "FILE"'.
|
||||
Therefore, the current directory is searched only if it is
|
||||
requested explicitly with `-I.'. Specifying both `-I-' and `-I.'
|
||||
allows you to control precisely which directories are searched
|
||||
before the current one and which are searched after.
|
||||
|
||||
`-nostdinc'
|
||||
Do not search the standard system directories for header files.
|
||||
Only the directories you have specified with `-I' options (and the
|
||||
current directory, if appropriate) are searched.
|
||||
|
||||
`-nostdinc++'
|
||||
Do not search for header files in the C++-specific standard
|
||||
directories, but do still search the other standard directories.
|
||||
(This option is used when building the C++ library.)
|
||||
|
||||
`-remap'
|
||||
When searching for a header file in a directory, remap file names
|
||||
if a file named `header.gcc' exists in that directory. This can
|
||||
be used to work around limitations of file systems with file name
|
||||
restrictions. The `header.gcc' file should contain a series of
|
||||
lines with two tokens on each line: the first token is the name to
|
||||
map, and the second token is the actual name to use.
|
||||
|
||||
`-D NAME'
|
||||
Predefine NAME as a macro, with definition `1'.
|
||||
|
||||
`-D NAME=DEFINITION'
|
||||
Predefine NAME as a macro, with definition DEFINITION. There are
|
||||
no restrictions on the contents of DEFINITION, but if you are
|
||||
invoking the preprocessor from a shell or shell-like program you
|
||||
may need to use the shell's quoting syntax to protect characters
|
||||
such as spaces that have a meaning in the shell syntax. If you
|
||||
use more than one `-D' for the same NAME, the rightmost definition
|
||||
takes effect.
|
||||
|
||||
`-U NAME'
|
||||
Do not predefine NAME. If both `-U' and `-D' are specified for
|
||||
one name, the `-U' beats the `-D' and the name is not predefined.
|
||||
|
||||
`-undef'
|
||||
Do not predefine any nonstandard macros.
|
||||
|
||||
`-gcc'
|
||||
Define the macros __GNUC__ and __GNUC_MINOR__. These are defined
|
||||
automatically when you use `gcc -E'; you can turn them off in that
|
||||
case with `-no-gcc'.
|
||||
|
||||
`-A PREDICATE(ANSWER)'
|
||||
Make an assertion with the predicate PREDICATE and answer ANSWER.
|
||||
*Note Assertions::.
|
||||
|
||||
You can use `-A-' to disable all predefined assertions; it also
|
||||
undefines all predefined macros and all macros that preceded it on
|
||||
the command line.
|
||||
|
||||
`-dM'
|
||||
Instead of outputting the result of preprocessing, output a list of
|
||||
`#define' directives for all the macros defined during the
|
||||
execution of the preprocessor, including predefined macros. This
|
||||
gives you a way of finding out what is predefined in your version
|
||||
of the preprocessor; assuming you have no file `foo.h', the command
|
||||
|
||||
touch foo.h; cpp -dM foo.h
|
||||
|
||||
will show the values of any predefined macros.
|
||||
|
||||
`-dD'
|
||||
Like `-dM' except in two respects: it does *not* include the
|
||||
predefined macros, and it outputs *both* the `#define' directives
|
||||
and the result of preprocessing. Both kinds of output go to the
|
||||
standard output file.
|
||||
|
||||
`-dI'
|
||||
Output `#include' directives in addition to the result of
|
||||
preprocessing.
|
||||
|
||||
`-M [-MG]'
|
||||
Instead of outputting the result of preprocessing, output a rule
|
||||
suitable for `make' describing the dependencies of the main source
|
||||
file. The preprocessor outputs one `make' rule containing the
|
||||
object file name for that source file, a colon, and the names of
|
||||
all the included files. If there are many included files then the
|
||||
rule is split into several lines using `\'-newline.
|
||||
|
||||
`-MG' says to treat missing header files as generated files and
|
||||
assume they live in the same directory as the source file. It
|
||||
must be specified in addition to `-M'.
|
||||
|
||||
This feature is used in automatic updating of makefiles.
|
||||
|
||||
`-MM [-MG]'
|
||||
Like `-M' but mention only the files included with `#include
|
||||
"FILE"'. System header files included with `#include <FILE>' are
|
||||
omitted.
|
||||
|
||||
`-MD FILE'
|
||||
Like `-M' but the dependency information is written to FILE. This
|
||||
is in addition to compiling the file as specified--`-MD' does not
|
||||
inhibit ordinary compilation the way `-M' does.
|
||||
|
||||
When invoking `gcc', do not specify the FILE argument. `gcc' will
|
||||
create file names made by replacing ".c" with ".d" at the end of
|
||||
the input file names.
|
||||
|
||||
In Mach, you can use the utility `md' to merge multiple dependency
|
||||
files into a single dependency file suitable for using with the
|
||||
`make' command.
|
||||
|
||||
`-MMD FILE'
|
||||
Like `-MD' except mention only user header files, not system
|
||||
header files.
|
||||
|
||||
`-H'
|
||||
Print the name of each header file used, in addition to other
|
||||
normal activities.
|
||||
|
||||
`-imacros FILE'
|
||||
Process FILE as input, discarding the resulting output, before
|
||||
processing the regular input file. Because the output generated
|
||||
from FILE is discarded, the only effect of `-imacros FILE' is to
|
||||
make the macros defined in FILE available for use in the main
|
||||
input.
|
||||
|
||||
`-include FILE'
|
||||
Process FILE as input, and include all the resulting output,
|
||||
before processing the regular input file.
|
||||
|
||||
`-idirafter DIR'
|
||||
Add the directory DIR to the second include path. The directories
|
||||
on the second include path are searched when a header file is not
|
||||
found in any of the directories in the main include path (the one
|
||||
that `-I' adds to).
|
||||
|
||||
`-iprefix PREFIX'
|
||||
Specify PREFIX as the prefix for subsequent `-iwithprefix' options.
|
||||
|
||||
`-iwithprefix DIR'
|
||||
Add a directory to the second include path. The directory's name
|
||||
is made by concatenating PREFIX and DIR, where PREFIX was
|
||||
specified previously with `-iprefix'.
|
||||
|
||||
`-isystem DIR'
|
||||
Add a directory to the beginning of the second include path,
|
||||
marking it as a system directory, so that it gets the same special
|
||||
treatment as is applied to the standard system directories.
|
||||
|
||||
`-x c'
|
||||
`-x c++'
|
||||
`-x objective-c'
|
||||
`-x assembler-with-cpp'
|
||||
Specify the source language: C, C++, Objective-C, or assembly.
|
||||
This has nothing to do with standards conformance or extensions;
|
||||
it merely selects which base syntax to expect. If you give none
|
||||
of these options, cpp will deduce the language from the extension
|
||||
of the source file: `.c', `.cc', `.m', or `.S'. Some other common
|
||||
extensions for C++ and assembly are also recognized. If cpp does
|
||||
not recognize the extension, it will treat the file as C; this is
|
||||
the most generic mode.
|
||||
|
||||
*Note:* Previous versions of cpp accepted a `-lang' option which
|
||||
selected both the language and the standards conformance level.
|
||||
This option has been removed, because it conflicts with the `-l'
|
||||
option.
|
||||
|
||||
`-std=STANDARD'
|
||||
`-ansi'
|
||||
Specify the standard to which the code should conform. Currently
|
||||
cpp only knows about the standards for C; other language standards
|
||||
will be added in the future.
|
||||
|
||||
STANDARD may be one of:
|
||||
`iso9899:1990'
|
||||
The ISO C standard from 1990.
|
||||
|
||||
`iso9899:199409'
|
||||
`c89'
|
||||
The 1990 C standard, as amended in 1994. `c89' is the
|
||||
customary shorthand for this version of the standard.
|
||||
|
||||
The `-ansi' option is equivalent to `-std=c89'.
|
||||
|
||||
`iso9899:199x'
|
||||
`c9x'
|
||||
The revised ISO C standard, which is expected to be
|
||||
promulgated some time in 1999. It has not been approved yet,
|
||||
hence the `x'.
|
||||
|
||||
`gnu89'
|
||||
The 1990 C standard plus GNU extensions. This is the default.
|
||||
|
||||
`gnu9x'
|
||||
The 199x C standard plus GNU extensions.
|
||||
|
||||
`-Wp,-lint'
|
||||
Look for commands to the program checker `lint' embedded in
|
||||
comments, and emit them preceded by `#pragma lint'. For example,
|
||||
the comment `/* NOTREACHED */' becomes `#pragma lint NOTREACHED'.
|
||||
|
||||
Because of the clash with `-l', you must use the awkward syntax
|
||||
above. In a future release, this option will be replaced by
|
||||
`-flint' or `-Wlint'; we are not sure which yet.
|
||||
|
||||
`-$'
|
||||
Forbid the use of `$' in identifiers. The C standard does not
|
||||
permit this, but it is a common extension.
|
||||
|
||||
|
||||
File: cpp.info, Node: Concept Index, Next: Index, Prev: Invocation, Up: Top
|
||||
|
||||
Concept Index
|
||||
*************
|
||||
|
||||
* Menu:
|
||||
|
||||
* ##: Concatenation.
|
||||
* arguments in macro definitions: Argument Macros.
|
||||
* assertions: Assertions.
|
||||
* assertions, undoing: Assertions.
|
||||
* blank macro arguments: Argument Macros.
|
||||
* cascaded macros: Cascaded Macros.
|
||||
* commenting out code: Deleted Code.
|
||||
* computed #include: Include Syntax.
|
||||
* concatenation: Concatenation.
|
||||
* conditionals: Conditionals.
|
||||
* directives: Directives.
|
||||
* expansion of arguments: Argument Prescan.
|
||||
* Fortran: Invocation.
|
||||
* function-like macro: Argument Macros.
|
||||
* g77: Invocation.
|
||||
* header file: Header Files.
|
||||
* including just once: Once-Only.
|
||||
* inheritance: Inheritance.
|
||||
* invocation of the preprocessor: Invocation.
|
||||
* line control: Combining Sources.
|
||||
* macro argument expansion: Argument Prescan.
|
||||
* macro body uses macro: Cascaded Macros.
|
||||
* macros with argument: Argument Macros.
|
||||
* manifest constant: Simple Macros.
|
||||
* newlines in macro arguments: Newlines in Args.
|
||||
* null directive: Other Directives.
|
||||
* options: Invocation.
|
||||
* output format: Output.
|
||||
* overriding a header file: Inheritance.
|
||||
* parentheses in macro bodies: Macro Parentheses.
|
||||
* pitfalls of macros: Macro Pitfalls.
|
||||
* predefined macros: Predefined.
|
||||
* predicates: Assertions.
|
||||
* preprocessing directives: Directives.
|
||||
* prescan of macro arguments: Argument Prescan.
|
||||
* problems with macros: Macro Pitfalls.
|
||||
* redefining macros: Redefining.
|
||||
* repeated inclusion: Once-Only.
|
||||
* retracting assertions: Assertions.
|
||||
* second include path: Invocation.
|
||||
* self-reference: Self-Reference.
|
||||
* semicolons (after macro calls): Swallow Semicolon.
|
||||
* side effects (in macro arguments): Side Effects.
|
||||
* simple macro: Simple Macros.
|
||||
* space as macro argument: Argument Macros.
|
||||
* standard predefined macros: Standard Predefined.
|
||||
* stringification: Stringification.
|
||||
* testing predicates: Assertions.
|
||||
* unassert: Assertions.
|
||||
* undefining macros: Undefining.
|
||||
* unsafe macros: Side Effects.
|
||||
* unterminated: Invocation.
|
||||
|
||||
|
||||
File: cpp.info, Node: Index, Prev: Concept Index, Up: Top
|
||||
|
||||
Index of Directives, Macros and Options
|
||||
***************************************
|
||||
|
||||
* Menu:
|
||||
|
||||
* #assert: Assertions.
|
||||
* #cpu: Assertions.
|
||||
* #define: Argument Macros.
|
||||
* #elif: #elif Directive.
|
||||
* #else: #else Directive.
|
||||
* #error: #error Directive.
|
||||
* #ident: Other Directives.
|
||||
* #if: Conditional Syntax.
|
||||
* #ifdef: Conditionals-Macros.
|
||||
* #ifndef: Conditionals-Macros.
|
||||
* #import: Once-Only.
|
||||
* #include: Include Syntax.
|
||||
* #include_next: Inheritance.
|
||||
* #line: Combining Sources.
|
||||
* #machine: Assertions.
|
||||
* #pragma: Other Directives.
|
||||
* #pragma once: Once-Only.
|
||||
* #system: Assertions.
|
||||
* #unassert: Assertions.
|
||||
* #warning: #error Directive.
|
||||
* -$: Invocation.
|
||||
* -A: Invocation.
|
||||
* -ansi: Invocation.
|
||||
* -C: Invocation.
|
||||
* -D: Invocation.
|
||||
* -dD: Invocation.
|
||||
* -dI: Invocation.
|
||||
* -dM: Invocation.
|
||||
* -gcc: Invocation.
|
||||
* -H: Invocation.
|
||||
* -I: Invocation.
|
||||
* -idirafter: Invocation.
|
||||
* -imacros: Invocation.
|
||||
* -include: Invocation.
|
||||
* -iprefix: Invocation.
|
||||
* -isystem: Invocation.
|
||||
* -iwithprefix: Invocation.
|
||||
* -lint: Invocation.
|
||||
* -M: Invocation.
|
||||
* -MD: Invocation.
|
||||
* -MM: Invocation.
|
||||
* -MMD: Invocation.
|
||||
* -nostdinc: Invocation.
|
||||
* -nostdinc++: Invocation.
|
||||
* -P: Invocation.
|
||||
* -pedantic: Invocation.
|
||||
* -pedantic-errors: Invocation.
|
||||
* -remap: Invocation.
|
||||
* -std: Invocation.
|
||||
* -traditional: Invocation.
|
||||
* -trigraphs: Invocation.
|
||||
* -U: Invocation.
|
||||
* -undef: Invocation.
|
||||
* -Wall: Invocation.
|
||||
* -Wcomment: Invocation.
|
||||
* -Wtraditional: Invocation.
|
||||
* -Wtrigraphs: Invocation.
|
||||
* -Wundef: Invocation.
|
||||
* -x assembler-with-cpp: Invocation.
|
||||
* -x c: Invocation.
|
||||
* -x objective-c: Invocation.
|
||||
* __BASE_FILE__: Standard Predefined.
|
||||
* __CHAR_UNSIGNED__: Standard Predefined.
|
||||
* __cplusplus: Standard Predefined.
|
||||
* __DATE__: Standard Predefined.
|
||||
* __FILE__: Standard Predefined.
|
||||
* __GNUC__: Standard Predefined.
|
||||
* __GNUC_MINOR__: Standard Predefined.
|
||||
* __GNUG__: Standard Predefined.
|
||||
* __INCLUDE_LEVEL_: Standard Predefined.
|
||||
* __LINE__: Standard Predefined.
|
||||
* __OPTIMIZE__: Standard Predefined.
|
||||
* __REGISTER_PREFIX__: Standard Predefined.
|
||||
* __STDC__: Standard Predefined.
|
||||
* __STDC_VERSION__: Standard Predefined.
|
||||
* __STRICT_ANSI__: Standard Predefined.
|
||||
* __TIME__: Standard Predefined.
|
||||
* __USER_LABEL_PREFIX__: Standard Predefined.
|
||||
* __VERSION__: Standard Predefined.
|
||||
* _AM29000: Nonstandard Predefined.
|
||||
* _AM29K: Nonstandard Predefined.
|
||||
* BSD: Nonstandard Predefined.
|
||||
* defined: Conditionals-Macros.
|
||||
* M68020: Nonstandard Predefined.
|
||||
* m68k: Nonstandard Predefined.
|
||||
* mc68000: Nonstandard Predefined.
|
||||
* ns32000: Nonstandard Predefined.
|
||||
* pyr: Nonstandard Predefined.
|
||||
* sequent: Nonstandard Predefined.
|
||||
* sun: Nonstandard Predefined.
|
||||
* system header files: Header Uses.
|
||||
* unix: Nonstandard Predefined.
|
||||
* vax: Nonstandard Predefined.
|
||||
|
||||
|
||||
Executable
+329
@@ -0,0 +1,329 @@
|
||||
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
|
||||
input file ../../gcc-2.95.2/gcc/gcc.texi.
|
||||
|
||||
INFO-DIR-SECTION Programming
|
||||
START-INFO-DIR-ENTRY
|
||||
* gcc: (gcc). The GNU Compiler Collection.
|
||||
END-INFO-DIR-ENTRY
|
||||
This file documents the use and the internals of the GNU compiler.
|
||||
|
||||
Published by the Free Software Foundation 59 Temple Place - Suite 330
|
||||
Boston, MA 02111-1307 USA
|
||||
|
||||
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
|
||||
1999 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 "Funding
|
||||
for Free Software" 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 one.
|
||||
|
||||
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 "Funding for Free Software", and this permission notice,
|
||||
may be included in translations approved by the Free Software Foundation
|
||||
instead of in the original English.
|
||||
|
||||
|
||||
Indirect:
|
||||
gcc.info-1: 1468
|
||||
gcc.info-2: 42003
|
||||
gcc.info-3: 75234
|
||||
gcc.info-4: 122510
|
||||
gcc.info-5: 166689
|
||||
gcc.info-6: 213193
|
||||
gcc.info-7: 260569
|
||||
gcc.info-8: 302186
|
||||
gcc.info-9: 349051
|
||||
gcc.info-10: 399031
|
||||
gcc.info-11: 440266
|
||||
gcc.info-12: 488386
|
||||
gcc.info-13: 529896
|
||||
gcc.info-14: 578788
|
||||
gcc.info-15: 626050
|
||||
gcc.info-16: 671156
|
||||
gcc.info-17: 721050
|
||||
gcc.info-18: 769831
|
||||
gcc.info-19: 816705
|
||||
gcc.info-20: 865531
|
||||
gcc.info-21: 915283
|
||||
gcc.info-22: 952344
|
||||
gcc.info-23: 994139
|
||||
gcc.info-24: 1039021
|
||||
gcc.info-25: 1084921
|
||||
gcc.info-26: 1129014
|
||||
gcc.info-27: 1178605
|
||||
gcc.info-28: 1218283
|
||||
gcc.info-29: 1263090
|
||||
gcc.info-30: 1287554
|
||||
|
||||
Tag Table:
|
||||
(Indirect)
|
||||
Node: Top1468
|
||||
Node: G++ and GCC3229
|
||||
Node: Invoking GCC5627
|
||||
Node: Option Summary8988
|
||||
Node: Overall Options23740
|
||||
Node: Invoking G++28760
|
||||
Node: C Dialect Options30217
|
||||
Node: C++ Dialect Options42003
|
||||
Node: Warning Options57982
|
||||
Node: Debugging Options75234
|
||||
Node: Optimize Options92302
|
||||
Node: Preprocessor Options109774
|
||||
Node: Assembler Options116237
|
||||
Node: Link Options116604
|
||||
Node: Directory Options122510
|
||||
Node: Target Options126375
|
||||
Node: Submodel Options130006
|
||||
Node: M680x0 Options131556
|
||||
Node: VAX Options137072
|
||||
Node: SPARC Options137607
|
||||
Node: Convex Options147471
|
||||
Node: AMD29K Options149652
|
||||
Node: ARM Options153048
|
||||
Node: Thumb Options161069
|
||||
Node: MN10200 Options163039
|
||||
Node: MN10300 Options163563
|
||||
Node: M32R/D Options164339
|
||||
Node: M88K Options166689
|
||||
Node: RS/6000 and PowerPC Options174627
|
||||
Node: RT Options193741
|
||||
Node: MIPS Options195445
|
||||
Node: i386 Options205190
|
||||
Node: HPPA Options213193
|
||||
Node: Intel 960 Options217464
|
||||
Node: DEC Alpha Options220406
|
||||
Node: Clipper Options229800
|
||||
Node: H8/300 Options230199
|
||||
Node: SH Options231013
|
||||
Node: System V Options231832
|
||||
Node: TMS320C3x/C4x Options232650
|
||||
Node: V850 Options238155
|
||||
Node: ARC Options240164
|
||||
Node: NS32K Options241366
|
||||
Node: Code Gen Options245586
|
||||
Node: Environment Variables260569
|
||||
Node: Running Protoize266755
|
||||
Node: Installation273121
|
||||
Node: Configuration Files300581
|
||||
Node: Configurations302186
|
||||
Node: Other Dir341310
|
||||
Node: Cross-Compiler343026
|
||||
Node: Steps of Cross344857
|
||||
Node: Configure Cross345975
|
||||
Node: Tools and Libraries346612
|
||||
Node: Cross Runtime349051
|
||||
Node: Cross Headers353132
|
||||
Node: Build Cross355131
|
||||
Node: Sun Install357007
|
||||
Node: VMS Install358679
|
||||
Node: Collect2368609
|
||||
Node: Header Dirs371174
|
||||
Node: C Extensions372598
|
||||
Node: Statement Exprs376123
|
||||
Node: Local Labels378017
|
||||
Node: Labels as Values380079
|
||||
Node: Nested Functions381943
|
||||
Node: Constructing Calls385786
|
||||
Node: Naming Types387843
|
||||
Node: Typeof388937
|
||||
Node: Lvalues390802
|
||||
Node: Conditionals393242
|
||||
Node: Long Long394133
|
||||
Node: Complex395573
|
||||
Node: Hex Floats397434
|
||||
Node: Zero Length398354
|
||||
Node: Variable Length399031
|
||||
Node: Macro Varargs401556
|
||||
Node: Subscripting403659
|
||||
Node: Pointer Arith404142
|
||||
Node: Initializers404707
|
||||
Node: Constructors405172
|
||||
Node: Labeled Elements406866
|
||||
Node: Case Ranges409495
|
||||
Node: Cast to Union410176
|
||||
Node: Function Attributes411254
|
||||
Node: Function Prototypes427178
|
||||
Node: C++ Comments428980
|
||||
Node: Dollar Signs429516
|
||||
Node: Character Escapes429974
|
||||
Node: Alignment430261
|
||||
Node: Variable Attributes431733
|
||||
Node: Type Attributes440266
|
||||
Node: Inline449477
|
||||
Node: Extended Asm453719
|
||||
Node: Asm Labels468652
|
||||
Node: Explicit Reg Vars469971
|
||||
Node: Global Reg Vars471426
|
||||
Node: Local Reg Vars475991
|
||||
Node: Alternate Keywords477795
|
||||
Node: Incomplete Enums479197
|
||||
Node: Function Names479953
|
||||
Node: Return Address481227
|
||||
Node: Other Builtins483270
|
||||
Node: Deprecated Features485736
|
||||
Node: C++ Extensions487013
|
||||
Node: Naming Results488386
|
||||
Node: Min and Max491700
|
||||
Node: Destructors and Goto493140
|
||||
Node: C++ Interface493616
|
||||
Node: Template Instantiation498850
|
||||
Node: Bound member functions507465
|
||||
Node: C++ Signatures508798
|
||||
Node: Gcov513142
|
||||
Node: Gcov Intro513665
|
||||
Node: Invoking Gcov516346
|
||||
Node: Gcov and Optimization521957
|
||||
Node: Gcov Data Files523381
|
||||
Node: Trouble526951
|
||||
Node: Actual Bugs528629
|
||||
Node: Installation Problems529896
|
||||
Node: Cross-Compiler Problems543574
|
||||
Node: Interoperation545045
|
||||
Node: External Bugs558323
|
||||
Node: Incompatibilities560446
|
||||
Node: Fixed Headers568918
|
||||
Node: Standard Libraries571228
|
||||
Node: Disappointments572469
|
||||
Node: C++ Misunderstandings577008
|
||||
Node: Static Definitions577734
|
||||
Node: Temporaries578788
|
||||
Node: Copy Assignment580766
|
||||
Node: Protoize Caveats582577
|
||||
Node: Non-bugs586533
|
||||
Node: Warnings and Errors596164
|
||||
Node: Bugs597925
|
||||
Node: Bug Criteria599273
|
||||
Node: Bug Lists601711
|
||||
Node: Bug Reporting602827
|
||||
Node: Sending Patches615050
|
||||
Node: Service620425
|
||||
Node: Contributing620992
|
||||
Node: VMS621798
|
||||
Node: Include Files and VMS622184
|
||||
Node: Global Declarations626050
|
||||
Node: VMS Misc630355
|
||||
Node: Portability634662
|
||||
Node: Interface636411
|
||||
Node: Passes640993
|
||||
Node: RTL659344
|
||||
Node: RTL Objects661312
|
||||
Node: RTL Classes664358
|
||||
Node: Accessors668776
|
||||
Node: Flags671156
|
||||
Node: Machine Modes681491
|
||||
Node: Constants689125
|
||||
Node: Regs and Memory694313
|
||||
Node: Arithmetic706789
|
||||
Node: Comparisons712687
|
||||
Node: Bit Fields716750
|
||||
Node: Conversions718162
|
||||
Node: RTL Declarations721050
|
||||
Node: Side Effects721859
|
||||
Node: Incdec734863
|
||||
Node: Assembler738364
|
||||
Node: Insns739886
|
||||
Node: Calls763221
|
||||
Node: Sharing765816
|
||||
Node: Reading RTL768892
|
||||
Node: Machine Desc769831
|
||||
Node: Patterns771684
|
||||
Node: Example774628
|
||||
Node: RTL Template775756
|
||||
Node: Output Template788835
|
||||
Node: Output Statement792817
|
||||
Node: Constraints796530
|
||||
Node: Simple Constraints797533
|
||||
Node: Multi-Alternative809445
|
||||
Node: Class Preferences812281
|
||||
Node: Modifiers813161
|
||||
Node: Machine Constraints816705
|
||||
Node: No Constraints825767
|
||||
Node: Standard Names826888
|
||||
Node: Pattern Ordering864304
|
||||
Node: Dependent Patterns865531
|
||||
Node: Jump Patterns868346
|
||||
Node: Insn Canonicalizations874162
|
||||
Node: Peephole Definitions877657
|
||||
Node: Expander Definitions884575
|
||||
Node: Insn Splitting891960
|
||||
Node: Insn Attributes898891
|
||||
Node: Defining Attributes899938
|
||||
Node: Expressions901950
|
||||
Node: Tagging Insns908544
|
||||
Node: Attr Example912907
|
||||
Node: Insn Lengths915283
|
||||
Node: Constant Attributes918576
|
||||
Node: Delay Slots919736
|
||||
Node: Function Units922947
|
||||
Node: Target Macros928617
|
||||
Node: Driver930500
|
||||
Node: Run-time Target946047
|
||||
Node: Storage Layout952344
|
||||
Node: Type Layout969671
|
||||
Node: Registers976444
|
||||
Node: Register Basics977424
|
||||
Node: Allocation Order982220
|
||||
Node: Values in Registers983636
|
||||
Node: Leaf Functions988756
|
||||
Node: Stack Registers991534
|
||||
Node: Obsolete Register Macros992367
|
||||
Node: Register Classes994139
|
||||
Node: Stack and Calling1014146
|
||||
Node: Frame Layout1014601
|
||||
Node: Stack Checking1020098
|
||||
Node: Frame Registers1023678
|
||||
Node: Elimination1028093
|
||||
Node: Stack Arguments1032349
|
||||
Node: Register Arguments1039021
|
||||
Node: Scalar Return1049531
|
||||
Node: Aggregate Return1053769
|
||||
Node: Caller Saves1057484
|
||||
Node: Function Entry1059023
|
||||
Node: Profiling1069925
|
||||
Node: Varargs1077006
|
||||
Node: Trampolines1084921
|
||||
Node: Library Calls1091639
|
||||
Node: Addressing Modes1099697
|
||||
Node: Condition Code1110105
|
||||
Node: Costs1116304
|
||||
Node: Sections1129014
|
||||
Node: PIC1135245
|
||||
Node: Assembler Format1137954
|
||||
Node: File Framework1139020
|
||||
Node: Data Output1143718
|
||||
Node: Uninitialized Data1150912
|
||||
Node: Label Output1156318
|
||||
Node: Initialization1167524
|
||||
Node: Macros for Initialization1173667
|
||||
Node: Instruction Output1178605
|
||||
Node: Dispatch Tables1186792
|
||||
Node: Exception Region Output1189345
|
||||
Node: Alignment Output1192339
|
||||
Node: Debugging Info1194562
|
||||
Node: All Debuggers1195171
|
||||
Node: DBX Options1197999
|
||||
Node: DBX Hooks1203282
|
||||
Node: File Names and DBX1206922
|
||||
Node: SDB and DWARF1208895
|
||||
Node: Cross-compilation1211717
|
||||
Node: Misc1218283
|
||||
Node: Config1242660
|
||||
Node: Fragments1249923
|
||||
Node: Target Fragment1250519
|
||||
Node: Host Fragment1254674
|
||||
Node: Funding1255276
|
||||
Node: GNU/Linux1257775
|
||||
Node: Copying1263090
|
||||
Node: Contributors1282278
|
||||
Node: Index1287554
|
||||
|
||||
End Tag Table
|
||||
Executable
+954
@@ -0,0 +1,954 @@
|
||||
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
|
||||
input file ../../gcc-2.95.2/gcc/gcc.texi.
|
||||
|
||||
INFO-DIR-SECTION Programming
|
||||
START-INFO-DIR-ENTRY
|
||||
* gcc: (gcc). The GNU Compiler Collection.
|
||||
END-INFO-DIR-ENTRY
|
||||
This file documents the use and the internals of the GNU compiler.
|
||||
|
||||
Published by the Free Software Foundation 59 Temple Place - Suite 330
|
||||
Boston, MA 02111-1307 USA
|
||||
|
||||
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
|
||||
1999 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 "Funding
|
||||
for Free Software" 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 one.
|
||||
|
||||
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 "Funding for Free Software", 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: Top, Next: G++ and GCC, Up: (DIR)
|
||||
|
||||
Introduction
|
||||
************
|
||||
|
||||
This manual documents how to run, install and port the GNU compiler,
|
||||
as well as its new features and incompatibilities, and how to report
|
||||
bugs. It corresponds to GCC version 2.95.
|
||||
|
||||
* Menu:
|
||||
|
||||
|
||||
* G++ and GCC:: You can compile C or C++ programs.
|
||||
* Invoking GCC:: Command options supported by `gcc'.
|
||||
* Installation:: How to configure, compile and install GCC.
|
||||
* C Extensions:: GNU extensions to the C language family.
|
||||
* C++ Extensions:: GNU extensions to the C++ language.
|
||||
* Gcov:: gcov: a GCC test coverage program.
|
||||
* Trouble:: If you have trouble installing GCC.
|
||||
* Bugs:: How, why and where to report bugs.
|
||||
* Service:: How to find suppliers of support for GCC.
|
||||
* Contributing:: How to contribute to testing and developing GCC.
|
||||
* VMS:: Using GCC on VMS.
|
||||
|
||||
* Portability:: Goals of GCC's portability features.
|
||||
* Interface:: Function-call interface of GCC output.
|
||||
* Passes:: Order of passes, what they do, and what each file is for.
|
||||
* RTL:: The intermediate representation that most passes work on.
|
||||
* Machine Desc:: How to write machine description instruction patterns.
|
||||
* Target Macros:: How to write the machine description C macros.
|
||||
* Config:: Writing the `xm-MACHINE.h' file.
|
||||
* Fragments:: Writing the `t-TARGET' and `x-HOST' files.
|
||||
|
||||
* Funding:: How to help assure funding for free software.
|
||||
* GNU/Linux:: Linux and the GNU Project
|
||||
|
||||
* Copying:: GNU General Public License says
|
||||
how you can copy and share GCC.
|
||||
* Contributors:: People who have contributed to GCC.
|
||||
|
||||
* Index:: Index of concepts and symbol names.
|
||||
|
||||
|
||||
File: gcc.info, Node: G++ and GCC, Next: Invoking GCC, Prev: Top, Up: Top
|
||||
|
||||
Compile C, C++, Objective C, or Fortran
|
||||
***************************************
|
||||
|
||||
The C, C++, and Objective C, and Fortran versions of the compiler are
|
||||
integrated; this is why we use the name "GNU Compiler Collection". GCC
|
||||
can compile programs written in C, C++, Objective C, or Fortran. The
|
||||
Fortran compiler is described in a separate manual.
|
||||
|
||||
"GCC" is a common shorthand term for the GNU Compiler Collection.
|
||||
This is both the most general name for the compiler, and the name used
|
||||
when the emphasis is on compiling C programs (as the abbreviation
|
||||
formerly stood for "GNU C Compiler").
|
||||
|
||||
When referring to C++ compilation, it is usual to call the compiler
|
||||
"G++". Since there is only one compiler, it is also accurate to call
|
||||
it "GCC" no matter what the language context; however, the term "G++"
|
||||
is more useful when the emphasis is on compiling C++ programs.
|
||||
|
||||
We use the name "GCC" to refer to the compilation system as a whole,
|
||||
and more specifically to the language-independent part of the compiler.
|
||||
For example, we refer to the optimization options as affecting the
|
||||
behavior of "GCC" or sometimes just "the compiler".
|
||||
|
||||
Front ends for other languages, such as Ada 9X, Fortran, Modula-3,
|
||||
and Pascal, are under development. These front-ends, like that for
|
||||
C++, are built in subdirectories of GCC and link to it. The result is
|
||||
an integrated compiler that can compile programs written in C, C++,
|
||||
Objective C, or any of the languages for which you have installed front
|
||||
ends.
|
||||
|
||||
In this manual, we only discuss the options for the C, Objective-C,
|
||||
and C++ compilers and those of the GCC core. Consult the documentation
|
||||
of the other front ends for the options to use when compiling programs
|
||||
written in other languages.
|
||||
|
||||
G++ is a *compiler*, not merely a preprocessor. G++ builds object
|
||||
code directly from your C++ program source. There is no intermediate C
|
||||
version of the program. (By contrast, for example, some other
|
||||
implementations use a program that generates a C program from your C++
|
||||
source.) Avoiding an intermediate C representation of the program means
|
||||
that you get better object code, and better debugging information. The
|
||||
GNU debugger, GDB, works with this information in the object code to
|
||||
give you comprehensive C++ source-level editing capabilities (*note C
|
||||
and C++: (gdb.info)C.).
|
||||
|
||||
|
||||
File: gcc.info, Node: Invoking GCC, Next: Installation, Prev: G++ and GCC, Up: Top
|
||||
|
||||
GCC Command Options
|
||||
*******************
|
||||
|
||||
When you invoke GCC, it normally does preprocessing, compilation,
|
||||
assembly and linking. The "overall options" allow you to stop this
|
||||
process at an intermediate stage. For example, the `-c' option says
|
||||
not to run the linker. Then the output consists of object files output
|
||||
by the assembler.
|
||||
|
||||
Other options are passed on to one stage of processing. Some options
|
||||
control the preprocessor and others the compiler itself. Yet other
|
||||
options control the assembler and linker; most of these are not
|
||||
documented here, since you rarely need to use any of them.
|
||||
|
||||
Most of the command line options that you can use with GCC are useful
|
||||
for C programs; when an option is only useful with another language
|
||||
(usually C++), the explanation says so explicitly. If the description
|
||||
for a particular option does not mention a source language, you can use
|
||||
that option with all supported languages.
|
||||
|
||||
*Note Compiling C++ Programs: Invoking G++, for a summary of special
|
||||
options for compiling C++ programs.
|
||||
|
||||
The `gcc' program accepts options and file names as operands. Many
|
||||
options have multiletter names; therefore multiple single-letter options
|
||||
may *not* be grouped: `-dr' is very different from `-d -r'.
|
||||
|
||||
You can mix options and other arguments. For the most part, the
|
||||
order you use doesn't matter. Order does matter when you use several
|
||||
options of the same kind; for example, if you specify `-L' more than
|
||||
once, the directories are searched in the order specified.
|
||||
|
||||
Many options have long names starting with `-f' or with `-W'--for
|
||||
example, `-fforce-mem', `-fstrength-reduce', `-Wformat' and so on.
|
||||
Most of these have both positive and negative forms; the negative form
|
||||
of `-ffoo' would be `-fno-foo'. This manual documents only one of
|
||||
these two forms, whichever one is not the default.
|
||||
|
||||
* Menu:
|
||||
|
||||
* Option Summary:: Brief list of all options, without explanations.
|
||||
* Overall Options:: Controlling the kind of output:
|
||||
an executable, object files, assembler files,
|
||||
or preprocessed source.
|
||||
* Invoking G++:: Compiling C++ programs.
|
||||
* C Dialect Options:: Controlling the variant of C language compiled.
|
||||
* C++ Dialect Options:: Variations on C++.
|
||||
* Warning Options:: How picky should the compiler be?
|
||||
* Debugging Options:: Symbol tables, measurements, and debugging dumps.
|
||||
* Optimize Options:: How much optimization?
|
||||
* Preprocessor Options:: Controlling header files and macro definitions.
|
||||
Also, getting dependency information for Make.
|
||||
* Assembler Options:: Passing options to the assembler.
|
||||
* Link Options:: Specifying libraries and so on.
|
||||
* Directory Options:: Where to find header files and libraries.
|
||||
Where to find the compiler executable files.
|
||||
* Target Options:: Running a cross-compiler, or an old version of GCC.
|
||||
* Submodel Options:: Specifying minor hardware or convention variations,
|
||||
such as 68010 vs 68020.
|
||||
* Code Gen Options:: Specifying conventions for function calls, data layout
|
||||
and register usage.
|
||||
* Environment Variables:: Env vars that affect GCC.
|
||||
* Running Protoize:: Automatically adding or removing function prototypes.
|
||||
|
||||
|
||||
File: gcc.info, Node: Option Summary, Next: Overall Options, Up: Invoking GCC
|
||||
|
||||
Option Summary
|
||||
==============
|
||||
|
||||
Here is a summary of all the options, grouped by type. Explanations
|
||||
are in the following sections.
|
||||
|
||||
*Overall Options*
|
||||
*Note Options Controlling the Kind of Output: Overall Options.
|
||||
-c -S -E -o FILE -pipe -v --help -x LANGUAGE
|
||||
|
||||
*C Language Options*
|
||||
*Note Options Controlling C Dialect: C Dialect Options.
|
||||
-ansi -flang-isoc9x -fallow-single-precision -fcond-mismatch -fno-asm
|
||||
-fno-builtin -ffreestanding -fhosted -fsigned-bitfields -fsigned-char
|
||||
-funsigned-bitfields -funsigned-char -fwritable-strings
|
||||
-traditional -traditional-cpp -trigraphs
|
||||
|
||||
*C++ Language Options*
|
||||
*Note Options Controlling C++ Dialect: C++ Dialect Options.
|
||||
-fno-access-control -fcheck-new -fconserve-space -fdollars-in-identifiers
|
||||
-fno-elide-constructors -fexternal-templates -ffor-scope
|
||||
-fno-for-scope -fno-gnu-keywords -fguiding-decls -fhandle-signatures
|
||||
-fhonor-std -fhuge-objects -fno-implicit-templates -finit-priority
|
||||
-fno-implement-inlines -fname-mangling-version-N -fno-default-inline
|
||||
-foperator-names -fno-optional-diags -fpermissive -frepo -fstrict-prototype
|
||||
-fsquangle -ftemplate-depth-N -fthis-is-variable -fvtable-thunks
|
||||
-nostdinc++ -Wctor-dtor-privacy -Wno-deprecated -Weffc++
|
||||
-Wno-non-template-friend
|
||||
-Wnon-virtual-dtor -Wold-style-cast -Woverloaded-virtual
|
||||
-Wno-pmf-conversions -Wreorder -Wsign-promo -Wsynth
|
||||
|
||||
*Warning Options*
|
||||
*Note Options to Request or Suppress Warnings: Warning Options.
|
||||
-fsyntax-only -pedantic -pedantic-errors
|
||||
-w -W -Wall -Waggregate-return -Wbad-function-cast
|
||||
-Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment
|
||||
-Wconversion -Werror -Wformat
|
||||
-Wid-clash-LEN -Wimplicit -Wimplicit-int
|
||||
-Wimplicit-function-declaration -Wimport
|
||||
-Werror-implicit-function-declaration -Winline
|
||||
-Wlarger-than-LEN -Wlong-long
|
||||
-Wmain -Wmissing-declarations -Wmissing-noreturn
|
||||
-Wmissing-prototypes -Wmultichar -Wnested-externs -Wno-import
|
||||
-Wparentheses -Wpointer-arith -Wredundant-decls
|
||||
-Wreturn-type -Wshadow -Wsign-compare -Wstrict-prototypes
|
||||
-Wswitch -Wtraditional
|
||||
-Wtrigraphs -Wundef -Wuninitialized -Wunused -Wwrite-strings
|
||||
-Wunknown-pragmas
|
||||
|
||||
*Debugging Options*
|
||||
*Note Options for Debugging Your Program or GCC: Debugging Options.
|
||||
-a -ax -dLETTERS -fdump-unnumbered -fpretend-float
|
||||
-fprofile-arcs -ftest-coverage
|
||||
-g -gLEVEL -gcoff -gdwarf -gdwarf-1 -gdwarf-1+ -gdwarf-2
|
||||
-ggdb -gstabs -gstabs+ -gxcoff -gxcoff+
|
||||
-p -pg -print-file-name=LIBRARY -print-libgcc-file-name
|
||||
-print-prog-name=PROGRAM -print-search-dirs -save-temps
|
||||
|
||||
*Optimization Options*
|
||||
*Note Options that Control Optimization: Optimize Options.
|
||||
-fbranch-probabilities -foptimize-register-moves
|
||||
-fcaller-saves -fcse-follow-jumps -fcse-skip-blocks
|
||||
-fdelayed-branch -fexpensive-optimizations
|
||||
-ffast-math -ffloat-store -fforce-addr -fforce-mem
|
||||
-fdata-sections -ffunction-sections -fgcse
|
||||
-finline-functions -finline-limit-N -fkeep-inline-functions
|
||||
-fno-default-inline -fno-defer-pop -fno-function-cse
|
||||
-fno-inline -fno-peephole -fomit-frame-pointer -fregmove
|
||||
-frerun-cse-after-loop -frerun-loop-opt -fschedule-insns
|
||||
-fschedule-insns2 -fstrength-reduce -fthread-jumps
|
||||
-funroll-all-loops -funroll-loops
|
||||
-fmove-all-movables -freduce-all-givs -fstrict-aliasing
|
||||
-O -O0 -O1 -O2 -O3 -Os
|
||||
|
||||
*Preprocessor Options*
|
||||
*Note Options Controlling the Preprocessor: Preprocessor Options.
|
||||
-AQUESTION(ANSWER) -C -dD -dM -dN
|
||||
-DMACRO[=DEFN] -E -H
|
||||
-idirafter DIR
|
||||
-include FILE -imacros FILE
|
||||
-iprefix FILE -iwithprefix DIR
|
||||
-iwithprefixbefore DIR -isystem DIR -isystem-c++ DIR
|
||||
-M -MD -MM -MMD -MG -nostdinc -P -trigraphs
|
||||
-undef -UMACRO -Wp,OPTION
|
||||
|
||||
*Assembler Option*
|
||||
*Note Passing Options to the Assembler: Assembler Options.
|
||||
-Wa,OPTION
|
||||
|
||||
*Linker Options*
|
||||
*Note Options for Linking: Link Options.
|
||||
OBJECT-FILE-NAME -lLIBRARY
|
||||
-nostartfiles -nodefaultlibs -nostdlib
|
||||
-s -static -shared -symbolic
|
||||
-Wl,OPTION -Xlinker OPTION
|
||||
-u SYMBOL
|
||||
|
||||
*Directory Options*
|
||||
*Note Options for Directory Search: Directory Options.
|
||||
-BPREFIX -IDIR -I- -LDIR -specs=FILE
|
||||
|
||||
*Target Options*
|
||||
*Note Target Options::.
|
||||
-b MACHINE -V VERSION
|
||||
|
||||
*Machine Dependent Options*
|
||||
*Note Hardware Models and Configurations: Submodel Options.
|
||||
*M680x0 Options*
|
||||
-m68000 -m68020 -m68020-40 -m68020-60 -m68030 -m68040
|
||||
-m68060 -mcpu32 -m5200 -m68881 -mbitfield -mc68000 -mc68020
|
||||
-mfpa -mnobitfield -mrtd -mshort -msoft-float
|
||||
-malign-int
|
||||
|
||||
*VAX Options*
|
||||
-mg -mgnu -munix
|
||||
|
||||
*SPARC Options*
|
||||
-mcpu=CPU TYPE
|
||||
-mtune=CPU TYPE
|
||||
-mcmodel=CODE MODEL
|
||||
-malign-jumps=NUM -malign-loops=NUM
|
||||
-malign-functions=NUM
|
||||
-m32 -m64
|
||||
-mapp-regs -mbroken-saverestore -mcypress -mepilogue
|
||||
-mflat -mfpu -mhard-float -mhard-quad-float
|
||||
-mimpure-text -mlive-g0 -mno-app-regs -mno-epilogue
|
||||
-mno-flat -mno-fpu -mno-impure-text
|
||||
-mno-stack-bias -mno-unaligned-doubles
|
||||
-msoft-float -msoft-quad-float -msparclite -mstack-bias
|
||||
-msupersparc -munaligned-doubles -mv8
|
||||
|
||||
*Convex Options*
|
||||
-mc1 -mc2 -mc32 -mc34 -mc38
|
||||
-margcount -mnoargcount
|
||||
-mlong32 -mlong64
|
||||
-mvolatile-cache -mvolatile-nocache
|
||||
|
||||
*AMD29K Options*
|
||||
-m29000 -m29050 -mbw -mnbw -mdw -mndw
|
||||
-mlarge -mnormal -msmall
|
||||
-mkernel-registers -mno-reuse-arg-regs
|
||||
-mno-stack-check -mno-storem-bug
|
||||
-mreuse-arg-regs -msoft-float -mstack-check
|
||||
-mstorem-bug -muser-registers
|
||||
|
||||
*ARM Options*
|
||||
-mapcs-frame -mno-apcs-frame
|
||||
-mapcs-26 -mapcs-32
|
||||
-mapcs-stack-check -mno-apcs-stack-check
|
||||
-mapcs-float -mno-apcs-float
|
||||
-mapcs-reentrant -mno-apcs-reentrant
|
||||
-msched-prolog -mno-sched-prolog
|
||||
-mlittle-endian -mbig-endian -mwords-little-endian
|
||||
-mshort-load-bytes -mno-short-load-bytes -mshort-load-words -mno-short-load-words
|
||||
-msoft-float -mhard-float -mfpe
|
||||
-mthumb-interwork -mno-thumb-interwork
|
||||
-mcpu= -march= -mfpe=
|
||||
-mstructure-size-boundary=
|
||||
-mbsd -mxopen -mno-symrename
|
||||
-mabort-on-noreturn
|
||||
-mno-sched-prolog
|
||||
|
||||
*Thumb Options*
|
||||
-mtpcs-frame -mno-tpcs-frame
|
||||
-mtpcs-leaf-frame -mno-tpcs-leaf-frame
|
||||
-mlittle-endian -mbig-endian
|
||||
-mthumb-interwork -mno-thumb-interwork
|
||||
-mstructure-size-boundary=
|
||||
|
||||
*MN10200 Options*
|
||||
-mrelax
|
||||
|
||||
*MN10300 Options*
|
||||
-mmult-bug
|
||||
-mno-mult-bug
|
||||
-mrelax
|
||||
|
||||
*M32R/D Options*
|
||||
-mcode-model=MODEL TYPE -msdata=SDATA TYPE
|
||||
-G NUM
|
||||
|
||||
*M88K Options*
|
||||
-m88000 -m88100 -m88110 -mbig-pic
|
||||
-mcheck-zero-division -mhandle-large-shift
|
||||
-midentify-revision -mno-check-zero-division
|
||||
-mno-ocs-debug-info -mno-ocs-frame-position
|
||||
-mno-optimize-arg-area -mno-serialize-volatile
|
||||
-mno-underscores -mocs-debug-info
|
||||
-mocs-frame-position -moptimize-arg-area
|
||||
-mserialize-volatile -mshort-data-NUM -msvr3
|
||||
-msvr4 -mtrap-large-shift -muse-div-instruction
|
||||
-mversion-03.00 -mwarn-passed-structs
|
||||
|
||||
*RS/6000 and PowerPC Options*
|
||||
-mcpu=CPU TYPE
|
||||
-mtune=CPU TYPE
|
||||
-mpower -mno-power -mpower2 -mno-power2
|
||||
-mpowerpc -mno-powerpc
|
||||
-mpowerpc-gpopt -mno-powerpc-gpopt
|
||||
-mpowerpc-gfxopt -mno-powerpc-gfxopt
|
||||
-mnew-mnemonics -mno-new-mnemonics
|
||||
-mfull-toc -mminimal-toc -mno-fop-in-toc -mno-sum-in-toc
|
||||
-maix64 -maix32 -mxl-call -mno-xl-call -mthreads -mpe
|
||||
-msoft-float -mhard-float -mmultiple -mno-multiple
|
||||
-mstring -mno-string -mupdate -mno-update
|
||||
-mfused-madd -mno-fused-madd -mbit-align -mno-bit-align
|
||||
-mstrict-align -mno-strict-align -mrelocatable
|
||||
-mno-relocatable -mrelocatable-lib -mno-relocatable-lib
|
||||
-mtoc -mno-toc -mlittle -mlittle-endian -mbig -mbig-endian
|
||||
-mcall-aix -mcall-sysv -mprototype -mno-prototype
|
||||
-msim -mmvme -mads -myellowknife -memb -msdata
|
||||
-msdata=OPT -G NUM
|
||||
|
||||
*RT Options*
|
||||
-mcall-lib-mul -mfp-arg-in-fpregs -mfp-arg-in-gregs
|
||||
-mfull-fp-blocks -mhc-struct-return -min-line-mul
|
||||
-mminimum-fp-blocks -mnohc-struct-return
|
||||
|
||||
*MIPS Options*
|
||||
-mabicalls -mcpu=CPU TYPE -membedded-data
|
||||
-membedded-pic -mfp32 -mfp64 -mgas -mgp32 -mgp64
|
||||
-mgpopt -mhalf-pic -mhard-float -mint64 -mips1
|
||||
-mips2 -mips3 -mips4 -mlong64 -mlong32 -mlong-calls -mmemcpy
|
||||
-mmips-as -mmips-tfile -mno-abicalls
|
||||
-mno-embedded-data -mno-embedded-pic
|
||||
-mno-gpopt -mno-long-calls
|
||||
-mno-memcpy -mno-mips-tfile -mno-rnames -mno-stats
|
||||
-mrnames -msoft-float
|
||||
-m4650 -msingle-float -mmad
|
||||
-mstats -EL -EB -G NUM -nocpp
|
||||
-mabi=32 -mabi=n32 -mabi=64 -mabi=eabi
|
||||
|
||||
*i386 Options*
|
||||
-mcpu=CPU TYPE
|
||||
-march=CPU TYPE
|
||||
-mieee-fp -mno-fancy-math-387
|
||||
-mno-fp-ret-in-387 -msoft-float -msvr3-shlib
|
||||
-mno-wide-multiply -mrtd -malign-double
|
||||
-mreg-alloc=LIST -mregparm=NUM
|
||||
-malign-jumps=NUM -malign-loops=NUM
|
||||
-malign-functions=NUM -mpreferred-stack-boundary=NUM
|
||||
|
||||
*HPPA Options*
|
||||
-march=ARCHITECTURE TYPE
|
||||
-mbig-switch -mdisable-fpregs -mdisable-indexing
|
||||
-mfast-indirect-calls -mgas -mjump-in-delay
|
||||
-mlong-load-store -mno-big-switch -mno-disable-fpregs
|
||||
-mno-disable-indexing -mno-fast-indirect-calls -mno-gas
|
||||
-mno-jump-in-delay -mno-long-load-store
|
||||
-mno-portable-runtime -mno-soft-float -mno-space
|
||||
-mno-space-regs -msoft-float -mpa-risc-1-0
|
||||
-mpa-risc-1-1 -mpa-risc-2-0 -mportable-runtime
|
||||
-mschedule=CPU TYPE -mspace -mspace-regs
|
||||
|
||||
*Intel 960 Options*
|
||||
-mCPU TYPE -masm-compat -mclean-linkage
|
||||
-mcode-align -mcomplex-addr -mleaf-procedures
|
||||
-mic-compat -mic2.0-compat -mic3.0-compat
|
||||
-mintel-asm -mno-clean-linkage -mno-code-align
|
||||
-mno-complex-addr -mno-leaf-procedures
|
||||
-mno-old-align -mno-strict-align -mno-tail-call
|
||||
-mnumerics -mold-align -msoft-float -mstrict-align
|
||||
-mtail-call
|
||||
|
||||
*DEC Alpha Options*
|
||||
-mfp-regs -mno-fp-regs -mno-soft-float -msoft-float
|
||||
-malpha-as -mgas
|
||||
-mieee -mieee-with-inexact -mieee-conformant
|
||||
-mfp-trap-mode=MODE -mfp-rounding-mode=MODE
|
||||
-mtrap-precision=MODE -mbuild-constants
|
||||
-mcpu=CPU TYPE
|
||||
-mbwx -mno-bwx -mcix -mno-cix -mmax -mno-max
|
||||
-mmemory-latency=TIME
|
||||
|
||||
*Clipper Options*
|
||||
-mc300 -mc400
|
||||
|
||||
*H8/300 Options*
|
||||
-mrelax -mh -ms -mint32 -malign-300
|
||||
|
||||
*SH Options*
|
||||
-m1 -m2 -m3 -m3e -mb -ml -mdalign -mrelax
|
||||
|
||||
*System V Options*
|
||||
-Qy -Qn -YP,PATHS -Ym,DIR
|
||||
|
||||
*ARC Options*
|
||||
-EB -EL
|
||||
-mmangle-cpu -mcpu=CPU -mtext=TEXT SECTION
|
||||
-mdata=DATA SECTION -mrodata=READONLY DATA SECTION
|
||||
|
||||
*TMS320C3x/C4x Options*
|
||||
-mcpu=CPU -mbig -msmall -mregparm -mmemparm
|
||||
-mfast-fix -mmpyi -mbk -mti -mdp-isr-reload
|
||||
-mrpts=COUNT -mrptb -mdb -mloop-unsigned
|
||||
-mparallel-insns -mparallel-mpy -mpreserve-float
|
||||
|
||||
*V850 Options*
|
||||
-mlong-calls -mno-long-calls -mep -mno-ep
|
||||
-mprolog-function -mno-prolog-function -mspace
|
||||
-mtda=N -msda=N -mzda=N
|
||||
-mv850 -mbig-switch
|
||||
|
||||
*NS32K Options*
|
||||
-m32032 -m32332 -m32532 -m32081 -m32381 -mmult-add -mnomult-add
|
||||
-msoft-float -mrtd -mnortd -mregparam -mnoregparam -msb -mnosb
|
||||
-mbitfield -mnobitfield -mhimem -mnohimem
|
||||
|
||||
*Code Generation Options*
|
||||
*Note Options for Code Generation Conventions: Code Gen Options.
|
||||
-fcall-saved-REG -fcall-used-REG
|
||||
-fexceptions -ffixed-REG -finhibit-size-directive
|
||||
-fcheck-memory-usage -fprefix-function-name
|
||||
-fno-common -fno-ident -fno-gnu-linker
|
||||
-fpcc-struct-return -fpic -fPIC
|
||||
-freg-struct-return -fshared-data -fshort-enums
|
||||
-fshort-double -fvolatile -fvolatile-global -fvolatile-static
|
||||
-fverbose-asm -fpack-struct -fstack-check
|
||||
-fargument-alias -fargument-noalias
|
||||
-fargument-noalias-global
|
||||
-fleading-underscore
|
||||
|
||||
* Menu:
|
||||
|
||||
* Overall Options:: Controlling the kind of output:
|
||||
an executable, object files, assembler files,
|
||||
or preprocessed source.
|
||||
* C Dialect Options:: Controlling the variant of C language compiled.
|
||||
* C++ Dialect Options:: Variations on C++.
|
||||
* Warning Options:: How picky should the compiler be?
|
||||
* Debugging Options:: Symbol tables, measurements, and debugging dumps.
|
||||
* Optimize Options:: How much optimization?
|
||||
* Preprocessor Options:: Controlling header files and macro definitions.
|
||||
Also, getting dependency information for Make.
|
||||
* Assembler Options:: Passing options to the assembler.
|
||||
* Link Options:: Specifying libraries and so on.
|
||||
* Directory Options:: Where to find header files and libraries.
|
||||
Where to find the compiler executable files.
|
||||
* Target Options:: Running a cross-compiler, or an old version of GCC.
|
||||
|
||||
|
||||
File: gcc.info, Node: Overall Options, Next: Invoking G++, Prev: Option Summary, Up: Invoking GCC
|
||||
|
||||
Options Controlling the Kind of Output
|
||||
======================================
|
||||
|
||||
Compilation can involve up to four stages: preprocessing, compilation
|
||||
proper, assembly and linking, always in that order. The first three
|
||||
stages apply to an individual source file, and end by producing an
|
||||
object file; linking combines all the object files (those newly
|
||||
compiled, and those specified as input) into an executable file.
|
||||
|
||||
For any given input file, the file name suffix determines what kind
|
||||
of compilation is done:
|
||||
|
||||
`FILE.c'
|
||||
C source code which must be preprocessed.
|
||||
|
||||
`FILE.i'
|
||||
C source code which should not be preprocessed.
|
||||
|
||||
`FILE.ii'
|
||||
C++ source code which should not be preprocessed.
|
||||
|
||||
`FILE.m'
|
||||
Objective-C source code. Note that you must link with the library
|
||||
`libobjc.a' to make an Objective-C program work.
|
||||
|
||||
`FILE.h'
|
||||
C header file (not to be compiled or linked).
|
||||
|
||||
`FILE.cc'
|
||||
`FILE.cxx'
|
||||
`FILE.cpp'
|
||||
`FILE.C'
|
||||
C++ source code which must be preprocessed. Note that in `.cxx',
|
||||
the last two letters must both be literally `x'. Likewise, `.C'
|
||||
refers to a literal capital C.
|
||||
|
||||
`FILE.s'
|
||||
Assembler code.
|
||||
|
||||
`FILE.S'
|
||||
Assembler code which must be preprocessed.
|
||||
|
||||
`OTHER'
|
||||
An object file to be fed straight into linking. Any file name
|
||||
with no recognized suffix is treated this way.
|
||||
|
||||
You can specify the input language explicitly with the `-x' option:
|
||||
|
||||
`-x LANGUAGE'
|
||||
Specify explicitly the LANGUAGE for the following input files
|
||||
(rather than letting the compiler choose a default based on the
|
||||
file name suffix). This option applies to all following input
|
||||
files until the next `-x' option. Possible values for LANGUAGE
|
||||
are:
|
||||
c objective-c c++
|
||||
c-header cpp-output c++-cpp-output
|
||||
assembler assembler-with-cpp
|
||||
|
||||
`-x none'
|
||||
Turn off any specification of a language, so that subsequent files
|
||||
are handled according to their file name suffixes (as they are if
|
||||
`-x' has not been used at all).
|
||||
|
||||
If you only want some of the stages of compilation, you can use `-x'
|
||||
(or filename suffixes) to tell `gcc' where to start, and one of the
|
||||
options `-c', `-S', or `-E' to say where `gcc' is to stop. Note that
|
||||
some combinations (for example, `-x cpp-output -E' instruct `gcc' to do
|
||||
nothing at all.
|
||||
|
||||
`-c'
|
||||
Compile or assemble the source files, but do not link. The linking
|
||||
stage simply is not done. The ultimate output is in the form of an
|
||||
object file for each source file.
|
||||
|
||||
By default, the object file name for a source file is made by
|
||||
replacing the suffix `.c', `.i', `.s', etc., with `.o'.
|
||||
|
||||
Unrecognized input files, not requiring compilation or assembly,
|
||||
are ignored.
|
||||
|
||||
`-S'
|
||||
Stop after the stage of compilation proper; do not assemble. The
|
||||
output is in the form of an assembler code file for each
|
||||
non-assembler input file specified.
|
||||
|
||||
By default, the assembler file name for a source file is made by
|
||||
replacing the suffix `.c', `.i', etc., with `.s'.
|
||||
|
||||
Input files that don't require compilation are ignored.
|
||||
|
||||
`-E'
|
||||
Stop after the preprocessing stage; do not run the compiler
|
||||
proper. The output is in the form of preprocessed source code,
|
||||
which is sent to the standard output.
|
||||
|
||||
Input files which don't require preprocessing are ignored.
|
||||
|
||||
`-o FILE'
|
||||
Place output in file FILE. This applies regardless to whatever
|
||||
sort of output is being produced, whether it be an executable file,
|
||||
an object file, an assembler file or preprocessed C code.
|
||||
|
||||
Since only one output file can be specified, it does not make
|
||||
sense to use `-o' when compiling more than one input file, unless
|
||||
you are producing an executable file as output.
|
||||
|
||||
If `-o' is not specified, the default is to put an executable file
|
||||
in `a.out', the object file for `SOURCE.SUFFIX' in `SOURCE.o', its
|
||||
assembler file in `SOURCE.s', and all preprocessed C source on
|
||||
standard output.
|
||||
|
||||
`-v'
|
||||
Print (on standard error output) the commands executed to run the
|
||||
stages of compilation. Also print the version number of the
|
||||
compiler driver program and of the preprocessor and the compiler
|
||||
proper.
|
||||
|
||||
`-pipe'
|
||||
Use pipes rather than temporary files for communication between the
|
||||
various stages of compilation. This fails to work on some systems
|
||||
where the assembler is unable to read from a pipe; but the GNU
|
||||
assembler has no trouble.
|
||||
|
||||
`--help'
|
||||
Print (on the standard output) a description of the command line
|
||||
options understood by `gcc'. If the `-v' option is also specified
|
||||
then `--help' will also be passed on to the various processes
|
||||
invoked by `gcc', so that they can display the command line options
|
||||
they accept. If the `-W' option is also specified then command
|
||||
line options which have no documentation associated with them will
|
||||
also be displayed.
|
||||
|
||||
|
||||
File: gcc.info, Node: Invoking G++, Next: C Dialect Options, Prev: Overall Options, Up: Invoking GCC
|
||||
|
||||
Compiling C++ Programs
|
||||
======================
|
||||
|
||||
C++ source files conventionally use one of the suffixes `.C', `.cc',
|
||||
`.cpp', `.c++', `.cp', or `.cxx'; preprocessed C++ files use the suffix
|
||||
`.ii'. GCC recognizes files with these names and compiles them as C++
|
||||
programs even if you call the compiler the same way as for compiling C
|
||||
programs (usually with the name `gcc').
|
||||
|
||||
However, C++ programs often require class libraries as well as a
|
||||
compiler that understands the C++ language--and under some
|
||||
circumstances, you might want to compile programs from standard input,
|
||||
or otherwise without a suffix that flags them as C++ programs. `g++'
|
||||
is a program that calls GCC with the default language set to C++, and
|
||||
automatically specifies linking against the C++ library. On many
|
||||
systems, the script `g++' is also installed with the name `c++'.
|
||||
|
||||
When you compile C++ programs, you may specify many of the same
|
||||
command-line options that you use for compiling programs in any
|
||||
language; or command-line options meaningful for C and related
|
||||
languages; or options that are meaningful only for C++ programs. *Note
|
||||
Options Controlling C Dialect: C Dialect Options, for explanations of
|
||||
options for languages related to C. *Note Options Controlling C++
|
||||
Dialect: C++ Dialect Options, for explanations of options that are
|
||||
meaningful only for C++ programs.
|
||||
|
||||
|
||||
File: gcc.info, Node: C Dialect Options, Next: C++ Dialect Options, Prev: Invoking G++, Up: Invoking GCC
|
||||
|
||||
Options Controlling C Dialect
|
||||
=============================
|
||||
|
||||
The following options control the dialect of C (or languages derived
|
||||
from C, such as C++ and Objective C) that the compiler accepts:
|
||||
|
||||
`-ansi'
|
||||
In C mode, support all ANSI standard C programs. In C++ mode,
|
||||
remove GNU extensions that conflict with ANSI C++.
|
||||
|
||||
This turns off certain features of GCC that are incompatible with
|
||||
ANSI C (when compiling C code), or of ANSI standard C++ (when
|
||||
compiling C++ code), such as the `asm' and `typeof' keywords, and
|
||||
predefined macros such as `unix' and `vax' that identify the type
|
||||
of system you are using. It also enables the undesirable and
|
||||
rarely used ANSI trigraph feature. For the C compiler, it
|
||||
disables recognition of C++ style `//' comments as well as the
|
||||
`inline' keyword. For the C++ compiler, `-foperator-names' is
|
||||
enabled as well.
|
||||
|
||||
The alternate keywords `__asm__', `__extension__', `__inline__'
|
||||
and `__typeof__' continue to work despite `-ansi'. You would not
|
||||
want to use them in an ANSI C program, of course, but it is useful
|
||||
to put them in header files that might be included in compilations
|
||||
done with `-ansi'. Alternate predefined macros such as `__unix__'
|
||||
and `__vax__' are also available, with or without `-ansi'.
|
||||
|
||||
The `-ansi' option does not cause non-ANSI programs to be rejected
|
||||
gratuitously. For that, `-pedantic' is required in addition to
|
||||
`-ansi'. *Note Warning Options::.
|
||||
|
||||
The macro `__STRICT_ANSI__' is predefined when the `-ansi' option
|
||||
is used. Some header files may notice this macro and refrain from
|
||||
declaring certain functions or defining certain macros that the
|
||||
ANSI standard doesn't call for; this is to avoid interfering with
|
||||
any programs that might use these names for other things.
|
||||
|
||||
The functions `alloca', `abort', `exit', and `_exit' are not
|
||||
builtin functions when `-ansi' is used.
|
||||
|
||||
`-flang-isoc9x'
|
||||
Enable support for features found in the C9X standard. In
|
||||
particular, enable support for the C9X `restrict' keyword.
|
||||
|
||||
Even when this option is not specified, you can still use some C9X
|
||||
features in so far as they do not conflict with previous C
|
||||
standards. For example, you may use `__restrict__' even when
|
||||
-flang-isoc9x is not specified.
|
||||
|
||||
`-fno-asm'
|
||||
Do not recognize `asm', `inline' or `typeof' as a keyword, so that
|
||||
code can use these words as identifiers. You can use the keywords
|
||||
`__asm__', `__inline__' and `__typeof__' instead. `-ansi' implies
|
||||
`-fno-asm'.
|
||||
|
||||
In C++, this switch only affects the `typeof' keyword, since `asm'
|
||||
and `inline' are standard keywords. You may want to use the
|
||||
`-fno-gnu-keywords' flag instead, as it also disables the other,
|
||||
C++-specific, extension keywords such as `headof'.
|
||||
|
||||
`-fno-builtin'
|
||||
Don't recognize builtin functions that do not begin with
|
||||
`__builtin_' as prefix. Currently, the functions affected include
|
||||
`abort', `abs', `alloca', `cos', `exit', `fabs', `ffs', `labs',
|
||||
`memcmp', `memcpy', `sin', `sqrt', `strcmp', `strcpy', and
|
||||
`strlen'.
|
||||
|
||||
GCC normally generates special code to handle certain builtin
|
||||
functions more efficiently; for instance, calls to `alloca' may
|
||||
become single instructions that adjust the stack directly, and
|
||||
calls to `memcpy' may become inline copy loops. The resulting
|
||||
code is often both smaller and faster, but since the function
|
||||
calls no longer appear as such, you cannot set a breakpoint on
|
||||
those calls, nor can you change the behavior of the functions by
|
||||
linking with a different library.
|
||||
|
||||
The `-ansi' option prevents `alloca' and `ffs' from being builtin
|
||||
functions, since these functions do not have an ANSI standard
|
||||
meaning.
|
||||
|
||||
`-fhosted'
|
||||
Assert that compilation takes place in a hosted environment. This
|
||||
implies `-fbuiltin'. A hosted environment is one in which the
|
||||
entire standard library is available, and in which `main' has a
|
||||
return type of `int'. Examples are nearly everything except a
|
||||
kernel. This is equivalent to `-fno-freestanding'.
|
||||
|
||||
`-ffreestanding'
|
||||
Assert that compilation takes place in a freestanding environment.
|
||||
This implies `-fno-builtin'. A freestanding environment is one
|
||||
in which the standard library may not exist, and program startup
|
||||
may not necessarily be at `main'. The most obvious example is an
|
||||
OS kernel. This is equivalent to `-fno-hosted'.
|
||||
|
||||
`-trigraphs'
|
||||
Support ANSI C trigraphs. You don't want to know about this
|
||||
brain-damage. The `-ansi' option implies `-trigraphs'.
|
||||
|
||||
`-traditional'
|
||||
Attempt to support some aspects of traditional C compilers.
|
||||
Specifically:
|
||||
|
||||
* All `extern' declarations take effect globally even if they
|
||||
are written inside of a function definition. This includes
|
||||
implicit declarations of functions.
|
||||
|
||||
* The newer keywords `typeof', `inline', `signed', `const' and
|
||||
`volatile' are not recognized. (You can still use the
|
||||
alternative keywords such as `__typeof__', `__inline__', and
|
||||
so on.)
|
||||
|
||||
* Comparisons between pointers and integers are always allowed.
|
||||
|
||||
* Integer types `unsigned short' and `unsigned char' promote to
|
||||
`unsigned int'.
|
||||
|
||||
* Out-of-range floating point literals are not an error.
|
||||
|
||||
* Certain constructs which ANSI regards as a single invalid
|
||||
preprocessing number, such as `0xe-0xd', are treated as
|
||||
expressions instead.
|
||||
|
||||
* String "constants" are not necessarily constant; they are
|
||||
stored in writable space, and identical looking constants are
|
||||
allocated separately. (This is the same as the effect of
|
||||
`-fwritable-strings'.)
|
||||
|
||||
* All automatic variables not declared `register' are preserved
|
||||
by `longjmp'. Ordinarily, GNU C follows ANSI C: automatic
|
||||
variables not declared `volatile' may be clobbered.
|
||||
|
||||
* The character escape sequences `\x' and `\a' evaluate as the
|
||||
literal characters `x' and `a' respectively. Without
|
||||
`-traditional', `\x' is a prefix for the hexadecimal
|
||||
representation of a character, and `\a' produces a bell.
|
||||
|
||||
You may wish to use `-fno-builtin' as well as `-traditional' if
|
||||
your program uses names that are normally GNU C builtin functions
|
||||
for other purposes of its own.
|
||||
|
||||
You cannot use `-traditional' if you include any header files that
|
||||
rely on ANSI C features. Some vendors are starting to ship
|
||||
systems with ANSI C header files and you cannot use `-traditional'
|
||||
on such systems to compile files that include any system headers.
|
||||
|
||||
The `-traditional' option also enables `-traditional-cpp', which
|
||||
is described next.
|
||||
|
||||
`-traditional-cpp'
|
||||
Attempt to support some aspects of traditional C preprocessors.
|
||||
Specifically:
|
||||
|
||||
* Comments convert to nothing at all, rather than to a space.
|
||||
This allows traditional token concatenation.
|
||||
|
||||
* In a preprocessing directive, the `#' symbol must appear as
|
||||
the first character of a line.
|
||||
|
||||
* Macro arguments are recognized within string constants in a
|
||||
macro definition (and their values are stringified, though
|
||||
without additional quote marks, when they appear in such a
|
||||
context). The preprocessor always considers a string
|
||||
constant to end at a newline.
|
||||
|
||||
* The predefined macro `__STDC__' is not defined when you use
|
||||
`-traditional', but `__GNUC__' is (since the GNU extensions
|
||||
which `__GNUC__' indicates are not affected by
|
||||
`-traditional'). If you need to write header files that work
|
||||
differently depending on whether `-traditional' is in use, by
|
||||
testing both of these predefined macros you can distinguish
|
||||
four situations: GNU C, traditional GNU C, other ANSI C
|
||||
compilers, and other old C compilers. The predefined macro
|
||||
`__STDC_VERSION__' is also not defined when you use
|
||||
`-traditional'. *Note Standard Predefined Macros:
|
||||
(cpp.info)Standard Predefined, for more discussion of these
|
||||
and other predefined macros.
|
||||
|
||||
* The preprocessor considers a string constant to end at a
|
||||
newline (unless the newline is escaped with `\'). (Without
|
||||
`-traditional', string constants can contain the newline
|
||||
character as typed.)
|
||||
|
||||
`-fcond-mismatch'
|
||||
Allow conditional expressions with mismatched types in the second
|
||||
and third arguments. The value of such an expression is void.
|
||||
|
||||
`-funsigned-char'
|
||||
Let the type `char' be unsigned, like `unsigned char'.
|
||||
|
||||
Each kind of machine has a default for what `char' should be. It
|
||||
is either like `unsigned char' by default or like `signed char' by
|
||||
default.
|
||||
|
||||
Ideally, a portable program should always use `signed char' or
|
||||
`unsigned char' when it depends on the signedness of an object.
|
||||
But many programs have been written to use plain `char' and expect
|
||||
it to be signed, or expect it to be unsigned, depending on the
|
||||
machines they were written for. This option, and its inverse, let
|
||||
you make such a program work with the opposite default.
|
||||
|
||||
The type `char' is always a distinct type from each of `signed
|
||||
char' or `unsigned char', even though its behavior is always just
|
||||
like one of those two.
|
||||
|
||||
`-fsigned-char'
|
||||
Let the type `char' be signed, like `signed char'.
|
||||
|
||||
Note that this is equivalent to `-fno-unsigned-char', which is the
|
||||
negative form of `-funsigned-char'. Likewise, the option
|
||||
`-fno-signed-char' is equivalent to `-funsigned-char'.
|
||||
|
||||
You may wish to use `-fno-builtin' as well as `-traditional' if
|
||||
your program uses names that are normally GNU C builtin functions
|
||||
for other purposes of its own.
|
||||
|
||||
You cannot use `-traditional' if you include any header files that
|
||||
rely on ANSI C features. Some vendors are starting to ship
|
||||
systems with ANSI C header files and you cannot use `-traditional'
|
||||
on such systems to compile files that include any system headers.
|
||||
|
||||
`-fsigned-bitfields'
|
||||
`-funsigned-bitfields'
|
||||
`-fno-signed-bitfields'
|
||||
`-fno-unsigned-bitfields'
|
||||
These options control whether a bitfield is signed or unsigned,
|
||||
when the declaration does not use either `signed' or `unsigned'.
|
||||
By default, such a bitfield is signed, because this is consistent:
|
||||
the basic integer types such as `int' are signed types.
|
||||
|
||||
However, when `-traditional' is used, bitfields are all unsigned
|
||||
no matter what.
|
||||
|
||||
`-fwritable-strings'
|
||||
Store string constants in the writable data segment and don't
|
||||
uniquize them. This is for compatibility with old programs which
|
||||
assume they can write into string constants. The option
|
||||
`-traditional' also has this effect.
|
||||
|
||||
Writing into string constants is a very bad idea; "constants"
|
||||
should be constant.
|
||||
|
||||
`-fallow-single-precision'
|
||||
Do not promote single precision math operations to double
|
||||
precision, even when compiling with `-traditional'.
|
||||
|
||||
Traditional K&R C promotes all floating point operations to double
|
||||
precision, regardless of the sizes of the operands. On the
|
||||
architecture for which you are compiling, single precision may be
|
||||
faster than double precision. If you must use `-traditional',
|
||||
but want to use single precision operations when the operands are
|
||||
single precision, use this option. This option has no effect
|
||||
when compiling with ANSI or GNU C conventions (the default).
|
||||
|
||||
Executable
+1065
File diff suppressed because it is too large
Load Diff
Executable
+1065
File diff suppressed because it is too large
Load Diff
Executable
+965
@@ -0,0 +1,965 @@
|
||||
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
|
||||
input file ../../gcc-2.95.2/gcc/gcc.texi.
|
||||
|
||||
INFO-DIR-SECTION Programming
|
||||
START-INFO-DIR-ENTRY
|
||||
* gcc: (gcc). The GNU Compiler Collection.
|
||||
END-INFO-DIR-ENTRY
|
||||
This file documents the use and the internals of the GNU compiler.
|
||||
|
||||
Published by the Free Software Foundation 59 Temple Place - Suite 330
|
||||
Boston, MA 02111-1307 USA
|
||||
|
||||
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
|
||||
1999 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 "Funding
|
||||
for Free Software" 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 one.
|
||||
|
||||
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 "Funding for Free Software", 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: 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 compiler that
|
||||
combined an "elision" algorithm with interprocedural data flow analysis
|
||||
could conceivably eliminate all of this, it is much more practical to
|
||||
allow you to assist the compiler in generating efficient code by
|
||||
manipulating the return value explicitly, thus avoiding the local
|
||||
variable and copy constructor altogether.
|
||||
|
||||
Using the extended GNU C++ function-definition syntax, you can avoid
|
||||
the temporary allocation and copying by naming `r' as your return value
|
||||
at the outset, and assigning to its `a' field directly:
|
||||
|
||||
X
|
||||
m () return r;
|
||||
{
|
||||
r.a = 23;
|
||||
}
|
||||
|
||||
The declaration of `r' is a standard, proper declaration, whose effects
|
||||
are executed *before* any of the body of `m'.
|
||||
|
||||
Functions of this type impose no additional restrictions; in
|
||||
particular, you can execute `return' statements, or return implicitly by
|
||||
reaching the end of the function body ("falling off the edge"). Cases
|
||||
like
|
||||
|
||||
X
|
||||
m () return r (23);
|
||||
{
|
||||
return;
|
||||
}
|
||||
|
||||
(or even `X m () return r (23); { }') are unambiguous, since the return
|
||||
value `r' has been initialized in either case. The following code may
|
||||
be hard to read, but also works predictably:
|
||||
|
||||
X
|
||||
m () return r;
|
||||
{
|
||||
X b;
|
||||
return b;
|
||||
}
|
||||
|
||||
The return value slot denoted by `r' is initialized at the outset,
|
||||
but the statement `return b;' overrides this value. The compiler deals
|
||||
with this by destroying `r' (calling the destructor if there is one, or
|
||||
doing nothing if there is not), and then reinitializing `r' with `b'.
|
||||
|
||||
This extension is provided primarily to help people who use
|
||||
overloaded operators, where there is a great need to control not just
|
||||
the arguments, but the return values of functions. For classes where
|
||||
the copy constructor incurs a heavy performance penalty (especially in
|
||||
the common case where there is a quick default constructor), this is a
|
||||
major savings. The disadvantage of this extension is that you do not
|
||||
control when the default constructor for the return value is called: it
|
||||
is always called at the beginning.
|
||||
|
||||
|
||||
File: gcc.info, Node: Min and Max, Next: Destructors and Goto, Prev: Naming Results, Up: C++ Extensions
|
||||
|
||||
Minimum and Maximum Operators in C++
|
||||
====================================
|
||||
|
||||
It is very convenient to have operators which return the "minimum"
|
||||
or the "maximum" of two arguments. In GNU C++ (but not in GNU C),
|
||||
|
||||
`A <? B'
|
||||
is the "minimum", returning the smaller of the numeric values A
|
||||
and B;
|
||||
|
||||
`A >? B'
|
||||
is the "maximum", returning the larger of the numeric values A and
|
||||
B.
|
||||
|
||||
These operations are not primitive in ordinary C++, since you can
|
||||
use a macro to return the minimum of two things in C++, as in the
|
||||
following example.
|
||||
|
||||
#define MIN(X,Y) ((X) < (Y) ? : (X) : (Y))
|
||||
|
||||
You might then use `int min = MIN (i, j);' to set MIN to the minimum
|
||||
value of variables I and J.
|
||||
|
||||
However, side effects in `X' or `Y' may cause unintended behavior.
|
||||
For example, `MIN (i++, j++)' will fail, incrementing the smaller
|
||||
counter twice. A GNU C extension allows you to write safe macros that
|
||||
avoid this kind of problem (*note Naming an Expression's Type: Naming
|
||||
Types.). However, writing `MIN' and `MAX' as macros also forces you to
|
||||
use function-call notation for a fundamental arithmetic operation.
|
||||
Using GNU C++ extensions, you can write `int min = i <? j;' instead.
|
||||
|
||||
Since `<?' and `>?' are built into the compiler, they properly
|
||||
handle expressions with side-effects; `int min = i++ <? j++;' works
|
||||
correctly.
|
||||
|
||||
|
||||
File: gcc.info, Node: Destructors and Goto, Next: C++ Interface, Prev: Min and Max, Up: C++ Extensions
|
||||
|
||||
`goto' and Destructors in GNU C++
|
||||
=================================
|
||||
|
||||
In C++ programs, you can safely use the `goto' statement. When you
|
||||
use it to exit a block which contains aggregates requiring destructors,
|
||||
the destructors will run before the `goto' transfers control.
|
||||
|
||||
The compiler still forbids using `goto' to *enter* a scope that
|
||||
requires constructors.
|
||||
|
||||
|
||||
File: gcc.info, Node: C++ Interface, Next: Template Instantiation, Prev: Destructors and Goto, Up: C++ Extensions
|
||||
|
||||
Declarations and Definitions in One Header
|
||||
==========================================
|
||||
|
||||
C++ object definitions can be quite complex. In principle, your
|
||||
source code will need two kinds of things for each object that you use
|
||||
across more than one source file. First, you need an "interface"
|
||||
specification, describing its structure with type declarations and
|
||||
function prototypes. Second, you need the "implementation" itself. It
|
||||
can be tedious to maintain a separate interface description in a header
|
||||
file, in parallel to the actual implementation. It is also dangerous,
|
||||
since separate interface and implementation definitions may not remain
|
||||
parallel.
|
||||
|
||||
With GNU C++, you can use a single header file for both purposes.
|
||||
|
||||
*Warning:* The mechanism to specify this is in transition. For the
|
||||
nonce, you must use one of two `#pragma' commands; in a future
|
||||
release of GNU C++, an alternative mechanism will make these
|
||||
`#pragma' commands unnecessary.
|
||||
|
||||
The header file contains the full definitions, but is marked with
|
||||
`#pragma interface' in the source code. This allows the compiler to
|
||||
use the header file only as an interface specification when ordinary
|
||||
source files incorporate it with `#include'. In the single source file
|
||||
where the full implementation belongs, you can use either a naming
|
||||
convention or `#pragma implementation' to indicate this alternate use
|
||||
of the header file.
|
||||
|
||||
`#pragma interface'
|
||||
`#pragma interface "SUBDIR/OBJECTS.h"'
|
||||
Use this directive in *header files* that define object classes,
|
||||
to save space in most of the object files that use those classes.
|
||||
Normally, local copies of certain information (backup copies of
|
||||
inline member functions, debugging information, and the internal
|
||||
tables that implement virtual functions) must be kept in each
|
||||
object file that includes class definitions. You can use this
|
||||
pragma to avoid such duplication. When a header file containing
|
||||
`#pragma interface' is included in a compilation, this auxiliary
|
||||
information will not be generated (unless the main input source
|
||||
file itself uses `#pragma implementation'). Instead, the object
|
||||
files will contain references to be resolved at link time.
|
||||
|
||||
The second form of this directive is useful for the case where you
|
||||
have multiple headers with the same name in different directories.
|
||||
If you use this form, you must specify the same string to `#pragma
|
||||
implementation'.
|
||||
|
||||
`#pragma implementation'
|
||||
`#pragma implementation "OBJECTS.h"'
|
||||
Use this pragma in a *main input file*, when you want full output
|
||||
from included header files to be generated (and made globally
|
||||
visible). The included header file, in turn, should use `#pragma
|
||||
interface'. Backup copies of inline member functions, debugging
|
||||
information, and the internal tables used to implement virtual
|
||||
functions are all generated in implementation files.
|
||||
|
||||
If you use `#pragma implementation' with no argument, it applies to
|
||||
an include file with the same basename(1) as your source file.
|
||||
For example, in `allclass.cc', giving just `#pragma implementation'
|
||||
by itself is equivalent to `#pragma implementation "allclass.h"'.
|
||||
|
||||
In versions of GNU C++ prior to 2.6.0 `allclass.h' was treated as
|
||||
an implementation file whenever you would include it from
|
||||
`allclass.cc' even if you never specified `#pragma
|
||||
implementation'. This was deemed to be more trouble than it was
|
||||
worth, however, and disabled.
|
||||
|
||||
If you use an explicit `#pragma implementation', it must appear in
|
||||
your source file *before* you include the affected header files.
|
||||
|
||||
Use the string argument if you want a single implementation file to
|
||||
include code from multiple header files. (You must also use
|
||||
`#include' to include the header file; `#pragma implementation'
|
||||
only specifies how to use the file--it doesn't actually include
|
||||
it.)
|
||||
|
||||
There is no way to split up the contents of a single header file
|
||||
into multiple implementation files.
|
||||
|
||||
`#pragma implementation' and `#pragma interface' also have an effect
|
||||
on function inlining.
|
||||
|
||||
If you define a class in a header file marked with `#pragma
|
||||
interface', the effect on a function defined in that class is similar to
|
||||
an explicit `extern' declaration--the compiler emits no code at all to
|
||||
define an independent version of the function. Its definition is used
|
||||
only for inlining with its callers.
|
||||
|
||||
Conversely, when you include the same header file in a main source
|
||||
file that declares it as `#pragma implementation', the compiler emits
|
||||
code for the function itself; this defines a version of the function
|
||||
that can be found via pointers (or by callers compiled without
|
||||
inlining). If all calls to the function can be inlined, you can avoid
|
||||
emitting the function by compiling with `-fno-implement-inlines'. If
|
||||
any calls were not inlined, you will get linker errors.
|
||||
|
||||
---------- Footnotes ----------
|
||||
|
||||
(1) A file's "basename" was the name stripped of all leading path
|
||||
information and of trailing suffixes, such as `.h' or `.C' or `.cc'.
|
||||
|
||||
|
||||
File: gcc.info, Node: Template Instantiation, Next: Bound member functions, Prev: C++ Interface, Up: C++ Extensions
|
||||
|
||||
Where's the Template?
|
||||
=====================
|
||||
|
||||
C++ templates are the first language feature to require more
|
||||
intelligence from the environment than one usually finds on a UNIX
|
||||
system. Somehow the compiler and linker have to make sure that each
|
||||
template instance occurs exactly once in the executable if it is needed,
|
||||
and not at all otherwise. There are two basic approaches to this
|
||||
problem, which I will refer to as the Borland model and the Cfront
|
||||
model.
|
||||
|
||||
Borland model
|
||||
Borland C++ solved the template instantiation problem by adding
|
||||
the code equivalent of common blocks to their linker; the compiler
|
||||
emits template instances in each translation unit that uses them,
|
||||
and the linker collapses them together. The advantage of this
|
||||
model is that the linker only has to consider the object files
|
||||
themselves; there is no external complexity to worry about. This
|
||||
disadvantage is that compilation time is increased because the
|
||||
template code is being compiled repeatedly. Code written for this
|
||||
model tends to include definitions of all templates in the header
|
||||
file, since they must be seen to be instantiated.
|
||||
|
||||
Cfront model
|
||||
The AT&T C++ translator, Cfront, solved the template instantiation
|
||||
problem by creating the notion of a template repository, an
|
||||
automatically maintained place where template instances are
|
||||
stored. A more modern version of the repository works as follows:
|
||||
As individual object files are built, the compiler places any
|
||||
template definitions and instantiations encountered in the
|
||||
repository. At link time, the link wrapper adds in the objects in
|
||||
the repository and compiles any needed instances that were not
|
||||
previously emitted. The advantages of this model are more optimal
|
||||
compilation speed and the ability to use the system linker; to
|
||||
implement the Borland model a compiler vendor also needs to
|
||||
replace the linker. The disadvantages are vastly increased
|
||||
complexity, and thus potential for error; for some code this can be
|
||||
just as transparent, but in practice it can been very difficult to
|
||||
build multiple programs in one directory and one program in
|
||||
multiple directories. Code written for this model tends to
|
||||
separate definitions of non-inline member templates into a
|
||||
separate file, which should be compiled separately.
|
||||
|
||||
When used with GNU ld version 2.8 or later on an ELF system such as
|
||||
Linux/GNU or Solaris 2, or on Microsoft Windows, g++ supports the
|
||||
Borland model. On other systems, g++ implements neither automatic
|
||||
model.
|
||||
|
||||
A future version of g++ will support a hybrid model whereby the
|
||||
compiler will emit any instantiations for which the template definition
|
||||
is included in the compile, and store template definitions and
|
||||
instantiation context information into the object file for the rest.
|
||||
The link wrapper will extract that information as necessary and invoke
|
||||
the compiler to produce the remaining instantiations. The linker will
|
||||
then combine duplicate instantiations.
|
||||
|
||||
In the mean time, you have the following options for dealing with
|
||||
template instantiations:
|
||||
|
||||
1. Compile your template-using code with `-frepo'. The compiler will
|
||||
generate files with the extension `.rpo' listing all of the
|
||||
template instantiations used in the corresponding object files
|
||||
which could be instantiated there; the link wrapper, `collect2',
|
||||
will then update the `.rpo' files to tell the compiler where to
|
||||
place those instantiations and rebuild any affected object files.
|
||||
The link-time overhead is negligible after the first pass, as the
|
||||
compiler will continue to place the instantiations in the same
|
||||
files.
|
||||
|
||||
This is your best option for application code written for the
|
||||
Borland model, as it will just work. Code written for the Cfront
|
||||
model will need to be modified so that the template definitions
|
||||
are available at one or more points of instantiation; usually this
|
||||
is as simple as adding `#include <tmethods.cc>' to the end of each
|
||||
template header.
|
||||
|
||||
For library code, if you want the library to provide all of the
|
||||
template instantiations it needs, just try to link all of its
|
||||
object files together; the link will fail, but cause the
|
||||
instantiations to be generated as a side effect. Be warned,
|
||||
however, that this may cause conflicts if multiple libraries try
|
||||
to provide the same instantiations. For greater control, use
|
||||
explicit instantiation as described in the next option.
|
||||
|
||||
2. Compile your code with `-fno-implicit-templates' to disable the
|
||||
implicit generation of template instances, and explicitly
|
||||
instantiate all the ones you use. This approach requires more
|
||||
knowledge of exactly which instances you need than do the others,
|
||||
but it's less mysterious and allows greater control. You can
|
||||
scatter the explicit instantiations throughout your program,
|
||||
perhaps putting them in the translation units where the instances
|
||||
are used or the translation units that define the templates
|
||||
themselves; you can put all of the explicit instantiations you
|
||||
need into one big file; or you can create small files like
|
||||
|
||||
#include "Foo.h"
|
||||
#include "Foo.cc"
|
||||
|
||||
template class Foo<int>;
|
||||
template ostream& operator <<
|
||||
(ostream&, const Foo<int>&);
|
||||
|
||||
for each of the instances you need, and create a template
|
||||
instantiation library from those.
|
||||
|
||||
If you are using Cfront-model code, you can probably get away with
|
||||
not using `-fno-implicit-templates' when compiling files that don't
|
||||
`#include' the member template definitions.
|
||||
|
||||
If you use one big file to do the instantiations, you may want to
|
||||
compile it without `-fno-implicit-templates' so you get all of the
|
||||
instances required by your explicit instantiations (but not by any
|
||||
other files) without having to specify them as well.
|
||||
|
||||
g++ has extended the template instantiation syntax outlined in the
|
||||
Working Paper to allow forward declaration of explicit
|
||||
instantiations and instantiation of the compiler support data for
|
||||
a template class (i.e. the vtable) without instantiating any of
|
||||
its members:
|
||||
|
||||
extern template int max (int, int);
|
||||
inline template class Foo<int>;
|
||||
|
||||
3. Do nothing. Pretend g++ does implement automatic instantiation
|
||||
management. Code written for the Borland model will work fine, but
|
||||
each translation unit will contain instances of each of the
|
||||
templates it uses. In a large program, this can lead to an
|
||||
unacceptable amount of code duplication.
|
||||
|
||||
4. Add `#pragma interface' to all files containing template
|
||||
definitions. For each of these files, add `#pragma implementation
|
||||
"FILENAME"' to the top of some `.C' file which `#include's it.
|
||||
Then compile everything with `-fexternal-templates'. The
|
||||
templates will then only be expanded in the translation unit which
|
||||
implements them (i.e. has a `#pragma implementation' line for the
|
||||
file where they live); all other files will use external
|
||||
references. If you're lucky, everything should work properly. If
|
||||
you get undefined symbol errors, you need to make sure that each
|
||||
template instance which is used in the program is used in the file
|
||||
which implements that template. If you don't have any use for a
|
||||
particular instance in that file, you can just instantiate it
|
||||
explicitly, using the syntax from the latest C++ working paper:
|
||||
|
||||
template class A<int>;
|
||||
template ostream& operator << (ostream&, const A<int>&);
|
||||
|
||||
This strategy will work with code written for either model. If
|
||||
you are using code written for the Cfront model, the file
|
||||
containing a class template and the file containing its member
|
||||
templates should be implemented in the same translation unit.
|
||||
|
||||
A slight variation on this approach is to instead use the flag
|
||||
`-falt-external-templates'; this flag causes template instances to
|
||||
be emitted in the translation unit that implements the header
|
||||
where they are first instantiated, rather than the one which
|
||||
implements the file where the templates are defined. This header
|
||||
must be the same in all translation units, or things are likely to
|
||||
break.
|
||||
|
||||
*Note Declarations and Definitions in One Header: C++ Interface,
|
||||
for more discussion of these pragmas.
|
||||
|
||||
|
||||
File: gcc.info, Node: Bound member functions, Next: C++ Signatures, Prev: Template Instantiation, Up: C++ Extensions
|
||||
|
||||
Extracting the function pointer from a bound pointer to member function
|
||||
=======================================================================
|
||||
|
||||
In C++, pointer to member functions (PMFs) are implemented using a
|
||||
wide pointer of sorts to handle all the possible call mechanisms; the
|
||||
PMF needs to store information about how to adjust the `this' pointer,
|
||||
and if the function pointed to is virtual, where to find the vtable, and
|
||||
where in the vtable to look for the member function. If you are using
|
||||
PMFs in an inner loop, you should really reconsider that decision. If
|
||||
that is not an option, you can extract the pointer to the function that
|
||||
would be called for a given object/PMF pair and call it directly inside
|
||||
the inner loop, to save a bit of time.
|
||||
|
||||
Note that you will still be paying the penalty for the call through a
|
||||
function pointer; on most modern architectures, such a call defeats the
|
||||
branch prediction features of the CPU. This is also true of normal
|
||||
virtual function calls.
|
||||
|
||||
The syntax for this extension is
|
||||
|
||||
extern A a;
|
||||
extern int (A::*fp)();
|
||||
typedef int (*fptr)(A *);
|
||||
|
||||
fptr p = (fptr)(a.*fp);
|
||||
|
||||
You must specify `-Wno-pmf-conversions' to use this extension.
|
||||
|
||||
|
||||
File: gcc.info, Node: C++ Signatures, Prev: Bound member functions, Up: C++ Extensions
|
||||
|
||||
Type Abstraction using Signatures
|
||||
=================================
|
||||
|
||||
In GNU C++, you can use the keyword `signature' to define a
|
||||
completely abstract class interface as a datatype. You can connect this
|
||||
abstraction with actual classes using signature pointers. If you want
|
||||
to use signatures, run the GNU compiler with the `-fhandle-signatures'
|
||||
command-line option. (With this option, the compiler reserves a second
|
||||
keyword `sigof' as well, for a future extension.)
|
||||
|
||||
Roughly, signatures are type abstractions or interfaces of classes.
|
||||
Some other languages have similar facilities. C++ signatures are
|
||||
related to ML's signatures, Haskell's type classes, definition modules
|
||||
in Modula-2, interface modules in Modula-3, abstract types in Emerald,
|
||||
type modules in Trellis/Owl, categories in Scratchpad II, and types in
|
||||
POOL-I. For a more detailed discussion of signatures, see `Signatures:
|
||||
A Language Extension for Improving Type Abstraction and Subtype
|
||||
Polymorphism in C++' by Gerald Baumgartner and Vincent F. Russo (Tech
|
||||
report CSD-TR-95-051, Dept. of Computer Sciences, Purdue University,
|
||||
August 1995, a slightly improved version appeared in
|
||||
*Software--Practice & Experience*, 25(8), pp. 863-889, August 1995).
|
||||
You can get the tech report by anonymous FTP from `ftp.cs.purdue.edu'
|
||||
in `pub/gb/Signature-design.ps.gz'.
|
||||
|
||||
Syntactically, a signature declaration is a collection of member
|
||||
function declarations and nested type declarations. For example, this
|
||||
signature declaration defines a new abstract type `S' with member
|
||||
functions `int foo ()' and `int bar (int)':
|
||||
|
||||
signature S
|
||||
{
|
||||
int foo ();
|
||||
int bar (int);
|
||||
};
|
||||
|
||||
Since signature types do not include implementation definitions, you
|
||||
cannot write an instance of a signature directly. Instead, you can
|
||||
define a pointer to any class that contains the required interfaces as a
|
||||
"signature pointer". Such a class "implements" the signature type.
|
||||
|
||||
To use a class as an implementation of `S', you must ensure that the
|
||||
class has public member functions `int foo ()' and `int bar (int)'.
|
||||
The class can have other member functions as well, public or not; as
|
||||
long as it offers what's declared in the signature, it is suitable as
|
||||
an implementation of that signature type.
|
||||
|
||||
For example, suppose that `C' is a class that meets the requirements
|
||||
of signature `S' (`C' "conforms to" `S'). Then
|
||||
|
||||
C obj;
|
||||
S * p = &obj;
|
||||
|
||||
defines a signature pointer `p' and initializes it to point to an
|
||||
object of type `C'. The member function call `int i = p->foo ();'
|
||||
executes `obj.foo ()'.
|
||||
|
||||
Abstract virtual classes provide somewhat similar facilities in
|
||||
standard C++. There are two main advantages to using signatures
|
||||
instead:
|
||||
|
||||
1. Subtyping becomes independent from inheritance. A class or
|
||||
signature type `T' is a subtype of a signature type `S'
|
||||
independent of any inheritance hierarchy as long as all the member
|
||||
functions declared in `S' are also found in `T'. So you can
|
||||
define a subtype hierarchy that is completely independent from any
|
||||
inheritance (implementation) hierarchy, instead of being forced to
|
||||
use types that mirror the class inheritance hierarchy.
|
||||
|
||||
2. Signatures allow you to work with existing class hierarchies as
|
||||
implementations of a signature type. If those class hierarchies
|
||||
are only available in compiled form, you're out of luck with
|
||||
abstract virtual classes, since an abstract virtual class cannot
|
||||
be retrofitted on top of existing class hierarchies. So you would
|
||||
be required to write interface classes as subtypes of the abstract
|
||||
virtual class.
|
||||
|
||||
There is one more detail about signatures. A signature declaration
|
||||
can contain member function *definitions* as well as member function
|
||||
declarations. A signature member function with a full definition is
|
||||
called a *default implementation*; classes need not contain that
|
||||
particular interface in order to conform. For example, a class `C' can
|
||||
conform to the signature
|
||||
|
||||
signature T
|
||||
{
|
||||
int f (int);
|
||||
int f0 () { return f (0); };
|
||||
};
|
||||
|
||||
whether or not `C' implements the member function `int f0 ()'. If you
|
||||
define `C::f0', that definition takes precedence; otherwise, the
|
||||
default implementation `S::f0' applies.
|
||||
|
||||
|
||||
File: gcc.info, Node: Gcov, Next: Trouble, Prev: C++ Extensions, Up: Top
|
||||
|
||||
`gcov': a Test Coverage Program
|
||||
*******************************
|
||||
|
||||
`gcov' is a tool you can use in conjunction with GNU CC to test code
|
||||
coverage in your programs.
|
||||
|
||||
This chapter describes version 1.5 of `gcov'.
|
||||
|
||||
* Menu:
|
||||
|
||||
* Gcov Intro:: Introduction to gcov.
|
||||
* Invoking Gcov:: How to use gcov.
|
||||
* Gcov and Optimization:: Using gcov with GCC optimization.
|
||||
* Gcov Data Files:: The files used by gcov.
|
||||
|
||||
|
||||
File: gcc.info, Node: Gcov Intro, Next: Invoking Gcov, Up: Gcov
|
||||
|
||||
Introduction to `gcov'
|
||||
======================
|
||||
|
||||
`gcov' is a test coverage program. Use it in concert with GNU CC to
|
||||
analyze your programs to help create more efficient, faster running
|
||||
code. You can use `gcov' as a profiling tool to help discover where
|
||||
your optimization efforts will best affect your code. You can also use
|
||||
`gcov' along with the other profiling tool, `gprof', to assess which
|
||||
parts of your code use the greatest amount of computing time.
|
||||
|
||||
Profiling tools help you analyze your code's performance. Using a
|
||||
profiler such as `gcov' or `gprof', you can find out some basic
|
||||
performance statistics, such as:
|
||||
|
||||
* how often each line of code executes
|
||||
|
||||
* what lines of code are actually executed
|
||||
|
||||
* how much computing time each section of code uses
|
||||
|
||||
Once you know these things about how your code works when compiled,
|
||||
you can look at each module to see which modules should be optimized.
|
||||
`gcov' helps you determine where to work on optimization.
|
||||
|
||||
Software developers also use coverage testing in concert with
|
||||
testsuites, to make sure software is actually good enough for a release.
|
||||
Testsuites can verify that a program works as expected; a coverage
|
||||
program tests to see how much of the program is exercised by the
|
||||
testsuite. Developers can then determine what kinds of test cases need
|
||||
to be added to the testsuites to create both better testing and a better
|
||||
final product.
|
||||
|
||||
You should compile your code without optimization if you plan to use
|
||||
`gcov' because the optimization, by combining some lines of code into
|
||||
one function, may not give you as much information as you need to look
|
||||
for `hot spots' where the code is using a great deal of computer time.
|
||||
Likewise, because `gcov' accumulates statistics by line (at the lowest
|
||||
resolution), it works best with a programming style that places only
|
||||
one statement on each line. If you use complicated macros that expand
|
||||
to loops or to other control structures, the statistics are less
|
||||
helpful--they only report on the line where the macro call appears. If
|
||||
your complex macros behave like functions, you can replace them with
|
||||
inline functions to solve this problem.
|
||||
|
||||
`gcov' creates a logfile called `SOURCEFILE.gcov' which indicates
|
||||
how many times each line of a source file `SOURCEFILE.c' has executed.
|
||||
You can use these logfiles along with `gprof' to aid in fine-tuning the
|
||||
performance of your programs. `gprof' gives timing information you can
|
||||
use along with the information you get from `gcov'.
|
||||
|
||||
`gcov' works only on code compiled with GNU CC. It is not
|
||||
compatible with any other profiling or test coverage mechanism.
|
||||
|
||||
|
||||
File: gcc.info, Node: Invoking Gcov, Next: Gcov and Optimization, Prev: Gcov Intro, Up: Gcov
|
||||
|
||||
Invoking gcov
|
||||
=============
|
||||
|
||||
gcov [-b] [-v] [-n] [-l] [-f] [-o directory] SOURCEFILE
|
||||
|
||||
`-b'
|
||||
Write branch frequencies to the output file, and write branch
|
||||
summary info to the standard output. This option allows you to
|
||||
see how often each branch in your program was taken.
|
||||
|
||||
`-v'
|
||||
Display the `gcov' version number (on the standard error stream).
|
||||
|
||||
`-n'
|
||||
Do not create the `gcov' output file.
|
||||
|
||||
`-l'
|
||||
Create long file names for included source files. For example, if
|
||||
the header file `x.h' contains code, and was included in the file
|
||||
`a.c', then running `gcov' on the file `a.c' will produce an
|
||||
output file called `a.c.x.h.gcov' instead of `x.h.gcov'. This can
|
||||
be useful if `x.h' is included in multiple source files.
|
||||
|
||||
`-f'
|
||||
Output summaries for each function in addition to the file level
|
||||
summary.
|
||||
|
||||
`-o'
|
||||
The directory where the object files live. Gcov will search for
|
||||
`.bb', `.bbg', and `.da' files in this directory.
|
||||
|
||||
When using `gcov', you must first compile your program with two
|
||||
special GNU CC options: `-fprofile-arcs -ftest-coverage'. This tells
|
||||
the compiler to generate additional information needed by gcov
|
||||
(basically a flow graph of the program) and also includes additional
|
||||
code in the object files for generating the extra profiling information
|
||||
needed by gcov. These additional files are placed in the directory
|
||||
where the source code is located.
|
||||
|
||||
Running the program will cause profile output to be generated. For
|
||||
each source file compiled with -fprofile-arcs, an accompanying `.da'
|
||||
file will be placed in the source directory.
|
||||
|
||||
Running `gcov' with your program's source file names as arguments
|
||||
will now produce a listing of the code along with frequency of execution
|
||||
for each line. For example, if your program is called `tmp.c', this is
|
||||
what you see when you use the basic `gcov' facility:
|
||||
|
||||
$ gcc -fprofile-arcs -ftest-coverage tmp.c
|
||||
$ a.out
|
||||
$ gcov tmp.c
|
||||
87.50% of 8 source lines executed in file tmp.c
|
||||
Creating tmp.c.gcov.
|
||||
|
||||
The file `tmp.c.gcov' contains output from `gcov'. Here is a sample:
|
||||
|
||||
main()
|
||||
{
|
||||
1 int i, total;
|
||||
|
||||
1 total = 0;
|
||||
|
||||
11 for (i = 0; i < 10; i++)
|
||||
10 total += i;
|
||||
|
||||
1 if (total != 45)
|
||||
###### printf ("Failure\n");
|
||||
else
|
||||
1 printf ("Success\n");
|
||||
1 }
|
||||
|
||||
When you use the `-b' option, your output looks like this:
|
||||
|
||||
$ gcov -b tmp.c
|
||||
87.50% of 8 source lines executed in file tmp.c
|
||||
80.00% of 5 branches executed in file tmp.c
|
||||
80.00% of 5 branches taken at least once in file tmp.c
|
||||
50.00% of 2 calls executed in file tmp.c
|
||||
Creating tmp.c.gcov.
|
||||
|
||||
Here is a sample of a resulting `tmp.c.gcov' file:
|
||||
|
||||
main()
|
||||
{
|
||||
1 int i, total;
|
||||
|
||||
1 total = 0;
|
||||
|
||||
11 for (i = 0; i < 10; i++)
|
||||
branch 0 taken = 91%
|
||||
branch 1 taken = 100%
|
||||
branch 2 taken = 100%
|
||||
10 total += i;
|
||||
|
||||
1 if (total != 45)
|
||||
branch 0 taken = 100%
|
||||
###### printf ("Failure\n");
|
||||
call 0 never executed
|
||||
branch 1 never executed
|
||||
else
|
||||
1 printf ("Success\n");
|
||||
call 0 returns = 100%
|
||||
1 }
|
||||
|
||||
For each basic block, a line is printed after the last line of the
|
||||
basic block describing the branch or call that ends the basic block.
|
||||
There can be multiple branches and calls listed for a single source
|
||||
line if there are multiple basic blocks that end on that line. In this
|
||||
case, the branches and calls are each given a number. There is no
|
||||
simple way to map these branches and calls back to source constructs.
|
||||
In general, though, the lowest numbered branch or call will correspond
|
||||
to the leftmost construct on the source line.
|
||||
|
||||
For a branch, if it was executed at least once, then a percentage
|
||||
indicating the number of times the branch was taken divided by the
|
||||
number of times the branch was executed will be printed. Otherwise, the
|
||||
message "never executed" is printed.
|
||||
|
||||
For a call, if it was executed at least once, then a percentage
|
||||
indicating the number of times the call returned divided by the number
|
||||
of times the call was executed will be printed. This will usually be
|
||||
100%, but may be less for functions call `exit' or `longjmp', and thus
|
||||
may not return everytime they are called.
|
||||
|
||||
The execution counts are cumulative. If the example program were
|
||||
executed again without removing the `.da' file, the count for the
|
||||
number of times each line in the source was executed would be added to
|
||||
the results of the previous run(s). This is potentially useful in
|
||||
several ways. For example, it could be used to accumulate data over a
|
||||
number of program runs as part of a test verification suite, or to
|
||||
provide more accurate long-term information over a large number of
|
||||
program runs.
|
||||
|
||||
The data in the `.da' files is saved immediately before the program
|
||||
exits. For each source file compiled with -fprofile-arcs, the profiling
|
||||
code first attempts to read in an existing `.da' file; if the file
|
||||
doesn't match the executable (differing number of basic block counts) it
|
||||
will ignore the contents of the file. It then adds in the new execution
|
||||
counts and finally writes the data to the file.
|
||||
|
||||
|
||||
File: gcc.info, Node: Gcov and Optimization, Next: Gcov Data Files, Prev: Invoking Gcov, Up: Gcov
|
||||
|
||||
Using `gcov' with GCC Optimization
|
||||
==================================
|
||||
|
||||
If you plan to use `gcov' to help optimize your code, you must first
|
||||
compile your program with two special GNU CC options: `-fprofile-arcs
|
||||
-ftest-coverage'. Aside from that, you can use any other GNU CC
|
||||
options; but if you want to prove that every single line in your
|
||||
program was executed, you should not compile with optimization at the
|
||||
same time. On some machines the optimizer can eliminate some simple
|
||||
code lines by combining them with other lines. For example, code like
|
||||
this:
|
||||
|
||||
if (a != b)
|
||||
c = 1;
|
||||
else
|
||||
c = 0;
|
||||
|
||||
can be compiled into one instruction on some machines. In this case,
|
||||
there is no way for `gcov' to calculate separate execution counts for
|
||||
each line because there isn't separate code for each line. Hence the
|
||||
`gcov' output looks like this if you compiled the program with
|
||||
optimization:
|
||||
|
||||
100 if (a != b)
|
||||
100 c = 1;
|
||||
100 else
|
||||
100 c = 0;
|
||||
|
||||
The output shows that this block of code, combined by optimization,
|
||||
executed 100 times. In one sense this result is correct, because there
|
||||
was only one instruction representing all four of these lines. However,
|
||||
the output does not indicate how many times the result was 0 and how
|
||||
many times the result was 1.
|
||||
|
||||
|
||||
File: gcc.info, Node: Gcov Data Files, Prev: Gcov and Optimization, Up: Gcov
|
||||
|
||||
Brief description of `gcov' data files
|
||||
======================================
|
||||
|
||||
`gcov' uses three files for doing profiling. The names of these
|
||||
files are derived from the original *source* file by substituting the
|
||||
file suffix with either `.bb', `.bbg', or `.da'. All of these files
|
||||
are placed in the same directory as the source file, and contain data
|
||||
stored in a platform-independent method.
|
||||
|
||||
The `.bb' and `.bbg' files are generated when the source file is
|
||||
compiled with the GNU CC `-ftest-coverage' option. The `.bb' file
|
||||
contains a list of source files (including headers), functions within
|
||||
those files, and line numbers corresponding to each basic block in the
|
||||
source file.
|
||||
|
||||
The `.bb' file format consists of several lists of 4-byte integers
|
||||
which correspond to the line numbers of each basic block in the file.
|
||||
Each list is terminated by a line number of 0. A line number of -1 is
|
||||
used to designate that the source file name (padded to a 4-byte
|
||||
boundary and followed by another -1) follows. In addition, a line
|
||||
number of -2 is used to designate that the name of a function (also
|
||||
padded to a 4-byte boundary and followed by a -2) follows.
|
||||
|
||||
The `.bbg' file is used to reconstruct the program flow graph for
|
||||
the source file. It contains a list of the program flow arcs (possible
|
||||
branches taken from one basic block to another) for each function which,
|
||||
in combination with the `.bb' file, enables gcov to reconstruct the
|
||||
program flow.
|
||||
|
||||
In the `.bbg' file, the format is:
|
||||
number of basic blocks for function #0 (4-byte number)
|
||||
total number of arcs for function #0 (4-byte number)
|
||||
count of arcs in basic block #0 (4-byte number)
|
||||
destination basic block of arc #0 (4-byte number)
|
||||
flag bits (4-byte number)
|
||||
destination basic block of arc #1 (4-byte number)
|
||||
flag bits (4-byte number)
|
||||
...
|
||||
destination basic block of arc #N (4-byte number)
|
||||
flag bits (4-byte number)
|
||||
count of arcs in basic block #1 (4-byte number)
|
||||
destination basic block of arc #0 (4-byte number)
|
||||
flag bits (4-byte number)
|
||||
...
|
||||
|
||||
A -1 (stored as a 4-byte number) is used to separate each function's
|
||||
list of basic blocks, and to verify that the file has been read
|
||||
correctly.
|
||||
|
||||
The `.da' file is generated when a program containing object files
|
||||
built with the GNU CC `-fprofile-arcs' option is executed. A separate
|
||||
`.da' file is created for each source file compiled with this option,
|
||||
and the name of the `.da' file is stored as an absolute pathname in the
|
||||
resulting object file. This path name is derived from the source file
|
||||
name by substituting a `.da' suffix.
|
||||
|
||||
The format of the `.da' file is fairly simple. The first 8-byte
|
||||
number is the number of counts in the file, followed by the counts
|
||||
(stored as 8-byte numbers). Each count corresponds to the number of
|
||||
times each arc in the program is executed. The counts are cumulative;
|
||||
each time the program is executed, it attemps to combine the existing
|
||||
`.da' files with the new counts for this invocation of the program. It
|
||||
ignores the contents of any `.da' files whose number of arcs doesn't
|
||||
correspond to the current program, and merely overwrites them instead.
|
||||
|
||||
All three of these files use the functions in `gcov-io.h' to store
|
||||
integers; the functions in this header provide a machine-independent
|
||||
mechanism for storing and retrieving data from a stream.
|
||||
|
||||
|
||||
File: gcc.info, Node: Trouble, Next: Bugs, Prev: Gcov, Up: Top
|
||||
|
||||
Known Causes of Trouble with GCC
|
||||
********************************
|
||||
|
||||
This section describes known problems that affect users of GCC. Most
|
||||
of these are not GCC bugs per se--if they were, we would fix them. But
|
||||
the result for a user may be like the result of a bug.
|
||||
|
||||
Some of these problems are due to bugs in other software, some are
|
||||
missing features that are too much work to add, and some are places
|
||||
where people's opinions differ as to what is best.
|
||||
|
||||
* Menu:
|
||||
|
||||
* Actual Bugs:: Bugs we will fix later.
|
||||
* Installation Problems:: Problems that manifest when you install GCC.
|
||||
* Cross-Compiler Problems:: Common problems of cross compiling with GCC.
|
||||
* Interoperation:: Problems using GCC with other compilers,
|
||||
and with certain linkers, assemblers and debuggers.
|
||||
* External Bugs:: Problems compiling certain programs.
|
||||
* Incompatibilities:: GCC is incompatible with traditional C.
|
||||
* Fixed Headers:: GNU C uses corrected versions of system header files.
|
||||
This is necessary, but doesn't always work smoothly.
|
||||
* Standard Libraries:: GNU C uses the system C library, which might not be
|
||||
compliant with the ISO/ANSI C standard.
|
||||
* Disappointments:: Regrettable things we can't change, but not quite bugs.
|
||||
* C++ Misunderstandings:: Common misunderstandings with GNU C++.
|
||||
* Protoize Caveats:: Things to watch out for when using `protoize'.
|
||||
* Non-bugs:: Things we think are right, but some others disagree.
|
||||
* Warnings and Errors:: Which problems in your code get warnings,
|
||||
and which get errors.
|
||||
|
||||
|
||||
File: gcc.info, Node: Actual Bugs, Next: Installation Problems, Up: Trouble
|
||||
|
||||
Actual Bugs We Haven't Fixed Yet
|
||||
================================
|
||||
|
||||
* The `fixincludes' script interacts badly with automounters; if the
|
||||
directory of system header files is automounted, it tends to be
|
||||
unmounted while `fixincludes' is running. This would seem to be a
|
||||
bug in the automounter. We don't know any good way to work around
|
||||
it.
|
||||
|
||||
* The `fixproto' script will sometimes add prototypes for the
|
||||
`sigsetjmp' and `siglongjmp' functions that reference the
|
||||
`jmp_buf' type before that type is defined. To work around this,
|
||||
edit the offending file and place the typedef in front of the
|
||||
prototypes.
|
||||
|
||||
* There are several obscure case of mis-using struct, union, and
|
||||
enum tags that are not detected as errors by the compiler.
|
||||
|
||||
* When `-pedantic-errors' is specified, GCC will incorrectly give an
|
||||
error message when a function name is specified in an expression
|
||||
involving the comma operator.
|
||||
|
||||
* Loop unrolling doesn't work properly for certain C++ programs.
|
||||
This is a bug in the C++ front end. It sometimes emits incorrect
|
||||
debug info, and the loop unrolling code is unable to recover from
|
||||
this error.
|
||||
|
||||
Executable
+1143
File diff suppressed because it is too large
Load Diff
Executable
+1089
File diff suppressed because it is too large
Load Diff
Executable
+1012
File diff suppressed because it is too large
Load Diff
Executable
+1205
File diff suppressed because it is too large
Load Diff
Executable
+1085
File diff suppressed because it is too large
Load Diff
Executable
+1066
File diff suppressed because it is too large
Load Diff
Executable
+1332
File diff suppressed because it is too large
Load Diff
Executable
+837
@@ -0,0 +1,837 @@
|
||||
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
|
||||
input file ../../gcc-2.95.2/gcc/gcc.texi.
|
||||
|
||||
INFO-DIR-SECTION Programming
|
||||
START-INFO-DIR-ENTRY
|
||||
* gcc: (gcc). The GNU Compiler Collection.
|
||||
END-INFO-DIR-ENTRY
|
||||
This file documents the use and the internals of the GNU compiler.
|
||||
|
||||
Published by the Free Software Foundation 59 Temple Place - Suite 330
|
||||
Boston, MA 02111-1307 USA
|
||||
|
||||
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
|
||||
1999 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 "Funding
|
||||
for Free Software" 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 one.
|
||||
|
||||
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 "Funding for Free Software", 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: C++ Dialect Options, Next: Warning Options, Prev: C Dialect Options, Up: Invoking GCC
|
||||
|
||||
Options Controlling C++ Dialect
|
||||
===============================
|
||||
|
||||
This section describes the command-line options that are only
|
||||
meaningful for C++ programs; but you can also use most of the GNU
|
||||
compiler options regardless of what language your program is in. For
|
||||
example, you might compile a file `firstClass.C' like this:
|
||||
|
||||
g++ -g -frepo -O -c firstClass.C
|
||||
|
||||
In this example, only `-frepo' is an option meant only for C++
|
||||
programs; you can use the other options with any language supported by
|
||||
GCC.
|
||||
|
||||
Here is a list of options that are *only* for compiling C++ programs:
|
||||
|
||||
`-fno-access-control'
|
||||
Turn off all access checking. This switch is mainly useful for
|
||||
working around bugs in the access control code.
|
||||
|
||||
`-fcheck-new'
|
||||
Check that the pointer returned by `operator new' is non-null
|
||||
before attempting to modify the storage allocated. The current
|
||||
Working Paper requires that `operator new' never return a null
|
||||
pointer, so this check is normally unnecessary.
|
||||
|
||||
An alternative to using this option is to specify that your
|
||||
`operator new' does not throw any exceptions; if you declare it
|
||||
`throw()', g++ will check the return value. See also `new
|
||||
(nothrow)'.
|
||||
|
||||
`-fconserve-space'
|
||||
Put uninitialized or runtime-initialized global variables into the
|
||||
common segment, as C does. This saves space in the executable at
|
||||
the cost of not diagnosing duplicate definitions. If you compile
|
||||
with this flag and your program mysteriously crashes after
|
||||
`main()' has completed, you may have an object that is being
|
||||
destroyed twice because two definitions were merged.
|
||||
|
||||
This option is no longer useful on most targets, now that support
|
||||
has been added for putting variables into BSS without making them
|
||||
common.
|
||||
|
||||
`-fdollars-in-identifiers'
|
||||
Accept `$' in identifiers. You can also explicitly prohibit use of
|
||||
`$' with the option `-fno-dollars-in-identifiers'. (GNU C allows
|
||||
`$' by default on most target systems, but there are a few
|
||||
exceptions.) Traditional C allowed the character `$' to form part
|
||||
of identifiers. However, ANSI C and C++ forbid `$' in identifiers.
|
||||
|
||||
`-fno-elide-constructors'
|
||||
The C++ standard allows an implementation to omit creating a
|
||||
temporary which is only used to initialize another object of the
|
||||
same type. Specifying this option disables that optimization, and
|
||||
forces g++ to call the copy constructor in all cases.
|
||||
|
||||
`-fexternal-templates'
|
||||
Cause template instantiations to obey `#pragma interface' and
|
||||
`implementation'; template instances are emitted or not according
|
||||
to the location of the template definition. *Note Template
|
||||
Instantiation::, for more information.
|
||||
|
||||
This option is deprecated.
|
||||
|
||||
`-falt-external-templates'
|
||||
Similar to -fexternal-templates, but template instances are
|
||||
emitted or not according to the place where they are first
|
||||
instantiated. *Note Template Instantiation::, for more
|
||||
information.
|
||||
|
||||
This option is deprecated.
|
||||
|
||||
`-ffor-scope'
|
||||
`-fno-for-scope'
|
||||
If -ffor-scope is specified, the scope of variables declared in a
|
||||
for-init-statement is limited to the `for' loop itself, as
|
||||
specified by the draft C++ standard. If -fno-for-scope is
|
||||
specified, the scope of variables declared in a for-init-statement
|
||||
extends to the end of the enclosing scope, as was the case in old
|
||||
versions of gcc, and other (traditional) implementations of C++.
|
||||
|
||||
The default if neither flag is given to follow the standard, but
|
||||
to allow and give a warning for old-style code that would
|
||||
otherwise be invalid, or have different behavior.
|
||||
|
||||
`-fno-gnu-keywords'
|
||||
Do not recognize `classof', `headof', `signature', `sigof' or
|
||||
`typeof' as a keyword, so that code can use these words as
|
||||
identifiers. You can use the keywords `__classof__',
|
||||
`__headof__', `__signature__', `__sigof__', and `__typeof__'
|
||||
instead. `-ansi' implies `-fno-gnu-keywords'.
|
||||
|
||||
`-fguiding-decls'
|
||||
Treat a function declaration with the same type as a potential
|
||||
function template instantiation as though it declares that
|
||||
instantiation, not a normal function. If a definition is given
|
||||
for the function later in the translation unit (or another
|
||||
translation unit if the target supports weak symbols), that
|
||||
definition will be used; otherwise the template will be
|
||||
instantiated. This behavior reflects the C++ language prior to
|
||||
September 1996, when guiding declarations were removed.
|
||||
|
||||
This option implies `-fname-mangling-version-0', and will not work
|
||||
with other name mangling versions. Like all options that change
|
||||
the ABI, all C++ code, *including libgcc.a* must be built with the
|
||||
same setting of this option.
|
||||
|
||||
`-fhandle-signatures'
|
||||
Recognize the `signature' and `sigof' keywords for specifying
|
||||
abstract types. The default (`-fno-handle-signatures') is not to
|
||||
recognize them. *Note Type Abstraction using Signatures: C++
|
||||
Signatures.
|
||||
|
||||
`-fhonor-std'
|
||||
Treat the `namespace std' as a namespace, instead of ignoring it.
|
||||
For compatibility with earlier versions of g++, the compiler will,
|
||||
by default, ignore `namespace-declarations', `using-declarations',
|
||||
`using-directives', and `namespace-names', if they involve `std'.
|
||||
|
||||
`-fhuge-objects'
|
||||
Support virtual function calls for objects that exceed the size
|
||||
representable by a `short int'. Users should not use this flag by
|
||||
default; if you need to use it, the compiler will tell you so.
|
||||
|
||||
This flag is not useful when compiling with -fvtable-thunks.
|
||||
|
||||
Like all options that change the ABI, all C++ code, *including
|
||||
libgcc* must be built with the same setting of this option.
|
||||
|
||||
`-fno-implicit-templates'
|
||||
Never emit code for non-inline templates which are instantiated
|
||||
implicitly (i.e. by use); only emit code for explicit
|
||||
instantiations. *Note Template Instantiation::, for more
|
||||
information.
|
||||
|
||||
`-fno-implicit-inline-templates'
|
||||
Don't emit code for implicit instantiations of inline templates,
|
||||
either. The default is to handle inlines differently so that
|
||||
compiles with and without optimization will need the same set of
|
||||
explicit instantiations.
|
||||
|
||||
`-finit-priority'
|
||||
Support `__attribute__ ((init_priority (n)))' for controlling the
|
||||
order of initialization of file-scope objects. On ELF targets,
|
||||
this requires GNU ld 2.10 or later.
|
||||
|
||||
`-fno-implement-inlines'
|
||||
To save space, do not emit out-of-line copies of inline functions
|
||||
controlled by `#pragma implementation'. This will cause linker
|
||||
errors if these functions are not inlined everywhere they are
|
||||
called.
|
||||
|
||||
`-fname-mangling-version-N'
|
||||
Control the way in which names are mangled. Version 0 is
|
||||
compatible with versions of g++ before 2.8. Version 1 is the
|
||||
default. Version 1 will allow correct mangling of function
|
||||
templates. For example, version 0 mangling does not mangle
|
||||
foo<int, double> and foo<int, char> given this declaration:
|
||||
|
||||
template <class T, class U> void foo(T t);
|
||||
|
||||
Like all options that change the ABI, all C++ code, *including
|
||||
libgcc* must be built with the same setting of this option.
|
||||
|
||||
`-foperator-names'
|
||||
Recognize the operator name keywords `and', `bitand', `bitor',
|
||||
`compl', `not', `or' and `xor' as synonyms for the symbols they
|
||||
refer to. `-ansi' implies `-foperator-names'.
|
||||
|
||||
`-fno-optional-diags'
|
||||
Disable diagnostics that the standard says a compiler does not
|
||||
need to issue. Currently, the only such diagnostic issued by g++
|
||||
is the one for a name having multiple meanings within a class.
|
||||
|
||||
`-fpermissive'
|
||||
Downgrade messages about nonconformant code from errors to
|
||||
warnings. By default, g++ effectively sets `-pedantic-errors'
|
||||
without `-pedantic'; this option reverses that. This behavior and
|
||||
this option are superceded by `-pedantic', which works as it does
|
||||
for GNU C.
|
||||
|
||||
`-frepo'
|
||||
Enable automatic template instantiation. This option also implies
|
||||
`-fno-implicit-templates'. *Note Template Instantiation::, for
|
||||
more information.
|
||||
|
||||
`-fno-rtti'
|
||||
Disable generation of the information used by C++ runtime type
|
||||
identification features (`dynamic_cast' and `typeid'). If you
|
||||
don't use those parts of the language (or exception handling,
|
||||
which uses `dynamic_cast' internally), you can save some space by
|
||||
using this flag.
|
||||
|
||||
`-fstrict-prototype'
|
||||
Within an `extern "C"' linkage specification, treat a function
|
||||
declaration with no arguments, such as `int foo ();', as declaring
|
||||
the function to take no arguments. Normally, such a declaration
|
||||
means that the function `foo' can take any combination of
|
||||
arguments, as in C. `-pedantic' implies `-fstrict-prototype'
|
||||
unless overridden with `-fno-strict-prototype'.
|
||||
|
||||
Specifying this option will also suppress implicit declarations of
|
||||
functions.
|
||||
|
||||
This flag no longer affects declarations with C++ linkage.
|
||||
|
||||
`-fsquangle'
|
||||
`-fno-squangle'
|
||||
`-fsquangle' will enable a compressed form of name mangling for
|
||||
identifiers. In particular, it helps to shorten very long names by
|
||||
recognizing types and class names which occur more than once,
|
||||
replacing them with special short ID codes. This option also
|
||||
requires any C++ libraries being used to be compiled with this
|
||||
option as well. The compiler has this disabled (the equivalent of
|
||||
`-fno-squangle') by default.
|
||||
|
||||
Like all options that change the ABI, all C++ code, *including
|
||||
libgcc.a* must be built with the same setting of this option.
|
||||
|
||||
`-ftemplate-depth-N'
|
||||
Set the maximum instantiation depth for template classes to N. A
|
||||
limit on the template instantiation depth is needed to detect
|
||||
endless recursions during template class instantiation. ANSI/ISO
|
||||
C++ conforming programs must not rely on a maximum depth greater
|
||||
than 17.
|
||||
|
||||
`-fthis-is-variable'
|
||||
Permit assignment to `this'. The incorporation of user-defined
|
||||
free store management into C++ has made assignment to `this' an
|
||||
anachronism. Therefore, by default it is invalid to assign to
|
||||
`this' within a class member function; that is, GNU C++ treats
|
||||
`this' in a member function of class `X' as a non-lvalue of type
|
||||
`X *'. However, for backwards compatibility, you can make it
|
||||
valid with `-fthis-is-variable'.
|
||||
|
||||
`-fvtable-thunks'
|
||||
Use `thunks' to implement the virtual function dispatch table
|
||||
(`vtable'). The traditional (cfront-style) approach to
|
||||
implementing vtables was to store a pointer to the function and two
|
||||
offsets for adjusting the `this' pointer at the call site. Newer
|
||||
implementations store a single pointer to a `thunk' function which
|
||||
does any necessary adjustment and then calls the target function.
|
||||
|
||||
This option also enables a heuristic for controlling emission of
|
||||
vtables; if a class has any non-inline virtual functions, the
|
||||
vtable will be emitted in the translation unit containing the
|
||||
first one of those.
|
||||
|
||||
Like all options that change the ABI, all C++ code, *including
|
||||
libgcc.a* must be built with the same setting of this option.
|
||||
|
||||
`-nostdinc++'
|
||||
Do not search for header files in the standard directories
|
||||
specific to C++, but do still search the other standard
|
||||
directories. (This option is used when building the C++ library.)
|
||||
|
||||
In addition, these optimization, warning, and code generation options
|
||||
have meanings only for C++ programs:
|
||||
|
||||
`-fno-default-inline'
|
||||
Do not assume `inline' for functions defined inside a class scope.
|
||||
*Note Options That Control Optimization: Optimize Options. Note
|
||||
that these functions will have linkage like inline functions; they
|
||||
just won't be inlined by default.
|
||||
|
||||
`-Wctor-dtor-privacy (C++ only)'
|
||||
Warn when a class seems unusable, because all the constructors or
|
||||
destructors in a class are private and the class has no friends or
|
||||
public static member functions.
|
||||
|
||||
`-Wnon-virtual-dtor (C++ only)'
|
||||
Warn when a class declares a non-virtual destructor that should
|
||||
probably be virtual, because it looks like the class will be used
|
||||
polymorphically.
|
||||
|
||||
`-Wreorder (C++ only)'
|
||||
Warn when the order of member initializers given in the code does
|
||||
not match the order in which they must be executed. For instance:
|
||||
|
||||
struct A {
|
||||
int i;
|
||||
int j;
|
||||
A(): j (0), i (1) { }
|
||||
};
|
||||
|
||||
Here the compiler will warn that the member initializers for `i'
|
||||
and `j' will be rearranged to match the declaration order of the
|
||||
members.
|
||||
|
||||
The following `-W...' options are not affected by `-Wall'.
|
||||
|
||||
`-Weffc++ (C++ only)'
|
||||
Warn about violations of various style guidelines from Scott
|
||||
Meyers' `Effective C++' books. If you use this option, you should
|
||||
be aware that the standard library headers do not obey all of
|
||||
these guidelines; you can use `grep -v' to filter out those
|
||||
warnings.
|
||||
|
||||
`-Wno-deprecated (C++ only)'
|
||||
Do not warn about usage of deprecated features. *Note Deprecated
|
||||
Features::.
|
||||
|
||||
`-Wno-non-template-friend (C++ only)'
|
||||
Disable warnings when non-templatized friend functions are declared
|
||||
within a template. With the advent of explicit template
|
||||
specification support in g++, if the name of the friend is an
|
||||
unqualified-id (ie, `friend foo(int)'), the C++ language
|
||||
specification demands that the friend declare or define an
|
||||
ordinary, nontemplate function. (Section 14.5.3). Before g++
|
||||
implemented explicit specification, unqualified-ids could be
|
||||
interpreted as a particular specialization of a templatized
|
||||
function. Because this non-conforming behavior is no longer the
|
||||
default behavior for g++, `-Wnon-template-friend' allows the
|
||||
compiler to check existing code for potential trouble spots, and
|
||||
is on by default. This new compiler behavior can also be turned
|
||||
off with the flag `-fguiding-decls', which activates the older,
|
||||
non-specification compiler code, or with
|
||||
`-Wno-non-template-friend' which keeps the conformant compiler
|
||||
code but disables the helpful warning.
|
||||
|
||||
`-Wold-style-cast (C++ only)'
|
||||
Warn if an old-style (C-style) cast is used within a C++ program.
|
||||
The new-style casts (`static_cast', `reinterpret_cast', and
|
||||
`const_cast') are less vulnerable to unintended effects.
|
||||
|
||||
`-Woverloaded-virtual (C++ only)'
|
||||
Warn when a derived class function declaration may be an error in
|
||||
defining a virtual function. In a derived class, the definitions
|
||||
of virtual functions must match the type signature of a virtual
|
||||
function declared in the base class. With this option, the
|
||||
compiler warns when you define a function with the same name as a
|
||||
virtual function, but with a type signature that does not match any
|
||||
declarations from the base class.
|
||||
|
||||
`-Wno-pmf-conversions (C++ only)'
|
||||
Disable the diagnostic for converting a bound pointer to member
|
||||
function to a plain pointer.
|
||||
|
||||
`-Wsign-promo (C++ only)'
|
||||
Warn when overload resolution chooses a promotion from unsigned or
|
||||
enumeral type to a signed type over a conversion to an unsigned
|
||||
type of the same size. Previous versions of g++ would try to
|
||||
preserve unsignedness, but the standard mandates the current
|
||||
behavior.
|
||||
|
||||
`-Wsynth (C++ only)'
|
||||
Warn when g++'s synthesis behavior does not match that of cfront.
|
||||
For instance:
|
||||
|
||||
struct A {
|
||||
operator int ();
|
||||
A& operator = (int);
|
||||
};
|
||||
|
||||
main ()
|
||||
{
|
||||
A a,b;
|
||||
a = b;
|
||||
}
|
||||
|
||||
In this example, g++ will synthesize a default `A& operator =
|
||||
(const A&);', while cfront will use the user-defined `operator ='.
|
||||
|
||||
|
||||
File: gcc.info, Node: Warning Options, Next: Debugging Options, Prev: C++ Dialect Options, Up: Invoking GCC
|
||||
|
||||
Options to Request or Suppress Warnings
|
||||
=======================================
|
||||
|
||||
Warnings are diagnostic messages that report constructions which are
|
||||
not inherently erroneous but which are risky or suggest there may have
|
||||
been an error.
|
||||
|
||||
You can request many specific warnings with options beginning `-W',
|
||||
for example `-Wimplicit' to request warnings on implicit declarations.
|
||||
Each of these specific warning options also has a negative form
|
||||
beginning `-Wno-' to turn off warnings; for example, `-Wno-implicit'.
|
||||
This manual lists only one of the two forms, whichever is not the
|
||||
default.
|
||||
|
||||
These options control the amount and kinds of warnings produced by
|
||||
GCC:
|
||||
|
||||
`-fsyntax-only'
|
||||
Check the code for syntax errors, but don't do anything beyond
|
||||
that.
|
||||
|
||||
`-pedantic'
|
||||
Issue all the warnings demanded by strict ANSI C and ISO C++;
|
||||
reject all programs that use forbidden extensions.
|
||||
|
||||
Valid ANSI C and ISO C++ programs should compile properly with or
|
||||
without this option (though a rare few will require `-ansi').
|
||||
However, without this option, certain GNU extensions and
|
||||
traditional C and C++ features are supported as well. With this
|
||||
option, they are rejected.
|
||||
|
||||
`-pedantic' does not cause warning messages for use of the
|
||||
alternate keywords whose names begin and end with `__'. Pedantic
|
||||
warnings are also disabled in the expression that follows
|
||||
`__extension__'. However, only system header files should use
|
||||
these escape routes; application programs should avoid them.
|
||||
*Note Alternate Keywords::.
|
||||
|
||||
This option is not intended to be useful; it exists only to satisfy
|
||||
pedants who would otherwise claim that GCC fails to support the
|
||||
ANSI standard.
|
||||
|
||||
Some users try to use `-pedantic' to check programs for strict ANSI
|
||||
C conformance. They soon find that it does not do quite what they
|
||||
want: it finds some non-ANSI practices, but not all--only those
|
||||
for which ANSI C *requires* a diagnostic.
|
||||
|
||||
A feature to report any failure to conform to ANSI C might be
|
||||
useful in some instances, but would require considerable
|
||||
additional work and would be quite different from `-pedantic'. We
|
||||
don't have plans to support such a feature in the near future.
|
||||
|
||||
`-pedantic-errors'
|
||||
Like `-pedantic', except that errors are produced rather than
|
||||
warnings.
|
||||
|
||||
`-w'
|
||||
Inhibit all warning messages.
|
||||
|
||||
`-Wno-import'
|
||||
Inhibit warning messages about the use of `#import'.
|
||||
|
||||
`-Wchar-subscripts'
|
||||
Warn if an array subscript has type `char'. This is a common cause
|
||||
of error, as programmers often forget that this type is signed on
|
||||
some machines.
|
||||
|
||||
`-Wcomment'
|
||||
Warn whenever a comment-start sequence `/*' appears in a `/*'
|
||||
comment, or whenever a Backslash-Newline appears in a `//' comment.
|
||||
|
||||
`-Wformat'
|
||||
Check calls to `printf' and `scanf', etc., to make sure that the
|
||||
arguments supplied have types appropriate to the format string
|
||||
specified.
|
||||
|
||||
`-Wimplicit-int'
|
||||
Warn when a declaration does not specify a type.
|
||||
|
||||
`-Wimplicit-function-declaration'
|
||||
`-Werror-implicit-function-declaration'
|
||||
Give a warning (or error) whenever a function is used before being
|
||||
declared.
|
||||
|
||||
`-Wimplicit'
|
||||
Same as `-Wimplicit-int' and `-Wimplicit-function-'
|
||||
`declaration'.
|
||||
|
||||
`-Wmain'
|
||||
Warn if the type of `main' is suspicious. `main' should be a
|
||||
function with external linkage, returning int, taking either zero
|
||||
arguments, two, or three arguments of appropriate types.
|
||||
|
||||
`-Wmultichar'
|
||||
Warn if a multicharacter constant (`'FOOF'') is used. Usually they
|
||||
indicate a typo in the user's code, as they have
|
||||
implementation-defined values, and should not be used in portable
|
||||
code.
|
||||
|
||||
`-Wparentheses'
|
||||
Warn if parentheses are omitted in certain contexts, such as when
|
||||
there is an assignment in a context where a truth value is
|
||||
expected, or when operators are nested whose precedence people
|
||||
often get confused about.
|
||||
|
||||
Also warn about constructions where there may be confusion to which
|
||||
`if' statement an `else' branch belongs. Here is an example of
|
||||
such a case:
|
||||
|
||||
{
|
||||
if (a)
|
||||
if (b)
|
||||
foo ();
|
||||
else
|
||||
bar ();
|
||||
}
|
||||
|
||||
In C, every `else' branch belongs to the innermost possible `if'
|
||||
statement, which in this example is `if (b)'. This is often not
|
||||
what the programmer expected, as illustrated in the above example
|
||||
by indentation the programmer chose. When there is the potential
|
||||
for this confusion, GNU C will issue a warning when this flag is
|
||||
specified. To eliminate the warning, add explicit braces around
|
||||
the innermost `if' statement so there is no way the `else' could
|
||||
belong to the enclosing `if'. The resulting code would look like
|
||||
this:
|
||||
|
||||
{
|
||||
if (a)
|
||||
{
|
||||
if (b)
|
||||
foo ();
|
||||
else
|
||||
bar ();
|
||||
}
|
||||
}
|
||||
|
||||
`-Wreturn-type'
|
||||
Warn whenever a function is defined with a return-type that
|
||||
defaults to `int'. Also warn about any `return' statement with no
|
||||
return-value in a function whose return-type is not `void'.
|
||||
|
||||
`-Wswitch'
|
||||
Warn whenever a `switch' statement has an index of enumeral type
|
||||
and lacks a `case' for one or more of the named codes of that
|
||||
enumeration. (The presence of a `default' label prevents this
|
||||
warning.) `case' labels outside the enumeration range also
|
||||
provoke warnings when this option is used.
|
||||
|
||||
`-Wtrigraphs'
|
||||
Warn if any trigraphs are encountered (assuming they are enabled).
|
||||
|
||||
`-Wunused'
|
||||
Warn whenever a variable is unused aside from its declaration,
|
||||
whenever a function is declared static but never defined, whenever
|
||||
a label is declared but not used, and whenever a statement
|
||||
computes a result that is explicitly not used.
|
||||
|
||||
In order to get a warning about an unused function parameter, you
|
||||
must specify both `-W' and `-Wunused'.
|
||||
|
||||
To suppress this warning for an expression, simply cast it to
|
||||
void. For unused variables, parameters and labels, use the
|
||||
`unused' attribute (*note Variable Attributes::.).
|
||||
|
||||
`-Wuninitialized'
|
||||
An automatic variable is used without first being initialized.
|
||||
|
||||
These warnings are possible only in optimizing compilation,
|
||||
because they require data flow information that is computed only
|
||||
when optimizing. If you don't specify `-O', you simply won't get
|
||||
these warnings.
|
||||
|
||||
These warnings occur only for variables that are candidates for
|
||||
register allocation. Therefore, they do not occur for a variable
|
||||
that is declared `volatile', or whose address is taken, or whose
|
||||
size is other than 1, 2, 4 or 8 bytes. Also, they do not occur for
|
||||
structures, unions or arrays, even when they are in registers.
|
||||
|
||||
Note that there may be no warning about a variable that is used
|
||||
only to compute a value that itself is never used, because such
|
||||
computations may be deleted by data flow analysis before the
|
||||
warnings are printed.
|
||||
|
||||
These warnings are made optional because GCC is not smart enough
|
||||
to see all the reasons why the code might be correct despite
|
||||
appearing to have an error. Here is one example of how this can
|
||||
happen:
|
||||
|
||||
{
|
||||
int x;
|
||||
switch (y)
|
||||
{
|
||||
case 1: x = 1;
|
||||
break;
|
||||
case 2: x = 4;
|
||||
break;
|
||||
case 3: x = 5;
|
||||
}
|
||||
foo (x);
|
||||
}
|
||||
|
||||
If the value of `y' is always 1, 2 or 3, then `x' is always
|
||||
initialized, but GCC doesn't know this. Here is another common
|
||||
case:
|
||||
|
||||
{
|
||||
int save_y;
|
||||
if (change_y) save_y = y, y = new_y;
|
||||
...
|
||||
if (change_y) y = save_y;
|
||||
}
|
||||
|
||||
This has no bug because `save_y' is used only if it is set.
|
||||
|
||||
Some spurious warnings can be avoided if you declare all the
|
||||
functions you use that never return as `noreturn'. *Note Function
|
||||
Attributes::.
|
||||
|
||||
`-Wunknown-pragmas'
|
||||
Warn when a #pragma directive is encountered which is not
|
||||
understood by GCC. If this command line option is used, warnings
|
||||
will even be issued for unknown pragmas in system header files.
|
||||
This is not the case if the warnings were only enabled by the
|
||||
`-Wall' command line option.
|
||||
|
||||
`-Wall'
|
||||
All of the above `-W' options combined. This enables all the
|
||||
warnings about constructions that some users consider
|
||||
questionable, and that are easy to avoid (or modify to prevent the
|
||||
warning), even in conjunction with macros.
|
||||
|
||||
The following `-W...' options are not implied by `-Wall'. Some of
|
||||
them warn about constructions that users generally do not consider
|
||||
questionable, but which occasionally you might wish to check for;
|
||||
others warn about constructions that are necessary or hard to avoid in
|
||||
some cases, and there is no simple way to modify the code to suppress
|
||||
the warning.
|
||||
|
||||
`-W'
|
||||
Print extra warning messages for these events:
|
||||
|
||||
* A nonvolatile automatic variable might be changed by a call to
|
||||
`longjmp'. These warnings as well are possible only in
|
||||
optimizing compilation.
|
||||
|
||||
The compiler sees only the calls to `setjmp'. It cannot know
|
||||
where `longjmp' will be called; in fact, a signal handler
|
||||
could call it at any point in the code. As a result, you may
|
||||
get a warning even when there is in fact no problem because
|
||||
`longjmp' cannot in fact be called at the place which would
|
||||
cause a problem.
|
||||
|
||||
* A function can return either with or without a value.
|
||||
(Falling off the end of the function body is considered
|
||||
returning without a value.) For example, this function would
|
||||
evoke such a warning:
|
||||
|
||||
foo (a)
|
||||
{
|
||||
if (a > 0)
|
||||
return a;
|
||||
}
|
||||
|
||||
* An expression-statement or the left-hand side of a comma
|
||||
expression contains no side effects. To suppress the
|
||||
warning, cast the unused expression to void. For example, an
|
||||
expression such as `x[i,j]' will cause a warning, but
|
||||
`x[(void)i,j]' will not.
|
||||
|
||||
* An unsigned value is compared against zero with `<' or `<='.
|
||||
|
||||
* A comparison like `x<=y<=z' appears; this is equivalent to
|
||||
`(x<=y ? 1 : 0) <= z', which is a different interpretation
|
||||
from that of ordinary mathematical notation.
|
||||
|
||||
* Storage-class specifiers like `static' are not the first
|
||||
things in a declaration. According to the C Standard, this
|
||||
usage is obsolescent.
|
||||
|
||||
* If `-Wall' or `-Wunused' is also specified, warn about unused
|
||||
arguments.
|
||||
|
||||
* A comparison between signed and unsigned values could produce
|
||||
an incorrect result when the signed value is converted to
|
||||
unsigned. (But don't warn if `-Wno-sign-compare' is also
|
||||
specified.)
|
||||
|
||||
* An aggregate has a partly bracketed initializer. For
|
||||
example, the following code would evoke such a warning,
|
||||
because braces are missing around the initializer for `x.h':
|
||||
|
||||
struct s { int f, g; };
|
||||
struct t { struct s h; int i; };
|
||||
struct t x = { 1, 2, 3 };
|
||||
|
||||
* An aggregate has an initializer which does not initialize all
|
||||
members. For example, the following code would cause such a
|
||||
warning, because `x.h' would be implicitly initialized to
|
||||
zero:
|
||||
|
||||
struct s { int f, g, h; };
|
||||
struct s x = { 3, 4 };
|
||||
|
||||
`-Wtraditional'
|
||||
Warn about certain constructs that behave differently in
|
||||
traditional and ANSI C.
|
||||
|
||||
* Macro arguments occurring within string constants in the
|
||||
macro body. These would substitute the argument in
|
||||
traditional C, but are part of the constant in ANSI C.
|
||||
|
||||
* A function declared external in one block and then used after
|
||||
the end of the block.
|
||||
|
||||
* A `switch' statement has an operand of type `long'.
|
||||
|
||||
* A non-`static' function declaration follows a `static' one.
|
||||
This construct is not accepted by some traditional C
|
||||
compilers.
|
||||
|
||||
`-Wundef'
|
||||
Warn if an undefined identifier is evaluated in an `#if' directive.
|
||||
|
||||
`-Wshadow'
|
||||
Warn whenever a local variable shadows another local variable.
|
||||
|
||||
`-Wid-clash-LEN'
|
||||
Warn whenever two distinct identifiers match in the first LEN
|
||||
characters. This may help you prepare a program that will compile
|
||||
with certain obsolete, brain-damaged compilers.
|
||||
|
||||
`-Wlarger-than-LEN'
|
||||
Warn whenever an object of larger than LEN bytes is defined.
|
||||
|
||||
`-Wpointer-arith'
|
||||
Warn about anything that depends on the "size of" a function type
|
||||
or of `void'. GNU C assigns these types a size of 1, for
|
||||
convenience in calculations with `void *' pointers and pointers to
|
||||
functions.
|
||||
|
||||
`-Wbad-function-cast'
|
||||
Warn whenever a function call is cast to a non-matching type. For
|
||||
example, warn if `int malloc()' is cast to `anything *'.
|
||||
|
||||
`-Wcast-qual'
|
||||
Warn whenever a pointer is cast so as to remove a type qualifier
|
||||
from the target type. For example, warn if a `const char *' is
|
||||
cast to an ordinary `char *'.
|
||||
|
||||
`-Wcast-align'
|
||||
Warn whenever a pointer is cast such that the required alignment
|
||||
of the target is increased. For example, warn if a `char *' is
|
||||
cast to an `int *' on machines where integers can only be accessed
|
||||
at two- or four-byte boundaries.
|
||||
|
||||
`-Wwrite-strings'
|
||||
Give string constants the type `const char[LENGTH]' so that
|
||||
copying the address of one into a non-`const' `char *' pointer
|
||||
will get a warning. These warnings will help you find at compile
|
||||
time code that can try to write into a string constant, but only
|
||||
if you have been very careful about using `const' in declarations
|
||||
and prototypes. Otherwise, it will just be a nuisance; this is
|
||||
why we did not make `-Wall' request these warnings.
|
||||
|
||||
`-Wconversion'
|
||||
Warn if a prototype causes a type conversion that is different
|
||||
from what would happen to the same argument in the absence of a
|
||||
prototype. This includes conversions of fixed point to floating
|
||||
and vice versa, and conversions changing the width or signedness
|
||||
of a fixed point argument except when the same as the default
|
||||
promotion.
|
||||
|
||||
Also, warn if a negative integer constant expression is implicitly
|
||||
converted to an unsigned type. For example, warn about the
|
||||
assignment `x = -1' if `x' is unsigned. But do not warn about
|
||||
explicit casts like `(unsigned) -1'.
|
||||
|
||||
`-Wsign-compare'
|
||||
Warn when a comparison between signed and unsigned values could
|
||||
produce an incorrect result when the signed value is converted to
|
||||
unsigned. This warning is also enabled by `-W'; to get the other
|
||||
warnings of `-W' without this warning, use `-W -Wno-sign-compare'.
|
||||
|
||||
`-Waggregate-return'
|
||||
Warn if any functions that return structures or unions are defined
|
||||
or called. (In languages where you can return an array, this also
|
||||
elicits a warning.)
|
||||
|
||||
`-Wstrict-prototypes'
|
||||
Warn if a function is declared or defined without specifying the
|
||||
argument types. (An old-style function definition is permitted
|
||||
without a warning if preceded by a declaration which specifies the
|
||||
argument types.)
|
||||
|
||||
`-Wmissing-prototypes'
|
||||
Warn if a global function is defined without a previous prototype
|
||||
declaration. This warning is issued even if the definition itself
|
||||
provides a prototype. The aim is to detect global functions that
|
||||
fail to be declared in header files.
|
||||
|
||||
`-Wmissing-declarations'
|
||||
Warn if a global function is defined without a previous
|
||||
declaration. Do so even if the definition itself provides a
|
||||
prototype. Use this option to detect global functions that are
|
||||
not declared in header files.
|
||||
|
||||
`-Wmissing-noreturn'
|
||||
Warn about functions which might be candidates for attribute
|
||||
`noreturn'. Note these are only possible candidates, not absolute
|
||||
ones. Care should be taken to manually verify functions actually
|
||||
do not ever return before adding the `noreturn' attribute,
|
||||
otherwise subtle code generation bugs could be introduced.
|
||||
|
||||
`-Wredundant-decls'
|
||||
Warn if anything is declared more than once in the same scope,
|
||||
even in cases where multiple declaration is valid and changes
|
||||
nothing.
|
||||
|
||||
`-Wnested-externs'
|
||||
Warn if an `extern' declaration is encountered within an function.
|
||||
|
||||
`-Winline'
|
||||
Warn if a function can not be inlined, and either it was declared
|
||||
as inline, or else the `-finline-functions' option was given.
|
||||
|
||||
`-Wlong-long'
|
||||
Warn if `long long' type is used. This is default. To inhibit
|
||||
the warning messages, use `-Wno-long-long'. Flags `-Wlong-long'
|
||||
and `-Wno-long-long' are taken into account only when `-pedantic'
|
||||
flag is used.
|
||||
|
||||
`-Werror'
|
||||
Make all warnings into errors.
|
||||
|
||||
Executable
+1168
File diff suppressed because it is too large
Load Diff
Executable
+886
@@ -0,0 +1,886 @@
|
||||
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
|
||||
input file ../../gcc-2.95.2/gcc/gcc.texi.
|
||||
|
||||
INFO-DIR-SECTION Programming
|
||||
START-INFO-DIR-ENTRY
|
||||
* gcc: (gcc). The GNU Compiler Collection.
|
||||
END-INFO-DIR-ENTRY
|
||||
This file documents the use and the internals of the GNU compiler.
|
||||
|
||||
Published by the Free Software Foundation 59 Temple Place - Suite 330
|
||||
Boston, MA 02111-1307 USA
|
||||
|
||||
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
|
||||
1999 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 "Funding
|
||||
for Free Software" 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 one.
|
||||
|
||||
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 "Funding for Free Software", 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: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes
|
||||
|
||||
Computing the Length of an Insn
|
||||
-------------------------------
|
||||
|
||||
For many machines, multiple types of branch instructions are
|
||||
provided, each for different length branch displacements. In most
|
||||
cases, the assembler will choose the correct instruction to use.
|
||||
However, when the assembler cannot do so, GCC can when a special
|
||||
attribute, the `length' attribute, is defined. This attribute must be
|
||||
defined to have numeric values by specifying a null string in its
|
||||
`define_attr'.
|
||||
|
||||
In the case of the `length' attribute, two additional forms of
|
||||
arithmetic terms are allowed in test expressions:
|
||||
|
||||
`(match_dup N)'
|
||||
This refers to the address of operand N of the current insn, which
|
||||
must be a `label_ref'.
|
||||
|
||||
`(pc)'
|
||||
This refers to the address of the *current* insn. It might have
|
||||
been more consistent with other usage to make this the address of
|
||||
the *next* insn but this would be confusing because the length of
|
||||
the current insn is to be computed.
|
||||
|
||||
For normal insns, the length will be determined by value of the
|
||||
`length' attribute. In the case of `addr_vec' and `addr_diff_vec' insn
|
||||
patterns, the length is computed as the number of vectors multiplied by
|
||||
the size of each vector.
|
||||
|
||||
Lengths are measured in addressable storage units (bytes).
|
||||
|
||||
The following macros can be used to refine the length computation:
|
||||
|
||||
`FIRST_INSN_ADDRESS'
|
||||
When the `length' insn attribute is used, this macro specifies the
|
||||
value to be assigned to the address of the first insn in a
|
||||
function. If not specified, 0 is used.
|
||||
|
||||
`ADJUST_INSN_LENGTH (INSN, LENGTH)'
|
||||
If defined, modifies the length assigned to instruction INSN as a
|
||||
function of the context in which it is used. LENGTH is an lvalue
|
||||
that contains the initially computed length of the insn and should
|
||||
be updated with the correct length of the insn.
|
||||
|
||||
This macro will normally not be required. A case in which it is
|
||||
required is the ROMP. On this machine, the size of an `addr_vec'
|
||||
insn must be increased by two to compensate for the fact that
|
||||
alignment may be required.
|
||||
|
||||
The routine that returns `get_attr_length' (the value of the
|
||||
`length' attribute) can be used by the output routine to determine the
|
||||
form of the branch instruction to be written, as the example below
|
||||
illustrates.
|
||||
|
||||
As an example of the specification of variable-length branches,
|
||||
consider the IBM 360. If we adopt the convention that a register will
|
||||
be set to the starting address of a function, we can jump to labels
|
||||
within 4k of the start using a four-byte instruction. Otherwise, we
|
||||
need a six-byte sequence to load the address from memory and then
|
||||
branch to it.
|
||||
|
||||
On such a machine, a pattern for a branch instruction might be
|
||||
specified as follows:
|
||||
|
||||
(define_insn "jump"
|
||||
[(set (pc)
|
||||
(label_ref (match_operand 0 "" "")))]
|
||||
""
|
||||
"*
|
||||
{
|
||||
return (get_attr_length (insn) == 4
|
||||
? \"b %l0\" : \"l r15,=a(%l0); br r15\");
|
||||
}"
|
||||
[(set (attr "length") (if_then_else (lt (match_dup 0) (const_int 4096))
|
||||
(const_int 4)
|
||||
(const_int 6)))])
|
||||
|
||||
|
||||
File: gcc.info, Node: Constant Attributes, Next: Delay Slots, Prev: Insn Lengths, Up: Insn Attributes
|
||||
|
||||
Constant Attributes
|
||||
-------------------
|
||||
|
||||
A special form of `define_attr', where the expression for the
|
||||
default value is a `const' expression, indicates an attribute that is
|
||||
constant for a given run of the compiler. Constant attributes may be
|
||||
used to specify which variety of processor is used. For example,
|
||||
|
||||
(define_attr "cpu" "m88100,m88110,m88000"
|
||||
(const
|
||||
(cond [(symbol_ref "TARGET_88100") (const_string "m88100")
|
||||
(symbol_ref "TARGET_88110") (const_string "m88110")]
|
||||
(const_string "m88000"))))
|
||||
|
||||
(define_attr "memory" "fast,slow"
|
||||
(const
|
||||
(if_then_else (symbol_ref "TARGET_FAST_MEM")
|
||||
(const_string "fast")
|
||||
(const_string "slow"))))
|
||||
|
||||
The routine generated for constant attributes has no parameters as it
|
||||
does not depend on any particular insn. RTL expressions used to define
|
||||
the value of a constant attribute may use the `symbol_ref' form, but
|
||||
may not use either the `match_operand' form or `eq_attr' forms
|
||||
involving insn attributes.
|
||||
|
||||
|
||||
File: gcc.info, Node: Delay Slots, Next: Function Units, Prev: Constant Attributes, Up: Insn Attributes
|
||||
|
||||
Delay Slot Scheduling
|
||||
---------------------
|
||||
|
||||
The insn attribute mechanism can be used to specify the requirements
|
||||
for delay slots, if any, on a target machine. An instruction is said to
|
||||
require a "delay slot" if some instructions that are physically after
|
||||
the instruction are executed as if they were located before it.
|
||||
Classic examples are branch and call instructions, which often execute
|
||||
the following instruction before the branch or call is performed.
|
||||
|
||||
On some machines, conditional branch instructions can optionally
|
||||
"annul" instructions in the delay slot. This means that the
|
||||
instruction will not be executed for certain branch outcomes. Both
|
||||
instructions that annul if the branch is true and instructions that
|
||||
annul if the branch is false are supported.
|
||||
|
||||
Delay slot scheduling differs from instruction scheduling in that
|
||||
determining whether an instruction needs a delay slot is dependent only
|
||||
on the type of instruction being generated, not on data flow between the
|
||||
instructions. See the next section for a discussion of data-dependent
|
||||
instruction scheduling.
|
||||
|
||||
The requirement of an insn needing one or more delay slots is
|
||||
indicated via the `define_delay' expression. It has the following form:
|
||||
|
||||
(define_delay TEST
|
||||
[DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1
|
||||
DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2
|
||||
...])
|
||||
|
||||
TEST is an attribute test that indicates whether this `define_delay'
|
||||
applies to a particular insn. If so, the number of required delay
|
||||
slots is determined by the length of the vector specified as the second
|
||||
argument. An insn placed in delay slot N must satisfy attribute test
|
||||
DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns
|
||||
may be annulled if the branch is true. Similarly, ANNUL-FALSE-N
|
||||
specifies which insns in the delay slot may be annulled if the branch
|
||||
is false. If annulling is not supported for that delay slot, `(nil)'
|
||||
should be coded.
|
||||
|
||||
For example, in the common case where branch and call insns require
|
||||
a single delay slot, which may contain any insn other than a branch or
|
||||
call, the following would be placed in the `md' file:
|
||||
|
||||
(define_delay (eq_attr "type" "branch,call")
|
||||
[(eq_attr "type" "!branch,call") (nil) (nil)])
|
||||
|
||||
Multiple `define_delay' expressions may be specified. In this case,
|
||||
each such expression specifies different delay slot requirements and
|
||||
there must be no insn for which tests in two `define_delay' expressions
|
||||
are both true.
|
||||
|
||||
For example, if we have a machine that requires one delay slot for
|
||||
branches but two for calls, no delay slot can contain a branch or call
|
||||
insn, and any valid insn in the delay slot for the branch can be
|
||||
annulled if the branch is true, we might represent this as follows:
|
||||
|
||||
(define_delay (eq_attr "type" "branch")
|
||||
[(eq_attr "type" "!branch,call")
|
||||
(eq_attr "type" "!branch,call")
|
||||
(nil)])
|
||||
|
||||
(define_delay (eq_attr "type" "call")
|
||||
[(eq_attr "type" "!branch,call") (nil) (nil)
|
||||
(eq_attr "type" "!branch,call") (nil) (nil)])
|
||||
|
||||
|
||||
File: gcc.info, Node: Function Units, Prev: Delay Slots, Up: Insn Attributes
|
||||
|
||||
Specifying Function Units
|
||||
-------------------------
|
||||
|
||||
On most RISC machines, there are instructions whose results are not
|
||||
available for a specific number of cycles. Common cases are
|
||||
instructions that load data from memory. On many machines, a pipeline
|
||||
stall will result if the data is referenced too soon after the load
|
||||
instruction.
|
||||
|
||||
In addition, many newer microprocessors have multiple function
|
||||
units, usually one for integer and one for floating point, and often
|
||||
will incur pipeline stalls when a result that is needed is not yet
|
||||
ready.
|
||||
|
||||
The descriptions in this section allow the specification of how much
|
||||
time must elapse between the execution of an instruction and the time
|
||||
when its result is used. It also allows specification of when the
|
||||
execution of an instruction will delay execution of similar instructions
|
||||
due to function unit conflicts.
|
||||
|
||||
For the purposes of the specifications in this section, a machine is
|
||||
divided into "function units", each of which execute a specific class
|
||||
of instructions in first-in-first-out order. Function units that
|
||||
accept one instruction each cycle and allow a result to be used in the
|
||||
succeeding instruction (usually via forwarding) need not be specified.
|
||||
Classic RISC microprocessors will normally have a single function unit,
|
||||
which we can call `memory'. The newer "superscalar" processors will
|
||||
often have function units for floating point operations, usually at
|
||||
least a floating point adder and multiplier.
|
||||
|
||||
Each usage of a function units by a class of insns is specified with
|
||||
a `define_function_unit' expression, which looks like this:
|
||||
|
||||
(define_function_unit NAME MULTIPLICITY SIMULTANEITY
|
||||
TEST READY-DELAY ISSUE-DELAY
|
||||
[CONFLICT-LIST])
|
||||
|
||||
NAME is a string giving the name of the function unit.
|
||||
|
||||
MULTIPLICITY is an integer specifying the number of identical units
|
||||
in the processor. If more than one unit is specified, they will be
|
||||
scheduled independently. Only truly independent units should be
|
||||
counted; a pipelined unit should be specified as a single unit. (The
|
||||
only common example of a machine that has multiple function units for a
|
||||
single instruction class that are truly independent and not pipelined
|
||||
are the two multiply and two increment units of the CDC 6600.)
|
||||
|
||||
SIMULTANEITY specifies the maximum number of insns that can be
|
||||
executing in each instance of the function unit simultaneously or zero
|
||||
if the unit is pipelined and has no limit.
|
||||
|
||||
All `define_function_unit' definitions referring to function unit
|
||||
NAME must have the same name and values for MULTIPLICITY and
|
||||
SIMULTANEITY.
|
||||
|
||||
TEST is an attribute test that selects the insns we are describing
|
||||
in this definition. Note that an insn may use more than one function
|
||||
unit and a function unit may be specified in more than one
|
||||
`define_function_unit'.
|
||||
|
||||
READY-DELAY is an integer that specifies the number of cycles after
|
||||
which the result of the instruction can be used without introducing any
|
||||
stalls.
|
||||
|
||||
ISSUE-DELAY is an integer that specifies the number of cycles after
|
||||
the instruction matching the TEST expression begins using this unit
|
||||
until a subsequent instruction can begin. A cost of N indicates an N-1
|
||||
cycle delay. A subsequent instruction may also be delayed if an
|
||||
earlier instruction has a longer READY-DELAY value. This blocking
|
||||
effect is computed using the SIMULTANEITY, READY-DELAY, ISSUE-DELAY,
|
||||
and CONFLICT-LIST terms. For a normal non-pipelined function unit,
|
||||
SIMULTANEITY is one, the unit is taken to block for the READY-DELAY
|
||||
cycles of the executing insn, and smaller values of ISSUE-DELAY are
|
||||
ignored.
|
||||
|
||||
CONFLICT-LIST is an optional list giving detailed conflict costs for
|
||||
this unit. If specified, it is a list of condition test expressions to
|
||||
be applied to insns chosen to execute in NAME following the particular
|
||||
insn matching TEST that is already executing in NAME. For each insn in
|
||||
the list, ISSUE-DELAY specifies the conflict cost; for insns not in the
|
||||
list, the cost is zero. If not specified, CONFLICT-LIST defaults to
|
||||
all instructions that use the function unit.
|
||||
|
||||
Typical uses of this vector are where a floating point function unit
|
||||
can pipeline either single- or double-precision operations, but not
|
||||
both, or where a memory unit can pipeline loads, but not stores, etc.
|
||||
|
||||
As an example, consider a classic RISC machine where the result of a
|
||||
load instruction is not available for two cycles (a single "delay"
|
||||
instruction is required) and where only one load instruction can be
|
||||
executed simultaneously. This would be specified as:
|
||||
|
||||
(define_function_unit "memory" 1 1 (eq_attr "type" "load") 2 0)
|
||||
|
||||
For the case of a floating point function unit that can pipeline
|
||||
either single or double precision, but not both, the following could be
|
||||
specified:
|
||||
|
||||
(define_function_unit
|
||||
"fp" 1 0 (eq_attr "type" "sp_fp") 4 4 [(eq_attr "type" "dp_fp")])
|
||||
(define_function_unit
|
||||
"fp" 1 0 (eq_attr "type" "dp_fp") 4 4 [(eq_attr "type" "sp_fp")])
|
||||
|
||||
*Note:* The scheduler attempts to avoid function unit conflicts and
|
||||
uses all the specifications in the `define_function_unit' expression.
|
||||
It has recently come to our attention that these specifications may not
|
||||
allow modeling of some of the newer "superscalar" processors that have
|
||||
insns using multiple pipelined units. These insns will cause a
|
||||
potential conflict for the second unit used during their execution and
|
||||
there is no way of representing that conflict. We welcome any examples
|
||||
of how function unit conflicts work in such processors and suggestions
|
||||
for their representation.
|
||||
|
||||
|
||||
File: gcc.info, Node: Target Macros, Next: Config, Prev: Machine Desc, Up: Top
|
||||
|
||||
Target Description Macros
|
||||
*************************
|
||||
|
||||
In addition to the file `MACHINE.md', a machine description includes
|
||||
a C header file conventionally given the name `MACHINE.h'. This header
|
||||
file defines numerous macros that convey the information about the
|
||||
target machine that does not fit into the scheme of the `.md' file.
|
||||
The file `tm.h' should be a link to `MACHINE.h'. The header file
|
||||
`config.h' includes `tm.h' and most compiler source files include
|
||||
`config.h'.
|
||||
|
||||
* Menu:
|
||||
|
||||
* Driver:: Controlling how the driver runs the compilation passes.
|
||||
* Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'.
|
||||
* Storage Layout:: Defining sizes and alignments of data.
|
||||
* Type Layout:: Defining sizes and properties of basic user data types.
|
||||
* Registers:: Naming and describing the hardware registers.
|
||||
* Register Classes:: Defining the classes of hardware registers.
|
||||
* Stack and Calling:: Defining which way the stack grows and by how much.
|
||||
* Varargs:: Defining the varargs macros.
|
||||
* Trampolines:: Code set up at run time to enter a nested function.
|
||||
* Library Calls:: Controlling how library routines are implicitly called.
|
||||
* Addressing Modes:: Defining addressing modes valid for memory operands.
|
||||
* Condition Code:: Defining how insns update the condition code.
|
||||
* Costs:: Defining relative costs of different operations.
|
||||
* Sections:: Dividing storage into text, data, and other sections.
|
||||
* PIC:: Macros for position independent code.
|
||||
* Assembler Format:: Defining how to write insns and pseudo-ops to output.
|
||||
* Debugging Info:: Defining the format of debugging output.
|
||||
* Cross-compilation:: Handling floating point for cross-compilers.
|
||||
* Misc:: Everything else.
|
||||
|
||||
|
||||
File: gcc.info, Node: Driver, Next: Run-time Target, Up: Target Macros
|
||||
|
||||
Controlling the Compilation Driver, `gcc'
|
||||
=========================================
|
||||
|
||||
You can control the compilation driver.
|
||||
|
||||
`SWITCH_TAKES_ARG (CHAR)'
|
||||
A C expression which determines whether the option `-CHAR' takes
|
||||
arguments. The value should be the number of arguments that
|
||||
option takes-zero, for many options.
|
||||
|
||||
By default, this macro is defined as `DEFAULT_SWITCH_TAKES_ARG',
|
||||
which handles the standard options properly. You need not define
|
||||
`SWITCH_TAKES_ARG' unless you wish to add additional options which
|
||||
take arguments. Any redefinition should call
|
||||
`DEFAULT_SWITCH_TAKES_ARG' and then check for additional options.
|
||||
|
||||
`WORD_SWITCH_TAKES_ARG (NAME)'
|
||||
A C expression which determines whether the option `-NAME' takes
|
||||
arguments. The value should be the number of arguments that
|
||||
option takes-zero, for many options. This macro rather than
|
||||
`SWITCH_TAKES_ARG' is used for multi-character option names.
|
||||
|
||||
By default, this macro is defined as
|
||||
`DEFAULT_WORD_SWITCH_TAKES_ARG', which handles the standard options
|
||||
properly. You need not define `WORD_SWITCH_TAKES_ARG' unless you
|
||||
wish to add additional options which take arguments. Any
|
||||
redefinition should call `DEFAULT_WORD_SWITCH_TAKES_ARG' and then
|
||||
check for additional options.
|
||||
|
||||
`SWITCH_CURTAILS_COMPILATION (CHAR)'
|
||||
A C expression which determines whether the option `-CHAR' stops
|
||||
compilation before the generation of an executable. The value is
|
||||
boolean, non-zero if the option does stop an executable from being
|
||||
generated, zero otherwise.
|
||||
|
||||
By default, this macro is defined as
|
||||
`DEFAULT_SWITCH_CURTAILS_COMPILATION', which handles the standard
|
||||
options properly. You need not define
|
||||
`SWITCH_CURTAILS_COMPILATION' unless you wish to add additional
|
||||
options which affect the generation of an executable. Any
|
||||
redefinition should call `DEFAULT_SWITCH_CURTAILS_COMPILATION' and
|
||||
then check for additional options.
|
||||
|
||||
`SWITCHES_NEED_SPACES'
|
||||
A string-valued C expression which enumerates the options for which
|
||||
the linker needs a space between the option and its argument.
|
||||
|
||||
If this macro is not defined, the default value is `""'.
|
||||
|
||||
`CPP_SPEC'
|
||||
A C string constant that tells the GNU CC driver program options to
|
||||
pass to CPP. It can also specify how to translate options you
|
||||
give to GNU CC into options for GNU CC to pass to the CPP.
|
||||
|
||||
Do not define this macro if it does not need to do anything.
|
||||
|
||||
`NO_BUILTIN_SIZE_TYPE'
|
||||
If this macro is defined, the preprocessor will not define the
|
||||
builtin macro `__SIZE_TYPE__'. The macro `__SIZE_TYPE__' must
|
||||
then be defined by `CPP_SPEC' instead.
|
||||
|
||||
This should be defined if `SIZE_TYPE' depends on target dependent
|
||||
flags which are not accessible to the preprocessor. Otherwise, it
|
||||
should not be defined.
|
||||
|
||||
`NO_BUILTIN_PTRDIFF_TYPE'
|
||||
If this macro is defined, the preprocessor will not define the
|
||||
builtin macro `__PTRDIFF_TYPE__'. The macro `__PTRDIFF_TYPE__'
|
||||
must then be defined by `CPP_SPEC' instead.
|
||||
|
||||
This should be defined if `PTRDIFF_TYPE' depends on target
|
||||
dependent flags which are not accessible to the preprocessor.
|
||||
Otherwise, it should not be defined.
|
||||
|
||||
`SIGNED_CHAR_SPEC'
|
||||
A C string constant that tells the GNU CC driver program options to
|
||||
pass to CPP. By default, this macro is defined to pass the option
|
||||
`-D__CHAR_UNSIGNED__' to CPP if `char' will be treated as
|
||||
`unsigned char' by `cc1'.
|
||||
|
||||
Do not define this macro unless you need to override the default
|
||||
definition.
|
||||
|
||||
`CC1_SPEC'
|
||||
A C string constant that tells the GNU CC driver program options to
|
||||
pass to `cc1'. It can also specify how to translate options you
|
||||
give to GNU CC into options for GNU CC to pass to the `cc1'.
|
||||
|
||||
Do not define this macro if it does not need to do anything.
|
||||
|
||||
`CC1PLUS_SPEC'
|
||||
A C string constant that tells the GNU CC driver program options to
|
||||
pass to `cc1plus'. It can also specify how to translate options
|
||||
you give to GNU CC into options for GNU CC to pass to the
|
||||
`cc1plus'.
|
||||
|
||||
Do not define this macro if it does not need to do anything.
|
||||
|
||||
`ASM_SPEC'
|
||||
A C string constant that tells the GNU CC driver program options to
|
||||
pass to the assembler. It can also specify how to translate
|
||||
options you give to GNU CC into options for GNU CC to pass to the
|
||||
assembler. See the file `sun3.h' for an example of this.
|
||||
|
||||
Do not define this macro if it does not need to do anything.
|
||||
|
||||
`ASM_FINAL_SPEC'
|
||||
A C string constant that tells the GNU CC driver program how to
|
||||
run any programs which cleanup after the normal assembler.
|
||||
Normally, this is not needed. See the file `mips.h' for an
|
||||
example of this.
|
||||
|
||||
Do not define this macro if it does not need to do anything.
|
||||
|
||||
`LINK_SPEC'
|
||||
A C string constant that tells the GNU CC driver program options to
|
||||
pass to the linker. It can also specify how to translate options
|
||||
you give to GNU CC into options for GNU CC to pass to the linker.
|
||||
|
||||
Do not define this macro if it does not need to do anything.
|
||||
|
||||
`LIB_SPEC'
|
||||
Another C string constant used much like `LINK_SPEC'. The
|
||||
difference between the two is that `LIB_SPEC' is used at the end
|
||||
of the command given to the linker.
|
||||
|
||||
If this macro is not defined, a default is provided that loads the
|
||||
standard C library from the usual place. See `gcc.c'.
|
||||
|
||||
`LIBGCC_SPEC'
|
||||
Another C string constant that tells the GNU CC driver program how
|
||||
and when to place a reference to `libgcc.a' into the linker
|
||||
command line. This constant is placed both before and after the
|
||||
value of `LIB_SPEC'.
|
||||
|
||||
If this macro is not defined, the GNU CC driver provides a default
|
||||
that passes the string `-lgcc' to the linker unless the `-shared'
|
||||
option is specified.
|
||||
|
||||
`STARTFILE_SPEC'
|
||||
Another C string constant used much like `LINK_SPEC'. The
|
||||
difference between the two is that `STARTFILE_SPEC' is used at the
|
||||
very beginning of the command given to the linker.
|
||||
|
||||
If this macro is not defined, a default is provided that loads the
|
||||
standard C startup file from the usual place. See `gcc.c'.
|
||||
|
||||
`ENDFILE_SPEC'
|
||||
Another C string constant used much like `LINK_SPEC'. The
|
||||
difference between the two is that `ENDFILE_SPEC' is used at the
|
||||
very end of the command given to the linker.
|
||||
|
||||
Do not define this macro if it does not need to do anything.
|
||||
|
||||
`EXTRA_SPECS'
|
||||
Define this macro to provide additional specifications to put in
|
||||
the `specs' file that can be used in various specifications like
|
||||
`CC1_SPEC'.
|
||||
|
||||
The definition should be an initializer for an array of structures,
|
||||
containing a string constant, that defines the specification name,
|
||||
and a string constant that provides the specification.
|
||||
|
||||
Do not define this macro if it does not need to do anything.
|
||||
|
||||
`EXTRA_SPECS' is useful when an architecture contains several
|
||||
related targets, which have various `..._SPECS' which are similar
|
||||
to each other, and the maintainer would like one central place to
|
||||
keep these definitions.
|
||||
|
||||
For example, the PowerPC System V.4 targets use `EXTRA_SPECS' to
|
||||
define either `_CALL_SYSV' when the System V calling sequence is
|
||||
used or `_CALL_AIX' when the older AIX-based calling sequence is
|
||||
used.
|
||||
|
||||
The `config/rs6000/rs6000.h' target file defines:
|
||||
|
||||
#define EXTRA_SPECS \
|
||||
{ "cpp_sysv_default", CPP_SYSV_DEFAULT },
|
||||
|
||||
#define CPP_SYS_DEFAULT ""
|
||||
|
||||
The `config/rs6000/sysv.h' target file defines:
|
||||
#undef CPP_SPEC
|
||||
#define CPP_SPEC \
|
||||
"%{posix: -D_POSIX_SOURCE } \
|
||||
%{mcall-sysv: -D_CALL_SYSV } %{mcall-aix: -D_CALL_AIX } \
|
||||
%{!mcall-sysv: %{!mcall-aix: %(cpp_sysv_default) }} \
|
||||
%{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}"
|
||||
|
||||
#undef CPP_SYSV_DEFAULT
|
||||
#define CPP_SYSV_DEFAULT "-D_CALL_SYSV"
|
||||
|
||||
while the `config/rs6000/eabiaix.h' target file defines
|
||||
`CPP_SYSV_DEFAULT' as:
|
||||
|
||||
#undef CPP_SYSV_DEFAULT
|
||||
#define CPP_SYSV_DEFAULT "-D_CALL_AIX"
|
||||
|
||||
`LINK_LIBGCC_SPECIAL'
|
||||
Define this macro if the driver program should find the library
|
||||
`libgcc.a' itself and should not pass `-L' options to the linker.
|
||||
If you do not define this macro, the driver program will pass the
|
||||
argument `-lgcc' to tell the linker to do the search and will pass
|
||||
`-L' options to it.
|
||||
|
||||
`LINK_LIBGCC_SPECIAL_1'
|
||||
Define this macro if the driver program should find the library
|
||||
`libgcc.a'. If you do not define this macro, the driver program
|
||||
will pass the argument `-lgcc' to tell the linker to do the search.
|
||||
This macro is similar to `LINK_LIBGCC_SPECIAL', except that it does
|
||||
not affect `-L' options.
|
||||
|
||||
`LINK_COMMAND_SPEC'
|
||||
A C string constant giving the complete command line need to
|
||||
execute the linker. When you do this, you will need to update
|
||||
your port each time a change is made to the link command line
|
||||
within `gcc.c'. Therefore, define this macro only if you need to
|
||||
completely redefine the command line for invoking the linker and
|
||||
there is no other way to accomplish the effect you need.
|
||||
|
||||
`MULTILIB_DEFAULTS'
|
||||
Define this macro as a C expression for the initializer of an
|
||||
array of string to tell the driver program which options are
|
||||
defaults for this target and thus do not need to be handled
|
||||
specially when using `MULTILIB_OPTIONS'.
|
||||
|
||||
Do not define this macro if `MULTILIB_OPTIONS' is not defined in
|
||||
the target makefile fragment or if none of the options listed in
|
||||
`MULTILIB_OPTIONS' are set by default. *Note Target Fragment::.
|
||||
|
||||
`RELATIVE_PREFIX_NOT_LINKDIR'
|
||||
Define this macro to tell `gcc' that it should only translate a
|
||||
`-B' prefix into a `-L' linker option if the prefix indicates an
|
||||
absolute file name.
|
||||
|
||||
`STANDARD_EXEC_PREFIX'
|
||||
Define this macro as a C string constant if you wish to override
|
||||
the standard choice of `/usr/local/lib/gcc-lib/' as the default
|
||||
prefix to try when searching for the executable files of the
|
||||
compiler.
|
||||
|
||||
`MD_EXEC_PREFIX'
|
||||
If defined, this macro is an additional prefix to try after
|
||||
`STANDARD_EXEC_PREFIX'. `MD_EXEC_PREFIX' is not searched when the
|
||||
`-b' option is used, or the compiler is built as a cross compiler.
|
||||
If you define `MD_EXEC_PREFIX', then be sure to add it to the
|
||||
list of directories used to find the assembler in `configure.in'.
|
||||
|
||||
`STANDARD_STARTFILE_PREFIX'
|
||||
Define this macro as a C string constant if you wish to override
|
||||
the standard choice of `/usr/local/lib/' as the default prefix to
|
||||
try when searching for startup files such as `crt0.o'.
|
||||
|
||||
`MD_STARTFILE_PREFIX'
|
||||
If defined, this macro supplies an additional prefix to try after
|
||||
the standard prefixes. `MD_EXEC_PREFIX' is not searched when the
|
||||
`-b' option is used, or when the compiler is built as a cross
|
||||
compiler.
|
||||
|
||||
`MD_STARTFILE_PREFIX_1'
|
||||
If defined, this macro supplies yet another prefix to try after the
|
||||
standard prefixes. It is not searched when the `-b' option is
|
||||
used, or when the compiler is built as a cross compiler.
|
||||
|
||||
`INIT_ENVIRONMENT'
|
||||
Define this macro as a C string constant if you wish to set
|
||||
environment variables for programs called by the driver, such as
|
||||
the assembler and loader. The driver passes the value of this
|
||||
macro to `putenv' to initialize the necessary environment
|
||||
variables.
|
||||
|
||||
`LOCAL_INCLUDE_DIR'
|
||||
Define this macro as a C string constant if you wish to override
|
||||
the standard choice of `/usr/local/include' as the default prefix
|
||||
to try when searching for local header files. `LOCAL_INCLUDE_DIR'
|
||||
comes before `SYSTEM_INCLUDE_DIR' in the search order.
|
||||
|
||||
Cross compilers do not use this macro and do not search either
|
||||
`/usr/local/include' or its replacement.
|
||||
|
||||
`SYSTEM_INCLUDE_DIR'
|
||||
Define this macro as a C string constant if you wish to specify a
|
||||
system-specific directory to search for header files before the
|
||||
standard directory. `SYSTEM_INCLUDE_DIR' comes before
|
||||
`STANDARD_INCLUDE_DIR' in the search order.
|
||||
|
||||
Cross compilers do not use this macro and do not search the
|
||||
directory specified.
|
||||
|
||||
`STANDARD_INCLUDE_DIR'
|
||||
Define this macro as a C string constant if you wish to override
|
||||
the standard choice of `/usr/include' as the default prefix to try
|
||||
when searching for header files.
|
||||
|
||||
Cross compilers do not use this macro and do not search either
|
||||
`/usr/include' or its replacement.
|
||||
|
||||
`STANDARD_INCLUDE_COMPONENT'
|
||||
The "component" corresponding to `STANDARD_INCLUDE_DIR'. See
|
||||
`INCLUDE_DEFAULTS', below, for the description of components. If
|
||||
you do not define this macro, no component is used.
|
||||
|
||||
`INCLUDE_DEFAULTS'
|
||||
Define this macro if you wish to override the entire default
|
||||
search path for include files. For a native compiler, the default
|
||||
search path usually consists of `GCC_INCLUDE_DIR',
|
||||
`LOCAL_INCLUDE_DIR', `SYSTEM_INCLUDE_DIR',
|
||||
`GPLUSPLUS_INCLUDE_DIR', and `STANDARD_INCLUDE_DIR'. In addition,
|
||||
`GPLUSPLUS_INCLUDE_DIR' and `GCC_INCLUDE_DIR' are defined
|
||||
automatically by `Makefile', and specify private search areas for
|
||||
GCC. The directory `GPLUSPLUS_INCLUDE_DIR' is used only for C++
|
||||
programs.
|
||||
|
||||
The definition should be an initializer for an array of structures.
|
||||
Each array element should have four elements: the directory name (a
|
||||
string constant), the component name, and flag for C++-only
|
||||
directories, and a flag showing that the includes in the directory
|
||||
don't need to be wrapped in `extern `C'' when compiling C++. Mark
|
||||
the end of the array with a null element.
|
||||
|
||||
The component name denotes what GNU package the include file is
|
||||
part of, if any, in all upper-case letters. For example, it might
|
||||
be `GCC' or `BINUTILS'. If the package is part of the a
|
||||
vendor-supplied operating system, code the component name as `0'.
|
||||
|
||||
For example, here is the definition used for VAX/VMS:
|
||||
|
||||
#define INCLUDE_DEFAULTS \
|
||||
{ \
|
||||
{ "GNU_GXX_INCLUDE:", "G++", 1, 1}, \
|
||||
{ "GNU_CC_INCLUDE:", "GCC", 0, 0}, \
|
||||
{ "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \
|
||||
{ ".", 0, 0, 0}, \
|
||||
{ 0, 0, 0, 0} \
|
||||
}
|
||||
|
||||
Here is the order of prefixes tried for exec files:
|
||||
|
||||
1. Any prefixes specified by the user with `-B'.
|
||||
|
||||
2. The environment variable `GCC_EXEC_PREFIX', if any.
|
||||
|
||||
3. The directories specified by the environment variable
|
||||
`COMPILER_PATH'.
|
||||
|
||||
4. The macro `STANDARD_EXEC_PREFIX'.
|
||||
|
||||
5. `/usr/lib/gcc/'.
|
||||
|
||||
6. The macro `MD_EXEC_PREFIX', if any.
|
||||
|
||||
Here is the order of prefixes tried for startfiles:
|
||||
|
||||
1. Any prefixes specified by the user with `-B'.
|
||||
|
||||
2. The environment variable `GCC_EXEC_PREFIX', if any.
|
||||
|
||||
3. The directories specified by the environment variable
|
||||
`LIBRARY_PATH' (native only, cross compilers do not use this).
|
||||
|
||||
4. The macro `STANDARD_EXEC_PREFIX'.
|
||||
|
||||
5. `/usr/lib/gcc/'.
|
||||
|
||||
6. The macro `MD_EXEC_PREFIX', if any.
|
||||
|
||||
7. The macro `MD_STARTFILE_PREFIX', if any.
|
||||
|
||||
8. The macro `STANDARD_STARTFILE_PREFIX'.
|
||||
|
||||
9. `/lib/'.
|
||||
|
||||
10. `/usr/lib/'.
|
||||
|
||||
|
||||
File: gcc.info, Node: Run-time Target, Next: Storage Layout, Prev: Driver, Up: Target Macros
|
||||
|
||||
Run-time Target Specification
|
||||
=============================
|
||||
|
||||
Here are run-time target specifications.
|
||||
|
||||
`CPP_PREDEFINES'
|
||||
Define this to be a string constant containing `-D' options to
|
||||
define the predefined macros that identify this machine and system.
|
||||
These macros will be predefined unless the `-ansi' option is
|
||||
specified.
|
||||
|
||||
In addition, a parallel set of macros are predefined, whose names
|
||||
are made by appending `__' at the beginning and at the end. These
|
||||
`__' macros are permitted by the ANSI standard, so they are
|
||||
predefined regardless of whether `-ansi' is specified.
|
||||
|
||||
For example, on the Sun, one can use the following value:
|
||||
|
||||
"-Dmc68000 -Dsun -Dunix"
|
||||
|
||||
The result is to define the macros `__mc68000__', `__sun__' and
|
||||
`__unix__' unconditionally, and the macros `mc68000', `sun' and
|
||||
`unix' provided `-ansi' is not specified.
|
||||
|
||||
`extern int target_flags;'
|
||||
This declaration should be present.
|
||||
|
||||
`TARGET_...'
|
||||
This series of macros is to allow compiler command arguments to
|
||||
enable or disable the use of optional features of the target
|
||||
machine. For example, one machine description serves both the
|
||||
68000 and the 68020; a command argument tells the compiler whether
|
||||
it should use 68020-only instructions or not. This command
|
||||
argument works by means of a macro `TARGET_68020' that tests a bit
|
||||
in `target_flags'.
|
||||
|
||||
Define a macro `TARGET_FEATURENAME' for each such option. Its
|
||||
definition should test a bit in `target_flags'; for example:
|
||||
|
||||
#define TARGET_68020 (target_flags & 1)
|
||||
|
||||
One place where these macros are used is in the
|
||||
condition-expressions of instruction patterns. Note how
|
||||
`TARGET_68020' appears frequently in the 68000 machine description
|
||||
file, `m68k.md'. Another place they are used is in the
|
||||
definitions of the other macros in the `MACHINE.h' file.
|
||||
|
||||
`TARGET_SWITCHES'
|
||||
This macro defines names of command options to set and clear bits
|
||||
in `target_flags'. Its definition is an initializer with a
|
||||
subgrouping for each command option.
|
||||
|
||||
Each subgrouping contains a string constant, that defines the
|
||||
option name, a number, which contains the bits to set in
|
||||
`target_flags', and a second string which is the description
|
||||
displayed by -help. If the number is negative then the bits
|
||||
specified by the number are cleared instead of being set. If the
|
||||
description string is present but empty, then no help information
|
||||
will be displayed for that option, but it will not count as an
|
||||
undocumented option. The actual option name is made by appending
|
||||
`-m' to the specified name.
|
||||
|
||||
One of the subgroupings should have a null string. The number in
|
||||
this grouping is the default value for `target_flags'. Any target
|
||||
options act starting with that value.
|
||||
|
||||
Here is an example which defines `-m68000' and `-m68020' with
|
||||
opposite meanings, and picks the latter as the default:
|
||||
|
||||
#define TARGET_SWITCHES \
|
||||
{ { "68020", 1, "" }, \
|
||||
{ "68000", -1, "Compile for the 68000" }, \
|
||||
{ "", 1, "" }}
|
||||
|
||||
`TARGET_OPTIONS'
|
||||
This macro is similar to `TARGET_SWITCHES' but defines names of
|
||||
command options that have values. Its definition is an
|
||||
initializer with a subgrouping for each command option.
|
||||
|
||||
Each subgrouping contains a string constant, that defines the
|
||||
fixed part of the option name, the address of a variable, and a
|
||||
description string. The variable, type `char *', is set to the
|
||||
variable part of the given option if the fixed part matches. The
|
||||
actual option name is made by appending `-m' to the specified name.
|
||||
|
||||
Here is an example which defines `-mshort-data-NUMBER'. If the
|
||||
given option is `-mshort-data-512', the variable `m88k_short_data'
|
||||
will be set to the string `"512"'.
|
||||
|
||||
extern char *m88k_short_data;
|
||||
#define TARGET_OPTIONS \
|
||||
{ { "short-data-", &m88k_short_data, "Specify the size of the short data section" } }
|
||||
|
||||
`TARGET_VERSION'
|
||||
This macro is a C statement to print on `stderr' a string
|
||||
describing the particular machine description choice. Every
|
||||
machine description should define `TARGET_VERSION'. For example:
|
||||
|
||||
#ifdef MOTOROLA
|
||||
#define TARGET_VERSION \
|
||||
fprintf (stderr, " (68k, Motorola syntax)");
|
||||
#else
|
||||
#define TARGET_VERSION \
|
||||
fprintf (stderr, " (68k, MIT syntax)");
|
||||
#endif
|
||||
|
||||
`OVERRIDE_OPTIONS'
|
||||
Sometimes certain combinations of command options do not make
|
||||
sense on a particular target machine. You can define a macro
|
||||
`OVERRIDE_OPTIONS' to take account of this. This macro, if
|
||||
defined, is executed once just after all the command options have
|
||||
been parsed.
|
||||
|
||||
Don't use this macro to turn on various extra optimizations for
|
||||
`-O'. That is what `OPTIMIZATION_OPTIONS' is for.
|
||||
|
||||
`OPTIMIZATION_OPTIONS (LEVEL, SIZE)'
|
||||
Some machines may desire to change what optimizations are
|
||||
performed for various optimization levels. This macro, if
|
||||
defined, is executed once just after the optimization level is
|
||||
determined and before the remainder of the command options have
|
||||
been parsed. Values set in this macro are used as the default
|
||||
values for the other command line options.
|
||||
|
||||
LEVEL is the optimization level specified; 2 if `-O2' is
|
||||
specified, 1 if `-O' is specified, and 0 if neither is specified.
|
||||
|
||||
SIZE is non-zero if `-Os' is specified and zero otherwise.
|
||||
|
||||
You should not use this macro to change options that are not
|
||||
machine-specific. These should uniformly selected by the same
|
||||
optimization level on all supported machines. Use this macro to
|
||||
enable machine-specific optimizations.
|
||||
|
||||
*Do not examine `write_symbols' in this macro!* The debugging
|
||||
options are not supposed to alter the generated code.
|
||||
|
||||
`CAN_DEBUG_WITHOUT_FP'
|
||||
Define this macro if debugging can be performed even without a
|
||||
frame pointer. If this macro is defined, GNU CC will turn on the
|
||||
`-fomit-frame-pointer' option whenever `-O' is specified.
|
||||
|
||||
Executable
+1002
File diff suppressed because it is too large
Load Diff
Executable
+989
@@ -0,0 +1,989 @@
|
||||
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
|
||||
input file ../../gcc-2.95.2/gcc/gcc.texi.
|
||||
|
||||
INFO-DIR-SECTION Programming
|
||||
START-INFO-DIR-ENTRY
|
||||
* gcc: (gcc). The GNU Compiler Collection.
|
||||
END-INFO-DIR-ENTRY
|
||||
This file documents the use and the internals of the GNU compiler.
|
||||
|
||||
Published by the Free Software Foundation 59 Temple Place - Suite 330
|
||||
Boston, MA 02111-1307 USA
|
||||
|
||||
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
|
||||
1999 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 "Funding
|
||||
for Free Software" 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 one.
|
||||
|
||||
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 "Funding for Free Software", 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: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros
|
||||
|
||||
Register Classes
|
||||
================
|
||||
|
||||
On many machines, the numbered registers are not all equivalent.
|
||||
For example, certain registers may not be allowed for indexed
|
||||
addressing; certain registers may not be allowed in some instructions.
|
||||
These machine restrictions are described to the compiler using
|
||||
"register classes".
|
||||
|
||||
You define a number of register classes, giving each one a name and
|
||||
saying which of the registers belong to it. Then you can specify
|
||||
register classes that are allowed as operands to particular instruction
|
||||
patterns.
|
||||
|
||||
In general, each register will belong to several classes. In fact,
|
||||
one class must be named `ALL_REGS' and contain all the registers.
|
||||
Another class must be named `NO_REGS' and contain no registers. Often
|
||||
the union of two classes will be another class; however, this is not
|
||||
required.
|
||||
|
||||
One of the classes must be named `GENERAL_REGS'. There is nothing
|
||||
terribly special about the name, but the operand constraint letters `r'
|
||||
and `g' specify this class. If `GENERAL_REGS' is the same as
|
||||
`ALL_REGS', just define it as a macro which expands to `ALL_REGS'.
|
||||
|
||||
Order the classes so that if class X is contained in class Y then X
|
||||
has a lower class number than Y.
|
||||
|
||||
The way classes other than `GENERAL_REGS' are specified in operand
|
||||
constraints is through machine-dependent operand constraint letters.
|
||||
You can define such letters to correspond to various classes, then use
|
||||
them in operand constraints.
|
||||
|
||||
You should define a class for the union of two classes whenever some
|
||||
instruction allows both classes. For example, if an instruction allows
|
||||
either a floating point (coprocessor) register or a general register
|
||||
for a certain operand, you should define a class `FLOAT_OR_GENERAL_REGS'
|
||||
which includes both of them. Otherwise you will get suboptimal code.
|
||||
|
||||
You must also specify certain redundant information about the
|
||||
register classes: for each class, which classes contain it and which
|
||||
ones are contained in it; for each pair of classes, the largest class
|
||||
contained in their union.
|
||||
|
||||
When a value occupying several consecutive registers is expected in a
|
||||
certain class, all the registers used must belong to that class.
|
||||
Therefore, register classes cannot be used to enforce a requirement for
|
||||
a register pair to start with an even-numbered register. The way to
|
||||
specify this requirement is with `HARD_REGNO_MODE_OK'.
|
||||
|
||||
Register classes used for input-operands of bitwise-and or shift
|
||||
instructions have a special requirement: each such class must have, for
|
||||
each fixed-point machine mode, a subclass whose registers can transfer
|
||||
that mode to or from memory. For example, on some machines, the
|
||||
operations for single-byte values (`QImode') are limited to certain
|
||||
registers. When this is so, each register class that is used in a
|
||||
bitwise-and or shift instruction must have a subclass consisting of
|
||||
registers from which single-byte values can be loaded or stored. This
|
||||
is so that `PREFERRED_RELOAD_CLASS' can always have a possible value to
|
||||
return.
|
||||
|
||||
`enum reg_class'
|
||||
An enumeral type that must be defined with all the register class
|
||||
names as enumeral values. `NO_REGS' must be first. `ALL_REGS'
|
||||
must be the last register class, followed by one more enumeral
|
||||
value, `LIM_REG_CLASSES', which is not a register class but rather
|
||||
tells how many classes there are.
|
||||
|
||||
Each register class has a number, which is the value of casting
|
||||
the class name to type `int'. The number serves as an index in
|
||||
many of the tables described below.
|
||||
|
||||
`N_REG_CLASSES'
|
||||
The number of distinct register classes, defined as follows:
|
||||
|
||||
#define N_REG_CLASSES (int) LIM_REG_CLASSES
|
||||
|
||||
`REG_CLASS_NAMES'
|
||||
An initializer containing the names of the register classes as C
|
||||
string constants. These names are used in writing some of the
|
||||
debugging dumps.
|
||||
|
||||
`REG_CLASS_CONTENTS'
|
||||
An initializer containing the contents of the register classes, as
|
||||
integers which are bit masks. The Nth integer specifies the
|
||||
contents of class N. The way the integer MASK is interpreted is
|
||||
that register R is in the class if `MASK & (1 << R)' is 1.
|
||||
|
||||
When the machine has more than 32 registers, an integer does not
|
||||
suffice. Then the integers are replaced by sub-initializers,
|
||||
braced groupings containing several integers. Each
|
||||
sub-initializer must be suitable as an initializer for the type
|
||||
`HARD_REG_SET' which is defined in `hard-reg-set.h'.
|
||||
|
||||
`REGNO_REG_CLASS (REGNO)'
|
||||
A C expression whose value is a register class containing hard
|
||||
register REGNO. In general there is more than one such class;
|
||||
choose a class which is "minimal", meaning that no smaller class
|
||||
also contains the register.
|
||||
|
||||
`BASE_REG_CLASS'
|
||||
A macro whose definition is the name of the class to which a valid
|
||||
base register must belong. A base register is one used in an
|
||||
address which is the register value plus a displacement.
|
||||
|
||||
`INDEX_REG_CLASS'
|
||||
A macro whose definition is the name of the class to which a valid
|
||||
index register must belong. An index register is one used in an
|
||||
address where its value is either multiplied by a scale factor or
|
||||
added to another register (as well as added to a displacement).
|
||||
|
||||
`REG_CLASS_FROM_LETTER (CHAR)'
|
||||
A C expression which defines the machine-dependent operand
|
||||
constraint letters for register classes. If CHAR is such a
|
||||
letter, the value should be the register class corresponding to
|
||||
it. Otherwise, the value should be `NO_REGS'. The register
|
||||
letter `r', corresponding to class `GENERAL_REGS', will not be
|
||||
passed to this macro; you do not need to handle it.
|
||||
|
||||
`REGNO_OK_FOR_BASE_P (NUM)'
|
||||
A C expression which is nonzero if register number NUM is suitable
|
||||
for use as a base register in operand addresses. It may be either
|
||||
a suitable hard register or a pseudo register that has been
|
||||
allocated such a hard register.
|
||||
|
||||
`REGNO_MODE_OK_FOR_BASE_P (NUM, MODE)'
|
||||
A C expression that is just like `REGNO_OK_FOR_BASE_P', except that
|
||||
that expression may examine the mode of the memory reference in
|
||||
MODE. You should define this macro if the mode of the memory
|
||||
reference affects whether a register may be used as a base
|
||||
register. If you define this macro, the compiler will use it
|
||||
instead of `REGNO_OK_FOR_BASE_P'.
|
||||
|
||||
`REGNO_OK_FOR_INDEX_P (NUM)'
|
||||
A C expression which is nonzero if register number NUM is suitable
|
||||
for use as an index register in operand addresses. It may be
|
||||
either a suitable hard register or a pseudo register that has been
|
||||
allocated such a hard register.
|
||||
|
||||
The difference between an index register and a base register is
|
||||
that the index register may be scaled. If an address involves the
|
||||
sum of two registers, neither one of them scaled, then either one
|
||||
may be labeled the "base" and the other the "index"; but whichever
|
||||
labeling is used must fit the machine's constraints of which
|
||||
registers may serve in each capacity. The compiler will try both
|
||||
labelings, looking for one that is valid, and will reload one or
|
||||
both registers only if neither labeling works.
|
||||
|
||||
`PREFERRED_RELOAD_CLASS (X, CLASS)'
|
||||
A C expression that places additional restrictions on the register
|
||||
class to use when it is necessary to copy value X into a register
|
||||
in class CLASS. The value is a register class; perhaps CLASS, or
|
||||
perhaps another, smaller class. On many machines, the following
|
||||
definition is safe:
|
||||
|
||||
#define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
|
||||
|
||||
Sometimes returning a more restrictive class makes better code.
|
||||
For example, on the 68000, when X is an integer constant that is
|
||||
in range for a `moveq' instruction, the value of this macro is
|
||||
always `DATA_REGS' as long as CLASS includes the data registers.
|
||||
Requiring a data register guarantees that a `moveq' will be used.
|
||||
|
||||
If X is a `const_double', by returning `NO_REGS' you can force X
|
||||
into a memory constant. This is useful on certain machines where
|
||||
immediate floating values cannot be loaded into certain kinds of
|
||||
registers.
|
||||
|
||||
`PREFERRED_OUTPUT_RELOAD_CLASS (X, CLASS)'
|
||||
Like `PREFERRED_RELOAD_CLASS', but for output reloads instead of
|
||||
input reloads. If you don't define this macro, the default is to
|
||||
use CLASS, unchanged.
|
||||
|
||||
`LIMIT_RELOAD_CLASS (MODE, CLASS)'
|
||||
A C expression that places additional restrictions on the register
|
||||
class to use when it is necessary to be able to hold a value of
|
||||
mode MODE in a reload register for which class CLASS would
|
||||
ordinarily be used.
|
||||
|
||||
Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when
|
||||
there are certain modes that simply can't go in certain reload
|
||||
classes.
|
||||
|
||||
The value is a register class; perhaps CLASS, or perhaps another,
|
||||
smaller class.
|
||||
|
||||
Don't define this macro unless the target machine has limitations
|
||||
which require the macro to do something nontrivial.
|
||||
|
||||
`SECONDARY_RELOAD_CLASS (CLASS, MODE, X)'
|
||||
`SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X)'
|
||||
`SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X)'
|
||||
Many machines have some registers that cannot be copied directly
|
||||
to or from memory or even from other types of registers. An
|
||||
example is the `MQ' register, which on most machines, can only be
|
||||
copied to or from general registers, but not memory. Some
|
||||
machines allow copying all registers to and from memory, but
|
||||
require a scratch register for stores to some memory locations
|
||||
(e.g., those with symbolic address on the RT, and those with
|
||||
certain symbolic address on the Sparc when compiling PIC). In
|
||||
some cases, both an intermediate and a scratch register are
|
||||
required.
|
||||
|
||||
You should define these macros to indicate to the reload phase
|
||||
that it may need to allocate at least one register for a reload in
|
||||
addition to the register to contain the data. Specifically, if
|
||||
copying X to a register CLASS in MODE requires an intermediate
|
||||
register, you should define `SECONDARY_INPUT_RELOAD_CLASS' to
|
||||
return the largest register class all of whose registers can be
|
||||
used as intermediate registers or scratch registers.
|
||||
|
||||
If copying a register CLASS in MODE to X requires an intermediate
|
||||
or scratch register, `SECONDARY_OUTPUT_RELOAD_CLASS' should be
|
||||
defined to return the largest register class required. If the
|
||||
requirements for input and output reloads are the same, the macro
|
||||
`SECONDARY_RELOAD_CLASS' should be used instead of defining both
|
||||
macros identically.
|
||||
|
||||
The values returned by these macros are often `GENERAL_REGS'.
|
||||
Return `NO_REGS' if no spare register is needed; i.e., if X can be
|
||||
directly copied to or from a register of CLASS in MODE without
|
||||
requiring a scratch register. Do not define this macro if it
|
||||
would always return `NO_REGS'.
|
||||
|
||||
If a scratch register is required (either with or without an
|
||||
intermediate register), you should define patterns for
|
||||
`reload_inM' or `reload_outM', as required (*note Standard
|
||||
Names::.. These patterns, which will normally be implemented with
|
||||
a `define_expand', should be similar to the `movM' patterns,
|
||||
except that operand 2 is the scratch register.
|
||||
|
||||
Define constraints for the reload register and scratch register
|
||||
that contain a single register class. If the original reload
|
||||
register (whose class is CLASS) can meet the constraint given in
|
||||
the pattern, the value returned by these macros is used for the
|
||||
class of the scratch register. Otherwise, two additional reload
|
||||
registers are required. Their classes are obtained from the
|
||||
constraints in the insn pattern.
|
||||
|
||||
X might be a pseudo-register or a `subreg' of a pseudo-register,
|
||||
which could either be in a hard register or in memory. Use
|
||||
`true_regnum' to find out; it will return -1 if the pseudo is in
|
||||
memory and the hard register number if it is in a register.
|
||||
|
||||
These macros should not be used in the case where a particular
|
||||
class of registers can only be copied to memory and not to another
|
||||
class of registers. In that case, secondary reload registers are
|
||||
not needed and would not be helpful. Instead, a stack location
|
||||
must be used to perform the copy and the `movM' pattern should use
|
||||
memory as a intermediate storage. This case often occurs between
|
||||
floating-point and general registers.
|
||||
|
||||
`SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M)'
|
||||
Certain machines have the property that some registers cannot be
|
||||
copied to some other registers without using memory. Define this
|
||||
macro on those machines to be a C expression that is non-zero if
|
||||
objects of mode M in registers of CLASS1 can only be copied to
|
||||
registers of class CLASS2 by storing a register of CLASS1 into
|
||||
memory and loading that memory location into a register of CLASS2.
|
||||
|
||||
Do not define this macro if its value would always be zero.
|
||||
|
||||
`SECONDARY_MEMORY_NEEDED_RTX (MODE)'
|
||||
Normally when `SECONDARY_MEMORY_NEEDED' is defined, the compiler
|
||||
allocates a stack slot for a memory location needed for register
|
||||
copies. If this macro is defined, the compiler instead uses the
|
||||
memory location defined by this macro.
|
||||
|
||||
Do not define this macro if you do not define
|
||||
`SECONDARY_MEMORY_NEEDED'.
|
||||
|
||||
`SECONDARY_MEMORY_NEEDED_MODE (MODE)'
|
||||
When the compiler needs a secondary memory location to copy
|
||||
between two registers of mode MODE, it normally allocates
|
||||
sufficient memory to hold a quantity of `BITS_PER_WORD' bits and
|
||||
performs the store and load operations in a mode that many bits
|
||||
wide and whose class is the same as that of MODE.
|
||||
|
||||
This is right thing to do on most machines because it ensures that
|
||||
all bits of the register are copied and prevents accesses to the
|
||||
registers in a narrower mode, which some machines prohibit for
|
||||
floating-point registers.
|
||||
|
||||
However, this default behavior is not correct on some machines,
|
||||
such as the DEC Alpha, that store short integers in floating-point
|
||||
registers differently than in integer registers. On those
|
||||
machines, the default widening will not work correctly and you
|
||||
must define this macro to suppress that widening in some cases.
|
||||
See the file `alpha.h' for details.
|
||||
|
||||
Do not define this macro if you do not define
|
||||
`SECONDARY_MEMORY_NEEDED' or if widening MODE to a mode that is
|
||||
`BITS_PER_WORD' bits wide is correct for your machine.
|
||||
|
||||
`SMALL_REGISTER_CLASSES'
|
||||
On some machines, it is risky to let hard registers live across
|
||||
arbitrary insns. Typically, these machines have instructions that
|
||||
require values to be in specific registers (like an accumulator),
|
||||
and reload will fail if the required hard register is used for
|
||||
another purpose across such an insn.
|
||||
|
||||
Define `SMALL_REGISTER_CLASSES' to be an expression with a non-zero
|
||||
value on these machines. When this macro has a non-zero value, the
|
||||
compiler will try to minimize the lifetime of hard registers.
|
||||
|
||||
It is always safe to define this macro with a non-zero value, but
|
||||
if you unnecessarily define it, you will reduce the amount of
|
||||
optimizations that can be performed in some cases. If you do not
|
||||
define this macro with a non-zero value when it is required, the
|
||||
compiler will run out of spill registers and print a fatal error
|
||||
message. For most machines, you should not define this macro at
|
||||
all.
|
||||
|
||||
`CLASS_LIKELY_SPILLED_P (CLASS)'
|
||||
A C expression whose value is nonzero if pseudos that have been
|
||||
assigned to registers of class CLASS would likely be spilled
|
||||
because registers of CLASS are needed for spill registers.
|
||||
|
||||
The default value of this macro returns 1 if CLASS has exactly one
|
||||
register and zero otherwise. On most machines, this default
|
||||
should be used. Only define this macro to some other expression
|
||||
if pseudos allocated by `local-alloc.c' end up in memory because
|
||||
their hard registers were needed for spill registers. If this
|
||||
macro returns nonzero for those classes, those pseudos will only
|
||||
be allocated by `global.c', which knows how to reallocate the
|
||||
pseudo to another register. If there would not be another
|
||||
register available for reallocation, you should not change the
|
||||
definition of this macro since the only effect of such a
|
||||
definition would be to slow down register allocation.
|
||||
|
||||
`CLASS_MAX_NREGS (CLASS, MODE)'
|
||||
A C expression for the maximum number of consecutive registers of
|
||||
class CLASS needed to hold a value of mode MODE.
|
||||
|
||||
This is closely related to the macro `HARD_REGNO_NREGS'. In fact,
|
||||
the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be
|
||||
the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all
|
||||
REGNO values in the class CLASS.
|
||||
|
||||
This macro helps control the handling of multiple-word values in
|
||||
the reload pass.
|
||||
|
||||
`CLASS_CANNOT_CHANGE_SIZE'
|
||||
If defined, a C expression for a class that contains registers
|
||||
which the compiler must always access in a mode that is the same
|
||||
size as the mode in which it loaded the register.
|
||||
|
||||
For the example, loading 32-bit integer or floating-point objects
|
||||
into floating-point registers on the Alpha extends them to 64-bits.
|
||||
Therefore loading a 64-bit object and then storing it as a 32-bit
|
||||
object does not store the low-order 32-bits, as would be the case
|
||||
for a normal register. Therefore, `alpha.h' defines this macro as
|
||||
`FLOAT_REGS'.
|
||||
|
||||
Three other special macros describe which operands fit which
|
||||
constraint letters.
|
||||
|
||||
`CONST_OK_FOR_LETTER_P (VALUE, C)'
|
||||
A C expression that defines the machine-dependent operand
|
||||
constraint letters (`I', `J', `K', ... `P') that specify
|
||||
particular ranges of integer values. If C is one of those
|
||||
letters, the expression should check that VALUE, an integer, is in
|
||||
the appropriate range and return 1 if so, 0 otherwise. If C is
|
||||
not one of those letters, the value should be 0 regardless of
|
||||
VALUE.
|
||||
|
||||
`CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)'
|
||||
A C expression that defines the machine-dependent operand
|
||||
constraint letters that specify particular ranges of
|
||||
`const_double' values (`G' or `H').
|
||||
|
||||
If C is one of those letters, the expression should check that
|
||||
VALUE, an RTX of code `const_double', is in the appropriate range
|
||||
and return 1 if so, 0 otherwise. If C is not one of those
|
||||
letters, the value should be 0 regardless of VALUE.
|
||||
|
||||
`const_double' is used for all floating-point constants and for
|
||||
`DImode' fixed-point constants. A given letter can accept either
|
||||
or both kinds of values. It can use `GET_MODE' to distinguish
|
||||
between these kinds.
|
||||
|
||||
`EXTRA_CONSTRAINT (VALUE, C)'
|
||||
A C expression that defines the optional machine-dependent
|
||||
constraint letters (`Q', `R', `S', `T', `U') that can be used to
|
||||
segregate specific types of operands, usually memory references,
|
||||
for the target machine. Normally this macro will not be defined.
|
||||
If it is required for a particular target machine, it should
|
||||
return 1 if VALUE corresponds to the operand type represented by
|
||||
the constraint letter C. If C is not defined as an extra
|
||||
constraint, the value returned should be 0 regardless of VALUE.
|
||||
|
||||
For example, on the ROMP, load instructions cannot have their
|
||||
output in r0 if the memory reference contains a symbolic address.
|
||||
Constraint letter `Q' is defined as representing a memory address
|
||||
that does *not* contain a symbolic address. An alternative is
|
||||
specified with a `Q' constraint on the input and `r' on the
|
||||
output. The next alternative specifies `m' on the input and a
|
||||
register class that does not include r0 on the output.
|
||||
|
||||
|
||||
File: gcc.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros
|
||||
|
||||
Stack Layout and Calling Conventions
|
||||
====================================
|
||||
|
||||
This describes the stack layout and calling conventions.
|
||||
|
||||
* Menu:
|
||||
|
||||
* Frame Layout::
|
||||
* Stack Checking::
|
||||
* Frame Registers::
|
||||
* Elimination::
|
||||
* Stack Arguments::
|
||||
* Register Arguments::
|
||||
* Scalar Return::
|
||||
* Aggregate Return::
|
||||
* Caller Saves::
|
||||
* Function Entry::
|
||||
* Profiling::
|
||||
|
||||
|
||||
File: gcc.info, Node: Frame Layout, Next: Stack Checking, Up: Stack and Calling
|
||||
|
||||
Basic Stack Layout
|
||||
------------------
|
||||
|
||||
Here is the basic stack layout.
|
||||
|
||||
`STACK_GROWS_DOWNWARD'
|
||||
Define this macro if pushing a word onto the stack moves the stack
|
||||
pointer to a smaller address.
|
||||
|
||||
When we say, "define this macro if ...," it means that the
|
||||
compiler checks this macro only with `#ifdef' so the precise
|
||||
definition used does not matter.
|
||||
|
||||
`FRAME_GROWS_DOWNWARD'
|
||||
Define this macro if the addresses of local variable slots are at
|
||||
negative offsets from the frame pointer.
|
||||
|
||||
`ARGS_GROW_DOWNWARD'
|
||||
Define this macro if successive arguments to a function occupy
|
||||
decreasing addresses on the stack.
|
||||
|
||||
`STARTING_FRAME_OFFSET'
|
||||
Offset from the frame pointer to the first local variable slot to
|
||||
be allocated.
|
||||
|
||||
If `FRAME_GROWS_DOWNWARD', find the next slot's offset by
|
||||
subtracting the first slot's length from `STARTING_FRAME_OFFSET'.
|
||||
Otherwise, it is found by adding the length of the first slot to
|
||||
the value `STARTING_FRAME_OFFSET'.
|
||||
|
||||
`STACK_POINTER_OFFSET'
|
||||
Offset from the stack pointer register to the first location at
|
||||
which outgoing arguments are placed. If not specified, the
|
||||
default value of zero is used. This is the proper value for most
|
||||
machines.
|
||||
|
||||
If `ARGS_GROW_DOWNWARD', this is the offset to the location above
|
||||
the first location at which outgoing arguments are placed.
|
||||
|
||||
`FIRST_PARM_OFFSET (FUNDECL)'
|
||||
Offset from the argument pointer register to the first argument's
|
||||
address. On some machines it may depend on the data type of the
|
||||
function.
|
||||
|
||||
If `ARGS_GROW_DOWNWARD', this is the offset to the location above
|
||||
the first argument's address.
|
||||
|
||||
`STACK_DYNAMIC_OFFSET (FUNDECL)'
|
||||
Offset from the stack pointer register to an item dynamically
|
||||
allocated on the stack, e.g., by `alloca'.
|
||||
|
||||
The default value for this macro is `STACK_POINTER_OFFSET' plus the
|
||||
length of the outgoing arguments. The default is correct for most
|
||||
machines. See `function.c' for details.
|
||||
|
||||
`DYNAMIC_CHAIN_ADDRESS (FRAMEADDR)'
|
||||
A C expression whose value is RTL representing the address in a
|
||||
stack frame where the pointer to the caller's frame is stored.
|
||||
Assume that FRAMEADDR is an RTL expression for the address of the
|
||||
stack frame itself.
|
||||
|
||||
If you don't define this macro, the default is to return the value
|
||||
of FRAMEADDR--that is, the stack frame address is also the address
|
||||
of the stack word that points to the previous frame.
|
||||
|
||||
`SETUP_FRAME_ADDRESSES'
|
||||
If defined, a C expression that produces the machine-specific code
|
||||
to setup the stack so that arbitrary frames can be accessed. For
|
||||
example, on the Sparc, we must flush all of the register windows
|
||||
to the stack before we can access arbitrary stack frames. You
|
||||
will seldom need to define this macro.
|
||||
|
||||
`BUILTIN_SETJMP_FRAME_VALUE'
|
||||
If defined, a C expression that contains an rtx that is used to
|
||||
store the address of the current frame into the built in `setjmp'
|
||||
buffer. The default value, `virtual_stack_vars_rtx', is correct
|
||||
for most machines. One reason you may need to define this macro
|
||||
is if `hard_frame_pointer_rtx' is the appropriate value on your
|
||||
machine.
|
||||
|
||||
`RETURN_ADDR_RTX (COUNT, FRAMEADDR)'
|
||||
A C expression whose value is RTL representing the value of the
|
||||
return address for the frame COUNT steps up from the current
|
||||
frame, after the prologue. FRAMEADDR is the frame pointer of the
|
||||
COUNT frame, or the frame pointer of the COUNT - 1 frame if
|
||||
`RETURN_ADDR_IN_PREVIOUS_FRAME' is defined.
|
||||
|
||||
The value of the expression must always be the correct address when
|
||||
COUNT is zero, but may be `NULL_RTX' if there is not way to
|
||||
determine the return address of other frames.
|
||||
|
||||
`RETURN_ADDR_IN_PREVIOUS_FRAME'
|
||||
Define this if the return address of a particular stack frame is
|
||||
accessed from the frame pointer of the previous stack frame.
|
||||
|
||||
`INCOMING_RETURN_ADDR_RTX'
|
||||
A C expression whose value is RTL representing the location of the
|
||||
incoming return address at the beginning of any function, before
|
||||
the prologue. This RTL is either a `REG', indicating that the
|
||||
return value is saved in `REG', or a `MEM' representing a location
|
||||
in the stack.
|
||||
|
||||
You only need to define this macro if you want to support call
|
||||
frame debugging information like that provided by DWARF 2.
|
||||
|
||||
`INCOMING_FRAME_SP_OFFSET'
|
||||
A C expression whose value is an integer giving the offset, in
|
||||
bytes, from the value of the stack pointer register to the top of
|
||||
the stack frame at the beginning of any function, before the
|
||||
prologue. The top of the frame is defined to be the value of the
|
||||
stack pointer in the previous frame, just before the call
|
||||
instruction.
|
||||
|
||||
You only need to define this macro if you want to support call
|
||||
frame debugging information like that provided by DWARF 2.
|
||||
|
||||
`ARG_POINTER_CFA_OFFSET'
|
||||
A C expression whose value is an integer giving the offset, in
|
||||
bytes, from the argument pointer to the canonical frame address
|
||||
(cfa). The final value should coincide with that calculated by
|
||||
`INCOMING_FRAME_SP_OFFSET'. Which is unfortunately not usable
|
||||
during virtual register instantiation.
|
||||
|
||||
You only need to define this macro if you want to support call
|
||||
frame debugging information like that provided by DWARF 2.
|
||||
|
||||
|
||||
File: gcc.info, Node: Stack Checking, Next: Frame Registers, Prev: Frame Layout, Up: Stack and Calling
|
||||
|
||||
Specifying How Stack Checking is Done
|
||||
-------------------------------------
|
||||
|
||||
GNU CC will check that stack references are within the boundaries of
|
||||
the stack, if the `-fstack-check' is specified, in one of three ways:
|
||||
|
||||
1. If the value of the `STACK_CHECK_BUILTIN' macro is nonzero, GNU CC
|
||||
will assume that you have arranged for stack checking to be done at
|
||||
appropriate places in the configuration files, e.g., in
|
||||
`FUNCTION_PROLOGUE'. GNU CC will do not other special processing.
|
||||
|
||||
2. If `STACK_CHECK_BUILTIN' is zero and you defined a named pattern
|
||||
called `check_stack' in your `md' file, GNU CC will call that
|
||||
pattern with one argument which is the address to compare the stack
|
||||
value against. You must arrange for this pattern to report an
|
||||
error if the stack pointer is out of range.
|
||||
|
||||
3. If neither of the above are true, GNU CC will generate code to
|
||||
periodically "probe" the stack pointer using the values of the
|
||||
macros defined below.
|
||||
|
||||
Normally, you will use the default values of these macros, so GNU CC
|
||||
will use the third approach.
|
||||
|
||||
`STACK_CHECK_BUILTIN'
|
||||
A nonzero value if stack checking is done by the configuration
|
||||
files in a machine-dependent manner. You should define this macro
|
||||
if stack checking is require by the ABI of your machine or if you
|
||||
would like to have to stack checking in some more efficient way
|
||||
than GNU CC's portable approach. The default value of this macro
|
||||
is zero.
|
||||
|
||||
`STACK_CHECK_PROBE_INTERVAL'
|
||||
An integer representing the interval at which GNU CC must generate
|
||||
stack probe instructions. You will normally define this macro to
|
||||
be no larger than the size of the "guard pages" at the end of a
|
||||
stack area. The default value of 4096 is suitable for most
|
||||
systems.
|
||||
|
||||
`STACK_CHECK_PROBE_LOAD'
|
||||
A integer which is nonzero if GNU CC should perform the stack probe
|
||||
as a load instruction and zero if GNU CC should use a store
|
||||
instruction. The default is zero, which is the most efficient
|
||||
choice on most systems.
|
||||
|
||||
`STACK_CHECK_PROTECT'
|
||||
The number of bytes of stack needed to recover from a stack
|
||||
overflow, for languages where such a recovery is supported. The
|
||||
default value of 75 words should be adequate for most machines.
|
||||
|
||||
`STACK_CHECK_MAX_FRAME_SIZE'
|
||||
The maximum size of a stack frame, in bytes. GNU CC will generate
|
||||
probe instructions in non-leaf functions to ensure at least this
|
||||
many bytes of stack are available. If a stack frame is larger
|
||||
than this size, stack checking will not be reliable and GNU CC
|
||||
will issue a warning. The default is chosen so that GNU CC only
|
||||
generates one instruction on most systems. You should normally
|
||||
not change the default value of this macro.
|
||||
|
||||
`STACK_CHECK_FIXED_FRAME_SIZE'
|
||||
GNU CC uses this value to generate the above warning message. It
|
||||
represents the amount of fixed frame used by a function, not
|
||||
including space for any callee-saved registers, temporaries and
|
||||
user variables. You need only specify an upper bound for this
|
||||
amount and will normally use the default of four words.
|
||||
|
||||
`STACK_CHECK_MAX_VAR_SIZE'
|
||||
The maximum size, in bytes, of an object that GNU CC will place in
|
||||
the fixed area of the stack frame when the user specifies
|
||||
`-fstack-check'. GNU CC computed the default from the values of
|
||||
the above macros and you will normally not need to override that
|
||||
default.
|
||||
|
||||
|
||||
File: gcc.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling
|
||||
|
||||
Registers That Address the Stack Frame
|
||||
--------------------------------------
|
||||
|
||||
This discusses registers that address the stack frame.
|
||||
|
||||
`STACK_POINTER_REGNUM'
|
||||
The register number of the stack pointer register, which must also
|
||||
be a fixed register according to `FIXED_REGISTERS'. On most
|
||||
machines, the hardware determines which register this is.
|
||||
|
||||
`FRAME_POINTER_REGNUM'
|
||||
The register number of the frame pointer register, which is used to
|
||||
access automatic variables in the stack frame. On some machines,
|
||||
the hardware determines which register this is. On other
|
||||
machines, you can choose any register you wish for this purpose.
|
||||
|
||||
`HARD_FRAME_POINTER_REGNUM'
|
||||
On some machines the offset between the frame pointer and starting
|
||||
offset of the automatic variables is not known until after register
|
||||
allocation has been done (for example, because the saved registers
|
||||
are between these two locations). On those machines, define
|
||||
`FRAME_POINTER_REGNUM' the number of a special, fixed register to
|
||||
be used internally until the offset is known, and define
|
||||
`HARD_FRAME_POINTER_REGNUM' to be the actual hard register number
|
||||
used for the frame pointer.
|
||||
|
||||
You should define this macro only in the very rare circumstances
|
||||
when it is not possible to calculate the offset between the frame
|
||||
pointer and the automatic variables until after register
|
||||
allocation has been completed. When this macro is defined, you
|
||||
must also indicate in your definition of `ELIMINABLE_REGS' how to
|
||||
eliminate `FRAME_POINTER_REGNUM' into either
|
||||
`HARD_FRAME_POINTER_REGNUM' or `STACK_POINTER_REGNUM'.
|
||||
|
||||
Do not define this macro if it would be the same as
|
||||
`FRAME_POINTER_REGNUM'.
|
||||
|
||||
`ARG_POINTER_REGNUM'
|
||||
The register number of the arg pointer register, which is used to
|
||||
access the function's argument list. On some machines, this is
|
||||
the same as the frame pointer register. On some machines, the
|
||||
hardware determines which register this is. On other machines,
|
||||
you can choose any register you wish for this purpose. If this is
|
||||
not the same register as the frame pointer register, then you must
|
||||
mark it as a fixed register according to `FIXED_REGISTERS', or
|
||||
arrange to be able to eliminate it (*note Elimination::.).
|
||||
|
||||
`RETURN_ADDRESS_POINTER_REGNUM'
|
||||
The register number of the return address pointer register, which
|
||||
is used to access the current function's return address from the
|
||||
stack. On some machines, the return address is not at a fixed
|
||||
offset from the frame pointer or stack pointer or argument
|
||||
pointer. This register can be defined to point to the return
|
||||
address on the stack, and then be converted by `ELIMINABLE_REGS'
|
||||
into either the frame pointer or stack pointer.
|
||||
|
||||
Do not define this macro unless there is no other way to get the
|
||||
return address from the stack.
|
||||
|
||||
`STATIC_CHAIN_REGNUM'
|
||||
`STATIC_CHAIN_INCOMING_REGNUM'
|
||||
Register numbers used for passing a function's static chain
|
||||
pointer. If register windows are used, the register number as
|
||||
seen by the called function is `STATIC_CHAIN_INCOMING_REGNUM',
|
||||
while the register number as seen by the calling function is
|
||||
`STATIC_CHAIN_REGNUM'. If these registers are the same,
|
||||
`STATIC_CHAIN_INCOMING_REGNUM' need not be defined.
|
||||
|
||||
The static chain register need not be a fixed register.
|
||||
|
||||
If the static chain is passed in memory, these macros should not be
|
||||
defined; instead, the next two macros should be defined.
|
||||
|
||||
`STATIC_CHAIN'
|
||||
`STATIC_CHAIN_INCOMING'
|
||||
If the static chain is passed in memory, these macros provide rtx
|
||||
giving `mem' expressions that denote where they are stored.
|
||||
`STATIC_CHAIN' and `STATIC_CHAIN_INCOMING' give the locations as
|
||||
seen by the calling and called functions, respectively. Often the
|
||||
former will be at an offset from the stack pointer and the latter
|
||||
at an offset from the frame pointer.
|
||||
|
||||
The variables `stack_pointer_rtx', `frame_pointer_rtx', and
|
||||
`arg_pointer_rtx' will have been initialized prior to the use of
|
||||
these macros and should be used to refer to those items.
|
||||
|
||||
If the static chain is passed in a register, the two previous
|
||||
macros should be defined instead.
|
||||
|
||||
|
||||
File: gcc.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling
|
||||
|
||||
Eliminating Frame Pointer and Arg Pointer
|
||||
-----------------------------------------
|
||||
|
||||
This is about eliminating the frame pointer and arg pointer.
|
||||
|
||||
`FRAME_POINTER_REQUIRED'
|
||||
A C expression which is nonzero if a function must have and use a
|
||||
frame pointer. This expression is evaluated in the reload pass.
|
||||
If its value is nonzero the function will have a frame pointer.
|
||||
|
||||
The expression can in principle examine the current function and
|
||||
decide according to the facts, but on most machines the constant 0
|
||||
or the constant 1 suffices. Use 0 when the machine allows code to
|
||||
be generated with no frame pointer, and doing so saves some time
|
||||
or space. Use 1 when there is no possible advantage to avoiding a
|
||||
frame pointer.
|
||||
|
||||
In certain cases, the compiler does not know how to produce valid
|
||||
code without a frame pointer. The compiler recognizes those cases
|
||||
and automatically gives the function a frame pointer regardless of
|
||||
what `FRAME_POINTER_REQUIRED' says. You don't need to worry about
|
||||
them.
|
||||
|
||||
In a function that does not require a frame pointer, the frame
|
||||
pointer register can be allocated for ordinary usage, unless you
|
||||
mark it as a fixed register. See `FIXED_REGISTERS' for more
|
||||
information.
|
||||
|
||||
`INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR)'
|
||||
A C statement to store in the variable DEPTH-VAR the difference
|
||||
between the frame pointer and the stack pointer values immediately
|
||||
after the function prologue. The value would be computed from
|
||||
information such as the result of `get_frame_size ()' and the
|
||||
tables of registers `regs_ever_live' and `call_used_regs'.
|
||||
|
||||
If `ELIMINABLE_REGS' is defined, this macro will be not be used and
|
||||
need not be defined. Otherwise, it must be defined even if
|
||||
`FRAME_POINTER_REQUIRED' is defined to always be true; in that
|
||||
case, you may set DEPTH-VAR to anything.
|
||||
|
||||
`ELIMINABLE_REGS'
|
||||
If defined, this macro specifies a table of register pairs used to
|
||||
eliminate unneeded registers that point into the stack frame. If
|
||||
it is not defined, the only elimination attempted by the compiler
|
||||
is to replace references to the frame pointer with references to
|
||||
the stack pointer.
|
||||
|
||||
The definition of this macro is a list of structure
|
||||
initializations, each of which specifies an original and
|
||||
replacement register.
|
||||
|
||||
On some machines, the position of the argument pointer is not
|
||||
known until the compilation is completed. In such a case, a
|
||||
separate hard register must be used for the argument pointer.
|
||||
This register can be eliminated by replacing it with either the
|
||||
frame pointer or the argument pointer, depending on whether or not
|
||||
the frame pointer has been eliminated.
|
||||
|
||||
In this case, you might specify:
|
||||
#define ELIMINABLE_REGS \
|
||||
{{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
|
||||
{ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \
|
||||
{FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}}
|
||||
|
||||
Note that the elimination of the argument pointer with the stack
|
||||
pointer is specified first since that is the preferred elimination.
|
||||
|
||||
`CAN_ELIMINATE (FROM-REG, TO-REG)'
|
||||
A C expression that returns non-zero if the compiler is allowed to
|
||||
try to replace register number FROM-REG with register number
|
||||
TO-REG. This macro need only be defined if `ELIMINABLE_REGS' is
|
||||
defined, and will usually be the constant 1, since most of the
|
||||
cases preventing register elimination are things that the compiler
|
||||
already knows about.
|
||||
|
||||
`INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)'
|
||||
This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It
|
||||
specifies the initial difference between the specified pair of
|
||||
registers. This macro must be defined if `ELIMINABLE_REGS' is
|
||||
defined.
|
||||
|
||||
`LONGJMP_RESTORE_FROM_STACK'
|
||||
Define this macro if the `longjmp' function restores registers from
|
||||
the stack frames, rather than from those saved specifically by
|
||||
`setjmp'. Certain quantities must not be kept in registers across
|
||||
a call to `setjmp' on such machines.
|
||||
|
||||
|
||||
File: gcc.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling
|
||||
|
||||
Passing Function Arguments on the Stack
|
||||
---------------------------------------
|
||||
|
||||
The macros in this section control how arguments are passed on the
|
||||
stack. See the following section for other macros that control passing
|
||||
certain arguments in registers.
|
||||
|
||||
`PROMOTE_PROTOTYPES'
|
||||
Define this macro if an argument declared in a prototype as an
|
||||
integral type smaller than `int' should actually be passed as an
|
||||
`int'. In addition to avoiding errors in certain cases of
|
||||
mismatch, it also makes for better code on certain machines.
|
||||
|
||||
`PUSH_ROUNDING (NPUSHED)'
|
||||
A C expression that is the number of bytes actually pushed onto the
|
||||
stack when an instruction attempts to push NPUSHED bytes.
|
||||
|
||||
If the target machine does not have a push instruction, do not
|
||||
define this macro. That directs GNU CC to use an alternate
|
||||
strategy: to allocate the entire argument block and then store the
|
||||
arguments into it.
|
||||
|
||||
On some machines, the definition
|
||||
|
||||
#define PUSH_ROUNDING(BYTES) (BYTES)
|
||||
|
||||
will suffice. But on other machines, instructions that appear to
|
||||
push one byte actually push two bytes in an attempt to maintain
|
||||
alignment. Then the definition should be
|
||||
|
||||
#define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
|
||||
|
||||
`ACCUMULATE_OUTGOING_ARGS'
|
||||
If defined, the maximum amount of space required for outgoing
|
||||
arguments will be computed and placed into the variable
|
||||
`current_function_outgoing_args_size'. No space will be pushed
|
||||
onto the stack for each call; instead, the function prologue should
|
||||
increase the stack frame size by this amount.
|
||||
|
||||
Defining both `PUSH_ROUNDING' and `ACCUMULATE_OUTGOING_ARGS' is
|
||||
not proper.
|
||||
|
||||
`REG_PARM_STACK_SPACE (FNDECL)'
|
||||
Define this macro if functions should assume that stack space has
|
||||
been allocated for arguments even when their values are passed in
|
||||
registers.
|
||||
|
||||
The value of this macro is the size, in bytes, of the area
|
||||
reserved for arguments passed in registers for the function
|
||||
represented by FNDECL, which can be zero if GNU CC is calling a
|
||||
library function.
|
||||
|
||||
This space can be allocated by the caller, or be a part of the
|
||||
machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' says
|
||||
which.
|
||||
|
||||
`MAYBE_REG_PARM_STACK_SPACE'
|
||||
`FINAL_REG_PARM_STACK_SPACE (CONST_SIZE, VAR_SIZE)'
|
||||
Define these macros in addition to the one above if functions might
|
||||
allocate stack space for arguments even when their values are
|
||||
passed in registers. These should be used when the stack space
|
||||
allocated for arguments in registers is not a simple constant
|
||||
independent of the function declaration.
|
||||
|
||||
The value of the first macro is the size, in bytes, of the area
|
||||
that we should initially assume would be reserved for arguments
|
||||
passed in registers.
|
||||
|
||||
The value of the second macro is the actual size, in bytes, of the
|
||||
area that will be reserved for arguments passed in registers.
|
||||
This takes two arguments: an integer representing the number of
|
||||
bytes of fixed sized arguments on the stack, and a tree
|
||||
representing the number of bytes of variable sized arguments on
|
||||
the stack.
|
||||
|
||||
When these macros are defined, `REG_PARM_STACK_SPACE' will only be
|
||||
called for libcall functions, the current function, or for a
|
||||
function being called when it is known that such stack space must
|
||||
be allocated. In each case this value can be easily computed.
|
||||
|
||||
When deciding whether a called function needs such stack space,
|
||||
and how much space to reserve, GNU CC uses these two macros
|
||||
instead of `REG_PARM_STACK_SPACE'.
|
||||
|
||||
`OUTGOING_REG_PARM_STACK_SPACE'
|
||||
Define this if it is the responsibility of the caller to allocate
|
||||
the area reserved for arguments passed in registers.
|
||||
|
||||
If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls
|
||||
whether the space for these arguments counts in the value of
|
||||
`current_function_outgoing_args_size'.
|
||||
|
||||
`STACK_PARMS_IN_REG_PARM_AREA'
|
||||
Define this macro if `REG_PARM_STACK_SPACE' is defined, but the
|
||||
stack parameters don't skip the area specified by it.
|
||||
|
||||
Normally, when a parameter is not passed in registers, it is
|
||||
placed on the stack beyond the `REG_PARM_STACK_SPACE' area.
|
||||
Defining this macro suppresses this behavior and causes the
|
||||
parameter to be passed on the stack in its natural location.
|
||||
|
||||
`RETURN_POPS_ARGS (FUNDECL, FUNTYPE, STACK-SIZE)'
|
||||
A C expression that should indicate the number of bytes of its own
|
||||
arguments that a function pops on returning, or 0 if the function
|
||||
pops no arguments and the caller must therefore pop them all after
|
||||
the function returns.
|
||||
|
||||
FUNDECL is a C variable whose value is a tree node that describes
|
||||
the function in question. Normally it is a node of type
|
||||
`FUNCTION_DECL' that describes the declaration of the function.
|
||||
From this you can obtain the DECL_MACHINE_ATTRIBUTES of the
|
||||
function.
|
||||
|
||||
FUNTYPE is a C variable whose value is a tree node that describes
|
||||
the function in question. Normally it is a node of type
|
||||
`FUNCTION_TYPE' that describes the data type of the function.
|
||||
From this it is possible to obtain the data types of the value and
|
||||
arguments (if known).
|
||||
|
||||
When a call to a library function is being considered, FUNDECL
|
||||
will contain an identifier node for the library function. Thus, if
|
||||
you need to distinguish among various library functions, you can
|
||||
do so by their names. Note that "library function" in this
|
||||
context means a function used to perform arithmetic, whose name is
|
||||
known specially in the compiler and was not mentioned in the C
|
||||
code being compiled.
|
||||
|
||||
STACK-SIZE is the number of bytes of arguments passed on the
|
||||
stack. If a variable number of bytes is passed, it is zero, and
|
||||
argument popping will always be the responsibility of the calling
|
||||
function.
|
||||
|
||||
On the Vax, all functions always pop their arguments, so the
|
||||
definition of this macro is STACK-SIZE. On the 68000, using the
|
||||
standard calling convention, no functions pop their arguments, so
|
||||
the value of the macro is always 0 in this case. But an
|
||||
alternative calling convention is available in which functions
|
||||
that take a fixed number of arguments pop them but other functions
|
||||
(such as `printf') pop nothing (the caller pops all). When this
|
||||
convention is in use, FUNTYPE is examined to determine whether a
|
||||
function takes a fixed number of arguments.
|
||||
|
||||
Executable
+982
@@ -0,0 +1,982 @@
|
||||
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
|
||||
input file ../../gcc-2.95.2/gcc/gcc.texi.
|
||||
|
||||
INFO-DIR-SECTION Programming
|
||||
START-INFO-DIR-ENTRY
|
||||
* gcc: (gcc). The GNU Compiler Collection.
|
||||
END-INFO-DIR-ENTRY
|
||||
This file documents the use and the internals of the GNU compiler.
|
||||
|
||||
Published by the Free Software Foundation 59 Temple Place - Suite 330
|
||||
Boston, MA 02111-1307 USA
|
||||
|
||||
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
|
||||
1999 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 "Funding
|
||||
for Free Software" 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 one.
|
||||
|
||||
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 "Funding for Free Software", 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: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling
|
||||
|
||||
Passing Arguments in Registers
|
||||
------------------------------
|
||||
|
||||
This section describes the macros which let you control how various
|
||||
types of arguments are passed in registers or how they are arranged in
|
||||
the stack.
|
||||
|
||||
`FUNCTION_ARG (CUM, MODE, TYPE, NAMED)'
|
||||
A C expression that controls whether a function argument is passed
|
||||
in a register, and which register.
|
||||
|
||||
The arguments are CUM, which summarizes all the previous
|
||||
arguments; MODE, the machine mode of the argument; TYPE, the data
|
||||
type of the argument as a tree node or 0 if that is not known
|
||||
(which happens for C support library functions); and NAMED, which
|
||||
is 1 for an ordinary argument and 0 for nameless arguments that
|
||||
correspond to `...' in the called function's prototype.
|
||||
|
||||
The value of the expression is usually either a `reg' RTX for the
|
||||
hard register in which to pass the argument, or zero to pass the
|
||||
argument on the stack.
|
||||
|
||||
For machines like the Vax and 68000, where normally all arguments
|
||||
are pushed, zero suffices as a definition.
|
||||
|
||||
The value of the expression can also be a `parallel' RTX. This is
|
||||
used when an argument is passed in multiple locations. The mode
|
||||
of the of the `parallel' should be the mode of the entire
|
||||
argument. The `parallel' holds any number of `expr_list' pairs;
|
||||
each one describes where part of the argument is passed. In each
|
||||
`expr_list' the first operand must be a `reg' RTX for the hard
|
||||
register in which to pass this part of the argument, and the mode
|
||||
of the register RTX indicates how large this part of the argument
|
||||
is. The second operand of the `expr_list' is a `const_int' which
|
||||
gives the offset in bytes into the entire argument of where this
|
||||
part starts. As a special exception the first `expr_list' in the
|
||||
`parallel' RTX may have a first operand of zero. This indicates
|
||||
that the bytes starting from the second operand of that
|
||||
`expr_list' are stored on the stack and not held in a register.
|
||||
|
||||
The usual way to make the ANSI library `stdarg.h' work on a machine
|
||||
where some arguments are usually passed in registers, is to cause
|
||||
nameless arguments to be passed on the stack instead. This is done
|
||||
by making `FUNCTION_ARG' return 0 whenever NAMED is 0.
|
||||
|
||||
You may use the macro `MUST_PASS_IN_STACK (MODE, TYPE)' in the
|
||||
definition of this macro to determine if this argument is of a
|
||||
type that must be passed in the stack. If `REG_PARM_STACK_SPACE'
|
||||
is not defined and `FUNCTION_ARG' returns non-zero for such an
|
||||
argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is
|
||||
defined, the argument will be computed in the stack and then
|
||||
loaded into a register.
|
||||
|
||||
`MUST_PASS_IN_STACK (MODE, TYPE)'
|
||||
Define as a C expression that evaluates to nonzero if we do not
|
||||
know how to pass TYPE solely in registers. The file `expr.h'
|
||||
defines a definition that is usually appropriate, refer to
|
||||
`expr.h' for additional documentation.
|
||||
|
||||
`FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)'
|
||||
Define this macro if the target machine has "register windows", so
|
||||
that the register in which a function sees an arguments is not
|
||||
necessarily the same as the one in which the caller passed the
|
||||
argument.
|
||||
|
||||
For such machines, `FUNCTION_ARG' computes the register in which
|
||||
the caller passes the value, and `FUNCTION_INCOMING_ARG' should be
|
||||
defined in a similar fashion to tell the function being called
|
||||
where the arguments will arrive.
|
||||
|
||||
If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves
|
||||
both purposes.
|
||||
|
||||
`FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)'
|
||||
A C expression for the number of words, at the beginning of an
|
||||
argument, must be put in registers. The value must be zero for
|
||||
arguments that are passed entirely in registers or that are
|
||||
entirely pushed on the stack.
|
||||
|
||||
On some machines, certain arguments must be passed partially in
|
||||
registers and partially in memory. On these machines, typically
|
||||
the first N words of arguments are passed in registers, and the
|
||||
rest on the stack. If a multi-word argument (a `double' or a
|
||||
structure) crosses that boundary, its first few words must be
|
||||
passed in registers and the rest must be pushed. This macro tells
|
||||
the compiler when this occurs, and how many of the words should go
|
||||
in registers.
|
||||
|
||||
`FUNCTION_ARG' for these arguments should return the first
|
||||
register to be used by the caller for this argument; likewise
|
||||
`FUNCTION_INCOMING_ARG', for the called function.
|
||||
|
||||
`FUNCTION_ARG_PASS_BY_REFERENCE (CUM, MODE, TYPE, NAMED)'
|
||||
A C expression that indicates when an argument must be passed by
|
||||
reference. If nonzero for an argument, a copy of that argument is
|
||||
made in memory and a pointer to the argument is passed instead of
|
||||
the argument itself. The pointer is passed in whatever way is
|
||||
appropriate for passing a pointer to that type.
|
||||
|
||||
On machines where `REG_PARM_STACK_SPACE' is not defined, a suitable
|
||||
definition of this macro might be
|
||||
#define FUNCTION_ARG_PASS_BY_REFERENCE\
|
||||
(CUM, MODE, TYPE, NAMED) \
|
||||
MUST_PASS_IN_STACK (MODE, TYPE)
|
||||
|
||||
`FUNCTION_ARG_CALLEE_COPIES (CUM, MODE, TYPE, NAMED)'
|
||||
If defined, a C expression that indicates when it is the called
|
||||
function's responsibility to make a copy of arguments passed by
|
||||
invisible reference. Normally, the caller makes a copy and passes
|
||||
the address of the copy to the routine being called. When
|
||||
FUNCTION_ARG_CALLEE_COPIES is defined and is nonzero, the caller
|
||||
does not make a copy. Instead, it passes a pointer to the "live"
|
||||
value. The called function must not modify this value. If it can
|
||||
be determined that the value won't be modified, it need not make a
|
||||
copy; otherwise a copy must be made.
|
||||
|
||||
`CUMULATIVE_ARGS'
|
||||
A C type for declaring a variable that is used as the first
|
||||
argument of `FUNCTION_ARG' and other related values. For some
|
||||
target machines, the type `int' suffices and can hold the number
|
||||
of bytes of argument so far.
|
||||
|
||||
There is no need to record in `CUMULATIVE_ARGS' anything about the
|
||||
arguments that have been passed on the stack. The compiler has
|
||||
other variables to keep track of that. For target machines on
|
||||
which all arguments are passed on the stack, there is no need to
|
||||
store anything in `CUMULATIVE_ARGS'; however, the data structure
|
||||
must exist and should not be empty, so use `int'.
|
||||
|
||||
`INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, INDIRECT)'
|
||||
A C statement (sans semicolon) for initializing the variable CUM
|
||||
for the state at the beginning of the argument list. The variable
|
||||
has type `CUMULATIVE_ARGS'. The value of FNTYPE is the tree node
|
||||
for the data type of the function which will receive the args, or 0
|
||||
if the args are to a compiler support library function. The value
|
||||
of INDIRECT is nonzero when processing an indirect call, for
|
||||
example a call through a function pointer. The value of INDIRECT
|
||||
is zero for a call to an explicitly named function, a library
|
||||
function call, or when `INIT_CUMULATIVE_ARGS' is used to find
|
||||
arguments for the function being compiled.
|
||||
|
||||
When processing a call to a compiler support library function,
|
||||
LIBNAME identifies which one. It is a `symbol_ref' rtx which
|
||||
contains the name of the function, as a string. LIBNAME is 0 when
|
||||
an ordinary C function call is being processed. Thus, each time
|
||||
this macro is called, either LIBNAME or FNTYPE is nonzero, but
|
||||
never both of them at once.
|
||||
|
||||
`INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME)'
|
||||
Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of
|
||||
finding the arguments for the function being compiled. If this
|
||||
macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead.
|
||||
|
||||
The value passed for LIBNAME is always 0, since library routines
|
||||
with special calling conventions are never compiled with GNU CC.
|
||||
The argument LIBNAME exists for symmetry with
|
||||
`INIT_CUMULATIVE_ARGS'.
|
||||
|
||||
`FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)'
|
||||
A C statement (sans semicolon) to update the summarizer variable
|
||||
CUM to advance past an argument in the argument list. The values
|
||||
MODE, TYPE and NAMED describe that argument. Once this is done,
|
||||
the variable CUM is suitable for analyzing the *following*
|
||||
argument with `FUNCTION_ARG', etc.
|
||||
|
||||
This macro need not do anything if the argument in question was
|
||||
passed on the stack. The compiler knows how to track the amount
|
||||
of stack space used for arguments without any special help.
|
||||
|
||||
`FUNCTION_ARG_PADDING (MODE, TYPE)'
|
||||
If defined, a C expression which determines whether, and in which
|
||||
direction, to pad out an argument with extra space. The value
|
||||
should be of type `enum direction': either `upward' to pad above
|
||||
the argument, `downward' to pad below, or `none' to inhibit
|
||||
padding.
|
||||
|
||||
The *amount* of padding is always just enough to reach the next
|
||||
multiple of `FUNCTION_ARG_BOUNDARY'; this macro does not control
|
||||
it.
|
||||
|
||||
This macro has a default definition which is right for most
|
||||
systems. For little-endian machines, the default is to pad
|
||||
upward. For big-endian machines, the default is to pad downward
|
||||
for an argument of constant size shorter than an `int', and upward
|
||||
otherwise.
|
||||
|
||||
`FUNCTION_ARG_BOUNDARY (MODE, TYPE)'
|
||||
If defined, a C expression that gives the alignment boundary, in
|
||||
bits, of an argument with the specified mode and type. If it is
|
||||
not defined, `PARM_BOUNDARY' is used for all arguments.
|
||||
|
||||
`FUNCTION_ARG_REGNO_P (REGNO)'
|
||||
A C expression that is nonzero if REGNO is the number of a hard
|
||||
register in which function arguments are sometimes passed. This
|
||||
does *not* include implicit arguments such as the static chain and
|
||||
the structure-value address. On many machines, no registers can be
|
||||
used for this purpose since all function arguments are pushed on
|
||||
the stack.
|
||||
|
||||
`LOAD_ARGS_REVERSED'
|
||||
If defined, the order in which arguments are loaded into their
|
||||
respective argument registers is reversed so that the last
|
||||
argument is loaded first. This macro only effects arguments
|
||||
passed in registers.
|
||||
|
||||
|
||||
File: gcc.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling
|
||||
|
||||
How Scalar Function Values Are Returned
|
||||
---------------------------------------
|
||||
|
||||
This section discusses the macros that control returning scalars as
|
||||
values--values that can fit in registers.
|
||||
|
||||
`TRADITIONAL_RETURN_FLOAT'
|
||||
Define this macro if `-traditional' should not cause functions
|
||||
declared to return `float' to convert the value to `double'.
|
||||
|
||||
`FUNCTION_VALUE (VALTYPE, FUNC)'
|
||||
A C expression to create an RTX representing the place where a
|
||||
function returns a value of data type VALTYPE. VALTYPE is a tree
|
||||
node representing a data type. Write `TYPE_MODE (VALTYPE)' to get
|
||||
the machine mode used to represent that type. On many machines,
|
||||
only the mode is relevant. (Actually, on most machines, scalar
|
||||
values are returned in the same place regardless of mode).
|
||||
|
||||
The value of the expression is usually a `reg' RTX for the hard
|
||||
register where the return value is stored. The value can also be a
|
||||
`parallel' RTX, if the return value is in multiple places. See
|
||||
`FUNCTION_ARG' for an explanation of the `parallel' form.
|
||||
|
||||
If `PROMOTE_FUNCTION_RETURN' is defined, you must apply the same
|
||||
promotion rules specified in `PROMOTE_MODE' if VALTYPE is a scalar
|
||||
type.
|
||||
|
||||
If the precise function being called is known, FUNC is a tree node
|
||||
(`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This
|
||||
makes it possible to use a different value-returning convention
|
||||
for specific functions when all their calls are known.
|
||||
|
||||
`FUNCTION_VALUE' is not used for return vales with aggregate data
|
||||
types, because these are returned in another way. See
|
||||
`STRUCT_VALUE_REGNUM' and related macros, below.
|
||||
|
||||
`FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)'
|
||||
Define this macro if the target machine has "register windows" so
|
||||
that the register in which a function returns its value is not the
|
||||
same as the one in which the caller sees the value.
|
||||
|
||||
For such machines, `FUNCTION_VALUE' computes the register in which
|
||||
the caller will see the value. `FUNCTION_OUTGOING_VALUE' should be
|
||||
defined in a similar fashion to tell the function where to put the
|
||||
value.
|
||||
|
||||
If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE'
|
||||
serves both purposes.
|
||||
|
||||
`FUNCTION_OUTGOING_VALUE' is not used for return vales with
|
||||
aggregate data types, because these are returned in another way.
|
||||
See `STRUCT_VALUE_REGNUM' and related macros, below.
|
||||
|
||||
`LIBCALL_VALUE (MODE)'
|
||||
A C expression to create an RTX representing the place where a
|
||||
library function returns a value of mode MODE. If the precise
|
||||
function being called is known, FUNC is a tree node
|
||||
(`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This
|
||||
makes it possible to use a different value-returning convention
|
||||
for specific functions when all their calls are known.
|
||||
|
||||
Note that "library function" in this context means a compiler
|
||||
support routine, used to perform arithmetic, whose name is known
|
||||
specially by the compiler and was not mentioned in the C code being
|
||||
compiled.
|
||||
|
||||
The definition of `LIBRARY_VALUE' need not be concerned aggregate
|
||||
data types, because none of the library functions returns such
|
||||
types.
|
||||
|
||||
`FUNCTION_VALUE_REGNO_P (REGNO)'
|
||||
A C expression that is nonzero if REGNO is the number of a hard
|
||||
register in which the values of called function may come back.
|
||||
|
||||
A register whose use for returning values is limited to serving as
|
||||
the second of a pair (for a value of type `double', say) need not
|
||||
be recognized by this macro. So for most machines, this definition
|
||||
suffices:
|
||||
|
||||
#define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)
|
||||
|
||||
If the machine has register windows, so that the caller and the
|
||||
called function use different registers for the return value, this
|
||||
macro should recognize only the caller's register numbers.
|
||||
|
||||
`APPLY_RESULT_SIZE'
|
||||
Define this macro if `untyped_call' and `untyped_return' need more
|
||||
space than is implied by `FUNCTION_VALUE_REGNO_P' for saving and
|
||||
restoring an arbitrary return value.
|
||||
|
||||
|
||||
File: gcc.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling
|
||||
|
||||
How Large Values Are Returned
|
||||
-----------------------------
|
||||
|
||||
When a function value's mode is `BLKmode' (and in some other cases),
|
||||
the value is not returned according to `FUNCTION_VALUE' (*note Scalar
|
||||
Return::.). Instead, the caller passes the address of a block of
|
||||
memory in which the value should be stored. This address is called the
|
||||
"structure value address".
|
||||
|
||||
This section describes how to control returning structure values in
|
||||
memory.
|
||||
|
||||
`RETURN_IN_MEMORY (TYPE)'
|
||||
A C expression which can inhibit the returning of certain function
|
||||
values in registers, based on the type of value. A nonzero value
|
||||
says to return the function value in memory, just as large
|
||||
structures are always returned. Here TYPE will be a C expression
|
||||
of type `tree', representing the data type of the value.
|
||||
|
||||
Note that values of mode `BLKmode' must be explicitly handled by
|
||||
this macro. Also, the option `-fpcc-struct-return' takes effect
|
||||
regardless of this macro. On most systems, it is possible to
|
||||
leave the macro undefined; this causes a default definition to be
|
||||
used, whose value is the constant 1 for `BLKmode' values, and 0
|
||||
otherwise.
|
||||
|
||||
Do not use this macro to indicate that structures and unions
|
||||
should always be returned in memory. You should instead use
|
||||
`DEFAULT_PCC_STRUCT_RETURN' to indicate this.
|
||||
|
||||
`DEFAULT_PCC_STRUCT_RETURN'
|
||||
Define this macro to be 1 if all structure and union return values
|
||||
must be in memory. Since this results in slower code, this should
|
||||
be defined only if needed for compatibility with other compilers
|
||||
or with an ABI. If you define this macro to be 0, then the
|
||||
conventions used for structure and union return values are decided
|
||||
by the `RETURN_IN_MEMORY' macro.
|
||||
|
||||
If not defined, this defaults to the value 1.
|
||||
|
||||
`STRUCT_VALUE_REGNUM'
|
||||
If the structure value address is passed in a register, then
|
||||
`STRUCT_VALUE_REGNUM' should be the number of that register.
|
||||
|
||||
`STRUCT_VALUE'
|
||||
If the structure value address is not passed in a register, define
|
||||
`STRUCT_VALUE' as an expression returning an RTX for the place
|
||||
where the address is passed. If it returns 0, the address is
|
||||
passed as an "invisible" first argument.
|
||||
|
||||
`STRUCT_VALUE_INCOMING_REGNUM'
|
||||
On some architectures the place where the structure value address
|
||||
is found by the called function is not the same place that the
|
||||
caller put it. This can be due to register windows, or it could
|
||||
be because the function prologue moves it to a different place.
|
||||
|
||||
If the incoming location of the structure value address is in a
|
||||
register, define this macro as the register number.
|
||||
|
||||
`STRUCT_VALUE_INCOMING'
|
||||
If the incoming location is not a register, then you should define
|
||||
`STRUCT_VALUE_INCOMING' as an expression for an RTX for where the
|
||||
called function should find the value. If it should find the
|
||||
value on the stack, define this to create a `mem' which refers to
|
||||
the frame pointer. A definition of 0 means that the address is
|
||||
passed as an "invisible" first argument.
|
||||
|
||||
`PCC_STATIC_STRUCT_RETURN'
|
||||
Define this macro if the usual system convention on the target
|
||||
machine for returning structures and unions is for the called
|
||||
function to return the address of a static variable containing the
|
||||
value.
|
||||
|
||||
Do not define this if the usual system convention is for the
|
||||
caller to pass an address to the subroutine.
|
||||
|
||||
This macro has effect in `-fpcc-struct-return' mode, but it does
|
||||
nothing when you use `-freg-struct-return' mode.
|
||||
|
||||
|
||||
File: gcc.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling
|
||||
|
||||
Caller-Saves Register Allocation
|
||||
--------------------------------
|
||||
|
||||
If you enable it, GNU CC can save registers around function calls.
|
||||
This makes it possible to use call-clobbered registers to hold
|
||||
variables that must live across calls.
|
||||
|
||||
`DEFAULT_CALLER_SAVES'
|
||||
Define this macro if function calls on the target machine do not
|
||||
preserve any registers; in other words, if `CALL_USED_REGISTERS'
|
||||
has 1 for all registers. When defined, this macro enables
|
||||
`-fcaller-saves' by default for all optimization levels. It has
|
||||
no effect for optimization levels 2 and higher, where
|
||||
`-fcaller-saves' is the default.
|
||||
|
||||
`CALLER_SAVE_PROFITABLE (REFS, CALLS)'
|
||||
A C expression to determine whether it is worthwhile to consider
|
||||
placing a pseudo-register in a call-clobbered hard register and
|
||||
saving and restoring it around each function call. The expression
|
||||
should be 1 when this is worth doing, and 0 otherwise.
|
||||
|
||||
If you don't define this macro, a default is used which is good on
|
||||
most machines: `4 * CALLS < REFS'.
|
||||
|
||||
`HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS)'
|
||||
A C expression specifying which mode is required for saving NREGS
|
||||
of a pseudo-register in call-clobbered hard register REGNO. If
|
||||
REGNO is unsuitable for caller save, `VOIDmode' should be
|
||||
returned. For most machines this macro need not be defined since
|
||||
GCC will select the smallest suitable mode.
|
||||
|
||||
|
||||
File: gcc.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling
|
||||
|
||||
Function Entry and Exit
|
||||
-----------------------
|
||||
|
||||
This section describes the macros that output function entry
|
||||
("prologue") and exit ("epilogue") code.
|
||||
|
||||
`FUNCTION_PROLOGUE (FILE, SIZE)'
|
||||
A C compound statement that outputs the assembler code for entry
|
||||
to a function. The prologue is responsible for setting up the
|
||||
stack frame, initializing the frame pointer register, saving
|
||||
registers that must be saved, and allocating SIZE additional bytes
|
||||
of storage for the local variables. SIZE is an integer. FILE is
|
||||
a stdio stream to which the assembler code should be output.
|
||||
|
||||
The label for the beginning of the function need not be output by
|
||||
this macro. That has already been done when the macro is run.
|
||||
|
||||
To determine which registers to save, the macro can refer to the
|
||||
array `regs_ever_live': element R is nonzero if hard register R is
|
||||
used anywhere within the function. This implies the function
|
||||
prologue should save register R, provided it is not one of the
|
||||
call-used registers. (`FUNCTION_EPILOGUE' must likewise use
|
||||
`regs_ever_live'.)
|
||||
|
||||
On machines that have "register windows", the function entry code
|
||||
does not save on the stack the registers that are in the windows,
|
||||
even if they are supposed to be preserved by function calls;
|
||||
instead it takes appropriate steps to "push" the register stack,
|
||||
if any non-call-used registers are used in the function.
|
||||
|
||||
On machines where functions may or may not have frame-pointers, the
|
||||
function entry code must vary accordingly; it must set up the frame
|
||||
pointer if one is wanted, and not otherwise. To determine whether
|
||||
a frame pointer is in wanted, the macro can refer to the variable
|
||||
`frame_pointer_needed'. The variable's value will be 1 at run
|
||||
time in a function that needs a frame pointer. *Note
|
||||
Elimination::.
|
||||
|
||||
The function entry code is responsible for allocating any stack
|
||||
space required for the function. This stack space consists of the
|
||||
regions listed below. In most cases, these regions are allocated
|
||||
in the order listed, with the last listed region closest to the
|
||||
top of the stack (the lowest address if `STACK_GROWS_DOWNWARD' is
|
||||
defined, and the highest address if it is not defined). You can
|
||||
use a different order for a machine if doing so is more convenient
|
||||
or required for compatibility reasons. Except in cases where
|
||||
required by standard or by a debugger, there is no reason why the
|
||||
stack layout used by GCC need agree with that used by other
|
||||
compilers for a machine.
|
||||
|
||||
* A region of `current_function_pretend_args_size' bytes of
|
||||
uninitialized space just underneath the first argument
|
||||
arriving on the stack. (This may not be at the very start of
|
||||
the allocated stack region if the calling sequence has pushed
|
||||
anything else since pushing the stack arguments. But
|
||||
usually, on such machines, nothing else has been pushed yet,
|
||||
because the function prologue itself does all the pushing.)
|
||||
This region is used on machines where an argument may be
|
||||
passed partly in registers and partly in memory, and, in some
|
||||
cases to support the features in `varargs.h' and `stdargs.h'.
|
||||
|
||||
* An area of memory used to save certain registers used by the
|
||||
function. The size of this area, which may also include
|
||||
space for such things as the return address and pointers to
|
||||
previous stack frames, is machine-specific and usually
|
||||
depends on which registers have been used in the function.
|
||||
Machines with register windows often do not require a save
|
||||
area.
|
||||
|
||||
* A region of at least SIZE bytes, possibly rounded up to an
|
||||
allocation boundary, to contain the local variables of the
|
||||
function. On some machines, this region and the save area
|
||||
may occur in the opposite order, with the save area closer to
|
||||
the top of the stack.
|
||||
|
||||
* Optionally, when `ACCUMULATE_OUTGOING_ARGS' is defined, a
|
||||
region of `current_function_outgoing_args_size' bytes to be
|
||||
used for outgoing argument lists of the function. *Note
|
||||
Stack Arguments::.
|
||||
|
||||
Normally, it is necessary for the macros `FUNCTION_PROLOGUE' and
|
||||
`FUNCTION_EPILOGUE' to treat leaf functions specially. The C
|
||||
variable `current_function_is_leaf' is nonzero for such a function.
|
||||
|
||||
`EXIT_IGNORE_STACK'
|
||||
Define this macro as a C expression that is nonzero if the return
|
||||
instruction or the function epilogue ignores the value of the stack
|
||||
pointer; in other words, if it is safe to delete an instruction to
|
||||
adjust the stack pointer before a return from the function.
|
||||
|
||||
Note that this macro's value is relevant only for functions for
|
||||
which frame pointers are maintained. It is never safe to delete a
|
||||
final stack adjustment in a function that has no frame pointer,
|
||||
and the compiler knows this regardless of `EXIT_IGNORE_STACK'.
|
||||
|
||||
`EPILOGUE_USES (REGNO)'
|
||||
Define this macro as a C expression that is nonzero for registers
|
||||
are used by the epilogue or the `return' pattern. The stack and
|
||||
frame pointer registers are already be assumed to be used as
|
||||
needed.
|
||||
|
||||
`FUNCTION_EPILOGUE (FILE, SIZE)'
|
||||
A C compound statement that outputs the assembler code for exit
|
||||
from a function. The epilogue is responsible for restoring the
|
||||
saved registers and stack pointer to their values when the
|
||||
function was called, and returning control to the caller. This
|
||||
macro takes the same arguments as the macro `FUNCTION_PROLOGUE',
|
||||
and the registers to restore are determined from `regs_ever_live'
|
||||
and `CALL_USED_REGISTERS' in the same way.
|
||||
|
||||
On some machines, there is a single instruction that does all the
|
||||
work of returning from the function. On these machines, give that
|
||||
instruction the name `return' and do not define the macro
|
||||
`FUNCTION_EPILOGUE' at all.
|
||||
|
||||
Do not define a pattern named `return' if you want the
|
||||
`FUNCTION_EPILOGUE' to be used. If you want the target switches
|
||||
to control whether return instructions or epilogues are used,
|
||||
define a `return' pattern with a validity condition that tests the
|
||||
target switches appropriately. If the `return' pattern's validity
|
||||
condition is false, epilogues will be used.
|
||||
|
||||
On machines where functions may or may not have frame-pointers, the
|
||||
function exit code must vary accordingly. Sometimes the code for
|
||||
these two cases is completely different. To determine whether a
|
||||
frame pointer is wanted, the macro can refer to the variable
|
||||
`frame_pointer_needed'. The variable's value will be 1 when
|
||||
compiling a function that needs a frame pointer.
|
||||
|
||||
Normally, `FUNCTION_PROLOGUE' and `FUNCTION_EPILOGUE' must treat
|
||||
leaf functions specially. The C variable
|
||||
`current_function_is_leaf' is nonzero for such a function. *Note
|
||||
Leaf Functions::.
|
||||
|
||||
On some machines, some functions pop their arguments on exit while
|
||||
others leave that for the caller to do. For example, the 68020
|
||||
when given `-mrtd' pops arguments in functions that take a fixed
|
||||
number of arguments.
|
||||
|
||||
Your definition of the macro `RETURN_POPS_ARGS' decides which
|
||||
functions pop their own arguments. `FUNCTION_EPILOGUE' needs to
|
||||
know what was decided. The variable that is called
|
||||
`current_function_pops_args' is the number of bytes of its
|
||||
arguments that a function should pop. *Note Scalar Return::.
|
||||
|
||||
`DELAY_SLOTS_FOR_EPILOGUE'
|
||||
Define this macro if the function epilogue contains delay slots to
|
||||
which instructions from the rest of the function can be "moved".
|
||||
The definition should be a C expression whose value is an integer
|
||||
representing the number of delay slots there.
|
||||
|
||||
`ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N)'
|
||||
A C expression that returns 1 if INSN can be placed in delay slot
|
||||
number N of the epilogue.
|
||||
|
||||
The argument N is an integer which identifies the delay slot now
|
||||
being considered (since different slots may have different rules of
|
||||
eligibility). It is never negative and is always less than the
|
||||
number of epilogue delay slots (what `DELAY_SLOTS_FOR_EPILOGUE'
|
||||
returns). If you reject a particular insn for a given delay slot,
|
||||
in principle, it may be reconsidered for a subsequent delay slot.
|
||||
Also, other insns may (at least in principle) be considered for
|
||||
the so far unfilled delay slot.
|
||||
|
||||
The insns accepted to fill the epilogue delay slots are put in an
|
||||
RTL list made with `insn_list' objects, stored in the variable
|
||||
`current_function_epilogue_delay_list'. The insn for the first
|
||||
delay slot comes first in the list. Your definition of the macro
|
||||
`FUNCTION_EPILOGUE' should fill the delay slots by outputting the
|
||||
insns in this list, usually by calling `final_scan_insn'.
|
||||
|
||||
You need not define this macro if you did not define
|
||||
`DELAY_SLOTS_FOR_EPILOGUE'.
|
||||
|
||||
`ASM_OUTPUT_MI_THUNK (FILE, THUNK_FNDECL, DELTA, FUNCTION)'
|
||||
A C compound statement that outputs the assembler code for a thunk
|
||||
function, used to implement C++ virtual function calls with
|
||||
multiple inheritance. The thunk acts as a wrapper around a
|
||||
virtual function, adjusting the implicit object parameter before
|
||||
handing control off to the real function.
|
||||
|
||||
First, emit code to add the integer DELTA to the location that
|
||||
contains the incoming first argument. Assume that this argument
|
||||
contains a pointer, and is the one used to pass the `this' pointer
|
||||
in C++. This is the incoming argument *before* the function
|
||||
prologue, e.g. `%o0' on a sparc. The addition must preserve the
|
||||
values of all other incoming arguments.
|
||||
|
||||
After the addition, emit code to jump to FUNCTION, which is a
|
||||
`FUNCTION_DECL'. This is a direct pure jump, not a call, and does
|
||||
not touch the return address. Hence returning from FUNCTION will
|
||||
return to whoever called the current `thunk'.
|
||||
|
||||
The effect must be as if FUNCTION had been called directly with
|
||||
the adjusted first argument. This macro is responsible for
|
||||
emitting all of the code for a thunk function; `FUNCTION_PROLOGUE'
|
||||
and `FUNCTION_EPILOGUE' are not invoked.
|
||||
|
||||
The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already
|
||||
been extracted from it.) It might possibly be useful on some
|
||||
targets, but probably not.
|
||||
|
||||
If you do not define this macro, the target-independent code in
|
||||
the C++ frontend will generate a less efficient heavyweight thunk
|
||||
that calls FUNCTION instead of jumping to it. The generic
|
||||
approach does not support varargs.
|
||||
|
||||
|
||||
File: gcc.info, Node: Profiling, Prev: Function Entry, Up: Stack and Calling
|
||||
|
||||
Generating Code for Profiling
|
||||
-----------------------------
|
||||
|
||||
These macros will help you generate code for profiling.
|
||||
|
||||
`FUNCTION_PROFILER (FILE, LABELNO)'
|
||||
A C statement or compound statement to output to FILE some
|
||||
assembler code to call the profiling subroutine `mcount'. Before
|
||||
calling, the assembler code must load the address of a counter
|
||||
variable into a register where `mcount' expects to find the
|
||||
address. The name of this variable is `LP' followed by the number
|
||||
LABELNO, so you would generate the name using `LP%d' in a
|
||||
`fprintf'.
|
||||
|
||||
The details of how the address should be passed to `mcount' are
|
||||
determined by your operating system environment, not by GNU CC. To
|
||||
figure them out, compile a small program for profiling using the
|
||||
system's installed C compiler and look at the assembler code that
|
||||
results.
|
||||
|
||||
`PROFILE_BEFORE_PROLOGUE'
|
||||
Define this macro if the code for function profiling should come
|
||||
before the function prologue. Normally, the profiling code comes
|
||||
after.
|
||||
|
||||
`FUNCTION_BLOCK_PROFILER (FILE, LABELNO)'
|
||||
A C statement or compound statement to output to FILE some
|
||||
assembler code to initialize basic-block profiling for the current
|
||||
object module. The global compile flag `profile_block_flag'
|
||||
distinguishes two profile modes.
|
||||
|
||||
`profile_block_flag != 2'
|
||||
Output code to call the subroutine `__bb_init_func' once per
|
||||
object module, passing it as its sole argument the address of
|
||||
a block allocated in the object module.
|
||||
|
||||
The name of the block is a local symbol made with this
|
||||
statement:
|
||||
|
||||
ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0);
|
||||
|
||||
Of course, since you are writing the definition of
|
||||
`ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro,
|
||||
you can take a short cut in the definition of this macro and
|
||||
use the name that you know will result.
|
||||
|
||||
The first word of this block is a flag which will be nonzero
|
||||
if the object module has already been initialized. So test
|
||||
this word first, and do not call `__bb_init_func' if the flag
|
||||
is nonzero. BLOCK_OR_LABEL contains a unique number which
|
||||
may be used to generate a label as a branch destination when
|
||||
`__bb_init_func' will not be called.
|
||||
|
||||
Described in assembler language, the code to be output looks
|
||||
like:
|
||||
|
||||
cmp (LPBX0),0
|
||||
bne local_label
|
||||
parameter1 <- LPBX0
|
||||
call __bb_init_func
|
||||
local_label:
|
||||
|
||||
`profile_block_flag == 2'
|
||||
Output code to call the subroutine `__bb_init_trace_func' and
|
||||
pass two parameters to it. The first parameter is the same as
|
||||
for `__bb_init_func'. The second parameter is the number of
|
||||
the first basic block of the function as given by
|
||||
BLOCK_OR_LABEL. Note that `__bb_init_trace_func' has to be
|
||||
called, even if the object module has been initialized
|
||||
already.
|
||||
|
||||
Described in assembler language, the code to be output looks
|
||||
like:
|
||||
parameter1 <- LPBX0
|
||||
parameter2 <- BLOCK_OR_LABEL
|
||||
call __bb_init_trace_func
|
||||
|
||||
`BLOCK_PROFILER (FILE, BLOCKNO)'
|
||||
A C statement or compound statement to output to FILE some
|
||||
assembler code to increment the count associated with the basic
|
||||
block number BLOCKNO. The global compile flag
|
||||
`profile_block_flag' distinguishes two profile modes.
|
||||
|
||||
`profile_block_flag != 2'
|
||||
Output code to increment the counter directly. Basic blocks
|
||||
are numbered separately from zero within each compilation.
|
||||
The count associated with block number BLOCKNO is at index
|
||||
BLOCKNO in a vector of words; the name of this array is a
|
||||
local symbol made with this statement:
|
||||
|
||||
ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 2);
|
||||
|
||||
Of course, since you are writing the definition of
|
||||
`ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro,
|
||||
you can take a short cut in the definition of this macro and
|
||||
use the name that you know will result.
|
||||
|
||||
Described in assembler language, the code to be output looks
|
||||
like:
|
||||
|
||||
inc (LPBX2+4*BLOCKNO)
|
||||
|
||||
`profile_block_flag == 2'
|
||||
Output code to initialize the global structure `__bb' and
|
||||
call the function `__bb_trace_func', which will increment the
|
||||
counter.
|
||||
|
||||
`__bb' consists of two words. In the first word, the current
|
||||
basic block number, as given by BLOCKNO, has to be stored. In
|
||||
the second word, the address of a block allocated in the
|
||||
object module has to be stored. The address is given by the
|
||||
label created with this statement:
|
||||
|
||||
ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0);
|
||||
|
||||
Described in assembler language, the code to be output looks
|
||||
like:
|
||||
move BLOCKNO -> (__bb)
|
||||
move LPBX0 -> (__bb+4)
|
||||
call __bb_trace_func
|
||||
|
||||
`FUNCTION_BLOCK_PROFILER_EXIT (FILE)'
|
||||
A C statement or compound statement to output to FILE assembler
|
||||
code to call function `__bb_trace_ret'. The assembler code should
|
||||
only be output if the global compile flag `profile_block_flag' ==
|
||||
2. This macro has to be used at every place where code for
|
||||
returning from a function is generated (e.g. `FUNCTION_EPILOGUE').
|
||||
Although you have to write the definition of `FUNCTION_EPILOGUE'
|
||||
as well, you have to define this macro to tell the compiler, that
|
||||
the proper call to `__bb_trace_ret' is produced.
|
||||
|
||||
`MACHINE_STATE_SAVE (ID)'
|
||||
A C statement or compound statement to save all registers, which
|
||||
may be clobbered by a function call, including condition codes.
|
||||
The `asm' statement will be mostly likely needed to handle this
|
||||
task. Local labels in the assembler code can be concatenated with
|
||||
the string ID, to obtain a unique lable name.
|
||||
|
||||
Registers or condition codes clobbered by `FUNCTION_PROLOGUE' or
|
||||
`FUNCTION_EPILOGUE' must be saved in the macros
|
||||
`FUNCTION_BLOCK_PROFILER', `FUNCTION_BLOCK_PROFILER_EXIT' and
|
||||
`BLOCK_PROFILER' prior calling `__bb_init_trace_func',
|
||||
`__bb_trace_ret' and `__bb_trace_func' respectively.
|
||||
|
||||
`MACHINE_STATE_RESTORE (ID)'
|
||||
A C statement or compound statement to restore all registers,
|
||||
including condition codes, saved by `MACHINE_STATE_SAVE'.
|
||||
|
||||
Registers or condition codes clobbered by `FUNCTION_PROLOGUE' or
|
||||
`FUNCTION_EPILOGUE' must be restored in the macros
|
||||
`FUNCTION_BLOCK_PROFILER', `FUNCTION_BLOCK_PROFILER_EXIT' and
|
||||
`BLOCK_PROFILER' after calling `__bb_init_trace_func',
|
||||
`__bb_trace_ret' and `__bb_trace_func' respectively.
|
||||
|
||||
`BLOCK_PROFILER_CODE'
|
||||
A C function or functions which are needed in the library to
|
||||
support block profiling.
|
||||
|
||||
|
||||
File: gcc.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros
|
||||
|
||||
Implementing the Varargs Macros
|
||||
===============================
|
||||
|
||||
GNU CC comes with an implementation of `varargs.h' and `stdarg.h'
|
||||
that work without change on machines that pass arguments on the stack.
|
||||
Other machines require their own implementations of varargs, and the
|
||||
two machine independent header files must have conditionals to include
|
||||
it.
|
||||
|
||||
ANSI `stdarg.h' differs from traditional `varargs.h' mainly in the
|
||||
calling convention for `va_start'. The traditional implementation
|
||||
takes just one argument, which is the variable in which to store the
|
||||
argument pointer. The ANSI implementation of `va_start' takes an
|
||||
additional second argument. The user is supposed to write the last
|
||||
named argument of the function here.
|
||||
|
||||
However, `va_start' should not use this argument. The way to find
|
||||
the end of the named arguments is with the built-in functions described
|
||||
below.
|
||||
|
||||
`__builtin_saveregs ()'
|
||||
Use this built-in function to save the argument registers in
|
||||
memory so that the varargs mechanism can access them. Both ANSI
|
||||
and traditional versions of `va_start' must use
|
||||
`__builtin_saveregs', unless you use `SETUP_INCOMING_VARARGS' (see
|
||||
below) instead.
|
||||
|
||||
On some machines, `__builtin_saveregs' is open-coded under the
|
||||
control of the macro `EXPAND_BUILTIN_SAVEREGS'. On other machines,
|
||||
it calls a routine written in assembler language, found in
|
||||
`libgcc2.c'.
|
||||
|
||||
Code generated for the call to `__builtin_saveregs' appears at the
|
||||
beginning of the function, as opposed to where the call to
|
||||
`__builtin_saveregs' is written, regardless of what the code is.
|
||||
This is because the registers must be saved before the function
|
||||
starts to use them for its own purposes.
|
||||
|
||||
`__builtin_args_info (CATEGORY)'
|
||||
Use this built-in function to find the first anonymous arguments in
|
||||
registers.
|
||||
|
||||
In general, a machine may have several categories of registers
|
||||
used for arguments, each for a particular category of data types.
|
||||
(For example, on some machines, floating-point registers are used
|
||||
for floating-point arguments while other arguments are passed in
|
||||
the general registers.) To make non-varargs functions use the
|
||||
proper calling convention, you have defined the `CUMULATIVE_ARGS'
|
||||
data type to record how many registers in each category have been
|
||||
used so far
|
||||
|
||||
`__builtin_args_info' accesses the same data structure of type
|
||||
`CUMULATIVE_ARGS' after the ordinary argument layout is finished
|
||||
with it, with CATEGORY specifying which word to access. Thus, the
|
||||
value indicates the first unused register in a given category.
|
||||
|
||||
Normally, you would use `__builtin_args_info' in the implementation
|
||||
of `va_start', accessing each category just once and storing the
|
||||
value in the `va_list' object. This is because `va_list' will
|
||||
have to update the values, and there is no way to alter the values
|
||||
accessed by `__builtin_args_info'.
|
||||
|
||||
`__builtin_next_arg (LASTARG)'
|
||||
This is the equivalent of `__builtin_args_info', for stack
|
||||
arguments. It returns the address of the first anonymous stack
|
||||
argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns
|
||||
the address of the location above the first anonymous stack
|
||||
argument. Use it in `va_start' to initialize the pointer for
|
||||
fetching arguments from the stack. Also use it in `va_start' to
|
||||
verify that the second parameter LASTARG is the last named argument
|
||||
of the current function.
|
||||
|
||||
`__builtin_classify_type (OBJECT)'
|
||||
Since each machine has its own conventions for which data types are
|
||||
passed in which kind of register, your implementation of `va_arg'
|
||||
has to embody these conventions. The easiest way to categorize the
|
||||
specified data type is to use `__builtin_classify_type' together
|
||||
with `sizeof' and `__alignof__'.
|
||||
|
||||
`__builtin_classify_type' ignores the value of OBJECT, considering
|
||||
only its data type. It returns an integer describing what kind of
|
||||
type that is--integer, floating, pointer, structure, and so on.
|
||||
|
||||
The file `typeclass.h' defines an enumeration that you can use to
|
||||
interpret the values of `__builtin_classify_type'.
|
||||
|
||||
These machine description macros help implement varargs:
|
||||
|
||||
`EXPAND_BUILTIN_SAVEREGS (ARGS)'
|
||||
If defined, is a C expression that produces the machine-specific
|
||||
code for a call to `__builtin_saveregs'. This code will be moved
|
||||
to the very beginning of the function, before any parameter access
|
||||
are made. The return value of this function should be an RTX that
|
||||
contains the value to use as the return of `__builtin_saveregs'.
|
||||
|
||||
The argument ARGS is a `tree_list' containing the arguments that
|
||||
were passed to `__builtin_saveregs'.
|
||||
|
||||
If this macro is not defined, the compiler will output an ordinary
|
||||
call to the library function `__builtin_saveregs'.
|
||||
|
||||
`SETUP_INCOMING_VARARGS (ARGS_SO_FAR, MODE, TYPE, PRETEND_ARGS_SIZE, SECOND_TIME)'
|
||||
This macro offers an alternative to using `__builtin_saveregs' and
|
||||
defining the macro `EXPAND_BUILTIN_SAVEREGS'. Use it to store the
|
||||
anonymous register arguments into the stack so that all the
|
||||
arguments appear to have been passed consecutively on the stack.
|
||||
Once this is done, you can use the standard implementation of
|
||||
varargs that works for machines that pass all their arguments on
|
||||
the stack.
|
||||
|
||||
The argument ARGS_SO_FAR is the `CUMULATIVE_ARGS' data structure,
|
||||
containing the values that obtain after processing of the named
|
||||
arguments. The arguments MODE and TYPE describe the last named
|
||||
argument--its machine mode and its data type as a tree node.
|
||||
|
||||
The macro implementation should do two things: first, push onto the
|
||||
stack all the argument registers *not* used for the named
|
||||
arguments, and second, store the size of the data thus pushed into
|
||||
the `int'-valued variable whose name is supplied as the argument
|
||||
PRETEND_ARGS_SIZE. The value that you store here will serve as
|
||||
additional offset for setting up the stack frame.
|
||||
|
||||
Because you must generate code to push the anonymous arguments at
|
||||
compile time without knowing their data types,
|
||||
`SETUP_INCOMING_VARARGS' is only useful on machines that have just
|
||||
a single category of argument register and use it uniformly for
|
||||
all data types.
|
||||
|
||||
If the argument SECOND_TIME is nonzero, it means that the
|
||||
arguments of the function are being analyzed for the second time.
|
||||
This happens for an inline function, which is not actually
|
||||
compiled until the end of the source file. The macro
|
||||
`SETUP_INCOMING_VARARGS' should not generate any instructions in
|
||||
this case.
|
||||
|
||||
`STRICT_ARGUMENT_NAMING'
|
||||
Define this macro to be a nonzero value if the location where a
|
||||
function argument is passed depends on whether or not it is a
|
||||
named argument.
|
||||
|
||||
This macro controls how the NAMED argument to `FUNCTION_ARG' is
|
||||
set for varargs and stdarg functions. If this macro returns a
|
||||
nonzero value, the NAMED argument is always true for named
|
||||
arguments, and false for unnamed arguments. If it returns a value
|
||||
of zero, but `SETUP_INCOMING_VARARGS' is defined, then all
|
||||
arguments are treated as named. Otherwise, all named arguments
|
||||
except the last are treated as named.
|
||||
|
||||
You need not define this macro if it always returns zero.
|
||||
|
||||
`PRETEND_OUTGOING_VARARGS_NAMED'
|
||||
If you need to conditionally change ABIs so that one works with
|
||||
`SETUP_INCOMING_VARARGS', but the other works like neither
|
||||
`SETUP_INCOMING_VARARGS' nor `STRICT_ARGUMENT_NAMING' was defined,
|
||||
then define this macro to return nonzero if
|
||||
`SETUP_INCOMING_VARARGS' is used, zero otherwise. Otherwise, you
|
||||
should not define this macro.
|
||||
|
||||
Executable
+980
@@ -0,0 +1,980 @@
|
||||
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
|
||||
input file ../../gcc-2.95.2/gcc/gcc.texi.
|
||||
|
||||
INFO-DIR-SECTION Programming
|
||||
START-INFO-DIR-ENTRY
|
||||
* gcc: (gcc). The GNU Compiler Collection.
|
||||
END-INFO-DIR-ENTRY
|
||||
This file documents the use and the internals of the GNU compiler.
|
||||
|
||||
Published by the Free Software Foundation 59 Temple Place - Suite 330
|
||||
Boston, MA 02111-1307 USA
|
||||
|
||||
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
|
||||
1999 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 "Funding
|
||||
for Free Software" 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 one.
|
||||
|
||||
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 "Funding for Free Software", 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: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros
|
||||
|
||||
Trampolines for Nested Functions
|
||||
================================
|
||||
|
||||
A "trampoline" is a small piece of code that is created at run time
|
||||
when the address of a nested function is taken. It normally resides on
|
||||
the stack, in the stack frame of the containing function. These macros
|
||||
tell GNU CC how to generate code to allocate and initialize a
|
||||
trampoline.
|
||||
|
||||
The instructions in the trampoline must do two things: load a
|
||||
constant address into the static chain register, and jump to the real
|
||||
address of the nested function. On CISC machines such as the m68k,
|
||||
this requires two instructions, a move immediate and a jump. Then the
|
||||
two addresses exist in the trampoline as word-long immediate operands.
|
||||
On RISC machines, it is often necessary to load each address into a
|
||||
register in two parts. Then pieces of each address form separate
|
||||
immediate operands.
|
||||
|
||||
The code generated to initialize the trampoline must store the
|
||||
variable parts--the static chain value and the function address--into
|
||||
the immediate operands of the instructions. On a CISC machine, this is
|
||||
simply a matter of copying each address to a memory reference at the
|
||||
proper offset from the start of the trampoline. On a RISC machine, it
|
||||
may be necessary to take out pieces of the address and store them
|
||||
separately.
|
||||
|
||||
`TRAMPOLINE_TEMPLATE (FILE)'
|
||||
A C statement to output, on the stream FILE, assembler code for a
|
||||
block of data that contains the constant parts of a trampoline.
|
||||
This code should not include a label--the label is taken care of
|
||||
automatically.
|
||||
|
||||
If you do not define this macro, it means no template is needed
|
||||
for the target. Do not define this macro on systems where the
|
||||
block move code to copy the trampoline into place would be larger
|
||||
than the code to generate it on the spot.
|
||||
|
||||
`TRAMPOLINE_SECTION'
|
||||
The name of a subroutine to switch to the section in which the
|
||||
trampoline template is to be placed (*note Sections::.). The
|
||||
default is a value of `readonly_data_section', which places the
|
||||
trampoline in the section containing read-only data.
|
||||
|
||||
`TRAMPOLINE_SIZE'
|
||||
A C expression for the size in bytes of the trampoline, as an
|
||||
integer.
|
||||
|
||||
`TRAMPOLINE_ALIGNMENT'
|
||||
Alignment required for trampolines, in bits.
|
||||
|
||||
If you don't define this macro, the value of `BIGGEST_ALIGNMENT'
|
||||
is used for aligning trampolines.
|
||||
|
||||
`INITIALIZE_TRAMPOLINE (ADDR, FNADDR, STATIC_CHAIN)'
|
||||
A C statement to initialize the variable parts of a trampoline.
|
||||
ADDR is an RTX for the address of the trampoline; FNADDR is an RTX
|
||||
for the address of the nested function; STATIC_CHAIN is an RTX for
|
||||
the static chain value that should be passed to the function when
|
||||
it is called.
|
||||
|
||||
`ALLOCATE_TRAMPOLINE (FP)'
|
||||
A C expression to allocate run-time space for a trampoline. The
|
||||
expression value should be an RTX representing a memory reference
|
||||
to the space for the trampoline.
|
||||
|
||||
If this macro is not defined, by default the trampoline is
|
||||
allocated as a stack slot. This default is right for most
|
||||
machines. The exceptions are machines where it is impossible to
|
||||
execute instructions in the stack area. On such machines, you may
|
||||
have to implement a separate stack, using this macro in
|
||||
conjunction with `FUNCTION_PROLOGUE' and `FUNCTION_EPILOGUE'.
|
||||
|
||||
FP points to a data structure, a `struct function', which
|
||||
describes the compilation status of the immediate containing
|
||||
function of the function which the trampoline is for. Normally
|
||||
(when `ALLOCATE_TRAMPOLINE' is not defined), the stack slot for the
|
||||
trampoline is in the stack frame of this containing function.
|
||||
Other allocation strategies probably must do something analogous
|
||||
with this information.
|
||||
|
||||
Implementing trampolines is difficult on many machines because they
|
||||
have separate instruction and data caches. Writing into a stack
|
||||
location fails to clear the memory in the instruction cache, so when
|
||||
the program jumps to that location, it executes the old contents.
|
||||
|
||||
Here are two possible solutions. One is to clear the relevant parts
|
||||
of the instruction cache whenever a trampoline is set up. The other is
|
||||
to make all trampolines identical, by having them jump to a standard
|
||||
subroutine. The former technique makes trampoline execution faster; the
|
||||
latter makes initialization faster.
|
||||
|
||||
To clear the instruction cache when a trampoline is initialized,
|
||||
define the following macros which describe the shape of the cache.
|
||||
|
||||
`INSN_CACHE_SIZE'
|
||||
The total size in bytes of the cache.
|
||||
|
||||
`INSN_CACHE_LINE_WIDTH'
|
||||
The length in bytes of each cache line. The cache is divided into
|
||||
cache lines which are disjoint slots, each holding a contiguous
|
||||
chunk of data fetched from memory. Each time data is brought into
|
||||
the cache, an entire line is read at once. The data loaded into a
|
||||
cache line is always aligned on a boundary equal to the line size.
|
||||
|
||||
`INSN_CACHE_DEPTH'
|
||||
The number of alternative cache lines that can hold any particular
|
||||
memory location.
|
||||
|
||||
Alternatively, if the machine has system calls or instructions to
|
||||
clear the instruction cache directly, you can define the following
|
||||
macro.
|
||||
|
||||
`CLEAR_INSN_CACHE (BEG, END)'
|
||||
If defined, expands to a C expression clearing the *instruction
|
||||
cache* in the specified interval. If it is not defined, and the
|
||||
macro INSN_CACHE_SIZE is defined, some generic code is generated
|
||||
to clear the cache. The definition of this macro would typically
|
||||
be a series of `asm' statements. Both BEG and END are both pointer
|
||||
expressions.
|
||||
|
||||
To use a standard subroutine, define the following macro. In
|
||||
addition, you must make sure that the instructions in a trampoline fill
|
||||
an entire cache line with identical instructions, or else ensure that
|
||||
the beginning of the trampoline code is always aligned at the same
|
||||
point in its cache line. Look in `m68k.h' as a guide.
|
||||
|
||||
`TRANSFER_FROM_TRAMPOLINE'
|
||||
Define this macro if trampolines need a special subroutine to do
|
||||
their work. The macro should expand to a series of `asm'
|
||||
statements which will be compiled with GNU CC. They go in a
|
||||
library function named `__transfer_from_trampoline'.
|
||||
|
||||
If you need to avoid executing the ordinary prologue code of a
|
||||
compiled C function when you jump to the subroutine, you can do so
|
||||
by placing a special label of your own in the assembler code. Use
|
||||
one `asm' statement to generate an assembler label, and another to
|
||||
make the label global. Then trampolines can use that label to
|
||||
jump directly to your special assembler code.
|
||||
|
||||
|
||||
File: gcc.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros
|
||||
|
||||
Implicit Calls to Library Routines
|
||||
==================================
|
||||
|
||||
Here is an explanation of implicit calls to library routines.
|
||||
|
||||
`MULSI3_LIBCALL'
|
||||
A C string constant giving the name of the function to call for
|
||||
multiplication of one signed full-word by another. If you do not
|
||||
define this macro, the default name is used, which is `__mulsi3',
|
||||
a function defined in `libgcc.a'.
|
||||
|
||||
`DIVSI3_LIBCALL'
|
||||
A C string constant giving the name of the function to call for
|
||||
division of one signed full-word by another. If you do not define
|
||||
this macro, the default name is used, which is `__divsi3', a
|
||||
function defined in `libgcc.a'.
|
||||
|
||||
`UDIVSI3_LIBCALL'
|
||||
A C string constant giving the name of the function to call for
|
||||
division of one unsigned full-word by another. If you do not
|
||||
define this macro, the default name is used, which is `__udivsi3',
|
||||
a function defined in `libgcc.a'.
|
||||
|
||||
`MODSI3_LIBCALL'
|
||||
A C string constant giving the name of the function to call for the
|
||||
remainder in division of one signed full-word by another. If you
|
||||
do not define this macro, the default name is used, which is
|
||||
`__modsi3', a function defined in `libgcc.a'.
|
||||
|
||||
`UMODSI3_LIBCALL'
|
||||
A C string constant giving the name of the function to call for the
|
||||
remainder in division of one unsigned full-word by another. If
|
||||
you do not define this macro, the default name is used, which is
|
||||
`__umodsi3', a function defined in `libgcc.a'.
|
||||
|
||||
`MULDI3_LIBCALL'
|
||||
A C string constant giving the name of the function to call for
|
||||
multiplication of one signed double-word by another. If you do not
|
||||
define this macro, the default name is used, which is `__muldi3',
|
||||
a function defined in `libgcc.a'.
|
||||
|
||||
`DIVDI3_LIBCALL'
|
||||
A C string constant giving the name of the function to call for
|
||||
division of one signed double-word by another. If you do not
|
||||
define this macro, the default name is used, which is `__divdi3', a
|
||||
function defined in `libgcc.a'.
|
||||
|
||||
`UDIVDI3_LIBCALL'
|
||||
A C string constant giving the name of the function to call for
|
||||
division of one unsigned full-word by another. If you do not
|
||||
define this macro, the default name is used, which is `__udivdi3',
|
||||
a function defined in `libgcc.a'.
|
||||
|
||||
`MODDI3_LIBCALL'
|
||||
A C string constant giving the name of the function to call for the
|
||||
remainder in division of one signed double-word by another. If
|
||||
you do not define this macro, the default name is used, which is
|
||||
`__moddi3', a function defined in `libgcc.a'.
|
||||
|
||||
`UMODDI3_LIBCALL'
|
||||
A C string constant giving the name of the function to call for the
|
||||
remainder in division of one unsigned full-word by another. If
|
||||
you do not define this macro, the default name is used, which is
|
||||
`__umoddi3', a function defined in `libgcc.a'.
|
||||
|
||||
`INIT_TARGET_OPTABS'
|
||||
Define this macro as a C statement that declares additional library
|
||||
routines renames existing ones. `init_optabs' calls this macro
|
||||
after initializing all the normal library routines.
|
||||
|
||||
`TARGET_EDOM'
|
||||
The value of `EDOM' on the target machine, as a C integer constant
|
||||
expression. If you don't define this macro, GNU CC does not
|
||||
attempt to deposit the value of `EDOM' into `errno' directly.
|
||||
Look in `/usr/include/errno.h' to find the value of `EDOM' on your
|
||||
system.
|
||||
|
||||
If you do not define `TARGET_EDOM', then compiled code reports
|
||||
domain errors by calling the library function and letting it
|
||||
report the error. If mathematical functions on your system use
|
||||
`matherr' when there is an error, then you should leave
|
||||
`TARGET_EDOM' undefined so that `matherr' is used normally.
|
||||
|
||||
`GEN_ERRNO_RTX'
|
||||
Define this macro as a C expression to create an rtl expression
|
||||
that refers to the global "variable" `errno'. (On certain systems,
|
||||
`errno' may not actually be a variable.) If you don't define this
|
||||
macro, a reasonable default is used.
|
||||
|
||||
`TARGET_MEM_FUNCTIONS'
|
||||
Define this macro if GNU CC should generate calls to the System V
|
||||
(and ANSI C) library functions `memcpy' and `memset' rather than
|
||||
the BSD functions `bcopy' and `bzero'.
|
||||
|
||||
`LIBGCC_NEEDS_DOUBLE'
|
||||
Define this macro if only `float' arguments cannot be passed to
|
||||
library routines (so they must be converted to `double'). This
|
||||
macro affects both how library calls are generated and how the
|
||||
library routines in `libgcc1.c' accept their arguments. It is
|
||||
useful on machines where floating and fixed point arguments are
|
||||
passed differently, such as the i860.
|
||||
|
||||
`FLOAT_ARG_TYPE'
|
||||
Define this macro to override the type used by the library
|
||||
routines to pick up arguments of type `float'. (By default, they
|
||||
use a union of `float' and `int'.)
|
||||
|
||||
The obvious choice would be `float'--but that won't work with
|
||||
traditional C compilers that expect all arguments declared as
|
||||
`float' to arrive as `double'. To avoid this conversion, the
|
||||
library routines ask for the value as some other type and then
|
||||
treat it as a `float'.
|
||||
|
||||
On some systems, no other type will work for this. For these
|
||||
systems, you must use `LIBGCC_NEEDS_DOUBLE' instead, to force
|
||||
conversion of the values `double' before they are passed.
|
||||
|
||||
`FLOATIFY (PASSED-VALUE)'
|
||||
Define this macro to override the way library routines redesignate
|
||||
a `float' argument as a `float' instead of the type it was passed
|
||||
as. The default is an expression which takes the `float' field of
|
||||
the union.
|
||||
|
||||
`FLOAT_VALUE_TYPE'
|
||||
Define this macro to override the type used by the library
|
||||
routines to return values that ought to have type `float'. (By
|
||||
default, they use `int'.)
|
||||
|
||||
The obvious choice would be `float'--but that won't work with
|
||||
traditional C compilers gratuitously convert values declared as
|
||||
`float' into `double'.
|
||||
|
||||
`INTIFY (FLOAT-VALUE)'
|
||||
Define this macro to override the way the value of a
|
||||
`float'-returning library routine should be packaged in order to
|
||||
return it. These functions are actually declared to return type
|
||||
`FLOAT_VALUE_TYPE' (normally `int').
|
||||
|
||||
These values can't be returned as type `float' because traditional
|
||||
C compilers would gratuitously convert the value to a `double'.
|
||||
|
||||
A local variable named `intify' is always available when the macro
|
||||
`INTIFY' is used. It is a union of a `float' field named `f' and
|
||||
a field named `i' whose type is `FLOAT_VALUE_TYPE' or `int'.
|
||||
|
||||
If you don't define this macro, the default definition works by
|
||||
copying the value through that union.
|
||||
|
||||
`nongcc_SI_type'
|
||||
Define this macro as the name of the data type corresponding to
|
||||
`SImode' in the system's own C compiler.
|
||||
|
||||
You need not define this macro if that type is `long int', as it
|
||||
usually is.
|
||||
|
||||
`nongcc_word_type'
|
||||
Define this macro as the name of the data type corresponding to the
|
||||
word_mode in the system's own C compiler.
|
||||
|
||||
You need not define this macro if that type is `long int', as it
|
||||
usually is.
|
||||
|
||||
`perform_...'
|
||||
Define these macros to supply explicit C statements to carry out
|
||||
various arithmetic operations on types `float' and `double' in the
|
||||
library routines in `libgcc1.c'. See that file for a full list of
|
||||
these macros and their arguments.
|
||||
|
||||
On most machines, you don't need to define any of these macros,
|
||||
because the C compiler that comes with the system takes care of
|
||||
doing them.
|
||||
|
||||
`NEXT_OBJC_RUNTIME'
|
||||
Define this macro to generate code for Objective C message sending
|
||||
using the calling convention of the NeXT system. This calling
|
||||
convention involves passing the object, the selector and the
|
||||
method arguments all at once to the method-lookup library function.
|
||||
|
||||
The default calling convention passes just the object and the
|
||||
selector to the lookup function, which returns a pointer to the
|
||||
method.
|
||||
|
||||
|
||||
File: gcc.info, Node: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Target Macros
|
||||
|
||||
Addressing Modes
|
||||
================
|
||||
|
||||
This is about addressing modes.
|
||||
|
||||
`HAVE_POST_INCREMENT'
|
||||
A C expression that is nonzero the machine supports post-increment
|
||||
addressing.
|
||||
|
||||
`HAVE_PRE_INCREMENT'
|
||||
`HAVE_POST_DECREMENT'
|
||||
`HAVE_PRE_DECREMENT'
|
||||
Similar for other kinds of addressing.
|
||||
|
||||
`CONSTANT_ADDRESS_P (X)'
|
||||
A C expression that is 1 if the RTX X is a constant which is a
|
||||
valid address. On most machines, this can be defined as
|
||||
`CONSTANT_P (X)', but a few machines are more restrictive in which
|
||||
constant addresses are supported.
|
||||
|
||||
`CONSTANT_P' accepts integer-values expressions whose values are
|
||||
not explicitly known, such as `symbol_ref', `label_ref', and
|
||||
`high' expressions and `const' arithmetic expressions, in addition
|
||||
to `const_int' and `const_double' expressions.
|
||||
|
||||
`MAX_REGS_PER_ADDRESS'
|
||||
A number, the maximum number of registers that can appear in a
|
||||
valid memory address. Note that it is up to you to specify a
|
||||
value equal to the maximum number that `GO_IF_LEGITIMATE_ADDRESS'
|
||||
would ever accept.
|
||||
|
||||
`GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)'
|
||||
A C compound statement with a conditional `goto LABEL;' executed
|
||||
if X (an RTX) is a legitimate memory address on the target machine
|
||||
for a memory operand of mode MODE.
|
||||
|
||||
It usually pays to define several simpler macros to serve as
|
||||
subroutines for this one. Otherwise it may be too complicated to
|
||||
understand.
|
||||
|
||||
This macro must exist in two variants: a strict variant and a
|
||||
non-strict one. The strict variant is used in the reload pass. It
|
||||
must be defined so that any pseudo-register that has not been
|
||||
allocated a hard register is considered a memory reference. In
|
||||
contexts where some kind of register is required, a pseudo-register
|
||||
with no hard register must be rejected.
|
||||
|
||||
The non-strict variant is used in other passes. It must be
|
||||
defined to accept all pseudo-registers in every context where some
|
||||
kind of register is required.
|
||||
|
||||
Compiler source files that want to use the strict variant of this
|
||||
macro define the macro `REG_OK_STRICT'. You should use an `#ifdef
|
||||
REG_OK_STRICT' conditional to define the strict variant in that
|
||||
case and the non-strict variant otherwise.
|
||||
|
||||
Subroutines to check for acceptable registers for various purposes
|
||||
(one for base registers, one for index registers, and so on) are
|
||||
typically among the subroutines used to define
|
||||
`GO_IF_LEGITIMATE_ADDRESS'. Then only these subroutine macros
|
||||
need have two variants; the higher levels of macros may be the
|
||||
same whether strict or not.
|
||||
|
||||
Normally, constant addresses which are the sum of a `symbol_ref'
|
||||
and an integer are stored inside a `const' RTX to mark them as
|
||||
constant. Therefore, there is no need to recognize such sums
|
||||
specifically as legitimate addresses. Normally you would simply
|
||||
recognize any `const' as legitimate.
|
||||
|
||||
Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant
|
||||
sums that are not marked with `const'. It assumes that a naked
|
||||
`plus' indicates indexing. If so, then you *must* reject such
|
||||
naked constant sums as illegitimate addresses, so that none of
|
||||
them will be given to `PRINT_OPERAND_ADDRESS'.
|
||||
|
||||
On some machines, whether a symbolic address is legitimate depends
|
||||
on the section that the address refers to. On these machines,
|
||||
define the macro `ENCODE_SECTION_INFO' to store the information
|
||||
into the `symbol_ref', and then check for it here. When you see a
|
||||
`const', you will have to look inside it to find the `symbol_ref'
|
||||
in order to determine the section. *Note Assembler Format::.
|
||||
|
||||
The best way to modify the name string is by adding text to the
|
||||
beginning, with suitable punctuation to prevent any ambiguity.
|
||||
Allocate the new name in `saveable_obstack'. You will have to
|
||||
modify `ASM_OUTPUT_LABELREF' to remove and decode the added text
|
||||
and output the name accordingly, and define `STRIP_NAME_ENCODING'
|
||||
to access the original name string.
|
||||
|
||||
You can check the information stored here into the `symbol_ref' in
|
||||
the definitions of the macros `GO_IF_LEGITIMATE_ADDRESS' and
|
||||
`PRINT_OPERAND_ADDRESS'.
|
||||
|
||||
`REG_OK_FOR_BASE_P (X)'
|
||||
A C expression that is nonzero if X (assumed to be a `reg' RTX) is
|
||||
valid for use as a base register. For hard registers, it should
|
||||
always accept those which the hardware permits and reject the
|
||||
others. Whether the macro accepts or rejects pseudo registers
|
||||
must be controlled by `REG_OK_STRICT' as described above. This
|
||||
usually requires two variant definitions, of which `REG_OK_STRICT'
|
||||
controls the one actually used.
|
||||
|
||||
`REG_MODE_OK_FOR_BASE_P (X, MODE)'
|
||||
A C expression that is just like `REG_OK_FOR_BASE_P', except that
|
||||
that expression may examine the mode of the memory reference in
|
||||
MODE. You should define this macro if the mode of the memory
|
||||
reference affects whether a register may be used as a base
|
||||
register. If you define this macro, the compiler will use it
|
||||
instead of `REG_OK_FOR_BASE_P'.
|
||||
|
||||
`REG_OK_FOR_INDEX_P (X)'
|
||||
A C expression that is nonzero if X (assumed to be a `reg' RTX) is
|
||||
valid for use as an index register.
|
||||
|
||||
The difference between an index register and a base register is
|
||||
that the index register may be scaled. If an address involves the
|
||||
sum of two registers, neither one of them scaled, then either one
|
||||
may be labeled the "base" and the other the "index"; but whichever
|
||||
labeling is used must fit the machine's constraints of which
|
||||
registers may serve in each capacity. The compiler will try both
|
||||
labelings, looking for one that is valid, and will reload one or
|
||||
both registers only if neither labeling works.
|
||||
|
||||
`LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)'
|
||||
A C compound statement that attempts to replace X with a valid
|
||||
memory address for an operand of mode MODE. WIN will be a C
|
||||
statement label elsewhere in the code; the macro definition may use
|
||||
|
||||
GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN);
|
||||
|
||||
to avoid further processing if the address has become legitimate.
|
||||
|
||||
X will always be the result of a call to `break_out_memory_refs',
|
||||
and OLDX will be the operand that was given to that function to
|
||||
produce X.
|
||||
|
||||
The code generated by this macro should not alter the substructure
|
||||
of X. If it transforms X into a more legitimate form, it should
|
||||
assign X (which will always be a C variable) a new value.
|
||||
|
||||
It is not necessary for this macro to come up with a legitimate
|
||||
address. The compiler has standard ways of doing so in all cases.
|
||||
In fact, it is safe for this macro to do nothing. But often a
|
||||
machine-dependent strategy can generate better code.
|
||||
|
||||
`LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS, WIN)'
|
||||
A C compound statement that attempts to replace X, which is an
|
||||
address that needs reloading, with a valid memory address for an
|
||||
operand of mode MODE. WIN will be a C statement label elsewhere
|
||||
in the code. It is not necessary to define this macro, but it
|
||||
might be useful for performance reasons.
|
||||
|
||||
For example, on the i386, it is sometimes possible to use a single
|
||||
reload register instead of two by reloading a sum of two pseudo
|
||||
registers into a register. On the other hand, for number of RISC
|
||||
processors offsets are limited so that often an intermediate
|
||||
address needs to be generated in order to address a stack slot.
|
||||
By defining LEGITIMIZE_RELOAD_ADDRESS appropriately, the
|
||||
intermediate addresses generated for adjacent some stack slots can
|
||||
be made identical, and thus be shared.
|
||||
|
||||
*Note*: This macro should be used with caution. It is necessary
|
||||
to know something of how reload works in order to effectively use
|
||||
this, and it is quite easy to produce macros that build in too
|
||||
much knowledge of reload internals.
|
||||
|
||||
*Note*: This macro must be able to reload an address created by a
|
||||
previous invocation of this macro. If it fails to handle such
|
||||
addresses then the compiler may generate incorrect code or abort.
|
||||
|
||||
The macro definition should use `push_reload' to indicate parts
|
||||
that need reloading; OPNUM, TYPE and IND_LEVELS are usually
|
||||
suitable to be passed unaltered to `push_reload'.
|
||||
|
||||
The code generated by this macro must not alter the substructure of
|
||||
X. If it transforms X into a more legitimate form, it should
|
||||
assign X (which will always be a C variable) a new value. This
|
||||
also applies to parts that you change indirectly by calling
|
||||
`push_reload'.
|
||||
|
||||
The macro definition may use `strict_memory_address_p' to test if
|
||||
the address has become legitimate.
|
||||
|
||||
If you want to change only a part of X, one standard way of doing
|
||||
this is to use `copy_rtx'. Note, however, that is unshares only a
|
||||
single level of rtl. Thus, if the part to be changed is not at the
|
||||
top level, you'll need to replace first the top leve It is not
|
||||
necessary for this macro to come up with a legitimate address;
|
||||
but often a machine-dependent strategy can generate better code.
|
||||
|
||||
`GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)'
|
||||
A C statement or compound statement with a conditional `goto
|
||||
LABEL;' executed if memory address X (an RTX) can have different
|
||||
meanings depending on the machine mode of the memory reference it
|
||||
is used for or if the address is valid for some modes but not
|
||||
others.
|
||||
|
||||
Autoincrement and autodecrement addresses typically have
|
||||
mode-dependent effects because the amount of the increment or
|
||||
decrement is the size of the operand being addressed. Some
|
||||
machines have other mode-dependent addresses. Many RISC machines
|
||||
have no mode-dependent addresses.
|
||||
|
||||
You may assume that ADDR is a valid address for the machine.
|
||||
|
||||
`LEGITIMATE_CONSTANT_P (X)'
|
||||
A C expression that is nonzero if X is a legitimate constant for
|
||||
an immediate operand on the target machine. You can assume that X
|
||||
satisfies `CONSTANT_P', so you need not check this. In fact, `1'
|
||||
is a suitable definition for this macro on machines where anything
|
||||
`CONSTANT_P' is valid.
|
||||
|
||||
|
||||
File: gcc.info, Node: Condition Code, Next: Costs, Prev: Addressing Modes, Up: Target Macros
|
||||
|
||||
Condition Code Status
|
||||
=====================
|
||||
|
||||
This describes the condition code status.
|
||||
|
||||
The file `conditions.h' defines a variable `cc_status' to describe
|
||||
how the condition code was computed (in case the interpretation of the
|
||||
condition code depends on the instruction that it was set by). This
|
||||
variable contains the RTL expressions on which the condition code is
|
||||
currently based, and several standard flags.
|
||||
|
||||
Sometimes additional machine-specific flags must be defined in the
|
||||
machine description header file. It can also add additional
|
||||
machine-specific information by defining `CC_STATUS_MDEP'.
|
||||
|
||||
`CC_STATUS_MDEP'
|
||||
C code for a data type which is used for declaring the `mdep'
|
||||
component of `cc_status'. It defaults to `int'.
|
||||
|
||||
This macro is not used on machines that do not use `cc0'.
|
||||
|
||||
`CC_STATUS_MDEP_INIT'
|
||||
A C expression to initialize the `mdep' field to "empty". The
|
||||
default definition does nothing, since most machines don't use the
|
||||
field anyway. If you want to use the field, you should probably
|
||||
define this macro to initialize it.
|
||||
|
||||
This macro is not used on machines that do not use `cc0'.
|
||||
|
||||
`NOTICE_UPDATE_CC (EXP, INSN)'
|
||||
A C compound statement to set the components of `cc_status'
|
||||
appropriately for an insn INSN whose body is EXP. It is this
|
||||
macro's responsibility to recognize insns that set the condition
|
||||
code as a byproduct of other activity as well as those that
|
||||
explicitly set `(cc0)'.
|
||||
|
||||
This macro is not used on machines that do not use `cc0'.
|
||||
|
||||
If there are insns that do not set the condition code but do alter
|
||||
other machine registers, this macro must check to see whether they
|
||||
invalidate the expressions that the condition code is recorded as
|
||||
reflecting. For example, on the 68000, insns that store in address
|
||||
registers do not set the condition code, which means that usually
|
||||
`NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns.
|
||||
But suppose that the previous insn set the condition code based
|
||||
on location `a4@(102)' and the current insn stores a new value in
|
||||
`a4'. Although the condition code is not changed by this, it will
|
||||
no longer be true that it reflects the contents of `a4@(102)'.
|
||||
Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case
|
||||
to say that nothing is known about the condition code value.
|
||||
|
||||
The definition of `NOTICE_UPDATE_CC' must be prepared to deal with
|
||||
the results of peephole optimization: insns whose patterns are
|
||||
`parallel' RTXs containing various `reg', `mem' or constants which
|
||||
are just the operands. The RTL structure of these insns is not
|
||||
sufficient to indicate what the insns actually do. What
|
||||
`NOTICE_UPDATE_CC' should do when it sees one is just to run
|
||||
`CC_STATUS_INIT'.
|
||||
|
||||
A possible definition of `NOTICE_UPDATE_CC' is to call a function
|
||||
that looks at an attribute (*note Insn Attributes::.) named, for
|
||||
example, `cc'. This avoids having detailed information about
|
||||
patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'.
|
||||
|
||||
`EXTRA_CC_MODES'
|
||||
A list of names to be used for additional modes for condition code
|
||||
values in registers (*note Jump Patterns::.). These names are
|
||||
added to `enum machine_mode' and all have class `MODE_CC'. By
|
||||
convention, they should start with `CC' and end with `mode'.
|
||||
|
||||
You should only define this macro if your machine does not use
|
||||
`cc0' and only if additional modes are required.
|
||||
|
||||
`EXTRA_CC_NAMES'
|
||||
A list of C strings giving the names for the modes listed in
|
||||
`EXTRA_CC_MODES'. For example, the Sparc defines this macro and
|
||||
`EXTRA_CC_MODES' as
|
||||
|
||||
#define EXTRA_CC_MODES CC_NOOVmode, CCFPmode, CCFPEmode
|
||||
#define EXTRA_CC_NAMES "CC_NOOV", "CCFP", "CCFPE"
|
||||
|
||||
This macro is not required if `EXTRA_CC_MODES' is not defined.
|
||||
|
||||
`SELECT_CC_MODE (OP, X, Y)'
|
||||
Returns a mode from class `MODE_CC' to be used when comparison
|
||||
operation code OP is applied to rtx X and Y. For example, on the
|
||||
Sparc, `SELECT_CC_MODE' is defined as (see *note Jump Patterns::.
|
||||
for a description of the reason for this definition)
|
||||
|
||||
#define SELECT_CC_MODE(OP,X,Y) \
|
||||
(GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \
|
||||
? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode) \
|
||||
: ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \
|
||||
|| GET_CODE (X) == NEG) \
|
||||
? CC_NOOVmode : CCmode))
|
||||
|
||||
You need not define this macro if `EXTRA_CC_MODES' is not defined.
|
||||
|
||||
`CANONICALIZE_COMPARISON (CODE, OP0, OP1)'
|
||||
One some machines not all possible comparisons are defined, but
|
||||
you can convert an invalid comparison into a valid one. For
|
||||
example, the Alpha does not have a `GT' comparison, but you can
|
||||
use an `LT' comparison instead and swap the order of the operands.
|
||||
|
||||
On such machines, define this macro to be a C statement to do any
|
||||
required conversions. CODE is the initial comparison code and OP0
|
||||
and OP1 are the left and right operands of the comparison,
|
||||
respectively. You should modify CODE, OP0, and OP1 as required.
|
||||
|
||||
GNU CC will not assume that the comparison resulting from this
|
||||
macro is valid but will see if the resulting insn matches a
|
||||
pattern in the `md' file.
|
||||
|
||||
You need not define this macro if it would never change the
|
||||
comparison code or operands.
|
||||
|
||||
`REVERSIBLE_CC_MODE (MODE)'
|
||||
A C expression whose value is one if it is always safe to reverse a
|
||||
comparison whose mode is MODE. If `SELECT_CC_MODE' can ever
|
||||
return MODE for a floating-point inequality comparison, then
|
||||
`REVERSIBLE_CC_MODE (MODE)' must be zero.
|
||||
|
||||
You need not define this macro if it would always returns zero or
|
||||
if the floating-point format is anything other than
|
||||
`IEEE_FLOAT_FORMAT'. For example, here is the definition used on
|
||||
the Sparc, where floating-point inequality comparisons are always
|
||||
given `CCFPEmode':
|
||||
|
||||
#define REVERSIBLE_CC_MODE(MODE) ((MODE) != CCFPEmode)
|
||||
|
||||
|
||||
File: gcc.info, Node: Costs, Next: Sections, Prev: Condition Code, Up: Target Macros
|
||||
|
||||
Describing Relative Costs of Operations
|
||||
=======================================
|
||||
|
||||
These macros let you describe the relative speed of various
|
||||
operations on the target machine.
|
||||
|
||||
`CONST_COSTS (X, CODE, OUTER_CODE)'
|
||||
A part of a C `switch' statement that describes the relative costs
|
||||
of constant RTL expressions. It must contain `case' labels for
|
||||
expression codes `const_int', `const', `symbol_ref', `label_ref'
|
||||
and `const_double'. Each case must ultimately reach a `return'
|
||||
statement to return the relative cost of the use of that kind of
|
||||
constant value in an expression. The cost may depend on the
|
||||
precise value of the constant, which is available for examination
|
||||
in X, and the rtx code of the expression in which it is contained,
|
||||
found in OUTER_CODE.
|
||||
|
||||
CODE is the expression code--redundant, since it can be obtained
|
||||
with `GET_CODE (X)'.
|
||||
|
||||
`RTX_COSTS (X, CODE, OUTER_CODE)'
|
||||
Like `CONST_COSTS' but applies to nonconstant RTL expressions.
|
||||
This can be used, for example, to indicate how costly a multiply
|
||||
instruction is. In writing this macro, you can use the construct
|
||||
`COSTS_N_INSNS (N)' to specify a cost equal to N fast
|
||||
instructions. OUTER_CODE is the code of the expression in which X
|
||||
is contained.
|
||||
|
||||
This macro is optional; do not define it if the default cost
|
||||
assumptions are adequate for the target machine.
|
||||
|
||||
`DEFAULT_RTX_COSTS (X, CODE, OUTER_CODE)'
|
||||
This macro, if defined, is called for any case not handled by the
|
||||
`RTX_COSTS' or `CONST_COSTS' macros. This eliminates the need to
|
||||
put case labels into the macro, but the code, or any functions it
|
||||
calls, must assume that the RTL in X could be of any type that has
|
||||
not already been handled. The arguments are the same as for
|
||||
`RTX_COSTS', and the macro should execute a return statement giving
|
||||
the cost of any RTL expressions that it can handle. The default
|
||||
cost calculation is used for any RTL for which this macro does not
|
||||
return a value.
|
||||
|
||||
This macro is optional; do not define it if the default cost
|
||||
assumptions are adequate for the target machine.
|
||||
|
||||
`ADDRESS_COST (ADDRESS)'
|
||||
An expression giving the cost of an addressing mode that contains
|
||||
ADDRESS. If not defined, the cost is computed from the ADDRESS
|
||||
expression and the `CONST_COSTS' values.
|
||||
|
||||
For most CISC machines, the default cost is a good approximation
|
||||
of the true cost of the addressing mode. However, on RISC
|
||||
machines, all instructions normally have the same length and
|
||||
execution time. Hence all addresses will have equal costs.
|
||||
|
||||
In cases where more than one form of an address is known, the form
|
||||
with the lowest cost will be used. If multiple forms have the
|
||||
same, lowest, cost, the one that is the most complex will be used.
|
||||
|
||||
For example, suppose an address that is equal to the sum of a
|
||||
register and a constant is used twice in the same basic block.
|
||||
When this macro is not defined, the address will be computed in a
|
||||
register and memory references will be indirect through that
|
||||
register. On machines where the cost of the addressing mode
|
||||
containing the sum is no higher than that of a simple indirect
|
||||
reference, this will produce an additional instruction and
|
||||
possibly require an additional register. Proper specification of
|
||||
this macro eliminates this overhead for such machines.
|
||||
|
||||
Similar use of this macro is made in strength reduction of loops.
|
||||
|
||||
ADDRESS need not be valid as an address. In such a case, the cost
|
||||
is not relevant and can be any value; invalid addresses need not be
|
||||
assigned a different cost.
|
||||
|
||||
On machines where an address involving more than one register is as
|
||||
cheap as an address computation involving only one register,
|
||||
defining `ADDRESS_COST' to reflect this can cause two registers to
|
||||
be live over a region of code where only one would have been if
|
||||
`ADDRESS_COST' were not defined in that manner. This effect should
|
||||
be considered in the definition of this macro. Equivalent costs
|
||||
should probably only be given to addresses with different numbers
|
||||
of registers on machines with lots of registers.
|
||||
|
||||
This macro will normally either not be defined or be defined as a
|
||||
constant.
|
||||
|
||||
`REGISTER_MOVE_COST (FROM, TO)'
|
||||
A C expression for the cost of moving data from a register in class
|
||||
FROM to one in class TO. The classes are expressed using the
|
||||
enumeration values such as `GENERAL_REGS'. A value of 2 is the
|
||||
default; other values are interpreted relative to that.
|
||||
|
||||
It is not required that the cost always equal 2 when FROM is the
|
||||
same as TO; on some machines it is expensive to move between
|
||||
registers if they are not general registers.
|
||||
|
||||
If reload sees an insn consisting of a single `set' between two
|
||||
hard registers, and if `REGISTER_MOVE_COST' applied to their
|
||||
classes returns a value of 2, reload does not check to ensure that
|
||||
the constraints of the insn are met. Setting a cost of other than
|
||||
2 will allow reload to verify that the constraints are met. You
|
||||
should do this if the `movM' pattern's constraints do not allow
|
||||
such copying.
|
||||
|
||||
`MEMORY_MOVE_COST (MODE, CLASS, IN)'
|
||||
A C expression for the cost of moving data of mode MODE between a
|
||||
register of class CLASS and memory; IN is zero if the value is to
|
||||
be written to memory, non-zero if it is to be read in. This cost
|
||||
is relative to those in `REGISTER_MOVE_COST'. If moving between
|
||||
registers and memory is more expensive than between two registers,
|
||||
you should define this macro to express the relative cost.
|
||||
|
||||
If you do not define this macro, GNU CC uses a default cost of 4
|
||||
plus the cost of copying via a secondary reload register, if one is
|
||||
needed. If your machine requires a secondary reload register to
|
||||
copy between memory and a register of CLASS but the reload
|
||||
mechanism is more complex than copying via an intermediate, define
|
||||
this macro to reflect the actual cost of the move.
|
||||
|
||||
GNU CC defines the function `memory_move_secondary_cost' if
|
||||
secondary reloads are needed. It computes the costs due to
|
||||
copying via a secondary register. If your machine copies from
|
||||
memory using a secondary register in the conventional way but the
|
||||
default base value of 4 is not correct for your machine, define
|
||||
this macro to add some other value to the result of that function.
|
||||
The arguments to that function are the same as to this macro.
|
||||
|
||||
`BRANCH_COST'
|
||||
A C expression for the cost of a branch instruction. A value of 1
|
||||
is the default; other values are interpreted relative to that.
|
||||
|
||||
Here are additional macros which do not specify precise relative
|
||||
costs, but only that certain actions are more expensive than GNU CC
|
||||
would ordinarily expect.
|
||||
|
||||
`SLOW_BYTE_ACCESS'
|
||||
Define this macro as a C expression which is nonzero if accessing
|
||||
less than a word of memory (i.e. a `char' or a `short') is no
|
||||
faster than accessing a word of memory, i.e., if such access
|
||||
require more than one instruction or if there is no difference in
|
||||
cost between byte and (aligned) word loads.
|
||||
|
||||
When this macro is not defined, the compiler will access a field by
|
||||
finding the smallest containing object; when it is defined, a
|
||||
fullword load will be used if alignment permits. Unless bytes
|
||||
accesses are faster than word accesses, using word accesses is
|
||||
preferable since it may eliminate subsequent memory access if
|
||||
subsequent accesses occur to other fields in the same word of the
|
||||
structure, but to different bytes.
|
||||
|
||||
`SLOW_ZERO_EXTEND'
|
||||
Define this macro if zero-extension (of a `char' or `short' to an
|
||||
`int') can be done faster if the destination is a register that is
|
||||
known to be zero.
|
||||
|
||||
If you define this macro, you must have instruction patterns that
|
||||
recognize RTL structures like this:
|
||||
|
||||
(set (strict_low_part (subreg:QI (reg:SI ...) 0)) ...)
|
||||
|
||||
and likewise for `HImode'.
|
||||
|
||||
`SLOW_UNALIGNED_ACCESS'
|
||||
Define this macro to be the value 1 if unaligned accesses have a
|
||||
cost many times greater than aligned accesses, for example if they
|
||||
are emulated in a trap handler.
|
||||
|
||||
When this macro is non-zero, the compiler will act as if
|
||||
`STRICT_ALIGNMENT' were non-zero when generating code for block
|
||||
moves. This can cause significantly more instructions to be
|
||||
produced. Therefore, do not set this macro non-zero if unaligned
|
||||
accesses only add a cycle or two to the time for a memory access.
|
||||
|
||||
If the value of this macro is always zero, it need not be defined.
|
||||
|
||||
`DONT_REDUCE_ADDR'
|
||||
Define this macro to inhibit strength reduction of memory
|
||||
addresses. (On some machines, such strength reduction seems to do
|
||||
harm rather than good.)
|
||||
|
||||
`MOVE_RATIO'
|
||||
The threshold of number of scalar memory-to-memory move insns,
|
||||
*below* which a sequence of insns should be generated instead of a
|
||||
string move insn or a library call. Increasing the value will
|
||||
always make code faster, but eventually incurs high cost in
|
||||
increased code size.
|
||||
|
||||
Note that on machines with no memory-to-memory move insns, this
|
||||
macro denotes the corresponding number of memory-to-memory
|
||||
*sequences*.
|
||||
|
||||
If you don't define this, a reasonable default is used.
|
||||
|
||||
`MOVE_BY_PIECES_P (SIZE, ALIGNMENT)'
|
||||
A C expression used to determine whether `move_by_pieces' will be
|
||||
used to copy a chunk of memory, or whether some other block move
|
||||
mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns'
|
||||
returns less than `MOVE_RATIO'.
|
||||
|
||||
`MOVE_MAX_PIECES'
|
||||
A C expression used by `move_by_pieces' to determine the largest
|
||||
unit a load or store used to copy memory is. Defaults to
|
||||
`MOVE_MAX'.
|
||||
|
||||
`USE_LOAD_POST_INCREMENT (MODE)'
|
||||
A C expression used to determine whether a load postincrement is a
|
||||
good thing to use for a given mode. Defaults to the value of
|
||||
`HAVE_POST_INCREMENT'.
|
||||
|
||||
`USE_LOAD_POST_DECREMENT (MODE)'
|
||||
A C expression used to determine whether a load postdecrement is a
|
||||
good thing to use for a given mode. Defaults to the value of
|
||||
`HAVE_POST_DECREMENT'.
|
||||
|
||||
`USE_LOAD_PRE_INCREMENT (MODE)'
|
||||
A C expression used to determine whether a load preincrement is a
|
||||
good thing to use for a given mode. Defaults to the value of
|
||||
`HAVE_PRE_INCREMENT'.
|
||||
|
||||
`USE_LOAD_PRE_DECREMENT (MODE)'
|
||||
A C expression used to determine whether a load predecrement is a
|
||||
good thing to use for a given mode. Defaults to the value of
|
||||
`HAVE_PRE_DECREMENT'.
|
||||
|
||||
`USE_STORE_POST_INCREMENT (MODE)'
|
||||
A C expression used to determine whether a store postincrement is
|
||||
a good thing to use for a given mode. Defaults to the value of
|
||||
`HAVE_POST_INCREMENT'.
|
||||
|
||||
`USE_STORE_POST_DECREMENT (MODE)'
|
||||
A C expression used to determine whether a store postdeccrement is
|
||||
a good thing to use for a given mode. Defaults to the value of
|
||||
`HAVE_POST_DECREMENT'.
|
||||
|
||||
`USE_STORE_PRE_INCREMENT (MODE)'
|
||||
This macro is used to determine whether a store preincrement is a
|
||||
good thing to use for a given mode. Defaults to the value of
|
||||
`HAVE_PRE_INCREMENT'.
|
||||
|
||||
`USE_STORE_PRE_DECREMENT (MODE)'
|
||||
This macro is used to determine whether a store predecrement is a
|
||||
good thing to use for a given mode. Defaults to the value of
|
||||
`HAVE_PRE_DECREMENT'.
|
||||
|
||||
`NO_FUNCTION_CSE'
|
||||
Define this macro if it is as good or better to call a constant
|
||||
function address than to call an address kept in a register.
|
||||
|
||||
`NO_RECURSIVE_FUNCTION_CSE'
|
||||
Define this macro if it is as good or better for a function to call
|
||||
itself with an explicit address than to call an address kept in a
|
||||
register.
|
||||
|
||||
`ADJUST_COST (INSN, LINK, DEP_INSN, COST)'
|
||||
A C statement (sans semicolon) to update the integer variable COST
|
||||
based on the relationship between INSN that is dependent on
|
||||
DEP_INSN through the dependence LINK. The default is to make no
|
||||
adjustment to COST. This can be used for example to specify to
|
||||
the scheduler that an output- or anti-dependence does not incur
|
||||
the same cost as a data-dependence.
|
||||
|
||||
`ADJUST_PRIORITY (INSN)'
|
||||
A C statement (sans semicolon) to update the integer scheduling
|
||||
priority `INSN_PRIORITY(INSN)'. Reduce the priority to execute
|
||||
the INSN earlier, increase the priority to execute INSN later.
|
||||
Do not define this macro if you do not need to adjust the
|
||||
scheduling priorities of insns.
|
||||
|
||||
Executable
+1107
File diff suppressed because it is too large
Load Diff
Executable
+946
@@ -0,0 +1,946 @@
|
||||
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
|
||||
input file ../../gcc-2.95.2/gcc/gcc.texi.
|
||||
|
||||
INFO-DIR-SECTION Programming
|
||||
START-INFO-DIR-ENTRY
|
||||
* gcc: (gcc). The GNU Compiler Collection.
|
||||
END-INFO-DIR-ENTRY
|
||||
This file documents the use and the internals of the GNU compiler.
|
||||
|
||||
Published by the Free Software Foundation 59 Temple Place - Suite 330
|
||||
Boston, MA 02111-1307 USA
|
||||
|
||||
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
|
||||
1999 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 "Funding
|
||||
for Free Software" 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 one.
|
||||
|
||||
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 "Funding for Free Software", 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: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format
|
||||
|
||||
Output of Assembler Instructions
|
||||
--------------------------------
|
||||
|
||||
This describes assembler instruction output.
|
||||
|
||||
`REGISTER_NAMES'
|
||||
A C initializer containing the assembler's names for the machine
|
||||
registers, each one as a C string constant. This is what
|
||||
translates register numbers in the compiler into assembler
|
||||
language.
|
||||
|
||||
`ADDITIONAL_REGISTER_NAMES'
|
||||
If defined, a C initializer for an array of structures containing
|
||||
a name and a register number. This macro defines additional names
|
||||
for hard registers, thus allowing the `asm' option in declarations
|
||||
to refer to registers using alternate names.
|
||||
|
||||
`ASM_OUTPUT_OPCODE (STREAM, PTR)'
|
||||
Define this macro if you are using an unusual assembler that
|
||||
requires different names for the machine instructions.
|
||||
|
||||
The definition is a C statement or statements which output an
|
||||
assembler instruction opcode to the stdio stream STREAM. The
|
||||
macro-operand PTR is a variable of type `char *' which points to
|
||||
the opcode name in its "internal" form--the form that is written
|
||||
in the machine description. The definition should output the
|
||||
opcode name to STREAM, performing any translation you desire, and
|
||||
increment the variable PTR to point at the end of the opcode so
|
||||
that it will not be output twice.
|
||||
|
||||
In fact, your macro definition may process less than the entire
|
||||
opcode name, or more than the opcode name; but if you want to
|
||||
process text that includes `%'-sequences to substitute operands,
|
||||
you must take care of the substitution yourself. Just be sure to
|
||||
increment PTR over whatever text should not be output normally.
|
||||
|
||||
If you need to look at the operand values, they can be found as the
|
||||
elements of `recog_operand'.
|
||||
|
||||
If the macro definition does nothing, the instruction is output in
|
||||
the usual way.
|
||||
|
||||
`FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS)'
|
||||
If defined, a C statement to be executed just prior to the output
|
||||
of assembler code for INSN, to modify the extracted operands so
|
||||
they will be output differently.
|
||||
|
||||
Here the argument OPVEC is the vector containing the operands
|
||||
extracted from INSN, and NOPERANDS is the number of elements of
|
||||
the vector which contain meaningful data for this insn. The
|
||||
contents of this vector are what will be used to convert the insn
|
||||
template into assembler code, so you can change the assembler
|
||||
output by changing the contents of the vector.
|
||||
|
||||
This macro is useful when various assembler syntaxes share a single
|
||||
file of instruction patterns; by defining this macro differently,
|
||||
you can cause a large class of instructions to be output
|
||||
differently (such as with rearranged operands). Naturally,
|
||||
variations in assembler syntax affecting individual insn patterns
|
||||
ought to be handled by writing conditional output routines in
|
||||
those patterns.
|
||||
|
||||
If this macro is not defined, it is equivalent to a null statement.
|
||||
|
||||
`FINAL_PRESCAN_LABEL'
|
||||
If defined, `FINAL_PRESCAN_INSN' will be called on each
|
||||
`CODE_LABEL'. In that case, OPVEC will be a null pointer and
|
||||
NOPERANDS will be zero.
|
||||
|
||||
`PRINT_OPERAND (STREAM, X, CODE)'
|
||||
A C compound statement to output to stdio stream STREAM the
|
||||
assembler syntax for an instruction operand X. X is an RTL
|
||||
expression.
|
||||
|
||||
CODE is a value that can be used to specify one of several ways of
|
||||
printing the operand. It is used when identical operands must be
|
||||
printed differently depending on the context. CODE comes from the
|
||||
`%' specification that was used to request printing of the
|
||||
operand. If the specification was just `%DIGIT' then CODE is 0;
|
||||
if the specification was `%LTR DIGIT' then CODE is the ASCII code
|
||||
for LTR.
|
||||
|
||||
If X is a register, this macro should print the register's name.
|
||||
The names can be found in an array `reg_names' whose type is `char
|
||||
*[]'. `reg_names' is initialized from `REGISTER_NAMES'.
|
||||
|
||||
When the machine description has a specification `%PUNCT' (a `%'
|
||||
followed by a punctuation character), this macro is called with a
|
||||
null pointer for X and the punctuation character for CODE.
|
||||
|
||||
`PRINT_OPERAND_PUNCT_VALID_P (CODE)'
|
||||
A C expression which evaluates to true if CODE is a valid
|
||||
punctuation character for use in the `PRINT_OPERAND' macro. If
|
||||
`PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no
|
||||
punctuation characters (except for the standard one, `%') are used
|
||||
in this way.
|
||||
|
||||
`PRINT_OPERAND_ADDRESS (STREAM, X)'
|
||||
A C compound statement to output to stdio stream STREAM the
|
||||
assembler syntax for an instruction operand that is a memory
|
||||
reference whose address is X. X is an RTL expression.
|
||||
|
||||
On some machines, the syntax for a symbolic address depends on the
|
||||
section that the address refers to. On these machines, define the
|
||||
macro `ENCODE_SECTION_INFO' to store the information into the
|
||||
`symbol_ref', and then check for it here. *Note Assembler
|
||||
Format::.
|
||||
|
||||
`DBR_OUTPUT_SEQEND(FILE)'
|
||||
A C statement, to be executed after all slot-filler instructions
|
||||
have been output. If necessary, call `dbr_sequence_length' to
|
||||
determine the number of slots filled in a sequence (zero if not
|
||||
currently outputting a sequence), to decide how many no-ops to
|
||||
output, or whatever.
|
||||
|
||||
Don't define this macro if it has nothing to do, but it is helpful
|
||||
in reading assembly output if the extent of the delay sequence is
|
||||
made explicit (e.g. with white space).
|
||||
|
||||
Note that output routines for instructions with delay slots must be
|
||||
prepared to deal with not being output as part of a sequence (i.e.
|
||||
when the scheduling pass is not run, or when no slot fillers could
|
||||
be found.) The variable `final_sequence' is null when not
|
||||
processing a sequence, otherwise it contains the `sequence' rtx
|
||||
being output.
|
||||
|
||||
`REGISTER_PREFIX'
|
||||
`LOCAL_LABEL_PREFIX'
|
||||
`USER_LABEL_PREFIX'
|
||||
`IMMEDIATE_PREFIX'
|
||||
If defined, C string expressions to be used for the `%R', `%L',
|
||||
`%U', and `%I' options of `asm_fprintf' (see `final.c'). These
|
||||
are useful when a single `md' file must support multiple assembler
|
||||
formats. In that case, the various `tm.h' files can define these
|
||||
macros differently.
|
||||
|
||||
`ASSEMBLER_DIALECT'
|
||||
If your target supports multiple dialects of assembler language
|
||||
(such as different opcodes), define this macro as a C expression
|
||||
that gives the numeric index of the assembler language dialect to
|
||||
use, with zero as the first variant.
|
||||
|
||||
If this macro is defined, you may use constructs of the form
|
||||
`{option0|option1|option2...}' in the output templates of patterns
|
||||
(*note Output Template::.) or in the first argument of
|
||||
`asm_fprintf'. This construct outputs `option0', `option1' or
|
||||
`option2', etc., if the value of `ASSEMBLER_DIALECT' is zero, one
|
||||
or two, etc. Any special characters within these strings retain
|
||||
their usual meaning.
|
||||
|
||||
If you do not define this macro, the characters `{', `|' and `}'
|
||||
do not have any special meaning when used in templates or operands
|
||||
to `asm_fprintf'.
|
||||
|
||||
Define the macros `REGISTER_PREFIX', `LOCAL_LABEL_PREFIX',
|
||||
`USER_LABEL_PREFIX' and `IMMEDIATE_PREFIX' if you can express the
|
||||
variations in assembler language syntax with that mechanism.
|
||||
Define `ASSEMBLER_DIALECT' and use the `{option0|option1}' syntax
|
||||
if the syntax variant are larger and involve such things as
|
||||
different opcodes or operand order.
|
||||
|
||||
`ASM_OUTPUT_REG_PUSH (STREAM, REGNO)'
|
||||
A C expression to output to STREAM some assembler code which will
|
||||
push hard register number REGNO onto the stack. The code need not
|
||||
be optimal, since this macro is used only when profiling.
|
||||
|
||||
`ASM_OUTPUT_REG_POP (STREAM, REGNO)'
|
||||
A C expression to output to STREAM some assembler code which will
|
||||
pop hard register number REGNO off of the stack. The code need
|
||||
not be optimal, since this macro is used only when profiling.
|
||||
|
||||
|
||||
File: gcc.info, Node: Dispatch Tables, Next: Exception Region Output, Prev: Instruction Output, Up: Assembler Format
|
||||
|
||||
Output of Dispatch Tables
|
||||
-------------------------
|
||||
|
||||
This concerns dispatch tables.
|
||||
|
||||
`ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL)'
|
||||
A C statement to output to the stdio stream STREAM an assembler
|
||||
pseudo-instruction to generate a difference between two labels.
|
||||
VALUE and REL are the numbers of two internal labels. The
|
||||
definitions of these labels are output using
|
||||
`ASM_OUTPUT_INTERNAL_LABEL', and they must be printed in the same
|
||||
way here. For example,
|
||||
|
||||
fprintf (STREAM, "\t.word L%d-L%d\n",
|
||||
VALUE, REL)
|
||||
|
||||
You must provide this macro on machines where the addresses in a
|
||||
dispatch table are relative to the table's own address. If
|
||||
defined, GNU CC will also use this macro on all machines when
|
||||
producing PIC. BODY is the body of the ADDR_DIFF_VEC; it is
|
||||
provided so that the mode and flags can be read.
|
||||
|
||||
`ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE)'
|
||||
This macro should be provided on machines where the addresses in a
|
||||
dispatch table are absolute.
|
||||
|
||||
The definition should be a C statement to output to the stdio
|
||||
stream STREAM an assembler pseudo-instruction to generate a
|
||||
reference to a label. VALUE is the number of an internal label
|
||||
whose definition is output using `ASM_OUTPUT_INTERNAL_LABEL'. For
|
||||
example,
|
||||
|
||||
fprintf (STREAM, "\t.word L%d\n", VALUE)
|
||||
|
||||
`ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE)'
|
||||
Define this if the label before a jump-table needs to be output
|
||||
specially. The first three arguments are the same as for
|
||||
`ASM_OUTPUT_INTERNAL_LABEL'; the fourth argument is the jump-table
|
||||
which follows (a `jump_insn' containing an `addr_vec' or
|
||||
`addr_diff_vec').
|
||||
|
||||
This feature is used on system V to output a `swbeg' statement for
|
||||
the table.
|
||||
|
||||
If this macro is not defined, these labels are output with
|
||||
`ASM_OUTPUT_INTERNAL_LABEL'.
|
||||
|
||||
`ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE)'
|
||||
Define this if something special must be output at the end of a
|
||||
jump-table. The definition should be a C statement to be executed
|
||||
after the assembler code for the table is written. It should write
|
||||
the appropriate code to stdio stream STREAM. The argument TABLE
|
||||
is the jump-table insn, and NUM is the label-number of the
|
||||
preceding label.
|
||||
|
||||
If this macro is not defined, nothing special is output at the end
|
||||
of the jump-table.
|
||||
|
||||
|
||||
File: gcc.info, Node: Exception Region Output, Next: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format
|
||||
|
||||
Assembler Commands for Exception Regions
|
||||
----------------------------------------
|
||||
|
||||
This describes commands marking the start and the end of an exception
|
||||
region.
|
||||
|
||||
`ASM_OUTPUT_EH_REGION_BEG ()'
|
||||
A C expression to output text to mark the start of an exception
|
||||
region.
|
||||
|
||||
This macro need not be defined on most platforms.
|
||||
|
||||
`ASM_OUTPUT_EH_REGION_END ()'
|
||||
A C expression to output text to mark the end of an exception
|
||||
region.
|
||||
|
||||
This macro need not be defined on most platforms.
|
||||
|
||||
`EXCEPTION_SECTION ()'
|
||||
A C expression to switch to the section in which the main
|
||||
exception table is to be placed (*note Sections::.). The default
|
||||
is a section named `.gcc_except_table' on machines that support
|
||||
named sections via `ASM_OUTPUT_SECTION_NAME', otherwise if `-fpic'
|
||||
or `-fPIC' is in effect, the `data_section', otherwise the
|
||||
`readonly_data_section'.
|
||||
|
||||
`EH_FRAME_SECTION_ASM_OP'
|
||||
If defined, a C string constant for the assembler operation to
|
||||
switch to the section for exception handling frame unwind
|
||||
information. If not defined, GNU CC will provide a default
|
||||
definition if the target supports named sections. `crtstuff.c'
|
||||
uses this macro to switch to the appropriate section.
|
||||
|
||||
You should define this symbol if your target supports DWARF 2 frame
|
||||
unwind information and the default definition does not work.
|
||||
|
||||
`OMIT_EH_TABLE ()'
|
||||
A C expression that is nonzero if the normal exception table output
|
||||
should be omitted.
|
||||
|
||||
This macro need not be defined on most platforms.
|
||||
|
||||
`EH_TABLE_LOOKUP ()'
|
||||
Alternate runtime support for looking up an exception at runtime
|
||||
and finding the associated handler, if the default method won't
|
||||
work.
|
||||
|
||||
This macro need not be defined on most platforms.
|
||||
|
||||
`DOESNT_NEED_UNWINDER'
|
||||
A C expression that decides whether or not the current function
|
||||
needs to have a function unwinder generated for it. See the file
|
||||
`except.c' for details on when to define this, and how.
|
||||
|
||||
`MASK_RETURN_ADDR'
|
||||
An rtx used to mask the return address found via RETURN_ADDR_RTX,
|
||||
so that it does not contain any extraneous set bits in it.
|
||||
|
||||
`DWARF2_UNWIND_INFO'
|
||||
Define this macro to 0 if your target supports DWARF 2 frame unwind
|
||||
information, but it does not yet work with exception handling.
|
||||
Otherwise, if your target supports this information (if it defines
|
||||
`INCOMING_RETURN_ADDR_RTX' and either `UNALIGNED_INT_ASM_OP' or
|
||||
`OBJECT_FORMAT_ELF'), GCC will provide a default definition of 1.
|
||||
|
||||
If this macro is defined to 1, the DWARF 2 unwinder will be the
|
||||
default exception handling mechanism; otherwise, setjmp/longjmp
|
||||
will be used by default.
|
||||
|
||||
If this macro is defined to anything, the DWARF 2 unwinder will be
|
||||
used instead of inline unwinders and __unwind_function in the
|
||||
non-setjmp case.
|
||||
|
||||
|
||||
File: gcc.info, Node: Alignment Output, Prev: Exception Region Output, Up: Assembler Format
|
||||
|
||||
Assembler Commands for Alignment
|
||||
--------------------------------
|
||||
|
||||
This describes commands for alignment.
|
||||
|
||||
`LABEL_ALIGN_AFTER_BARRIER (LABEL)'
|
||||
The alignment (log base 2) to put in front of LABEL, which follows
|
||||
a BARRIER.
|
||||
|
||||
This macro need not be defined if you don't want any special
|
||||
alignment to be done at such a time. Most machine descriptions do
|
||||
not currently define the macro.
|
||||
|
||||
`LOOP_ALIGN (LABEL)'
|
||||
The alignment (log base 2) to put in front of LABEL, which follows
|
||||
a NOTE_INSN_LOOP_BEG note.
|
||||
|
||||
This macro need not be defined if you don't want any special
|
||||
alignment to be done at such a time. Most machine descriptions do
|
||||
not currently define the macro.
|
||||
|
||||
`LABEL_ALIGN (LABEL)'
|
||||
The alignment (log base 2) to put in front of LABEL. If
|
||||
LABEL_ALIGN_AFTER_BARRIER / LOOP_ALIGN specify a different
|
||||
alignment, the maximum of the specified values is used.
|
||||
|
||||
`ASM_OUTPUT_SKIP (STREAM, NBYTES)'
|
||||
A C statement to output to the stdio stream STREAM an assembler
|
||||
instruction to advance the location counter by NBYTES bytes.
|
||||
Those bytes should be zero when loaded. NBYTES will be a C
|
||||
expression of type `int'.
|
||||
|
||||
`ASM_NO_SKIP_IN_TEXT'
|
||||
Define this macro if `ASM_OUTPUT_SKIP' should not be used in the
|
||||
text section because it fails to put zeros in the bytes that are
|
||||
skipped. This is true on many Unix systems, where the pseudo-op
|
||||
to skip bytes produces no-op instructions rather than zeros when
|
||||
used in the text section.
|
||||
|
||||
`ASM_OUTPUT_ALIGN (STREAM, POWER)'
|
||||
A C statement to output to the stdio stream STREAM an assembler
|
||||
command to advance the location counter to a multiple of 2 to the
|
||||
POWER bytes. POWER will be a C expression of type `int'.
|
||||
|
||||
`ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP)'
|
||||
A C statement to output to the stdio stream STREAM an assembler
|
||||
command to advance the location counter to a multiple of 2 to the
|
||||
POWER bytes, but only if MAX_SKIP or fewer bytes are needed to
|
||||
satisfy the alignment request. POWER and MAX_SKIP will be a C
|
||||
expression of type `int'.
|
||||
|
||||
|
||||
File: gcc.info, Node: Debugging Info, Next: Cross-compilation, Prev: Assembler Format, Up: Target Macros
|
||||
|
||||
Controlling Debugging Information Format
|
||||
========================================
|
||||
|
||||
This describes how to specify debugging information.
|
||||
|
||||
* Menu:
|
||||
|
||||
* All Debuggers:: Macros that affect all debugging formats uniformly.
|
||||
* DBX Options:: Macros enabling specific options in DBX format.
|
||||
* DBX Hooks:: Hook macros for varying DBX format.
|
||||
* File Names and DBX:: Macros controlling output of file names in DBX format.
|
||||
* SDB and DWARF:: Macros for SDB (COFF) and DWARF formats.
|
||||
|
||||
|
||||
File: gcc.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info
|
||||
|
||||
Macros Affecting All Debugging Formats
|
||||
--------------------------------------
|
||||
|
||||
These macros affect all debugging formats.
|
||||
|
||||
`DBX_REGISTER_NUMBER (REGNO)'
|
||||
A C expression that returns the DBX register number for the
|
||||
compiler register number REGNO. In simple cases, the value of this
|
||||
expression may be REGNO itself. But sometimes there are some
|
||||
registers that the compiler knows about and DBX does not, or vice
|
||||
versa. In such cases, some register may need to have one number in
|
||||
the compiler and another for DBX.
|
||||
|
||||
If two registers have consecutive numbers inside GNU CC, and they
|
||||
can be used as a pair to hold a multiword value, then they *must*
|
||||
have consecutive numbers after renumbering with
|
||||
`DBX_REGISTER_NUMBER'. Otherwise, debuggers will be unable to
|
||||
access such a pair, because they expect register pairs to be
|
||||
consecutive in their own numbering scheme.
|
||||
|
||||
If you find yourself defining `DBX_REGISTER_NUMBER' in way that
|
||||
does not preserve register pairs, then what you must do instead is
|
||||
redefine the actual register numbering scheme.
|
||||
|
||||
`DEBUGGER_AUTO_OFFSET (X)'
|
||||
A C expression that returns the integer offset value for an
|
||||
automatic variable having address X (an RTL expression). The
|
||||
default computation assumes that X is based on the frame-pointer
|
||||
and gives the offset from the frame-pointer. This is required for
|
||||
targets that produce debugging output for DBX or COFF-style
|
||||
debugging output for SDB and allow the frame-pointer to be
|
||||
eliminated when the `-g' options is used.
|
||||
|
||||
`DEBUGGER_ARG_OFFSET (OFFSET, X)'
|
||||
A C expression that returns the integer offset value for an
|
||||
argument having address X (an RTL expression). The nominal offset
|
||||
is OFFSET.
|
||||
|
||||
`PREFERRED_DEBUGGING_TYPE'
|
||||
A C expression that returns the type of debugging output GNU CC
|
||||
should produce when the user specifies just `-g'. Define this if
|
||||
you have arranged for GNU CC to support more than one format of
|
||||
debugging output. Currently, the allowable values are `DBX_DEBUG',
|
||||
`SDB_DEBUG', `DWARF_DEBUG', `DWARF2_DEBUG', and `XCOFF_DEBUG'.
|
||||
|
||||
When the user specifies `-ggdb', GNU CC normally also uses the
|
||||
value of this macro to select the debugging output format, but
|
||||
with two exceptions. If `DWARF2_DEBUGGING_INFO' is defined and
|
||||
`LINKER_DOES_NOT_WORK_WITH_DWARF2' is not defined, GNU CC uses the
|
||||
value `DWARF2_DEBUG'. Otherwise, if `DBX_DEBUGGING_INFO' is
|
||||
defined, GNU CC uses `DBX_DEBUG'.
|
||||
|
||||
The value of this macro only affects the default debugging output;
|
||||
the user can always get a specific type of output by using
|
||||
`-gstabs', `-gcoff', `-gdwarf-1', `-gdwarf-2', or `-gxcoff'.
|
||||
|
||||
|
||||
File: gcc.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info
|
||||
|
||||
Specific Options for DBX Output
|
||||
-------------------------------
|
||||
|
||||
These are specific options for DBX output.
|
||||
|
||||
`DBX_DEBUGGING_INFO'
|
||||
Define this macro if GNU CC should produce debugging output for DBX
|
||||
in response to the `-g' option.
|
||||
|
||||
`XCOFF_DEBUGGING_INFO'
|
||||
Define this macro if GNU CC should produce XCOFF format debugging
|
||||
output in response to the `-g' option. This is a variant of DBX
|
||||
format.
|
||||
|
||||
`DEFAULT_GDB_EXTENSIONS'
|
||||
Define this macro to control whether GNU CC should by default
|
||||
generate GDB's extended version of DBX debugging information
|
||||
(assuming DBX-format debugging information is enabled at all). If
|
||||
you don't define the macro, the default is 1: always generate the
|
||||
extended information if there is any occasion to.
|
||||
|
||||
`DEBUG_SYMS_TEXT'
|
||||
Define this macro if all `.stabs' commands should be output while
|
||||
in the text section.
|
||||
|
||||
`ASM_STABS_OP'
|
||||
A C string constant naming the assembler pseudo op to use instead
|
||||
of `.stabs' to define an ordinary debugging symbol. If you don't
|
||||
define this macro, `.stabs' is used. This macro applies only to
|
||||
DBX debugging information format.
|
||||
|
||||
`ASM_STABD_OP'
|
||||
A C string constant naming the assembler pseudo op to use instead
|
||||
of `.stabd' to define a debugging symbol whose value is the current
|
||||
location. If you don't define this macro, `.stabd' is used. This
|
||||
macro applies only to DBX debugging information format.
|
||||
|
||||
`ASM_STABN_OP'
|
||||
A C string constant naming the assembler pseudo op to use instead
|
||||
of `.stabn' to define a debugging symbol with no name. If you
|
||||
don't define this macro, `.stabn' is used. This macro applies
|
||||
only to DBX debugging information format.
|
||||
|
||||
`DBX_NO_XREFS'
|
||||
Define this macro if DBX on your system does not support the
|
||||
construct `xsTAGNAME'. On some systems, this construct is used to
|
||||
describe a forward reference to a structure named TAGNAME. On
|
||||
other systems, this construct is not supported at all.
|
||||
|
||||
`DBX_CONTIN_LENGTH'
|
||||
A symbol name in DBX-format debugging information is normally
|
||||
continued (split into two separate `.stabs' directives) when it
|
||||
exceeds a certain length (by default, 80 characters). On some
|
||||
operating systems, DBX requires this splitting; on others,
|
||||
splitting must not be done. You can inhibit splitting by defining
|
||||
this macro with the value zero. You can override the default
|
||||
splitting-length by defining this macro as an expression for the
|
||||
length you desire.
|
||||
|
||||
`DBX_CONTIN_CHAR'
|
||||
Normally continuation is indicated by adding a `\' character to
|
||||
the end of a `.stabs' string when a continuation follows. To use
|
||||
a different character instead, define this macro as a character
|
||||
constant for the character you want to use. Do not define this
|
||||
macro if backslash is correct for your system.
|
||||
|
||||
`DBX_STATIC_STAB_DATA_SECTION'
|
||||
Define this macro if it is necessary to go to the data section
|
||||
before outputting the `.stabs' pseudo-op for a non-global static
|
||||
variable.
|
||||
|
||||
`DBX_TYPE_DECL_STABS_CODE'
|
||||
The value to use in the "code" field of the `.stabs' directive for
|
||||
a typedef. The default is `N_LSYM'.
|
||||
|
||||
`DBX_STATIC_CONST_VAR_CODE'
|
||||
The value to use in the "code" field of the `.stabs' directive for
|
||||
a static variable located in the text section. DBX format does not
|
||||
provide any "right" way to do this. The default is `N_FUN'.
|
||||
|
||||
`DBX_REGPARM_STABS_CODE'
|
||||
The value to use in the "code" field of the `.stabs' directive for
|
||||
a parameter passed in registers. DBX format does not provide any
|
||||
"right" way to do this. The default is `N_RSYM'.
|
||||
|
||||
`DBX_REGPARM_STABS_LETTER'
|
||||
The letter to use in DBX symbol data to identify a symbol as a
|
||||
parameter passed in registers. DBX format does not customarily
|
||||
provide any way to do this. The default is `'P''.
|
||||
|
||||
`DBX_MEMPARM_STABS_LETTER'
|
||||
The letter to use in DBX symbol data to identify a symbol as a
|
||||
stack parameter. The default is `'p''.
|
||||
|
||||
`DBX_FUNCTION_FIRST'
|
||||
Define this macro if the DBX information for a function and its
|
||||
arguments should precede the assembler code for the function.
|
||||
Normally, in DBX format, the debugging information entirely
|
||||
follows the assembler code.
|
||||
|
||||
`DBX_LBRAC_FIRST'
|
||||
Define this macro if the `N_LBRAC' symbol for a block should
|
||||
precede the debugging information for variables and functions
|
||||
defined in that block. Normally, in DBX format, the `N_LBRAC'
|
||||
symbol comes first.
|
||||
|
||||
`DBX_BLOCKS_FUNCTION_RELATIVE'
|
||||
Define this macro if the value of a symbol describing the scope of
|
||||
a block (`N_LBRAC' or `N_RBRAC') should be relative to the start
|
||||
of the enclosing function. Normally, GNU C uses an absolute
|
||||
address.
|
||||
|
||||
`DBX_USE_BINCL'
|
||||
Define this macro if GNU C should generate `N_BINCL' and `N_EINCL'
|
||||
stabs for included header files, as on Sun systems. This macro
|
||||
also directs GNU C to output a type number as a pair of a file
|
||||
number and a type number within the file. Normally, GNU C does not
|
||||
generate `N_BINCL' or `N_EINCL' stabs, and it outputs a single
|
||||
number for a type number.
|
||||
|
||||
|
||||
File: gcc.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info
|
||||
|
||||
Open-Ended Hooks for DBX Format
|
||||
-------------------------------
|
||||
|
||||
These are hooks for DBX format.
|
||||
|
||||
`DBX_OUTPUT_LBRAC (STREAM, NAME)'
|
||||
Define this macro to say how to output to STREAM the debugging
|
||||
information for the start of a scope level for variable names. The
|
||||
argument NAME is the name of an assembler symbol (for use with
|
||||
`assemble_name') whose value is the address where the scope begins.
|
||||
|
||||
`DBX_OUTPUT_RBRAC (STREAM, NAME)'
|
||||
Like `DBX_OUTPUT_LBRAC', but for the end of a scope level.
|
||||
|
||||
`DBX_OUTPUT_ENUM (STREAM, TYPE)'
|
||||
Define this macro if the target machine requires special handling
|
||||
to output an enumeration type. The definition should be a C
|
||||
statement (sans semicolon) to output the appropriate information
|
||||
to STREAM for the type TYPE.
|
||||
|
||||
`DBX_OUTPUT_FUNCTION_END (STREAM, FUNCTION)'
|
||||
Define this macro if the target machine requires special output at
|
||||
the end of the debugging information for a function. The
|
||||
definition should be a C statement (sans semicolon) to output the
|
||||
appropriate information to STREAM. FUNCTION is the
|
||||
`FUNCTION_DECL' node for the function.
|
||||
|
||||
`DBX_OUTPUT_STANDARD_TYPES (SYMS)'
|
||||
Define this macro if you need to control the order of output of the
|
||||
standard data types at the beginning of compilation. The argument
|
||||
SYMS is a `tree' which is a chain of all the predefined global
|
||||
symbols, including names of data types.
|
||||
|
||||
Normally, DBX output starts with definitions of the types for
|
||||
integers and characters, followed by all the other predefined
|
||||
types of the particular language in no particular order.
|
||||
|
||||
On some machines, it is necessary to output different particular
|
||||
types first. To do this, define `DBX_OUTPUT_STANDARD_TYPES' to
|
||||
output those symbols in the necessary order. Any predefined types
|
||||
that you don't explicitly output will be output afterward in no
|
||||
particular order.
|
||||
|
||||
Be careful not to define this macro so that it works only for C.
|
||||
There are no global variables to access most of the built-in
|
||||
types, because another language may have another set of types.
|
||||
The way to output a particular type is to look through SYMS to see
|
||||
if you can find it. Here is an example:
|
||||
|
||||
{
|
||||
tree decl;
|
||||
for (decl = syms; decl; decl = TREE_CHAIN (decl))
|
||||
if (!strcmp (IDENTIFIER_POINTER (DECL_NAME (decl)),
|
||||
"long int"))
|
||||
dbxout_symbol (decl);
|
||||
...
|
||||
}
|
||||
|
||||
This does nothing if the expected type does not exist.
|
||||
|
||||
See the function `init_decl_processing' in `c-decl.c' to find the
|
||||
names to use for all the built-in C types.
|
||||
|
||||
Here is another way of finding a particular type:
|
||||
|
||||
{
|
||||
tree decl;
|
||||
for (decl = syms; decl; decl = TREE_CHAIN (decl))
|
||||
if (TREE_CODE (decl) == TYPE_DECL
|
||||
&& (TREE_CODE (TREE_TYPE (decl))
|
||||
== INTEGER_CST)
|
||||
&& TYPE_PRECISION (TREE_TYPE (decl)) == 16
|
||||
&& TYPE_UNSIGNED (TREE_TYPE (decl)))
|
||||
/* This must be `unsigned short'. */
|
||||
dbxout_symbol (decl);
|
||||
...
|
||||
}
|
||||
|
||||
`NO_DBX_FUNCTION_END'
|
||||
Some stabs encapsulation formats (in particular ECOFF), cannot
|
||||
handle the `.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx
|
||||
extention construct. On those machines, define this macro to turn
|
||||
this feature off without disturbing the rest of the gdb extensions.
|
||||
|
||||
|
||||
File: gcc.info, Node: File Names and DBX, Next: SDB and DWARF, Prev: DBX Hooks, Up: Debugging Info
|
||||
|
||||
File Names in DBX Format
|
||||
------------------------
|
||||
|
||||
This describes file names in DBX format.
|
||||
|
||||
`DBX_WORKING_DIRECTORY'
|
||||
Define this if DBX wants to have the current directory recorded in
|
||||
each object file.
|
||||
|
||||
Note that the working directory is always recorded if GDB
|
||||
extensions are enabled.
|
||||
|
||||
`DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME)'
|
||||
A C statement to output DBX debugging information to the stdio
|
||||
stream STREAM which indicates that file NAME is the main source
|
||||
file--the file specified as the input file for compilation. This
|
||||
macro is called only once, at the beginning of compilation.
|
||||
|
||||
This macro need not be defined if the standard form of output for
|
||||
DBX debugging information is appropriate.
|
||||
|
||||
`DBX_OUTPUT_MAIN_SOURCE_DIRECTORY (STREAM, NAME)'
|
||||
A C statement to output DBX debugging information to the stdio
|
||||
stream STREAM which indicates that the current directory during
|
||||
compilation is named NAME.
|
||||
|
||||
This macro need not be defined if the standard form of output for
|
||||
DBX debugging information is appropriate.
|
||||
|
||||
`DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME)'
|
||||
A C statement to output DBX debugging information at the end of
|
||||
compilation of the main source file NAME.
|
||||
|
||||
If you don't define this macro, nothing special is output at the
|
||||
end of compilation, which is correct for most machines.
|
||||
|
||||
`DBX_OUTPUT_SOURCE_FILENAME (STREAM, NAME)'
|
||||
A C statement to output DBX debugging information to the stdio
|
||||
stream STREAM which indicates that file NAME is the current source
|
||||
file. This output is generated each time input shifts to a
|
||||
different source file as a result of `#include', the end of an
|
||||
included file, or a `#line' command.
|
||||
|
||||
This macro need not be defined if the standard form of output for
|
||||
DBX debugging information is appropriate.
|
||||
|
||||
|
||||
File: gcc.info, Node: SDB and DWARF, Prev: File Names and DBX, Up: Debugging Info
|
||||
|
||||
Macros for SDB and DWARF Output
|
||||
-------------------------------
|
||||
|
||||
Here are macros for SDB and DWARF output.
|
||||
|
||||
`SDB_DEBUGGING_INFO'
|
||||
Define this macro if GNU CC should produce COFF-style debugging
|
||||
output for SDB in response to the `-g' option.
|
||||
|
||||
`DWARF_DEBUGGING_INFO'
|
||||
Define this macro if GNU CC should produce dwarf format debugging
|
||||
output in response to the `-g' option.
|
||||
|
||||
`DWARF2_DEBUGGING_INFO'
|
||||
Define this macro if GNU CC should produce dwarf version 2 format
|
||||
debugging output in response to the `-g' option.
|
||||
|
||||
To support optional call frame debugging information, you must also
|
||||
define `INCOMING_RETURN_ADDR_RTX' and either set
|
||||
`RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the
|
||||
prologue, or call `dwarf2out_def_cfa' and `dwarf2out_reg_save' as
|
||||
appropriate from `FUNCTION_PROLOGUE' if you don't.
|
||||
|
||||
`DWARF2_FRAME_INFO'
|
||||
Define this macro to a nonzero value if GNU CC should always output
|
||||
Dwarf 2 frame information. If `DWARF2_UNWIND_INFO' (*note
|
||||
Exception Region Output::. is nonzero, GNU CC will output this
|
||||
information not matter how you define `DWARF2_FRAME_INFO'.
|
||||
|
||||
`LINKER_DOES_NOT_WORK_WITH_DWARF2'
|
||||
Define this macro if the linker does not work with Dwarf version 2.
|
||||
Normally, if the user specifies only `-ggdb' GNU CC will use Dwarf
|
||||
version 2 if available; this macro disables this. See the
|
||||
description of the `PREFERRED_DEBUGGING_TYPE' macro for more
|
||||
details.
|
||||
|
||||
`PUT_SDB_...'
|
||||
Define these macros to override the assembler syntax for the
|
||||
special SDB assembler directives. See `sdbout.c' for a list of
|
||||
these macros and their arguments. If the standard syntax is used,
|
||||
you need not define them yourself.
|
||||
|
||||
`SDB_DELIM'
|
||||
Some assemblers do not support a semicolon as a delimiter, even
|
||||
between SDB assembler directives. In that case, define this macro
|
||||
to be the delimiter to use (usually `\n'). It is not necessary to
|
||||
define a new set of `PUT_SDB_OP' macros if this is the only change
|
||||
required.
|
||||
|
||||
`SDB_GENERATE_FAKE'
|
||||
Define this macro to override the usual method of constructing a
|
||||
dummy name for anonymous structure and union types. See
|
||||
`sdbout.c' for more information.
|
||||
|
||||
`SDB_ALLOW_UNKNOWN_REFERENCES'
|
||||
Define this macro to allow references to unknown structure, union,
|
||||
or enumeration tags to be emitted. Standard COFF does not allow
|
||||
handling of unknown references, MIPS ECOFF has support for it.
|
||||
|
||||
`SDB_ALLOW_FORWARD_REFERENCES'
|
||||
Define this macro to allow references to structure, union, or
|
||||
enumeration tags that have not yet been seen to be handled. Some
|
||||
assemblers choke if forward tags are used, while some require it.
|
||||
|
||||
|
||||
File: gcc.info, Node: Cross-compilation, Next: Misc, Prev: Debugging Info, Up: Target Macros
|
||||
|
||||
Cross Compilation and Floating Point
|
||||
====================================
|
||||
|
||||
While all modern machines use 2's complement representation for
|
||||
integers, there are a variety of representations for floating point
|
||||
numbers. This means that in a cross-compiler the representation of
|
||||
floating point numbers in the compiled program may be different from
|
||||
that used in the machine doing the compilation.
|
||||
|
||||
Because different representation systems may offer different amounts
|
||||
of range and precision, the cross compiler cannot safely use the host
|
||||
machine's floating point arithmetic. Therefore, floating point
|
||||
constants must be represented in the target machine's format. This
|
||||
means that the cross compiler cannot use `atof' to parse a floating
|
||||
point constant; it must have its own special routine to use instead.
|
||||
Also, constant folding must emulate the target machine's arithmetic (or
|
||||
must not be done at all).
|
||||
|
||||
The macros in the following table should be defined only if you are
|
||||
cross compiling between different floating point formats.
|
||||
|
||||
Otherwise, don't define them. Then default definitions will be set
|
||||
up which use `double' as the data type, `==' to test for equality, etc.
|
||||
|
||||
You don't need to worry about how many times you use an operand of
|
||||
any of these macros. The compiler never uses operands which have side
|
||||
effects.
|
||||
|
||||
`REAL_VALUE_TYPE'
|
||||
A macro for the C data type to be used to hold a floating point
|
||||
value in the target machine's format. Typically this would be a
|
||||
`struct' containing an array of `int'.
|
||||
|
||||
`REAL_VALUES_EQUAL (X, Y)'
|
||||
A macro for a C expression which compares for equality the two
|
||||
values, X and Y, both of type `REAL_VALUE_TYPE'.
|
||||
|
||||
`REAL_VALUES_LESS (X, Y)'
|
||||
A macro for a C expression which tests whether X is less than Y,
|
||||
both values being of type `REAL_VALUE_TYPE' and interpreted as
|
||||
floating point numbers in the target machine's representation.
|
||||
|
||||
`REAL_VALUE_LDEXP (X, SCALE)'
|
||||
A macro for a C expression which performs the standard library
|
||||
function `ldexp', but using the target machine's floating point
|
||||
representation. Both X and the value of the expression have type
|
||||
`REAL_VALUE_TYPE'. The second argument, SCALE, is an integer.
|
||||
|
||||
`REAL_VALUE_FIX (X)'
|
||||
A macro whose definition is a C expression to convert the
|
||||
target-machine floating point value X to a signed integer. X has
|
||||
type `REAL_VALUE_TYPE'.
|
||||
|
||||
`REAL_VALUE_UNSIGNED_FIX (X)'
|
||||
A macro whose definition is a C expression to convert the
|
||||
target-machine floating point value X to an unsigned integer. X
|
||||
has type `REAL_VALUE_TYPE'.
|
||||
|
||||
`REAL_VALUE_RNDZINT (X)'
|
||||
A macro whose definition is a C expression to round the
|
||||
target-machine floating point value X towards zero to an integer
|
||||
value (but still as a floating point number). X has type
|
||||
`REAL_VALUE_TYPE', and so does the value.
|
||||
|
||||
`REAL_VALUE_UNSIGNED_RNDZINT (X)'
|
||||
A macro whose definition is a C expression to round the
|
||||
target-machine floating point value X towards zero to an unsigned
|
||||
integer value (but still represented as a floating point number).
|
||||
X has type `REAL_VALUE_TYPE', and so does the value.
|
||||
|
||||
`REAL_VALUE_ATOF (STRING, MODE)'
|
||||
A macro for a C expression which converts STRING, an expression of
|
||||
type `char *', into a floating point number in the target machine's
|
||||
representation for mode MODE. The value has type
|
||||
`REAL_VALUE_TYPE'.
|
||||
|
||||
`REAL_INFINITY'
|
||||
Define this macro if infinity is a possible floating point value,
|
||||
and therefore division by 0 is legitimate.
|
||||
|
||||
`REAL_VALUE_ISINF (X)'
|
||||
A macro for a C expression which determines whether X, a floating
|
||||
point value, is infinity. The value has type `int'. By default,
|
||||
this is defined to call `isinf'.
|
||||
|
||||
`REAL_VALUE_ISNAN (X)'
|
||||
A macro for a C expression which determines whether X, a floating
|
||||
point value, is a "nan" (not-a-number). The value has type `int'.
|
||||
By default, this is defined to call `isnan'.
|
||||
|
||||
Define the following additional macros if you want to make floating
|
||||
point constant folding work while cross compiling. If you don't define
|
||||
them, cross compilation is still possible, but constant folding will
|
||||
not happen for floating point values.
|
||||
|
||||
`REAL_ARITHMETIC (OUTPUT, CODE, X, Y)'
|
||||
A macro for a C statement which calculates an arithmetic operation
|
||||
of the two floating point values X and Y, both of type
|
||||
`REAL_VALUE_TYPE' in the target machine's representation, to
|
||||
produce a result of the same type and representation which is
|
||||
stored in OUTPUT (which will be a variable).
|
||||
|
||||
The operation to be performed is specified by CODE, a tree code
|
||||
which will always be one of the following: `PLUS_EXPR',
|
||||
`MINUS_EXPR', `MULT_EXPR', `RDIV_EXPR', `MAX_EXPR', `MIN_EXPR'.
|
||||
|
||||
The expansion of this macro is responsible for checking for
|
||||
overflow. If overflow happens, the macro expansion should execute
|
||||
the statement `return 0;', which indicates the inability to
|
||||
perform the arithmetic operation requested.
|
||||
|
||||
`REAL_VALUE_NEGATE (X)'
|
||||
A macro for a C expression which returns the negative of the
|
||||
floating point value X. Both X and the value of the expression
|
||||
have type `REAL_VALUE_TYPE' and are in the target machine's
|
||||
floating point representation.
|
||||
|
||||
There is no way for this macro to report overflow, since overflow
|
||||
can't happen in the negation operation.
|
||||
|
||||
`REAL_VALUE_TRUNCATE (MODE, X)'
|
||||
A macro for a C expression which converts the floating point value
|
||||
X to mode MODE.
|
||||
|
||||
Both X and the value of the expression are in the target machine's
|
||||
floating point representation and have type `REAL_VALUE_TYPE'.
|
||||
However, the value should have an appropriate bit pattern to be
|
||||
output properly as a floating constant whose precision accords
|
||||
with mode MODE.
|
||||
|
||||
There is no way for this macro to report overflow.
|
||||
|
||||
`REAL_VALUE_TO_INT (LOW, HIGH, X)'
|
||||
A macro for a C expression which converts a floating point value X
|
||||
into a double-precision integer which is then stored into LOW and
|
||||
HIGH, two variables of type INT.
|
||||
|
||||
`REAL_VALUE_FROM_INT (X, LOW, HIGH, MODE)'
|
||||
A macro for a C expression which converts a double-precision
|
||||
integer found in LOW and HIGH, two variables of type INT, into a
|
||||
floating point value which is then stored into X. The value is in
|
||||
the target machine's representation for mode MODE and has the type
|
||||
`REAL_VALUE_TYPE'.
|
||||
|
||||
Executable
+1017
File diff suppressed because it is too large
Load Diff
Executable
+535
@@ -0,0 +1,535 @@
|
||||
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
|
||||
input file ../../gcc-2.95.2/gcc/gcc.texi.
|
||||
|
||||
INFO-DIR-SECTION Programming
|
||||
START-INFO-DIR-ENTRY
|
||||
* gcc: (gcc). The GNU Compiler Collection.
|
||||
END-INFO-DIR-ENTRY
|
||||
This file documents the use and the internals of the GNU compiler.
|
||||
|
||||
Published by the Free Software Foundation 59 Temple Place - Suite 330
|
||||
Boston, MA 02111-1307 USA
|
||||
|
||||
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
|
||||
1999 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 "Funding
|
||||
for Free Software" 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 one.
|
||||
|
||||
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 "Funding for Free Software", 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: Copying, Next: Contributors, Prev: GNU/Linux, Up: Top
|
||||
|
||||
GNU GENERAL PUBLIC LICENSE
|
||||
**************************
|
||||
|
||||
Version 2, June 1991
|
||||
|
||||
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
|
||||
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
|
||||
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
of this license document, but changing it is not allowed.
|
||||
|
||||
Preamble
|
||||
========
|
||||
|
||||
The licenses for most software are designed to take away your
|
||||
freedom to share and change it. By contrast, the GNU General Public
|
||||
License is intended to guarantee your freedom to share and change free
|
||||
software--to make sure the software is free for all its users. This
|
||||
General Public License applies to most of the Free Software
|
||||
Foundation's software and to any other program whose authors commit to
|
||||
using it. (Some other Free Software Foundation software is covered by
|
||||
the GNU Library General Public License instead.) You can apply it to
|
||||
your programs, too.
|
||||
|
||||
When we speak of free software, we are referring to freedom, not
|
||||
price. Our General Public Licenses are designed to make sure that you
|
||||
have the freedom to distribute copies of free software (and charge for
|
||||
this service if you wish), that you receive source code or can get it
|
||||
if you want it, that you can change the software or use pieces of it in
|
||||
new free programs; and that you know you can do these things.
|
||||
|
||||
To protect your rights, we need to make restrictions that forbid
|
||||
anyone to deny you these rights or to ask you to surrender the rights.
|
||||
These restrictions translate to certain responsibilities for you if you
|
||||
distribute copies of the software, or if you modify it.
|
||||
|
||||
For example, if you distribute copies of such a program, whether
|
||||
gratis or for a fee, you must give the recipients all the rights that
|
||||
you have. You must make sure that they, too, receive or can get the
|
||||
source code. And you must show them these terms so they know their
|
||||
rights.
|
||||
|
||||
We protect your rights with two steps: (1) copyright the software,
|
||||
and (2) offer you this license which gives you legal permission to copy,
|
||||
distribute and/or modify the software.
|
||||
|
||||
Also, for each author's protection and ours, we want to make certain
|
||||
that everyone understands that there is no warranty for this free
|
||||
software. If the software is modified by someone else and passed on, we
|
||||
want its recipients to know that what they have is not the original, so
|
||||
that any problems introduced by others will not reflect on the original
|
||||
authors' reputations.
|
||||
|
||||
Finally, any free program is threatened constantly by software
|
||||
patents. We wish to avoid the danger that redistributors of a free
|
||||
program will individually obtain patent licenses, in effect making the
|
||||
program proprietary. To prevent this, we have made it clear that any
|
||||
patent must be licensed for everyone's free use or not licensed at all.
|
||||
|
||||
The precise terms and conditions for copying, distribution and
|
||||
modification follow.
|
||||
|
||||
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
|
||||
|
||||
0. This License applies to any program or other work which contains a
|
||||
notice placed by the copyright holder saying it may be distributed
|
||||
under the terms of this General Public License. The "Program",
|
||||
below, refers to any such program or work, and a "work based on
|
||||
the Program" means either the Program or any derivative work under
|
||||
copyright law: that is to say, a work containing the Program or a
|
||||
portion of it, either verbatim or with modifications and/or
|
||||
translated into another language. (Hereinafter, translation is
|
||||
included without limitation in the term "modification".) Each
|
||||
licensee is addressed as "you".
|
||||
|
||||
Activities other than copying, distribution and modification are
|
||||
not covered by this License; they are outside its scope. The act
|
||||
of running the Program is not restricted, and the output from the
|
||||
Program is covered only if its contents constitute a work based on
|
||||
the Program (independent of having been made by running the
|
||||
Program). Whether that is true depends on what the Program does.
|
||||
|
||||
1. You may copy and distribute verbatim copies of the Program's
|
||||
source code as you receive it, in any medium, provided that you
|
||||
conspicuously and appropriately publish on each copy an appropriate
|
||||
copyright notice and disclaimer of warranty; keep intact all the
|
||||
notices that refer to this License and to the absence of any
|
||||
warranty; and give any other recipients of the Program a copy of
|
||||
this License along with the Program.
|
||||
|
||||
You may charge a fee for the physical act of transferring a copy,
|
||||
and you may at your option offer warranty protection in exchange
|
||||
for a fee.
|
||||
|
||||
2. You may modify your copy or copies of the Program or any portion
|
||||
of it, thus forming a work based on the Program, and copy and
|
||||
distribute such modifications or work under the terms of Section 1
|
||||
above, provided that you also meet all of these conditions:
|
||||
|
||||
a. You must cause the modified files to carry prominent notices
|
||||
stating that you changed the files and the date of any change.
|
||||
|
||||
b. You must cause any work that you distribute or publish, that
|
||||
in whole or in part contains or is derived from the Program
|
||||
or any part thereof, to be licensed as a whole at no charge
|
||||
to all third parties under the terms of this License.
|
||||
|
||||
c. If the modified program normally reads commands interactively
|
||||
when run, you must cause it, when started running for such
|
||||
interactive use in the most ordinary way, to print or display
|
||||
an announcement including an appropriate copyright notice and
|
||||
a notice that there is no warranty (or else, saying that you
|
||||
provide a warranty) and that users may redistribute the
|
||||
program under these conditions, and telling the user how to
|
||||
view a copy of this License. (Exception: if the Program
|
||||
itself is interactive but does not normally print such an
|
||||
announcement, your work based on the Program is not required
|
||||
to print an announcement.)
|
||||
|
||||
These requirements apply to the modified work as a whole. If
|
||||
identifiable sections of that work are not derived from the
|
||||
Program, and can be reasonably considered independent and separate
|
||||
works in themselves, then this License, and its terms, do not
|
||||
apply to those sections when you distribute them as separate
|
||||
works. But when you distribute the same sections as part of a
|
||||
whole which is a work based on the Program, the distribution of
|
||||
the whole must be on the terms of this License, whose permissions
|
||||
for other licensees extend to the entire whole, and thus to each
|
||||
and every part regardless of who wrote it.
|
||||
|
||||
Thus, it is not the intent of this section to claim rights or
|
||||
contest your rights to work written entirely by you; rather, the
|
||||
intent is to exercise the right to control the distribution of
|
||||
derivative or collective works based on the Program.
|
||||
|
||||
In addition, mere aggregation of another work not based on the
|
||||
Program with the Program (or with a work based on the Program) on
|
||||
a volume of a storage or distribution medium does not bring the
|
||||
other work under the scope of this License.
|
||||
|
||||
3. You may copy and distribute the Program (or a work based on it,
|
||||
under Section 2) in object code or executable form under the terms
|
||||
of Sections 1 and 2 above provided that you also do one of the
|
||||
following:
|
||||
|
||||
a. Accompany it with the complete corresponding machine-readable
|
||||
source code, which must be distributed under the terms of
|
||||
Sections 1 and 2 above on a medium customarily used for
|
||||
software interchange; or,
|
||||
|
||||
b. Accompany it with a written offer, valid for at least three
|
||||
years, to give any third party, for a charge no more than your
|
||||
cost of physically performing source distribution, a complete
|
||||
machine-readable copy of the corresponding source code, to be
|
||||
distributed under the terms of Sections 1 and 2 above on a
|
||||
medium customarily used for software interchange; or,
|
||||
|
||||
c. Accompany it with the information you received as to the offer
|
||||
to distribute corresponding source code. (This alternative is
|
||||
allowed only for noncommercial distribution and only if you
|
||||
received the program in object code or executable form with
|
||||
such an offer, in accord with Subsection b above.)
|
||||
|
||||
The source code for a work means the preferred form of the work for
|
||||
making modifications to it. For an executable work, complete
|
||||
source code means all the source code for all modules it contains,
|
||||
plus any associated interface definition files, plus the scripts
|
||||
used to control compilation and installation of the executable.
|
||||
However, as a special exception, the source code distributed need
|
||||
not include anything that is normally distributed (in either
|
||||
source or binary form) with the major components (compiler,
|
||||
kernel, and so on) of the operating system on which the executable
|
||||
runs, unless that component itself accompanies the executable.
|
||||
|
||||
If distribution of executable or object code is made by offering
|
||||
access to copy from a designated place, then offering equivalent
|
||||
access to copy the source code from the same place counts as
|
||||
distribution of the source code, even though third parties are not
|
||||
compelled to copy the source along with the object code.
|
||||
|
||||
4. You may not copy, modify, sublicense, or distribute the Program
|
||||
except as expressly provided under this License. Any attempt
|
||||
otherwise to copy, modify, sublicense or distribute the Program is
|
||||
void, and will automatically terminate your rights under this
|
||||
License. However, parties who have received copies, or rights,
|
||||
from you under this License will not have their licenses
|
||||
terminated so long as such parties remain in full compliance.
|
||||
|
||||
5. You are not required to accept this License, since you have not
|
||||
signed it. However, nothing else grants you permission to modify
|
||||
or distribute the Program or its derivative works. These actions
|
||||
are prohibited by law if you do not accept this License.
|
||||
Therefore, by modifying or distributing the Program (or any work
|
||||
based on the Program), you indicate your acceptance of this
|
||||
License to do so, and all its terms and conditions for copying,
|
||||
distributing or modifying the Program or works based on it.
|
||||
|
||||
6. Each time you redistribute the Program (or any work based on the
|
||||
Program), the recipient automatically receives a license from the
|
||||
original licensor to copy, distribute or modify the Program
|
||||
subject to these terms and conditions. You may not impose any
|
||||
further restrictions on the recipients' exercise of the rights
|
||||
granted herein. You are not responsible for enforcing compliance
|
||||
by third parties to this License.
|
||||
|
||||
7. If, as a consequence of a court judgment or allegation of patent
|
||||
infringement or for any other reason (not limited to patent
|
||||
issues), conditions are imposed on you (whether by court order,
|
||||
agreement or otherwise) that contradict the conditions of this
|
||||
License, they do not excuse you from the conditions of this
|
||||
License. If you cannot distribute so as to satisfy simultaneously
|
||||
your obligations under this License and any other pertinent
|
||||
obligations, then as a consequence you may not distribute the
|
||||
Program at all. For example, if a patent license would not permit
|
||||
royalty-free redistribution of the Program by all those who
|
||||
receive copies directly or indirectly through you, then the only
|
||||
way you could satisfy both it and this License would be to refrain
|
||||
entirely from distribution of the Program.
|
||||
|
||||
If any portion of this section is held invalid or unenforceable
|
||||
under any particular circumstance, the balance of the section is
|
||||
intended to apply and the section as a whole is intended to apply
|
||||
in other circumstances.
|
||||
|
||||
It is not the purpose of this section to induce you to infringe any
|
||||
patents or other property right claims or to contest validity of
|
||||
any such claims; this section has the sole purpose of protecting
|
||||
the integrity of the free software distribution system, which is
|
||||
implemented by public license practices. Many people have made
|
||||
generous contributions to the wide range of software distributed
|
||||
through that system in reliance on consistent application of that
|
||||
system; it is up to the author/donor to decide if he or she is
|
||||
willing to distribute software through any other system and a
|
||||
licensee cannot impose that choice.
|
||||
|
||||
This section is intended to make thoroughly clear what is believed
|
||||
to be a consequence of the rest of this License.
|
||||
|
||||
8. If the distribution and/or use of the Program is restricted in
|
||||
certain countries either by patents or by copyrighted interfaces,
|
||||
the original copyright holder who places the Program under this
|
||||
License may add an explicit geographical distribution limitation
|
||||
excluding those countries, so that distribution is permitted only
|
||||
in or among countries not thus excluded. In such case, this
|
||||
License incorporates the limitation as if written in the body of
|
||||
this License.
|
||||
|
||||
9. The Free Software Foundation may publish revised and/or new
|
||||
versions of the General Public License from time to time. Such
|
||||
new versions will be similar in spirit to the present version, but
|
||||
may differ in detail to address new problems or concerns.
|
||||
|
||||
Each version is given a distinguishing version number. If the
|
||||
Program specifies a version number of this License which applies
|
||||
to it and "any later version", you have the option of following
|
||||
the terms and conditions either of that version or of any later
|
||||
version published by the Free Software Foundation. If the Program
|
||||
does not specify a version number of this License, you may choose
|
||||
any version ever published by the Free Software Foundation.
|
||||
|
||||
10. If you wish to incorporate parts of the Program into other free
|
||||
programs whose distribution conditions are different, write to the
|
||||
author to ask for permission. For software which is copyrighted
|
||||
by the Free Software Foundation, write to the Free Software
|
||||
Foundation; we sometimes make exceptions for this. Our decision
|
||||
will be guided by the two goals of preserving the free status of
|
||||
all derivatives of our free software and of promoting the sharing
|
||||
and reuse of software generally.
|
||||
|
||||
NO WARRANTY
|
||||
|
||||
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO
|
||||
WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
|
||||
LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
|
||||
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT
|
||||
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT
|
||||
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
|
||||
FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE
|
||||
QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
|
||||
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
|
||||
SERVICING, REPAIR OR CORRECTION.
|
||||
|
||||
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
|
||||
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY
|
||||
MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE
|
||||
LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL,
|
||||
INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
|
||||
INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
|
||||
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU
|
||||
OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY
|
||||
OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN
|
||||
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
|
||||
|
||||
END OF TERMS AND CONDITIONS
|
||||
|
||||
How to Apply These Terms to Your New Programs
|
||||
=============================================
|
||||
|
||||
If you develop a new program, and you want it to be of the greatest
|
||||
possible use to the public, the best way to achieve this is to make it
|
||||
free software which everyone can redistribute and change under these
|
||||
terms.
|
||||
|
||||
To do so, attach the following notices to the program. It is safest
|
||||
to attach them to the start of each source file to most effectively
|
||||
convey the exclusion of warranty; and each file should have at least
|
||||
the "copyright" line and a pointer to where the full notice is found.
|
||||
|
||||
ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES.
|
||||
Copyright (C) YYYY NAME OF AUTHOR
|
||||
|
||||
This program is free software; you can redistribute it and/or modify
|
||||
it under the terms of the GNU General Public License as published by
|
||||
the Free Software Foundation; either version 2 of the License, or
|
||||
(at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
||||
|
||||
Also add information on how to contact you by electronic and paper
|
||||
mail.
|
||||
|
||||
If the program is interactive, make it output a short notice like
|
||||
this when it starts in an interactive mode:
|
||||
|
||||
Gnomovision version 69, Copyright (C) YYYY NAME OF AUTHOR
|
||||
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
|
||||
type `show w'.
|
||||
This is free software, and you are welcome to redistribute it
|
||||
under certain conditions; type `show c' for details.
|
||||
|
||||
The hypothetical commands `show w' and `show c' should show the
|
||||
appropriate parts of the General Public License. Of course, the
|
||||
commands you use may be called something other than `show w' and `show
|
||||
c'; they could even be mouse-clicks or menu items--whatever suits your
|
||||
program.
|
||||
|
||||
You should also get your employer (if you work as a programmer) or
|
||||
your school, if any, to sign a "copyright disclaimer" for the program,
|
||||
if necessary. Here is a sample; alter the names:
|
||||
|
||||
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
|
||||
`Gnomovision' (which makes passes at compilers) written by James Hacker.
|
||||
|
||||
SIGNATURE OF TY COON, 1 April 1989
|
||||
Ty Coon, President of Vice
|
||||
|
||||
This General Public License does not permit incorporating your
|
||||
program into proprietary programs. If your program is a subroutine
|
||||
library, you may consider it more useful to permit linking proprietary
|
||||
applications with the library. If this is what you want to do, use the
|
||||
GNU Library General Public License instead of this License.
|
||||
|
||||
|
||||
File: gcc.info, Node: Contributors, Next: Index, Prev: Copying, Up: Top
|
||||
|
||||
Contributors to GCC
|
||||
*******************
|
||||
|
||||
In addition to Richard Stallman, several people have written parts
|
||||
of GCC.
|
||||
|
||||
* The idea of using RTL and some of the optimization ideas came from
|
||||
the program PO written at the University of Arizona by Jack
|
||||
Davidson and Christopher Fraser. See "Register Allocation and
|
||||
Exhaustive Peephole Optimization", Software Practice and
|
||||
Experience 14 (9), Sept. 1984, 857-866.
|
||||
|
||||
* Paul Rubin wrote most of the preprocessor.
|
||||
|
||||
* Leonard Tower wrote parts of the parser, RTL generator, and RTL
|
||||
definitions, and of the Vax machine description.
|
||||
|
||||
* Ted Lemon wrote parts of the RTL reader and printer.
|
||||
|
||||
* Jim Wilson implemented loop strength reduction and some other loop
|
||||
optimizations.
|
||||
|
||||
* Nobuyuki Hikichi of Software Research Associates, Tokyo,
|
||||
contributed the support for the Sony NEWS machine.
|
||||
|
||||
* Charles LaBrec contributed the support for the Integrated Solutions
|
||||
68020 system.
|
||||
|
||||
* Michael Tiemann of Cygnus Support wrote the front end for C++, as
|
||||
well as the support for inline functions and instruction
|
||||
scheduling. Also the descriptions of the National Semiconductor
|
||||
32000 series cpu, the SPARC cpu and part of the Motorola 88000 cpu.
|
||||
|
||||
* Gerald Baumgartner added the signature extension to the C++
|
||||
front-end.
|
||||
|
||||
* Jan Stein of the Chalmers Computer Society provided support for
|
||||
Genix, as well as part of the 32000 machine description.
|
||||
|
||||
* Randy Smith finished the Sun FPA support.
|
||||
|
||||
* Robert Brown implemented the support for Encore 32000 systems.
|
||||
|
||||
* David Kashtan of SRI adapted GCC to VMS.
|
||||
|
||||
* Alex Crain provided changes for the 3b1.
|
||||
|
||||
* Greg Satz and Chris Hanson assisted in making GCC work on HP-UX for
|
||||
the 9000 series 300.
|
||||
|
||||
* William Schelter did most of the work on the Intel 80386 support.
|
||||
|
||||
* Christopher Smith did the port for Convex machines.
|
||||
|
||||
* Paul Petersen wrote the machine description for the Alliant FX/8.
|
||||
|
||||
* Dario Dariol contributed the four varieties of sample programs
|
||||
that print a copy of their source.
|
||||
|
||||
* Alain Lichnewsky ported GCC to the Mips cpu.
|
||||
|
||||
* Devon Bowen, Dale Wiles and Kevin Zachmann ported GCC to the Tahoe.
|
||||
|
||||
* Jonathan Stone wrote the machine description for the Pyramid
|
||||
computer.
|
||||
|
||||
* Gary Miller ported GCC to Charles River Data Systems machines.
|
||||
|
||||
* Richard Kenner of the New York University Ultracomputer Research
|
||||
Laboratory wrote the machine descriptions for the AMD 29000, the
|
||||
DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the
|
||||
support for instruction attributes. He also made changes to
|
||||
better support RISC processors including changes to common
|
||||
subexpression elimination, strength reduction, function calling
|
||||
sequence handling, and condition code support, in addition to
|
||||
generalizing the code for frame pointer elimination.
|
||||
|
||||
* Richard Kenner and Michael Tiemann jointly developed reorg.c, the
|
||||
delay slot scheduler.
|
||||
|
||||
* Mike Meissner and Tom Wood of Data General finished the port to the
|
||||
Motorola 88000.
|
||||
|
||||
* Masanobu Yuhara of Fujitsu Laboratories implemented the machine
|
||||
description for the Tron architecture (specifically, the Gmicro).
|
||||
|
||||
* NeXT, Inc. donated the front end that supports the Objective C
|
||||
language.
|
||||
|
||||
* James van Artsdalen wrote the code that makes efficient use of the
|
||||
Intel 80387 register stack.
|
||||
|
||||
* Mike Meissner at the Open Software Foundation finished the port to
|
||||
the MIPS cpu, including adding ECOFF debug support, and worked on
|
||||
the Intel port for the Intel 80386 cpu. Later at Cygnus Support,
|
||||
he worked on the rs6000 and PowerPC ports.
|
||||
|
||||
* Ron Guilmette implemented the `protoize' and `unprotoize' tools,
|
||||
the support for Dwarf symbolic debugging information, and much of
|
||||
the support for System V Release 4. He has also worked heavily on
|
||||
the Intel 386 and 860 support.
|
||||
|
||||
* Torbjorn Granlund implemented multiply- and divide-by-constant
|
||||
optimization, improved long long support, and improved leaf
|
||||
function register allocation.
|
||||
|
||||
* Mike Stump implemented the support for Elxsi 64 bit CPU.
|
||||
|
||||
* John Wehle added the machine description for the Western Electric
|
||||
32000 processor used in several 3b series machines (no relation to
|
||||
the National Semiconductor 32000 processor).
|
||||
|
||||
* Holger Teutsch provided the support for the Clipper cpu.
|
||||
|
||||
* Kresten Krab Thorup wrote the run time support for the Objective C
|
||||
language.
|
||||
|
||||
* Stephen Moshier contributed the floating point emulator that
|
||||
assists in cross-compilation and permits support for floating
|
||||
point numbers wider than 64 bits.
|
||||
|
||||
* David Edelsohn contributed the changes to RS/6000 port to make it
|
||||
support the PowerPC and POWER2 architectures.
|
||||
|
||||
* Steve Chamberlain wrote the support for the Hitachi SH processor.
|
||||
|
||||
* Peter Schauer wrote the code to allow debugging to work on the
|
||||
Alpha.
|
||||
|
||||
* Oliver M. Kellogg of Deutsche Aerospace contributed the port to the
|
||||
MIL-STD-1750A.
|
||||
|
||||
* Michael K. Gschwind contributed the port to the PDP-11.
|
||||
|
||||
* David Reese of Sun Microsystems contributed to the Solaris on
|
||||
PowerPC port.
|
||||
|
||||
Executable
+1158
File diff suppressed because it is too large
Load Diff
Executable
+2131
File diff suppressed because it is too large
Load Diff
Executable
+1121
File diff suppressed because it is too large
Load Diff
Executable
+1102
File diff suppressed because it is too large
Load Diff
Executable
+1210
File diff suppressed because it is too large
Load Diff
Executable
+943
@@ -0,0 +1,943 @@
|
||||
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
|
||||
input file ../../gcc-2.95.2/gcc/gcc.texi.
|
||||
|
||||
INFO-DIR-SECTION Programming
|
||||
START-INFO-DIR-ENTRY
|
||||
* gcc: (gcc). The GNU Compiler Collection.
|
||||
END-INFO-DIR-ENTRY
|
||||
This file documents the use and the internals of the GNU compiler.
|
||||
|
||||
Published by the Free Software Foundation 59 Temple Place - Suite 330
|
||||
Boston, MA 02111-1307 USA
|
||||
|
||||
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
|
||||
1999 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 "Funding
|
||||
for Free Software" 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 one.
|
||||
|
||||
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 "Funding for Free Software", 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: Environment Variables, Next: Running Protoize, Prev: Code Gen Options, Up: Invoking GCC
|
||||
|
||||
Environment Variables Affecting GCC
|
||||
===================================
|
||||
|
||||
This section describes several environment variables that affect how
|
||||
GCC operates. Some of them work by specifying directories or prefixes
|
||||
to use when searching for various kinds of files. Some are used to
|
||||
specify other aspects of the compilation environment.
|
||||
|
||||
Note that you can also specify places to search using options such as
|
||||
`-B', `-I' and `-L' (*note Directory Options::.). These take
|
||||
precedence over places specified using environment variables, which in
|
||||
turn take precedence over those specified by the configuration of GCC.
|
||||
*Note Driver::.
|
||||
|
||||
`LANG'
|
||||
`LC_CTYPE'
|
||||
`LC_MESSAGES'
|
||||
`LC_ALL'
|
||||
These environment variables control the way that GCC uses
|
||||
localization information that allow GCC to work with different
|
||||
national conventions. GCC inspects the locale categories
|
||||
`LC_CTYPE' and `LC_MESSAGES' if it has been configured to do so.
|
||||
These locale categories can be set to any value supported by your
|
||||
installation. A typical value is `en_UK' for English in the United
|
||||
Kingdom.
|
||||
|
||||
The `LC_CTYPE' environment variable specifies character
|
||||
classification. GCC uses it to determine the character boundaries
|
||||
in a string; this is needed for some multibyte encodings that
|
||||
contain quote and escape characters that would otherwise be
|
||||
interpreted as a string end or escape.
|
||||
|
||||
The `LC_MESSAGES' environment variable specifies the language to
|
||||
use in diagnostic messages.
|
||||
|
||||
If the `LC_ALL' environment variable is set, it overrides the value
|
||||
of `LC_CTYPE' and `LC_MESSAGES'; otherwise, `LC_CTYPE' and
|
||||
`LC_MESSAGES' default to the value of the `LANG' environment
|
||||
variable. If none of these variables are set, GCC defaults to
|
||||
traditional C English behavior.
|
||||
|
||||
`TMPDIR'
|
||||
If `TMPDIR' is set, it specifies the directory to use for temporary
|
||||
files. GCC uses temporary files to hold the output of one stage of
|
||||
compilation which is to be used as input to the next stage: for
|
||||
example, the output of the preprocessor, which is the input to the
|
||||
compiler proper.
|
||||
|
||||
`GCC_EXEC_PREFIX'
|
||||
If `GCC_EXEC_PREFIX' is set, it specifies a prefix to use in the
|
||||
names of the subprograms executed by the compiler. No slash is
|
||||
added when this prefix is combined with the name of a subprogram,
|
||||
but you can specify a prefix that ends with a slash if you wish.
|
||||
|
||||
If GCC cannot find the subprogram using the specified prefix, it
|
||||
tries looking in the usual places for the subprogram.
|
||||
|
||||
The default value of `GCC_EXEC_PREFIX' is `PREFIX/lib/gcc-lib/'
|
||||
where PREFIX is the value of `prefix' when you ran the `configure'
|
||||
script.
|
||||
|
||||
Other prefixes specified with `-B' take precedence over this
|
||||
prefix.
|
||||
|
||||
This prefix is also used for finding files such as `crt0.o' that
|
||||
are used for linking.
|
||||
|
||||
In addition, the prefix is used in an unusual way in finding the
|
||||
directories to search for header files. For each of the standard
|
||||
directories whose name normally begins with
|
||||
`/usr/local/lib/gcc-lib' (more precisely, with the value of
|
||||
`GCC_INCLUDE_DIR'), GCC tries replacing that beginning with the
|
||||
specified prefix to produce an alternate directory name. Thus,
|
||||
with `-Bfoo/', GCC will search `foo/bar' where it would normally
|
||||
search `/usr/local/lib/bar'. These alternate directories are
|
||||
searched first; the standard directories come next.
|
||||
|
||||
`COMPILER_PATH'
|
||||
The value of `COMPILER_PATH' is a colon-separated list of
|
||||
directories, much like `PATH'. GCC tries the directories thus
|
||||
specified when searching for subprograms, if it can't find the
|
||||
subprograms using `GCC_EXEC_PREFIX'.
|
||||
|
||||
`LIBRARY_PATH'
|
||||
The value of `LIBRARY_PATH' is a colon-separated list of
|
||||
directories, much like `PATH'. When configured as a native
|
||||
compiler, GCC tries the directories thus specified when searching
|
||||
for special linker files, if it can't find them using
|
||||
`GCC_EXEC_PREFIX'. Linking using GCC also uses these directories
|
||||
when searching for ordinary libraries for the `-l' option (but
|
||||
directories specified with `-L' come first).
|
||||
|
||||
`C_INCLUDE_PATH'
|
||||
`CPLUS_INCLUDE_PATH'
|
||||
`OBJC_INCLUDE_PATH'
|
||||
These environment variables pertain to particular languages. Each
|
||||
variable's value is a colon-separated list of directories, much
|
||||
like `PATH'. When GCC searches for header files, it tries the
|
||||
directories listed in the variable for the language you are using,
|
||||
after the directories specified with `-I' but before the standard
|
||||
header file directories.
|
||||
|
||||
`DEPENDENCIES_OUTPUT'
|
||||
If this variable is set, its value specifies how to output
|
||||
dependencies for Make based on the header files processed by the
|
||||
compiler. This output looks much like the output from the `-M'
|
||||
option (*note Preprocessor Options::.), but it goes to a separate
|
||||
file, and is in addition to the usual results of compilation.
|
||||
|
||||
The value of `DEPENDENCIES_OUTPUT' can be just a file name, in
|
||||
which case the Make rules are written to that file, guessing the
|
||||
target name from the source file name. Or the value can have the
|
||||
form `FILE TARGET', in which case the rules are written to file
|
||||
FILE using TARGET as the target name.
|
||||
|
||||
`LANG'
|
||||
This variable is used to pass locale information to the compiler.
|
||||
One way in which this information is used is to determine the
|
||||
character set to be used when character literals, string literals
|
||||
and comments are parsed in C and C++. When the compiler is
|
||||
configured to allow multibyte characters, the following values for
|
||||
`LANG' are recognized:
|
||||
|
||||
`C-JIS'
|
||||
Recognize JIS characters.
|
||||
|
||||
`C-SJIS'
|
||||
Recognize SJIS characters.
|
||||
|
||||
`C-EUCJP'
|
||||
Recognize EUCJP characters.
|
||||
|
||||
If `LANG' is not defined, or if it has some other value, then the
|
||||
compiler will use mblen and mbtowc as defined by the default
|
||||
locale to recognize and translate multibyte characters.
|
||||
|
||||
|
||||
File: gcc.info, Node: Running Protoize, Prev: Environment Variables, Up: Invoking GCC
|
||||
|
||||
Running Protoize
|
||||
================
|
||||
|
||||
The program `protoize' is an optional part of GNU C. You can use it
|
||||
to add prototypes to a program, thus converting the program to ANSI C
|
||||
in one respect. The companion program `unprotoize' does the reverse:
|
||||
it removes argument types from any prototypes that are found.
|
||||
|
||||
When you run these programs, you must specify a set of source files
|
||||
as command line arguments. The conversion programs start out by
|
||||
compiling these files to see what functions they define. The
|
||||
information gathered about a file FOO is saved in a file named `FOO.X'.
|
||||
|
||||
After scanning comes actual conversion. The specified files are all
|
||||
eligible to be converted; any files they include (whether sources or
|
||||
just headers) are eligible as well.
|
||||
|
||||
But not all the eligible files are converted. By default,
|
||||
`protoize' and `unprotoize' convert only source and header files in the
|
||||
current directory. You can specify additional directories whose files
|
||||
should be converted with the `-d DIRECTORY' option. You can also
|
||||
specify particular files to exclude with the `-x FILE' option. A file
|
||||
is converted if it is eligible, its directory name matches one of the
|
||||
specified directory names, and its name within the directory has not
|
||||
been excluded.
|
||||
|
||||
Basic conversion with `protoize' consists of rewriting most function
|
||||
definitions and function declarations to specify the types of the
|
||||
arguments. The only ones not rewritten are those for varargs functions.
|
||||
|
||||
`protoize' optionally inserts prototype declarations at the
|
||||
beginning of the source file, to make them available for any calls that
|
||||
precede the function's definition. Or it can insert prototype
|
||||
declarations with block scope in the blocks where undeclared functions
|
||||
are called.
|
||||
|
||||
Basic conversion with `unprotoize' consists of rewriting most
|
||||
function declarations to remove any argument types, and rewriting
|
||||
function definitions to the old-style pre-ANSI form.
|
||||
|
||||
Both conversion programs print a warning for any function
|
||||
declaration or definition that they can't convert. You can suppress
|
||||
these warnings with `-q'.
|
||||
|
||||
The output from `protoize' or `unprotoize' replaces the original
|
||||
source file. The original file is renamed to a name ending with
|
||||
`.save'. If the `.save' file already exists, then the source file is
|
||||
simply discarded.
|
||||
|
||||
`protoize' and `unprotoize' both depend on GCC itself to scan the
|
||||
program and collect information about the functions it uses. So
|
||||
neither of these programs will work until GCC is installed.
|
||||
|
||||
Here is a table of the options you can use with `protoize' and
|
||||
`unprotoize'. Each option works with both programs unless otherwise
|
||||
stated.
|
||||
|
||||
`-B DIRECTORY'
|
||||
Look for the file `SYSCALLS.c.X' in DIRECTORY, instead of the
|
||||
usual directory (normally `/usr/local/lib'). This file contains
|
||||
prototype information about standard system functions. This option
|
||||
applies only to `protoize'.
|
||||
|
||||
`-c COMPILATION-OPTIONS'
|
||||
Use COMPILATION-OPTIONS as the options when running `gcc' to
|
||||
produce the `.X' files. The special option `-aux-info' is always
|
||||
passed in addition, to tell `gcc' to write a `.X' file.
|
||||
|
||||
Note that the compilation options must be given as a single
|
||||
argument to `protoize' or `unprotoize'. If you want to specify
|
||||
several `gcc' options, you must quote the entire set of
|
||||
compilation options to make them a single word in the shell.
|
||||
|
||||
There are certain `gcc' arguments that you cannot use, because they
|
||||
would produce the wrong kind of output. These include `-g', `-O',
|
||||
`-c', `-S', and `-o' If you include these in the
|
||||
COMPILATION-OPTIONS, they are ignored.
|
||||
|
||||
`-C'
|
||||
Rename files to end in `.C' instead of `.c'. This is convenient
|
||||
if you are converting a C program to C++. This option applies
|
||||
only to `protoize'.
|
||||
|
||||
`-g'
|
||||
Add explicit global declarations. This means inserting explicit
|
||||
declarations at the beginning of each source file for each function
|
||||
that is called in the file and was not declared. These
|
||||
declarations precede the first function definition that contains a
|
||||
call to an undeclared function. This option applies only to
|
||||
`protoize'.
|
||||
|
||||
`-i STRING'
|
||||
Indent old-style parameter declarations with the string STRING.
|
||||
This option applies only to `protoize'.
|
||||
|
||||
`unprotoize' converts prototyped function definitions to old-style
|
||||
function definitions, where the arguments are declared between the
|
||||
argument list and the initial `{'. By default, `unprotoize' uses
|
||||
five spaces as the indentation. If you want to indent with just
|
||||
one space instead, use `-i " "'.
|
||||
|
||||
`-k'
|
||||
Keep the `.X' files. Normally, they are deleted after conversion
|
||||
is finished.
|
||||
|
||||
`-l'
|
||||
Add explicit local declarations. `protoize' with `-l' inserts a
|
||||
prototype declaration for each function in each block which calls
|
||||
the function without any declaration. This option applies only to
|
||||
`protoize'.
|
||||
|
||||
`-n'
|
||||
Make no real changes. This mode just prints information about the
|
||||
conversions that would have been done without `-n'.
|
||||
|
||||
`-N'
|
||||
Make no `.save' files. The original files are simply deleted.
|
||||
Use this option with caution.
|
||||
|
||||
`-p PROGRAM'
|
||||
Use the program PROGRAM as the compiler. Normally, the name `gcc'
|
||||
is used.
|
||||
|
||||
`-q'
|
||||
Work quietly. Most warnings are suppressed.
|
||||
|
||||
`-v'
|
||||
Print the version number, just like `-v' for `gcc'.
|
||||
|
||||
If you need special compiler options to compile one of your program's
|
||||
source files, then you should generate that file's `.X' file specially,
|
||||
by running `gcc' on that source file with the appropriate options and
|
||||
the option `-aux-info'. Then run `protoize' on the entire set of
|
||||
files. `protoize' will use the existing `.X' file because it is newer
|
||||
than the source file. For example:
|
||||
|
||||
gcc -Dfoo=bar file1.c -aux-info
|
||||
protoize *.c
|
||||
|
||||
You need to include the special files along with the rest in the
|
||||
`protoize' command, even though their `.X' files already exist, because
|
||||
otherwise they won't get converted.
|
||||
|
||||
*Note Protoize Caveats::, for more information on how to use
|
||||
`protoize' successfully.
|
||||
|
||||
Note most of this information is out of date and superceded by the
|
||||
EGCS install procedures. It is provided for historical reference only.
|
||||
|
||||
|
||||
File: gcc.info, Node: Installation, Next: C Extensions, Prev: Invoking GCC, Up: Top
|
||||
|
||||
Installing GNU CC
|
||||
*****************
|
||||
|
||||
* Menu:
|
||||
|
||||
* Configuration Files:: Files created by running `configure'.
|
||||
* Configurations:: Configurations Supported by GNU CC.
|
||||
* Other Dir:: Compiling in a separate directory (not where the source is).
|
||||
* Cross-Compiler:: Building and installing a cross-compiler.
|
||||
* Sun Install:: See below for installation on the Sun.
|
||||
* VMS Install:: See below for installation on VMS.
|
||||
* Collect2:: How `collect2' works; how it finds `ld'.
|
||||
* Header Dirs:: Understanding the standard header file directories.
|
||||
|
||||
Here is the procedure for installing GNU CC on a GNU or Unix system.
|
||||
See *Note VMS Install::, for VMS systems. In this section we assume you
|
||||
compile in the same directory that contains the source files; see *Note
|
||||
Other Dir::, to find out how to compile in a separate directory on Unix
|
||||
systems.
|
||||
|
||||
You cannot install GNU C by itself on MSDOS; it will not compile
|
||||
under any MSDOS compiler except itself. You need to get the complete
|
||||
compilation package DJGPP, which includes binaries as well as sources,
|
||||
and includes all the necessary compilation tools and libraries.
|
||||
|
||||
1. If you have built GNU CC previously in the same directory for a
|
||||
different target machine, do `make distclean' to delete all files
|
||||
that might be invalid. One of the files this deletes is
|
||||
`Makefile'; if `make distclean' complains that `Makefile' does not
|
||||
exist, it probably means that the directory is already suitably
|
||||
clean.
|
||||
|
||||
2. On a System V release 4 system, make sure `/usr/bin' precedes
|
||||
`/usr/ucb' in `PATH'. The `cc' command in `/usr/ucb' uses
|
||||
libraries which have bugs.
|
||||
|
||||
3. Make sure the Bison parser generator is installed. (This is
|
||||
unnecessary if the Bison output files `c-parse.c' and `cexp.c' are
|
||||
more recent than `c-parse.y' and `cexp.y' and you do not plan to
|
||||
change the `.y' files.)
|
||||
|
||||
Bison versions older than Sept 8, 1988 will produce incorrect
|
||||
output for `c-parse.c'.
|
||||
|
||||
4. If you have chosen a configuration for GNU CC which requires other
|
||||
GNU tools (such as GAS or the GNU linker) instead of the standard
|
||||
system tools, install the required tools in the build directory
|
||||
under the names `as', `ld' or whatever is appropriate. This will
|
||||
enable the compiler to find the proper tools for compilation of
|
||||
the program `enquire'.
|
||||
|
||||
Alternatively, you can do subsequent compilation using a value of
|
||||
the `PATH' environment variable such that the necessary GNU tools
|
||||
come before the standard system tools.
|
||||
|
||||
5. Specify the host, build and target machine configurations. You do
|
||||
this when you run the `configure' script.
|
||||
|
||||
The "build" machine is the system which you are using, the "host"
|
||||
machine is the system where you want to run the resulting compiler
|
||||
(normally the build machine), and the "target" machine is the
|
||||
system for which you want the compiler to generate code.
|
||||
|
||||
If you are building a compiler to produce code for the machine it
|
||||
runs on (a native compiler), you normally do not need to specify
|
||||
any operands to `configure'; it will try to guess the type of
|
||||
machine you are on and use that as the build, host and target
|
||||
machines. So you don't need to specify a configuration when
|
||||
building a native compiler unless `configure' cannot figure out
|
||||
what your configuration is or guesses wrong.
|
||||
|
||||
In those cases, specify the build machine's "configuration name"
|
||||
with the `--host' option; the host and target will default to be
|
||||
the same as the host machine. (If you are building a
|
||||
cross-compiler, see *Note Cross-Compiler::.)
|
||||
|
||||
Here is an example:
|
||||
|
||||
./configure --host=sparc-sun-sunos4.1
|
||||
|
||||
A configuration name may be canonical or it may be more or less
|
||||
abbreviated.
|
||||
|
||||
A canonical configuration name has three parts, separated by
|
||||
dashes. It looks like this: `CPU-COMPANY-SYSTEM'. (The three
|
||||
parts may themselves contain dashes; `configure' can figure out
|
||||
which dashes serve which purpose.) For example,
|
||||
`m68k-sun-sunos4.1' specifies a Sun 3.
|
||||
|
||||
You can also replace parts of the configuration by nicknames or
|
||||
aliases. For example, `sun3' stands for `m68k-sun', so
|
||||
`sun3-sunos4.1' is another way to specify a Sun 3. You can also
|
||||
use simply `sun3-sunos', since the version of SunOS is assumed by
|
||||
default to be version 4.
|
||||
|
||||
You can specify a version number after any of the system types,
|
||||
and some of the CPU types. In most cases, the version is
|
||||
irrelevant, and will be ignored. So you might as well specify the
|
||||
version if you know it.
|
||||
|
||||
See *Note Configurations::, for a list of supported configuration
|
||||
names and notes on many of the configurations. You should check
|
||||
the notes in that section before proceeding any further with the
|
||||
installation of GNU CC.
|
||||
|
||||
6. When running `configure', you may also need to specify certain
|
||||
additional options that describe variant hardware and software
|
||||
configurations. These are `--with-gnu-as', `--with-gnu-ld',
|
||||
`--with-stabs' and `--nfp'.
|
||||
|
||||
`--with-gnu-as'
|
||||
If you will use GNU CC with the GNU assembler (GAS), you
|
||||
should declare this by using the `--with-gnu-as' option when
|
||||
you run `configure'.
|
||||
|
||||
Using this option does not install GAS. It only modifies the
|
||||
output of GNU CC to work with GAS. Building and installing
|
||||
GAS is up to you.
|
||||
|
||||
Conversely, if you *do not* wish to use GAS and do not specify
|
||||
`--with-gnu-as' when building GNU CC, it is up to you to make
|
||||
sure that GAS is not installed. GNU CC searches for a
|
||||
program named `as' in various directories; if the program it
|
||||
finds is GAS, then it runs GAS. If you are not sure where
|
||||
GNU CC finds the assembler it is using, try specifying `-v'
|
||||
when you run it.
|
||||
|
||||
The systems where it makes a difference whether you use GAS
|
||||
are
|
||||
`hppa1.0-ANY-ANY', `hppa1.1-ANY-ANY', `i386-ANY-sysv',
|
||||
`i386-ANY-isc',
|
||||
`i860-ANY-bsd', `m68k-bull-sysv',
|
||||
`m68k-hp-hpux', `m68k-sony-bsd',
|
||||
`m68k-altos-sysv', `m68000-hp-hpux',
|
||||
`m68000-att-sysv', `ANY-lynx-lynxos', and `mips-ANY'). On
|
||||
any other system, `--with-gnu-as' has no effect.
|
||||
|
||||
On the systems listed above (except for the HP-PA, for ISC on
|
||||
the 386, and for `mips-sgi-irix5.*'), if you use GAS, you
|
||||
should also use the GNU linker (and specify `--with-gnu-ld').
|
||||
|
||||
`--with-gnu-ld'
|
||||
Specify the option `--with-gnu-ld' if you plan to use the GNU
|
||||
linker with GNU CC.
|
||||
|
||||
This option does not cause the GNU linker to be installed; it
|
||||
just modifies the behavior of GNU CC to work with the GNU
|
||||
linker.
|
||||
|
||||
`--with-stabs'
|
||||
On MIPS based systems and on Alphas, you must specify whether
|
||||
you want GNU CC to create the normal ECOFF debugging format,
|
||||
or to use BSD-style stabs passed through the ECOFF symbol
|
||||
table. The normal ECOFF debug format cannot fully handle
|
||||
languages other than C. BSD stabs format can handle other
|
||||
languages, but it only works with the GNU debugger GDB.
|
||||
|
||||
Normally, GNU CC uses the ECOFF debugging format by default;
|
||||
if you prefer BSD stabs, specify `--with-stabs' when you
|
||||
configure GNU CC.
|
||||
|
||||
No matter which default you choose when you configure GNU CC,
|
||||
the user can use the `-gcoff' and `-gstabs+' options to
|
||||
specify explicitly the debug format for a particular
|
||||
compilation.
|
||||
|
||||
`--with-stabs' is meaningful on the ISC system on the 386,
|
||||
also, if `--with-gas' is used. It selects use of stabs
|
||||
debugging information embedded in COFF output. This kind of
|
||||
debugging information supports C++ well; ordinary COFF
|
||||
debugging information does not.
|
||||
|
||||
`--with-stabs' is also meaningful on 386 systems running
|
||||
SVR4. It selects use of stabs debugging information embedded
|
||||
in ELF output. The C++ compiler currently (2.6.0) does not
|
||||
support the DWARF debugging information normally used on 386
|
||||
SVR4 platforms; stabs provide a workable alternative. This
|
||||
requires gas and gdb, as the normal SVR4 tools can not
|
||||
generate or interpret stabs.
|
||||
|
||||
`--nfp'
|
||||
On certain systems, you must specify whether the machine has
|
||||
a floating point unit. These systems include
|
||||
`m68k-sun-sunosN' and `m68k-isi-bsd'. On any other system,
|
||||
`--nfp' currently has no effect, though perhaps there are
|
||||
other systems where it could usefully make a difference.
|
||||
|
||||
`--enable-haifa'
|
||||
`--disable-haifa'
|
||||
Use `--enable-haifa' to enable use of an experimental
|
||||
instruction scheduler (from IBM Haifa). This may or may not
|
||||
produce better code. Some targets on which it is known to be
|
||||
a win enable it by default; use `--disable-haifa' to disable
|
||||
it in these cases. `configure' will print out whether the
|
||||
Haifa scheduler is enabled when it is run.
|
||||
|
||||
`--enable-threads=TYPE'
|
||||
Certain systems, notably Linux-based GNU systems, can't be
|
||||
relied on to supply a threads facility for the Objective C
|
||||
runtime and so will default to single-threaded runtime. They
|
||||
may, however, have a library threads implementation
|
||||
available, in which case threads can be enabled with this
|
||||
option by supplying a suitable TYPE, probably `posix'. The
|
||||
possibilities for TYPE are `single', `posix', `win32',
|
||||
`solaris', `irix' and `mach'.
|
||||
|
||||
`--enable-checking'
|
||||
When you specify this option, the compiler is built to
|
||||
perform checking of tree node types when referencing fields
|
||||
of that node. This does not change the generated code, but
|
||||
adds error checking within the compiler. This will slow down
|
||||
the compiler and may only work properly if you are building
|
||||
the compiler with GNU C.
|
||||
|
||||
The `configure' script searches subdirectories of the source
|
||||
directory for other compilers that are to be integrated into
|
||||
GNU CC. The GNU compiler for C++, called G++ is in a
|
||||
subdirectory named `cp'. `configure' inserts rules into
|
||||
`Makefile' to build all of those compilers.
|
||||
|
||||
Here we spell out what files will be set up by `configure'.
|
||||
Normally you need not be concerned with these files.
|
||||
|
||||
* A file named `config.h' is created that contains a
|
||||
`#include' of the top-level config file for the machine
|
||||
you will run the compiler on (*note Config::.). This
|
||||
file is responsible for defining information about the
|
||||
host machine. It includes `tm.h'.
|
||||
|
||||
The top-level config file is located in the subdirectory
|
||||
`config'. Its name is always `xm-SOMETHING.h'; usually
|
||||
`xm-MACHINE.h', but there are some exceptions.
|
||||
|
||||
If your system does not support symbolic links, you
|
||||
might want to set up `config.h' to contain a `#include'
|
||||
command which refers to the appropriate file.
|
||||
|
||||
* A file named `tconfig.h' is created which includes the
|
||||
top-level config file for your target machine. This is
|
||||
used for compiling certain programs to run on that
|
||||
machine.
|
||||
|
||||
* A file named `tm.h' is created which includes the
|
||||
machine-description macro file for your target machine.
|
||||
It should be in the subdirectory `config' and its name
|
||||
is often `MACHINE.h'.
|
||||
|
||||
`--enable-nls'
|
||||
`--disable-nls'
|
||||
The `--enable-nls' option enables Native Language Support
|
||||
(NLS), which lets GCC output diagnostics in languages other
|
||||
than American English. No translations are available yet, so
|
||||
the main users of this option now are those translating GCC's
|
||||
diagnostics who want to test their work. Once translations
|
||||
become available, Native Language Support will become enabled
|
||||
by default. The `--disable-nls' option disables NLS.
|
||||
|
||||
`--with-included-gettext'
|
||||
If NLS is enabled, the GCC build procedure normally attempts
|
||||
to use the host's `gettext' libraries, and falls back on
|
||||
GCC's copy of the GNU `gettext' library only if the host
|
||||
libraries do not suffice. The `--with-included-gettext'
|
||||
option causes the build procedure to prefer its copy of GNU
|
||||
`gettext'.
|
||||
|
||||
`--with-catgets'
|
||||
If NLS is enabled, and if the host lacks `gettext' but has the
|
||||
inferior `catgets' interface, the GCC build procedure normally
|
||||
ignores `catgets' and instead uses GCC's copy of the GNU
|
||||
`gettext' library. The `--with-catgets' option causes the
|
||||
build procedure to use the host's `catgets' in this situation.
|
||||
|
||||
7. In certain cases, you should specify certain other options when
|
||||
you run `configure'.
|
||||
|
||||
* The standard directory for installing GNU CC is
|
||||
`/usr/local/lib'. If you want to install its files somewhere
|
||||
else, specify `--prefix=DIR' when you run `configure'. Here
|
||||
DIR is a directory name to use instead of `/usr/local' for
|
||||
all purposes with one exception: the directory
|
||||
`/usr/local/include' is searched for header files no matter
|
||||
where you install the compiler. To override this name, use
|
||||
the `--with-local-prefix' option below. The directory you
|
||||
specify need not exist, but its parent directory must exist.
|
||||
|
||||
* Specify `--with-local-prefix=DIR' if you want the compiler to
|
||||
search directory `DIR/include' for locally installed header
|
||||
files *instead* of `/usr/local/include'.
|
||||
|
||||
You should specify `--with-local-prefix' *only* if your site
|
||||
has a different convention (not `/usr/local') for where to put
|
||||
site-specific files.
|
||||
|
||||
The default value for `--with-local-prefix' is `/usr/local'
|
||||
regardless of the value of `--prefix'. Specifying `--prefix'
|
||||
has no effect on which directory GNU CC searches for local
|
||||
header files. This may seem counterintuitive, but actually
|
||||
it is logical.
|
||||
|
||||
The purpose of `--prefix' is to specify where to *install GNU
|
||||
CC*. The local header files in `/usr/local/include'--if you
|
||||
put any in that directory--are not part of GNU CC. They are
|
||||
part of other programs--perhaps many others. (GNU CC
|
||||
installs its own header files in another directory which is
|
||||
based on the `--prefix' value.)
|
||||
|
||||
*Do not* specify `/usr' as the `--with-local-prefix'! The
|
||||
directory you use for `--with-local-prefix' *must not* contain
|
||||
any of the system's standard header files. If it did contain
|
||||
them, certain programs would be miscompiled (including GNU
|
||||
Emacs, on certain targets), because this would override and
|
||||
nullify the header file corrections made by the `fixincludes'
|
||||
script.
|
||||
|
||||
Indications are that people who use this option use it based
|
||||
on mistaken ideas of what it is for. People use it as if it
|
||||
specified where to install part of GNU CC. Perhaps they make
|
||||
this assumption because installing GNU CC creates the
|
||||
directory.
|
||||
|
||||
8. Build the compiler. Just type `make LANGUAGES=c' in the compiler
|
||||
directory.
|
||||
|
||||
`LANGUAGES=c' specifies that only the C compiler should be
|
||||
compiled. The makefile normally builds compilers for all the
|
||||
supported languages; currently, C, C++ and Objective C. However,
|
||||
C is the only language that is sure to work when you build with
|
||||
other non-GNU C compilers. In addition, building anything but C
|
||||
at this stage is a waste of time.
|
||||
|
||||
In general, you can specify the languages to build by typing the
|
||||
argument `LANGUAGES="LIST"', where LIST is one or more words from
|
||||
the list `c', `c++', and `objective-c'. If you have any
|
||||
additional GNU compilers as subdirectories of the GNU CC source
|
||||
directory, you may also specify their names in this list.
|
||||
|
||||
Ignore any warnings you may see about "statement not reached" in
|
||||
`insn-emit.c'; they are normal. Also, warnings about "unknown
|
||||
escape sequence" are normal in `genopinit.c' and perhaps some
|
||||
other files. Likewise, you should ignore warnings about "constant
|
||||
is so large that it is unsigned" in `insn-emit.c' and
|
||||
`insn-recog.c', a warning about a comparison always being zero in
|
||||
`enquire.o', and warnings about shift counts exceeding type widths
|
||||
in `cexp.y'. Any other compilation errors may represent bugs in
|
||||
the port to your machine or operating system, and should be
|
||||
investigated and reported (*note Bugs::.).
|
||||
|
||||
Some compilers fail to compile GNU CC because they have bugs or
|
||||
limitations. For example, the Microsoft compiler is said to run
|
||||
out of macro space. Some Ultrix compilers run out of expression
|
||||
space; then you need to break up the statement where the problem
|
||||
happens.
|
||||
|
||||
9. If you are building a cross-compiler, stop here. *Note
|
||||
Cross-Compiler::.
|
||||
|
||||
10. Move the first-stage object files and executables into a
|
||||
subdirectory with this command:
|
||||
|
||||
make stage1
|
||||
|
||||
The files are moved into a subdirectory named `stage1'. Once
|
||||
installation is complete, you may wish to delete these files with
|
||||
`rm -r stage1'.
|
||||
|
||||
11. If you have chosen a configuration for GNU CC which requires other
|
||||
GNU tools (such as GAS or the GNU linker) instead of the standard
|
||||
system tools, install the required tools in the `stage1'
|
||||
subdirectory under the names `as', `ld' or whatever is
|
||||
appropriate. This will enable the stage 1 compiler to find the
|
||||
proper tools in the following stage.
|
||||
|
||||
Alternatively, you can do subsequent compilation using a value of
|
||||
the `PATH' environment variable such that the necessary GNU tools
|
||||
come before the standard system tools.
|
||||
|
||||
12. Recompile the compiler with itself, with this command:
|
||||
|
||||
make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O2"
|
||||
|
||||
This is called making the stage 2 compiler.
|
||||
|
||||
The command shown above builds compilers for all the supported
|
||||
languages. If you don't want them all, you can specify the
|
||||
languages to build by typing the argument `LANGUAGES="LIST"'. LIST
|
||||
should contain one or more words from the list `c', `c++',
|
||||
`objective-c', and `proto'. Separate the words with spaces.
|
||||
`proto' stands for the programs `protoize' and `unprotoize'; they
|
||||
are not a separate language, but you use `LANGUAGES' to enable or
|
||||
disable their installation.
|
||||
|
||||
If you are going to build the stage 3 compiler, then you might
|
||||
want to build only the C language in stage 2.
|
||||
|
||||
Once you have built the stage 2 compiler, if you are short of disk
|
||||
space, you can delete the subdirectory `stage1'.
|
||||
|
||||
On a 68000 or 68020 system lacking floating point hardware, unless
|
||||
you have selected a `tm.h' file that expects by default that there
|
||||
is no such hardware, do this instead:
|
||||
|
||||
make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O2 -msoft-float"
|
||||
|
||||
13. If you wish to test the compiler by compiling it with itself one
|
||||
more time, install any other necessary GNU tools (such as GAS or
|
||||
the GNU linker) in the `stage2' subdirectory as you did in the
|
||||
`stage1' subdirectory, then do this:
|
||||
|
||||
make stage2
|
||||
make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O2"
|
||||
|
||||
This is called making the stage 3 compiler. Aside from the `-B'
|
||||
option, the compiler options should be the same as when you made
|
||||
the stage 2 compiler. But the `LANGUAGES' option need not be the
|
||||
same. The command shown above builds compilers for all the
|
||||
supported languages; if you don't want them all, you can specify
|
||||
the languages to build by typing the argument `LANGUAGES="LIST"',
|
||||
as described above.
|
||||
|
||||
If you do not have to install any additional GNU tools, you may
|
||||
use the command
|
||||
|
||||
make bootstrap LANGUAGES=LANGUAGE-LIST BOOT_CFLAGS=OPTION-LIST
|
||||
|
||||
instead of making `stage1', `stage2', and performing the two
|
||||
compiler builds.
|
||||
|
||||
14. Compare the latest object files with the stage 2 object files--they
|
||||
ought to be identical, aside from time stamps (if any).
|
||||
|
||||
On some systems, meaningful comparison of object files is
|
||||
impossible; they always appear "different." This is currently
|
||||
true on Solaris and some systems that use ELF object file format.
|
||||
On some versions of Irix on SGI machines and DEC Unix (OSF/1) on
|
||||
Alpha systems, you will not be able to compare the files without
|
||||
specifying `-save-temps'; see the description of individual
|
||||
systems above to see if you get comparison failures. You may have
|
||||
similar problems on other systems.
|
||||
|
||||
Use this command to compare the files:
|
||||
|
||||
make compare
|
||||
|
||||
This will mention any object files that differ between stage 2 and
|
||||
stage 3. Any difference, no matter how innocuous, indicates that
|
||||
the stage 2 compiler has compiled GNU CC incorrectly, and is
|
||||
therefore a potentially serious bug which you should investigate
|
||||
and report (*note Bugs::.).
|
||||
|
||||
If your system does not put time stamps in the object files, then
|
||||
this is a faster way to compare them (using the Bourne shell):
|
||||
|
||||
for file in *.o; do
|
||||
cmp $file stage2/$file
|
||||
done
|
||||
|
||||
If you have built the compiler with the `-mno-mips-tfile' option on
|
||||
MIPS machines, you will not be able to compare the files.
|
||||
|
||||
15. Install the compiler driver, the compiler's passes and run-time
|
||||
support with `make install'. Use the same value for `CC',
|
||||
`CFLAGS' and `LANGUAGES' that you used when compiling the files
|
||||
that are being installed. One reason this is necessary is that
|
||||
some versions of Make have bugs and recompile files gratuitously
|
||||
when you do this step. If you use the same variable values, those
|
||||
files will be recompiled properly.
|
||||
|
||||
For example, if you have built the stage 2 compiler, you can use
|
||||
the following command:
|
||||
|
||||
make install CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O" LANGUAGES="LIST"
|
||||
|
||||
This copies the files `cc1', `cpp' and `libgcc.a' to files `cc1',
|
||||
`cpp' and `libgcc.a' in the directory
|
||||
`/usr/local/lib/gcc-lib/TARGET/VERSION', which is where the
|
||||
compiler driver program looks for them. Here TARGET is the
|
||||
canonicalized form of target machine type specified when you ran
|
||||
`configure', and VERSION is the version number of GNU CC. This
|
||||
naming scheme permits various versions and/or cross-compilers to
|
||||
coexist. It also copies the executables for compilers for other
|
||||
languages (e.g., `cc1plus' for C++) to the same directory.
|
||||
|
||||
This also copies the driver program `xgcc' into
|
||||
`/usr/local/bin/gcc', so that it appears in typical execution
|
||||
search paths. It also copies `gcc.1' into `/usr/local/man/man1'
|
||||
and info pages into `/usr/local/info'.
|
||||
|
||||
On some systems, this command causes recompilation of some files.
|
||||
This is usually due to bugs in `make'. You should either ignore
|
||||
this problem, or use GNU Make.
|
||||
|
||||
*Warning: there is a bug in `alloca' in the Sun library. To avoid
|
||||
this bug, be sure to install the executables of GNU CC that were
|
||||
compiled by GNU CC. (That is, the executables from stage 2 or 3,
|
||||
not stage 1.) They use `alloca' as a built-in function and never
|
||||
the one in the library.*
|
||||
|
||||
(It is usually better to install GNU CC executables from stage 2
|
||||
or 3, since they usually run faster than the ones compiled with
|
||||
some other compiler.)
|
||||
|
||||
16. If you're going to use C++, you need to install the C++ runtime
|
||||
library. This includes all I/O functionality, special class
|
||||
libraries, etc.
|
||||
|
||||
The standard C++ runtime library for GNU CC is called `libstdc++'.
|
||||
An obsolescent library `libg++' may also be available, but it's
|
||||
necessary only for older software that hasn't been converted yet;
|
||||
if you don't know whether you need `libg++' then you probably don't
|
||||
need it.
|
||||
|
||||
Here's one way to build and install `libstdc++' for GNU CC:
|
||||
|
||||
* Build and install GNU CC, so that invoking `gcc' obtains the
|
||||
GNU CC that was just built.
|
||||
|
||||
* Obtain a copy of a compatible `libstdc++' distribution. For
|
||||
example, the `libstdc++-2.8.0.tar.gz' distribution should be
|
||||
compatible with GCC 2.8.0. GCC distributors normally
|
||||
distribute `libstdc++' as well.
|
||||
|
||||
* Set the `CXX' environment variable to `gcc' while running the
|
||||
`libstdc++' distribution's `configure' command. Use the same
|
||||
`configure' options that you used when you invoked GCC's
|
||||
`configure' command.
|
||||
|
||||
* Invoke `make' to build the C++ runtime.
|
||||
|
||||
* Invoke `make install' to install the C++ runtime.
|
||||
|
||||
To summarize, after building and installing GNU CC, invoke the
|
||||
following shell commands in the topmost directory of the C++
|
||||
library distribution. For CONFIGURE-OPTIONS, use the same options
|
||||
that you used to configure GNU CC.
|
||||
|
||||
$ CXX=gcc ./configure CONFIGURE-OPTIONS
|
||||
$ make
|
||||
$ make install
|
||||
|
||||
17. GNU CC includes a runtime library for Objective-C because it is an
|
||||
integral part of the language. You can find the files associated
|
||||
with the library in the subdirectory `objc'. The GNU Objective-C
|
||||
Runtime Library requires header files for the target's C library in
|
||||
order to be compiled,and also requires the header files for the
|
||||
target's thread library if you want thread support. *Note
|
||||
Cross-Compilers and Header Files: Cross Headers, for discussion
|
||||
about header files issues for cross-compilation.
|
||||
|
||||
When you run `configure', it picks the appropriate Objective-C
|
||||
thread implementation file for the target platform. In some
|
||||
situations, you may wish to choose a different back-end as some
|
||||
platforms support multiple thread implementations or you may wish
|
||||
to disable thread support completely. You do this by specifying a
|
||||
value for the OBJC_THREAD_FILE makefile variable on the command
|
||||
line when you run make, for example:
|
||||
|
||||
make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O2" OBJC_THREAD_FILE=thr-single
|
||||
|
||||
Below is a list of the currently available back-ends.
|
||||
|
||||
* thr-single Disable thread support, should work for all
|
||||
platforms.
|
||||
|
||||
* thr-decosf1 DEC OSF/1 thread support.
|
||||
|
||||
* thr-irix SGI IRIX thread support.
|
||||
|
||||
* thr-mach Generic MACH thread support, known to work on
|
||||
NEXTSTEP.
|
||||
|
||||
* thr-os2 IBM OS/2 thread support.
|
||||
|
||||
* thr-posix Generix POSIX thread support.
|
||||
|
||||
* thr-pthreads PCThreads on Linux-based GNU systems.
|
||||
|
||||
* thr-solaris SUN Solaris thread support.
|
||||
|
||||
* thr-win32 Microsoft Win32 API thread support.
|
||||
|
||||
|
||||
File: gcc.info, Node: Configuration Files, Next: Configurations, Up: Installation
|
||||
|
||||
Files Created by `configure'
|
||||
============================
|
||||
|
||||
Here we spell out what files will be set up by `configure'. Normally
|
||||
you need not be concerned with these files.
|
||||
|
||||
* A file named `config.h' is created that contains a `#include' of
|
||||
the top-level config file for the machine you will run the compiler
|
||||
on (*note Config::.). This file is responsible for defining
|
||||
information about the host machine. It includes `tm.h'.
|
||||
|
||||
The top-level config file is located in the subdirectory `config'.
|
||||
Its name is always `xm-SOMETHING.h'; usually `xm-MACHINE.h', but
|
||||
there are some exceptions.
|
||||
|
||||
If your system does not support symbolic links, you might want to
|
||||
set up `config.h' to contain a `#include' command which refers to
|
||||
the appropriate file.
|
||||
|
||||
* A file named `tconfig.h' is created which includes the top-level
|
||||
config file for your target machine. This is used for compiling
|
||||
certain programs to run on that machine.
|
||||
|
||||
* A file named `tm.h' is created which includes the
|
||||
machine-description macro file for your target machine. It should
|
||||
be in the subdirectory `config' and its name is often `MACHINE.h'.
|
||||
|
||||
* The command file `configure' also constructs the file `Makefile'
|
||||
by adding some text to the template file `Makefile.in'. The
|
||||
additional text comes from files in the `config' directory, named
|
||||
`t-TARGET' and `x-HOST'. If these files do not exist, it means
|
||||
nothing needs to be added for a given target or host.
|
||||
|
||||
Executable
+1112
File diff suppressed because it is too large
Load Diff
Executable
+1230
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
Binary file not shown.
Binary file not shown.
Binary file not shown.
@@ -0,0 +1,9 @@
|
||||
This README file is copied into the directory for GCC-only header files
|
||||
when fixincludes is run by the makefile for GCC.
|
||||
|
||||
Many of the files in this directory were made from the standard system
|
||||
header files of this system by the shell script `fixincludes'.
|
||||
They are system-specific, and will not work on any other kind of system.
|
||||
They are also not part of GCC. The reason for making the files here
|
||||
is to fix the places in the header files which use constructs
|
||||
that are incompatible with ANSI C.
|
||||
@@ -0,0 +1,96 @@
|
||||
/* float.h for target with IEEE 32 bit and 64 bit floating point formats */
|
||||
#ifndef _FLOAT_H_
|
||||
#define _FLOAT_H_
|
||||
/* Produced by enquire version 4.3, CWI, Amsterdam */
|
||||
|
||||
/* Radix of exponent representation */
|
||||
#undef FLT_RADIX
|
||||
#define FLT_RADIX 2
|
||||
/* Number of base-FLT_RADIX digits in the significand of a float */
|
||||
#undef FLT_MANT_DIG
|
||||
#define FLT_MANT_DIG 24
|
||||
/* Number of decimal digits of precision in a float */
|
||||
#undef FLT_DIG
|
||||
#define FLT_DIG 6
|
||||
/* Addition rounds to 0: zero, 1: nearest, 2: +inf, 3: -inf, -1: unknown */
|
||||
#undef FLT_ROUNDS
|
||||
#define FLT_ROUNDS 1
|
||||
/* Difference between 1.0 and the minimum float greater than 1.0 */
|
||||
#undef FLT_EPSILON
|
||||
#define FLT_EPSILON 1.19209290e-07F
|
||||
/* Minimum int x such that FLT_RADIX**(x-1) is a normalised float */
|
||||
#undef FLT_MIN_EXP
|
||||
#define FLT_MIN_EXP (-125)
|
||||
/* Minimum normalised float */
|
||||
#undef FLT_MIN
|
||||
#define FLT_MIN 1.17549435e-38F
|
||||
/* Minimum int x such that 10**x is a normalised float */
|
||||
#undef FLT_MIN_10_EXP
|
||||
#define FLT_MIN_10_EXP (-37)
|
||||
/* Maximum int x such that FLT_RADIX**(x-1) is a representable float */
|
||||
#undef FLT_MAX_EXP
|
||||
#define FLT_MAX_EXP 128
|
||||
/* Maximum float */
|
||||
#undef FLT_MAX
|
||||
#define FLT_MAX 3.40282347e+38F
|
||||
/* Maximum int x such that 10**x is a representable float */
|
||||
#undef FLT_MAX_10_EXP
|
||||
#define FLT_MAX_10_EXP 38
|
||||
|
||||
/* Number of base-FLT_RADIX digits in the significand of a double */
|
||||
#undef DBL_MANT_DIG
|
||||
#define DBL_MANT_DIG 53
|
||||
/* Number of decimal digits of precision in a double */
|
||||
#undef DBL_DIG
|
||||
#define DBL_DIG 15
|
||||
/* Difference between 1.0 and the minimum double greater than 1.0 */
|
||||
#undef DBL_EPSILON
|
||||
#define DBL_EPSILON 2.2204460492503131e-16
|
||||
/* Minimum int x such that FLT_RADIX**(x-1) is a normalised double */
|
||||
#undef DBL_MIN_EXP
|
||||
#define DBL_MIN_EXP (-1021)
|
||||
/* Minimum normalised double */
|
||||
#undef DBL_MIN
|
||||
#define DBL_MIN 2.2250738585072014e-308
|
||||
/* Minimum int x such that 10**x is a normalised double */
|
||||
#undef DBL_MIN_10_EXP
|
||||
#define DBL_MIN_10_EXP (-307)
|
||||
/* Maximum int x such that FLT_RADIX**(x-1) is a representable double */
|
||||
#undef DBL_MAX_EXP
|
||||
#define DBL_MAX_EXP 1024
|
||||
/* Maximum double */
|
||||
#undef DBL_MAX
|
||||
#define DBL_MAX 1.7976931348623157e+308
|
||||
/* Maximum int x such that 10**x is a representable double */
|
||||
#undef DBL_MAX_10_EXP
|
||||
#define DBL_MAX_10_EXP 308
|
||||
|
||||
/* Number of base-FLT_RADIX digits in the significand of a long double */
|
||||
#undef LDBL_MANT_DIG
|
||||
#define LDBL_MANT_DIG 53
|
||||
/* Number of decimal digits of precision in a long double */
|
||||
#undef LDBL_DIG
|
||||
#define LDBL_DIG 15
|
||||
/* Difference between 1.0 and the minimum long double greater than 1.0 */
|
||||
#undef LDBL_EPSILON
|
||||
#define LDBL_EPSILON 2.2204460492503131e-16L
|
||||
/* Minimum int x such that FLT_RADIX**(x-1) is a normalised long double */
|
||||
#undef LDBL_MIN_EXP
|
||||
#define LDBL_MIN_EXP (-1021)
|
||||
/* Minimum normalised long double */
|
||||
#undef LDBL_MIN
|
||||
#define LDBL_MIN 2.2250738585072014e-308L
|
||||
/* Minimum int x such that 10**x is a normalised long double */
|
||||
#undef LDBL_MIN_10_EXP
|
||||
#define LDBL_MIN_10_EXP (-307)
|
||||
/* Maximum int x such that FLT_RADIX**(x-1) is a representable long double */
|
||||
#undef LDBL_MAX_EXP
|
||||
#define LDBL_MAX_EXP 1024
|
||||
/* Maximum long double */
|
||||
#undef LDBL_MAX
|
||||
#define LDBL_MAX 1.7976931348623157e+308L
|
||||
/* Maximum int x such that 10**x is a representable long double */
|
||||
#undef LDBL_MAX_10_EXP
|
||||
#define LDBL_MAX_10_EXP 308
|
||||
|
||||
#endif /* _FLOAT_H_ */
|
||||
@@ -0,0 +1,15 @@
|
||||
/* Macros for C programs written in national variants of ISO 646. */
|
||||
|
||||
#ifndef __cplusplus
|
||||
#define and &&
|
||||
#define and_eq &=
|
||||
#define bitand &
|
||||
#define bitor |
|
||||
#define compl ~
|
||||
#define not !
|
||||
#define not_eq !=
|
||||
#define or ||
|
||||
#define or_eq |=
|
||||
#define xor ^
|
||||
#define xor_eq ^=
|
||||
#endif
|
||||
@@ -0,0 +1,98 @@
|
||||
#ifndef _LIMITS_H___
|
||||
#ifndef _MACH_MACHLIMITS_H_
|
||||
|
||||
/* _MACH_MACHLIMITS_H_ is used on OSF/1. */
|
||||
#define _LIMITS_H___
|
||||
#define _MACH_MACHLIMITS_H_
|
||||
|
||||
/* Number of bits in a `char'. */
|
||||
#undef CHAR_BIT
|
||||
#define CHAR_BIT 8
|
||||
|
||||
/* Maximum length of a multibyte character. */
|
||||
#ifndef MB_LEN_MAX
|
||||
#define MB_LEN_MAX 1
|
||||
#endif
|
||||
|
||||
/* Minimum and maximum values a `signed char' can hold. */
|
||||
#undef SCHAR_MIN
|
||||
#define SCHAR_MIN (-128)
|
||||
#undef SCHAR_MAX
|
||||
#define SCHAR_MAX 127
|
||||
|
||||
/* Maximum value an `unsigned char' can hold. (Minimum is 0). */
|
||||
#undef UCHAR_MAX
|
||||
#define UCHAR_MAX 255
|
||||
|
||||
/* Minimum and maximum values a `char' can hold. */
|
||||
#ifdef __CHAR_UNSIGNED__
|
||||
#undef CHAR_MIN
|
||||
#define CHAR_MIN 0
|
||||
#undef CHAR_MAX
|
||||
#define CHAR_MAX 255
|
||||
#else
|
||||
#undef CHAR_MIN
|
||||
#define CHAR_MIN (-128)
|
||||
#undef CHAR_MAX
|
||||
#define CHAR_MAX 127
|
||||
#endif
|
||||
|
||||
/* Minimum and maximum values a `signed short int' can hold. */
|
||||
#undef SHRT_MIN
|
||||
/* For the sake of 16 bit hosts, we may not use -32768 */
|
||||
#define SHRT_MIN (-32767-1)
|
||||
#undef SHRT_MAX
|
||||
#define SHRT_MAX 32767
|
||||
|
||||
/* Maximum value an `unsigned short int' can hold. (Minimum is 0). */
|
||||
#undef USHRT_MAX
|
||||
#define USHRT_MAX 65535
|
||||
|
||||
/* Minimum and maximum values a `signed int' can hold. */
|
||||
#ifndef __INT_MAX__
|
||||
#define __INT_MAX__ 2147483647
|
||||
#endif
|
||||
#undef INT_MIN
|
||||
#define INT_MIN (-INT_MAX-1)
|
||||
#undef INT_MAX
|
||||
#define INT_MAX __INT_MAX__
|
||||
|
||||
/* Maximum value an `unsigned int' can hold. (Minimum is 0). */
|
||||
#undef UINT_MAX
|
||||
#define UINT_MAX (INT_MAX * 2U + 1)
|
||||
|
||||
/* Minimum and maximum values a `signed long int' can hold.
|
||||
(Same as `int'). */
|
||||
#ifndef __LONG_MAX__
|
||||
#if defined (__alpha__) || defined (__sparc_v9__) || defined (__sparcv9)
|
||||
#define __LONG_MAX__ 9223372036854775807L
|
||||
#else
|
||||
#define __LONG_MAX__ 2147483647L
|
||||
#endif /* __alpha__ || sparc64 */
|
||||
#endif
|
||||
#undef LONG_MIN
|
||||
#define LONG_MIN (-LONG_MAX-1)
|
||||
#undef LONG_MAX
|
||||
#define LONG_MAX __LONG_MAX__
|
||||
|
||||
/* Maximum value an `unsigned long int' can hold. (Minimum is 0). */
|
||||
#undef ULONG_MAX
|
||||
#define ULONG_MAX (LONG_MAX * 2UL + 1)
|
||||
|
||||
#if defined (__GNU_LIBRARY__) ? defined (__USE_GNU) : !defined (__STRICT_ANSI__)
|
||||
/* Minimum and maximum values a `signed long long int' can hold. */
|
||||
#ifndef __LONG_LONG_MAX__
|
||||
#define __LONG_LONG_MAX__ 9223372036854775807LL
|
||||
#endif
|
||||
#undef LONG_LONG_MIN
|
||||
#define LONG_LONG_MIN (-LONG_LONG_MAX-1)
|
||||
#undef LONG_LONG_MAX
|
||||
#define LONG_LONG_MAX __LONG_LONG_MAX__
|
||||
|
||||
/* Maximum value an `unsigned long long int' can hold. (Minimum is 0). */
|
||||
#undef ULONG_LONG_MAX
|
||||
#define ULONG_LONG_MAX (LONG_LONG_MAX * 2ULL + 1)
|
||||
#endif
|
||||
|
||||
#endif /* _MACH_MACHLIMITS_H_ */
|
||||
#endif /* _LIMITS_H___ */
|
||||
@@ -0,0 +1,4 @@
|
||||
/* This header file is to avoid trouble with semi-ANSI header files
|
||||
on the Convex in system version 8.0. */
|
||||
|
||||
#define _PROTO(list) ()
|
||||
@@ -0,0 +1,212 @@
|
||||
/* stdarg.h for GNU.
|
||||
Note that the type used in va_arg is supposed to match the
|
||||
actual type **after default promotions**.
|
||||
Thus, va_arg (..., short) is not valid. */
|
||||
|
||||
#ifndef _STDARG_H
|
||||
#ifndef _ANSI_STDARG_H_
|
||||
#ifndef __need___va_list
|
||||
#define _STDARG_H
|
||||
#define _ANSI_STDARG_H_
|
||||
#endif /* not __need___va_list */
|
||||
#undef __need___va_list
|
||||
|
||||
#ifdef __clipper__
|
||||
#include "va-clipper.h"
|
||||
#else
|
||||
#ifdef __m88k__
|
||||
#include "va-m88k.h"
|
||||
#else
|
||||
#ifdef __i860__
|
||||
#include "va-i860.h"
|
||||
#else
|
||||
#ifdef __hppa__
|
||||
#include "va-pa.h"
|
||||
#else
|
||||
#ifdef __mips__
|
||||
#include "va-mips.h"
|
||||
#else
|
||||
#ifdef __sparc__
|
||||
#include "va-sparc.h"
|
||||
#else
|
||||
#ifdef __i960__
|
||||
#include "va-i960.h"
|
||||
#else
|
||||
#ifdef __alpha__
|
||||
#include "va-alpha.h"
|
||||
#else
|
||||
#if defined (__H8300__) || defined (__H8300H__) || defined (__H8300S__)
|
||||
#include "va-h8300.h"
|
||||
#else
|
||||
#if defined (__PPC__) && (defined (_CALL_SYSV) || defined (_WIN32))
|
||||
#include "va-ppc.h"
|
||||
#else
|
||||
#ifdef __arc__
|
||||
#include "va-arc.h"
|
||||
#else
|
||||
#ifdef __M32R__
|
||||
#include "va-m32r.h"
|
||||
#else
|
||||
#ifdef __sh__
|
||||
#include "va-sh.h"
|
||||
#else
|
||||
#ifdef __mn10300__
|
||||
#include "va-mn10300.h"
|
||||
#else
|
||||
#ifdef __mn10200__
|
||||
#include "va-mn10200.h"
|
||||
#else
|
||||
#ifdef __v850__
|
||||
#include "va-v850.h"
|
||||
#else
|
||||
#if defined (_TMS320C4x) || defined (_TMS320C3x)
|
||||
#include <va-c4x.h>
|
||||
#else
|
||||
|
||||
/* Define __gnuc_va_list. */
|
||||
|
||||
#ifndef __GNUC_VA_LIST
|
||||
#define __GNUC_VA_LIST
|
||||
#if defined(__svr4__) || defined(_AIX) || defined(_M_UNIX) || defined(__NetBSD__)
|
||||
typedef char *__gnuc_va_list;
|
||||
#else
|
||||
typedef void *__gnuc_va_list;
|
||||
#endif
|
||||
#endif
|
||||
|
||||
/* Define the standard macros for the user,
|
||||
if this invocation was from the user program. */
|
||||
#ifdef _STDARG_H
|
||||
|
||||
/* Amount of space required in an argument list for an arg of type TYPE.
|
||||
TYPE may alternatively be an expression whose type is used. */
|
||||
|
||||
#if defined(sysV68)
|
||||
#define __va_rounded_size(TYPE) \
|
||||
(((sizeof (TYPE) + sizeof (short) - 1) / sizeof (short)) * sizeof (short))
|
||||
#elif defined(_AIX)
|
||||
#define __va_rounded_size(TYPE) \
|
||||
(((sizeof (TYPE) + sizeof (long) - 1) / sizeof (long)) * sizeof (long))
|
||||
#else
|
||||
#define __va_rounded_size(TYPE) \
|
||||
(((sizeof (TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof (int))
|
||||
#endif
|
||||
|
||||
#define va_start(AP, LASTARG) \
|
||||
(AP = ((__gnuc_va_list) __builtin_next_arg (LASTARG)))
|
||||
|
||||
#undef va_end
|
||||
void va_end (__gnuc_va_list); /* Defined in libgcc.a */
|
||||
#define va_end(AP) ((void)0)
|
||||
|
||||
/* We cast to void * and then to TYPE * because this avoids
|
||||
a warning about increasing the alignment requirement. */
|
||||
|
||||
#if (defined (__arm__) && ! defined (__ARMEB__)) || defined (__i386__) || defined (__i860__) || defined (__ns32000__) || defined (__vax__)
|
||||
/* This is for little-endian machines; small args are padded upward. */
|
||||
#define va_arg(AP, TYPE) \
|
||||
(AP = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (TYPE)), \
|
||||
*((TYPE *) (void *) ((char *) (AP) - __va_rounded_size (TYPE))))
|
||||
#else /* big-endian */
|
||||
/* This is for big-endian machines; small args are padded downward. */
|
||||
#define va_arg(AP, TYPE) \
|
||||
(AP = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (TYPE)), \
|
||||
*((TYPE *) (void *) ((char *) (AP) \
|
||||
- ((sizeof (TYPE) < __va_rounded_size (char) \
|
||||
? sizeof (TYPE) : __va_rounded_size (TYPE))))))
|
||||
#endif /* big-endian */
|
||||
|
||||
/* Copy __gnuc_va_list into another variable of this type. */
|
||||
#define __va_copy(dest, src) (dest) = (src)
|
||||
|
||||
#endif /* _STDARG_H */
|
||||
|
||||
#endif /* not TMS320C3x or TMS320C4x */
|
||||
#endif /* not v850 */
|
||||
#endif /* not mn10200 */
|
||||
#endif /* not mn10300 */
|
||||
#endif /* not sh */
|
||||
#endif /* not m32r */
|
||||
#endif /* not arc */
|
||||
#endif /* not powerpc with V.4 calling sequence */
|
||||
#endif /* not h8300 */
|
||||
#endif /* not alpha */
|
||||
#endif /* not i960 */
|
||||
#endif /* not sparc */
|
||||
#endif /* not mips */
|
||||
#endif /* not hppa */
|
||||
#endif /* not i860 */
|
||||
#endif /* not m88k */
|
||||
#endif /* not clipper */
|
||||
|
||||
#ifdef _STDARG_H
|
||||
/* Define va_list, if desired, from __gnuc_va_list. */
|
||||
/* We deliberately do not define va_list when called from
|
||||
stdio.h, because ANSI C says that stdio.h is not supposed to define
|
||||
va_list. stdio.h needs to have access to that data type,
|
||||
but must not use that name. It should use the name __gnuc_va_list,
|
||||
which is safe because it is reserved for the implementation. */
|
||||
|
||||
#ifdef _HIDDEN_VA_LIST /* On OSF1, this means varargs.h is "half-loaded". */
|
||||
#undef _VA_LIST
|
||||
#endif
|
||||
|
||||
#ifdef _BSD_VA_LIST
|
||||
#undef _BSD_VA_LIST
|
||||
#endif
|
||||
|
||||
#if defined(__svr4__) || (defined(_SCO_DS) && !defined(__VA_LIST))
|
||||
/* SVR4.2 uses _VA_LIST for an internal alias for va_list,
|
||||
so we must avoid testing it and setting it here.
|
||||
SVR4 uses _VA_LIST as a flag in stdarg.h, but we should
|
||||
have no conflict with that. */
|
||||
#ifndef _VA_LIST_
|
||||
#define _VA_LIST_
|
||||
#ifdef __i860__
|
||||
#ifndef _VA_LIST
|
||||
#define _VA_LIST va_list
|
||||
#endif
|
||||
#endif /* __i860__ */
|
||||
typedef __gnuc_va_list va_list;
|
||||
#ifdef _SCO_DS
|
||||
#define __VA_LIST
|
||||
#endif
|
||||
#endif /* _VA_LIST_ */
|
||||
#else /* not __svr4__ || _SCO_DS */
|
||||
|
||||
/* The macro _VA_LIST_ is the same thing used by this file in Ultrix.
|
||||
But on BSD NET2 we must not test or define or undef it.
|
||||
(Note that the comments in NET 2's ansi.h
|
||||
are incorrect for _VA_LIST_--see stdio.h!) */
|
||||
#if !defined (_VA_LIST_) || defined (__BSD_NET2__) || defined (____386BSD____) || defined (__bsdi__) || defined (__sequent__) || defined (__FreeBSD__) || defined(WINNT)
|
||||
/* The macro _VA_LIST_DEFINED is used in Windows NT 3.5 */
|
||||
#ifndef _VA_LIST_DEFINED
|
||||
/* The macro _VA_LIST is used in SCO Unix 3.2. */
|
||||
#ifndef _VA_LIST
|
||||
/* The macro _VA_LIST_T_H is used in the Bull dpx2 */
|
||||
#ifndef _VA_LIST_T_H
|
||||
typedef __gnuc_va_list va_list;
|
||||
#endif /* not _VA_LIST_T_H */
|
||||
#endif /* not _VA_LIST */
|
||||
#endif /* not _VA_LIST_DEFINED */
|
||||
#if !(defined (__BSD_NET2__) || defined (____386BSD____) || defined (__bsdi__) || defined (__sequent__) || defined (__FreeBSD__))
|
||||
#define _VA_LIST_
|
||||
#endif
|
||||
#ifndef _VA_LIST
|
||||
#define _VA_LIST
|
||||
#endif
|
||||
#ifndef _VA_LIST_DEFINED
|
||||
#define _VA_LIST_DEFINED
|
||||
#endif
|
||||
#ifndef _VA_LIST_T_H
|
||||
#define _VA_LIST_T_H
|
||||
#endif
|
||||
|
||||
#endif /* not _VA_LIST_, except on certain systems */
|
||||
|
||||
#endif /* not __svr4__ */
|
||||
|
||||
#endif /* _STDARG_H */
|
||||
|
||||
#endif /* not _ANSI_STDARG_H_ */
|
||||
#endif /* not _STDARG_H */
|
||||
@@ -0,0 +1,20 @@
|
||||
/* stdbool.h for GNU. */
|
||||
#ifndef __STDBOOL_H__
|
||||
#define __STDBOOL_H__ 1
|
||||
|
||||
/* The type `bool' must promote to `int' or `unsigned int'. The constants
|
||||
`true' and `false' must have the value 0 and 1 respectively. */
|
||||
typedef enum
|
||||
{
|
||||
false = 0,
|
||||
true = 1
|
||||
} bool;
|
||||
|
||||
/* The names `true' and `false' must also be made available as macros. */
|
||||
#define false false
|
||||
#define true true
|
||||
|
||||
/* Signal that all the definitions are present. */
|
||||
#define __bool_true_false_are_defined 1
|
||||
|
||||
#endif /* stdbool.h */
|
||||
@@ -0,0 +1,342 @@
|
||||
#if (!defined(_STDDEF_H) && !defined(_STDDEF_H_) && !defined(_ANSI_STDDEF_H) \
|
||||
&& !defined(__STDDEF_H__)) \
|
||||
|| defined(__need_wchar_t) || defined(__need_size_t) \
|
||||
|| defined(__need_ptrdiff_t) || defined(__need_NULL) \
|
||||
|| defined(__need_wint_t)
|
||||
|
||||
/* Any one of these symbols __need_* means that GNU libc
|
||||
wants us just to define one data type. So don't define
|
||||
the symbols that indicate this file's entire job has been done. */
|
||||
#if (!defined(__need_wchar_t) && !defined(__need_size_t) \
|
||||
&& !defined(__need_ptrdiff_t) && !defined(__need_NULL) \
|
||||
&& !defined(__need_wint_t))
|
||||
#define _STDDEF_H
|
||||
#define _STDDEF_H_
|
||||
/* snaroff@next.com says the NeXT needs this. */
|
||||
#define _ANSI_STDDEF_H
|
||||
/* Irix 5.1 needs this. */
|
||||
#define __STDDEF_H__
|
||||
#endif
|
||||
|
||||
#ifndef __sys_stdtypes_h
|
||||
/* This avoids lossage on SunOS but only if stdtypes.h comes first.
|
||||
There's no way to win with the other order! Sun lossage. */
|
||||
|
||||
/* On 4.3bsd-net2, make sure ansi.h is included, so we have
|
||||
one less case to deal with in the following. */
|
||||
#if defined (__BSD_NET2__) || defined (____386BSD____) || defined (__FreeBSD__) || defined(__NetBSD__)
|
||||
#include <machine/ansi.h>
|
||||
#endif
|
||||
|
||||
/* In 4.3bsd-net2, machine/ansi.h defines these symbols, which are
|
||||
defined if the corresponding type is *not* defined.
|
||||
FreeBSD-2.1 defines _MACHINE_ANSI_H_ instead of _ANSI_H_ */
|
||||
#if defined(_ANSI_H_) || defined(_MACHINE_ANSI_H_)
|
||||
#if !defined(_SIZE_T_) && !defined(_BSD_SIZE_T_)
|
||||
#define _SIZE_T
|
||||
#endif
|
||||
#if !defined(_PTRDIFF_T_) && !defined(_BSD_PTRDIFF_T_)
|
||||
#define _PTRDIFF_T
|
||||
#endif
|
||||
/* On BSD/386 1.1, at least, machine/ansi.h defines _BSD_WCHAR_T_
|
||||
instead of _WCHAR_T_. */
|
||||
#if !defined(_WCHAR_T_) && !defined(_BSD_WCHAR_T_)
|
||||
#ifndef _BSD_WCHAR_T_
|
||||
#define _WCHAR_T
|
||||
#endif
|
||||
#endif
|
||||
/* Undef _FOO_T_ if we are supposed to define foo_t. */
|
||||
#if defined (__need_ptrdiff_t) || defined (_STDDEF_H_)
|
||||
#undef _PTRDIFF_T_
|
||||
#undef _BSD_PTRDIFF_T_
|
||||
#endif
|
||||
#if defined (__need_size_t) || defined (_STDDEF_H_)
|
||||
#undef _SIZE_T_
|
||||
#undef _BSD_SIZE_T_
|
||||
#endif
|
||||
#if defined (__need_wchar_t) || defined (_STDDEF_H_)
|
||||
#undef _WCHAR_T_
|
||||
#undef _BSD_WCHAR_T_
|
||||
#endif
|
||||
#endif /* defined(_ANSI_H_) || defined(_MACHINE_ANSI_H_) */
|
||||
|
||||
/* Sequent's header files use _PTRDIFF_T_ in some conflicting way.
|
||||
Just ignore it. */
|
||||
#if defined (__sequent__) && defined (_PTRDIFF_T_)
|
||||
#undef _PTRDIFF_T_
|
||||
#endif
|
||||
|
||||
/* On VxWorks, <type/vxTypesBase.h> may have defined macros like
|
||||
_TYPE_size_t which will typedef size_t. fixincludes patched the
|
||||
vxTypesBase.h so that this macro is only defined if _GCC_SIZE_T is
|
||||
not defined, and so that defining this macro defines _GCC_SIZE_T.
|
||||
If we find that the macros are still defined at this point, we must
|
||||
invoke them so that the type is defined as expected. */
|
||||
#if defined (_TYPE_ptrdiff_t) && (defined (__need_ptrdiff_t) || defined (_STDDEF_H_))
|
||||
_TYPE_ptrdiff_t;
|
||||
#undef _TYPE_ptrdiff_t
|
||||
#endif
|
||||
#if defined (_TYPE_size_t) && (defined (__need_size_t) || defined (_STDDEF_H_))
|
||||
_TYPE_size_t;
|
||||
#undef _TYPE_size_t
|
||||
#endif
|
||||
#if defined (_TYPE_wchar_t) && (defined (__need_wchar_t) || defined (_STDDEF_H_))
|
||||
_TYPE_wchar_t;
|
||||
#undef _TYPE_wchar_t
|
||||
#endif
|
||||
|
||||
/* In case nobody has defined these types, but we aren't running under
|
||||
GCC 2.00, make sure that __PTRDIFF_TYPE__, __SIZE__TYPE__, and
|
||||
__WCHAR_TYPE__ have reasonable values. This can happen if the
|
||||
parts of GCC is compiled by an older compiler, that actually
|
||||
include gstddef.h, such as collect2. */
|
||||
|
||||
/* Signed type of difference of two pointers. */
|
||||
|
||||
/* Define this type if we are doing the whole job,
|
||||
or if we want this type in particular. */
|
||||
#if defined (_STDDEF_H) || defined (__need_ptrdiff_t)
|
||||
#ifndef _PTRDIFF_T /* in case <sys/types.h> has defined it. */
|
||||
#ifndef _T_PTRDIFF_
|
||||
#ifndef _T_PTRDIFF
|
||||
#ifndef __PTRDIFF_T
|
||||
#ifndef _PTRDIFF_T_
|
||||
#ifndef _BSD_PTRDIFF_T_
|
||||
#ifndef ___int_ptrdiff_t_h
|
||||
#ifndef _GCC_PTRDIFF_T
|
||||
#define _PTRDIFF_T
|
||||
#define _T_PTRDIFF_
|
||||
#define _T_PTRDIFF
|
||||
#define __PTRDIFF_T
|
||||
#define _PTRDIFF_T_
|
||||
#define _BSD_PTRDIFF_T_
|
||||
#define ___int_ptrdiff_t_h
|
||||
#define _GCC_PTRDIFF_T
|
||||
#ifndef __PTRDIFF_TYPE__
|
||||
#define __PTRDIFF_TYPE__ long int
|
||||
#endif
|
||||
typedef __PTRDIFF_TYPE__ ptrdiff_t;
|
||||
#endif /* _GCC_PTRDIFF_T */
|
||||
#endif /* ___int_ptrdiff_t_h */
|
||||
#endif /* _BSD_PTRDIFF_T_ */
|
||||
#endif /* _PTRDIFF_T_ */
|
||||
#endif /* __PTRDIFF_T */
|
||||
#endif /* _T_PTRDIFF */
|
||||
#endif /* _T_PTRDIFF_ */
|
||||
#endif /* _PTRDIFF_T */
|
||||
|
||||
/* If this symbol has done its job, get rid of it. */
|
||||
#undef __need_ptrdiff_t
|
||||
|
||||
#endif /* _STDDEF_H or __need_ptrdiff_t. */
|
||||
|
||||
/* Unsigned type of `sizeof' something. */
|
||||
|
||||
/* Define this type if we are doing the whole job,
|
||||
or if we want this type in particular. */
|
||||
#if defined (_STDDEF_H) || defined (__need_size_t)
|
||||
#ifndef __size_t__ /* BeOS */
|
||||
#ifndef _SIZE_T /* in case <sys/types.h> has defined it. */
|
||||
#ifndef _SYS_SIZE_T_H
|
||||
#ifndef _T_SIZE_
|
||||
#ifndef _T_SIZE
|
||||
#ifndef __SIZE_T
|
||||
#ifndef _SIZE_T_
|
||||
#ifndef _BSD_SIZE_T_
|
||||
#ifndef _SIZE_T_DEFINED_
|
||||
#ifndef _SIZE_T_DEFINED
|
||||
#ifndef ___int_size_t_h
|
||||
#ifndef _GCC_SIZE_T
|
||||
#ifndef _SIZET_
|
||||
#ifndef __size_t
|
||||
#define __size_t__ /* BeOS */
|
||||
#define _SIZE_T
|
||||
#define _SYS_SIZE_T_H
|
||||
#define _T_SIZE_
|
||||
#define _T_SIZE
|
||||
#define __SIZE_T
|
||||
#define _SIZE_T_
|
||||
#define _BSD_SIZE_T_
|
||||
#define _SIZE_T_DEFINED_
|
||||
#define _SIZE_T_DEFINED
|
||||
#define ___int_size_t_h
|
||||
#define _GCC_SIZE_T
|
||||
#define _SIZET_
|
||||
#define __size_t
|
||||
#ifndef __SIZE_TYPE__
|
||||
#define __SIZE_TYPE__ long unsigned int
|
||||
#endif
|
||||
#if !(defined (__GNUG__) && defined (size_t))
|
||||
typedef __SIZE_TYPE__ size_t;
|
||||
#ifdef __BEOS__
|
||||
typedef long ssize_t;
|
||||
#endif /* __BEOS__ */
|
||||
#endif /* !(defined (__GNUG__) && defined (size_t)) */
|
||||
#endif /* __size_t */
|
||||
#endif /* _SIZET_ */
|
||||
#endif /* _GCC_SIZE_T */
|
||||
#endif /* ___int_size_t_h */
|
||||
#endif /* _SIZE_T_DEFINED */
|
||||
#endif /* _SIZE_T_DEFINED_ */
|
||||
#endif /* _BSD_SIZE_T_ */
|
||||
#endif /* _SIZE_T_ */
|
||||
#endif /* __SIZE_T */
|
||||
#endif /* _T_SIZE */
|
||||
#endif /* _T_SIZE_ */
|
||||
#endif /* _SYS_SIZE_T_H */
|
||||
#endif /* _SIZE_T */
|
||||
#endif /* __size_t__ */
|
||||
#undef __need_size_t
|
||||
#endif /* _STDDEF_H or __need_size_t. */
|
||||
|
||||
|
||||
/* Wide character type.
|
||||
Locale-writers should change this as necessary to
|
||||
be big enough to hold unique values not between 0 and 127,
|
||||
and not (wchar_t) -1, for each defined multibyte character. */
|
||||
|
||||
/* Define this type if we are doing the whole job,
|
||||
or if we want this type in particular. */
|
||||
#if defined (_STDDEF_H) || defined (__need_wchar_t)
|
||||
#ifndef __wchar_t__ /* BeOS */
|
||||
#ifndef _WCHAR_T
|
||||
#ifndef _T_WCHAR_
|
||||
#ifndef _T_WCHAR
|
||||
#ifndef __WCHAR_T
|
||||
#ifndef _WCHAR_T_
|
||||
#ifndef _BSD_WCHAR_T_
|
||||
#ifndef _WCHAR_T_DEFINED_
|
||||
#ifndef _WCHAR_T_DEFINED
|
||||
#ifndef _WCHAR_T_H
|
||||
#ifndef ___int_wchar_t_h
|
||||
#ifndef __INT_WCHAR_T_H
|
||||
#ifndef _GCC_WCHAR_T
|
||||
#define __wchar_t__ /* BeOS */
|
||||
#define _WCHAR_T
|
||||
#define _T_WCHAR_
|
||||
#define _T_WCHAR
|
||||
#define __WCHAR_T
|
||||
#define _WCHAR_T_
|
||||
#define _BSD_WCHAR_T_
|
||||
#define _WCHAR_T_DEFINED_
|
||||
#define _WCHAR_T_DEFINED
|
||||
#define _WCHAR_T_H
|
||||
#define ___int_wchar_t_h
|
||||
#define __INT_WCHAR_T_H
|
||||
#define _GCC_WCHAR_T
|
||||
|
||||
/* On BSD/386 1.1, at least, machine/ansi.h defines _BSD_WCHAR_T_
|
||||
instead of _WCHAR_T_, and _BSD_RUNE_T_ (which, unlike the other
|
||||
symbols in the _FOO_T_ family, stays defined even after its
|
||||
corresponding type is defined). If we define wchar_t, then we
|
||||
must undef _WCHAR_T_; for BSD/386 1.1 (and perhaps others), if
|
||||
we undef _WCHAR_T_, then we must also define rune_t, since
|
||||
headers like runetype.h assume that if machine/ansi.h is included,
|
||||
and _BSD_WCHAR_T_ is not defined, then rune_t is available.
|
||||
machine/ansi.h says, "Note that _WCHAR_T_ and _RUNE_T_ must be of
|
||||
the same type." */
|
||||
#ifdef _BSD_WCHAR_T_
|
||||
#undef _BSD_WCHAR_T_
|
||||
#ifdef _BSD_RUNE_T_
|
||||
#if !defined (_ANSI_SOURCE) && !defined (_POSIX_SOURCE)
|
||||
typedef _BSD_RUNE_T_ rune_t;
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
|
||||
#ifndef __WCHAR_TYPE__
|
||||
#ifdef __BEOS__
|
||||
#define __WCHAR_TYPE__ unsigned char
|
||||
#else
|
||||
#define __WCHAR_TYPE__ int
|
||||
#endif
|
||||
#endif
|
||||
#ifndef __cplusplus
|
||||
typedef __WCHAR_TYPE__ wchar_t;
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
#endif /* __wchar_t__ */
|
||||
#undef __need_wchar_t
|
||||
#endif /* _STDDEF_H or __need_wchar_t. */
|
||||
|
||||
#if defined (_STDDEF_H) || defined (__need_wint_t)
|
||||
#ifndef _WINT_T
|
||||
#define _WINT_T
|
||||
|
||||
#ifndef __WINT_TYPE__
|
||||
#define __WINT_TYPE__ unsigned int
|
||||
#endif
|
||||
typedef __WINT_TYPE__ wint_t;
|
||||
#endif
|
||||
#undef __need_wint_t
|
||||
#endif
|
||||
|
||||
/* In 4.3bsd-net2, leave these undefined to indicate that size_t, etc.
|
||||
are already defined. */
|
||||
/* BSD/OS 3.1 requires the MACHINE_ANSI_H check here. FreeBSD 2.x apparently
|
||||
does not, even though there is a check for MACHINE_ANSI_H above. */
|
||||
#if defined(_ANSI_H_) || (defined(__bsdi__) && defined(_MACHINE_ANSI_H_))
|
||||
/* The references to _GCC_PTRDIFF_T_, _GCC_SIZE_T_, and _GCC_WCHAR_T_
|
||||
are probably typos and should be removed before 2.8 is released. */
|
||||
#ifdef _GCC_PTRDIFF_T_
|
||||
#undef _PTRDIFF_T_
|
||||
#undef _BSD_PTRDIFF_T_
|
||||
#endif
|
||||
#ifdef _GCC_SIZE_T_
|
||||
#undef _SIZE_T_
|
||||
#undef _BSD_SIZE_T_
|
||||
#endif
|
||||
#ifdef _GCC_WCHAR_T_
|
||||
#undef _WCHAR_T_
|
||||
#undef _BSD_WCHAR_T_
|
||||
#endif
|
||||
/* The following ones are the real ones. */
|
||||
#ifdef _GCC_PTRDIFF_T
|
||||
#undef _PTRDIFF_T_
|
||||
#undef _BSD_PTRDIFF_T_
|
||||
#endif
|
||||
#ifdef _GCC_SIZE_T
|
||||
#undef _SIZE_T_
|
||||
#undef _BSD_SIZE_T_
|
||||
#endif
|
||||
#ifdef _GCC_WCHAR_T
|
||||
#undef _WCHAR_T_
|
||||
#undef _BSD_WCHAR_T_
|
||||
#endif
|
||||
#endif /* _ANSI_H_ || ( __bsdi__ && _MACHINE_ANSI_H_ ) */
|
||||
|
||||
#endif /* __sys_stdtypes_h */
|
||||
|
||||
/* A null pointer constant. */
|
||||
|
||||
#if defined (_STDDEF_H) || defined (__need_NULL)
|
||||
#undef NULL /* in case <stdio.h> has defined it. */
|
||||
#ifdef __GNUG__
|
||||
#define NULL __null
|
||||
#else /* G++ */
|
||||
#define NULL ((void *)0)
|
||||
#endif /* G++ */
|
||||
#endif /* NULL not defined and <stddef.h> or need NULL. */
|
||||
#undef __need_NULL
|
||||
|
||||
#ifdef _STDDEF_H
|
||||
|
||||
/* Offset of member MEMBER in a struct of type TYPE. */
|
||||
|
||||
#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
|
||||
|
||||
#endif /* _STDDEF_H was defined this time */
|
||||
|
||||
#endif /* !_STDDEF_H && !_STDDEF_H_ && !_ANSI_STDDEF_H && !__STDDEF_H__
|
||||
|| __need_XXX was not defined before */
|
||||
@@ -0,0 +1,8 @@
|
||||
/* syslimits.h stands for the system's own limits.h file.
|
||||
If we can use it ok unmodified, then we install this text.
|
||||
If fixincludes fixes it, then the fixed version is installed
|
||||
instead of this text. */
|
||||
|
||||
#define _GCC_NEXT_LIMITS_H /* tell gcc's limits.h to recurse */
|
||||
#include_next <limits.h>
|
||||
#undef _GCC_NEXT_LIMITS_H
|
||||
@@ -0,0 +1,128 @@
|
||||
/* GNU C varargs and stdargs support for the DEC Alpha. */
|
||||
|
||||
/* Note: We must use the name __builtin_savregs. GCC attaches special
|
||||
significance to that name. In particular, regardless of where in a
|
||||
function __builtin_saveregs is called, GCC moves the call up to the
|
||||
very start of the function. */
|
||||
|
||||
/* Define __gnuc_va_list. */
|
||||
|
||||
#ifndef __GNUC_VA_LIST
|
||||
#define __GNUC_VA_LIST
|
||||
|
||||
/* In VMS, __gnuc_va_list is simply char *; on OSF, it's a structure. */
|
||||
|
||||
#ifdef __VMS__
|
||||
typedef char *__gnuc_va_list;
|
||||
#else
|
||||
|
||||
typedef struct {
|
||||
char *__base; /* Pointer to first integer register. */
|
||||
int __offset; /* Byte offset of args so far. */
|
||||
} __gnuc_va_list;
|
||||
#endif
|
||||
|
||||
#endif /* __GNUC_VA_LIST */
|
||||
|
||||
/* If this is for internal libc use, don't define anything but
|
||||
__gnuc_va_list. */
|
||||
|
||||
#if !defined(__GNUC_VA_LIST_1) && (defined (_STDARG_H) || defined (_VARARGS_H))
|
||||
#define __GNUC_VA_LIST_1
|
||||
|
||||
#define _VA_LIST
|
||||
#define _VA_LIST_
|
||||
|
||||
typedef __gnuc_va_list va_list;
|
||||
|
||||
#if !defined(_STDARG_H)
|
||||
|
||||
/* varargs support */
|
||||
#define va_alist __builtin_va_alist
|
||||
#define va_dcl int __builtin_va_alist;...
|
||||
#ifdef __VMS__
|
||||
#define va_start(pvar) ((pvar) = __builtin_saveregs ())
|
||||
#else
|
||||
#define va_start(pvar) ((pvar) = * (__gnuc_va_list *) __builtin_saveregs ())
|
||||
#endif
|
||||
|
||||
#else /* STDARG.H */
|
||||
|
||||
/* ANSI alternative. */
|
||||
|
||||
/* Call __builtin_next_arg even though we aren't using its value, so that
|
||||
we can verify that firstarg is correct. */
|
||||
|
||||
#ifdef __VMS__
|
||||
#define va_start(pvar, firstarg) \
|
||||
(__builtin_next_arg (firstarg), \
|
||||
(pvar) = __builtin_saveregs ())
|
||||
#else
|
||||
#define va_start(pvar, firstarg) \
|
||||
(__builtin_next_arg (firstarg), \
|
||||
(pvar) = *(__gnuc_va_list *) __builtin_saveregs ())
|
||||
#endif
|
||||
|
||||
#endif /* _STDARG_H */
|
||||
|
||||
#define va_end(__va) ((void) 0)
|
||||
|
||||
/* Values returned by __builtin_classify_type. */
|
||||
|
||||
enum {
|
||||
__no_type_class = -1,
|
||||
__void_type_class,
|
||||
__integer_type_class,
|
||||
__char_type_class,
|
||||
__enumeral_type_class,
|
||||
__boolean_type_class,
|
||||
__pointer_type_class,
|
||||
__reference_type_class,
|
||||
__offset_type_class,
|
||||
__real_type_class,
|
||||
__complex_type_class,
|
||||
__function_type_class,
|
||||
__method_type_class,
|
||||
__record_type_class,
|
||||
__union_type_class,
|
||||
__array_type_class,
|
||||
__string_type_class,
|
||||
__set_type_class,
|
||||
__file_type_class,
|
||||
__lang_type_class
|
||||
};
|
||||
|
||||
/* Note that parameters are always aligned at least to a word boundary
|
||||
(when passed) regardless of what GCC's __alignof__ operator says. */
|
||||
|
||||
/* Avoid errors if compiling GCC v2 with GCC v1. */
|
||||
#if __GNUC__ == 1
|
||||
#define __extension__
|
||||
#endif
|
||||
|
||||
/* Get the size of a type in bytes, rounded up to an integral number
|
||||
of words. */
|
||||
|
||||
#define __va_tsize(__type) \
|
||||
(((sizeof (__type) + __extension__ sizeof (long long) - 1) \
|
||||
/ __extension__ sizeof (long long)) * __extension__ sizeof (long long))
|
||||
|
||||
#ifdef __VMS__
|
||||
#define va_arg(__va, __type) \
|
||||
(*(((__va) += __va_tsize (__type)), \
|
||||
(__type *)(void *)((__va) - __va_tsize (__type))))
|
||||
|
||||
#else
|
||||
|
||||
#define va_arg(__va, __type) \
|
||||
(*(((__va).__offset += __va_tsize (__type)), \
|
||||
(__type *)(void *)((__va).__base + (__va).__offset \
|
||||
- (((__builtin_classify_type (* (__type *) 0) \
|
||||
== __real_type_class) && (__va).__offset <= (6 * 8)) \
|
||||
? (6 * 8) + 8 : __va_tsize (__type)))))
|
||||
#endif
|
||||
|
||||
/* Copy __gnuc_va_list into another variable of this type. */
|
||||
#define __va_copy(dest, src) (dest) = (src)
|
||||
|
||||
#endif /* __GNUC_VA_LIST_1 */
|
||||
@@ -0,0 +1,111 @@
|
||||
/* stdarg/varargs support for the ARC */
|
||||
|
||||
/* Define __gnuc_va_list. */
|
||||
|
||||
#ifndef __GNUC_VA_LIST
|
||||
#define __GNUC_VA_LIST
|
||||
typedef void * __gnuc_va_list;
|
||||
#endif /* not __GNUC_VA_LIST */
|
||||
|
||||
/* If this is for internal libc use, don't define anything but
|
||||
__gnuc_va_list. */
|
||||
#if defined (_STDARG_H) || defined (_VARARGS_H)
|
||||
|
||||
/* In GCC version 2, we want an ellipsis at the end of the declaration
|
||||
of the argument list. GCC version 1 can't parse it. */
|
||||
|
||||
#if __GNUC__ > 1
|
||||
#define __va_ellipsis ...
|
||||
#else
|
||||
#define __va_ellipsis
|
||||
#endif
|
||||
|
||||
/* See arc_setup_incoming_varargs for reasons for the oddity in va_start. */
|
||||
#ifdef _STDARG_H
|
||||
#define va_start(AP, LASTARG) \
|
||||
(AP = (__gnuc_va_list) ((int *) __builtin_next_arg (LASTARG) \
|
||||
+ (__builtin_args_info (0) < 8 \
|
||||
? (__builtin_args_info (0) & 1) \
|
||||
: 0)))
|
||||
#else
|
||||
#define va_alist __builtin_va_alist
|
||||
#define va_dcl int __builtin_va_alist; __va_ellipsis
|
||||
#define va_start(AP) \
|
||||
(AP = (__gnuc_va_list) ((int *) &__builtin_va_alist \
|
||||
+ (__builtin_args_info (0) < 8 \
|
||||
? (__builtin_args_info (0) & 1) \
|
||||
: 0)))
|
||||
#endif
|
||||
|
||||
#ifndef va_end
|
||||
void va_end (__gnuc_va_list); /* Defined in libgcc.a */
|
||||
|
||||
/* Values returned by __builtin_classify_type. */
|
||||
|
||||
enum __va_type_classes {
|
||||
__no_type_class = -1,
|
||||
__void_type_class,
|
||||
__integer_type_class,
|
||||
__char_type_class,
|
||||
__enumeral_type_class,
|
||||
__boolean_type_class,
|
||||
__pointer_type_class,
|
||||
__reference_type_class,
|
||||
__offset_type_class,
|
||||
__real_type_class,
|
||||
__complex_type_class,
|
||||
__function_type_class,
|
||||
__method_type_class,
|
||||
__record_type_class,
|
||||
__union_type_class,
|
||||
__array_type_class,
|
||||
__string_type_class,
|
||||
__set_type_class,
|
||||
__file_type_class,
|
||||
__lang_type_class
|
||||
};
|
||||
|
||||
#endif
|
||||
#define va_end(AP) ((void)0)
|
||||
|
||||
/* Avoid errors if compiling GCC v2 with GCC v1. */
|
||||
#if __GNUC__ == 1
|
||||
#define __extension__
|
||||
#endif
|
||||
|
||||
/* All aggregates are passed by reference. All scalar types larger than 8
|
||||
bytes are passed by reference. */
|
||||
/* We cast to void * and then to TYPE * because this avoids
|
||||
a warning about increasing the alignment requirement.
|
||||
The casts to char * avoid warnings about invalid pointer arithmetic. */
|
||||
|
||||
#define __va_rounded_size(TYPE) \
|
||||
(((sizeof (TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof (int))
|
||||
|
||||
#ifdef __big_endian__
|
||||
#define va_arg(AP,TYPE) \
|
||||
__extension__ \
|
||||
(*({((__builtin_classify_type (*(TYPE*) 0) >= __record_type_class \
|
||||
|| __va_rounded_size (TYPE) > 8) \
|
||||
? ((AP) = (char *)(AP) + __va_rounded_size (TYPE *), \
|
||||
*(TYPE **) (void *) ((char *)(AP) - __va_rounded_size (TYPE *))) \
|
||||
: ((TYPE *) (void *) \
|
||||
(AP = (void *) ((__alignof__ (TYPE) > 4 \
|
||||
? ((int) AP + 8 - 1) & -8 \
|
||||
: (int) AP) \
|
||||
+ __va_rounded_size (TYPE))) - 1));}))
|
||||
#else
|
||||
#define va_arg(AP,TYPE) \
|
||||
__extension__ \
|
||||
(*({((__builtin_classify_type (*(TYPE*) 0) >= __record_type_class \
|
||||
|| __va_rounded_size (TYPE) > 8) \
|
||||
? ((AP) = (char *)(AP) + __va_rounded_size (TYPE *), \
|
||||
*(TYPE **) (void *) ((char *)(AP) - __va_rounded_size (TYPE *))) \
|
||||
: ((AP = (void *) ((__alignof__ (TYPE) > 4 \
|
||||
? ((int) AP + 8 - 1) & -8 \
|
||||
: (int) AP) \
|
||||
+ __va_rounded_size (TYPE))), \
|
||||
(TYPE *) (void *) (AP - __va_rounded_size (TYPE))));}))
|
||||
#endif
|
||||
|
||||
#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */
|
||||
@@ -0,0 +1,34 @@
|
||||
/* GNU C varargs support for the TMS320C[34]x */
|
||||
|
||||
/* C[34]x arguments grow in weird ways (downwards) that the standard
|
||||
varargs stuff can't handle. */
|
||||
|
||||
#ifndef __GNUC_VA_LIST
|
||||
#define __GNUC_VA_LIST
|
||||
|
||||
typedef void *__gnuc_va_list;
|
||||
|
||||
#endif /* not __GNUC_VA_LIST */
|
||||
|
||||
/* If this is for internal libc use, don't define anything but
|
||||
__gnuc_va_list. */
|
||||
#if defined (_STDARG_H) || defined (_VARARGS_H)
|
||||
|
||||
#ifdef _STDARG_H /* stdarg.h support */
|
||||
|
||||
#define va_start(AP,LASTARG) AP=(__gnuc_va_list) __builtin_next_arg (LASTARG)
|
||||
|
||||
#else /* varargs.h support */
|
||||
|
||||
#define __va_ellipsis ...
|
||||
#define va_alist __builtin_va_alist
|
||||
#define va_dcl int __builtin_va_alist; __va_ellipsis
|
||||
#define va_start(AP) AP=(__gnuc_va_list) ((int *)&__builtin_va_alist + 1)
|
||||
|
||||
#endif /* _STDARG_H */
|
||||
|
||||
#define va_end(AP) ((void) 0)
|
||||
#define va_arg(AP,TYPE) (AP = (__gnuc_va_list) ((char *) (AP) - sizeof(TYPE)), \
|
||||
*((TYPE *) ((char *) (AP))))
|
||||
|
||||
#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */
|
||||
@@ -0,0 +1,60 @@
|
||||
/* GNU C varargs and stdargs support for Clipper. */
|
||||
|
||||
/* Define __gnuc_va_list. */
|
||||
|
||||
#ifndef __GNUC_VA_LIST
|
||||
#define __GNUC_VA_LIST
|
||||
|
||||
typedef struct
|
||||
{
|
||||
int __va_ap; /* pointer to stack args */
|
||||
void *__va_reg[4]; /* pointer to r0,f0,r1,f1 */
|
||||
int __va_num; /* number of args processed */
|
||||
} __gnuc_va_list;
|
||||
#endif /* not __GNUC_VA_LIST */
|
||||
|
||||
|
||||
#if defined (_STDARG_H) || defined (_VARARGS_H)
|
||||
typedef __gnuc_va_list va_list;
|
||||
#define __va_list __gnuc_va_list /* acc compatibility */
|
||||
|
||||
#define _VA_LIST
|
||||
#define _VA_LIST_
|
||||
#define _SYS_INT_STDARG_H /* acc compatibility */
|
||||
|
||||
/* Call __builtin_next_arg even though we aren't using its value, so that
|
||||
we can verify that LASTARG is correct. */
|
||||
#ifdef _STDARG_H
|
||||
#define va_start(AP,LASTARG) \
|
||||
(__builtin_next_arg (LASTARG), \
|
||||
(AP) = *(va_list *)__builtin_saveregs(), \
|
||||
(AP).__va_num = __builtin_args_info (0), \
|
||||
(AP).__va_ap += __builtin_args_info (1))
|
||||
#else
|
||||
#define va_alist __builtin_va_alist
|
||||
/* The ... causes current_function_varargs to be set in cc1. */
|
||||
#define va_dcl va_list __builtin_va_alist; ...
|
||||
#define va_start(AP) \
|
||||
((AP) = *(va_list *)__builtin_saveregs(), \
|
||||
(AP).__va_num = __builtin_args_info (0))
|
||||
#endif /* _STDARG_H */
|
||||
|
||||
/* round to alignment of `type' but keep a least integer alignment */
|
||||
#define __va_round(AP,TYPE) \
|
||||
((AP).__va_ap = ((AP).__va_ap + __alignof__ (TYPE) - 1 ) & \
|
||||
~(__alignof__ (TYPE) - 1), \
|
||||
((AP).__va_ap = ((AP).__va_ap + sizeof (int) - 1) & ~(sizeof (int) - 1)))
|
||||
|
||||
#define va_arg(AP, TYPE) \
|
||||
(*((AP).__va_num < 2 && __builtin_classify_type (* (TYPE *)0) < 12 \
|
||||
? (__builtin_classify_type (* (TYPE *)0) == 8 \
|
||||
? ((TYPE *)(AP).__va_reg[2 * (AP).__va_num++ + 1]) \
|
||||
: ((TYPE *)(AP).__va_reg[2 * (AP).__va_num++ ])) \
|
||||
: ((AP).__va_num++, __va_round (AP,TYPE), ((TYPE *)((AP).__va_ap))++)))
|
||||
|
||||
#define va_end(AP) ((void) 0)
|
||||
|
||||
/* Copy __gnuc_va_list into another variable of this type. */
|
||||
#define __va_copy(dest, src) (dest) = (src)
|
||||
|
||||
#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */
|
||||
@@ -0,0 +1,56 @@
|
||||
/* stdarg/vararg support for the Hitachi h8/300 and h8/300h */
|
||||
|
||||
/* Define __gnuc_va_list. */
|
||||
|
||||
#ifndef __GNUC_VA_LIST
|
||||
#define __GNUC_VA_LIST
|
||||
typedef void *__gnuc_va_list;
|
||||
#endif
|
||||
|
||||
/* If this is for internal libc use, don't define anything but
|
||||
__gnuc_va_list. */
|
||||
#if defined (_STDARG_H) || defined (_VARARGS_H)
|
||||
|
||||
/* In GCC version 2, we want an ellipsis at the end of the declaration
|
||||
of the argument list. GCC version 1 can't parse it. */
|
||||
|
||||
#if __GNUC__ > 1
|
||||
#define __va_ellipsis ...
|
||||
#else
|
||||
#define __va_ellipsis
|
||||
#endif
|
||||
|
||||
#ifdef __H8300__
|
||||
#define __va_rounded_size(TYPE) \
|
||||
(((sizeof (TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof (int))
|
||||
#else
|
||||
#define __va_rounded_size(TYPE) \
|
||||
(((sizeof (TYPE) + sizeof (long) - 1) / sizeof (long)) * sizeof (long))
|
||||
#endif
|
||||
|
||||
#ifdef _STDARG_H
|
||||
|
||||
#define va_start(AP,LASTARG) \
|
||||
(AP = ((__gnuc_va_list) __builtin_next_arg (LASTARG)))
|
||||
|
||||
#else /* _VARARGS_H */
|
||||
|
||||
#define va_alist __builtin_va_alist
|
||||
/* The ... causes current_function_varargs to be set in cc1. */
|
||||
#define va_dcl int __builtin_va_alist; __va_ellipsis
|
||||
#define va_start(AP) AP = (void *) &__builtin_va_alist
|
||||
|
||||
#endif /* _VARARGS_H */
|
||||
|
||||
#define va_arg(AP, TYPE) \
|
||||
(AP = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (TYPE)), \
|
||||
*((TYPE *) (void *) ((char *) (AP) \
|
||||
- ((sizeof (TYPE) < __va_rounded_size (int) \
|
||||
? sizeof (TYPE) : __va_rounded_size (TYPE))))))
|
||||
|
||||
#define va_end(AP) ((void) 0)
|
||||
|
||||
/* Copy __gnuc_va_list into another variable of this type. */
|
||||
#define __va_copy(dest, src) (dest) = (src)
|
||||
|
||||
#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */
|
||||
@@ -0,0 +1,214 @@
|
||||
/* Note: We must use the name __builtin_savregs. GCC attaches special
|
||||
significance to that name. In particular, regardless of where in a
|
||||
function __builtin_saveregs is called, GCC moves the call up to the
|
||||
very start of the function. */
|
||||
|
||||
|
||||
/* Define __gnuc_va_list. */
|
||||
|
||||
#ifndef __GNUC_VA_LIST
|
||||
#define __GNUC_VA_LIST
|
||||
|
||||
typedef union {
|
||||
float __freg[8];
|
||||
double __dreg[4];
|
||||
} __f_regs;
|
||||
|
||||
typedef struct {
|
||||
#if defined (__SVR4__) || defined (__svr4__) || defined (__alliant__) || defined (__PARAGON__)
|
||||
__f_regs __float_regs; long __ireg[12];
|
||||
#else /* pre-SVR4 */
|
||||
long __ireg[12]; __f_regs __float_regs;
|
||||
#endif
|
||||
} __va_saved_regs;
|
||||
|
||||
typedef struct {
|
||||
#if defined(__SVR4__) || defined(__svr4__) || defined(__alliant__) || defined (__PARAGON__)
|
||||
unsigned __ireg_used; /* How many int regs consumed 'til now? */
|
||||
unsigned __freg_used; /* How many flt regs consumed 'til now? */
|
||||
long *__reg_base; /* Address of where we stored the regs. */
|
||||
long * __mem_ptr; /* Address of memory overflow args area. */
|
||||
#else /* pre-SVR4 */
|
||||
long *__reg_base; /* Address of where we stored the regs. */
|
||||
long * __mem_ptr; /* Address of memory overflow args area. */
|
||||
unsigned __ireg_used; /* How many int regs consumed 'til now? */
|
||||
unsigned __freg_used; /* How many flt regs consumed 'til now? */
|
||||
#endif
|
||||
} __gnuc_va_list;
|
||||
#endif /* not __GNUC_VA_LIST */
|
||||
|
||||
/* If this is for internal libc use, don't define anything but
|
||||
__gnuc_va_list. */
|
||||
#if defined (_STDARG_H) || defined (_VARARGS_H)
|
||||
|
||||
#if !defined(_STDARG_H)
|
||||
|
||||
/* varargs support */
|
||||
#define va_alist __builtin_va_alist
|
||||
#if defined (__PARAGON__)
|
||||
#define va_dcl int va_alist;
|
||||
#else /* __PARAGON__ */
|
||||
#define va_dcl
|
||||
#endif /* __PARAGON__ */
|
||||
#define va_start(pvar) ((pvar) = * (__gnuc_va_list *) __builtin_saveregs ())
|
||||
|
||||
#else /* STDARG.H */
|
||||
|
||||
/* ANSI alternative. */
|
||||
/* Note that CUMULATIVE_ARGS elements are measured in bytes on the i860,
|
||||
so we divide by 4 to get # of registers. */
|
||||
#define va_start(pvar, firstarg) \
|
||||
((pvar) = *(__gnuc_va_list *) __builtin_saveregs (), \
|
||||
(pvar).__ireg_used = __builtin_args_info (0) / 4, \
|
||||
(pvar).__freg_used = __builtin_args_info (1) / 4, \
|
||||
(pvar).__mem_ptr = __builtin_next_arg (firstarg))
|
||||
|
||||
#endif /* _STDARG_H */
|
||||
|
||||
/* Values returned by __builtin_classify_type. */
|
||||
|
||||
#ifndef va_end
|
||||
enum {
|
||||
__no_type_class = -1,
|
||||
__void_type_class,
|
||||
__integer_type_class,
|
||||
__char_type_class,
|
||||
__enumeral_type_class,
|
||||
__boolean_type_class,
|
||||
__pointer_type_class,
|
||||
__reference_type_class,
|
||||
__offset_type_class,
|
||||
__real_type_class,
|
||||
__complex_type_class,
|
||||
__function_type_class,
|
||||
__method_type_class,
|
||||
__record_type_class,
|
||||
__union_type_class,
|
||||
__array_type_class,
|
||||
__string_type_class,
|
||||
__set_type_class,
|
||||
__file_type_class,
|
||||
__lang_type_class
|
||||
};
|
||||
|
||||
void va_end (__gnuc_va_list); /* Defined in libgcc.a */
|
||||
#endif
|
||||
#define va_end(__va) ((void) 0)
|
||||
|
||||
#define __NUM_PARM_FREGS 8
|
||||
#define __NUM_PARM_IREGS 12
|
||||
|
||||
#define __savereg(__va) ((__va_saved_regs *) ((__va).__reg_base))
|
||||
|
||||
/* This macro works both for SVR4 and pre-SVR4 environments. */
|
||||
|
||||
/* Note that parameters are always aligned at least to a word boundary
|
||||
(when passed) regardless of what GCC's __alignof__ operator says. */
|
||||
|
||||
/* Make allowances here for adding 128-bit (long double) floats someday. */
|
||||
|
||||
#if 0 /* What was this for? */
|
||||
#ifndef __GNU_VA_LIST
|
||||
#define __ireg_used ireg_used
|
||||
#define __freg_used freg_used
|
||||
#define __mem_ptr mem_ptr
|
||||
#define __reg_base reg_base
|
||||
#endif
|
||||
#endif /* 0 */
|
||||
|
||||
/* Avoid errors if compiling GCC v2 with GCC v1. */
|
||||
#if __GNUC__ == 1
|
||||
#define __extension__
|
||||
#endif
|
||||
|
||||
#define va_arg(__va, __type) \
|
||||
__extension__ \
|
||||
(* (__type *) \
|
||||
({ \
|
||||
register void *__rv; /* result value */ \
|
||||
register unsigned __align; \
|
||||
switch (__builtin_classify_type (* (__type *) 0)) \
|
||||
{ \
|
||||
case __real_type_class: \
|
||||
switch (sizeof (__type)) \
|
||||
{ \
|
||||
case sizeof (float): \
|
||||
case sizeof (double): \
|
||||
if ((__va).__freg_used < __NUM_PARM_FREGS - 1) \
|
||||
{ \
|
||||
if (((__va).__freg_used & 1) != 0) \
|
||||
(__va).__freg_used++; /* skip odd */ \
|
||||
__rv = &__savereg((__va))->__float_regs.__freg[(__va).__freg_used];\
|
||||
(__va).__freg_used += 2; \
|
||||
} \
|
||||
else \
|
||||
{ \
|
||||
if ((((unsigned) (__va).__mem_ptr) & (sizeof(double)-1)) != 0) \
|
||||
(__va).__mem_ptr++; /* skip odd */ \
|
||||
__rv = (__va).__mem_ptr; \
|
||||
(__va).__mem_ptr += 2; \
|
||||
} \
|
||||
if (sizeof (__type) == sizeof (float)) \
|
||||
{ \
|
||||
*((float *) __rv) = *((double *) __rv); \
|
||||
*(((long *) __rv) + 1) = 0xfff00001; \
|
||||
} \
|
||||
break; \
|
||||
default: \
|
||||
abort (); \
|
||||
} \
|
||||
break; \
|
||||
case __void_type_class: \
|
||||
case __integer_type_class: \
|
||||
case __char_type_class: \
|
||||
case __enumeral_type_class: \
|
||||
case __boolean_type_class: \
|
||||
case __pointer_type_class: \
|
||||
case __reference_type_class: \
|
||||
case __offset_type_class: \
|
||||
if (sizeof (__type) <= 4) \
|
||||
{ \
|
||||
__rv = ((__va).__ireg_used < __NUM_PARM_IREGS \
|
||||
? (&__savereg((__va))->__ireg[(__va).__ireg_used++]) \
|
||||
: (__va).__mem_ptr++); \
|
||||
break; \
|
||||
} \
|
||||
else if ((__va).__ireg_used + sizeof (__type) / 4 <= __NUM_PARM_IREGS) \
|
||||
{ \
|
||||
__rv = &__savereg((__va))->__ireg[(__va).__ireg_used]; \
|
||||
(__va).__ireg_used += sizeof (__type) / 4; \
|
||||
break; \
|
||||
} \
|
||||
/* Fall through to fetch from memory. */ \
|
||||
case __record_type_class: \
|
||||
case __union_type_class: \
|
||||
__align = (__alignof__ (__type) < sizeof (long) \
|
||||
? sizeof (long) \
|
||||
: __alignof__ (__type)); \
|
||||
(__va).__mem_ptr \
|
||||
= (long *) \
|
||||
((((unsigned) (__va).__mem_ptr) + (__align-1)) & ~(__align-1)); \
|
||||
__rv = (__va).__mem_ptr; \
|
||||
(__va).__mem_ptr \
|
||||
+= ((sizeof (__type) + sizeof (long) - 1) / sizeof (long)); \
|
||||
break; \
|
||||
case __complex_type_class: \
|
||||
case __function_type_class: \
|
||||
case __method_type_class: \
|
||||
case __array_type_class: \
|
||||
case __string_type_class: \
|
||||
case __set_type_class: \
|
||||
case __file_type_class: \
|
||||
case __lang_type_class: \
|
||||
case __no_type_class: \
|
||||
default: \
|
||||
abort (); \
|
||||
} \
|
||||
__rv; \
|
||||
}))
|
||||
|
||||
/* Copy __gnuc_va_list into another variable of this type. */
|
||||
#define __va_copy(dest, src) (dest) = (src)
|
||||
|
||||
#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */
|
||||
|
||||
@@ -0,0 +1,79 @@
|
||||
/* GNU C varargs support for the Intel 80960. */
|
||||
|
||||
/* Define __gnuc_va_list. */
|
||||
|
||||
#ifndef __GNUC_VA_LIST
|
||||
#define __GNUC_VA_LIST
|
||||
/* The first element is the address of the first argument.
|
||||
The second element is the number of bytes skipped past so far. */
|
||||
typedef unsigned __gnuc_va_list[2];
|
||||
#endif /* not __GNUC_VA_LIST */
|
||||
|
||||
/* If this is for internal libc use, don't define anything but
|
||||
__gnuc_va_list. */
|
||||
#if defined (_STDARG_H) || defined (_VARARGS_H)
|
||||
|
||||
/* In GCC version 2, we want an ellipsis at the end of the declaration
|
||||
of the argument list. GCC version 1 can't parse it. */
|
||||
|
||||
#if __GNUC__ > 1
|
||||
#define __va_ellipsis ...
|
||||
#else
|
||||
#define __va_ellipsis
|
||||
#endif
|
||||
|
||||
/* The stack size of the type t. */
|
||||
#define __vsiz(T) (((sizeof (T) + 3) / 4) * 4)
|
||||
/* The stack alignment of the type t. */
|
||||
#define __vali(T) (__alignof__ (T) >= 4 ? __alignof__ (T) : 4)
|
||||
/* The offset of the next stack argument after one of type t at offset i. */
|
||||
#define __vpad(I, T) ((((I) + __vali (T) - 1) / __vali (T)) \
|
||||
* __vali (T) + __vsiz (T))
|
||||
|
||||
/* Avoid errors if compiling GCC v2 with GCC v1. */
|
||||
#if __GNUC__ == 1
|
||||
#define __extension__
|
||||
#endif
|
||||
|
||||
#ifdef _STDARG_H
|
||||
/* Call __builtin_next_arg even though we aren't using its value, so that
|
||||
we can verify that firstarg is correct. */
|
||||
#define va_start(AP, LASTARG) \
|
||||
__extension__ \
|
||||
({ __builtin_next_arg (LASTARG); \
|
||||
__asm__ ("st g14,%0" : "=m" (*(AP))); \
|
||||
(AP)[1] = (__builtin_args_info (0) + __builtin_args_info (1)) * 4; })
|
||||
|
||||
#else
|
||||
|
||||
#define va_alist __builtin_va_alist
|
||||
#define va_dcl char *__builtin_va_alist; __va_ellipsis
|
||||
#define va_start(AP) \
|
||||
__extension__ \
|
||||
({ __asm__ ("st g14,%0" : "=m" (*(AP))); \
|
||||
(AP)[1] = (__builtin_args_info (0) + __builtin_args_info (1)) * 4; })
|
||||
#endif
|
||||
|
||||
/* We cast to void * and then to TYPE * because this avoids
|
||||
a warning about increasing the alignment requirement. */
|
||||
#define va_arg(AP, T) \
|
||||
( \
|
||||
( \
|
||||
((AP)[1] <= 48 && (__vpad ((AP)[1], T) > 48 || __vsiz (T) > 16)) \
|
||||
? ((AP)[1] = 48 + __vsiz (T)) \
|
||||
: ((AP)[1] = __vpad ((AP)[1], T)) \
|
||||
), \
|
||||
\
|
||||
*((T *) (void *) ((char *) *(AP) + (AP)[1] - __vsiz (T))) \
|
||||
)
|
||||
|
||||
#ifndef va_end
|
||||
void va_end (__gnuc_va_list); /* Defined in libgcc.a */
|
||||
#endif
|
||||
#define va_end(AP) ((void) 0)
|
||||
|
||||
/* Copy __gnuc_va_list into another variable of this type. */
|
||||
#define __va_copy(dest, src) (dest) = (src)
|
||||
|
||||
#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */
|
||||
|
||||
@@ -0,0 +1,86 @@
|
||||
/* GNU C stdarg/varargs support for the M32R */
|
||||
|
||||
/* Define __gnuc_va_list. */
|
||||
#ifndef __GNUC_VA_LIST
|
||||
#define __GNUC_VA_LIST
|
||||
typedef void *__gnuc_va_list;
|
||||
#endif /* not __GNUC_VA_LIST */
|
||||
|
||||
/* If this is for internal libc use, don't define anything but
|
||||
__gnuc_va_list. */
|
||||
#if defined (_STDARG_H) || defined (_VARARGS_H)
|
||||
|
||||
/* Common code for va_start for both varargs and stdarg. */
|
||||
|
||||
#define __va_rounded_size(TYPE) \
|
||||
(((sizeof (TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof (int))
|
||||
|
||||
#ifdef _STDARG_H /* stdarg.h support */
|
||||
|
||||
/* Calling __builtin_next_arg gives the proper error message if LASTARG is
|
||||
not indeed the last argument. */
|
||||
#define va_start(AP, LASTARG) \
|
||||
(AP = ((__gnuc_va_list) __builtin_next_arg (LASTARG)))
|
||||
|
||||
#else /* varargs.h support */
|
||||
|
||||
#define va_alist __builtin_va_alist
|
||||
/* The ... causes current_function_varargs to be set in cc1. */
|
||||
#define va_dcl int __builtin_va_alist; ...
|
||||
#define va_start(AP) AP=(char *) &__builtin_va_alist
|
||||
|
||||
#endif /* _STDARG_H */
|
||||
|
||||
/* Nothing needs to be done to end varargs/stdarg processing */
|
||||
#define va_end(AP) ((void) 0)
|
||||
|
||||
/* Values returned by __builtin_classify_type. */
|
||||
enum __type_class
|
||||
{
|
||||
__no_type_class = -1,
|
||||
__void_type_class,
|
||||
__integer_type_class,
|
||||
__char_type_class,
|
||||
__enumeral_type_class,
|
||||
__boolean_type_class,
|
||||
__pointer_type_class,
|
||||
__reference_type_class,
|
||||
__offset_type_class,
|
||||
__real_type_class,
|
||||
__complex_type_class,
|
||||
__function_type_class,
|
||||
__method_type_class,
|
||||
__record_type_class,
|
||||
__union_type_class,
|
||||
__array_type_class,
|
||||
__string_type_class,
|
||||
__set_type_class,
|
||||
__file_type_class,
|
||||
__lang_type_class
|
||||
};
|
||||
|
||||
/* Return whether a type is passed by reference. */
|
||||
#define __va_by_reference_p(TYPE) (sizeof (TYPE) > 8)
|
||||
|
||||
#define va_arg(AP,TYPE) \
|
||||
__extension__ (*({ \
|
||||
register TYPE *__ptr; \
|
||||
\
|
||||
if (__va_by_reference_p (TYPE)) \
|
||||
{ \
|
||||
__ptr = *(TYPE **)(void *) (AP); \
|
||||
(AP) = (__gnuc_va_list) ((char *) (AP) + sizeof (void *)); \
|
||||
} \
|
||||
else \
|
||||
{ \
|
||||
__ptr = (TYPE *)(void *) \
|
||||
((char *) (AP) + (sizeof (TYPE) < __va_rounded_size (char) \
|
||||
? __va_rounded_size (TYPE) - sizeof (TYPE) \
|
||||
: 0)); \
|
||||
(AP) = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (TYPE)); \
|
||||
} \
|
||||
\
|
||||
__ptr; \
|
||||
}))
|
||||
|
||||
#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */
|
||||
@@ -0,0 +1,87 @@
|
||||
/* GNU C varargs support for the Motorola 88100 */
|
||||
|
||||
/* Define __gnuc_va_list. */
|
||||
|
||||
#ifndef __GNUC_VA_LIST
|
||||
#define __GNUC_VA_LIST
|
||||
|
||||
typedef struct
|
||||
{
|
||||
int __va_arg; /* argument number */
|
||||
int *__va_stk; /* start of args passed on stack */
|
||||
int *__va_reg; /* start of args passed in regs */
|
||||
} __gnuc_va_list;
|
||||
#endif /* not __GNUC_VA_LIST */
|
||||
|
||||
/* If this is for internal libc use, don't define anything but
|
||||
__gnuc_va_list. */
|
||||
#if defined (_STDARG_H) || defined (_VARARGS_H)
|
||||
|
||||
#ifdef _STDARG_H /* stdarg.h support */
|
||||
|
||||
/* Call __builtin_next_arg even though we aren't using its value, so that
|
||||
we can verify that LASTARG is correct. */
|
||||
#if __GNUC__ > 1 /* GCC 2.0 and beyond */
|
||||
#define va_start(AP,LASTARG) \
|
||||
(__builtin_next_arg (LASTARG), \
|
||||
(AP) = *(__gnuc_va_list *)__builtin_saveregs())
|
||||
#else
|
||||
#define va_start(AP,LASTARG) \
|
||||
( (AP).__va_reg = (int *) __builtin_saveregs2(0), \
|
||||
(AP).__va_stk = (int *) __builtin_argptr(), \
|
||||
(AP).__va_arg = (int) (__builtin_argsize() + 3) / 4 )
|
||||
#endif
|
||||
|
||||
#else /* varargs.h support */
|
||||
|
||||
#if __GNUC__ > 1 /* GCC 2.0 and beyond */
|
||||
#define va_start(AP) ((AP) = *(__gnuc_va_list *)__builtin_saveregs())
|
||||
#else
|
||||
#define va_start(AP) \
|
||||
( (AP).__va_reg = (int *) __builtin_saveregs2(1), \
|
||||
(AP).__va_stk = (int *) __builtin_argptr(), \
|
||||
(AP).__va_arg = (int) (__builtin_argsize() - 4 + 3) / 4 )
|
||||
#endif
|
||||
#define va_alist __va_1st_arg
|
||||
#define va_dcl register int va_alist;...
|
||||
|
||||
#endif /* _STDARG_H */
|
||||
|
||||
/* Avoid trouble between this file and _int_varargs.h under DG/UX. This file
|
||||
can be included by <stdio.h> and others and provides definitions of
|
||||
__va_size and __va_reg_p and a va_list typedef. Avoid defining va_list
|
||||
again with _VA_LIST. */
|
||||
#ifdef __INT_VARARGS_H
|
||||
#undef __va_size
|
||||
#undef __va_reg_p
|
||||
#define __gnuc_va_list va_list
|
||||
#define _VA_LIST
|
||||
#define _VA_LIST_
|
||||
#else
|
||||
/* Similarly, if this gets included first, do nothing in _int_varargs.h. */
|
||||
#define __INT_VARARGS_H
|
||||
#endif
|
||||
|
||||
#define __va_reg_p(TYPE) \
|
||||
(__builtin_classify_type(*(TYPE *)0) < 12 \
|
||||
? sizeof(TYPE) <= 8 : sizeof(TYPE) == 4 && __alignof__(TYPE) == 4)
|
||||
|
||||
#define __va_size(TYPE) ((sizeof(TYPE) + 3) >> 2)
|
||||
|
||||
/* We cast to void * and then to TYPE * because this avoids
|
||||
a warning about increasing the alignment requirement. */
|
||||
#define va_arg(AP,TYPE) \
|
||||
( (AP).__va_arg = (((AP).__va_arg + (1 << (__alignof__(TYPE) >> 3)) - 1) \
|
||||
& ~((1 << (__alignof__(TYPE) >> 3)) - 1)) \
|
||||
+ __va_size(TYPE), \
|
||||
*((TYPE *) (void *) ((__va_reg_p(TYPE) \
|
||||
&& (AP).__va_arg < 8 + __va_size(TYPE) \
|
||||
? (AP).__va_reg : (AP).__va_stk) \
|
||||
+ ((AP).__va_arg - __va_size(TYPE)))))
|
||||
|
||||
#define va_end(AP) ((void)0)
|
||||
|
||||
/* Copy __gnuc_va_list into another variable of this type. */
|
||||
#define __va_copy(dest, src) (dest) = (src)
|
||||
|
||||
#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */
|
||||
@@ -0,0 +1,277 @@
|
||||
/* ---------------------------------------- */
|
||||
/* VARARGS for MIPS/GNU CC */
|
||||
/* */
|
||||
/* */
|
||||
/* */
|
||||
/* */
|
||||
/* ---------------------------------------- */
|
||||
|
||||
|
||||
/* These macros implement varargs for GNU C--either traditional or ANSI. */
|
||||
|
||||
/* Define __gnuc_va_list. */
|
||||
|
||||
#ifndef __GNUC_VA_LIST
|
||||
#define __GNUC_VA_LIST
|
||||
#if defined (__mips_eabi) && ! defined (__mips_soft_float) && ! defined (__mips_single_float)
|
||||
|
||||
typedef struct {
|
||||
/* Pointer to FP regs. */
|
||||
char *__fp_regs;
|
||||
/* Number of FP regs remaining. */
|
||||
int __fp_left;
|
||||
/* Pointer to GP regs followed by stack parameters. */
|
||||
char *__gp_regs;
|
||||
} __gnuc_va_list;
|
||||
|
||||
#else /* ! (defined (__mips_eabi) && ! defined (__mips_soft_float) && ! defined (__mips_single_float)) */
|
||||
|
||||
typedef char * __gnuc_va_list;
|
||||
|
||||
#endif /* ! (defined (__mips_eabi) && ! defined (__mips_soft_float) && ! defined (__mips_single_float)) */
|
||||
#endif /* not __GNUC_VA_LIST */
|
||||
|
||||
/* If this is for internal libc use, don't define anything but
|
||||
__gnuc_va_list. */
|
||||
#if defined (_STDARG_H) || defined (_VARARGS_H)
|
||||
|
||||
#ifndef _VA_MIPS_H_ENUM
|
||||
#define _VA_MIPS_H_ENUM
|
||||
enum {
|
||||
__no_type_class = -1,
|
||||
__void_type_class,
|
||||
__integer_type_class,
|
||||
__char_type_class,
|
||||
__enumeral_type_class,
|
||||
__boolean_type_class,
|
||||
__pointer_type_class,
|
||||
__reference_type_class,
|
||||
__offset_type_class,
|
||||
__real_type_class,
|
||||
__complex_type_class,
|
||||
__function_type_class,
|
||||
__method_type_class,
|
||||
__record_type_class,
|
||||
__union_type_class,
|
||||
__array_type_class,
|
||||
__string_type_class,
|
||||
__set_type_class,
|
||||
__file_type_class,
|
||||
__lang_type_class
|
||||
};
|
||||
#endif
|
||||
|
||||
/* In GCC version 2, we want an ellipsis at the end of the declaration
|
||||
of the argument list. GCC version 1 can't parse it. */
|
||||
|
||||
#if __GNUC__ > 1
|
||||
#define __va_ellipsis ...
|
||||
#else
|
||||
#define __va_ellipsis
|
||||
#endif
|
||||
|
||||
#ifdef __mips64
|
||||
#define __va_rounded_size(__TYPE) \
|
||||
(((sizeof (__TYPE) + 8 - 1) / 8) * 8)
|
||||
#else
|
||||
#define __va_rounded_size(__TYPE) \
|
||||
(((sizeof (__TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof (int))
|
||||
#endif
|
||||
|
||||
#ifdef __mips64
|
||||
#define __va_reg_size 8
|
||||
#else
|
||||
#define __va_reg_size 4
|
||||
#endif
|
||||
|
||||
/* Get definitions for _MIPS_SIM_ABI64 etc. */
|
||||
#ifdef _MIPS_SIM
|
||||
#include <sgidefs.h>
|
||||
#endif
|
||||
|
||||
#ifdef _STDARG_H
|
||||
#if defined (__mips_eabi)
|
||||
#if ! defined (__mips_soft_float) && ! defined (__mips_single_float)
|
||||
#ifdef __mips64
|
||||
#define va_start(__AP, __LASTARG) \
|
||||
(__AP.__gp_regs = ((char *) __builtin_next_arg (__LASTARG) \
|
||||
- (__builtin_args_info (2) < 8 \
|
||||
? (8 - __builtin_args_info (2)) * __va_reg_size \
|
||||
: 0)), \
|
||||
__AP.__fp_left = 8 - __builtin_args_info (3), \
|
||||
__AP.__fp_regs = __AP.__gp_regs - __AP.__fp_left * __va_reg_size)
|
||||
#else /* ! defined (__mips64) */
|
||||
#define va_start(__AP, __LASTARG) \
|
||||
(__AP.__gp_regs = ((char *) __builtin_next_arg (__LASTARG) \
|
||||
- (__builtin_args_info (2) < 8 \
|
||||
? (8 - __builtin_args_info (2)) * __va_reg_size \
|
||||
: 0)), \
|
||||
__AP.__fp_left = (8 - __builtin_args_info (3)) / 2, \
|
||||
__AP.__fp_regs = __AP.__gp_regs - __AP.__fp_left * 8, \
|
||||
__AP.__fp_regs = (char *) ((int) __AP.__fp_regs & -8))
|
||||
#endif /* ! defined (__mips64) */
|
||||
#else /* ! (! defined (__mips_soft_float) && ! defined (__mips_single_float) ) */
|
||||
#define va_start(__AP, __LASTARG) \
|
||||
(__AP = ((__gnuc_va_list) __builtin_next_arg (__LASTARG) \
|
||||
- (__builtin_args_info (2) >= 8 ? 0 \
|
||||
: (8 - __builtin_args_info (2)) * __va_reg_size)))
|
||||
#endif /* ! (! defined (__mips_soft_float) && ! defined (__mips_single_float) ) */
|
||||
#else /* ! defined (__mips_eabi) */
|
||||
#define va_start(__AP, __LASTARG) \
|
||||
(__AP = (__gnuc_va_list) __builtin_next_arg (__LASTARG))
|
||||
#endif /* ! (defined (__mips_eabi) && ! defined (__mips_soft_float) && ! defined (__mips_single_float)) */
|
||||
#else /* ! _STDARG_H */
|
||||
#define va_alist __builtin_va_alist
|
||||
#ifdef __mips64
|
||||
/* This assumes that `long long int' is always a 64 bit type. */
|
||||
#define va_dcl long long int __builtin_va_alist; __va_ellipsis
|
||||
#else
|
||||
#define va_dcl int __builtin_va_alist; __va_ellipsis
|
||||
#endif
|
||||
#if defined (__mips_eabi)
|
||||
#if ! defined (__mips_soft_float) && ! defined (__mips_single_float)
|
||||
#ifdef __mips64
|
||||
#define va_start(__AP) \
|
||||
(__AP.__gp_regs = ((char *) __builtin_next_arg () \
|
||||
- (__builtin_args_info (2) < 8 \
|
||||
? (8 - __builtin_args_info (2)) * __va_reg_size \
|
||||
: __va_reg_size)), \
|
||||
__AP.__fp_left = 8 - __builtin_args_info (3), \
|
||||
__AP.__fp_regs = __AP.__gp_regs - __AP.__fp_left * __va_reg_size)
|
||||
#else /* ! defined (__mips64) */
|
||||
#define va_start(__AP) \
|
||||
(__AP.__gp_regs = ((char *) __builtin_next_arg () \
|
||||
- (__builtin_args_info (2) < 8 \
|
||||
? (8 - __builtin_args_info (2)) * __va_reg_size \
|
||||
: __va_reg_size)), \
|
||||
__AP.__fp_left = (8 - __builtin_args_info (3)) / 2, \
|
||||
__AP.__fp_regs = __AP.__gp_regs - __AP.__fp_left * 8, \
|
||||
__AP.__fp_regs = (char *) ((int) __AP.__fp_regs & -8))
|
||||
#endif /* ! defined (__mips64) */
|
||||
#else /* ! (! defined (__mips_soft_float) && ! defined (__mips_single_float)) */
|
||||
#define va_start(__AP) \
|
||||
(__AP = ((__gnuc_va_list) __builtin_next_arg () \
|
||||
- (__builtin_args_info (2) >= 8 ? __va_reg_size \
|
||||
: (8 - __builtin_args_info (2)) * __va_reg_size)))
|
||||
#endif /* ! (! defined (__mips_soft_float) && ! defined (__mips_single_float)) */
|
||||
/* Need alternate code for _MIPS_SIM_ABI64. */
|
||||
#elif defined(_MIPS_SIM) && (_MIPS_SIM == _MIPS_SIM_ABI64 || _MIPS_SIM == _MIPS_SIM_NABI32)
|
||||
#define va_start(__AP) \
|
||||
(__AP = (__gnuc_va_list) __builtin_next_arg () \
|
||||
+ (__builtin_args_info (2) >= 8 ? -8 : 0))
|
||||
#else
|
||||
#define va_start(__AP) __AP = (char *) &__builtin_va_alist
|
||||
#endif
|
||||
#endif /* ! _STDARG_H */
|
||||
|
||||
#ifndef va_end
|
||||
void va_end (__gnuc_va_list); /* Defined in libgcc.a */
|
||||
#endif
|
||||
#define va_end(__AP) ((void)0)
|
||||
|
||||
#if defined (__mips_eabi)
|
||||
|
||||
#if ! defined (__mips_soft_float) && ! defined (__mips_single_float)
|
||||
#ifdef __mips64
|
||||
#define __va_next_addr(__AP, __type) \
|
||||
((__builtin_classify_type (*(__type *) 0) == __real_type_class \
|
||||
&& __AP.__fp_left > 0) \
|
||||
? (--__AP.__fp_left, (__AP.__fp_regs += 8) - 8) \
|
||||
: (__AP.__gp_regs += __va_reg_size) - __va_reg_size)
|
||||
#else
|
||||
#define __va_next_addr(__AP, __type) \
|
||||
((__builtin_classify_type (*(__type *) 0) == __real_type_class \
|
||||
&& __AP.__fp_left > 0) \
|
||||
? (--__AP.__fp_left, (__AP.__fp_regs += 8) - 8) \
|
||||
: (((__builtin_classify_type (* (__type *) 0) < __record_type_class \
|
||||
&& __alignof__ (__type) > 4) \
|
||||
? __AP.__gp_regs = (char *) (((int) __AP.__gp_regs + 8 - 1) & -8) \
|
||||
: (char *) 0), \
|
||||
(__builtin_classify_type (* (__type *) 0) >= __record_type_class \
|
||||
? (__AP.__gp_regs += __va_reg_size) - __va_reg_size \
|
||||
: ((__AP.__gp_regs += __va_rounded_size (__type)) \
|
||||
- __va_rounded_size (__type)))))
|
||||
#endif
|
||||
#else /* ! (! defined (__mips_soft_float) && ! defined (__mips_single_float)) */
|
||||
#ifdef __mips64
|
||||
#define __va_next_addr(__AP, __type) \
|
||||
((__AP += __va_reg_size) - __va_reg_size)
|
||||
#else
|
||||
#define __va_next_addr(__AP, __type) \
|
||||
(((__builtin_classify_type (* (__type *) 0) < __record_type_class \
|
||||
&& __alignof__ (__type) > 4) \
|
||||
? __AP = (char *) (((__PTRDIFF_TYPE__) __AP + 8 - 1) & -8) \
|
||||
: (char *) 0), \
|
||||
(__builtin_classify_type (* (__type *) 0) >= __record_type_class \
|
||||
? (__AP += __va_reg_size) - __va_reg_size \
|
||||
: ((__AP += __va_rounded_size (__type)) \
|
||||
- __va_rounded_size (__type))))
|
||||
#endif
|
||||
#endif /* ! (! defined (__mips_soft_float) && ! defined (__mips_single_float)) */
|
||||
|
||||
#ifdef __MIPSEB__
|
||||
#define va_arg(__AP, __type) \
|
||||
((__va_rounded_size (__type) <= __va_reg_size) \
|
||||
? *(__type *) (void *) (__va_next_addr (__AP, __type) \
|
||||
+ __va_reg_size \
|
||||
- sizeof (__type)) \
|
||||
: (__builtin_classify_type (*(__type *) 0) >= __record_type_class \
|
||||
? **(__type **) (void *) (__va_next_addr (__AP, __type) \
|
||||
+ __va_reg_size \
|
||||
- sizeof (char *)) \
|
||||
: *(__type *) (void *) __va_next_addr (__AP, __type)))
|
||||
#else
|
||||
#define va_arg(__AP, __type) \
|
||||
((__va_rounded_size (__type) <= __va_reg_size) \
|
||||
? *(__type *) (void *) __va_next_addr (__AP, __type) \
|
||||
: (__builtin_classify_type (* (__type *) 0) >= __record_type_class \
|
||||
? **(__type **) (void *) __va_next_addr (__AP, __type) \
|
||||
: *(__type *) (void *) __va_next_addr (__AP, __type)))
|
||||
#endif
|
||||
|
||||
#else /* ! defined (__mips_eabi) */
|
||||
|
||||
/* We cast to void * and then to TYPE * because this avoids
|
||||
a warning about increasing the alignment requirement. */
|
||||
/* The __mips64 cases are reversed from the 32 bit cases, because the standard
|
||||
32 bit calling convention left-aligns all parameters smaller than a word,
|
||||
whereas the __mips64 calling convention does not (and hence they are
|
||||
right aligned). */
|
||||
#ifdef __mips64
|
||||
#ifdef __MIPSEB__
|
||||
#define va_arg(__AP, __type) \
|
||||
((__type *) (void *) (__AP = (char *) \
|
||||
((((__PTRDIFF_TYPE__)__AP + 8 - 1) & -8) \
|
||||
+ __va_rounded_size (__type))))[-1]
|
||||
#else
|
||||
#define va_arg(__AP, __type) \
|
||||
((__AP = (char *) ((((__PTRDIFF_TYPE__)__AP + 8 - 1) & -8) \
|
||||
+ __va_rounded_size (__type))), \
|
||||
*(__type *) (void *) (__AP - __va_rounded_size (__type)))
|
||||
#endif
|
||||
|
||||
#else /* not __mips64 */
|
||||
|
||||
#ifdef __MIPSEB__
|
||||
/* For big-endian machines. */
|
||||
#define va_arg(__AP, __type) \
|
||||
((__AP = (char *) ((__alignof__ (__type) > 4 \
|
||||
? ((__PTRDIFF_TYPE__)__AP + 8 - 1) & -8 \
|
||||
: ((__PTRDIFF_TYPE__)__AP + 4 - 1) & -4) \
|
||||
+ __va_rounded_size (__type))), \
|
||||
*(__type *) (void *) (__AP - __va_rounded_size (__type)))
|
||||
#else
|
||||
/* For little-endian machines. */
|
||||
#define va_arg(__AP, __type) \
|
||||
((__type *) (void *) (__AP = (char *) ((__alignof__(__type) > 4 \
|
||||
? ((__PTRDIFF_TYPE__)__AP + 8 - 1) & -8 \
|
||||
: ((__PTRDIFF_TYPE__)__AP + 4 - 1) & -4) \
|
||||
+ __va_rounded_size(__type))))[-1]
|
||||
#endif
|
||||
#endif
|
||||
#endif /* ! defined (__mips_eabi) */
|
||||
|
||||
/* Copy __gnuc_va_list into another variable of this type. */
|
||||
#define __va_copy(dest, src) (dest) = (src)
|
||||
|
||||
#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */
|
||||
@@ -0,0 +1,37 @@
|
||||
/* CYGNUS LOCAL entire file/law */
|
||||
/* Define __gnuc_va_list. */
|
||||
|
||||
#ifndef __GNUC_VA_LIST
|
||||
#define __GNUC_VA_LIST
|
||||
typedef void *__gnuc_va_list;
|
||||
#endif /* not __GNUC_VA_LIST */
|
||||
|
||||
/* If this is for internal libc use, don't define anything but
|
||||
__gnuc_va_list. */
|
||||
#if defined (_STDARG_H) || defined (_VARARGS_H)
|
||||
#define __gnuc_va_start(AP) (AP = (__gnuc_va_list)__builtin_saveregs())
|
||||
#define __va_ellipsis ...
|
||||
|
||||
#ifdef _STDARG_H
|
||||
#define va_start(AP, LASTARG) \
|
||||
(AP = ((__gnuc_va_list) __builtin_next_arg (LASTARG)))
|
||||
#else
|
||||
#define va_alist __builtin_va_alist
|
||||
#define va_dcl int __builtin_va_alist; __va_ellipsis
|
||||
#define va_start(AP) AP=(char *) &__builtin_va_alist
|
||||
#endif
|
||||
|
||||
/* Now stuff common to both varargs & stdarg implementations. */
|
||||
#define __va_rounded_size(TYPE) \
|
||||
(((sizeof (TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof (int))
|
||||
#undef va_end
|
||||
void va_end (__gnuc_va_list);
|
||||
#define va_end(AP) ((void)0)
|
||||
#define va_arg(AP, TYPE) \
|
||||
(sizeof (TYPE) > 8 \
|
||||
? (AP = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (char *)),\
|
||||
**((TYPE **) (void *) ((char *) (AP) - __va_rounded_size (char *))))\
|
||||
: (AP = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (TYPE)), \
|
||||
*((TYPE *) (void *) ((char *) (AP) - __va_rounded_size (TYPE)))))
|
||||
#endif
|
||||
/* END CYGNUS LOCAL */
|
||||
@@ -0,0 +1,35 @@
|
||||
/* Define __gnuc_va_list. */
|
||||
|
||||
#ifndef __GNUC_VA_LIST
|
||||
#define __GNUC_VA_LIST
|
||||
typedef void *__gnuc_va_list;
|
||||
#endif /* not __GNUC_VA_LIST */
|
||||
|
||||
/* If this is for internal libc use, don't define anything but
|
||||
__gnuc_va_list. */
|
||||
#if defined (_STDARG_H) || defined (_VARARGS_H)
|
||||
#define __gnuc_va_start(AP) (AP = (__gnuc_va_list)__builtin_saveregs())
|
||||
#define __va_ellipsis ...
|
||||
|
||||
#ifdef _STDARG_H
|
||||
#define va_start(AP, LASTARG) \
|
||||
(__builtin_next_arg (LASTARG), __gnuc_va_start (AP))
|
||||
#else
|
||||
#define va_alist __builtin_va_alist
|
||||
#define va_dcl int __builtin_va_alist; __va_ellipsis
|
||||
#define va_start(AP) AP=(char *) &__builtin_va_alist
|
||||
#endif
|
||||
|
||||
/* Now stuff common to both varargs & stdarg implementations. */
|
||||
#define __va_rounded_size(TYPE) \
|
||||
(((sizeof (TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof (int))
|
||||
#undef va_end
|
||||
void va_end (__gnuc_va_list);
|
||||
#define va_end(AP) ((void)0)
|
||||
#define va_arg(AP, TYPE) \
|
||||
(sizeof (TYPE) > 8 \
|
||||
? (AP = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (char *)),\
|
||||
**((TYPE **) (void *) ((char *) (AP) - __va_rounded_size (char *))))\
|
||||
: (AP = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (TYPE)), \
|
||||
*((TYPE *) (void *) ((char *) (AP) - __va_rounded_size (TYPE)))))
|
||||
#endif
|
||||
@@ -0,0 +1,52 @@
|
||||
|
||||
/* Define __gnuc_va_list. */
|
||||
|
||||
#ifndef __GNUC_VA_LIST
|
||||
#define __GNUC_VA_LIST
|
||||
|
||||
typedef void *__gnuc_va_list;
|
||||
#endif /* not __GNUC_VA_LIST */
|
||||
|
||||
/* If this is for internal libc use, don't define anything but
|
||||
__gnuc_va_list. */
|
||||
#if defined (_STDARG_H) || defined (_VARARGS_H)
|
||||
#if __GNUC__ > 1
|
||||
#define __va_ellipsis ...
|
||||
#define __gnuc_va_start(AP) ((AP) = (va_list)__builtin_saveregs())
|
||||
#else
|
||||
#define va_alist __va_a__, __va_b__, __va_c__, __va_d__
|
||||
#define __va_ellipsis
|
||||
#define __gnuc_va_start(AP)\
|
||||
(AP) = (double *) &__va_a__, &__va_b__, &__va_c__, &__va_d__, \
|
||||
(AP) = (double *)((char *)(AP) + 4)
|
||||
#endif /* __GNUC__ > 1 */
|
||||
|
||||
/* Call __builtin_next_arg even though we aren't using its value, so that
|
||||
we can verify that LASTARG is correct. */
|
||||
#ifdef _STDARG_H
|
||||
#define va_start(AP,LASTARG) \
|
||||
(__builtin_next_arg (LASTARG), __gnuc_va_start (AP))
|
||||
#else
|
||||
/* The ... causes current_function_varargs to be set in cc1. */
|
||||
#define va_dcl long va_alist; __va_ellipsis
|
||||
#define va_start(AP) __gnuc_va_start (AP)
|
||||
#endif
|
||||
|
||||
#define va_arg(AP,TYPE) \
|
||||
(*(sizeof(TYPE) > 8 ? \
|
||||
((AP = (__gnuc_va_list) ((char *)AP - sizeof (int))), \
|
||||
(((TYPE *) (void *) (*((int *) (AP)))))) \
|
||||
:((AP = \
|
||||
(__gnuc_va_list) ((long)((char *)AP - sizeof (TYPE)) \
|
||||
& (sizeof(TYPE) > 4 ? ~0x7 : ~0x3))), \
|
||||
(((TYPE *) (void *) ((char *)AP + ((8 - sizeof(TYPE)) % 4)))))))
|
||||
|
||||
#ifndef va_end
|
||||
void va_end (__gnuc_va_list); /* Defined in libgcc.a */
|
||||
#endif
|
||||
#define va_end(AP) ((void)0)
|
||||
|
||||
/* Copy __gnuc_va_list into another variable of this type. */
|
||||
#define __va_copy(dest, src) (dest) = (src)
|
||||
|
||||
#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */
|
||||
@@ -0,0 +1,255 @@
|
||||
/* GNU C varargs support for the PowerPC with either the V.4 or Windows NT calling sequences */
|
||||
|
||||
#ifndef _WIN32
|
||||
/* System V.4 support */
|
||||
/* Define __gnuc_va_list. */
|
||||
|
||||
#ifndef __GNUC_VA_LIST
|
||||
#define __GNUC_VA_LIST
|
||||
|
||||
#ifndef _SYS_VA_LIST_H
|
||||
#define _SYS_VA_LIST_H /* Solaris sys/va_list.h */
|
||||
|
||||
/* Solaris decided to rename overflow_arg_area to input_arg_area,
|
||||
so handle it via a macro. */
|
||||
#define __va_overflow(AP) (AP)->overflow_arg_area
|
||||
|
||||
/* Note that the names in this structure are in the user's namespace, but
|
||||
that the V.4 abi explicitly states that these names should be used. */
|
||||
typedef struct __va_list_tag {
|
||||
unsigned char gpr; /* index into the array of 8 GPRs stored in the
|
||||
register save area gpr=0 corresponds to r3,
|
||||
gpr=1 to r4, etc. */
|
||||
unsigned char fpr; /* index into the array of 8 FPRs stored in the
|
||||
register save area fpr=0 corresponds to f1,
|
||||
fpr=1 to f2, etc. */
|
||||
char *overflow_arg_area; /* location on stack that holds the next
|
||||
overflow argument */
|
||||
char *reg_save_area; /* where r3:r10 and f1:f8, if saved are stored */
|
||||
} __va_list[1], __gnuc_va_list[1];
|
||||
|
||||
#else /* _SYS_VA_LIST */
|
||||
|
||||
typedef __va_list __gnuc_va_list;
|
||||
#define __va_overflow(AP) (AP)->input_arg_area
|
||||
|
||||
#endif /* not _SYS_VA_LIST */
|
||||
#endif /* not __GNUC_VA_LIST */
|
||||
|
||||
/* If this is for internal libc use, don't define anything but
|
||||
__gnuc_va_list. */
|
||||
#if defined (_STDARG_H) || defined (_VARARGS_H)
|
||||
|
||||
/* Register save area located below the frame pointer */
|
||||
#ifndef __VA_PPC_H__
|
||||
#define __VA_PPC_H__
|
||||
typedef struct {
|
||||
long __gp_save[8]; /* save area for GP registers */
|
||||
double __fp_save[8]; /* save area for FP registers */
|
||||
} __va_regsave_t;
|
||||
|
||||
/* Macros to access the register save area */
|
||||
/* We cast to void * and then to TYPE * because this avoids
|
||||
a warning about increasing the alignment requirement. */
|
||||
#define __VA_FP_REGSAVE(AP,OFS,TYPE) \
|
||||
((TYPE *) (void *) (&(((__va_regsave_t *) \
|
||||
(AP)->reg_save_area)->__fp_save[OFS])))
|
||||
|
||||
#define __VA_GP_REGSAVE(AP,OFS,TYPE) \
|
||||
((TYPE *) (void *) (&(((__va_regsave_t *) \
|
||||
(AP)->reg_save_area)->__gp_save[OFS])))
|
||||
|
||||
/* Common code for va_start for both varargs and stdarg. We allow all
|
||||
the work to be done by __builtin_saveregs. It returns a pointer to
|
||||
a va_list that was constructed on the stack; we must simply copy it
|
||||
to the user's variable. */
|
||||
|
||||
#define __va_start_common(AP, FAKE) \
|
||||
__builtin_memcpy ((AP), __builtin_saveregs (), sizeof(__gnuc_va_list))
|
||||
|
||||
#ifdef _STDARG_H /* stdarg.h support */
|
||||
|
||||
/* Calling __builtin_next_arg gives the proper error message if LASTARG is
|
||||
not indeed the last argument. */
|
||||
#define va_start(AP,LASTARG) \
|
||||
(__builtin_next_arg (LASTARG), __va_start_common (AP, 0))
|
||||
|
||||
#else /* varargs.h support */
|
||||
|
||||
#define va_start(AP) __va_start_common (AP, 1)
|
||||
#define va_alist __va_1st_arg
|
||||
#define va_dcl register int va_alist; ...
|
||||
|
||||
#endif /* _STDARG_H */
|
||||
|
||||
#ifdef _SOFT_FLOAT
|
||||
#define __va_float_p(TYPE) 0
|
||||
#else
|
||||
#define __va_float_p(TYPE) (__builtin_classify_type(*(TYPE *)0) == 8)
|
||||
#endif
|
||||
|
||||
#define __va_aggregate_p(TYPE) (__builtin_classify_type(*(TYPE *)0) >= 12)
|
||||
#define __va_size(TYPE) ((sizeof(TYPE) + sizeof (long) - 1) / sizeof (long))
|
||||
|
||||
/* This symbol isn't defined. It is used to flag type promotion violations
|
||||
at link time. We can only do this when optimizing. Use __builtin_trap
|
||||
instead of abort so that we don't require a prototype for abort.
|
||||
|
||||
__builtin_trap stuff is not available on the gcc-2.95 branch, so we just
|
||||
avoid calling it for now. */
|
||||
|
||||
#ifdef __OPTIMIZE__
|
||||
extern void __va_arg_type_violation(void) __attribute__((__noreturn__));
|
||||
#else
|
||||
#define __va_arg_type_violation()
|
||||
#endif
|
||||
|
||||
#define va_arg(AP,TYPE) \
|
||||
__extension__ (*({ \
|
||||
register TYPE *__ptr; \
|
||||
\
|
||||
if (__va_float_p (TYPE) && sizeof (TYPE) < 16) \
|
||||
{ \
|
||||
unsigned char __fpr = (AP)->fpr; \
|
||||
if (__fpr < 8) \
|
||||
{ \
|
||||
__ptr = __VA_FP_REGSAVE (AP, __fpr, TYPE); \
|
||||
(AP)->fpr = __fpr + 1; \
|
||||
} \
|
||||
else if (sizeof (TYPE) == 8) \
|
||||
{ \
|
||||
unsigned long __addr = (unsigned long) (__va_overflow (AP)); \
|
||||
__ptr = (TYPE *)((__addr + 7) & -8); \
|
||||
__va_overflow (AP) = (char *)(__ptr + 1); \
|
||||
} \
|
||||
else \
|
||||
{ \
|
||||
/* float is promoted to double. */ \
|
||||
__va_arg_type_violation (); \
|
||||
} \
|
||||
} \
|
||||
\
|
||||
/* Aggregates and long doubles are passed by reference. */ \
|
||||
else if (__va_aggregate_p (TYPE) || __va_float_p (TYPE)) \
|
||||
{ \
|
||||
unsigned char __gpr = (AP)->gpr; \
|
||||
if (__gpr < 8) \
|
||||
{ \
|
||||
__ptr = * __VA_GP_REGSAVE (AP, __gpr, TYPE *); \
|
||||
(AP)->gpr = __gpr + 1; \
|
||||
} \
|
||||
else \
|
||||
{ \
|
||||
TYPE **__pptr = (TYPE **) (__va_overflow (AP)); \
|
||||
__ptr = * __pptr; \
|
||||
__va_overflow (AP) = (char *) (__pptr + 1); \
|
||||
} \
|
||||
} \
|
||||
\
|
||||
/* Only integrals remaining. */ \
|
||||
else \
|
||||
{ \
|
||||
/* longlong is aligned. */ \
|
||||
if (sizeof (TYPE) == 8) \
|
||||
{ \
|
||||
unsigned char __gpr = (AP)->gpr; \
|
||||
if (__gpr < 7) \
|
||||
{ \
|
||||
__gpr += __gpr & 1; \
|
||||
__ptr = __VA_GP_REGSAVE (AP, __gpr, TYPE); \
|
||||
(AP)->gpr = __gpr + 2; \
|
||||
} \
|
||||
else \
|
||||
{ \
|
||||
unsigned long __addr = (unsigned long) (__va_overflow (AP)); \
|
||||
__ptr = (TYPE *)((__addr + 7) & -8); \
|
||||
(AP)->gpr = 8; \
|
||||
__va_overflow (AP) = (char *)(__ptr + 1); \
|
||||
} \
|
||||
} \
|
||||
else if (sizeof (TYPE) == 4) \
|
||||
{ \
|
||||
unsigned char __gpr = (AP)->gpr; \
|
||||
if (__gpr < 8) \
|
||||
{ \
|
||||
__ptr = __VA_GP_REGSAVE (AP, __gpr, TYPE); \
|
||||
(AP)->gpr = __gpr + 1; \
|
||||
} \
|
||||
else \
|
||||
{ \
|
||||
__ptr = (TYPE *) __va_overflow (AP); \
|
||||
__va_overflow (AP) = (char *)(__ptr + 1); \
|
||||
} \
|
||||
} \
|
||||
else \
|
||||
{ \
|
||||
/* Everything else was promoted to int. */ \
|
||||
__va_arg_type_violation (); \
|
||||
} \
|
||||
} \
|
||||
__ptr; \
|
||||
}))
|
||||
|
||||
#define va_end(AP) ((void)0)
|
||||
|
||||
/* Copy __gnuc_va_list into another variable of this type. */
|
||||
#define __va_copy(dest, src) *(dest) = *(src)
|
||||
|
||||
#endif /* __VA_PPC_H__ */
|
||||
#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */
|
||||
|
||||
|
||||
#else
|
||||
/* Windows NT */
|
||||
/* Define __gnuc_va_list. */
|
||||
|
||||
#ifndef __GNUC_VA_LIST
|
||||
#define __GNUC_VA_LIST
|
||||
typedef char *__gnuc_va_list;
|
||||
#endif /* not __GNUC_VA_LIST */
|
||||
|
||||
/* If this is for internal libc use, don't define anything but
|
||||
__gnuc_va_list. */
|
||||
#if defined (_STDARG_H) || defined (_VARARGS_H)
|
||||
|
||||
#define __va_start_common(AP, LASTARG, FAKE) \
|
||||
((__builtin_saveregs ()), ((AP) = ((char *) &LASTARG) + __va_rounded_size (AP)), 0)
|
||||
|
||||
#ifdef _STDARG_H /* stdarg.h support */
|
||||
|
||||
/* Calling __builtin_next_arg gives the proper error message if LASTARG is
|
||||
not indeed the last argument. */
|
||||
#define va_start(AP,LASTARG) \
|
||||
(__builtin_saveregs (), \
|
||||
(AP) = __builtin_next_arg (LASTARG), \
|
||||
0)
|
||||
|
||||
#else /* varargs.h support */
|
||||
|
||||
#define va_start(AP) \
|
||||
(__builtin_saveregs (), \
|
||||
(AP) = __builtin_next_arg (__va_1st_arg) - sizeof (int), \
|
||||
0)
|
||||
|
||||
#define va_alist __va_1st_arg
|
||||
#define va_dcl register int __va_1st_arg; ...
|
||||
|
||||
#endif /* _STDARG_H */
|
||||
|
||||
#define __va_rounded_size(TYPE) ((sizeof (TYPE) + 3) & ~3)
|
||||
#define __va_align(AP, TYPE) \
|
||||
((((unsigned long)(AP)) + ((sizeof (TYPE) >= 8) ? 7 : 3)) \
|
||||
& ~((sizeof (TYPE) >= 8) ? 7 : 3))
|
||||
|
||||
#define va_arg(AP,TYPE) \
|
||||
( *(TYPE *)((AP = (char *) (__va_align(AP, TYPE) \
|
||||
+ __va_rounded_size(TYPE))) \
|
||||
- __va_rounded_size(TYPE)))
|
||||
|
||||
#define va_end(AP) ((void)0)
|
||||
|
||||
/* Copy __gnuc_va_list into another variable of this type. */
|
||||
#define __va_copy(dest, src) (dest) = (src)
|
||||
|
||||
#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */
|
||||
#endif /* Windows NT */
|
||||
@@ -0,0 +1,130 @@
|
||||
/**
|
||||
*
|
||||
* Varargs for PYR/GNU CC
|
||||
*
|
||||
* WARNING -- WARNING -- DANGER
|
||||
*
|
||||
* The code in this file implements varargs for gcc on a pyr in
|
||||
* a way that is compatible with code compiled by the Pyramid Technology
|
||||
* C compiler.
|
||||
* As such, it depends strongly on the Pyramid conventions for
|
||||
* parameter passing.ct and independent implementation.
|
||||
* These (somewhat bizarre) parameter-passing conventions are described
|
||||
* in the ``OSx Operating System Porting Guide''.
|
||||
*
|
||||
* A quick summary is useful:
|
||||
* 12 of the 48 register-windowed regs available for
|
||||
* parameter passing. Parameters of a function call that are eligible
|
||||
* to be passed in registers are assigned registers from TR0/PR0 onwards;
|
||||
* all other arguments are passed on the stack.
|
||||
* Structure and union parameters are *never* passed in registers,
|
||||
* even if they are small enough to fit. They are always passed on
|
||||
* the stack.
|
||||
*
|
||||
* Double-sized parameters cannot be passed in TR11, because
|
||||
* TR12 is not used for passing parameters. If, in the absence of this
|
||||
* rule, a double-sized param would have been passed in TR11,
|
||||
* that parameter is passed on the stack and no parameters are
|
||||
* passed in TR11.
|
||||
*
|
||||
* It is only known to work for passing 32-bit integer quantities
|
||||
* (ie chars, shorts, ints/enums, longs), doubles, or pointers.
|
||||
* Passing structures on a Pyramid via varargs is a loser.
|
||||
* Passing an object larger than 8 bytes on a pyramid via varargs may
|
||||
* also be a loser.
|
||||
*
|
||||
*/
|
||||
|
||||
|
||||
/*
|
||||
* pointer to next stack parameter in __va_buf[0]
|
||||
* pointer to next parameter register in __va_buf[1]
|
||||
* Count of registers seen at __va_buf[2]
|
||||
* saved pr0..pr11 in __va_buf[3..14]
|
||||
* # of calls to va_arg (debugging) at __va_buf[15]
|
||||
*/
|
||||
|
||||
/* Define __gnuc_va_list. */
|
||||
|
||||
#ifndef __GNUC_VA_LIST
|
||||
#define __GNUC_VA_LIST
|
||||
|
||||
typedef void *__voidptr;
|
||||
#if 1
|
||||
|
||||
typedef struct __va_regs {
|
||||
__voidptr __stackp,__regp,__count;
|
||||
__voidptr __pr0,__pr1,__pr2,__pr3,__pr4,__pr5,__pr6,__pr7,__pr8,__pr9,__pr10,__pr11;
|
||||
} __va_regs;
|
||||
|
||||
typedef __va_regs __va_buf;
|
||||
#else
|
||||
|
||||
/* __va_buf[0] = address of next arg passed on the stack
|
||||
__va_buf[1] = address of next arg passed in a register
|
||||
__va_buf[2] = register-# of next arg passed in a register
|
||||
*/
|
||||
typedef __voidptr(*__va_buf);
|
||||
|
||||
#endif
|
||||
|
||||
typedef __va_buf __gnuc_va_list;
|
||||
|
||||
#endif /* not __GNUC_VA_LIST */
|
||||
|
||||
/* If this is for internal libc use, don't define anything but
|
||||
__gnuc_va_list. */
|
||||
#if defined (_STDARG_H) || defined (_VARARGS_H)
|
||||
|
||||
/* In GCC version 2, we want an ellipsis at the end of the declaration
|
||||
of the argument list. GCC version 1 can't parse it. */
|
||||
|
||||
#if __GNUC__ > 1
|
||||
#define __va_ellipsis ...
|
||||
#else
|
||||
#define __va_ellipsis
|
||||
#endif
|
||||
|
||||
#define va_alist \
|
||||
__va0,__va1,__va2,__va3,__va4,__va5,__va6,__va7,__va8,__va9,__va10,__va11, \
|
||||
__builtin_va_alist
|
||||
|
||||
/* The ... causes current_function_varargs to be set in cc1. */
|
||||
#define va_dcl __voidptr va_alist; __va_ellipsis
|
||||
|
||||
|
||||
/* __asm ("rcsp %0" : "=r" ( _AP [0]));*/
|
||||
|
||||
#define va_start(_AP) \
|
||||
_AP = ((struct __va_regs) { \
|
||||
&(_AP.__pr0), (void*)&__builtin_va_alist, (void*)0, \
|
||||
__va0,__va1,__va2,__va3,__va4,__va5, \
|
||||
__va6,__va7,__va8,__va9,__va10,__va11})
|
||||
|
||||
|
||||
/* Avoid errors if compiling GCC v2 with GCC v1. */
|
||||
#if __GNUC__ == 1
|
||||
#define __extension__
|
||||
#endif
|
||||
|
||||
/* We cast to void * and then to TYPE * because this avoids
|
||||
a warning about increasing the alignment requirement. */
|
||||
#define va_arg(_AP, _MODE) \
|
||||
__extension__ \
|
||||
(*({__voidptr *__ap = (__voidptr*)&_AP; \
|
||||
register int __size = sizeof (_MODE); \
|
||||
register int __onstack = \
|
||||
(__size > 8 || ( (int)(__ap[2]) > 11) || \
|
||||
(__size==8 && (int)(__ap[2])==11)); \
|
||||
register int* __param_addr = ((int*)((__ap) [__onstack])); \
|
||||
\
|
||||
((void *)__ap[__onstack])+=__size; \
|
||||
if (__onstack==0 || (int)(__ap[2])==11) \
|
||||
__ap[2]+= (__size >> 2); \
|
||||
(( _MODE *) (void *) __param_addr); \
|
||||
}))
|
||||
|
||||
void va_end (__gnuc_va_list); /* Defined in libgcc.a */
|
||||
#define va_end(_X) ((void)0)
|
||||
|
||||
#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */
|
||||
@@ -0,0 +1,229 @@
|
||||
/* The ! __SH3E_VARG case is similar to the default gvarargs.h . */
|
||||
|
||||
#if (defined (__SH3E__) || defined (__SH4_SINGLE__) || defined (__SH4__) || defined (__SH4_SINGLE_ONLY__)) && ! defined (__HITACHI__)
|
||||
#define __SH3E_VARG
|
||||
#endif
|
||||
|
||||
/* Define __gnuc_va_list. */
|
||||
|
||||
#ifndef __GNUC_VA_LIST
|
||||
#define __GNUC_VA_LIST
|
||||
|
||||
#ifdef __SH3E_VARG
|
||||
|
||||
typedef long __va_greg;
|
||||
typedef float __va_freg;
|
||||
|
||||
typedef struct {
|
||||
__va_greg * __va_next_o; /* next available register */
|
||||
__va_greg * __va_next_o_limit; /* past last available register */
|
||||
__va_freg * __va_next_fp; /* next available fp register */
|
||||
__va_freg * __va_next_fp_limit; /* last available fp register */
|
||||
__va_greg * __va_next_stack; /* next extended word on stack */
|
||||
} __gnuc_va_list;
|
||||
|
||||
#else /* ! SH3E */
|
||||
|
||||
typedef void *__gnuc_va_list;
|
||||
|
||||
#endif /* ! SH3E */
|
||||
|
||||
#endif /* __GNUC_VA_LIST */
|
||||
|
||||
/* If this is for internal libc use, don't define anything but
|
||||
__gnuc_va_list. */
|
||||
#if defined (_STDARG_H) || defined (_VARARGS_H)
|
||||
|
||||
#ifdef _STDARG_H
|
||||
|
||||
#ifdef __SH3E_VARG
|
||||
|
||||
#define va_start(AP, LASTARG) \
|
||||
__extension__ \
|
||||
({ \
|
||||
(AP).__va_next_fp = (__va_freg *) __builtin_saveregs (); \
|
||||
(AP).__va_next_fp_limit = ((AP).__va_next_fp + \
|
||||
(__builtin_args_info (1) < 8 ? 8 - __builtin_args_info (1) : 0)); \
|
||||
(AP).__va_next_o = (__va_greg *) (AP).__va_next_fp_limit; \
|
||||
(AP).__va_next_o_limit = ((AP).__va_next_o + \
|
||||
(__builtin_args_info (0) < 4 ? 4 - __builtin_args_info (0) : 0)); \
|
||||
(AP).__va_next_stack = (__va_greg *) __builtin_next_arg (LASTARG); \
|
||||
})
|
||||
|
||||
#else /* ! SH3E */
|
||||
|
||||
#define va_start(AP, LASTARG) \
|
||||
((AP) = ((__gnuc_va_list) __builtin_next_arg (LASTARG)))
|
||||
|
||||
#endif /* ! SH3E */
|
||||
|
||||
#else /* _VARARGS_H */
|
||||
|
||||
#define va_alist __builtin_va_alist
|
||||
#define va_dcl int __builtin_va_alist;...
|
||||
|
||||
#ifdef __SH3E_VARG
|
||||
|
||||
#define va_start(AP) \
|
||||
__extension__ \
|
||||
({ \
|
||||
(AP).__va_next_fp = (__va_freg *) __builtin_saveregs (); \
|
||||
(AP).__va_next_fp_limit = ((AP).__va_next_fp + \
|
||||
(__builtin_args_info (1) < 8 ? 8 - __builtin_args_info (1) : 0)); \
|
||||
(AP).__va_next_o = (__va_greg *) (AP).__va_next_fp_limit; \
|
||||
(AP).__va_next_o_limit = ((AP).__va_next_o + \
|
||||
(__builtin_args_info (0) < 4 ? 4 - __builtin_args_info (0) : 0)); \
|
||||
(AP).__va_next_stack \
|
||||
= ((__va_greg *) __builtin_next_arg (__builtin_va_alist) \
|
||||
- (__builtin_args_info (0) >= 4 || __builtin_args_info (1) >= 8 \
|
||||
? 1 : 0)); \
|
||||
})
|
||||
|
||||
#else /* ! SH3E */
|
||||
|
||||
#define va_start(AP) ((AP) = (char *) &__builtin_va_alist)
|
||||
|
||||
#endif /* ! SH3E */
|
||||
|
||||
#endif /* _STDARG */
|
||||
|
||||
#ifndef va_end
|
||||
void va_end (__gnuc_va_list); /* Defined in libgcc.a */
|
||||
|
||||
/* Values returned by __builtin_classify_type. */
|
||||
|
||||
enum __va_type_classes {
|
||||
__no_type_class = -1,
|
||||
__void_type_class,
|
||||
__integer_type_class,
|
||||
__char_type_class,
|
||||
__enumeral_type_class,
|
||||
__boolean_type_class,
|
||||
__pointer_type_class,
|
||||
__reference_type_class,
|
||||
__offset_type_class,
|
||||
__real_type_class,
|
||||
__complex_type_class,
|
||||
__function_type_class,
|
||||
__method_type_class,
|
||||
__record_type_class,
|
||||
__union_type_class,
|
||||
__array_type_class,
|
||||
__string_type_class,
|
||||
__set_type_class,
|
||||
__file_type_class,
|
||||
__lang_type_class
|
||||
};
|
||||
|
||||
#endif
|
||||
#define va_end(pvar) ((void)0)
|
||||
|
||||
#ifdef __LITTLE_ENDIAN__
|
||||
#define __LITTLE_ENDIAN_P 1
|
||||
#else
|
||||
#define __LITTLE_ENDIAN_P 0
|
||||
#endif
|
||||
|
||||
#define __SCALAR_TYPE(TYPE) \
|
||||
((TYPE) == __integer_type_class \
|
||||
|| (TYPE) == __char_type_class \
|
||||
|| (TYPE) == __enumeral_type_class)
|
||||
|
||||
/* RECORD_TYPE args passed using the C calling convention are
|
||||
passed by invisible reference. ??? RECORD_TYPE args passed
|
||||
in the stack are made to be word-aligned; for an aggregate that is
|
||||
not word-aligned, we advance the pointer to the first non-reg slot. */
|
||||
|
||||
/* When this is a smaller-than-int integer, using
|
||||
auto-increment in the promoted (SImode) is fastest;
|
||||
however, there is no way to express that is C. Therefore,
|
||||
we use an asm.
|
||||
We want the MEM_IN_STRUCT_P bit set in the emitted RTL, therefore we
|
||||
use unions even when it would otherwise be unnecessary. */
|
||||
|
||||
/* gcc has an extension that allows to use a casted lvalue as an lvalue,
|
||||
But it doesn't work in C++ with -pedantic - even in the presence of
|
||||
__extension__ . We work around this problem by using a reference type. */
|
||||
#ifdef __cplusplus
|
||||
#define __VA_REF &
|
||||
#else
|
||||
#define __VA_REF
|
||||
#endif
|
||||
|
||||
#define __va_arg_sh1(AP, TYPE) __extension__ \
|
||||
({(sizeof (TYPE) == 1 \
|
||||
? ({union {TYPE t; char c;} __t; \
|
||||
__asm("" \
|
||||
: "=r" (__t.c) \
|
||||
: "0" ((((union { int i, j; } *__VA_REF) (AP))++)->i)); \
|
||||
__t.t;}) \
|
||||
: sizeof (TYPE) == 2 \
|
||||
? ({union {TYPE t; short s;} __t; \
|
||||
__asm("" \
|
||||
: "=r" (__t.s) \
|
||||
: "0" ((((union { int i, j; } *__VA_REF) (AP))++)->i)); \
|
||||
__t.t;}) \
|
||||
: sizeof (TYPE) >= 4 || __LITTLE_ENDIAN_P \
|
||||
? (((union { TYPE t; int i;} *__VA_REF) (AP))++)->t \
|
||||
: ((union {TYPE t;TYPE u;}*) ((char *)++(int *__VA_REF)(AP) - sizeof (TYPE)))->t);})
|
||||
|
||||
#ifdef __SH3E_VARG
|
||||
|
||||
#define __PASS_AS_FLOAT(TYPE_CLASS,SIZE) \
|
||||
(TYPE_CLASS == __real_type_class && SIZE == 4)
|
||||
|
||||
#define __TARGET_SH4_P 0
|
||||
|
||||
#if defined(__SH4__) || defined(__SH4_SINGLE__)
|
||||
#undef __PASS_AS_FLOAT
|
||||
#define __PASS_AS_FLOAT(TYPE_CLASS,SIZE) \
|
||||
(TYPE_CLASS == __real_type_class && SIZE <= 8 \
|
||||
|| TYPE_CLASS == __complex_type_class && SIZE <= 16)
|
||||
#undef __TARGET_SH4_P
|
||||
#define __TARGET_SH4_P 1
|
||||
#endif
|
||||
|
||||
#define va_arg(pvar,TYPE) \
|
||||
__extension__ \
|
||||
({int __type = __builtin_classify_type (* (TYPE *) 0); \
|
||||
void * __result_p; \
|
||||
if (__PASS_AS_FLOAT (__type, sizeof(TYPE))) \
|
||||
{ \
|
||||
if ((pvar).__va_next_fp < (pvar).__va_next_fp_limit) \
|
||||
{ \
|
||||
if (((__type == __real_type_class && sizeof (TYPE) > 4)\
|
||||
|| sizeof (TYPE) > 8) \
|
||||
&& (((int) (pvar).__va_next_fp ^ (int) (pvar).__va_next_fp_limit)\
|
||||
& 4)) \
|
||||
(pvar).__va_next_fp++; \
|
||||
__result_p = &(pvar).__va_next_fp; \
|
||||
} \
|
||||
else \
|
||||
__result_p = &(pvar).__va_next_stack; \
|
||||
} \
|
||||
else \
|
||||
{ \
|
||||
if ((pvar).__va_next_o + ((sizeof (TYPE) + 3) / 4) \
|
||||
<= (pvar).__va_next_o_limit) \
|
||||
__result_p = &(pvar).__va_next_o; \
|
||||
else \
|
||||
{ \
|
||||
if (sizeof (TYPE) > 4) \
|
||||
if (! __TARGET_SH4_P) \
|
||||
(pvar).__va_next_o = (pvar).__va_next_o_limit; \
|
||||
\
|
||||
__result_p = &(pvar).__va_next_stack; \
|
||||
} \
|
||||
} \
|
||||
__va_arg_sh1(*(void **)__result_p, TYPE);})
|
||||
|
||||
#else /* ! SH3E */
|
||||
|
||||
#define va_arg(AP, TYPE) __va_arg_sh1((AP), TYPE)
|
||||
|
||||
#endif /* SH3E */
|
||||
|
||||
/* Copy __gnuc_va_list into another variable of this type. */
|
||||
#define __va_copy(dest, src) ((dest) = (src))
|
||||
|
||||
#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */
|
||||
@@ -0,0 +1,165 @@
|
||||
/* This is just like the default gvarargs.h
|
||||
except for differences described below. */
|
||||
|
||||
/* Define __gnuc_va_list. */
|
||||
|
||||
#ifndef __GNUC_VA_LIST
|
||||
#define __GNUC_VA_LIST
|
||||
#if ! defined (__svr4__) && ! defined (__linux__) && ! defined (__arch64__)
|
||||
/* This has to be a char * to be compatible with Sun.
|
||||
i.e., we have to pass a `va_list' to vsprintf. */
|
||||
typedef char * __gnuc_va_list;
|
||||
#else
|
||||
/* This has to be a void * to be compatible with Sun svr4.
|
||||
i.e., we have to pass a `va_list' to vsprintf. */
|
||||
typedef void * __gnuc_va_list;
|
||||
#endif
|
||||
#endif /* not __GNUC_VA_LIST */
|
||||
|
||||
/* If this is for internal libc use, don't define anything but
|
||||
__gnuc_va_list. */
|
||||
#if defined (_STDARG_H) || defined (_VARARGS_H)
|
||||
|
||||
#ifdef _STDARG_H
|
||||
|
||||
/* Call __builtin_next_arg even though we aren't using its value, so that
|
||||
we can verify that LASTARG is correct. */
|
||||
#if defined (__GCC_NEW_VARARGS__) || defined (__arch64__)
|
||||
#define va_start(AP, LASTARG) \
|
||||
(__builtin_next_arg (LASTARG), AP = (char *) __builtin_saveregs ())
|
||||
#else
|
||||
#define va_start(AP, LASTARG) \
|
||||
(__builtin_saveregs (), AP = ((char *) __builtin_next_arg (LASTARG)))
|
||||
#endif
|
||||
|
||||
#else
|
||||
|
||||
#define va_alist __builtin_va_alist
|
||||
#define va_dcl int __builtin_va_alist;...
|
||||
|
||||
#if defined (__GCC_NEW_VARARGS__) || defined (__arch64__)
|
||||
#define va_start(AP) ((AP) = (char *) __builtin_saveregs ())
|
||||
#else
|
||||
#define va_start(AP) \
|
||||
(__builtin_saveregs (), (AP) = ((char *) &__builtin_va_alist))
|
||||
#endif
|
||||
|
||||
#endif
|
||||
|
||||
#ifndef va_end
|
||||
void va_end (__gnuc_va_list); /* Defined in libgcc.a */
|
||||
|
||||
/* Values returned by __builtin_classify_type. */
|
||||
|
||||
enum __va_type_classes {
|
||||
__no_type_class = -1,
|
||||
__void_type_class,
|
||||
__integer_type_class,
|
||||
__char_type_class,
|
||||
__enumeral_type_class,
|
||||
__boolean_type_class,
|
||||
__pointer_type_class,
|
||||
__reference_type_class,
|
||||
__offset_type_class,
|
||||
__real_type_class,
|
||||
__complex_type_class,
|
||||
__function_type_class,
|
||||
__method_type_class,
|
||||
__record_type_class,
|
||||
__union_type_class,
|
||||
__array_type_class,
|
||||
__string_type_class,
|
||||
__set_type_class,
|
||||
__file_type_class,
|
||||
__lang_type_class
|
||||
};
|
||||
|
||||
#endif
|
||||
#define va_end(pvar) ((void)0)
|
||||
|
||||
/* Avoid errors if compiling GCC v2 with GCC v1. */
|
||||
#if __GNUC__ == 1
|
||||
#define __extension__
|
||||
#endif
|
||||
|
||||
/* RECORD_TYPE args passed using the C calling convention are
|
||||
passed by invisible reference. ??? RECORD_TYPE args passed
|
||||
in the stack are made to be word-aligned; for an aggregate that is
|
||||
not word-aligned, we advance the pointer to the first non-reg slot. */
|
||||
|
||||
#ifdef __arch64__
|
||||
|
||||
typedef unsigned int __ptrint __attribute__ ((__mode__ (__DI__)));
|
||||
|
||||
/* ??? TODO: little endian support */
|
||||
|
||||
#define va_arg(pvar, TYPE) \
|
||||
__extension__ \
|
||||
(*({int __type = __builtin_classify_type (* (TYPE *) 0); \
|
||||
char * __result; \
|
||||
if (__type == __real_type_class) /* float? */ \
|
||||
{ \
|
||||
if (__alignof__ (TYPE) == 16) \
|
||||
(pvar) = (void *) (((__ptrint) (pvar) + 15) & -16); \
|
||||
__result = (pvar); \
|
||||
(pvar) = (char *) (pvar) + sizeof (TYPE); \
|
||||
} \
|
||||
else if (__type < __record_type_class) /* integer? */ \
|
||||
{ \
|
||||
(pvar) = (char *) (pvar) + 8; \
|
||||
__result = (char *) (pvar) - sizeof (TYPE); \
|
||||
} \
|
||||
else /* aggregate object */ \
|
||||
{ \
|
||||
if (sizeof (TYPE) <= 8) \
|
||||
{ \
|
||||
__result = (pvar); \
|
||||
(pvar) = (char *) (pvar) + 8; \
|
||||
} \
|
||||
else if (sizeof (TYPE) <= 16) \
|
||||
{ \
|
||||
if (__alignof__ (TYPE) == 16) \
|
||||
(pvar) = (void *) (((__ptrint) (pvar) + 15) & -16); \
|
||||
__result = (pvar); \
|
||||
(pvar) = (char *) (pvar) + 16; \
|
||||
} \
|
||||
else \
|
||||
{ \
|
||||
__result = * (void **) (pvar); \
|
||||
(pvar) = (char *) (pvar) + 8; \
|
||||
} \
|
||||
} \
|
||||
(TYPE *) __result;}))
|
||||
|
||||
#else /* not __arch64__ */
|
||||
|
||||
#define __va_rounded_size(TYPE) \
|
||||
(((sizeof (TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof (int))
|
||||
|
||||
/* We don't declare the union member `d' to have type TYPE
|
||||
because that would lose in C++ if TYPE has a constructor. */
|
||||
/* We cast to void * and then to TYPE * because this avoids
|
||||
a warning about increasing the alignment requirement.
|
||||
The casts to char * avoid warnings about invalid pointer arithmetic. */
|
||||
#define va_arg(pvar,TYPE) \
|
||||
__extension__ \
|
||||
(*({((__builtin_classify_type (*(TYPE*) 0) >= __record_type_class \
|
||||
|| (__builtin_classify_type (*(TYPE*) 0) == __real_type_class \
|
||||
&& sizeof (TYPE) == 16)) \
|
||||
? ((pvar) = (char *)(pvar) + __va_rounded_size (TYPE *), \
|
||||
*(TYPE **) (void *) ((char *)(pvar) - __va_rounded_size (TYPE *))) \
|
||||
: __va_rounded_size (TYPE) == 8 \
|
||||
? ({ union {char __d[sizeof (TYPE)]; int __i[2];} __u; \
|
||||
__u.__i[0] = ((int *) (void *) (pvar))[0]; \
|
||||
__u.__i[1] = ((int *) (void *) (pvar))[1]; \
|
||||
(pvar) = (char *)(pvar) + 8; \
|
||||
(TYPE *) (void *) __u.__d; }) \
|
||||
: ((pvar) = (char *)(pvar) + __va_rounded_size (TYPE), \
|
||||
((TYPE *) (void *) ((char *)(pvar) - __va_rounded_size (TYPE)))));}))
|
||||
|
||||
#endif /* not __arch64__ */
|
||||
|
||||
/* Copy __gnuc_va_list into another variable of this type. */
|
||||
#define __va_copy(dest, src) (dest) = (src)
|
||||
|
||||
#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */
|
||||
@@ -0,0 +1,64 @@
|
||||
/* varargs.h for SPUR */
|
||||
|
||||
/* NB. This is NOT the definition needed for the new ANSI proposed
|
||||
standard */
|
||||
|
||||
|
||||
struct __va_struct { char __regs[20]; };
|
||||
|
||||
#define va_alist __va_regs, __va_stack
|
||||
|
||||
/* In GCC version 2, we want an ellipsis at the end of the declaration
|
||||
of the argument list. GCC version 1 can't parse it. */
|
||||
|
||||
#if __GNUC__ > 1
|
||||
#define __va_ellipsis ...
|
||||
#else
|
||||
#define __va_ellipsis
|
||||
#endif
|
||||
|
||||
/* The ... causes current_function_varargs to be set in cc1. */
|
||||
#define va_dcl struct __va_struct __va_regs; int __va_stack;
|
||||
|
||||
typedef struct {
|
||||
int __pnt;
|
||||
char *__regs;
|
||||
char *__stack;
|
||||
} va_list;
|
||||
|
||||
#define va_start(pvar) \
|
||||
((pvar).__pnt = 0, (pvar).__regs = __va_regs.__regs, \
|
||||
(pvar).__stack = (char *) &__va_stack)
|
||||
#define va_end(pvar) ((void)0)
|
||||
|
||||
/* Avoid errors if compiling GCC v2 with GCC v1. */
|
||||
#if __GNUC__ == 1
|
||||
#define __extension__
|
||||
#endif
|
||||
|
||||
#define va_arg(pvar,type) \
|
||||
__extension__ \
|
||||
(*({ type *__va_result; \
|
||||
if ((pvar).__pnt >= 20) { \
|
||||
__va_result = ( (type *) ((pvar).__stack + (pvar).__pnt - 20)); \
|
||||
(pvar).__pnt += (sizeof(type) + 7) & ~7; \
|
||||
} \
|
||||
else if ((pvar).__pnt + sizeof(type) > 20) { \
|
||||
__va_result = (type *) (pvar).__stack; \
|
||||
(pvar).__pnt = 20 + ( (sizeof(type) + 7) & ~7); \
|
||||
} \
|
||||
else if (sizeof(type) == 8) { \
|
||||
union {double d; int i[2];} __u; \
|
||||
__u.i[0] = *(int *) ((pvar).__regs + (pvar).__pnt); \
|
||||
__u.i[1] = *(int *) ((pvar).__regs + (pvar).__pnt + 4); \
|
||||
__va_result = (type *) &__u; \
|
||||
(pvar).__pnt += 8; \
|
||||
} \
|
||||
else { \
|
||||
__va_result = (type *) ((pvar).__regs + (pvar).__pnt); \
|
||||
(pvar).__pnt += (sizeof(type) + 3) & ~3; \
|
||||
} \
|
||||
__va_result; }))
|
||||
|
||||
/* Copy __gnuc_va_list into another variable of this type. */
|
||||
#define __va_copy(dest, src) (dest) = (src)
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user