Using the GNU Compiler Colle

tion (GCC)

Using the GNU Compiler Colle tion

by Ri hard M. Stallman and the GCC Developer Community

For GCC Version 4.0.0

Published by:
GNU Press
a division of the
Free Software Foundation
59 Temple Pla e Suite 330
Boston, MA 02111-1307 USA

Website: www.gnupress.org
General: pressgnu.org
Orders: salesgnu.org
Tel 617-542-5942
Fax 617-542-2652

Last printed O tober 2003 for GCC 3.3.1.

Printed opies are available for $45 ea h.
1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
Copyright
2003, 2004, 2005 Free Software Foundation, In .
Permission is granted to opy, distribute and/or modify this do ument under the terms of
the GNU Free Do umentation Li ense, Version 1.2 or any later version published by the
Free Software Foundation; with the Invariant Se tions being \GNU General Publi Li ense"
and \Funding Free Software", the Front-Cover texts being (a) (see below), and with the
Ba k-Cover Texts being (b) (see below). A opy of the li ense is in luded in the se tion
entitled \GNU Free Do umentation Li ense".
(a) The FSF's Front-Cover Text is:
A GNU Manual
(b) The FSF's Ba k-Cover Text is:
You have freedom to opy and modify this GNU Manual, like GNU software. Copies
published by the Free Software Foundation raise funds for GNU development.

Short Contents
Introdu tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1 Programming Languages Supported by GCC . . . . . . . . . . . . 3
2 Language Standards Supported by GCC . . . . . . . . . . . . . . . 5
3 GCC Command Options . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4 C Implementation-dened behavior . . . . . . . . . . . . . . . . . 193
5 Extensions to the C Language Family . . . . . . . . . . . . . . . . 201
6 Extensions to the C++ Language . . . . . . . . . . . . . . . . . . . 335
7 GNU Obje tive-C runtime features . . . . . . . . . . . . . . . . . . 345
8 Binary Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
9 g ov|a Test Coverage Program . . . . . . . . . . . . . . . . . . . 355
10 Known Causes of Trouble with GCC . . . . . . . . . . . . . . . . 363
11 Reporting Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
12 How To Get Help with GCC . . . . . . . . . . . . . . . . . . . . . . 383
13 Contributing to GCC Development . . . . . . . . . . . . . . . . . 385
Funding Free Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
The GNU Proje t and GNU/Linux . . . . . . . . . . . . . . . . . . . . . 389
GNU GENERAL PUBLIC LICENSE . . . . . . . . . . . . . . . . . . . 391
GNU Free Do umentation Li ense . . . . . . . . . . . . . . . . . . . . . 397
Contributors to GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Option Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Keyword Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431

ii

Using the GNU Compiler Colle tion (GCC)

iii

Table of Contents
Introdu tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1 Programming Languages Supported by GCC
.........................................

2 Language Standards Supported by GCC . . . . 5

3 GCC Command Options . . . . . . . . . . . . . . . . . . . 7

3.1 Option Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 Options Controlling the Kind of Output . . . . . . . . . . . . . . . . . . . . . 16
3.3 Compiling C++ Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Options Controlling C Diale t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Options Controlling C++ Diale t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6 Options Controlling Obje tive-C and Obje tive-C++ Diale ts . . 31
3.7 Options to Control Diagnosti Messages Formatting . . . . . . . . . . . 34
3.8 Options to Request or Suppress Warnings . . . . . . . . . . . . . . . . . . . . 34
3.9 Options for Debugging Your Program or GCC . . . . . . . . . . . . . . . . 49
3.10 Options That Control Optimization . . . . . . . . . . . . . . . . . . . . . . . . 61
3.11 Options Controlling the Prepro essor . . . . . . . . . . . . . . . . . . . . . . . 87
3.12 Passing Options to the Assembler . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.13 Options for Linking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.14 Options for Dire tory Sear h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.15 Spe ifying subpro esses and the swit hes to pass to them . . . . 101
3.16 Spe ifying Target Ma hine and Compiler Version . . . . . . . . . . . 108
3.17 Hardware Models and Congurations . . . . . . . . . . . . . . . . . . . . . . 108
3.17.1 ARC Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.17.2 ARM Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.17.3 AVR Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
3.17.4 CRIS Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
3.17.5 Darwin Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
3.17.6 DEC Alpha Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
3.17.7 DEC Alpha/VMS Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3.17.8 FRV Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3.17.9 H8/300 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
3.17.10 HPPA Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
3.17.11 Intel 386 and AMD x86-64 Options . . . . . . . . . . . . . . . . . . 130
3.17.12 IA-64 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
3.17.13 M32R/D Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
3.17.14 M680x0 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
3.17.15 M68h 1x Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
3.17.16 MCore Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
3.17.17 MIPS Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

iv

Using the GNU Compiler Colle tion (GCC)

3.17.18 MMIX Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.17.19 MN10300 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.17.20 NS32K Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.17.21 PDP-11 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.17.22 PowerPC Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.17.23 IBM RS/6000 and PowerPC Options . . . . . . . . . . . . . . . . .
3.17.24 S/390 and zSeries Options . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.17.25 SH Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.17.26 SPARC Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.17.27 Options for System V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.17.28 TMS320C3x/C4x Options . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.17.29 V850 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.17.30 VAX Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.17.31 x86-64 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.17.32 Xstormy16 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.17.33 Xtensa Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.17.34 zSeries Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.18 Options for Code Generation Conventions . . . . . . . . . . . . . . . . . .
3.19 Environment Variables Ae ting GCC . . . . . . . . . . . . . . . . . . . . .
3.20 Using Pre ompiled Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.21 Running Protoize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

150
152
152
154
155
155
165
167
169
173
173
175
176
176
176
177
178
178
184
187
189

4 C Implementation-dened behavior . . . . . . . 193

4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16

Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chara ters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Floating point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arrays and pointers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Stru tures, unions, enumerations, and bit-elds . . . . . . . . . . . . . .
Qualiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
De larators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prepro essing dire tives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Library fun tions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ar hite ture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lo ale-spe i behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

193
193
193
194
194
195
196
197
197
198
198
198
198
199
199
199

5 Extensions to the C Language Family . . . . . 201

5.1 Statements and De larations in Expressions . . . . . . . . . . . . . . . . .
5.2 Lo ally De lared Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Labels as Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Nested Fun tions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5 Constru ting Fun tion Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6 Referring to a Type with typeof . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7 Conditionals with Omitted Operands . . . . . . . . . . . . . . . . . . . . . . .
5.8 Double-Word Integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.9 Complex Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.10 Hex Floats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.11 Arrays of Length Zero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.12 Stru tures With No Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.13 Arrays of Variable Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.14 Ma ros with a Variable Number of Arguments. . . . . . . . . . . . . .
5.15 Slightly Looser Rules for Es aped Newlines . . . . . . . . . . . . . . . . .
5.16 Non-Lvalue Arrays May Have Subs ripts . . . . . . . . . . . . . . . . . . .
5.17 Arithmeti on void- and Fun tion-Pointers . . . . . . . . . . . . . . . . .
5.18 Non-Constant Initializers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.19 Compound Literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.20 Designated Initializers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.21 Case Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.22 Cast to a Union Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.23 Mixed De larations and Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.24 De laring Attributes of Fun tions . . . . . . . . . . . . . . . . . . . . . . . . . .
5.25 Attribute Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.26 Prototypes and Old-Style Fun tion Denitions . . . . . . . . . . . . . .
5.27 C++ Style Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.28 Dollar Signs in Identier Names . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.29 The Chara ter hESCi in Constants . . . . . . . . . . . . . . . . . . . . . . . . . .
5.30 Inquiring on Alignment of Types or Variables . . . . . . . . . . . . . .
5.31 Spe ifying Attributes of Variables . . . . . . . . . . . . . . . . . . . . . . . . .
5.31.1 M32R/D Variable Attributes . . . . . . . . . . . . . . . . . . . . . . . . .
5.31.2 i386 Variable Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.31.3 Xstormy16 Variable Attributes . . . . . . . . . . . . . . . . . . . . . . .
5.32 Spe ifying Attributes of Types . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.32.1 ARM Type Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.32.2 i386 Type Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.33 An Inline Fun tion is As Fast As a Ma ro . . . . . . . . . . . . . . . . . .
5.34 Assembler Instru tions with C Expression Operands . . . . . . . .
5.34.1 Size of an asm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.34.2 i386 oating point asm operands . . . . . . . . . . . . . . . . . . . . . .
5.35 Constraints for asm Operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.35.1 Simple Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.35.2 Multiple Alternative Constraints . . . . . . . . . . . . . . . . . . . . . .
5.35.3 Constraint Modier Chara ters . . . . . . . . . . . . . . . . . . . . . . .
5.35.4 Constraints for Parti ular Ma hines . . . . . . . . . . . . . . . . . . .
5.36 Controlling Names Used in Assembler Code . . . . . . . . . . . . . . . .

201
202
203
204
206
207
208
209
209
210
210
211
211
212
213
213
214
214
214
215
216
216
217
217
228
231
232
232
232
232
233
237
237
238
238
242
242
242
244
249
249
250
250
252
253
254
265

vi

Using the GNU Compiler Colle tion (GCC)

5.37 Variables in Spe ied Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.37.1 Dening Global Register Variables . . . . . . . . . . . . . . . . . . . .
5.37.2 Spe ifying Registers for Lo al Variables . . . . . . . . . . . . . . .
5.38 Alternate Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.39 In omplete enum Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.40 Fun tion Names as Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.41 Getting the Return or Frame Address of a Fun tion . . . . . . . . .
5.42 Using ve tor instru tions through built-in fun tions . . . . . . . . .
5.43 Osetof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.44 Other built-in fun tions provided by GCC . . . . . . . . . . . . . . . . . .
5.45 Built-in Fun tions Spe i to Parti ular Target Ma hines . . . .
5.45.1 Alpha Built-in Fun tions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.45.2 ARM Built-in Fun tions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.45.3 FR-V Built-in Fun tions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.45.3.1 Argument Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.45.3.2 Dire tly-mapped Integer Fun tions . . . . . . . . . . . . . . .
5.45.3.3 Dire tly-mapped Media Fun tions . . . . . . . . . . . . . . . .
5.45.3.4 Other Built-in Fun tions . . . . . . . . . . . . . . . . . . . . . . . . .
5.45.4 X86 Built-in Fun tions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.45.5 MIPS Paired-Single Support . . . . . . . . . . . . . . . . . . . . . . . . . .
5.45.5.1 Paired-Single Arithmeti . . . . . . . . . . . . . . . . . . . . . . . . .
5.45.5.2 Paired-Single Built-in Fun tions . . . . . . . . . . . . . . . . . .
5.45.5.3 MIPS-3D Built-in Fun tions . . . . . . . . . . . . . . . . . . . . .
5.45.6 PowerPC AltiVe Built-in Fun tions . . . . . . . . . . . . . . . . . .
5.45.7 SPARC VIS Built-in Fun tions . . . . . . . . . . . . . . . . . . . . . . .
5.46 Format Che ks Spe i to Parti ular Target Ma hines . . . . . .
5.46.1 Solaris Format Che ks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.47 Pragmas A epted by GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.47.1 ARM Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.47.2 RS/6000 and PowerPC Pragmas . . . . . . . . . . . . . . . . . . . . . .
5.47.3 Darwin Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.47.4 Solaris Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.47.5 Symbol-Renaming Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . .
5.47.6 Stru ture-Pa king Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.47.7 Weak Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.48 Unnamed stru t/union elds within stru ts/unions . . . . . . . . .
5.49 Thread-Lo al Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.49.1 ISO/IEC 9899:1999 Edits for Thread-Lo al Storage . . . .
5.49.2 ISO/IEC 14882:1998 Edits for Thread-Lo al Storage . . .

266
266
267
268
269
269
270
271
272
272
279
279
280
282
282
283
283
285
286
290
290
291
292
294
326
327
327
327
327
327
328
328
328
329
330
330
331
331
332

vii

6 Extensions to the C++ Language . . . . . . . . . . 335

6.1
6.2
6.3
6.4
6.5
6.6

When is a Volatile Obje t A essed? . . . . . . . . . . . . . . . . . . . . . . . . 335

Restri ting Pointer Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Vague Linkage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
#pragma interfa e and implementation . . . . . . . . . . . . . . . . . . . . . 337
Where's the Template? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Extra ting the fun tion pointer from a bound pointer to member
fun tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
6.7 C++-Spe i Variable, Fun tion, and Type Attributes . . . . . . . . 341
6.8 Strong Using . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
6.9 Java Ex eptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
6.10 Depre ated Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
6.11 Ba kwards Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

7 GNU Obje tive-C runtime features . . . . . . . 345

7.1 +load: Exe uting ode before main . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.1 What you an and what you annot do in +load . . . . . . . .
7.2 Type en oding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Garbage Colle tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4 Constant string obje ts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5 ompatibility alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

345
346
347
348
349
350

8 Binary Compatibility . . . . . . . . . . . . . . . . . . . . 351

9

g ov|a

9.1
9.2
9.3
9.4

Test Coverage Program . . . . . . . . . . 355

Introdu tion to g ov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Invoking g ov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using g ov with GCC Optimization . . . . . . . . . . . . . . . . . . . . . . . .
Brief des ription of g ov data les . . . . . . . . . . . . . . . . . . . . . . . . . .

355
355
360
361

10 Known Causes of Trouble with GCC . . . . . 363

10.1 A tual Bugs We Haven't Fixed Yet . . . . . . . . . . . . . . . . . . . . . . . .
10.2 Cross-Compiler Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3 Interoperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.4 In ompatibilities of GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.5 Fixed Header Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.6 Standard Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.7 Disappointments and Misunderstandings . . . . . . . . . . . . . . . . . . .
10.8 Common Misunderstandings with GNU C++ . . . . . . . . . . . . . . .
10.8.1 De lare and Dene Stati Members . . . . . . . . . . . . . . . . . . .
10.8.2 Name lookup, templates, and a essing members of base
lasses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.8.3 Temporaries May Vanish Before You Expe t . . . . . . . . . . .
10.8.4 Impli it Copy-Assignment for Virtual Bases . . . . . . . . . . .
10.9 Caveats of using protoize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.10 Certain Changes We Don't Want to Make . . . . . . . . . . . . . . . . .
10.11 Warning Messages and Error Messages . . . . . . . . . . . . . . . . . . . .

363
363
363
365
368
369
369
370
370
371
372
373
374
375
378

viii

Using the GNU Compiler Colle tion (GCC)

11 Reporting Bugs . . . . . . . . . . . . . . . . . . . . . . . . 381

11.1 Have You Found a Bug? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
11.2 How and where to Report Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

12 How To Get Help with GCC . . . . . . . . . . . . 383

13 Contributing to GCC Development . . . . . . 385
Funding Free Software . . . . . . . . . . . . . . . . . . . . . . 387
The GNU Proje t and GNU/Linux . . . . . . . . . . 389
GNU GENERAL PUBLIC LICENSE . . . . . . . . 391
Preamble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
TERMS AND CONDITIONS FOR COPYING,
DISTRIBUTION AND MODIFICATION . . . . . . . . . . . . . . . . . . . 392
How to Apply These Terms to Your New Programs . . . . . . . . . . . . . . . 396

GNU Free Do umentation Li ense . . . . . . . . . . . 397

ADDENDUM: How to use this Li ense for your do uments . . . . . . . . 403

Contributors to GCC . . . . . . . . . . . . . . . . . . . . . . . 405

Option Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Keyword Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431

Introdu tion
This manual do uments how to use the GNU ompilers, as well as their features and in ompatibilities, and how to report bugs. It orresponds to GCC version 4.0.0. The internals
of the GNU ompilers, in luding how to port them to new targets and some information
about how to write front ends for new languages, are do umented in a separate manual.
See se tion \Introdu tion" in GNU Compiler Colle tion (GCC) Internals.

Using the GNU Compiler Colle tion (GCC)

Chapter 1: Programming Languages Supported by GCC

1 Programming Languages Supported by GCC

GCC stands for \GNU Compiler Colle tion". GCC is an integrated distribution of ompilers for several major programming languages. These languages urrently in lude C, C++,
Obje tive-C, Obje tive-C++, Java, Fortran, and Ada.
The abbreviation GCC has multiple meanings in ommon use. The urrent o ial meaning is \GNU Compiler Colle tion", whi h refers generi ally to the omplete suite of tools.
The name histori ally stood for \GNU C Compiler", and this usage is still ommon when
the emphasis is on ompiling C programs. Finally, the name is also used when speaking
of the language-independent omponent of GCC: ode shared among the ompilers for all
supported languages.
The language-independent omponent of GCC in ludes the majority of the optimizers,
as well as the \ba k ends" that generate ma hine ode for various pro essors.
The part of a ompiler that is spe i to a parti ular language is alled the \front end".
In addition to the front ends that are integrated omponents of GCC, there are several
other front ends that are maintained separately. These support languages su h as Pas al,
Mer ury, and COBOL. To use these, they must be built together with GCC proper.
Most of the ompilers for languages other than C have their own names. The C++ ompiler
is G++, the Ada ompiler is GNAT, and so on. When we talk about ompiling one of those
languages, we might refer to that ompiler by its own name, or as GCC. Either is orre t.
Histori ally, ompilers for many languages, in luding C++ and Fortran, have been implemented as \prepro essors" whi h emit another high level language su h as C. None of
the ompilers in luded in GCC are implemented this way; they all generate ma hine ode
dire tly. This sort of prepro essor should not be onfused with the C prepro essor, whi h
is an integral feature of the C, C++, Obje tive-C and Obje tive-C++ languages.

Using the GNU Compiler Colle tion (GCC)

Chapter 2: Language Standards Supported by GCC

2 Language Standards Supported by GCC

For ea h language ompiled by GCC for whi h there is a standard, GCC attempts to follow
one or more versions of that standard, possibly with some ex eptions, and possibly with
some extensions.
GCC supports three versions of the C standard, although support for the most re ent
version is not yet omplete.
The original ANSI C standard (X3.159-1989) was ratied in 1989 and published in 1990.
This standard was ratied as an ISO standard (ISO/IEC 9899:1990) later in 1990. There
were no te hni al dieren es between these publi ations, although the se tions of the ANSI
standard were renumbered and be ame lauses in the ISO standard. This standard, in
both its forms, is ommonly known as C89, or o asionally as C90, from the dates of
rati ation. The ANSI standard, but not the ISO standard, also ame with a Rationale
do ument. To sele t this standard in GCC, use one of the options `-ansi', `-std= 89' or
`-std=iso9899:1990'; to obtain all the diagnosti s required by the standard, you should
also spe ify `-pedanti ' (or `-pedanti -errors' if you want them to be errors rather than
warnings). See Se tion 3.4 [Options Controlling C Diale t, page 20.
Errors in the 1990 ISO C standard were orre ted in two Te hni al Corrigenda published
in 1994 and 1996. GCC does not support the un orre ted version.
An amendment to the 1990 standard was published in 1995. This amendment added
digraphs and __STDC_VERSION__ to the language, but otherwise on erned the library. This
amendment is ommonly known as AMD1; the amended standard is sometimes known as
C94 or C95. To sele t this standard in GCC, use the option `-std=iso9899:199409' (with,
as for other standard versions, `-pedanti ' to re eive all required diagnosti s).
A new edition of the ISO C standard was published in 1999 as ISO/IEC 9899:1999, and
is ommonly known as C99. GCC has in omplete support for this standard version; see
http://g .gnu.org/g -4.0/ 99status.html for details. To sele t this standard, use
`-std= 99' or `-std=iso9899:1999'. (While in development, drafts of this standard version
were referred to as C9X.)
Errors in the 1999 ISO C standard were orre ted in two Te hni al Corrigenda published
in 2001 and 2004. GCC does not support the un orre ted version.
By default, GCC provides some extensions to the C language that on rare o asions on i t with the C standard. See Chapter 5 [Extensions to the C Language Family, page 201.
Use of the `-std' options listed above will disable these extensions where they on i t with
the C standard version sele ted. You may also sele t an extended version of the C language
expli itly with `-std=gnu89' (for C89 with GNU extensions) or `-std=gnu99' (for C99 with
GNU extensions). The default, if no C language diale t options are given, is `-std=gnu89';
this will hange to `-std=gnu99' in some future release when the C99 support is omplete.
Some features that are part of the C99 standard are a epted as extensions in C89 mode.
The ISO C standard denes (in lause 4) two lasses of onforming implementation. A
onforming hosted implementation supports the whole standard in luding all the library fa ilities; a onforming freestanding implementation is only required to provide ertain library
fa ilities: those in <float.h>, <limits.h>, <stdarg.h>, and <stddef.h>; sin e AMD1,
also those in <iso646.h>; and in C99, also those in <stdbool.h> and <stdint.h>. In addition, omplex types, added in C99, are not required for freestanding implementations. The

Using the GNU Compiler Colle tion (GCC)

standard also denes two environments for programs, a freestanding environment, required
of all implementations and whi h may not have library fa ilities beyond those required of
freestanding implementations, where the handling of program startup and termination are
implementation-dened, and a hosted environment, whi h is not required, in whi h all the
library fa ilities are provided and startup is through a fun tion int main (void) or int
main (int, har *[). An OS kernel would be a freestanding environment; a program
using the fa ilities of an operating system would normally be in a hosted implementation.
GCC aims towards being usable as a onforming freestanding implementation, or as the
ompiler for a onforming hosted implementation. By default, it will a t as the ompiler for a
hosted implementation, dening __STDC_HOSTED__ as 1 and presuming that when the names
of ISO C fun tions are used, they have the semanti s dened in the standard. To make it a t
as a onforming freestanding implementation for a freestanding environment, use the option
`-ffreestanding'; it will then dene __STDC_HOSTED__ to 0 and not make assumptions
about the meanings of fun tion names from the standard library, with ex eptions noted
below. To build an OS kernel, you may well still need to make your own arrangements for
linking and startup. See Se tion 3.4 [Options Controlling C Diale t, page 20.
GCC does not provide the library fa ilities required only of hosted implementations, nor
yet all the fa ilities required by C99 of freestanding implementations; to use the fa ilities
of a hosted environment, you will need to nd them elsewhere (for example, in the GNU C
library). See Se tion 10.6 [Standard Libraries, page 369.
Most of the ompiler support routines used by GCC are present in `libg ', but there
are a few ex eptions. GCC requires the freestanding environment provide mem py, memmove,
memset and mem mp. Finally, if __builtin_trap is used, and the target does not implement
the trap pattern, then GCC will emit a all to abort.
For referen es to Te hni al Corrigenda, Rationale do uments and information on erning
the history of C that is available online, see http://g .gnu.org/readings.html
There is no formal written standard for Obje tive-C or Obje tive-C++. The most authoritative manual is \Obje t-Oriented Programming and the Obje tive-C Language", available
at a number of web sites:
 http://developer.apple. om/do umentation/Co oa/Con eptual/Obje tiveC/ is
a re ent (and periodi ally updated) version;
 http://www.toodarkpark.org/ omputers/obj / is an older example;
 http://www.gnustep.org and http://g .gnu.org/readings.html have additional
useful information.
There is no standard for treelang, whi h is a sample language front end for GCC. Its only
purpose is as a sample for people wishing to write a new language for GCC. The language
is do umented in `g /treelang/treelang.texi' whi h an be turned into info or HTML
format.
See se tion \About This Guide" in GNAT Referen e Manual, for information on standard
onforman e and ompatibility of the Ada ompiler.
See se tion \Standards" in The GNU Fortran 95 Compiler, for details of standards supported by gfortran.
See se tion \Compatibility with the Java Platform" in GNU g j, for details of ompatibility between g j and the Java Platform.

Chapter 3: GCC Command Options

3 GCC Command Options

When you invoke GCC, it normally does prepro essing, ompilation, assembly and linking.
The \overall options" allow you to stop this pro ess at an intermediate stage. For example,
the `- ' option says not to run the linker. Then the output onsists of obje t les output
by the assembler.
Other options are passed on to one stage of pro essing. Some options ontrol the prepro essor and others the ompiler itself. Yet other options ontrol the assembler and linker;
most of these are not do umented here, sin e you rarely need to use any of them.
Most of the ommand line options that you an use with GCC are useful for C programs;
when an option is only useful with another language (usually C++), the explanation says
so expli itly. If the des ription for a parti ular option does not mention a sour e language,
you an use that option with all supported languages.
See Se tion 3.3 [Compiling C++ Programs, page 20, for a summary of spe ial options for
ompiling C++ programs.
The g program a epts options and le names as operands. Many options have multiletter names; therefore multiple single-letter options may not be grouped: `-dr' is very
dierent from `-d -r'.
You an 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 spe ify `-L' more than on e, the dire tories are sear hed in the order spe ied.
Many options have long names starting with `-f' or with `-W'|for example,
`-ffor e-mem', `-fstrength-redu e', `-Wformat' and so on. Most of these have both
positive and negative forms; the negative form of `-ffoo' would be `-fno-foo'. This
manual do uments only one of these two forms, whi hever one is not the default.
See [Option Index, page 419, for an index to GCC's options.

3.1 Option Summary

Here is a summary of all the options, grouped by type. Explanations are in the following
se tions.
Overall Options
See Se tion 3.2 [Options Controlling the Kind of Output, page 16.
- -S -E -o file - ombine -pipe -pass-exit- odes
-x language -v -### --help --target-help --version

C Language Options
See Se tion 3.4 [Options Controlling C Diale t, page 20.
-ansi -std=standard -aux-info filename
-fno-asm -fno-builtin -fno-builtin-fun tion
-fhosted -ffreestanding -fms-extensions
-trigraphs -no-integrated- pp -traditional -traditional- pp
-fallow-single-pre ision -f ond-mismat h
-fsigned-bitfields -fsigned- har
-funsigned-bitfields -funsigned- har

C++ Language Options

See Se tion 3.5 [Options Controlling C++ Diale t, page 24.

Using the GNU Compiler Colle tion (GCC)

-fabi-version=n -fno-a ess- ontrol -f he k-new

-f onserve-spa e -fno- onst-strings
-fno-elide- onstru tors
-fno-enfor e-eh-spe s
-ffor-s ope -fno-for-s ope -fno-gnu-keywords
-fno-impli it-templates
-fno-impli it-inline-templates
-fno-implement-inlines -fms-extensions
-fno-nonansi-builtins -fno-operator-names
-fno-optional-diags -fpermissive
-frepo -fno-rtti -fstats -ftemplate-depth-n
-fno-threadsafe-stati s -fuse- xa-atexit -fno-weak -nostdin ++
-fno-default-inline -fvisibility-inlines-hidden
-Wabi -W tor-dtor-priva y
-Wnon-virtual-dtor -Wreorder
-Weff ++ -Wno-depre ated
-Wno-non-template-friend -Wold-style- ast
-Woverloaded-virtual -Wno-pmf- onversions
-Wsign-promo

Obje tive-C and Obje tive-C++ Language Options

See Se tion 3.6 [Options Controlling Obje tive-C and Obje tive-C++ Diale ts,
page 31.
-f onstant-string- lass= lass-name
-fgnu-runtime -fnext-runtime
-fno-nil-re eivers
-fobj -ex eptions
-frepla e-obj - lasses
-fzero-link
-gen-de ls
-Wno-proto ol -Wsele tor -Wunde lared-sele tor

Language Independent Options

See Se tion 3.7 [Options to Control Diagnosti Messages Formatting, page 34.
-fmessage-length=n
-fdiagnosti s-show-lo ation=[on e|every-line

Warning Options
See Se tion 3.8 [Options to Request or Suppress Warnings, page 34.
-fsyntax-only -pedanti -pedanti -errors
-w -Wextra -Wall -Waggregate-return
-W ast-align -W ast-qual -W har-subs ripts -W omment
-W onversion -Wno-depre ated-de larations
-Wdisabled-optimization -Wno-div-by-zero -Wno-endif-labels
-Werror -Werror-impli it-fun tion-de laration
-Wfatal-errors -Wfloat-equal -Wformat -Wformat=2
-Wno-format-extra-args -Wformat-nonliteral
-Wformat-se urity -Wformat-y2k
-Wimpli it -Wimpli it-fun tion-de laration -Wimpli it-int
-Wimport -Wno-import -Winit-self -Winline
-Wno-invalid-offsetof -Winvalid-p h
-Wlarger-than-len -Wlong-long
-Wmain -Wmissing-bra es -Wmissing-field-initializers
-Wmissing-format-attribute -Wmissing-in lude-dirs
-Wmissing-noreturn
-Wno-multi har -Wnonnull -Wpa ked -Wpadded
-Wparentheses -Wpointer-arith -Wredundant-de ls
-Wreturn-type -Wsequen e-point -Wshadow

Chapter 3: GCC Command Options

-Wsign- ompare -Wstri t-aliasing -Wstri t-aliasing=2

-Wswit h -Wswit h-default -Wswit h-enum
-Wsystem-headers -Wtrigraphs -Wundef -Wuninitialized
-Wunknown-pragmas -Wunrea hable- ode
-Wunused -Wunused-fun tion -Wunused-label -Wunused-parameter
-Wunused-value -Wunused-variable -Wwrite-strings
-Wvariadi -ma ros

C-only Warning Options

-Wbad-fun tion- ast -Wmissing-de larations

-Wmissing-prototypes -Wnested-externs -Wold-style-definition
-Wstri t-prototypes -Wtraditional
-Wde laration-after-statement -Wno-pointer-sign

Debugging Options
See Se tion 3.9 [Options for Debugging Your Program or GCC, page 49.

-dletters -dumpspe s -dumpma hine -dumpversion

-fdump-unnumbered -fdump-translation-unit[-n
-fdump- lass-hierar hy[-n
-fdump-ipa-all -fdump-ipa- graph
-fdump-tree-all
-fdump-tree-original[-n
-fdump-tree-optimized[-n
-fdump-tree-inlined[-n
-fdump-tree- fg -fdump-tree-v g -fdump-tree-alias
-fdump-tree- h
-fdump-tree-ssa[-n -fdump-tree-pre[-n
-fdump-tree- p[-n -fdump-tree-d e[-n
-fdump-tree-gimple[-raw -fdump-tree-mudflap[-n
-fdump-tree-dom[-n
-fdump-tree-dse[-n
-fdump-tree-phiopt[-n
-fdump-tree-forwprop[-n
-fdump-tree- opyrename[-n
-fdump-tree-nrv -fdump-tree-ve t
-fdump-tree-sra[-n
-fdump-tree-fre[-n
-ftree-ve torizer-verbose=n
-feliminate-dwarf2-dups -feliminate-unused-debug-types
-feliminate-unused-debug-symbols -fmem-report -fprofile-ar s -ftree-basedprofiling
-frandom-seed=string -fs hed-verbose=n
-ftest- overage -ftime-report -fvar-tra king
-g -glevel -g off -gdwarf-2
-ggdb -gstabs -gstabs+ -gvms -gx off -gx off+
-p -pg -print-file-name=library -print-libg -file-name
-print-multi-dire tory -print-multi-lib
-print-prog-name=program -print-sear h-dirs -Q
-save-temps -time

Optimization Options
See Se tion 3.10 [Options that Control Optimization, page 61.

-falign-fun tions=n -falign-jumps=n

-falign-labels=n -falign-loops=n
-fbounds- he k -fmudflap -fmudflapth -fmudflapir
-fbran h-probabilities -fprofile-values -fvpt -fbran h-target-load-optimize
-fbran h-target-load-optimize2 -fbtr-bb-ex lusive
-f aller-saves -f prop-registers -f se-follow-jumps
-f se-skip-blo ks -f x-limited-range -fdata-se tions

10

Using the GNU Compiler Colle tion (GCC)

-fdelayed-bran h -fdelete-null-pointer- he ks
-fexpensive-optimizations -ffast-math -ffloat-store
-ffor e-addr -ffor e-mem -ffun tion-se tions
-fg se -fg se-lm -fg se-sm -fg se-las -fg se-after-reload
-floop-optimize -f rossjumping -fif- onversion -fif- onversion2
-finline-fun tions -finline-limit=n -fkeep-inline-fun tions
-fkeep-stati - onsts -fmerge- onstants -fmerge-all- onstants
-fmodulo-s hed -fno-bran h- ount-reg
-fno-default-inline -fno-defer-pop -floop-optimize2 -fmove-loop-invariants
-fno-fun tion- se -fno-guess-bran h-probability
-fno-inline -fno-math-errno -fno-peephole -fno-peephole2
-funsafe-math-optimizations -ffinite-math-only
-fno-trapping-math -fno-zero-initialized-in-bss
-fomit-frame-pointer -foptimize-register-move
-foptimize-sibling- alls -fprefet h-loop-arrays
-fprofile-generate -fprofile-use
-fregmove -frename-registers
-freorder-blo ks -freorder-blo ks-and-partition -freorder-fun tions
-frerun- se-after-loop -frerun-loop-opt
-frounding-math -fs hedule-insns -fs hedule-insns2
-fno-s hed-interblo k -fno-s hed-spe -fs hed-spe -load
-fs hed-spe -load-dangerous
-fs hed-stalled-insns=n -s hed-stalled-insns-dep=n
-fs hed2-use-superblo ks
-fs hed2-use-tra es -fres hedule-modulo-s heduled-loops
-fsignaling-nans -fsingle-pre ision- onstant -fspe ulative-prefet hing
-fstrength-redu e -fstri t-aliasing -ftra er -fthread-jumps
-funroll-all-loops -funroll-loops -fpeel-loops
-fsplit-ivs-in-unroller -funswit h-loops
-fvariable-expansion-in-unroller
-ftree-pre -ftree- p -ftree-d e -ftree-loop-optimize
-ftree-loop-linear -ftree-loop-im -ftree-loop-iv anon -fivopts
-ftree-dominator-opts -ftree-dse -ftree- opyrename
-ftree- h -ftree-sra -ftree-ter -ftree-lrs -ftree-fre -ftree-ve torize
-fweb
--param name =value -O -O0 -O1 -O2 -O3 -Os

Prepro essor Options

See Se tion 3.11 [Options Controlling the Prepro essor, page 87.
-Aquestion =answer
-A-question [=answer
-C -dD -dI -dM -dN
-Dma ro [=defn -E -H
-idirafter dir
-in lude file -ima ros file
-iprefix file -iwithprefix dir
-iwithprefixbefore dir -isystem dir
-M -MM -MF -MG -MP -MQ -MT -nostdin
-P -fworking-dire tory -remap
-trigraphs -undef -Uma ro -Wp,option
-Xprepro essor option

Assembler Option
See Se tion 3.12 [Passing Options to the Assembler, page 97.
-Wa,option -Xassembler option

Linker Options
See Se tion 3.13 [Options for Linking, page 97.

Chapter 3: GCC Command Options

obje t-file-name -llibrary

-nostartfiles -nodefaultlibs -nostdlib -pie
-s -stati -stati -libg -shared -shared-libg -symboli
-Wl,option -Xlinker option
-u symbol

Dire tory Options

See Se tion 3.14 [Options for Dire tory Sear h, page 100.
-Bprefix -Idir -iquotedir -Ldir -spe s=file -I-

Target Options
See Se tion 3.16 [Target Options, page 108.
-V version -b ma hine

Ma hine Dependent Options

See Se tion 3.17 [Hardware Models and Congurations, page 108.
ARC Options
-EB -EL
-mmangle- pu -m pu= pu -mtext=text-se tion
-mdata=data-se tion -mrodata=readonly-data-se tion

ARM Options

-map s-frame -mno-ap s-frame

-mabi=name
-map s-sta k- he k -mno-ap s-sta k- he k
-map s-float -mno-ap s-float
-map s-reentrant -mno-ap s-reentrant
-ms hed-prolog -mno-s hed-prolog
-mlittle-endian -mbig-endian -mwords-little-endian
-mfloat-abi=name -msoft-float -mhard-float -mfpe
-mthumb-interwork -mno-thumb-interwork
-m pu=name -mar h=name -mfpu=name
-mstru ture-size-boundary=n
-mabort-on-noreturn
-mlong- alls -mno-long- alls
-msingle-pi -base -mno-single-pi -base
-mpi -register=reg
-mnop-fun-dllimport
-m irrus-fix-invalid-insns -mno- irrus-fix-invalid-insns
-mpoke-fun tion-name
-mthumb -marm
-mtp s-frame -mtp s-leaf-frame
-m aller-super-interworking -m allee-super-interworking

AVR Options

-mm u=m u -msize -minit-sta k=n -mno-interrupts

-m all-prologues -mno-tablejump -mtiny-sta k -mint8

CRIS Options

-m pu= pu -mar h= pu -mtune= pu

-mmax-sta k-frame=n -melinux-sta ksize=n
-metrax4 -metrax100 -mpdebug -m -init -mno-side-effe ts
-msta k-align -mdata-align -m onst-align
-m32-bit -m16-bit -m8-bit -mno-prologue-epilogue -mno-gotplt
-melf -maout -melinux -mlinux -sim -sim2
-mmul-bug-workaround -mno-mul-bug-workaround

Darwin Options

-all_load -allowable_ lient -ar h -ar h_errors_fatal

-ar h_only -bind_at_load -bundle -bundle_loader

11

12

Using the GNU Compiler Colle tion (GCC)

- lient_name - ompatibility_version - urrent_version

-dead_strip
-dependen y-file -dylib_file -dylinker_install_name
-dynami -dynami lib -exported_symbols_list
-filelist -flat_namespa e -for e_ pusubtype_ALL
-for e_flat_namespa e -headerpad_max_install_names
-image_base -init -install_name -keep_private_externs
-multi_module -multiply_defined -multiply_defined_unused
-noall_load -no_dead_strip_inits_and_terms
-nofixprebinding -nomultidefs -noprebind -noseglinkedit
-pagezero_size -prebind -prebind_all_twolevel_modules
-private_bundle -read_only_relo s -se talign
-se tobje tsymbols -whyload -seg1addr
-se t reate -se tobje tsymbols -se torder
-segaddr -segs_read_only_addr -segs_read_write_addr
-seg_addr_table -seg_addr_table_filename -seglinkedit
-segprot -segs_read_only_addr -segs_read_write_addr
-single_module -stati -sub_library -sub_umbrella
-twolevel_namespa e -umbrella -undefined
-unexported_symbols_list -weak_referen e_mismat hes
-whatsloaded -F -gused -gfull -mone-byte-bool

DEC Alpha Options

-mno-fp-regs -msoft-float -malpha-as -mgas

-mieee -mieee-with-inexa t -mieee- onformant
-mfp-trap-mode=mode -mfp-rounding-mode=mode
-mtrap-pre ision=mode -mbuild- onstants
-m pu= pu-type -mtune= pu-type
-mbwx -mmax -mfix -m ix
-mfloat-vax -mfloat-ieee
-mexpli it-relo s -msmall-data -mlarge-data
-msmall-text -mlarge-text
-mmemory-laten y=time

DEC Alpha/VMS Options

-mvms-return- odes

FRV Options

-mgpr-32 -mgpr-64 -mfpr-32 -mfpr-64

-mhard-float -msoft-float
-mallo - -mfixed- -mdword -mno-dword
-mdouble -mno-double
-mmedia -mno-media -mmuladd -mno-muladd
-mfdpi -minline-plt -mgprel-ro -multilib-library-pi
-mlinked-fp -mlong- alls -malign-labels
-mlibrary-pi -ma -4 -ma -8
-mpa k -mno-pa k -mno-eflags -m ond-move -mno- ond-move
-ms -mno-s -m ond-exe -mno- ond-exe
-mvliw-bran h -mno-vliw-bran h
-mmulti- ond-exe -mno-multi- ond-exe -mnested- ond-exe
-mno-nested- ond-exe -mtom at-stats
-mTLS -mtls
-m pu= pu

H8/300 Options

-mrelax -mh -ms -mn -mint32 -malign-300

HPPA Options

-mar h=ar hite ture-type

-mbig-swit h -mdisable-fpregs -mdisable-indexing
-mfast-indire t- alls -mgas -mgnu-ld -mhp-ld

Chapter 3: GCC Command Options

-mfixed-range=register-range
-mjump-in-delay -mlinker-opt -mlong- alls
-mlong-load-store -mno-big-swit h -mno-disable-fpregs
-mno-disable-indexing -mno-fast-indire t- alls -mno-gas
-mno-jump-in-delay -mno-long-load-store
-mno-portable-runtime -mno-soft-float
-mno-spa e-regs -msoft-float -mpa-ris -1-0
-mpa-ris -1-1 -mpa-ris -2-0 -mportable-runtime
-ms hedule= pu-type -mspa e-regs -msio -mwsio
-munix=unix-std -nolibdld -stati -threads

i386 and x86-64 Options

-mtune= pu-type -mar h= pu-type

-mfpmath=unit
-masm=diale t -mno-fan y-math-387
-mno-fp-ret-in-387 -msoft-float -msvr3-shlib
-mno-wide-multiply -mrtd -malign-double
-mpreferred-sta k-boundary=num
-mmmx -msse -msse2 -msse3 -m3dnow
-mthreads -mno-align-stringops -minline-all-stringops
-mpush-args -ma umulate-outgoing-args -m128bit-long-double
-m96bit-long-double -mregparm=num -momit-leaf-frame-pointer
-mno-red-zone -mno-tls-dire t-seg-refs
-m model= ode-model
-m32 -m64

IA-64 Options

-mbig-endian -mlittle-endian -mgnu-as -mgnu-ld -mno-pi

-mvolatile-asm-stop -mregister-names -mno-sdata
-m onstant-gp -mauto-pi -minline-float-divide-min-laten y
-minline-float-divide-max-throughput
-minline-int-divide-min-laten y
-minline-int-divide-max-throughput
-minline-sqrt-min-laten y -minline-sqrt-max-throughput
-mno-dwarf2-asm -mearly-stop-bits
-mfixed-range=register-range -mtls-size=tls-size
-mtune= pu-type -mt -pthread -milp32 -mlp64

M32R/D Options

-m32r2 -m32rx -m32r

-mdebug
-malign-loops -mno-align-loops
-missue-rate=number
-mbran h- ost=number
-mmodel= ode-size-model-type
-msdata=sdata-type
-mno-flush-fun -mflush-fun =name
-mno-flush-trap -mflush-trap=number
-G num

M680x0 Options

-m68000 -m68020 -m68020-40 -m68020-60 -m68030 -m68040

-m68060 -m pu32 -m5200 -m68881 -mbitfield -m 68000 -m 68020
-mnobitfield -mrtd -mshort -msoft-float -mp rel
-malign-int -mstri t-align -msep-data -mno-sep-data
-mshared-library-id=n -mid-shared-library -mno-id-shared-library

M68h 1x Options

-m6811 -m6812 -m68h 11 -m68h 12 -m68h s12

-mauto-in de -minmax -mlong- alls -mshort
-msoft-reg- ount= ount

13

14

Using the GNU Compiler Colle tion (GCC)

MCore Options

-mhardlit -mno-hardlit -mdiv -mno-div -mrelax-immediates

-mno-relax-immediates -mwide-bitfields -mno-wide-bitfields
-m4byte-fun tions -mno-4byte-fun tions -m allgraph-data
-mno- allgraph-data -mslow-bytes -mno-slow-bytes -mno-lsim
-mlittle-endian -mbig-endian -m210 -m340 -msta k-in rement

MIPS Options

-EL -EB -mar h=ar h -mtune=ar h

-mips1 -mips2 -mips3 -mips4 -mips32 -mips32r2 -mips64
-mips16 -mno-mips16 -mabi=abi -mabi alls -mno-abi alls
-mxgot -mno-xgot -mgp32 -mgp64 -mfp32 -mfp64
-mhard-float -msoft-float -msingle-float -mdouble-float
-mpaired-single -mips3d
-mint64 -mlong64 -mlong32 -msym32 -mno-sym32
-Gnum -membedded-data -mno-embedded-data
-muninit- onst-in-rodata -mno-uninit- onst-in-rodata
-msplit-addresses -mno-split-addresses
-mexpli it-relo s -mno-expli it-relo s
-m he k-zero-division -mno- he k-zero-division
-mdivide-traps -mdivide-breaks
-mmem py -mno-mem py -mlong- alls -mno-long- alls
-mmad -mno-mad -mfused-madd -mno-fused-madd -no pp
-mfix-r4000 -mno-fix-r4000 -mfix-r4400 -mno-fix-r4400
-mfix-vr4120 -mno-fix-vr4120 -mfix-vr4130
-mfix-sb1 -mno-fix-sb1
-mflush-fun =fun -mno-flush-fun
-mbran h-likely -mno-bran h-likely
-mfp-ex eptions -mno-fp-ex eptions
-mvr4130-align -mno-vr4130-align

MMIX Options

-mlibfun s -mno-libfun s -mepsilon -mno-epsilon -mabi=gnu

-mabi=mmixware -mzero-extend -mknuthdiv -mtoplevel-symbols
-melf -mbran h-predi t -mno-bran h-predi t -mbase-addresses
-mno-base-addresses -msingle-exit -mno-single-exit

MN10300 Options

-mmult-bug -mno-mult-bug
-mam33 -mno-am33
-mam33-2 -mno-am33-2
-mno- rt0 -mrelax

NS32K Options

-m32032 -m32332 -m32532

-mmult-add -mnomult-add
-mregparam -mnoregparam
-mbitfield -mnobitfield

PDP-11 Options

-m32081 -m32381
-msoft-float -mrtd -mnortd
-msb -mnosb
-mhimem -mnohimem

-mfpu -msoft-float -ma 0 -mno-a 0 -m40 -m45 -m10

-mb opy -mb opy-builtin -mint32 -mno-int16
-mint16 -mno-int32 -mfloat32 -mno-float64
-mfloat64 -mno-float32 -mabshi -mno-abshi
-mbran h-expensive -mbran h- heap
-msplit -mno-split -munix-asm -mde -asm

PowerPC Options See RS/6000 and PowerPC Options.

RS/6000 and PowerPC Options
-m pu= pu-type
-mtune= pu-type

Chapter 3: GCC Command Options

15

-mpower -mno-power -mpower2 -mno-power2

-mpowerp -mpowerp 64 -mno-powerp
-maltive -mno-altive
-mpowerp -gpopt -mno-powerp -gpopt
-mpowerp -gfxopt -mno-powerp -gfxopt
-mnew-mnemoni s -mold-mnemoni s
-mfull-to -mminimal-to -mno-fp-in-to -mno-sum-in-to
-m64 -m32 -mxl- ompat -mno-xl- ompat -mpe
-malign-power -malign-natural
-msoft-float -mhard-float -mmultiple -mno-multiple
-mstring -mno-string -mupdate -mno-update
-mfused-madd -mno-fused-madd -mbit-align -mno-bit-align
-mstri t-align -mno-stri t-align -mrelo atable
-mno-relo atable -mrelo atable-lib -mno-relo atable-lib
-mto -mno-to -mlittle -mlittle-endian -mbig -mbig-endian
-mdynami -no-pi
-mprioritize-restri ted-insns=priority
-ms hed- ostly-dep=dependen e_type
-minsert-s hed-nops=s heme
-m all-sysv -m all-netbsd
-maix-stru t-return -msvr4-stru t-return
-mabi=altive -mabi=no-altive
-mabi=spe -mabi=no-spe
-misel=yes -misel=no
-mspe=yes -mspe=no
-mfloat-gprs=yes -mfloat-gprs=no -mfloat-gprs=single -mfloat-gprs=double
-mprototype -mno-prototype
-msim -mmvme -mads -myellowknife -memb -msdata
-msdata=opt -mvxworks -mwindiss -G num -pthread

S/390 and zSeries Options

-mtune= pu-type -mar h= pu-type

-mhard-float -msoft-float -mba k hain -mno-ba k hain
-mpa ked-sta k -mno-pa ked-sta k
-msmall-exe -mno-small-exe -mmv le -mno-mv le
-m64 -m31 -mdebug -mno-debug -mesa -mzar h
-mtpf-tra e -mno-tpf-tra e -mfused-madd -mno-fused-madd
-mwarn-framesize -mwarn-dynami sta k -msta k-size -msta k-guard

SH Options

-m1 -m2 -m2e -m3 -m3e

-m4-nofpu -m4-single-only -m4-single -m4
-m4a-nofpu -m4a-single-only -m4a-single -m4a -m4al
-m5-64media -m5-64media-nofpu
-m5-32media -m5-32media-nofpu
-m5- ompa t -m5- ompa t-nofpu
-mb -ml -mdalign -mrelax
-mbigtable -mfmovd -mhita hi -mrenesas -mno-renesas -mnoma save
-mieee -misize -mpadstru t -mspa e
-mprefergot -musermode

SPARC Options

-m pu= pu-type
-mtune= pu-type
-m model= ode-model
-m32 -m64 -mapp-regs -mno-app-regs
-mfaster-stru ts -mno-faster-stru ts
-mfpu -mno-fpu -mhard-float -msoft-float
-mhard-quad-float -msoft-quad-float
-mimpure-text -mno-impure-text -mlittle-endian

16

Using the GNU Compiler Colle tion (GCC)

-msta k-bias -mno-sta k-bias

-munaligned-doubles -mno-unaligned-doubles
-mv8plus -mno-v8plus -mvis -mno-vis -threads -pthreads

System V Options

-Qy -Qn -YP,paths -Ym,dir

TMS320C3x/C4x Options

-m pu= pu -mbig -msmall -mregparm -mmemparm

-mfast-fix -mmpyi -mbk -mti -mdp-isr-reload
-mrpts= ount -mrptb -mdb -mloop-unsigned
-mparallel-insns -mparallel-mpy -mpreserve-float

V850 Options

-mlong- alls -mno-long- alls -mep -mno-ep

-mprolog-fun tion -mno-prolog-fun tion -mspa e
-mtda=n -msda=n -mzda=n
-mapp-regs -mno-app-regs
-mdisable- allt -mno-disable- allt
-mv850e1
-mv850e
-mv850 -mbig-swit h

VAX Options

-mg -mgnu -munix

x86-64 Options See i386 and x86-64 Options.

Xstormy16 Options
-msim

Xtensa Options

-m onst16 -mno- onst16

-mfused-madd -mno-fused-madd
-mtext-se tion-literals -mno-text-se tion-literals
-mtarget-align -mno-target-align
-mlong alls -mno-long alls

zSeries Options See S/390 and zSeries Options.

Code Generation Options
See Se tion 3.18 [Options for Code Generation Conventions, page 178.
-f all-saved-reg -f all-used-reg
-ffixed-reg -fex eptions
-fnon- all-ex eptions -funwind-tables
-fasyn hronous-unwind-tables
-finhibit-size-dire tive -finstrument-fun tions
-fno- ommon -fno-ident
-fp -stru t-return -fpi -fPIC -fpie -fPIE
-freg-stru t-return -fshared-data -fshort-enums
-fshort-double -fshort-w har
-fverbose-asm -fpa k-stru t[=n -fsta k- he k
-fsta k-limit-register=reg -fsta k-limit-symbol=sym
-fargument-alias -fargument-noalias
-fargument-noalias-global -fleading-unders ore
-ftls-model=model
-ftrapv -fwrapv -fbounds- he k
-fvisibility

3.2 Options Controlling the Kind of Output

Compilation an involve up to four stages: prepro essing, ompilation proper, assembly
and linking, always in that order. GCC is apable of prepro essing and ompiling several

Chapter 3: GCC Command Options

17

les either into several assembler input les, or into one assembler input le; then ea h
assembler input le produ es an obje t le, and linking ombines all the obje t les (those
newly ompiled, and those spe ied as input) into an exe utable le.
For any given input le, the le name sux determines what kind of ompilation is done:
C sour e ode whi h must be prepro essed.
file.
file.i
file.ii

C sour e ode whi h should not be prepro essed.

C++ sour e ode whi h should not be prepro essed.

file.m

Obje tive-C sour e ode. Note that you must link with the `libobj ' library
to make an Obje tive-C program work.

file.mi

Obje tive-C sour e ode whi h should not be prepro essed.

file.mm
file.M

file.mii
file.h
file.
file. p
file. xx
file. pp
file.CPP
file. ++
file.C

Obje tive-C++ sour e ode. Note that you must link with the `libobj ' library
to make an Obje tive-C++ program work. Note that `.M' refers to a literal
apital M.
Obje tive-C++ sour e ode whi h should not be prepro essed.
C, C++, Obje tive-C or Obje tive-C++ header le to be turned into a pre ompiled header.

C++ sour e ode whi h must be prepro essed. Note that in `. xx', the last two
letters must both be literally `x'. Likewise, `.C' refers to a literal apital C.

file.hh
file.H

C++ header le to be turned into a pre ompiled header.

file.f
file.for
file.FOR

Fortran sour e ode whi h should not be prepro essed.

file.F
file.fpp
file.FPP
file.r
file.f90
file.f95

Fortran sour e ode whi h must be prepro essed (with the traditional prepro essor).
Fortran sour e ode whi h must be prepro essed with a RATFOR prepro essor
(not in luded with GCC).

Fortran 90/95 sour e ode whi h should not be prepro essed.

file.ads Ada sour e ode le whi h ontains a library unit de laration (a de laration of
a pa kage, subprogram, or generi , or a generi instantiation), or a library unit

18

Using the GNU Compiler Colle tion (GCC)

renaming de laration (a pa kage, generi , or subprogram renaming de laration).

Su h les are also alled spe s.
file.adb Ada sour e ode le ontaining a library unit body (a subprogram or pa kage
body). Su h les are also alled bodies.
file.s

Assembler ode.

file.S

Assembler ode whi h must be prepro essed.

other

An obje t le to be fed straight into linking. Any le name with no re ognized

sux is treated this way.

You an spe ify the input language expli itly with the `-x' option:
-x language

Spe ify expli itly the language for the following input les (rather than letting
the ompiler hoose a default based on the le name sux). This option applies
to all following input les until the next `-x' option. Possible values for language
are:
-header - pp-output
++ ++-header ++- pp-output
obje tive- obje tive- -header obje tive- - pp-output
obje tive- ++ obje tive- ++-header obje tive- ++- pp-output
assembler assembler-with- pp
ada
f77 f77- pp-input ratfor
f95
java
treelang

-x none

Turn o any spe i ation of a language, so that subsequent les are handled
a ording to their le name suxes (as they are if `-x' has not been used at
all).

-pass-exit- odes

Normally the g program will exit with the ode of 1 if any phase of the
ompiler returns a non-su ess return ode. If you spe ify `-pass-exit- odes',
the g program will instead return with numeri ally highest error produ ed
by any phase that returned an error indi ation.

If you only want some of the stages of ompilation, you an use `-x' (or lename suxes)
to tell g where to start, and one of the options `- ', `-S', or `-E' to say where g is to
stop. Note that some ombinations (for example, `-x pp-output -E') instru t g to do
nothing at all.
-

Compile or assemble the sour e les, but do not link. The linking stage simply
is not done. The ultimate output is in the form of an obje t le for ea h sour e
le.
By default, the obje t le name for a sour e le is made by repla ing the sux
`. ', `.i', `.s', et ., with `.o'.
Unre ognized input les, not requiring ompilation or assembly, are ignored.

-S

Stop after the stage of ompilation proper; do not assemble. The output is in
the form of an assembler ode le for ea h non-assembler input le spe ied.

Chapter 3: GCC Command Options

19

By default, the assembler le name for a sour e le is made by repla ing the
sux `. ', `.i', et ., with `.s'.
Input les that don't require ompilation are ignored.
-E

Stop after the prepro essing stage; do not run the ompiler proper. The output
is in the form of prepro essed sour e ode, whi h is sent to the standard output.
Input les whi h don't require prepro essing are ignored.

-o file

Pla e output in le le. This applies regardless to whatever sort of output is

being produ ed, whether it be an exe utable le, an obje t le, an assembler
le or prepro essed C ode.
If `-o' is not spe ied, the default is to put an exe utable le in `a.out', the
obje t le for `sour e.suffix ' in `sour e.o', its assembler le in `sour e.s', a
pre ompiled header le in `sour e.suffix.g h', and all prepro essed C sour e
on standard output.

-v

Print (on standard error output) the ommands exe uted to run the stages of
ompilation. Also print the version number of the ompiler driver program and
of the prepro essor and the ompiler proper.

-###

Like `-v' ex ept the ommands are not exe uted and all ommand arguments
are quoted. This is useful for shell s ripts to apture the driver-generated
ommand lines.

-pipe

Use pipes rather than temporary les for ommuni ation between the various
stages of ompilation. This fails to work on some systems where the assembler
is unable to read from a pipe; but the GNU assembler has no trouble.

- ombine If you are ompiling multiple sour e les, this option tells the driver to pass

all the sour e les to the ompiler at on e (for those languages for whi h the
ompiler an handle this). This will allow intermodule analysis (IMA) to be
performed by the ompiler. Currently the only language for whi h this is supported is C. If you pass sour e les for multiple languages to the driver, using
this option, the driver will invoke the ompiler(s) that support IMA on e ea h,
passing ea h ompiler all the sour e les appropriate for it. For those languages
that do not support IMA this option will be ignored, and the ompiler will be
invoked on e for ea h sour e le in that language. If you use this option in onjun tion with `-save-temps', the ompiler will generate multiple pre-pro essed
les (one for ea h sour e le), but only one ( ombined) `.o' or `.s' le.

--help

Print (on the standard output) a des ription of the ommand line options understood by g . If the `-v' option is also spe ied then `--help' will also be
passed on to the various pro esses invoked by g , so that they an display the
ommand line options they a ept. If the `-Wextra' option is also spe ied then
ommand line options whi h have no do umentation asso iated with them will
also be displayed.

--target-help

Print (on the standard output) a des ription of target spe i ommand line
options for ea h tool.

20

--version

Using the GNU Compiler Colle tion (GCC)

Display the version number and opyrights of the invoked GCC.

3.3 Compiling C++ Programs

C++ sour e les onventionally use one of the suxes `.C', `. ', `. pp', `.CPP', `. ++',
`. p', or `. xx'; C++ header les often use `.hh' or `.H'; and prepro essed C++ les use the
sux `.ii'. GCC re ognizes les with these names and ompiles them as C++ programs
even if you all the ompiler the same way as for ompiling C programs (usually with the
name g ).
However, C++ programs often require lass libraries as well as a ompiler that understands
the C++ language|and under some ir umstan es, you might want to ompile programs
or header les from standard input, or otherwise without a sux that ags them as C++
programs. You might also like to pre ompile a C header le with a `.h' extension to be
used in C++ ompilations. g++ is a program that alls GCC with the default language set
to C++, and automati ally spe ies linking against the C++ library. On many systems, g++
is also installed with the name ++.
When you ompile C++ programs, you may spe ify many of the same ommand-line
options that you use for ompiling programs in any language; or ommand-line options
meaningful for C and related languages; or options that are meaningful only for C++ programs. See Se tion 3.4 [Options Controlling C Diale t, page 20, for explanations of options
for languages related to C. See Se tion 3.5 [Options Controlling C++ Diale t, page 24, for
explanations of options that are meaningful only for C++ programs.

3.4 Options Controlling C Diale t

The following options ontrol the diale t of C (or languages derived from C, su h as C++,
Obje tive-C and Obje tive-C++) that the ompiler a epts:
-ansi

In C mode, support all ISO C90 programs. In C++ mode, remove GNU extensions that on i t with ISO C++.
This turns o ertain features of GCC that are in ompatible with ISO C90
(when ompiling C ode), or of standard C++ (when ompiling C++ ode), su h
as the asm and typeof keywords, and predened ma ros su h as unix and vax
that identify the type of system you are using. It also enables the undesirable
and rarely used ISO trigraph feature. For the C ompiler, it disables re ognition
of C++ style `//' omments as well as the inline keyword.
The alternate keywords __asm__, __extension__, __inline__ and __typeof_
_ ontinue to work despite `-ansi'. You would not want to use them in an ISO
C program, of ourse, but it is useful to put them in header les that might be
in luded in ompilations done with `-ansi'. Alternate predened ma ros su h
as __unix__ and __vax__ are also available, with or without `-ansi'.
The `-ansi' option does not ause non-ISO programs to be reje ted gratuitously. For that, `-pedanti ' is required in addition to `-ansi'. See Se tion 3.8
[Warning Options, page 34.
The ma ro __STRICT_ANSI__ is predened when the `-ansi' option is used.
Some header les may noti e this ma ro and refrain from de laring ertain

Chapter 3: GCC Command Options

21

fun tions or dening ertain ma ros that the ISO standard doesn't all for; this
is to avoid interfering with any programs that might use these names for other
things.
Fun tions whi h would normally be built in but do not have semanti s dened
by ISO C (su h as allo a and ffs) are not built-in fun tions with `-ansi' is
used. See Se tion 5.44 [Other built-in fun tions provided by GCC, page 272,
for details of the fun tions ae ted.
-std=

Determine the language standard. This option is urrently only supported when
ompiling C or C++. A value for this option must be provided; possible values
are
` 89'
`iso9899:1990'
ISO C90 (same as `-ansi').
`iso9899:199409'
ISO C90 as modied in amendment 1.
` 99'
` 9x'
`iso9899:1999'
`iso9899:199x'
ISO C99. Note that this standard is not yet fully supported;
see http://g .gnu.org/g -4.0/ 99status.html for more information. The names ` 9x' and `iso9899:199x' are depre ated.
`gnu89'
`gnu99'
`gnu9x'
` ++98'

Default, ISO C90 plus GNU extensions (in luding some C99 features).
ISO C99 plus GNU extensions. When ISO C99 is fully implemented
in GCC, this will be ome the default. The name `gnu9x' is depre ated.
The 1998 ISO C++ standard plus amendments.

`gnu++98' The same as `-std= ++98' plus GNU extensions. This is the default
for C++ ode.
Even when this option is not spe ied, you an still use some of the features of
newer standards in so far as they do not on i t with previous C standards. For
example, you may use __restri t__ even when `-std= 99' is not spe ied.
The `-std' options spe ifying some version of ISO C have the same ee ts as
`-ansi', ex ept that features that were not in ISO C90 but are in the spe ied
version (for example, `//' omments and the inline keyword in ISO C99) are
not disabled.
See Chapter 2 [Language Standards Supported by GCC, page 5, for details of
these standard versions.

22

Using the GNU Compiler Colle tion (GCC)

-aux-info filename

Output to the given lename prototyped de larations for all fun tions de lared
and/or dened in a translation unit, in luding those in header les. This option
is silently ignored in any language other than C.
Besides de larations, the le indi ates, in omments, the origin of ea h de laration (sour e le and line), whether the de laration was impli it, prototyped or
unprototyped (`I', `N' for new or `O' for old, respe tively, in the rst hara ter
after the line number and the olon), and whether it ame from a de laration
or a denition (`C' or `F', respe tively, in the following hara ter). In the ase
of fun tion denitions, a K&R-style list of arguments followed by their de larations is also provided, inside omments, after the de laration.

-fno-asm Do not re ognize asm, inline or typeof as a keyword, so that ode an use
these words as identiers. You an use the keywords __asm__, __inline__ and
__typeof__ instead. `-ansi' implies `-fno-asm'.
In C++, this swit h only ae ts the typeof keyword, sin e asm and inline
are standard keywords. You may want to use the `-fno-gnu-keywords' ag
instead, whi h has the same ee t. In C99 mode (`-std= 99' or `-std=gnu99'),
this swit h only ae ts the asm and typeof keywords, sin e inline is a standard

keyword in ISO C99.

-fno-builtin
-fno-builtin-fun tion

Don't re ognize built-in fun tions that do not begin with `__builtin_' as prex.
See Se tion 5.44 [Other built-in fun tions provided by GCC, page 272, for
details of the fun tions ae ted, in luding those whi h are not built-in fun tions
when `-ansi' or `-std' options for stri t ISO C onforman e are used be ause
they do not have an ISO standard meaning.
GCC normally generates spe ial ode to handle ertain built-in fun tions more
e iently; for instan e, alls to allo a may be ome single instru tions that
adjust the sta k dire tly, and alls to mem py may be ome inline opy loops.
The resulting ode is often both smaller and faster, but sin e the fun tion
alls no longer appear as su h, you annot set a breakpoint on those alls,
nor an you hange the behavior of the fun tions by linking with a dierent
library. In addition, when a fun tion is re ognized as a built-in fun tion, GCC
may use information about that fun tion to warn about problems with alls to
that fun tion, or to generate more e ient ode, even if the resulting ode still
ontains alls to that fun tion. For example, warnings are given with `-Wformat'
for bad alls to printf, when printf is built in, and strlen is known not to
modify global memory.
With the `-fno-builtin-fun tion ' option only the built-in fun tion fun tion
is disabled. fun tion must not begin with `__builtin_'. If a fun tion is named
this is not built-in in this version of GCC, this option is ignored. There is
no orresponding `-fbuiltin-fun tion ' option; if you wish to enable built-in
fun tions sele tively when using `-fno-builtin' or `-ffreestanding', you may
dene ma ros su h as:
#define abs(n)

__builtin_abs ((n))

Chapter 3: GCC Command Options

#define str py(d, s)

-fhosted

23

__builtin_str py ((d), (s))

Assert that ompilation takes pla e in a hosted environment. This implies

`-fbuiltin'. A hosted environment is one in whi h the entire standard library
is available, and in whi h main has a return type of int. Examples are nearly
everything ex ept a kernel. This is equivalent to `-fno-freestanding'.

-ffreestanding

Assert that ompilation takes pla e in a freestanding environment. This implies

`-fno-builtin'. A freestanding environment is one in whi h the standard
library may not exist, and program startup may not ne essarily be at main. The
most obvious example is an OS kernel. This is equivalent to `-fno-hosted'.
See Chapter 2 [Language Standards Supported by GCC, page 5, for details of
freestanding and hosted environments.

-fms-extensions

A ept some non-standard onstru ts used in Mi rosoft header les.

Some ases of unnamed elds in stru tures and unions are only a epted
with this option. See Se tion 5.48 [Unnamed stru t/union elds within
stru ts/unions, page 330, for details.

-trigraphs

Support ISO C trigraphs. The `-ansi' option (and `-std' options for stri t ISO
C onforman e) implies `-trigraphs'.

-no-integrated- pp

Performs a ompilation in two passes: prepro essing and ompiling. This option
allows a user supplied " 1", " 1plus", or " 1obj" via the `-B' option. The
user supplied ompilation step an then add in an additional prepro essing
step after normal prepro essing but before ompiling. The default is to use the
integrated pp (internal pp)
The semanti s of this option will hange if " 1", " 1plus", and " 1obj" are
merged.

-traditional
-traditional- pp

Formerly, these options aused GCC to attempt to emulate a pre-standard C

ompiler. They are now only supported with the `-E' swit h. The prepro essor
ontinues to support a pre-standard mode. See the GNU CPP manual for
details.

-f ond-mismat h

Allow onditional expressions with mismat hed types in the se ond and third
arguments. The value of su h an expression is void. This option is not supported
for C++.

-funsigned- har

Let the type har be unsigned, like unsigned har.

Ea h kind of ma hine has a default for what har should be. It is either like
unsigned har by default or like signed har by default.

24

Using the GNU Compiler Colle tion (GCC)

Ideally, a portable program should always use signed har or unsigned har
when it depends on the signedness of an obje t. But many programs have been
written to use plain har and expe t it to be signed, or expe t it to be unsigned,
depending on the ma hines they were written for. This option, and its inverse,
let you make su h a program work with the opposite default.
The type har is always a distin t type from ea h of signed har or unsigned
har, even though its behavior is always just like one of those two.
-fsigned- har

Let the type har be signed, like signed har.

Note that this is equivalent to `-fno-unsigned- har', whi h is the negative
form of `-funsigned- har'. Likewise, the option `-fno-signed- har' is equivalent to `-funsigned- har'.

-fsigned-bitfields
-funsigned-bitfields
-fno-signed-bitfields
-fno-unsigned-bitfields

These options ontrol whether a bit-eld is signed or unsigned, when the de laration does not use either signed or unsigned. By default, su h a bit-eld is
signed, be ause this is onsistent: the basi integer types su h as int are signed
types.

3.5 Options Controlling C++ Diale t

This se tion des ribes the ommand-line options that are only meaningful for C++ programs;
but you an also use most of the GNU ompiler options regardless of what language your
program is in. For example, you might ompile a le firstClass.C like this:
g++ -g -frepo -O - firstClass.C

In this example, only `-frepo' is an option meant only for C++ programs; you an use the
other options with any language supported by GCC.
Here is a list of options that are only for ompiling C++ programs:
-fabi-version=n

Use version n of the C++ ABI. Version 2 is the version of the C++ ABI that
rst appeared in G++ 3.4. Version 1 is the version of the C++ ABI that rst
appeared in G++ 3.2. Version 0 will always be the version that onforms most
losely to the C++ ABI spe i ation. Therefore, the ABI obtained using version
0 will hange as ABI bugs are xed.
The default is version 2.

-fno-a ess- ontrol

Turn o all a ess he king. This swit h is mainly useful for working around
bugs in the a ess ontrol ode.

-f he k-new

Che k that the pointer returned by operator new is non-null before attempting
to modify the storage allo ated. This he k is normally unne essary be ause
the C++ standard spe ies that operator new will only return 0 if it is de lared

Chapter 3: GCC Command Options

25

`throw()', in whi h ase the ompiler will always he k the return value even
without this option. In all other ases, when operator new has a non-empty
ex eption spe i ation, memory exhaustion is signalled by throwing std::bad_
allo . See also `new (nothrow)'.
-f onserve-spa e

Put uninitialized or runtime-initialized global variables into the ommon segment, as C does. This saves spa e in the exe utable at the ost of not diagnosing
dupli ate denitions. If you ompile with this ag and your program mysteriously rashes after main() has ompleted, you may have an obje t that is being
destroyed twi e be ause two denitions 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 ommon.

-fno- onst-strings

Give string onstants type har * instead of type onst har *. By default,
G++ uses type onst har * as required by the standard. Even if you use
`-fno- onst-strings', you annot a tually modify the value of a string onstant.
This option might be removed in a future release of G++. For maximum portability, you should stru ture your ode so that it works with string onstants
that have type onst har *.

-fno-elide- onstru tors

The C++ standard allows an implementation to omit reating a temporary whi h

is only used to initialize another obje t of the same type. Spe ifying this option
disables that optimization, and for es G++ to all the opy onstru tor in all
ases.

-fno-enfor e-eh-spe s

Don't he k for violation of ex eption spe i ations at runtime. This option

violates the C++ standard, but may be useful for redu ing ode size in produ tion builds, mu h like dening `NDEBUG'. The ompiler will still optimize based
on the ex eption spe i ations.

-ffor-s ope
-fno-for-s ope
If `-ffor-s ope' is spe ied, the s ope of variables de lared in a for-initstatement is limited to the `for' loop itself, as spe ied by the C++ standard.
If `-fno-for-s ope' is spe ied, the s ope of variables de lared in a for-init-

statement extends to the end of the en losing s ope, as was the ase in old
versions of G++, and other (traditional) implementations of C++.
The default if neither ag is given to follow the standard, but to allow and give
a warning for old-style ode that would otherwise be invalid, or have dierent
behavior.

-fno-gnu-keywords

Do not re ognize typeof as a keyword, so that ode an use this word as

an identier. You an use the keyword __typeof__ instead. `-ansi' implies
`-fno-gnu-keywords'.

26

Using the GNU Compiler Colle tion (GCC)

-fno-impli it-templates

Never emit ode for non-inline templates whi h are instantiated impli itly (i.e.
by use); only emit ode for expli it instantiations. See Se tion 6.5 [Template
Instantiation, page 339, for more information.

-fno-impli it-inline-templates

Don't emit ode for impli it instantiations of inline templates, either. The
default is to handle inlines dierently so that ompiles with and without optimization will need the same set of expli it instantiations.

-fno-implement-inlines

To save spa e, do not emit out-of-line opies of inline fun tions ontrolled by
`#pragma implementation'. This will ause linker errors if these fun tions are
not inlined everywhere they are alled.

-fms-extensions

Disable pedanti warnings about onstru ts used in MFC, su h as impli it int

and getting a pointer to member fun tion via non-standard syntax.

-fno-nonansi-builtins

Disable built-in de larations of fun tions that are not mandated by ANSI/ISO
C. These in lude ffs, allo a, _exit, index, bzero, onjf, and other related
fun tions.

-fno-operator-names

Do not treat the operator name keywords and, bitand, bitor, ompl, not, or
and xor as synonyms as keywords.

-fno-optional-diags

Disable diagnosti s that the standard says a ompiler does not need to issue.
Currently, the only su h diagnosti issued by G++ is the one for a name having
multiple meanings within a lass.

-fpermissive

Downgrade some diagnosti s about non onformant ode from errors to warnings. Thus, using `-fpermissive' will allow some non onforming ode to ompile.

-frepo

-fno-rtti

-fstats

Enable automati template instantiation at link time. This option also implies `-fno-impli it-templates'. See Se tion 6.5 [Template Instantiation,
page 339, for more information.
Disable generation of information about every lass with virtual fun tions
for use by the C++ runtime type identi ation features (`dynami _ ast'
and `typeid'). If you don't use those parts of the language, you an save
some spa e by using this ag. Note that ex eption handling uses the same
information, but it will generate it as needed.
Emit statisti s about front-end pro essing at the end of the ompilation. This
information is generally only useful to the G++ development team.

Chapter 3: GCC Command Options

27

-ftemplate-depth-n

Set the maximum instantiation depth for template lasses to n. A limit on

the template instantiation depth is needed to dete t endless re ursions during
template lass instantiation. ANSI/ISO C++ onforming programs must not
rely on a maximum depth greater than 17.

-fno-threadsafe-stati s

Do not emit the extra ode to use the routines spe ied in the C++ ABI for
thread-safe initialization of lo al stati s. You an use this option to redu e ode
size slightly in ode that doesn't need to be thread-safe.

-fuse- xa-atexit

Register destru tors for obje ts with stati storage duration with the __ xa_
atexit fun tion rather than the atexit fun tion. This option is required for

fully standards- ompliant handling of stati destru tors, but will only work if
your C library supports __ xa_atexit.
-fvisibility-inlines-hidden

Causes all inlined methods to be marked with __attribute__ ((visibility

("hidden"))) so that they do not appear in the export table of a DSO and do

not require a PLT indire tion when used within the DSO. Enabling this option
an have a dramati ee t on load and link times of a DSO as it massively
redu es the size of the dynami export table when the library makes heavy use
of templates. While it an ause bloating through dupli ation of ode within
ea h DSO where it is used, often the wastage is less than the onsiderable spa e
o upied by a long symbol name in the export table whi h is typi al when
using templates and namespa es. For even more savings, ombine with the
`-fvisibility=hidden' swit h.
-fno-weak

Do not use weak symbol support, even if it is provided by the linker. By

default, G++ will use weak symbols if they are available. This option exists
only for testing, and should not be used by end-users; it will result in inferior
ode and has no benets. This option may be removed in a future release of
G++.

-nostdin ++

Do not sear h for header les in the standard dire tories spe i to C++, but do
still sear h the other standard dire tories. (This option is used when building
the C++ library.)
In addition, these optimization, warning, and ode generation options have meanings only
for C++ programs:
-fno-default-inline

Do not assume `inline' for fun tions dened inside a lass s ope. See Se tion 3.10 [Options That Control Optimization, page 61. Note that these fun tions will have linkage like inline fun tions; they just won't be inlined by default.
-Wabi (C++ only)
Warn when G++ generates ode that is probably not ompatible with the
vendor-neutral C++ ABI. Although an eort has been made to warn about

28

Using the GNU Compiler Colle tion (GCC)

all su h ases, there are probably some ases that are not warned about, even
though G++ is generating in ompatible ode. There may also be ases where
warnings are emitted even though the ode that is generated will be ompatible.
You should rewrite your ode to avoid these warnings if you are on erned about
the fa t that ode generated by G++ may not be binary ompatible with ode
generated by other ompilers.
The known in ompatibilities at this point in lude:
 In orre t handling of tail-padding for bit-elds. G++ may attempt to pa k
data into the same byte as a base lass. For example:
stru t A { virtual void f(); int f1 : 1; };
stru t B : publi A { int f2 : 1; };

In this ase, G++ will pla e B::f2 into the same byte asA::f1; other ompilers will not. You an avoid this problem by expli itly padding A so that
its size is a multiple of the byte size on your platform; that will ause G++
and other ompilers to layout B identi ally.
In orre t handling of tail-padding for virtual bases. G++ does not use tail
padding when laying out virtual bases. For example:
stru t A { virtual void f(); har 1; };
stru t B { B(); har 2; };
stru t C : publi A, publi virtual B {};

In this ase, G++ will not pla e B into the tail-padding for A; other ompilers
will. You an avoid this problem by expli itly padding A so that its size is
a multiple of its alignment (ignoring virtual base lasses); that will ause
G++ and other ompilers to layout C identi ally.
In orre t handling of bit-elds with de lared widths greater than that of
their underlying types, when the bit-elds appear in a union. For example:
union U { int i : 4096; };

Assuming that an int does not have 4096 bits, G++ will make the union
too small by the number of bits in an int.
Empty lasses an be pla ed at in orre t osets. For example:
stru t A {};
stru t B {
A a;
virtual void f ();
};
stru t C : publi B, publi A {};

G++ will pla e the A base lass of C at a nonzero oset; it should be pla ed
at oset zero. G++ mistakenly believes that the A data member of B is
already at oset zero.
Names of template fun tions whose types involve typename or template
template parameters an be mangled in orre tly.
template <typename Q>
void f(typename Q::X) {}
template <template <typename> lass Q>

Chapter 3: GCC Command Options

29

void f(typename Q<int>::X) {}

Instantiations of these templates may be mangled in orre tly.

-W tor-dtor-priva y (C++ only)
Warn when a lass seems unusable be ause all the onstru tors or destru tors
in that lass are private, and it has neither friends nor publi stati member
fun tions.
-Wnon-virtual-dtor (C++ only)
Warn when a lass appears to be polymorphi , thereby requiring a virtual
destru tor, yet it de lares a non-virtual one. This warning is enabled by `-Wall'.
-Wreorder (C++ only)
Warn when the order of member initializers given in the ode does not mat h
the order in whi h they must be exe uted. For instan e:
stru t A {
int i;
int j;
A(): j (0), i (1) { }
};

The ompiler will rearrange the member initializers for `i' and `j' to mat h
the de laration order of the members, emitting a warning to that ee t. This
warning is enabled by `-Wall'.
The following `-W...' options are not ae ted by `-Wall'.
-Weff ++ (C++ only)
Warn about violations of the following style guidelines from S ott Meyers' Effe tive C++ book:
 Item 11: Dene a opy onstru tor and an assignment operator for lasses
with dynami ally allo ated memory.
 Item 12: Prefer initialization to assignment in onstru tors.
 Item 14: Make destru tors virtual in base lasses.
 Item 15: Have operator= return a referen e to *this.
 Item 23: Don't try to return a referen e when you must return an obje t.
Also warn about violations of the following style guidelines from S ott Meyers'
More Ee tive C++ book:
 Item 6: Distinguish between prex and postx forms of in rement and
de rement operators.
 Item 7: Never overload &&, ||, or ,.
When sele ting this option, be aware that the standard library headers do not
obey all of these guidelines; use `grep -v' to lter out those warnings.
-Wno-depre ated (C++ only)
Do not warn about usage of depre ated features. See Se tion 6.10 [Depre ated
Features, page 343.
-Wno-non-template-friend (C++ only)
Disable warnings when non-templatized friend fun tions are de lared within a
template. Sin e the advent of expli it template spe i ation support in G++,

30

Using the GNU Compiler Colle tion (GCC)

if the name of the friend is an unqualied-id (i.e., `friend foo(int)'), the
C++ language spe i ation demands that the friend de lare or dene an ordinary, nontemplate fun tion. (Se tion 14.5.3). Before G++ implemented expli it
spe i ation, unqualied-ids ould be interpreted as a parti ular spe ialization
of a templatized fun tion. Be ause this non- onforming behavior is no longer
the default behavior for G++, `-Wnon-template-friend' allows the ompiler to
he k existing ode for potential trouble spots and is on by default. This new
ompiler behavior an be turned o with `-Wno-non-template-friend' whi h
keeps the onformant ompiler ode but disables the helpful warning.
-Wold-style- ast (C++ only)
Warn if an old-style (C-style) ast to a non-void type is used within a C++
program. The new-style asts (`stati _ ast', `reinterpret_ ast', and
` onst_ ast') are less vulnerable to unintended ee ts and mu h easier to
sear h for.
-Woverloaded-virtual (C++ only)
Warn when a fun tion de laration hides virtual fun tions from a base lass. For
example, in:
stru t A {
virtual void f();
};

stru t B: publi A {
void f(int);
};

the A lass version of f is hidden in B, and ode like:

B* b;
b->f();

will fail to ompile.

-Wno-pmf- onversions (C++ only)
Disable the diagnosti for onverting a bound pointer to member fun tion to a
plain pointer.
-Wsign-promo (C++ only)
Warn when overload resolution hooses a promotion from unsigned or enumerated type to a signed type, over a onversion to an unsigned type of the same
size. Previous versions of G++ would try to preserve unsignedness, but the
standard mandates the urrent behavior.
stru t A {
operator int ();
A& operator = (int);
};
main ()
{
A a,b;
a = b;
}

In this example, G++ will synthesize a default `A& operator = ( onst A&);',
while front will use the user-dened `operator ='.

Chapter 3: GCC Command Options

31

3.6 Options Controlling Obje tive-C and Obje tive-C++

Diale ts
(NOTE: This manual does not des ribe the Obje tive-C and Obje tive-C++ languages themselves. See See Chapter 2 [Language Standards Supported by GCC, page 5, for referen es.)
This se tion des ribes the ommand-line options that are only meaningful for Obje tive-C
and Obje tive-C++ programs, but you an also use most of the language-independent GNU
ompiler options. For example, you might ompile a le some_ lass.m like this:
g -g -fgnu-runtime -O - some_ lass.m

In this example, `-fgnu-runtime' is an option meant only for Obje tive-C and Obje tiveC++ programs; you an use the other options with any language supported by GCC.
Note that sin e Obje tive-C is an extension of the C language, Obje tive-C ompilations may also use options spe i to the C front-end (e.g., `-Wtraditional'). Similarly,
Obje tive-C++ ompilations may use C++-spe i options (e.g., `-Wabi').
Here is a list of options that are only for ompiling Obje tive-C and Obje tive-C++
programs:
-f onstant-string- lass= lass-name

Use lass-name as the name of the lass to instantiate for ea h literal string
spe ied with the syntax "...". The default lass name is NXConstantString
if the GNU runtime is being used, and NSConstantString if the NeXT runtime
is being used (see below). The `-f onstant- fstrings' option, if also present,
will override the `-f onstant-string- lass' setting and ause "..." literals
to be laid out as onstant CoreFoundation strings.

-fgnu-runtime

Generate obje t ode ompatible with the standard GNU Obje tive-C runtime.
This is the default for most types of systems.

-fnext-runtime

Generate output ompatible with the NeXT runtime. This is the default for
NeXT-based systems, in luding Darwin and Ma OS X. The ma ro __NEXT_
RUNTIME__ is predened if (and only if) this option is used.

-fno-nil-re eivers

Assume that all Obje tive-C message dispat hes (e.g., [re eiver
message:arg) in this translation unit ensure that the re eiver is not nil.
This allows for more e ient entry points in the runtime to be used. Currently,
this option is only available in onjun tion with the NeXT runtime on Ma
OS X 10.3 and later.

-fobj -ex eptions

Enable synta ti support for stru tured ex eption handling in Obje tive-C, similar to what is oered by C++ and Java. Currently, this option is only available
in onjun tion with the NeXT runtime on Ma OS X 10.3 and later.
try {
...
throw expr;
...
}
 at h (AnObjCClass *ex ) {

32

Using the GNU Compiler Colle tion (GCC)

...
throw expr;
...
throw;
...

}
 at h (AnotherClass *ex ) {
...
}
 at h (id allOthers) {
...
}
finally {
...
throw expr;
...
}

The throw statement may appear anywhere in an Obje tive-C or Obje tiveC++ program; when used inside of a  at h blo k, the throw may appear
without an argument (as shown above), in whi h ase the obje t aught by the
 at h will be rethrown.
Note that only (pointers to) Obje tive-C obje ts may be thrown and aught
using this s heme. When an obje t is thrown, it will be aught by the nearest
 at h lause apable of handling obje ts of that type, analogously to how
at h blo ks work in C++ and Java. A  at h(id ...) lause (as shown
above) may also be provided to at h any and all Obje tive-C ex eptions not
aught by previous  at h lauses (if any).
The finally lause, if present, will be exe uted upon exit from the immediately pre eding try ...  at h se tion. This will happen regardless of
whether any ex eptions are thrown, aught or rethrown inside the try ...
 at h se tion, analogously to the behavior of the finally lause in Java.
There are several aveats to using the new ex eption me hanism:
 Although urrently designed to be binary ompatible with NS_HANDLERstyle idioms provided by the NSEx eption lass, the new ex eptions an
only be used on Ma OS X 10.3 (Panther) and later systems, due to additional fun tionality needed in the (NeXT) Obje tive-C runtime.
 As mentioned above, the new ex eptions do not support handling types
other than Obje tive-C obje ts. Furthermore, when used from Obje tiveC++, the Obje tive-C ex eption model does not interoperate with C++
ex eptions at this time. This means you annot throw an ex eption from
Obje tive-C and at h it in C++, or vi e versa (i.e., throw ...  at h).
The `-fobj -ex eptions' swit h also enables the use of syn hronization blo ks
for thread-safe exe ution:
syn hronized (ObjCClass *guard) {
...
}

Upon entering the syn hronized blo k, a thread of exe ution shall rst he k
whether a lo k has been pla ed on the orresponding guard obje t by another
thread. If it has, the urrent thread shall wait until the other thread relinquishes

Chapter 3: GCC Command Options

33

its lo k. On e guard be omes available, the urrent thread will pla e its own
lo k on it, exe ute the ode ontained in the syn hronized blo k, and nally
relinquish the lo k (thereby making guard available to other threads).
Unlike Java, Obje tive-C does not allow for entire methods to be marked
syn hronized. Note that throwing ex eptions out of syn hronized blo ks
is allowed, and will ause the guarding obje t to be unlo ked properly.
-frepla e-obj - lasses

Emit a spe ial marker instru ting ld(1) not to stati ally link in the resulting
obje t le, and allow dyld(1) to load it in at run time instead. This is used
in onjun tion with the Fix-and-Continue debugging mode, where the obje t
le in question may be re ompiled and dynami ally reloaded in the ourse of
program exe ution, without the need to restart the program itself. Currently,
Fix-and-Continue fun tionality is only available in onjun tion with the NeXT
runtime on Ma OS X 10.3 and later.

-fzero-link

When ompiling for the NeXT runtime, the ompiler ordinarily repla es alls to
obj _getClass("...") (when the name of the lass is known at ompile time)
with stati lass referen es that get initialized at load time, whi h improves runtime performan e. Spe ifying the `-fzero-link' ag suppresses this behavior
and auses alls to obj _getClass("...") to be retained. This is useful in
Zero-Link debugging mode, sin e it allows for individual lass implementations
to be modied during program exe ution.

-gen-de ls

Dump interfa e de larations for all lasses seen in the sour e le to a le named
`sour ename.de l'.

-Wno-proto ol

If a lass is de lared to implement a proto ol, a warning is issued for every

method in the proto ol that is not implemented by the lass. The default
behavior is to issue a warning for every method not expli itly implemented in the
lass, even if a method implementation is inherited from the super lass. If you
use the `-Wno-proto ol' option, then methods inherited from the super lass
are onsidered to be implemented, and no warning is issued for them.

-Wsele tor

Warn if multiple methods of dierent types for the same sele tor are found
during ompilation. The he k is performed on the list of methods in the
nal stage of ompilation. Additionally, a he k is performed for ea h sele tor
appearing in a sele tor(...) expression, and a orresponding method for
that sele tor has been found during ompilation. Be ause these he ks s an the
method table only at the end of ompilation, these warnings are not produ ed
if the nal stage of ompilation is not rea hed, for example be ause an error
is found during ompilation, or be ause the `-fsyntax-only' option is being
used.

-Wunde lared-sele tor

Warn if a sele tor(...) expression referring to an unde lared sele tor is

found. A sele tor is onsidered unde lared if no method with that name has

34

Using the GNU Compiler Colle tion (GCC)

been de lared before the sele tor(...) expression, either expli itly in an
interfa e or proto ol de laration, or impli itly in an implementation
se tion. This option always performs its he ks as soon as a sele tor(...)
expression is found, while `-Wsele tor' only performs its he ks in the nal
stage of ompilation. This also enfor es the oding style onvention that methods and sele tors must be de lared before being used.
-print-obj -runtime-info

Generate C header des ribing the largest stru ture that is passed by value, if
any.

3.7 Options to Control Diagnosti Messages Formatting

Traditionally, diagnosti messages have been formatted irrespe tive of the output devi e's
aspe t (e.g. its width, . . . ). The options des ribed below an be used to ontrol the diagnosti messages formatting algorithm, e.g. how many hara ters per line, how often sour e
lo ation information should be reported. Right now, only the C++ front end an honor these
options. However it is expe ted, in the near future, that the remaining front ends would be
able to digest them orre tly.
-fmessage-length=n

Try to format error messages so that they t on lines of about n hara ters. The
default is 72 hara ters for g++ and 0 for the rest of the front ends supported
by GCC. If n is zero, then no line-wrapping will be done; ea h error message
will appear on a single line.

-fdiagnosti s-show-lo ation=on e

Only meaningful in line-wrapping mode. Instru ts the diagnosti messages reporter to emit on e sour e lo ation information; that is, in ase the message
is too long to t on a single physi al line and has to be wrapped, the sour e
lo ation won't be emitted (as prex) again, over and over, in subsequent ontinuation lines. This is the default behavior.

-fdiagnosti s-show-lo ation=every-line

Only meaningful in line-wrapping mode. Instru ts the diagnosti messages

reporter to emit the same sour e lo ation information (as prex) for physi al
lines that result from the pro ess of breaking a message whi h is too long to t
on a single line.

3.8 Options to Request or Suppress Warnings

Warnings are diagnosti messages that report onstru tions whi h are not inherently erroneous but whi h are risky or suggest there may have been an error.
You an request many spe i warnings with options beginning `-W', for example
`-Wimpli it' to request warnings on impli it de larations. Ea h of these spe i warning
options also has a negative form beginning `-Wno-' to turn o warnings; for example,
`-Wno-impli it'. This manual lists only one of the two forms, whi hever is not the
default.

Chapter 3: GCC Command Options

35

The following options ontrol the amount and kinds of warnings produ ed by GCC; for
further, language-spe i options also refer to Se tion 3.5 [C++ Diale t Options, page 24
and Se tion 3.6 [Obje tive-C and Obje tive-C++ Diale t Options, page 31.
-fsyntax-only

Che k the ode for syntax errors, but don't do anything beyond that.

-pedanti

Issue all the warnings demanded by stri t ISO C and ISO C++; reje t all programs that use forbidden extensions, and some other programs that do not
follow ISO C and ISO C++. For ISO C, follows the version of the ISO C standard spe ied by any `-std' option used.
Valid ISO C and ISO C++ programs should ompile properly with or without
this option (though a rare few will require `-ansi' or a `-std' option spe ifying
the required version of ISO C). However, without this option, ertain GNU
extensions and traditional C and C++ features are supported as well. With this
option, they are reje ted.
`-pedanti ' does not ause warning messages for use of the alternate keywords
whose names begin and end with `__'. Pedanti warnings are also disabled in
the expression that follows __extension__. However, only system header les
should use these es ape routes; appli ation programs should avoid them. See
Se tion 5.38 [Alternate Keywords, page 268.
Some users try to use `-pedanti ' to he k programs for stri t ISO C onforman e. They soon nd that it does not do quite what they want: it nds
some non-ISO pra ti es, but not all|only those for whi h ISO C requires a
diagnosti , and some others for whi h diagnosti s have been added.
A feature to report any failure to onform to ISO C might be useful in some
instan es, but would require onsiderable additional work and would be quite
dierent from `-pedanti '. We don't have plans to support su h a feature in
the near future.
Where the standard spe ied with `-std' represents a GNU extended diale t
of C, su h as `gnu89' or `gnu99', there is a orresponding base standard, the
version of ISO C on whi h the GNU extended diale t is based. Warnings from
`-pedanti ' are given where they are required by the base standard. (It would
not make sense for su h warnings to be given only for features not in the spe ied GNU C diale t, sin e by denition the GNU diale ts of C in lude all features the ompiler supports with the given option, and there would be nothing
to warn about.)

-pedanti -errors
Like `-pedanti ', ex ept that errors are produ ed rather than warnings.
-w

Inhibit all warning messages.

-Wno-import

Inhibit warning messages about the use of `#import'.

36

Using the GNU Compiler Colle tion (GCC)

-W har-subs ripts

Warn if an array subs ript has type har. This is a ommon ause of error,
as programmers often forget that this type is signed on some ma hines. This
warning is enabled by `-Wall'.

-W omment

Warn whenever a omment-start sequen e `/*' appears in a `/*' omment, or

whenever a Ba kslash-Newline appears in a `//' omment. This warning is
enabled by `-Wall'.

-Wfatal-errors

This option auses the ompiler to abort ompilation on the rst error o urred
rather than trying to keep going and printing further error messages.
-Wformat Che k alls to printf and s anf, et ., to make sure that the arguments supplied
have types appropriate to the format string spe ied, and that the onversions
spe ied in the format string make sense. This in ludes standard fun tions, and
others spe ied by format attributes (see Se tion 5.24 [Fun tion Attributes,
page 217), in the printf, s anf, strftime and strfmon (an X/Open extension, not in the C standard) families (or other target-spe i families). Whi h
fun tions are he ked without format attributes having been spe ied depends
on the standard version sele ted, and su h he ks of fun tions without the attribute spe ied are disabled by `-ffreestanding' or `-fno-builtin'.
The formats are he ked against the format features supported by GNU lib
version 2.2. These in lude all ISO C90 and C99 features, as well as features
from the Single Unix Spe i ation and some BSD and GNU extensions. Other
library implementations may not support all these features; GCC does not support warning about features that go beyond a parti ular library's limitations.
However, if `-pedanti ' is used with `-Wformat', warnings will be given about
format features not in the sele ted standard version (but not for strfmon formats, sin e those are not in any version of the C standard). See Se tion 3.4
[Options Controlling C Diale t, page 20.
Sin e `-Wformat' also he ks for null format arguments for several fun tions,
`-Wformat' also implies `-Wnonnull'.
`-Wformat' is in luded in `-Wall'. For more ontrol over some aspe ts of
format he king, the options `-Wformat-y2k', `-Wno-format-extra-args',
`-Wno-format-zero-length', `-Wformat-nonliteral', `-Wformat-se urity',
and `-Wformat=2' are available, but are not in luded in `-Wall'.
-Wformat-y2k

If `-Wformat' is spe ied, also warn about strftime formats whi h may yield
only a two-digit year.

-Wno-format-extra-args
If `-Wformat' is spe ied, do not warn about ex ess arguments to a printf
or s anf format fun tion. The C standard spe ies that su h arguments are

ignored.
Where the unused arguments lie between used arguments that are spe ied
with `$' operand number spe i ations, normally warnings are still given, sin e

Chapter 3: GCC Command Options

37

the implementation ould not know what type to pass to va_arg to skip the
unused arguments. However, in the ase of s anf formats, this option will
suppress the warning if the unused arguments are all pointers, sin e the Single
Unix Spe i ation says that su h unused arguments are allowed.
-Wno-format-zero-length
If `-Wformat' is spe ied, do not warn about zero-length formats. The C stan-

dard spe ies that zero-length formats are allowed.

-Wformat-nonliteral
If `-Wformat' is spe ied, also warn if the format string is not a string literal and

so annot be he ked, unless the format fun tion takes its format arguments as
a va_list.

-Wformat-se urity
If `-Wformat' is spe ied, also warn about uses of format fun tions that represent possible se urity problems. At present, this warns about alls to printf
and s anf fun tions where the format string is not a string literal and there
are no format arguments, as in printf (foo);. This may be a se urity hole
if the format string ame from untrusted input and ontains `%n'. (This is
urrently a subset of what `-Wformat-nonliteral' warns about, but in future warnings may be added to `-Wformat-se urity' that are not in luded in
`-Wformat-nonliteral'.)
-Wformat=2

Enable `-Wformat' plus format he ks not in luded in `-Wformat'. Currently

equivalent
to
`-Wformat -Wformat-nonliteral -Wformat-se urity
-Wformat-y2k'.

-Wnonnull

Warn about passing a null pointer for arguments marked as requiring a non-null
value by the nonnull fun tion attribute.
`-Wnonnull' is in luded in `-Wall' and `-Wformat'. It an be disabled with the
`-Wno-nonnull' option.

-Winit-self (C, C++, Obje tive-C and Obje tive-C++ only)

Warn about uninitialized variables whi h are initialized with themselves. Note
this option an only be used with the `-Wuninitialized' option, whi h in turn
only works with `-O1' and above.
For example, GCC will warn about i being uninitialized in the following snippet
only when `-Winit-self' has been spe ied:
int f()
{
int i = i;
return i;
}

-Wimpli it-int

Warn when a de laration does not spe ify a type. This warning is enabled by
`-Wall'.

38

Using the GNU Compiler Colle tion (GCC)

-Wimpli it-fun tion-de laration

-Werror-impli it-fun tion-de laration

Give a warning (or error) whenever a fun tion is used before being de lared.
The form `-Wno-error-impli it-fun tion-de laration' is not supported.
This warning is enabled by `-Wall' (as a warning, not an error).

-Wimpli it

Same as `-Wimpli it-int' and `-Wimpli it-fun tion-de laration'. This

warning is enabled by `-Wall'.

-Wmain

Warn if the type of `main' is suspi ious. `main' should be a fun tion with
external linkage, returning int, taking either zero arguments, two, or three
arguments of appropriate types. This warning is enabled by `-Wall'.

-Wmissing-bra es

Warn if an aggregate or union initializer is not fully bra keted. In the following
example, the initializer for `a' is not fully bra keted, but that for `b' is fully
bra keted.
int a[2[2 = { 0, 1, 2, 3 };
int b[2[2 = { { 0, 1 }, { 2, 3 } };

This warning is enabled by `-Wall'.

-Wmissing-in lude-dirs (C, C++, Obje tive-C and Obje tive-C++ only)

Warn if a user-supplied in lude dire tory does not exist.

-Wparentheses

Warn if parentheses are omitted in ertain ontexts, su h as when there is an

assignment in a ontext where a truth value is expe ted, or when operators are
nested whose pre eden e people often get onfused about. Only the warning
for an assignment used as a truth value is supported when ompiling C++; the
other warnings are only supported when ompiling C.
Also warn if a omparison like `x<=y<=z' appears; this is equivalent to `(x<=y
? 1 : 0) <= z', whi h is a dierent interpretation from that of ordinary mathemati al notation.
Also warn about onstru tions where there may be onfusion to whi h if statement an else bran h belongs. Here is an example of su h a ase:
{

if (a)
if (b)
foo ();
else
bar ();

In C, every else bran h belongs to the innermost possible if statement, whi h

in this example is if (b). This is often not what the programmer expe ted, as
illustrated in the above example by indentation the programmer hose. When
there is the potential for this onfusion, GCC will issue a warning when this ag
is spe ied. To eliminate the warning, add expli it bra es around the innermost
if statement so there is no way the else ould belong to the en losing if. The
resulting ode would look like this:

Chapter 3: GCC Command Options

39

if (a)
{
if (b)
foo ();
else
bar ();
}

This warning is enabled by `-Wall'.

-Wsequen e-point

Warn about ode that may have undened semanti s be ause of violations of
sequen e point rules in the C standard.
The C standard denes the order in whi h expressions in a C program are evaluated in terms of sequen e points, whi h represent a partial ordering between
the exe ution of parts of the program: those exe uted before the sequen e point,
and those exe uted after it. These o ur after the evaluation of a full expression
(one whi h is not part of a larger expression), after the evaluation of the rst
operand of a &&, ||, ? : or , ( omma) operator, before a fun tion is alled (but
after the evaluation of its arguments and the expression denoting the alled
fun tion), and in ertain other pla es. Other than as expressed by the sequen e
point rules, the order of evaluation of subexpressions of an expression is not
spe ied. All these rules des ribe only a partial order rather than a total order,
sin e, for example, if two fun tions are alled within one expression with no
sequen e point between them, the order in whi h the fun tions are alled is not
spe ied. However, the standards ommittee have ruled that fun tion alls do
not overlap.
It is not spe ied when between sequen e points modi ations to the values of
obje ts take ee t. Programs whose behavior depends on this have undened
behavior; the C standard spe ies that \Between the previous and next sequen e point an obje t shall have its stored value modied at most on e by the
evaluation of an expression. Furthermore, the prior value shall be read only to
determine the value to be stored.". If a program breaks these rules, the results
on any parti ular implementation are entirely unpredi table.
Examples of ode with undened behavior are a = a++;, a[n = b[n++ and
a[i++ = i;. Some more ompli ated ases are not diagnosed by this option,
and it may give an o asional false positive result, but in general it has been
found fairly ee tive at dete ting this sort of problem in programs.
The present implementation of this option only works for C programs. A future
implementation may also work for C++ programs.
The C standard is worded onfusingly, therefore there is some debate over the
pre ise meaning of the sequen e point rules in subtle ases. Links to dis ussions
of the problem, in luding proposed formal denitions, may be found on the GCC
readings page, at http://g .gnu.org/readings.html.
This warning is enabled by `-Wall'.

40

Using the GNU Compiler Colle tion (GCC)

-Wreturn-type

Warn whenever a fun tion is dened with a return-type that defaults to int.
Also warn about any return statement with no return-value in a fun tion whose
return-type is not void.
For C, also warn if the return type of a fun tion has a type qualier su h
as onst. Su h a type qualier has no ee t, sin e the value returned by
a fun tion is not an lvalue. ISO C prohibits qualied void return types on
fun tion denitions, so su h return types always re eive a warning even without
this option.
For C++, a fun tion without return type always produ es a diagnosti message,
even when `-Wno-return-type' is spe ied. The only ex eptions are `main' and
fun tions dened in system headers.
This warning is enabled by `-Wall'.
-Wswit h Warn whenever a swit h statement has an index of enumerated type and la ks
a ase for one or more of the named odes of that enumeration. (The presen e
of a default label prevents this warning.) ase labels outside the enumeration
range also provoke warnings when this option is used. This warning is enabled
by `-Wall'.
-Wswit h-default

Warn whenever a swit h statement does not have a default ase.

-Wswit h-enum

Warn whenever a swit h statement has an index of enumerated type and la ks

a ase for one or more of the named odes of that enumeration. ase labels
outside the enumeration range also provoke warnings when this option is used.

-Wtrigraphs

Warn if any trigraphs are en ountered that might hange the meaning of the
program (trigraphs within omments are not warned about). This warning is
enabled by `-Wall'.

-Wunused-fun tion

Warn whenever a stati fun tion is de lared but not dened or a non\-inline
stati fun tion is unused. This warning is enabled by `-Wall'.

-Wunused-label

Warn whenever a label is de lared but not used. This warning is enabled by
`-Wall'.
To suppress this warning use the `unused' attribute (see Se tion 5.31 [Variable
Attributes, page 233).

-Wunused-parameter

Warn whenever a fun tion parameter is unused aside from its de laration.
To suppress this warning use the `unused' attribute (see Se tion 5.31 [Variable
Attributes, page 233).

-Wunused-variable

Warn whenever a lo al variable or non- onstant stati variable is unused aside

from its de laration This warning is enabled by `-Wall'.

Chapter 3: GCC Command Options

41

To suppress this warning use the `unused' attribute (see Se tion 5.31 [Variable
Attributes, page 233).
-Wunused-value

Warn whenever a statement omputes a result that is expli itly not used. This
warning is enabled by `-Wall'.
To suppress this warning ast the expression to `void'.
-Wunused All the above `-Wunused' options ombined.
In order to get a warning about an unused fun tion parameter, you must either
spe ify `-Wextra -Wunused' (note that `-Wall' implies `-Wunused'), or separately spe ify `-Wunused-parameter'.

-Wuninitialized

Warn if an automati variable is used without rst being initialized or if a

variable may be lobbered by a setjmp all.
These warnings are possible only in optimizing ompilation, be ause they require data ow information that is omputed only when optimizing. If you
don't spe ify `-O', you simply won't get these warnings.
If you want to warn about ode whi h uses the uninitialized value of the variable
in its own initializer, use the `-Winit-self' option.
These warnings o ur only for variables that are andidates for register allo ation. Therefore, they do not o ur for a variable that is de lared volatile, or
whose address is taken, or whose size is other than 1, 2, 4 or 8 bytes. Also, they
do not o ur for stru tures, unions or arrays, even when they are in registers.
Note that there may be no warning about a variable that is used only to ompute
a value that itself is never used, be ause su h omputations may be deleted by
data ow analysis before the warnings are printed.
These warnings are made optional be ause GCC is not smart enough to see all
the reasons why the ode might be orre t despite appearing to have an error.
Here is one example of how this an happen:
{

int x;
swit h (y)
{
ase 1: x = 1;
break;
ase 2: x = 4;
break;
ase 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 ommon ase:
{

int save_y;
if ( hange_y) save_y = y, y = new_y;
...
if ( hange_y) y = save_y;

42

Using the GNU Compiler Colle tion (GCC)

This has no bug be ause save_y is used only if it is set.

This option also warns when a non-volatile automati variable might be hanged
by a all to longjmp. These warnings as well are possible only in optimizing
ompilation.
The ompiler sees only the alls to setjmp. It annot know where longjmp will
be alled; in fa t, a signal handler ould all it at any point in the ode. As a
result, you may get a warning even when there is in fa t no problem be ause
longjmp annot in fa t be alled at the pla e whi h would ause a problem.
Some spurious warnings an be avoided if you de lare all the fun tions you
use that never return as noreturn. See Se tion 5.24 [Fun tion Attributes,
page 217.
This warning is enabled by `-Wall'.
-Wunknown-pragmas

Warn when a #pragma dire tive is en ountered whi h is not understood by

GCC. If this ommand line option is used, warnings will even be issued for
unknown pragmas in system header les. This is not the ase if the warnings
were only enabled by the `-Wall' ommand line option.

-Wstri t-aliasing

This option is only a tive when `-fstri t-aliasing' is a tive. It warns about
ode whi h might break the stri t aliasing rules that the ompiler is using for
optimization. The warning does not at h all ases, but does attempt to at h
the more ommon pitfalls. It is in luded in `-Wall'.

-Wstri t-aliasing=2

This option is only a tive when `-fstri t-aliasing' is a tive. It warns about
all ode whi h might break the stri t aliasing rules that the ompiler is using
for optimization. This warning at hes all ases, but it will also give a warning
for some ambiguous ases that are safe.
-Wall
All of the above `-W' options ombined. This enables all the warnings about
onstru tions that some users onsider questionable, and that are easy to avoid
(or modify to prevent the warning), even in onjun tion with ma ros. This
also enables some language-spe i warnings des ribed in Se tion 3.5 [C++ Diale t Options, page 24 and Se tion 3.6 [Obje tive-C and Obje tive-C++ Diale t
Options, page 31.
The following `-W...' options are not implied by `-Wall'. Some of them warn about
onstru tions that users generally do not onsider questionable, but whi h o asionally you
might wish to he k for; others warn about onstru tions that are ne essary or hard to
avoid in some ases, and there is no simple way to modify the ode to suppress the warning.
-Wextra (This option used to be alled `-W'. The older name is still supported, but the
newer name is more des riptive.) Print extra warning messages for these events:
 A fun tion an return either with or without a value. (Falling o the end of
the fun tion body is onsidered returning without a value.) For example,
this fun tion would evoke su h a warning:

Chapter 3: GCC Command Options



















43

foo (a)
{
if (a > 0)
return a;
}

An expression-statement or the left-hand side of a omma expression ontains no side ee ts. To suppress the warning, ast the unused expression
to void. For example, an expression su h as `x[i,j' will ause a warning,
but `x[(void)i,j' will not.
An unsigned value is ompared against zero with `<' or `>='.
Storage- lass spe iers like stati are not the rst things in a de laration.
A ording to the C Standard, this usage is obsoles ent.
If `-Wall' or `-Wunused' is also spe ied, warn about unused arguments.
A omparison between signed and unsigned values ould produ e an in orre t result when the signed value is onverted to unsigned. (But don't
warn if `-Wno-sign- ompare' is also spe ied.)
An aggregate has an initializer whi h does not initialize all
members.
This warning an be independently ontrolled by
`-Wmissing-field-initializers'.
A fun tion parameter is de lared without a type spe ier in K&R-style
fun tions:
void foo(bar) { }

An empty body o urs in an `if' or `else' statement.

A pointer is ompared against integer zero with `<', `<=', `>', or `>='.
A variable might be hanged by `longjmp' or `vfork'.
Any of several oating-point events that often indi ate errors, su h as over ow, under ow, loss of pre ision, et .
(C++ only) An enumerator and a non-enumerator both appear in a onditional expression.
(C++ only) A non-stati referen e or non-stati ` onst' member appears in
a lass without onstru tors.
(C++ only) Ambiguous virtual bases.
(C++ only) Subs ripting an array whi h has been de lared `register'.
(C++ only) Taking the address of a variable whi h has been de lared
`register'.
(C++ only) A base lass is not initialized in a derived lass' opy onstru tor.

-Wno-div-by-zero

Do not warn about ompile-time integer division by zero. Floating point division by zero is not warned about, as it an be a legitimate way of obtaining
innities and NaNs.

-Wsystem-headers

Print warning messages for onstru ts found in system header les. Warnings
from system headers are normally suppressed, on the assumption that they

44

Using the GNU Compiler Colle tion (GCC)

usually do not indi ate real problems and would only make the ompiler output
harder to read. Using this ommand line option tells GCC to emit warnings
from system headers as if they o urred in user ode. However, note that using
`-Wall' in onjun tion with this option will not warn about unknown pragmas
in system headers|for that, `-Wunknown-pragmas' must also be used.
-Wfloat-equal

Warn if oating point values are used in equality omparisons.

The idea behind this is that sometimes it is onvenient (for the programmer)
to onsider oating-point values as approximations to innitely pre ise real
numbers. If you are doing this, then you need to ompute (by analyzing the
ode, or in some other way) the maximum or likely maximum error that the
omputation introdu es, and allow for it when performing omparisons (and
when produ ing output, but that's a dierent problem). In parti ular, instead
of testing for equality, you would he k to see whether the two values have
ranges that overlap; and this is done with the relational operators, so equality
omparisons are probably mistaken.
-Wtraditional (C only)
Warn about ertain onstru ts that behave dierently in traditional and ISO
C. Also warn about ISO C onstru ts that have no traditional C equivalent,
and/or problemati onstru ts whi h should be avoided.
 Ma ro parameters that appear within string literals in the ma ro body. In
traditional C ma ro repla ement takes pla e within string literals, but does
not in ISO C.
 In traditional C, some prepro essor dire tives did not exist. Traditional
prepro essors would only onsider a line to be a dire tive if the `#' appeared
in olumn 1 on the line. Therefore `-Wtraditional' warns about dire tives
that traditional C understands but would ignore be ause the `#' does not
appear as the rst hara ter on the line. It also suggests you hide dire tives
like `#pragma' not understood by traditional C by indenting them. Some
traditional implementations would not re ognize `#elif', so it suggests
avoiding it altogether.
 A fun tion-like ma ro that appears without arguments.
 The unary plus operator.
 The `U' integer onstant sux, or the `F' or `L' oating point onstant
suxes. (Traditional C does support the `L' sux on integer onstants.)
Note, these suxes appear in ma ros dened in the system headers of most
modern systems, e.g. the `_MIN'/`_MAX' ma ros in <limits.h>. Use of these
ma ros in user ode might normally lead to spurious warnings, however
GCC's integrated prepro essor has enough ontext to avoid warning in
these ases.
 A fun tion de lared external in one blo k and then used after the end of
the blo k.
 A swit h statement has an operand of type long.
 A non-stati fun tion de laration follows a stati one. This onstru t
is not a epted by some traditional C ompilers.

Chapter 3: GCC Command Options









45

The ISO type of an integer onstant has a dierent width or signedness

from its traditional type. This warning is only issued if the base of the
onstant is ten. I.e. hexade imal or o tal values, whi h typi ally represent
bit patterns, are not warned about.
Usage of ISO string on atenation is dete ted.
Initialization of automati aggregates.
Identier on i ts with labels. Traditional C la ks a separate namespa e
for labels.
Initialization of unions. If the initializer is zero, the warning is omitted.
This is done under the assumption that the zero initializer in user ode
appears onditioned on e.g. __STDC__ to avoid missing initializer warnings
and relies on default initialization to zero in the traditional C ase.
Conversions by prototypes between xed/ oating point values and vi e
versa. The absen e of these prototypes when ompiling with traditional C
would ause serious problems. This is a subset of the possible onversion
warnings, for the full set use `-W onversion'.
Use of ISO C style fun tion denitions. This warning intentionally is not
issued for prototype de larations or variadi fun tions be ause these ISO
C features will appear in your ode when using libiberty's traditional C
ompatibility ma ros, PARAMS and VPARAMS. This warning is also bypassed
for nested fun tions be ause that feature is already a GCC extension and
thus not relevant to traditional C ompatibility.

-Wde laration-after-statement (C only)

Warn when a de laration is found after a statement in a blo k. This onstru t,

known from C++, was introdu ed with ISO C99 and is by default allowed in
GCC. It is not supported by ISO C90 and was not supported by GCC versions
before GCC 3.0. See Se tion 5.23 [Mixed De larations, page 217.

-Wundef

Warn if an undened identier is evaluated in an `#if' dire tive.

-Wno-endif-labels

Do not warn whenever an `#else' or an `#endif' are followed by text.

-Wshadow Warn whenever a lo al variable shadows another lo al variable, parameter or

global variable or whenever a built-in fun tion is shadowed.

-Wlarger-than-len

Warn whenever an obje t of larger than len bytes is dened.

-Wpointer-arith

Warn about anything that depends on the \size of" a fun tion type or of void.
GNU C assigns these types a size of 1, for onvenien e in al ulations with void
* pointers and pointers to fun tions.

-Wbad-fun tion- ast (C only)

Warn whenever a fun tion all is ast to a non-mat hing type. For example,
warn if int mallo () is ast to anything *.

46

Using the GNU Compiler Colle tion (GCC)

-W ast-qual

Warn whenever a pointer is ast so as to remove a type qualier from the target
type. For example, warn if a onst har * is ast to an ordinary har *.

-W ast-align

Warn whenever a pointer is ast su h that the required alignment of the target
is in reased. For example, warn if a har * is ast to an int * on ma hines
where integers an only be a essed at two- or four-byte boundaries.

-Wwrite-strings

When ompiling C, give string onstants the type onst har[length so that
opying the address of one into a non- onst har * pointer will get a warning;
when ompiling C++, warn about the depre ated onversion from string onstants to har *. These warnings will help you nd at ompile time ode that
an try to write into a string onstant, but only if you have been very areful
about using onst in de larations and prototypes. Otherwise, it will just be a
nuisan e; this is why we did not make `-Wall' request these warnings.

-W onversion

Warn if a prototype auses a type onversion that is dierent from what would
happen to the same argument in the absen e of a prototype. This in ludes
onversions of xed point to oating and vi e versa, and onversions hanging
the width or signedness of a xed point argument ex ept when the same as the
default promotion.
Also, warn if a negative integer onstant expression is impli itly onverted to an
unsigned type. For example, warn about the assignment x = -1 if x is unsigned.
But do not warn about expli it asts like (unsigned) -1.

-Wsign- ompare

Warn when a omparison between signed and unsigned values ould produ e an
in orre t result when the signed value is onverted to unsigned. This warning
is also enabled by `-Wextra'; to get the other warnings of `-Wextra' without
this warning, use `-Wextra -Wno-sign- ompare'.

-Waggregate-return

Warn if any fun tions that return stru tures or unions are dened or alled. (In
languages where you an return an array, this also eli its a warning.)

-Wstri t-prototypes (C only)

Warn if a fun tion is de lared or dened without spe ifying the argument types.
(An old-style fun tion denition is permitted without a warning if pre eded by
a de laration whi h spe ies the argument types.)

-Wold-style-definition (C only)

Warn if an old-style fun tion denition is used. A warning is given even if there
is a previous prototype.

-Wmissing-prototypes (C only)

Warn if a global fun tion is dened without a previous prototype de laration.

This warning is issued even if the denition itself provides a prototype. The
aim is to dete t global fun tions that fail to be de lared in header les.

Chapter 3: GCC Command Options

47

-Wmissing-de larations (C only)

Warn if a global fun tion is dened without a previous de laration. Do so even

if the denition itself provides a prototype. Use this option to dete t global
fun tions that are not de lared in header les.

-Wmissing-field-initializers

Warn if a stru ture's initializer has some elds missing. For example, the following ode would ause su h a warning, be ause x.h is impli itly zero:
stru t s { int f, g, h; };
stru t s x = { 3, 4 };

This option does not warn about designated initializers, so the following modi ation would not trigger a warning:
stru t s { int f, g, h; };
stru t s x = { .f = 3, .g = 4 };

This warning is in luded in `-Wextra'. To get other `-Wextra' warnings without

this one, use `-Wextra -Wno-missing-field-initializers'.
-Wmissing-noreturn

Warn about fun tions whi h might be andidates for attribute noreturn. Note
these are only possible andidates, not absolute ones. Care should be taken
to manually verify fun tions a tually do not ever return before adding the
noreturn attribute, otherwise subtle ode generation bugs ould be introdu ed.
You will not get a warning for main in hosted C environments.

-Wmissing-format-attribute
If `-Wformat' is enabled, also warn about fun tions whi h might be andidates
for format attributes. Note these are only possible andidates, not absolute
ones. GCC will guess that format attributes might be appropriate for any
fun tion that alls a fun tion like vprintf or vs anf, but this might not always
be the ase, and some fun tions for whi h format attributes are appropriate
may not be dete ted. This option has no ee t unless `-Wformat' is enabled
(possibly by `-Wall').
-Wno-multi har

Do not warn if a multi hara ter onstant (`'FOOF'') is used. Usually they
indi ate a typo in the user's ode, as they have implementation-dened values,
and should not be used in portable ode.

-Wno-depre ated-de larations

Do not warn about uses of fun tions, variables, and types marked as depre ated
by using the depre ated attribute. (see Se tion 5.24 [Fun tion Attributes,
page 217, see Se tion 5.31 [Variable Attributes, page 233, see Se tion 5.32
[Type Attributes, page 238.)

-Wpa ked Warn if a stru ture is given the pa ked attribute, but the pa ked attribute has

no ee t on the layout or size of the stru ture. Su h stru tures may be misaligned for little benet. For instan e, in this ode, the variable f.x in stru t
bar will be misaligned even though stru t bar does not itself have the pa ked
attribute:

48

Using the GNU Compiler Colle tion (GCC)

stru t foo {
int x;
har a, b, , d;
} __attribute__((pa ked));
stru t bar {
har z;
stru t foo f;
};

-Wpadded Warn if padding is in luded in a stru ture, either to align an element of the

stru ture or to align the whole stru ture. Sometimes when this happens it is
possible to rearrange the elds of the stru ture to redu e the padding and so
make the stru ture smaller.

-Wredundant-de ls

Warn if anything is de lared more than on e in the same s ope, even in ases
where multiple de laration is valid and hanges nothing.
-Wnested-externs (C only)
Warn if an extern de laration is en ountered within a fun tion.
-Wunrea hable- ode

Warn if the ompiler dete ts that ode will never be exe uted.
This option is intended to warn when the ompiler dete ts that at least a whole
line of sour e ode will never be exe uted, be ause some ondition is never
satised or be ause it is after a pro edure that never returns.
It is possible for this option to produ e a warning even though there are ir umstan es under whi h part of the ae ted line an be exe uted, so are should
be taken when removing apparently-unrea hable ode.
For instan e, when a fun tion is inlined, a warning may mean that the line is
unrea hable in only one inlined opy of the fun tion.
This option is not made part of `-Wall' be ause in a debugging version of a
program there is often substantial ode whi h he ks orre t fun tioning of the
program and is, hopefully, unrea hable be ause the program does work. Another ommon use of unrea hable ode is to provide behavior whi h is sele table
at ompile-time.
-Winline Warn if a fun tion an not be inlined and it was de lared as inline. Even with
this option, the ompiler will not warn about failures to inline fun tions de lared
in system headers.
The ompiler uses a variety of heuristi s to determine whether or not to inline a
fun tion. For example, the ompiler takes into a ount the size of the fun tion
being inlined and the amount of inlining that has already been done in the urrent fun tion. Therefore, seemingly insigni ant hanges in the sour e program
an ause the warnings produ ed by `-Winline' to appear or disappear.
-Wno-invalid-offsetof (C++ only)
Suppress warnings from applying the `offsetof' ma ro to a non-POD type.
A ording to the 1998 ISO C++ standard, applying `offsetof' to a non-POD
type is undened. In existing C++ implementations, however, `offsetof' typi ally gives meaningful results even when applied to ertain kinds of non-POD

Chapter 3: GCC Command Options

49

types. (Su h as a simple `stru t' that fails to be a POD type only by virtue of
having a onstru tor.) This ag is for users who are aware that they are writing nonportable ode and who have deliberately hosen to ignore the warning
about it.
The restri tions on `offsetof' may be relaxed in a future version of the C++
standard.
-Winvalid-p h

Warn if a pre ompiled header (see Se tion 3.20 [Pre ompiled Headers,
page 187) is found in the sear h path but an't be used.

-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 a ount only when `-pedanti ' ag is used.

-Wvariadi -ma ros

Warn if variadi ma ros are used in pedanti ISO C90 mode, or the GNU
alternate syntax when in pedanti ISO C99 mode. This is default. To inhibit
the warning messages, use `-Wno-variadi -ma ros'.

-Wdisabled-optimization

Warn if a requested optimization pass is disabled. This warning does not generally indi ate that there is anything wrong with your ode; it merely indi ates
that GCC's optimizers were unable to handle the ode ee tively. Often, the
problem is that your ode is too big or too omplex; GCC will refuse to optimize
programs when the optimization itself is likely to take inordinate amounts of
time.

-Wno-pointer-sign

-Werror

Don't warn for pointer argument passing or assignment with dierent signedness. Only useful in the negative form sin e this warning is enabled by default.
This option is only supported for C and Obje tive-C.
Make all warnings into errors.

3.9 Options for Debugging Your Program or GCC

GCC has various spe ial options that are used for debugging either your program or GCC:
-g
Produ e debugging information in the operating system's native format (stabs,
COFF, XCOFF, or DWARF 2). GDB an work with this debugging information.
On most systems that use stabs format, `-g' enables use of extra debugging
information that only GDB an use; this extra information makes debugging
work better in GDB but will probably make other debuggers rash or refuse to
read the program. If you want to ontrol for ertain whether to generate the
extra information, use `-gstabs+', `-gstabs', `-gx off+', `-gx off', or `-gvms'
(see below).
GCC allows you to use `-g' with `-O'. The short uts taken by optimized ode
may o asionally produ e surprising results: some variables you de lared may

50

Using the GNU Compiler Colle tion (GCC)

not exist at all; ow of ontrol may brie y move where you did not expe t it;
some statements may not be exe uted be ause they ompute onstant results
or their values were already at hand; some statements may exe ute in dierent
pla es be ause they were moved out of loops.
Nevertheless it proves possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs.
The following options are useful when GCC is generated with the apability for
more than one debugging format.
-ggdb

Produ e debugging information for use by GDB. This means to use the most
expressive format available (DWARF 2, stabs, or the native format if neither
of those are supported), in luding GDB extensions if at all possible.

-gstabs

Produ e debugging information in stabs format (if that is supported), without

GDB extensions. This is the format used by DBX on most BSD systems.
On MIPS, Alpha and System V Release 4 systems this option produ es stabs
debugging output whi h is not understood by DBX or SDB. On System V
Release 4 systems this option requires the GNU assembler.

-feliminate-unused-debug-symbols

Produ e debugging information in stabs format (if that is supported), for only
symbols that are a tually used.

-gstabs+ Produ e debugging information in stabs format (if that is supported), using

GNU extensions understood only by the GNU debugger (GDB). The use of
these extensions is likely to make other debuggers rash or refuse to read the
program.

-g off

Produ e debugging information in COFF format (if that is supported). This is

the format used by SDB on most System V systems prior to System V Release
4.

-gx off

Produ e debugging information in XCOFF format (if that is supported). This

is the format used by the DBX debugger on IBM RS/6000 systems.

-gx off+ Produ e debugging information in XCOFF format (if that is supported), using

GNU extensions understood only by the GNU debugger (GDB). The use of
these extensions is likely to make other debuggers rash or refuse to read the
program, and may ause assemblers other than the GNU assembler (GAS) to
fail with an error.

-gdwarf-2

-gvms

Produ e debugging information in DWARF version 2 format (if that is supported). This is the format used by DBX on IRIX 6. With this option, GCC
uses features of DWARF version 3 when they are useful; version 3 is upward
ompatible with version 2, but may still ause problems for older debuggers.
Produ e debugging information in VMS debug format (if that is supported).
This is the format used by DEBUG on VMS systems.

Chapter 3: GCC Command Options

51

-glevel
-ggdblevel
-gstabslevel
-g offlevel
-gx offlevel
-gvmslevel

Request debugging information and also use level to spe ify how mu h information. The default level is 2.
Level 1 produ es minimal information, enough for making ba ktra es in parts
of the program that you don't plan to debug. This in ludes des riptions of
fun tions and external variables, but no information about lo al variables and
no line numbers.
Level 3 in ludes extra information, su h as all the ma ro denitions present in
the program. Some debuggers support ma ro expansion when you use `-g3'.
`-gdwarf-2' does not a ept a on atenated debug level, be ause GCC used
to support an option `-gdwarf' that meant to generate debug information in
version 1 of the DWARF format (whi h is very dierent from version 2), and
it would have been too onfusing. That debug format is long obsolete, but the
option annot be hanged now. Instead use an additional `-glevel ' option to
hange the debug level for DWARF2.

-feliminate-dwarf2-dups

Compress DWARF2 debugging information by eliminating dupli ated information about ea h symbol. This option only makes sense when generating
DWARF2 debugging information with `-gdwarf-2'.

-p

Generate extra ode to write prole information suitable for the analysis program prof. You must use this option when ompiling the sour e les you want
data about, and you must also use it when linking.

-pg

Generate extra ode to write prole information suitable for the analysis program gprof. You must use this option when ompiling the sour e les you want
data about, and you must also use it when linking.

-Q

Makes the ompiler print out ea h fun tion name as it is ompiled, and print
some statisti s about ea h pass when it nishes.

-ftime-report

Makes the ompiler print some statisti s about the time onsumed by ea h pass
when it nishes.

-fmem-report

Makes the ompiler print some statisti s about permanent memory allo ation
when it nishes.

-fprofile-ar s

Add ode so that program ow ar s are instrumented. During exe ution the
program re ords how many times ea h bran h and all is exe uted and how
many times it is taken or returns. When the ompiled program exits it saves
this data to a le alled `auxname.g da' for ea h sour e le. The data may be

52

Using the GNU Compiler Colle tion (GCC)

used for prole-dire ted optimizations (`-fbran h-probabilities'), or for test
overage analysis (`-ftest- overage'). Ea h obje t le's auxname is generated
from the name of the output le, if expli itly spe ied and it is not the nal
exe utable, otherwise it is the basename of the sour e le. In both ases any
sux is removed (e.g. `foo.g da' for input le `dir/foo. ', or `dir/foo.g da'
for output le spe ied as `-o dir/foo.o').

Compile the sour e les with `-fprofile-ar s' plus optimization and
ode generation options. For test overage analysis, use the additional
`-ftest- overage' option. You do not need to prole every sour e le in
a program.

Link your obje t les with `-lg ov' or `-fprofile-ar s' (the latter implies
the former).

Run the program on a representative workload to generate the ar prole

information. This may be repeated any number of times. You an run
on urrent instan es of your program, and provided that the le system
supports lo king, the data les will be orre tly updated. Also fork alls
are dete ted and orre tly handled (double ounting will not happen).

For prole-dire ted optimizations, ompile the sour e les again
with the same optimization and ode generation options plus
`-fbran h-probabilities' (see Se tion 3.10 [Options that Control
Optimization, page 61).

For test overage analysis, use g ov to produ e human readable information

from the `.g no' and `.g da' les. Refer to the g ov do umentation for
further information.

With `-fprofile-ar s', for ea h fun tion of your program GCC reates a
program ow graph, then nds a spanning tree for the graph. Only ar s that
are not on the spanning tree have to be instrumented: the ompiler adds ode
to ount the number of times that these ar s are exe uted. When an ar is
the only exit or only entran e to a blo k, the instrumentation ode an be
added to the blo k; otherwise, a new basi blo k must be reated to hold the
instrumentation ode.
-ftree-based-profiling

This option is used in addition to `-fprofile-ar s' or `-fbran h-probabilities'

to ontrol whether those optimizations are performed on a tree-based or
rtl-based internal representation. If you use this option when ompiling
with `-fprofile-ar s', you must also use it when ompiling later with
`-fbran h-probabilities'. Currently the tree-based optimization is in an
early stage of development, and this option is re ommended only for those
people working on improving it.

Chapter 3: GCC Command Options

53

-ftest- overage

Produ e a notes le that the g ov ode- overage utility (see Chapter 9 [g ov|a
Test Coverage Program, page 355) an use to show program overage. Ea h
sour e le's note le is alled `auxname.g no'. Refer to the `-fprofile-ar s'
option above for a des ription of auxname and instru tions on how to generate
test overage data. Coverage data will mat h the sour e les more losely, if
you do not optimize.

-dletters
-fdump-rtl-pass

Says to make debugging dumps during ompilation at times spe ied by letters.

This is used for debugging the RTL-based passes of the ompiler. The le names
for most of the dumps are made by appending a pass number and a word to
the dumpname. dumpname is generated from the name of the output le, if
expli itly spe ied and it is not an exe utable, otherwise it is the basename of
the sour e le.
Most debug dumps an be enabled either passing a letter to the `-d' option, or
with a long `-fdump-rtl' swit h; here are the possible letters for use in letters
and pass, and their meanings:
-dA
Annotate the assembler output with mis ellaneous debugging information.
-db
-fdump-rtl-bp

Dump after omputing bran h probabilities, to `file.09.bp'.

-dB
-fdump-rtl-bbro

Dump after blo k reordering, to `file.30.bbro'.

-d
-fdump-rtl- ombine

Dump after instru tion ombination, to the le `file.17. ombine'.

-dC
-fdump-rtl- e1
-fdump-rtl- e2
`-dC' and `-fdump-rtl- e1' enable dumping after the rst if
onversion, to the le `file.11. e1'. `-dC' and `-fdump-rtl- e2'

enable dumping after the se ond if onversion, to the le

`file.18. e2'.

-dd
-fdump-rtl-btl
-fdump-rtl-dbr
`-dd' and `-fdump-rtl-btl' enable dumping after bran h target
load optimization, to `file.31.btl'. `-dd' and `-fdump-rtl-dbr'
enable dumping after delayed bran h s heduling, to `file.36.dbr'.
-dD

Dump all ma ro denitions, at the end of prepro essing, in addition

to normal output.

54

Using the GNU Compiler Colle tion (GCC)

-dE
-fdump-rtl- e3

Dump after the third if onversion, to `file.28. e3'.

-df
-fdump-rtl- fg
-fdump-rtl-life
`-df' and `-fdump-rtl- fg' enable dumping after ontrol and data
ow analysis, to `file.08. fg'. `-df' and `-fdump-rtl- fg' enable dumping dump after life analysis, to `file.16.life'.
-dg
-fdump-rtl-greg

Dump after global register allo ation, to `file.23.greg'.

-dG
-fdump-rtl-g se
-fdump-rtl-bypass
`-dG' and `-fdump-rtl-g se' enable dumping after GCSE,
to `file.05.g se'.
`-dG' and `-fdump-rtl-bypass' enable

dumping after jump bypassing and ontrol ow optimizations, to

`file.07.bypass'.

-dh
-fdump-rtl-eh

Dump after nalization of EH handling ode, to `file.02.eh'.

-di
-fdump-rtl-sibling

Dump after sibling all optimizations, to `file.01.sibling'.

-dj
-fdump-rtl-jump

Dump after the rst jump optimization, to `file.03.jump'.

-dk
-fdump-rtl-sta k

Dump after onversion from registers to sta k, to `file.33.sta k'.

-dl
-fdump-rtl-lreg

Dump after lo al register allo ation, to `file.22.lreg'.

-dL
-fdump-rtl-loop
-fdump-rtl-loop2
`-dL' and

`-fdump-rtl-loop' enable dumping after the

rst loop optimization pass, to `file.06.loop'. `-dL' and
`-fdump-rtl-loop2' enable dumping after the se ond pass, to
`file.13.loop2'.

Chapter 3: GCC Command Options

55

-dm
-fdump-rtl-sms

Dump after modulo s heduling, to `file.20.sms'.

-dM
-fdump-rtl-ma h

Dump after performing the ma hine dependent reorganization pass,

to `file.35.ma h'.

-dn
-fdump-rtl-rnreg

Dump after register renumbering, to `file.29.rnreg'.

-dN
-fdump-rtl-regmove

Dump after the register move pass, to `file.19.regmove'.

-do
-fdump-rtl-postreload

Dump after post-reload optimizations, to `file.24.postreload'.

-dr
-fdump-rtl-expand

Dump after RTL generation, to `file.00.expand'.

-dR
-fdump-rtl-s hed2

Dump after the se ond s heduling pass, to `file.32.s hed2'.

-ds
-fdump-rtl- se

Dump after CSE (in luding the jump optimization that sometimes
follows CSE), to `file.04. se'.

-dS
-fdump-rtl-s hed

Dump after the rst s heduling pass, to `file.21.s hed'.

-dt
-fdump-rtl- se2

Dump after the se ond CSE pass (in luding the jump optimization
that sometimes follows CSE), to `file.15. se2'.

-dT
-fdump-rtl-tra er

Dump after running tra er, to `file.12.tra er'.

-dV
-fdump-rtl-vpt
-fdump-rtl-vartra k
`-dV' and

`-fdump-rtl-vpt' enable dumping after the

value prole transformations, to `file.10.vpt'. `-dV' and
`-fdump-rtl-vartra k' enable dumping after variable tra king,
to `file.34.vartra k'.

56

Using the GNU Compiler Colle tion (GCC)

-dw
-fdump-rtl-flow2

Dump after the se ond ow pass, to `file.26.flow2'.

-dz
-fdump-rtl-peephole2

Dump after the peephole pass, to `file.27.peephole2'.

-dZ
-fdump-rtl-web

Dump after live range splitting, to `file.14.web'.

-da
-fdump-rtl-all

Produ e all the dumps listed above.

-dH

Produ e a ore dump whenever an error o urs.

-dm

Print statisti s on memory usage, at the end of the run, to standard

error.

-dp

Annotate the assembler output with a omment indi ating whi h

pattern and alternative was used. The length of ea h instru tion is
also printed.

-dP

Dump the RTL in the assembler output as a omment before ea h

instru tion. Also turns on `-dp' annotation.

-dv

For ea h of the other indi ated dump les (either with `-d' or
`-fdump-rtl-pass '), dump a representation of the ontrol ow
graph suitable for viewing with VCG to `file.pass.v g'.

-dx

Just generate RTL for a fun tion instead of ompiling it. Usually
used with `r' (`-fdump-rtl-expand').

-dy

Dump debugging information during parsing, to standard error.

-fdump-unnumbered

When doing debugging dumps (see `-d' option above), suppress instru tion
numbers and line number note output. This makes it more feasible to use
di on debugging dumps for ompiler invo ations with dierent options, in
parti ular with and without `-g'.

-fdump-translation-unit (C and C++ only)

-fdump-translation-unit-options (C and C++ only)

Dump a representation of the tree stru ture for the entire translation unit to a
le. The le name is made by appending `.tu' to the sour e le name. If the
`-options ' form is used, options ontrols the details of the dump as des ribed
for the `-fdump-tree' options.

-fdump- lass-hierar hy (C++ only)

-fdump- lass-hierar hy-options (C++ only)

Dump a representation of ea h lass's hierar hy and virtual fun tion table layout
to a le. The le name is made by appending `. lass' to the sour e le name.

Chapter 3: GCC Command Options

57

If the `-options ' form is used, options ontrols the details of the dump as
des ribed for the `-fdump-tree' options.
-fdump-ipa-swit h

Control the dumping at various stages of inter-pro edural analysis language

tree to a le. The le name is generated by appending a swit h spe i sux
to the sour e le name. The following dumps are possible:

`all'

Enables all inter-pro edural analysis dumps; urrently the only produ ed dump is the ` graph' dump.

` graph'

Dumps information about all-graph optimization, unused fun tion

removal, and inlining de isions.

-fdump-tree-swit h (C and C++ only)

-fdump-tree-swit h -options (C and C++ only)

Control the dumping at various stages of pro essing the intermediate language
tree to a le. The le name is generated by appending a swit h spe i sux
to the sour e le name. If the `-options ' form is used, options is a list of
`-' separated options that ontrol the details of the dump. Not all options are
appli able to all dumps, those whi h are not meaningful will be ignored. The
following options are available
`address' Print the address of ea h node. Usually this is not meaningful as it
hanges a ording to the environment and sour e le. Its primary
use is for tying up a dump le with a debug environment.
`slim'

Inhibit dumping of members of a s ope or body of a fun tion merely

be ause that s ope has been rea hed. Only dump su h items when
they are dire tly rea hable by some other path. When dumping
pretty-printed trees, this option inhibits dumping the bodies of ontrol stru tures.

`raw'

Print a raw representation of the tree. By default, trees are prettyprinted into a C-like representation.

`details' Enable more detailed dumps (not honored by every dump option).
`stats'

Enable dumping various statisti s about the pass (not honored by

every dump option).

`blo ks'

Enable showing basi blo k boundaries (disabled in raw dumps).

`vops'

Enable showing virtual operands for every statement.

`lineno'

Enable showing line numbers for statements.

`uid'

Enable showing the unique ID (DECL_UID) for ea h variable.

`all'

Turn on all options, ex ept `raw', `slim' and `lineno'.

The following tree dumps are possible:

`original'

Dump before any tree based optimization, to `file.original'.

58

Using the GNU Compiler Colle tion (GCC)

`optimized'
Dump after all tree based optimization, to `file.optimized'.
`inlined' Dump after fun tion inlining, to `file.inlined'.
`gimple'

Dump ea h fun tion before and after the gimpli ation pass to a
le. The le name is made by appending `.gimple' to the sour e
le name.

` fg'

Dump the ontrol ow graph of ea h fun tion to a le. The le

name is made by appending `. fg' to the sour e le name.

`v g'

Dump the ontrol ow graph of ea h fun tion to a le in VCG

format. The le name is made by appending `.v g' to the sour e
le name. Note that if the le ontains more than one fun tion, the
generated le annot be used dire tly by VCG. You will need to
ut and paste ea h fun tion's graph into its own separate le rst.

` h'

Dump ea h fun tion after opying loop headers. The le name is

made by appending `. h' to the sour e le name.

`ssa'

Dump SSA related information to a le. The le name is made by

appending `.ssa' to the sour e le name.

`alias'

Dump aliasing information for ea h fun tion. The le name is made

by appending `.alias' to the sour e le name.

` p'

Dump ea h fun tion after CCP. The le name is made by appending `. p' to the sour e le name.

`pre'

Dump trees after partial redundan y elimination. The le name is

made by appending `.pre' to the sour e le name.

`fre'

Dump trees after full redundan y elimination. The le name is

made by appending `.fre' to the sour e le name.

`d e'

Dump ea h fun tion after dead ode elimination. The le name is

made by appending `.d e' to the sour e le name.

`mudflap' Dump ea h fun tion after adding mud ap instrumentation. The

le name is made by appending `.mudflap' to the sour e le name.
`sra'

Dump ea h fun tion after performing s alar repla ement of aggregates. The le name is made by appending `.sra' to the sour e le
name.

`dom'

Dump ea h fun tion after applying dominator tree optimizations.

The le name is made by appending `.dom' to the sour e le name.

`dse'

Dump ea h fun tion after applying dead store elimination. The le

name is made by appending `.dse' to the sour e le name.

`phiopt'

Dump ea h fun tion after optimizing PHI nodes into straightline

ode. The le name is made by appending `.phiopt' to the sour e
le name.

Chapter 3: GCC Command Options

`forwprop'

59

Dump ea h fun tion after forward propagating single use variables.

The le name is made by appending `.forwprop' to the sour e le
name.

` opyrename'
Dump ea h fun tion after applying the opy rename optimization.
The le name is made by appending `. opyrename' to the sour e
le name.
`nrv'

Dump ea h fun tion after applying the named return value optimization on generi trees. The le name is made by appending
`.nrv' to the sour e le name.

`ve t'

Dump ea h fun tion after applying ve torization of loops. The le

name is made by appending `.ve t' to the sour e le name.

`all'

Enable all the available tree dumps with the ags provided in this
option.

-ftree-ve torizer-verbose=n

This option ontrols the amount of debugging output the ve torizer prints.
This information is written to standard error, unless `-fdump-tree-all' or
`-fdump-tree-ve t' is spe ied, in whi h ase it is output to the usual dump
listing le, `.ve t'.

-frandom-seed=string

This option provides a seed that GCC uses when it would otherwise use random
numbers. It is used to generate ertain symbol names that have to be dierent
in every ompiled le. It is also used to pla e unique stamps in overage data
les and the obje t les that produ e them. You an use the `-frandom-seed'
option to produ e reprodu ibly identi al obje t les.
The string should be dierent for every le you ompile.

-fs hed-verbose=n

On targets that use instru tion s heduling, this option ontrols the amount of
debugging output the s heduler prints. This information is written to standard
error, unless `-dS' or `-dR' is spe ied, in whi h ase it is output to the usual
dump listing le, `.s hed' or `.s hed2' respe tively. However for n greater
than nine, the output is always printed to standard error.
For n greater than zero, `-fs hed-verbose' outputs the same information as
`-dRS'. For n greater than one, it also output basi blo k probabilities, detailed ready list information and unit/insn info. For n greater than two, it
in ludes RTL at abort point, ontrol- ow and regions info. And for n over four,
`-fs hed-verbose' also in ludes dependen e info.

-save-temps

Store the usual \temporary" intermediate les permanently; pla e them in the
urrent dire tory and name them based on the sour e le. Thus, ompiling
`foo. ' with `- -save-temps' would produ e les `foo.i' and `foo.s', as well

60

-time

Using the GNU Compiler Colle tion (GCC)

as `foo.o'. This reates a prepro essed `foo.i' output le even though the
ompiler now normally uses an integrated prepro essor.
When used in ombination with the `-x' ommand line option, `-save-temps'
is sensible enough to avoid over writing an input sour e le with the same
extension as an intermediate le. The orresponding intermediate le may be
obtained by renaming the sour e le before using `-save-temps'.
Report the CPU time taken by ea h subpro ess in the ompilation sequen e.
For C sour e les, this is the ompiler proper and assembler (plus the linker if
linking is done). The output looks like this:
# 1 0.12 0.01
# as 0.00 0.01

The rst number on ea h line is the \user time", that is time spent exe uting
the program itself. The se ond number is \system time", time spent exe uting
operating system routines on behalf of the program. Both numbers are in
se onds.
-fvar-tra king

Run variable tra king pass. It omputes where variables are stored at ea h position in ode. Better debugging information is then generated (if the debugging
information format supports this information).
It is enabled by default when ompiling with optimization (`-Os', `-O', `-O2',
...), debugging information (`-g') and the debug info format supports it.

-print-file-name=library

Print the full absolute name of the library le library that would be used when
linking|and don't do anything else. With this option, GCC does not ompile
or link anything; it just prints the le name.

-print-multi-dire tory

Print the dire tory name orresponding to the multilib sele ted by any other
swit hes present in the ommand line. This dire tory is supposed to exist in
GCC_EXEC_PREFIX.

-print-multi-lib

Print the mapping from multilib dire tory names to ompiler swit hes that
enable them. The dire tory name is separated from the swit hes by `;', and
ea h swit h starts with an `' instead of the `-', without spa es between multiple
swit hes. This is supposed to ease shell-pro essing.

-print-prog-name=program
Like `-print-file-name', but sear hes for a program su h as ` pp'.
-print-libg -file-name
Same as `-print-file-name=libg .a'.
This is useful when you use `-nostdlib' or `-nodefaultlibs' but you do want
to link with `libg .a'. You an do
g -nostdlib files ... `g -print-libg -file-name`

-print-sear h-dirs

Print the name of the ongured installation dire tory and a list of program
and library dire tories g will sear h|and don't do anything else.

Chapter 3: GCC Command Options

61

This is useful when g prints the error message `installation problem,

annot exe pp0: No su h file or dire tory'. To resolve this you either
need to put ` pp0' and the other ompiler omponents where g expe ts to
nd them, or you an set the environment variable GCC_EXEC_PREFIX to the dire tory where you installed them. Don't forget the trailing `/'. See Se tion 3.19
[Environment Variables, page 184.
-dumpma hine

Print the ompiler's target ma hine (for example, `i686-p -linux-gnu')|and

don't do anything else.

-dumpversion

Print the ompiler version (for example, `3.0')|and don't do anything else.

-dumpspe s

Print the ompiler's built-in spe s|and don't do anything else. (This is used
when GCC itself is being built.) See Se tion 3.15 [Spe Files, page 101.

-feliminate-unused-debug-types

Normally, when produ ing DWARF2 output, GCC will emit debugging information for all types de lared in a ompilation unit, regardless of whether or not
they are a tually used in that ompilation unit. Sometimes this is useful, su h
as if, in the debugger, you want to ast a value to a type that is not a tually
used in your program (but is de lared). More often, however, this results in
a signi ant amount of wasted spa e. With this option, GCC will avoid produ ing debug symbol output for types that are nowhere used in the sour e le
being ompiled.

3.10 Options That Control Optimization

These options ontrol various sorts of optimizations.
Without any optimization option, the ompiler's goal is to redu e the ost of ompilation
and to make debugging produ e the expe ted results. Statements are independent: if you
stop the program with a breakpoint between statements, you an then assign a new value
to any variable or hange the program ounter to any other statement in the fun tion and
get exa tly the results you would expe t from the sour e ode.
Turning on optimization ags makes the ompiler attempt to improve the performan e
and/or ode size at the expense of ompilation time and possibly the ability to debug the
program.
The ompiler performs optimization based on the knowledge it has of the program. Optimization levels `-O2' and above, in parti ular, enable unit-at-a-time mode, whi h allows
the ompiler to onsider information gained from later fun tions in the le when ompiling
a fun tion. Compiling multiple les at on e to a single output le in unit-at-a-time mode
allows the ompiler to use information gained from all of the les when ompiling ea h of
them.
Not all optimizations are ontrolled dire tly by a ag. Only optimizations that have a
ag are listed.

62

-O
-O1

Using the GNU Compiler Colle tion (GCC)

Optimize. Optimizing ompilation takes somewhat more time, and a lot more
memory for a large fun tion.
With `-O', the ompiler tries to redu e ode size and exe ution time, without
performing any optimizations that take a great deal of ompilation time.
`-O' turns on the following optimization ags:
-fdefer-pop
-fdelayed-bran h
-fguess-bran h-probability
-f prop-registers
-floop-optimize
-fif- onversion
-fif- onversion2
-ftree- p
-ftree-d e
-ftree-dominator-opts
-ftree-dse
-ftree-ter
-ftree-lrs
-ftree-sra
-ftree- opyrename
-ftree-fre
-ftree- h
-fmerge- onstants

-O2

`-O' also turns on `-fomit-frame-pointer' on ma hines where doing so does

not interfere with debugging.
`-O' doesn't turn on `-ftree-sra' for the Ada ompiler. This option must be
expli itly spe ied on the ommand line to be enabled for the Ada ompiler.
Optimize even more. GCC performs nearly all supported optimizations that
do not involve a spa e-speed tradeo. The ompiler does not perform loop
unrolling or fun tion inlining when you spe ify `-O2'. As ompared to `-O', this
option in reases both ompilation time and the performan e of the generated
ode.
`-O2' turns on all optimization ags spe ied by `-O'. It also turns on the
following optimization ags:
-fthread-jumps
-f rossjumping
-foptimize-sibling- alls
-f se-follow-jumps -f se-skip-blo ks
-fg se -fg se-lm
-fexpensive-optimizations
-fstrength-redu e
-frerun- se-after-loop -frerun-loop-opt
-f aller-saves
-ffor e-mem
-fpeephole2
-fs hedule-insns -fs hedule-insns2
-fs hed-interblo k -fs hed-spe
-fregmove
-fstri t-aliasing
-fdelete-null-pointer- he ks
-freorder-blo ks -freorder-fun tions
-funit-at-a-time

Chapter 3: GCC Command Options

63

-falign-fun tions -falign-jumps

-falign-loops -falign-labels
-ftree-pre

Please note the warning under `-fg se' about invoking `-O2' on programs that
use omputed gotos.
-O3

Optimize yet more. `-O3' turns on all optimizations spe ied by `-O2'

and also turns on the `-finline-fun tions', `-funswit h-loops' and
`-fg se-after-reload' options.

-O0

Do not optimize. This is the default.

-Os

Optimize for size. `-Os' enables all `-O2' optimizations that do not typi ally
in rease ode size. It also performs further optimizations designed to redu e
ode size.
`-Os' disables the following optimization ags:
-falign-fun tions -falign-jumps -falign-loops
-falign-labels -freorder-blo ks -freorder-blo ks-and-partition -fprefet hloop-arrays

If you use multiple `-O' options, with or without level numbers, the last su h
option is the one that is ee tive.
Options of the form `-fflag ' spe ify ma hine-independent ags. Most ags have both
positive and negative forms; the negative form of `-ffoo' would be `-fno-foo'. In the table
below, only one of the forms is listed|the one you typi ally will use. You an gure out
the other form by either removing `no-' or adding it.
The following options ontrol spe i optimizations. They are either a tivated by `-O'
options or are related to ones that are. You an use the following ags in the rare ases
when \ne-tuning" of optimizations to be performed is desired.
-fno-default-inline

Do not make member fun tions inline by default merely be ause they are dened
inside the lass s ope (C++ only). Otherwise, when you spe ify `-O', member
fun tions dened inside lass s ope are ompiled inline by default; i.e., you don't
need to add `inline' in front of the member fun tion name.

-fno-defer-pop

Always pop the arguments to ea h fun tion all as soon as that fun tion returns.
For ma hines whi h must pop arguments after a fun tion all, the ompiler
normally lets arguments a umulate on the sta k for several fun tion alls and
pops them all at on e.
Disabled at levels `-O', `-O2', `-O3', `-Os'.

-ffor e-mem

For e memory operands to be opied into registers before doing arithmeti on

them. This produ es better ode by making all memory referen es potential
ommon subexpressions. When they are not ommon subexpressions, instru tion ombination should eliminate the separate register-load.
Enabled at levels `-O2', `-O3', `-Os'.

64

Using the GNU Compiler Colle tion (GCC)

-ffor e-addr

For e memory address onstants to be opied into registers before doing arithmeti on them. This may produ e better ode just as `-ffor e-mem' may.

-fomit-frame-pointer

Don't keep the frame pointer in a register for fun tions that don't need one.
This avoids the instru tions to save, set up and restore frame pointers; it also
makes an extra register available in many fun tions. It also makes debugging
impossible on some ma hines.

On some ma hines, su h as the VAX, this ag has no ee t, be ause the standard alling sequen e automati ally handles the frame pointer and nothing is
saved by pretending it doesn't exist. The ma hine-des ription ma ro FRAME_
POINTER_REQUIRED ontrols whether a target ma hine supports this ag. See
se tion \Register Usage" in GNU Compiler Colle tion (GCC) Internals.
Enabled at levels `-O', `-O2', `-O3', `-Os'.
-foptimize-sibling- alls

Optimize sibling and tail re ursive alls.

Enabled at levels `-O2', `-O3', `-Os'.

-fno-inline

Don't pay attention to the inline keyword. Normally this option is used to
keep the ompiler from expanding any fun tions inline. Note that if you are
not optimizing, no fun tions an be expanded inline.

-finline-fun tions

Integrate all simple fun tions into their allers. The ompiler heuristi ally de ides whi h fun tions are simple enough to be worth integrating in this way.
If all alls to a given fun tion are integrated, and the fun tion is de lared
stati , then the fun tion is normally not output as assembler ode in its own
right.
Enabled at level `-O3'.

-finline-limit=n

By default, GCC limits the size of fun tions that an be inlined. This ag allows
the ontrol of this limit for fun tions that are expli itly marked as inline (i.e.,
marked with the inline keyword or dened within the lass denition in ++).
n is the size of fun tions that an be inlined in number of pseudo instru tions
(not ounting parameter handling). The default value of n is 600. In reasing
this value an result in more inlined ode at the ost of ompilation time and
memory onsumption. De reasing usually makes the ompilation faster and less
ode will be inlined (whi h presumably means slower programs). This option
is parti ularly useful for programs that use inlining heavily su h as those based
on re ursive templates with C++.
Inlining is a tually ontrolled by a number of parameters, whi h may be spe ied individually by using `--param name =value '. The `-finline-limit=n '
option sets some of these parameters as follows:
max-inline-insns-single

is set to n/2.

Chapter 3: GCC Command Options

65

max-inline-insns-auto

is set to n/2.

min-inline-insns

is set to 130 or n/4, whi hever is smaller.

max-inline-insns-rtl

is set to n.
See below for a do umentation of the individual parameters ontrolling inlining.
Note: pseudo instru tion represents, in this parti ular ontext, an abstra t
measurement of fun tion's size. In no way, it represents a ount of assembly
instru tions and as su h its exa t meaning might hange from one release to an
another.
-fkeep-inline-fun tions
In C, emit stati fun tions that are de lared inline into the obje t le, even

if the fun tion has been inlined into all of its allers. This swit h does not ae t
fun tions using the extern inline extension in GNU C. In C++, emit any and
all inline fun tions into the obje t le.

-fkeep-stati - onsts

Emit variables de lared stati onst when optimization isn't turned on, even
if the variables aren't referen ed.
GCC enables this option by default. If you want to for e the ompiler to he k if
the variable was referen ed, regardless of whether or not optimization is turned
on, use the `-fno-keep-stati - onsts' option.

-fmerge- onstants

Attempt to merge identi al onstants (string onstants and oating point onstants) a ross ompilation units.
This option is the default for optimized ompilation if the assembler and linker
support it. Use `-fno-merge- onstants' to inhibit this behavior.
Enabled at levels `-O', `-O2', `-O3', `-Os'.

-fmerge-all- onstants

Attempt to merge identi al onstants and identi al variables.

This option implies `-fmerge- onstants'. In addition to `-fmerge- onstants'
this onsiders e.g. even onstant initialized arrays or initialized onstant variables with integral or oating point types. Languages like C or C++ require
ea h non-automati variable to have distin t lo ation, so using this option will
result in non- onforming behavior.

-fmodulo-s hed

Perform swing modulo s heduling immediately before the rst s heduling pass.
This pass looks at innermost loops and reorders their instru tions by overlapping dierent iterations.

-fno-bran h- ount-reg

Do not use \de rement and bran h" instru tions on a ount register, but instead
generate a sequen e of instru tions that de rement a register, ompare it against

66

Using the GNU Compiler Colle tion (GCC)

zero, then bran h based upon the result. This option is only meaningful on
ar hite tures that support su h instru tions, whi h in lude x86, PowerPC, IA64 and S/390.
The default is `-fbran h- ount-reg', enabled when `-fstrength-redu e' is
enabled.
-fno-fun tion- se

Do not put fun tion addresses in registers; make ea h instru tion that alls a
onstant fun tion ontain the fun tion's address expli itly.
This option results in less e ient ode, but some strange ha ks that alter the
assembler output may be onfused by the optimizations performed when this
option is not used.
The default is `-ffun tion- se'

-fno-zero-initialized-in-bss

If the target supports a BSS se tion, GCC by default puts variables that are
initialized to zero into BSS. This an save spa e in the resulting ode.
This option turns o this behavior be ause some programs expli itly rely on
variables going to the data se tion. E.g., so that the resulting exe utable an
nd the beginning of that se tion and/or make assumptions based on that.
The default is `-fzero-initialized-in-bss'.

-fbounds- he k

For front-ends that support it, generate additional ode to he k that indi es
used to a ess arrays are within the de lared range. This is urrently only
supported by the Java and Fortran front-ends, where this option defaults to
true and false respe tively.

-fmudflap -fmudflapth -fmudflapir

For front-ends that support it (C and C++), instrument all risky pointer/array
dereferen ing operations, some standard library string/heap fun tions, and
some other asso iated onstru ts with range/validity tests. Modules so instrumented should be immune to buer over ows, invalid heap use, and some
other lasses of C/C++ programming errors. The instrumentation relies on a
separate runtime library (`libmudflap'), whi h will be linked into a program
if `-fmudflap' is given at link time. Run-time behavior of the instrumented
program is ontrolled by the MUDFLAP_OPTIONS environment variable. See env
MUDFLAP_OPTIONS=-help a.out for its options.
Use `-fmudflapth' instead of `-fmudflap' to ompile and to link if your program is multi-threaded. Use `-fmudflapir', in addition to `-fmudflap' or
`-fmudflapth', if instrumentation should ignore pointer reads. This produ es
less instrumentation (and therefore faster exe ution) and still provides some
prote tion against outright memory orrupting writes, but allows erroneously
read data to propagate within a program.

-fstrength-redu e

Perform the optimizations of loop strength redu tion and elimination of iteration variables.
Enabled at levels `-O2', `-O3', `-Os'.

Chapter 3: GCC Command Options

67

-fthread-jumps

Perform optimizations where we he k to see if a jump bran hes to a lo ation

where another omparison subsumed by the rst is found. If so, the rst bran h
is redire ted to either the destination of the se ond bran h or a point immediately following it, depending on whether the ondition is known to be true or
false.
Enabled at levels `-O2', `-O3', `-Os'.

-f se-follow-jumps

In ommon subexpression elimination, s an through jump instru tions when

the target of the jump is not rea hed by any other path. For example, when
CSE en ounters an if statement with an else lause, CSE will follow the jump
when the ondition tested is false.
Enabled at levels `-O2', `-O3', `-Os'.

-f se-skip-blo ks

This is similar to `-f se-follow-jumps', but auses CSE to follow jumps whi h
onditionally skip over blo ks. When CSE en ounters a simple if statement
with no else lause, `-f se-skip-blo ks' auses CSE to follow the jump around
the body of the if.
Enabled at levels `-O2', `-O3', `-Os'.

-frerun- se-after-loop

Re-run ommon subexpression elimination after loop optimizations has been

performed.
Enabled at levels `-O2', `-O3', `-Os'.

-frerun-loop-opt

-fg se

-fg se-lm

-fg se-sm

Run the loop optimizer twi e.

Enabled at levels `-O2', `-O3', `-Os'.
Perform a global ommon subexpression elimination pass. This pass also performs global onstant and opy propagation.
Note: When ompiling a program using omputed gotos, a GCC extension,
you may get better runtime performan e if you disable the global ommon
subexpression elimination pass by adding `-fno-g se' to the ommand line.
Enabled at levels `-O2', `-O3', `-Os'.

When `-fg se-lm' is enabled, global ommon subexpression elimination will

attempt to move loads whi h are only killed by stores into themselves. This
allows a loop ontaining a load/store sequen e to be hanged to a load outside
the loop, and a opy/store within the loop.
Enabled by default when g se is enabled.
When `-fg se-sm' is enabled, a store motion pass is run after global ommon
subexpression elimination. This pass will attempt to move stores out of loops.
When used in onjun tion with `-fg se-lm', loops ontaining a load/store sequen e an be hanged to a load before the loop and a store after the loop.

68

Using the GNU Compiler Colle tion (GCC)

Not enabled at any optimization level.

-fg se-las

When `-fg se-las' is enabled, the global ommon subexpression elimination

pass eliminates redundant loads that ome after stores to the same memory
lo ation (both partial and full redundan ies).
Not enabled at any optimization level.

-fg se-after-reload
When `-fg se-after-reload' is enabled, a redundant load elimination pass

is performed after reload. The purpose of this pass is to leanup redundant

spilling.

-floop-optimize

Perform loop optimizations: move onstant expressions out of loops, simplify

exit test onditions and optionally do strength-redu tion as well.
Enabled at levels `-O', `-O2', `-O3', `-Os'.

-floop-optimize2

Perform loop optimizations using the new loop optimizer. The optimizations
(loop unrolling, peeling and unswit hing, loop invariant motion) are enabled by
separate ags.

-f rossjumping

Perform ross-jumping transformation. This transformation unies equivalent

ode and save ode size. The resulting ode may or may not perform better
than without ross-jumping.
Enabled at levels `-O2', `-O3', `-Os'.

-fif- onversion

Attempt to transform onditional jumps into bran h-less equivalents. This

in lude use of onditional moves, min, max, set ags and abs instru tions, and
some tri ks doable by standard arithmeti s. The use of onditional exe ution
on hips where it is available is ontrolled by if- onversion2.
Enabled at levels `-O', `-O2', `-O3', `-Os'.

-fif- onversion2

Use onditional exe ution (where available) to transform onditional jumps into
bran h-less equivalents.
Enabled at levels `-O', `-O2', `-O3', `-Os'.

-fdelete-null-pointer- he ks

Use global data ow analysis to identify and eliminate useless he ks for null
pointers. The ompiler assumes that dereferen ing a null pointer would have
halted the program. If a pointer is he ked after it has already been dereferen ed, it annot be null.
In some environments, this assumption is not true, and programs an safely
dereferen e null pointers. Use `-fno-delete-null-pointer- he ks' to disable
this optimization for programs whi h depend on that behavior.
Enabled at levels `-O2', `-O3', `-Os'.

Chapter 3: GCC Command Options

69

-fexpensive-optimizations

Perform a number of minor optimizations that are relatively expensive.

Enabled at levels `-O2', `-O3', `-Os'.

-foptimize-register-move
-fregmove

Attempt to reassign register numbers in move instru tions and as operands of

other simple instru tions in order to maximize the amount of register tying.
This is espe ially helpful on ma hines with two-operand instru tions.
Note `-fregmove' and `-foptimize-register-move' are the same optimization.
Enabled at levels `-O2', `-O3', `-Os'.

-fdelayed-bran h

If supported for the target ma hine, attempt to reorder instru tions to exploit
instru tion slots available after delayed bran h instru tions.
Enabled at levels `-O', `-O2', `-O3', `-Os'.

-fs hedule-insns

If supported for the target ma hine, attempt to reorder instru tions to eliminate
exe ution stalls due to required data being unavailable. This helps ma hines
that have slow oating point or memory load instru tions by allowing other
instru tions to be issued until the result of the load or oating point instru tion
is required.
Enabled at levels `-O2', `-O3', `-Os'.

-fs hedule-insns2

Similar to `-fs hedule-insns', but requests an additional pass of instru tion

s heduling after register allo ation has been done. This is espe ially useful on
ma hines with a relatively small number of registers and where memory load
instru tions take more than one y le.
Enabled at levels `-O2', `-O3', `-Os'.

-fno-s hed-interblo k

Don't s hedule instru tions a ross basi blo ks. This is normally enabled by
default when s heduling before register allo ation, i.e. with `-fs hedule-insns'
or at `-O2' or higher.

-fno-s hed-spe

Don't allow spe ulative motion of non-load instru tions. This is normally
enabled by default when s heduling before register allo ation, i.e. with
`-fs hedule-insns' or at `-O2' or higher.

-fs hed-spe -load

Allow spe ulative motion of some load instru tions. This only makes sense
when s heduling before register allo ation, i.e. with `-fs hedule-insns' or at
`-O2' or higher.

70

Using the GNU Compiler Colle tion (GCC)

-fs hed-spe -load-dangerous

Allow spe ulative motion of more load instru tions. This only makes sense
when s heduling before register allo ation, i.e. with `-fs hedule-insns' or at
`-O2' or higher.

-fs hed-stalled-insns=n

Dene how many insns (if any) an be moved prematurely from the queue of
stalled insns into the ready list, during the se ond s heduling pass.

-fs hed-stalled-insns-dep=n

Dene how many insn groups ( y les) will be examined for a dependen y

on a stalled insn that is andidate for premature removal from the queue of
stalled insns. Has an ee t only during the se ond s heduling pass, and only if
`-fs hed-stalled-insns' is used and its value is not zero.

-fs hed2-use-superblo ks

When s heduling after register allo ation, do use superblo k s heduling algorithm. Superblo k s heduling allows motion a ross basi blo k boundaries resulting on faster s hedules. This option is experimental, as not all ma hine
des riptions used by GCC model the CPU losely enough to avoid unreliable
results from the algorithm.
This only makes sense when s heduling after register allo ation, i.e. with
`-fs hedule-insns2' or at `-O2' or higher.

-fs hed2-use-tra es
Use `-fs hed2-use-superblo ks' algorithm when s heduling after register al-

lo ation and additionally perform ode dupli ation in order to in rease the size
of superblo ks using tra er pass. See `-ftra er' for details on tra e formation.
This mode should produ e faster but signi antly longer programs. Also without `-fbran h-probabilities' the tra es onstru ted may not mat h the reality and hurt the performan e. This only makes sense when s heduling after
register allo ation, i.e. with `-fs hedule-insns2' or at `-O2' or higher.

-fres hedule-modulo-s heduled-loops

The modulo s heduling omes before the traditional s heduling, if a loop was
modulo s heduled we may want to prevent the later s heduling passes from
hanging its s hedule, we use this option to ontrol that.

-f aller-saves

Enable values to be allo ated in registers that will be lobbered by fun tion
alls, by emitting extra instru tions to save and restore the registers around
su h alls. Su h allo ation is done only when it seems to result in better ode
than would otherwise be produ ed.
This option is always enabled by default on ertain ma hines, usually those
whi h have no all-preserved registers to use instead.
Enabled at levels `-O2', `-O3', `-Os'.

-ftree-pre

Perform Partial Redundan y Elimination (PRE) on trees. This ag is enabled

by default at `-O2' and `-O3'.

Chapter 3: GCC Command Options

71

-ftree-fre

Perform Full Redundan y Elimination (FRE) on trees. The dieren e between

FRE and PRE is that FRE only onsiders expressions that are omputed on all
paths leading to the redundant omputation. This analysis faster than PRE,
though it exposes fewer redundan ies. This ag is enabled by default at `-O'
and higher.

-ftree- p

Perform sparse onditional onstant propagation (CCP) on trees. This ag is

enabled by default at `-O' and higher.

-ftree-d e

Perform dead ode elimination (DCE) on trees. This ag is enabled by default

at `-O' and higher.

-ftree-dominator-opts

Perform dead ode elimination (DCE) on trees. This ag is enabled by default

at `-O' and higher.

-ftree- h

Perform loop header opying on trees. This is bene ial sin e it in reases effe tiveness of ode motion optimizations. It also saves one jump. This ag is
enabled by default at `-O' and higher. It is not enabled for `-Os', sin e it usually
in reases ode size.

-ftree-loop-optimize

Perform loop optimizations on trees. This ag is enabled by default at `-O' and

higher.

-ftree-loop-linear

Perform linear loop transformations on tree. This ag an improve a he performan e and allow further loop optimizations to take pla e.

-ftree-loop-im

Perform loop invariant motion on trees. This pass moves only invariants that
would be hard to handle at RTL level (fun tion alls, operations that expand
to nontrivial sequen es of insns). With `-funswit h-loops' it also moves
operands of onditions that are invariant out of the loop, so that we an use
just trivial invariantness analysis in loop unswit hing. The pass also in ludes
store motion.

-ftree-loop-iv anon

Create a anoni al ounter for number of iterations in the loop for that determining number of iterations requires ompli ated analysis. Later optimizations
then may determine the number easily. Useful espe ially in onne tion with
unrolling.

-fivopts Perform indu tion variable optimizations (strength redu tion, indu tion vari-

able merging and indu tion variable elimination) on trees.

72

Using the GNU Compiler Colle tion (GCC)

-ftree-sra

Perform s alar repla ement of aggregates. This pass repla es stru ture referen es with s alars to prevent ommitting stru tures to memory too early. This
ag is enabled by default at `-O' and higher.

-ftree- opyrename

Perform opy renaming on trees. This pass attempts to rename ompiler temporaries to other variables at opy lo ations, usually resulting in variable names
whi h more losely resemble the original variables. This ag is enabled by default at `-O' and higher.

-ftree-ter

Perform temporary expression repla ement during the SSA->normal phase. Single use/single def temporaries are repla ed at their use lo ation with their dening expression. This results in non-GIMPLE ode, but gives the expanders
mu h more omplex trees to work on resulting in better RTL generation. This
is enabled by default at `-O' and higher.

-ftree-lrs

Perform live range splitting during the SSA->normal phase. Distin t live ranges
of a variable are split into unique variables, allowing for better optimization
later. This is enabled by default at `-O' and higher.

-ftree-ve torize

Perform loop ve torization on trees.

-ftra er Perform tail dupli ation to enlarge superblo k size. This transformation simplies the ontrol ow of the fun tion allowing other optimizations to do better
job.

-funroll-loops

Unroll loops whose number of iterations an be determined at ompile time or

upon entry to the loop. `-funroll-loops' implies both `-fstrength-redu e'
and `-frerun- se-after-loop'. This option makes ode larger, and may or
may not make it run faster.

-funroll-all-loops

Unroll all loops, even if their number of iterations is un ertain when the loop is
entered. This usually makes programs run more slowly. `-funroll-all-loops'
implies the same options as `-funroll-loops',

-fsplit-ivs-in-unroller

Enables expressing of values of indu tion variables in later iterations of the

unrolled loop using the value in the rst iteration. This breaks long dependen y hains, thus improving e ien y of the s heduling passes (for best results,
`-fweb' should be used as well).
Combination of `-fweb' and CSE is often su ient to obtain the same ee t.
However in ases the loop body is more ompli ated than a single basi blo k,
this is not reliable. It also does not work at all on some of the ar hite tures
due to restri tions in the CSE pass.
This optimization is enabled by default.

Chapter 3: GCC Command Options

73

-fvariable-expansion-in-unroller

With this option, the ompiler will reate multiple opies of some lo al variables
when unrolling a loop whi h an result in superior ode.

-fprefet h-loop-arrays

If supported by the target ma hine, generate instru tions to prefet h memory

to improve the performan e of loops that a ess large arrays.
These options may generate better or worse ode; results are highly dependent
on the stru ture of loops within the sour e ode.

-fno-peephole
-fno-peephole2

Disable any ma hine-spe i peephole optimizations. The dieren e between

`-fno-peephole' and `-fno-peephole2' is in how they are implemented in the
ompiler; some targets use one, some use the other, a few use both.
`-fpeephole' is enabled by default. `-fpeephole2' enabled at levels `-O2',
`-O3', `-Os'.

-fno-guess-bran h-probability

Do not guess bran h probabilities using heuristi s.

GCC will use heuristi s to guess bran h probabilities if they are not
provided by proling feedba k (`-fprofile-ar s').
These heuristi s
are based on the ontrol ow graph. If some bran h probabilities are
spe ied by `__builtin_expe t', then the heuristi s will be used to guess
bran h probabilities for the rest of the ontrol ow graph, taking the
`__builtin_expe t' info into a ount. The intera tions between the heuristi s
and `__builtin_expe t' an be omplex, and in some ases, it may be useful
to disable the heuristi s so that the ee ts of `__builtin_expe t' are easier
to understand.
The default is `-fguess-bran h-probability' at levels `-O', `-O2', `-O3', `-Os'.

-freorder-blo ks

Reorder basi blo ks in the ompiled fun tion in order to redu e number of
taken bran hes and improve ode lo ality.
Enabled at levels `-O2', `-O3'.

-freorder-blo ks-and-partition

In addition to reordering basi blo ks in the ompiled fun tion, in order to

redu e number of taken bran hes, partitions hot and old basi blo ks into
separate se tions of the assembly and .o les, to improve paging and a he
lo ality performan e.
This optimization is automati ally turned o in the presen e of ex eption handling, for linkon e se tions, for fun tions with a user-dened se tion attribute
and on any ar hite ture that does not support named se tions.

-freorder-fun tions

Reorder fun tions in the obje t le in order to improve ode lo ality. This is implemented by using spe ial subse tions .text.hot for most frequently exe uted
fun tions and .text.unlikely for unlikely exe uted fun tions. Reordering is

74

Using the GNU Compiler Colle tion (GCC)

done by the linker so obje t le format must support named se tions and linker
must pla e them in a reasonable way.
Also prole feedba k must be available in to make this option ee tive. See
`-fprofile-ar s' for details.
Enabled at levels `-O2', `-O3', `-Os'.
-fstri t-aliasing

Allows the ompiler to assume the stri test aliasing rules appli able to the
language being ompiled. For C (and C++), this a tivates optimizations based
on the type of expressions. In parti ular, an obje t of one type is assumed never
to reside at the same address as an obje t of a dierent type, unless the types
are almost the same. For example, an unsigned int an alias an int, but not
a void* or a double. A hara ter type may alias any other type.
Pay spe ial attention to ode like this:
union a_union {
int i;
double d;
};
int f() {
a_union t;
t.d = 3.0;
return t.i;
}

The pra ti e of reading from a dierent union member than the one
most re ently written to ( alled \type-punning") is ommon. Even with
`-fstri t-aliasing', type-punning is allowed, provided the memory is
a essed through the union type. So, the ode above will work as expe ted.
However, this ode might not:
int f() {
a_union t;
int* ip;
t.d = 3.0;
ip = &t.i;
return *ip;
}

Every language that wishes to perform language-spe i alias analysis should

dene a fun tion that omputes, given an tree node, an alias set for the node.
Nodes in dierent alias sets are not allowed to alias. For an example, see the C
front-end fun tion _get_alias_set.
Enabled at levels `-O2', `-O3', `-Os'.
-falign-fun tions
-falign-fun tions=n

Align the start of fun tions to the next power-of-two greater than n, skipping
up to n bytes. For instan e, `-falign-fun tions=32' aligns fun tions to the
next 32-byte boundary, but `-falign-fun tions=24' would align to the next
32-byte boundary only if this an be done by skipping 23 bytes or less.
`-fno-align-fun tions' and `-falign-fun tions=1' are equivalent and mean
that fun tions will not be aligned.

Chapter 3: GCC Command Options

75

Some assemblers only support this ag when n is a power of two; in that ase,
it is rounded up.
If n is not spe ied or is zero, use a ma hine-dependent default.
Enabled at levels `-O2', `-O3'.
-falign-labels
-falign-labels=n

Align all bran h targets to a power-of-two boundary, skipping up to n bytes

like `-falign-fun tions'. This option an easily make ode slower, be ause
it must insert dummy operations for when the bran h target is rea hed in the
usual ow of the ode.
`-fno-align-labels' and `-falign-labels=1' are equivalent and mean that
labels will not be aligned.
If `-falign-loops' or `-falign-jumps' are appli able and are greater than this
value, then their values are used instead.
If n is not spe ied or is zero, use a ma hine-dependent default whi h is very
likely to be `1', meaning no alignment.
Enabled at levels `-O2', `-O3'.

-falign-loops
-falign-loops=n

Align loops to a power-of-two boundary, skipping up to n bytes like

`-falign-fun tions'. The hope is that the loop will be exe uted many times,
whi h will make up for any exe ution of the dummy operations.
`-fno-align-loops' and `-falign-loops=1' are equivalent and mean that
loops will not be aligned.
If n is not spe ied or is zero, use a ma hine-dependent default.
Enabled at levels `-O2', `-O3'.

-falign-jumps
-falign-jumps=n

Align bran h targets to a power-of-two boundary, for bran h targets where

the targets an only be rea hed by jumping, skipping up to n bytes like
`-falign-fun tions'. In this ase, no dummy operations need be exe uted.
`-fno-align-jumps' and `-falign-jumps=1' are equivalent and mean that
loops will not be aligned.
If n is not spe ied or is zero, use a ma hine-dependent default.
Enabled at levels `-O2', `-O3'.

-funit-at-a-time

Parse the whole ompilation unit before starting to produ e ode. This allows
some extra optimizations to take pla e but onsumes more memory (in general).
There are some ompatibility issues with unit-at-at-time mode:
 enabling unit-at-a-time mode may hange the order in whi h fun tions,
variables, and top-level asm statements are emitted, and will likely break
ode relying on some parti ular ordering. The majority of su h top-level
asm statements, though, an be repla ed by se tion attributes.

76

Using the GNU Compiler Colle tion (GCC)

unit-at-a-time mode removes unreferen ed stati variables and fun tions

are removed. This may result in undened referen es when an asm statement refers dire tly to variables or fun tions that are otherwise unused.
In that ase either the variable/fun tion shall be listed as an operand of
the asm statement operand or, in the ase of top-level asm statements the
attribute used shall be used on the de laration.
Stati fun tions now an use non-standard passing onventions that may
break asm statements alling fun tions dire tly. Again, attribute used will
prevent this behavior.

As a temporary workaround, `-fno-unit-at-a-time' an be used, but this

s heme may not be supported by future releases of GCC.
Enabled at levels `-O2', `-O3'.
-fweb

Constru ts webs as ommonly used for register allo ation purposes and assign
ea h web individual pseudo register. This allows the register allo ation pass
to operate on pseudos dire tly, but also strengthens several other optimization
passes, su h as CSE, loop optimizer and trivial dead ode remover. It an,
however, make debugging impossible, sin e variables will no longer stay in a
\home register".
Enabled at levels `-O2', `-O3', `-Os', on targets where the default format for
debugging information supports variable tra king.

-fno- prop-registers

After register allo ation and post-register allo ation instru tion splitting, we
perform a opy-propagation pass to try to redu e s heduling dependen ies and
o asionally eliminate the opy.
Disabled at levels `-O', `-O2', `-O3', `-Os'.

-fprofile-generate

Enable options usually used for instrumenting appli ation to produ e prole
useful for later re ompilation with prole feedba k based optimization. You
must use `-fprofile-generate' both when ompiling and when linking your
program.
The following options are enabled: -fprofile-ar s, -fprofile-values, fvpt.

-fprofile-use

Enable prole feedba k dire ted optimizations, and optimizations generally

protable only with prole feedba k available.
The following options are enabled: -fbran h-probabilities, -fvpt,
-funroll-loops, -fpeel-loops, -ftra er.

The following options ontrol ompiler behavior regarding oating point arithmeti .
These options trade o between speed and orre tness. All must be spe i ally enabled.
-ffloat-store

Do not store oating point variables in registers, and inhibit other options that
might hange whether a oating point value is taken from a register or memory.

Chapter 3: GCC Command Options

77

This option prevents undesirable ex ess pre ision on ma hines su h as the 68000
where the oating registers (of the 68881) keep more pre ision than a double
is supposed to have. Similarly for the x86 ar hite ture. For most programs,
the ex ess pre ision does only good, but a few programs rely on the pre ise
denition of IEEE oating point. Use `-ffloat-store' for su h programs, after
modifying them to store all pertinent intermediate omputations into variables.
-ffast-math

Sets `-fno-math-errno', `-funsafe-math-optimizations',

`-fno-trapping-math', `-ffinite-math-only', `-fno-rounding-math',
`-fno-signaling-nans' and `f x-limited-range'.
This option auses the prepro essor ma ro __FAST_MATH__ to be dened.
This option should never be turned on by any `-O' option sin e it an result
in in orre t output for programs whi h depend on an exa t implementation of
IEEE or ISO rules/spe i ations for math fun tions.

-fno-math-errno

Do not set ERRNO after alling math fun tions that are exe uted with a single
instru tion, e.g., sqrt. A program that relies on IEEE ex eptions for math error
handling may want to use this ag for speed while maintaining IEEE arithmeti
ompatibility.
This option should never be turned on by any `-O' option sin e it an result
in in orre t output for programs whi h depend on an exa t implementation of
IEEE or ISO rules/spe i ations for math fun tions.
The default is `-fmath-errno'.

-funsafe-math-optimizations

Allow optimizations for oating-point arithmeti that (a) assume that arguments and results are valid and (b) may violate IEEE or ANSI standards.
When used at link-time, it may in lude libraries or startup les that hange the
default FPU ontrol word or other similar optimizations.
This option should never be turned on by any `-O' option sin e it an result
in in orre t output for programs whi h depend on an exa t implementation of
IEEE or ISO rules/spe i ations for math fun tions.
The default is `-fno-unsafe-math-optimizations'.

-ffinite-math-only

Allow optimizations for oating-point arithmeti that assume that arguments

and results are not NaNs or +-Infs.
This option should never be turned on by any `-O' option sin e it an result
in in orre t output for programs whi h depend on an exa t implementation of
IEEE or ISO rules/spe i ations.
The default is `-fno-finite-math-only'.

-fno-trapping-math

Compile ode assuming that oating-point operations annot generate uservisible traps. These traps in lude division by zero, over ow, under ow, inexa t result and invalid operation. This option implies `-fno-signaling-nans'.

78

Using the GNU Compiler Colle tion (GCC)

Setting this option may allow faster ode if one relies on \non-stop" IEEE
arithmeti , for example.
This option should never be turned on by any `-O' option sin e it an result
in in orre t output for programs whi h depend on an exa t implementation of
IEEE or ISO rules/spe i ations for math fun tions.
The default is `-ftrapping-math'.
-frounding-math

Disable transformations and optimizations that assume default oating point

rounding behavior. This is round-to-zero for all oating point to integer onversions, and round-to-nearest for all other arithmeti trun ations. This option
should be spe ied for programs that hange the FP rounding mode dynami ally, or that may be exe uted with a non-default rounding mode. This option
disables onstant folding of oating point expressions at ompile-time (whi h
may be ae ted by rounding mode) and arithmeti transformations that are
unsafe in the presen e of sign-dependent rounding modes.
The default is `-fno-rounding-math'.
This option is experimental and does not urrently guarantee to disable all GCC
optimizations that are ae ted by rounding mode. Future versions of GCC may
provide ner ontrol of this setting using C99's FENV_ACCESS pragma. This
ommand line option will be used to spe ify the default state for FENV_ACCESS.

-fsignaling-nans

Compile ode assuming that IEEE signaling NaNs may generate user-visible
traps during oating-point operations. Setting this option disables optimizations that may hange the number of ex eptions visible with signaling NaNs.
This option implies `-ftrapping-math'.
This option auses the prepro essor ma ro __SUPPORT_SNAN__ to be dened.
The default is `-fno-signaling-nans'.
This option is experimental and does not urrently guarantee to disable all
GCC optimizations that ae t signaling NaN behavior.

-fsingle-pre ision- onstant

Treat oating point onstant as single pre ision onstant instead of impli itly
onverting it to double pre ision onstant.

-f x-limited-range
-fno- x-limited-range

When enabled, this option states that a range redu tion step is not needed
when performing omplex division. The default is `-fno- x-limited-range',
but is enabled by `-ffast-math'.
This option ontrols the default setting of the ISO C99 CX_LIMITED_RANGE
pragma. Nevertheless, the option applies to all languages.

The following options ontrol optimizations that may improve performan e, but are not
enabled by any `-O' options. This se tion in ludes experimental options that may produ e
broken ode.

Chapter 3: GCC Command Options

79

-fbran h-probabilities

After running a program ompiled with `-fprofile-ar s' (see Se tion 3.9 [Options for Debugging Your Program or g , page 49), you an ompile it a se ond time using `-fbran h-probabilities', to improve optimizations based
on the number of times ea h bran h was taken. When the program ompiled with `-fprofile-ar s' exits it saves ar exe ution ounts to a le alled
`sour ename.g da' for ea h sour e le The information in this data le is very
dependent on the stru ture of the generated ode, so you must use the same
sour e ode and the same optimization options for both ompilations.
With `-fbran h-probabilities', GCC puts a `REG_BR_PROB' note on ea h
`JUMP_INSN' and `CALL_INSN'. These an be used to improve optimization.
Currently, they are only used in one pla e: in `reorg. ', instead of guessing
whi h path a bran h is mostly to take, the `REG_BR_PROB' values are used to
exa tly determine whi h path is taken more often.

-fprofile-values

-fvpt

If ombined with `-fprofile-ar s', it adds ode so that some data about
values of expressions in the program is gathered.
With `-fbran h-probabilities', it reads ba k the data gathered from proling values of expressions and adds `REG_VALUE_PROFILE' notes to instru tions
for their later usage in optimizations.
Enabled with `-fprofile-generate' and `-fprofile-use'.
If ombined with `-fprofile-ar s', it instru ts the ompiler to add a ode to
gather information about values of expressions.
With `-fbran h-probabilities', it reads ba k the data gathered and a tually
performs the optimizations based on them. Currently the optimizations in lude
spe ialization of division operation using the knowledge about the value of the
denominator.

-fspe ulative-prefet hing

If ombined with `-fprofile-ar s', it instru ts the ompiler to add a ode to

gather information about addresses of memory referen es in the program.
With `-fbran h-probabilities', it reads ba k the data gathered and issues
prefet h instru tions a ording to them. In addition to the opportunities noti ed by `-fprefet h-loop-arrays', it also noti es more ompli ated memory
a ess patterns|for example a esses to the data stored in linked list whose
elements are usually allo ated sequentially.
In order to prevent issuing double prefet hes, usage of `-fspe ulative-prefet hing'
implies `-fno-prefet h-loop-arrays'.
Enabled with `-fprofile-generate' and `-fprofile-use'.

-frename-registers

Attempt to avoid false dependen ies in s heduled ode by making use of registers
left over after register allo ation. This optimization will most benet pro essors
with lots of registers. Depending on the debug information format adopted by
the target, however, it an make debugging impossible, sin e variables will no
longer stay in a \home register".

80

Using the GNU Compiler Colle tion (GCC)

Not enabled by default at any level be ause it has known bugs.

-ftra er Perform tail dupli ation to enlarge superblo k size. This transformation sim-

plies the ontrol ow of the fun tion allowing other optimizations to do better
job.
Enabled with `-fprofile-use'.

-funroll-loops

Unroll loops whose number of iterations an be determined at ompile time or

upon entry to the loop. `-funroll-loops' implies `-frerun- se-after-loop'.
It also turns on omplete loop peeling (i.e. omplete removal of loops with small
onstant number of iterations). This option makes ode larger, and may or may
not make it run faster.
Enabled with `-fprofile-use'.

-funroll-all-loops

Unroll all loops, even if their number of iterations is un ertain when the loop is
entered. This usually makes programs run more slowly. `-funroll-all-loops'
implies the same options as `-funroll-loops'.

-fpeel-loops

Peels the loops for that there is enough information that they do not roll mu h
(from prole feedba k). It also turns on omplete loop peeling (i.e. omplete
removal of loops with small onstant number of iterations).
Enabled with `-fprofile-use'.

-fmove-loop-invariants

Enables the loop invariant motion pass in the new loop optimizer. Enabled at
level `-O1'

-funswit h-loops

Move bran hes with loop invariant onditions out of the loop, with dupli ates
of the loop on both bran hes (modied a ording to result of the ondition).

-fprefet h-loop-arrays

If supported by the target ma hine, generate instru tions to prefet h memory

to improve the performan e of loops that a ess large arrays.
Disabled at level `-Os'.

-ffun tion-se tions

-fdata-se tions

Pla e ea h fun tion or data item into its own se tion in the output le if the
target supports arbitrary se tions. The name of the fun tion or the name of
the data item determines the se tion's name in the output le.
Use these options on systems where the linker an perform optimizations to
improve lo ality of referen e in the instru tion spa e. Most systems using the
ELF obje t format and SPARC pro essors running Solaris 2 have linkers with
su h optimizations. AIX may have these optimizations in the future.
Only use these options when there are signi ant benets from doing so. When
you spe ify these options, the assembler and linker will reate larger obje t and

Chapter 3: GCC Command Options

81

exe utable les and will also be slower. You will not be able to use gprof on all
systems if you spe ify this option and you may have problems with debugging
if you spe ify both this option and `-g'.
-fbran h-target-load-optimize

Perform bran h target register load optimization before prologue / epilogue

threading. The use of target registers an typi ally be exposed only during
reload, thus hoisting loads out of loops and doing inter-blo k s heduling needs
a separate optimization pass.

-fbran h-target-load-optimize2

Perform bran h target register load optimization after prologue / epilogue

threading.

-fbtr-bb-ex lusive

When performing bran h target register load optimization, don't reuse bran h
target registers in within any basi blo k.

--param name =value

In some pla es, GCC uses various onstants to ontrol the amount of optimization that is done. For example, GCC will not inline fun tions that ontain more
that a ertain number of instru tions. You an ontrol some of these onstants
on the ommand-line using the `--param' option.
The names of spe i parameters, and the meaning of the values, are tied to
the internals of the ompiler, and are subje t to hange without noti e in future
releases.
In ea h ase, the value is an integer. The allowable hoi es for name are given
in the following table:
sra-max-stru ture-size

The maximum stru ture size, in bytes, at whi h the s alar repla ement of aggregates (SRA) optimization will perform blo k opies.
The default value, 0, implies that GCC will sele t the most appropriate size itself.

sra-field-stru ture-ratio

The threshold ratio (as a per entage) between instantiated elds

and the omplete stru ture size. We say that if the ratio of the
number of bytes in instantiated elds to the number of bytes in the
omplete stru ture ex eeds this parameter, then blo k opies are
not used. The default is 75.

max- rossjump-edges

The maximum number of in oming edges to onsider for rossjumping. The algorithm used by `-f rossjumping' is O(N 2 ) in the
number of edges in oming to ea h blo k. In reasing values mean
more aggressive optimization, making the ompile time in rease
with probably small improvement in exe utable size.

min- rossjump-insns

The minimum number of instru tions whi h must be mat hed at

the end of two blo ks before rossjumping will be performed on

82

Using the GNU Compiler Colle tion (GCC)

them. This value is ignored in the ase where all instru tions in
the blo k being rossjumped from are mat hed. The default value
is 5.
max-goto-dupli ation-insns

The maximum number of instru tions to dupli ate to a blo k that

jumps to a omputed goto. To avoid O(N 2 ) behavior in a number
of passes, GCC fa tors omputed gotos early in the ompilation
pro ess, and unfa tors them as late as possible. Only omputed
jumps at the end of a basi blo ks with no more than max-gotodupli ation-insns are unfa tored. The default value is 8.

max-delay-slot-insn-sear h

The maximum number of instru tions to onsider when looking for

an instru tion to ll a delay slot. If more than this arbitrary number
of instru tions is sear hed, the time savings from lling the delay
slot will be minimal so stop sear hing. In reasing values mean
more aggressive optimization, making the ompile time in rease
with probably small improvement in exe utable run time.

max-delay-slot-live-sear h

When trying to ll delay slots, the maximum number of instru tions to onsider when sear hing for a blo k with valid live register
information. In reasing this arbitrarily hosen value means more
aggressive optimization, in reasing the ompile time. This parameter should be removed when the delay slot ode is rewritten to
maintain the ontrol- ow graph.

max-g se-memory

The approximate maximum amount of memory that will be allo ated in order to perform the global ommon subexpression elimination optimization. If more memory than spe ied is required,
the optimization will not be done.

max-g se-passes

The maximum number of passes of GCSE to run. The default is 1.

max-pending-list-length

The maximum number of pending dependen ies s heduling will allow before ushing the urrent state and starting over. Large fun tions with few bran hes or alls an reate ex essively large lists
whi h needlessly onsume memory and resour es.

max-inline-insns-single

Several parameters ontrol the tree inliner used in g . This number sets the maximum number of instru tions ( ounted in GCC's
internal representation) in a single fun tion that the tree inliner
will onsider for inlining. This only ae ts fun tions de lared inline and methods implemented in a lass de laration (C++). The
default value is 450.

Chapter 3: GCC Command Options

83

max-inline-insns-auto

When you use `-finline-fun tions' (in luded in `-O3'), a lot of

fun tions that would otherwise not be onsidered for inlining by
the ompiler will be investigated. To those fun tions, a dierent
(more restri tive) limit ompared to fun tions de lared inline an
be applied. The default value is 90.

large-fun tion-insns

The limit spe ifying really large fun tions.

For fun tions
larger than this limit after inlining inlining is onstrained by
`--param large-fun tion-growth'. This parameter is useful
primarily to avoid extreme ompilation time aused by non-linear
algorithms used by the ba kend. This parameter is ignored when
`-funit-at-a-time' is not used. The default value is 2700.

large-fun tion-growth

Spe ies maximal growth of large fun tion aused by inlining in per ents. This parameter is ignored when `-funit-at-a-time' is not
used. The default value is 100 whi h limits large fun tion growth
to 2.0 times the original size.

inline-unit-growth

Spe ies maximal overall growth of the ompilation unit aused by

inlining. This parameter is ignored when `-funit-at-a-time' is
not used. The default value is 50 whi h limits unit growth to 1.5
times the original size.

max-inline-insns-re ursive
max-inline-insns-re ursive-auto

Spe ies maximum number of instru tions out-of-line opy of self

re ursive inline fun tion an grow into by performing re ursive inlining.
For fun tions de lared inline `--param max-inline-insns-re ursive'
is taken into a ount. For fun tion not de lared inline, re ursive
inlining happens only when `-finline-fun tions' (in luded in
`-O3') is enabled and `--param max-inline-insns-re ursive-auto'
is used. The default value is 450.

max-inline-re ursive-depth
max-inline-re ursive-depth-auto

Spe ies maximum re ursion depth used by the re ursive inlining.

For fun tions de lared inline `--param max-inline-re ursive-depth'
is taken into a ount. For fun tion not de lared inline, re ursive
inlining happens only when `-finline-fun tions' (in luded in
`-O3') is enabled and `--param max-inline-re ursive-depth-auto'
is used. The default value is 450.

inline- all- ost

Spe ify ost of all instru tion relative to simple arithmeti s operations (having ost of 1). In reasing this ost disqualify inlinining

84

Using the GNU Compiler Colle tion (GCC)

of non-leaf fun tions and at same time in rease size of leaf fun tion
that is believed to redu e fun tion size by being inlined. In effe t it in rease amount of inlining for ode having large abstra tion
penalty (many fun tions that just pass the argumetns to other fun tions) and de rease inlining for ode with low abstra tion penalty.
Default value is 16.
max-unrolled-insns

The maximum number of instru tions that a loop should have if

that loop is unrolled, and if the loop is unrolled, it determines how
many times the loop ode is unrolled.

max-average-unrolled-insns

The maximum number of instru tions biased by probabilities of

their exe ution that a loop should have if that loop is unrolled, and
if the loop is unrolled, it determines how many times the loop ode
is unrolled.

max-unroll-times

The maximum number of unrollings of a single loop.

max-peeled-insns

The maximum number of instru tions that a loop should have if

that loop is peeled, and if the loop is peeled, it determines how
many times the loop ode is peeled.

max-peel-times

The maximum number of peelings of a single loop.

max- ompletely-peeled-insns

The maximum number of insns of a ompletely peeled loop.

max- ompletely-peel-times

The maximum number of iterations of a loop to be suitable for

omplete peeling.

max-unswit h-insns

The maximum number of insns of an unswit hed loop.

max-unswit h-level

The maximum number of bran hes unswit hed in a single loop.

lim-expensive

The minimum ost of an expensive expression in the loop invariant

motion.

iv- onsider-all- andidates-bound

Bound on number of andidates for indu tion variables below that

all andidates are onsidered for ea h use in indu tion variable optimizations. Only the most relevant andidates are onsidered if
there are more andidates, to avoid quadrati time omplexity.

iv-max- onsidered-uses

The indu tion variable optimizations give up on loops that ontain

more indu tion variable uses.

Chapter 3: GCC Command Options

85

iv-always-prune- and-set-bound

If number of andidates in the set is smaller than this value, we

always try to remove unne essary ivs from the set during its optimization when a new iv is added to the set.

max-iterations-to-tra k

The maximum number of iterations of a loop the brute for e algorithm for analysis of # of iterations of the loop tries to evaluate.

hot-bb- ount-fra tion

Sele t fra tion of the maximal ount of repetitions of basi blo k in

program given basi blo k needs to have to be onsidered hot.

hot-bb-frequen y-fra tion

Sele t fra tion of the maximal frequen y of exe utions of basi blo k
in fun tion given basi blo k needs to have to be onsidered hot

tra er-dynami - overage

tra er-dynami - overage-feedba k

This value is used to limit superblo k formation on e the given per entage of exe uted instru tions is overed. This limits unne essary
ode size expansion.
The `tra er-dynami - overage-feedba k' is used only when prole feedba k is available. The real proles (as opposed to stati ally
estimated ones) are mu h less balan ed allowing the threshold to
be larger value.

tra er-max- ode-growth

Stop tail dupli ation on e ode growth has rea hed given per entage. This is rather hokey argument, as most of the dupli ates will
be eliminated later in ross jumping, so it may be set to mu h
higher values than is the desired ode growth.

tra er-min-bran h-ratio

Stop reverse growth when the reverse probability of best edge is

less than this threshold (in per ent).

tra er-min-bran h-ratio

tra er-min-bran h-ratio-feedba k

Stop forward growth if the best edge do have probability lower than
this threshold.
Similarly to `tra er-dynami - overage' two values are present,
one for ompilation for prole feedba k and one for ompilation
without. The value for ompilation with prole feedba k needs to
be more onservative (higher) in order to make tra er ee tive.

max- se-path-length

Maximum number of basi blo ks on path that se onsiders. The

default is 10.

86

Using the GNU Compiler Colle tion (GCC)

global-var-threshold

Counts the number of fun tion alls (n) and the number of all lobbered variables (v). If nxv is larger than this limit, a single
arti ial variable will be reated to represent all the all- lobbered
variables at fun tion all sites. This arti ial variable will then be
made to alias every all- lobbered variable. (done as int * size_t
on the host ma hine; beware over ow).

max-aliased-vops

Maximum number of virtual operands allowed to represent aliases

before triggering the alias grouping heuristi . Alias grouping redu es ompile times and memory onsumption needed for aliasing
at the expense of pre ision loss in alias information.

gg -min-expand

GCC uses a garbage olle tor to manage its own memory allo ation. This parameter spe ies the minimum per entage by whi h
the garbage olle tor's heap should be allowed to expand between
olle tions. Tuning this may improve ompilation speed; it has no
ee t on ode generation.
The default is 30% + 70% * (RAM/1GB) with an upper bound
of 100% when RAM >= 1GB. If getrlimit is available, the notion of "RAM" is the smallest of a tual RAM and RLIMIT_DATA or
RLIMIT_AS. If GCC is not able to al ulate RAM on a parti ular
platform, the lower bound of 30% is used. Setting this parameter
and `gg -min-heapsize' to zero auses a full olle tion to o ur
at every opportunity. This is extremely slow, but an be useful for
debugging.

gg -min-heapsize

Minimum size of the garbage olle tor's heap before it begins

bothering to olle t garbage. The rst olle tion o urs after the
heap expands by `gg -min-expand'% beyond `gg -min-heapsize'.
Again, tuning this may improve ompilation speed, and has no
ee t on ode generation.
The default is the smaller of RAM/8, RLIMIT RSS, or a limit
whi h tries to ensure that RLIMIT DATA or RLIMIT AS are not
ex eeded, but with a lower bound of 4096 (four megabytes) and
an upper bound of 131072 (128 megabytes). If GCC is not able
to al ulate RAM on a parti ular platform, the lower bound is
used. Setting this parameter very large ee tively disables garbage
olle tion. Setting this parameter and `gg -min-expand' to zero
auses a full olle tion to o ur at every opportunity.

max-reload-sear h-insns

The maximum number of instru tion reload should look ba kward

for equivalent register. In reasing values mean more aggressive optimization, making the ompile time in rease with probably slightly
better performan e. The default value is 100.

Chapter 3: GCC Command Options

87

max- selib-memory-lo ation

The maximum number of memory lo ations selib should take into

a ount. In reasing values mean more aggressive optimization, making the ompile time in rease with probably slightly better performan e. The default value is 500.

reorder-blo ks-dupli ate

reorder-blo ks-dupli ate-feedba k

Used by basi blo k reordering pass to de ide whether to use un onditional bran h or dupli ate the ode on its destination. Code
is dupli ated when its estimated size is smaller than this value multiplied by the estimated size of un onditional jump in the hot spots
of the program.
The `reorder-blo k-dupli ate-feedba k' is used only when prole feedba k is available and may be set to higher values than
`reorder-blo k-dupli ate' sin e information about the hot spots
is more a urate.

max-s hed-region-blo ks

The maximum number of blo ks in a region to be onsidered for

interblo k s heduling. The default value is 10.

max-s hed-region-insns

The maximum number of insns in a region to be onsidered for

interblo k s heduling. The default value is 100.

max-last-value-rtl

The maximum size measured as number of RTLs that an be

re orded in an expression in ombiner for a pseudo register as last
known value of that register. The default is 10000.

integer-share-limit

Small integer onstants an use a shared data stru ture, redu ing
the ompiler's memory usage and in reasing its speed. This sets the
maximum value of a shared integer onstant's. The default value
is 256.

3.11 Options Controlling the Prepro essor

These options ontrol the C prepro essor, whi h is run on ea h C sour e le before a tual
ompilation.
If you use the `-E' option, nothing is done ex ept prepro essing. Some of these options
make sense only together with `-E' be ause they ause the prepro essor output to be unsuitable for a tual ompilation.
You an use `-Wp,option ' to bypass the ompiler driver and pass option dire tly
through to the prepro essor. If option ontains ommas, it is split into multiple
options at the ommas. However, many options are modied, translated or
interpreted by the ompiler driver before being passed to the prepro essor,
and `-Wp' for ibly bypasses this phase. The prepro essor's dire t interfa e is

88

Using the GNU Compiler Colle tion (GCC)

undo umented and subje t to hange, so whenever possible you should avoid
using `-Wp' and let the driver handle the options instead.
-Xprepro essor option

-D name

Pass option as an option to the prepro essor. You an use this to supply systemspe i prepro essor options whi h GCC does not know how to re ognize.
If you want to pass an option that takes an argument, you must use
`-Xprepro essor' twi e, on e for the option and on e for the argument.
Predene name as a ma ro, with denition 1.

-D name =definition

-U name
-undef
-I dir

-o file

-Wall

The ontents of denition are tokenized and pro essed as if they appeared during translation phase three in a `#define' dire tive. In parti ular, the denition
will be trun ated by embedded newline hara ters.
If you are invoking the prepro essor from a shell or shell-like program you may
need to use the shell's quoting syntax to prote t hara ters su h as spa es that
have a meaning in the shell syntax.
If you wish to dene a fun tion-like ma ro on the ommand line, write its
argument list with surrounding parentheses before the equals sign (if any).
Parentheses are meaningful to most shells, so you will need to quote the option.
With sh and sh, `-D'name (args...)=definition '' works.
`-D' and `-U' options are pro essed in the order they are given on the ommand
line. All `-ima ros file ' and `-in lude file ' options are pro essed after all
`-D' and `-U' options.
Can el any previous denition of name, either built in or provided with a `-D'
option.
Do not predene any system-spe i or GCC-spe i ma ros. The standard
predened ma ros remain dened.
Add the dire tory dir to the list of dire tories to be sear hed for header les.
Dire tories named by `-I' are sear hed before the standard system in lude dire tories. If the dire tory dir is a standard system in lude dire tory, the option
is ignored to ensure that the default sear h order for system dire tories and the
spe ial treatment of system headers are not defeated .
Write output to le. This is the same as spe ifying le as the se ond non-option
argument to pp. g has a dierent interpretation of a se ond non-option
argument, so you must use `-o' to spe ify the output le.
Turns on all optional warnings whi h are desirable for normal ode. At present
this is `-W omment', `-Wtrigraphs', `-Wmulti har' and a warning about integer
promotion ausing a hange of sign in #if expressions. Note that many of the
prepro essor's warnings are on by default and have no options to ontrol them.

-W omment
-W omments

Warn whenever a omment-start sequen e `/*' appears in a `/*' omment, or

whenever a ba kslash-newline appears in a `//' omment. (Both forms have
the same ee t.)

Chapter 3: GCC Command Options

89

-Wtrigraphs

Most trigraphs in omments annot ae t the meaning of the program. However, a trigraph that would form an es aped newline (`??/' at the end of a line)
an, by hanging where the omment begins or ends. Therefore, only trigraphs
that would form es aped newlines produ e warnings inside a omment.
This option is implied by `-Wall'. If `-Wall' is not given, this option
is still enabled unless trigraphs are enabled. To get trigraph onversion
without warnings, but get the other `-Wall' warnings, use `-trigraphs -Wall
-Wno-trigraphs'.

-Wtraditional

Warn about ertain onstru ts that behave dierently in traditional and ISO
C. Also warn about ISO C onstru ts that have no traditional C equivalent,
and problemati onstru ts whi h should be avoided.
-Wimport Warn the rst time `#import' is used.
-Wundef Warn whenever an identier whi h is not a ma ro is en ountered in an `#if'
dire tive, outside of `defined'. Su h identiers are repla ed with zero.
-Wunused-ma ros

Warn about ma ros dened in the main le that are unused. A ma ro is used if
it is expanded or tested for existen e at least on e. The prepro essor will also
warn if the ma ro has not been used at the time it is redened or undened.
Built-in ma ros, ma ros dened on the ommand line, and ma ros dened in
in lude les are not warned about.
Note: If a ma ro is a tually used, but only used in skipped onditional blo ks,
then CPP will report it as unused. To avoid the warning in su h a ase, you
might improve the s ope of the ma ro's denition by, for example, moving it
into the rst skipped blo k. Alternatively, you ould provide a dummy use with
something like:
#if defined the_ma ro_ ausing_the_warning
#endif

-Wendif-labels

Warn whenever an `#else' or an `#endif' are followed by text. This usually

happens in ode of the form
#if FOO
...
#else FOO
...
#endif FOO

-Werror

The se ond and third FOO should be in omments, but often are not in older
programs. This warning is on by default.
Make all warnings into hard errors. Sour e ode whi h triggers warnings will
be reje ted.

-Wsystem-headers

Issue warnings for ode in system headers. These are normally unhelpful in
nding bugs in your own ode, therefore suppressed. If you are responsible for
the system library, you may want to see them.

90

-w
-pedanti

Using the GNU Compiler Colle tion (GCC)

Suppress all warnings, in luding those whi h GNU CPP issues by default.
Issue all the mandatory diagnosti s listed in the C standard. Some of them are
left out by default, sin e they trigger frequently on harmless ode.

-pedanti -errors

Issue all the mandatory diagnosti s, and make all mandatory diagnosti s
into errors. This in ludes mandatory diagnosti s that GCC issues without
`-pedanti ' but treats as warnings.

-M

-MM

-MF file

-MG

Instead of outputting the result of prepro essing, output a rule suitable for make
des ribing the dependen ies of the main sour e le. The prepro essor outputs
one make rule ontaining the obje t le name for that sour e le, a olon, and
the names of all the in luded les, in luding those oming from `-in lude' or
`-ima ros' ommand line options.
Unless spe ied expli itly (with `-MT' or `-MQ'), the obje t le name onsists of
the basename of the sour e le with any sux repla ed with obje t le sux.
If there are many in luded les then the rule is split into several lines using
`\'-newline. The rule has no ommands.
This option does not suppress the prepro essor's debug output, su h as `-dM'.
To avoid mixing su h debug output with the dependen y rules you should expli itly spe ify the dependen y output le with `-MF', or use an environment
variable like DEPENDENCIES_OUTPUT (see Se tion 3.19 [Environment Variables,
page 184). Debug output will still be sent to the regular output stream as
normal.
Passing `-M' to the driver implies `-E', and suppresses warnings with an impli it
`-w'.
Like `-M' but do not mention header les that are found in system header
dire tories, nor header les that are in luded, dire tly or indire tly, from su h
a header.
This implies that the hoi e of angle bra kets or double quotes in an `#in lude'
dire tive does not in itself determine whether that header will appear in `-MM'
dependen y output. This is a slight hange in semanti s from GCC versions
3.0 and earlier.
When used with `-M' or `-MM', spe ies a le to write the dependen ies to. If
no `-MF' swit h is given the prepro essor sends the rules to the same pla e it
would have sent prepro essed output.
When used with the driver options `-MD' or `-MMD', `-MF' overrides the default
dependen y output le.
In onjun tion with an option su h as `-M' requesting dependen y generation,
`-MG' assumes missing header les are generated les and adds them to the
dependen y list without raising an error. The dependen y lename is taken
dire tly from the #in lude dire tive without prepending any path. `-MG' also
suppresses prepro essed output, as a missing header le renders this useless.
This feature is used in automati updating of makeles.

Chapter 3: GCC Command Options

91

This option instru ts CPP to add a phony target for ea h dependen y other
than the main le, ausing ea h to depend on nothing. These dummy rules
work around errors make gives if you remove header les without updating the
`Makefile' to mat h.
This is typi al output:

-MP

test.o: test. test.h

test.h:

-MT target

Change the target of the rule emitted by dependen y generation. By default

CPP takes the name of the main input le, in luding any path, deletes any le
sux su h as `. ', and appends the platform's usual obje t sux. The result
is the target.
An `-MT' option will set the target to be exa tly the string you spe ify. If you
want multiple targets, you an spe ify them as a single argument to `-MT', or
use multiple `-MT' options.
For example, `-MT '$(objpfx)foo.o'' might give
$(objpfx)foo.o: foo.

-MQ target

Same as `-MT', but it quotes any hara ters whi h are spe ial to Make.
`-MQ '$(objpfx)foo.o'' gives
$$(objpfx)foo.o: foo.

The default target is automati ally quoted, as if it were given with `-MQ'.
-MD

`-MD' is equivalent to `-M -MF file ', ex ept that `-E' is not implied. The driver
determines le based on whether an `-o' option is given. If it is, the driver uses
its argument but with a sux of `.d', otherwise it take the basename of the
input le and applies a `.d' sux.
If `-MD' is used in onjun tion with `-E', any `-o' swit h is understood to spe ify
the dependen y output le (but see [-MF, page 90), but if used without `-E',
ea h `-o' is understood to spe ify a target obje t le.
Sin e `-E' is not implied, `-MD' an be used to generate a dependen y output
le as a side-ee t of the ompilation pro ess.

-MMD

Like `-MD' ex ept mention only user header les, not system header les.

-fp h-deps

When using pre ompiled headers (see Se tion 3.20 [Pre ompiled Headers,
page 187), this ag will ause the dependen y-output ags to also list the
les from the pre ompiled header's dependen ies. If not spe ied only the
pre ompiled header would be listed and not the les that were used to reate
it be ause those les are not onsulted when a pre ompiled header is used.

-fp h-prepro ess

This option allows use of a pre ompiled header (see Se tion 3.20 [Pre ompiled
Headers, page 187) together with `-E'. It inserts a spe ial #pragma, #pragma
GCC p h_prepro ess "<filename>" in the output to mark the pla e where the

92

Using the GNU Compiler Colle tion (GCC)

pre ompiled header was found, and its lename. When `-fprepro essed' is in
use, GCC re ognizes this #pragma and loads the PCH.
This option is o by default, be ause the resulting prepro essed output is only
really suitable as input to GCC. It is swit hed on by `-save-temps'.
You should not write this #pragma in your own ode, but it is safe to edit the
lename if the PCH le is available in a dierent lo ation. The lename may
be absolute or it may be relative to GCC's urrent dire tory.
-x
-x
-x
-x

++
obje tive-
assembler-with- pp

Spe ify the sour e language: C, C++, Obje tive-C, or assembly. This has nothing to do with standards onforman e or extensions; it merely sele ts whi h
base syntax to expe t. If you give none of these options, pp will dedu e the
language from the extension of the sour e le: `. ', `. ', `.m', or `.S'. Some
other ommon extensions for C++ and assembly are also re ognized. If pp does
not re ognize the extension, it will treat the le as C; this is the most generi
mode.
Note: Previous versions of pp a epted a `-lang' option whi h sele ted both
the language and the standards onforman e level. This option has been removed, be ause it on i ts with the `-l' option.

-std=standard
-ansi
Spe ify the standard to whi h the ode should onform. Currently CPP knows
about C and C++ standards; others may be added in the future.

standard may be one of:

iso9899:1990
89
The ISO C standard from 1990. ` 89' is the ustomary shorthand

for this version of the standard.

The `-ansi' option is equivalent to `-std= 89'.

iso9899:199409

The 1990 C standard, as amended in 1994.

iso9899:1999
99
iso9899:199x
9x
The revised ISO C standard, published in De ember 1999. Before
gnu89
gnu99
gnu9x
++98
gnu++98

publi ation, this was known as C9X.

The 1990 C standard plus GNU extensions. This is the default.

The 1999 C standard plus GNU extensions.

The 1998 ISO C++ standard plus amendments.
The same as `-std= ++98' plus GNU extensions. This is the default
for C++ ode.

Chapter 3: GCC Command Options

-I-

-nostdin

93

Split the in lude path. Any dire tories spe ied with `-I' options before `-I-'
are sear hed only for headers requested with #in lude "file "; they are not
sear hed for #in lude <file >. If additional dire tories are spe ied with `-I'
options after the `-I-', those dire tories are sear hed for all `#in lude' dire tives.
In addition, `-I-' inhibits the use of the dire tory of the urrent le dire tory as the rst sear h dire tory for #in lude "file ". This option has been
depre ated.
Do not sear h the standard system dire tories for header les. Only the dire tories you have spe ied with `-I' options (and the dire tory of the urrent le,
if appropriate) are sear hed.

-nostdin ++

Do not sear h for header les in the C++-spe i standard dire tories, but do
still sear h the other standard dire tories. (This option is used when building
the C++ library.)

-in lude file

Pro ess le as if #in lude "file" appeared as the rst line of the primary
sour e le. However, the rst dire tory sear hed for le is the prepro essor's
working dire tory instead of the dire tory ontaining the main sour e le. If
not found there, it is sear hed for in the remainder of the #in lude "..."
sear h hain as normal.
If multiple `-in lude' options are given, the les are in luded in the order they
appear on the ommand line.

-ima ros file

Exa tly like `-in lude', ex ept that any output produ ed by s anning le is
thrown away. Ma ros it denes remain dened. This allows you to a quire all
the ma ros from a header without also pro essing its de larations.
All les spe ied by `-ima ros' are pro essed before all les spe ied by
`-in lude'.

-idirafter dir

Sear h dir for header les, but do it after all dire tories spe ied with `-I' and
the standard system dire tories have been exhausted. dir is treated as a system
in lude dire tory.

-iprefix prefix

Spe ify prex as the prex for subsequent `-iwithprefix' options. If the prex
represents a dire tory, you should in lude the nal `/'.

-iwithprefix dir
-iwithprefixbefore dir

Append dir to the prex spe ied previously with `-iprefix', and add the
resulting dire tory to the in lude sear h path. `-iwithprefixbefore' puts it
in the same pla e `-I' would; `-iwithprefix' puts it where `-idirafter' would.

94

Using the GNU Compiler Colle tion (GCC)

-isystem dir

Sear h dir for header les, after all dire tories spe ied by `-I' but before the
standard system dire tories. Mark it as a system dire tory, so that it gets the
same spe ial treatment as is applied to the standard system dire tories.

-iquote dir

Sear h dir only for header les requested with #in lude "file "; they are not
sear hed for #in lude <file >, before all dire tories spe ied by `-I' and before
the standard system dire tories.

-fdollars-in-identifiers
A ept `$' in identiers.
-fprepro essed

Indi ate to the prepro essor that the input le has already been prepro essed.
This suppresses things like ma ro expansion, trigraph onversion, es aped newline spli ing, and pro essing of most dire tives. The prepro essor still re ognizes
and removes omments, so that you an pass a le prepro essed with `-C' to the
ompiler without problems. In this mode the integrated prepro essor is little
more than a tokenizer for the front ends.
`-fprepro essed' is impli it if the input le has one of the extensions `.i',
`.ii' or `.mi'. These are the extensions that GCC uses for prepro essed les
reated by `-save-temps'.

-ftabstop=width

Set the distan e between tab stops. This helps the prepro essor report orre t
olumn numbers in warnings or errors, even if tabs appear on the line. If the
value is less than 1 or greater than 100, the option is ignored. The default is 8.

-fexe - harset= harset

Set the exe ution hara ter set, used for string and hara ter onstants. The
default is UTF-8. harset an be any en oding supported by the system's i onv
library routine.

-fwide-exe - harset= harset

Set the wide exe ution hara ter set, used for wide string and hara ter onstants. The default is UTF-32 or UTF-16, whi hever orresponds to the width
of w har_t. As with `-fexe - harset', harset an be any en oding supported
by the system's i onv library routine; however, you will have problems with
en odings that do not t exa tly in w har_t.

-finput- harset= harset

Set the input hara ter set, used for translation from the hara ter set of the
input le to the sour e hara ter set used by GCC. If the lo ale does not spe ify,
or GCC annot get this information from the lo ale, the default is UTF-8. This
an be overridden by either the lo ale or this ommand line option. Currently
the ommand line option takes pre eden e if there's a on i t. harset an be
any en oding supported by the system's i onv library routine.

-fworking-dire tory

Enable generation of linemarkers in the prepro essor output that will let the
ompiler know the urrent working dire tory at the time of prepro essing.

Chapter 3: GCC Command Options

95

When this option is enabled, the prepro essor will emit, after the initial linemarker, a se ond linemarker with the urrent working dire tory followed by
two slashes. GCC will use this dire tory, when it's present in the prepro essed input, as the dire tory emitted as the urrent working dire tory in some
debugging information formats. This option is impli itly enabled if debugging information is enabled, but this an be inhibited with the negated form
`-fno-working-dire tory'. If the `-P' ag is present in the ommand line,
this option has no ee t, sin e no #line dire tives are emitted whatsoever.
-fno-show- olumn

Do not print olumn numbers in diagnosti s. This may be ne essary if diagnosti s are being s anned by a program that does not understand the olumn
numbers, su h as dejagnu.

-A predi ate =answer

Make an assertion with the predi ate predi ate and answer answer. This form is
preferred to the older form `-A predi ate (answer )', whi h is still supported,
be ause it does not use shell spe ial hara ters.

-A -predi ate =answer

Can el an assertion with the predi ate predi ate and answer answer.

-dCHARS

CHARS is a sequen e of one or more of the following hara ters, and must
not be pre eded by a spa e. Other hara ters are interpreted by the ompiler
proper, or reserved for future versions of GCC, and so are silently ignored. If
you spe ify hara ters whose behavior on i ts, the result is undened.
`M'

Instead of the normal output, generate a list of `#define' dire tives

for all the ma ros dened during the exe ution of the prepro essor,
in luding predened ma ros. This gives you a way of nding out
what is predened in your version of the prepro essor. Assuming
you have no le `foo.h', the ommand
tou h foo.h; pp -dM foo.h

will show all the predened ma ros.

`D'

Like `M' ex ept in two respe ts: it does not in lude the predened
ma ros, and it outputs both the `#define' dire tives and the result
of prepro essing. Both kinds of output go to the standard output
le.

`N'

Like `D', but emit only the ma ro names, not their expansions.

`I'

Output `#in lude' dire tives in addition to the result of prepro essing.

-P

Inhibit generation of linemarkers in the output from the prepro essor. This
might be useful when running the prepro essor on something that is not C ode,
and will be sent to a program whi h might be onfused by the linemarkers.

-C

Do not dis ard omments. All omments are passed through to the output le,
ex ept for omments in pro essed dire tives, whi h are deleted along with the
dire tive.

96

Using the GNU Compiler Colle tion (GCC)

You should be prepared for side ee ts when using `-C'; it auses the prepro essor to treat omments as tokens in their own right. For example, omments
appearing at the start of what would be a dire tive line have the ee t of turning that line into an ordinary sour e line, sin e the rst token on the line is no
longer a `#'.
-CC

Do not dis ard omments, in luding during ma ro expansion. This is like `-C',
ex ept that omments ontained within ma ros are also passed through to the
output le where the ma ro is expanded.
In addition to the side-ee ts of the `-C' option, the `-CC' option auses all
C++-style omments inside a ma ro to be onverted to C-style omments. This
is to prevent later use of that ma ro from inadvertently ommenting out the
remainder of the sour e line.
The `-CC' option is generally used to support lint omments.

-traditional- pp

Try to imitate the behavior of old-fashioned C prepro essors, as opposed to ISO

C prepro essors.

-trigraphs

Pro ess trigraph sequen es. These are three- hara ter sequen es, all starting
with `??', that are dened by ISO C to stand for single hara ters. For example,
`??/' stands for `\', so `'??/n'' is a hara ter onstant for a newline. By default,
GCC ignores trigraphs, but in standard- onforming modes it onverts them. See
the `-std' and `-ansi' options.
The nine trigraphs and their repla ements are
Trigraph:
Repla ement:

-remap

??(
[

??)

??<
{

??> ??= ??/ ??'

}
#
\
^

??!
|

??~

Enable spe ial ode to work around le systems whi h only permit very short
le names, su h as MS-DOS.

--help
--target-help

Print text des ribing all the ommand line options instead of prepro essing
anything.

-v

Verbose mode. Print out GNU CPP's version number at the beginning of
exe ution, and report the nal form of the in lude path.

-H

Print the name of ea h header le used, in addition to other normal a tivities.

Ea h name is indented to show how deep in the `#in lude' sta k it is. Pre ompiled header les are also printed, even if they are found to be invalid; an invalid
pre ompiled header le is printed with `...x' and a valid one with `...!' .

-version
--version

Print out GNU CPP's version number. With one dash, pro eed to prepro ess
as normal. With two dashes, exit immediately.

Chapter 3: GCC Command Options

97

3.12 Passing Options to the Assembler

You an pass options to the assembler.
-Wa,option

Pass option as an option to the assembler. If option ontains ommas, it is split

into multiple options at the ommas.

-Xassembler option

Pass option as an option to the assembler. You an use this to supply systemspe i assembler options whi h GCC does not know how to re ognize.
If you want to pass an option that takes an argument, you must use
`-Xassembler' twi e, on e for the option and on e for the argument.

3.13 Options for Linking

These options ome into play when the ompiler links obje t les into an exe utable output
le. They are meaningless if the ompiler is not doing a link step.
obje t-file-name

A le name that does not end in a spe ial re ognized sux is onsidered to
name an obje t le or library. (Obje t les are distinguished from libraries by
the linker a ording to the le ontents.) If linking is done, these obje t les
are used as input to the linker.

-
-S
-E
-llibrary
-l library

If any of these options is used, then the linker is not run, and obje t le names
should not be used as arguments. See Se tion 3.2 [Overall Options, page 16.
Sear h the library named library when linking. (The se ond alternative with
the library as a separate argument is only for POSIX omplian e and is not
re ommended.)
It makes a dieren e where in the ommand you write this option; the linker
sear hes and pro esses libraries and obje t les in the order they are spe ied. Thus, `foo.o -lz bar.o' sear hes library `z' after le `foo.o' but before
`bar.o'. If `bar.o' refers to fun tions in `z', those fun tions may not be loaded.
The linker sear hes a standard list of dire tories for the library, whi h is a tually
a le named `liblibrary.a'. The linker then uses this le as if it had been
spe ied pre isely by name.
The dire tories sear hed in lude several standard system dire tories plus any
that you spe ify with `-L'.
Normally the les found this way are library les|ar hive les whose members
are obje t les. The linker handles an ar hive le by s anning through it for
members whi h dene symbols that have so far been referen ed but not dened.
But if the le that is found is an ordinary obje t le, it is linked in the usual
fashion. The only dieren e between using an `-l' option and spe ifying a le

98

Using the GNU Compiler Colle tion (GCC)

-lobj

name is that `-l' surrounds library with `lib' and `.a' and sear hes several
dire tories.
You need this spe ial ase of the `-l' option in order to link an Obje tive-C or
Obje tive-C++ program.

-nostartfiles

Do not use the standard system startup les when linking. The standard system
libraries are used normally, unless `-nostdlib' or `-nodefaultlibs' is used.

-nodefaultlibs

Do not use the standard system libraries when linking. Only the libraries you
spe ify will be passed to the linker. The standard startup les are used normally,
unless `-nostartfiles' is used. The ompiler may generate alls to mem mp,
memset, mem py and memmove. These entries are usually resolved by entries in
lib . These entry points should be supplied through some other me hanism
when this option is spe ied.

-nostdlib

-pie

-s
-stati
-shared

Do not use the standard system startup les or libraries when linking. No
startup les and only the libraries you spe ify will be passed to the linker. The
ompiler may generate alls to mem mp, memset, mem py and memmove. These
entries are usually resolved by entries in lib . These entry points should be
supplied through some other me hanism when this option is spe ied.
One of the standard libraries bypassed by `-nostdlib' and `-nodefaultlibs'
is `libg .a', a library of internal subroutines that GCC uses to over ome
short omings of parti ular ma hines, or spe ial needs for some languages. (See
se tion \Interfa ing to GCC Output" in GNU Compiler Colle tion (GCC) Internals, for more dis ussion of `libg .a'.) In most ases, you need `libg .a'
even when you want to avoid other standard libraries. In other words, when you
spe ify `-nostdlib' or `-nodefaultlibs' you should usually spe ify `-lg ' as
well. This ensures that you have no unresolved referen es to internal GCC
library subroutines. (For example, `__main', used to ensure C++ onstru tors
will be alled; see se tion \ olle t2" in GNU Compiler Colle tion (GCC) Internals.)
Produ e a position independent exe utable on targets whi h support it. For
predi table results, you must also spe ify the same set of options that were
used to generate ode (`-fpie', `-fPIE', or model suboptions) when you spe ify
this option.
Remove all symbol table and relo ation information from the exe utable.
On systems that support dynami linking, this prevents linking with the shared
libraries. On other systems, this option has no ee t.
Produ e a shared obje t whi h an then be linked with other obje ts to form
an exe utable. Not all systems support this option. For predi table results,
you must also spe ify the same set of options that were used to generate ode
(`-fpi ', `-fPIC', or model suboptions) when you spe ify this option.1

On some systems, `g -shared' needs to build supplementary stub ode for onstru tors to work. On
multi-libbed systems, `g -shared' must sele t the orre t support libraries to link against. Failing to

Chapter 3: GCC Command Options

99

-shared-libg
-stati -libg

On systems that provide `libg ' as a shared library, these options for e the
use of either the shared or stati version respe tively. If no shared version of
`libg ' was built when the ompiler was ongured, these options have no
ee t.
There are several situations in whi h an appli ation should use the shared
`libg ' instead of the stati version. The most ommon of these is when
the appli ation wishes to throw and at h ex eptions a ross dierent shared libraries. In that ase, ea h of the libraries as well as the appli ation itself should
use the shared `libg '.
Therefore, the G++ and GCJ drivers automati ally add `-shared-libg '
whenever you build a shared library or a main exe utable, be ause C++ and
Java programs typi ally use ex eptions, so this is the right thing to do.
If, instead, you use the GCC driver to reate shared libraries, you may nd
that they will not always be linked with the shared `libg '. If GCC nds, at
its onguration time, that you have a non-GNU linker or a GNU linker that
does not support option `--eh-frame-hdr', it will link the shared version of
`libg ' into shared libraries by default. Otherwise, it will take advantage of
the linker and optimize away the linking with the shared version of `libg ',
linking with the stati version of libg by default. This allows ex eptions to
propagate through su h shared libraries, without in urring relo ation osts at
library load time.
However, if a library or main exe utable is supposed to throw or at h ex eptions, you must link it using the G++ or GCJ driver, as appropriate for the
languages used in the program, or using the option `-shared-libg ', su h
that it is linked with the shared `libg '.

-symboli

Bind referen es to global symbols when building a shared obje t. Warn about
any unresolved referen es (unless overridden by the link editor option `-Xlinker
-z -Xlinker defs'). Only a few systems support this option.

-Xlinker option

Pass option as an option to the linker. You an use this to supply system-spe i
linker options whi h GCC does not know how to re ognize.
If you want to pass an option that takes an argument, you must use `-Xlinker'
twi e, on e for the option and on e for the argument. For example, to
pass `-assert definitions', you must write `-Xlinker -assert -Xlinker
definitions'. It does not work to write `-Xlinker "-assert definitions"',
be ause this passes the entire string as a single argument, whi h is not what
the linker expe ts.

supply the orre t ags may lead to subtle defe ts. Supplying them in ases where they are not ne essary
is inno uous.

100

Using the GNU Compiler Colle tion (GCC)

-Wl,option

Pass option as an option to the linker. If option ontains ommas, it is split

into multiple options at the ommas.

-u symbol

Pretend the symbol symbol is undened, to for e linking of library modules
to dene it. You an use `-u' multiple times with dierent symbols to for e
loading of additional library modules.

3.14 Options for Dire tory Sear h

These options spe ify dire tories to sear h for header les, for libraries and for parts of the
ompiler:
-Idir
Add the dire tory dir to the head of the list of dire tories to be sear hed for
header les. This an be used to override a system header le, substituting
your own version, sin e these dire tories are sear hed before the system header
le dire tories. However, you should not use this option to add dire tories that
ontain vendor-supplied system header les (use `-isystem' for that). If you
use more than one `-I' option, the dire tories are s anned in left-to-right order;
the standard system dire tories ome after.
If a standard system in lude dire tory, or a dire tory spe ied with `-isystem',
is also spe ied with `-I', the `-I' option will be ignored. The dire tory will
still be sear hed but as a system dire tory at its normal position in the system
in lude hain. This is to ensure that GCC's pro edure to x buggy system
headers and the ordering for the in lude next dire tive are not inadvertently
hanged. If you really need to hange the sear h order for system dire tories,
use the `-nostdin ' and/or `-isystem' options.
-iquotedir

Add the dire tory dir to the head of the list of dire tories to be sear hed for
header les only for the ase of `#in lude "file "'; they are not sear hed for
`#in lude <file >', otherwise just like `-I'.
-Ldir
Add dire tory dir to the list of dire tories to be sear hed for `-l'.
-Bprefix This option spe ies where to nd the exe utables, libraries, in lude les, and
data les of the ompiler itself.
The ompiler driver program runs one or more of the subprograms ` pp', ` 1',
`as' and `ld'. It tries prex as a prex for ea h program it tries to run, both with
and without `ma hine /version /' (see Se tion 3.16 [Target Options, page 108).
For ea h subprogram to be run, the ompiler driver rst tries the `-B' prex, if
any. If that name is not found, or if `-B' was not spe ied, the driver tries two
standard prexes, whi h are `/usr/lib/g /' and `/usr/lo al/lib/g /'. If
neither of those results in a le name that is found, the unmodied program
name is sear hed for using the dire tories spe ied in your PATH environment
variable.
The ompiler will he k to see if the path provided by the `-B' refers to a
dire tory, and if ne essary it will add a dire tory separator hara ter at the end
of the path.

Chapter 3: GCC Command Options

101

`-B' prexes that ee tively spe ify dire tory names also apply to libraries in
the linker, be ause the ompiler translates these options into `-L' options for
the linker. They also apply to in ludes les in the prepro essor, be ause the
ompiler translates these options into `-isystem' options for the prepro essor.
In this ase, the ompiler appends `in lude' to the prex.
The run-time support le `libg .a' an also be sear hed for using the `-B'
prex, if needed. If it is not found there, the two standard prexes above are
tried, and that is all. The le is left out of the link if it is not found by those
means.
Another way to spe ify a prex mu h like the `-B' prex is to use the environment variable GCC_EXEC_PREFIX. See Se tion 3.19 [Environment Variables,
page 184.
As a spe ial kludge, if the path provided by `-B' is `[dir/stageN /', where N
is a number in the range 0 to 9, then it will be repla ed by `[dir/in lude'.
This is to help with boot-strapping the ompiler.
-spe s=file

Pro ess le after the ompiler reads in the standard `spe s' le, in order
to override the defaults that the `g ' driver program uses when determining what swit hes to pass to ` 1', ` 1plus', `as', `ld', et . More than one
`-spe s=file ' an be spe ied on the ommand line, and they are pro essed
in order, from left to right.

-I-

This option has been depre ated. Please use `-iquote' instead for `-I' dire tories before the `-I-' and remove the `-I-'. Any dire tories you spe ify with
`-I' options before the `-I-' option are sear hed only for the ase of `#in lude
"file "'; they are not sear hed for `#in lude <file >'.
If additional dire tories are spe ied with `-I' options after the `-I-', these
dire tories are sear hed for all `#in lude' dire tives. (Ordinarily all `-I' dire tories are used this way.)
In addition, the `-I-' option inhibits the use of the urrent dire tory (where
the urrent input le ame from) as the rst sear h dire tory for `#in lude
"file "'. There is no way to override this ee t of `-I-'. With `-I.' you
an spe ify sear hing the dire tory whi h was urrent when the ompiler was
invoked. That is not exa tly the same as what the prepro essor does by default,
but it is often satisfa tory.
`-I-' does not inhibit the use of the standard system dire tories for header les.
Thus, `-I-' and `-nostdin ' are independent.

3.15 Spe ifying subpro esses and the swit hes to pass to
them
g is a driver program. It performs its job by invoking a sequen e of other programs to do

the work of ompiling, assembling and linking. GCC interprets its ommand-line parameters
and uses these to dedu e whi h programs it should invoke, and whi h ommand-line options
it ought to pla e on their ommand lines. This behavior is ontrolled by spe strings. In
most ases there is one spe string for ea h program that GCC an invoke, but a few

102

Using the GNU Compiler Colle tion (GCC)

programs have multiple spe strings to ontrol their behavior. The spe strings built into
GCC an be overridden by using the `-spe s=' ommand-line swit h to spe ify a spe le.
Spe les are plaintext les that are used to onstru t spe strings. They onsist of a
sequen e of dire tives separated by blank lines. The type of dire tive is determined by the
rst non-whitespa e hara ter on the line and it an be one of the following:
% ommand Issues a ommand to the spe le pro essor. The ommands that an appear
here are:
%in lude <file >

Sear h for le and insert its text at the urrent point in the spe s
le.

%in lude_noerr <file >

Just like `%in lude', but do not generate an error message if the

in lude le annot be found.

%rename old_name new_name

Rename the spe string old name to new name.

*[spe _name :

This tells the ompiler to reate, override or delete the named spe string. All
lines after this dire tive up to the next dire tive or blank line are onsidered
to be the text for the spe string. If this results in an empty string then the
spe will be deleted. (Or, if the spe did not exist, then nothing will happened.)
Otherwise, if the spe does not urrently exist a new spe will be reated. If the
spe does exist then its ontents will be overridden by the text of this dire tive,
unless the rst hara ter of that text is the `+' hara ter, in whi h ase the text
will be appended to the spe .

[suffix :

Creates a new `[suffix spe ' pair. All lines after this dire tive and up to the
next dire tive or blank line are onsidered to make up the spe string for the
indi ated sux. When the ompiler en ounters an input le with the named
sux, it will pro esses the spe string in order to work out how to ompile that
le. For example:
.ZZ:
z- ompile -input %i

This says that any input le whose name ends in `.ZZ' should be passed to the
program `z- ompile', whi h should be invoked with the ommand-line swit h
`-input' and with the result of performing the `%i' substitution. (See below.)
As an alternative to providing a spe string, the text that follows a sux dire tive an be one of the following:
language

This says that the sux is an alias for a known language. This is
similar to using the `-x' ommand-line swit h to GCC to spe ify a
language expli itly. For example:
.ZZ:
 ++

Says that .ZZ les are, in fa t, C++ sour e les.

Chapter 3: GCC Command Options

#name

103

This auses an error messages saying:

name ompiler not installed on this system.

GCC already has an extensive list of suxes built into it. This dire tive will
add an entry to the end of the list of suxes, but sin e the list is sear hed from
the end ba kwards, it is ee tively possible to override earlier entries using this
te hnique.
GCC has the following spe strings built into it. Spe les an override these strings or
reate their own. Note that individual targets an also add their own spe strings to this
list.
asm
asm_final
pp
1
1plus
endfile
link
lib
libg
linker
predefines
signed_ har
startfile

Options to pass to the assembler

Options to pass to the assembler post-pro essor
Options to pass to the C prepro essor
Options to pass to the C ompiler
Options to pass to the C++ ompiler
Obje t files to in lude at the end of the link
Options to pass to the linker
Libraries to in lude on the ommand line to the linker
De ides whi h GCC support library to pass to the linker
Sets the name of the linker
Defines to be passed to the C prepro essor
Defines to pass to CPP to say whether har is signed
by default
Obje t files to in lude at the start of the link

Here is a small example of a spe le:

%rename lib

old_lib

*lib:
--start-group -lg -l -leval1 --end-group %(old_lib)

This example renames the spe alled `lib' to `old_lib' and then overrides the previous
denition of `lib' with a new one. The new denition adds in some extra ommand-line
options before in luding the text of the old denition.
Spe strings are a list of ommand-line options to be passed to their orresponding program. In addition, the spe strings an ontain `%'-prexed sequen es to substitute variable
text or to onditionally insert text into the ommand line. Using these onstru ts it is
possible to generate quite omplex ommand lines.
Here is a table of all dened `%'-sequen es for spe strings. Note that spa es are not
generated automati ally around the results of expanding these sequen es. Therefore you
an on atenate them together or ombine them with onstant text in a single argument.
%%

Substitute one `%' into the program name or argument.

%i

Substitute the name of the input le being pro essed.

%b

Substitute the basename of the input le being pro essed. This is the substring
up to (and not in luding) the last period and not in luding the dire tory.

%B

This is the same as `%b', but in lude the le sux (text after the last period).

%d

Marks the argument ontaining or following the `%d' as a temporary le name,

so that that le will be deleted if GCC exits su essfully. Unlike `%g', this
ontributes no text to the argument.

104

Using the GNU Compiler Colle tion (GCC)

%gsuffix Substitute a le name that has sux sux and is hosen on e per ompilation,
and mark the argument in the same way as `%d'. To redu e exposure to denial-

of-servi e atta ks, the le name is now hosen in a way that is hard to predi t
even when previously hosen le names are known. For example, `%g.s ...
%g.o ... %g.s' might turn into ` UVUUAU.s XYAXZ12.o UVUUAU.s'. sux
mat hes the regexp `[.A-Za-z*' or the spe ial string `%O', whi h is treated
exa tly as if `%O' had been prepro essed. Previously, `%g' was simply substituted
with a le name hosen on e per ompilation, without regard to any appended
sux (whi h was therefore treated just like ordinary text), making su h atta ks
more likely to su eed.

%usuffix Like `%g', but generates a new temporary le name even if `%usuffix ' was

already seen.

%Usuffix Substitutes the last le name generated with `%usuffix ', generating a new one
if there is no su h last le name. In the absen e of any `%usuffix ', this is
just like `%gsuffix ', ex ept they don't share the same sux spa e, so `%g.s
... %U.s ... %g.s ... %U.s' would involve the generation of two distin t le
names, one for ea h `%g.s' and another for ea h `%U.s'. Previously, `%U' was
simply substituted with a le name hosen for the previous `%u', without regard

to any appended sux.

%jsuffix Substitutes the name of the HOST_BIT_BUCKET, if any, and if it is writable, and

if save-temps is o; otherwise, substitute the name of a temporary le, just like

`%u'. This temporary le is not meant for ommuni ation between pro esses,
but rather as a junk disposal me hanism.

%|suffix
%msuffix Like `%g', ex ept if `-pipe' is in ee t. In that ase `%|' substitutes a single
dash and `%m' substitutes nothing at all. These are the two most ommon

ways to instru t a program that it should read from standard input or write
to standard output. If you need something more elaborate you an use an
`%{pipe:X}' onstru t: see for example `f/lang-spe s.h'.

%.SUFFIX Substitutes .SUFFIX for the suxes of a mat hed swit h's args when it is
subsequently output with `%*'. SUFFIX is terminated by the next spa e or %.
%w

Marks the argument ontaining or following the `%w' as the designated output
le of this ompilation. This puts the argument into the sequen e of arguments
that `%o' will substitute later.

%o

Substitutes the names of all the output les, with spa es automati ally pla ed
around them. You should write spa es around the `%o' as well or the results are
undened. `%o' is for use in the spe s for running the linker. Input les whose
names have no re ognized sux are not ompiled at all, but they are in luded
among the output les, so they will be linked.

%O

Substitutes the sux for obje t les. Note that this is handled spe ially when
it immediately follows `%g, %u, or %U', be ause of the need for those to form
omplete le names. The handling is su h that `%O' is treated exa tly as if it
had already been substituted, ex ept that `%g, %u, and %U' do not urrently

Chapter 3: GCC Command Options

%p
%P

%I

%s
%estr
%(name )
%[name

support additional sux hara ters following `%O' as they would following, for
example, `.o'.
Substitutes the standard ma ro predenitions for the urrent target ma hine.
Use this when running pp.
Like `%p', but puts `__' before and after the name of ea h predened ma ro,
ex ept for ma ros that start with `__' or with `_L ', where L is an upper ase
letter. This is for ISO C.
Substitute any of `-iprefix' (made from GCC_EXEC_PREFIX), `-isysroot'
(made from TARGET_SYSTEM_ROOT), and `-isystem' (made from
COMPILER_PATH and `-B' options) as ne essary.
Current argument is the name of a library or startup le of some sort. Sear h
for that le in a standard list of dire tories and substitute the full name found.
Print str as an error message. str is terminated by a newline. Use this when
in onsistent options are dete ted.
Substitute the ontents of spe string name at this point.
Like `%(...)' but put `__' around `-D' arguments.

%x{option }
%X
%Y
%Z
%a
%A
%l
%D

%L
%G
%S

%E

105

A umulate an option for `%X'.

Output the a umulated linker options spe ied by `-Wl' or a `%x' spe string.
Output the a umulated assembler options spe ied by `-Wa'.
Output the a umulated prepro essor options spe ied by `-Wp'.
Pro ess the asm spe . This is used to ompute the swit hes to be passed to the
assembler.
Pro ess the asm_final spe . This is a spe string for passing swit hes to an
assembler post-pro essor, if su h a program is needed.
Pro ess the link spe . This is the spe for omputing the ommand line passed
to the linker. Typi ally it will make use of the `%L %G %S %D and %E' sequen es.
Dump out a `-L' option for ea h dire tory that GCC believes might ontain
startup les. If the target supports multilibs then the urrent multilib dire tory
will be prepended to ea h of these paths.
Pro ess the lib spe . This is a spe string for de iding whi h libraries should
be in luded on the ommand line to the linker.
Pro ess the libg spe . This is a spe string for de iding whi h GCC support
library should be in luded on the ommand line to the linker.
Pro ess the startfile spe . This is a spe for de iding whi h obje t les
should be the rst ones passed to the linker. Typi ally this might be a le
named ` rt0.o'.
Pro ess the endfile spe . This is a spe string that spe ies the last obje t
les that will be passed to the linker.

106

%C
%1
%2
%*
%<S

Using the GNU Compiler Colle tion (GCC)

Pro ess the pp spe . This is used to onstru t the arguments to be passed to
the C prepro essor.
Pro ess the 1 spe . This is used to onstru t the options to be passed to the
a tual C ompiler (` 1').
Pro ess the 1plus spe . This is used to onstru t the options to be passed
to the a tual C++ ompiler (` 1plus').
Substitute the variable part of a mat hed option. See below. Note that ea h
omma in the substituted string is repla ed by a single spa e.
Remove all o urren es of -S from the ommand line. Note|this ommand is
position dependent. `%' ommands in the spe string before this one will see -S,
`%' ommands in the spe string after this one will not.

%:fun tion (args )

Call the named fun tion fun tion, passing it args. args is rst pro essed as a
nested spe string, then split into an argument ve tor in the usual fashion. The
fun tion returns a string whi h is pro essed as if it had appeared literally as
part of the urrent spe .
The following built-in spe fun tions are provided:
if-exists

The if-exists spe fun tion takes one argument, an absolute

pathname to a le. If the le exists, if-exists returns the pathname. Here is a small example of its usage:
*startfile:
rt0%O%s %:if-exists( rti%O%s) rtbegin%O%s

if-exists-else
The if-exists-else spe fun tion is similar to the if-exists spe

fun tion, ex ept that it takes two arguments. The rst argument is
an absolute pathname to a le. If the le exists, if-exists-else
returns the pathname. If it does not exist, it returns the se ond
argument. This way, if-exists-else an be used to sele t one
le or another, based on the existen e of the rst. Here is a small
example of its usage:
*startfile:
rt0%O%s %:if-exists( rti%O%s) \
%:if-exists-else( rtbeginT%O%s rtbegin%O%s)

repla e-outfile
The repla e-outfile spe fun tion takes two arguments. It looks

for the rst argument in the outles array and repla es it with the
se ond argument. Here is a small example of its usage:
%{fgnu-runtime:%:repla e-outfile(-lobj -lobj -gnu)}

%{S}

Substitutes the -S swit h, if that swit h was given to GCC. If that swit h was
not spe ied, this substitutes nothing. Note that the leading dash is omitted
when spe ifying this option, and it is automati ally inserted if the substitution
is performed. Thus the spe string `%{foo}' would mat h the ommand-line
option `-foo' and would output the ommand line option `-foo'.

Chapter 3: GCC Command Options

107

Like %{S} but mark last argument supplied within as a le to be deleted on

failure.
%{S*}
Substitutes all the swit hes spe ied to GCC whose names start with -S, but
whi h also take an argument. This is used for swit hes like `-o', `-D', `-I',
et . GCC onsiders `-o foo' as being one swit h whose names starts with `o'.
%{o*} would substitute this text, in luding the spa e. Thus two arguments
would be generated.
%{S*&T*} Like %{S*}, but preserve order of S and T options (the order of S and T in
the spe is not signi ant). There an be any number of ampersand-separated
variables; for ea h the wild ard is optional. Useful for CPP as `%{D*&U*&A*}'.
%{S:X}
Substitutes X, if the `-S' swit h was given to GCC.
%{!S:X} Substitutes X, if the `-S' swit h was not given to GCC.
%{S*:X} Substitutes X if one or more swit hes whose names start with -S are spe ied to
GCC. Normally X is substituted only on e, no matter how many su h swit hes
appeared. However, if %* appears somewhere in X, then X will be substituted
on e for ea h mat hing swit h, with the %* repla ed by the part of that swit h
that mat hed the *.
%{.S:X} Substitutes X, if pro essing a le with sux S.
%{!.S:X} Substitutes X, if not pro essing a le with sux S.
%{S|P:X} Substitutes X if either -S or -P was given to GCC. This may be ombined with
`!', `.', and * sequen es as well, although they have a stronger binding than
the `|'. If %* appears in X, all of the alternatives must be starred, and only the
rst mat hing alternative is substituted.
For example, a spe string like this:
%W{S}

%{. :-foo} %{!. :-bar} %{. |d:-baz} %{!. |d:-boggle}

will output the following ommand-line options from the following input
ommand-line options:
fred.
jim.d
-d fred.
-d jim.d

-foo
-bar
-foo
-bar

-baz
-boggle
-baz -boggle
-baz -boggle

%{S:X; T:Y; :D}

If S was given to GCC, substitutes X; else if T was given to GCC, substitutes
Y; else substitutes D. There an be as many lauses as you need. This may be
ombined with ., !, |, and * as needed.

The onditional text X in a %{S:X} or similar onstru t may ontain other nested `%'
onstru ts or spa es, or even newlines. They are pro essed as usual, as des ribed above.
Trailing white spa e in X is ignored. White spa e may also appear anywhere on the left side
of the olon in these onstru ts, ex ept between . or * and the orresponding word.
The `-O', `-f', `-m', and `-W' swit hes are handled spe i ally in these onstru ts. If
another value of `-O' or the negated form of a `-f', `-m', or `-W' swit h is found later in
the ommand line, the earlier swit h value is ignored, ex ept with {S*} where S is just one
letter, whi h passes all mat hing options.

108

Using the GNU Compiler Colle tion (GCC)

The hara ter `|' at the beginning of the predi ate text is used to indi ate that a ommand
should be piped to the following ommand, but only if `-pipe' is spe ied.
It is built into GCC whi h swit hes take arguments and whi h do not. (You might think
it would be useful to generalize this to allow ea h ompiler's spe to say whi h swit hes
take arguments. But this annot be done in a onsistent fashion. GCC annot even de ide
whi h input les have been spe ied without knowing whi h swit hes take arguments, and
it must know whi h input les to ompile in order to tell whi h ompilers to run).
GCC also knows impli itly that arguments starting in `-l' are to be treated as ompiler
output les, and passed to the linker in their proper position among the other output les.

3.16 Spe ifying Target Ma hine and Compiler Version

The usual way to run GCC is to run the exe utable alled `g ', or `<ma hine>-g ' when
ross- ompiling, or `<ma hine>-g -<version>' to run a version other than the one that
was installed last. Sometimes this is in onvenient, so GCC provides options that will swit h
to another ross- ompiler or version.
-b ma hine

-V version

The argument ma hine spe ies the target ma hine for ompilation.

The value to use for ma hine is the same as was spe ied as the ma hine type
when onguring GCC as a ross- ompiler. For example, if a ross- ompiler was
ongured with ` onfigure i386v', meaning to ompile for an 80386 running
System V, then you would spe ify `-b i386v' to run that ross ompiler.
The argument version spe ies whi h version of GCC to run. This is useful
when multiple versions are installed. For example, version might be `2.0',
meaning to run GCC version 2.0.

The `-V' and `-b' options work by running the `<ma hine>-g -<version>' exe utable,
so there's no real reason to use them if you an just run that dire tly.

3.17 Hardware Models and Congurations

Earlier we dis ussed the standard option `-b' whi h hooses among dierent installed ompilers for ompletely dierent target ma hines, su h as VAX vs. 68000 vs. 80386.
In addition, ea h of these target ma hine types an have its own spe ial options, starting
with `-m', to hoose among various hardware models or ongurations|for example, 68010
vs 68020, oating opro essor or none. A single installed version of the ompiler an ompile
for any model or onguration, a ording to the options spe ied.
Some ongurations of the ompiler also support additional spe ial options, usually for
ompatibility with other ompilers on the same platform.
These options are dened by the ma ro TARGET_SWITCHES in the ma hine des ription.
The default for the options is also dened by that ma ro, whi h enables you to hange the
defaults.

Chapter 3: GCC Command Options

109

3.17.1 ARC Options

These options are dened for ARC implementations:

Compile ode for little endian mode. This is the default.
Compile ode for big endian mode.

-EL
-EB

-mmangle- pu

Prepend the name of the pu to all publi symbol names. In multiple-pro essor
systems, there are many ARC variants with dierent instru tion and register
set hara teristi s. This ag prevents ode ompiled for one pu to be linked
with ode ompiled for another. No fa ility exists for handling variants that
are \almost identi al". This is an all or nothing option.

-m pu= pu

Compile ode for ARC variant pu. Whi h variants are supported depend on
the onguration. All variants support `-m pu=base', this is the default.

-mtext=text-se tion
-mdata=data-se tion
-mrodata=readonly-data-se tion

Put fun tions, data, and readonly data in text-se tion, data-se tion, and
readonly-data-se tion respe tively by default. This an be overridden with the
se tion attribute. See Se tion 5.31 [Variable Attributes, page 233.

3.17.2 ARM Options

These `-m' options are dened for Advan ed RISC Ma hines (ARM) ar hite tures:
-mabi=name

Generate ode for the spe ied ABI. Permissible values are: `ap s-gnu',
`atp s', `aap s' and `iwmmxt'.

-map s-frame

-map s

Generate a sta k frame that is ompliant with the ARM Pro edure Call Standard for all fun tions, even if this is not stri tly ne essary for orre t exe ution of the ode. Spe ifying `-fomit-frame-pointer' with this option will
ause the sta k frames not to be generated for leaf fun tions. The default is
`-mno-ap s-frame'.
This is a synonym for `-map s-frame'.

-mthumb-interwork

Generate ode whi h supports alling between the ARM and Thumb instru tion
sets. Without this option the two instru tion sets annot be reliably used inside
one program. The default is `-mno-thumb-interwork', sin e slightly larger ode
is generated when `-mthumb-interwork' is spe ied.

-mno-s hed-prolog

Prevent the reordering of instru tions in the fun tion prolog, or the merging of
those instru tion with the instru tions in the fun tion's body. This means that
all fun tions will start with a re ognizable set of instru tions (or in fa t one of
a hoi e from a small set of dierent fun tion prologues), and this information

110

Using the GNU Compiler Colle tion (GCC)

an be used to lo ate the start if fun tions inside an exe utable pie e of ode.
The default is `-ms hed-prolog'.
-mhard-float

Generate output ontaining oating point instru tions. This is the default.

-msoft-float

Generate output ontaining library alls for oating point. Warning: the requisite libraries are not available for all ARM targets. Normally the fa ilities of
the ma hine's usual C ompiler are used, but this annot be done dire tly in
ross- ompilation. You must make your own arrangements to provide suitable
library fun tions for ross- ompilation.
`-msoft-float' hanges the alling onvention in the output le; therefore, it
is only useful if you ompile all of a program with this option. In parti ular, you need to ompile `libg .a', the library that omes with GCC, with
`-msoft-float' in order for this to work.

-mfloat-abi=name

Spe ies whi h ABI to use for oating point values. Permissible values are:
`soft', `softfp' and `hard'.
`soft' and `hard' are equivalent to `-msoft-float' and `-mhard-float' respe tively. `softfp' allows the generation of oating point instru tions, but
still uses the soft- oat alling onventions.

-mlittle-endian

Generate ode for a pro essor running in little-endian mode. This is the default
for all standard ongurations.

-mbig-endian

Generate ode for a pro essor running in big-endian mode; the default is to
ompile ode for a little-endian pro essor.

-mwords-little-endian

This option only applies when generating ode for big-endian pro essors. Generate ode for a little-endian word order but a big-endian byte order. That is,
a byte order of the form `32107654'. Note: this option should only be used if
you require ompatibility with ode for big-endian ARM pro essors generated
by versions of the ompiler prior to 2.8.

-m pu=name

This spe ies the name of the target ARM pro essor. GCC uses this name to
determine what kind of instru tions it an emit when generating assembly
ode. Permissible names are: `arm2', `arm250', `arm3', `arm6', `arm60',
`arm600', `arm610', `arm620', `arm7', `arm7m', `arm7d', `arm7dm', `arm7di',
`arm7dmi', `arm70', `arm700', `arm700i', `arm710', `arm710 ', `arm7100',
`arm7500', `arm7500fe', `arm7tdmi', `arm7tdmi-s', `arm8', `strongarm',
`strongarm110', `strongarm1100', `arm8', `arm810', `arm9', `arm9e',
`arm920', `arm920t', `arm922t', `arm946e-s', `arm966e-s', `arm968e-s',
`arm926ej-s', `arm940t', `arm9tdmi', `arm10tdmi', `arm1020t', `arm1026ej-s',

Chapter 3: GCC Command Options

111

`arm10e', `arm1020e', `arm1022e', `arm1136j-s', `arm1136jf-s', `mp ore',

`mp orenovfp', `arm1176jz-s', `arm1176jzf-s', `xs ale', `iwmmxt', `ep9312'.
-mtune=name

This option is very similar to the `-m pu=' option, ex ept that instead of spe ifying the a tual target pro essor type, and hen e restri ting whi h instru tions
an be used, it spe ies that GCC should tune the performan e of the ode as
if the target were of the type spe ied in this option, but still hoosing the instru tions that it will generate based on the pu spe ied by a `-m pu=' option.
For some ARM implementations better performan e an be obtained by using
this option.

-mar h=name

This spe ies the name of the target ARM ar hite ture. GCC uses this name
to determine what kind of instru tions it an emit when generating assembly
ode. This option an be used in onjun tion with or instead of the `-m pu='
option. Permissible names are: `armv2', `armv2a', `armv3', `armv3m', `armv4',
`armv4t', `armv5', `armv5t', `armv5te', `armv6', `armv6j', `iwmmxt', `ep9312'.

-mfpu=name
-mfpe=number
-mfp=number

This spe ies what oating point hardware (or hardware emulation) is available
on the target. Permissible names are: `fpa', `fpe2', `fpe3', `maveri k', `vfp'.
`-mfp' and `-mfpe' are synonyms for `-mfpu'=`fpe'number, for ompatibility
with older versions of GCC.
If `-msoft-float' is spe ied this spe ies the format of oating point values.

-mstru ture-size-boundary=n

The size of all stru tures and unions will be rounded up to a multiple of the
number of bits set by this option. Permissible values are 8, 32 and 64. The
default value varies for dierent tool hains. For the COFF targeted tool hain
the default value is 8. A value of 64 is only allowed if the underlying ABI
supports it.
Spe ifying the larger number an produ e faster, more e ient ode, but an
also in rease the size of the program. Dierent values are potentially in ompatible. Code ompiled with one value annot ne essarily expe t to work with ode
or libraries ompiled with another value, if they ex hange information using
stru tures or unions.

-mabort-on-noreturn

Generate a all to the fun tion abort at the end of a noreturn fun tion. It
will be exe uted if the fun tion tries to return.

-mlong- alls
-mno-long- alls

Tells the ompiler to perform fun tion alls by rst loading the address of the
fun tion into a register and then performing a subroutine all on this register.
This swit h is needed if the target fun tion will lie outside of the 64 megabyte
addressing range of the oset based version of subroutine all instru tion.

112

Using the GNU Compiler Colle tion (GCC)

Even if this swit h is enabled, not all fun tion alls will be turned into long alls.
The heuristi is that stati fun tions, fun tions whi h have the `short- all'
attribute, fun tions that are inside the s ope of a `#pragma no_long_ alls'
dire tive and fun tions whose denitions have already been ompiled within
the urrent ompilation unit, will not be turned into long alls. The ex eption
to this rule is that weak fun tion denitions, fun tions with the `long- all'
attribute or the `se tion' attribute, and fun tions that are within the s ope of
a `#pragma long_ alls' dire tive, will always be turned into long alls.
This feature is not enabled by default. Spe ifying `-mno-long- alls' will restore the default behavior, as will pla ing the fun tion alls within the s ope of
a `#pragma long_ alls_off' dire tive. Note these swit hes have no ee t on
how the ompiler generates ode to handle fun tion alls via fun tion pointers.
-mnop-fun-dllimport

Disable support for the dllimport attribute.

-msingle-pi -base

Treat the register used for PIC addressing as read-only, rather than loading
it in the prologue for ea h fun tion. The run-time system is responsible for
initializing this register with an appropriate value before exe ution begins.

-mpi -register=reg

Spe ify the register to be used for PIC addressing. The default is R10 unless
sta k- he king is enabled, when R9 is used.

-m irrus-fix-invalid-insns

Insert NOPs into the instru tion stream to in order to work around problems
with invalid Maveri k instru tion ombinations. This option is only valid if the
`-m pu=ep9312' option has been used to enable generation of instru tions for
the Cirrus Maveri k oating point o-pro essor. This option is not enabled by
default, sin e the problem is only present in older Maveri k implementations.
The default an be re-enabled by use of the `-mno- irrus-fix-invalid-insns'
swit h.

-mpoke-fun tion-name

Write the name of ea h fun tion into the text se tion, dire tly pre eding the
fun tion prologue. The generated ode is similar to this:
t0
t1

.as ii "arm_poke_fun tion_name", 0

.align

.word 0xff000000 + (t1 - t0)

arm_poke_fun tion_name
mov
ip, sp
stmfd
sp!, {fp, ip, lr, p }
sub
fp, ip, #4

When performing a sta k ba ktra e, ode an inspe t the value of p stored at

fp + 0. If the tra e fun tion then looks at lo ation p - 12 and the top 8 bits
are set, then we know that there is a fun tion name embedded immediately
pre eding this lo ation and has length ((p [-3) & 0xff000000).

Chapter 3: GCC Command Options

-mthumb

113

Generate ode for the 16-bit Thumb instru tion set. The default is to use the
32-bit ARM instru tion set.

-mtp s-frame

Generate a sta k frame that is ompliant with the Thumb Pro edure Call Standard for all non-leaf fun tions. (A leaf fun tion is one that does not all any
other fun tions.) The default is `-mno-tp s-frame'.

-mtp s-leaf-frame

Generate a sta k frame that is ompliant with the Thumb Pro edure Call Standard for all leaf fun tions. (A leaf fun tion is one that does not all any other
fun tions.) The default is `-mno-ap s-leaf-frame'.

-m allee-super-interworking

Gives all externally visible fun tions in the le being ompiled an ARM instru tion set header whi h swit hes to Thumb mode before exe uting the rest of the
fun tion. This allows these fun tions to be alled from non-interworking ode.

-m aller-super-interworking

Allows alls via fun tion pointers (in luding virtual fun tions) to exe ute orre tly regardless of whether the target ode has been ompiled for interworking
or not. There is a small overhead in the ost of exe uting a fun tion pointer if
this option is enabled.

3.17.3 AVR Options

These options are dened for AVR implementations:

-mm u=m u

-msize

Spe ify ATMEL AVR instru tion set or MCU type.

Instru tion set avr1 is for the minimal AVR ore, not supported by the C ompiler, only for assembler programs (MCU types: at90s1200, attiny10, attiny11,
attiny12, attiny15, attiny28).
Instru tion set avr2 (default) is for the lassi AVR ore with up to 8K program memory spa e (MCU types: at90s2313, at90s2323, attiny22, at90s2333,
at90s2343, at90s4414, at90s4433, at90s4434, at90s8515, at90 8534, at90s8535).
Instru tion set avr3 is for the lassi AVR ore with up to 128K program memory spa e (MCU types: atmega103, atmega603, at43usb320, at76 711).
Instru tion set avr4 is for the enhan ed AVR ore with up to 8K program
memory spa e (MCU types: atmega8, atmega83, atmega85).
Instru tion set avr5 is for the enhan ed AVR ore with up to 128K program
memory spa e (MCU types: atmega16, atmega161, atmega163, atmega32, atmega323, atmega64, atmega128, at43usb355, at94k).
Output instru tion sizes to the asm le.

-minit-sta k=N

Spe ify the initial sta k address, whi h may be a symbol or numeri value,
`__sta k' is the default.

114

Using the GNU Compiler Colle tion (GCC)

-mno-interrupts

Generated ode is not ompatible with hardware interrupts. Code size will be
smaller.

-m all-prologues

Fun tions prologues/epilogues expanded as all to appropriate subroutines.

Code size will be smaller.

-mno-tablejump

Do not generate tablejump insns whi h sometimes in rease ode size.

-mtiny-sta k

Change only the low 8 bits of the sta k pointer.

-mint8

Assume int to be 8 bit integer. This ae ts the sizes of all types: A har will
be 1 byte, an int will be 1 byte, an long will be 2 bytes and long long will be 4
bytes. Please note that this option does not omply to the C standards, but it
will provide you with smaller ode size.

3.17.4 CRIS Options

These options are dened spe i ally for the CRIS ports.
-mar h=ar hite ture-type
-m pu=ar hite ture-type

Generate ode for the spe ied ar hite ture. The hoi es for ar hite turetype are `v3', `v8' and `v10' for respe tively ETRAX 4, ETRAX 100, and
ETRAX 100 LX. Default is `v0' ex ept for ris-axis-linux-gnu, where the default is `v10'.

-mtune=ar hite ture-type

Tune to ar hite ture-type everything appli able about the generated ode,
ex ept for the ABI and the set of available instru tions. The hoi es for
ar hite ture-type are the same as for `-mar h=ar hite ture-type '.

-mmax-sta k-frame=n

Warn when the sta k frame of a fun tion ex eeds n bytes.

-melinux-sta ksize=n

Only available with the ` ris-axis-aout' target. Arranges for indi ations in
the program to the kernel loader that the sta k of the program should be set
to n bytes.

-metrax4
-metrax100

The options `-metrax4' and `-metrax100' are synonyms for `-mar h=v3' and
`-mar h=v8' respe tively.

-mmul-bug-workaround
-mno-mul-bug-workaround

Work around a bug in the muls and mulu instru tions for CPU models where
it applies. This option is a tive by default.

Chapter 3: GCC Command Options

115

-mpdebug Enable CRIS-spe i verbose debug-related information in the assembly ode.

This option also has the ee t to turn o the `#NO_APP' formatted- ode indi ator

to the assembler at the beginning of the assembly le.

-m -init

Do not use ondition- ode results from previous instru tion; always emit ompare and test instru tions before use of ondition odes.

-mno-side-effe ts

Do not emit instru tions with side-ee ts in addressing modes other than postin rement.

-msta k-align
-mno-sta k-align
-mdata-align
-mno-data-align
-m onst-align
-mno- onst-align

These options (no-options) arranges (eliminate arrangements) for the sta kframe, individual data and onstants to be aligned for the maximum single
data a ess size for the hosen CPU model. The default is to arrange for 32bit alignment. ABI details su h as stru ture layout are not ae ted by these
options.

-m32-bit
-m16-bit
-m8-bit Similar to the sta k- data- and onst-align options above, these options arrange

for sta k-frame, writable data and onstants to all be 32-bit, 16-bit or 8-bit
aligned. The default is 32-bit alignment.

-mno-prologue-epilogue
-mprologue-epilogue
With `-mno-prologue-epilogue', the normal fun tion prologue and epilogue

that sets up the sta k-frame are omitted and no return instru tions or return
sequen es are generated in the ode. Use this option only together with visual
inspe tion of the ompiled ode: no warnings or errors are generated when
all-saved registers must be saved, or storage for lo al variable needs to be
allo ated.

-mno-gotplt
-mgotplt With `-fpi ' and `-fPIC', don't generate (do generate) instru tion sequen es

that load addresses for fun tions from the PLT part of the GOT rather than
(traditional on other ar hite tures) alls to the PLT. The default is `-mgotplt'.
-maout
Lega y no-op option only re ognized with the ris-axis-aout target.
-melf
Lega y no-op option only re ognized with the ris-axis-elf and ris-axis-linuxgnu targets.
-melinux Only re ognized with the ris-axis-aout target, where it sele ts a GNU/linuxlike multilib, in lude les and instru tion set for `-mar h=v8'.
-mlinux Lega y no-op option only re ognized with the ris-axis-linux-gnu target.

116

-sim

-sim2

Using the GNU Compiler Colle tion (GCC)

This option, re ognized for the ris-axis-aout and ris-axis-elf arranges to link
with input-output fun tions from a simulator library. Code, initialized data
and zero-initialized data are allo ated onse utively.
Like `-sim', but pass linker options to lo ate initialized data at 0x40000000 and
zero-initialized data at 0x80000000.

3.17.5 Darwin Options

These options are dened for all ar hite tures running the Darwin operating system.
FSF GCC on Darwin does not reate \fat" obje t les; it will reate an obje t le for
the single ar hite ture that it was built to target. Apple's GCC on Darwin does reate
\fat" les if multiple `-ar h' options are used; it does so by running the ompiler or linker
multiple times and joining the results together with `lipo'.
The subtype of the le reated (like `pp 7400' or `pp 970' or `i686') is determined
by the ags that spe ify the ISA that GCC is targetting, like `-m pu' or `-mar h'. The
`-for e_ pusubtype_ALL' option an be used to override this.
The Darwin tools vary in their behavior when presented with an ISA mismat h. The
assembler, `as', will only permit instru tions to be used that are valid for the subtype of
the le it is generating, so you annot put 64-bit instru tions in an `pp 750' obje t le.
The linker for shared libraries, `/usr/bin/libtool', will fail and print an error if asked
to reate a shared library with a less restri tive subtype than its input les (for instan e,
trying to put a `pp 970' obje t le in a `pp 7400' library). The linker for exe utables, `ld',
will quietly give the exe utable the most restri tive subtype of any of its input les.
-Fdir
Add the framework dire tory dir to the head of the list of dire tories to be
sear hed for header les. These dire tories are interleaved with those spe ied
by `-I' options and are s anned in a left-to-right order.
A framework dire tory is a dire tory with frameworks in it. A framework is a
dire tory with a `"Headers"' and/or `"PrivateHeaders"' dire tory ontained
dire tly in it that ends in `".framework"'. The name of a framework is the
name of this dire tory ex luding the `".framework"'. Headers asso iated with
the framework are found in one of those two dire tories, with `"Headers"'
being sear hed rst. A subframework is a framework dire tory that is in a
framework's `"Frameworks"' dire tory. In ludes of subframework headers an
only appear in a header of a framework that ontains the subframework,
or in a sibling subframework header. Two subframeworks are siblings if
they o ur in the same framework. A subframework should not have the
same name as a framework, a warning will be issued if this is violated.
Currently a subframework annot have subframeworks, in the future, the
me hanism may be extended to support this. The standard frameworks an be
found in `"/System/Library/Frameworks"' and `"/Library/Frameworks"'.
An example in lude looks like #in lude <Framework/header.h>, where
`Framework' denotes the name of the framework and header.h is found in the
`"PrivateHeaders"' or `"Headers"' dire tory.
-gused
Emit debugging information for symbols that are used. For STABS debugging
format, this enables `-feliminate-unused-debug-symbols'. This is by default
ON.

Chapter 3: GCC Command Options

-gfull

117

Emit debugging information for all symbols and types.

-mone-byte-bool

Override the defaults for `bool' so that `sizeof(bool)==1'. By default

`sizeof(bool)' is `4' when ompiling for Darwin/PowerPC and `1' when
ompiling for Darwin/x86, so this option has no ee t on x86.
The `-mone-byte-bool' swit h auses GCC to generate ode that
is not binary ompatible with ode generated without that swit h. Using this
swit h may require re ompiling all other modules in a program, in luding system libraries. Use this swit h to onform to a non-default data model.
Warning:

-mfix-and- ontinue
-ffix-and- ontinue
-findire t-data

Generate ode suitable for fast turn around development. Needed to enable gdb
to dynami ally load .o les into already running programs. `-findire t-data'
and `-ffix-and- ontinue' are provided for ba kwards ompatibility.

-all_load

Loads all members of stati ar hive libraries. See man ld(1) for more information.

-ar h_errors_fatal

Cause the errors having to do with les that have the wrong ar hite ture to be
fatal.

-bind_at_load

Causes the output le to be marked su h that the dynami linker will bind all
undened referen es when the le is loaded or laun hed.

-bundle

Produ e a Ma h-o bundle format le. See man ld(1) for more information.

-bundle_loader exe utable

This option spe ies the exe utable that will be loading the build output le
being linked. See man ld(1) for more information.

-dynami lib

When passed this option, GCC will produ e a dynami library instead of an
exe utable when linking, using the Darwin `libtool' ommand.

-for e_ pusubtype_ALL

This auses GCC's output le to have the ALL subtype, instead of one ontrolled by the `-m pu' or `-mar h' option.

118

-allowable_ lient lient_name

- lient_name
- ompatibility_version
- urrent_version
-dead_strip
-dependen y-file
-dylib_file
-dylinker_install_name
-dynami
-exported_symbols_list
-filelist
-flat_namespa e
-for e_flat_namespa e
-headerpad_max_install_names
-image_base
-init
-install_name
-keep_private_externs
-multi_module
-multiply_defined
-multiply_defined_unused
-noall_load
-no_dead_strip_inits_and_terms
-nofixprebinding
-nomultidefs
-noprebind
-noseglinkedit
-pagezero_size
-prebind
-prebind_all_twolevel_modules
-private_bundle
-read_only_relo s
-se talign
-se tobje tsymbols
-whyload
-seg1addr
-se t reate
-se tobje tsymbols
-se torder
-segaddr
-segs_read_only_addr
-segs_read_write_addr
-seg_addr_table
-seg_addr_table_filename
-seglinkedit
-segprot
-segs_read_only_addr
-segs_read_write_addr
-single_module
-stati
-sub_library
-sub_umbrella
-twolevel_namespa e
-umbrella
-undefined
-unexported_symbols_list

Using the GNU Compiler Colle tion (GCC)

Chapter 3: GCC Command Options

119

3.17.6 DEC Alpha Options

These `-m' options are dened for the DEC Alpha implementations:
-mno-soft-float
-msoft-float

Use (do not use) the hardware oating-point instru tions for oating-point operations. When `-msoft-float' is spe ied, fun tions in `libg .a' will be
used to perform oating-point operations. Unless they are repla ed by routines
that emulate the oating-point operations, or ompiled in su h a way as to all
su h emulations routines, these routines will issue oating-point operations. If
you are ompiling for an Alpha without oating-point operations, you must
ensure that the library is built so as not to all them.

Note that Alpha implementations without oating-point operations are required

to have oating-point registers.
-mfp-reg
-mno-fp-regs

Generate ode that uses (does not use) the oating-point register set.
`-mno-fp-regs' implies `-msoft-float'. If the oating-point register set is
not used, oating point operands are passed in integer registers as if they were
integers and oating-point results are passed in $0 instead of $f0. This is a
non-standard alling sequen e, so any fun tion with a oating-point argument
or return value alled by ode ompiled with `-mno-fp-regs' must also be
ompiled with that option.
A typi al use of this option is building a kernel that does not use, and hen e
need not save and restore, any oating-point registers.

-mieee

The Alpha ar hite ture implements oating-point hardware optimized for maximum performan e. It is mostly ompliant with the IEEE oating point standard. However, for full omplian e, software assistan e is required. This option
generates ode fully IEEE ompliant ode ex ept that the inexa t- ag is not
maintained (see below). If this option is turned on, the prepro essor ma ro
_IEEE_FP is dened during ompilation. The resulting ode is less e ient but
is able to orre tly support denormalized numbers and ex eptional IEEE values
su h as not-a-number and plus/minus innity. Other Alpha ompilers all this
option `-ieee_with_no_inexa t'.

-mieee-with-inexa t

This is like `-mieee' ex ept the generated ode also maintains the IEEE inexa t ag. Turning on this option auses the generated ode to implement fully ompliant IEEE math. In addition to _IEEE_FP, _IEEE_FP_EXACT is dened as
a prepro essor ma ro. On some Alpha implementations the resulting ode may
exe ute signi antly slower than the ode generated by default. Sin e there is
very little ode that depends on the inexa t- ag, you should normally not spe ify this option. Other Alpha ompilers all this option `-ieee_with_inexa t'.

120

Using the GNU Compiler Colle tion (GCC)

-mfp-trap-mode=trap-mode

This option ontrols what oating-point related traps are enabled. Other Alpha
ompilers all this option `-fptm trap-mode '. The trap mode an be set to one
of four values:
`n'

This is the default (normal) setting. The only traps that are enabled are the ones that annot be disabled in software (e.g., division
by zero trap).

`u'

In addition to the traps enabled by `n', under ow traps are enabled

as well.

`su'

Like `su', but the instru tions are marked to be safe for software
ompletion (see Alpha ar hite ture manual for details).

`sui'

Like `su', but inexa t traps are enabled as well.

-mfp-rounding-mode=rounding-mode

Sele ts the IEEE rounding mode. Other Alpha ompilers all this option `-fprm

rounding-mode '. The rounding-mode an be one of:

`n'

Normal IEEE rounding mode. Floating point numbers are rounded

towards the nearest ma hine number or towards the even ma hine
number in ase of a tie.

`m'

Round towards minus innity.

` '

Chopped rounding mode. Floating point numbers are rounded towards zero.

`d'

Dynami rounding mode. A eld in the oating point ontrol register (fp r, see Alpha ar hite ture referen e manual) ontrols the
rounding mode in ee t. The C library initializes this register for
rounding towards plus innity. Thus, unless your program modies
the fp r, `d' orresponds to round towards plus innity.

-mtrap-pre ision=trap-pre ision

In the Alpha ar hite ture, oating point traps are impre ise. This means without software assistan e it is impossible to re over from a oating trap and
program exe ution normally needs to be terminated. GCC an generate ode
that an assist operating system trap handlers in determining the exa t lo ation that aused a oating point trap. Depending on the requirements of an
appli ation, dierent levels of pre isions an be sele ted:
`p'

Program pre ision. This option is the default and means a trap
handler an only identify whi h program aused a oating point
ex eption.

`f'

Fun tion pre ision. The trap handler an determine the fun tion
that aused a oating point ex eption.

`i'

Instru tion pre ision. The trap handler an determine the exa t
instru tion that aused a oating point ex eption.

Chapter 3: GCC Command Options

121

Other Alpha ompilers provide the equivalent options alled `-s ope_safe' and
`-resumption_safe'.
-mieee- onformant

This option marks the generated ode as IEEE onformant. You must not
use this option unless you also spe ify `-mtrap-pre ision=i' and either
`-mfp-trap-mode=su' or `-mfp-trap-mode=sui'. Its only ee t is to emit the
line `.eflag 48' in the fun tion prologue of the generated assembly le. Under
DEC Unix, this has the ee t that IEEE- onformant math library routines
will be linked in.

-mbuild- onstants

Normally GCC examines a 32- or 64-bit integer onstant to see if it an onstru t

it from smaller onstants in two or three instru tions. If it annot, it will output
the onstant as a literal and generate ode to load it from the data segment at
runtime.
Use this option to require GCC to onstru t all integer onstants using ode,
even if it takes more instru tions (the maximum is six).
You would typi ally use this option to build a shared library dynami loader.
Itself a shared library, it must relo ate itself in memory before it an nd the
variables and onstants in its own data segment.

-malpha-as
-mgas
Sele t whether to generate ode to be assembled by the vendor-supplied assembler (`-malpha-as') or by the GNU assembler `-mgas'.
-mbwx
-mno-bwx
-m ix
-mno- ix
-mfix
-mno-fix
-mmax
-mno-max Indi ate whether GCC should generate ode to use the optional BWX, CIX, FIX

and MAX instru tion sets. The default is to use the instru tion sets supported
by the CPU type spe ied via `-m pu=' option or that of the CPU on whi h
GCC was built if none was spe ied.

-mfloat-vax
-mfloat-ieee

Generate ode that uses (does not use) VAX F and G oating point arithmeti
instead of IEEE single and double pre ision.

-mexpli it-relo s
-mno-expli it-relo s

Older Alpha assemblers provided no way to generate symbol relo ations ex ept
via assembler ma ros. Use of these ma ros does not allow optimal instru tion
s heduling. GNU binutils as of version 2.12 supports a new syntax that allows the ompiler to expli itly mark whi h relo ations should apply to whi h

122

Using the GNU Compiler Colle tion (GCC)

instru tions. This option is mostly useful for debugging, as GCC dete ts the
apabilities of the assembler when it is built and sets the default a ordingly.
-msmall-data
-mlarge-data

When `-mexpli it-relo s' is in ee t, stati data is a essed via gp-relative

relo ations. When `-msmall-data' is used, obje ts 8 bytes long or smaller are
pla ed in a small data area (the .sdata and .sbss se tions) and are a essed
via 16-bit relo ations o of the $gp register. This limits the size of the small
data area to 64KB, but allows the variables to be dire tly a essed via a single
instru tion.
The default is `-mlarge-data'. With this option the data area is limited to just
below 2GB. Programs that require more than 2GB of data must use mallo or
mmap to allo ate the data in the heap instead of in the program's data segment.
When generating ode for shared libraries, `-fpi ' implies `-msmall-data' and
`-fPIC' implies `-mlarge-data'.

-msmall-text
-mlarge-text

When `-msmall-text' is used, the ompiler assumes that the ode of the entire
program (or shared library) ts in 4MB, and is thus rea hable with a bran h instru tion. When `-msmall-data' is used, the ompiler an assume that all lo al
symbols share the same $gp value, and thus redu e the number of instru tions
required for a fun tion all from 4 to 1.
The default is `-mlarge-text'.

-m pu= pu_type

Set the instru tion set and instru tion s heduling parameters for ma hine type
pu type. You an spe ify either the `EV' style name or the orresponding hip
number. GCC supports s heduling parameters for the EV4, EV5 and EV6
family of pro essors and will hoose the default values for the instru tion set
from the pro essor you spe ify. If you do not spe ify a pro essor type, GCC
will default to the pro essor on whi h the ompiler was built.
Supported values for pu type are
`ev4'
`ev45'
`21064'

S hedules as an EV4 and has no instru tion set extensions.

`ev5'
`21164'

S hedules as an EV5 and has no instru tion set extensions.

`ev56'
`21164a'

S hedules as an EV5 and supports the BWX extension.

`p a56'
`21164p '
`21164PC' S hedules as an EV5 and supports the BWX and MAX extensions.

Chapter 3: GCC Command Options

`ev6'
`21264'
`ev67'
`21264a'

123

S hedules as an EV6 and supports the BWX, FIX, and MAX extensions.
S hedules as an EV6 and supports the BWX, CIX, FIX, and MAX
extensions.

-mtune= pu_type

Set only the instru tion s heduling parameters for ma hine type pu type. The
instru tion set is not hanged.

-mmemory-laten y=time

Sets the laten y the s heduler should assume for typi al memory referen es
as seen by the appli ation. This number is highly dependent on the memory
a ess patterns used by the appli ation and the size of the external a he on
the ma hine.
Valid options for time are
`number ' A de imal number representing lo k y les.
`L1'
`L2'
`L3'
`main'
The ompiler ontains estimates of the number of lo k y les for
\typi al" EV4 & EV5 hardware for the Level 1, 2 & 3 a hes (also
alled D a he, S a he, and B a he), as well as to main memory.
Note that L3 is only valid for EV5.

3.17.7 DEC Alpha/VMS Options

These `-m' options are dened for the DEC Alpha/VMS implementations:

-mvms-return- odes

Return VMS ondition odes from main. The default is to return POSIX style
ondition (e.g. error) odes.

3.17.8 FRV Options

-mgpr-32
-mgpr-64
-mfpr-32
-mfpr-64

Only use the rst 32 general purpose registers.

Use all 64 general purpose registers.
Use only the rst 32 oating point registers.
Use all 64 oating point registers

-mhard-float

Use hardware instru tions for oating point operations.

124

Using the GNU Compiler Colle tion (GCC)

-msoft-float

Use library routines for oating point operations.

-mallo -

Dynami ally allo ate ondition ode registers.

-mfixed-

Do not try to dynami ally allo ate ondition ode registers, only use i 0 and

f 0.
-mdword

Change ABI to use double word insns.

-mno-dword

Do not use double word instru tions.

-mdouble

Use oating point double instru tions.

-mno-double

Do not use oating point double instru tions.

-mmedia

Use media instru tions.

-mno-media

Do not use media instru tions.

-mmuladd

Use multiply and add/subtra t instru tions.

-mno-muladd

Do not use multiply and add/subtra t instru tions.

-mfdpi

Sele t the FDPIC ABI, that uses fun tion des riptors to represent pointers to
fun tions. Without any PIC/PIE-related options, it implies `-fPIE'. With
`-fpi ' or `-fpie', it assumes GOT entries and small data are within a 12-bit
range from the GOT base address; with `-fPIC' or `-fPIE', GOT osets are
omputed with 32 bits.

-minline-plt

Enable inlining of PLT entries in fun tion alls to fun tions that are not known
to bind lo ally. It has no ee t without `-mfdpi '. It's enabled by default if
optimizing for speed and ompiling for shared libraries (i.e., `-fPIC' or `-fpi '),
or when an optimization option su h as `-O3' or above is present in the ommand
line.

-mTLS

Assume a large TLS segment when generating thread-lo al ode.

-mtls

Do not assume a large TLS segment when generating thread-lo al ode.

Chapter 3: GCC Command Options

125

-mgprel-ro

Enable the use of GPREL relo ations in the FDPIC ABI for data that is known to
be in read-only se tions. It's enabled by default, ex ept for `-fpi ' or `-fpie':
even though it may help make the global oset table smaller, it trades 1 instru tion for 4. With `-fPIC' or `-fPIE', it trades 3 instru tions for 4, one of
whi h may be shared by multiple symbols, and it avoids the need for a GOT
entry for the referen ed symbol, so it's more likely to be a win. If it is not,
`-mno-gprel-ro' an be used to disable it.

-multilib-library-pi

Link with the (library, not FD) pi libraries. It's implied by `-mlibrary-pi ',
as well as by `-fPIC' and `-fpi ' without `-mfdpi '. You should never have to
use it expli itly.

-mlinked-fp

Follow the EABI requirement of always reating a frame pointer whenever a

sta k frame is allo ated. This option is enabled by default and an be disabled
with `-mno-linked-fp'.

-mlong- alls

Use indire t addressing to all fun tions outside the urrent ompilation unit.
This allows the fun tions to be pla ed anywhere within the 32-bit address spa e.

-malign-labels

Try to align labels to an 8-byte boundary by inserting nops into the previous
pa ket. This option only has an ee t when VLIW pa king is enabled. It
doesn't reate new pa kets; it merely adds nops to existing ones.

-mlibrary-pi

Generate position-independent EABI ode.

-ma -4
-ma -8
-mpa k
-mno-pa k

Use only the rst four media a umulator registers.

Use all eight media a umulator registers.
Pa k VLIW instru tions.
Do not pa k VLIW instru tions.

-mno-eflags

Do not mark ABI swit hes in e ags.

-m ond-move

Enable the use of onditional-move instru tions (default).

This swit h is mainly for debugging the ompiler and will likely be removed in
a future version.

-mno- ond-move

Disable the use of onditional-move instru tions.

126

Using the GNU Compiler Colle tion (GCC)

This swit h is mainly for debugging the ompiler and will likely be removed in
a future version.
-ms

-mno-s

Enable the use of onditional set instru tions (default).

This swit h is mainly for debugging the ompiler and will likely be removed in
a future version.
Disable the use of onditional set instru tions.
This swit h is mainly for debugging the ompiler and will likely be removed in
a future version.

-m ond-exe

Enable the use of onditional exe ution (default).

This swit h is mainly for debugging the ompiler and will likely be removed in
a future version.

-mno- ond-exe

Disable the use of onditional exe ution.

This swit h is mainly for debugging the ompiler and will likely be removed in
a future version.

-mvliw-bran h

Run a pass to pa k bran hes into VLIW instru tions (default).

This swit h is mainly for debugging the ompiler and will likely be removed in
a future version.

-mno-vliw-bran h

Do not run a pass to pa k bran hes into VLIW instru tions.

This swit h is mainly for debugging the ompiler and will likely be removed in
a future version.

-mmulti- ond-exe

Enable optimization of && and || in onditional exe ution (default).

This swit h is mainly for debugging the ompiler and will likely be removed in
a future version.

-mno-multi- ond-exe

Disable optimization of && and || in onditional exe ution.

This swit h is mainly for debugging the ompiler and will likely be removed in
a future version.

-mnested- ond-exe

Enable nested onditional exe ution optimizations (default).

This swit h is mainly for debugging the ompiler and will likely be removed in
a future version.

-mno-nested- ond-exe

Disable nested onditional exe ution optimizations.

Chapter 3: GCC Command Options

127

This swit h is mainly for debugging the ompiler and will likely be removed in
a future version.
-mtom at-stats

Cause gas to print out tom at statisti s.

-m pu= pu

Sele t the pro essor type for whi h to generate ode. Possible values are `frv',
`fr550', `tom at', `fr500', `fr450', `fr405', `fr400', `fr300' and `simple'.

3.17.9 H8/300 Options

These `-m' options are dened for the H8/300 implementations:

-mrelax

Shorten some address referen es at link time, when possible; uses the linker
option `-relax'. See se tion \ld and the H8/300" in Using ld, for a fuller
des ription.

-mh

Generate ode for the H8/300H.

-ms

Generate ode for the H8S.

-mn

Generate ode for the H8S and H8/300H in the normal mode. This swit h must
be used either with `-mh' or `-ms'.

-ms2600

Generate ode for the H8S/2600. This swit h must be used with `-ms'.

-mint32

Make int data 32 bits by default.

-malign-300

On the H8/300H and H8S, use the same alignment rules as for the H8/300.
The default for the H8/300H and H8S is to align longs and oats on 4 byte
boundaries. `-malign-300' auses them to be aligned on 2 byte boundaries.
This option has no ee t on the H8/300.

3.17.10 HPPA Options

These `-m' options are dened for the HPPA family of omputers:
-mar h=ar hite ture-type

Generate ode for the spe ied ar hite ture. The hoi es for ar hite ture-type
are `1.0' for PA 1.0, `1.1' for PA 1.1, and `2.0' for PA 2.0 pro essors. Refer
to `/usr/lib/s hed.models' on an HP-UX system to determine the proper
ar hite ture option for your ma hine. Code ompiled for lower numbered ar hite tures will run on higher numbered ar hite tures, but not the other way
around.

-mpa-ris -1-0
-mpa-ris -1-1
-mpa-ris -2-0

Synonyms for `-mar h=1.0', `-mar h=1.1', and `-mar h=2.0' respe tively.

-mbig-swit h

Generate ode suitable for big swit h tables. Use this option only if the assembler/linker omplain about out of range bran hes within a swit h table.

128

Using the GNU Compiler Colle tion (GCC)

-mjump-in-delay

Fill delay slots of fun tion alls with un onditional jump instru tions by modifying the return pointer for the fun tion all to be the target of the onditional
jump.

-mdisable-fpregs

Prevent oating point registers from being used in any manner. This is ne essary for ompiling kernels whi h perform lazy ontext swit hing of oating
point registers. If you use this option and attempt to perform oating point
operations, the ompiler will abort.

-mdisable-indexing

Prevent the ompiler from using indexing address modes. This avoids some
rather obs ure problems when ompiling MIG generated ode under MACH.

-mno-spa e-regs

Generate ode that assumes the target has no spa e registers. This allows GCC
to generate faster indire t alls and use uns aled index address modes.
Su h ode is suitable for level 0 PA systems and kernels.

-mfast-indire t- alls

Generate ode that assumes alls never ross spa e boundaries. This allows
GCC to emit ode whi h performs faster indire t alls.
This option will not work in the presen e of shared libraries or nested fun tions.

-mfixed-range=register-range

Generate ode treating the given register range as xed registers. A xed
register is one that the register allo ator an not use. This is useful when
ompiling kernel ode. A register range is spe ied as two registers separated
by a dash. Multiple register ranges an be spe ied separated by a omma.

-mlong-load-store

Generate 3-instru tion load and store sequen es as sometimes required by the
HP-UX 10 linker. This is equivalent to the `+k' option to the HP ompilers.

-mportable-runtime
-mgas

Use the portable alling onventions proposed by HP for ELF systems.

Enable the use of assembler dire tives only GAS understands.

-ms hedule= pu-type

S hedule ode a ording to the onstraints for the ma hine type pu-type. The
hoi es for pu-type are `700' `7100', `7100LC', `7200', `7300' and `8000'. Refer
to `/usr/lib/s hed.models' on an HP-UX system to determine the proper
s heduling option for your ma hine. The default s heduling is `8000'.

-mlinker-opt

Enable the optimization pass in the HP-UX linker. Note this makes symboli
debugging impossible. It also triggers a bug in the HP-UX 8 and HP-UX 9
linkers in whi h they give bogus error messages when linking some programs.

-msoft-float

Generate output ontaining library alls for oating point. Warning: the requisite libraries are not available for all HPPA targets. Normally the fa ilities of

Chapter 3: GCC Command Options

129

the ma hine's usual C ompiler are used, but this annot be done dire tly in
ross- ompilation. You must make your own arrangements to provide suitable
library fun tions for ross- ompilation. The embedded target `hppa1.1-*-pro'
does provide software oating point support.
`-msoft-float' hanges the alling onvention in the output le; therefore, it
is only useful if you ompile all of a program with this option. In parti ular, you need to ompile `libg .a', the library that omes with GCC, with
`-msoft-float' in order for this to work.
-msio
Generate the predene, _SIO, for server IO. The default is `-mwsio'. This generates the predenes, __hp9000s700, __hp9000s700__ and _WSIO, for workstation IO. These options are available under HP-UX and HI-UX.
-mgnu-ld Use GNU ld spe i options. This passes `-shared' to ld when building a shared
library. It is the default when GCC is ongured, expli itly or impli itly, with
the GNU linker. This option does not have any ae t on whi h ld is alled, it
only hanges what parameters are passed to that ld. The ld that is alled is
determined by the `--with-ld' ongure option, GCC's program sear h path,
and nally by the user's PATH. The linker used by GCC an be printed using
`whi h `g -print-prog-name=ld`'.
-mhp-ld Use HP ld spe i options. This passes `-b' to ld when building a shared library
and passes `+A ept TypeMismat h' to ld on all links. It is the default when
GCC is ongured, expli itly or impli itly, with the HP linker. This option does
not have any ae t on whi h ld is alled, it only hanges what parameters are
passed to that ld. The ld that is alled is determined by the `--with-ld' ongure option, GCC's program sear h path, and nally by the user's PATH. The
linker used by GCC an be printed using `whi h `g -print-prog-name=ld`'.
-mlong- alls

Generate ode that uses long all sequen es. This ensures that a all is always
able to rea h linker generated stubs. The default is to generate long alls
only when the distan e from the all site to the beginning of the fun tion or
translation unit, as the ase may be, ex eeds a predened limit set by the
bran h type being used. The limits for normal alls are 7,600,000 and 240,000
bytes, respe tively for the PA 2.0 and PA 1.X ar hite tures. Sib alls are always
limited at 240,000 bytes.
Distan es are measured from the beginning of fun tions when using
the `-ffun tion-se tions' option, or when using the `-mgas' and
`-mno-portable-runtime' options together under HP-UX with the SOM
linker.
It is normally not desirable to use this option as it will degrade performan e.
However, it may be useful in large appli ations, parti ularly when partial linking
is used to build the appli ation.
The types of long alls used depends on the apabilities of the assembler and
linker, and the type of ode being generated. The impa t on systems that
support long absolute alls, and long pi symbol-dieren e or p -relative alls
should be relatively small. However, an indire t all is used on 32-bit ELF
systems in pi ode and it is quite long.

130

Using the GNU Compiler Colle tion (GCC)

-munix=unix-std

Generate ompiler predenes and sele t a startle for the spe ied UNIX standard. The hoi es for unix-std are `93', `95' and `98'. `93' is supported on all
HP-UX versions. `95' is available on HP-UX 10.10 and later. `98' is available
on HP-UX 11.11 and later. The default values are `93' for HP-UX 10.00, `95'
for HP-UX 10.10 though to 11.00, and `98' for HP-UX 11.11 and later.
`-munix=93' provides the same predenes as GCC 3.3 and 3.4. `-munix=95'
provides additional predenes for XOPEN_UNIX and _XOPEN_SOURCE_EXTENDED,
and the startle `unix95.o'. `-munix=98' provides additional predenes for
_XOPEN_UNIX, _XOPEN_SOURCE_EXTENDED, _INCLUDE__STDC_A1_SOURCE and _
INCLUDE_XOPEN_SOURCE_500, and the startle `unix98.o'.
It is important to note that this option hanges the interfa es for various library
routines. It also ae ts the operational behavior of the C library. Thus, extreme
are is needed in using this option.
Library ode that is intended to operate with more than one UNIX standard
must test, set and restore the variable xpg4 extended mask as appropriate.
Most GNU software doesn't provide this apability.

-nolibdld

Suppress the generation of link options to sear h libdld.sl when the `-stati '
option is spe ied on HP-UX 10 and later.
-stati The HP-UX implementation of setlo ale in lib has a dependen y on libdld.sl.
There isn't an ar hive version of libdld.sl. Thus, when the `-stati ' option is
spe ied, spe ial link options are needed to resolve this dependen y.
On HP-UX 10 and later, the GCC driver adds the ne essary options to link
with libdld.sl when the `-stati ' option is spe ied. This auses the resulting
binary to be dynami . On the 64-bit port, the linkers generate dynami binaries
by default in any ase. The `-nolibdld' option an be used to prevent the GCC
driver from adding these link options.
-threads Add support for multithreading with the d e thread library under HP-UX. This
option sets ags for both the prepro essor and linker.

3.17.11 Intel 386 and AMD x86-64 Options

These `-m' options are dened for the i386 and x86-64 family of omputers:
-mtune= pu-type

Tune to pu-type everything appli able about the generated ode, ex ept for
the ABI and the set of available instru tions. The hoi es for pu-type are:
i386
Original Intel's i386 CPU.
i486
Intel's i486 CPU. (No s heduling is implemented for this hip.)
i586, pentium
Intel Pentium CPU with no MMX support.
pentium-mmx
Intel PentiumMMX CPU based on Pentium ore with MMX instru tion set support.

Chapter 3: GCC Command Options

131

i686, pentiumpro
Intel PentiumPro CPU.
pentium2

Intel Pentium2 CPU based on PentiumPro ore with MMX instru tion set support.

pentium3, pentium3m
Intel Pentium3 CPU based on PentiumPro ore with MMX and
SSE instru tion set support.
pentium-m

Low power version of Intel Pentium3 CPU with MMX, SSE and
SSE2 instru tion set support. Used by Centrino notebooks.

pentium4, pentium4m
Intel Pentium4 CPU with MMX, SSE and SSE2 instru tion set
support.
pres ott

Improved version of Intel Pentium4 CPU with MMX, SSE, SSE2

and SSE3 instru tion set support.

no ona

Improved version of Intel Pentium4 CPU with 64-bit extensions,

MMX, SSE, SSE2 and SSE3 instru tion set support.

k6

AMD K6 CPU with MMX instru tion set support.

k6-2, k6-3 Improved versions of AMD K6 CPU with MMX and 3dNOW! instru tion set support.
athlon, athlon-tbird
AMD Athlon CPU with MMX, 3dNOW!, enhan ed 3dNOW! and
SSE prefet h instru tions support.
athlon-4, athlon-xp, athlon-mp
Improved AMD Athlon CPU with MMX, 3dNOW!, enhan ed
3dNOW! and full SSE instru tion set support.
k8, opteron, athlon64, athlon-fx
AMD K8 ore based CPUs with x86-64 instru tion set support.
(This supersets MMX, SSE, SSE2, 3dNOW!, enhan ed 3dNOW!
and 64-bit instru tion set extensions.)
win hip- 6

IDT Win hip C6 CPU, dealt in same way as i486 with additional
MMX instru tion set support.

win hip2

IDT Win hip2 CPU, dealt in same way as i486 with additional
MMX and 3dNOW! instru tion set support.

Via C3 CPU with MMX and 3dNOW! instru tion set support. (No
s heduling is implemented for this hip.)

3-2

Via C3-2 CPU with MMX and SSE instru tion set support. (No
s heduling is implemented for this hip.)

132

Using the GNU Compiler Colle tion (GCC)

While pi king a spe i pu-type will s hedule things appropriately for that
parti ular hip, the ompiler will not generate any ode that does not run on
the i386 without the `-mar h= pu-type ' option being used.
-mar h= pu-type

Generate instru tions for the ma hine type pu-type. The hoi es for pu-type
are the same as for `-mtune'. Moreover, spe ifying `-mar h= pu-type ' implies
`-mtune= pu-type '.

-m pu= pu-type

A depre ated synonym for `-mtune'.

-m386
-m486
-mpentium
-mpentiumpro

These options are synonyms for `-mtune=i386', `-mtune=i486',

`-mtune=pentium', and `-mtune=pentiumpro' respe tively. These synonyms
are depre ated.

-mfpmath=unit

Generate oating point arithmeti s for sele ted unit unit. The hoi es for unit
are:
`387'

Use the standard 387 oating point opro essor present majority of
hips and emulated otherwise. Code ompiled with this option will
run almost everywhere. The temporary results are omputed in
80bit pre ision instead of pre ision spe ied by the type resulting
in slightly dierent results ompared to most of other hips. See
`-ffloat-store' for more detailed des ription.
This is the default hoi e for i386 ompiler.

`sse'

Use s alar oating point instru tions present in the SSE instru tion
set. This instru tion set is supported by Pentium3 and newer hips,
in the AMD line by Athlon-4, Athlon-xp and Athlon-mp hips. The
earlier version of SSE instru tion set supports only single pre ision
arithmeti s, thus the double and extended pre ision arithmeti s is
still done using 387. Later version, present only in Pentium4 and
the future AMD x86-64 hips supports double pre ision arithmeti s
too.
For the i386 ompiler, you need to use `-mar h= pu-type ', `-msse'
or `-msse2' swit hes to enable SSE extensions and make this option
ee tive. For the x86-64 ompiler, these extensions are enabled by
default.
The resulting ode should be onsiderably faster in the majority
of ases and avoid the numeri al instability problems of 387 ode,
but may break some existing ode that expe ts temporaries to be
80bit.
This is the default hoi e for the x86-64 ompiler.

Chapter 3: GCC Command Options

133

`sse,387' Attempt to utilize both instru tion sets at on e. This ee tively

double the amount of available registers and on hips with separate exe ution units for 387 and SSE the exe ution resour es too.
Use this option with are, as it is still experimental, be ause the
GCC register allo ator does not model separate fun tional units
well resulting in instable performan e.
-masm=diale t

Output asm instru tions using sele ted diale t. Supported hoi es are `intel'
or `att' (the default one).

-mieee-fp
-mno-ieee-fp

Control whether or not the ompiler uses IEEE oating point omparisons.
These handle orre tly the ase where the result of a omparison is unordered.

-msoft-float

Generate output ontaining library alls for oating point. Warning: the requisite libraries are not part of GCC. Normally the fa ilities of the ma hine's
usual C ompiler are used, but this an't be done dire tly in ross- ompilation.
You must make your own arrangements to provide suitable library fun tions
for ross- ompilation.
On ma hines where a fun tion returns oating point results in the 80387 register
sta k, some oating point op odes may be emitted even if `-msoft-float' is
used.

-mno-fp-ret-in-387

Do not use the FPU registers for return values of fun tions.
The usual alling onvention has fun tions return values of types float and
double in an FPU register, even if there is no FPU. The idea is that the
operating system should emulate an FPU.
The option `-mno-fp-ret-in-387' auses su h values to be returned in ordinary
CPU registers instead.

-mno-fan y-math-387

Some 387 emulators do not support the sin, os and sqrt instru tions for the
387. Spe ify this option to avoid generating those instru tions. This option
is the default on FreeBSD, OpenBSD and NetBSD. This option is overridden
when `-mar h' indi ates that the target pu will always have an FPU and so the
instru tion will not need emulation. As of revision 2.6.1, these instru tions are
not generated unless you also use the `-funsafe-math-optimizations' swit h.

-malign-double
-mno-align-double

Control whether GCC aligns double, long double, and long long variables on
a two word boundary or a one word boundary. Aligning double variables on a
two word boundary will produ e ode that runs somewhat faster on a `Pentium'
at the expense of more memory.
Warning: if you use the `-malign-double' swit h, stru tures ontaining the
above types will be aligned dierently than the published appli ation binary

134

Using the GNU Compiler Colle tion (GCC)

interfa e spe i ations for the 386 and will not be binary ompatible with stru tures in ode ompiled without that swit h.
-m96bit-long-double
-m128bit-long-double

These swit hes ontrol the size of long double type. The i386 appli ation
binary interfa e spe ies the size to be 96 bits, so `-m96bit-long-double' is
the default in 32 bit mode.
Modern ar hite tures (Pentium and newer) would prefer long double to be
aligned to an 8 or 16 byte boundary. In arrays or stru tures onforming to the
ABI, this would not be possible. So spe ifying a `-m128bit-long-double' will
align long double to a 16 byte boundary by padding the long double with an
additional 32 bit zero.
In the x86-64 ompiler, `-m128bit-long-double' is the default hoi e as its
ABI spe ies that long double is to be aligned on 16 byte boundary.
Noti e that neither of these options enable any extra pre ision over the x87
standard of 80 bits for a long double.
Warning: if you override the default value for your target ABI, the stru tures
and arrays ontaining long double variables will hange their size as well as
fun tion alling onvention for fun tion taking long double will be modied.
Hen e they will not be binary ompatible with arrays or stru tures in ode
ompiled without that swit h.

-msvr3-shlib
-mno-svr3-shlib

Control whether GCC pla es uninitialized lo al variables into the bss or data
segments. `-msvr3-shlib' pla es them into bss. These options are meaningful
only on System V Release 3.

-mrtd

Use a dierent fun tion- alling onvention, in whi h fun tions that take a xed
number of arguments return with the ret num instru tion, whi h pops their
arguments while returning. This saves one instru tion in the aller sin e there
is no need to pop the arguments there.
You an spe ify that an individual fun tion is alled with this alling sequen e
with the fun tion attribute `std all'. You an also override the `-mrtd' option
by using the fun tion attribute ` de l'. See Se tion 5.24 [Fun tion Attributes,
page 217.
Warning: this alling onvention is in ompatible with the one normally used on
Unix, so you annot use it if you need to all libraries ompiled with the Unix
ompiler.
Also, you must provide fun tion prototypes for all fun tions that take variable
numbers of arguments (in luding printf); otherwise in orre t ode will be
generated for alls to those fun tions.
In addition, seriously in orre t ode will result if you all a fun tion with too
many arguments. (Normally, extra arguments are harmlessly ignored.)

Chapter 3: GCC Command Options

135

-mregparm=num

Control how many registers are used to pass integer arguments. By default, no
registers are used to pass arguments, and at most 3 registers an be used. You
an ontrol this behavior for a spe i fun tion by using the fun tion attribute
`regparm'. See Se tion 5.24 [Fun tion Attributes, page 217.
Warning: if you use this swit h, and num is nonzero, then you must build all
modules with the same value, in luding any libraries. This in ludes the system
libraries and startup modules.

-mpreferred-sta k-boundary=num

Attempt to keep the sta k boundary aligned to a 2 raised to num byte boundary.
If `-mpreferred-sta k-boundary' is not spe ied, the default is 4 (16 bytes or
128 bits), ex ept when optimizing for ode size (`-Os'), in whi h ase the default
is the minimum orre t alignment (4 bytes for x86, and 8 bytes for x86-64).
On Pentium and PentiumPro, double and long double values should be
aligned to an 8 byte boundary (see `-malign-double') or suer signi ant run
time performan e penalties. On Pentium III, the Streaming SIMD Extension
(SSE) data type __m128 suers similar penalties if it is not 16 byte aligned.
To ensure proper alignment of this values on the sta k, the sta k boundary must
be as aligned as that required by any value stored on the sta k. Further, every
fun tion must be generated su h that it keeps the sta k aligned. Thus alling
a fun tion ompiled with a higher preferred sta k boundary from a fun tion
ompiled with a lower preferred sta k boundary will most likely misalign the
sta k. It is re ommended that libraries that use allba ks always use the default
setting.
This extra alignment does onsume extra sta k spa e, and generally in reases
ode size. Code that is sensitive to sta k spa e usage, su h as embedded systems
and operating system kernels, may want to redu e the preferred alignment to
`-mpreferred-sta k-boundary=2'.

-mmmx
-mno-mmx
-msse
-mno-sse
-msse2
-mno-sse2
-msse3
-mno-sse3
-m3dnow
-mno-3dnow

These swit hes enable or disable the use of built-in fun tions that allow dire t
a ess to the MMX, SSE, SSE2, SSE3 and 3Dnow extensions of the instru tion
set.
See Se tion 5.45.4 [X86 Built-in Fun tions, page 286, for details of the fun tions
enabled and disabled by these swit hes.

136

Using the GNU Compiler Colle tion (GCC)

To have SSE/SSE2 instru tions generated automati ally from oating-point

ode, see `-mfpmath=sse'.
-mpush-args
-mno-push-args

Use PUSH operations to store outgoing parameters. This method is shorter

and usually equally fast as method using SUB/MOV operations and is enabled
by default. In some ases disabling it may improve performan e be ause of
improved s heduling and redu ed dependen ies.

-ma umulate-outgoing-args

If enabled, the maximum amount of spa e required for outgoing arguments will
be omputed in the fun tion prologue. This is faster on most modern CPUs
be ause of redu ed dependen ies, improved s heduling and redu ed sta k usage
when preferred sta k boundary is not equal to 2. The drawba k is a notable
in rease in ode size. This swit h implies `-mno-push-args'.

-mthreads

Support thread-safe ex eption handling on `Mingw32'. Code that relies on

thread-safe ex eption handling must ompile and link all ode with the
`-mthreads' option. When ompiling, `-mthreads' denes `-D_MT'; when
linking, it links in a spe ial thread helper library `-lmingwthrd' whi h leans
up per thread ex eption handling data.

-mno-align-stringops

Do not align destination of inlined string operations. This swit h redu es ode
size and improves performan e in ase the destination is already aligned, but
GCC doesn't know about it.

-minline-all-stringops

By default GCC inlines string operations only when destination is known to be

aligned at least to 4 byte boundary. This enables more inlining, in rease ode
size, but may improve performan e of ode that depends on fast mem py, strlen
and memset for short lengths.

-momit-leaf-frame-pointer

Don't keep the frame pointer in a register for leaf fun tions. This avoids the
instru tions to save, set up and restore frame pointers and makes an extra register available in leaf fun tions. The option `-fomit-frame-pointer' removes
the frame pointer for all fun tions whi h might make debugging harder.

-mtls-dire t-seg-refs
-mno-tls-dire t-seg-refs

Controls whether TLS variables may be a essed with osets from the TLS
segment register (%gs for 32-bit, %fs for 64-bit), or whether the thread base
pointer must be added. Whether or not this is legal depends on the operating
system, and whether it maps the segment to over the entire TLS area.
For systems that use GNU lib , the default is on.

These `-m' swit hes are supported in addition to the above on AMD x86-64 pro essors in
64-bit environments.

Chapter 3: GCC Command Options

-m32
-m64

137

Generate ode for a 32-bit or 64-bit environment. The 32-bit environment sets
int, long and pointer to 32 bits and generates ode that runs on any i386 system.
The 64-bit environment sets int to 32 bits and long and pointer to 64 bits and
generates ode for AMD's x86-64 ar hite ture.

-mno-red-zone

Do not use a so alled red zone for x86-64 ode. The red zone is mandated by the
x86-64 ABI, it is a 128-byte area beyond the lo ation of the sta k pointer that
will not be modied by signal or interrupt handlers and therefore an be used for
temporary data without adjusting the sta k pointer. The ag `-mno-red-zone'
disables this red zone.

-m model=small

Generate ode for the small ode model: the program and its symbols must be
linked in the lower 2 GB of the address spa e. Pointers are 64 bits. Programs
an be stati ally or dynami ally linked. This is the default ode model.

-m model=kernel

Generate ode for the kernel ode model. The kernel runs in the negative 2 GB
of the address spa e. This model has to be used for Linux kernel ode.

-m model=medium

Generate ode for the medium model: The program is linked in the lower 2
GB of the address spa e but symbols an be lo ated anywhere in the address
spa e. Programs an be stati ally or dynami ally linked, but building of shared
libraries are not supported with the medium model.

-m model=large

Generate ode for the large model: This model makes no assumptions about
addresses and sizes of se tions. Currently GCC does not implement this model.

3.17.12 IA-64 Options

These are the `-m' options dened for the Intel IA-64 ar hite ture.
-mbig-endian

Generate ode for a big endian target. This is the default for HP-UX.

-mlittle-endian

Generate ode for a little endian target. This is the default for AIX5 and
GNU/Linux.

-mgnu-as
-mno-gnu-as

Generate (or don't) ode for the GNU assembler. This is the default.

-mgnu-ld
-mno-gnu-ld

Generate (or don't) ode for the GNU linker. This is the default.

-mno-pi Generate ode that does not use a global pointer register. The result is not

position independent ode, and violates the IA-64 ABI.

138

Using the GNU Compiler Colle tion (GCC)

-mvolatile-asm-stop
-mno-volatile-asm-stop

Generate (or don't) a stop bit immediately before and after volatile asm statements.

-mregister-names
-mno-register-names

Generate (or don't) `in', `lo ', and `out' register names for the sta ked registers.
This may make assembler output more readable.

-mno-sdata
-msdata Disable (or enable) optimizations that use the small data se tion. This may be

useful for working around optimizer bugs.

-m onstant-gp

Generate ode that uses a single onstant global pointer value. This is useful
when ompiling kernel ode.

-mauto-pi

Generate ode that is self-relo atable. This implies `-m onstant-gp'. This is
useful when ompiling rmware ode.

-minline-float-divide-min-laten y

Generate ode for inline divides of oating point values using the minimum
laten y algorithm.

-minline-float-divide-max-throughput

Generate ode for inline divides of oating point values using the maximum
throughput algorithm.

-minline-int-divide-min-laten y

Generate ode for inline divides of integer values using the minimum laten y
algorithm.

-minline-int-divide-max-throughput

Generate ode for inline divides of integer values using the maximum throughput algorithm.

-minline-sqrt-min-laten y

Generate ode for inline square roots using the minimum laten y algorithm.

-minline-sqrt-max-throughput

Generate ode for inline square roots using the maximum throughput algorithm.

-mno-dwarf2-asm
-mdwarf2-asm

Don't (or do) generate assembler ode for the DWARF2 line number debugging
info. This may be useful when not using the GNU assembler.

-mearly-stop-bits
-mno-early-stop-bits

Allow stop bits to be pla ed earlier than immediately pre eding the instru tion
that triggered the stop bit. This an improve instru tion s heduling, but does
not always do so.

Chapter 3: GCC Command Options

139

-mfixed-range=register-range

Generate ode treating the given register range as xed registers. A xed
register is one that the register allo ator an not use. This is useful when
ompiling kernel ode. A register range is spe ied as two registers separated
by a dash. Multiple register ranges an be spe ied separated by a omma.

-mtls-size=tls-size

Spe ify bit size of immediate TLS osets. Valid values are 14, 22, and 64.

-mtune-ar h= pu-type

Tune the instru tion s heduling for a parti ular CPU, Valid values are itanium,
itanium1, mer ed, itanium2, and m kinley.

-mt
-pthread Add support for multithreading using the POSIX threads library. This option

sets ags for both the prepro essor and linker. It does not ae t the thread
safety of obje t ode produ ed by the ompiler or that of libraries supplied with
it. These are HP-UX spe i ags.

-milp32
-mlp64

Generate ode for a 32-bit or 64-bit environment. The 32-bit environment sets
int, long and pointer to 32 bits. The 64-bit environment sets int to 32 bits and
long and pointer to 64 bits. These are HP-UX spe i ags.

3.17.13 M32R/D Options

These `-m' options are dened for Renesas M32R/D ar hite tures:
-m32r2
Generate ode for the M32R/2.
-m32rx
Generate ode for the M32R/X.
-m32r
Generate ode for the M32R. This is the default.
-mmodel=small

Assume all obje ts live in the lower 16MB of memory (so that their addresses
an be loaded with the ld24 instru tion), and assume all subroutines are rea hable with the bl instru tion. This is the default.
The addressability of a parti ular obje t an be set with the model attribute.

-mmodel=medium

Assume obje ts may be anywhere in the 32-bit address spa e (the ompiler
will generate seth/add3 instru tions to load their addresses), and assume all
subroutines are rea hable with the bl instru tion.

-mmodel=large

Assume obje ts may be anywhere in the 32-bit address spa e (the ompiler will
generate seth/add3 instru tions to load their addresses), and assume subroutines may not be rea hable with the bl instru tion (the ompiler will generate
the mu h slower seth/add3/jl instru tion sequen e).

-msdata=none

Disable use of the small data area. Variables will be put into one of `.data',
`bss', or `.rodata' (unless the se tion attribute has been spe ied). This is
the default.

140

Using the GNU Compiler Colle tion (GCC)

The small data area onsists of se tions `.sdata' and `.sbss'. Obje ts may be
expli itly put in the small data area with the se tion attribute using one of
these se tions.
-msdata=sdata

Put small global and stati data in the small data area, but do not generate
spe ial ode to referen e them.

-msdata=use

Put small global and stati data in the small data area, and generate spe ial
instru tions to referen e them.

-G num

Put global and stati obje ts less than or equal to num bytes into the small
data or bss se tions instead of the normal data or bss se tions. The default
value of num is 8. The `-msdata' option must be set to one of `sdata' or `use'
for this option to have any ee t.
All modules should be ompiled with the same `-G num ' value. Compiling with
dierent values of num may or may not work; if it doesn't the linker will give
an error message|in orre t ode will not be generated.

-mdebug

Makes the M32R spe i ode in the ompiler display some statisti s that might
help in debugging programs.

-malign-loops

Align all loops to a 32-byte boundary.

-mno-align-loops

Do not enfor e a 32-byte alignment for loops. This is the default.

-missue-rate=number

Issue number instru tions per y le. number an only be 1 or 2.

-mbran h- ost=number

number an only be 1 or 2. If it is 1 then bran hes will be preferred over

onditional ode, if it is 2, then the opposite will apply.

-mflush-trap=number

Spe ies the trap number to use to ush the a he. The default is 12. Valid
numbers are between 0 and 15 in lusive.

-mno-flush-trap

Spe ies that the a he annot be ushed by using a trap.

-mflush-fun =name

Spe ies the name of the operating system fun tion to all to ush the a he.
The default is ush a he, but a fun tion all will only be used if a trap is not
available.

-mno-flush-fun

Indi ates that there is no OS fun tion for ushing the a he.

Chapter 3: GCC Command Options

141

3.17.14 M680x0 Options

These are the `-m' options dened for the 68000 series. The default values for these options
depends on whi h style of 68000 was sele ted when the ompiler was ongured; the defaults
for the most ommon hoi es are given below.
-m68000
-m 68000 Generate output for a 68000. This is the default when the ompiler is ongured

for 68000-based systems.

Use this option for mi ro ontrollers with a 68000 or EC000 ore, in luding the
68008, 68302, 68306, 68307, 68322, 68328 and 68356.

-m68020
-m 68020 Generate output for a 68020. This is the default when the ompiler is ongured

for 68020-based systems.

-m68881

Generate output ontaining 68881 instru tions for oating point. This is the
default for most 68020 systems unless `--nfp' was spe ied when the ompiler
was ongured.

-m68030

Generate output for a 68030. This is the default when the ompiler is ongured
for 68030-based systems.

-m68040

Generate output for a 68040. This is the default when the ompiler is ongured
for 68040-based systems.
This option inhibits the use of 68881/68882 instru tions that have to be emulated by software on the 68040. Use this option if your 68040 does not have
ode to emulate those instru tions.

-m68060

Generate output for a 68060. This is the default when the ompiler is ongured
for 68060-based systems.
This option inhibits the use of 68020 and 68881/68882 instru tions that have
to be emulated by software on the 68060. Use this option if your 68060 does
not have ode to emulate those instru tions.

-m pu32

Generate output for a CPU32. This is the default when the ompiler is ongured for CPU32-based systems.
Use this option for mi ro ontrollers with a CPU32 or CPU32+ ore, in luding
the 68330, 68331, 68332, 68333, 68334, 68336, 68340, 68341, 68349 and 68360.

-m5200

Generate output for a 520X \ oldre" family pu. This is the default when the
ompiler is ongured for 520X-based systems.
Use this option for mi ro ontroller with a 5200 ore, in luding the MCF5202,
MCF5203, MCF5204 and MCF5202.

-m68020-40

Generate output for a 68040, without using any of the new instru tions. This
results in ode whi h an run relatively e iently on either a 68020/68881 or a
68030 or a 68040. The generated ode does use the 68881 instru tions that are
emulated on the 68040.

142

Using the GNU Compiler Colle tion (GCC)

-m68020-60

Generate output for a 68060, without using any of the new instru tions. This
results in ode whi h an run relatively e iently on either a 68020/68881 or a
68030 or a 68040. The generated ode does use the 68881 instru tions that are
emulated on the 68060.

-msoft-float

-mshort

Generate output ontaining library alls for oating point. Warning: the requisite libraries are not available for all m68k targets. Normally the fa ilities
of the ma hine's usual C ompiler are used, but this an't be done dire tly in
ross- ompilation. You must make your own arrangements to provide suitable
library fun tions for ross- ompilation. The embedded targets `m68k-*-aout'
and `m68k-*- off' do provide software oating point support.
Consider type int to be 16 bits wide, like short int. Additionally, parameters
passed on the sta k are also aligned to a 16-bit boundary even on targets whose
API mandates promotion to 32-bit.

-mnobitfield

Do not use the bit-eld instru tions. The `-m68000', `-m pu32' and `-m5200'
options imply `-mnobitfield'.

-mbitfield

-mrtd

Do use the bit-eld instru tions. The `-m68020' option implies `-mbitfield'.
This is the default if you use a onguration designed for a 68020.
Use a dierent fun tion- alling onvention, in whi h fun tions that take a xed
number of arguments return with the rtd instru tion, whi h pops their arguments while returning. This saves one instru tion in the aller sin e there is no
need to pop the arguments there.
This alling onvention is in ompatible with the one normally used on Unix, so
you annot use it if you need to all libraries ompiled with the Unix ompiler.
Also, you must provide fun tion prototypes for all fun tions that take variable
numbers of arguments (in luding printf); otherwise in orre t ode will be
generated for alls to those fun tions.
In addition, seriously in orre t ode will result if you all a fun tion with too
many arguments. (Normally, extra arguments are harmlessly ignored.)
The rtd instru tion is supported by the 68010, 68020, 68030, 68040, 68060 and
CPU32 pro essors, but not by the 68000 or 5200.

-malign-int
-mno-align-int

Control whether GCC aligns int, long, long long, float, double, and long
double variables on a 32-bit boundary (`-malign-int') or a 16-bit boundary
(`-mno-align-int'). Aligning variables on 32-bit boundaries produ es ode
that runs somewhat faster on pro essors with 32-bit busses at the expense of
more memory.
Warning: if you use the `-malign-int' swit h, GCC will align stru tures ontaining the above types dierently than most published appli ation binary interfa e spe i ations for the m68k.

Chapter 3: GCC Command Options

143

Use the p -relative addressing mode of the 68000 dire tly, instead of using a
global oset table. At present, this option implies `-fpi ', allowing at most a
16-bit oset for p -relative addressing. `-fPIC' is not presently supported with
`-mp rel', though this ould be supported for 68020 and higher pro essors.

-mp rel

-mno-stri t-align
-mstri t-align

Do not (do) assume that unaligned memory referen es will be handled by the
system.

-msep-data

Generate ode that allows the data segment to be lo ated in a dierent area of
memory from the text segment. This allows for exe ute in pla e in an environment without virtual memory management. This option implies `-fPIC'.

-mno-sep-data

Generate ode that assumes that the data segment follows the text segment.
This is the default.

-mid-shared-library

Generate ode that supports shared libraries via the library ID method. This allows for exe ute in pla e and shared libraries in an environment without virtual
memory management. This option implies `-fPIC'.

-mno-id-shared-library

Generate ode that doesn't assume ID based shared libraries are being used.
This is the default.

-mshared-library-id=n

Spe ied the identi ation number of the ID based shared library being ompiled. Spe ifying a value of 0 will generate more ompa t ode, spe ifying other
values will for e the allo ation of that number to the urrent library but is no
more spa e or time e ient than omitting this option.

3.17.15 M68h 1x Options

These are the `-m' options dened for the 68h 11 and 68h 12 mi ro ontrollers. The default
values for these options depends on whi h style of mi ro ontroller was sele ted when the
ompiler was ongured; the defaults for the most ommon hoi es are given below.
-m6811
-m68h 11 Generate output for a 68HC11. This is the default when the ompiler is on-

gured for 68HC11-based systems.

-m6812
-m68h 12 Generate output for a 68HC12. This is the default when the ompiler is on-

gured for 68HC12-based systems.

-m68S12
-m68h s12

Generate output for a 68HCS12.

144

Using the GNU Compiler Colle tion (GCC)

-mauto-in de

Enable the use of 68HC12 pre and post auto-in rement and auto-de rement
addressing modes.

-minmax
-nominmax

Enable the use of 68HC12 min and max instru tions.

-mlong- alls
-mno-long- alls

Treat all alls as being far away (near). If alls are assumed to be far away, the
ompiler will use the all instru tion to all a fun tion and the rt instru tion
for returning.

-mshort

Consider type int to be 16 bits wide, like short int.

-msoft-reg- ount= ount

Spe ify the number of pseudo-soft registers whi h are used for the ode generation. The maximum number is 32. Using more pseudo-soft register may or
may not result in better ode depending on the program. The default is 4 for
68HC11 and 2 for 68HC12.

3.17.16 MCore Options

These are the `-m' options dened for the Motorola M*Core pro essors.
-mhardlit
-mno-hardlit

Inline onstants into the ode stream if it an be done in two instru tions or
less.

-mdiv
-mno-div Use the divide instru tion. (Enabled by default).
-mrelax-immediate
-mno-relax-immediate

Allow arbitrary sized immediates in bit operations.

-mwide-bitfields
-mno-wide-bitfields

Always treat bit-elds as int-sized.

-m4byte-fun tions
-mno-4byte-fun tions

For e all fun tions to be aligned to a four byte boundary.

-m allgraph-data
-mno- allgraph-data

Emit allgraph information.

-mslow-bytes
-mno-slow-bytes

Prefer word a ess when reading byte quantities.

Chapter 3: GCC Command Options

145

-mlittle-endian
-mbig-endian

Generate ode for a little endian target.

-m210
-m340

Generate ode for the 210 pro essor.

3.17.17 MIPS Options

-EB

Generate big-endian ode.

-EL

Generate little-endian ode. This is the default for `mips*el-*-*' ongurations.

-mar h=ar h

Generate ode that will run on ar h, whi h an be the name of a generi MIPS
ISA, or the name of a parti ular pro essor. The ISA names are: `mips1',
`mips2', `mips3', `mips4', `mips32', `mips32r2', and `mips64'. The pro essor names are: `4k ', `4kp', `5k ', `20k ', `m4k', `r2000', `r3000', `r3900',
`r4000', `r4400', `r4600', `r4650', `r6000', `r8000', `rm7000', `rm9000', `orion',
`sb1', `vr4100', `vr4111', `vr4120', `vr4130', `vr4300', `vr5000', `vr5400' and
`vr5500'. The spe ial value `from-abi' sele ts the most ompatible ar hite ture for the sele ted ABI (that is, `mips1' for 32-bit ABIs and `mips3' for 64-bit
ABIs).
In pro essor names, a nal `000' an be abbreviated as `k' (for example,
`-mar h=r2k'). Prexes are optional, and `vr' may be written `r'.
GCC denes two ma ros based on the value of this option. The rst is
`_MIPS_ARCH', whi h gives the name of target ar hite ture, as a string. The
se ond has the form `_MIPS_ARCH_foo ', where foo is the apitalized value
of `_MIPS_ARCH'. For example, `-mar h=r2000' will set `_MIPS_ARCH' to
`"r2000"' and dene the ma ro `_MIPS_ARCH_R2000'.
Note that the `_MIPS_ARCH' ma ro uses the pro essor names given above. In
other words, it will have the full prex and will not abbreviate `000' as `k'.
In the ase of `from-abi', the ma ro names the resolved ar hite ture (either
`"mips1"' or `"mips3"'). It names the default ar hite ture when no `-mar h'
option is given.

-mtune=ar h

Optimize for ar h. Among other things, this option ontrols the way instru tions are s heduled, and the per eived ost of arithmeti operations. The list
of ar h values is the same as for `-mar h'.
When this option is not used, GCC will optimize for the pro essor spe ied by
`-mar h'. By using `-mar h' and `-mtune' together, it is possible to generate
ode that will run on a family of pro essors, but optimize the ode for one
parti ular member of that family.
`-mtune' denes the ma ros `_MIPS_TUNE' and `_MIPS_TUNE_foo ', whi h work
in the same way as the `-mar h' ones des ribed above.

-mips1

Equivalent to `-mar h=mips1'.

146

-mips2
-mips3
-mips4
-mips32
-mips32r2
-mips64

Using the GNU Compiler Colle tion (GCC)

Equivalent to `-mar h=mips2'.

Equivalent to `-mar h=mips3'.
Equivalent to `-mar h=mips4'.
Equivalent to `-mar h=mips32'.
Equivalent to `-mar h=mips32r2'.
Equivalent to `-mar h=mips64'.

-mips16
-mno-mips16

Use (do not use) the MIPS16 ISA.

-mabi=32
-mabi=o64
-mabi=n32
-mabi=64
-mabi=eabi

Generate ode for the given ABI.

Note that the EABI has a 32-bit and a 64-bit variant. GCC normally generates
64-bit ode when you sele t a 64-bit ar hite ture, but you an use `-mgp32' to
get 32-bit ode instead.
For information about the O64 ABI, see http://g .gnu.org/proje ts/mipso64-abi.html.

-mabi alls
-mno-abi alls

Generate (do not generate) SVR4-style position-independent ode.

`-mabi alls' is the default for SVR4-based systems.

-mxgot
-mno-xgot

Lift (do not lift) the usual restri tions on the size of the global oset table.
GCC normally uses a single instru tion to load values from the GOT. While
this is relatively e ient, it will only work if the GOT is smaller than about
64k. Anything larger will ause the linker to report an error su h as:
relo ation trun ated to fit: R_MIPS_GOT16 foobar

-mgp32
-mgp64

If this happens, you should re ompile your ode with `-mxgot'. It should then
work with very large GOTs, although it will also be less e ient, sin e it will
take three instru tions to fet h the value of a global symbol.
Note that some linkers an reate multiple GOTs. If you have su h a linker,
you should only need to use `-mxgot' when a single obje t le a esses more
than 64k's worth of GOT entries. Very few do.
These options have no ee t unless GCC is generating position independent
ode.
Assume that general-purpose registers are 32 bits wide.
Assume that general-purpose registers are 64 bits wide.

Chapter 3: GCC Command Options

-mfp32
-mfp64

147

Assume that oating-point registers are 32 bits wide.

Assume that oating-point registers are 64 bits wide.

-mhard-float

Use oating-point opro essor instru tions.

-msoft-float

Do not use oating-point opro essor instru tions. Implement oating-point

al ulations using library alls instead.

-msingle-float

Assume that the oating-point opro essor only supports single-pre ision operations.

-mdouble-float

Assume that the oating-point opro essor supports double-pre ision operations. This is the default.

-mpaired-single
-mno-paired-single

Use (do not use) paired-single oating-point instru tions. See Se tion 5.45.5
[MIPS Paired-Single Support, page 290. This option an only be used when
generating 64-bit ode and requires hardware oating-point support to be enabled.

-mips3d
-mno-mips3d

Use (do not use) the MIPS-3D ASE. See Se tion 5.45.5.3 [MIPS-3D Built-in
Fun tions, page 292. The option `-mips3d' implies `-mpaired-single'.
-mint64 For e int and long types to be 64 bits wide. See `-mlong32' for an explanation
of the default and the way that the pointer size is determined.
This option has been depre ated and will be removed in a future release.
-mlong64 For e long types to be 64 bits wide. See `-mlong32' for an explanation of the
default and the way that the pointer size is determined.
-mlong32 For e long, int, and pointer types to be 32 bits wide.
The default size of ints, longs and pointers depends on the ABI. All the
supported ABIs use 32-bit ints. The n64 ABI uses 64-bit longs, as does the
64-bit EABI; the others use 32-bit longs. Pointers are the same size as longs,
or the same size as integer registers, whi hever is smaller.
-msym32
-mno-sym32

-G num

Assume (do not assume) that all symbols have 32-bit values, regardless of
the sele ted ABI. This option is useful in ombination with `-mabi=64' and
`-mno-abi alls' be ause it allows GCC to generate shorter and faster referen es to symboli addresses.
Put global and stati items less than or equal to num bytes into the small data
or bss se tion instead of the normal data or bss se tion. This allows the data
to be a essed using a single instru tion.

148

Using the GNU Compiler Colle tion (GCC)

All modules should be ompiled with the same `-G num ' value.
-membedded-data
-mno-embedded-data

Allo ate variables to the read-only data se tion rst if possible, then next in the
small data se tion if possible, otherwise in data. This gives slightly slower ode
than the default, but redu es the amount of RAM required when exe uting,
and thus may be preferred for some embedded systems.

-muninit- onst-in-rodata
-mno-uninit- onst-in-rodata
Put uninitialized onst variables in the read-only data se tion. This option is
only meaningful in onjun tion with `-membedded-data'.
-msplit-addresses
-mno-split-addresses

Enable (disable) use of the %hi() and %lo() assembler relo ation operators.
This option has been superseded by `-mexpli it-relo s' but is retained for
ba kwards ompatibility.

-mexpli it-relo s
-mno-expli it-relo s

Use (do not use) assembler relo ation operators when dealing with symboli
addresses. The alternative, sele ted by `-mno-expli it-relo s', is to use assembler ma ros instead.
`-mexpli it-relo s' is the default if GCC was ongured to use an assembler
that supports relo ation operators.

-m he k-zero-division
-mno- he k-zero-division

Trap (do not trap) on integer division by zero.

`-m he k-zero-division'.

The default is

-mdivide-traps
-mdivide-breaks

MIPS systems he k for division by zero by generating either a onditional

trap or a break instru tion. Using traps results in smaller ode, but is only
supported on MIPS II and later. Also, some versions of the Linux kernel have
a bug that prevents trap from generating the proper signal (SIGFPE). Use
`-mdivide-traps' to allow onditional traps on ar hite tures that support them
and `-mdivide-breaks' to for e the use of breaks.
The default is usually `-mdivide-traps', but this an be overridden at ongure
time using `--with-divide=breaks'. Divide-by-zero he ks an be ompletely
disabled using `-mno- he k-zero-division'.

-mmem py
-mno-mem py

For e (do not for e) the use of mem py() for non-trivial blo k moves. The default is `-mno-mem py', whi h allows GCC to inline most onstant-sized opies.

Chapter 3: GCC Command Options

149

-mlong- alls
-mno-long- alls

Disable (do not disable) use of the jal instru tion. Calling fun tions using
jal is more e ient but requires the aller and allee to be in the same 256
megabyte segment.
This option has no ee t on abi alls ode. The default is `-mno-long- alls'.

-mmad
-mno-mad Enable (disable) use of the mad, madu and mul instru tions, as provided by the

R4650 ISA.

-mfused-madd
-mno-fused-madd

-no pp

Enable (disable) use of the oating point multiply-a umulate instru tions,
when they are available. The default is `-mfused-madd'.
When multiply-a umulate instru tions are used, the intermediate produ t is
al ulated to innite pre ision and is not subje t to the FCSR Flush to Zero
bit. This may be undesirable in some ir umstan es.
Tell the MIPS assembler to not run its prepro essor over user assembler les
(with a `.s' sux) when assembling them.

-mfix-r4000
-mno-fix-r4000

Work around ertain R4000 CPU errata:

A double-word or a variable shift may give an in orre t result if exe uted
immediately after starting an integer division.
A double-word or a variable shift may give an in orre t result if exe uted
while an integer multipli ation is in progress.
An integer division may give an in orre t result if started in a delay slot of
a taken bran h or a jump.

-mfix-r4400
-mno-fix-r4400

Work around ertain R4400 CPU errata:

A double-word or a variable shift may give an in orre t result if exe uted
immediately after starting an integer division.

-mfix-vr4120
-mno-fix-vr4120

Work around ertain VR4120 errata:

dmultu does not always produ e the orre t result.
div and ddiv do not always produ e the orre t result if one of the operands
is negative.
The workarounds for the division errata rely on spe ial fun tions in `libg .a'.
At present, these fun tions are only provided by the mips64vr*-elf ongurations.
Other VR4120 errata require a nop to be inserted between ertain pairs of
instru tions. These errata are handled by the assembler, not by GCC itself.

150

Using the GNU Compiler Colle tion (GCC)

-mfix-vr4130

Work around the VR4130 mflo/mfhi errata. The workarounds are implemented
by the assembler rather than by GCC, although GCC will avoid using mflo and
mfhi if the VR4130 ma , ma hi, dma and dma hi instru tions are available
instead.

-mfix-sb1
-mno-fix-sb1

Work around ertain SB-1 CPU ore errata. (This ag urrently works around
the SB-1 revision 2 \F1" and \F2" oating point errata.)

-mflush-fun =fun
-mno-flush-fun

Spe ies the fun tion to all to ush the I and D a hes, or to not all any su h
fun tion. If alled, the fun tion must take the same arguments as the ommon
_flush_fun (), that is, the address of the memory range for whi h the a he
is being ushed, the size of the memory range, and the number 3 (to ush
both a hes). The default depends on the target GCC was ongured for, but
ommonly is either `_flush_fun ' or `__ pu_flush'.

-mbran h-likely
-mno-bran h-likely

Enable or disable use of Bran h Likely instru tions, regardless of the default
for the sele ted ar hite ture. By default, Bran h Likely instru tions may be
generated if they are supported by the sele ted ar hite ture. An ex eption
is for the MIPS32 and MIPS64 ar hite tures and pro essors whi h implement
those ar hite tures; for those, Bran h Likely instru tions will not be generated
by default be ause the MIPS32 and MIPS64 ar hite tures spe i ally depre ate
their use.

-mfp-ex eptions
-mno-fp-ex eptions

Spe ies whether FP ex eptions are enabled. This ae ts how we s hedule FP

instru tions for some pro essors. The default is that FP ex eptions are enabled.
For instan e, on the SB-1, if FP ex eptions are disabled, and we are emitting
64-bit ode, then we an use both FP pipes. Otherwise, we an only use one
FP pipe.

-mvr4130-align
-mno-vr4130-align

The VR4130 pipeline is two-way supers alar, but an only issue two instru tions
together if the rst one is 8-byte aligned. When this option is enabled, GCC
will align pairs of instru tions that it thinks should exe ute in parallel.
This option only has an ee t when optimizing for the VR4130. It normally
makes ode faster, but at the expense of making it bigger. It is enabled by
default at optimization level `-O3'.

3.17.18 MMIX Options

These options are dened for the MMIX:

Chapter 3: GCC Command Options

151

-mlibfun s
-mno-libfun s

Spe ify that intrinsi library fun tions are being ompiled, passing all values in
registers, no matter the size.

-mepsilon
-mno-epsilon

Generate oating-point omparison instru tions that ompare with respe t to

the rE epsilon register.

-mabi=mmixware
-mabi=gnu

Generate ode that passes fun tion parameters and return values that (in the
alled fun tion) are seen as registers $0 and up, as opposed to the GNU ABI
whi h uses global registers $231 and up.

-mzero-extend
-mno-zero-extend

When reading data from memory in sizes shorter than 64 bits, use (do not use)
zero-extending load instru tions by default, rather than sign-extending ones.

-mknuthdiv
-mno-knuthdiv

Make the result of a division yielding a remainder have the same sign as the
divisor. With the default, `-mno-knuthdiv', the sign of the remainder follows
the sign of the dividend. Both methods are arithmeti ally valid, the latter being
almost ex lusively used.

-mtoplevel-symbols
-mno-toplevel-symbols

Prepend (do not prepend) a `:' to all global symbols, so the assembly ode an
be used with the PREFIX assembly dire tive.

-melf

Generate an exe utable in the ELF format, rather than the default `mmo' format
used by the mmix simulator.

-mbran h-predi t
-mno-bran h-predi t

Use (do not use) the probable-bran h instru tions, when stati bran h predi tion indi ates a probable bran h.

-mbase-addresses
-mno-base-addresses

Generate (do not generate) ode that uses base addresses. Using a base address
automati ally generates a request (handled by the assembler and the linker)
for a onstant to be set up in a global register. The register is used for one or
more base address requests within the range 0 to 255 from the value held in the
register. The generally leads to short and fast ode, but the number of dierent
data items that an be addressed is limited. This means that a program that
uses lots of stati data may require `-mno-base-addresses'.

152

Using the GNU Compiler Colle tion (GCC)

-msingle-exit
-mno-single-exit

For e (do not for e) generated ode to have a single exit point in ea h fun tion.

3.17.19 MN10300 Options

These `-m' options are dened for Matsushita MN10300 ar hite tures:

-mmult-bug

Generate ode to avoid bugs in the multiply instru tions for the MN10300
pro essors. This is the default.

-mno-mult-bug

Do not generate ode to avoid bugs in the multiply instru tions for the MN10300
pro essors.

-mam33
-mno-am33

-mno- rt0
-mrelax

Generate ode whi h uses features spe i to the AM33 pro essor.
Do not generate ode whi h uses features spe i to the AM33 pro essor. This
is the default.
Do not link in the C run-time initialization obje t le.
Indi ate to the linker that it should perform a relaxation optimization pass to
shorten bran hes, alls and absolute memory addresses. This option only has
an ee t when used on the ommand line for the nal link step.
This option makes symboli debugging impossible.

3.17.20 NS32K Options

These are the `-m' options dened for the 32000 series. The default values for these options
depends on whi h style of 32000 was sele ted when the ompiler was ongured; the defaults
for the most ommon hoi es are given below.
-m32032
-m32032
-m32332
-m32332
-m32532
-m32532

Generate output for a 32032. This is the default when the ompiler is ongured
for 32032 and 32016 based systems.
Generate output for a 32332. This is the default when the ompiler is ongured
for 32332-based systems.
Generate output for a 32532. This is the default when the ompiler is ongured
for 32532-based systems.

-m32081

Generate output ontaining 32081 instru tions for oating point. This is the
default for all systems.

-m32381

Generate output ontaining 32381 instru tions for oating point. This also
implies `-m32081'. The 32381 is only ompatible with the 32332 and 32532
pus. This is the default for the p 532-netbsd onguration.

Chapter 3: GCC Command Options

153

-mmulti-add

Try and generate multiply-add oating point instru tions polyF and dotF. This
option is only available if the `-m32381' option is in ee t. Using these instru tions requires hanges to register allo ation whi h generally has a negative impa t on performan e. This option should only be enabled when ompiling ode
parti ularly likely to make heavy use of multiply-add instru tions.

-mnomulti-add

Do not try and generate multiply-add oating point instru tions polyF and

dotF. This is the default on all platforms.

-msoft-float

Generate output ontaining library alls for oating point.

uisite libraries may not be available.

Warning:

the req-

-mieee- ompare
-mno-ieee- ompare

Control whether or not the ompiler uses IEEE oating point omparisons.
These handle orre tly the ase where the result of a omparison is unordered.
Warning: the requisite kernel support may not be available.

-mnobitfield

Do not use the bit-eld instru tions. On some ma hines it is faster to use
shifting and masking operations. This is the default for the p 532.

-mbitfield

-mrtd

Do use the bit-eld instru tions. This is the default for all platforms ex ept the
p 532.
Use a dierent fun tion- alling onvention, in whi h fun tions that take a xed
number of arguments return pop their arguments on return with the ret instru tion.
This alling onvention is in ompatible with the one normally used on Unix, so
you annot use it if you need to all libraries ompiled with the Unix ompiler.
Also, you must provide fun tion prototypes for all fun tions that take variable
numbers of arguments (in luding printf); otherwise in orre t ode will be
generated for alls to those fun tions.
In addition, seriously in orre t ode will result if you all a fun tion with too
many arguments. (Normally, extra arguments are harmlessly ignored.)
This option takes its name from the 680x0 rtd instru tion.

-mregparam

Use a dierent fun tion- alling onvention where the rst two arguments are
passed in registers.
This alling onvention is in ompatible with the one normally used on Unix, so
you annot use it if you need to all libraries ompiled with the Unix ompiler.

-mnoregparam
-msb

Do not pass any arguments in registers. This is the default for all targets.
It is OK to use the sb as an index register whi h is always loaded with zero.
This is the default for the p 532-netbsd target.

154

Using the GNU Compiler Colle tion (GCC)

The sb register is not available for use or has not been initialized to zero by the
run time system. This is the default for all targets ex ept the p 532-netbsd. It
is also implied whenever `-mhimem' or `-fpi ' is set.
Many ns32000 series addressing modes use displa ements of up to 512MB. If
an address is above 512MB then displa ements from zero an not be used. This
option auses ode to be generated whi h an be loaded above 512MB. This
may be useful for operating systems or ROM ode.

-mnosb

-mhimem

-mnohimem

Assume ode will be loaded in the rst 512MB of virtual address spa e. This
is the default for all platforms.

3.17.21 PDP-11 Options

These options are dened for the PDP-11:

-mfpu
Use hardware FPP oating point. This is the default. (FIS oating point on
the PDP-11/40 is not supported.)
-msoft-float

Do not use hardware oating point.

-ma 0
Return oating-point results in a 0 (fr0 in Unix assembler syntax).
-mno-a 0 Return oating-point results in memory. This is the default.
-m40
Generate ode for a PDP-11/40.
-m45
Generate ode for a PDP-11/45. This is the default.
-m10
Generate ode for a PDP-11/10.
-mb opy-builtin
-mb opy

Use inline movmemhi patterns for opying memory. This is the default.
Do not use inline movmemhi patterns for opying memory.

-mint16
-mno-int32

Use 16-bit int. This is the default.

-mint32
-mno-int16

Use 32-bit int.

-mfloat64
-mno-float32

Use 64-bit float. This is the default.

-mfloat32
-mno-float64

Use 32-bit float.

Use abshi2 pattern. This is the default.

-mabshi
-mno-abshi

Do not use abshi2 pattern.

Chapter 3: GCC Command Options

155

-mbran h-expensive

Pretend that bran hes are expensive. This is for experimenting with ode generation only.

-mbran h- heap

Do not pretend that bran hes are expensive. This is the default.

-msplit

Generate ode for a system with split I&D.

-mno-split

Generate ode for a system without split I&D. This is the default.

-munix-asm

Use Unix assembler syntax.

`pdp11-*-bsd'.

-mde -asm

This is the default when ongured for

Use DEC assembler syntax. This is the default when ongured for any PDP-11
target other than `pdp11-*-bsd'.

3.17.22 PowerPC Options

These are listed under See Se tion 3.17.23 [RS/6000 and PowerPC Options, page 155.

3.17.23 IBM RS/6000 and PowerPC Options

These `-m' options are dened for the IBM RS/6000 and PowerPC:
-mpower
-mno-power
-mpower2
-mno-power2
-mpowerp
-mno-powerp
-mpowerp -gpopt
-mno-powerp -gpopt
-mpowerp -gfxopt
-mno-powerp -gfxopt
-mpowerp 64
-mno-powerp 64

GCC supports two related instru tion set ar hite tures for the RS/6000 and
PowerPC. The POWER instru tion set are those instru tions supported by
the `rios' hip set used in the original RS/6000 systems and the PowerPC
instru tion set is the ar hite ture of the Motorola MPC5xx, MPC6xx, MPC8xx
mi ropro essors, and the IBM 4xx mi ropro essors.
Neither ar hite ture is a subset of the other. However there is a large ommon subset of instru tions supported by both. An MQ register is in luded in
pro essors supporting the POWER ar hite ture.
You use these options to spe ify whi h instru tions are available on the pro essor
you are using. The default value of these options is determined when onguring
GCC. Spe ifying the `-m pu= pu_type ' overrides the spe i ation of these

156

Using the GNU Compiler Colle tion (GCC)

options. We re ommend you use the `-m pu= pu_type ' option rather than the
options listed above.
The `-mpower' option allows GCC to generate instru tions that are found only
in the POWER ar hite ture and to use the MQ register. Spe ifying `-mpower2'
implies `-power' and also allows GCC to generate instru tions that are present
in the POWER2 ar hite ture but not the original POWER ar hite ture.
The `-mpowerp ' option allows GCC to generate instru tions that are
found only in the 32-bit subset of the PowerPC ar hite ture. Spe ifying
`-mpowerp -gpopt' implies `-mpowerp ' and also allows GCC to use the
optional PowerPC ar hite ture instru tions in the General Purpose group,
in luding oating-point square root. Spe ifying `-mpowerp -gfxopt' implies
`-mpowerp ' and also allows GCC to use the optional PowerPC ar hite ture
instru tions in the Graphi s group, in luding oating-point sele t.
The `-mpowerp 64' option allows GCC to generate the additional 64-bit instru tions that are found in the full PowerPC64 ar hite ture and to treat GPRs as
64-bit, doubleword quantities. GCC defaults to `-mno-powerp 64'.
If you spe ify both `-mno-power' and `-mno-powerp ', GCC will use only the
instru tions in the ommon subset of both ar hite tures plus some spe ial
AIX ommon-mode alls, and will not use the MQ register. Spe ifying both
`-mpower' and `-mpowerp ' permits GCC to use any instru tion from either
ar hite ture and to allow use of the MQ register; spe ify this for the Motorola
MPC601.
-mnew-mnemoni s
-mold-mnemoni s

Sele t whi h mnemoni s to use in the generated assembler ode. With

`-mnew-mnemoni s', GCC uses the assembler mnemoni s dened for the
PowerPC ar hite ture. With `-mold-mnemoni s' it uses the assembler
mnemoni s dened for the POWER ar hite ture. Instru tions dened in
only one ar hite ture have only one mnemoni ; GCC uses that mnemoni
irrespe tive of whi h of these options is spe ied.
GCC defaults to the mnemoni s appropriate for the ar hite ture in use. Spe ifying `-m pu= pu_type ' sometimes overrides the value of these option. Unless you are building a ross- ompiler, you should normally not spe ify either
`-mnew-mnemoni s' or `-mold-mnemoni s', but should instead a ept the default.

-m pu= pu_type

Set ar hite ture type, register usage, hoi e of mnemoni s, and instru tion
s heduling parameters for ma hine type pu type. Supported values for
pu type are `401', `403', `405', `405fp', `440', `440fp', `505', `601', `602',
`603', `603e', `604', `604e', `620', `630', `740', `7400', `7450', `750', `801', `821',
`823', `860', `970', `8540', ` ommon', `e 603e', `G3', `G4', `G5', `power', `power2',
`power3', `power4', `power5', `powerp ', `powerp 64', `rios', `rios1', `rios2',
`rs ', and `rs64a'.
`-m pu= ommon' sele ts a ompletely generi pro essor. Code generated under
this option will run on any POWER or PowerPC pro essor. GCC will use

Chapter 3: GCC Command Options

157

only the instru tions in the ommon subset of both ar hite tures, and will not
use the MQ register. GCC assumes a generi pro essor model for s heduling
purposes.
`-m pu=power', `-m pu=power2', `-m pu=powerp ', and `-m pu=powerp 64'
spe ify generi POWER, POWER2, pure 32-bit PowerPC (i.e., not MPC601),
and 64-bit PowerPC ar hite ture ma hine types, with an appropriate, generi
pro essor model assumed for s heduling purposes.
The other options spe ify a spe i pro essor. Code generated under those
options will run best on that pro essor, and may not run at all on others.
The `-m pu' options automati ally enable or disable the following options:
`-maltive ', `-mhard-float', `-mmf rf', `-mmultiple', `-mnew-mnemoni s',
`-mpower', `-mpower2', `-mpowerp 64', `-mpowerp -gpopt', `-mpowerp -gfxopt',
`-mstring'. The parti ular options set for any parti ular CPU will vary
between ompiler versions, depending on what setting seems to produ e
optimal ode for that CPU; it doesn't ne essarily re e t the a tual hardware's
apabilities. If you wish to set an individual option to a parti ular value, you
may spe ify it after the `-m pu' option, like `-m pu=970 -mno-altive '.
On AIX, the `-maltive ' and `-mpowerp 64' options are not enabled or disabled
by the `-m pu' option at present, sin e AIX does not have full support for these
options. You may still enable or disable them individually if you're sure it'll
work in your environment.
-mtune= pu_type

Set the instru tion s heduling parameters for ma hine type pu type, but
do not set the ar hite ture type, register usage, or hoi e of mnemoni s,
as `-m pu= pu_type ' would. The same values for pu type are used for
`-mtune' as for `-m pu'. If both are spe ied, the ode generated will use
the ar hite ture, registers, and mnemoni s set by `-m pu', but the s heduling
parameters set by `-mtune'.

-maltive
-mno-altive

Generate ode that uses (does not use) AltiVe instru tions, and also enable the
use of built-in fun tions that allow more dire t a ess to the AltiVe instru tion
set. You may also need to set `-mabi=altive ' to adjust the urrent ABI with
AltiVe ABI enhan ements.

-mabi=spe

Extend the urrent ABI with SPE ABI extensions. This does not hange the
default ABI, instead it adds the SPE ABI extensions to the urrent ABI.

-mabi=no-spe

Disable Booke SPE ABI extensions for the urrent ABI.

-misel=yes/no
-misel
This swit h enables or disables the generation of ISEL instru tions.
-mspe=yes/no
-mspe
This swit h enables or disables the generation of SPE simd instru tions.

158

Using the GNU Compiler Colle tion (GCC)

-mfloat-gprs=yes/single/double/no
-mfloat-gprs

This swit h enables or disables the generation of oating point operations on

the general purpose registers for ar hite tures that support it.
The argument yes or single enables the use of single-pre ision oating point
operations.
The argument double enables the use of single and double-pre ision oating
point operations.
The argument no disables oating point operations on the general purpose
registers.
This option is urrently only available on the MPC854x.

-m32
-m64

Generate ode for 32-bit or 64-bit environments of Darwin and SVR4 targets
(in luding GNU/Linux). The 32-bit environment sets int, long and pointer
to 32 bits and generates ode that runs on any PowerPC variant. The 64-bit
environment sets int to 32 bits and long and pointer to 64 bits, and generates
ode for PowerPC64, as for `-mpowerp 64'.

-mfull-to
-mno-fp-in-to
-mno-sum-in-to
-mminimal-to

Modify generation of the TOC (Table Of Contents), whi h is reated for every
exe utable le. The `-mfull-to ' option is sele ted by default. In that ase,
GCC will allo ate at least one TOC entry for ea h unique non-automati variable referen e in your program. GCC will also pla e oating-point onstants in
the TOC. However, only 16,384 entries are available in the TOC.
If you re eive a linker error message that saying you have over owed the available TOC spa e, you an redu e the amount of TOC spa e used with the
`-mno-fp-in-to ' and `-mno-sum-in-to ' options. `-mno-fp-in-to ' prevents
GCC from putting oating-point onstants in the TOC and `-mno-sum-in-to '
for es GCC to generate ode to al ulate the sum of an address and a onstant
at run-time instead of putting that sum into the TOC. You may spe ify one
or both of these options. Ea h auses GCC to produ e very slightly slower and
larger ode at the expense of onserving TOC spa e.
If you still run out of spa e in the TOC even when you spe ify both of these
options, spe ify `-mminimal-to ' instead. This option auses GCC to make
only one TOC entry for every le. When you spe ify this option, GCC will
produ e ode that is slower and larger but whi h uses extremely little TOC
spa e. You may wish to use this option only on les that ontain less frequently
exe uted ode.

-maix64
-maix32

Enable 64-bit AIX ABI and alling onvention: 64-bit pointers, 64-bit long
type, and the infrastru ture needed to support them. Spe ifying `-maix64'
implies `-mpowerp 64' and `-mpowerp ', while `-maix32' disables the 64-bit
ABI and implies `-mno-powerp 64'. GCC defaults to `-maix32'.

Chapter 3: GCC Command Options

159

-mxl- ompat
-mno-xl- ompat

Produ e ode that onforms more losely to IBM XLC semanti s when using
AIX- ompatible ABI. Pass oating-point arguments to prototyped fun tions
beyond the register save area (RSA) on the sta k in addition to argument
FPRs. Do not assume that most signi ant double in 128 bit long double value
is properly rounded when omparing values.
The AIX alling onvention was extended but not initially do umented to handle an obs ure K&R C ase of alling a fun tion that takes the address of
its arguments with fewer arguments than de lared. AIX XL ompilers a ess
oating point arguments whi h do not t in the RSA from the sta k when a
subroutine is ompiled without optimization. Be ause always storing oatingpoint arguments on the sta k is ine ient and rarely needed, this option is not
enabled by default and only is ne essary when alling subroutines ompiled by
AIX XL ompilers without optimization.

-mpe

Support IBM RS/6000 SP Parallel Environment (PE). Link an appli ation

written to use message passing with spe ial startup ode to enable the appli ation to run. The system must have PE installed in the standard lo ation (`/usr/lpp/ppe.poe/'), or the `spe s' le must be overridden with the
`-spe s=' option to spe ify the appropriate dire tory lo ation. The Parallel
Environment does not support threads, so the `-mpe' option and the `-pthread'
option are in ompatible.

-malign-natural
-malign-power

On AIX, 32-bit Darwin, and 64-bit PowerPC GNU/Linux, the option

`-malign-natural' overrides the ABI-dened alignment of larger types, su h
as oating-point doubles, on their natural size-based boundary. The option
`-malign-power' instru ts GCC to follow the ABI-spe ied alignment rules.
GCC defaults to the standard alignment dened in the ABI.
On 64-bit Darwin, natural alignment is the default, and `-malign-power' is not
supported.

-msoft-float
-mhard-float

Generate ode that does not use (uses) the oating-point register set. Software
oating point emulation is provided if you use the `-msoft-float' option, and
pass the option to GCC when linking.

-mmultiple
-mno-multiple

Generate ode that uses (does not use) the load multiple word instru tions
and the store multiple word instru tions. These instru tions are generated by
default on POWER systems, and not generated on PowerPC systems. Do not
use `-mmultiple' on little endian PowerPC systems, sin e those instru tions
do not work when the pro essor is in little endian mode. The ex eptions are
PPC740 and PPC750 whi h permit the instru tions usage in little endian mode.

160

Using the GNU Compiler Colle tion (GCC)

-mstring
-mno-string

Generate ode that uses (does not use) the load string instru tions and the
store string word instru tions to save multiple registers and do small blo k
moves. These instru tions are generated by default on POWER systems, and
not generated on PowerPC systems. Do not use `-mstring' on little endian
PowerPC systems, sin e those instru tions do not work when the pro essor is
in little endian mode. The ex eptions are PPC740 and PPC750 whi h permit
the instru tions usage in little endian mode.

-mupdate
-mno-update

Generate ode that uses (does not use) the load or store instru tions that update
the base register to the address of the al ulated memory lo ation. These
instru tions are generated by default. If you use `-mno-update', there is a small
window between the time that the sta k pointer is updated and the address of
the previous frame is stored, whi h means ode that walks the sta k frame
a ross interrupts or signals may get orrupted data.

-mfused-madd
-mno-fused-madd

Generate ode that uses (does not use) the oating point multiply and a umulate instru tions. These instru tions are generated by default if hardware
oating is used.

-mno-bit-align
-mbit-align

On System V.4 and embedded PowerPC systems do not (do) for e stru tures
and unions that ontain bit-elds to be aligned to the base type of the bit-eld.
For example, by default a stru ture ontaining nothing but 8 unsigned bitelds of length 1 would be aligned to a 4 byte boundary and have a size of 4
bytes. By using `-mno-bit-align', the stru ture would be aligned to a 1 byte
boundary and be one byte in size.

-mno-stri t-align
-mstri t-align

On System V.4 and embedded PowerPC systems do not (do) assume that unaligned memory referen es will be handled by the system.

-mrelo atable
-mno-relo atable

On embedded PowerPC systems generate ode that allows (does not allow)
the program to be relo ated to a dierent address at runtime. If you use
`-mrelo atable' on any module, all obje ts linked together must be ompiled
with `-mrelo atable' or `-mrelo atable-lib'.

-mrelo atable-lib
-mno-relo atable-lib

On embedded PowerPC systems generate ode that allows (does not allow) the
program to be relo ated to a dierent address at runtime. Modules ompiled

Chapter 3: GCC Command Options

161

with `-mrelo atable-lib' an be linked with either modules ompiled without

`-mrelo atable' and `-mrelo atable-lib' or with modules ompiled with the
`-mrelo atable' options.
-mno-to
-mto
On System V.4 and embedded PowerPC systems do not (do) assume that reg-

ister 2 ontains a pointer to a global area pointing to the addresses used in the
program.

-mlittle
-mlittle-endian

On System V.4 and embedded PowerPC systems ompile ode for the pro essor
in little endian mode. The `-mlittle-endian' option is the same as `-mlittle'.

-mbig
-mbig-endian

On System V.4 and embedded PowerPC systems ompile ode for the pro essor
in big endian mode. The `-mbig-endian' option is the same as `-mbig'.

-mdynami -no-pi

On Darwin and Ma OS X systems, ompile ode so that it is not relo atable,

but that its external referen es are relo atable. The resulting ode is suitable
for appli ations, but not shared libraries.

-mprioritize-restri ted-insns=priority

This option ontrols the priority that is assigned to dispat h-slot restri ted
instru tions during the se ond s heduling pass. The argument priority takes
the value 0/1/2 to assign no/highest/se ond-highest priority to dispat h slot
restri ted instru tions.

-ms hed- ostly-dep=dependen e_type

This option ontrols whi h dependen es are onsidered ostly by the target
during instru tion s heduling. The argument dependen e type takes one of the
following values: no: no dependen e is ostly, all: all dependen es are ostly,
true store to load: a true dependen e from store to load is ostly, store to load:
any dependen e from store to load is ostly, number: any dependen e whi h
laten y >= number is ostly.

-minsert-s hed-nops=s heme

This option ontrols whi h nop insertion s heme will be used during the se ond
s heduling pass. The argument s heme takes one of the following values: no:
Don't insert nops. pad: Pad with nops any dispat h group whi h has va ant
issue slots, a ording to the s heduler's grouping. regroup exa t: Insert nops
to for e ostly dependent insns into separate groups. Insert exa tly as many
nops as needed to for e an insn to a new group, a ording to the estimated
pro essor grouping. number: Insert nops to for e ostly dependent insns into
separate groups. Insert number nops to for e an insn to a new group.

-m all-sysv

On System V.4 and embedded PowerPC systems ompile ode using alling
onventions that adheres to the Mar h 1995 draft of the System V Appli ation

162

Using the GNU Compiler Colle tion (GCC)

Binary Interfa e, PowerPC pro essor supplement. This is the default unless
you ongured GCC using `powerp -*-eabiaix'.
-m all-sysv-eabi

Spe ify both `-m all-sysv' and `-meabi' options.

-m all-sysv-noeabi

Spe ify both `-m all-sysv' and `-mno-eabi' options.

-m all-solaris

On System V.4 and embedded PowerPC systems ompile ode for the Solaris
operating system.

-m all-linux

On System V.4 and embedded PowerPC systems ompile ode for the Linuxbased GNU system.

-m all-gnu

On System V.4 and embedded PowerPC systems ompile ode for the Hurdbased GNU system.

-m all-netbsd

On System V.4 and embedded PowerPC systems ompile ode for the NetBSD
operating system.

-maix-stru t-return

Return all stru tures in memory (as spe ied by the AIX ABI).

-msvr4-stru t-return

Return stru tures smaller than 8 bytes in registers (as spe ied by the SVR4
ABI).

-mabi=altive

Extend the urrent ABI with AltiVe ABI extensions. This does not hange
the default ABI, instead it adds the AltiVe ABI extensions to the urrent ABI.

-mabi=no-altive

Disable AltiVe ABI extensions for the urrent ABI.

-mprototype
-mno-prototype

-msim

-mmvme

On System V.4 and embedded PowerPC systems assume that all alls to variable argument fun tions are properly prototyped. Otherwise, the ompiler must
insert an instru tion before every non prototyped all to set or lear bit 6
of the ondition ode register (CR) to indi ate whether oating point values
were passed in the oating point registers in ase the fun tion takes a variable
arguments. With `-mprototype', only alls to prototyped variable argument
fun tions will set or lear the bit.
On embedded PowerPC systems, assume that the startup module is alled
`sim- rt0.o' and that the standard C libraries are `libsim.a' and `lib .a'.
This is the default for `powerp -*-eabisim'. ongurations.
On embedded PowerPC systems, assume that the startup module is alled
` rt0.o' and the standard C libraries are `libmvme.a' and `lib .a'.

Chapter 3: GCC Command Options

-mads

163

On embedded PowerPC systems, assume that the startup module is alled

` rt0.o' and the standard C libraries are `libads.a' and `lib .a'.

-myellowknife

On embedded PowerPC systems, assume that the startup module is alled

` rt0.o' and the standard C libraries are `libyk.a' and `lib .a'.

-mvxworks

-mwindiss
-memb
-meabi
-mno-eabi

On System V.4 and embedded PowerPC systems, spe ify that you are ompiling
for a VxWorks system.
Spe ify that you are ompiling for the WindISS simulation environment.
On embedded PowerPC systems, set the PPC EMB bit in the ELF ags header
to indi ate that `eabi' extended relo ations are used.
On System V.4 and embedded PowerPC systems do (do not) adhere to the
Embedded Appli ations Binary Interfa e (eabi) whi h is a set of modi ations
to the System V.4 spe i ations. Sele ting `-meabi' means that the sta k is
aligned to an 8 byte boundary, a fun tion __eabi is alled to from main to set
up the eabi environment, and the `-msdata' option an use both r2 and r13
to point to two separate small data areas. Sele ting `-mno-eabi' means that
the sta k is aligned to a 16 byte boundary, do not all an initialization fun tion
from main, and the `-msdata' option will only use r13 to point to a single small
data area. The `-meabi' option is on by default if you ongured GCC using
one of the `powerp *-*-eabi*' options.

-msdata=eabi

On System V.4 and embedded PowerPC systems, put small initialized onst
global and stati data in the `.sdata2' se tion, whi h is pointed to by register
r2. Put small initialized non- onst global and stati data in the `.sdata'
se tion, whi h is pointed to by register r13. Put small uninitialized global and
stati data in the `.sbss' se tion, whi h is adja ent to the `.sdata' se tion.
The `-msdata=eabi' option is in ompatible with the `-mrelo atable' option.
The `-msdata=eabi' option also sets the `-memb' option.

-msdata=sysv

On System V.4 and embedded PowerPC systems, put small global and stati
data in the `.sdata' se tion, whi h is pointed to by register r13. Put small
uninitialized global and stati data in the `.sbss' se tion, whi h is adja ent
to the `.sdata' se tion. The `-msdata=sysv' option is in ompatible with the
`-mrelo atable' option.

-msdata=default
-msdata On System V.4 and embedded PowerPC systems, if `-meabi' is used, ompile ode the same as `-msdata=eabi', otherwise ompile ode the same as
`-msdata=sysv'.

164

Using the GNU Compiler Colle tion (GCC)

-msdata-data

On System V.4 and embedded PowerPC systems, put small global and stati
data in the `.sdata' se tion. Put small uninitialized global and stati data in
the `.sbss' se tion. Do not use register r13 to address small data however.
This is the default behavior unless other `-msdata' options are used.

-msdata=none
-mno-sdata

On embedded PowerPC systems, put all initialized global and stati data in
the `.data' se tion, and all uninitialized data in the `.bss' se tion.

-G num

On embedded PowerPC systems, put global and stati items less than or equal
to num bytes into the small data or bss se tions instead of the normal data or
bss se tion. By default, num is 8. The `-G num ' swit h is also passed to the
linker. All modules should be ompiled with the same `-G num ' value.

-mregnames
-mno-regnames

On System V.4 and embedded PowerPC systems do (do not) emit register
names in the assembly language output using symboli forms.

-mlong all
-mno-long all

Default to making all fun tion alls indire tly, using a register, so that fun tions
whi h reside further than 32 megabytes (33,554,432 bytes) from the urrent lo ation an be alled. This setting an be overridden by the short all fun tion
attribute, or by #pragma long all(0).
Some linkers are apable of dete ting out-of-range alls and generating glue
ode on the y. On these systems, long alls are unne essary and generate
slower ode. As of this writing, the AIX linker an do this, as an the GNU
linker for PowerPC/64. It is planned to add this feature to the GNU linker for
32-bit PowerPC systems as well.
On Darwin/PPC systems, #pragma long all will generate \jbsr allee, L42",
plus a \bran h island" (glue ode). The two target addresses represent the
allee and the \bran h island". The Darwin/PPC linker will prefer the rst
address and generate a \bl allee" if the PPC \bl" instru tion will rea h the
allee dire tly; otherwise, the linker will generate \bl L42" to all the \bran h
island". The \bran h island" is appended to the body of the alling fun tion;
it omputes the full 32-bit address of the allee and jumps to it.
On Ma h-O (Darwin) systems, this option dire ts the ompiler emit to the glue
for every dire t all, and the Darwin linker de ides whether to use or dis ard
it.
In the future, we may ause GCC to ignore all long all spe i ations when the
linker is known to generate glue.

-pthread Adds support for multithreading with the pthreads library. This option sets

ags for both the prepro essor and linker.

Chapter 3: GCC Command Options

165

3.17.24 S/390 and zSeries Options

These are the `-m' options dened for the S/390 and zSeries ar hite ture.
-mhard-float
-msoft-float

Use (do not use) the hardware oating-point instru tions and registers
for oating-point operations. When `-msoft-float' is spe ied, fun tions
in `libg .a' will be used to perform oating-point operations. When
`-mhard-float' is spe ied, the ompiler generates IEEE oating-point
instru tions. This is the default.

-mba k hain
-mno-ba k hain

Store (do not store) the address of the aller's frame as ba k hain pointer into
the allee's sta k frame. A ba k hain may be needed to allow debugging using tools that do not understand DWARF-2 all frame information. When
`-mno-pa ked-sta k' is in ee t, the ba k hain pointer is stored at the bottom
of the sta k frame; when `-mpa ked-sta k' is in ee t, the ba k hain is pla ed
into the topmost word of the 96/160 byte register save area.
In general, ode ompiled with `-mba k hain' is all- ompatible with ode ompiled with `-mmo-ba k hain'; however, use of the ba k hain for debugging purposes usually requires that the whole binary is built with `-mba k hain'. Note
that the ombination of `-mba k hain', `-mpa ked-sta k' and `-mhard-float'
is not supported. In order to build a linux kernel use `-msoft-float'.
The default is to not maintain the ba k hain.

-mpa ked-sta k
-mno-pa ked-sta k

Use (do not use) the pa ked sta k layout. When `-mno-pa ked-sta k' is spe ied, the ompiler uses the all elds of the 96/160 byte register save area
only for their default purpose; unused elds still take up sta k spa e. When
`-mpa ked-sta k' is spe ied, register save slots are densely pa ked at the top
of the register save area; unused spa e is reused for other purposes, allowing for
more e ient use of the available sta k spa e. However, when `-mba k hain'
is also in ee t, the topmost word of the save area is always used to store the
ba k hain, and the return address register is always saved two words below the
ba k hain.
As long as the sta k frame ba k hain is not used, ode generated
with `-mpa ked-sta k' is all- ompatible with ode generated with
`-mno-pa ked-sta k'. Note that some non-FSF releases of GCC 2.95 for
S/390 or zSeries generated ode that uses the sta k frame ba k hain at run
time, not just for debugging purposes. Su h ode is not all- ompatible with
ode ompiled with `-mpa ked-sta k'. Also, note that the ombination of
`-mba k hain', `-mpa ked-sta k' and `-mhard-float' is not supported. In
order to build a linux kernel use `-msoft-float'.
The default is to not use the pa ked sta k layout.

166

Using the GNU Compiler Colle tion (GCC)

-msmall-exe
-mno-small-exe

Generate (or do not generate) ode using the bras instru tion to do subroutine
alls. This only works reliably if the total exe utable size does not ex eed 64k.
The default is to use the basr instru tion instead, whi h does not have this
limitation.

-m64
-m31

-mzar h
-mesa

When `-m31' is spe ied, generate ode ompliant to the GNU/Linux for S/390
ABI. When `-m64' is spe ied, generate ode ompliant to the GNU/Linux for
zSeries ABI. This allows GCC in parti ular to generate 64-bit instru tions. For
the `s390' targets, the default is `-m31', while the `s390x' targets default to
`-m64'.
When `-mzar h' is spe ied, generate ode using the instru tions available on
z/Ar hite ture. When `-mesa' is spe ied, generate ode using the instru tions
available on ESA/390. Note that `-mesa' is not possible with `-m64'. When
generating ode ompliant to the GNU/Linux for S/390 ABI, the default is
`-mesa'. When generating ode ompliant to the GNU/Linux for zSeries ABI,
the default is `-mzar h'.

-mmv le
-mno-mv le

Generate (or do not generate) ode using the mv le instru tion to perform
blo k moves. When `-mno-mv le' is spe ied, use a mv loop instead. This is
the default.

-mdebug
-mno-debug

Print (or do not print) additional debug information when ompiling. The
default is to not print debug information.

-mar h= pu-type

Generate ode that will run on pu-type, whi h is the name of a system representing a ertain pro essor type. Possible values for pu-type are `g5', `g6',
`z900', and `z990'. When generating ode using the instru tions available
on z/Ar hite ture, the default is `-mar h=z900'. Otherwise, the default is
`-mar h=g5'.

-mtune= pu-type

Tune to pu-type everything appli able about the generated ode, ex ept for
the ABI and the set of available instru tions. The list of pu-type values is the
same as for `-mar h'. The default is the value used for `-mar h'.

-mtpf-tra e
-mno-tpf-tra e

Generate ode that adds (does not add) in TPF OS spe i bran hes to tra e
routines in the operating system. This option is o by default, even when
ompiling for the TPF OS.

Chapter 3: GCC Command Options

167

-mfused-madd
-mno-fused-madd

Generate ode that uses (does not use) the oating point multiply and a umulate instru tions. These instru tions are generated by default if hardware
oating point is used.

-mwarn-framesize=framesize

Emit a warning if the urrent fun tion ex eeds the given frame size. Be ause
this is a ompile time he k it doesn't need to be a real problem when the
program runs. It is intended to identify fun tions whi h most probably ause
a sta k over ow. It is useful to be used in an environment with limited sta k
size e.g. the linux kernel.

-mwarn-dynami sta k

Emit a warning if the fun tion alls allo a or uses dynami ally sized arrays.
This is generally a bad idea with a limited sta k size.

-msta k-guard=sta k-guard

-msta k-size=sta k-size

These arguments always have to be used in onjun tion. If they are present
the s390 ba k end emits additional instru tions in the fun tion prologue whi h
trigger a trap if the sta k size is sta k-guard bytes above the sta k-size (remember that the sta k on s390 grows downward). These options are intended to
be used to help debugging sta k over ow problems. The additionally emitted
ode ause only little overhead and hen e an also be used in produ tion like
systems without greater performan e degradation. The given values have to be
exa t powers of 2 and sta k-size has to be greater than sta k-guard. In order
to be e ient the extra ode makes the assumption that the sta k starts at an
address aligned to the value given by sta k-size.

3.17.25 SH Options

These `-m' options are dened for the SH implementations:

-m1
Generate ode for the SH1.
-m2
Generate ode for the SH2.
-m2e
Generate ode for the SH2e.
-m3
Generate ode for the SH3.
-m3e
Generate ode for the SH3e.
-m4-nofpu

Generate ode for the SH4 without a oating-point unit.

-m4-single-only

Generate ode for the SH4 with a oating-point unit that only supports singlepre ision arithmeti .

-m4-single

Generate ode for the SH4 assuming the oating-point unit is in single-pre ision
mode by default.

168

Using the GNU Compiler Colle tion (GCC)

Generate ode for the SH4.

-m4

-m4a-nofpu

Generate ode for the SH4al-dsp, or for a SH4a in su h a way that the oatingpoint unit is not used.

-m4a-single-only

Generate ode for the SH4a, in su h a way that no double-pre ision oating
point operations are used.

-m4a-single

Generate ode for the SH4a assuming the oating-point unit is in

single-pre ision mode by default.
-m4a
Generate ode for the SH4a.
-m4al
Same as `-m4a-nofpu', ex ept that it impli itly passes `-dsp' to the assembler.
GCC doesn't generate any DSP instru tions at the moment.
-mb
Compile ode for the pro essor in big endian mode.
-ml
Compile ode for the pro essor in little endian mode.
-mdalign Align doubles at 64-bit boundaries. Note that this hanges the alling onventions, and thus some fun tions from the standard C library will not work unless
you re ompile it rst with `-mdalign'.
-mrelax Shorten some address referen es at link time, when possible; uses the linker
option `-relax'.
-mbigtable
-mfmovd
-mhita hi
-mrenesas

Use 32-bit osets in swit h tables. The default is to use 16-bit osets.
Enable the use of the instru tion fmovd.
Comply with the alling onventions dened by Renesas.
Comply with the alling onventions dened by Renesas.

-mno-renesas

Comply with the alling onventions dened for GCC before the Renesas onventions were available. This option is the default for all targets of the SH
tool hain ex ept for `sh-symbianelf'.

-mnoma save
-mieee
-misize

Mark the MAC register as all- lobbered, even if `-mhita hi' is given.
In rease IEEE- omplian e of oating-point ode.
Dump instru tion size and lo ation in the assembly ode.

-mpadstru t

-mspa e

This option is depre ated. It pads stru tures to multiple of 4 bytes, whi h is
in ompatible with the SH ABI.
Optimize for spa e instead of speed. Implied by `-Os'.

Chapter 3: GCC Command Options

169

-mprefergot

When generating position-independent ode, emit fun tion alls using the
Global Oset Table instead of the Pro edure Linkage Table.

-musermode

Generate a library fun tion all to invalidate instru tion a he entries, after
xing up a trampoline. This library fun tion all doesn't assume it an write
to the whole memory address spa e. This is the default when the target is
sh-*-linux*.

3.17.26 SPARC Options

These `-m' options are supported on the SPARC:

-mno-app-regs
-mapp-regs

Spe ify `-mapp-regs' to generate output using the global registers 2 through 4,
whi h the SPARC SVR4 ABI reserves for appli ations. This is the default.
To be fully SVR4 ABI ompliant at the ost of some performan e loss, spe ify
`-mno-app-regs'. You should ompile libraries and system software with this
option.

-mfpu
-mhard-float

Generate output ontaining oating point instru tions. This is the default.

-mno-fpu
-msoft-float

Generate output ontaining library alls for oating point. Warning: the requisite libraries are not available for all SPARC targets. Normally the fa ilities
of the ma hine's usual C ompiler are used, but this annot be done dire tly in
ross- ompilation. You must make your own arrangements to provide suitable
library fun tions for ross- ompilation. The embedded targets `spar -*-aout'
and `spar lite-*-*' do provide software oating point support.
`-msoft-float' hanges the alling onvention in the output le; therefore, it
is only useful if you ompile all of a program with this option. In parti ular, you need to ompile `libg .a', the library that omes with GCC, with
`-msoft-float' in order for this to work.

-mhard-quad-float

Generate output ontaining quad-word (long double) oating point instru tions.

-msoft-quad-float

Generate output ontaining library alls for quad-word (long double) oating
point instru tions. The fun tions alled are those spe ied in the SPARC ABI.
This is the default.
As of this writing, there are no SPARC implementations that have hardware
support for the quad-word oating point instru tions. They all invoke a trap
handler for one of these instru tions, and then the trap handler emulates the
ee t of the instru tion. Be ause of the trap handler overhead, this is mu h

170

Using the GNU Compiler Colle tion (GCC)

slower than alling the ABI library routines. Thus the `-msoft-quad-float'
option is the default.
-mno-unaligned-doubles
-munaligned-doubles

Assume that doubles have 8 byte alignment. This is the default.

With `-munaligned-doubles', GCC assumes that doubles have 8 byte alignment only if they are ontained in another type, or if they have an absolute
address. Otherwise, it assumes they have 4 byte alignment. Spe ifying this
option avoids some rare ompatibility problems with ode generated by other
ompilers. It is not the default be ause it results in a performan e loss, espe ially for oating point ode.

-mno-faster-stru ts
-mfaster-stru ts
With `-mfaster-stru ts', the ompiler assumes that stru tures should have
8 byte alignment. This enables the use of pairs of ldd and std instru tions
for opies in stru ture assignment, in pla e of twi e as many ld and st pairs.

However, the use of this hanged alignment dire tly violates the SPARC ABI.
Thus, it's intended only for use on targets where the developer a knowledges
that their resulting ode will not be dire tly in line with the rules of the ABI.

-mimpure-text
`-mimpure-text', used in addition to `-shared', tells the ompiler to not pass
`-z text' to the linker when linking a shared obje t. Using this option, you an

link position-dependent ode into a shared obje t.

`-mimpure-text' suppresses the \relo ations remain against allo atable but
non-writable se tions" linker error message. However, the ne essary relo ations will trigger opy-on-write, and the shared obje t is not a tually shared
a ross pro esses. Instead of using `-mimpure-text', you should ompile all
sour e ode with `-fpi ' or `-fPIC'.
This option is only available on SunOS and Solaris.

-m pu= pu_type

Set the instru tion set, register set, and instru tion s heduling parameters for
ma hine type pu type. Supported values for pu type are `v7', ` ypress',
`v8', `superspar ', `spar lite', `f930', `f934', `hyperspar ', `spar lite86x',
`spar let', `ts 701', `v9', `ultraspar ', and `ultraspar 3'.
Default instru tion s heduling parameters are used for values that sele t an
ar hite ture and not an implementation. These are `v7', `v8', `spar lite',
`spar let', `v9'.
Here is a list of ea h supported ar hite ture and their supported implementations.
v7:
v8:
spar lite:
spar let:
v9:

ypress
superspar , hyperspar
f930, f934, spar lite86x
ts 701
ultraspar , ultraspar 3

Chapter 3: GCC Command Options

171

By default (unless ongured otherwise), GCC generates ode for the V7 variant of the SPARC ar hite ture. With `-m pu= ypress', the ompiler additionally optimizes it for the Cypress CY7C602 hip, as used in the SPARCStation/SPARCServer 3xx series. This is also appropriate for the older SPARCStation 1, 2, IPX et .
With `-m pu=v8', GCC generates ode for the V8 variant of the SPARC ar hite ture. The only dieren e from V7 ode is that the ompiler emits the integer
multiply and integer divide instru tions whi h exist in SPARC-V8 but not in
SPARC-V7. With `-m pu=superspar ', the ompiler additionally optimizes it
for the SuperSPARC hip, as used in the SPARCStation 10, 1000 and 2000
series.
With `-m pu=spar lite', GCC generates ode for the SPARClite variant of the
SPARC ar hite ture. This adds the integer multiply, integer divide step and
s an (ffs) instru tions whi h exist in SPARClite but not in SPARC-V7. With
`-m pu=f930', the ompiler additionally optimizes it for the Fujitsu MB86930
hip, whi h is the original SPARClite, with no FPU. With `-m pu=f934', the
ompiler additionally optimizes it for the Fujitsu MB86934 hip, whi h is the
more re ent SPARClite with FPU.
With `-m pu=spar let', GCC generates ode for the SPARClet variant of the
SPARC ar hite ture. This adds the integer multiply, multiply/a umulate,
integer divide step and s an (ffs) instru tions whi h exist in SPARClet but
not in SPARC-V7. With `-m pu=ts 701', the ompiler additionally optimizes
it for the TEMIC SPARClet hip.
With `-m pu=v9', GCC generates ode for the V9 variant of the SPARC ar hite ture. This adds 64-bit integer and oating-point move instru tions, 3 additional oating-point ondition ode registers and onditional move instru tions.
With `-m pu=ultraspar ', the ompiler additionally optimizes it for the Sun
UltraSPARC I/II hips. With `-m pu=ultraspar 3', the ompiler additionally
optimizes it for the Sun UltraSPARC III hip.
-mtune= pu_type

Set the instru tion s heduling parameters for ma hine type pu type, but do
not set the instru tion set or register set that the option `-m pu= pu_type '
would.
The same values for `-m pu= pu_type ' an be used for `-mtune= pu_type ',
but the only useful values are those that sele t a parti ular pu implementation. Those are ` ypress', `superspar ', `hyperspar ', `f930', `f934',
`spar lite86x', `ts 701', `ultraspar ', and `ultraspar 3'.

-mv8plus
-mno-v8plus

With `-mv8plus', GCC generates ode for the SPARC-V8+ ABI. The dieren e
from the V8 ABI is that the global and out registers are onsidered 64-bit
wide. This is enabled by default on Solaris in 32-bit mode for all SPARC-V9
pro essors.

172

Using the GNU Compiler Colle tion (GCC)

-mvis
-mno-vis With `-mvis', GCC generates ode that takes advantage of the UltraSPARC
Visual Instru tion Set extensions. The default is `-mno-vis'.

These `-m' options are supported in addition to the above on SPARC-V9 pro essors in
64-bit environments:
-mlittle-endian

Generate ode for a pro essor running in little-endian mode. It is only available
for a few ongurations and most notably not on Solaris and Linux.

-m32
-m64

Generate ode for a 32-bit or 64-bit environment. The 32-bit environment sets
int, long and pointer to 32 bits. The 64-bit environment sets int to 32 bits and
long and pointer to 64 bits.

-m model=medlow

Generate ode for the Medium/Low ode model: 64-bit addresses, programs
must be linked in the low 32 bits of memory. Programs an be stati ally or
dynami ally linked.

-m model=medmid

Generate ode for the Medium/Middle ode model: 64-bit addresses, programs
must be linked in the low 44 bits of memory, the text and data segments must
be less than 2GB in size and the data segment must be lo ated within 2GB of
the text segment.

-m model=medany

Generate ode for the Medium/Anywhere ode model: 64-bit addresses, programs may be linked anywhere in memory, the text and data segments must
be less than 2GB in size and the data segment must be lo ated within 2GB of
the text segment.

-m model=embmedany

Generate ode for the Medium/Anywhere ode model for embedded systems:
64-bit addresses, the text and data segments must be less than 2GB in size, both
starting anywhere in memory (determined at link time). The global register
%g4 points to the base of the data segment. Programs are stati ally linked and
PIC is not supported.

-msta k-bias
-mno-sta k-bias

With `-msta k-bias', GCC assumes that the sta k pointer, and frame pointer
if present, are oset by 2047 whi h must be added ba k when making sta k
frame referen es. This is the default in 64-bit mode. Otherwise, assume no
su h oset is present.
These swit hes are supported in addition to the above on Solaris:
-threads Add support for multithreading using the Solaris threads library. This option
sets ags for both the prepro essor and linker. This option does not ae t
the thread safety of obje t ode produ ed by the ompiler or that of libraries
supplied with it.

Chapter 3: GCC Command Options

-pthreads

173

Add support for multithreading using the POSIX threads library. This option
sets ags for both the prepro essor and linker. This option does not ae t
the thread safety of obje t ode produ ed by the ompiler or that of libraries
supplied with it.

3.17.27 Options for System V

These additional options are available on System V Release 4 for ompatibility with other
ompilers on those systems:
-G

Create a shared obje t. It is re ommended that `-symboli ' or `-shared' be

used instead.

-Qy

Identify the versions of ea h tool used by the ompiler, in a .ident assembler

dire tive in the output.

-Qn

Refrain from adding .ident dire tives to the output le (this is the default).

-YP,dirs

Sear h the dire tories dirs, and no others, for libraries spe ied with `-l'.

-Ym,dir

Look in the dire tory dir to nd the M4 prepro essor. The assembler uses this
option.

3.17.28 TMS320C3x/C4x Options

These `-m' options are dened for TMS320C3x/C4x implementations:

-m pu= pu_type

Set the instru tion set, register set, and instru tion s heduling parameters for
ma hine type pu type. Supported values for pu type are ` 30', ` 31', ` 32',
` 40', and ` 44'. The default is ` 40' to generate ode for the TMS320C40.

-mbig-memory
-mbig
-msmall-memory
-msmall Generates ode for the big or small memory model. The small memory model

assumed that all data ts into one 64K word page. At run-time the data page
(DP) register must be set to point to the 64K page ontaining the .bss and .data
program se tions. The big memory model is the default and requires reloading
of the DP register for every dire t memory a ess.

-mbk
-mno-bk
-mdb
-mno-db

Allow (disallow) allo ation of general integer operands into the blo k ount
register BK.
Enable (disable) generation of ode using de rement and bran h, DB ond(D),
instru tions. This is enabled by default for the C4x. To be on the safe side,
this is disabled for the C3x, sin e the maximum iteration ount on the C3x is
223 + 1 (but who iterates loops more than 223 times on the C3x?). Note that
GCC will try to reverse a loop so that it an utilize the de rement and bran h
instru tion, but will give up if there is more than one memory referen e in the

174

Using the GNU Compiler Colle tion (GCC)

loop. Thus a loop where the loop ounter is de remented an generate slightly
more e ient ode, in ases where the RPTB instru tion annot be utilized.
-mdp-isr-reload
-mparanoid

For e the DP register to be saved on entry to an interrupt servi e routine (ISR),

reloaded to point to the data se tion, and restored on exit from the ISR. This
should not be required unless someone has violated the small memory model
by modifying the DP register, say within an obje t library.

-mmpyi
-mno-mpyi

For the C3x use the 24-bit MPYI instru tion for integer multiplies instead of
a library all to guarantee 32-bit results. Note that if one of the operands is
a onstant, then the multipli ation will be performed using shifts and adds. If
the `-mmpyi' option is not spe ied for the C3x, then squaring operations are
performed inline instead of a library all.

-mfast-fix
-mno-fast-fix

The C3x/C4x FIX instru tion to onvert a oating point value to an integer
value hooses the nearest integer less than or equal to the oating point value
rather than to the nearest integer. Thus if the oating point number is negative,
the result will be in orre tly trun ated an additional ode is ne essary to dete t
and orre t this ase. This option an be used to disable generation of the
additional ode required to orre t the result.

-mrptb
-mno-rptb

Enable (disable) generation of repeat blo k sequen es using the RPTB instru tion for zero overhead looping. The RPTB onstru t is only used for innermost
loops that do not all fun tions or jump a ross the loop boundaries. There is no
advantage having nested RPTB loops due to the overhead required to save and
restore the RC, RS, and RE registers. This is enabled by default with `-O2'.

-mrpts= ount
-mno-rpts

Enable (disable) the use of the single instru tion repeat instru tion RPTS. If a
repeat blo k ontains a single instru tion, and the loop ount an be guaranteed
to be less than the value ount, GCC will emit a RPTS instru tion instead of
a RPTB. If no value is spe ied, then a RPTS will be emitted even if the loop
ount annot be determined at ompile time. Note that the repeated instru tion
following RPTS does not have to be reloaded from memory ea h iteration, thus
freeing up the CPU buses for operands. However, sin e interrupts are blo ked
by this instru tion, it is disabled by default.

-mloop-unsigned
-mno-loop-unsigned

The maximum iteration ount when using RPTS and RPTB (and DB on the
C40) is 231 + 1 sin e these instru tions test if the iteration ount is negative to

Chapter 3: GCC Command Options

-mti

-mregparm
-mmemparm

175

terminate the loop. If the iteration ount is unsigned there is a possibility than
the 231 + 1 maximum iteration ount may be ex eeded. This swit h allows an
unsigned iteration ount.
Try to emit an assembler syntax that the TI assembler (asm30) is happy with.
This also enfor es ompatibility with the API employed by the TI C3x C ompiler. For example, long doubles are passed as stru tures rather than in oating
point registers.
Generate ode that uses registers (sta k) for passing arguments to fun tions.
By default, arguments are passed in registers where possible rather than by
pushing arguments on to the sta k.

-mparallel-insns
-mno-parallel-insns

Allow the generation of parallel instru tions. This is enabled by default with
`-O2'.

-mparallel-mpy
-mno-parallel-mpy

Allow the generation of MPY||ADD and MPY||SUB parallel instru tions,

provided `-mparallel-insns' is also spe ied. These instru tions have tight
register onstraints whi h an pessimize the ode generation of large fun tions.

3.17.29 V850 Options

These `-m' options are dened for V850 implementations:

-mlong- alls
-mno-long- alls

Treat all alls as being far away (near). If alls are assumed to be far away,
the ompiler will always load the fun tions address up into a register, and all
indire t through the pointer.

-mno-ep
-mep

Do not optimize (do optimize) basi blo ks that use the same index pointer 4
or more times to opy pointer into the ep register, and use the shorter sld and
sst instru tions. The `-mep' option is on by default if you optimize.

-mno-prolog-fun tion
-mprolog-fun tion

-mspa e
-mtda=n

Do not use (do use) external fun tions to save and restore registers at the
prologue and epilogue of a fun tion. The external fun tions are slower, but use
less ode spa e if more than one fun tion saves the same number of registers.
The `-mprolog-fun tion' option is on by default if you optimize.
Try to make the ode as small as possible. At present, this just turns on the
`-mep' and `-mprolog-fun tion' options.
Put stati or global variables whose size is n bytes or less into the tiny data
area that register ep points to. The tiny data area an hold up to 256 bytes in
total (128 bytes for byte referen es).

176

-msda=n
-mzda=n
-mv850

Using the GNU Compiler Colle tion (GCC)

Put stati or global variables whose size is n bytes or less into the small data
area that register gp points to. The small data area an hold up to 64 kilobytes.
Put stati or global variables whose size is n bytes or less into the rst 32
kilobytes of memory.
Spe ify that the target pro essor is the V850.

-mbig-swit h

Generate ode suitable for big swit h tables. Use this option only if the assembler/linker omplain about out of range bran hes within a swit h table.

-mapp-regs

This option will ause r2 and r5 to be used in the ode generated by the ompiler.
This setting is the default.

-mno-app-regs

This option will ause r2 and r5 to be treated as xed registers.

-mv850e1 Spe ify that the target pro essor is the V850E1. The prepro essor onstants
`__v850e1__' and `__v850e__' will be dened if this option is used.
-mv850e Spe ify that the target pro essor is the V850E. The prepro essor onstant
`__v850e__' will be dened if this option is used.
If neither `-mv850' nor `-mv850e' nor `-mv850e1' are dened then a default target pro essor will be hosen and the relevant `__v850*__' prepro essor onstant
will be dened.
The prepro essor onstants `__v850' and `__v851__' are always dened, regardless of whi h pro essor variant is the target.
-mdisable- allt

This option will suppress generation of the CALLT instru tion for the v850e and
v850e1 avors of the v850 ar hite ture. The default is `-mno-disable- allt'
whi h allows the CALLT instru tion to be used.

3.17.30 VAX Options

These `-m' options are dened for the VAX:

-munix
Do not output ertain jump instru tions (aobleq and so on) that the Unix
assembler for the VAX annot handle a ross long ranges.
-mgnu
Do output those jump instru tions, on the assumption that you will assemble
with the GNU assembler.
-mg
Output ode for g-format oating point numbers instead of d-format.

3.17.31 x86-64 Options

These are listed under See Se tion 3.17.11 [i386 and x86-64 Options, page 130.

3.17.32 Xstormy16 Options

These options are dened for Xstormy16:

-msim
Choose startup les and linker s ript suitable for the simulator.

Chapter 3: GCC Command Options

177

3.17.33 Xtensa Options

These options are supported for Xtensa targets:

-m onst16
-mno- onst16

Enable or disable use of CONST16 instru tions for loading onstant values. The
CONST16 instru tion is urrently not a standard option from Tensili a. When
enabled, CONST16 instru tions are always used in pla e of the standard L32R instru tions. The use of CONST16 is enabled by default only if the L32R instru tion
is not available.

-mfused-madd
-mno-fused-madd

Enable or disable use of fused multiply/add and multiply/subtra t instru tions

in the oating-point option. This has no ee t if the oating-point option
is not also enabled. Disabling fused multiply/add and multiply/subtra t instru tions for es the ompiler to use separate instru tions for the multiply and
add/subtra t operations. This may be desirable in some ases where stri t
IEEE 754- ompliant results are required: the fused multiply add/subtra t instru tions do not round the intermediate result, thereby produ ing results with
more bits of pre ision than spe ied by the IEEE standard. Disabling fused
multiply add/subtra t instru tions also ensures that the program output is not
sensitive to the ompiler's ability to ombine multiply and add/subtra t operations.

-mtext-se tion-literals
-mno-text-se tion-literals

Control the treatment of literal pools. The default is `-mno-text-se tion-literals',

whi h pla es literals in a separate se tion in the output le. This allows the
literal pool to be pla ed in a data RAM/ROM, and it also allows the linker to
ombine literal pools from separate obje t les to remove redundant literals
and improve ode size. With `-mtext-se tion-literals', the literals are
interspersed in the text se tion in order to keep them as lose as possible to
their referen es. This may be ne essary for large assembly les.

-mtarget-align
-mno-target-align

When this option is enabled, GCC instru ts the assembler to automati ally align
instru tions to redu e bran h penalties at the expense of some ode density. The
assembler attempts to widen density instru tions to align bran h targets and
the instru tions following all instru tions. If there are not enough pre eding
safe density instru tions to align a target, no widening will be performed. The
default is `-mtarget-align'. These options do not ae t the treatment of autoaligned instru tions like LOOP, whi h the assembler will always align, either by
widening density instru tions or by inserting no-op instru tions.

-mlong alls
-mno-long alls

When this option is enabled, GCC instru ts the assembler to translate dire t
alls to indire t alls unless it an determine that the target of a dire t all is

178

Using the GNU Compiler Colle tion (GCC)

in the range allowed by the all instru tion. This translation typi ally o urs
for alls to fun tions in other sour e les. Spe i ally, the assembler translates
a dire t CALL instru tion into an L32R followed by a CALLX instru tion. The
default is `-mno-long alls'. This option should be used in programs where
the all target an potentially be out of range. This option is implemented in
the assembler, not the ompiler, so the assembly ode generated by GCC will
still show dire t all instru tions|look at the disassembled obje t ode to see
the a tual instru tions. Note that the assembler will use an indire t all for
every ross-le all, not just those that really will be out of range.

3.17.34 zSeries Options

These are listed under See Se tion 3.17.24 [S/390 and zSeries Options, page 165.

3.18 Options for Code Generation Conventions

These ma hine-independent options ontrol the interfa e onventions used in ode generation.
Most of them have both positive and negative forms; the negative form of `-ffoo' would
be `-fno-foo'. In the table below, only one of the forms is listed|the one whi h is not the
default. You an gure out the other form by either removing `no-' or adding it.
-fbounds- he k

For front-ends that support it, generate additional ode to he k that indi es
used to a ess arrays are within the de lared range. This is urrently only
supported by the Java and Fortran 77 front-ends, where this option defaults to
true and false respe tively.

-ftrapv

This option generates traps for signed over ow on addition, subtra tion, multipli ation operations.

-fwrapv

This option instru ts the ompiler to assume that signed arithmeti over ow of
addition, subtra tion and multipli ation wraps around using twos- omplement
representation. This ag enables some optimizations and disables other. This
option is enabled by default for the Java front-end, as required by the Java
language spe i ation.

-fex eptions

Enable ex eption handling. Generates extra ode needed to propagate ex eptions. For some targets, this implies GCC will generate frame unwind information for all fun tions, whi h an produ e signi ant data size overhead, although
it does not ae t exe ution. If you do not spe ify this option, GCC will enable
it by default for languages like C++ whi h normally require ex eption handling,
and disable it for languages like C that do not normally require it. However,
you may need to enable this option when ompiling C ode that needs to interoperate properly with ex eption handlers written in C++. You may also wish
to disable this option if you are ompiling older C++ programs that don't use
ex eption handling.

Chapter 3: GCC Command Options

179

-fnon- all-ex eptions

Generate ode that allows trapping instru tions to throw ex eptions. Note that
this requires platform-spe i runtime support that does not exist everywhere.
Moreover, it only allows trapping instru tions to throw ex eptions, i.e. memory
referen es or oating point instru tions. It does not allow ex eptions to be
thrown from arbitrary signal handlers su h as SIGALRM.

-funwind-tables

Similar to `-fex eptions', ex ept that it will just generate any needed stati
data, but will not ae t the generated ode in any other way. You will normally
not enable this option; instead, a language pro essor that needs this handling
would enable it on your behalf.

-fasyn hronous-unwind-tables

Generate unwind table in dwarf2 format, if supported by target ma hine. The

table is exa t at ea h instru tion boundary, so it an be used for sta k unwinding
from asyn hronous events (su h as debugger or garbage olle tor).

-fp -stru t-return

Return \short" stru t and union values in memory like longer ones, rather
than in registers. This onvention is less e ient, but it has the advantage
of allowing inter allability between GCC- ompiled les and les ompiled with
other ompilers, parti ularly the Portable C Compiler (p ).
The pre ise onvention for returning stru tures in memory depends on the target onguration ma ros.
Short stru tures and unions are those whose size and alignment mat h that of
some integer type.
Warning: ode ompiled with the `-fp -stru t-return' swit h is not binary
ompatible with ode ompiled with the `-freg-stru t-return' swit h. Use
it to onform to a non-default appli ation binary interfa e.

-freg-stru t-return
Return stru t and union values in registers when possible. This is more e ient for small stru tures than `-fp -stru t-return'.

If you spe ify neither `-fp -stru t-return' nor `-freg-stru t-return',
GCC defaults to whi hever onvention is standard for the target. If there is
no standard onvention, GCC defaults to `-fp -stru t-return', ex ept on
targets where GCC is the prin ipal ompiler. In those ases, we an hoose
the standard, and we hose the more e ient register return alternative.
Warning: ode ompiled with the `-freg-stru t-return' swit h is not binary
ompatible with ode ompiled with the `-fp -stru t-return' swit h. Use
it to onform to a non-default appli ation binary interfa e.
-fshort-enums

Allo ate to an enum type only as many bytes as it needs for the de lared range
of possible values. Spe i ally, the enum type will be equivalent to the smallest
integer type whi h has enough room.

180

Using the GNU Compiler Colle tion (GCC)

the `-fshort-enums' swit h auses GCC to generate ode that is not

binary ompatible with ode generated without that swit h. Use it to onform
to a non-default appli ation binary interfa e.
Warning:

-fshort-double

Use the same size for double as for float.

Warning: the `-fshort-double' swit h auses GCC to generate ode that is not
binary ompatible with ode generated without that swit h. Use it to onform
to a non-default appli ation binary interfa e.

-fshort-w har

Override the underlying type for `w har_t' to be `short unsigned int' instead
of the default for the target. This option is useful for building programs to run
under WINE.
Warning: the `-fshort-w har' swit h auses GCC to generate ode that is not
binary ompatible with ode generated without that swit h. Use it to onform
to a non-default appli ation binary interfa e.

-fshared-data

Requests that the data and non- onst variables of this ompilation be shared
data rather than private data. The distin tion makes sense only on ertain
operating systems, where shared data is shared between pro esses running the
same program, while private data exists in one opy per pro ess.

-fno- ommon

In C, allo ate even uninitialized global variables in the data se tion of the obje t
le, rather than generating them as ommon blo ks. This has the ee t that
if the same variable is de lared (without extern) in two dierent ompilations,
you will get an error when you link them. The only reason this might be useful
is if you wish to verify that the program will work on other systems whi h
always work this way.

-fno-ident

Ignore the `#ident' dire tive.

-finhibit-size-dire tive
Don't output a .size assembler dire tive, or anything else that would ause

trouble if the fun tion is split in the middle, and the two halves are pla ed at lo ations far apart in memory. This option is used when ompiling ` rtstuff. ';
you should not need to use it for anything else.

-fverbose-asm

-fpi

Put extra ommentary information in the generated assembly ode to make it

more readable. This option is generally only of use to those who a tually need
to read the generated assembly ode (perhaps while debugging the ompiler
itself).
`-fno-verbose-asm', the default, auses the extra information to be omitted
and is useful when omparing two assembler les.
Generate position-independent ode (PIC) suitable for use in a shared library,
if supported for the target ma hine. Su h ode a esses all onstant addresses

Chapter 3: GCC Command Options

181

through a global oset table (GOT). The dynami loader resolves the GOT
entries when the program starts (the dynami loader is not part of GCC; it
is part of the operating system). If the GOT size for the linked exe utable
ex eeds a ma hine-spe i maximum size, you get an error message from the
linker indi ating that `-fpi ' does not work; in that ase, re ompile with `-fPIC'
instead. (These maximums are 8k on the SPARC and 32k on the m68k and
RS/6000. The 386 has no su h limit.)
Position-independent ode requires spe ial support, and therefore works only on
ertain ma hines. For the 386, GCC supports PIC for System V but not for the
Sun 386i. Code generated for the IBM RS/6000 is always position-independent.
-fPIC

-fpie
-fPIE

If supported for the target ma hine, emit position-independent ode, suitable

for dynami linking and avoiding any limit on the size of the global oset table.
This option makes a dieren e on the m68k, PowerPC and SPARC.
Position-independent ode requires spe ial support, and therefore works only
on ertain ma hines.
These options are similar to `-fpi ' and `-fPIC', but generated position independent ode an be only linked into exe utables. Usually these options are
used when `-pie' GCC option will be used during linking.

-ffixed-reg

Treat the register named reg as a xed register; generated ode should never
refer to it (ex ept perhaps as a sta k pointer, frame pointer or in some other
xed role).
reg must be the name of a register. The register names a epted are ma hinespe i and are dened in the REGISTER_NAMES ma ro in the ma hine des ription ma ro le.
This ag does not have a negative form, be ause it spe ies a three-way hoi e.

-f all-used-reg

Treat the register named reg as an allo able register that is lobbered by fun tion alls. It may be allo ated for temporaries or variables that do not live
a ross a all. Fun tions ompiled this way will not save and restore the register
reg.
It is an error to used this ag with the frame pointer or sta k pointer. Use
of this ag for other registers that have xed pervasive roles in the ma hine's
exe ution model will produ e disastrous results.
This ag does not have a negative form, be ause it spe ies a three-way hoi e.

-f all-saved-reg

Treat the register named reg as an allo able register saved by fun tions. It may
be allo ated even for temporaries or variables that live a ross a all. Fun tions
ompiled this way will save and restore the register reg if they use it.
It is an error to used this ag with the frame pointer or sta k pointer. Use
of this ag for other registers that have xed pervasive roles in the ma hine's
exe ution model will produ e disastrous results.

182

Using the GNU Compiler Colle tion (GCC)

A dierent sort of disaster will result from the use of this ag for a register in
whi h fun tion values may be returned.
This ag does not have a negative form, be ause it spe ies a three-way hoi e.
-fpa k-stru t[=n

Without a value spe ied, pa k all stru ture members together without holes.
When a value is spe ied (whi h must be a small power of two), pa k stru ture
members a ording to this value, representing the maximum alignment (that
is, obje ts with default alignment requirements larger than this will be output
potentially unaligned at the next tting lo ation.
Warning: the `-fpa k-stru t' swit h auses GCC to generate ode that is
not binary ompatible with ode generated without that swit h. Additionally,
it makes the ode suboptimal. Use it to onform to a non-default appli ation
binary interfa e.

-finstrument-fun tions

Generate instrumentation alls for entry and exit to fun tions. Just after fun tion entry and just before fun tion exit, the following proling fun tions will
be alled with the address of the urrent fun tion and its all site. (On some
platforms, __builtin_return_address does not work beyond the urrent fun tion, so the all site information may not be available to the proling fun tions
otherwise.)
void __ yg_profile_fun _enter (void
void
void __ yg_profile_fun _exit (void
void

*this_fn,
* all_site);
*this_fn,
* all_site);

The rst argument is the address of the start of the urrent fun tion, whi h
may be looked up exa tly in the symbol table.
This instrumentation is also done for fun tions expanded inline in other fun tions. The proling alls will indi ate where, on eptually, the inline fun tion
is entered and exited. This means that addressable versions of su h fun tions
must be available. If all your uses of a fun tion are expanded inline, this may
mean an additional expansion of ode size. If you use `extern inline' in your
C ode, an addressable version of su h fun tions must be provided. (This is
normally the ase anyways, but if you get lu ky and the optimizer always expands the fun tions inline, you might have gotten away without providing stati
opies.)
A fun tion may be given the attribute no_instrument_fun tion, in whi h
ase this instrumentation will not be done. This an be used, for example, for
the proling fun tions listed above, high-priority interrupt routines, and any
fun tions from whi h the proling fun tions annot safely be alled (perhaps
signal handlers, if the proling routines generate output or allo ate memory).
-fsta k- he k

Generate ode to verify that you do not go beyond the boundary of the sta k.
You should spe ify this ag if you are running in an environment with multiple
threads, but only rarely need to spe ify it in a single-threaded environment

Chapter 3: GCC Command Options

183

sin e sta k over ow is automati ally dete ted on nearly all systems if there is
only one sta k.
Note that this swit h does not a tually ause he king to be done; the operating
system must do that. The swit h auses generation of ode to ensure that the
operating system sees the sta k being extended.
-fsta k-limit-register=reg
-fsta k-limit-symbol=sym
-fno-sta k-limit

Generate ode to ensure that the sta k does not grow beyond a ertain value,
either the value of a register or the address of a symbol. If the sta k would grow
beyond the value, a signal is raised. For most targets, the signal is raised before
the sta k overruns the boundary, so it is possible to at h the signal without
taking spe ial pre autions.
For instan e, if the sta k starts at absolute address `0x80000000' and grows
downwards, you an use the ags `-fsta k-limit-symbol=__sta k_limit'
and `-Wl,--defsym,__sta k_limit=0x7ffe0000' to enfor e a sta k limit of
128KB. Note that this may only work with the GNU linker.

-fargument-alias
-fargument-noalias
-fargument-noalias-global

Spe ify the possible relationships among parameters and between parameters
and global data.
`-fargument-alias' spe ies that arguments (parameters) may alias ea h other
and may alias global storage.
`-fargument-noalias' spe ies that arguments do not alias ea h other, but
may alias global storage.
`-fargument-noalias-global' spe ies that arguments do not alias ea h other
and do not alias global storage.
Ea h language will automati ally use whatever option is required by the language standard. You should not need to use these options yourself.

-fleading-unders ore

This option and its ounterpart, `-fno-leading-unders ore', for ibly hange
the way C symbols are represented in the obje t le. One use is to help link
with lega y assembly ode.
Warning: the `-fleading-unders ore' swit h auses GCC to generate ode
that is not binary ompatible with ode generated without that swit h. Use it
to onform to a non-default appli ation binary interfa e. Not all targets provide
omplete support for this swit h.

-ftls-model=model

Alter the thread-lo al storage model to be used (see Se tion 5.49 [ThreadLo al, page 331). The model argument should be one of global-dynami ,
lo al-dynami , initial-exe or lo al-exe .
The default without `-fpi ' is initial-exe ; with `-fpi ' the default is
global-dynami .

184

Using the GNU Compiler Colle tion (GCC)

-fvisibility=default|internal|hidden|prote ted

Set the default ELF image symbol visibility to the spe ied option|all symbols
will be marked with this unless overridden within the ode. Using this feature
an very substantially improve linking and load times of shared obje t libraries,
produ e more optimized ode, provide near-perfe t API export and prevent
symbol lashes. It is strongly re ommended that you use this in any shared
obje ts you distribute.
Despite the nomen lature, default always means publi ie; available to be
linked against from outside the shared obje t. prote ted and internal are
pretty useless in real-world usage so the only other ommonly used option will
be hidden. The default if `-fvisibility' isn't spe ied is default, i.e., make
every symbol publi |this auses the same behavior as previous versions of
GCC.
A good explanation of the benets oered by ensuring ELF symbols have
the orre t visibility is given by \How To Write Shared Libraries" by Ulri h
Drepper (whi h an be found at http://people.redhat. om/~drepper/)|
however a superior solution made possible by this option to marking things
hidden when the default is publi is to make the default hidden and
mark things publi . This is the norm with DLL's on Windows and with
`-fvisibility=hidden' and __attribute__ ((visibility("default")))
instead of __de lspe (dllexport) you get almost identi al semanti s with
identi al syntax. This is a great boon to those working with ross-platform
proje ts.
For those adding visibility support to existing ode, you may nd `#pragma GCC
visibility' of use. This works by you en losing the de larations you wish to
set visibility for with (for example) `#pragma GCC visibility push(hidden)'
and `#pragma GCC visibility pop'. These an be nested up to sixteen times.
Bear in mind that symbol visibility should be viewed as part of the API interfa e
ontra t and thus all new ode should always spe ify visibility when it is not
the default ie; de larations only for use within the lo al DSO should always be
marked expli itly as hidden as so to avoid PLT indire tion overheads|making
this abundantly lear also aids readability and self-do umentation of the ode.
Note that due to ISO C++ spe i ation requirements, operator new and operator
delete must always be of default visibility.
An overview of these te hniques, their benets and how to use them is at
http://www.nedprod. om/programs/g visibility.html.

3.19 Environment Variables Ae ting GCC

This se tion des ribes several environment variables that ae t how GCC operates. Some
of them work by spe ifying dire tories or prexes to use when sear hing for various kinds
of les. Some are used to spe ify other aspe ts of the ompilation environment.
Note that you an also spe ify pla es to sear h using options su h as `-B', `-I' and
`-L' (see Se tion 3.14 [Dire tory Options, page 100). These take pre eden e over pla es
spe ied using environment variables, whi h in turn take pre eden e over those spe ied by

Chapter 3: GCC Command Options

185

the onguration of GCC. See se tion \Controlling the Compilation Driver `g '" in GNU
Compiler Colle tion (GCC) Internals.
LANG
LC_CTYPE
LC_MESSAGES
LC_ALL
These environment variables ontrol the way that GCC uses lo alization in-

formation that allow GCC to work with dierent national onventions. GCC
inspe ts the lo ale ategories LC_CTYPE and LC_MESSAGES if it has been ongured to do so. These lo ale ategories an be set to any value supported by
your installation. A typi al value is `en_GB.UTF-8' for English in the United
Kingdom en oded in UTF-8.
The LC_CTYPE environment variable spe ies hara ter lassi ation. GCC uses
it to determine the hara ter boundaries in a string; this is needed for some
multibyte en odings that ontain quote and es ape hara ters that would otherwise be interpreted as a string end or es ape.
The LC_MESSAGES environment variable spe ies the language to use in diagnosti 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 spe ies the dire tory to use for temporary les. GCC uses
temporary les to hold the output of one stage of ompilation whi h is to be
used as input to the next stage: for example, the output of the prepro essor,
whi h is the input to the ompiler proper.

GCC_EXEC_PREFIX
If GCC_EXEC_PREFIX is set, it spe ies a prex to use in the names of the

subprograms exe uted by the ompiler. No slash is added when this prex is
ombined with the name of a subprogram, but you an spe ify a prex that
ends with a slash if you wish.
If GCC_EXEC_PREFIX is not set, GCC will attempt to gure out an appropriate
prex to use based on the pathname it was invoked with.
If GCC annot nd the subprogram using the spe ied prex, it tries looking
in the usual pla es for the subprogram.
The default value of GCC_EXEC_PREFIX is `prefix /lib/g /' where prex is
the value of prefix when you ran the ` onfigure' s ript.
Other prexes spe ied with `-B' take pre eden e over this prex.
This prex is also used for nding les su h as ` rt0.o' that are used for linking.
In addition, the prex is used in an unusual way in nding the dire tories
to sear h for header les. For ea h of the standard dire tories whose name
normally begins with `/usr/lo al/lib/g ' (more pre isely, with the value
of GCC_INCLUDE_DIR), GCC tries repla ing that beginning with the spe ied
prex to produ e an alternate dire tory name. Thus, with `-Bfoo/', GCC will

186

Using the GNU Compiler Colle tion (GCC)

sear h `foo/bar' where it would normally sear h `/usr/lo al/lib/bar'. These

alternate dire tories are sear hed rst; the standard dire tories ome next.
COMPILER_PATH

The value of COMPILER_PATH is a olon-separated list of dire tories, mu h like

PATH. GCC tries the dire tories thus spe ied when sear hing for subprograms,
if it an't nd the subprograms using GCC_EXEC_PREFIX.

LIBRARY_PATH

The value of LIBRARY_PATH is a olon-separated list of dire tories, mu h like

PATH. When ongured as a native ompiler, GCC tries the dire tories thus
spe ied when sear hing for spe ial linker les, if it an't nd them using GCC_
EXEC_PREFIX. Linking using GCC also uses these dire tories when sear hing for
ordinary libraries for the `-l' option (but dire tories spe ied with `-L' ome

rst).
LANG
This variable is used to pass lo ale information to the ompiler. One way in
whi h this information is used is to determine the hara ter set to be used when
hara ter literals, string literals and omments are parsed in C and C++. When
the ompiler is ongured to allow multibyte hara ters, the following values
for LANG are re ognized:
`C-JIS'
Re ognize JIS hara ters.
`C-SJIS' Re ognize SJIS hara ters.
`C-EUCJP' Re ognize EUCJP hara ters.
If LANG is not dened, or if it has some other value, then the ompiler will use
mblen and mbtow as dened by the default lo ale to re ognize and translate
multibyte hara ters.
Some additional environments variables ae t the behavior of the prepro essor.
CPATH
C_INCLUDE_PATH
CPLUS_INCLUDE_PATH
OBJC_INCLUDE_PATH

Ea h variable's value is a list of dire tories separated by a spe ial hara ter,
mu h like PATH, in whi h to look for header les. The spe ial hara ter, PATH_
SEPARATOR, is target-dependent and determined at GCC build time. For Mi rosoft Windows-based targets it is a semi olon, and for almost all other targets
it is a olon.
CPATH spe ies a list of dire tories to be sear hed as if spe ied with `-I', but
after any paths given with `-I' options on the ommand line. This environment
variable is used regardless of whi h language is being prepro essed.
The remaining environment variables apply only when prepro essing the parti ular language indi ated. Ea h spe ies a list of dire tories to be sear hed as
if spe ied with `-isystem', but after any paths given with `-isystem' options
on the ommand line.
In all these variables, an empty element instru ts the ompiler to sear h its
urrent working dire tory. Empty elements an appear at the beginning or end

Chapter 3: GCC Command Options

187

of a path. For instan e, if the value of CPATH is :/spe ial/in lude, that has
the same ee t as `-I. -I/spe ial/in lude'.
DEPENDENCIES_OUTPUT

If this variable is set, its value spe ies how to output dependen ies for Make
based on the non-system header les pro essed by the ompiler. System header
les are ignored in the dependen y output.
The value of DEPENDENCIES_OUTPUT an be just a le name, in whi h ase the
Make rules are written to that le, guessing the target name from the sour e
le name. Or the value an have the form `file target ', in whi h ase the
rules are written to le le using target as the target name.
In other words, this environment variable is equivalent to ombining the options
`-MM' and `-MF' (see Se tion 3.11 [Prepro essor Options, page 87), with an
optional `-MT' swit h too.

SUNPRO_DEPENDENCIES

This variable is the same as DEPENDENCIES_OUTPUT (see above), ex ept that

system header les are not ignored, so it implies `-M' rather than `-MM'. However,
the dependen e on the main input le is omitted. See Se tion 3.11 [Prepro essor
Options, page 87.

3.20 Using Pre ompiled Headers

Often large proje ts have many header les that are in luded in every sour e le. The time
the ompiler takes to pro ess these header les over and over again an a ount for nearly
all of the time required to build the proje t. To make builds faster, GCC allows users to
`pre ompile' a header le; then, if builds an use the pre ompiled header le they will be
mu h faster.
Caution: There are a few known situations where GCC will rash when trying to use
a pre ompiled header. If you have trouble with a pre ompiled header, you should remove
the pre ompiled header and ompile without it. In addition, please use GCC's on-line
defe t-tra king system to report any problems you en ounter with pre ompiled headers.
See Chapter 11 [Bugs, page 381.
To reate a pre ompiled header le, simply ompile it as you would any other le, if
ne essary using the `-x' option to make the driver treat it as a C or C++ header le. You
will probably want to use a tool like make to keep the pre ompiled header up-to-date when
the headers it ontains hange.
A pre ompiled header le will be sear hed for when #in lude is seen in the ompilation.
As it sear hes for the in luded le (see se tion \Sear h Path" in The C Prepro essor) the
ompiler looks for a pre ompiled header in ea h dire tory just before it looks for the in lude
le in that dire tory. The name sear hed for is the name spe ied in the #in lude with
`.g h' appended. If the pre ompiled header le an't be used, it is ignored.
For instan e, if you have #in lude "all.h", and you have `all.h.g h' in the same
dire tory as `all.h', then the pre ompiled header le will be used if possible, and the
original header will be used otherwise.
Alternatively, you might de ide to put the pre ompiled header le in a dire tory and use
`-I' to ensure that dire tory is sear hed before (or instead of) the dire tory ontaining the

188

Using the GNU Compiler Colle tion (GCC)

original header. Then, if you want to he k that the pre ompiled header le is always used,
you an put a le of the same name as the original header in this dire tory ontaining an
#error ommand.
This also works with `-in lude'. So yet another way to use pre ompiled headers, good
for proje ts not designed with pre ompiled header les in mind, is to simply take most
of the header les used by a proje t, in lude them from another header le, pre ompile
that header le, and `-in lude' the pre ompiled header. If the header les have guards
against multiple in lusion, they will be skipped be ause they've already been in luded (in
the pre ompiled header).
If you need to pre ompile the same header le for dierent languages, targets, or ompiler
options, you an instead make a dire tory named like `all.h.g h', and put ea h pre ompiled header in the dire tory, perhaps using `-o'. It doesn't matter what you all the les
in the dire tory, every pre ompiled header in the dire tory will be onsidered. The rst
pre ompiled header en ountered in the dire tory that is valid for this ompilation will be
used; they're sear hed in no parti ular order.
There are many other possibilities, limited only by your imagination, good sense, and the
onstraints of your build system.
A pre ompiled header le an be used only when these onditions apply:
 Only one pre ompiled header an be used in a parti ular ompilation.
 A pre ompiled header an't be used on e the rst C token is seen. You an have
prepro essor dire tives before a pre ompiled header; you an even in lude a pre ompiled
header from inside another header, so long as there are no C tokens before the #in lude.
 The pre ompiled header le must be produ ed for the same language as the urrent
ompilation. You an't use a C pre ompiled header for a C++ ompilation.
 The pre ompiled header le must be produ ed by the same ompiler version and onguration as the urrent ompilation is using. The easiest way to guarantee this is to
use the same ompiler binary for reating and using pre ompiled headers.
 Any ma ros dened before the pre ompiled header is in luded must either be dened
in the same way as when the pre ompiled header was generated, or must not ae t the
pre ompiled header, whi h usually means that they don't appear in the pre ompiled
header at all.
The `-D' option is one way to dene a ma ro before a pre ompiled header is in luded;
using a #define an also do it. There are also some options that dene ma ros impli itly, like `-O' and `-Wdepre ated'; the same rule applies to ma ros dened this
way.
 If debugging information is output when using the pre ompiled header, using `-g' or
similar, the same kind of debugging information must have been output when building
the pre ompiled header. However, a pre ompiled header built using `-g' an be used
in a ompilation when no debugging information is being output.
 The same `-m' options must generally be used when building and using the pre ompiled
header. See Se tion 3.17 [Submodel Options, page 108, for any ases where this rule
is relaxed.
 Ea h of the following options must be the same when building and using the pre ompiled header:

Chapter 3: GCC Command Options

189

-fex eptions -funit-at-a-time

Some other ommand-line options starting with `-f', `-p', or `-O' must be dened in
the same way as when the pre ompiled header was generated. At present, it's not lear
whi h options are safe to hange and whi h are not; the safest hoi e is to use exa tly
the same options when generating and using the pre ompiled header. The following
are known to be safe:
-fprepro essed -pedanti -errors

For all of these ex ept the last, the ompiler will automati ally ignore the pre ompiled
header if the onditions aren't met. If you nd an option ombination that doesn't work
and doesn't ause the pre ompiled header to be ignored, please onsider ling a bug report,
see Chapter 11 [Bugs, page 381.
If you do use diering options when generating and using the pre ompiled header, the
a tual behavior will be a mixture of the behavior for the options. For instan e, if you use
`-g' to generate the pre ompiled header but not when using it, you may or may not get
debugging information for routines in the pre ompiled header.

3.21 Running Protoize

The program protoize is an optional part of GCC. You an use it to add prototypes to a
program, thus onverting the program to ISO C in one respe t. The ompanion program
unprotoize does the reverse: it removes argument types from any prototypes that are
found.
When you run these programs, you must spe ify a set of sour e les as ommand line
arguments. The onversion programs start out by ompiling these les to see what fun tions
they dene. The information gathered about a le foo is saved in a le named `foo.X'.
After s anning omes a tual onversion. The spe ied les are all eligible to be onverted;
any les they in lude (whether sour es or just headers) are eligible as well.
But not all the eligible les are onverted. By default, protoize and unprotoize onvert
only sour e and header les in the urrent dire tory. You an spe ify additional dire tories
whose les should be onverted with the `-d dire tory ' option. You an also spe ify
parti ular les to ex lude with the `-x file ' option. A le is onverted if it is eligible,
its dire tory name mat hes one of the spe ied dire tory names, and its name within the
dire tory has not been ex luded.
Basi onversion with protoize onsists of rewriting most fun tion denitions and fun tion de larations to spe ify the types of the arguments. The only ones not rewritten are
those for varargs fun tions.
protoize optionally inserts prototype de larations at the beginning of the sour e le, to
make them available for any alls that pre ede the fun tion's denition. Or it an insert
prototype de larations with blo k s ope in the blo ks where unde lared fun tions are alled.
Basi onversion with unprotoize onsists of rewriting most fun tion de larations to
remove any argument types, and rewriting fun tion denitions to the old-style pre-ISO
form.
Both onversion programs print a warning for any fun tion de laration or denition that
they an't onvert. You an suppress these warnings with `-q'.

190

Using the GNU Compiler Colle tion (GCC)

The output from protoize or unprotoize repla es the original sour e le. The original
le is renamed to a name ending with `.save' (for DOS, the saved lename ends in `.sav'
without the original `. ' sux). If the `.save' (`.sav' for DOS) le already exists, then the
sour e le is simply dis arded.
protoize and unprotoize both depend on GCC itself to s an the program and olle t
information about the fun tions it uses. So neither of these programs will work until GCC
is installed.
Here is a table of the options you an use with protoize and unprotoize. Ea h option
works with both programs unless otherwise stated.
-B dire tory

Look for the le `SYSCALLS. .X' in dire tory, instead of the usual dire tory
(normally `/usr/lo al/lib'). This le ontains prototype information about
standard system fun tions. This option applies only to protoize.

- ompilation-options

Use ompilation-options as the options when running g to produ e the `.X'

les. The spe ial option `-aux-info' is always passed in addition, to tell g
to write a `.X' le.
Note that the ompilation options must be given as a single argument to
protoize or unprotoize. If you want to spe ify several g options, you must
quote the entire set of ompilation options to make them a single word in the
shell.
There are ertain g arguments that you annot use, be ause they would
produ e the wrong kind of output. These in lude `-g', `-O', `- ', `-S', and `-o'
If you in lude these in the ompilation-options, they are ignored.

-C

Rename les to end in `.C' (`. ' for DOS-based le systems) instead of `. '.
This is onvenient if you are onverting a C program to C++. This option
applies only to protoize.

-g

Add expli it global de larations. This means inserting expli it de larations at

the beginning of ea h sour e le for ea h fun tion that is alled in the le and
was not de lared. These de larations pre ede the rst fun tion denition that
ontains a all to an unde lared fun tion. This option applies only to protoize.

-i string

Indent old-style parameter de larations with the string string. This option
applies only to protoize.
unprotoize onverts prototyped fun tion denitions to old-style fun tion definitions, where the arguments are de lared between the argument list and the
initial `{'. By default, unprotoize uses ve spa es as the indentation. If you
want to indent with just one spa e instead, use `-i " "'.

-k

Keep the `.X' les. Normally, they are deleted after onversion is nished.

-l

Add expli it lo al de larations. protoize with `-l' inserts a prototype de laration for ea h fun tion in ea h blo k whi h alls the fun tion without any
de laration. This option applies only to protoize.

Chapter 3: GCC Command Options

191

-n

Make no real hanges. This mode just prints information about the onversions
that would have been done without `-n'.

-N

Make no `.save' les. The original les are simply deleted. Use this option
with aution.

-p program

Use the program program as the ompiler. Normally, the name `g ' is used.

-q

Work quietly. Most warnings are suppressed.

-v

Print the version number, just like `-v' for g .

If you need spe ial ompiler options to ompile one of your program's sour e les, then
you should generate that le's `.X' le spe ially, by running g on that sour e le with the
appropriate options and the option `-aux-info'. Then run protoize on the entire set of
les. protoize will use the existing `.X' le be ause it is newer than the sour e le. For
example:
g -Dfoo=bar file1. -aux-info file1.X
protoize *.

You need to in lude the spe ial les along with the rest in the protoize ommand, even
though their `.X' les already exist, be ause otherwise they won't get onverted.
See Se tion 10.9 [Protoize Caveats, page 374, for more information on how to use
protoize su essfully.

192

Using the GNU Compiler Colle tion (GCC)

Chapter 4: C Implementation-dened behavior

193

4 C Implementation-dened behavior

A onforming implementation of ISO C is required to do ument its hoi e of behavior in
ea h of the areas that are designated \implementation dened". The following lists all su h
areas, along with the se tion numbers from the ISO/IEC 9899:1990 and ISO/IEC 9899:1999
standards. Some areas are only implementation-dened in one version of the standard.
Some hoi es depend on the externally determined ABI for the platform (in luding standard hara ter en odings) whi h GCC follows; these are listed as
\determined by ABI" below. See Chapter 8 [Binary Compatibility, page 351, and
http://g .gnu.org/readings.html. Some hoi es are do umented in the prepro essor
manual. See se tion \Implementation-dened behavior" in The C Prepro essor. Some
hoi es are made by the library and operating system (or other environment when
ompiling for a freestanding environment); refer to their do umentation for details.

4.1 Translation


How a diagnosti is identied (C90 3.7, C99 3.10, C90 and C99 5.1.1.3).
Diagnosti s onsist of all the output sent to stderr by GCC.
Whether ea h nonempty sequen e of white-spa e hara ters other than new-line is
retained or repla ed by one spa e hara ter in translation phase 3 (C90 and C99 5.1.1.2).
See se tion \Implementation-dened behavior" in The C Prepro essor.

4.2 Environment
The behavior of most of these points are dependent on the implementation of the C library,
and are not dened by GCC itself.
 The mapping between physi al sour e le multibyte hara ters and the sour e hara ter
set in translation phase 1 (C90 and C99 5.1.1.2).
See se tion \Implementation-dened behavior" in The C Prepro essor.

4.3 Identiers



Whi h additional multibyte hara ters may appear in identiers and their orresponden e to universal hara ter names (C99 6.4.2).
See se tion \Implementation-dened behavior" in The C Prepro essor.
The number of signi ant initial hara ters in an identier (C90 6.1.2, C90 and C99
5.2.4.1, C99 6.4.2).
For internal names, all hara ters are signi ant. For external names, the number of
signi ant hara ters are dened by the linker; for almost all targets, all hara ters are
signi ant.
Whether ase distin tions are signi ant in an identier with external linkage (C90
6.1.2).
This is a property of the linker. C99 requires that ase distin tions are always signi ant
in identiers with external linkage and systems without this property are not supported
by GCC.

194

Using the GNU Compiler Colle tion (GCC)

4.4 Chara ters














The number of bits in a byte (C90 3.4, C99 3.6).

Determined by ABI.
The values of the members of the exe ution hara ter set (C90 and C99 5.2.1).
Determined by ABI.
The unique value of the member of the exe ution hara ter set produ ed for ea h of
the standard alphabeti es ape sequen es (C90 and C99 5.2.2).
Determined by ABI.
The value of a har obje t into whi h has been stored any hara ter other than a
member of the basi exe ution hara ter set (C90 6.1.2.5, C99 6.2.5).
Determined by ABI.
Whi h of signed har or unsigned har has the same range, representation, and behavior as \plain" har (C90 6.1.2.5, C90 6.2.1.1, C99 6.2.5, C99 6.3.1.1).
Determined by ABI. The options `-funsigned- har' and `-fsigned- har' hange the
default. See Se tion 3.4 [Options Controlling C Diale t, page 20.
The mapping of members of the sour e hara ter set (in hara ter onstants and string
literals) to members of the exe ution hara ter set (C90 6.1.3.4, C99 6.4.4.4, C90 and
C99 5.1.1.2).
Determined by ABI.
The value of an integer hara ter onstant ontaining more than one hara ter or
ontaining a hara ter or es ape sequen e that does not map to a single-byte exe ution
hara ter (C90 6.1.3.4, C99 6.4.4.4).
See se tion \Implementation-dened behavior" in The C Prepro essor.
The value of a wide hara ter onstant ontaining more than one multibyte hara ter,
or ontaining a multibyte hara ter or es ape sequen e not represented in the extended
exe ution hara ter set (C90 6.1.3.4, C99 6.4.4.4).
See se tion \Implementation-dened behavior" in The C Prepro essor.
The urrent lo ale used to onvert a wide hara ter onstant onsisting of a single
multibyte hara ter that maps to a member of the extended exe ution hara ter set
into a orresponding wide hara ter ode (C90 6.1.3.4, C99 6.4.4.4).
See se tion \Implementation-dened behavior" in The C Prepro essor.
The urrent lo ale used to onvert a wide string literal into orresponding wide hara ter odes (C90 6.1.4, C99 6.4.5).
See se tion \Implementation-dened behavior" in The C Prepro essor.
The value of a string literal ontaining a multibyte hara ter or es ape sequen e not
represented in the exe ution hara ter set (C90 6.1.4, C99 6.4.5).
See se tion \Implementation-dened behavior" in The C Prepro essor.

4.5 Integers


Any extended integer types that exist in the implementation (C99 6.2.5).
GCC does not support any extended integer types.

Chapter 4: C Implementation-dened behavior





195

Whether signed integer types are represented using sign and magnitude, two's omplement, or one's omplement, and whether the extraordinary value is a trap representation or an ordinary value (C99 6.2.6.2).
GCC supports only two's omplement integer types, and all bit patterns are ordinary
values.
The rank of any extended integer type relative to another extended integer type with
the same pre ision (C99 6.3.1.1).
GCC does not support any extended integer types.
The result of, or the signal raised by, onverting an integer to a signed integer type when
the value annot be represented in an obje t of that type (C90 6.2.1.2, C99 6.3.1.3).
For onversion to a type of width N , the value is redu ed modulo 2N to be within range
of the type; no signal is raised.
The results of some bitwise operations on signed integers (C90 6.3, C99 6.5).
Bitwise operators a t on the representation of the value in luding both the sign and
value bits, where the sign bit is onsidered immediately above the highest-value value
bit. Signed `>>' a ts on negative numbers by sign extension.
GCC does not use the latitude given in C99 only to treat ertain aspe ts of signed `<<'
as undened, but this is subje t to hange.
The sign of the remainder on integer division (C90 6.3.5).
GCC always follows the C99 requirement that the result of division is trun ated towards
zero.

4.6 Floating point








The a ura y of the oating-point operations and of the library fun tions in <math.h>
and < omplex.h> that return oating-point results (C90 and C99 5.2.4.2.2).
The a ura y is unknown.
The rounding behaviors hara terized by non-standard values of FLT_ROUNDS
(C90 and C99 5.2.4.2.2).
GCC does not use su h values.
The evaluation methods hara terized by non-standard negative values of FLT_EVAL_
METHOD (C99 5.2.4.2.2).
GCC does not use su h values.
The dire tion of rounding when an integer is onverted to a oating-point number that
annot exa tly represent the original value (C90 6.2.1.3, C99 6.3.1.4).
C99 Annex F is followed.
The dire tion of rounding when a oating-point number is onverted to a narrower
oating-point number (C90 6.2.1.4, C99 6.3.1.5).
C99 Annex F is followed.
How the nearest representable value or the larger or smaller representable value immediately adja ent to the nearest representable value is hosen for ertain oating
onstants (C90 6.1.3.1, C99 6.4.4.2).
C99 Annex F is followed.

196

Using the GNU Compiler Colle tion (GCC)

Whether and how oating expressions are ontra ted when not disallowed by the FP_
CONTRACT pragma (C99 6.5).
Expressions are urrently only ontra ted if `-funsafe-math-optimizations' or
`-ffast-math' are used. This is subje t to hange.
The default state for the FENV_ACCESS pragma (C99 7.6.1).
This pragma is not implemented, but the default is to \o" unless `-frounding-math'
is used in whi h ase it is \on".
Additional oating-point ex eptions, rounding modes, environments, and lassi ations, and their ma ro names (C99 7.6, C99 7.12).
This is dependent on the implementation of the C library, and is not dened by GCC
itself.
The default state for the FP_CONTRACT pragma (C99 7.12.2).
This pragma is not implemented. Expressions are urrently only ontra ted if
`-funsafe-math-optimizations' or `-ffast-math' are used. This is subje t to
hange.
Whether the \inexa t" oating-point ex eption an be raised when the rounded result
a tually does equal the mathemati al result in an IEC 60559 onformant implementation (C99 F.9).
This is dependent on the implementation of the C library, and is not dened by GCC
itself.
Whether the \under ow" (and \inexa t") oating-point ex eption an be raised when
a result is tiny but not inexa t in an IEC 60559 onformant implementation (C99 F.9).
This is dependent on the implementation of the C library, and is not dened by GCC
itself.






4.7 Arrays and pointers




1

The result of onverting a pointer to an integer or vi e versa (C90 6.3.4, C99 6.3.2.3).
A ast from pointer to integer dis ards most-signi ant bits if the pointer representation
is larger than the integer type, sign-extends1 if the pointer representation is smaller
than the integer type, otherwise the bits are un hanged.
A ast from integer to pointer dis ards most-signi ant bits if the pointer representation
is smaller than the integer type, extends a ording to the signedness of the integer type
if the pointer representation is larger than the integer type, otherwise the bits are
un hanged.
When asting from pointer to integer and ba k again, the resulting pointer must referen e the same obje t as the original pointer, otherwise the behavior is undened.
That is, one may not use integer arithmeti to avoid the undened behavior of pointer
arithmeti as pros ribed in C99 6.5.6/8.
The size of the result of subtra ting two pointers to elements of the same array (C90
6.3.6, C99 6.5.6).
The value is as spe ied in the standard and the type is determined by the ABI.

Future versions of GCC may zero-extend, or use a target-dened ptr_extend pattern. Do not rely on
sign extension.

Chapter 4: C Implementation-dened behavior

197

4.8 Hints


The extent to whi h suggestions made by using the register storage- lass spe ier
are ee tive (C90 6.5.1, C99 6.7.1).
The register spe ier ae ts ode generation only in these ways:
 When used as part of the register variable extension, see Se tion 5.37 [Expli it Reg
Vars, page 266.
 When `-O0' is in use, the ompiler allo ates distin t sta k memory for all variables
that do not have the register storage- lass spe ier; if register is spe ied, the
variable may have a shorter lifespan than the ode would indi ate and may never
be pla ed in memory.
 On some rare x86 targets, setjmp doesn't save the registers in all ir umstan es.
In those ases, GCC doesn't allo ate any variables in registers unless they are
marked register.
The extent to whi h suggestions made by using the inline fun tion spe ier are ee tive
(C99 6.7.4).
GCC will not inline any fun tions if the `-fno-inline' option is used or if `-O0' is
used. Otherwise, GCC may still be unable to inline a fun tion for many reasons; the
`-Winline' option may be used to determine if a fun tion has not been inlined and why
not.

4.9 Stru tures, unions, enumerations, and bit-elds










A member of a union obje t is a essed using a member of a dierent type (C90 6.3.2.3).
The relevant bytes of the representation of the obje t are treated as an obje t of the
type used for the a ess. This may be a trap representation.
Whether a \plain" int bit-eld is treated as a signed int bit-eld or as an unsigned
int bit-eld (C90 6.5.2, C90 6.5.2.1, C99 6.7.2, C99 6.7.2.1).
By default it is treated as signed int but this may be hanged by the
`-funsigned-bitfields' option.
Allowable bit-eld types other than _Bool, signed int, and unsigned int (C99
6.7.2.1).
No other types are permitted in stri tly onforming mode.
Whether a bit-eld an straddle a storage-unit boundary (C90 6.5.2.1, C99 6.7.2.1).
Determined by ABI.
The order of allo ation of bit-elds within a unit (C90 6.5.2.1, C99 6.7.2.1).
Determined by ABI.
The alignment of non-bit-eld members of stru tures (C90 6.5.2.1, C99 6.7.2.1).
Determined by ABI.
The integer type ompatible with ea h enumerated type (C90 6.5.2.2, C99 6.7.2.2).
Normally, the type is unsigned int if there are no negative values in the enumeration,
otherwise int. If `-fshort-enums' is spe ied, then if there are negative values it is
the rst of signed har, short and int that an represent all the values, otherwise it

198

Using the GNU Compiler Colle tion (GCC)

is the rst of unsigned har, unsigned short and unsigned int that an represent
all the values.
On some targets, `-fshort-enums' is the default; this is determined by the ABI.

4.10 Qualiers



What onstitutes an a ess to an obje t that has volatile-qualied type (C90 6.5.3, C99
6.7.3).
See Se tion 6.1 [When is a Volatile Obje t A essed?, page 335.

4.11 De larators


The maximum number of de larators that may modify an arithmeti , stru ture or
union type (C90 6.5.4).
GCC is only limited by available memory.

4.12 Statements


The maximum number of ase values in a swit h statement (C90 6.6.4.2).

GCC is only limited by available memory.

4.13 Prepro essing dire tives

See se tion \Implementation-dened behavior" in The C Prepro essor, for details of these
aspe ts of implementation-dened behavior.
 How sequen es in both forms of header names are mapped to headers or external sour e
le names (C90 6.1.7, C99 6.4.7).
 Whether the value of a hara ter onstant in a onstant expression that ontrols onditional in lusion mat hes the value of the same hara ter onstant in the exe ution
hara ter set (C90 6.8.1, C99 6.10.1).
 Whether the value of a single- hara ter hara ter onstant in a onstant expression
that ontrols onditional in lusion may have a negative value (C90 6.8.1, C99 6.10.1).
 The pla es that are sear hed for an in luded `<>' delimited header, and how the pla es
are spe ied or the header is identied (C90 6.8.2, C99 6.10.2).
 How the named sour e le is sear hed for in an in luded `""' delimited header (C90
6.8.2, C99 6.10.2).
 The method by whi h prepro essing tokens (possibly resulting from ma ro expansion)
in a #in lude dire tive are ombined into a header name (C90 6.8.2, C99 6.10.2).
 The nesting limit for #in lude pro essing (C90 6.8.2, C99 6.10.2).
 Whether the `#' operator inserts a `\' hara ter before the `\' hara ter that begins a
universal hara ter name in a hara ter onstant or string literal (C99 6.10.3.2).
 The behavior on ea h re ognized non-STDC #pragma dire tive (C90 6.8.6, C99 6.10.6).
See se tion \Pragmas" in The C Prepro essor, for details of pragmas a epted by GCC
on all targets. See Se tion 5.47 [Pragmas A epted by GCC, page 327, for details of
target-spe i pragmas.

Chapter 4: C Implementation-dened behavior

199

The denitions for __DATE__ and __TIME__ when respe tively, the date and time of
translation are not available (C90 6.8.8, C99 6.10.8).

4.14 Library fun tions

The behavior of most of these points are dependent on the implementation of the C library,
and are not dened by GCC itself.
 The null pointer onstant to whi h the ma ro NULL expands (C90 7.1.6, C99 7.17).
In <stddef.h>, NULL expands to ((void *)0). GCC does not provide the other headers
whi h dene NULL and some library implementations may use other denitions in those
headers.

4.15 Ar hite ture






The values or expressions assigned to the ma ros spe ied in the headers <float.h>,
<limits.h>, and <stdint.h> (C90 and C99 5.2.4.2, C99 7.18.2, C99 7.18.3).
Determined by ABI.
The number, order, and en oding of bytes in any obje t (when not expli itly spe ied
in this International Standard) (C99 6.2.6.1).
Determined by ABI.
The value of the result of the sizeof operator (C90 6.3.3.4, C99 6.5.3.4).
Determined by ABI.

4.16 Lo ale-spe i behavior

The behavior of these points are dependent on the implementation of the C library, and are
not dened by GCC itself.

200

Using the GNU Compiler Colle tion (GCC)

Chapter 5: Extensions to the C Language Family

201

5 Extensions to the C Language Family

GNU C provides several language features not found in ISO standard C. (The `-pedanti '
option dire ts GCC to print a warning message if any of these features is used.) To test for
the availability of these features in onditional ompilation, he k for a predened ma ro
__GNUC__, whi h is always dened under GCC.
These extensions are available in C and Obje tive-C. Most of them are also available in
C++. See Chapter 6 [Extensions to the C++ Language, page 335, for extensions that apply
only to C++.
Some features that are in ISO C99 but not C89 or C++ are also, as extensions, a epted
by GCC in C89 mode and in C++.

5.1 Statements and De larations in Expressions

A ompound statement en losed in parentheses may appear as an expression in GNU C.
This allows you to use loops, swit hes, and lo al variables within an expression.
Re all that a ompound statement is a sequen e of statements surrounded by bra es; in
this onstru t, parentheses go around the bra es. For example:
({ int y = foo (); int z;
if (y > 0) z = y;
else z = - y;
z; })

is a valid (though slightly more omplex than ne essary) expression for the absolute value
of foo ().
The last thing in the ompound statement should be an expression followed by a semi olon; the value of this subexpression serves as the value of the entire onstru t. (If you use
some other kind of statement last within the bra es, the onstru t has type void, and thus
ee tively no value.)
This feature is espe ially useful in making ma ro denitions \safe" (so that they evaluate
ea h operand exa tly on e). For example, the \maximum" fun tion is ommonly dened
as a ma ro in standard C as follows:
#define max(a,b) ((a) > (b) ? (a) : (b))

But this denition omputes either a or b twi e, with bad results if the operand has side
ee ts. In GNU C, if you know the type of the operands (here taken as int), you an dene
the ma ro safely as follows:
#define maxint(a,b) \
({int _a = (a), _b = (b); _a > _b ? _a : _b; })

Embedded statements are not allowed in onstant expressions, su h as the value of an

enumeration onstant, the width of a bit-eld, or the initial value of a stati variable.
If you don't know the type of the operand, you an still do this, but you must use typeof
(see Se tion 5.6 [Typeof, page 207).
In G++, the result value of a statement expression undergoes array and fun tion pointer
de ay, and is returned by value to the en losing expression. For instan e, if A is a lass,
then

202

Using the GNU Compiler Colle tion (GCC)

A a;
({a;}).Foo ()

will onstru t a temporary A obje t to hold the result of the statement expression, and that
will be used to invoke Foo. Therefore the this pointer observed by Foo will not be the
address of a.
Any temporaries reated within a statement within a statement expression will be destroyed at the statement's end. This makes statement expressions inside ma ros slightly
dierent from fun tion alls. In the latter ase temporaries introdu ed during argument
evaluation will be destroyed at the end of the statement that in ludes the fun tion all. In
the statement expression ase they will be destroyed during the statement expression. For
instan e,
#define ma ro(a) ({__typeof__(a) b = (a); b + 3; })
template<typename T> T fun tion(T a) { T b = a; return b + 3; }
void foo ()
{
ma ro (X ());
fun tion (X ());
}

will have dierent pla es where temporaries are destroyed. For the ma ro ase, the temporary X will be destroyed just after the initialization of b. In the fun tion ase that
temporary will be destroyed when the fun tion returns.
These onsiderations mean that it is probably a bad idea to use statement-expressions of
this form in header les that are designed to work with C++. (Note that some versions of
the GNU C Library ontained header les using statement-expression that lead to pre isely
this bug.)
Jumping into a statement expression with goto or using a swit h statement outside the
statement expression with a ase or default label inside the statement expression is not
permitted. Jumping into a statement expression with a omputed goto (see Se tion 5.3
[Labels as Values, page 203) yields undened behavior. Jumping out of a statement expression is permitted, but if the statement expression is part of a larger expression then
it is unspe ied whi h other subexpressions of that expression have been evaluated ex ept
where the language denition requires ertain subexpressions to be evaluated before or after
the statement expression. In any ase, as with a fun tion all the evaluation of a statement
expression is not interleaved with the evaluation of other parts of the ontaining expression.
For example,
foo (), (({ bar1 (); goto a; 0; }) + bar2 ()), baz();

will all foo and bar1 and will not all baz but may or may not all bar2. If bar2 is alled,
it will be alled after foo and before bar1

5.2 Lo ally De lared Labels

GCC allows you to de lare lo al labels in any nested blo k s ope. A lo al label is just like
an ordinary label, but you an only referen e it (with a goto statement, or by taking its
address) within the blo k in whi h it was de lared.
A lo al label de laration looks like this:

Chapter 5: Extensions to the C Language Family

203

__label__ label ;

or

__label__ label1, label2, /* . . . */;

Lo al label de larations must ome at the beginning of the blo k, before any ordinary
de larations or statements.
The label de laration denes the label name, but does not dene the label itself. You must
do this in the usual way, with label :, within the statements of the statement expression.
The lo al label feature is useful for omplex ma ros. If a ma ro ontains nested loops, a
goto an be useful for breaking out of them. However, an ordinary label whose s ope is the
whole fun tion annot be used: if the ma ro an be expanded several times in one fun tion,
the label will be multiply dened in that fun tion. A lo al label avoids this problem. For
example:
#define SEARCH(value, array, target)
do {
__label__ found;
typeof (target) _SEARCH_target = (target);
typeof (*(array)) *_SEARCH_array = (array);
int i, j;
int value;
for (i = 0; i < max; i++)
for (j = 0; j < max; j++)
if (_SEARCH_array[i[j == _SEARCH_target)
{ (value) = i; goto found; }
(value) = -1;
found:;
} while (0)

\
\
\
\
\
\
\
\
\
\
\
\
\

This ould also be written using a statement-expression:

#define SEARCH(array, target)
({
__label__ found;
typeof (target) _SEARCH_target = (target);
typeof (*(array)) *_SEARCH_array = (array);
int i, j;
int value;
for (i = 0; i < max; i++)
for (j = 0; j < max; j++)
if (_SEARCH_array[i[j == _SEARCH_target)
{ value = i; goto found; }
value = -1;
found:
value;
})

\
\
\
\
\
\
\
\
\
\
\
\
\
\

Lo al label de larations also make the labels they de lare visible to nested fun tions, if
there are any. See Se tion 5.4 [Nested Fun tions, page 204, for details.

5.3 Labels as Values

You an get the address of a label dened in the urrent fun tion (or a ontaining fun tion)
with the unary operator `&&'. The value has type void *. This value is a onstant and an
be used wherever a onstant of that type is valid. For example:
void *ptr;

204

Using the GNU Compiler Colle tion (GCC)

/* . . . */
ptr = &&foo;

To use these values, you need to be able to jump to one. This is done with the omputed
goto statement1 , goto *exp ;. For example,
goto *ptr;

Any expression of type void * is allowed.

One way of using these onstants is in initializing a stati array that will serve as a jump
table:
stati void *array[ = { &&foo, &&bar, &&ha k };

Then you an sele t a label with indexing, like this:

goto *array[i;

Note that this does not he k whether the subs ript is in bounds|array indexing in C never
does that.
Su h an array of label values serves a purpose mu h like that of the swit h statement.
The swit h statement is leaner, so use that rather than an array unless the problem does
not t a swit h statement very well.
Another use of label values is in an interpreter for threaded ode. The labels within the
interpreter fun tion an be stored in the threaded ode for super-fast dispat hing.
You may not use this me hanism to jump to ode in a dierent fun tion. If you do that,
totally unpredi table things will happen. The best way to avoid this is to store the label
address only in automati variables and never pass it as an argument.
An alternate way to write the above example is
stati onst int array[ = { &&foo - &&foo, &&bar - &&foo,
&&ha k - &&foo };
goto *(&&foo + array[i);

This is more friendly to ode living in shared libraries, as it redu es the number of dynami
relo ations that are needed, and by onsequen e, allows the data to be read-only.

5.4 Nested Fun tions

A nested fun tion is a fun tion dened inside another fun tion. (Nested fun tions are not
supported for GNU C++.) The nested fun tion's name is lo al to the blo k where it is
dened. For example, here we dene a nested fun tion named square, and all it twi e:
foo (double a, double b)
{
double square (double z) { return z * z; }
}

return square (a) + square (b);

The nested fun tion an a ess all the variables of the ontaining fun tion that are visible
at the point of its denition. This is alled lexi al s oping. For example, here we show a
nested fun tion whi h uses an inherited variable named offset:
1

The analogous feature in Fortran is alled an assigned goto, but that name seems inappropriate in C,
where one an do more than simply store label addresses in label variables.

Chapter 5: Extensions to the C Language Family

205

bar (int *array, int offset, int size)

{
int a ess (int *array, int index)
{ return array[index + offset; }
int i;
/* . . . */
for (i = 0; i < size; i++)
/* . . . */ a ess (array, i) /* . . . */
}

Nested fun tion denitions are permitted within fun tions in the pla es where variable
denitions are allowed; that is, in any blo k, mixed with the other de larations and statements in the blo k.
It is possible to all the nested fun tion from outside the s ope of its name by storing its
address or passing the address to another fun tion:
ha k (int *array, int size)
{
void store (int index, int value)
{ array[index = value; }
}

intermediate (store, size);

Here, the fun tion intermediate re eives the address of store as an argument. If
intermediate alls store, the arguments given to store are used to store into array.
But this te hnique works only so long as the ontaining fun tion (ha k, in this example)

does not exit.

If you try to all the nested fun tion through its address after the ontaining fun tion has
exited, all hell will break loose. If you try to all it after a ontaining s ope level has exited,
and if it refers to some of the variables that are no longer in s ope, you may be lu ky, but
it's not wise to take the risk. If, however, the nested fun tion does not refer to anything
that has gone out of s ope, you should be safe.
GCC implements taking the address of a nested fun tion using a te hnique alled trampolines. A paper des ribing them is available as
http://people.debian.org/~aaronl/Usenix88-lexi .pdf.

A nested fun tion an jump to a label inherited from a ontaining fun tion, provided
the label was expli itly de lared in the ontaining fun tion (see Se tion 5.2 [Lo al Labels,
page 202). Su h a jump returns instantly to the ontaining fun tion, exiting the nested
fun tion whi h did the goto and any intermediate fun tions as well. Here is an example:

206

Using the GNU Compiler Colle tion (GCC)

bar (int *array, int offset, int size)

{
__label__ failure;
int a ess (int *array, int index)
{
if (index > size)
goto failure;
return array[index + offset;
}
int i;
/* . . . */
for (i = 0; i < size; i++)
/* . . . */ a ess (array, i) /* . . . */
/* . . . */
return 0;
/* Control omes here from a ess
if it dete ts an error. */
failure:
return -1;
}

A nested fun tion always has no linkage. De laring one with extern or stati is erroneous. If you need to de lare the nested fun tion before its denition, use auto (whi h is
otherwise meaningless for fun tion de larations).
bar (int *array, int offset, int size)
{
__label__ failure;
auto int a ess (int *, int);
/* . . . */
int a ess (int *array, int index)
{
if (index > size)
goto failure;
return array[index + offset;
}
/* . . . */
}

5.5 Constru ting Fun tion Calls

Using the built-in fun tions des ribed below, you an re ord the arguments a fun tion
re eived, and all another fun tion with the same arguments, without knowing the number
or types of the arguments.
You an also re ord the return value of that fun tion all, and later return that value,
without knowing what data type the fun tion tried to return (as long as your aller expe ts
that data type).
However, these built-in fun tions may intera t badly with some sophisti ated features or
other extensions of the language. It is, therefore, not re ommended to use them outside
very simple fun tions a ting as mere forwarders for their arguments.
void * __builtin_apply_args ()
[Built-in Fun tion
This built-in fun tion returns a pointer to data des ribing how to perform a all with
the same arguments as were passed to the urrent fun tion.

Chapter 5: Extensions to the C Language Family

207

The fun tion saves the arg pointer register, stru ture value address, and all registers
that might be used to pass arguments to a fun tion into a blo k of memory allo ated
on the sta k. Then it returns the address of that blo k.
void * __builtin_apply (void (*fun tion )(), void
[Built-in Fun tion
*arguments, size t size )
This built-in fun tion invokes fun tion with a opy of the parameters des ribed by
arguments and size.
The value of arguments should be the value returned by __builtin_apply_args.
The argument size spe ies the size of the sta k argument data, in bytes.
This fun tion returns a pointer to data des ribing how to return whatever value was
returned by fun tion. The data is saved in a blo k of memory allo ated on the sta k.
It is not always simple to ompute the proper value for size. The value is used by
__builtin_apply to ompute the amount of data that should be pushed on the sta k
and opied from the in oming argument area.
void __builtin_return (void *result )
[Built-in Fun tion
This built-in fun tion returns the value des ribed by result from the ontaining fun tion. You should spe ify, for result, a value returned by __builtin_apply.

5.6 Referring to a Type with typeof

Another way to refer to the type of an expression is with typeof. The syntax of using of
this keyword looks like sizeof, but the onstru t a ts semanti ally like a type name dened
with typedef.
There are two ways of writing the argument to typeof: with an expression or with a
type. Here is an example with an expression:
typeof (x[0(1))

This assumes that x is an array of pointers to fun tions; the type des ribed is that of the
values of the fun tions.
Here is an example with a typename as the argument:
typeof (int *)

Here the type des ribed is that of pointers to int.

If you are writing a header le that must work when in luded in ISO C programs, write
__typeof__ instead of typeof. See Se tion 5.38 [Alternate Keywords, page 268.
A typeof- onstru t an be used anywhere a typedef name ould be used. For example,
you an use it in a de laration, in a ast, or inside of sizeof or typeof.
typeof is often useful in onjun tion with the statements-within-expressions feature.
Here is how the two together an be used to dene a safe \maximum" ma ro that operates
on any arithmeti type and evaluates ea h of its arguments exa tly on e:
#define max(a,b) \
({ typeof (a) _a = (a); \
typeof (b) _b = (b); \
_a > _b ? _a : _b; })

The reason for using names that start with unders ores for the lo al variables is to avoid
on i ts with variable names that o ur within the expressions that are substituted for a

208

Using the GNU Compiler Colle tion (GCC)

and b. Eventually we hope to design a new form of de laration syntax that allows you to
de lare variables whose s opes start only after their initializers; this will be a more reliable
way to prevent su h on i ts.
Some more examples of the use of typeof:
 This de lares y with the type of what x points to.
typeof (*x) y;

This de lares y as an array of su h values.

This de lares y as an array of pointers to hara ters:

typeof (*x) y[4;

typeof (typeof ( har *)[4) y;

It is equivalent to the following traditional C de laration:

har *y[4;

To see the meaning of the de laration using typeof, and why it might be a useful way
to write, rewrite it with these ma ros:
#define pointer(T) typeof(T *)
#define array(T, N) typeof(T [N)

Now the de laration an be rewritten this way:

array (pointer ( har), 4) y;

Thus, array (pointer ( har), 4) is the type of arrays of 4 pointers to har.

Compatibility Note: In addition to typeof, GCC 2 supported a more limited extension
whi h permitted one to write
typedef T = expr ;

with the ee t of de laring T to have the type of the expression expr. This extension does
not work with GCC 3 (versions between 3.0 and 3.2 will rash; 3.2.1 and later give an error).
Code whi h relies on it should be rewritten to use typeof:
typedef typeof(expr ) T ;

This will work with all versions of GCC.

5.7 Conditionals with Omitted Operands

The middle operand in a onditional expression may be omitted. Then if the rst operand
is nonzero, its value is the value of the onditional expression.
Therefore, the expression
x ? : y

has the value of x if that is nonzero; otherwise, the value of y.

This example is perfe tly equivalent to
x ? x : y

In this simple ase, the ability to omit the middle operand is not espe ially useful. When it
be omes useful is when the rst operand does, or may (if it is a ma ro argument), ontain a
side ee t. Then repeating the operand in the middle would perform the side ee t twi e.
Omitting the middle operand uses the value already omputed without the undesirable
ee ts of re omputing it.

Chapter 5: Extensions to the C Language Family

209

5.8 Double-Word Integers

ISO C99 supports data types for integers that are at least 64 bits wide, and as an extension
GCC supports them in C89 mode and in C++. Simply write long long int for a signed
integer, or unsigned long long int for an unsigned integer. To make an integer onstant
of type long long int, add the sux `LL' to the integer. To make an integer onstant of
type unsigned long long int, add the sux `ULL' to the integer.
You an use these types in arithmeti like any other integer types. Addition, subtra tion,
and bitwise boolean operations on these types are open- oded on all types of ma hines.
Multipli ation is open- oded if the ma hine supports fullword-to-doubleword a widening
multiply instru tion. Division and shifts are open- oded only on ma hines that provide
spe ial support. The operations that are not open- oded use spe ial library routines that
ome with GCC.
There may be pitfalls when you use long long types for fun tion arguments, unless you
de lare fun tion prototypes. If a fun tion expe ts type int for its argument, and you pass
a value of type long long int, onfusion will result be ause the aller and the subroutine
will disagree about the number of bytes for the argument. Likewise, if the fun tion expe ts
long long int and you pass int. The best way to avoid su h problems is to use prototypes.

5.9 Complex Numbers

ISO C99 supports omplex oating data types, and as an extension GCC supports them in
C89 mode and in C++, and supports omplex integer data types whi h are not part of ISO
C99. You an de lare omplex types using the keyword _Complex. As an extension, the
older GNU keyword __ omplex__ is also supported.
For example, `_Complex double x;' de lares x as a variable whose real part and imaginary part are both of type double. `_Complex short int y;' de lares y to have real and
imaginary parts of type short int; this is not likely to be useful, but it shows that the set
of omplex types is omplete.
To write a onstant with a omplex data type, use the sux `i' or `j' (either one; they are
equivalent). For example, 2.5fi has type _Complex float and 3i has type _Complex int.
Su h a onstant always has a pure imaginary value, but you an form any omplex value
you like by adding one to a real onstant. This is a GNU extension; if you have an ISO
C99 onforming C library (su h as GNU lib ), and want to onstru t omplex onstants of
oating type, you should in lude < omplex.h> and use the ma ros I or _Complex_I instead.
To extra t the real part of a omplex-valued expression exp, write __real__ exp . Likewise, use __imag__ to extra t the imaginary part. This is a GNU extension; for values of
oating type, you should use the ISO C99 fun tions realf, real, reall, imagf, imag
and imagl, de lared in < omplex.h> and also provided as built-in fun tions by GCC.
The operator `~' performs omplex onjugation when used on a value with a omplex
type. This is a GNU extension; for values of oating type, you should use the ISO C99
fun tions onjf, onj and onjl, de lared in < omplex.h> and also provided as built-in
fun tions by GCC.
GCC an allo ate omplex automati variables in a non ontiguous fashion; it's even
possible for the real part to be in a register while the imaginary part is on the sta k (or
vi e-versa). Only the DWARF2 debug info format an represent this, so use of DWARF2 is

210

Using the GNU Compiler Colle tion (GCC)

re ommended. If you are using the stabs debug info format, GCC des ribes a non ontiguous
omplex variable as if it were two separate variables of non omplex type. If the variable's
a tual name is foo, the two  titious variables are named foo$real and foo$imag. You
an examine and set these two  titious variables with your debugger.

5.10 Hex Floats

ISO C99 supports oating-point numbers written not only in the usual de imal notation,
su h as 1.55e1, but also numbers su h as 0x1.fp3 written in hexade imal format. As
a GNU extension, GCC supports this in C89 mode (ex ept in some ases when stri tly
onforming) and in C++. In that format the `0x' hex introdu er and the `p' or `P' exponent
eld are mandatory. The exponent is a de imal number that indi ates the power of 2 by
15
, `p3' multiplies it by 8,
whi h the signi ant part will be multiplied. Thus `0x1.f' is 1 16
and the value of 0x1.fp3 is the same as 1.55e1.
Unlike for oating-point numbers in the de imal notation the exponent is always required
in the hexade imal notation. Otherwise the ompiler would not be able to resolve the
ambiguity of, e.g., 0x1.f. This ould mean 1.0f or 1.9375 sin e `f' is also the extension
for oating-point onstants of type float.

5.11 Arrays of Length Zero

Zero-length arrays are allowed in GNU C. They are very useful as the last element of a
stru ture whi h is really a header for a variable-length obje t:
stru t line {
int length;
har ontents[0;
};
stru t line *thisline = (stru t line *)
mallo (sizeof (stru t line) + this_length);
thisline->length = this_length;

In ISO C90, you would have to give ontents a length of 1, whi h means either you
waste spa e or ompli ate the argument to mallo .
In ISO C99, you would use a exible array member, whi h is slightly dierent in syntax
and semanti s:
 Flexible array members are written as ontents[ without the 0.
 Flexible array members have in omplete type, and so the sizeof operator may not
be applied. As a quirk of the original implementation of zero-length arrays, sizeof
evaluates to zero.
 Flexible array members may only appear as the last member of a stru t that is
otherwise non-empty.
 A stru ture ontaining a exible array member, or a union ontaining su h a stru ture
(possibly re ursively), may not be a member of a stru ture or an element of an array.
(However, these uses are permitted by GCC as extensions.)
GCC versions before 3.0 allowed zero-length arrays to be stati ally initialized, as if they
were exible arrays. In addition to those ases that were useful, it also allowed initializations
in situations that would orrupt later data. Non-empty initialization of zero-length arrays is

Chapter 5: Extensions to the C Language Family

211

now treated like any ase where there are more initializer elements than the array holds, in
that a suitable warning about "ex ess elements in array" is given, and the ex ess elements
(all of them, in this ase) are ignored.
Instead GCC allows stati initialization of exible array members. This is equivalent to
dening a new stru ture ontaining the original stru ture followed by an array of su ient
size to ontain the data. I.e. in the following, f1 is onstru ted as if it were de lared like
f2.
stru t f1 {
int x; int y[;
} f1 = { 1, { 2, 3, 4 } };
stru t f2 {
stru t f1 f1; int data[3;
} f2 = { { 1 }, { 2, 3, 4 } };

The onvenien e of this extension is that f1 has the desired type, eliminating the need to
onsistently refer to f2.f1.
This has symmetry with normal stati arrays, in that an array of unknown size is also
written with [.
Of ourse, this extension only makes sense if the extra data omes at the end of a top-level
obje t, as otherwise we would be overwriting data at subsequent osets. To avoid undue
ompli ation and onfusion with initialization of deeply nested arrays, we simply disallow
any non-empty initialization ex ept when the stru ture is the top-level obje t. For example:
stru t foo { int x; int y[; };
stru t bar { stru t foo z; };
stru t
stru t
stru t
stru t

foo
bar
bar
foo

a = { 1, {
b = { { 1,
= { { 1,
d[1 = { {

2, 3, 4 } };
{ 2, 3, 4 } } };
{ } } };
1 { 2, 3, 4 } } };

//
//
//
//

Valid.
Invalid.
Valid.
Invalid.

5.12 Stru tures With No Members

GCC permits a C stru ture to have no members:
stru t empty {
};

The stru ture will have size zero. In C++, empty stru tures are part of the language. G++
treats empty stru tures as if they had a single member of type har.

5.13 Arrays of Variable Length

Variable-length automati arrays are allowed in ISO C99, and as an extension GCC a epts
them in C89 mode and in C++. (However, GCC's implementation of variable-length arrays
does not yet onform in detail to the ISO C99 standard.) These arrays are de lared like any
other automati arrays, but with a length that is not a onstant expression. The storage
is allo ated at the point of de laration and deallo ated when the bra e-level is exited. For
example:
FILE *
on at_fopen ( har *s1, har *s2, har *mode)
{
har str[strlen (s1) + strlen (s2) + 1;

212

Using the GNU Compiler Colle tion (GCC)

str py (str, s1);

str at (str, s2);
return fopen (str, mode);

Jumping or breaking out of the s ope of the array name deallo ates the storage. Jumping
into the s ope is not allowed; you get an error message for it.
You an use the fun tion allo a to get an ee t mu h like variable-length arrays. The
fun tion allo a is available in many other C implementations (but not in all). On the
other hand, variable-length arrays are more elegant.
There are other dieren es between these two methods. Spa e allo ated with allo a
exists until the ontaining fun tion returns. The spa e for a variable-length array is deallo ated as soon as the array name's s ope ends. (If you use both variable-length arrays
and allo a in the same fun tion, deallo ation of a variable-length array will also deallo ate
anything more re ently allo ated with allo a.)
You an also use variable-length arrays as arguments to fun tions:
stru t entry
tester (int len, har data[len[len)
{
/* . . . */
}

The length of an array is omputed on e when the storage is allo ated and is remembered
for the s ope of the array in ase you a ess it with sizeof.
If you want to pass the array rst and the length afterward, you an use a forward
de laration in the parameter list|another GNU extension.
stru t entry
tester (int len; har data[len[len, int len)
{
/* . . . */
}

The `int len' before the semi olon is a parameter forward de laration, and it serves the
purpose of making the name len known when the de laration of data is parsed.
You an write any number of su h parameter forward de larations in the parameter list.
They an be separated by ommas or semi olons, but the last one must end with a semi olon,
whi h is followed by the \real" parameter de larations. Ea h forward de laration must
mat h a \real" de laration in parameter name and data type. ISO C99 does not support
parameter forward de larations.

5.14 Ma ros with a Variable Number of Arguments.

In the ISO C standard of 1999, a ma ro an be de lared to a ept a variable number of
arguments mu h as a fun tion an. The syntax for dening the ma ro is similar to that of
a fun tion. Here is an example:
#define debug(format, ...) fprintf (stderr, format, __VA_ARGS__)

Here `...' is a variable argument. In the invo ation of su h a ma ro, it represents the
zero or more tokens until the losing parenthesis that ends the invo ation, in luding any
ommas. This set of tokens repla es the identier __VA_ARGS__ in the ma ro body wherever
it appears. See the CPP manual for more information.

Chapter 5: Extensions to the C Language Family

213

GCC has long supported variadi ma ros, and used a dierent syntax that allowed you
to give a name to the variable arguments just like any other argument. Here is an example:
#define debug(format, args...) fprintf (stderr, format, args)

This is in all ways equivalent to the ISO C example above, but arguably more readable
and des riptive.
GNU CPP has two further variadi ma ro extensions, and permits them to be used with
either of the above forms of ma ro denition.
In standard C, you are not allowed to leave the variable argument out entirely; but you
are allowed to pass an empty argument. For example, this invo ation is invalid in ISO C,
be ause there is no omma after the string:
debug ("A message")

GNU CPP permits you to ompletely omit the variable arguments in this way. In the
above examples, the ompiler would omplain, though sin e the expansion of the ma ro still
has the extra omma after the format string.
To help solve this problem, CPP behaves spe ially for variable arguments used with the
token paste operator, `##'. If instead you write
#define debug(format, ...) fprintf (stderr, format, ## __VA_ARGS__)

and if the variable arguments are omitted or empty, the `##' operator auses the prepro essor to remove the omma before it. If you do provide some variable arguments in
your ma ro invo ation, GNU CPP does not omplain about the paste operation and instead
pla es the variable arguments after the omma. Just like any other pasted ma ro argument,
these arguments are not ma ro expanded.

5.15 Slightly Looser Rules for Es aped Newlines

Re ently, the prepro essor has relaxed its treatment of es aped newlines. Previously, the
newline had to immediately follow a ba kslash. The urrent implementation allows whitespa e in the form of spa es, horizontal and verti al tabs, and form feeds between the ba kslash and the subsequent newline. The prepro essor issues a warning, but treats it as a valid
es aped newline and ombines the two lines to form a single logi al line. This works within
omments and tokens, as well as between tokens. Comments are not treated as whitespa e
for the purposes of this relaxation, sin e they have not yet been repla ed with spa es.

5.16 Non-Lvalue Arrays May Have Subs ripts

In ISO C99, arrays that are not lvalues still de ay to pointers, and may be subs ripted,
although they may not be modied or used after the next sequen e point and the unary
`&' operator may not be applied to them. As an extension, GCC allows su h arrays to
be subs ripted in C89 mode, though otherwise they do not de ay to pointers outside C99
mode. For example, this is valid in GNU C though not valid in C89:
stru t foo {int a[4;};
stru t foo f();
bar (int index)
{
return f().a[index;
}

214

Using the GNU Compiler Colle tion (GCC)

5.17 Arithmeti on void- and Fun tion-Pointers

In GNU C, addition and subtra tion operations are supported on pointers to void and on
pointers to fun tions. This is done by treating the size of a void or of a fun tion as 1.
A onsequen e of this is that sizeof is also allowed on void and on fun tion types, and
returns 1.
The option `-Wpointer-arith' requests a warning if these extensions are used.

5.18 Non-Constant Initializers

As in standard C++ and ISO C99, the elements of an aggregate initializer for an automati
variable are not required to be onstant expressions in GNU C. Here is an example of an
initializer with run-time varying elements:
foo (float f, float g)
{
float beat_freqs[2 = { f-g, f+g };
/* . . . */
}

5.19 Compound Literals

ISO C99 supports ompound literals. A ompound literal looks like a ast ontaining an
initializer. Its value is an obje t of the type spe ied in the ast, ontaining the elements
spe ied in the initializer; it is an lvalue. As an extension, GCC supports ompound literals
in C89 mode and in C++.
Usually, the spe ied type is a stru ture. Assume that stru t foo and stru ture are
de lared as shown:
stru t foo {int a; har b[2;} stru ture;

Here is an example of onstru ting a stru t foo with a ompound literal:

stru ture = ((stru t foo) {x + y, 'a', 0});

This is equivalent to writing the following:

{
}

stru t foo temp = {x + y, 'a', 0};

stru ture = temp;

You an also onstru t an array. If all the elements of the ompound literal are (made
up of) simple onstant expressions, suitable for use in initializers of obje ts of stati storage
duration, then the ompound literal an be oer ed to a pointer to its rst element and
used in su h an initializer, as shown here:
har **foo = ( har *[) { "x", "y", "z" };

Compound literals for s alar types and union types are is also allowed, but then the
ompound literal is equivalent to a ast.
As a GNU extension, GCC allows initialization of obje ts with stati storage duration
by ompound literals (whi h is not possible in ISO C99, be ause the initializer is not a
onstant). It is handled as if the obje t was initialized only with the bra ket en losed list
if ompound literal's and obje t types mat h. The initializer list of the ompound literal
must be onstant. If the obje t being initialized has array type of unknown size, the size is
determined by ompound literal size.

Chapter 5: Extensions to the C Language Family

215

stati stru t foo x = (stru t foo) {1, 'a', 'b'};

stati int y[ = (int [) {1, 2, 3};
stati int z[ = (int [3) {1};

The above lines are equivalent to the following:

stati stru t foo x = {1, 'a', 'b'};
stati int y[ = {1, 2, 3};
stati int z[ = {1, 0, 0};

5.20 Designated Initializers

Standard C89 requires the elements of an initializer to appear in a xed order, the same as
the order of the elements in the array or stru ture being initialized.
In ISO C99 you an give the elements in any order, spe ifying the array indi es or stru ture
eld names they apply to, and GNU C allows this as an extension in C89 mode as well.
This extension is not implemented in GNU C++.
To spe ify an array index, write `[index =' before the element value. For example,
int a[6 = { [4 = 29, [2 = 15 };

is equivalent to
int a[6 = { 0, 0, 15, 0, 29, 0 };

The index values must be onstant expressions, even if the array being initialized is automati .
An alternative syntax for this whi h has been obsolete sin e GCC 2.5 but GCC still
a epts is to write `[index ' before the element value, with no `='.
To initialize a range of elements to the same value, write `[first ... last = value '.
This is a GNU extension. For example,
int widths[ = { [0 ... 9 = 1, [10 ... 99 = 2, [100 = 3 };

If the value in it has side-ee ts, the side-ee ts will happen only on e, not for ea h initialized eld by the range initializer.
Note that the length of the array is the highest value spe ied plus one.
In a stru ture initializer, spe ify the name of a eld to initialize with `.fieldname ='
before the element value. For example, given the following stru ture,
stru t point { int x, y; };

the following initialization

stru t point p = { .y = yvalue, .x = xvalue };

is equivalent to
stru t point p = { xvalue, yvalue };

Another syntax whi h has the same meaning, obsolete sin e GCC 2.5, is `fieldname :',
as shown here:
stru t point p = { y: yvalue, x: xvalue };

The `[index ' or `.fieldname ' is known as a designator. You an also use a designator
(or the obsolete olon syntax) when initializing a union, to spe ify whi h element of the
union should be used. For example,
union foo { int i; double d; };
union foo f = { .d = 4 };

216

Using the GNU Compiler Colle tion (GCC)

will onvert 4 to a double to store it in the union using the se ond element. By ontrast,
asting 4 to type union foo would store it into the union as the integer i, sin e it is an
integer. (See Se tion 5.22 [Cast to Union, page 216.)
You an ombine this te hnique of naming elements with ordinary C initialization of
su essive elements. Ea h initializer element that does not have a designator applies to the
next onse utive element of the array or stru ture. For example,
int a[6 = { [1 = v1, v2, [4 = v4 };

is equivalent to
int a[6 = { 0, v1, v2, 0, v4, 0 };

Labeling the elements of an array initializer is espe ially useful when the indi es are
hara ters or belong to an enum type. For example:
int whitespa e[256
= { [' ' = 1, ['\t' = 1, ['\h' = 1,
['\f' = 1, ['\n' = 1, ['\r' = 1 };

You an also write a series of `.fieldname ' and `[index ' designators before an `=' to
spe ify a nested subobje t to initialize; the list is taken relative to the subobje t orresponding to the losest surrounding bra e pair. For example, with the `stru t point' de laration
above:
stru t point ptarray[10 = { [2.y = yv2, [2.x = xv2, [0.x = xv0 };

If the same eld is initialized multiple times, it will have value from the last initialization.
If any su h overridden initialization has side-ee t, it is unspe ied whether the side-ee t
happens or not. Currently, GCC will dis ard them and issue a warning.

5.21 Case Ranges

You an spe ify a range of onse utive values in a single ase label, like this:
ase low ... high :

This has the same ee t as the proper number of individual ase labels, one for ea h integer
value from low to high, in lusive.
This feature is espe ially useful for ranges of ASCII hara ter odes:
ase 'A' ... 'Z':
Be areful: Write spa es around the ..., for otherwise it may be parsed wrong when you
use it with integer values. For example, write this:

ase 1 ... 5:

rather than this:

ase 1...5:

5.22 Cast to a Union Type

A ast to union type is similar to other asts, ex ept that the type spe ied is a union type.
You an spe ify the type either with union tag or with a typedef name. A ast to union
is a tually a onstru tor though, not a ast, and hen e does not yield an lvalue like normal
asts. (See Se tion 5.19 [Compound Literals, page 214.)
The types that may be ast to the union type are those of the members of the union.
Thus, given the following union and variables:

Chapter 5: Extensions to the C Language Family

217

union foo { int i; double d; };

int x;
double y;

both x and y an be ast to type union foo.

Using the ast as the right-hand side of an assignment to a variable of union type is
equivalent to storing in a member of the union:
union foo u;
/* . . . */
u = (union foo) x
u = (union foo) y




u.i = x
u.d = y

You an also use the union ast as a fun tion argument:

void ha k (union foo);
/* . . . */
ha k ((union foo) x);

5.23 Mixed De larations and Code

ISO C99 and ISO C++ allow de larations and ode to be freely mixed within ompound
statements. As an extension, GCC also allows this in C89 mode. For example, you ould
do:
int i;
/* . . . */
i++;
int j = i + 2;

Ea h identier is visible from where it is de lared until the end of the en losing blo k.

5.24 De laring Attributes of Fun tions

In GNU C, you de lare ertain things about fun tions alled in your program whi h help
the ompiler optimize fun tion alls and he k your ode more arefully.
The keyword __attribute__ allows you to spe ify spe ial attributes when making a
de laration. This keyword is followed by an attribute spe i ation inside double parentheses. The following attributes are urrently dened for fun tions on all targets: noreturn,
noinline, always_inline, pure, onst, nothrow, sentinel, format, format_arg, no_
instrument_fun tion, se tion, onstru tor, destru tor, used, unused, depre ated,
weak, mallo , alias, warn_unused_result and nonnull. Several other attributes are dened for fun tions on parti ular target systems. Other attributes, in luding se tion are
supported for variables de larations (see Se tion 5.31 [Variable Attributes, page 233) and
for types (see Se tion 5.32 [Type Attributes, page 238).
You may also spe ify attributes with `__' pre eding and following ea h keyword. This
allows you to use them in header les without being on erned about a possible ma ro of
the same name. For example, you may use __noreturn__ instead of noreturn.
See Se tion 5.25 [Attribute Syntax, page 228, for details of the exa t syntax for using
attributes.
alias ("target ")
The alias attribute auses the de laration to be emitted as an alias for another

symbol, whi h must be spe ied. For instan e,

218

Using the GNU Compiler Colle tion (GCC)

void __f () { /* Do something. */; }

void f () __attribute__ ((weak, alias ("__f")));

de lares `f' to be a weak alias for `__f'. In C++, the mangled name for the
target must be used. It is an error if `__f' is not dened in the same translation
unit.
Not all target ma hines support this attribute.
always_inline

Generally, fun tions are not inlined unless optimization is spe ied. For fun tions de lared inline, this attribute inlines the fun tion even if no optimization
level was spe ied.
On the Intel 386, the de l attribute auses the ompiler to assume that the
alling fun tion will pop o the sta k spa e used to pass arguments. This is
useful to override the ee ts of the `-mrtd' swit h.

de l

Many fun tions do not examine any values ex ept their arguments, and have
no ee ts ex ept the return value. Basi ally this is just slightly more stri t
lass than the pure attribute below, sin e fun tion is not allowed to read global
memory.
Note that a fun tion that has pointer arguments and examines the data pointed
to must not be de lared onst. Likewise, a fun tion that alls a non- onst
fun tion usually must not be onst. It does not make sense for a onst fun tion
to return void.
The attribute onst is not implemented in GCC versions earlier than 2.5. An
alternative way to de lare that a fun tion has no side ee ts, whi h works in
the urrent version and in some older versions, is as follows:

onst

typedef int intfn ();

extern onst intfn square;

This approa h does not work in GNU C++ from 2.6.0 on, sin e the language
spe ies that the ` onst' must be atta hed to the return value.
onstru tor
destru tor

The onstru tor attribute auses the fun tion to be alled automati ally before exe ution enters main (). Similarly, the destru tor attribute auses the
fun tion to be alled automati ally after main () has ompleted or exit () has
been alled. Fun tions with these attributes are useful for initializing data that
will be used impli itly during the exe ution of the program.
These attributes are not urrently implemented for Obje tive-C.

depre ated

The depre ated attribute results in a warning if the fun tion is used anywhere
in the sour e le. This is useful when identifying fun tions that are expe ted
to be removed in a future version of a program. The warning also in ludes the
lo ation of the de laration of the depre ated fun tion, to enable users to easily
nd further information about why the fun tion is depre ated, or what they
should do instead. Note that the warnings only o urs for uses:

Chapter 5: Extensions to the C Language Family

219

int old_fn () __attribute__ ((depre ated));

int old_fn ();
int (*fn_ptr)() = old_fn;

results in a warning on line 3 but not line 2.

The depre ated attribute an also be used for variables and types (see Se tion 5.31 [Variable Attributes, page 233, see Se tion 5.32 [Type Attributes,
page 238.)
dllexport

dllimport

On Mi rosoft Windows targets and Symbian OS targets the dllexport attribute auses the ompiler to provide a global pointer to a pointer in a DLL,
so that it an be referen ed with the dllimport attribute. On Mi rosoft Windows targets, the pointer name is formed by ombining _imp__ and the fun tion
or variable name.
You an use __de lspe (dllexport) as a synonym for __attribute__
((dllexport)) for ompatibility with other ompilers.
On systems that support the visibility attribute, this attribute also implies
\default" visibility, unless a visibility attribute is expli itly spe ied. You
should avoid the use of dllexport with \hidden" or \internal" visibility; in the
future GCC may issue an error for those ases.
Currently, the dllexport attribute is ignored for inlined fun tions, unless the
`-fkeep-inline-fun tions' ag has been used. The attribute is also ignored
for undened symbols.
When applied to C++ lasses, the attribute marks dened non-inlined member
fun tions and stati data members as exports. Stati onsts initialized in- lass
are not marked unless they are also dened out-of- lass.
For Mi rosoft Windows targets there are alternative methods for in luding the
symbol in the DLL's export table su h as using a `.def' le with an EXPORTS
se tion or, with GNU ld, using the `--export-all' linker ag.
On Mi rosoft Windows and Symbian OS targets, the dllimport attribute
auses the ompiler to referen e a fun tion or variable via a global pointer
to a pointer that is set up by the DLL exporting the symbol. The attribute
implies extern storage. On Mi rosoft Windows targets, the pointer name is
formed by ombining _imp__ and the fun tion or variable name.
You an use __de lspe (dllimport) as a synonym for __attribute__
((dllimport)) for ompatibility with other ompilers.
Currently, the attribute is ignored for inlined fun tions. If the attribute is applied to a symbol denition, an error is reported. If a symbol previously de lared
dllimport is later dened, the attribute is ignored in subsequent referen es,
and a warning is emitted. The attribute is also overridden by a subsequent
de laration as dllexport.
When applied to C++ lasses, the attribute marks non-inlined member fun tions
and stati data members as imports. However, the attribute is ignored for
virtual methods to allow reation of vtables using thunks.

220

Using the GNU Compiler Colle tion (GCC)

On the SH Symbian OS target the dllimport attribute also has another ae t|

it an ause the vtable and run-time type information for a lass to be exported.
This happens when the lass has a dllimport'ed onstru tor or a non-inline, nonpure virtual fun tion and, for either of those two onditions, the lass also has
a inline onstru tor or destru tor and has a key fun tion that is dened in the
urrent translation unit.
For Mi rosoft Windows based targets the use of the dllimport attribute on
fun tions is not ne essary, but provides a small performan e benet by eliminating a thunk in the DLL. The use of the dllimport attribute on imported
variables was required on older versions of the GNU linker, but an now be
avoided by passing the `--enable-auto-import' swit h to the GNU linker. As
with fun tions, using the attribute for a variable eliminates a thunk in the DLL.
One drawba k to using this attribute is that a pointer to a fun tion or variable
marked as dllimport annot be used as a onstant address. On Mi rosoft
Windows targets, the attribute an be disabled for fun tions by setting the
`-mnop-fun-dllimport' ag.
eightbit_data

Use this attribute on the H8/300, H8/300H, and H8S to indi ate that the
spe ied variable should be pla ed into the eight bit data se tion. The ompiler
will generate more e ient ode for ertain operations on data in the eight bit
data area. Note the eight bit data area is limited to 256 bytes of data.
You must use GAS and GLD from GNU binutils version 2.7 or later for this
attribute to work orre tly.

far

On 68HC11 and 68HC12 the far attribute auses the ompiler to use a alling onvention that takes are of swit hing memory banks when entering and
leaving a fun tion. This alling onvention is also the default when using the
`-mlong- alls' option.
On 68HC12 the ompiler will use the all and rt instru tions to all and
return from a fun tion.
On 68HC11 the ompiler will generate a sequen e of instru tions to invoke a
board-spe i routine to swit h the memory bank and all the real fun tion.
The board-spe i routine simulates a all. At the end of a fun tion, it will
jump to a board-spe i routine instead of using rts. The board-spe i return
routine simulates the rt .

fast all On the Intel 386, the fast all attribute auses the ompiler to pass the rst

two arguments in the registers ECX and EDX. Subsequent arguments are
passed on the sta k. The alled fun tion will pop the arguments o the sta k.
If the number of arguments is variable all arguments are pushed on the sta k.

format (ar hetype, string-index, first-to- he k )

The format attribute spe ies that a fun tion takes printf, s anf, strftime
or strfmon style arguments whi h should be type- he ked against a format

string. For example, the de laration:

extern int
my_printf (void *my_obje t, onst har *my_format, ...)

Chapter 5: Extensions to the C Language Family

221

__attribute__ ((format (printf, 2, 3)));

auses the ompiler to he k the arguments in alls to my_printf for onsisten y

with the printf style format string argument my_format.
The parameter ar hetype determines how the format string is interpreted, and
should be printf, s anf, strftime or strfmon. (You an also use __printf_
_, __s anf__, __strftime__ or __strfmon__.) The parameter string-index
spe ies whi h argument is the format string argument (starting from 1), while
rst-to- he k is the number of the rst argument to he k against the format
string. For fun tions where the arguments are not available to be he ked (su h
as vprintf), spe ify the third parameter as zero. In this ase the ompiler
only he ks the format string for onsisten y. For strftime formats, the third
parameter is required to be zero. Sin e non-stati C++ methods have an impli it
this argument, the arguments of su h methods should be ounted from two,
not one, when giving values for string-index and rst-to- he k.
In the example above, the format string (my_format) is the se ond argument
of the fun tion my_print, and the arguments to he k start with the third
argument, so the orre t parameters for the format attribute are 2 and 3.
The format attribute allows you to identify your own fun tions whi h take
format strings as arguments, so that GCC an he k the alls to these fun tions
for errors. The ompiler always (unless `-ffreestanding' or `-fno-builtin'
is used) he ks formats for the standard library fun tions printf, fprintf,
sprintf, s anf, fs anf, ss anf, strftime, vprintf, vfprintf and vsprintf
whenever su h warnings are requested (using `-Wformat'), so there is no need
to modify the header le `stdio.h'. In C99 mode, the fun tions snprintf,
vsnprintf, vs anf, vfs anf and vss anf are also he ked. Ex ept in stri tly
onforming C standard modes, the X/Open fun tion strfmon is also he ked
as are printf_unlo ked and fprintf_unlo ked. See Se tion 3.4 [Options
Controlling C Diale t, page 20.
The target may provide additional types of format he ks. See Se tion 5.46
[Format Che ks Spe i to Parti ular Target Ma hines, page 327.
format_arg (string-index )
The format_arg attribute spe ies that a fun tion takes a format string for
a printf, s anf, strftime or strfmon style fun tion and modies it (for ex-

ample, to translate it into another language), so the result an be passed to

a printf, s anf, strftime or strfmon style fun tion (with the remaining arguments to the format fun tion the same as they would have been for the
unmodied string). For example, the de laration:
extern har *
my_dgettext ( har *my_domain, onst har *my_format)
__attribute__ ((format_arg (2)));

auses the ompiler to he k the arguments in alls to a printf, s anf,

strftime or strfmon type fun tion, whose format string argument is a
all to the my_dgettext fun tion, for onsisten y with the format string
argument my_format. If the format_arg attribute had not been spe ied, all
the ompiler ould tell in su h alls to format fun tions would be that the
format string argument is not onstant; this would generate a warning when

222

Using the GNU Compiler Colle tion (GCC)

`-Wformat-nonliteral' is used, but the alls ould not be he ked without

the attribute.
The parameter string-index spe ies whi h argument is the format string argument (starting from one). Sin e non-stati C++ methods have an impli it this
argument, the arguments of su h methods should be ounted from two.
The format-arg attribute allows you to identify your own fun tions whi h
modify format strings, so that GCC an he k the alls to printf, s anf,
strftime or strfmon type fun tion whose operands are a all to one of your
own fun tion. The ompiler always treats gettext, dgettext, and d gettext
in this manner ex ept when stri t ISO C support is requested by `-ansi' or an
appropriate `-std' option, or `-ffreestanding' or `-fno-builtin' is used. See
Se tion 3.4 [Options Controlling C Diale t, page 20.
fun tion_ve tor

Use this attribute on the H8/300, H8/300H, and H8S to indi ate that the spe ied fun tion should be alled through the fun tion ve tor. Calling a fun tion
through the fun tion ve tor will redu e ode size, however; the fun tion ve tor
has a limited size (maximum 128 entries on the H8/300 and 64 entries on the
H8/300H and H8S) and shares spa e with the interrupt ve tor.
You must use GAS and GLD from GNU binutils version 2.7 or later for this
attribute to work orre tly.

interrupt

Use this attribute on the ARM, AVR, C4x, M32R/D and Xstormy16 ports
to indi ate that the spe ied fun tion is an interrupt handler. The ompiler
will generate fun tion entry and exit sequen es suitable for use in an interrupt
handler when this attribute is present.
Note, interrupt handlers for the m68k, H8/300, H8/300H, H8S, and SH pro essors an be spe ied via the interrupt_handler attribute.
Note, on the AVR, interrupts will be enabled inside the fun tion.
Note, for the ARM, you an spe ify the kind of interrupt to be handled by
adding an optional parameter to the interrupt attribute like this:
void f () __attribute__ ((interrupt ("IRQ")));

Permissible values for this parameter are: IRQ, FIQ, SWI, ABORT and UNDEF.
interrupt_handler

Use this attribute on the m68k, H8/300, H8/300H, H8S, and SH to indi ate
that the spe ied fun tion is an interrupt handler. The ompiler will generate
fun tion entry and exit sequen es suitable for use in an interrupt handler when
this attribute is present.

long_ all/short_ all

This attribute spe ies how a parti ular fun tion is alled on ARM. Both
attributes override the `-mlong- alls' (see Se tion 3.17.2 [ARM Options,
page 109) ommand line swit h and #pragma long_ alls settings. The long_
all attribute auses the ompiler to always all the fun tion by rst loading
its address into a register and then using the ontents of that register. The

Chapter 5: Extensions to the C Language Family

223

short_ all attribute always pla es the oset to the fun tion from the all site
into the `BL' instru tion dire tly.
long all/short all

On the RS/6000 and PowerPC, the long all attribute auses the ompiler
to always all this fun tion via a pointer, just as it would if the `-mlong all'
option had been spe ied. The short all attribute auses the ompiler not
to do this. These attributes override both the `-mlong all' swit h and the
#pragma long all setting.
See Se tion 3.17.23 [RS/6000 and PowerPC Options, page 155, for more information on whether long alls are ne essary.

mallo

The mallo attribute is used to tell the ompiler that a fun tion may be treated
as if any non-NULL pointer it returns annot alias any other pointer valid when
the fun tion returns. This will often improve optimization. Standard fun tions
with this property in lude mallo and allo . reallo -like fun tions have this
property as long as the old pointer is never referred to (in luding omparing it
to the new pointer) after the fun tion returns a non-NULL value.

model (model-name )

On the M32R/D, use this attribute to set the addressability of an obje t, and of
the ode generated for a fun tion. The identier model-name is one of small,
medium, or large, representing ea h of the ode models.
Small model obje ts live in the lower 16MB of memory (so that their addresses
an be loaded with the ld24 instru tion), and are allable with the bl instru tion.
Medium model obje ts may live anywhere in the 32-bit address spa e (the
ompiler will generate seth/add3 instru tions to load their addresses), and are
allable with the bl instru tion.
Large model obje ts may live anywhere in the 32-bit address spa e (the ompiler
will generate seth/add3 instru tions to load their addresses), and may not be
rea hable with the bl instru tion (the ompiler will generate the mu h slower
seth/add3/jl instru tion sequen e).
On IA-64, use this attribute to set the addressability of an obje t. At present,
the only supported identier for model-name is small, indi ating addressability via \small" (22-bit) addresses (so that their addresses an be loaded with
the addl instru tion). Caveat: su h addressing is by denition not position
independent and hen e this attribute must not be used for obje ts dened by
shared libraries.

naked

Use this attribute on the ARM, AVR, C4x and IP2K ports to indi ate that the
spe ied fun tion does not need prologue/epilogue sequen es generated by the
ompiler. It is up to the programmer to provide these sequen es.

near

On 68HC11 and 68HC12 the near attribute auses the ompiler to use the
normal alling onvention based on jsr and rts. This attribute an be used to
an el the ee t of the `-mlong- alls' option.

224

Using the GNU Compiler Colle tion (GCC)

no_instrument_fun tion
If `-finstrument-fun tions' is given, proling fun tion alls will be generated

at entry and exit of most user- ompiled fun tions. Fun tions with this attribute
will not be so instrumented.

noinline This fun tion attribute prevents a fun tion from being onsidered for inlining.
nonnull (arg-index, ...)
The nonnull attribute spe ies that some fun tion parameters should be non-

null pointers. For instan e, the de laration:

extern void *
my_mem py (void *dest, onst void *sr , size_t len)
__attribute__((nonnull (1, 2)));

auses the ompiler to he k that, in alls to my_mem py, arguments dest and
sr are non-null. If the ompiler determines that a null pointer is passed in
an argument slot marked as non-null, and the `-Wnonnull' option is enabled, a
warning is issued. The ompiler may also hoose to make optimizations based
on the knowledge that ertain fun tion arguments will not be null.
If no argument index list is given to the nonnull attribute, all pointer arguments
are marked as non-null. To illustrate, the following de laration is equivalent to
the previous example:
extern void *
my_mem py (void *dest, onst void *sr , size_t len)
__attribute__((nonnull));

noreturn A few standard library fun tions, su h as abort and exit, annot return. GCC

knows this automati ally. Some programs dene their own fun tions that never
return. You an de lare them noreturn to tell the ompiler this fa t. For
example,
void fatal () __attribute__ ((noreturn));
void
fatal (/* . . . */)
{
/* . . . */ /* Print error message. */ /* . . . */
exit (1);
}

The noreturn keyword tells the ompiler to assume that fatal annot return.
It an then optimize without regard to what would happen if fatal ever did
return. This makes slightly better ode. More importantly, it helps avoid
spurious warnings of uninitialized variables.
The noreturn keyword does not ae t the ex eptional path when that applies:
a noreturn-marked fun tion may still return to the aller by throwing an ex eption or alling longjmp.
Do not assume that registers saved by the alling fun tion are restored before
alling the noreturn fun tion.
It does not make sense for a noreturn fun tion to have a return type other
than void.

Chapter 5: Extensions to the C Language Family

225

The attribute noreturn is not implemented in GCC versions earlier than 2.5.
An alternative way to de lare that a fun tion does not return, whi h works in
the urrent version and in some older versions, is as follows:
typedef void voidfn ();
volatile voidfn fatal;

nothrow

pure

This approa h does not work in GNU C++.

The nothrow attribute is used to inform the ompiler that a fun tion annot
throw an ex eption. For example, most fun tions in the standard C library an
be guaranteed not to throw an ex eption with the notable ex eptions of qsort
and bsear h that take fun tion pointer arguments. The nothrow attribute is
not implemented in GCC versions earlier than 3.3.
Many fun tions have no ee ts ex ept the return value and their return value
depends only on the parameters and/or global variables. Su h a fun tion an
be subje t to ommon subexpression elimination and loop optimization just as
an arithmeti operator would be. These fun tions should be de lared with the
attribute pure. For example,
int square (int) __attribute__ ((pure));

says that the hypotheti al fun tion square is safe to all fewer times than the
program says.
Some of ommon examples of pure fun tions are strlen or mem mp. Interesting non-pure fun tions are fun tions with innite loops or those depending
on volatile memory or other system resour e, that may hange between two
onse utive alls (su h as feof in a multithreading environment).
The attribute pure is not implemented in GCC versions earlier than 2.96.
regparm (number )

saveall

On the Intel 386, the regparm attribute auses the ompiler to pass up to
number integer arguments in registers EAX, EDX, and ECX instead of on the
sta k. Fun tions that take a variable number of arguments will ontinue to be
passed all of their arguments on the sta k.
Beware that on some ELF systems this attribute is unsuitable for global fun tions in shared libraries with lazy binding (whi h is the default). Lazy binding
will send the rst all via resolving ode in the loader, whi h might assume
EAX, EDX and ECX an be lobbered, as per the standard alling onventions. Solaris 8 is ae ted by this. GNU systems with GLIBC 2.1 or higher,
and FreeBSD, are believed to be safe sin e the loaders there save all registers.
(Lazy binding an be disabled with the linker or the loader if desired, to avoid
the problem.)
Use this attribute on the H8/300, H8/300H, and H8S to indi ate that all registers ex ept the sta k pointer should be saved in the prologue regardless of
whether they are used or not.

se tion ("se tion-name ")

Normally, the ompiler pla es the ode it generates in the text se tion. Sometimes, however, you need additional se tions, or you need ertain parti ular

226

Using the GNU Compiler Colle tion (GCC)

fun tions to appear in spe ial se tions. The se tion attribute spe ies that a
fun tion lives in a parti ular se tion. For example, the de laration:
extern void foobar (void) __attribute__ ((se tion ("bar")));

puts the fun tion foobar in the bar se tion.

Some le formats do not support arbitrary se tions so the se tion attribute
is not available on all platforms. If you need to map the entire ontents of a
module to a parti ular se tion, onsider using the fa ilities of the linker instead.
sentinel This fun tion attribute ensures that a parameter in a fun tion all is an expli it
NULL. The attribute is only valid on variadi fun tions. By default, the sentinel
is lo ated at position zero, the last parameter of the fun tion all. If an optional
integer position argument P is supplied to the attribute, the sentinel must be
lo ated at position P ounting ba kwards from the end of the argument list.
__attribute__ ((sentinel))
is equivalent to
__attribute__ ((sentinel(0)))

The attribute is automati ally set with a position of 0 for the built-in fun tions
exe l and exe lp. The built-in fun tion exe le has the attribute set with a
position of 1.
A valid NULL in this ontext is dened as zero with any pointer type. If your
system denes the NULL ma ro with an integer type then you need to add
an expli it ast. GCC repla es stddef.h with a opy that redenes NULL
appropriately.
The warnings for missing or in orre t sentinels are enabled with `-Wformat'.
short_ all

See long all/short all.

short all
signal

sp_swit h

See long all/short all.

Use this attribute on the AVR to indi ate that the spe ied fun tion is a signal
handler. The ompiler will generate fun tion entry and exit sequen es suitable
for use in a signal handler when this attribute is present. Interrupts will be
disabled inside the fun tion.
Use this attribute on the SH to indi ate an interrupt_handler fun tion should
swit h to an alternate sta k. It expe ts a string argument that names a global
variable holding the address of the alternate sta k.
void *alt_sta k;
void f () __attribute__ ((interrupt_handler,
sp_swit h ("alt_sta k")));

std all

tiny_data

On the Intel 386, the std all attribute auses the ompiler to assume that the
alled fun tion will pop o the sta k spa e used to pass arguments, unless it
takes a variable number of arguments.
Use this attribute on the H8/300H and H8S to indi ate that the spe ied variable should be pla ed into the tiny data se tion. The ompiler will generate

Chapter 5: Extensions to the C Language Family

227

more e ient ode for loads and stores on data in the tiny data se tion. Note
the tiny data area is limited to slightly under 32kbytes of data.
trap_exit

unused
used

Use this attribute on the SH for an interrupt_handler to return using trapa

instead of rte. This attribute expe ts an integer argument spe ifying the trap
number to be used.
This attribute, atta hed to a fun tion, means that the fun tion is meant to be
possibly unused. GCC will not produ e a warning for this fun tion.
This attribute, atta hed to a fun tion, means that ode must be emitted for the
fun tion even if it appears that the fun tion is not referen ed. This is useful,
for example, when the fun tion is referen ed only in inline assembly.

visibility ("visibility_type ")

The visibility attribute on ELF targets auses the de laration to be emitted

with default, hidden, prote ted or internal visibility.

void __attribute__ ((visibility ("prote ted")))

f () { /* Do something. */; }
int i __attribute__ ((visibility ("hidden")));

See the ELF gABI for omplete details, but the short story is:
default
Default visibility is the normal ase for ELF. This value is available
for the visibility attribute to override other options that may hange
the assumed visibility of symbols.
hidden
Hidden visibility indi ates that the symbol will not be pla ed into
the dynami symbol table, so no other module (exe utable or
shared library) an referen e it dire tly.
internal
Internal visibility is like hidden visibility, but with additional pro essor spe i semanti s. Unless otherwise spe ied by the psABI,
GCC denes internal visibility to mean that the fun tion is never
alled from another module. Note that hidden symbols, while they
annot be referen ed dire tly by other modules, an be referen ed
indire tly via fun tion pointers. By indi ating that a symbol annot be alled from outside the module, GCC may for instan e omit
the load of a PIC register sin e it is known that the alling fun tion
loaded the orre t value.
prote ted Prote ted visibility indi ates that the symbol will be pla ed in the
dynami symbol table, but that referen es within the dening module will bind to the lo al symbol. That is, the symbol annot be
overridden by another module.
Not all ELF targets support this attribute.
warn_unused_result
The warn_unused_result attribute auses a warning to be emitted if a aller of

the fun tion with this attribute does not use its return value. This is useful for
fun tions where not he king the result is either a se urity problem or always
a bug, su h as reallo .

228

Using the GNU Compiler Colle tion (GCC)

int fn () __attribute__ ((warn_unused_result));

int foo ()
{
if (fn () < 0) return -1;
fn ();
return 0;
}

results in warning on line 5.

weak
The weak attribute auses the de laration to be emitted as a weak symbol
rather than a global. This is primarily useful in dening library fun tions whi h
an be overridden in user ode, though it an also be used with non-fun tion
de larations. Weak symbols are supported for ELF targets, and also for a.out
targets when using the GNU assembler and linker.
You an spe ify multiple attributes in a de laration by separating them by ommas within
the double parentheses or by immediately following an attribute de laration with another
attribute de laration.
Some people obje t to the __attribute__ feature, suggesting that ISO C's #pragma
should be used instead. At the time __attribute__ was designed, there were two reasons
for not doing this.
1. It is impossible to generate #pragma ommands from a ma ro.
2. There is no telling what the same #pragma might mean in another ompiler.
These two reasons applied to almost any appli ation that might have been proposed for
#pragma. It was basi ally a mistake to use #pragma for anything.
The ISO C99 standard in ludes _Pragma, whi h now allows pragmas to be generated
from ma ros. In addition, a #pragma GCC namespa e is now in use for GCC-spe i pragmas. However, it has been found onvenient to use __attribute__ to a hieve a natural
atta hment of attributes to their orresponding de larations, whereas #pragma GCC is of use
for onstru ts that do not naturally form part of the grammar. See se tion \Mis ellaneous
Prepro essing Dire tives" in The GNU C Prepro essor.

5.25 Attribute Syntax

This se tion des ribes the syntax with whi h __attribute__ may be used, and the onstru ts to whi h attribute spe iers bind, for the C language. Some details may vary for
C++ and Obje tive-C. Be ause of infeli ities in the grammar for attributes, some forms
des ribed here may not be su essfully parsed in all ases.
There are some problems with the semanti s of attributes in C++. For example, there
are no manglings for attributes, although they may ae t ode generation, so problems
may arise when attributed types are used in onjun tion with templates or overloading.
Similarly, typeid does not distinguish between types with dierent attributes. Support for
attributes in C++ may be restri ted in future to attributes on de larations only, but not on
nested de larators.
See Se tion 5.24 [Fun tion Attributes, page 217, for details of the semanti s of attributes
applying to fun tions. See Se tion 5.31 [Variable Attributes, page 233, for details of the
semanti s of attributes applying to variables. See Se tion 5.32 [Type Attributes, page 238,
for details of the semanti s of attributes applying to stru ture, union and enumerated types.

Chapter 5: Extensions to the C Language Family

229

An attribute spe ier is of the form __attribute__ ((attribute-list )). An attribute

list is a possibly empty omma-separated sequen e of attributes, where ea h attribute is
one of the following:
 Empty. Empty attributes are ignored.
 A word (whi h may be an identier su h as unused, or a reserved word su h as onst).
 A word, followed by, in parentheses, parameters for the attribute. These parameters
take one of the following forms:
 An identier. For example, mode attributes use this form.
 An identier followed by a omma and a non-empty omma-separated list of expressions. For example, format attributes use this form.
 A possibly empty omma-separated list of expressions. For example, format_arg
attributes use this form with the list being a single integer onstant expression,
and alias attributes use this form with the list being a single string onstant.
An attribute spe ier list is a sequen e of one or more attribute spe iers, not separated
by any other tokens.
In GNU C, an attribute spe ier list may appear after the olon following a label, other
than a ase or default label. The only attribute it makes sense to use after a label is
unused. This feature is intended for ode generated by programs whi h ontains labels that
may be unused but whi h is ompiled with `-Wall'. It would not normally be appropriate
to use in it human-written ode, though it ould be useful in ases where the ode that
jumps to the label is ontained within an #ifdef onditional. GNU C++ does not permit
su h pla ement of attribute lists, as it is permissible for a de laration, whi h ould begin
with an attribute list, to be labelled in C++. De larations annot be labelled in C90 or C99,
so the ambiguity does not arise there.
An attribute spe ier list may appear as part of a stru t, union or enum spe ier. It
may go either immediately after the stru t, union or enum keyword, or after the losing
bra e. It is ignored if the ontent of the stru ture, union or enumerated type is not dened
in the spe ier in whi h the attribute spe ier list is used|that is, in usages su h as stru t
__attribute__((foo)) bar with no following opening bra e. Where attribute spe iers
follow the losing bra e, they are onsidered to relate to the stru ture, union or enumerated
type dened, not to any en losing de laration the type spe ier appears in, and the type
dened is not omplete until after the attribute spe iers.
Otherwise, an attribute spe ier appears as part of a de laration, ounting de larations
of unnamed parameters and type names, and relates to that de laration (whi h may be
nested in another de laration, for example in the ase of a parameter de laration), or to
a parti ular de larator within a de laration. Where an attribute spe ier is applied to a
parameter de lared as a fun tion or an array, it should apply to the fun tion or array rather
than the pointer to whi h the parameter is impli itly onverted, but this is not yet orre tly
implemented.
Any list of spe iers and qualiers at the start of a de laration may ontain attribute
spe iers, whether or not su h a list may in that ontext ontain storage lass spe iers.
(Some attributes, however, are essentially in the nature of storage lass spe iers, and only
make sense where storage lass spe iers may be used; for example, se tion.) There is one
ne essary limitation to this syntax: the rst old-style parameter de laration in a fun tion

230

Using the GNU Compiler Colle tion (GCC)

denition annot begin with an attribute spe ier, be ause su h an attribute applies to the
fun tion instead by syntax des ribed below (whi h, however, is not yet implemented in this
ase). In some other ases, attribute spe iers are permitted by this grammar but not yet
supported by the ompiler. All attribute spe iers in this pla e relate to the de laration as
a whole. In the obsoles ent usage where a type of int is implied by the absen e of type
spe iers, su h a list of spe iers and qualiers may be an attribute spe ier list with no
other spe iers or qualiers.
At present, the rst parameter in a fun tion prototype must have some type spe ier
whi h is not an attribute spe ier; this resolves an ambiguity in the interpretation of void
f(int (__attribute__((foo)) x)), but is subje t to hange. At present, if the parentheses of a fun tion de larator ontain only attributes then those attributes are ignored, rather
than yielding an error or warning or implying a single parameter of type int, but this is
subje t to hange.
An attribute spe ier list may appear immediately before a de larator (other than the
rst) in a omma-separated list of de larators in a de laration of more than one identier
using a single list of spe iers and qualiers. Su h attribute spe iers apply only to the
identier before whose de larator they appear. For example, in
__attribute__((noreturn)) void d0 (void),
__attribute__((format(printf, 1, 2))) d1 ( onst har *, ...),
d2 (void)

the noreturn attribute applies to all the fun tions de lared; the format attribute only
applies to d1.
An attribute spe ier list may appear immediately before the omma, = or semi olon
terminating the de laration of an identier other than a fun tion denition. At present,
su h attribute spe iers apply to the de lared obje t or fun tion, but in future they may
atta h to the outermost adja ent de larator. In simple ases there is no dieren e, but, for
example, in
void (****f)(void) __attribute__((noreturn));

at present the noreturn attribute applies to f, whi h auses a warning sin e f is not a
fun tion, but in future it may apply to the fun tion ****f. The pre ise semanti s of what
attributes in su h ases will apply to are not yet spe ied. Where an assembler name for
an obje t or fun tion is spe ied (see Se tion 5.36 [Asm Labels, page 265), at present the
attribute must follow the asm spe i ation; in future, attributes before the asm spe i ation
may apply to the adja ent de larator, and those after it to the de lared obje t or fun tion.
An attribute spe ier list may, in future, be permitted to appear after the de larator in
a fun tion denition (before any old-style parameter de larations or the fun tion body).
Attribute spe iers may be mixed with type qualiers appearing inside the [ of a parameter array de larator, in the C99 onstru t by whi h su h qualiers are applied to the
pointer to whi h the array is impli itly onverted. Su h attribute spe iers apply to the
pointer, not to the array, but at present this is not implemented and they are ignored.
An attribute spe ier list may appear at the start of a nested de larator. At present,
there are some limitations in this usage: the attributes orre tly apply to the de larator,
but for most individual attributes the semanti s this implies are not implemented. When
attribute spe iers follow the * of a pointer de larator, they may be mixed with any type
qualiers present. The following des ribes the formal semanti s of this syntax. It will make

Chapter 5: Extensions to the C Language Family

231

the most sense if you are familiar with the formal spe i ation of de larators in the ISO C
standard.
Consider (as in C99 sub lause 6.7.5 paragraph 4) a de laration T D1, where T ontains
de laration spe iers that spe ify a type Type (su h as int) and D1 is a de larator that
ontains an identier ident. The type spe ied for ident for derived de larators whose type
does not in lude an attribute spe ier is as in the ISO C standard.
If D1 has the form ( attribute-spe ifier-list D ), and the de laration T D spe ies
the type \derived-de larator-type-list Type" for ident, then T D1 spe ies the type \derivedde larator-type-list attribute-spe ier-list Type" for ident.
If D1 has the form * type-qualifier-and-attribute-spe ifier-list D, and the de laration T D spe ies the type \derived-de larator-type-list Type" for ident, then T D1 spe ies the type \derived-de larator-type-list type-qualier-and-attribute-spe ier-list Type"
for ident.
For example,
void (__attribute__((noreturn)) ****f) (void);

spe ies the type \pointer to pointer to pointer to pointer to non-returning fun tion returning void". As another example,
har *__attribute__((aligned(8))) *f;

spe ies the type \pointer to 8-byte-aligned pointer to har". Note again that this does not
work with most attributes; for example, the usage of `aligned' and `noreturn' attributes
given above is not yet supported.
For ompatibility with existing ode written for ompiler versions that did not implement
attributes on nested de larators, some laxity is allowed in the pla ing of attributes. If an
attribute that only applies to types is applied to a de laration, it will be treated as applying
to the type of that de laration. If an attribute that only applies to de larations is applied
to the type of a de laration, it will be treated as applying to that de laration; and, for
ompatibility with ode pla ing the attributes immediately before the identier de lared,
su h an attribute applied to a fun tion return type will be treated as applying to the
fun tion type, and su h an attribute applied to an array element type will be treated as
applying to the array type. If an attribute that only applies to fun tion types is applied to
a pointer-to-fun tion type, it will be treated as applying to the pointer target type; if su h
an attribute is applied to a fun tion return type that is not a pointer-to-fun tion type, it
will be treated as applying to the fun tion type.

5.26 Prototypes and Old-Style Fun tion Denitions

GNU C extends ISO C to allow a fun tion prototype to override a later old-style nonprototype denition. Consider the following example:
/* Use prototypes unless the ompiler is old-fashioned.
#ifdef __STDC__
#define P(x) x
#else
#define P(x) ()
#endif
/* Prototype fun tion de laration.
int isroot P((uid_t));

*/

*/

232

Using the GNU Compiler Colle tion (GCC)

/* Old-style fun tion denition. */

int
isroot (x)
/* ??? lossage here ??? */
uid_t x;
{
return x == 0;
}

Suppose the type uid_t happens to be short. ISO C does not allow this example,
be ause subword arguments in old-style non-prototype denitions are promoted. Therefore
in this example the fun tion denition's argument is really an int, whi h does not mat h
the prototype argument type of short.
This restri tion of ISO C makes it hard to write ode that is portable to traditional C
ompilers, be ause the programmer does not know whether the uid_t type is short, int,
or long. Therefore, in ases like these GNU C allows a prototype to override a later oldstyle denition. More pre isely, in GNU C, a fun tion prototype argument type overrides
the argument type spe ied by a later old-style denition if the former type is the same as
the latter type before promotion. Thus in GNU C the above example is equivalent to the
following:
int isroot (uid_t);
int
isroot (uid_t x)
{
return x == 0;
}

GNU C++ does not support old-style fun tion denitions, so this extension is irrelevant.

5.27 C++ Style Comments

In GNU C, you may use C++ style omments, whi h start with `//' and ontinue until
the end of the line. Many other C implementations allow su h omments, and they are
in luded in the 1999 C standard. However, C++ style omments are not re ognized if you
spe ify an `-std' option spe ifying a version of ISO C before C99, or `-ansi' (equivalent to
`-std= 89').

5.28 Dollar Signs in Identier Names

In GNU C, you may normally use dollar signs in identier names. This is be ause many
traditional C implementations allow su h identiers. However, dollar signs in identiers are
not supported on a few target ma hines, typi ally be ause the target assembler does not
allow them.

5.29 The Chara ter hESCi in Constants

You an use the sequen e `\e' in a string or hara ter onstant to stand for the ASCII
hara ter hESCi.

Chapter 5: Extensions to the C Language Family

233

5.30 Inquiring on Alignment of Types or Variables

The keyword __alignof__ allows you to inquire about how an obje t is aligned, or the
minimum alignment usually required by a type. Its syntax is just like sizeof.
For example, if the target ma hine requires a double value to be aligned on an 8-byte
boundary, then __alignof__ (double) is 8. This is true on many RISC ma hines. On
more traditional ma hine designs, __alignof__ (double) is 4 or even 2.
Some ma hines never a tually require alignment; they allow referen e to any data type
even at an odd address. For these ma hines, __alignof__ reports the re ommended alignment of a type.
If the operand of __alignof__ is an lvalue rather than a type, its value is the required
alignment for its type, taking into a ount any minimum alignment spe ied with GCC's
__attribute__ extension (see Se tion 5.31 [Variable Attributes, page 233). For example,
after this de laration:
stru t foo { int x; har y; } foo1;

the value of __alignof__ (foo1.y) is 1, even though its a tual alignment is probably 2 or
4, the same as __alignof__ (int).
It is an error to ask for the alignment of an in omplete type.

5.31 Spe ifying Attributes of Variables

The keyword __attribute__ allows you to spe ify spe ial attributes of variables or stru ture
elds. This keyword is followed by an attribute spe i ation inside double parentheses.
Some attributes are urrently dened generi ally for variables. Other attributes are dened
for variables on parti ular target systems. Other attributes are available for fun tions
(see Se tion 5.24 [Fun tion Attributes, page 217) and for types (see Se tion 5.32 [Type
Attributes, page 238). Other front ends might dene more attributes (see Chapter 6
[Extensions to the C++ Language, page 335).
You may also spe ify attributes with `__' pre eding and following ea h keyword. This
allows you to use them in header les without being on erned about a possible ma ro of
the same name. For example, you may use __aligned__ instead of aligned.
See Se tion 5.25 [Attribute Syntax, page 228, for details of the exa t syntax for using
attributes.
aligned (alignment )

This attribute spe ies a minimum alignment for the variable or stru ture eld,
measured in bytes. For example, the de laration:
int x __attribute__ ((aligned (16))) = 0;

auses the ompiler to allo ate the global variable x on a 16-byte boundary. On
a 68040, this ould be used in onjun tion with an asm expression to a ess the
move16 instru tion whi h requires 16-byte aligned operands.
You an also spe ify the alignment of stru ture elds. For example, to reate a
double-word aligned int pair, you ould write:
stru t foo { int x[2 __attribute__ ((aligned (8))); };

This is an alternative to reating a union with a double member that for es

the union to be double-word aligned.

234

Using the GNU Compiler Colle tion (GCC)

As in the pre eding examples, you an expli itly spe ify the alignment (in bytes)
that you wish the ompiler to use for a given variable or stru ture eld. Alternatively, you an leave out the alignment fa tor and just ask the ompiler to
align a variable or eld to the maximum useful alignment for the target ma hine
you are ompiling for. For example, you ould write:
short array[3 __attribute__ ((aligned));

Whenever you leave out the alignment fa tor in an aligned attribute spe i ation, the ompiler automati ally sets the alignment for the de lared variable or
eld to the largest alignment whi h is ever used for any data type on the target
ma hine you are ompiling for. Doing this an often make opy operations more
e ient, be ause the ompiler an use whatever instru tions opy the biggest
hunks of memory when performing opies to or from the variables or elds
that you have aligned this way.
The aligned attribute an only in rease the alignment; but you an de rease
it by spe ifying pa ked as well. See below.
Note that the ee tiveness of aligned attributes may be limited by inherent
limitations in your linker. On many systems, the linker is only able to arrange
for variables to be aligned up to a ertain maximum alignment. (For some
linkers, the maximum supported alignment may be very very small.) If your
linker is only able to align variables up to a maximum of 8 byte alignment, then
spe ifying aligned(16) in an __attribute__ will still only provide you with
8 byte alignment. See your linker do umentation for further information.
leanup ( leanup_fun tion )
The leanup attribute runs a fun tion when the variable goes out of s ope.

This attribute an only be applied to auto fun tion s ope variables; it may not
be applied to parameters or variables with stati storage duration. The fun tion
must take one parameter, a pointer to a type ompatible with the variable. The
return value of the fun tion (if any) is ignored.
If `-fex eptions' is enabled, then leanup fun tion will be run during the sta k
unwinding that happens during the pro essing of the ex eption. Note that the
leanup attribute does not allow the ex eption to be aught, only to perform
an a tion. It is undened what happens if leanup fun tion does not return
normally.

ommon
no ommon The ommon attribute requests GCC to pla e a variable in \ ommon" storage.
The no ommon attribute requests the opposite|to allo ate spa e for it dire tly.
These attributes override the default hosen by the `-fno- ommon' and
`-f ommon' ags respe tively.
depre ated

The depre ated attribute results in a warning if the variable is used anywhere
in the sour e le. This is useful when identifying variables that are expe ted
to be removed in a future version of a program. The warning also in ludes the
lo ation of the de laration of the depre ated variable, to enable users to easily
nd further information about why the variable is depre ated, or what they
should do instead. Note that the warning only o urs for uses:

Chapter 5: Extensions to the C Language Family

235

extern int old_var __attribute__ ((depre ated));

extern int old_var;
int new_fn () { return old_var; }

results in a warning on line 3 but not line 2.

The depre ated attribute an also be used for fun tions and types (see Se tion 5.24 [Fun tion Attributes, page 217, see Se tion 5.32 [Type Attributes,
page 238.)
mode (mode )

This attribute spe ies the data type for the de laration|whi hever type orresponds to the mode mode. This in ee t lets you request an integer or oating
point type a ording to its width.
You may also spe ify a mode of `byte' or `__byte__' to indi ate the mode
orresponding to a one-byte integer, `word' or `__word__' for the mode of a oneword integer, and `pointer' or `__pointer__' for the mode used to represent
pointers.

pa ked

The pa ked attribute spe ies that a variable or stru ture eld should have the
smallest possible alignment|one byte for a variable, and one bit for a eld,
unless you spe ify a larger value with the aligned attribute.
Here is a stru ture in whi h the eld x is pa ked, so that it immediately follows
a:
stru t foo
{
har a;
int x[2 __attribute__ ((pa ked));
};

se tion ("se tion-name ")

Normally, the ompiler pla es the obje ts it generates in se tions like data and
bss. Sometimes, however, you need additional se tions, or you need ertain
parti ular variables to appear in spe ial se tions, for example to map to spe ial
hardware. The se tion attribute spe ies that a variable (or fun tion) lives
in a parti ular se tion. For example, this small program uses several spe i
se tion names:
stru t duart a __attribute__ ((se tion ("DUART_A"))) = { 0 };
stru t duart b __attribute__ ((se tion ("DUART_B"))) = { 0 };
har sta k[10000 __attribute__ ((se tion ("STACK"))) = { 0 };
int init_data __attribute__ ((se tion ("INITDATA"))) = 0;
main()
{
/* Initialize sta k pointer */
init_sp (sta k + sizeof (sta k));
/* Initialize initialized data */
mem py (&init_data, &data, &edata - &data);

/* Turn on the serial ports */

init_duart (&a);
init_duart (&b);

236

Using the GNU Compiler Colle tion (GCC)

Use the se tion attribute with an initialized denition of a global variable,

as shown in the example. GCC issues a warning and otherwise ignores the
se tion attribute in uninitialized variable de larations.
You may only use the se tion attribute with a fully initialized global denition
be ause of the way linkers work. The linker requires ea h obje t be dened on e,
with the ex eption that uninitialized variables tentatively go in the ommon (or
bss) se tion and an be multiply \dened". You an for e a variable to be
initialized with the `-fno- ommon' ag or the no ommon attribute.
Some le formats do not support arbitrary se tions so the se tion attribute
is not available on all platforms. If you need to map the entire ontents of a
module to a parti ular se tion, onsider using the fa ilities of the linker instead.
shared

On Mi rosoft Windows, in addition to putting variable denitions in a named

se tion, the se tion an also be shared among all running opies of an exe utable
or DLL. For example, this small program denes shared data by putting it in
a named se tion shared and marking the se tion shareable:
int foo __attribute__((se tion ("shared"), shared)) = 0;
int
main()
{
/* Read and write foo. All running
opies see the same value. */
return 0;
}

You may only use the shared attribute along with se tion attribute with a
fully initialized global denition be ause of the way linkers work. See se tion
attribute for more information.
The shared attribute is only available on Mi rosoft Windows.
tls_model ("tls_model ")
The tls_model attribute sets thread-lo al storage model (see Se tion 5.49
[Thread-Lo al, page 331) of a parti ular __thread variable, overriding
`-ftls-model=' ommand line swit h on a per-variable basis. The tls model
argument should be one of global-dynami , lo al-dynami , initial-exe
or lo al-exe .

Not all targets support this attribute.

transparent_union

This attribute, atta hed to a fun tion parameter whi h is a union, means that
the orresponding argument may have the type of any union member, but the
argument is passed as if its type were that of the rst union member. For more
details see See Se tion 5.32 [Type Attributes, page 238. You an also use this
attribute on a typedef for a union data type; then it applies to all fun tion
parameters with that type.

unused

This attribute, atta hed to a variable, means that the variable is meant to be
possibly unused. GCC will not produ e a warning for this variable.

Chapter 5: Extensions to the C Language Family

237

ve tor_size (bytes )

This attribute spe ies the ve tor size for the variable, measured in bytes. For
example, the de laration:
int foo __attribute__ ((ve tor_size (16)));

auses the ompiler to set the mode for foo, to be 16 bytes, divided into int
sized units. Assuming a 32-bit int (a ve tor of 4 units of 4 bytes), the orresponding mode of foo will be V4SI.
This attribute is only appli able to integral and oat s alars, although arrays,
pointers, and fun tion return values are allowed in onjun tion with this onstru t.
Aggregates with this attribute are invalid, even if they are of the same size as
a orresponding s alar. For example, the de laration:
stru t S { int a; };
stru t S __attribute__ ((ve tor_size (16))) foo;

is invalid even if the size of the stru ture is the same as the size of the int.
The weak attribute is des ribed in See Se tion 5.24 [Fun tion Attributes,
page 217.

weak
dllimport

The dllimport attribute is des ribed in See Se tion 5.24 [Fun tion Attributes,
page 217.

dlexport The dllexport attribute is des ribed in See Se tion 5.24 [Fun tion Attributes,

page 217.

5.31.1 M32R/D Variable Attributes

One attribute is urrently dened for the M32R/D.

model (model-name )

Use this attribute on the M32R/D to set the addressability of an obje t. The
identier model-name is one of small, medium, or large, representing ea h of
the ode models.
Small model obje ts live in the lower 16MB of memory (so that their addresses
an be loaded with the ld24 instru tion).
Medium and large model obje ts may live anywhere in the 32-bit address spa e
(the ompiler will generate seth/add3 instru tions to load their addresses).

5.31.2 i386 Variable Attributes

Two attributes are urrently dened for i386 ongurations: ms_stru t and g _stru t
ms_stru t
g _stru t

If pa ked is used on a stru ture, or if bit-elds are used it may be that the
Mi rosoft ABI pa ks them dierently than GCC would normally pa k them.
Parti ularly when moving pa ked data between fun tions ompiled with GCC
and the native Mi rosoft ompiler (either via fun tion all or as data in a le),
it may be ne essary to a ess either format.

238

Using the GNU Compiler Colle tion (GCC)

Currently `-m[no-ms-bitfields' is provided for the Mi rosoft Windows X86

ompilers to mat h the native Mi rosoft ompiler.

5.31.3 Xstormy16 Variable Attributes

One attribute is urrently dened for xstormy16 ongurations: below100

below100

If a variable has the below100 attribute (BELOW100 is allowed also), GCC will
pla e the variable in the rst 0x100 bytes of memory and use spe ial op odes
to a ess it. Su h variables will be pla ed in either the .bss_below100 se tion
or the .data_below100 se tion.

5.32 Spe ifying Attributes of Types

The keyword __attribute__ allows you to spe ify spe ial attributes of stru t and union
types when you dene su h types. This keyword is followed by an attribute spe i ation
inside double parentheses. Six attributes are urrently dened for types: aligned, pa ked,
transparent_union, unused, depre ated and may_alias. Other attributes are dened
for fun tions (see Se tion 5.24 [Fun tion Attributes, page 217) and for variables (see Se tion 5.31 [Variable Attributes, page 233).
You may also spe ify any one of these attributes with `__' pre eding and following its
keyword. This allows you to use these attributes in header les without being on erned
about a possible ma ro of the same name. For example, you may use __aligned__ instead
of aligned.
You may spe ify the aligned and transparent_union attributes either in a typedef
de laration or just past the losing urly bra e of a omplete enum, stru t or union type
denition and the pa ked attribute only past the losing bra e of a denition.
You may also spe ify attributes between the enum, stru t or union tag and the name of
the type rather than after the losing bra e.
See Se tion 5.25 [Attribute Syntax, page 228, for details of the exa t syntax for using
attributes.
aligned (alignment )

This attribute spe ies a minimum alignment (in bytes) for variables of the
spe ied type. For example, the de larations:
stru t S { short f[3; } __attribute__ ((aligned (8)));
typedef int more_aligned_int __attribute__ ((aligned (8)));

for e the ompiler to insure (as far as it an) that ea h variable whose type
is stru t S or more_aligned_int will be allo ated and aligned at least on a
8-byte boundary. On a SPARC, having all variables of type stru t S aligned to
8-byte boundaries allows the ompiler to use the ldd and std (doubleword load
and store) instru tions when opying one variable of type stru t S to another,
thus improving run-time e ien y.
Note that the alignment of any given stru t or union type is required by the
ISO C standard to be at least a perfe t multiple of the lowest ommon multiple
of the alignments of all of the members of the stru t or union in question. This
means that you an ee tively adjust the alignment of a stru t or union type

Chapter 5: Extensions to the C Language Family

239

by atta hing an aligned attribute to any one of the members of su h a type,

but the notation illustrated in the example above is a more obvious, intuitive,
and readable way to request the ompiler to adjust the alignment of an entire
stru t or union type.
As in the pre eding example, you an expli itly spe ify the alignment (in bytes)
that you wish the ompiler to use for a given stru t or union type. Alternatively, you an leave out the alignment fa tor and just ask the ompiler to
align a type to the maximum useful alignment for the target ma hine you are
ompiling for. For example, you ould write:
stru t S { short f[3; } __attribute__ ((aligned));

pa ked

Whenever you leave out the alignment fa tor in an aligned attribute spe i ation, the ompiler automati ally sets the alignment for the type to the largest
alignment whi h is ever used for any data type on the target ma hine you are
ompiling for. Doing this an often make opy operations more e ient, be ause the ompiler an use whatever instru tions opy the biggest hunks of
memory when performing opies to or from the variables whi h have types that
you have aligned this way.
In the example above, if the size of ea h short is 2 bytes, then the size of the
entire stru t S type is 6 bytes. The smallest power of two whi h is greater
than or equal to that is 8, so the ompiler sets the alignment for the entire
stru t S type to 8 bytes.
Note that although you an ask the ompiler to sele t a time-e ient alignment
for a given type and then de lare only individual stand-alone obje ts of that
type, the ompiler's ability to sele t a time-e ient alignment is primarily useful
only when you plan to reate arrays of variables having the relevant (e iently
aligned) type. If you de lare or use arrays of variables of an e iently-aligned
type, then it is likely that your program will also be doing pointer arithmeti (or
subs ripting, whi h amounts to the same thing) on pointers to the relevant type,
and the ode that the ompiler generates for these pointer arithmeti operations
will often be more e ient for e iently-aligned types than for other types.
The aligned attribute an only in rease the alignment; but you an de rease
it by spe ifying pa ked as well. See below.
Note that the ee tiveness of aligned attributes may be limited by inherent
limitations in your linker. On many systems, the linker is only able to arrange
for variables to be aligned up to a ertain maximum alignment. (For some
linkers, the maximum supported alignment may be very very small.) If your
linker is only able to align variables up to a maximum of 8 byte alignment, then
spe ifying aligned(16) in an __attribute__ will still only provide you with
8 byte alignment. See your linker do umentation for further information.
This attribute, atta hed to stru t or union type denition, spe ies that ea h
member of the stru ture or union is pla ed to minimize the memory required.
When atta hed to an enum denition, it indi ates that the smallest integral type
should be used.
Spe ifying this attribute for stru t and union types is equivalent to spe ifying
the pa ked attribute on ea h of the stru ture or union members. Spe ifying

240

Using the GNU Compiler Colle tion (GCC)

the `-fshort-enums' ag on the line is equivalent to spe ifying the pa ked

attribute on all enum denitions.
In the following example stru t my_pa ked_stru t's members are pa ked
losely together, but the internal layout of its s member is not pa ked|to
do that, stru t my_unpa ked_stru t would need to be pa ked too.
stru t my_unpa ked_stru t
{
har ;
int i;
};

stru t my_pa ked_stru t __attribute__ ((__pa ked__))

{
har ;
int i;
stru t my_unpa ked_stru t s;
};

You may only spe ify this attribute on the denition of a enum, stru t or union,
not on a typedef whi h does not also dene the enumerated type, stru ture or
union.
transparent_union

This attribute, atta hed to a union type denition, indi ates that any fun tion
parameter having that union type auses alls to that fun tion to be treated in
a spe ial way.
First, the argument orresponding to a transparent union type an be of any
type in the union; no ast is required. Also, if the union ontains a pointer type,
the orresponding argument an be a null pointer onstant or a void pointer
expression; and if the union ontains a void pointer type, the orresponding
argument an be any pointer expression. If the union member type is a pointer,
qualiers like onst on the referen ed type must be respe ted, just as with
normal pointer onversions.
Se ond, the argument is passed to the fun tion using the alling onventions of
the rst member of the transparent union, not the alling onventions of the
union itself. All members of the union must have the same ma hine representation; this is ne essary for this argument passing to work properly.
Transparent unions are designed for library fun tions that have multiple interfa es for ompatibility reasons. For example, suppose the wait fun tion must
a ept either a value of type int * to omply with Posix, or a value of type
union wait * to omply with the 4.1BSD interfa e. If wait's parameter were
void *, wait would a ept both kinds of arguments, but it would also a ept
any other pointer type and this would make argument type he king less useful.
Instead, <sys/wait.h> might dene the interfa e as follows:
typedef union
{
int *__ip;
union wait *__up;
} wait_status_ptr_t __attribute__ ((__transparent_union__));
pid_t wait (wait_status_ptr_t);

Chapter 5: Extensions to the C Language Family

241

This interfa e allows either int * or union wait * arguments to be passed,

using the int * alling onvention. The program an all wait with arguments
of either type:
int w1 () { int w; return wait (&w); }
int w2 () { union wait w; return wait (&w); }

With this interfa e, wait's implementation might look like this:

pid_t wait (wait_status_ptr_t p)
{
return waitpid (-1, p.__ip, 0);
}

unused

When atta hed to a type (in luding a union or a stru t), this attribute means
that variables of that type are meant to appear possibly unused. GCC will not
produ e a warning for any variables of that type, even if the variable appears to
do nothing. This is often the ase with lo k or thread lasses, whi h are usually
dened and then not referen ed, but ontain onstru tors and destru tors that
have nontrivial bookkeeping fun tions.

depre ated

The depre ated attribute results in a warning if the type is used anywhere in
the sour e le. This is useful when identifying types that are expe ted to be
removed in a future version of a program. If possible, the warning also in ludes
the lo ation of the de laration of the depre ated type, to enable users to easily
nd further information about why the type is depre ated, or what they should
do instead. Note that the warnings only o ur for uses and then only if the type
is being applied to an identier that itself is not being de lared as depre ated.
typedef int T1 __attribute__ ((depre ated));
T1 x;
typedef T1 T2;
T2 y;
typedef T1 T3 __attribute__ ((depre ated));
T3 z __attribute__ ((depre ated));

results in a warning on line 2 and 3 but not lines 4, 5, or 6. No warning is

issued for line 4 be ause T2 is not expli itly depre ated. Line 5 has no warning
be ause T3 is expli itly depre ated. Similarly for line 6.
The depre ated attribute an also be used for fun tions and variables (see Se tion 5.24 [Fun tion Attributes, page 217, see Se tion 5.31 [Variable Attributes,
page 233.)
may_alias

A esses to obje ts with types with this attribute are not subje ted to typebased alias analysis, but are instead assumed to be able to alias any other
type of obje ts, just like the har type. See `-fstri t-aliasing' for more
information on aliasing issues.
Example of use:
typedef short __attribute__((__may_alias__)) short_a;
int
main (void)
{

242

Using the GNU Compiler Colle tion (GCC)

int a = 0x12345678;
short_a *b = (short_a *) &a;
b[1 = 0;
if (a == 0x12345678)
abort();
}

exit(0);

If you repla ed short_a with short in the variable de laration, the above program would abort when ompiled with `-fstri t-aliasing', whi h is on by
default at `-O2' or above in re ent GCC versions.

5.32.1 ARM Type Attributes

On those ARM targets that support dllimport (su h as Symbian OS), you an
use the notshared attribute to indi ate that the virtual table and other similar
data for a lass should not be exported from a DLL. For example:
lass __de lspe (notshared) C {
publi :
__de lspe (dllimport) C();
virtual void f();
}
__de lspe (dllexport)
C::C() {}

In this ode, C::C is exported from the urrent DLL, but the virtual table for
C is not exported. (You an use __attribute__ instead of __de lspe if you
prefer, but most Symbian OS ode uses __de lspe .)

5.32.2 i386 Type Attributes

Two attributes are urrently dened for i386 ongurations: ms_stru t and
g _stru t

ms_stru t
g _stru t

If pa ked is used on a stru ture, or if bit-elds are used it may be that the
Mi rosoft ABI pa ks them dierently than GCC would normally pa k them.
Parti ularly when moving pa ked data between fun tions ompiled with GCC
and the native Mi rosoft ompiler (either via fun tion all or as data in a le),
it may be ne essary to a ess either format.
Currently `-m[no-ms-bitfields' is provided for the Mi rosoft Windows X86
ompilers to mat h the native Mi rosoft ompiler.
To spe ify multiple attributes, separate them by ommas within the double parentheses:
for example, `__attribute__ ((aligned (16), pa ked))'.

5.33 An Inline Fun tion is As Fast As a Ma ro

By de laring a fun tion inline, you an dire t GCC to integrate that fun tion's ode
into the ode for its allers. This makes exe ution faster by eliminating the fun tion- all

Chapter 5: Extensions to the C Language Family

243

overhead; in addition, if any of the a tual argument values are onstant, their known values
may permit simpli ations at ompile time so that not all of the inline fun tion's ode needs
to be in luded. The ee t on ode size is less predi table; obje t ode may be larger or
smaller with fun tion inlining, depending on the parti ular ase. Inlining of fun tions is an
optimization and it really \works" only in optimizing ompilation. If you don't use `-O', no
fun tion is really inline.
Inline fun tions are in luded in the ISO C99 standard, but there are urrently substantial
dieren es between what GCC implements and what the ISO C99 standard requires.
To de lare a fun tion inline, use the inline keyword in its de laration, like this:
inline int
in (int *a)
{
(*a)++;
}

(If you are writing a header le to be in luded in ISO C programs, write __inline__
instead of inline. See Se tion 5.38 [Alternate Keywords, page 268.) You an also make
all \simple enough" fun tions inline with the option `-finline-fun tions'.
Note that ertain usages in a fun tion denition an make it unsuitable for inline substitution. Among these usages are: use of varargs, use of allo a, use of variable sized data
types (see Se tion 5.13 [Variable Length, page 211), use of omputed goto (see Se tion 5.3
[Labels as Values, page 203), use of nonlo al goto, and nested fun tions (see Se tion 5.4
[Nested Fun tions, page 204). Using `-Winline' will warn when a fun tion marked inline
ould not be substituted, and will give the reason for the failure.
Note that in C and Obje tive-C, unlike C++, the inline keyword does not ae t the
linkage of the fun tion.
GCC automati ally inlines member fun tions dened within the lass body of C++
programs even if they are not expli itly de lared inline. (You an override this with
`-fno-default-inline'; see Se tion 3.5 [Options Controlling C++ Diale t, page 24.)
When a fun tion is both inline and stati , if all alls to the fun tion are integrated
into the aller, and the fun tion's address is never used, then the fun tion's own assembler
ode is never referen ed. In this ase, GCC does not a tually output assembler ode for
the fun tion, unless you spe ify the option `-fkeep-inline-fun tions'. Some alls annot
be integrated for various reasons (in parti ular, alls that pre ede the fun tion's denition
annot be integrated, and neither an re ursive alls within the denition). If there is a
nonintegrated all, then the fun tion is ompiled to assembler ode as usual. The fun tion
must also be ompiled as usual if the program refers to its address, be ause that an't be
inlined.
When an inline fun tion is not stati , then the ompiler must assume that there may be
alls from other sour e les; sin e a global symbol an be dened only on e in any program,
the fun tion must not be dened in the other sour e les, so the alls therein annot be
integrated. Therefore, a non-stati inline fun tion is always ompiled on its own in the
usual fashion.
If you spe ify both inline and extern in the fun tion denition, then the denition is
used only for inlining. In no ase is the fun tion ompiled on its own, not even if you refer
to its address expli itly. Su h an address be omes an external referen e, as if you had only
de lared the fun tion, and had not dened it.

244

Using the GNU Compiler Colle tion (GCC)

This ombination of inline and extern has almost the ee t of a ma ro. The way to
use it is to put a fun tion denition in a header le with these keywords, and put another
opy of the denition (la king inline and extern) in a library le. The denition in the
header le will ause most alls to the fun tion to be inlined. If any uses of the fun tion
remain, they will refer to the single opy in the library.
Sin e GCC eventually will implement ISO C99 semanti s for inline fun tions, it is best
to use stati inline only to guarantee ompatibility. (The existing semanti s will remain
available when `-std=gnu89' is spe ied, but eventually the default will be `-std=gnu99'
and that will implement the C99 semanti s, though it does not do so yet.)
GCC does not inline any fun tions when not optimizing unless you spe ify the
`always_inline' attribute for the fun tion, like this:
/* Prototype. */
inline void foo ( onst har) __attribute__((always_inline));

5.34 Assembler Instru tions with C Expression Operands

In an assembler instru tion using asm, you an spe ify the operands of the instru tion using
C expressions. This means you need not guess whi h registers or memory lo ations will
ontain the data you want to use.
You must spe ify an assembler instru tion template mu h like what appears in a ma hine
des ription, plus an operand onstraint string for ea h operand.
For example, here is how to use the 68881's fsinx instru tion:
asm ("fsinx %1,%0" : "=f" (result) : "f" (angle));

Here angle is the C expression for the input operand while result is that of the output
operand. Ea h has `"f"' as its operand onstraint, saying that a oating point register
is required. The `=' in `=f' indi ates that the operand is an output; all output operands'
onstraints must use `='. The onstraints use the same language used in the ma hine
des ription (see Se tion 5.35 [Constraints, page 250).
Ea h operand is des ribed by an operand- onstraint string followed by the C expression
in parentheses. A olon separates the assembler template from the rst output operand and
another separates the last output operand from the rst input, if any. Commas separate
the operands within ea h group. The total number of operands is urrently limited to 30;
this limitation may be lifted in some future version of GCC.
If there are no output operands but there are input operands, you must pla e two onse utive olons surrounding the pla e where the output operands would go.
As of GCC version 3.1, it is also possible to spe ify input and output operands using
symboli names whi h an be referen ed within the assembler ode. These names are
spe ied inside square bra kets pre eding the onstraint string, and an be referen ed inside
the assembler ode using %[name instead of a per entage sign followed by the operand
number. Using named operands the above example ould look like:
asm ("fsinx %[angle,%[output"
: [output "=f" (result)
: [angle "f" (angle));

Note that the symboli operand names have no relation whatsoever to other C identiers.
You may use any name you like, even those of existing C symbols, but you must ensure
that no two operands within the same assembler onstru t use the same symboli name.

Chapter 5: Extensions to the C Language Family

245

Output operand expressions must be lvalues; the ompiler an he k this. The input
operands need not be lvalues. The ompiler annot he k whether the operands have data
types that are reasonable for the instru tion being exe uted. It does not parse the assembler
instru tion template and does not know what it means or even whether it is valid assembler
input. The extended asm feature is most often used for ma hine instru tions the ompiler
itself does not know exist. If the output expression annot be dire tly addressed (for example, it is a bit-eld), your onstraint must allow a register. In that ase, GCC will use the
register as the output of the asm, and then store that register into the output.
The ordinary output operands must be write-only; GCC will assume that the values in
these operands before the instru tion are dead and need not be generated. Extended asm
supports input-output or read-write operands. Use the onstraint hara ter `+' to indi ate
su h an operand and list it with the output operands. You should only use read-write
operands when the onstraints for the operand (or the operand in whi h only some of the
bits are to be hanged) allow a register.
You may, as an alternative, logi ally split its fun tion into two separate operands, one
input operand and one write-only output operand. The onne tion between them is expressed by onstraints whi h say they need to be in the same lo ation when the instru tion
exe utes. You an use the same C expression for both operands, or dierent expressions.
For example, here we write the ( titious) ` ombine' instru tion with bar as its read-only
sour e operand and foo as its read-write destination:
asm (" ombine %2,%0" : "=r" (foo) : "0" (foo), "g" (bar));

The onstraint `"0"' for operand 1 says that it must o upy the same lo ation as operand 0.
A number in onstraint is allowed only in an input operand and it must refer to an output
operand.
Only a number in the onstraint an guarantee that one operand will be in the same pla e
as another. The mere fa t that foo is the value of both operands is not enough to guarantee
that they will be in the same pla e in the generated assembler ode. The following would
not work reliably:
asm (" ombine %2,%0" : "=r" (foo) : "r" (foo), "g" (bar));

Various optimizations or reloading ould ause operands 0 and 1 to be in dierent registers; GCC knows no reason not to do so. For example, the ompiler might nd a opy of
the value of foo in one register and use it for operand 1, but generate the output operand
0 in a dierent register ( opying it afterward to foo's own address). Of ourse, sin e the
register for operand 1 is not even mentioned in the assembler ode, the result will not work,
but GCC an't tell that.
As of GCC version 3.1, one may write [name instead of the operand number for a
mat hing onstraint. For example:
asm (" moveq %1,%2,%[result"
: [result "=r"(result)
: "r" (test), "r"(new), "[result"(old));

Sometimes you need to make an asm operand be a spe i register, but there's no mat hing
onstraint letter for that register by itself. To for e the operand into that register, use a lo al
variable for the operand and spe ify the register in the variable de laration. See Se tion 5.37
[Expli it Reg Vars, page 266. Then for the asm operand, use any register onstraint letter
that mat hes the register:

246

Using the GNU Compiler Colle tion (GCC)

register int *p1 asm

register int *p2 asm
register int *result
asm ("sysint" : "=r"

("r0") = ...;
("r1") = ...;
asm ("r0");
(result) : "0" (p1), "r" (p2));

In the above example, beware that a register that is all- lobbered by the target ABI will
be overwritten by any fun tion all in the assignment, in luding library alls for arithmeti
operators. Assuming it is a all- lobbered register, this may happen to r0 above by the
assignment to p2. If you have to use su h a register, use temporary variables for expressions
between the register assignment and use:
int t1 = ...;
register int *p1 asm
register int *p2 asm
register int *result
asm ("sysint" : "=r"

("r0") = ...;
("r1") = t1;
asm ("r0");
(result) : "0" (p1), "r" (p2));

Some instru tions lobber spe i hard registers. To des ribe this, write a third olon
after the input operands, followed by the names of the lobbered hard registers (given as
strings). Here is a realisti example for the VAX:
asm volatile ("mov 3 %0,%1,%2"
: /* no outputs */
: "g" (from), "g" (to), "g" ( ount)
: "r0", "r1", "r2", "r3", "r4", "r5");

You may not write a lobber des ription in a way that overlaps with an input or output
operand. For example, you may not have an operand des ribing a register lass with one
member if you mention that register in the lobber list. Variables de lared to live in spe i
registers (see Se tion 5.37 [Expli it Reg Vars, page 266), and used as asm input or output
operands must have no part mentioned in the lobber des ription. There is no way for
you to spe ify that an input operand is modied without also spe ifying it as an output
operand. Note that if all the output operands you spe ify are for this purpose (and hen e
unused), you will then also need to spe ify volatile for the asm onstru t, as des ribed
below, to prevent GCC from deleting the asm statement as unused.
If you refer to a parti ular hardware register from the assembler ode, you will probably
have to list the register after the third olon to tell the ompiler the register's value is
modied. In some assemblers, the register names begin with `%'; to produ e one `%' in the
assembler ode, you must write `%%' in the input.
If your assembler instru tion an alter the ondition ode register, add ` ' to the list
of lobbered registers. GCC on some ma hines represents the ondition odes as a spe i
hardware register; ` ' serves to name this register. On other ma hines, the ondition ode
is handled dierently, and spe ifying ` ' has no ee t. But it is valid no matter what the
ma hine.
If your assembler instru tions a ess memory in an unpredi table fashion, add `memory'
to the list of lobbered registers. This will ause GCC to not keep memory values a hed in
registers a ross the assembler instru tion and not optimize stores or loads to that memory.
You will also want to add the volatile keyword if the memory ae ted is not listed in the
inputs or outputs of the asm, as the `memory' lobber does not ount as a side-ee t of the
asm. If you know how large the a essed memory is, you an add it as input or output but
if this is not known, you should add `memory'. As an example, if you a ess ten bytes of a
string, you an use a memory input like:

Chapter 5: Extensions to the C Language Family

247

{"m"( ({ stru t { har x[10; } *p = (void *)ptr ; *p; }) )}.

Note that in the following example the memory input is ne essary, otherwise GCC might
optimize the store to x away:
int foo ()
{
int x = 42;
int *y = &x;
int result;
asm ("magi stuff a essing an 'int' pointed to by '%1'"
"=&d" (r) : "a" (y), "m" (*y));
return result;
}

You an put multiple assembler instru tions together in a single asm template, separated
by the hara ters normally used in assembly ode for the system. A ombination that works
in most pla es is a newline to break the line, plus a tab hara ter to move to the instru tion eld (written as `\n\t'). Sometimes semi olons an be used, if the assembler allows
semi olons as a line-breaking hara ter. Note that some assembler diale ts use semi olons
to start a omment. The input operands are guaranteed not to use any of the lobbered
registers, and neither will the output operands' addresses, so you an read and write the
lobbered registers as many times as you like. Here is an example of multiple instru tions
in a template; it assumes the subroutine _foo a epts arguments in registers 9 and 10:
asm ("movl %0,r9\n\tmovl %1,r10\n\t all _foo"
: /* no outputs */
: "g" (from), "g" (to)
: "r9", "r10");

Unless an output operand has the `&' onstraint modier, GCC may allo ate it in the same
register as an unrelated input operand, on the assumption the inputs are onsumed before
the outputs are produ ed. This assumption may be false if the assembler ode a tually
onsists of more than one instru tion. In su h a ase, use `&' for ea h output operand that
may not overlap an input. See Se tion 5.35.3 [Modiers, page 253.
If you want to test the ondition ode produ ed by an assembler instru tion, you must
in lude a bran h and a label in the asm onstru t, as follows:
asm (" lr %0\n\tfrob %1\n\tbeq 0f\n\tmov #1,%0\n0:"
: "g" (result)
: "g" (input));

This assumes your assembler supports lo al labels, as the GNU assembler and most Unix
assemblers do.
Speaking of labels, jumps from one asm to another are not supported. The ompiler's
optimizers do not know about these jumps, and therefore they annot take a ount of them
when de iding how to optimize.
Usually the most onvenient way to use these asm instru tions is to en apsulate them in
ma ros that look like fun tions. For example,
#define sin(x)
\
({ double __value, __arg = (x);
\
asm ("fsinx %1,%0": "=f" (__value): "f" (__arg));
__value; })

Here the variable __arg is used to make sure that the instru tion operates on a proper
double value, and to a ept only those arguments x whi h an onvert automati ally to a
double.

248

Using the GNU Compiler Colle tion (GCC)

Another way to make sure the instru tion operates on the orre t data type is to use
a ast in the asm. This is dierent from using a variable __arg in that it onverts more
dierent types. For example, if the desired type were int, asting the argument to int
would a ept a pointer with no omplaint, while assigning the argument to an int variable
named __arg would warn about using a pointer unless the aller expli itly asts it.
If an asm has output operands, GCC assumes for optimization purposes the instru tion
has no side ee ts ex ept to hange the output operands. This does not mean instru tions
with a side ee t annot be used, but you must be areful, be ause the ompiler may
eliminate them if the output operands aren't used, or move them out of loops, or repla e
two with one if they onstitute a ommon subexpression. Also, if your instru tion does
have a side ee t on a variable that otherwise appears not to hange, the old value of the
variable may be reused later if it happens to be found in a register.
You an prevent an asm instru tion from being deleted by writing the keyword volatile
after the asm. For example:
#define get_and_set_priority(new)
({ int __old;
asm volatile ("get_and_set_priority %0, %1"
: "=g" (__old) : "g" (new));
__old; })

\
\
\
\

The volatile keyword indi ates that the instru tion has important side-ee ts. GCC will
not delete a volatile asm if it is rea hable. (The instru tion an still be deleted if GCC
an prove that ontrol- ow will never rea h the lo ation of the instru tion.) Note that
even a volatile asm instru tion an be moved relative to other ode, in luding a ross jump
instru tions. For example, on many targets there is a system register whi h an be set to
ontrol the rounding mode of oating point operations. You might try setting it with a
volatile asm, like this PowerPC example:
asm volatile("mtfsf 255,%0" : : "f" (fpenv));
sum = x + y;

This will not work reliably, as the ompiler may move the addition ba k before the volatile
asm. To make it work you need to add an arti ial dependen y to the asm referen ing a
variable in the ode you don't want moved, for example:
asm volatile ("mtfsf 255,%1" : "=X"(sum): "f"(fpenv));
sum = x + y;

Similarly, you an't expe t a sequen e of volatile asm instru tions to remain perfe tly
onse utive. If you want onse utive output, use a single asm. Also, GCC will perform
some optimizations a ross a volatile asm instru tion; GCC does not \forget everything"
when it en ounters a volatile asm instru tion the way some other ompilers do.
An asm instru tion without any output operands will be treated identi ally to a volatile
asm instru tion.
It is a natural idea to look for a way to give a ess to the ondition ode left by the
assembler instru tion. However, when we attempted to implement this, we found no way
to make it work reliably. The problem is that output operands might need reloading,
whi h would result in additional following \store" instru tions. On most ma hines, these
instru tions would alter the ondition ode before there was time to test it. This problem
doesn't arise for ordinary \test" and \ ompare" instru tions be ause they don't have any
output operands.

Chapter 5: Extensions to the C Language Family

249

For reasons similar to those des ribed above, it is not possible to give an assembler
instru tion a ess to the ondition ode left by previous instru tions.
If you are writing a header le that should be in ludable in ISO C programs, write
__asm__ instead of asm. See Se tion 5.38 [Alternate Keywords, page 268.

5.34.1 Size of an asm

Some targets require that GCC tra k the size of ea h instru tion used in order to generate
orre t ode. Be ause the nal length of an asm is only known by the assembler, GCC
must make an estimate as to how big it will be. The estimate is formed by ounting the
number of statements in the pattern of the asm and multiplying that by the length of
the longest instru tion on that pro essor. Statements in the asm are identied by newline
hara ters and whatever statement separator hara ters are supported by the assembler; on
most pro essors this is the `;' hara ter.
Normally, GCC's estimate is perfe tly adequate to ensure that orre t ode is generated,
but it is possible to onfuse the ompiler if you use pseudo instru tions or assembler ma ros
that expand into multiple real instru tions or if you use assembler dire tives that expand to
more spa e in the obje t le than would be needed for a single instru tion. If this happens
then the assembler will produ e a diagnosti saying that a label is unrea hable.

5.34.2 i386 oating point asm operands

There are several rules on the usage of sta k-like regs in asm operands insns. These rules
apply only to the operands that are sta k-like regs:
1. Given a set of input regs that die in an asm operands, it is ne essary to know whi h
are impli itly popped by the asm, and whi h must be expli itly popped by g .
An input reg that is impli itly popped by the asm must be expli itly lobbered, unless
it is onstrained to mat h an output operand.
2. For any input reg that is impli itly popped by an asm, it is ne essary to know how to
adjust the sta k to ompensate for the pop. If any non-popped input is loser to the
top of the reg-sta k than the impli itly popped reg, it would not be possible to know
what the sta k looked like|it's not lear how the rest of the sta k \slides up".
All impli itly popped input regs must be loser to the top of the reg-sta k than any
input that is not impli itly popped.
It is possible that if an input dies in an insn, reload might use the input reg for an
output reload. Consider this example:
asm ("foo" : "=t" (a) : "f" (b));

This asm says that input B is not popped by the asm, and that the asm pushes a result
onto the reg-sta k, i.e., the sta k is one deeper after the asm than it was before. But,
it is possible that reload will think that it an use the same reg for both the input and
the output, if input B dies in this insn.
If any input operand uses the f onstraint, all output reg onstraints must use the &
early lobber.
The asm above would be written as
asm ("foo" : "=&t" (a) : "f" (b));

250

Using the GNU Compiler Colle tion (GCC)

3. Some operands need to be in parti ular pla es on the sta k. All output operands fall in
this ategory|there is no other way to know whi h regs the outputs appear in unless
the user indi ates this in the onstraints.
Output operands must spe i ally indi ate whi h reg an output appears in after an
asm. =f is not allowed: the operand onstraints must sele t a lass with a single reg.
4. Output operands may not be \inserted" between existing sta k regs. Sin e no 387 op ode uses a read/write operand, all output operands are dead before the asm operands,
and are pushed by the asm operands. It makes no sense to push anywhere but the top
of the reg-sta k.
Output operands must start at the top of the reg-sta k: output operands may not
\skip" a reg.
5. Some asm statements may need extra sta k spa e for internal al ulations. This an
be guaranteed by lobbering sta k registers unrelated to the inputs and outputs.
Here are a ouple of reasonable asms to want to write. This asm takes one input, whi h
is internally popped, and produ es two outputs.
asm ("fsin os" : "=t" ( os), "=u" (sin) : "0" (inp));

This asm takes two inputs, whi h are popped by the fyl2xp1 op ode, and repla es them
with one output. The user must ode the st(1) lobber for reg-sta k. to know that
fyl2xp1 pops both inputs.
asm ("fyl2xp1" : "=t" (result) : "0" (x), "u" (y) : "st(1)");

5.35 Constraints for asm Operands

Here are spe i details on what onstraint letters you an use with asm operands. Constraints an say whether an operand may be in a register, and whi h kinds of register;
whether the operand an be a memory referen e, and whi h kinds of address; whether the
operand may be an immediate onstant, and whi h possible values it may have. Constraints
an also require two operands to mat h.

5.35.1 Simple Constraints

The simplest kind of onstraint is a string full of letters, ea h of whi h des ribes one kind
of operand that is permitted. Here are the letters that are allowed:
whitespa e
Whitespa e hara ters are ignored and an be inserted at any position ex ept
the rst. This enables ea h alternative for dierent operands to be visually
aligned in the ma hine des ription even if they have dierent number of onstraints and modiers.
`m'
A memory operand is allowed, with any kind of address that the ma hine supports in general.
`o'
A memory operand is allowed, but only if the address is osettable. This
means that adding a small integer (a tually, the width in bytes of the operand,
as determined by its ma hine mode) may be added to the address and the result
is also a valid memory address.
For example, an address whi h is onstant is osettable; so is an address that
is the sum of a register and a onstant (as long as a slightly larger onstant

Chapter 5: Extensions to the C Language Family

251

is also within the range of address-osets supported by the ma hine); but an
autoin rement or autode rement address is not osettable. More ompli ated
indire t/indexed addresses may or may not be osettable depending on the
other addressing modes that the ma hine supports.
Note that in an output operand whi h an be mat hed by another operand,
the onstraint letter `o' is valid only when a ompanied by both `<' (if the
target ma hine has prede rement addressing) and `>' (if the target ma hine has
prein rement addressing).
`V'

A memory operand that is not osettable. In other words, anything that would
t the `m' onstraint but not the `o' onstraint.

`<'

A memory operand with autode rement addressing (either prede rement or

postde rement) is allowed.

`>'

A memory operand with autoin rement addressing (either prein rement or

postin rement) is allowed.

`r'

A register operand is allowed provided that it is in a general register.

`i'

An immediate integer operand (one with onstant value) is allowed. This in ludes symboli onstants whose values will be known only at assembly time or
later.

`n'

An immediate integer operand with a known numeri value is allowed. Many

systems annot support assembly-time onstants for operands less than a word
wide. Constraints for these operands should use `n' rather than `i'.

`I', `J', `K', . . . `P'

Other letters in the range `I' through `P' may be dened in a ma hine-dependent
fashion to permit immediate integer operands with expli it integer values in
spe ied ranges. For example, on the 68000, `I' is dened to stand for the
range of values 1 to 8. This is the range permitted as a shift ount in the shift
instru tions.
`E'

An immediate oating operand (expression ode onst_double) is allowed, but

only if the target oating point format is the same as that of the host ma hine
(on whi h the ompiler is running).

`F'

An immediate oating operand (expression ode onst_double or

onst_ve tor) is allowed.

`G', `H'

`G' and `H' may be dened in a ma hine-dependent fashion to permit immediate

oating operands in parti ular ranges of values.

`s'

An immediate integer operand whose value is not an expli it integer is allowed.

This might appear strange; if an insn allows a onstant operand with a value
not known at ompile time, it ertainly must allow any known value. So why
use `s' instead of `i'? Sometimes it allows better ode to be generated.
For example, on the 68000 in a fullword instru tion it is possible to use an
immediate operand; but if the immediate value is between 128 and 127, better
ode results from loading the value into a register and using the register. This

252

Using the GNU Compiler Colle tion (GCC)

is be ause the load into the register an be done with a `moveq' instru tion. We
arrange for this to happen by dening the letter `K' to mean \any integer outside
the range 128 to 127", and then spe ifying `Ks' in the operand onstraints.
`g'
Any register, memory or immediate integer operand is allowed, ex ept for registers that are not general registers.
`X'
Any operand whatsoever is allowed.
`0', `1', `2', . . . `9'
An operand that mat hes the spe ied operand number is allowed. If a digit
is used together with letters within the same alternative, the digit should ome
last.
This number is allowed to be more than a single digit. If multiple digits are en ountered onse utively, they are interpreted as a single de imal integer. There
is s ant han e for ambiguity, sin e to-date it has never been desirable that
`10' be interpreted as mat hing either operand 1 or operand 0. Should this be
desired, one an use multiple alternatives instead.
This is alled a mat hing onstraint and what it really means is that the assembler has only a single operand that lls two roles whi h asm distinguishes. For
example, an add instru tion uses two input operands and an output operand,
but on most CISC ma hines an add instru tion really has only two operands,
one of them an input-output operand:
addl #35,r12

Mat hing onstraints are used in these ir umstan es. More pre isely, the two
operands that mat h must in lude one input-only operand and one output-only
operand. Moreover, the digit must be a smaller number than the number of
the operand that uses it in the onstraint.
`p'
An operand that is a valid memory address is allowed. This is for \load address"
and \push address" instru tions.
`p' in the onstraint must be a ompanied by address_operand as the predi ate
in the mat h_operand. This predi ate interprets the mode spe ied in the
mat h_operand as the mode of the memory referen e for whi h the address
would be valid.
other-letters
Other letters an be dened in ma hine-dependent fashion to stand for parti ular lasses of registers or other arbitrary operand types. `d', `a' and `f'
are dened on the 68000/68020 to stand for data, address and oating point
registers.

5.35.2 Multiple Alternative Constraints

Sometimes a single instru tion has multiple alternative sets of possible operands. For example, on the 68000, a logi al-or instru tion an ombine register or an immediate value
into memory, or it an ombine any kind of operand into a register; but it annot ombine
one memory lo ation into another.
These onstraints are represented as multiple alternatives. An alternative an be des ribed by a series of letters for ea h operand. The overall onstraint for an operand is

Chapter 5: Extensions to the C Language Family

253

made from the letters for this operand from the rst alternative, a omma, the letters for
this operand from the se ond alternative, a omma, and so on until the last alternative.
If all the operands t any one alternative, the instru tion is valid. Otherwise, for ea h
alternative, the ompiler ounts how many instru tions must be added to opy the operands
so that that alternative applies. The alternative requiring the least opying is hosen. If
two alternatives need the same amount of opying, the one that omes rst is hosen. These
hoi es an be altered with the `?' and `!' hara ters:
?
Disparage slightly the alternative that the `?' appears in, as a hoi e when no
alternative applies exa tly. The ompiler regards this alternative as one unit
more ostly for ea h `?' that appears in it.
!
Disparage severely the alternative that the `!' appears in. This alternative an
still be used if it ts without reloading, but if reloading is needed, some other
alternative will be used.

5.35.3 Constraint Modier Chara ters

Here are onstraint modier hara ters.

`='
Means that this operand is write-only for this instru tion: the previous value
is dis arded and repla ed by output data.
`+'
Means that this operand is both read and written by the instru tion.
When the ompiler xes up the operands to satisfy the onstraints, it needs
to know whi h operands are inputs to the instru tion and whi h are outputs
from it. `=' identies an output; `+' identies an operand that is both input and
output; all other operands are assumed to be input only.
If you spe ify `=' or `+' in a onstraint, you put it in the rst hara ter of the
onstraint string.
`&'
Means (in a parti ular alternative) that this operand is an early lobber operand,
whi h is modied before the instru tion is nished using the input operands.
Therefore, this operand may not lie in a register that is used as an input operand
or as part of any memory address.
`&' applies only to the alternative in whi h it is written. In onstraints with
multiple alternatives, sometimes one alternative requires `&' while others do
not. See, for example, the `movdf' insn of the 68000.
An input operand an be tied to an early lobber operand if its only use as an
input o urs before the early result is written. Adding alternatives of this form
often allows GCC to produ e better ode when only some of the inputs an be
ae ted by the early lobber. See, for example, the `mulsi3' insn of the ARM.
`&' does not obviate the need to write `='.
`%'
De lares the instru tion to be ommutative for this operand and the following
operand. This means that the ompiler may inter hange the two operands if
that is the heapest way to make all operands t the onstraints. GCC an
only handle one ommutative pair in an asm; if you use more, the ompiler
may fail. Note that you need not use the modier if the two alternatives are
stri tly identi al; this would only waste time in the reload pass.

254

Using the GNU Compiler Colle tion (GCC)

`#'

Says that all following hara ters, up to the next omma, are to be ignored as
a onstraint. They are signi ant only for hoosing register preferen es.

`*'

Says that the following hara ter should be ignored when hoosing register
preferen es. `*' has no ee t on the meaning of the onstraint as a onstraint,
and no ee t on reloading.

5.35.4 Constraints for Parti ular Ma hines

Whenever possible, you should use the general-purpose onstraint letters in asm arguments,
sin e they will onvey meaning more readily to people reading your ode. Failing that, use
the onstraint letters that usually have very similar meanings a ross ar hite tures. The
most ommonly used onstraints are `m' and `r' (for memory and general-purpose registers
respe tively; see Se tion 5.35.1 [Simple Constraints, page 250), and `I', usually the letter
indi ating the most ommon immediate- onstant format.
For ea h ma hine ar hite ture, the ` onfig/ma hine /ma hine.h' le denes additional
onstraints. These onstraints are used by the ompiler itself for instru tion generation, as
well as for asm statements; therefore, some of the onstraints are not parti ularly interesting
for asm. The onstraints are dened through these ma ros:
REG_CLASS_FROM_LETTER

Register lass onstraints (usually lower ase).

CONST_OK_FOR_LETTER_P

Immediate onstant onstraints, for non- oating point onstants of word size
or smaller pre ision (usually upper ase).

CONST_DOUBLE_OK_FOR_LETTER_P

Immediate onstant onstraints, for all oating point onstants and for onstants of greater than word size pre ision (usually upper ase).

EXTRA_CONSTRAINT

Spe ial ases of registers or memory. This ma ro is not required, and is only
dened for some ma hines.

Inspe ting these ma ro denitions in the ompiler sour e for your ma hine is the best
way to be ertain you have the right onstraints. However, here is a summary of the
ma hine-dependent onstraints available on some parti ular ma hines.
ARM family|`arm.h'
f

Floating-point register

VFP oating-point register

One of the oating-point onstants 0.0, 0.5, 1.0, 2.0, 3.0, 4.0, 5.0 or
10.0

Floating-point onstant that would satisfy the onstraint `F' if it

were negated

Integer that is valid as an immediate operand in a data pro essing

instru tion. That is, an integer in the range 0 to 255 rotated by a
multiple of 2

Chapter 5: Extensions to the C Language Family

255

Integer in the range 4095 to 4095

Integer that satises onstraint `I' when inverted (ones omplement)

Integer that satises onstraint `I' when negated (twos omplement)

Integer in the range 0 to 32

A memory referen e where the exa t address is in a single register

(\m'' is preferable for asm statements)

An item in the onstant pool

A symbol in the text segment of the urrent le

Uv

A memory referen e suitable for VFP load/store insns (reg+ onstant oset)

Uy

A memory referen e suitable for iWMMXt load/store instru tions.

A memory referen e suitable for the ARMv4 ldrsb instru tion.

AVR family|`avr.h'
l
Registers from r0 to r15

Uq

Registers from r16 to r23

Registers from r16 to r31

Registers from r24 to r31. These registers an be used in `adiw'

ommand

e
b

Pointer register (r26{r31)

Base pointer register (r28{r31)

Sta k pointer register (SPH:SPL)

Temporary register r0

Register pair X (r27:r26)

y
z

Register pair Y (r29:r28)

Register pair Z (r31:r30)

Constant greater than 1, less than 64

Constant greater than 64, less than 1

Constant integer 2

K
L
M

Constant integer 0
Constant that ts in 8 bits

Constant integer 1
Constant integer 8, 16, or 24

Constant integer 1

256

Using the GNU Compiler Colle tion (GCC)

A oating point onstant 0.0

PowerPC and IBM RS6000|`rs6000.h'

b
Address base register
f

Floating point register

Ve tor register

`MQ', `CTR', or `LINK' register

`MQ' register

`CTR' register

`LINK' register

`CR' register ( ondition register) number 0

`CR' register ( ondition register)

`FPMEM' sta k memory for FPR-GPR transfers

Signed 16-bit onstant

Unsigned 16-bit onstant shifted left 16 bits (use `L' instead for
SImode onstants)

Unsigned 16-bit onstant

Signed 16-bit onstant shifted left 16 bits

Constant larger than 31

Exa t power of 2

Zero

Constant whose negation is a signed 16-bit onstant

Floating point onstant that an be loaded into a register with one

instru tion per word

Memory operand that is an oset from a register (`m' is preferable

for asm statements)

AIX TOC entry

Constant suitable as a 64-bit mask operand

Constant suitable as a 32-bit mask operand

System V Release 4 small data area referen e

Intel 386|`i386.h'
q

`a', b, , or d register for the i386. For x86-64 it is equivalent to `r'

lass (for 8-bit instru tions that do not use upper halves).

`a', b, , or d register (for 8-bit instru tions, that do use upper

halves).

Chapter 5: Extensions to the C Language Family

f
t
u
a
b

257

Lega y register|equivalent to r lass in i386 mode. (for non-8-bit

registers used together with 8-bit upper halves in a single instru tion)
Spe ies the `a' or `d' registers. This is primarily useful for 64-bit
integer values (when in 32-bit mode) intended to be returned with
the `d' register holding the most signi ant bits and the `a' register
holding the least signi ant bits.
Floating point register
First (top of sta k) oating point register
Se ond oating point register
`a' register
`b' register
` ' register

Spe ies onstant that an be easily onstru ted in SSE register

without loading it from memory.

`d' register
`di' register
`si' register
`xmm' SSE register
MMX register
Constant in range 0 to 31 (for 32-bit shifts)
Constant in range 0 to 63 (for 64-bit shifts)
`0xff'

D
S
x
y
I
J
K
L
M
N
Z

Intel IA-64|`ia64.h'
a
b

`0xffff'
0, 1, 2, or 3 (shifts for lea instru tion)
Constant in range 0 to 255 (for out instru tion)
Constant in range 0 to 0xffffffff or symboli referen e known to
t spe ied range. (for using immediates in zero extending 32-bit
to 64-bit x86-64 instru tions)
Constant in range 2147483648 to 2147483647 or symboli referen e known to t spe ied range. (for using immediates in 64-bit
x86-64 instru tions)
Standard 80387 oating point onstant
General register r0 to r3 for addl instru tion
Bran h register

258

Using the GNU Compiler Colle tion (GCC)

Predi ate register (` ' as in \ onditional")

Appli ation register residing in M-unit

Appli ation register residing in I-unit

Floating-point register

Memory operand. Remember that `m' allows postin rement and

postde rement whi h require printing with `%Pn' on IA-64. Use `S'
to disallow postin rement and postde rement.

Floating-point onstant 0.0 or 1.0

14-bit signed integer onstant

22-bit signed integer onstant

8-bit signed integer onstant for logi al instru tions

8-bit adjusted signed integer onstant for ompare pseudo-ops

6-bit unsigned integer onstant for shift ounts

9-bit signed integer onstant for load and store postin rements

The onstant zero

0 or 1 for dep instru tion

Non-volatile memory for oating-point loads and stores

Integer onstant in the range 1 to 4 for shladd instru tion

Memory operand ex ept postin rement and postde rement

FRV|`frv.h'
a

Register in the lass ACC_REGS (a 0 to a 7).

Register in the lass EVEN_ACC_REGS (a 0 to a 7).

Register in the lass CC_REGS (f 0 to f 3 and i 0 to i 3).

Register in the lass GPR_REGS (gr0 to gr63).

Register in the lass EVEN_REGS (gr0 to gr63). Odd registers are

ex luded not in the lass but through the use of a ma hine mode
larger than 4 bytes.

Register in the lass FPR_REGS (fr0 to fr63).

Register in the lass FEVEN_REGS (fr0 to fr63). Odd registers are

ex luded not in the lass but through the use of a ma hine mode
larger than 4 bytes.

Register in the lass LR_REG (the lr register).

Register in the lass QUAD_REGS (gr2 to gr63). Register numbers

not divisible by 4 are ex luded not in the lass but through the use
of a ma hine mode larger than 8 bytes.

Chapter 5: Extensions to the C Language Family

t
u
v
w
x

z
A
B
C
G
I
J
L
M
N
O
P

IP2K|`ip2k.h'
a
f
j
k
b
y
z
q

d
u
R

259

Register in the lass ICC_REGS (i 0 to i 3).

Register in the lass FCC_REGS (f 0 to f 3).
Register in the lass ICR_REGS ( 4 to 7).
Register in the lass FCR_REGS ( 0 to 3).
Register in the lass QUAD_FPR_REGS (fr0 to fr63). Register numbers not divisible by 4 are ex luded not in the lass but through
the use of a ma hine mode larger than 8 bytes.
Register in the lass SPR_REGS (l r and lr).
Register in the lass QUAD_ACC_REGS (a 0 to a 7).
Register in the lass ACCG_REGS (a g0 to a g7).
Register in the lass CR_REGS ( 0 to 7).
Floating point onstant zero
6-bit signed integer onstant
10-bit signed integer onstant
16-bit signed integer onstant
16-bit unsigned integer onstant
12-bit signed integer onstant that is negative|i.e. in the range of
2048 to 1
Constant zero
12-bit signed integer onstant that is greater than zero|i.e. in the
range of 1 to 2047.
`DP' or `IP' registers (general address)
`IP' register
`IPL' register
`IPH' register
`DP' register
`DPH' register
`DPL' register
`SP' register
`DP' or `SP' registers (osettable address)
Non-pointer registers (not `SP', `DP', `IP')
Non-SP registers (everything ex ept `SP')
Indire t through `IP'|Avoid this ex ept for QImode, sin e we an't
a ess extra bytes

260

Using the GNU Compiler Colle tion (GCC)

Indire t through `SP' or `DP' with short displa ement (0..127)

Data-se tion immediate value

Integers from 255 to 1

Integers from 0 to 7|valid bit number in a register

Integers from 0 to 127|valid displa ement for addressing mode

Integers from 1 to 127

Integer 1

Integer 1

Zero

Integers from 0 to 255

MIPS|`mips.h'
d

General-purpose integer register

f
h

Floating-point register (if available)

`Hi' register

`Lo' register

`Hi' or `Lo' register

General-purpose integer register

y
z
I

Floating-point status register

Signed 16-bit onstant (for arithmeti instru tions)

Zero
Zero-extended 16-bit onstant (for logi instru tions)

Constant with low 16 bits zero ( an be loaded with lui)

32-bit onstant whi h requires two instru tions to load (a onstant

whi h is not `I', `K', or `L')

Negative 16-bit onstant

Exa t power of two

O
P
G
Q
R
S

Positive 16-bit onstant

Floating point zero
Memory referen e that an be loaded with more than one instru tion (`m' is preferable for asm statements)
Memory referen e that an be loaded with one instru tion (`m' is
preferable for asm statements)
Memory referen e in external OSF/rose PIC format (`m' is preferable for asm statements)

Chapter 5: Extensions to the C Language Family

261

Motorola 680x0|`m68k.h'
a
Address register

Data register
f
68881 oating-point register, if available
I
Integer in the range 1 to 8
J
16-bit signed number
K
Signed number whose magnitude is greater than 0x80
L
Integer in the range 8 to 1
M
Signed number whose magnitude is greater than 0x100
G
Floating point onstant that is not a 68881 onstant
Motorola 68HC11 & 68HC12 families|`m68h 11.h'
a
Register `a'
b
Register `b'
d
Register `d'
q
An 8-bit register
t
Temporary soft register .tmp
u
A soft register .d1 to .d31
w
Sta k pointer register
x
Register `x'
y
Register `y'
z
Pseudo register `z' (repla ed by `x' or `y' at the end)
A
An address register: x, y or z
B
An address register: x or y
D
Register pair (x:d) to form a 32-bit value
L
Constants in the range 65536 to 65535
M
Constants whose 16-bit low part is zero
N
Constant integer 1 or 1
O
Constant integer 16
P
Constants in the range 8 to 2
SPARC|`spar .h'
f
Floating-point register on the SPARC-V8 ar hite ture and lower
oating-point register on the SPARC-V9 ar hite ture.
e
Floating-point register. It is equivalent to `f' on the SPARC-V8
ar hite ture and ontains both lower and upper oating-point registers on the SPARC-V9 ar hite ture.
d

262

Using the GNU Compiler Colle tion (GCC)

Floating-point ondition ode register.

Lower oating-point register. It is only valid on the SPARC-V9

ar hite ture when the Visual Instru tion Set is available.

Floating-point register. It is only valid on the SPARC-V9 ar hite ture when the Visual Instru tion Set is available.

64-bit global or out register for the SPARC-V8+ ar hite ture.

Signed 13-bit onstant

Zero

32-bit onstant with the low 12 bits lear (a onstant that an be

loaded with the sethi instru tion)

A onstant in the range supported by mov instru tions

A onstant in the range supported by movr instru tions

Same as `K', ex ept that it veries that bits that are not in the
lower 32-bit range are all zero. Must be used instead of `K' for
modes wider than SImode

The onstant 4096

Floating-point zero

Signed 13-bit onstant, sign-extended to 32 or 64 bits

Floating-point onstant whose integral representation an be moved

into an integer register using a single sethi instru tion

Floating-point onstant whose integral representation an be moved

into an integer register using a single mov instru tion

Floating-point onstant whose integral representation an be moved

into an integer register using a high/lo sum instru tion sequen e

Memory address aligned to an 8-byte boundary

Even register

Memory address for `e' onstraint registers

Ve tor zero

TMS320C3x/C4x|` 4x.h'
a
Auxiliary (address) register (ar0-ar7)
b

Sta k pointer register (sp)

Standard (32-bit) pre ision integer register

Extended (40-bit) pre ision register (r0-r11)

Blo k ount register (bk)

Extended (40-bit) pre ision low register (r0-r7)

Chapter 5: Extensions to the C Language Family

263

Extended (40-bit) pre ision register (r0-r1)

u
Extended (40-bit) pre ision register (r2-r3)
v
Repeat ount register (r )
x
Index register (ir0-ir1)
y
Status ( ondition ode) register (st)
z
Data page register (dp)
G
Floating-point zero
H
Immediate 16-bit oating-point onstant
I
Signed 16-bit onstant
J
Signed 8-bit onstant
K
Signed 5-bit onstant
L
Unsigned 16-bit onstant
M
Unsigned 8-bit onstant
N
Ones omplement of unsigned 16-bit onstant
O
High 16-bit onstant (32-bit onstant with 16 LSBs zero)
Q
Indire t memory referen e with signed 8-bit or index register displa ement
R
Indire t memory referen e with unsigned 5-bit displa ement
S
Indire t memory referen e with 1 bit or index register displa ement
T
Dire t memory referen e
U
Symboli address
S/390 and zSeries|`s390.h'
a
Address register (general purpose register ex ept r0)

Condition ode register
d
Data register (arbitrary general purpose register)
f
Floating-point register
I
Unsigned 8-bit onstant (0{255)
J
Unsigned 12-bit onstant (0{4095)
K
Signed 16-bit onstant ( 32768{32767)
L
Value appropriate as displa ement.
t

(0..4095)

for short displa ement

(-524288..524287)

for long displa ement

264

Using the GNU Compiler Colle tion (GCC)

Constant integer with a value of 0x7f.

Multiple letter onstraint followed by 4 parameter letters.

Q
R

0..9:

number of the part ounting from most to least signifi ant

H,Q:

mode of the part

D,S,H:

mode of the ontaining operand

0,F:

value of the other parts (F|all bits set)

The onstraint mat hes if the spe ied part of a onstant has a

value dierent from it's other parts.
Memory referen e without index register and with short displa ement.
Memory referen e with index register and short displa ement.

Memory referen e without index register but with long displa ement.

Memory referen e with index register and long displa ement.

U
W

Pointer with short displa ement.

Pointer with long displa ement.

Shift ount operand.

Xstormy16|`stormy16.h'
a
Register r0.
b

Register r1.

Register r2.

Register r8.
Registers r0 through r7.

e
y

Registers r0 and r1.

The arry register.

Registers r8 and r9.

A onstant between 0 and 3 in lusive.

A onstant that has exa tly one bit set.

J
K
L

A onstant that has exa tly one bit lear.

A onstant between 0 and 255 in lusive.

A onstant between 255 and 0 in lusive.

A onstant between 3 and 0 in lusive.

A onstant between 1 and 4 in lusive.

Chapter 5: Extensions to the C Language Family

265

A onstant between 4 and 1 in lusive.

A memory referen e that is a sta k push.

A memory referen e that is a sta k pop.

A memory referen e that refers to a onstant address of known

value.

The register indi ated by Rx (not implemented yet).

A onstant that is not between 2 and 15 in lusive.

The onstant 0.

Xtensa|`xtensa.h'
a

General-purpose 32-bit register

One-bit boolean register

MAC16 40-bit a umulator register

Signed 12-bit integer onstant, for use in MOVI instru tions

Signed 8-bit integer onstant, for use in ADDI instru tions

Integer onstant valid for B I instru tions

Unsigned onstant valid for B UI instru tions

5.36 Controlling Names Used in Assembler Code

You an spe ify the name to be used in the assembler ode for a C fun tion or variable by
writing the asm (or __asm__) keyword after the de larator as follows:
int foo asm ("myfoo") = 2;

This spe ies that the name to be used for the variable foo in the assembler ode should
be `myfoo' rather than the usual `_foo'.
On systems where an unders ore is normally prepended to the name of a C fun tion or
variable, this feature allows you to dene names for the linker that do not start with an
unders ore.
It does not make sense to use this feature with a non-stati lo al variable sin e su h
variables do not have assembler names. If you are trying to put the variable in a parti ular
register, see Se tion 5.37 [Expli it Reg Vars, page 266. GCC presently a epts su h ode
with a warning, but will probably be hanged to issue an error, rather than a warning, in
the future.
You annot use asm in this way in a fun tion denition ; but you an get the same ee t
by writing a de laration for the fun tion before its denition and putting asm there, like
this:
extern fun () asm ("FUNC");
fun (x, y)
int x, y;
/* . . . */

266

Using the GNU Compiler Colle tion (GCC)

It is up to you to make sure that the assembler names you hoose do not on i t with
any other assembler symbols. Also, you must not use a register name; that would produ e
ompletely invalid assembler ode. GCC does not as yet have the ability to store stati
variables in registers. Perhaps that will be added.

5.37 Variables in Spe ied Registers

GNU C allows you to put a few global variables into spe ied hardware registers. You an
also spe ify the register in whi h an ordinary register variable should be allo ated.
 Global register variables reserve registers throughout the program. This may be useful
in programs su h as programming language interpreters whi h have a ouple of global
variables that are a essed very often.
 Lo al register variables in spe i registers do not reserve the registers, ex ept at the
point where they are used as input or output operands in an asm statement and the
asm statement itself is not deleted. The ompiler's data ow analysis is apable of determining where the spe ied registers ontain live values, and where they are available
for other uses. Stores into lo al register variables may be deleted when they appear to
be dead a ording to data ow analysis. Referen es to lo al register variables may be
deleted or moved or simplied.
These lo al variables are sometimes onvenient for use with the extended asm feature
(see Se tion 5.34 [Extended Asm, page 244), if you want to write one output of the
assembler instru tion dire tly into a parti ular register. (This will work provided the
register you spe ify ts the onstraints spe ied for that operand in the asm.)

5.37.1 Dening Global Register Variables

You an dene a global register variable in GNU C like this:

register int *foo asm ("a5");

Here a5 is the name of the register whi h should be used. Choose a register whi h is
normally saved and restored by fun tion alls on your ma hine, so that library routines will
not lobber it.
Naturally the register name is pu-dependent, so you would need to onditionalize your
program a ording to pu type. The register a5 would be a good hoi e on a 68000 for a
variable of pointer type. On ma hines with register windows, be sure to hoose a \global"
register that is not ae ted magi ally by the fun tion all me hanism.
In addition, operating systems on one type of pu may dier in how they name the
registers; then you would need additional onditionals. For example, some 68000 operating
systems all this register %a5.
Eventually there may be a way of asking the ompiler to hoose a register automati ally,
but rst we need to gure out how it should hoose and how to enable you to guide the
hoi e. No solution is evident.
Dening a global register variable in a ertain register reserves that register entirely for
this use, at least within the urrent ompilation. The register will not be allo ated for any
other purpose in the fun tions in the urrent ompilation. The register will not be saved
and restored by these fun tions. Stores into this register are never deleted even if they
would appear to be dead, but referen es may be deleted or moved or simplied.

Chapter 5: Extensions to the C Language Family

267

It is not safe to a ess the global register variables from signal handlers, or from more
than one thread of ontrol, be ause the system library routines may temporarily use the
register for other things (unless you re ompile them spe ially for the task at hand).
It is not safe for one fun tion that uses a global register variable to all another su h
fun tion foo by way of a third fun tion lose that was ompiled without knowledge of this
variable (i.e. in a dierent sour e le in whi h the variable wasn't de lared). This is be ause
lose might save the register and put some other value there. For example, you an't expe t
a global register variable to be available in the omparison-fun tion that you pass to qsort,
sin e qsort might have put something else in that register. (If you are prepared to re ompile
qsort with the same global register variable, you an solve this problem.)
If you want to re ompile qsort or other sour e les whi h do not a tually use your global
register variable, so that they will not use that register for any other purpose, then it su es
to spe ify the ompiler option `-ffixed-reg '. You need not a tually add a global register
de laration to their sour e ode.
A fun tion whi h an alter the value of a global register variable annot safely be alled
from a fun tion ompiled without this variable, be ause it ould lobber the value the aller
expe ts to nd there on return. Therefore, the fun tion whi h is the entry point into the
part of the program that uses the global register variable must expli itly save and restore
the value whi h belongs to its aller.
On most ma hines, longjmp will restore to ea h global register variable the value it had
at the time of the setjmp. On some ma hines, however, longjmp will not hange the value
of global register variables. To be portable, the fun tion that alled setjmp should make
other arrangements to save the values of the global register variables, and to restore them
in a longjmp. This way, the same thing will happen regardless of what longjmp does.
All global register variable de larations must pre ede all fun tion denitions. If su h a
de laration ould appear after fun tion denitions, the de laration would be too late to
prevent the register from being used for other purposes in the pre eding fun tions.
Global register variables may not have initial values, be ause an exe utable le has no
means to supply initial ontents for a register.
On the SPARC, there are reports that g3 . . . g7 are suitable registers, but ertain library
fun tions, su h as getwd, as well as the subroutines for division and remainder, modify g3
and g4. g1 and g2 are lo al temporaries.
On the 68000, a2 . . . a5 should be suitable, as should d2 . . . d7. Of ourse, it will not
do to use more than a few of those.

5.37.2 Spe ifying Registers for Lo al Variables

You an dene a lo al register variable with a spe ied register like this:

register int *foo asm ("a5");

Here a5 is the name of the register whi h should be used. Note that this is the same syntax
used for dening global register variables, but for a lo al variable it would appear within a
fun tion.
Naturally the register name is pu-dependent, but this is not a problem, sin e spe i
registers are most often useful with expli it assembler instru tions (see Se tion 5.34 [Extended Asm, page 244). Both of these things generally require that you onditionalize your
program a ording to pu type.

268

Using the GNU Compiler Colle tion (GCC)

In addition, operating systems on one type of pu may dier in how they name the
registers; then you would need additional onditionals. For example, some 68000 operating
systems all this register %a5.
Dening su h a register variable does not reserve the register; it remains available for
other uses in pla es where ow ontrol determines the variable's value is not live.
This option does not guarantee that GCC will generate ode that has this variable in the
register you spe ify at all times. You may not ode an expli it referen e to this register
in the assembler instru tion template part of an asm statement and assume it will always
refer to this variable. However, using the variable as an asm operand guarantees that the
spe ied register is used for the operand.
Stores into lo al register variables may be deleted when they appear to be dead a ording
to data ow analysis. Referen es to lo al register variables may be deleted or moved or
simplied.
As for global register variables, it's re ommended that you hoose a register whi h is
normally saved and restored by fun tion alls on your ma hine, so that library routines
will not lobber it. A ommon pitfall is to initialize multiple all- lobbered registers with
arbitrary expressions, where a fun tion all or library all for an arithmeti operator will
overwrite a register value from a previous assignment, for example r0 below:
register int *p1 asm ("r0") = ...;
register int *p2 asm ("r1") = ...;

In those ases, a solution is to use a temporary variable for ea h arbitrary expression.

See [Example of asm with lobbered asm reg, page 246.

5.38 Alternate Keywords

`-ansi' and the various `-std' options disable ertain keywords. This auses trouble when
you want to use GNU C extensions, or a general-purpose header le that should be usable
by all programs, in luding ISO C programs. The keywords asm, typeof and inline are
not available in programs ompiled with `-ansi' or `-std' (although inline an be used in
a program ompiled with `-std= 99'). The ISO C99 keyword restri t is only available
when `-std=gnu99' (whi h will eventually be the default) or `-std= 99' (or the equivalent
`-std=iso9899:1999') is used.
The way to solve these problems is to put `__' at the beginning and end of ea h problemati al keyword. For example, use __asm__ instead of asm, and __inline__ instead of
inline.
Other C ompilers won't a ept these alternative keywords; if you want to ompile with
another ompiler, you an dene the alternate keywords as ma ros to repla e them with
the ustomary keywords. It looks like this:
#ifndef __GNUC__
#define __asm__ asm
#endif

`-pedanti ' and other options ause warnings for many GNU C extensions. You an prevent su h warnings within one expression by writing __extension__ before the expression.
__extension__ has no ee t aside from this.

Chapter 5: Extensions to the C Language Family

269

5.39 In omplete enum Types

You an dene an enum tag without spe ifying its possible values. This results in an in omplete type, mu h like what you get if you write stru t foo without des ribing the elements.
A later de laration whi h does spe ify the possible values ompletes the type.
You an't allo ate variables or storage using the type while it is in omplete. However,
you an work with pointers to that type.
This extension may not be very useful, but it makes the handling of enum more onsistent
with the way stru t and union are handled.
This extension is not supported by GNU C++.

5.40 Fun tion Names as Strings

GCC provides three magi variables whi h hold the name of the urrent fun tion, as a
string. The rst of these is __fun __, whi h is part of the C99 standard:
The identier __fun __ is impli itly de lared by the translator
as if, immediately following the opening bra e of ea h fun tion
denition, the de laration
stati onst har __fun __[ = "fun tion-name";

appeared, where fun tion-name is the name of the lexi ally-en losing
fun tion. This name is the unadorned name of the fun tion.
__FUNCTION__ is another name for __fun __. Older versions of GCC re ognize only this
name. However, it is not standardized. For maximum portability, we re ommend you use
__fun __, but provide a fallba k denition with the prepro essor:
#if __STDC_VERSION__ < 199901L
# if __GNUC__ >= 2
# define __fun __ __FUNCTION__
# else
# define __fun __ "<unknown>"
# endif
#endif

In C, __PRETTY_FUNCTION__ is yet another name for __fun __. However, in C++, __

PRETTY_FUNCTION__ ontains the type signature of the fun tion as well as its bare name.
For example, this program:

extern "C" {
extern int printf ( har *, ...);
}

lass a {
publi :
void sub (int i)
{
printf ("__FUNCTION__ = %s\n", __FUNCTION__);
printf ("__PRETTY_FUNCTION__ = %s\n", __PRETTY_FUNCTION__);
}
};
int
main (void)

270

Using the GNU Compiler Colle tion (GCC)

a ax;
ax.sub (0);
return 0;

gives this output:

__FUNCTION__ = sub
__PRETTY_FUNCTION__ = void a::sub(int)

These identiers are not prepro essor ma ros. In GCC 3.3 and earlier, in C only, __
FUNCTION__ and __PRETTY_FUNCTION__ were treated as string literals; they ould be used
to initialize har arrays, and they ould be on atenated with other string literals. GCC
3.4 and later treat them as variables, like __fun __. In C++, __FUNCTION__ and __PRETTY_
FUNCTION__ have always been variables.

5.41 Getting the Return or Frame Address of a Fun tion

These fun tions may be used to get information about the allers of a fun tion.
void * __builtin_return_address (unsigned int level )
[Built-in Fun tion
This fun tion returns the return address of the urrent fun tion, or of one of its allers.
The level argument is number of frames to s an up the all sta k. A value of 0 yields
the return address of the urrent fun tion, a value of 1 yields the return address of
the aller of the urrent fun tion, and so forth. When inlining the expe ted behavior
is that the fun tion will return the address of the fun tion that will be returned to.
To work around this behavior use the noinline fun tion attribute.
The level argument must be a onstant integer.
On some ma hines it may be impossible to determine the return address of any
fun tion other than the urrent one; in su h ases, or when the top of the sta k has
been rea hed, this fun tion will return 0 or a random value. In addition, __builtin_
frame_address may be used to determine if the top of the sta k has been rea hed.
This fun tion should only be used with a nonzero argument for debugging purposes.
void * __builtin_frame_address (unsigned int level )
[Built-in Fun tion
This fun tion is similar to __builtin_return_address, but it returns the address of
the fun tion frame rather than the return address of the fun tion. Calling __builtin_
frame_address with a value of 0 yields the frame address of the urrent fun tion, a
value of 1 yields the frame address of the aller of the urrent fun tion, and so forth.
The frame is the area on the sta k whi h holds lo al variables and saved registers.
The frame address is normally the address of the rst word pushed on to the sta k
by the fun tion. However, the exa t denition depends upon the pro essor and the
alling onvention. If the pro essor has a dedi ated frame pointer register, and the
fun tion has a frame, then __builtin_frame_address will return the value of the
frame pointer register.
On some ma hines it may be impossible to determine the frame address of any fun tion
other than the urrent one; in su h ases, or when the top of the sta k has been
rea hed, this fun tion will return 0 if the rst frame pointer is properly initialized by
the startup ode.
This fun tion should only be used with a nonzero argument for debugging purposes.

Chapter 5: Extensions to the C Language Family

271

5.42 Using ve tor instru tions through built-in fun tions

On some targets, the instru tion set ontains SIMD ve tor instru tions that operate on
multiple values ontained in one large register at the same time. For example, on the i386
the MMX, 3Dnow! and SSE extensions an be used this way.
The rst step in using these extensions is to provide the ne essary data types. This should
be done using an appropriate typedef:
typedef int v4si __attribute__ ((ve tor_size (16)));

The int type spe ies the base type, while the attribute spe ies the ve tor size for the
variable, measured in bytes. For example, the de laration above auses the ompiler to set
the mode for the v4si type to be 16 bytes wide and divided into int sized units. For a
32-bit int this means a ve tor of 4 units of 4 bytes, and the orresponding mode of foo will
be V4SI.
The ve tor_size attribute is only appli able to integral and oat s alars, although
arrays, pointers, and fun tion return values are allowed in onjun tion with this onstru t.
All the basi integer types an be used as base types, both as signed and as unsigned:
har, short, int, long, long long. In addition, float and double an be used to build
oating-point ve tor types.
Spe ifying a ombination that is not valid for the urrent ar hite ture will ause GCC to
synthesize the instru tions using a narrower mode. For example, if you spe ify a variable
of type V4SI and your ar hite ture does not allow for this spe i SIMD type, GCC will
produ e ode that uses 4 SIs.
The types dened in this manner an be used with a subset of normal C operations.
Currently, GCC will allow using the following operators on these types: +, -, *, /, unary
minus, ^, |, &, ~.
The operations behave like C++ valarrays. Addition is dened as the addition of the
orresponding elements of the operands. For example, in the ode below, ea h of the 4
elements in a will be added to the orresponding 4 elements in b and the resulting ve tor
will be stored in .
typedef int v4si __attribute__ ((ve tor_size (16)));
v4si a, b, ;
= a + b;

Subtra tion, multipli ation, division, and the logi al operations operate in a similar manner. Likewise, the result of using the unary minus or omplement operators on a ve tor type
is a ve tor whose elements are the negative or omplemented values of the orresponding
elements in the operand.
You an de lare variables and use them in fun tion alls and returns, as well as in assignments and some asts. You an spe ify a ve tor type as a return type for a fun tion.
Ve tor types an also be used as fun tion arguments. It is possible to ast from one ve tor
type to another, provided they are of the same size (in fa t, you an also ast ve tors to
and from other datatypes of the same size).
You annot operate between ve tors of dierent lengths or dierent signedness without a
ast.

272

Using the GNU Compiler Colle tion (GCC)

A port that supports hardware ve tor operations, usually provides a set of built-in fun tions that an be used to operate on ve tors. For example, a fun tion to add two ve tors
and multiply the result by a third ould look like this:
v4si f (v4si a, v4si b, v4si )
{
v4si tmp = __builtin_addv4si (a, b);
return __builtin_mulv4si (tmp, );
}

5.43 Osetof
GCC implements for both C and C++ a synta ti extension to implement the offsetof
ma ro.
primary:
"__builtin_offsetof" "(" typename "," offsetof_member_designator ")"
offsetof_member_designator:
identifier
| offsetof_member_designator "." identifier
| offsetof_member_designator "[" expr ""

This extension is su ient su h that

#define offsetof(type, member )

__builtin_offsetof (type, member )

is a suitable denition of the offsetof ma ro. In C++, type may be dependent. In either
ase, member may onsist of a single identier, or a sequen e of member a esses and array
referen es.

5.44 Other built-in fun tions provided by GCC

GCC provides a large number of built-in fun tions other than the ones mentioned above.
Some of these are for internal use in the pro essing of ex eptions or variable-length argument
lists and will not be do umented here be ause they may hange from time to time; we do
not re ommend general use of these fun tions.
The remaining fun tions are provided for optimization purposes.
GCC in ludes built-in versions of many of the fun tions in the standard C library. The
versions prexed with __builtin_ will always be treated as having the same meaning as
the C library fun tion even if you spe ify the `-fno-builtin' option. (see Se tion 3.4 [C
Diale t Options, page 20) Many of these fun tions are only optimized in ertain ases; if
they are not optimized in a parti ular ase, a all to the library fun tion will be emitted.
Outside stri t ISO C mode (`-ansi', `-std= 89' or `-std= 99'), the fun tions _exit,
allo a, b mp, bzero, d gettext, dgettext, dremf, dreml, drem, exp10f, exp10l, exp10,
ffsll, ffsl, ffs, fprintf_unlo ked, fputs_unlo ked, gammaf, gammal, gamma, gettext,
index, isas ii, j0f, j0l, j0, j1f, j1l, j1, jnf, jnl, jn, memp py, pow10f, pow10l,
pow10, printf_unlo ked, rindex, s albf, s albl, s alb, signbit, signbitf, signbitl,
signifi andf, signifi andl, signifi and, sin osf, sin osl, sin os, stp py, strdup,
strfmon, toas ii, y0f, y0l, y0, y1f, y1l, y1, ynf, ynl and yn may be handled as built-in
fun tions. All these fun tions have orresponding versions prexed with __builtin_, whi h
may be used even in stri t C89 mode.

Chapter 5: Extensions to the C Language Family

273

The ISO C99 fun tions _Exit, a oshf, a oshl, a osh, asinhf, asinhl, asinh,
atanhf, atanhl, atanh, absf, absl, abs, a osf, a oshf, a oshl, a osh,
a osl, a os, argf, argl, arg, asinf, asinhf, asinhl, asinh, asinl,
asin, atanf, atanhf, atanhl, atanh, atanl, atan, brtf, brtl, brt, osf,
oshf, oshl, osh, osl, os, expf, expl, exp, imagf, imagl, imag,
onjf, onjl, onj, opysignf, opysignl, opysign, powf, powl, pow, projf,
projl, proj, realf, reall, real, sinf, sinhf, sinhl, sinh, sinl, sin,
sqrtf, sqrtl, sqrt, tanf, tanhf, tanhl, tanh, tanl, tan, erf f, erf l,
erf , erff, erfl, erf, exp2f, exp2l, exp2, expm1f, expm1l, expm1, fdimf, fdiml, fdim,
fmaf, fmal, fmaxf, fmaxl, fmax, fma, fminf, fminl, fmin, hypotf, hypotl, hypot,
ilogbf, ilogbl, ilogb, imaxabs, isblank, iswblank, lgammaf, lgammal, lgamma, llabs,
llrintf, llrintl, llrint, llroundf, llroundl, llround, log1pf, log1pl, log1p,
log2f, log2l, log2, logbf, logbl, logb, lrintf, lrintl, lrint, lroundf, lroundl,
lround, nearbyintf, nearbyintl, nearbyint, nextafterf, nextafterl, nextafter,
nexttowardf, nexttowardl, nexttoward, remainderf, remainderl, remainder, remquof,
remquol, remquo, rintf, rintl, rint, roundf, roundl, round, s alblnf, s alblnl,
s albln, s albnf, s albnl, s albn, snprintf, tgammaf, tgammal, tgamma, trun f,
trun l, trun , vfs anf, vs anf, vsnprintf and vss anf are handled as built-in
fun tions ex ept in stri t ISO C90 mode (`-ansi' or `-std= 89').
There are also built-in versions of the ISO C99 fun tions a osf, a osl, asinf, asinl,
atan2f, atan2l, atanf, atanl, eilf, eill, osf, oshf, oshl, osl, expf, expl,
fabsf, fabsl, floorf, floorl, fmodf, fmodl, frexpf, frexpl, ldexpf, ldexpl, log10f,
log10l, logf, logl, modfl, modf, powf, powl, sinf, sinhf, sinhl, sinl, sqrtf, sqrtl,
tanf, tanhf, tanhl and tanl that are re ognized in any mode sin e ISO C90 reserves these
names for the purpose to whi h ISO C99 puts them. All these fun tions have orresponding
versions prexed with __builtin_.
The ISO C94 fun tions iswalnum, iswalpha, isw ntrl, iswdigit, iswgraph, iswlower,
iswprint, iswpun t, iswspa e, iswupper, iswxdigit, towlower and towupper are handled as built-in fun tions ex ept in stri t ISO C90 mode (`-ansi' or `-std= 89').
The ISO C90 fun tions abort, abs, a os, asin, atan2, atan, allo , eil, osh,
os, exit, exp, fabs, floor, fmod, fprintf, fputs, frexp, fs anf, isalnum, isalpha,
is ntrl, isdigit, isgraph, islower, isprint, ispun t, isspa e, isupper, isxdigit,
tolower, toupper, labs, ldexp, log10, log, mallo , mem mp, mem py, memset, modf, pow,
printf, put har, puts, s anf, sinh, sin, snprintf, sprintf, sqrt, ss anf, str at,
str hr, str mp, str py, str spn, strlen, strn at, strn mp, strn py, strpbrk,
strr hr, strspn, strstr, tanh, tan, vfprintf, vprintf and vsprintf are all re ognized
as built-in fun tions unless `-fno-builtin' is spe ied (or `-fno-builtin-fun tion ' is
spe ied for an individual fun tion). All of these fun tions have orresponding versions
prexed with __builtin_.
GCC provides built-in versions of the ISO C99 oating point omparison ma ros that
avoid raising ex eptions for unordered operands. They have the same names as the standard ma ros ( isgreater, isgreaterequal, isless, islessequal, islessgreater, and
isunordered) , with __builtin_ prexed. We intend for a library implementor to be able
to simply #define ea h standard ma ro to its built-in equivalent.

274

Using the GNU Compiler Colle tion (GCC)

int __builtin_types_ ompatible_p (type1, type2 )

[Built-in Fun tion
You an use the built-in fun tion __builtin_types_ ompatible_p to determine
whether two types are the same.
This built-in fun tion returns 1 if the unqualied versions of the types type1 and
type2 (whi h are types, not expressions) are ompatible, 0 otherwise. The result of
this built-in fun tion an be used in integer onstant expressions.
This built-in fun tion ignores top level qualiers (e.g., onst, volatile). For example, int is equivalent to onst int.
The type int[ and int[5 are ompatible. On the other hand, int and har * are
not ompatible, even if the size of their types, on the parti ular ar hite ture are the
same. Also, the amount of pointer indire tion is taken into a ount when determining
similarity. Consequently, short * is not similar to short **. Furthermore, two types
that are typedefed are onsidered ompatible if their underlying types are ompatible.
An enum type is not onsidered to be ompatible with another enum type even if both
are ompatible with the same integer type; this is what the C standard spe ies. For
example, enum {foo, bar} is not similar to enum {hot, dog}.
You would typi ally use this fun tion in ode whose exe ution varies depending on
the arguments' types. For example:
#define foo(x)
\
({
\
typeof (x) tmp;
\
if (__builtin_types_ ompatible_p (typeof (x), long double)) \
tmp = foo_long_double (tmp);
\
else if (__builtin_types_ ompatible_p (typeof (x), double)) \
tmp = foo_double (tmp);
\
else if (__builtin_types_ ompatible_p (typeof (x), float)) \
tmp = foo_float (tmp);
\
else
\
abort ();
\
tmp;
\
})

Note: This onstru t is only available for C.

type __builtin_ hoose_expr ( onst_exp, exp1, exp2 )

[Built-in Fun tion
You an use the built-in fun tion __builtin_ hoose_expr to evaluate ode depending on the value of a onstant expression. This built-in fun tion returns exp1 if
onst exp, whi h is a onstant expression that must be able to be determined at
ompile time, is nonzero. Otherwise it returns 0.
This built-in fun tion is analogous to the `? :' operator in C, ex ept that the expression returned has its type unaltered by promotion rules. Also, the built-in fun tion
does not evaluate the expression that was not hosen. For example, if onst exp
evaluates to true, exp2 is not evaluated even if it has side-ee ts.
This built-in fun tion an return an lvalue if the hosen argument is an lvalue.
If exp1 is returned, the return type is the same as exp1's type. Similarly, if exp2 is
returned, its return type is the same as exp2.
Example:

Chapter 5: Extensions to the C Language Family

#define foo(x)
__builtin_ hoose_expr (
__builtin_types_ ompatible_p (typeof (x), double),
foo_double (x),
__builtin_ hoose_expr (
__builtin_types_ ompatible_p (typeof (x), float),
foo_float (x),
/* The void expression results in a ompile-time error \
when assigning the result to something. */
\
(void)0))

275

\
\
\
\
\
\
\

Note: This onstru t is only available for C. Furthermore, the unused expression
(exp1 or exp2 depending on the value of onst exp) may still generate syntax errors.
This may hange in future revisions.

int __builtin_ onstant_p (exp )

[Built-in Fun tion
You an use the built-in fun tion __builtin_ onstant_p to determine if a value is
known to be onstant at ompile-time and hen e that GCC an perform onstantfolding on expressions involving that value. The argument of the fun tion is the value
to test. The fun tion returns the integer 1 if the argument is known to be a ompiletime onstant and 0 if it is not known to be a ompile-time onstant. A return of 0
does not indi ate that the value is not a onstant, but merely that GCC annot prove
it is a onstant with the spe ied value of the `-O' option.
You would typi ally use this fun tion in an embedded appli ation where memory was
a riti al resour e. If you have some omplex al ulation, you may want it to be
folded if it involves onstants, but need to all a fun tion if it does not. For example:
#define S ale_Value(X)
\
(__builtin_ onstant_p (X) \
? ((X) * SCALE + OFFSET) : S ale (X))

You may use this built-in fun tion in either a ma ro or an inline fun tion. However, if
you use it in an inlined fun tion and pass an argument of the fun tion as the argument
to the built-in, GCC will never return 1 when you all the inline fun tion with a string
onstant or ompound literal (see Se tion 5.19 [Compound Literals, page 214) and
will not return 1 when you pass a onstant numeri value to the inline fun tion unless
you spe ify the `-O' option.
You may also use __builtin_ onstant_p in initializers for stati data. For instan e,
you an write
stati onst int table[ = {
__builtin_ onstant_p (EXPRESSION) ? (EXPRESSION) : -1,
/* . . . */
};

This is an a eptable initializer even if EXPRESSION is not a onstant expression.

GCC must be more onservative about evaluating the built-in in this ase, be ause it
has no opportunity to perform optimization.
Previous versions of GCC did not a ept this built-in in data initializers. The earliest
version where it is ompletely safe is 3.0.1.
long __builtin_expe t (long exp, long )
[Built-in Fun tion
You may use __builtin_expe t to provide the ompiler with bran h predi tion
information. In general, you should prefer to use a tual prole feedba k for this

276

Using the GNU Compiler Colle tion (GCC)

(`-fprofile-ar s'), as programmers are notoriously bad at predi ting how their
programs a tually perform. However, there are appli ations in whi h this data is
hard to olle t.
The return value is the value of exp, whi h should be an integral expression. The
value of must be a ompile-time onstant. The semanti s of the built-in are that it
is expe ted that exp == . For example:
if (__builtin_expe t (x, 0))
foo ();

would indi ate that we do not expe t to all foo, sin e we expe t x to be zero. Sin e
you are limited to integral expressions for exp, you should use onstru tions su h as
if (__builtin_expe t (ptr != NULL, 1))
error ();

when testing pointer or oating-point values.

void __builtin_prefet h ( onst void *addr, ...)
[Built-in Fun tion
This fun tion is used to minimize a he-miss laten y by moving data into a a he
before it is a essed. You an insert alls to __builtin_prefet h into ode for
whi h you know addresses of data in memory that is likely to be a essed soon. If the
target supports them, data prefet h instru tions will be generated. If the prefet h is
done early enough before the a ess then the data will be in the a he by the time it
is a essed.
The value of addr is the address of the memory to prefet h. There are two optional
arguments, rw and lo ality. The value of rw is a ompile-time onstant one or zero;
one means that the prefet h is preparing for a write to the memory address and zero,
the default, means that the prefet h is preparing for a read. The value lo ality must
be a ompile-time onstant integer between zero and three. A value of zero means
that the data has no temporal lo ality, so it need not be left in the a he after the
a ess. A value of three means that the data has a high degree of temporal lo ality and
should be left in all levels of a he possible. Values of one and two mean, respe tively,
a low or moderate degree of temporal lo ality. The default is three.
for (i = 0; i < n; i++)
{
a[i = a[i + b[i;
__builtin_prefet h (&a[i+j, 1, 1);
__builtin_prefet h (&b[i+j, 0, 1);
/* . . . */
}

Data prefet h does not generate faults if addr is invalid, but the address expression
itself must be valid. For example, a prefet h of p->next will not fault if p->next is
not a valid address, but evaluation will fault if p is not a valid address.
If the target does not support data prefet h, the address expression is evaluated if it
in ludes side ee ts but no other ode is generated and GCC does not issue a warning.
double __builtin_huge_val (void)
[Built-in Fun tion
Returns a positive innity, if supported by the oating-point format, else DBL_MAX.
This fun tion is suitable for implementing the ISO C ma ro HUGE_VAL.
float __builtin_huge_valf (void)
[Built-in Fun tion
Similar to __builtin_huge_val, ex ept the return type is float.

Chapter 5: Extensions to the C Language Family

277

long double __builtin_huge_vall (void)

[Built-in Fun tion
Similar to __builtin_huge_val, ex ept the return type is long double.
double __builtin_inf (void)
[Built-in Fun tion
Similar to __builtin_huge_val, ex ept a warning is generated if the target oatingpoint format does not support innities.
float __builtin_inff (void)
[Built-in Fun tion
Similar to __builtin_inf, ex ept the return type is float. This fun tion is suitable
for implementing the ISO C99 ma ro INFINITY.
long double __builtin_infl (void)
[Built-in Fun tion
Similar to __builtin_inf, ex ept the return type is long double.
double __builtin_nan ( onst har *str)
[Built-in Fun tion
This is an implementation of the ISO C99 fun tion nan.
Sin e ISO C99 denes this fun tion in terms of strtod, whi h we do not implement,
a des ription of the parsing is in order. The string is parsed as by strtol; that is, the
base is re ognized by leading `0' or `0x' prexes. The number parsed is pla ed in the
signi and su h that the least signi ant bit of the number is at the least signi ant
bit of the signi and. The number is trun ated to t the signi and eld provided.
The signi and is for ed to be a quiet NaN.
This fun tion, if given a string literal, is evaluated early enough that it is onsidered
a ompile-time onstant.
float __builtin_nanf ( onst har *str)
Similar to __builtin_nan, ex ept the return type is float.

[Built-in Fun tion

long double __builtin_nanl ( onst har *str)

[Built-in Fun tion
Similar to __builtin_nan, ex ept the return type is long double.
double __builtin_nans ( onst har *str)
[Built-in Fun tion
Similar to __builtin_nan, ex ept the signi and is for ed to be a signaling NaN.
The nans fun tion is proposed by WG14 N965.
float __builtin_nansf ( onst har *str)
Similar to __builtin_nans, ex ept the return type is float.

[Built-in Fun tion

long double __builtin_nansl ( onst har *str)

[Built-in Fun tion
Similar to __builtin_nans, ex ept the return type is long double.
int __builtin_ffs (unsigned int x)
[Built-in Fun tion
Returns one plus the index of the least signi ant 1-bit of x, or if x is zero, returns
zero.
int __builtin_ lz (unsigned int x)
[Built-in Fun tion
Returns the number of leading 0-bits in x, starting at the most signi ant bit position.
If x is 0, the result is undened.
int __builtin_ tz (unsigned int x)
[Built-in Fun tion
Returns the number of trailing 0-bits in x, starting at the least signi ant bit position.
If x is 0, the result is undened.

278

int __builtin_pop ount (unsigned int x)

Returns the number of 1-bits in x.

Using the GNU Compiler Colle tion (GCC)

[Built-in Fun tion

int __builtin_parity (unsigned int x)

[Built-in Fun tion
Returns the parity of x, i.e. the number of 1-bits in x modulo 2.
int __builtin_ffsl (unsigned long)
[Built-in Fun tion
Similar to __builtin_ffs, ex ept the argument type is unsigned long.
int __builtin_ lzl (unsigned long)
[Built-in Fun tion
Similar to __builtin_ lz, ex ept the argument type is unsigned long.
int __builtin_ tzl (unsigned long)
[Built-in Fun tion
Similar to __builtin_ tz, ex ept the argument type is unsigned long.
int __builtin_pop ountl (unsigned long)
[Built-in Fun tion
Similar to __builtin_pop ount, ex ept the argument type is unsigned long.
int __builtin_parityl (unsigned long)
[Built-in Fun tion
Similar to __builtin_parity, ex ept the argument type is unsigned long.
int __builtin_ffsll (unsigned long long)
[Built-in Fun tion
Similar to __builtin_ffs, ex ept the argument type is unsigned long long.
int __builtin_ lzll (unsigned long long)
[Built-in Fun tion
Similar to __builtin_ lz, ex ept the argument type is unsigned long long.
int __builtin_ tzll (unsigned long long)
[Built-in Fun tion
Similar to __builtin_ tz, ex ept the argument type is unsigned long long.
int __builtin_pop ountll (unsigned long long)
[Built-in Fun tion
Similar to __builtin_pop ount, ex ept the argument type is unsigned long long.
int __builtin_parityll (unsigned long long)
[Built-in Fun tion
Similar to __builtin_parity, ex ept the argument type is unsigned long long.
double __builtin_powi (double, int)
[Built-in Fun tion
Returns the rst argument raised to the power of the se ond. Unlike the pow fun tion
no guarantees about pre ision and rounding are made.
float __builtin_powif ( oat, int)
[Built-in Fun tion
Similar to __builtin_powi, ex ept the argument and return types are float.
long double __builtin_powil (long double, int)
[Built-in Fun tion
Similar to __builtin_powi, ex ept the argument and return types are long double.

Chapter 5: Extensions to the C Language Family

279

5.45 Built-in Fun tions Spe i to Parti ular Target

Ma hines
On some target ma hines, GCC supports many built-in fun tions spe i to those ma hines.
Generally these generate alls to spe i ma hine instru tions, but allow the ompiler to
s hedule those alls.

5.45.1 Alpha Built-in Fun tions

These built-in fun tions are available for the Alpha family of pro essors, depending on the
ommand-line swit hes used.
The following built-in fun tions are always available. They all generate the ma hine
instru tion that is part of the name.
long
long
long
long
long
long
long
long
long
long
long
long
long
long
long
long
long
long
long
long
long
long
long
long
long
long
long
long

__builtin_alpha_implver (void)
__builtin_alpha_rp (void)
__builtin_alpha_amask (long)
__builtin_alpha_ mpbge (long, long)
__builtin_alpha_extbl (long, long)
__builtin_alpha_extwl (long, long)
__builtin_alpha_extll (long, long)
__builtin_alpha_extql (long, long)
__builtin_alpha_extwh (long, long)
__builtin_alpha_extlh (long, long)
__builtin_alpha_extqh (long, long)
__builtin_alpha_insbl (long, long)
__builtin_alpha_inswl (long, long)
__builtin_alpha_insll (long, long)
__builtin_alpha_insql (long, long)
__builtin_alpha_inswh (long, long)
__builtin_alpha_inslh (long, long)
__builtin_alpha_insqh (long, long)
__builtin_alpha_mskbl (long, long)
__builtin_alpha_mskwl (long, long)
__builtin_alpha_mskll (long, long)
__builtin_alpha_mskql (long, long)
__builtin_alpha_mskwh (long, long)
__builtin_alpha_msklh (long, long)
__builtin_alpha_mskqh (long, long)
__builtin_alpha_umulh (long, long)
__builtin_alpha_zap (long, long)
__builtin_alpha_zapnot (long, long)

The following built-in fun tions are always with `-mmax' or `-m pu= pu ' where pu is
p a56 or later. They all generate the ma hine instru tion that is part of the name.
long
long
long
long
long
long
long
long
long
long
long
long
long

__builtin_alpha_pklb (long)
__builtin_alpha_pkwb (long)
__builtin_alpha_unpkbl (long)
__builtin_alpha_unpkbw (long)
__builtin_alpha_minub8 (long, long)
__builtin_alpha_minsb8 (long, long)
__builtin_alpha_minuw4 (long, long)
__builtin_alpha_minsw4 (long, long)
__builtin_alpha_maxub8 (long, long)
__builtin_alpha_maxsb8 (long, long)
__builtin_alpha_maxuw4 (long, long)
__builtin_alpha_maxsw4 (long, long)
__builtin_alpha_perr (long, long)

280

Using the GNU Compiler Colle tion (GCC)

The following built-in fun tions are always with `-m ix' or `-m pu= pu ' where pu is
ev67 or later. They all generate the ma hine instru tion that is part of the name.
long __builtin_alpha_ ttz (long)
long __builtin_alpha_ tlz (long)
long __builtin_alpha_ tpop (long)

The following builtins are available on systems that use the OSF/1 PAL ode. Normally
they invoke the rduniq and wruniq PAL alls, but when invoked with `-mtls-kernel',
they invoke rdval and wrval.
void *__builtin_thread_pointer (void)
void __builtin_set_thread_pointer (void *)

5.45.2 ARM Built-in Fun tions

These built-in fun tions are available for the ARM family of pro essors, when the
`-m pu=iwmmxt' swit h is used:
typedef int v2si __attribute__ ((ve tor_size (8)));
typedef short v4hi __attribute__ ((ve tor_size (8)));
typedef har v8qi __attribute__ ((ve tor_size (8)));
int __builtin_arm_getw x (int)
void __builtin_arm_setw x (int, int)
int __builtin_arm_textrmsb (v8qi, int)
int __builtin_arm_textrmsh (v4hi, int)
int __builtin_arm_textrmsw (v2si, int)
int __builtin_arm_textrmub (v8qi, int)
int __builtin_arm_textrmuh (v4hi, int)
int __builtin_arm_textrmuw (v2si, int)
v8qi __builtin_arm_tinsrb (v8qi, int)
v4hi __builtin_arm_tinsrh (v4hi, int)
v2si __builtin_arm_tinsrw (v2si, int)
long long __builtin_arm_tmia (long long, int, int)
long long __builtin_arm_tmiabb (long long, int, int)
long long __builtin_arm_tmiabt (long long, int, int)
long long __builtin_arm_tmiaph (long long, int, int)
long long __builtin_arm_tmiatb (long long, int, int)
long long __builtin_arm_tmiatt (long long, int, int)
int __builtin_arm_tmovmskb (v8qi)
int __builtin_arm_tmovmskh (v4hi)
int __builtin_arm_tmovmskw (v2si)
long long __builtin_arm_wa b (v8qi)
long long __builtin_arm_wa h (v4hi)
long long __builtin_arm_wa w (v2si)
v8qi __builtin_arm_waddb (v8qi, v8qi)
v8qi __builtin_arm_waddbss (v8qi, v8qi)
v8qi __builtin_arm_waddbus (v8qi, v8qi)
v4hi __builtin_arm_waddh (v4hi, v4hi)
v4hi __builtin_arm_waddhss (v4hi, v4hi)
v4hi __builtin_arm_waddhus (v4hi, v4hi)
v2si __builtin_arm_waddw (v2si, v2si)
v2si __builtin_arm_waddwss (v2si, v2si)
v2si __builtin_arm_waddwus (v2si, v2si)
v8qi __builtin_arm_walign (v8qi, v8qi, int)
long long __builtin_arm_wand(long long, long long)
long long __builtin_arm_wandn (long long, long long)
v8qi __builtin_arm_wavg2b (v8qi, v8qi)
v8qi __builtin_arm_wavg2br (v8qi, v8qi)

Chapter 5: Extensions to the C Language Family

v4hi
v4hi
v8qi
v4hi
v2si
v8qi
v4hi
v2si
v8qi
v4hi
v2si
long
long
long
long
v4hi
v4hi
v8qi
v4hi
v2si
v8qi
v4hi
v2si
v8qi
v4hi
v2si
v8qi
v4hi
v2si
v4hi
v4hi
v4hi
long
v2si
v2si
v8qi
v8qi
v4hi
v4hi
long
long
v4hi
v4hi
v2si
v2si
v2si
v2si
v2si
v2si
v4hi
long
long
v4hi
v4hi
v2si
v2si
long
long

__builtin_arm_wavg2h (v4hi, v4hi)

__builtin_arm_wavg2hr (v4hi, v4hi)
__builtin_arm_w mpeqb (v8qi, v8qi)
__builtin_arm_w mpeqh (v4hi, v4hi)
__builtin_arm_w mpeqw (v2si, v2si)
__builtin_arm_w mpgtsb (v8qi, v8qi)
__builtin_arm_w mpgtsh (v4hi, v4hi)
__builtin_arm_w mpgtsw (v2si, v2si)
__builtin_arm_w mpgtub (v8qi, v8qi)
__builtin_arm_w mpgtuh (v4hi, v4hi)
__builtin_arm_w mpgtuw (v2si, v2si)
long __builtin_arm_wma s (long long, v4hi, v4hi)
long __builtin_arm_wma sz (v4hi, v4hi)
long __builtin_arm_wma u (long long, v4hi, v4hi)
long __builtin_arm_wma uz (v4hi, v4hi)
__builtin_arm_wmadds (v4hi, v4hi)
__builtin_arm_wmaddu (v4hi, v4hi)
__builtin_arm_wmaxsb (v8qi, v8qi)
__builtin_arm_wmaxsh (v4hi, v4hi)
__builtin_arm_wmaxsw (v2si, v2si)
__builtin_arm_wmaxub (v8qi, v8qi)
__builtin_arm_wmaxuh (v4hi, v4hi)
__builtin_arm_wmaxuw (v2si, v2si)
__builtin_arm_wminsb (v8qi, v8qi)
__builtin_arm_wminsh (v4hi, v4hi)
__builtin_arm_wminsw (v2si, v2si)
__builtin_arm_wminub (v8qi, v8qi)
__builtin_arm_wminuh (v4hi, v4hi)
__builtin_arm_wminuw (v2si, v2si)
__builtin_arm_wmulsm (v4hi, v4hi)
__builtin_arm_wmulul (v4hi, v4hi)
__builtin_arm_wmulum (v4hi, v4hi)
long __builtin_arm_wor (long long, long long)
__builtin_arm_wpa kdss (long long, long long)
__builtin_arm_wpa kdus (long long, long long)
__builtin_arm_wpa khss (v4hi, v4hi)
__builtin_arm_wpa khus (v4hi, v4hi)
__builtin_arm_wpa kwss (v2si, v2si)
__builtin_arm_wpa kwus (v2si, v2si)
long __builtin_arm_wrord (long long, long long)
long __builtin_arm_wrordi (long long, int)
__builtin_arm_wrorh (v4hi, long long)
__builtin_arm_wrorhi (v4hi, int)
__builtin_arm_wrorw (v2si, long long)
__builtin_arm_wrorwi (v2si, int)
__builtin_arm_wsadb (v8qi, v8qi)
__builtin_arm_wsadbz (v8qi, v8qi)
__builtin_arm_wsadh (v4hi, v4hi)
__builtin_arm_wsadhz (v4hi, v4hi)
__builtin_arm_wshufh (v4hi, int)
long __builtin_arm_wslld (long long, long long)
long __builtin_arm_wslldi (long long, int)
__builtin_arm_wsllh (v4hi, long long)
__builtin_arm_wsllhi (v4hi, int)
__builtin_arm_wsllw (v2si, long long)
__builtin_arm_wsllwi (v2si, int)
long __builtin_arm_wsrad (long long, long long)
long __builtin_arm_wsradi (long long, int)

281

282

Using the GNU Compiler Colle tion (GCC)

v4hi
v4hi
v2si
v2si
long
long
v4hi
v4hi
v2si
v2si
v8qi
v8qi
v8qi
v4hi
v4hi
v4hi
v2si
v2si
v2si
v4hi
v2si
long
v4hi
v2si
long
v4hi
v2si
long
v4hi
v2si
long
v8qi
v4hi
v2si
v8qi
v4hi
v2si
long
long

__builtin_arm_wsrah (v4hi, long long)

__builtin_arm_wsrahi (v4hi, int)
__builtin_arm_wsraw (v2si, long long)
__builtin_arm_wsrawi (v2si, int)
long __builtin_arm_wsrld (long long, long long)
long __builtin_arm_wsrldi (long long, int)
__builtin_arm_wsrlh (v4hi, long long)
__builtin_arm_wsrlhi (v4hi, int)
__builtin_arm_wsrlw (v2si, long long)
__builtin_arm_wsrlwi (v2si, int)
__builtin_arm_wsubb (v8qi, v8qi)
__builtin_arm_wsubbss (v8qi, v8qi)
__builtin_arm_wsubbus (v8qi, v8qi)
__builtin_arm_wsubh (v4hi, v4hi)
__builtin_arm_wsubhss (v4hi, v4hi)
__builtin_arm_wsubhus (v4hi, v4hi)
__builtin_arm_wsubw (v2si, v2si)
__builtin_arm_wsubwss (v2si, v2si)
__builtin_arm_wsubwus (v2si, v2si)
__builtin_arm_wunp kehsb (v8qi)
__builtin_arm_wunp kehsh (v4hi)
long __builtin_arm_wunp kehsw (v2si)
__builtin_arm_wunp kehub (v8qi)
__builtin_arm_wunp kehuh (v4hi)
long __builtin_arm_wunp kehuw (v2si)
__builtin_arm_wunp kelsb (v8qi)
__builtin_arm_wunp kelsh (v4hi)
long __builtin_arm_wunp kelsw (v2si)
__builtin_arm_wunp kelub (v8qi)
__builtin_arm_wunp keluh (v4hi)
long __builtin_arm_wunp keluw (v2si)
__builtin_arm_wunp kihb (v8qi, v8qi)
__builtin_arm_wunp kihh (v4hi, v4hi)
__builtin_arm_wunp kihw (v2si, v2si)
__builtin_arm_wunp kilb (v8qi, v8qi)
__builtin_arm_wunp kilh (v4hi, v4hi)
__builtin_arm_wunp kilw (v2si, v2si)
long __builtin_arm_wxor (long long, long long)
long __builtin_arm_wzero ()

5.45.3 FR-V Built-in Fun tions

GCC provides many FR-V-spe i built-in fun tions. In general, these fun tions are intended to be ompatible with those des ribed by FR-V Family, Softune C/C++ Compiler
Manual (V6), Fujitsu Semi ondu tor. The two ex eptions are __MDUNPACKH and __MBTOHE,
the g forms of whi h pass 128-bit values by pointer rather than by value.
Most of the fun tions are named after spe i FR-V instru tions. Su h fun tions are said
to be \dire tly mapped" and are summarized here in tabular form.

5.45.3.1 Argument Types

The arguments to the built-in fun tions an be divided into three groups: register numbers,
ompile-time onstants and run-time values. In order to make this lassi ation lear at a
glan e, the arguments and return values are given the following pseudo types:
Pseudo type
Real C type
Constant? Des ription
uh
unsigned short
No
an unsigned halfword

Chapter 5: Extensions to the C Language Family

283

No
an unsigned word
No
a signed word
No
an unsigned doubleword
No
a signed doubleword
Yes
an integer onstant
Yes
an ACC register number
Yes
an IACC register number
These pseudo types are not dened by GCC, they are simply a notational onvenien e
used in this manual.
Arguments of type uh, uw1, sw1, uw2 and sw2 are evaluated at run time. They orrespond
to register operands in the underlying FR-V instru tions.
onst arguments represent immediate operands in the underlying FR-V instru tions.
They must be ompile-time onstants.
a arguments are evaluated at ompile time and spe ify the number of an a umulator
register. For example, an a argument of 2 will sele t the ACC2 register.
ia arguments are similar to a arguments but spe ify the number of an IACC register.
See see Se tion 5.45.3.4 [Other Built-in Fun tions, page 285 for more details.

uw1
sw1
uw2
sw2
onst
a
ia

unsigned int
int
unsigned long long
long long
int
int
int

5.45.3.2 Dire tly-mapped Integer Fun tions

The fun tions listed below map dire tly to FR-V I-type instru tions.
Fun tion prototype
Example usage

sw1 __ADDSS (sw1, sw1)

sw1 __SCAN (sw1, sw1)
sw1 __SCUTSS (sw1)
sw1 __SLASS (sw1, sw1)
void __SMASS (sw1, sw1)
void __SMSSS (sw1, sw1)
void __SMU (sw1, sw1)
sw2 __SMUL (sw1, sw1)
sw1 __SUBSS (sw1, sw1)
uw2 __UMUL (uw1, uw1)

= __ADDSS (a, b )
= __SCAN (a, b )
b = __SCUTSS (a )
= __SLASS (a, b )
__SMASS (a, b )
__SMSSS (a, b )
__SMU (a, b )
= __SMUL (a, b )
= __SUBSS (a, b )
= __UMUL (a, b )

Assembly output

ADDSS a,b,
SCAN a,b,
SCUTSS a,b
SLASS a,b,
SMASS a,b
SMSSS a,b
SMU a,b
SMUL a,b,
SUBSS a,b,
UMUL a,b,

5.45.3.3 Dire tly-mapped Media Fun tions

The fun tions listed below map dire tly to FR-V M-type instru tions.
Fun tion prototype
Example usage
Assembly output

uw1 __MABSHS (sw1)

void __MADDACCS (a , a )
sw1 __MADDHSS (sw1, sw1)
uw1 __MADDHUS (uw1, uw1)
uw1 __MAND (uw1, uw1)
void __MASACCS (a , a )
uw1 __MAVEH (uw1, uw1)
uw2 __MBTOH (uw1)
void __MBTOHE (uw1 *, uw1)
void __MCLRACC (a )

b = __MABSHS (a )
__MADDACCS (b, a )
= __MADDHSS (a, b )
= __MADDHUS (a, b )
= __MAND (a, b )
__MASACCS (b, a )
= __MAVEH (a, b )
b = __MBTOH (a )
__MBTOHE (&b, a )
__MCLRACC (a )

MABSHS a,b
MADDACCS a,b
MADDHSS a,b,
MADDHUS a,b,
MAND a,b,
MASACCS a,b
MAVEH a,b,
MBTOH a,b
MBTOHE a,b
MCLRACC a

284

void __MCLRACCA (void)

uw1 __M op1 (uw1, uw1)
uw1 __M op2 (uw1, uw1)
uw1 __MCPLHI (uw2, onst)
uw1 __MCPLI (uw2, onst)
void __MCPXIS (a , sw1, sw1)
void __MCPXIU (a , uw1, uw1)
void __MCPXRS (a , sw1, sw1)
void __MCPXRU (a , uw1, uw1)
uw1 __MCUT (a , uw1)
uw1 __MCUTSS (a , sw1)
void __MDADDACCS (a , a )
void __MDASACCS (a , a )
uw2 __MDCUTSSI (a , onst)
uw2 __MDPACKH (uw2, uw2)
uw2 __MDROTLI (uw2, onst)
void __MDSUBACCS (a , a )
void __MDUNPACKH (uw1 *, uw2)
uw2 __MEXPDHD (uw1, onst)
uw1 __MEXPDHW (uw1, onst)
uw1 __MHDSETH (uw1, onst)
sw1 __MHDSETS ( onst)
uw1 __MHSETHIH (uw1, onst)
sw1 __MHSETHIS (sw1, onst)
uw1 __MHSETLOH (uw1, onst)
sw1 __MHSETLOS (sw1, onst)
uw1 __MHTOB (uw2)
void __MMACHS (a , sw1, sw1)
void __MMACHU (a , uw1, uw1)
void __MMRDHS (a , sw1, sw1)
void __MMRDHU (a , uw1, uw1)
void __MMULHS (a , sw1, sw1)
void __MMULHU (a , uw1, uw1)
void __MMULXHS (a , sw1, sw1)
void __MMULXHU (a , uw1, uw1)
uw1 __MNOT (uw1)
uw1 __MOR (uw1, uw1)
uw1 __MPACKH (uh, uh)
sw2 __MQADDHSS (sw2, sw2)
uw2 __MQADDHUS (uw2, uw2)
void __MQCPXIS (a , sw2, sw2)
void __MQCPXIU (a , uw2, uw2)
void __MQCPXRS (a , sw2, sw2)
void __MQCPXRU (a , uw2, uw2)
sw2 __MQLCLRHS (sw2, sw2)
sw2 __MQLMTHS (sw2, sw2)
void __MQMACHS (a , sw2, sw2)

Using the GNU Compiler Colle tion (GCC)

__MCLRACCA ()
= __M op1 (a, b )
= __M op2 (a, b )
= __MCPLHI (a, b )
= __MCPLI (a, b )
__MCPXIS ( , a, b )
__MCPXIU ( , a, b )
__MCPXRS ( , a, b )
__MCPXRU ( , a, b )
= __MCUT (a, b )
= __MCUTSS (a, b )
__MDADDACCS (b, a )
__MDASACCS (b, a )
= __MDCUTSSI (a, b )
= __MDPACKH (a, b )
= __MDROTLI (a, b )
__MDSUBACCS (b, a )
__MDUNPACKH (&b, a )
= __MEXPDHD (a, b )
= __MEXPDHW (a, b )
= __MHDSETH (a, b )
b = __MHDSETS (a )
b = __MHSETHIH (b, a )
b = __MHSETHIS (b, a )
b = __MHSETLOH (b, a )
b = __MHSETLOS (b, a )
b = __MHTOB (a )
__MMACHS ( , a, b )
__MMACHU ( , a, b )
__MMRDHS ( , a, b )
__MMRDHU ( , a, b )
__MMULHS ( , a, b )
__MMULHU ( , a, b )
__MMULXHS ( , a, b )
__MMULXHU ( , a, b )
b = __MNOT (a )
= __MOR (a, b )
= __MPACKH (a, b )
= __MQADDHSS (a, b )
= __MQADDHUS (a, b )
__MQCPXIS ( , a, b )
__MQCPXIU ( , a, b )
__MQCPXRS ( , a, b )
__MQCPXRU ( , a, b )
= __MQLCLRHS (a, b )
= __MQLMTHS (a, b )
__MQMACHS ( , a, b )

MCLRACCA
M op1 a,b,
M op2 a,b,
MCPLHI a,#b,
MCPLI a,#b,
MCPXIS a,b,
MCPXIU a,b,
MCPXRS a,b,
MCPXRU a,b,
MCUT a,b,
MCUTSS a,b,
MDADDACCS a,b
MDASACCS a,b
MDCUTSSI a,#b,
MDPACKH a,b,
MDROTLI a,#b,
MDSUBACCS a,b
MDUNPACKH a,b
MEXPDHD a,#b,
MEXPDHW a,#b,
MHDSETH a,#b,
MHDSETS #a,b
MHSETHIH #a,b
MHSETHIS #a,b
MHSETLOH #a,b
MHSETLOS #a,b
MHTOB a,b
MMACHS a,b,
MMACHU a,b,
MMRDHS a,b,
MMRDHU a,b,
MMULHS a,b,
MMULHU a,b,
MMULXHS a,b,
MMULXHU a,b,
MNOT a,b
MOR a,b,
MPACKH a,b,
MQADDHSS a,b,
MQADDHUS a,b,
MQCPXIS a,b,
MQCPXIU a,b,
MQCPXRS a,b,
MQCPXRU a,b,
MQLCLRHS a,b,
MQLMTHS a,b,
MQMACHS a,b,

Chapter 5: Extensions to the C Language Family

void __MQMACHU (a , uw2, uw2)

void __MQMACXHS (a , sw2, sw2)
void __MQMULHS (a , sw2, sw2)
void __MQMULHU (a , uw2, uw2)
void __MQMULXHS (a , sw2, sw2)
void __MQMULXHU (a , uw2, uw2)
sw2 __MQSATHS (sw2, sw2)
uw2 __MQSLLHI (uw2, int)
sw2 __MQSRAHI (sw2, int)
sw2 __MQSUBHSS (sw2, sw2)
uw2 __MQSUBHUS (uw2, uw2)
void __MQXMACHS (a , sw2, sw2)
void __MQXMACXHS (a , sw2, sw2)
uw1 __MRDACC (a )
uw1 __MRDACCG (a )
uw1 __MROTLI (uw1, onst)
uw1 __MROTRI (uw1, onst)
sw1 __MSATHS (sw1, sw1)
uw1 __MSATHU (uw1, uw1)
uw1 __MSLLHI (uw1, onst)
sw1 __MSRAHI (sw1, onst)
uw1 __MSRLHI (uw1, onst)
void __MSUBACCS (a , a )
sw1 __MSUBHSS (sw1, sw1)
uw1 __MSUBHUS (uw1, uw1)
void __MTRAP (void)
uw2 __MUNPACKH (uw1)
uw1 __MWCUT (uw2, uw1)
void __MWTACC (a , uw1)
void __MWTACCG (a , uw1)
uw1 __MXOR (uw1, uw1)

__MQMACHU ( , a, b )
__MQMACXHS ( , a, b )
__MQMULHS ( , a, b )
__MQMULHU ( , a, b )
__MQMULXHS ( , a, b )
__MQMULXHU ( , a, b )
= __MQSATHS (a, b )
= __MQSLLHI (a, b )
= __MQSRAHI (a, b )
= __MQSUBHSS (a, b )
= __MQSUBHUS (a, b )
__MQXMACHS ( , a, b )
__MQXMACXHS ( , a, b )
b = __MRDACC (a )
b = __MRDACCG (a )
= __MROTLI (a, b )
= __MROTRI (a, b )
= __MSATHS (a, b )
= __MSATHU (a, b )
= __MSLLHI (a, b )
= __MSRAHI (a, b )
= __MSRLHI (a, b )
__MSUBACCS (b, a )
= __MSUBHSS (a, b )
= __MSUBHUS (a, b )
__MTRAP ()
b = __MUNPACKH (a )
= __MWCUT (a, b )
__MWTACC (b, a )
__MWTACCG (b, a )
= __MXOR (a, b )

285

MQMACHU a,b,
MQMACXHS a,b,
MQMULHS a,b,
MQMULHU a,b,
MQMULXHS a,b,
MQMULXHU a,b,
MQSATHS a,b,
MQSLLHI a,b,
MQSRAHI a,b,
MQSUBHSS a,b,
MQSUBHUS a,b,
MQXMACHS a,b,
MQXMACXHS a,b,
MRDACC a,b
MRDACCG a,b
MROTLI a,#b,
MROTRI a,#b,
MSATHS a,b,
MSATHU a,b,
MSLLHI a,#b,
MSRAHI a,#b,
MSRLHI a,#b,
MSUBACCS a,b
MSUBHSS a,b,
MSUBHUS a,b,
MTRAP
MUNPACKH a,b
MWCUT a,b,
MWTACC a,b
MWTACCG a,b
MXOR a,b,

5.45.3.4 Other Built-in Fun tions

This se tion des ribes built-in fun tions that are not named after a spe i FR-V instru tion.
sw2 __IACCreadll (ia reg )

Return the full 64-bit value of IACC0. The reg argument is reserved for future
expansion and must be 0.

sw1 __IACCreadl (ia reg )

Return the value of IACC0H if reg is 0 and IACC0L if reg is 1. Other values
of reg are reje ted as invalid.

void __IACCsetll (ia reg, sw2 x )

Set the full 64-bit value of IACC0 to x. The reg argument is reserved for future
expansion and must be 0.

286

Using the GNU Compiler Colle tion (GCC)

void __IACCsetl (ia reg, sw1 x )

Set IACC0H to x if reg is 0 and IACC0L to x if reg is 1. Other values of reg

are reje ted as invalid.

void __data_prefet h0 ( onst void *x )

Use the d pl instru tion to load the ontents of address x into the data a he.
void __data_prefet h ( onst void *x )
Use the nldub instru tion to load the ontents of address x into the data a he.

The instru tion will be issued in slot I1.

5.45.4 X86 Built-in Fun tions

These built-in fun tions are available for the i386 and x86-64 family of omputers, depending
on the ommand-line swit hes used.
The following ma hine modes are available for use with MMX built-in fun tions (see
Se tion 5.42 [Ve tor Extensions, page 271): V2SI for a ve tor of two 32-bit integers, V4HI
for a ve tor of four 16-bit integers, and V8QI for a ve tor of eight 8-bit integers. Some of
the built-in fun tions operate on MMX registers as a whole 64-bit entity, these use DI as
their mode.
If 3Dnow extensions are enabled, V2SF is used as a mode for a ve tor of two 32-bit oating
point values.
If SSE extensions are enabled, V4SF is used for a ve tor of four 32-bit oating point
values. Some instru tions use a ve tor of four 32-bit integers, these use V4SI. Finally, some
instru tions operate on an entire ve tor register, interpreting it as a 128-bit integer, these
use mode TI.
The following built-in fun tions are made available by `-mmmx'. All of them generate the
ma hine instru tion that is part of the name.
v8qi __builtin_ia32_paddb (v8qi, v8qi)
v4hi __builtin_ia32_paddw (v4hi, v4hi)
v2si __builtin_ia32_paddd (v2si, v2si)
v8qi __builtin_ia32_psubb (v8qi, v8qi)
v4hi __builtin_ia32_psubw (v4hi, v4hi)
v2si __builtin_ia32_psubd (v2si, v2si)
v8qi __builtin_ia32_paddsb (v8qi, v8qi)
v4hi __builtin_ia32_paddsw (v4hi, v4hi)
v8qi __builtin_ia32_psubsb (v8qi, v8qi)
v4hi __builtin_ia32_psubsw (v4hi, v4hi)
v8qi __builtin_ia32_paddusb (v8qi, v8qi)
v4hi __builtin_ia32_paddusw (v4hi, v4hi)
v8qi __builtin_ia32_psubusb (v8qi, v8qi)
v4hi __builtin_ia32_psubusw (v4hi, v4hi)
v4hi __builtin_ia32_pmullw (v4hi, v4hi)
v4hi __builtin_ia32_pmulhw (v4hi, v4hi)
di __builtin_ia32_pand (di, di)
di __builtin_ia32_pandn (di,di)
di __builtin_ia32_por (di, di)
di __builtin_ia32_pxor (di, di)
v8qi __builtin_ia32_p mpeqb (v8qi, v8qi)
v4hi __builtin_ia32_p mpeqw (v4hi, v4hi)
v2si __builtin_ia32_p mpeqd (v2si, v2si)
v8qi __builtin_ia32_p mpgtb (v8qi, v8qi)
v4hi __builtin_ia32_p mpgtw (v4hi, v4hi)

Chapter 5: Extensions to the C Language Family

v2si
v8qi
v4hi
v2si
v8qi
v4hi
v2si
v8qi
v4hi
v8qi

287

__builtin_ia32_p mpgtd (v2si, v2si)

__builtin_ia32_punp khbw (v8qi, v8qi)
__builtin_ia32_punp khwd (v4hi, v4hi)
__builtin_ia32_punp khdq (v2si, v2si)
__builtin_ia32_punp klbw (v8qi, v8qi)
__builtin_ia32_punp klwd (v4hi, v4hi)
__builtin_ia32_punp kldq (v2si, v2si)
__builtin_ia32_pa ksswb (v4hi, v4hi)
__builtin_ia32_pa kssdw (v2si, v2si)
__builtin_ia32_pa kuswb (v4hi, v4hi)

The following built-in fun tions are made available either with `-msse', or with a ombination of `-m3dnow' and `-mar h=athlon'. All of them generate the ma hine instru tion
that is part of the name.
v4hi __builtin_ia32_pmulhuw (v4hi, v4hi)
v8qi __builtin_ia32_pavgb (v8qi, v8qi)
v4hi __builtin_ia32_pavgw (v4hi, v4hi)
v4hi __builtin_ia32_psadbw (v8qi, v8qi)
v8qi __builtin_ia32_pmaxub (v8qi, v8qi)
v4hi __builtin_ia32_pmaxsw (v4hi, v4hi)
v8qi __builtin_ia32_pminub (v8qi, v8qi)
v4hi __builtin_ia32_pminsw (v4hi, v4hi)
int __builtin_ia32_pextrw (v4hi, int)
v4hi __builtin_ia32_pinsrw (v4hi, int, int)
int __builtin_ia32_pmovmskb (v8qi)
void __builtin_ia32_maskmovq (v8qi, v8qi, har *)
void __builtin_ia32_movntq (di *, di)
void __builtin_ia32_sfen e (void)

The following built-in fun tions are available when `-msse' is used. All of them generate
the ma hine instru tion that is part of the name.
int __builtin_ia32_ omieq (v4sf, v4sf)
int __builtin_ia32_ omineq (v4sf, v4sf)
int __builtin_ia32_ omilt (v4sf, v4sf)
int __builtin_ia32_ omile (v4sf, v4sf)
int __builtin_ia32_ omigt (v4sf, v4sf)
int __builtin_ia32_ omige (v4sf, v4sf)
int __builtin_ia32_u omieq (v4sf, v4sf)
int __builtin_ia32_u omineq (v4sf, v4sf)
int __builtin_ia32_u omilt (v4sf, v4sf)
int __builtin_ia32_u omile (v4sf, v4sf)
int __builtin_ia32_u omigt (v4sf, v4sf)
int __builtin_ia32_u omige (v4sf, v4sf)
v4sf __builtin_ia32_addps (v4sf, v4sf)
v4sf __builtin_ia32_subps (v4sf, v4sf)
v4sf __builtin_ia32_mulps (v4sf, v4sf)
v4sf __builtin_ia32_divps (v4sf, v4sf)
v4sf __builtin_ia32_addss (v4sf, v4sf)
v4sf __builtin_ia32_subss (v4sf, v4sf)
v4sf __builtin_ia32_mulss (v4sf, v4sf)
v4sf __builtin_ia32_divss (v4sf, v4sf)
v4si __builtin_ia32_ mpeqps (v4sf, v4sf)
v4si __builtin_ia32_ mpltps (v4sf, v4sf)
v4si __builtin_ia32_ mpleps (v4sf, v4sf)
v4si __builtin_ia32_ mpgtps (v4sf, v4sf)
v4si __builtin_ia32_ mpgeps (v4sf, v4sf)
v4si __builtin_ia32_ mpunordps (v4sf, v4sf)
v4si __builtin_ia32_ mpneqps (v4sf, v4sf)

288

Using the GNU Compiler Colle tion (GCC)

v4si __builtin_ia32_ mpnltps (v4sf, v4sf)

v4si __builtin_ia32_ mpnleps (v4sf, v4sf)
v4si __builtin_ia32_ mpngtps (v4sf, v4sf)
v4si __builtin_ia32_ mpngeps (v4sf, v4sf)
v4si __builtin_ia32_ mpordps (v4sf, v4sf)
v4si __builtin_ia32_ mpeqss (v4sf, v4sf)
v4si __builtin_ia32_ mpltss (v4sf, v4sf)
v4si __builtin_ia32_ mpless (v4sf, v4sf)
v4si __builtin_ia32_ mpunordss (v4sf, v4sf)
v4si __builtin_ia32_ mpneqss (v4sf, v4sf)
v4si __builtin_ia32_ mpnlts (v4sf, v4sf)
v4si __builtin_ia32_ mpnless (v4sf, v4sf)
v4si __builtin_ia32_ mpordss (v4sf, v4sf)
v4sf __builtin_ia32_maxps (v4sf, v4sf)
v4sf __builtin_ia32_maxss (v4sf, v4sf)
v4sf __builtin_ia32_minps (v4sf, v4sf)
v4sf __builtin_ia32_minss (v4sf, v4sf)
v4sf __builtin_ia32_andps (v4sf, v4sf)
v4sf __builtin_ia32_andnps (v4sf, v4sf)
v4sf __builtin_ia32_orps (v4sf, v4sf)
v4sf __builtin_ia32_xorps (v4sf, v4sf)
v4sf __builtin_ia32_movss (v4sf, v4sf)
v4sf __builtin_ia32_movhlps (v4sf, v4sf)
v4sf __builtin_ia32_movlhps (v4sf, v4sf)
v4sf __builtin_ia32_unp khps (v4sf, v4sf)
v4sf __builtin_ia32_unp klps (v4sf, v4sf)
v4sf __builtin_ia32_ vtpi2ps (v4sf, v2si)
v4sf __builtin_ia32_ vtsi2ss (v4sf, int)
v2si __builtin_ia32_ vtps2pi (v4sf)
int __builtin_ia32_ vtss2si (v4sf)
v2si __builtin_ia32_ vttps2pi (v4sf)
int __builtin_ia32_ vttss2si (v4sf)
v4sf __builtin_ia32_r pps (v4sf)
v4sf __builtin_ia32_rsqrtps (v4sf)
v4sf __builtin_ia32_sqrtps (v4sf)
v4sf __builtin_ia32_r pss (v4sf)
v4sf __builtin_ia32_rsqrtss (v4sf)
v4sf __builtin_ia32_sqrtss (v4sf)
v4sf __builtin_ia32_shufps (v4sf, v4sf, int)
void __builtin_ia32_movntps (float *, v4sf)
int __builtin_ia32_movmskps (v4sf)

The following built-in fun tions are available when `-msse' is used.
v4sf __builtin_ia32_loadaps (float *)
Generates the movaps ma hine instru tion as a load from memory.
void __builtin_ia32_storeaps (float *, v4sf)
Generates the movaps ma hine instru tion as a store to memory.
v4sf __builtin_ia32_loadups (float *)
Generates the movups ma hine instru tion as a load from memory.
void __builtin_ia32_storeups (float *, v4sf)
Generates the movups ma hine instru tion as a store to memory.
v4sf __builtin_ia32_loadsss (float *)
Generates the movss ma hine instru tion as a load from memory.

Chapter 5: Extensions to the C Language Family

289

void __builtin_ia32_storess (float *, v4sf)

Generates the movss ma hine instru tion as a store to memory.
v4sf __builtin_ia32_loadhps (v4sf, v2si *)
Generates the movhps ma hine instru tion as a load from memory.
v4sf __builtin_ia32_loadlps (v4sf, v2si *)
Generates the movlps ma hine instru tion as a load from memory
void __builtin_ia32_storehps (v4sf, v2si *)
Generates the movhps ma hine instru tion as a store to memory.
void __builtin_ia32_storelps (v4sf, v2si *)
Generates the movlps ma hine instru tion as a store to memory.

The following built-in fun tions are available when `-msse3' is used. All of them generate
the ma hine instru tion that is part of the name.
v2df __builtin_ia32_addsubpd (v2df, v2df)
v2df __builtin_ia32_addsubps (v2df, v2df)
v2df __builtin_ia32_haddpd (v2df, v2df)
v2df __builtin_ia32_haddps (v2df, v2df)
v2df __builtin_ia32_hsubpd (v2df, v2df)
v2df __builtin_ia32_hsubps (v2df, v2df)
v16qi __builtin_ia32_lddqu ( har onst *)
void __builtin_ia32_monitor (void *, unsigned int, unsigned int)
v2df __builtin_ia32_movddup (v2df)
v4sf __builtin_ia32_movshdup (v4sf)
v4sf __builtin_ia32_movsldup (v4sf)
void __builtin_ia32_mwait (unsigned int, unsigned int)

The following built-in fun tions are available when `-msse3' is used.
v2df __builtin_ia32_loadddup (double onst *)
Generates the movddup ma hine instru tion as a load from memory.

The following built-in fun tions are available when `-m3dnow' is used. All of them generate
the ma hine instru tion that is part of the name.
void
v8qi
v2si
v2sf
v2sf
v2si
v2si
v2si
v2sf
v2sf
v2sf
v2sf
v2sf
v2sf
v2sf
v2sf
v2sf
v2sf
v2sf
v4hi

__builtin_ia32_femms (void)
__builtin_ia32_pavgusb (v8qi, v8qi)
__builtin_ia32_pf2id (v2sf)
__builtin_ia32_pfa (v2sf, v2sf)
__builtin_ia32_pfadd (v2sf, v2sf)
__builtin_ia32_pf mpeq (v2sf, v2sf)
__builtin_ia32_pf mpge (v2sf, v2sf)
__builtin_ia32_pf mpgt (v2sf, v2sf)
__builtin_ia32_pfmax (v2sf, v2sf)
__builtin_ia32_pfmin (v2sf, v2sf)
__builtin_ia32_pfmul (v2sf, v2sf)
__builtin_ia32_pfr p (v2sf)
__builtin_ia32_pfr pit1 (v2sf, v2sf)
__builtin_ia32_pfr pit2 (v2sf, v2sf)
__builtin_ia32_pfrsqrt (v2sf)
__builtin_ia32_pfrsqrtit1 (v2sf, v2sf)
__builtin_ia32_pfsub (v2sf, v2sf)
__builtin_ia32_pfsubr (v2sf, v2sf)
__builtin_ia32_pi2fd (v2si)
__builtin_ia32_pmulhrw (v4hi, v4hi)

290

Using the GNU Compiler Colle tion (GCC)

The following built-in fun tions are available when both `-m3dnow' and `-mar h=athlon'
are used. All of them generate the ma hine instru tion that is part of the name.
v2si
v2sf
v2sf
v2sf
v2sf
v2si

__builtin_ia32_pf2iw (v2sf)
__builtin_ia32_pfna (v2sf, v2sf)
__builtin_ia32_pfpna (v2sf, v2sf)
__builtin_ia32_pi2fw (v2si)
__builtin_ia32_pswapdsf (v2sf)
__builtin_ia32_pswapdsi (v2si)

5.45.5 MIPS Paired-Single Support

The MIPS64 ar hite ture in ludes a number of instru tions that operate on pairs of singlepre ision oating-point values. Ea h pair is pa ked into a 64-bit oating-point register, with
one element being designated the \upper half" and the other being designated the \lower
half".
GCC supports paired-single operations using both the generi ve tor extensions (see Se tion 5.42 [Ve tor Extensions, page 271) and a olle tion of MIPS-spe i built-in fun tions.
Both kinds of support are enabled by the `-mpaired-single' ommand-line option.
The ve tor type asso iated with paired-single values is usually alled v2sf. It an be
dened in C as follows:
typedef float v2sf __attribute__ ((ve tor_size (8)));

v2sf values are initialized in the same way as aggregates. For example:
v2sf a = {1.5, 9.1};
v2sf b;
float e, f;
b = (v2sf) {e, f};

Note: The CPU's endianness determines whi h value is stored in the upper half of a
register and whi h value is stored in the lower half. On little-endian targets, the rst value
is the lower one and the se ond value is the upper one. The opposite order applies to
big-endian targets. For example, the ode above will set the lower half of a to 1.5 on
little-endian targets and 9.1 on big-endian targets.

5.45.5.1 Paired-Single Arithmeti

The table below lists the v2sf operations for whi h hardware support exists. a, b and are
v2sf values and x is an integral value.
C ode
MIPS instru tion
a+b
a-b
-a
a*b
a*b+
a*b-
-(a * b + )
-(a * b - )
x?a:b

add.ps
sub.ps
neg.ps
mul.ps
madd.ps
msub.ps
nmadd.ps
nmsub.ps
movn.ps/movz.ps

Note that the multiply-a umulate instru tions an be disabled using the ommand-line
option -mno-fused-madd.

Chapter 5: Extensions to the C Language Family

291

5.45.5.2 Paired-Single Built-in Fun tions

The following paired-single fun tions map dire tly to a parti ular MIPS instru tion. Please
refer to the ar hite ture spe i ation for details on what ea h instru tion does.
v2sf __builtin_mips_pll_ps (v2sf, v2sf)
Pair lower lower (pll.ps).
v2sf __builtin_mips_pul_ps (v2sf, v2sf)
Pair upper lower (pul.ps).
v2sf __builtin_mips_plu_ps (v2sf, v2sf)
Pair lower upper (plu.ps).
v2sf __builtin_mips_puu_ps (v2sf, v2sf)
Pair upper upper (puu.ps).
v2sf __builtin_mips_ vt_ps_s (float, float)
Convert pair to paired single ( vt.ps.s).
float __builtin_mips_ vt_s_pl (v2sf)
Convert pair lower to single ( vt.s.pl).
float __builtin_mips_ vt_s_pu (v2sf)
Convert pair upper to single ( vt.s.pu).
v2sf __builtin_mips_abs_ps (v2sf)
Absolute value (abs.ps).
v2sf __builtin_mips_alnv_ps (v2sf, v2sf, int)
Align variable (alnv.ps).

Note: The value of the third parameter must be 0 or 4 modulo 8, otherwise the
result will be unpredi table. Please read the instru tion des ription for details.

The following multi-instru tion fun tions are also available. In ea h ase, ond an be
any of the 16 oating-point onditions: f, un, eq, ueq, olt, ult, ole, ule, sf, ngle, seq,
ngl, lt, nge, le or ngt.
v2sf __builtin_mips_movt_ _ ond _ps (v2sf a, v2sf b, v2sf , v2sf d )
v2sf __builtin_mips_movf_ _ ond _ps (v2sf a, v2sf b, v2sf , v2sf d )

Conditional move based on oating point omparison ( . ond.ps,

movt.ps/movf.ps).
The movt fun tions return the value x omputed by:
. ond.ps ,a,b
mov.ps x,
movt.ps x,d,

The movf fun tions are similar but use movf.ps instead of movt.ps.
int __builtin_mips_upper_ _ ond _ps (v2sf a, v2sf b )
int __builtin_mips_lower_ _ ond _ps (v2sf a, v2sf b )
Comparison of two paired-single values ( . ond.ps, b 1t/b 1f).
These fun tions ompare a and b using . ond.ps and return either the upper

or lower half of the result. For example:

292

Using the GNU Compiler Colle tion (GCC)

v2sf a, b;
if (__builtin_mips_upper_ _eq_ps (a, b))
upper_halves_are_equal ();
else
upper_halves_are_unequal ();
if (__builtin_mips_lower_ _eq_ps (a, b))
lower_halves_are_equal ();
else
lower_halves_are_unequal ();

5.45.5.3 MIPS-3D Built-in Fun tions

The MIPS-3D Appli ation-Spe i Extension (ASE) in ludes additional paired-single instru tions that are designed to improve the performan e of 3D graphi s operations. Support
for these instru tions is ontrolled by the `-mips3d' ommand-line option.
The fun tions listed below map dire tly to a parti ular MIPS-3D instru tion. Please refer
to the ar hite ture spe i ation for more details on what ea h instru tion does.
v2sf __builtin_mips_addr_ps (v2sf, v2sf)
Redu tion add (addr.ps).
v2sf __builtin_mips_mulr_ps (v2sf, v2sf)
Redu tion multiply (mulr.ps).
v2sf __builtin_mips_ vt_pw_ps (v2sf)

Convert paired single to paired word ( vt.pw.ps).

v2sf __builtin_mips_ vt_ps_pw (v2sf)

Convert paired word to paired single ( vt.ps.pw).

float __builtin_mips_re ip1_s (float)

double __builtin_mips_re ip1_d (double)
v2sf __builtin_mips_re ip1_ps (v2sf)

Redu ed pre ision re ipro al (sequen e step 1) (re ip1.fmt ).

float __builtin_mips_re ip2_s (float, float)

double __builtin_mips_re ip2_d (double, double)
v2sf __builtin_mips_re ip2_ps (v2sf, v2sf)

Redu ed pre ision re ipro al (sequen e step 2) (re ip2.fmt ).

float __builtin_mips_rsqrt1_s (float)

double __builtin_mips_rsqrt1_d (double)
v2sf __builtin_mips_rsqrt1_ps (v2sf)

Redu ed pre ision re ipro al square root (sequen e step 1) (rsqrt1.fmt ).

float __builtin_mips_rsqrt2_s (float, float)

double __builtin_mips_rsqrt2_d (double, double)
v2sf __builtin_mips_rsqrt2_ps (v2sf, v2sf)

Redu ed pre ision re ipro al square root (sequen e step 2) (rsqrt2.fmt ).

The following multi-instru tion fun tions are also available. In ea h ase, ond an be
any of the 16 oating-point onditions: f, un, eq, ueq, olt, ult, ole, ule, sf, ngle, seq,
ngl, lt, nge, le or ngt.

Chapter 5: Extensions to the C Language Family

293

int __builtin_mips_ abs_ ond _s (float a, float b )

int __builtin_mips_ abs_ ond _d (double a, double b )
Absolute omparison of two s alar values ( abs. ond.fmt , b 1t/b 1f).
These fun tions ompare a and b using abs. ond.s or abs. ond.d and re-

turn the result as a boolean value. For example:

float a, b;
if (__builtin_mips_ abs_eq_s (a, b))
true ();
else
false ();

int __builtin_mips_upper_ abs_ ond _ps (v2sf a, v2sf b )

int __builtin_mips_lower_ abs_ ond _ps (v2sf a, v2sf b )
Absolute omparison of two paired-single values ( abs. ond.ps, b 1t/b 1f).
These fun tions ompare a and b using abs. ond.ps and return either the

upper or lower half of the result. For example:

v2sf a, b;
if (__builtin_mips_upper_ abs_eq_ps (a, b))
upper_halves_are_equal ();
else
upper_halves_are_unequal ();
if (__builtin_mips_lower_ abs_eq_ps (a, b))
lower_halves_are_equal ();
else
lower_halves_are_unequal ();

v2sf __builtin_mips_movt_ abs_ ond _ps (v2sf a, v2sf b, v2sf , v2sf d )

v2sf __builtin_mips_movf_ abs_ ond _ps (v2sf a, v2sf b, v2sf , v2sf d )
Conditional move based on absolute omparison ( abs. ond.ps,
movt.ps/movf.ps).
The movt fun tions return the value x omputed by:
abs. ond.ps ,a,b
mov.ps x,
movt.ps x,d,

The movf fun tions are similar but use movf.ps instead of movt.ps.
int
int
int
int

__builtin_mips_any_ _ ond _ps (v2sf a, v2sf b )

__builtin_mips_all_ _ ond _ps (v2sf a, v2sf b )
__builtin_mips_any_ abs_ ond _ps (v2sf a, v2sf b )
__builtin_mips_all_ abs_ ond _ps (v2sf a, v2sf b )

Comparison of two paired-single values ( . ond.ps/ abs. ond.ps,

b 1any2t/b 1any2f).
These fun tions ompare a and b using . ond.ps or abs. ond.ps. The any
forms return true if either result is true and the all forms return true if both
results are true. For example:
v2sf a, b;
if (__builtin_mips_any_ _eq_ps (a, b))
one_is_true ();
else
both_are_false ();

294

Using the GNU Compiler Colle tion (GCC)

if (__builtin_mips_all_ _eq_ps (a, b))

both_are_true ();
else
one_is_false ();

int
int
int
int

__builtin_mips_any_ _ ond _4s (v2sf a, v2sf b, v2sf , v2sf d )

__builtin_mips_all_ _ ond _4s (v2sf a, v2sf b, v2sf , v2sf d )
__builtin_mips_any_ abs_ ond _4s (v2sf a, v2sf b, v2sf , v2sf d )
__builtin_mips_all_ abs_ ond _4s (v2sf a, v2sf b, v2sf , v2sf d )
Comparison of four paired-single values ( . ond.ps/ abs. ond.ps,
b 1any4t/b 1any4f).
These fun tions use . ond.ps or abs. ond.ps to ompare a with b and to
ompare with d. The any forms return true if any of the four results are true
and the all forms return true if all four results are true. For example:
v2sf a, b, , d;
if (__builtin_mips_any_ _eq_4s (a, b, , d))
some_are_true ();
else
all_are_false ();
if (__builtin_mips_all_ _eq_4s (a, b, , d))
all_are_true ();
else
some_are_false ();

5.45.6 PowerPC AltiVe Built-in Fun tions

GCC provides an interfa e for the PowerPC family of pro essors to a ess the AltiVe
operations des ribed in Motorola's AltiVe Programming Interfa e Manual. The interfa e
is made available by in luding <altive .h> and using `-maltive ' and `-mabi=altive '.
The interfa e supports the following ve tor types.
ve tor unsigned har
ve tor signed har
ve tor bool har

ve tor
ve tor
ve tor
ve tor

unsigned short
signed short
bool short
pixel

ve tor
ve tor
ve tor
ve tor

unsigned int
signed int
bool int
float

GCC's implementation of the high-level language interfa e available from C and C++ ode
diers from Motorola's do umentation in several ways.
 A ve tor onstant is a list of onstant expressions within urly bra es.
 A ve tor initializer requires no ast if the ve tor onstant is of the same type as the
variable it is initializing.
 If signed or unsigned is omitted, the signedness of the ve tor type is the default
signedness of the base type. The default varies depending on the operating system, so
a portable program should always spe ify the signedness.

Chapter 5: Extensions to the C Language Family





295

Compiling with `-maltive ' adds keywords __ve tor, __pixel, and __bool. Ma ros
`ve tor', pixel, and bool are dened in <altive .h> and an be undened.
GCC allows using a typedef name as the type spe ier for a ve tor type.
For C, overloaded fun tions are implemented with ma ros so the following does not
work:
ve _add ((ve tor signed int){1, 2, 3, 4}, foo);

Sin e ve _add is a ma ro, the ve tor onstant in the example is treated as four separate
arguments. Wrap the entire argument in parentheses for this to work.
Note: Only the <altive .h> interfa e is supported. Internally, GCC uses built-in fun tions to a hieve the fun tionality in the aforementioned header le, but they are not supported and are subje t to hange without noti e.
The following interfa es are supported for the generi and spe i AltiVe operations
and the AltiVe predi ates. In ases where there is a dire t mapping between generi and
spe i operations, only the generi names are shown here, although the spe i operations
an also be used.
Arguments that are do umented as onst int require literal integral values within the
range required for that operation.
ve tor
ve tor
ve tor
ve tor

signed har ve _abs (ve tor signed har);

signed short ve _abs (ve tor signed short);
signed int ve _abs (ve tor signed int);
float ve _abs (ve tor float);

ve tor signed har ve _abss (ve tor signed har);

ve tor signed short ve _abss (ve tor signed short);
ve tor signed int ve _abss (ve tor signed int);
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor

signed har ve _add (ve tor bool har, ve tor signed har);
signed har ve _add (ve tor signed har, ve tor bool har);
signed har ve _add (ve tor signed har, ve tor signed har);
unsigned har ve _add (ve tor bool har, ve tor unsigned har);
unsigned har ve _add (ve tor unsigned har, ve tor bool har);
unsigned har ve _add (ve tor unsigned har,
ve tor unsigned har);
signed short ve _add (ve tor bool short, ve tor signed short);
signed short ve _add (ve tor signed short, ve tor bool short);
signed short ve _add (ve tor signed short, ve tor signed short);
unsigned short ve _add (ve tor bool short,
ve tor unsigned short);
unsigned short ve _add (ve tor unsigned short,
ve tor bool short);
unsigned short ve _add (ve tor unsigned short,
ve tor unsigned short);
signed int ve _add (ve tor bool int, ve tor signed int);
signed int ve _add (ve tor signed int, ve tor bool int);
signed int ve _add (ve tor signed int, ve tor signed int);
unsigned int ve _add (ve tor bool int, ve tor unsigned int);
unsigned int ve _add (ve tor unsigned int, ve tor bool int);
unsigned int ve _add (ve tor unsigned int, ve tor unsigned int);
float ve _add (ve tor float, ve tor float);

ve tor float ve _vaddfp (ve tor float, ve tor float);

296

Using the GNU Compiler Colle tion (GCC)

ve tor
ve tor
ve tor
ve tor
ve tor
ve tor

signed int ve _vadduwm (ve tor bool int, ve tor signed int);
signed int ve _vadduwm (ve tor signed int, ve tor bool int);
signed int ve _vadduwm (ve tor signed int, ve tor signed int);
unsigned int ve _vadduwm (ve tor bool int, ve tor unsigned int);
unsigned int ve _vadduwm (ve tor unsigned int, ve tor bool int);
unsigned int ve _vadduwm (ve tor unsigned int,
ve tor unsigned int);

ve tor signed short ve _vadduhm (ve tor bool short,

ve tor signed short);
ve tor signed short ve _vadduhm (ve tor signed short,
ve tor bool short);
ve tor signed short ve _vadduhm (ve tor signed short,
ve tor signed short);
ve tor unsigned short ve _vadduhm (ve tor bool short,
ve tor unsigned short);
ve tor unsigned short ve _vadduhm (ve tor unsigned short,
ve tor bool short);
ve tor unsigned short ve _vadduhm (ve tor unsigned short,
ve tor unsigned short);
ve tor
ve tor
ve tor
ve tor

signed har ve _vaddubm (ve tor bool har, ve tor signed har);
signed har ve _vaddubm (ve tor signed har, ve tor bool har);
signed har ve _vaddubm (ve tor signed har, ve tor signed har);
unsigned har ve _vaddubm (ve tor bool har,
ve tor unsigned har);
ve tor unsigned har ve _vaddubm (ve tor unsigned har,
ve tor bool har);
ve tor unsigned har ve _vaddubm (ve tor unsigned har,
ve tor unsigned har);
ve tor unsigned int ve _add (ve tor unsigned int, ve tor unsigned int);
ve tor unsigned har ve _adds (ve tor bool har, ve tor unsigned har);
ve tor unsigned har ve _adds (ve tor unsigned har, ve tor bool har);
ve tor unsigned har ve _adds (ve tor unsigned har,
ve tor unsigned har);
ve tor signed har ve _adds (ve tor bool har, ve tor signed har);
ve tor signed har ve _adds (ve tor signed har, ve tor bool har);
ve tor signed har ve _adds (ve tor signed har, ve tor signed har);
ve tor unsigned short ve _adds (ve tor bool short,
ve tor unsigned short);
ve tor unsigned short ve _adds (ve tor unsigned short,
ve tor bool short);
ve tor unsigned short ve _adds (ve tor unsigned short,
ve tor unsigned short);
ve tor signed short ve _adds (ve tor bool short, ve tor signed short);
ve tor signed short ve _adds (ve tor signed short, ve tor bool short);
ve tor signed short ve _adds (ve tor signed short, ve tor signed short);
ve tor unsigned int ve _adds (ve tor bool int, ve tor unsigned int);
ve tor unsigned int ve _adds (ve tor unsigned int, ve tor bool int);
ve tor unsigned int ve _adds (ve tor unsigned int, ve tor unsigned int);
ve tor signed int ve _adds (ve tor bool int, ve tor signed int);
ve tor signed int ve _adds (ve tor signed int, ve tor bool int);
ve tor signed int ve _adds (ve tor signed int, ve tor signed int);
ve tor signed int ve _vaddsws (ve tor bool int, ve tor signed int);
ve tor signed int ve _vaddsws (ve tor signed int, ve tor bool int);

Chapter 5: Extensions to the C Language Family

ve tor signed int ve _vaddsws (ve tor signed int, ve tor signed int);
ve tor unsigned int ve _vadduws (ve tor bool int, ve tor unsigned int);
ve tor unsigned int ve _vadduws (ve tor unsigned int, ve tor bool int);
ve tor unsigned int ve _vadduws (ve tor unsigned int,
ve tor unsigned int);
ve tor signed short ve _vaddshs (ve tor
ve tor
ve tor signed short ve _vaddshs (ve tor
ve tor
ve tor signed short ve _vaddshs (ve tor
ve tor

bool short,
signed short);
signed short,
bool short);
signed short,
signed short);

ve tor unsigned short ve _vadduhs (ve tor

ve tor
ve tor unsigned short ve _vadduhs (ve tor
ve tor
ve tor unsigned short ve _vadduhs (ve tor
ve tor

bool short,
unsigned short);
unsigned short,
bool short);
unsigned short,
unsigned short);

ve tor signed har ve _vaddsbs (ve tor bool har, ve tor signed har);
ve tor signed har ve _vaddsbs (ve tor signed har, ve tor bool har);
ve tor signed har ve _vaddsbs (ve tor signed har, ve tor signed har);
ve tor unsigned har ve _vaddubs (ve tor
ve tor
ve tor unsigned har ve _vaddubs (ve tor
ve tor
ve tor unsigned har ve _vaddubs (ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor

bool har,
unsigned har);
unsigned har,
bool har);
unsigned har,
unsigned har);

float ve _and (ve tor float, ve tor float);

float ve _and (ve tor float, ve tor bool int);
float ve _and (ve tor bool int, ve tor float);
bool int ve _and (ve tor bool int, ve tor bool int);
signed int ve _and (ve tor bool int, ve tor signed int);
signed int ve _and (ve tor signed int, ve tor bool int);
signed int ve _and (ve tor signed int, ve tor signed int);
unsigned int ve _and (ve tor bool int, ve tor unsigned int);
unsigned int ve _and (ve tor unsigned int, ve tor bool int);
unsigned int ve _and (ve tor unsigned int, ve tor unsigned int);
bool short ve _and (ve tor bool short, ve tor bool short);
signed short ve _and (ve tor bool short, ve tor signed short);
signed short ve _and (ve tor signed short, ve tor bool short);
signed short ve _and (ve tor signed short, ve tor signed short);
unsigned short ve _and (ve tor bool short,
ve tor unsigned short);
unsigned short ve _and (ve tor unsigned short,
ve tor bool short);
unsigned short ve _and (ve tor unsigned short,
ve tor unsigned short);
signed har ve _and (ve tor bool har, ve tor signed har);
bool har ve _and (ve tor bool har, ve tor bool har);
signed har ve _and (ve tor signed har, ve tor bool har);
signed har ve _and (ve tor signed har, ve tor signed har);
unsigned har ve _and (ve tor bool har, ve tor unsigned har);
unsigned har ve _and (ve tor unsigned har, ve tor bool har);

297

298

Using the GNU Compiler Colle tion (GCC)

ve tor unsigned har ve _and (ve tor unsigned har,

ve tor unsigned har);
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor

float ve _and (ve tor float, ve tor float);

float ve _and (ve tor float, ve tor bool int);
float ve _and (ve tor bool int, ve tor float);
bool int ve _and (ve tor bool int, ve tor bool int);
signed int ve _and (ve tor bool int, ve tor signed int);
signed int ve _and (ve tor signed int, ve tor bool int);
signed int ve _and (ve tor signed int, ve tor signed int);
unsigned int ve _and (ve tor bool int, ve tor unsigned int);
unsigned int ve _and (ve tor unsigned int, ve tor bool int);
unsigned int ve _and (ve tor unsigned int, ve tor unsigned int);
bool short ve _and (ve tor bool short, ve tor bool short);
signed short ve _and (ve tor bool short, ve tor signed short);
signed short ve _and (ve tor signed short, ve tor bool short);
signed short ve _and (ve tor signed short, ve tor signed short);
unsigned short ve _and (ve tor bool short,
ve tor unsigned short);
unsigned short ve _and (ve tor unsigned short,
ve tor bool short);
unsigned short ve _and (ve tor unsigned short,
ve tor unsigned short);
signed har ve _and (ve tor bool har, ve tor signed har);
bool har ve _and (ve tor bool har, ve tor bool har);
signed har ve _and (ve tor signed har, ve tor bool har);
signed har ve _and (ve tor signed har, ve tor signed har);
unsigned har ve _and (ve tor bool har, ve tor unsigned har);
unsigned har ve _and (ve tor unsigned har, ve tor bool har);
unsigned har ve _and (ve tor unsigned har,
ve tor unsigned har);

ve tor unsigned har ve _avg (ve tor unsigned har,

ve tor unsigned har);
ve tor signed har ve _avg (ve tor signed har, ve tor signed har);
ve tor unsigned short ve _avg (ve tor unsigned short,
ve tor unsigned short);
ve tor signed short ve _avg (ve tor signed short, ve tor signed short);
ve tor unsigned int ve _avg (ve tor unsigned int, ve tor unsigned int);
ve tor signed int ve _avg (ve tor signed int, ve tor signed int);
ve tor signed int ve _vavgsw (ve tor signed int, ve tor signed int);
ve tor unsigned int ve _vavguw (ve tor unsigned int,
ve tor unsigned int);
ve tor signed short ve _vavgsh (ve tor signed short,
ve tor signed short);
ve tor unsigned short ve _vavguh (ve tor unsigned short,
ve tor unsigned short);
ve tor signed har ve _vavgsb (ve tor signed har, ve tor signed har);
ve tor unsigned har ve _vavgub (ve tor unsigned har,
ve tor unsigned har);
ve tor float ve _ eil (ve tor float);

Chapter 5: Extensions to the C Language Family

ve tor signed int ve _ mpb (ve tor float, ve tor float);

ve tor
ve tor
ve tor
ve tor

bool
bool
bool
bool

har ve _ mpeq (ve tor signed har, ve tor signed har);

har ve _ mpeq (ve tor unsigned har, ve tor unsigned har);
short ve _ mpeq (ve tor signed short, ve tor signed short);
short ve _ mpeq (ve tor unsigned short,
ve tor unsigned short);
ve tor bool int ve _ mpeq (ve tor signed int, ve tor signed int);
ve tor bool int ve _ mpeq (ve tor unsigned int, ve tor unsigned int);
ve tor bool int ve _ mpeq (ve tor float, ve tor float);
ve tor bool int ve _v mpeqfp (ve tor float, ve tor float);
ve tor bool int ve _v mpequw (ve tor signed int, ve tor signed int);
ve tor bool int ve _v mpequw (ve tor unsigned int, ve tor unsigned int);
ve tor bool short ve _v mpequh (ve tor
ve tor
ve tor bool short ve _v mpequh (ve tor
ve tor

signed short,
signed short);
unsigned short,
unsigned short);

ve tor bool har ve _v mpequb (ve tor signed har, ve tor signed har);
ve tor bool har ve _v mpequb (ve tor unsigned har,
ve tor unsigned har);
ve tor bool int ve _ mpge (ve tor float, ve tor float);
ve tor bool har ve _ mpgt (ve tor unsigned har, ve tor unsigned har);
ve tor bool har ve _ mpgt (ve tor signed har, ve tor signed har);
ve tor bool short ve _ mpgt (ve tor unsigned short,
ve tor unsigned short);
ve tor bool short ve _ mpgt (ve tor signed short, ve tor signed short);
ve tor bool int ve _ mpgt (ve tor unsigned int, ve tor unsigned int);
ve tor bool int ve _ mpgt (ve tor signed int, ve tor signed int);
ve tor bool int ve _ mpgt (ve tor float, ve tor float);
ve tor bool int ve _v mpgtfp (ve tor float, ve tor float);
ve tor bool int ve _v mpgtsw (ve tor signed int, ve tor signed int);
ve tor bool int ve _v mpgtuw (ve tor unsigned int, ve tor unsigned int);
ve tor bool short ve _v mpgtsh (ve tor signed short,
ve tor signed short);
ve tor bool short ve _v mpgtuh (ve tor unsigned short,
ve tor unsigned short);
ve tor bool har ve _v mpgtsb (ve tor signed har, ve tor signed har);
ve tor bool har ve _v mpgtub (ve tor unsigned har,
ve tor unsigned har);
ve tor bool int ve _ mple (ve tor float, ve tor float);
ve tor bool har ve _ mplt (ve tor unsigned har, ve tor unsigned har);
ve tor bool har ve _ mplt (ve tor signed har, ve tor signed har);

299

300

Using the GNU Compiler Colle tion (GCC)

ve tor bool short ve _ mplt (ve tor unsigned short,

ve tor unsigned short);
ve tor bool short ve _ mplt (ve tor signed short, ve tor signed short);
ve tor bool int ve _ mplt (ve tor unsigned int, ve tor unsigned int);
ve tor bool int ve _ mplt (ve tor signed int, ve tor signed int);
ve tor bool int ve _ mplt (ve tor float, ve tor float);
ve tor float ve _ tf (ve tor unsigned int, onst int);
ve tor float ve _ tf (ve tor signed int, onst int);
ve tor float ve _v fsx (ve tor signed int, onst int);
ve tor float ve _v fux (ve tor unsigned int, onst int);
ve tor signed int ve _ ts (ve tor float, onst int);
ve tor unsigned int ve _ tu (ve tor float, onst int);
void ve _dss ( onst int);
void ve _dssall (void);
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void

ve _dst
ve _dst
ve _dst
ve _dst
ve _dst
ve _dst
ve _dst
ve _dst
ve _dst
ve _dst
ve _dst
ve _dst
ve _dst
ve _dst
ve _dst
ve _dst
ve _dst
ve _dst
ve _dst
ve _dst

( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst

void
void
void
void
void
void
void
void
void
void
void
void
void
void
void

ve _dstst
ve _dstst
ve _dstst
ve _dstst
ve _dstst
ve _dstst
ve _dstst
ve _dstst
ve _dstst
ve _dstst
ve _dstst
ve _dstst
ve _dstst
ve _dstst
ve _dstst

ve tor unsigned har *, int, onst int);

ve tor signed har *, int, onst int);
ve tor bool har *, int, onst int);
ve tor unsigned short *, int, onst int);
ve tor signed short *, int, onst int);
ve tor bool short *, int, onst int);
ve tor pixel *, int, onst int);
ve tor unsigned int *, int, onst int);
ve tor signed int *, int, onst int);
ve tor bool int *, int, onst int);
ve tor float *, int, onst int);
unsigned har *, int, onst int);
signed har *, int, onst int);
unsigned short *, int, onst int);
short *, int, onst int);
unsigned int *, int, onst int);
int *, int, onst int);
unsigned long *, int, onst int);
long *, int, onst int);
float *, int, onst int);

( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst

ve tor unsigned har *, int, onst int);

ve tor signed har *, int, onst int);
ve tor bool har *, int, onst int);
ve tor unsigned short *, int, onst int);
ve tor signed short *, int, onst int);
ve tor bool short *, int, onst int);
ve tor pixel *, int, onst int);
ve tor unsigned int *, int, onst int);
ve tor signed int *, int, onst int);
ve tor bool int *, int, onst int);
ve tor float *, int, onst int);
unsigned har *, int, onst int);
signed har *, int, onst int);
unsigned short *, int, onst int);
short *, int, onst int);

Chapter 5: Extensions to the C Language Family

void
void
void
void
void

ve _dstst
ve _dstst
ve _dstst
ve _dstst
ve _dstst

( onst
( onst
( onst
( onst
( onst

void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void

ve _dststt
ve _dststt
ve _dststt
ve _dststt
ve _dststt
ve _dststt
ve _dststt
ve _dststt
ve _dststt
ve _dststt
ve _dststt
ve _dststt
ve _dststt
ve _dststt
ve _dststt
ve _dststt
ve _dststt
ve _dststt
ve _dststt
ve _dststt

void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void

ve _dstt
ve _dstt
ve _dstt
ve _dstt
ve _dstt
ve _dstt
ve _dstt
ve _dstt
ve _dstt
ve _dstt
ve _dstt
ve _dstt
ve _dstt
ve _dstt
ve _dstt
ve _dstt
ve _dstt
ve _dstt
ve _dstt
ve _dstt

unsigned int *, int, onst int);

int *, int, onst int);
unsigned long *, int, onst int);
long *, int, onst int);
float *, int, onst int);

( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst

( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst
( onst

ve tor unsigned har *, int, onst int);

ve tor signed har *, int, onst int);
ve tor bool har *, int, onst int);
ve tor unsigned short *, int, onst int);
ve tor signed short *, int, onst int);
ve tor bool short *, int, onst int);
ve tor pixel *, int, onst int);
ve tor unsigned int *, int, onst int);
ve tor signed int *, int, onst int);
ve tor bool int *, int, onst int);
ve tor float *, int, onst int);
unsigned har *, int, onst int);
signed har *, int, onst int);
unsigned short *, int, onst int);
short *, int, onst int);
unsigned int *, int, onst int);
int *, int, onst int);
unsigned long *, int, onst int);
long *, int, onst int);
float *, int, onst int);

ve tor unsigned har *, int, onst int);

ve tor signed har *, int, onst int);
ve tor bool har *, int, onst int);
ve tor unsigned short *, int, onst int);
ve tor signed short *, int, onst int);
ve tor bool short *, int, onst int);
ve tor pixel *, int, onst int);
ve tor unsigned int *, int, onst int);
ve tor signed int *, int, onst int);
ve tor bool int *, int, onst int);
ve tor float *, int, onst int);
unsigned har *, int, onst int);
signed har *, int, onst int);
unsigned short *, int, onst int);
short *, int, onst int);
unsigned int *, int, onst int);
int *, int, onst int);
unsigned long *, int, onst int);
long *, int, onst int);
float *, int, onst int);

ve tor float ve _expte (ve tor float);

ve tor float ve _floor (ve tor float);
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor

float ve _ld (int, onst ve tor float *);

float ve _ld (int, onst float *);
bool int ve _ld (int, onst ve tor bool int *);
signed int ve _ld (int, onst ve tor signed int *);
signed int ve _ld (int, onst int *);
signed int ve _ld (int, onst long *);

301

302

Using the GNU Compiler Colle tion (GCC)

ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor

unsigned int ve _ld (int, onst ve tor unsigned int *);

unsigned int ve _ld (int, onst unsigned int *);
unsigned int ve _ld (int, onst unsigned long *);
bool short ve _ld (int, onst ve tor bool short *);
pixel ve _ld (int, onst ve tor pixel *);
signed short ve _ld (int, onst ve tor signed short *);
signed short ve _ld (int, onst short *);
unsigned short ve _ld (int, onst ve tor unsigned short *);
unsigned short ve _ld (int, onst unsigned short *);
bool har ve _ld (int, onst ve tor bool har *);
signed har ve _ld (int, onst ve tor signed har *);
signed har ve _ld (int, onst signed har *);
unsigned har ve _ld (int, onst ve tor unsigned har *);
unsigned har ve _ld (int, onst unsigned har *);

ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor

signed har ve _lde (int, onst signed har *);

unsigned har ve _lde (int, onst unsigned har *);
signed short ve _lde (int, onst short *);
unsigned short ve _lde (int, onst unsigned short *);
float ve _lde (int, onst float *);
signed int ve _lde (int, onst int *);
unsigned int ve _lde (int, onst unsigned int *);
signed int ve _lde (int, onst long *);
unsigned int ve _lde (int, onst unsigned long *);

ve tor
ve tor
ve tor
ve tor
ve tor

float ve _lvewx (int, float *);

signed int ve _lvewx (int, int *);
unsigned int ve _lvewx (int, unsigned int *);
signed int ve _lvewx (int, long *);
unsigned int ve _lvewx (int, unsigned long *);

ve tor signed short ve _lvehx (int, short *);

ve tor unsigned short ve _lvehx (int, unsigned short *);
ve tor signed har ve _lvebx (int, har *);
ve tor unsigned har ve _lvebx (int, unsigned har *);
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor

float ve _ldl (int, onst ve tor float *);

float ve _ldl (int, onst float *);
bool int ve _ldl (int, onst ve tor bool int *);
signed int ve _ldl (int, onst ve tor signed int *);
signed int ve _ldl (int, onst int *);
signed int ve _ldl (int, onst long *);
unsigned int ve _ldl (int, onst ve tor unsigned int *);
unsigned int ve _ldl (int, onst unsigned int *);
unsigned int ve _ldl (int, onst unsigned long *);
bool short ve _ldl (int, onst ve tor bool short *);
pixel ve _ldl (int, onst ve tor pixel *);
signed short ve _ldl (int, onst ve tor signed short *);
signed short ve _ldl (int, onst short *);
unsigned short ve _ldl (int, onst ve tor unsigned short *);
unsigned short ve _ldl (int, onst unsigned short *);
bool har ve _ldl (int, onst ve tor bool har *);
signed har ve _ldl (int, onst ve tor signed har *);
signed har ve _ldl (int, onst signed har *);
unsigned har ve _ldl (int, onst ve tor unsigned har *);
unsigned har ve _ldl (int, onst unsigned har *);

Chapter 5: Extensions to the C Language Family

303

ve tor float ve _loge (ve tor float);

ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor

unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned

har
har
har
har
har
har
har
har
har

ve _lvsl
ve _lvsl
ve _lvsl
ve _lvsl
ve _lvsl
ve _lvsl
ve _lvsl
ve _lvsl
ve _lvsl

(int,
(int,
(int,
(int,
(int,
(int,
(int,
(int,
(int,

onst
onst
onst
onst
onst
onst
onst
onst
onst

volatile
volatile
volatile
volatile
volatile
volatile
volatile
volatile
volatile

unsigned har *);

signed har *);
unsigned short *);
short *);
unsigned int *);
int *);
unsigned long *);
long *);
float *);

ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor

unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned

har
har
har
har
har
har
har
har
har

ve _lvsr
ve _lvsr
ve _lvsr
ve _lvsr
ve _lvsr
ve _lvsr
ve _lvsr
ve _lvsr
ve _lvsr

(int,
(int,
(int,
(int,
(int,
(int,
(int,
(int,
(int,

onst
onst
onst
onst
onst
onst
onst
onst
onst

volatile
volatile
volatile
volatile
volatile
volatile
volatile
volatile
volatile

unsigned har *);

signed har *);
unsigned short *);
short *);
unsigned int *);
int *);
unsigned long *);
long *);
float *);

ve tor float ve _madd (ve tor float, ve tor float, ve tor float);
ve tor signed short ve _madds (ve tor signed short,
ve tor signed short,
ve tor signed short);
ve tor unsigned har ve _max (ve tor bool har, ve tor unsigned har);
ve tor unsigned har ve _max (ve tor unsigned har, ve tor bool har);
ve tor unsigned har ve _max (ve tor unsigned har,
ve tor unsigned har);
ve tor signed har ve _max (ve tor bool har, ve tor signed har);
ve tor signed har ve _max (ve tor signed har, ve tor bool har);
ve tor signed har ve _max (ve tor signed har, ve tor signed har);
ve tor unsigned short ve _max (ve tor bool short,
ve tor unsigned short);
ve tor unsigned short ve _max (ve tor unsigned short,
ve tor bool short);
ve tor unsigned short ve _max (ve tor unsigned short,
ve tor unsigned short);
ve tor signed short ve _max (ve tor bool short, ve tor signed short);
ve tor signed short ve _max (ve tor signed short, ve tor bool short);
ve tor signed short ve _max (ve tor signed short, ve tor signed short);
ve tor unsigned int ve _max (ve tor bool int, ve tor unsigned int);
ve tor unsigned int ve _max (ve tor unsigned int, ve tor bool int);
ve tor unsigned int ve _max (ve tor unsigned int, ve tor unsigned int);
ve tor signed int ve _max (ve tor bool int, ve tor signed int);
ve tor signed int ve _max (ve tor signed int, ve tor bool int);
ve tor signed int ve _max (ve tor signed int, ve tor signed int);
ve tor float ve _max (ve tor float, ve tor float);
ve tor float ve _vmaxfp (ve tor float, ve tor float);
ve tor signed int ve _vmaxsw (ve tor bool int, ve tor signed int);
ve tor signed int ve _vmaxsw (ve tor signed int, ve tor bool int);
ve tor signed int ve _vmaxsw (ve tor signed int, ve tor signed int);

304

Using the GNU Compiler Colle tion (GCC)

ve tor unsigned int ve _vmaxuw (ve tor bool int, ve tor unsigned int);
ve tor unsigned int ve _vmaxuw (ve tor unsigned int, ve tor bool int);
ve tor unsigned int ve _vmaxuw (ve tor unsigned int,
ve tor unsigned int);
ve tor signed short ve _vmaxsh (ve tor bool short, ve tor signed short);
ve tor signed short ve _vmaxsh (ve tor signed short, ve tor bool short);
ve tor signed short ve _vmaxsh (ve tor signed short,
ve tor signed short);
ve tor unsigned short ve _vmaxuh (ve tor
ve tor
ve tor unsigned short ve _vmaxuh (ve tor
ve tor
ve tor unsigned short ve _vmaxuh (ve tor
ve tor

bool short,
unsigned short);
unsigned short,
bool short);
unsigned short,
unsigned short);

ve tor signed har ve _vmaxsb (ve tor bool har, ve tor signed har);
ve tor signed har ve _vmaxsb (ve tor signed har, ve tor bool har);
ve tor signed har ve _vmaxsb (ve tor signed har, ve tor signed har);
ve tor unsigned har ve _vmaxub (ve tor
ve tor
ve tor unsigned har ve _vmaxub (ve tor
ve tor
ve tor unsigned har ve _vmaxub (ve tor
ve tor

bool har,
unsigned har);
unsigned har,
bool har);
unsigned har,
unsigned har);

ve tor bool har ve _mergeh (ve tor bool har, ve tor bool har);
ve tor signed har ve _mergeh (ve tor signed har, ve tor signed har);
ve tor unsigned har ve _mergeh (ve tor unsigned har,
ve tor unsigned har);
ve tor bool short ve _mergeh (ve tor bool short, ve tor bool short);
ve tor pixel ve _mergeh (ve tor pixel, ve tor pixel);
ve tor signed short ve _mergeh (ve tor signed short,
ve tor signed short);
ve tor unsigned short ve _mergeh (ve tor unsigned short,
ve tor unsigned short);
ve tor float ve _mergeh (ve tor float, ve tor float);
ve tor bool int ve _mergeh (ve tor bool int, ve tor bool int);
ve tor signed int ve _mergeh (ve tor signed int, ve tor signed int);
ve tor unsigned int ve _mergeh (ve tor unsigned int,
ve tor unsigned int);
ve tor
ve tor
ve tor
ve tor

float ve _vmrghw (ve tor float, ve tor float);

bool int ve _vmrghw (ve tor bool int, ve tor bool int);
signed int ve _vmrghw (ve tor signed int, ve tor signed int);
unsigned int ve _vmrghw (ve tor unsigned int,
ve tor unsigned int);

ve tor bool short ve _vmrghh (ve tor bool short, ve tor bool short);
ve tor signed short ve _vmrghh (ve tor signed short,
ve tor signed short);
ve tor unsigned short ve _vmrghh (ve tor unsigned short,
ve tor unsigned short);
ve tor pixel ve _vmrghh (ve tor pixel, ve tor pixel);
ve tor bool har ve _vmrghb (ve tor bool har, ve tor bool har);

Chapter 5: Extensions to the C Language Family

ve tor signed har ve _vmrghb (ve tor signed har, ve tor signed har);
ve tor unsigned har ve _vmrghb (ve tor unsigned har,
ve tor unsigned har);
ve tor bool har ve _mergel (ve tor bool har, ve tor bool har);
ve tor signed har ve _mergel (ve tor signed har, ve tor signed har);
ve tor unsigned har ve _mergel (ve tor unsigned har,
ve tor unsigned har);
ve tor bool short ve _mergel (ve tor bool short, ve tor bool short);
ve tor pixel ve _mergel (ve tor pixel, ve tor pixel);
ve tor signed short ve _mergel (ve tor signed short,
ve tor signed short);
ve tor unsigned short ve _mergel (ve tor unsigned short,
ve tor unsigned short);
ve tor float ve _mergel (ve tor float, ve tor float);
ve tor bool int ve _mergel (ve tor bool int, ve tor bool int);
ve tor signed int ve _mergel (ve tor signed int, ve tor signed int);
ve tor unsigned int ve _mergel (ve tor unsigned int,
ve tor unsigned int);
ve tor float ve _vmrglw (ve tor float, ve tor float);
ve tor signed int ve _vmrglw (ve tor signed int, ve tor signed int);
ve tor unsigned int ve _vmrglw (ve tor unsigned int,
ve tor unsigned int);
ve tor bool int ve _vmrglw (ve tor bool int, ve tor bool int);
ve tor bool short ve _vmrglh (ve tor bool short, ve tor bool short);
ve tor signed short ve _vmrglh (ve tor signed short,
ve tor signed short);
ve tor unsigned short ve _vmrglh (ve tor unsigned short,
ve tor unsigned short);
ve tor pixel ve _vmrglh (ve tor pixel, ve tor pixel);
ve tor bool har ve _vmrglb (ve tor bool har, ve tor bool har);
ve tor signed har ve _vmrglb (ve tor signed har, ve tor signed har);
ve tor unsigned har ve _vmrglb (ve tor unsigned har,
ve tor unsigned har);
ve tor unsigned short ve _mfvs r (void);
ve tor unsigned har ve _min (ve tor bool har, ve tor unsigned har);
ve tor unsigned har ve _min (ve tor unsigned har, ve tor bool har);
ve tor unsigned har ve _min (ve tor unsigned har,
ve tor unsigned har);
ve tor signed har ve _min (ve tor bool har, ve tor signed har);
ve tor signed har ve _min (ve tor signed har, ve tor bool har);
ve tor signed har ve _min (ve tor signed har, ve tor signed har);
ve tor unsigned short ve _min (ve tor bool short,
ve tor unsigned short);
ve tor unsigned short ve _min (ve tor unsigned short,
ve tor bool short);
ve tor unsigned short ve _min (ve tor unsigned short,
ve tor unsigned short);
ve tor signed short ve _min (ve tor bool short, ve tor signed short);
ve tor signed short ve _min (ve tor signed short, ve tor bool short);
ve tor signed short ve _min (ve tor signed short, ve tor signed short);
ve tor unsigned int ve _min (ve tor bool int, ve tor unsigned int);
ve tor unsigned int ve _min (ve tor unsigned int, ve tor bool int);

305

306

Using the GNU Compiler Colle tion (GCC)

ve tor
ve tor
ve tor
ve tor
ve tor

unsigned int ve _min (ve tor unsigned int, ve tor unsigned int);
signed int ve _min (ve tor bool int, ve tor signed int);
signed int ve _min (ve tor signed int, ve tor bool int);
signed int ve _min (ve tor signed int, ve tor signed int);
float ve _min (ve tor float, ve tor float);

ve tor float ve _vminfp (ve tor float, ve tor float);

ve tor signed int ve _vminsw (ve tor bool int, ve tor signed int);
ve tor signed int ve _vminsw (ve tor signed int, ve tor bool int);
ve tor signed int ve _vminsw (ve tor signed int, ve tor signed int);
ve tor unsigned int ve _vminuw (ve tor bool int, ve tor unsigned int);
ve tor unsigned int ve _vminuw (ve tor unsigned int, ve tor bool int);
ve tor unsigned int ve _vminuw (ve tor unsigned int,
ve tor unsigned int);
ve tor signed short ve _vminsh (ve tor bool short, ve tor signed short);
ve tor signed short ve _vminsh (ve tor signed short, ve tor bool short);
ve tor signed short ve _vminsh (ve tor signed short,
ve tor signed short);
ve tor unsigned short ve _vminuh (ve tor
ve tor
ve tor unsigned short ve _vminuh (ve tor
ve tor
ve tor unsigned short ve _vminuh (ve tor
ve tor

bool short,
unsigned short);
unsigned short,
bool short);
unsigned short,
unsigned short);

ve tor signed har ve _vminsb (ve tor bool har, ve tor signed har);
ve tor signed har ve _vminsb (ve tor signed har, ve tor bool har);
ve tor signed har ve _vminsb (ve tor signed har, ve tor signed har);
ve tor unsigned har ve _vminub (ve tor
ve tor
ve tor unsigned har ve _vminub (ve tor
ve tor
ve tor unsigned har ve _vminub (ve tor
ve tor

bool har,
unsigned har);
unsigned har,
bool har);
unsigned har,
unsigned har);

ve tor signed short ve _mladd (ve tor signed short,

ve tor signed short,
ve tor signed short);
ve tor signed short ve _mladd (ve tor signed short,
ve tor unsigned short,
ve tor unsigned short);
ve tor signed short ve _mladd (ve tor unsigned short,
ve tor signed short,
ve tor signed short);
ve tor unsigned short ve _mladd (ve tor unsigned short,
ve tor unsigned short,
ve tor unsigned short);
ve tor signed short ve _mradds (ve tor signed short,
ve tor signed short,
ve tor signed short);
ve tor unsigned int ve _msum (ve tor unsigned har,

Chapter 5: Extensions to the C Language Family

ve tor unsigned har,

ve tor unsigned int);
ve tor signed int ve _msum (ve tor signed har,
ve tor unsigned har,
ve tor signed int);
ve tor unsigned int ve _msum (ve tor unsigned short,
ve tor unsigned short,
ve tor unsigned int);
ve tor signed int ve _msum (ve tor signed short,
ve tor signed short,
ve tor signed int);
ve tor signed int ve _vmsumshm (ve tor signed short,
ve tor signed short,
ve tor signed int);
ve tor unsigned int ve _vmsumuhm (ve tor unsigned short,
ve tor unsigned short,
ve tor unsigned int);
ve tor signed int ve _vmsummbm (ve tor signed har,
ve tor unsigned har,
ve tor signed int);
ve tor unsigned int ve _vmsumubm (ve tor unsigned har,
ve tor unsigned har,
ve tor unsigned int);
ve tor unsigned int ve _msums (ve tor unsigned short,
ve tor unsigned short,
ve tor unsigned int);
ve tor signed int ve _msums (ve tor signed short,
ve tor signed short,
ve tor signed int);
ve tor signed int ve _vmsumshs (ve tor signed short,
ve tor signed short,
ve tor signed int);
ve tor unsigned int ve _vmsumuhs (ve tor unsigned short,
ve tor unsigned short,
ve tor unsigned int);
void
void
void
void
void
void
void
void
void
void

ve _mtvs r
ve _mtvs r
ve _mtvs r
ve _mtvs r
ve _mtvs r
ve _mtvs r
ve _mtvs r
ve _mtvs r
ve _mtvs r
ve _mtvs r

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

signed int);
unsigned int);
bool int);
signed short);
unsigned short);
bool short);
pixel);
signed har);
unsigned har);
bool har);

ve tor unsigned short ve _mule (ve tor unsigned har,

ve tor unsigned har);
ve tor signed short ve _mule (ve tor signed har,
ve tor signed har);

307

308

Using the GNU Compiler Colle tion (GCC)

ve tor unsigned int ve _mule (ve tor unsigned short,

ve tor unsigned short);
ve tor signed int ve _mule (ve tor signed short, ve tor signed short);
ve tor signed int ve _vmulesh (ve tor signed short,
ve tor signed short);
ve tor unsigned int ve _vmuleuh (ve tor unsigned short,
ve tor unsigned short);
ve tor signed short ve _vmulesb (ve tor signed har,
ve tor signed har);
ve tor unsigned short ve _vmuleub (ve tor unsigned har,
ve tor unsigned har);
ve tor unsigned short ve _mulo (ve tor unsigned har,
ve tor unsigned har);
ve tor signed short ve _mulo (ve tor signed har, ve tor signed har);
ve tor unsigned int ve _mulo (ve tor unsigned short,
ve tor unsigned short);
ve tor signed int ve _mulo (ve tor signed short, ve tor signed short);
ve tor signed int ve _vmulosh (ve tor signed short,
ve tor signed short);
ve tor unsigned int ve _vmulouh (ve tor unsigned short,
ve tor unsigned short);
ve tor signed short ve _vmulosb (ve tor signed har,
ve tor signed har);
ve tor unsigned short ve _vmuloub (ve tor unsigned har,
ve tor unsigned har);
ve tor float ve _nmsub (ve tor float, ve tor float, ve tor float);
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor

ve tor

float ve _nor (ve tor float, ve tor float);

signed int ve _nor (ve tor signed int, ve tor signed int);
unsigned int ve _nor (ve tor unsigned int, ve tor unsigned int);
bool int ve _nor (ve tor bool int, ve tor bool int);
signed short ve _nor (ve tor signed short, ve tor signed short);
unsigned short ve _nor (ve tor unsigned short,
ve tor unsigned short);
bool short ve _nor (ve tor bool short, ve tor bool short);
signed har ve _nor (ve tor signed har, ve tor signed har);
unsigned har ve _nor (ve tor unsigned har,
ve tor unsigned har);
bool har ve _nor (ve tor bool har, ve tor bool har);

ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor

float ve _or (ve tor float, ve tor float);

float ve _or (ve tor float, ve tor bool int);
float ve _or (ve tor bool int, ve tor float);
bool int ve _or (ve tor bool int, ve tor bool int);
signed int ve _or (ve tor bool int, ve tor signed int);
signed int ve _or (ve tor signed int, ve tor bool int);
signed int ve _or (ve tor signed int, ve tor signed int);
unsigned int ve _or (ve tor bool int, ve tor unsigned int);

ve tor
ve tor
ve tor

Chapter 5: Extensions to the C Language Family

ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor

unsigned int ve _or (ve tor unsigned int, ve tor bool int);
unsigned int ve _or (ve tor unsigned int, ve tor unsigned int);
bool short ve _or (ve tor bool short, ve tor bool short);
signed short ve _or (ve tor bool short, ve tor signed short);
signed short ve _or (ve tor signed short, ve tor bool short);
signed short ve _or (ve tor signed short, ve tor signed short);
unsigned short ve _or (ve tor bool short, ve tor unsigned short);
unsigned short ve _or (ve tor unsigned short, ve tor bool short);
unsigned short ve _or (ve tor unsigned short,
ve tor unsigned short);
signed har ve _or (ve tor bool har, ve tor signed har);
bool har ve _or (ve tor bool har, ve tor bool har);
signed har ve _or (ve tor signed har, ve tor bool har);
signed har ve _or (ve tor signed har, ve tor signed har);
unsigned har ve _or (ve tor bool har, ve tor unsigned har);
unsigned har ve _or (ve tor unsigned har, ve tor bool har);
unsigned har ve _or (ve tor unsigned har,
ve tor unsigned har);

ve tor signed har ve _pa k (ve tor signed short, ve tor signed short);
ve tor unsigned har ve _pa k (ve tor unsigned short,
ve tor unsigned short);
ve tor bool har ve _pa k (ve tor bool short, ve tor bool short);
ve tor signed short ve _pa k (ve tor signed int, ve tor signed int);
ve tor unsigned short ve _pa k (ve tor unsigned int,
ve tor unsigned int);
ve tor bool short ve _pa k (ve tor bool int, ve tor bool int);
ve tor bool short ve _vpkuwum (ve tor bool int, ve tor bool int);
ve tor signed short ve _vpkuwum (ve tor signed int, ve tor signed int);
ve tor unsigned short ve _vpkuwum (ve tor unsigned int,
ve tor unsigned int);
ve tor bool har ve _vpkuhum (ve tor bool short, ve tor bool short);
ve tor signed har ve _vpkuhum (ve tor signed short,
ve tor signed short);
ve tor unsigned har ve _vpkuhum (ve tor unsigned short,
ve tor unsigned short);
ve tor pixel ve _pa kpx (ve tor unsigned int, ve tor unsigned int);
ve tor unsigned har ve _pa ks (ve tor unsigned short,
ve tor unsigned short);
ve tor signed har ve _pa ks (ve tor signed short, ve tor signed short);
ve tor unsigned short ve _pa ks (ve tor unsigned int,
ve tor unsigned int);
ve tor signed short ve _pa ks (ve tor signed int, ve tor signed int);
ve tor signed short ve _vpkswss (ve tor signed int, ve tor signed int);
ve tor unsigned short ve _vpkuwus (ve tor unsigned int,
ve tor unsigned int);
ve tor signed har ve _vpkshss (ve tor signed short,
ve tor signed short);
ve tor unsigned har ve _vpkuhus (ve tor unsigned short,
ve tor unsigned short);

309

310

Using the GNU Compiler Colle tion (GCC)

ve tor unsigned har ve _pa ksu (ve tor unsigned short,

ve tor unsigned short);
ve tor unsigned har ve _pa ksu (ve tor signed short,
ve tor signed short);
ve tor unsigned short ve _pa ksu (ve tor unsigned int,
ve tor unsigned int);
ve tor unsigned short ve _pa ksu (ve tor signed int, ve tor signed int);
ve tor unsigned short ve _vpkswus (ve tor signed int,
ve tor signed int);
ve tor unsigned har ve _vpkshus (ve tor signed short,
ve tor signed short);
ve tor float ve _perm (ve tor float,
ve tor float,
ve tor unsigned har);
ve tor signed int ve _perm (ve tor signed int,
ve tor signed int,
ve tor unsigned har);
ve tor unsigned int ve _perm (ve tor unsigned int,
ve tor unsigned int,
ve tor unsigned har);
ve tor bool int ve _perm (ve tor bool int,
ve tor bool int,
ve tor unsigned har);
ve tor signed short ve _perm (ve tor signed short,
ve tor signed short,
ve tor unsigned har);
ve tor unsigned short ve _perm (ve tor unsigned short,
ve tor unsigned short,
ve tor unsigned har);
ve tor bool short ve _perm (ve tor bool short,
ve tor bool short,
ve tor unsigned har);
ve tor pixel ve _perm (ve tor pixel,
ve tor pixel,
ve tor unsigned har);
ve tor signed har ve _perm (ve tor signed har,
ve tor signed har,
ve tor unsigned har);
ve tor unsigned har ve _perm (ve tor unsigned har,
ve tor unsigned har,
ve tor unsigned har);
ve tor bool har ve _perm (ve tor bool har,
ve tor bool har,
ve tor unsigned har);
ve tor float ve _re (ve tor float);
ve tor signed har ve _rl (ve tor signed har,
ve tor unsigned har);
ve tor unsigned har ve _rl (ve tor unsigned har,
ve tor unsigned har);
ve tor signed short ve _rl (ve tor signed short, ve tor unsigned short);
ve tor unsigned short ve _rl (ve tor unsigned short,
ve tor unsigned short);

Chapter 5: Extensions to the C Language Family

ve tor signed int ve _rl (ve tor signed int, ve tor unsigned int);
ve tor unsigned int ve _rl (ve tor unsigned int, ve tor unsigned int);
ve tor signed int ve _vrlw (ve tor signed int, ve tor unsigned int);
ve tor unsigned int ve _vrlw (ve tor unsigned int, ve tor unsigned int);
ve tor signed short ve _vrlh (ve tor signed short,
ve tor unsigned short);
ve tor unsigned short ve _vrlh (ve tor unsigned short,
ve tor unsigned short);
ve tor signed har ve _vrlb (ve tor signed har, ve tor unsigned har);
ve tor unsigned har ve _vrlb (ve tor unsigned har,
ve tor unsigned har);
ve tor float ve _round (ve tor float);
ve tor float ve _rsqrte (ve tor float);
ve tor float ve _sel (ve tor float, ve tor float, ve tor bool int);
ve tor float ve _sel (ve tor float, ve tor float, ve tor unsigned int);
ve tor signed int ve _sel (ve tor signed int,
ve tor signed int,
ve tor bool int);
ve tor signed int ve _sel (ve tor signed int,
ve tor signed int,
ve tor unsigned int);
ve tor unsigned int ve _sel (ve tor unsigned int,
ve tor unsigned int,
ve tor bool int);
ve tor unsigned int ve _sel (ve tor unsigned int,
ve tor unsigned int,
ve tor unsigned int);
ve tor bool int ve _sel (ve tor bool int,
ve tor bool int,
ve tor bool int);
ve tor bool int ve _sel (ve tor bool int,
ve tor bool int,
ve tor unsigned int);
ve tor signed short ve _sel (ve tor signed short,
ve tor signed short,
ve tor bool short);
ve tor signed short ve _sel (ve tor signed short,
ve tor signed short,
ve tor unsigned short);
ve tor unsigned short ve _sel (ve tor unsigned short,
ve tor unsigned short,
ve tor bool short);
ve tor unsigned short ve _sel (ve tor unsigned short,
ve tor unsigned short,
ve tor unsigned short);
ve tor bool short ve _sel (ve tor bool short,
ve tor bool short,
ve tor bool short);
ve tor bool short ve _sel (ve tor bool short,
ve tor bool short,
ve tor unsigned short);
ve tor signed har ve _sel (ve tor signed har,

311

312

Using the GNU Compiler Colle tion (GCC)

ve tor
ve tor
ve tor
ve tor
ve tor

ve tor signed har,

ve tor bool har);
signed har ve _sel (ve tor signed har,
ve tor signed har,
ve tor unsigned har);
unsigned har ve _sel (ve tor unsigned har,
ve tor unsigned har,
ve tor bool har);
unsigned har ve _sel (ve tor unsigned har,
ve tor unsigned har,
ve tor unsigned har);
bool har ve _sel (ve tor bool har,
ve tor bool har,
ve tor bool har);
bool har ve _sel (ve tor bool har,
ve tor bool har,
ve tor unsigned har);

ve tor signed har ve _sl (ve tor signed har,

ve tor unsigned har);
ve tor unsigned har ve _sl (ve tor unsigned har,
ve tor unsigned har);
ve tor signed short ve _sl (ve tor signed short, ve tor unsigned short);
ve tor unsigned short ve _sl (ve tor unsigned short,
ve tor unsigned short);
ve tor signed int ve _sl (ve tor signed int, ve tor unsigned int);
ve tor unsigned int ve _sl (ve tor unsigned int, ve tor unsigned int);
ve tor signed int ve _vslw (ve tor signed int, ve tor unsigned int);
ve tor unsigned int ve _vslw (ve tor unsigned int, ve tor unsigned int);
ve tor signed short ve _vslh (ve tor signed short,
ve tor unsigned short);
ve tor unsigned short ve _vslh (ve tor unsigned short,
ve tor unsigned short);
ve tor signed har ve _vslb (ve tor signed har, ve tor unsigned har);
ve tor unsigned har ve _vslb (ve tor unsigned har,
ve tor unsigned har);
ve tor float ve _sld (ve tor float, ve tor float, onst int);
ve tor signed int ve _sld (ve tor signed int,
ve tor signed int,
onst int);
ve tor unsigned int ve _sld (ve tor unsigned int,
ve tor unsigned int,
onst int);
ve tor bool int ve _sld (ve tor bool int,
ve tor bool int,
onst int);
ve tor signed short ve _sld (ve tor signed short,
ve tor signed short,
onst int);
ve tor unsigned short ve _sld (ve tor unsigned short,
ve tor unsigned short,
onst int);
ve tor bool short ve _sld (ve tor bool short,
ve tor bool short,

Chapter 5: Extensions to the C Language Family

onst int);
ve tor pixel ve _sld (ve tor pixel,
ve tor pixel,
onst int);
ve tor signed har ve _sld (ve tor signed har,
ve tor signed har,
onst int);
ve tor unsigned har ve _sld (ve tor unsigned har,
ve tor unsigned har,
onst int);
ve tor bool har ve _sld (ve tor bool har,
ve tor bool har,
onst int);
ve tor signed int ve _sll (ve tor signed int,
ve tor unsigned int);
ve tor signed int ve _sll (ve tor signed int,
ve tor unsigned short);
ve tor signed int ve _sll (ve tor signed int,
ve tor unsigned har);
ve tor unsigned int ve _sll (ve tor unsigned int,
ve tor unsigned int);
ve tor unsigned int ve _sll (ve tor unsigned int,
ve tor unsigned short);
ve tor unsigned int ve _sll (ve tor unsigned int,
ve tor unsigned har);
ve tor bool int ve _sll (ve tor bool int,
ve tor unsigned int);
ve tor bool int ve _sll (ve tor bool int,
ve tor unsigned short);
ve tor bool int ve _sll (ve tor bool int,
ve tor unsigned har);
ve tor signed short ve _sll (ve tor signed short,
ve tor unsigned int);
ve tor signed short ve _sll (ve tor signed short,
ve tor unsigned short);
ve tor signed short ve _sll (ve tor signed short,
ve tor unsigned har);
ve tor unsigned short ve _sll (ve tor unsigned short,
ve tor unsigned int);
ve tor unsigned short ve _sll (ve tor unsigned short,
ve tor unsigned short);
ve tor unsigned short ve _sll (ve tor unsigned short,
ve tor unsigned har);
ve tor bool short ve _sll (ve tor bool short, ve tor unsigned int);
ve tor bool short ve _sll (ve tor bool short, ve tor unsigned short);
ve tor bool short ve _sll (ve tor bool short, ve tor unsigned har);
ve tor pixel ve _sll (ve tor pixel, ve tor unsigned int);
ve tor pixel ve _sll (ve tor pixel, ve tor unsigned short);
ve tor pixel ve _sll (ve tor pixel, ve tor unsigned har);
ve tor signed har ve _sll (ve tor signed har, ve tor unsigned int);
ve tor signed har ve _sll (ve tor signed har, ve tor unsigned short);
ve tor signed har ve _sll (ve tor signed har, ve tor unsigned har);
ve tor unsigned har ve _sll (ve tor unsigned har,
ve tor unsigned int);
ve tor unsigned har ve _sll (ve tor unsigned har,
ve tor unsigned short);
ve tor unsigned har ve _sll (ve tor unsigned har,

313

314

Using the GNU Compiler Colle tion (GCC)

ve tor unsigned har);

ve tor bool har ve _sll (ve tor bool har, ve tor unsigned int);
ve tor bool har ve _sll (ve tor bool har, ve tor unsigned short);
ve tor bool har ve _sll (ve tor bool har, ve tor unsigned har);
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor

float ve _slo (ve tor float, ve tor signed har);

float ve _slo (ve tor float, ve tor unsigned har);
signed int ve _slo (ve tor signed int, ve tor signed har);
signed int ve _slo (ve tor signed int, ve tor unsigned har);
unsigned int ve _slo (ve tor unsigned int, ve tor signed har);
unsigned int ve _slo (ve tor unsigned int, ve tor unsigned har);
signed short ve _slo (ve tor signed short, ve tor signed har);
signed short ve _slo (ve tor signed short, ve tor unsigned har);
unsigned short ve _slo (ve tor unsigned short,
ve tor signed har);
unsigned short ve _slo (ve tor unsigned short,
ve tor unsigned har);
pixel ve _slo (ve tor pixel, ve tor signed har);
pixel ve _slo (ve tor pixel, ve tor unsigned har);
signed har ve _slo (ve tor signed har, ve tor signed har);
signed har ve _slo (ve tor signed har, ve tor unsigned har);
unsigned har ve _slo (ve tor unsigned har, ve tor signed har);
unsigned har ve _slo (ve tor unsigned har,
ve tor unsigned har);

ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor

signed har ve _splat (ve tor signed har, onst int);

unsigned har ve _splat (ve tor unsigned har, onst int);
bool har ve _splat (ve tor bool har, onst int);
signed short ve _splat (ve tor signed short, onst int);
unsigned short ve _splat (ve tor unsigned short, onst int);
bool short ve _splat (ve tor bool short, onst int);
pixel ve _splat (ve tor pixel, onst int);
float ve _splat (ve tor float, onst int);
signed int ve _splat (ve tor signed int, onst int);
unsigned int ve _splat (ve tor unsigned int, onst int);
bool int ve _splat (ve tor bool int, onst int);

ve tor
ve tor
ve tor
ve tor

float ve _vspltw (ve tor float, onst int);

signed int ve _vspltw (ve tor signed int, onst int);
unsigned int ve _vspltw (ve tor unsigned int, onst int);
bool int ve _vspltw (ve tor bool int, onst int);

ve tor
ve tor
ve tor
ve tor

bool short ve _vsplth (ve tor bool short, onst int);

signed short ve _vsplth (ve tor signed short, onst int);
unsigned short ve _vsplth (ve tor unsigned short, onst int);
pixel ve _vsplth (ve tor pixel, onst int);

ve tor signed har ve _vspltb (ve tor signed har, onst int);
ve tor unsigned har ve _vspltb (ve tor unsigned har, onst int);
ve tor bool har ve _vspltb (ve tor bool har, onst int);
ve tor signed har ve _splat_s8 ( onst int);
ve tor signed short ve _splat_s16 ( onst int);
ve tor signed int ve _splat_s32 ( onst int);
ve tor unsigned har ve _splat_u8 ( onst int);

Chapter 5: Extensions to the C Language Family

ve tor unsigned short ve _splat_u16 ( onst int);

ve tor unsigned int ve _splat_u32 ( onst int);
ve tor signed har ve _sr (ve tor signed har, ve tor unsigned har);
ve tor unsigned har ve _sr (ve tor unsigned har,
ve tor unsigned har);
ve tor signed short ve _sr (ve tor signed short,
ve tor unsigned short);
ve tor unsigned short ve _sr (ve tor unsigned short,
ve tor unsigned short);
ve tor signed int ve _sr (ve tor signed int, ve tor unsigned int);
ve tor unsigned int ve _sr (ve tor unsigned int, ve tor unsigned int);
ve tor signed int ve _vsrw (ve tor signed int, ve tor unsigned int);
ve tor unsigned int ve _vsrw (ve tor unsigned int, ve tor unsigned int);
ve tor signed short ve _vsrh (ve tor signed short,
ve tor unsigned short);
ve tor unsigned short ve _vsrh (ve tor unsigned short,
ve tor unsigned short);
ve tor signed har ve _vsrb (ve tor signed har, ve tor unsigned har);
ve tor unsigned har ve _vsrb (ve tor unsigned har,
ve tor unsigned har);
ve tor signed har ve _sra (ve tor signed har, ve tor unsigned har);
ve tor unsigned har ve _sra (ve tor unsigned har,
ve tor unsigned har);
ve tor signed short ve _sra (ve tor signed short,
ve tor unsigned short);
ve tor unsigned short ve _sra (ve tor unsigned short,
ve tor unsigned short);
ve tor signed int ve _sra (ve tor signed int, ve tor unsigned int);
ve tor unsigned int ve _sra (ve tor unsigned int, ve tor unsigned int);
ve tor signed int ve _vsraw (ve tor signed int, ve tor unsigned int);
ve tor unsigned int ve _vsraw (ve tor unsigned int,
ve tor unsigned int);
ve tor signed short ve _vsrah (ve tor signed short,
ve tor unsigned short);
ve tor unsigned short ve _vsrah (ve tor unsigned short,
ve tor unsigned short);
ve tor signed har ve _vsrab (ve tor signed har, ve tor unsigned har);
ve tor unsigned har ve _vsrab (ve tor unsigned har,
ve tor unsigned har);
ve tor
ve tor
ve tor
ve tor
ve tor

signed int ve _srl (ve tor signed int, ve tor unsigned int);
signed int ve _srl (ve tor signed int, ve tor unsigned short);
signed int ve _srl (ve tor signed int, ve tor unsigned har);
unsigned int ve _srl (ve tor unsigned int, ve tor unsigned int);
unsigned int ve _srl (ve tor unsigned int,
ve tor unsigned short);
ve tor unsigned int ve _srl (ve tor unsigned int, ve tor unsigned har);
ve tor bool int ve _srl (ve tor bool int, ve tor unsigned int);

315

316

Using the GNU Compiler Colle tion (GCC)

ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
void
void
void
void
void
void
void

bool int ve _srl (ve tor bool int, ve tor unsigned short);
bool int ve _srl (ve tor bool int, ve tor unsigned har);
signed short ve _srl (ve tor signed short, ve tor unsigned int);
signed short ve _srl (ve tor signed short,
ve tor unsigned short);
signed short ve _srl (ve tor signed short, ve tor unsigned har);
unsigned short ve _srl (ve tor unsigned short,
ve tor unsigned int);
unsigned short ve _srl (ve tor unsigned short,
ve tor unsigned short);
unsigned short ve _srl (ve tor unsigned short,
ve tor unsigned har);
bool short ve _srl (ve tor bool short, ve tor unsigned int);
bool short ve _srl (ve tor bool short, ve tor unsigned short);
bool short ve _srl (ve tor bool short, ve tor unsigned har);
pixel ve _srl (ve tor pixel, ve tor unsigned int);
pixel ve _srl (ve tor pixel, ve tor unsigned short);
pixel ve _srl (ve tor pixel, ve tor unsigned har);
signed har ve _srl (ve tor signed har, ve tor unsigned int);
signed har ve _srl (ve tor signed har, ve tor unsigned short);
signed har ve _srl (ve tor signed har, ve tor unsigned har);
unsigned har ve _srl (ve tor unsigned har,
ve tor unsigned int);
unsigned har ve _srl (ve tor unsigned har,
ve tor unsigned short);
unsigned har ve _srl (ve tor unsigned har,
ve tor unsigned har);
bool har ve _srl (ve tor bool har, ve tor unsigned int);
bool har ve _srl (ve tor bool har, ve tor unsigned short);
bool har ve _srl (ve tor bool har, ve tor unsigned har);
float ve _sro (ve tor float, ve tor signed har);
float ve _sro (ve tor float, ve tor unsigned har);
signed int ve _sro (ve tor signed int, ve tor signed har);
signed int ve _sro (ve tor signed int, ve tor unsigned har);
unsigned int ve _sro (ve tor unsigned int, ve tor signed har);
unsigned int ve _sro (ve tor unsigned int, ve tor unsigned har);
signed short ve _sro (ve tor signed short, ve tor signed har);
signed short ve _sro (ve tor signed short, ve tor unsigned har);
unsigned short ve _sro (ve tor unsigned short,
ve tor signed har);
unsigned short ve _sro (ve tor unsigned short,
ve tor unsigned har);
pixel ve _sro (ve tor pixel, ve tor signed har);
pixel ve _sro (ve tor pixel, ve tor unsigned har);
signed har ve _sro (ve tor signed har, ve tor signed har);
signed har ve _sro (ve tor signed har, ve tor unsigned har);
unsigned har ve _sro (ve tor unsigned har, ve tor signed har);
unsigned har ve _sro (ve tor unsigned har,
ve tor unsigned har);

ve _st
ve _st
ve _st
ve _st
ve _st
ve _st
ve _st

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

float, int, ve tor float *);

float, int, float *);
signed int, int, ve tor signed int *);
signed int, int, int *);
unsigned int, int, ve tor unsigned int *);
unsigned int, int, unsigned int *);
bool int, int, ve tor bool int *);

Chapter 5: Extensions to the C Language Family

void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void

ve _st
ve _st
ve _st
ve _st
ve _st
ve _st
ve _st
ve _st
ve _st
ve _st
ve _st
ve _st
ve _st
ve _st
ve _st
ve _st
ve _st
ve _st
ve _st

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

void
void
void
void
void
void
void
void
void
void
void
void
void
void
void

ve _ste
ve _ste
ve _ste
ve _ste
ve _ste
ve _ste
ve _ste
ve _ste
ve _ste
ve _ste
ve _ste
ve _ste
ve _ste
ve _ste
ve _ste

void
void
void
void
void

ve _stvewx
ve _stvewx
ve _stvewx
ve _stvewx
ve _stvewx

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

float, int, float *);

signed int, int, int *);
unsigned int, int, unsigned int *);
bool int, int, int *);
bool int, int, unsigned int *);

void
void
void
void
void
void

ve _stvehx
ve _stvehx
ve _stvehx
ve _stvehx
ve _stvehx
ve _stvehx

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

signed short, int, short *);

unsigned short, int, unsigned short *);
bool short, int, short *);
bool short, int, unsigned short *);
pixel, int, short *);
pixel, int, unsigned short *);

void
void
void
void

ve _stvebx
ve _stvebx
ve _stvebx
ve _stvebx

(ve tor
(ve tor
(ve tor
(ve tor

signed har, int, signed har *);

unsigned har, int, unsigned har *);
bool har, int, signed har *);
bool har, int, unsigned har *);

void
void
void
void

ve _stl
ve _stl
ve _stl
ve _stl

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

(ve tor
(ve tor
(ve tor
(ve tor

bool int, int, unsigned int *);

bool int, int, int *);
signed short, int, ve tor signed short *);
signed short, int, short *);
unsigned short, int, ve tor unsigned short *);
unsigned short, int, unsigned short *);
bool short, int, ve tor bool short *);
bool short, int, unsigned short *);
pixel, int, ve tor pixel *);
pixel, int, unsigned short *);
pixel, int, short *);
bool short, int, short *);
signed har, int, ve tor signed har *);
signed har, int, signed har *);
unsigned har, int, ve tor unsigned har *);
unsigned har, int, unsigned har *);
bool har, int, ve tor bool har *);
bool har, int, unsigned har *);
bool har, int, signed har *);
signed har, int, signed har *);
unsigned har, int, unsigned har *);
bool har, int, signed har *);
bool har, int, unsigned har *);
signed short, int, short *);
unsigned short, int, unsigned short *);
bool short, int, short *);
bool short, int, unsigned short *);
pixel, int, short *);
pixel, int, unsigned short *);
float, int, float *);
signed int, int, int *);
unsigned int, int, unsigned int *);
bool int, int, int *);
bool int, int, unsigned int *);

float,
float,
signed
signed

int,
int,
int,
int,

ve tor float *);

float *);
int, ve tor signed int *);
int, int *);

317

318

Using the GNU Compiler Colle tion (GCC)

void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void
void

ve _stl
ve _stl
ve _stl
ve _stl
ve _stl
ve _stl
ve _stl
ve _stl
ve _stl
ve _stl
ve _stl
ve _stl
ve _stl
ve _stl
ve _stl
ve _stl
ve _stl
ve _stl
ve _stl
ve _stl
ve _stl
ve _stl

ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

unsigned int, int, ve tor unsigned int *);

unsigned int, int, unsigned int *);
bool int, int, ve tor bool int *);
bool int, int, unsigned int *);
bool int, int, int *);
signed short, int, ve tor signed short *);
signed short, int, short *);
unsigned short, int, ve tor unsigned short *);
unsigned short, int, unsigned short *);
bool short, int, ve tor bool short *);
bool short, int, unsigned short *);
bool short, int, short *);
pixel, int, ve tor pixel *);
pixel, int, unsigned short *);
pixel, int, short *);
signed har, int, ve tor signed har *);
signed har, int, signed har *);
unsigned har, int, ve tor unsigned har *);
unsigned har, int, unsigned har *);
bool har, int, ve tor bool har *);
bool har, int, unsigned har *);
bool har, int, signed har *);

signed har ve _sub (ve tor bool har, ve tor signed har);
signed har ve _sub (ve tor signed har, ve tor bool har);
signed har ve _sub (ve tor signed har, ve tor signed har);
unsigned har ve _sub (ve tor bool har, ve tor unsigned har);
unsigned har ve _sub (ve tor unsigned har, ve tor bool har);
unsigned har ve _sub (ve tor unsigned har,
ve tor unsigned har);
signed short ve _sub (ve tor bool short, ve tor signed short);
signed short ve _sub (ve tor signed short, ve tor bool short);
signed short ve _sub (ve tor signed short, ve tor signed short);
unsigned short ve _sub (ve tor bool short,
ve tor unsigned short);
unsigned short ve _sub (ve tor unsigned short,
ve tor bool short);
unsigned short ve _sub (ve tor unsigned short,
ve tor unsigned short);
signed int ve _sub (ve tor bool int, ve tor signed int);
signed int ve _sub (ve tor signed int, ve tor bool int);
signed int ve _sub (ve tor signed int, ve tor signed int);
unsigned int ve _sub (ve tor bool int, ve tor unsigned int);
unsigned int ve _sub (ve tor unsigned int, ve tor bool int);
unsigned int ve _sub (ve tor unsigned int, ve tor unsigned int);
float ve _sub (ve tor float, ve tor float);

ve tor float ve _vsubfp (ve tor float, ve tor float);

ve tor
ve tor
ve tor
ve tor
ve tor
ve tor

signed int ve _vsubuwm (ve tor bool int, ve tor signed int);
signed int ve _vsubuwm (ve tor signed int, ve tor bool int);
signed int ve _vsubuwm (ve tor signed int, ve tor signed int);
unsigned int ve _vsubuwm (ve tor bool int, ve tor unsigned int);
unsigned int ve _vsubuwm (ve tor unsigned int, ve tor bool int);
unsigned int ve _vsubuwm (ve tor unsigned int,
ve tor unsigned int);

ve tor signed short ve _vsubuhm (ve tor bool short,

Chapter 5: Extensions to the C Language Family

ve tor signed short);

ve tor signed short ve _vsubuhm (ve tor signed short,
ve tor bool short);
ve tor signed short ve _vsubuhm (ve tor signed short,
ve tor signed short);
ve tor unsigned short ve _vsubuhm (ve tor bool short,
ve tor unsigned short);
ve tor unsigned short ve _vsubuhm (ve tor unsigned short,
ve tor bool short);
ve tor unsigned short ve _vsubuhm (ve tor unsigned short,
ve tor unsigned short);
ve tor
ve tor
ve tor
ve tor

signed har ve _vsububm (ve tor bool har, ve tor signed har);
signed har ve _vsububm (ve tor signed har, ve tor bool har);
signed har ve _vsububm (ve tor signed har, ve tor signed har);
unsigned har ve _vsububm (ve tor bool har,
ve tor unsigned har);
ve tor unsigned har ve _vsububm (ve tor unsigned har,
ve tor bool har);
ve tor unsigned har ve _vsububm (ve tor unsigned har,
ve tor unsigned har);
ve tor unsigned int ve _sub (ve tor unsigned int, ve tor unsigned int);
ve tor unsigned har ve _subs (ve tor bool har, ve tor unsigned har);
ve tor unsigned har ve _subs (ve tor unsigned har, ve tor bool har);
ve tor unsigned har ve _subs (ve tor unsigned har,
ve tor unsigned har);
ve tor signed har ve _subs (ve tor bool har, ve tor signed har);
ve tor signed har ve _subs (ve tor signed har, ve tor bool har);
ve tor signed har ve _subs (ve tor signed har, ve tor signed har);
ve tor unsigned short ve _subs (ve tor bool short,
ve tor unsigned short);
ve tor unsigned short ve _subs (ve tor unsigned short,
ve tor bool short);
ve tor unsigned short ve _subs (ve tor unsigned short,
ve tor unsigned short);
ve tor signed short ve _subs (ve tor bool short, ve tor signed short);
ve tor signed short ve _subs (ve tor signed short, ve tor bool short);
ve tor signed short ve _subs (ve tor signed short, ve tor signed short);
ve tor unsigned int ve _subs (ve tor bool int, ve tor unsigned int);
ve tor unsigned int ve _subs (ve tor unsigned int, ve tor bool int);
ve tor unsigned int ve _subs (ve tor unsigned int, ve tor unsigned int);
ve tor signed int ve _subs (ve tor bool int, ve tor signed int);
ve tor signed int ve _subs (ve tor signed int, ve tor bool int);
ve tor signed int ve _subs (ve tor signed int, ve tor signed int);
ve tor signed int ve _vsubsws (ve tor bool int, ve tor signed int);
ve tor signed int ve _vsubsws (ve tor signed int, ve tor bool int);
ve tor signed int ve _vsubsws (ve tor signed int, ve tor signed int);
ve tor unsigned int ve _vsubuws (ve tor bool int, ve tor unsigned int);
ve tor unsigned int ve _vsubuws (ve tor unsigned int, ve tor bool int);
ve tor unsigned int ve _vsubuws (ve tor unsigned int,
ve tor unsigned int);
ve tor signed short ve _vsubshs (ve tor bool short,
ve tor signed short);

319

320

Using the GNU Compiler Colle tion (GCC)

ve tor signed short ve _vsubshs (ve tor

ve tor
ve tor signed short ve _vsubshs (ve tor
ve tor

signed short,
bool short);
signed short,
signed short);

ve tor unsigned short ve _vsubuhs (ve tor

ve tor
ve tor unsigned short ve _vsubuhs (ve tor
ve tor
ve tor unsigned short ve _vsubuhs (ve tor
ve tor

bool short,
unsigned short);
unsigned short,
bool short);
unsigned short,
unsigned short);

ve tor signed har ve _vsubsbs (ve tor bool har, ve tor signed har);
ve tor signed har ve _vsubsbs (ve tor signed har, ve tor bool har);
ve tor signed har ve _vsubsbs (ve tor signed har, ve tor signed har);
ve tor unsigned har ve _vsububs (ve tor
ve tor
ve tor unsigned har ve _vsububs (ve tor
ve tor
ve tor unsigned har ve _vsububs (ve tor
ve tor

bool har,
unsigned har);
unsigned har,
bool har);
unsigned har,
unsigned har);

ve tor unsigned int ve _sum4s (ve tor unsigned har,

ve tor unsigned int);
ve tor signed int ve _sum4s (ve tor signed har, ve tor signed int);
ve tor signed int ve _sum4s (ve tor signed short, ve tor signed int);
ve tor signed int ve _vsum4shs (ve tor signed short, ve tor signed int);
ve tor signed int ve _vsum4sbs (ve tor signed har, ve tor signed int);
ve tor unsigned int ve _vsum4ubs (ve tor unsigned har,
ve tor unsigned int);
ve tor signed int ve _sum2s (ve tor signed int, ve tor signed int);
ve tor signed int ve _sums (ve tor signed int, ve tor signed int);
ve tor float ve _trun (ve tor float);
ve tor
ve tor
ve tor
ve tor
ve tor

signed short ve _unpa kh (ve tor signed har);

bool short ve _unpa kh (ve tor bool har);
signed int ve _unpa kh (ve tor signed short);
bool int ve _unpa kh (ve tor bool short);
unsigned int ve _unpa kh (ve tor pixel);

ve tor bool int ve _vupkhsh (ve tor bool short);

ve tor signed int ve _vupkhsh (ve tor signed short);
ve tor unsigned int ve _vupkhpx (ve tor pixel);
ve tor bool short ve _vupkhsb (ve tor bool har);
ve tor signed short ve _vupkhsb (ve tor signed har);
ve tor signed short ve _unpa kl (ve tor signed har);
ve tor bool short ve _unpa kl (ve tor bool har);
ve tor unsigned int ve _unpa kl (ve tor pixel);

Chapter 5: Extensions to the C Language Family

ve tor signed int ve _unpa kl (ve tor signed short);

ve tor bool int ve _unpa kl (ve tor bool short);
ve tor unsigned int ve _vupklpx (ve tor pixel);
ve tor bool int ve _vupklsh (ve tor bool short);
ve tor signed int ve _vupklsh (ve tor signed short);
ve tor bool short ve _vupklsb (ve tor bool har);
ve tor signed short ve _vupklsb (ve tor signed har);
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
ve tor
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int

float ve _xor (ve tor float, ve tor float);

float ve _xor (ve tor float, ve tor bool int);
float ve _xor (ve tor bool int, ve tor float);
bool int ve _xor (ve tor bool int, ve tor bool int);
signed int ve _xor (ve tor bool int, ve tor signed int);
signed int ve _xor (ve tor signed int, ve tor bool int);
signed int ve _xor (ve tor signed int, ve tor signed int);
unsigned int ve _xor (ve tor bool int, ve tor unsigned int);
unsigned int ve _xor (ve tor unsigned int, ve tor bool int);
unsigned int ve _xor (ve tor unsigned int, ve tor unsigned int);
bool short ve _xor (ve tor bool short, ve tor bool short);
signed short ve _xor (ve tor bool short, ve tor signed short);
signed short ve _xor (ve tor signed short, ve tor bool short);
signed short ve _xor (ve tor signed short, ve tor signed short);
unsigned short ve _xor (ve tor bool short,
ve tor unsigned short);
unsigned short ve _xor (ve tor unsigned short,
ve tor bool short);
unsigned short ve _xor (ve tor unsigned short,
ve tor unsigned short);
signed har ve _xor (ve tor bool har, ve tor signed har);
bool har ve _xor (ve tor bool har, ve tor bool har);
signed har ve _xor (ve tor signed har, ve tor bool har);
signed har ve _xor (ve tor signed har, ve tor signed har);
unsigned har ve _xor (ve tor bool har, ve tor unsigned har);
unsigned har ve _xor (ve tor unsigned har, ve tor bool har);
unsigned har ve _xor (ve tor unsigned har,
ve tor unsigned har);

ve _all_eq
ve _all_eq
ve _all_eq
ve _all_eq
ve _all_eq
ve _all_eq
ve _all_eq
ve _all_eq
ve _all_eq
ve _all_eq
ve _all_eq
ve _all_eq
ve _all_eq
ve _all_eq
ve _all_eq
ve _all_eq
ve _all_eq
ve _all_eq

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

signed har, ve tor bool har);

signed har, ve tor signed har);
unsigned har, ve tor bool har);
unsigned har, ve tor unsigned har);
bool har, ve tor bool har);
bool har, ve tor unsigned har);
bool har, ve tor signed har);
signed short, ve tor bool short);
signed short, ve tor signed short);
unsigned short, ve tor bool short);
unsigned short, ve tor unsigned short);
bool short, ve tor bool short);
bool short, ve tor unsigned short);
bool short, ve tor signed short);
pixel, ve tor pixel);
signed int, ve tor bool int);
signed int, ve tor signed int);
unsigned int, ve tor bool int);

321

322

Using the GNU Compiler Colle tion (GCC)

int
int
int
int
int

ve _all_eq
ve _all_eq
ve _all_eq
ve _all_eq
ve _all_eq

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

unsigned int, ve tor unsigned int);

bool int, ve tor bool int);
bool int, ve tor unsigned int);
bool int, ve tor signed int);
float, ve tor float);

int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int

ve _all_ge
ve _all_ge
ve _all_ge
ve _all_ge
ve _all_ge
ve _all_ge
ve _all_ge
ve _all_ge
ve _all_ge
ve _all_ge
ve _all_ge
ve _all_ge
ve _all_ge
ve _all_ge
ve _all_ge
ve _all_ge
ve _all_ge
ve _all_ge
ve _all_ge

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

bool har, ve tor unsigned har);

unsigned har, ve tor bool har);
unsigned har, ve tor unsigned har);
bool har, ve tor signed har);
signed har, ve tor bool har);
signed har, ve tor signed har);
bool short, ve tor unsigned short);
unsigned short, ve tor bool short);
unsigned short, ve tor unsigned short);
signed short, ve tor signed short);
bool short, ve tor signed short);
signed short, ve tor bool short);
bool int, ve tor unsigned int);
unsigned int, ve tor bool int);
unsigned int, ve tor unsigned int);
bool int, ve tor signed int);
signed int, ve tor bool int);
signed int, ve tor signed int);
float, ve tor float);

int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int

ve _all_gt
ve _all_gt
ve _all_gt
ve _all_gt
ve _all_gt
ve _all_gt
ve _all_gt
ve _all_gt
ve _all_gt
ve _all_gt
ve _all_gt
ve _all_gt
ve _all_gt
ve _all_gt
ve _all_gt
ve _all_gt
ve _all_gt
ve _all_gt
ve _all_gt

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

bool har, ve tor unsigned har);

unsigned har, ve tor bool har);
unsigned har, ve tor unsigned har);
bool har, ve tor signed har);
signed har, ve tor bool har);
signed har, ve tor signed har);
bool short, ve tor unsigned short);
unsigned short, ve tor bool short);
unsigned short, ve tor unsigned short);
bool short, ve tor signed short);
signed short, ve tor bool short);
signed short, ve tor signed short);
bool int, ve tor unsigned int);
unsigned int, ve tor bool int);
unsigned int, ve tor unsigned int);
bool int, ve tor signed int);
signed int, ve tor bool int);
signed int, ve tor signed int);
float, ve tor float);

int ve _all_in (ve tor float, ve tor float);

int
int
int
int
int
int
int
int
int
int

ve _all_le
ve _all_le
ve _all_le
ve _all_le
ve _all_le
ve _all_le
ve _all_le
ve _all_le
ve _all_le
ve _all_le

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

bool har, ve tor unsigned har);

unsigned har, ve tor bool har);
unsigned har, ve tor unsigned har);
bool har, ve tor signed har);
signed har, ve tor bool har);
signed har, ve tor signed har);
bool short, ve tor unsigned short);
unsigned short, ve tor bool short);
unsigned short, ve tor unsigned short);
bool short, ve tor signed short);

Chapter 5: Extensions to the C Language Family

int
int
int
int
int
int
int
int
int

ve _all_le
ve _all_le
ve _all_le
ve _all_le
ve _all_le
ve _all_le
ve _all_le
ve _all_le
ve _all_le

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

signed short, ve tor bool short);

signed short, ve tor signed short);
bool int, ve tor unsigned int);
unsigned int, ve tor bool int);
unsigned int, ve tor unsigned int);
bool int, ve tor signed int);
signed int, ve tor bool int);
signed int, ve tor signed int);
float, ve tor float);

int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int

ve _all_lt
ve _all_lt
ve _all_lt
ve _all_lt
ve _all_lt
ve _all_lt
ve _all_lt
ve _all_lt
ve _all_lt
ve _all_lt
ve _all_lt
ve _all_lt
ve _all_lt
ve _all_lt
ve _all_lt
ve _all_lt
ve _all_lt
ve _all_lt
ve _all_lt

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

bool har, ve tor unsigned har);

unsigned har, ve tor bool har);
unsigned har, ve tor unsigned har);
bool har, ve tor signed har);
signed har, ve tor bool har);
signed har, ve tor signed har);
bool short, ve tor unsigned short);
unsigned short, ve tor bool short);
unsigned short, ve tor unsigned short);
bool short, ve tor signed short);
signed short, ve tor bool short);
signed short, ve tor signed short);
bool int, ve tor unsigned int);
unsigned int, ve tor bool int);
unsigned int, ve tor unsigned int);
bool int, ve tor signed int);
signed int, ve tor bool int);
signed int, ve tor signed int);
float, ve tor float);

int ve _all_nan (ve tor float);

int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int

ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne
ve _all_ne

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

signed har, ve tor bool har);

signed har, ve tor signed har);
unsigned har, ve tor bool har);
unsigned har, ve tor unsigned har);
bool har, ve tor bool har);
bool har, ve tor unsigned har);
bool har, ve tor signed har);
signed short, ve tor bool short);
signed short, ve tor signed short);
unsigned short, ve tor bool short);
unsigned short, ve tor unsigned short);
bool short, ve tor bool short);
bool short, ve tor unsigned short);
bool short, ve tor signed short);
pixel, ve tor pixel);
signed int, ve tor bool int);
signed int, ve tor signed int);
unsigned int, ve tor bool int);
unsigned int, ve tor unsigned int);
bool int, ve tor bool int);
bool int, ve tor unsigned int);
bool int, ve tor signed int);
float, ve tor float);

int ve _all_nge (ve tor float, ve tor float);

323

324

Using the GNU Compiler Colle tion (GCC)

int ve _all_ngt (ve tor float, ve tor float);

int ve _all_nle (ve tor float, ve tor float);
int ve _all_nlt (ve tor float, ve tor float);
int ve _all_numeri (ve tor float);
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int

ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq
ve _any_eq

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

signed har, ve tor bool har);

signed har, ve tor signed har);
unsigned har, ve tor bool har);
unsigned har, ve tor unsigned har);
bool har, ve tor bool har);
bool har, ve tor unsigned har);
bool har, ve tor signed har);
signed short, ve tor bool short);
signed short, ve tor signed short);
unsigned short, ve tor bool short);
unsigned short, ve tor unsigned short);
bool short, ve tor bool short);
bool short, ve tor unsigned short);
bool short, ve tor signed short);
pixel, ve tor pixel);
signed int, ve tor bool int);
signed int, ve tor signed int);
unsigned int, ve tor bool int);
unsigned int, ve tor unsigned int);
bool int, ve tor bool int);
bool int, ve tor unsigned int);
bool int, ve tor signed int);
float, ve tor float);

int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int

ve _any_ge
ve _any_ge
ve _any_ge
ve _any_ge
ve _any_ge
ve _any_ge
ve _any_ge
ve _any_ge
ve _any_ge
ve _any_ge
ve _any_ge
ve _any_ge
ve _any_ge
ve _any_ge
ve _any_ge
ve _any_ge
ve _any_ge
ve _any_ge
ve _any_ge

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

signed har, ve tor bool har);

unsigned har, ve tor bool har);
unsigned har, ve tor unsigned har);
signed har, ve tor signed har);
bool har, ve tor unsigned har);
bool har, ve tor signed har);
unsigned short, ve tor bool short);
unsigned short, ve tor unsigned short);
signed short, ve tor signed short);
signed short, ve tor bool short);
bool short, ve tor unsigned short);
bool short, ve tor signed short);
signed int, ve tor bool int);
unsigned int, ve tor bool int);
unsigned int, ve tor unsigned int);
signed int, ve tor signed int);
bool int, ve tor unsigned int);
bool int, ve tor signed int);
float, ve tor float);

int
int
int
int
int
int

ve _any_gt
ve _any_gt
ve _any_gt
ve _any_gt
ve _any_gt
ve _any_gt

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

bool har, ve tor unsigned har);

unsigned har, ve tor bool har);
unsigned har, ve tor unsigned har);
bool har, ve tor signed har);
signed har, ve tor bool har);
signed har, ve tor signed har);

Chapter 5: Extensions to the C Language Family

int
int
int
int
int
int
int
int
int
int
int
int
int

ve _any_gt
ve _any_gt
ve _any_gt
ve _any_gt
ve _any_gt
ve _any_gt
ve _any_gt
ve _any_gt
ve _any_gt
ve _any_gt
ve _any_gt
ve _any_gt
ve _any_gt

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

bool short, ve tor unsigned short);

unsigned short, ve tor bool short);
unsigned short, ve tor unsigned short);
bool short, ve tor signed short);
signed short, ve tor bool short);
signed short, ve tor signed short);
bool int, ve tor unsigned int);
unsigned int, ve tor bool int);
unsigned int, ve tor unsigned int);
bool int, ve tor signed int);
signed int, ve tor bool int);
signed int, ve tor signed int);
float, ve tor float);

int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int

ve _any_le
ve _any_le
ve _any_le
ve _any_le
ve _any_le
ve _any_le
ve _any_le
ve _any_le
ve _any_le
ve _any_le
ve _any_le
ve _any_le
ve _any_le
ve _any_le
ve _any_le
ve _any_le
ve _any_le
ve _any_le
ve _any_le

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

bool har, ve tor unsigned har);

unsigned har, ve tor bool har);
unsigned har, ve tor unsigned har);
bool har, ve tor signed har);
signed har, ve tor bool har);
signed har, ve tor signed har);
bool short, ve tor unsigned short);
unsigned short, ve tor bool short);
unsigned short, ve tor unsigned short);
bool short, ve tor signed short);
signed short, ve tor bool short);
signed short, ve tor signed short);
bool int, ve tor unsigned int);
unsigned int, ve tor bool int);
unsigned int, ve tor unsigned int);
bool int, ve tor signed int);
signed int, ve tor bool int);
signed int, ve tor signed int);
float, ve tor float);

int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int

ve _any_lt
ve _any_lt
ve _any_lt
ve _any_lt
ve _any_lt
ve _any_lt
ve _any_lt
ve _any_lt
ve _any_lt
ve _any_lt
ve _any_lt
ve _any_lt
ve _any_lt
ve _any_lt
ve _any_lt
ve _any_lt
ve _any_lt
ve _any_lt
ve _any_lt

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

bool har, ve tor unsigned har);

unsigned har, ve tor bool har);
unsigned har, ve tor unsigned har);
bool har, ve tor signed har);
signed har, ve tor bool har);
signed har, ve tor signed har);
bool short, ve tor unsigned short);
unsigned short, ve tor bool short);
unsigned short, ve tor unsigned short);
bool short, ve tor signed short);
signed short, ve tor bool short);
signed short, ve tor signed short);
bool int, ve tor unsigned int);
unsigned int, ve tor bool int);
unsigned int, ve tor unsigned int);
bool int, ve tor signed int);
signed int, ve tor bool int);
signed int, ve tor signed int);
float, ve tor float);

int ve _any_nan (ve tor float);

int ve _any_ne (ve tor signed har, ve tor bool har);
int ve _any_ne (ve tor signed har, ve tor signed har);

325

326

Using the GNU Compiler Colle tion (GCC)

int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int

ve _any_ne
ve _any_ne
ve _any_ne
ve _any_ne
ve _any_ne
ve _any_ne
ve _any_ne
ve _any_ne
ve _any_ne
ve _any_ne
ve _any_ne
ve _any_ne
ve _any_ne
ve _any_ne
ve _any_ne
ve _any_ne
ve _any_ne
ve _any_ne
ve _any_ne
ve _any_ne
ve _any_ne

(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor
(ve tor

unsigned har, ve tor bool har);

unsigned har, ve tor unsigned har);
bool har, ve tor bool har);
bool har, ve tor unsigned har);
bool har, ve tor signed har);
signed short, ve tor bool short);
signed short, ve tor signed short);
unsigned short, ve tor bool short);
unsigned short, ve tor unsigned short);
bool short, ve tor bool short);
bool short, ve tor unsigned short);
bool short, ve tor signed short);
pixel, ve tor pixel);
signed int, ve tor bool int);
signed int, ve tor signed int);
unsigned int, ve tor bool int);
unsigned int, ve tor unsigned int);
bool int, ve tor bool int);
bool int, ve tor unsigned int);
bool int, ve tor signed int);
float, ve tor float);

int ve _any_nge (ve tor float, ve tor float);

int ve _any_ngt (ve tor float, ve tor float);
int ve _any_nle (ve tor float, ve tor float);
int ve _any_nlt (ve tor float, ve tor float);
int ve _any_numeri (ve tor float);
int ve _any_out (ve tor float, ve tor float);

5.45.7 SPARC VIS Built-in Fun tions

GCC supports SIMD operations on the SPARC using both the generi ve tor extensions
(see Se tion 5.42 [Ve tor Extensions, page 271) as well as built-in fun tions for the SPARC
Visual Instru tion Set (VIS). When you use the `-mvis' swit h, the VIS extension is exposed
as the following built-in fun tions:
typedef
typedef
typedef
typedef
typedef

int v2si __attribute__ ((ve tor_size (8)));

short v4hi __attribute__ ((ve tor_size (8)));
short v2hi __attribute__ ((ve tor_size (4)));
har v8qi __attribute__ ((ve tor_size (8)));
har v4qi __attribute__ ((ve tor_size (4)));

void * __builtin_vis_alignaddr (void *, long);

int64_t __builtin_vis_faligndatadi (int64_t, int64_t);
v2si __builtin_vis_faligndatav2si (v2si, v2si);
v4hi __builtin_vis_faligndatav4hi (v4si, v4si);
v8qi __builtin_vis_faligndatav8qi (v8qi, v8qi);
v4hi __builtin_vis_fexpand (v4qi);
v4hi
v4hi
v4hi
v4hi

__builtin_vis_fmul8x16 (v4qi, v4hi);

__builtin_vis_fmul8x16au (v4qi, v4hi);
__builtin_vis_fmul8x16al (v4qi, v4hi);
__builtin_vis_fmul8sux16 (v8qi, v4hi);

Chapter 5: Extensions to the C Language Family

327

v4hi __builtin_vis_fmul8ulx16 (v8qi, v4hi);

v2si __builtin_vis_fmuld8sux16 (v4qi, v2hi);
v2si __builtin_vis_fmuld8ulx16 (v4qi, v2hi);
v4qi
v8qi
v2hi
v8qi

__builtin_vis_fpa k16 (v4hi);

__builtin_vis_fpa k32 (v2si, v2si);
__builtin_vis_fpa kfix (v2si);
__builtin_vis_fpmerge (v4qi, v4qi);

int64_t __builtin_vis_pdist (v8qi, v8qi, int64_t);

5.46 Format Che ks Spe i to Parti ular Target Ma hines

For some target ma hines, GCC supports additional options to the format attribute (see
Se tion 5.24 [De laring Attributes of Fun tions, page 217).

5.46.1 Solaris Format Che ks

Solaris targets support the mn_err (or __ mn_err__) format he k. mn_err a epts a subset of the standard printf onversions, and the two-argument %b onversion for displaying
bit-elds. See the Solaris man page for mn_err for more information.

5.47 Pragmas A epted by GCC

GCC supports several types of pragmas, primarily in order to ompile ode originally written
for other ompilers. Note that in general we do not re ommend the use of pragmas; See
Se tion 5.24 [Fun tion Attributes, page 217, for further explanation.

5.47.1 ARM Pragmas

The ARM target denes pragmas for ontrolling the default addition of long_ all and
short_ all attributes to fun tions. See Se tion 5.24 [Fun tion Attributes, page 217, for
information about the ee ts of these attributes.
long_ alls

Set all subsequent fun tions to have the long_ all attribute.

no_long_ alls

Set all subsequent fun tions to have the short_ all attribute.

long_ alls_off

Do not ae t the long_ all or short_ all attributes of subsequent fun tions.

5.47.2 RS/6000 and PowerPC Pragmas

The RS/6000 and PowerPC targets dene one pragma for ontrolling whether or not the
long all attribute is added to fun tion de larations by default. This pragma overrides the
`-mlong all' option, but not the long all and short all attributes. See Se tion 3.17.23
[RS/6000 and PowerPC Options, page 155, for more information about when long alls are
and are not ne essary.
long all (1)

Apply the long all attribute to all subsequent fun tion de larations.

long all (0)

Do not apply the long all attribute to subsequent fun tion de larations.

328

Using the GNU Compiler Colle tion (GCC)

5.47.3 Darwin Pragmas

The following pragmas are available for all ar hite tures running the Darwin operating
system. These are useful for ompatibility with other Ma OS ompilers.
mark tokens ...

This pragma is a epted, but has no ee t.

options align=alignment

This pragma sets the alignment of elds in stru tures. The values of alignment
may be ma 68k, to emulate m68k alignment, or power, to emulate PowerPC
alignment. Uses of this pragma nest properly; to restore the previous setting,
use reset for the alignment.

segment tokens ...

This pragma is a epted, but has no ee t.

unused (var [, var ...)

This pragma de lares variables to be possibly unused. GCC will not produ e
warnings for the listed variables. The ee t is similar to that of the unused
attribute, ex ept that this pragma may appear anywhere within the variables'
s opes.

5.47.4 Solaris Pragmas

The Solaris target supports #pragma redefine_extname (see Se tion 5.47.5 [SymbolRenaming Pragmas, page 328). It also supports additional #pragma dire tives for
ompatibility with the system ompiler.
align alignment (variable [, variable ...)

In rease the minimum alignment of ea h variable to alignment. This is the same

as GCC's aligned attribute see Se tion 5.31 [Variable Attributes, page 233).
Ma ro expansion o urs on the arguments to this pragma when ompiling C
and Obje tive-C. It does not urrently o ur when ompiling C++, but this is
a bug whi h may be xed in a future release.

fini (fun tion [, fun tion ...)

This pragma auses ea h listed fun tion to be alled after main, or during shared
module unloading, by adding a all to the .fini se tion.

init (fun tion [, fun tion ...)

This pragma auses ea h listed fun tion to be alled during initialization (before
main) or during shared module loading, by adding a all to the .init se tion.

5.47.5 Symbol-Renaming Pragmas

For ompatibility with the Solaris and Tru64 UNIX system headers, GCC supports two
#pragma dire tives whi h hange the name used in assembly for a given de laration. These
pragmas are only available on platforms whose system headers need them. To get this ee t
on all platforms supported by GCC, use the asm labels extension (see Se tion 5.36 [Asm
Labels, page 265).

Chapter 5: Extensions to the C Language Family

329

redefine_extname oldname newname

This pragma gives the C fun tion oldname the assembly symbol newname. The
prepro essor ma ro __PRAGMA_REDEFINE_EXTNAME will be dened if this pragma
is available ( urrently only on Solaris).

extern_prefix string

This pragma auses all subsequent external fun tion and variable de larations to
have string prepended to their assembly symbols. This ee t may be terminated
with another extern_prefix pragma whose argument is an empty string. The
prepro essor ma ro __PRAGMA_EXTERN_PREFIX will be dened if this pragma is
available ( urrently only on Tru64 UNIX).

These pragmas and the asm labels extension intera t in a ompli ated manner. Here are
some orner ases you may want to be aware of.
1. Both pragmas silently apply only to de larations with external linkage. Asm labels do
not have this restri tion.
2. In C++, both pragmas silently apply only to de larations with \C" linkage. Again, asm
labels do not have this restri tion.
3. If any of the three ways of hanging the assembly name of a de laration is applied to
a de laration whose assembly name has already been determined (either by a previous
use of one of these features, or be ause the ompiler needed the assembly name in order
to generate ode), and the new name is dierent, a warning issues and the name does
not hange.
4. The oldname used by #pragma redefine_extname is always the C-language name.
5. If #pragma extern_prefix is in ee t, and a de laration o urs with an asm label
atta hed, the prex is silently ignored for that de laration.
6. If #pragma extern_prefix and #pragma redefine_extname apply to the same de laration, whi hever triggered rst wins, and a warning issues if they ontradi t ea h other.
(We would like to have #pragma redefine_extname always win, for onsisten y with
asm labels, but if #pragma extern_prefix triggers rst we have no way of knowing
that that happened.)

5.47.6 Stru ture-Pa king Pragmas

For ompatibility with Win32, GCC supports a set of #pragma dire tives whi h hange the
maximum alignment of members of stru tures, unions, and lasses subsequently dened.
The n value below always is required to be a small power of two and spe ies the new
alignment in bytes.
1. #pragma pa k(n ) simply sets the new alignment.
2. #pragma pa k() sets the alignment to the one that was in ee t when ompilation
started (see also ommand line option `-fpa k-stru t[=<n>' see Se tion 3.18 [Code
Gen Options, page 178).
3. #pragma pa k(push[,n ) pushes the urrent alignment setting on an internal sta k
and then optionally sets the new alignment.
4. #pragma pa k(pop) restores the alignment setting to the one saved at the top of the
internal sta k (and removes that sta k entry). Note that #pragma pa k([n ) does not

330

Using the GNU Compiler Colle tion (GCC)

in uen e this internal sta k; thus it is possible to have #pragma pa k(push) followed
by multiple #pragma pa k(n ) instan es and nalized by a single #pragma pa k(pop).

5.47.7 Weak Pragmas

For ompatibility with SVR4, GCC supports a set of #pragma dire tives for de laring symbols to be weak, and dening weak aliases.
#pragma weak symbol

This pragma de lares symbol to be weak, as if the de laration had the attribute
of the same name. The pragma may appear before or after the de laration of
symbol, but must appear before either its rst use or its denition. It is not an
error for symbol to never be dened at all.

#pragma weak symbol1 = symbol2

This pragma de lares symbol1 to be a weak alias of symbol2. It is an error if

symbol2 is not dened in the urrent translation unit.

5.48 Unnamed stru t/union elds within stru ts/unions

For ompatibility with other ompilers, GCC allows you to dene a stru ture or union that
ontains, as elds, stru tures and unions without names. For example:
stru t {
int a;
union {
int b;
float ;
};
int d;
} foo;

In this example, the user would be able to a ess members of the unnamed union with
ode like `foo.b'. Note that only unnamed stru ts and unions are allowed, you may not
have, for example, an unnamed int.
You must never reate su h stru tures that ause ambiguous eld denitions. For example, this stru ture:
stru t {
int a;
stru t {
int a;
};
} foo;

It is ambiguous whi h a is being referred to with `foo.a'. Su h onstru ts are not supported and must be avoided. In the future, su h onstru ts may be dete ted and treated
as ompilation errors.
Unless `-fms-extensions' is used, the unnamed eld must be a stru ture or union denition without a tag (for example, `stru t { int a; };'). If `-fms-extensions' is used, the
eld may also be a denition with a tag su h as `stru t foo { int a; };', a referen e to
a previously dened stru ture or union su h as `stru t foo;', or a referen e to a typedef
name for a previously dened stru ture or union type.

Chapter 5: Extensions to the C Language Family

331

5.49 Thread-Lo al Storage

Thread-lo al storage (TLS) is a me hanism by whi h variables are allo ated su h that there
is one instan e of the variable per extant thread. The run-time model GCC uses to implement this originates in the IA-64 pro essor-spe i ABI, but has sin e been migrated
to other pro essors as well. It requires signi ant support from the linker (ld), dynami
linker (ld.so), and system libraries (`lib .so' and `libpthread.so'), so it is not available
everywhere.
At the user level, the extension is visible with a new storage lass keyword: __thread.
For example:
__thread int i;
extern __thread stru t state s;
stati __thread har *p;

The __thread spe ier may be used alone, with the extern or stati spe iers, but
with no other storage lass spe ier. When used with extern or stati , __thread must
appear immediately after the other storage lass spe ier.
The __thread spe ier may be applied to any global, le-s oped stati , fun tion-s oped
stati , or stati data member of a lass. It may not be applied to blo k-s oped automati
or non-stati data member.
When the address-of operator is applied to a thread-lo al variable, it is evaluated at
run-time and returns the address of the urrent thread's instan e of that variable. An
address so obtained may be used by any thread. When a thread terminates, any pointers
to thread-lo al variables in that thread be ome invalid.
No stati initialization may refer to the address of a thread-lo al variable.
In C++, if an initializer is present for a thread-lo al variable, it must be a onstantexpression, as dened in 5.19.2 of the ANSI/ISO C++ standard.
See ELF Handling For Thread-Lo al Storage (http://people.redhat. om/drepper/tls.pdf)
for a detailed explanation of the four thread-lo al storage addressing models, and how the
run-time is expe ted to fun tion.

5.49.1 ISO/IEC 9899:1999 Edits for Thread-Lo al Storage

The following are a set of hanges to ISO/IEC 9899:1999 (aka C99) that do ument the
exa t semanti s of the language extension.
 5.1.2 Exe ution environments
Add new text after paragraph 1
Within either exe ution environment, a thread is a ow of ontrol within
a program. It is implementation dened whether or not there may be
more than one thread asso iated with a program. It is implementation
dened how threads beyond the rst are reated, the name and type of
the fun tion alled at thread startup, and how threads may be terminated.
However, obje ts with thread storage duration shall be initialized before
thread startup.
 6.2.4 Storage durations of obje ts
Add new text before paragraph 3

332




Using the GNU Compiler Colle tion (GCC)

An obje t whose identier is de lared with the storage- lass spe ier

__thread has thread storage duration. Its lifetime is the entire exe ution
of the thread, and its stored value is initialized only on e, prior to thread
startup.
6.4.1 Keywords
Add __thread.
6.7.1 Storage- lass spe iers
Add __thread to the list of storage lass spe iers in paragraph 1.
Change paragraph 2 to
With the ex eption of __thread, at most one storage- lass spe ier may
be given [. . . . The __thread spe ier may be used alone, or immediately
following extern or stati .
Add new text after paragraph 6
The de laration of an identier for a variable that has blo k s ope that
spe ies __thread shall also spe ify either extern or stati .
The __thread spe ier shall be used only with variables.

5.49.2 ISO/IEC 14882:1998 Edits for Thread-Lo al Storage

The following are a set of hanges to ISO/IEC 14882:1998 (aka C++98) that do ument the
exa t semanti s of the language extension.




[intro.exe ution

New text after paragraph 4

A thread is a ow of ontrol within the abstra t ma hine. It is implementation dened whether or not there may be more than one thread.
New text after paragraph 7
It is unspe ied whether additional a tion must be taken to ensure when
and whether side ee ts are visible to other threads.
[lex.key

Add __thread.
[basi .start.main

Add after paragraph 5

The thread that begins exe ution at the main fun tion is alled the main
thread. It is implementation dened how fun tions beginning threads other
than the main thread are designated or typed. A fun tion so designated,
as well as the main fun tion, is alled a thread startup fun tion. It is implementation dened what happens if a thread startup fun tion returns. It
is implementation dened what happens to other threads when any thread
alls exit.
[basi .start.init

Add after paragraph 4

The storage for an obje t of thread storage duration shall be stati ally
initialized before the rst statement of the thread startup fun tion. An
obje t of thread storage duration shall not require dynami initialization.

Chapter 5: Extensions to the C Language Family




[basi .start.term

Add after paragraph 3

The type of an obje t with thread storage duration shall not have a nontrivial destru tor, nor shall it be an array type whose elements (dire tly or
indire tly) have non-trivial destru tors.
[basi .st

Add \thread storage duration" to the list in paragraph 1.

Change paragraph 2
Thread, stati , and automati storage durations are asso iated with obje ts
introdu ed by de larations [. . . .
Add __thread to the list of spe iers in paragraph 3.
[basi .st .thread

New se tion before [basi .st .stati

The keyword __thread applied to a non-lo al obje t gives the obje t thread
storage duration.
A lo al variable or lass data member de lared both stati and __thread
gives the variable or member thread storage duration.
[basi .st .stati

Change paragraph 1
All obje ts whi h have neither thread storage duration, dynami storage
duration nor are lo al [. . . .
[d l.st

Add __thread to the list in paragraph 1.

Change paragraph 1
With the ex eption of __thread, at most one storage- lass-spe ier shall
appear in a given de l-spe ier-seq. The __thread spe ier may be used
alone, or immediately following the extern or stati spe iers. [. . .
Add after paragraph 5
The __thread spe ier an be applied only to the names of obje ts and to
anonymous unions.
[ lass.mem

Add after paragraph 6

Non-stati members shall not be __thread.

333

334

Using the GNU Compiler Colle tion (GCC)

Chapter 6: Extensions to the C++ Language

335

6 Extensions to the C++ Language

The GNU ompiler provides these extensions to the C++ language (and you an also use
most of the C language extensions in your C++ programs). If you want to write ode
that he ks whether these features are available, you an test for the GNU ompiler the
same way as for C programs: he k for a predened ma ro __GNUC__. You an also use
__GNUG__ to test spe i ally for GNU C++ (see se tion \Predened Ma ros" in The GNU
C Prepro essor).

6.1 When is a Volatile Obje t A essed?

Both the C and C++ standard have the on ept of volatile obje ts. These are normally
a essed by pointers and used for a essing hardware. The standards en ourage ompilers
to refrain from optimizations on erning a esses to volatile obje ts that it might perform on
non-volatile obje ts. The C standard leaves it implementation dened as to what onstitutes
a volatile a ess. The C++ standard omits to spe ify this, ex ept to say that C++ should
behave in a similar manner to C with respe t to volatiles, where possible. The minimum
either standard spe ies is that at a sequen e point all previous a esses to volatile obje ts
have stabilized and no subsequent a esses have o urred. Thus an implementation is free
to reorder and ombine volatile a esses whi h o ur between sequen e points, but annot
do so for a esses a ross a sequen e point. The use of volatiles does not allow you to violate
the restri tion on updating obje ts multiple times within a sequen e point.
In most expressions, it is intuitively obvious what is a read and what is a write. For
instan e
volatile int *dst = somevalue ;
volatile int *sr = someothervalue ;
*dst = *sr ;

will ause a read of the volatile obje t pointed to by sr and stores the value into the volatile
obje t pointed to by dst. There is no guarantee that these reads and writes are atomi ,
espe ially for obje ts larger than int.
Less obvious expressions are where something whi h looks like an a ess is used in a void
ontext. An example would be,
volatile int *sr = somevalue ;
*sr ;

With C, su h expressions are rvalues, and as rvalues ause a read of the obje t, GCC
interprets this as a read of the volatile being pointed to. The C++ standard spe ies that
su h expressions do not undergo lvalue to rvalue onversion, and that the type of the
dereferen ed obje t may be in omplete. The C++ standard does not spe ify expli itly that
it is this lvalue to rvalue onversion whi h is responsible for ausing an a ess. However,
there is reason to believe that it is, be ause otherwise ertain simple expressions be ome
undened. However, be ause it would surprise most programmers, G++ treats dereferen ing
a pointer to volatile obje t of omplete type in a void ontext as a read of the obje t. When
the obje t has in omplete type, G++ issues a warning.
stru t S;
stru t T {int m;};
volatile S *ptr1 = somevalue ;
volatile T *ptr2 = somevalue ;
*ptr1;

336

Using the GNU Compiler Colle tion (GCC)

*ptr2;

In this example, a warning is issued for *ptr1, and *ptr2 auses a read of the obje t
pointed to. If you wish to for e an error on the rst ase, you must for e a onversion to
rvalue with, for instan e a stati ast, stati _ ast<S>(*ptr1).
When using a referen e to volatile, G++ does not treat equivalent expressions as a esses
to volatiles, but instead issues a warning that no volatile is a essed. The rationale for
this is that otherwise it be omes di ult to determine where volatile a ess o ur, and not
possible to ignore the return value from fun tions returning volatile referen es. Again, if
you wish to for e a read, ast the referen e to an rvalue.

6.2 Restri ting Pointer Aliasing

As with the C front end, G++ understands the C99 feature of restri ted pointers, spe ied
with the __restri t__, or __restri t type qualier. Be ause you annot ompile C++ by
spe ifying the `-std= 99' language ag, restri t is not a keyword in C++.
In addition to allowing restri ted pointers, you an spe ify restri ted referen es, whi h
indi ate that the referen e is not aliased in the lo al ontext.
void fn (int *__restri t__ rptr, int &__restri t__ rref)
{
/* . . . */
}

In the body of fn, rptr points to an unaliased integer and rref refers to a (dierent) unaliased
integer.
You may also spe ify whether a member fun tion's this pointer is unaliased by using
__restri t__ as a member fun tion qualier.
void T::fn () __restri t__
{
/* . . . */
}

Within the body of T::fn, this will have the ee tive denition T *__restri t__ onst
this. Noti e that the interpretation of a __restri t__ member fun tion qualier is dierent to that of onst or volatile qualier, in that it is applied to the pointer rather than
the obje t. This is onsistent with other ompilers whi h implement restri ted pointers.
As with all outermost parameter qualiers, __restri t__ is ignored in fun tion denition
mat hing. This means you only need to spe ify __restri t__ in a fun tion denition,
rather than in a fun tion prototype as well.

6.3 Vague Linkage

There are several onstru ts in C++ whi h require spa e in the obje t le but are not
learly tied to a single translation unit. We say that these onstru ts have \vague linkage".
Typi ally su h onstru ts are emitted wherever they are needed, though sometimes we an
be more lever.
Inline Fun tions
Inline fun tions are typi ally dened in a header le whi h an be in luded
in many dierent ompilations. Hopefully they an usually be inlined, but
sometimes an out-of-line opy is ne essary, if the address of the fun tion is taken

Chapter 6: Extensions to the C++ Language

337

or if inlining fails. In general, we emit an out-of-line opy in all translation units

where one is needed. As an ex eption, we only emit inline virtual fun tions with
the vtable, sin e it will always require a opy.
Lo al stati variables and string onstants used in an inline fun tion are also
onsidered to have vague linkage, sin e they must be shared between all inlined
and out-of-line instan es of the fun tion.
VTables C++ virtual fun tions are implemented in most ompilers using a lookup table,
known as a vtable. The vtable ontains pointers to the virtual fun tions provided by a lass, and ea h obje t of the lass ontains a pointer to its vtable (or
vtables, in some multiple-inheritan e situations). If the lass de lares any noninline, non-pure virtual fun tions, the rst one is hosen as the \key method"
for the lass, and the vtable is only emitted in the translation unit where the
key method is dened.
Note: If the hosen key method is later dened as inline, the vtable will still
be emitted in every translation unit whi h denes it. Make sure that any inline
virtuals are de lared inline in the lass body, even if they are not dened there.
type info obje ts
C++ requires information about types to be written out in order to implement
`dynami _ ast', `typeid' and ex eption handling. For polymorphi lasses
( lasses with virtual fun tions), the type info obje t is written out along with
the vtable so that `dynami _ ast' an determine the dynami type of a lass
obje t at runtime. For all other types, we write out the type info obje t when
it is used: when applying `typeid' to an expression, throwing an obje t, or
referring to a type in a at h lause or ex eption spe i ation.
Template Instantiations
Most everything in this se tion also applies to template instantiations, but there
are other options as well. See Se tion 6.5 [Where's the Template?, page 339.
When used with GNU ld version 2.8 or later on an ELF system su h as GNU/Linux or
Solaris 2, or on Mi rosoft Windows, dupli ate opies of these onstru ts will be dis arded
at link time. This is known as COMDAT support.
On targets that don't support COMDAT, but do support weak symbols, GCC will use
them. This way one opy will override all the others, but the unused opies will still take
up spa e in the exe utable.
For targets whi h do not support either COMDAT or weak symbols, most entities with
vague linkage will be emitted as lo al symbols to avoid dupli ate denition errors from the
linker. This will not happen for lo al stati s in inlines, however, as having multiple opies
will almost ertainly break things.
See Se tion 6.4 [De larations and Denitions in One Header, page 337, for another way
to ontrol pla ement of these onstru ts.

6.4 #pragma interfa e and implementation

#pragma interfa e and #pragma implementation provide the user with a way of expli itly
dire ting the ompiler to emit entities with vague linkage (and debugging information) in a
parti ular translation unit.

338

Using the GNU Compiler Colle tion (GCC)

Note: As of GCC 2.7.2, these #pragmas are not useful in most ases, be ause of COMDAT
support and the \key method" heuristi mentioned in Se tion 6.3 [Vague Linkage, page 336.
Using them an a tually ause your program to grow due to unne essary out-of-line opies
of inline fun tions. Currently (3.4) the only benet of these #pragmas is redu ed dupli ation
of debugging information, and that should be addressed soon on DWARF 2 targets with
the use of COMDAT groups.
#pragma interfa e
#pragma interfa e "subdir /obje ts.h"

Use this dire tive in header les that dene obje t lasses, to save spa e in
most of the obje t les that use those lasses. Normally, lo al opies of ertain
information (ba kup opies of inline member fun tions, debugging information,
and the internal tables that implement virtual fun tions) must be kept in ea h
obje t le that in ludes lass denitions. You an use this pragma to avoid su h
dupli ation. When a header le ontaining `#pragma interfa e' is in luded in
a ompilation, this auxiliary information will not be generated (unless the main
input sour e le itself uses `#pragma implementation'). Instead, the obje t
les will ontain referen es to be resolved at link time.
The se ond form of this dire tive is useful for the ase where you have multiple
headers with the same name in dierent dire tories. If you use this form, you
must spe ify the same string to `#pragma implementation'.

#pragma implementation
#pragma implementation "obje ts.h"

Use this pragma in a main input le, when you want full output from in luded
header les to be generated (and made globally visible). The in luded header
le, in turn, should use `#pragma interfa e'. Ba kup opies of inline member
fun tions, debugging information, and the internal tables used to implement
virtual fun tions are all generated in implementation les.
If you use `#pragma implementation' with no argument, it applies to an
in lude le with the same basename1 as your sour e le. For example, in
`all lass. ', giving just `#pragma implementation' by itself is equivalent
to `#pragma implementation "all lass.h"'.
In versions of GNU C++ prior to 2.6.0 `all lass.h' was treated as an implementation le whenever you would in lude it from `all lass. ' even if
you never spe ied `#pragma implementation'. This was deemed to be more
trouble than it was worth, however, and disabled.
Use the string argument if you want a single implementation le to in lude ode
from multiple header les. (You must also use `#in lude' to in lude the header
le; `#pragma implementation' only spe ies how to use the le|it doesn't
a tually in lude it.)
There is no way to split up the ontents of a single header le into multiple
implementation les.

A le's basename was the name stripped of all leading path information and of trailing suxes, su h as
`.h' or `.C' or `. '.

Chapter 6: Extensions to the C++ Language

339

`#pragma implementation' and `#pragma interfa e' also have an ee t on fun tion inlining.
If you dene a lass in a header le marked with `#pragma interfa e', the ee t on
an inline fun tion dened in that lass is similar to an expli it extern de laration|the
ompiler emits no ode at all to dene an independent version of the fun tion. Its denition
is used only for inlining with its allers.
Conversely, when you in lude the same header le in a main sour e le that de lares it
as `#pragma implementation', the ompiler emits ode for the fun tion itself; this denes
a version of the fun tion that an be found via pointers (or by allers ompiled without
inlining). If all alls to the fun tion an be inlined, you an avoid emitting the fun tion
by ompiling with `-fno-implement-inlines'. If any alls were not inlined, you will get
linker errors.

6.5 Where's the Template?

C++ templates are the rst language feature to require more intelligen e from the environment than one usually nds on a UNIX system. Somehow the ompiler and linker have to
make sure that ea h template instan e o urs exa tly on e in the exe utable if it is needed,
and not at all otherwise. There are two basi approa hes to this problem, whi h are referred
to as the Borland model and the Cfront model.
Borland model
Borland C++ solved the template instantiation problem by adding the ode
equivalent of ommon blo ks to their linker; the ompiler emits template instan es in ea h translation unit that uses them, and the linker ollapses them
together. The advantage of this model is that the linker only has to onsider the
obje t les themselves; there is no external omplexity to worry about. This
disadvantage is that ompilation time is in reased be ause the template ode
is being ompiled repeatedly. Code written for this model tends to in lude
denitions of all templates in the header le, sin e they must be seen to be
instantiated.
Cfront model
The AT&T C++ translator, Cfront, solved the template instantiation problem
by reating the notion of a template repository, an automati ally maintained
pla e where template instan es are stored. A more modern version of the repository works as follows: As individual obje t les are built, the ompiler pla es
any template denitions and instantiations en ountered in the repository. At
link time, the link wrapper adds in the obje ts in the repository and ompiles
any needed instan es that were not previously emitted. The advantages of this
model are more optimal ompilation speed and the ability to use the system
linker; to implement the Borland model a ompiler vendor also needs to repla e
the linker. The disadvantages are vastly in reased omplexity, and thus potential for error; for some ode this an be just as transparent, but in pra ti e
it an been very di ult to build multiple programs in one dire tory and one
program in multiple dire tories. Code written for this model tends to separate
denitions of non-inline member templates into a separate le, whi h should be
ompiled separately.

340

Using the GNU Compiler Colle tion (GCC)

When used with GNU ld version 2.8 or later on an ELF system su h as GNU/Linux or
Solaris 2, or on Mi rosoft Windows, G++ supports the Borland model. On other systems,
G++ implements neither automati model.
A future version of G++ will support a hybrid model whereby the ompiler will emit
any instantiations for whi h the template denition is in luded in the ompile, and store
template denitions and instantiation ontext information into the obje t le for the rest.
The link wrapper will extra t that information as ne essary and invoke the ompiler to
produ e the remaining instantiations. The linker will then ombine dupli ate instantiations.
In the mean time, you have the following options for dealing with template instantiations:
1. Compile your template-using ode with `-frepo'. The ompiler will generate les with
the extension `.rpo' listing all of the template instantiations used in the orresponding
obje t les whi h ould be instantiated there; the link wrapper, ` olle t2', will then
update the `.rpo' les to tell the ompiler where to pla e those instantiations and
rebuild any ae ted obje t les. The link-time overhead is negligible after the rst
pass, as the ompiler will ontinue to pla e the instantiations in the same les.
This is your best option for appli ation ode written for the Borland model, as it will
just work. Code written for the Cfront model will need to be modied so that the
template denitions are available at one or more points of instantiation; usually this is
as simple as adding #in lude <tmethods. > to the end of ea h template header.
For library ode, if you want the library to provide all of the template instantiations
it needs, just try to link all of its obje t les together; the link will fail, but ause
the instantiations to be generated as a side ee t. Be warned, however, that this may
ause on i ts if multiple libraries try to provide the same instantiations. For greater
ontrol, use expli it instantiation as des ribed in the next option.
2. Compile your ode with `-fno-impli it-templates' to disable the impli it generation
of template instan es, and expli itly instantiate all the ones you use. This approa h
requires more knowledge of exa tly whi h instan es you need than do the others, but it's
less mysterious and allows greater ontrol. You an s atter the expli it instantiations
throughout your program, perhaps putting them in the translation units where the
instan es are used or the translation units that dene the templates themselves; you
an put all of the expli it instantiations you need into one big le; or you an reate
small les like
#in lude "Foo.h"
#in lude "Foo. "

template lass Foo<int>;

template ostream& operator <<
(ostream&, onst Foo<int>&);

for ea h of the instan es you need, and reate a template instantiation library from
those.
If you are using Cfront-model ode, you an probably get away with not using
`-fno-impli it-templates' when ompiling les that don't `#in lude' the member
template denitions.
If you use one big le to do the instantiations, you may want to ompile it without
`-fno-impli it-templates' so you get all of the instan es required by your expli it
instantiations (but not by any other les) without having to spe ify them as well.

Chapter 6: Extensions to the C++ Language

341

G++ has extended the template instantiation syntax given in the ISO standard to
allow forward de laration of expli it instantiations (with extern), instantiation of the
ompiler support data for a template lass (i.e. the vtable) without instantiating any
of its members (with inline), and instantiation of only the stati data members of a
template lass, without the support data or member fun tions (with (stati ):
extern template int max (int, int);
inline template lass Foo<int>;
stati template lass Foo<int>;

3. Do nothing. Pretend G++ does implement automati instantiation management. Code

written for the Borland model will work ne, but ea h translation unit will ontain
instan es of ea h of the templates it uses. In a large program, this an lead to an
una eptable amount of ode dupli ation.

6.6 Extra ting the fun tion pointer from a bound pointer to
member fun tion
In C++, pointer to member fun tions (PMFs) are implemented using a wide pointer of sorts
to handle all the possible all me hanisms; the PMF needs to store information about how
to adjust the `this' pointer, and if the fun tion pointed to is virtual, where to nd the
vtable, and where in the vtable to look for the member fun tion. If you are using PMFs in
an inner loop, you should really re onsider that de ision. If that is not an option, you an
extra t the pointer to the fun tion that would be alled for a given obje t/PMF pair and
all it dire tly inside the inner loop, to save a bit of time.
Note that you will still be paying the penalty for the all through a fun tion pointer; on
most modern ar hite tures, su h a all defeats the bran h predi tion features of the CPU.
This is also true of normal virtual fun tion alls.
The syntax for this extension is
extern A a;
extern int (A::*fp)();
typedef int (*fptr)(A *);
fptr p = (fptr)(a.*fp);

For PMF onstants (i.e. expressions of the form `&Klasse::Member'), no obje t is needed
to obtain the address of the fun tion. They an be onverted to fun tion pointers dire tly:
fptr p1 = (fptr)(&A::foo);

You must spe ify `-Wno-pmf- onversions' to use this extension.

6.7 C++-Spe i Variable, Fun tion, and Type Attributes

Some attributes only make sense for C++ programs.
init_priority (priority )
In Standard C++, obje ts dened at namespa e s ope are guaranteed to be

initialized in an order in stri t a ordan e with that of their denitions in a given

translation unit. No guarantee is made for initializations a ross translation
units. However, GNU C++ allows users to ontrol the order of initialization
of obje ts dened at namespa e s ope with the init_priority attribute by
spe ifying a relative priority, a onstant integral expression urrently bounded
between 101 and 65535 in lusive. Lower numbers indi ate a higher priority.

342

Using the GNU Compiler Colle tion (GCC)

In the following example, A would normally be reated before B, but the init_
priority attribute has reversed that order:
Some_Class
Some_Class

A __attribute__ ((init_priority (2000)));

B __attribute__ ((init_priority (543)));

Note that the parti ular values of priority do not matter; only their relative
ordering.
java_interfa e

This type attribute informs C++ that the lass is a Java interfa e. It may
only be applied to lasses de lared within an extern "Java" blo k. Calls to
methods de lared in this interfa e will be dispat hed using GCJ's interfa e table
me hanism, instead of regular virtual table dispat h.
See also See Se tion 6.8 [Strong Using, page 342.

6.8 Strong Using

The semanti s of this extension are not fully dened. Users should refrain from
using this extension as its semanti s may hange subtly over time. It is possible that this
extension wil be removed in future versions of G++.
A using-dire tive with __attribute ((strong)) is stronger than a normal using-dire tive
in two ways:
 Templates from the used namespa e an be spe ialized as though they were members
of the using namespa e.
 The using namespa e is onsidered an asso iated namespa e of all templates in the
used namespa e for purposes of argument-dependent name lookup.
This is useful for omposing a namespa e transparently from implementation namespa es.
For example:
Caution:

namespa e std {
namespa e debug {
template < lass T> stru t A { };
}
using namespa e debug __attribute ((__strong__));
template <> stru t A<int> { };
// ok to spe ialize

template < lass T> void f (A<T>);

int main()
{
f (std::A<float>());
f (std::A<int>());
}

// lookup nds std::f

6.9 Java Ex eptions

The Java language uses a slightly dierent ex eption handling model from C++. Normally, GNU C++ will automati ally dete t when you are writing C++ ode that uses Java
ex eptions, and handle them appropriately. However, if C++ ode only needs to exe ute destru tors when Java ex eptions are thrown through it, GCC will guess in orre tly. Sample
problemati ode is:

Chapter 6: Extensions to the C++ Language

stru t S { ~S(); };
extern void bar();
void foo()
{
S s;
bar();
}

343

// is written in Java, and may throw ex eptions

The usual ee t of an in orre t guess is a link failure, omplaining of a missing routine

alled `__gxx_personality_v0'.
You an inform the ompiler that Java ex eptions are to be used in a translation unit,
irrespe tive of what it might think, by writing `#pragma GCC java_ex eptions' at the head
of the le. This `#pragma' must appear before any fun tions that throw or at h ex eptions,
or run destru tors when ex eptions are thrown through them.
You annot mix Java and C++ ex eptions in the same translation unit. It is believed to
be safe to throw a C++ ex eption from one le through another le ompiled for the Java
ex eption model, or vi e versa, but there may be bugs in this area.

6.10 Depre ated Features

In the past, the GNU C++ ompiler was extended to experiment with new features, at a
time when the C++ language was still evolving. Now that the C++ standard is omplete,
some of those features are superseded by superior alternatives. Using the old features might
ause a warning in some ases that the feature will be dropped in the future. In other ases,
the feature might be gone already.
While the list below is not exhaustive, it do uments some of the options that are now
depre ated:
-fexternal-templates
-falt-external-templates

These are two of the many ways for G++ to implement template instantiation.
See Se tion 6.5 [Template Instantiation, page 339. The C++ standard learly
denes how template denitions have to be organized a ross implementation
units. G++ has an impli it instantiation me hanism that should work just ne
for standard- onforming ode.

-fstri t-prototype
-fno-stri t-prototype

Previously it was possible to use an empty prototype parameter list to indi ate
an unspe ied number of parameters (like C), rather than no parameters, as
C++ demands. This feature has been removed, ex ept where it is required for
ba kwards ompatibility See Se tion 6.11 [Ba kwards Compatibility, page 344.
G++ allows a virtual fun tion returning `void *' to be overridden by one returning a
dierent pointer type. This extension to the ovariant return type rules is now depre ated
and will be removed from a future version.
The G++ minimum and maximum operators (`<?' and `>?') and their ompound forms
(`<?=') and `>?=') have been depre ated and will be removed in a future version. Code using
these operators should be modied to use std::min and std::max instead.
The named return value extension has been depre ated, and is now removed from G++.

344

Using the GNU Compiler Colle tion (GCC)

The use of initializer lists with new expressions has been depre ated, and is now removed
from G++.
Floating and omplex non-type template parameters have been depre ated, and are now
removed from G++.
The impli it typename extension has been depre ated and is now removed from G++.
The use of default arguments in fun tion pointers, fun tion typedefs and and other pla es
where they are not permitted by the standard is depre ated and will be removed from a
future version of G++.
G++ allows oating-point literals to appear in integral onstant expressions, e.g. ` enum
E { e = int(2.2 * 3.7) } ' This extension is depre ated and will be removed from a future
version.
G++ allows stati data members of onst oating-point type to be de lared with an
initializer in a lass denition. The standard only allows initializers for stati members of
onst integral types and onst enumeration types so this extension has been depre ated and
will be removed from a future version.

6.11 Ba kwards Compatibility

Now that there is a denitive ISO standard C++, G++ has a spe i ation to adhere to.
The C++ language evolved over time, and features that used to be a eptable in previous
drafts of the standard, su h as the ARM [Annotated C++ Referen e Manual, are no longer
a epted. In order to allow ompilation of C++ written to su h drafts, G++ ontains some
ba kwards ompatibilities. All su h ba kwards ompatibility features are liable to disappear in future versions of G++. They should be onsidered depre ated See Se tion 6.10
[Depre ated Features, page 343.
For s ope If a variable is de lared at for s ope, it used to remain in s ope until the end
of the s ope whi h ontained the for statement (rather than just within the for
s ope). G++ retains this, but issues a warning, if su h a variable is a essed
outside the for s ope.
Impli it C language

Old C system header les did not ontain an extern "C" {...} s ope to set
the language. On su h systems, all header les are impli itly s oped inside a C
language s ope. Also, an empty prototype () will be treated as an unspe ied
number of arguments, rather than no arguments, as C++ demands.

Chapter 7: GNU Obje tive-C runtime features

345

7 GNU Obje tive-C runtime features

This do ument is meant to des ribe some of the GNU Obje tive-C runtime features. It
is not intended to tea h you Obje tive-C, there are several resour es on the Internet that
present the language. Questions and omments about this do ument to Ovidiu Predes u
ovidiu up.hp. om.

7.1

+load:

Exe uting ode before main

The GNU Obje tive-C runtime provides a way that allows you to exe ute ode before the
exe ution of the program enters the main fun tion. The ode is exe uted on a per- lass and
a per- ategory basis, through a spe ial lass method +load.
This fa ility is very useful if you want to initialize global variables whi h an be a essed
by the program dire tly, without sending a message to the lass rst. The usual way
to initialize global variables, in the +initialize method, might not be useful be ause
+initialize is only alled when the rst message is sent to a lass obje t, whi h in some
ases ould be too late.
Suppose for example you have a FileStream lass that de lares Stdin, Stdout and
Stderr as global variables, like below:
FileStream *Stdin = nil;
FileStream *Stdout = nil;
FileStream *Stderr = nil;
implementation FileStream
+ (void)initialize
{
Stdin = [[FileStream new initWithFd:0;
Stdout = [[FileStream new initWithFd:1;
Stderr = [[FileStream new initWithFd:2;
}
/* Other methods here */
end

In this example, the initialization of Stdin, Stdout and Stderr in +initialize o urs
too late. The programmer an send a message to one of these obje ts before the variables
are a tually initialized, thus sending messages to the nil obje t. The +initialize method
whi h a tually initializes the global variables is not invoked until the rst message is sent
to the lass obje t. The solution would require these variables to be initialized just before
entering main.
The orre t solution of the above problem is to use the +load method instead of
+initialize:
implementation FileStream
+ (void)load
{
Stdin = [[FileStream new initWithFd:0;
Stdout = [[FileStream new initWithFd:1;

346

Using the GNU Compiler Colle tion (GCC)

Stderr = [[FileStream new initWithFd:2;

/* Other methods here */

end

The +load is a method that is not overridden by ategories. If a lass and a ategory of
it both implement +load, both methods are invoked. This allows some additional initializations to be performed in a ategory.
This me hanism is not intended to be a repla ement for +initialize. You should be
aware of its limitations when you de ide to use it instead of +initialize.

7.1.1 What you an and what you annot do in +load

The +load implementation in the GNU runtime guarantees you the following things:








you an write whatever C ode you like;

you an send messages to Obje tive-C onstant strings ("this is a onstant
string");
you an allo ate and send messages to obje ts whose lass is implemented in the same
le;
the +load implementation of all super lasses of a lass are exe uted before the +load
of that lass is exe uted;
the +load implementation of a lass is exe uted before the +load implementation of
any ategory.

In parti ular, the following things, even if they an work in a parti ular ase, are not
guaranteed:




allo ation of or sending messages to arbitrary obje ts;

allo ation of or sending messages to obje ts whose lasses have a ategory implemented
in the same le;

You should make no assumptions about re eiving +load in sibling lasses when you write
+load of a lass. The order in whi h sibling lasses re eive +load is not guaranteed.
The order in whi h +load and +initialize are alled ould be problemati if this matters. If you don't allo ate obje ts inside +load, it is guaranteed that +load is alled before
+initialize. If you reate an obje t inside +load the +initialize method of obje t's
lass is invoked even if +load was not invoked. Note if you expli itly all +load on a lass,
+initialize will be alled rst. To avoid possible problems try to implement only one of
these methods.
The +load method is also invoked when a bundle is dynami ally loaded into your running
program. This happens automati ally without any intervening operation from you. When
you write bundles and you need to write +load you an safely reate and send messages to
obje ts whose lasses already exist in the running program. The same restri tions as above
apply to lasses dened in bundle.

Chapter 7: GNU Obje tive-C runtime features

347

7.2 Type en oding

The Obje tive-C ompiler generates type en odings for all the types. These type en odings
are used at runtime to nd out information about sele tors and methods and about obje ts
and lasses.
The types are en oded in the following way:
har
unsigned har
short
unsigned short
int
unsigned int
long
unsigned long
long long
unsigned long long
float
double
void
id
Class
SEL
har*

unknown type
bit-elds

C
s
S
i
I
l
L
q
Q
f
d
v

#
:
*
?
b followed by the starting position of the bit-eld, the type of the

bit-eld and the size of the bit-eld (the bit-elds en oding was
hanged from the NeXT's ompiler en oding, see below)
The en oding of bit-elds has hanged to allow bit-elds to be properly handled by the
runtime fun tions that ompute sizes and alignments of types that ontain bit-elds. The
previous en oding ontained only the size of the bit-eld. Using only this information it is
not possible to reliably ompute the size o upied by the bit-eld. This is very important
in the presen e of the Boehm's garbage olle tor be ause the obje ts are allo ated using
the typed memory fa ility available in this olle tor. The typed memory allo ation requires
information about where the pointers are lo ated inside the obje t.
The position in the bit-eld is the position, ounting in bits, of the bit losest to the
beginning of the stru ture.
The non-atomi types are en oded as follows:
pointers
`^' followed by the pointed type.
arrays
`[' followed by the number of elements in the array followed by the
type of the elements followed by `'
stru tures
`{' followed by the name of the stru ture (or `?' if the stru ture is
unnamed), the `=' sign, the type of the members and by `}'
unions
`(' followed by the name of the stru ture (or `?' if the union is unnamed), the `=' sign, the type of the members followed by `)'
Here are some types and their en odings, as they are generated by the ompiler on an
i386 ma hine:

348

Using the GNU Compiler Colle tion (GCC)

Obje tive-C type

int a[10;

stru t {
int i;
float f[3;
int a:3;
int b:2;
har ;
}

Compiler en oding
[10i

{?=i[3fb128i3b131i2 }

In addition to the types the ompiler also en odes the type spe iers. The table below
des ribes the en oding of the urrent Obje tive-C type spe iers:
Spe ier
onst
in
inout
out
by opy
oneway

En oding
r
n
N
o
O
V

The type spe iers are en oded just before the type. Unlike types however, the type
spe iers are only en oded when they appear in method argument types.

7.3 Garbage Colle tion

Support for a new memory management poli y has been added by using a powerful onservative garbage olle tor, known as the Boehm-Demers-Weiser onservative garbage olle tor.
It is available from http://www.hpl.hp. om/personal/Hans_Boehm/g /.
To enable the support for it you have to ongure the ompiler using an additional argument, `--enable-obj -g '. You need to have garbage olle tor installed before building
the ompiler. This will build an additional runtime library whi h has several enhan ements
to support the garbage olle tor. The new library has a new name, `libobj _g .a' to not
on i t with the non-garbage- olle ted library.
When the garbage olle tor is used, the obje ts are allo ated using the so- alled typed
memory allo ation me hanism available in the Boehm-Demers-Weiser olle tor. This mode
requires pre ise information on where pointers are lo ated inside obje ts. This information
is omputed on e per lass, immediately after the lass has been initialized.
There is a new runtime fun tion lass_ivar_set_g invisible() whi h an be used to
de lare a so- alled weak pointer referen e. Su h a pointer is basi ally hidden for the garbage
olle tor; this an be useful in ertain situations, espe ially when you want to keep tra k
of the allo ated obje ts, yet allow them to be olle ted. This kind of pointers an only be
members of obje ts, you annot de lare a global pointer as a weak referen e. Every type
whi h is a pointer type an be de lared a weak pointer, in luding id, Class and SEL.

Chapter 7: GNU Obje tive-C runtime features

349

Here is an example of how to use this feature. Suppose you want to implement a lass
whose instan es hold a weak pointer referen e; the following lass does this:
interfa e WeakPointer : Obje t
{
onst void* weakPointer;
}
- initWithPointer:( onst void*)p;
- ( onst void*)weakPointer;
end
implementation WeakPointer
+ (void)initialize
{
lass_ivar_set_g invisible (self, "weakPointer", YES);
}
- initWithPointer:( onst void*)p
{
weakPointer = p;
return self;
}
- ( onst void*)weakPointer
{
return weakPointer;
}
end

Weak pointers are supported through a new type hara ter spe ier represented by the
`!' hara ter. The lass_ivar_set_g invisible() fun tion adds or removes this spe ier
to the string type des ription of the instan e variable named as argument.

7.4 Constant string obje ts

GNU Obje tive-C provides onstant string obje ts that are generated dire tly by the ompiler. You de lare a onstant string obje t by prexing a C onstant string with the hara ter
`':
id myString = "this is a onstant string obje t";

The onstant string obje ts are by default instan es of the NXConstantString lass whi h
is provided by the GNU Obje tive-C runtime. To get the denition of this lass you must
in lude the `obj /NXConstStr.h' header le.
User dened libraries may want to implement their own onstant string lass. To be able
to support them, the GNU Obje tive-C ompiler provides a new ommand line options
`-f onstant-string- lass= lass-name '. The provided lass should adhere to a stri t
stru ture, the same as NXConstantString's stru ture:
interfa e MyConstantStringClass
{

350

Using the GNU Compiler Colle tion (GCC)

Class isa;
har * _string;
unsigned int len;

}
end

NXConstantString inherits from Obje t; user lass libraries may hoose to inherit the
ustomized onstant string lass from a dierent lass than Obje t. There is no requirement
in the methods the onstant string lass has to implement, but the nal ivar layout of the
lass must be the ompatible with the given stru ture.
When the ompiler reates the stati ally allo ated onstant string obje t, the _string
eld will be lled by the ompiler with the string; the length eld will be lled by the
ompiler with the string length; the isa pointer will be lled with NULL by the ompiler,
and it will later be xed up automati ally at runtime by the GNU Obje tive-C runtime
library to point to the lass whi h was set by the `-f onstant-string- lass' option when
the obje t le is loaded (if you wonder how it works behind the s enes, the name of the
lass to use, and the list of stati obje ts to xup, are stored by the ompiler in the obje t
le in a pla e where the GNU runtime library will nd them at runtime).
As a result, when a le is ompiled with the `-f onstant-string- lass' option, all the
onstant string obje ts will be instan es of the lass spe ied as argument to this option. It
is possible to have multiple ompilation units referring to dierent onstant string lasses,
neither the ompiler nor the linker impose any restri tions in doing this.

7.5 ompatibility alias

This is a feature of the Obje tive-C ompiler rather than of the runtime, anyway sin e it is
do umented nowhere and its existen e was forgotten, we are do umenting it here.
The keyword  ompatibility_alias allows you to dene a lass name as equivalent to
another lass name. For example:
 ompatibility_alias WOAppli ation GSWAppli ation;

tells the ompiler that ea h time it en ounters WOAppli ation as a lass name, it
should repla e it with GSWAppli ation (that is, WOAppli ation is just an alias for
GSWAppli ation).
There are some onstraints on how this an be used|
 WOAppli ation (the alias) must not be an existing lass;
 GSWAppli ation (the real lass) must be an existing lass.

Chapter 8: Binary Compatibility

351

8 Binary Compatibility
Binary ompatibility en ompasses several related on epts:
appli ation binary interfa e (ABI)
The set of runtime onventions followed by all of the tools that deal with binary representations of a program, in luding ompilers, assemblers, linkers, and
language runtime support. Some ABIs are formal with a written spe i ation,
possibly designed by multiple interested parties. Others are simply the way
things are a tually done by a parti ular set of tools.
ABI onforman e
A ompiler onforms to an ABI if it generates ode that follows all of the
spe i ations enumerated by that ABI. A library onforms to an ABI if it is
implemented a ording to that ABI. An appli ation onforms to an ABI if it
is built using tools that onform to that ABI and does not ontain sour e ode
that spe i ally hanges behavior spe ied by the ABI.
alling onventions
Calling onventions are a subset of an ABI that spe ify of how arguments are
passed and fun tion results are returned.
interoperability
Dierent sets of tools are interoperable if they generate les that an be used
in the same program. The set of tools in ludes ompilers, assemblers, linkers,
libraries, header les, startup les, and debuggers. Binaries produ ed by different sets of tools are not interoperable unless they implement the same ABI.
This applies to dierent versions of the same tools as well as tools from dierent
vendors.
inter allability
Whether a fun tion in a binary built by one set of tools an all a fun tion in
a binary built by a dierent set of tools is a subset of interoperability.
implementation-dened features
Language standards in lude lists of implementation-dened features whose behavior an vary from one implementation to another. Some of these features
are normally overed by a platform's ABI and others are not. The features
that are not overed by an ABI generally ae t how a program behaves, but
not inter allability.
ompatibility
Conforman e to the same ABI and the same behavior of implementation-dened
features are both relevant for ompatibility.
The appli ation binary interfa e implemented by a C or C++ ompiler ae ts ode generation and runtime support for:
 size and alignment of data types
 layout of stru tured types
 alling onventions

352

Using the GNU Compiler Colle tion (GCC)





register usage onventions

interfa es for runtime arithmeti support
obje t le formats
In addition, the appli ation binary interfa e implemented by a C++ ompiler ae ts ode
generation and runtime support for:
 name mangling
 ex eption handling
 invoking onstru tors and destru tors
 layout, alignment, and padding of lasses
 layout and alignment of virtual tables
Some GCC ompilation options ause the ompiler to generate ode that does not onform to the platform's default ABI. Other options ause dierent program behavior for
implementation-dened features that are not overed by an ABI. These options are provided for onsisten y with other ompilers that do not follow the platform's default ABI
or the usual behavior of implementation-dened features for the platform. Be very areful
about using su h options.
Most platforms have a well-dened ABI that overs C ode, but ABIs that over C++
fun tionality are not yet ommon.
Starting with GCC 3.2, GCC binary onventions for C++ are based on a written, vendorneutral C++ ABI that was designed to be spe i to 64-bit Itanium but also in ludes generi
spe i ations that apply to any platform. This C++ ABI is also implemented by other
ompiler vendors on some platforms, notably GNU/Linux and BSD systems. We have tried
hard to provide a stable ABI that will be ompatible with future GCC releases, but it is
possible that we will en ounter problems that make this di ult. Su h problems ould
in lude dierent interpretations of the C++ ABI by dierent vendors, bugs in the ABI, or
bugs in the implementation of the ABI in dierent ompilers. GCC's `-Wabi' swit h warns
when G++ generates ode that is probably not ompatible with the C++ ABI.
The C++ library used with a C++ ompiler in ludes the Standard C++ Library, with
fun tionality dened in the C++ Standard, plus language runtime support. The runtime
support is in luded in a C++ ABI, but there is no formal ABI for the Standard C++ Library.
Two implementations of that library are interoperable if one follows the de-fa to ABI of the
other and if they are both built with the same ompiler, or with ompilers that onform to
the same ABI for C++ ompiler and runtime support.
When G++ and another C++ ompiler onform to the same C++ ABI, but the implementations of the Standard C++ Library that they normally use do not follow the same ABI for
the Standard C++ Library, obje t les built with those ompilers an be used in the same
program only if they use the same C++ library. This requires spe ifying the lo ation of the
C++ library header les when invoking the ompiler whose usual library is not being used.
The lo ation of GCC's C++ header les depends on how the GCC build was ongured, but
an be seen by using the G++ `-v' option. With default onguration options for G++ 3.3
the ompile line for a dierent C++ ompiler needs to in lude
-Ig _install_dire tory /in lude/ ++/3.3

Similarly, ompiling ode with G++ that must use a C++ library other than the GNU C++
library requires spe ifying the lo ation of the header les for that other library.

Chapter 8: Binary Compatibility

353

The most straightforward way to link a program to use a parti ular C++ library is to
use a C++ driver that spe ies that C++ library by default. The g++ driver, for example,
tells the linker where to nd GCC's C++ library (`libstd ++') plus the other libraries and
startup les it needs, in the proper order.
If a program must use a dierent C++ library and it's not possible to do the nal link
using a C++ driver that uses that library by default, it is ne essary to tell g++ the lo ation
and name of that library. It might also be ne essary to spe ify dierent startup les and
other runtime support libraries, and to suppress the use of GCC's support libraries with
one or more of the options `-nostdlib', `-nostartfiles', and `-nodefaultlibs'.

354

Using the GNU Compiler Colle tion (GCC)

Chapter 9: g ov|a Test Coverage Program

355

9 g ov|a Test Coverage Program

g ov is a tool you an use in onjun tion with GCC to test ode overage in your programs.

9.1 Introdu tion to g ov

g ov is a test overage program. Use it in on ert with GCC to analyze your programs
to help reate more e ient, faster running ode and to dis over untested parts of your
program. You an use g ov as a proling tool to help dis over where your optimization
eorts will best ae t your ode. You an also use g ov along with the other proling tool,
gprof, to assess whi h parts of your ode use the greatest amount of omputing time.
Proling tools help you analyze your ode's performan e. Using a proler su h as g ov
or gprof, you an nd out some basi performan e statisti s, su h as:
 how often ea h line of ode exe utes
 what lines of ode are a tually exe uted
 how mu h omputing time ea h se tion of ode uses

On e you know these things about how your ode works when ompiled, you an look at
ea h module to see whi h modules should be optimized. g ov helps you determine where
to work on optimization.
Software developers also use overage testing in on ert with testsuites, to make sure
software is a tually good enough for a release. Testsuites an verify that a program works
as expe ted; a overage program tests to see how mu h of the program is exer ised by the
testsuite. Developers an then determine what kinds of test ases need to be added to the
testsuites to reate both better testing and a better nal produ t.
You should ompile your ode without optimization if you plan to use g ov be ause
the optimization, by ombining some lines of ode into one fun tion, may not give you
as mu h information as you need to look for `hot spots' where the ode is using a great
deal of omputer time. Likewise, be ause g ov a umulates statisti s by line (at the lowest
resolution), it works best with a programming style that pla es only one statement on ea h
line. If you use ompli ated ma ros that expand to loops or to other ontrol stru tures,
the statisti s are less helpful|they only report on the line where the ma ro all appears.
If your omplex ma ros behave like fun tions, you an repla e them with inline fun tions
to solve this problem.
g ov reates a logle alled `sour efile.g ov' whi h indi ates how many times ea h line
of a sour e le `sour efile. ' has exe uted. You an use these logles along with gprof
to aid in ne-tuning the performan e of your programs. gprof gives timing information
you an use along with the information you get from g ov.
g ov works only on ode ompiled with GCC. It is not ompatible with any other proling
or test overage me hanism.

9.2 Invoking g ov

g ov [options sour efile

g ov a epts the following options:

356

-h
--help
-v
--version

Using the GNU Compiler Colle tion (GCC)

Display help about using g ov (on the standard output), and exit without doing
any further pro essing.
Display the g ov version number (on the standard output), and exit without
doing any further pro essing.

-a
--all-blo ks

Write individual exe ution ounts for every basi blo k. Normally g ov outputs
exe ution ounts only for the main blo ks of a line. With this option you an
determine if blo ks within a single line are not being exe uted.

-b
--bran h-probabilities

Write bran h frequen ies to the output le, and write bran h summary info to
the standard output. This option allows you to see how often ea h bran h in
your program was taken. Un onditional bran hes will not be shown, unless the
`-u' option is given.

-
--bran h- ounts

Write bran h frequen ies as the number of bran hes taken, rather than the
per entage of bran hes taken.

-n
--no-output

Do not reate the g ov output le.

-l
--long-file-names

Create long le names for in luded sour e les. For example, if the header
le `x.h' ontains ode, and was in luded in the le `a. ', then running g ov
on the le `a. ' will produ e an output le alled `a. ##x.h.g ov' instead of
`x.h.g ov'. This an be useful if `x.h' is in luded in multiple sour e les. If you
use the `-p' option, both the in luding and in luded le names will be omplete
path names.

-p
--preserve-paths

Preserve omplete path information in the names of generated `.g ov' les.
Without this option, just the lename omponent is used. With this option, all
dire tories are used, with `/' hara ters translated to `#' hara ters, `.' dire tory
omponents removed and `..' omponents renamed to `^'. This is useful if
sour eles are in several dierent dire tories. It also ae ts the `-l' option.

-f
--fun tion-summaries

Output summaries for ea h fun tion in addition to the le level summary.

Chapter 9: g ov|a Test Coverage Program

357

-o dire tory|file
--obje t-dire tory dire tory
--obje t-file file

Spe ify either the dire tory ontaining the g ov data les, or the obje t path
name. The `.g no', and `.g da' data les are sear hed for using this option. If
a dire tory is spe ied, the data les are in that dire tory and named after the
sour e le name, without its extension. If a le is spe ied here, the data les
are named after that le, without its extension. If this option is not supplied,
it defaults to the urrent dire tory.

-u
--un onditional-bran hes

When bran h probabilities are given, in lude those of un onditional bran hes.
Un onditional bran hes are normally not interesting.

g ov should be run with the urrent dire tory the same as that when you invoked the
ompiler. Otherwise it will not be able to lo ate the sour e les. g ov produ es les alled
`mangledname.g ov' in the urrent dire tory. These ontain the overage information of the
sour e le they orrespond to. One `.g ov' le is produ ed for ea h sour e le ontaining
ode, whi h was ompiled to produ e the data les. The mangledname part of the output
le name is usually simply the sour e le name, but an be something more ompli ated if
the `-l' or `-p' options are given. Refer to those options for details.
The `.g ov' les ontain the `:' separated elds along with program sour e ode. The
format is
exe ution_ ount :line_number :sour e line text

Additional blo k information may su eed ea h line, when requested by ommand line
option. The exe ution ount is `-' for lines ontaining no ode and `#####' for lines whi h
were never exe uted. Some lines of information at the start have line number of zero.
The preamble lines are of the form
-:0:tag :value

The ordering and number of these preamble lines will be augmented as g ov development
progresses | do not rely on them remaining un hanged. Use tag to lo ate a parti ular
preamble line.
The additional blo k information is of the form
tag information

The information is human readable, but designed to be simple enough for ma hine parsing
too.
When printing per entages, 0% and 100% are only printed when the values are exa tly
0% and 100% respe tively. Other values whi h would onventionally be rounded to 0% or
100% are instead printed as the nearest non-boundary value.
When using g ov, you must rst ompile your program with two spe ial GCC options:
`-fprofile-ar s -ftest- overage'. This tells the ompiler to generate additional information needed by g ov (basi ally a ow graph of the program) and also in ludes additional
ode in the obje t les for generating the extra proling information needed by g ov. These
additional les are pla ed in the dire tory where the obje t le is lo ated.

358

Using the GNU Compiler Colle tion (GCC)

Running the program will ause prole output to be generated. For ea h sour e le
ompiled with `-fprofile-ar s', an a ompanying `.g da' le will be pla ed in the obje t
le dire tory.
Running g ov with your program's sour e le names as arguments will now produ e a
listing of the ode along with frequen y of exe ution for ea h line. For example, if your
program is alled `tmp. ', this is what you see when you use the basi g ov fa ility:
$ g -fprofile-ar s -ftest- overage tmp.
$ a.out
$ g ov tmp.
90.00% of 10 sour e lines exe uted in file tmp.
Creating tmp. .g ov.

The le `tmp. .g ov' ontains output from g ov. Here is a sample:

-:
-:
-:
-:
-:
-:
-:
-:
1:
1:
-:
1:
-:
11:
10:
-:
1:
#####:
-:
1:
1:
-:

0:Sour e:tmp.
0:Graph:tmp.g no
0:Data:tmp.g da
0:Runs:1
0:Programs:1
1:#in lude <stdio.h>
2:
3:int main (void)
4:{
5: int i, total;
6:
7: total = 0;
8:
9: for (i = 0; i < 10; i++)
10:
total += i;
11:
12: if (total != 45)
13:
printf ("Failure\n");
14: else
15:
printf ("Su ess\n");
16: return 0;
17:}

When you use the `-a' option, you will get individual blo k ounts, and the output looks
like this:
-:
-:
-:
-:
-:
-:
-:
-:
1:
1:
1:
-:
1:
-:
11:
11:
10:
10:
-:

0:Sour e:tmp.
0:Graph:tmp.g no
0:Data:tmp.g da
0:Runs:1
0:Programs:1
1:#in lude <stdio.h>
2:
3:int main (void)
4:{
4-blo k 0
5: int i, total;
6:
7: total = 0;
8:
9: for (i = 0; i < 10; i++)
9-blo k 0
10:
total += i;
10-blo k 0
11:

Chapter 9: g ov|a Test Coverage Program

1:
1:
#####:
$$$$$:
-:
1:
1:
1:
1:
-:

359

12: if (total != 45)

12-blo k 0
13:
printf ("Failure\n");
13-blo k 0
14: else
15:
printf ("Su ess\n");
15-blo k 0
16: return 0;
16-blo k 0
17:}

In this mode, ea h basi blo k is only shown on one line { the last line of the blo k.
A multi-line blo k will only ontribute to the exe ution ount of that last line, and other
lines will not be shown to ontain ode, unless previous blo ks end on those lines. The
total exe ution ount of a line is shown and subsequent lines show the exe ution ounts for
individual blo ks that end on that line. After ea h blo k, the bran h and all ounts of the
blo k will be shown, if the `-b' option is given.
Be ause of the way GCC instruments alls, a all ount an be shown after a line with
no individual blo ks. As you an see, line 13 ontains a basi blo k that was not exe uted.
When you use the `-b' option, your output looks like this:
$ g ov -b tmp.
90.00% of 10 sour e lines exe uted in file tmp.
80.00% of 5 bran hes exe uted in file tmp.
80.00% of 5 bran hes taken at least on e in file tmp.
50.00% of 2 alls exe uted in file tmp.
Creating tmp. .g ov.

Here is a sample of a resulting `tmp. .g ov' le:

-:
0:Sour e:tmp.
-:
0:Graph:tmp.g no
-:
0:Data:tmp.g da
-:
0:Runs:1
-:
0:Programs:1
-:
1:#in lude <stdio.h>
-:
2:
-:
3:int main (void)
fun tion main alled 1 returned 1 blo ks exe uted 75%
1:
4:{
1:
5: int i, total;
-:
6:
1:
7: total = 0;
-:
8:
11:
9: for (i = 0; i < 10; i++)
bran h 0 taken 91% (fallthrough)
bran h 1 taken 9%
10:
10:
total += i;
-:
11:
1:
12: if (total != 45)
bran h 0 taken 0% (fallthrough)
bran h 1 taken 100%
#####:
13:
printf ("Failure\n");
all
0 never exe uted
-:
14: else
1:
15:
printf ("Su ess\n");
all
0 alled 1 returned 100%
1:
16: return 0;

360

Using the GNU Compiler Colle tion (GCC)

-:

17:}

For ea h fun tion, a line is printed showing how many times the fun tion is alled, how
many times it returns and what per entage of the fun tion's blo ks were exe uted.
For ea h basi blo k, a line is printed after the last line of the basi blo k des ribing the
bran h or all that ends the basi blo k. There an be multiple bran hes and alls listed for
a single sour e line if there are multiple basi blo ks that end on that line. In this ase, the
bran hes and alls are ea h given a number. There is no simple way to map these bran hes
and alls ba k to sour e onstru ts. In general, though, the lowest numbered bran h or all
will orrespond to the leftmost onstru t on the sour e line.
For a bran h, if it was exe uted at least on e, then a per entage indi ating the number
of times the bran h was taken divided by the number of times the bran h was exe uted will
be printed. Otherwise, the message \never exe uted" is printed.
For a all, if it was exe uted at least on e, then a per entage indi ating the number of
times the all returned divided by the number of times the all was exe uted will be printed.
This will usually be 100%, but may be less for fun tions all exit or longjmp, and thus
may not return every time they are alled.
The exe ution ounts are umulative. If the example program were exe uted again without removing the `.g da' le, the ount for the number of times ea h line in the sour e was
exe uted would be added to the results of the previous run(s). This is potentially useful in
several ways. For example, it ould be used to a umulate data over a number of program
runs as part of a test veri ation suite, or to provide more a urate long-term information
over a large number of program runs.
The data in the `.g da' les is saved immediately before the program exits. For ea h
sour e le ompiled with `-fprofile-ar s', the proling ode rst attempts to read in an
existing `.g da' le; if the le doesn't mat h the exe utable (diering number of basi blo k
ounts) it will ignore the ontents of the le. It then adds in the new exe ution ounts and
nally writes the data to the le.

9.3 Using g ov with GCC Optimization

If you plan to use g ov to help optimize your ode, you must rst ompile your program
with two spe ial GCC options: `-fprofile-ar s -ftest- overage'. Aside from that, you
an use any other GCC options; but if you want to prove that every single line in your
program was exe uted, you should not ompile with optimization at the same time. On
some ma hines the optimizer an eliminate some simple ode lines by ombining them with
other lines. For example, ode like this:
if (a != b)
= 1;
else
= 0;

an be ompiled into one instru tion on some ma hines. In this ase, there is no way for
g ov to al ulate separate exe ution ounts for ea h line be ause there isn't separate ode
for ea h line. Hen e the g ov output looks like this if you ompiled the program with
optimization:
100:
100:
100:

12:if (a != b)
13: = 1;
14:else

Chapter 9: g ov|a Test Coverage Program

100:

15:

361

= 0;

The output shows that this blo k of ode, ombined by optimization, exe uted 100 times.
In one sense this result is orre t, be ause there was only one instru tion representing all
four of these lines. However, the output does not indi ate how many times the result was
0 and how many times the result was 1.
Inlineable fun tions an reate unexpe ted line ounts. Line ounts are shown for the
sour e ode of the inlineable fun tion, but what is shown depends on where the fun tion is
inlined, or if it is not inlined at all.
If the fun tion is not inlined, the ompiler must emit an out of line opy of the fun tion, in
any obje t le that needs it. If `fileA.o' and `fileB.o' both ontain out of line bodies of a
parti ular inlineable fun tion, they will also both ontain overage ounts for that fun tion.
When `fileA.o' and `fileB.o' are linked together, the linker will, on many systems, sele t
one of those out of line bodies for all alls to that fun tion, and remove or ignore the other.
Unfortunately, it will not remove the overage ounters for the unused fun tion body. Hen e
when instrumented, all but one use of that fun tion will show zero ounts.
If the fun tion is inlined in several pla es, the blo k stru ture in ea h lo ation might not
be the same. For instan e, a ondition might now be al ulable at ompile time in some
instan es. Be ause the overage of all the uses of the inline fun tion will be shown for the
same sour e lines, the line ounts themselves might seem in onsistent.

9.4 Brief des ription of g ov data les

g ov uses two les for proling. The names of these les are derived from the original obje t
le by substituting the le sux with either `.g no', or `.g da'. All of these les are pla ed

in the same dire tory as the obje t le, and ontain data stored in a platform-independent
format.
The `.g no' le is generated when the sour e le is ompiled with the GCC
`-ftest- overage' option. It ontains information to re onstru t the basi blo k graphs
and assign sour e line numbers to blo ks.
The `.g da' le is generated when a program ontaining obje t les built with the GCC
`-fprofile-ar s' option is exe uted. A separate `.g da' le is reated for ea h obje t le
ompiled with this option. It ontains ar transition ounts, and some summary information.
The full details of the le format is spe ied in `g ov-io.h', and fun tions provided in
that header le should be used to a ess the overage les.

362

Using the GNU Compiler Colle tion (GCC)

Chapter 10: Known Causes of Trouble with GCC

363

10 Known Causes of Trouble with GCC

This se tion des ribes known problems that ae t users of GCC. Most of these are not
GCC bugs per se|if they were, we would x 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 mu h work to add, and some are pla es where people's opinions dier as to what is
best.

10.1 A tual Bugs We Haven't Fixed Yet




The fixin ludes s ript intera ts badly with automounters; if the dire tory of system
header les is automounted, it tends to be unmounted while fixin ludes 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 s ript will sometimes add prototypes for the sigsetjmp and siglongjmp
fun tions that referen e the jmp_buf type before that type is dened. To work around
this, edit the oending le and pla e the typedef in front of the prototypes.

10.2 Cross-Compiler Problems

You may run into problems with ross ompilation on ertain ma hines, for several reasons.
 At present, the program `mips-tfile' whi h adds debug support to obje t les on
MIPS systems does not work in a ross ompile environment.

10.3 Interoperation
This se tion lists various di ulties en ountered in using GCC together with other ompilers
or with the assemblers, linkers, libraries and debuggers on ertain systems.
 On many platforms, GCC supports a dierent ABI for C++ than do other ompilers, so
the obje t les ompiled by GCC annot be used with obje t les generated by another
C++ ompiler.
An area where the dieren e is most apparent is name mangling. The use of dierent
name mangling is intentional, to prote t you from more subtle problems. Compilers
dier as to many internal details of C++ implementation, in luding: how lass instan es
are laid out, how multiple inheritan e is implemented, and how virtual fun tion alls
are handled. If the name en oding were made the same, your programs would link
against libraries provided from other ompilers|but the programs would then rash
when run. In ompatible libraries are then dete ted at link time, rather than at run
time.
 On some BSD systems, in luding some versions of Ultrix, use of proling auses stati
variable destru tors ( urrently used only in C++) not to be run.
 On some SGI systems, when you use `-lgl_s' as an option, it gets translated magi ally
to `-lgl_s -lX11_s -l _s'. Naturally, this does not happen when you use GCC. You
must spe ify all three options expli itly.

364

Using the GNU Compiler Colle tion (GCC)

On a SPARC, GCC aligns all values of type double on an 8-byte boundary, and it
expe ts every double to be so aligned. The Sun ompiler usually gives double values
8-byte alignment, with one ex eption: fun tion arguments of type double may not be
aligned.
As a result, if a fun tion ompiled with Sun CC takes the address of an argument
of type double and passes this pointer of type double * to a fun tion ompiled with
GCC, dereferen ing the pointer may ause a fatal signal.
One way to solve this problem is to ompile your entire program with GCC. Another
solution is to modify the fun tion that is ompiled with Sun CC to opy the argument
into a lo al variable; lo al variables are always properly aligned. A third solution is to
modify the fun tion that uses the pointer to dereferen e it via the following fun tion
a ess_double instead of dire tly with `*':
inline double
a ess_double (double *unaligned_ptr)
{
union d2i { double d; int i[2; };
union d2i *p = (union d2i *) unaligned_ptr;
union d2i u;
u.i[0 = p->i[0;
u.i[1 = p->i[1;
}







return u.d;

Storing into the pointer an be done likewise with the same union.
On Solaris, the mallo fun tion in the `libmallo .a' library may allo ate memory
that is only 4 byte aligned. Sin e GCC on the SPARC assumes that doubles are 8 byte
aligned, this may result in a fatal signal if doubles are stored in memory allo ated by
the `libmallo .a' library.
The solution is to not use the `libmallo .a' library. Use instead mallo and related
fun tions from `lib .a'; they do not have this problem.
On the HP PA ma hine, ADB sometimes fails to work on fun tions ompiled with
GCC. Spe i ally, it fails to work on fun tions that use allo a or variable-size arrays.
This is be ause GCC doesn't generate HP-UX unwind des riptors for su h fun tions.
It may even be impossible to generate them.
Debugging (`-g') is not supported on the HP PA ma hine, unless you use the preliminary GNU tools.
Taking the address of a label may generate errors from the HP-UX PA assembler. GAS
for the PA does not have this problem.
Using oating point parameters for indire t alls to stati fun tions will not work when
using the HP assembler. There simply is no way for GCC to spe ify what registers hold
arguments for stati fun tions when using the HP assembler. GAS for the PA does not
have this problem.
In extremely rare ases involving some very large fun tions you may re eive errors from
the HP linker omplaining about an out of bounds un onditional bran h oset. This

Chapter 10: Known Causes of Trouble with GCC











365

used to o ur more often in previous versions of GCC, but is now ex eptionally rare.
If you should run into it, you an work around by making your fun tion smaller.
GCC ompiled ode sometimes emits warnings from the HP-UX assembler of the form:
(warning) Use of GR3 when
frame >= 8192 may ause onfli t.

These warnings are harmless and an be safely ignored.

In extremely rare ases involving some very large fun tions you may re eive errors from
the AIX Assembler omplaining about a displa ement that is too large. If you should
run into it, you an work around by making your fun tion smaller.
The `libstd ++.a' library in GCC relies on the SVR4 dynami linker semanti s whi h
merges global symbols between libraries and appli ations, espe ially ne essary for C++
streams fun tionality. This is not the default behavior of AIX shared libraries and
dynami linking. `libstd ++.a' is built on AIX with \runtime-linking" enabled so
that symbol merging an o ur. To utilize this feature, the appli ation linked with
`libstd ++.a' must in lude the `-Wl,-brtl' ag on the link line. G++ annot impose
this be ause this option may interfere with the semanti s of the user program and users
may not always use `g++' to link his or her appli ation. Appli ations are not required to
use the `-Wl,-brtl' ag on the link line|the rest of the `libstd ++.a' library whi h
is not dependent on the symbol merging semanti s will ontinue to fun tion orre tly.
An appli ation an interpose its own denition of fun tions for fun tions invoked by
`libstd ++.a' with \runtime-linking" enabled on AIX. To a omplish this the appli ation must be linked with \runtime-linking" option and the fun tions expli itly must
be exported by the appli ation (`-Wl,-brtl,-bE:exportfile').
AIX on the RS/6000 provides support (NLS) for environments outside of the United
States. Compilers and assemblers use NLS to support lo ale-spe i representations
of various obje ts in luding oating-point numbers (`.' vs `,' for separating de imal
fra tions). There have been problems reported where the library linked with GCC does
not produ e the same oating-point formats that the assembler a epts. If you have
this problem, set the LANG environment variable to `C' or `En_US'.
Even if you spe ify `-fdollars-in-identifiers', you annot su essfully use `$' in
identiers on the RS/6000 due to a restri tion in the IBM assembler. GAS supports
these identiers.
On Ultrix, the Fortran ompiler expe ts registers 2 through 5 to be saved by fun tion
alls. However, the C ompiler uses onventions ompatible with BSD Unix: registers
2 through 5 may be lobbered by fun tion alls.
GCC uses the same onvention as the Ultrix C ompiler. You an use these options to
produ e ode ompatible with the Fortran ompiler:
-f all-saved-r2 -f all-saved-r3 -f all-saved-r4 -f all-saved-r5

10.4 In ompatibilities of GCC

There are several noteworthy in ompatibilities between GNU C and K&R (non-ISO) versions of C.
 GCC normally makes string onstants read-only. If several identi al-looking string
onstants are used, GCC stores only one opy of the string.

366




Using the GNU Compiler Colle tion (GCC)

One onsequen e is that you annot all mktemp with a string onstant argument. The
fun tion mktemp always alters the string its argument points to.
Another onsequen e is that ss anf does not work on some very old systems when
passed a string onstant as its format ontrol string or input. This is be ause ss anf
in orre tly tries to write into the string onstant. Likewise fs anf and s anf.
The solution to these problems is to hange the program to use har-array variables
with initialization strings for these purposes instead of string onstants.
-2147483648 is positive.
This is be ause 2147483648 annot t in the type int, so (following the ISO C rules)
its data type is unsigned long int. Negating this value yields 2147483648 again.
GCC does not substitute ma ro arguments when they appear inside of string onstants.
For example, the following ma ro in GCC
#define foo(a) "a"

will produ e output "a" regardless of what the argument a is.

When you use setjmp and longjmp, the only automati variables guaranteed to remain valid are those de lared volatile. This is a onsequen e of automati register
allo ation. Consider this fun tion:
jmp_buf j;
foo ()
{
int a, b;
a = fun1 ();
if (setjmp (j))
return a;

a = fun2 ();
/* longjmp (j) may o ur in fun3. */
return a + fun3 ();

Here a may or may not be restored to its rst value when the longjmp o urs. If a is
allo ated in a register, then its rst value is restored; otherwise, it keeps the last value
stored in it.
If you use the `-W' option with the `-O' option, you will get a warning when GCC thinks
su h a problem might be possible.
Programs that use prepro essing dire tives in the middle of ma ro arguments do not
work with GCC. For example, a program like this will not work:
foobar (
#define luser
ha k)




ISO C does not permit su h a onstru t.

K&R ompilers allow omments to ross over an in lusion boundary (i.e. started in an
in lude le and ended in the in luding le).
De larations of external variables and fun tions within a blo k apply only to the blo k
ontaining the de laration. In other words, they have the same s ope as any other
de laration in the same pla e.

Chapter 10: Known Causes of Trouble with GCC









367

In some other C ompilers, a extern de laration ae ts all the rest of the le even if
it happens within a blo k.
In traditional C, you an ombine long, et ., with a typedef name, as shown here:
typedef int foo;
typedef long foo bar;

In ISO C, this is not allowed: long and other type modiers require an expli it int.
PCC allows typedef names to be used as fun tion parameters.
Traditional C allows the following erroneous pair of de larations to appear together in
a given s ope:
typedef int foo;
typedef foo foo;

GCC treats all hara ters of identiers as signi ant. A ording to K&R-1 (2.2), \No
more than the rst eight hara ters are signi ant, although more may be used.". Also
a ording to K&R-1 (2.2), \An identier is a sequen e of letters and digits; the rst
hara ter must be a letter. The unders ore ounts as a letter.", but GCC also allows
dollar signs in identiers.
PCC allows whitespa e in the middle of ompound assignment operators su h as `+='.
GCC, following the ISO standard, does not allow this.
GCC omplains about unterminated hara ter onstants inside of prepro essing onditionals that fail. Some programs have English omments en losed in onditionals
that are guaranteed to fail; if these omments ontain apostrophes, GCC will probably
report an error. For example, this ode would produ e an error:
#if 0
You an't expe t this to work.
#endif




The best solution to su h a problem is to put the text into an a tual C omment
delimited by `/*...*/'.
Many user programs ontain the de laration `long time ();'. In the past, the system
header les on many systems did not a tually de lare time, so it did not matter what
type your program de lared it to return. But in systems with ISO C headers, time is
de lared to return time_t, and if that is not the same as long, then `long time ();'
is erroneous.
The solution is to hange your program to use appropriate system headers (<time.h>
on systems with ISO C headers) and not to de lare time if the system header les
de lare it, or failing that to use time_t as the return type of time.
When ompiling fun tions that return float, PCC onverts it to a double. GCC
a tually returns a float. If you are on erned with PCC ompatibility, you should
de lare your fun tions to return double; you might as well say what you mean.
When ompiling fun tions that return stru tures or unions, GCC output ode normally
uses a method dierent from that used on most versions of Unix. As a result, ode
ompiled with GCC annot all a stru ture-returning fun tion ompiled with PCC,
and vi e versa.
The method used by GCC is as follows: a stru ture or union whi h is 1, 2, 4 or 8
bytes long is returned like a s alar. A stru ture or union with any other size is stored
into an address supplied by the aller (usually in a spe ial, xed register, but on some

368

Using the GNU Compiler Colle tion (GCC)

ma hines it is passed on the sta k). The target hook TARGET_STRUCT_VALUE_RTX tells
GCC where to pass this address.
By ontrast, PCC on most target ma hines returns stru tures and unions of any size
by opying the data into an area of stati storage, and then returning the address of
that storage as if it were a pointer value. The aller must opy the data from that
memory area to the pla e where the value is wanted. GCC does not use this method
be ause it is slower and nonreentrant.
On some newer ma hines, PCC uses a reentrant onvention for all stru ture and union
returning. GCC on most of these ma hines uses a ompatible onvention when returning stru tures and unions in memory, but still returns small stru tures and unions in
registers.
You an tell GCC to use a ompatible onvention for all stru ture and union returning
with the option `-fp -stru t-return'.
GCC omplains about program fragments su h as `0x74ae-0x4000' whi h appear to be
two hexade imal onstants separated by the minus operator. A tually, this string is a
single prepro essing token. Ea h su h token must orrespond to one token in C. Sin e
this does not, GCC prints an error message. Although it may appear obvious that
what is meant is an operator and two values, the ISO C standard spe i ally requires
that this be treated as erroneous.
A prepro essing token is a prepro essing number if it begins with a digit and is followed
by letters, unders ores, digits, periods and `e+', `e-', `E+', `E-', `p+', `p-', `P+', or `P-'
hara ter sequen es. (In stri t C89 mode, the sequen es `p+', `p-', `P+' and `P-' annot
appear in prepro essing numbers.)
To make the above program fragment valid, pla e whitespa e in front of the minus
sign. This whitespa e will end the prepro essing number.

10.5 Fixed Header Files

GCC needs to install orre ted versions of some system header les. This is be ause most
target systems have some header les that won't work with GCC unless they are hanged.
Some have bugs, some are in ompatible with ISO C, and some depend on spe ial features
of other ompilers.
Installing GCC automati ally reates and installs the xed header les, by running a
program alled fixin ludes. Normally, you don't need to pay attention to this. But there
are ases where it doesn't do the right thing automati ally.
 If you update the system's header les, su h as by installing a new system version, the xed header les of GCC are not automati ally updated.
They an be updated using the mkheaders s ript installed in `libexe dir /g /target /version /install-tools/'.
 On some systems, header le dire tories ontain ma hine-spe i symboli links in
ertain pla es. This makes it possible to share most of the header les among hosts
running the same version of the system on dierent ma hine models.
The programs that x the header les do not understand this spe ial way of using
symboli links; therefore, the dire tory of xed header les is good only for the ma hine
model used to build it.

Chapter 10: Known Causes of Trouble with GCC

369

It is possible to make separate sets of xed header les for the dierent ma hine models,
and arrange a stru ture of symboli links so as to use the proper set, but you'll have
to do this by hand.

10.6 Standard Libraries

GCC by itself attempts to be a onforming freestanding implementation. See Chapter 2
[Language Standards Supported by GCC, page 5, for details of what this means. Beyond
the library fa ilities required of su h an implementation, the rest of the C library is supplied
by the vendor of the operating system. If that C library doesn't onform to the C standards,
then your programs might get warnings (espe ially when using `-Wall') that you don't
expe t.
For example, the sprintf fun tion on SunOS 4.1.3 returns har * while the C standard
says that sprintf returns an int. The fixin ludes program ould make the prototype
for this fun tion mat h the Standard, but that would be wrong, sin e the fun tion will still
return har *.
If you need a Standard ompliant library, then you need to nd one, as GCC does not
provide one. The GNU C library ( alled glib ) provides ISO C, POSIX, BSD, SystemV and
X/Open ompatibility for GNU/Linux and HURD-based GNU systems; no re ent version
of it supports other systems, though some very old versions did. Version 2.2 of the GNU
C library in ludes nearly omplete C99 support. You ould also ask your operating system
vendor if newer libraries are available.

10.7 Disappointments and Misunderstandings

These problems are perhaps regrettable, but we don't know any pra ti al way around them.
 Certain lo al variables aren't re ognized by debuggers when you ompile with optimization.
This o urs be ause sometimes GCC optimizes the variable out of existen e. There
is no way to tell the debugger how to ompute the value su h a variable \would have
had", and it is not lear that would be desirable anyway. So GCC simply does not
mention the eliminated variable when it writes debugging information.
You have to expe t a ertain amount of disagreement between the exe utable and your
sour e ode, when you use optimization.
 Users often think it is a bug when GCC reports an error for ode like this:
int foo (stru t mumble *);
stru t mumble { ... };
int foo (stru t mumble *x)
{ ... }

This ode really is erroneous, be ause the s ope of stru t mumble in the prototype
is limited to the argument list ontaining it. It does not refer to the stru t mumble
dened with le s ope immediately below|they are two unrelated types with similar
names in dierent s opes.
But in the denition of foo, the le-s ope type is used be ause that is available to be
inherited. Thus, the denition and the prototype do not mat h, and you get an error.

370




Using the GNU Compiler Colle tion (GCC)

This behavior may seem silly, but it's what the ISO standard spe ies. It is easy enough
for you to make your ode work by moving the denition of stru t mumble above the
prototype. It's not worth being in ompatible with ISO C just to avoid an error for the
example shown above.
A esses to bit-elds even in volatile obje ts works by a essing larger obje ts, su h as
a byte or a word. You annot rely on what size of obje t is a essed in order to read or
write the bit-eld; it may even vary for a given bit-eld a ording to the pre ise usage.
If you are about ontrolling the amount of memory that is a essed, use volatile but
do not use bit-elds.
GCC omes with shell s ripts to x ertain known problems in system header les.
They install orre ted opies of various header les in a spe ial dire tory where only
GCC will normally look for them. The s ripts adapt to various systems by sear hing
all the system header les for the problem ases that we know about.
If new system header les are installed, nothing automati ally arranges to update the
orre ted header les. They an be updated using the mkheaders s ript installed in
`libexe dir /g /target /version /install-tools/'.
On 68000 and x86 systems, for instan e, you an get paradoxi al results if you test
the pre ise values of oating point numbers. For example, you an nd that a oating
point value whi h is not a NaN is not equal to itself. This results from the fa t that
the oating point registers hold a few more bits of pre ision than t in a double in
memory. Compiled ode moves values between memory and oating point registers at
its onvenien e, and moving them into memory trun ates them.
You an partially avoid this problem by using the `-ffloat-store' option (see Se tion 3.10 [Optimize Options, page 61).
On AIX and other platforms without weak symbol support, templates need to be instantiated expli itly and symbols for stati members of templates will not be generated.
On AIX, GCC s ans obje t les and library ar hives for stati onstru tors and destru tors when linking an appli ation before the linker prunes unreferen ed symbols.
This is ne essary to prevent the AIX linker from mistakenly assuming that stati onstru tor or destru tor are unused and removing them before the s anning an o ur.
All stati onstru tors and destru tors found will be referen ed even though the modules in whi h they o ur may not be used by the program. This may lead to both
in reased exe utable size and unexpe ted symbol referen es.

10.8 Common Misunderstandings with GNU C++

C++ is a omplex language and an evolving one, and its standard denition (the ISO C++
standard) was only re ently ompleted. As a result, your C++ ompiler may o asionally
surprise you, even when its behavior is orre t. This se tion dis usses some areas that
frequently give rise to questions of this sort.

10.8.1 De lare and Dene Stati Members

When a lass has stati data members, it is not enough to de lare the stati member; you
must also dene it. For example:
lass Foo
{

Chapter 10: Known Causes of Trouble with GCC

371

...
void method();
stati int bar;

};

This de laration only establishes that the lass Foo has an int named Foo::bar, and a
member fun tion named Foo::method. But you still need to dene both method and bar
elsewhere. A ording to the ISO standard, you must supply an initializer in one (and only
one) sour e le, su h as:
int Foo::bar = 0;

Other C++ ompilers may not orre tly implement the standard behavior. As a result,
when you swit h to g++ from one of these ompilers, you may dis over that a program
that appeared to work orre tly in fa t does not onform to the standard: g++ reports as
undened symbols any stati data members that la k denitions.

10.8.2 Name lookup, templates, and a essing members of base

lasses

The C++ standard pres ribes that all names that are not dependent on template parameters
are bound to their present denitions when parsing a template fun tion or lass.1 Only
names that are dependent are looked up at the point of instantiation. For example, onsider
void foo(double);

stru t A {
template <typename T>
void f () {
foo (1);
// 1
int i = N;
// 2
T t;
t.bar();
// 3
foo (t);
// 4
}
};

stati onst int N;

Here, the names foo and N appear in a ontext that does not depend on the type of T.
The ompiler will thus require that they are dened in the ontext of use in the template,
not only before the point of instantiation, and will here use ::foo(double) and A::N,
respe tively. In parti ular, it will onvert the integer value to a double when passing it to
::foo(double).
Conversely, bar and the all to foo in the fourth marked line are used in ontexts that do
depend on the type of T, so they are only looked up at the point of instantiation, and you
an provide de larations for them after de laring the template, but before instantiating it.
In parti ular, if you instantiate A::f<int>, the last line will all an overloaded ::foo(int)
if one was provided, even if after the de laration of stru t A.
This distin tion between lookup of dependent and non-dependent names is alled twostage (or dependent) name lookup. G++ implements it sin e version 3.4.
Two-stage name lookup sometimes leads to situations with behavior dierent from nontemplate odes. The most ommon is probably this:
1

The C++ standard just uses the term \dependent" for names that depend on the type or value of template
parameters. This shorter term will also be used in the rest of this se tion.

372

Using the GNU Compiler Colle tion (GCC)

template <typename T> stru t Base {

int i;
};
template <typename T> stru t Derived : publi Base<T> {
int get_i() { return i; }
};

In get_i(), i is not used in a dependent ontext, so the ompiler will look for a name
de lared at the en losing namespa e s ope (whi h is the global s ope here). It will not look
into the base lass, sin e that is dependent and you may de lare spe ializations of Base
even after de laring Derived, so the ompiler an't really know what i would refer to. If
there is no global variable i, then you will get an error message.
In order to make it lear that you want the member of the base lass, you need to defer
lookup until instantiation time, at whi h the base lass is known. For this, you need to
a ess i in a dependent ontext, by either using this->i (remember that this is of type
Derived<T>*, so is obviously dependent), or using Base<T>::i. Alternatively, Base<T>::i
might be brought into s ope by a using-de laration.
Another, similar example involves alling member fun tions of a base lass:
template <typename T> stru t Base {
int f();
};

template <typename T> stru t Derived : Base<T> {

int g() { return f(); };
};

Again, the all to f() is not dependent on template arguments (there are no arguments
that depend on the type T, and it is also not otherwise spe ied that the all should be
in a dependent ontext). Thus a global de laration of su h a fun tion must be available,
sin e the one in the base lass is not visible until instantiation time. The ompiler will
onsequently produ e the following error message:
x. : In member fun tion `int Derived<T>::g()':
x. :6: error: there are no arguments to `f' that depend on a template
parameter, so a de laration of `f' must be available
x. :6: error: (if you use `-fpermissive', G++ will a ept your ode, but
allowing the use of an unde lared name is depre ated)

To make the ode valid either use this->f(), or Base<T>::f(). Using the
`-fpermissive' ag will also let the ompiler a ept the ode, by marking all fun tion
alls for whi h no de laration is visible at the time of denition of the template for later
lookup at instantiation time, as if it were a dependent all. We do not re ommend using
`-fpermissive' to work around invalid ode, and it will also only at h ases where
fun tions in base lasses are alled, not where variables in base lasses are used (as in the
example above).
Note that some ompilers (in luding G++ versions prior to 3.4) get these examples wrong
and a ept above ode without an error. Those ompilers do not implement two-stage name
lookup orre tly.

10.8.3 Temporaries May Vanish Before You Expe t

It is dangerous to use pointers or referen es to portions of a temporary obje t. The ompiler

may very well delete the obje t before you expe t it to, leaving a pointer to garbage. The

Chapter 10: Known Causes of Trouble with GCC

373

most ommon pla e where this problem rops up is in lasses like string lasses, espe ially
ones that dene a onversion fun tion to type har * or onst har *|whi h is one reason
why the standard string lass requires you to all the _str member fun tion. However,
any lass that returns a pointer to some internal stru ture is potentially subje t to this
problem.
For example, a program may use a fun tion strfun that returns string obje ts, and
another fun tion harfun that operates on pointers to har:
string strfun ();
void harfun ( onst har *);
void
f ()
{
onst har *p = strfun (). _str();
...
harfun (p);
...
harfun (p);
}

In this situation, it may seem reasonable to save a pointer to the C string returned by
the _str member fun tion and use that rather than all _str repeatedly. However, the
temporary string reated by the all to strfun is destroyed after p is initialized, at whi h
point p is left pointing to freed memory.
Code like this may run su essfully under some other ompilers, parti ularly obsolete
front-based ompilers that delete temporaries along with normal lo al variables. However, the GNU C++ behavior is standard- onforming, so if your program depends on late
destru tion of temporaries it is not portable.
The safe way to write su h ode is to give the temporary a name, whi h for es it to
remain until the end of the s ope of the name. For example:
onst string& tmp = strfun ();
harfun (tmp. _str ());

10.8.4 Impli it Copy-Assignment for Virtual Bases

When a base lass is virtual, only one subobje t of the base lass belongs to ea h full
obje t. Also, the onstru tors and destru tors are invoked only on e, and alled from the
most-derived lass. However, su h obje ts behave unspe ied when being assigned. For
example:
stru t Base{
har *name;
Base( har *n) : name(strdup(n)){}
Base& operator= ( onst Base& other){
free (name);
name = strdup (other.name);
}
};
stru t A:virtual Base{
int val;
A():Base("A"){}
};

374

Using the GNU Compiler Colle tion (GCC)

stru t B:virtual Base{

int bval;
B():Base("B"){}
};
stru t Derived:publi A, publi B{
Derived():Base("Derived"){}
};
void fun (Derived &d1, Derived &d2)
{
d1 = d2;
}

The C++ standard spe ies that `Base::Base' is only alled on e when onstru ting or
opy- onstru ting a Derived obje t. It is unspe ied whether `Base::operator=' is alled
more than on e when the impli it opy-assignment for Derived obje ts is invoked (as it is
inside `fun ' in the example).
G++ implements the \intuitive" algorithm for opy-assignment: assign all dire t bases,
then assign all members. In that algorithm, the virtual base subobje t an be en ountered
more than on e. In the example, opying pro eeds in the following order: `val', `name' (via
strdup), `bval', and `name' again.
If appli ation ode relies on opy-assignment, a user-dened opy-assignment operator
removes any un ertainties. With su h an operator, the appli ation an dene whether and
how the virtual base subobje t is assigned.

10.9 Caveats of using protoize

The onversion programs protoize and unprotoize an sometimes hange a sour e le in
a way that won't work unless you rearrange it.
 protoize an insert referen es to a type name or type tag before the denition, or in
a le where they are not dened.
If this happens, ompiler error messages should show you where the new referen es are,
so xing the le by hand is straightforward.
 There are some C onstru ts whi h protoize annot gure out. For example, it an't
determine argument types for de laring a pointer-to-fun tion variable; this you must
do by hand. protoize inserts a omment ontaining `???' ea h time it nds su h a
variable; so you an nd all su h variables by sear hing for this string. ISO C does not
require de laring the argument types of pointer-to-fun tion types.
 Using unprotoize an easily introdu e bugs. If the program relied on prototypes
to bring about onversion of arguments, these onversions will not take pla e in the
program without prototypes. One ase in whi h you an be sure unprotoize is safe
is when you are removing prototypes that were made with protoize; if the program
worked before without any prototypes, it will work again without them.
You an nd all the pla es where this problem might o ur by ompiling the program with the `-W onversion' option. It prints a warning whenever an argument is
onverted.
 Both onversion programs an be onfused if there are ma ro alls in and around the
text to be onverted. In other words, the standard syntax for a de laration or denition

Chapter 10: Known Causes of Trouble with GCC




375

must not result from expanding a ma ro. This problem is inherent in the design of C
and annot be xed. If only a few fun tions have onfusing ma ro alls, you an easily
onvert them manually.
protoize annot get the argument types for a fun tion whose denition was not a tually ompiled due to prepro essing onditionals. When this happens, protoize hanges
nothing in regard to su h a fun tion. protoize tries to dete t su h instan es and warn
about them.
You an generally work around this problem by using protoize step by step, ea h
time spe ifying a dierent set of `-D' options for ompilation, until all of the fun tions
have been onverted. There is no automati way to verify that you have got them all,
however.
Confusion may result if there is an o asion to onvert a fun tion de laration or definition in a region of sour e ode where there is more than one formal parameter list
present. Thus, attempts to onvert ode ontaining multiple ( onditionally ompiled)
versions of a single fun tion header (in the same vi inity) may not produ e the desired
(or expe ted) results.
If you plan on onverting sour e les whi h ontain su h ode, it is re ommended
that you rst make sure that ea h onditionally ompiled region of sour e ode whi h
ontains an alternative fun tion header also ontains at least one additional follower
token (past the nal right parenthesis of the fun tion header). This should ir umvent
the problem.
unprotoize an be ome onfused when trying to onvert a fun tion denition or de laration whi h ontains a de laration for a pointer-to-fun tion formal argument whi h
has the same name as the fun tion being dened or de lared. We re ommend you avoid
su h hoi es of formal parameter names.
You might also want to orre t some of the indentation by hand and break long lines.
(The onversion programs don't write lines longer than eighty hara ters in any ase.)

10.10 Certain Changes We Don't Want to Make

This se tion lists hanges that people frequently request, but whi h we do not make be ause
we think GCC is better without them.
 Che king the number and type of arguments to a fun tion whi h has an old-fashioned
denition and no prototype.
Su h a feature would work only o asionally|only for alls that appear in the same
le as the alled fun tion, following the denition. The only way to he k all alls
reliably is to add a prototype for the fun tion. But adding a prototype eliminates the
motivation for this feature. So the feature is not worthwhile.
 Warning about using an expression whose type is signed as a shift ount.
Shift ount operands are probably signed more often than unsigned. Warning about
this would ause far more annoyan e than good.
 Warning about assigning a signed value to an unsigned variable.
Su h assignments must be very ommon; warning about them would ause more annoyan e than good.

376

Using the GNU Compiler Colle tion (GCC)

Warning when a non-void fun tion value is ignored.

C ontains many standard fun tions that return a value that most programs hoose to
ignore. One obvious example is printf. Warning about this pra ti e only leads the
defensive programmer to lutter programs with dozens of asts to void. Su h asts
are required so frequently that they be ome visual noise. Writing those asts be omes
so automati that they no longer onvey useful information about the intentions of
the programmer. For fun tions where the return value should never be ignored, use
the warn_unused_result fun tion attribute (see Se tion 5.24 [Fun tion Attributes,
page 217).
Making `-fshort-enums' the default.
This would ause storage layout to be in ompatible with most other C ompilers. And
it doesn't seem very important, given that you an get the same result in other ways.
The ase where it matters most is when the enumeration-valued obje t is inside a
stru ture, and in that ase you an spe ify a eld width expli itly.
Making bit-elds unsigned by default on parti ular ma hines where \the ABI standard"
says to do so.
The ISO C standard leaves it up to the implementation whether a bit-eld de lared
plain int is signed or not. This in ee t reates two alternative diale ts of C.
The GNU C ompiler supports both diale ts; you an spe ify the signed diale t with
`-fsigned-bitfields' and the unsigned diale t with `-funsigned-bitfields'. However, this leaves open the question of whi h diale t to use by default.
Currently, the preferred diale t makes plain bit-elds signed, be ause this is simplest.
Sin e int is the same as signed int in every other ontext, it is leanest for them to
be the same in bit-elds as well.
Some omputer manufa turers have published Appli ation Binary Interfa e standards
whi h spe ify that plain bit-elds should be unsigned. It is a mistake, however, to say
anything about this issue in an ABI. This is be ause the handling of plain bit-elds
distinguishes two diale ts of C. Both diale ts are meaningful on every type of ma hine.
Whether a parti ular obje t le was ompiled using signed bit-elds or unsigned is of
no on ern to other obje t les, even if they a ess the same bit-elds in the same data
stru tures.
A given program is written in one or the other of these two diale ts. The program
stands a han e to work on most any ma hine if it is ompiled with the proper diale t.
It is unlikely to work at all if ompiled with the wrong diale t.
Many users appre iate the GNU C ompiler be ause it provides an environment that is
uniform a ross ma hines. These users would be in onvenien ed if the ompiler treated
plain bit-elds dierently on ertain ma hines.
O asionally users write programs intended only for a parti ular ma hine type. On
these o asions, the users would benet if the GNU C ompiler were to support by
default the same diale t as the other ompilers on that ma hine. But su h appli ations
are rare. And users writing a program to run on more than one type of ma hine annot
possibly benet from this kind of ompatibility.
This is why GCC does and will treat plain bit-elds in the same fashion on all types
of ma hines (by default).

Chapter 10: Known Causes of Trouble with GCC

377

There are some arguments for making bit-elds unsigned by default on all ma hines.
If, for example, this be omes a universal de fa to standard, it would make sense for
GCC to go along with it. This is something to be onsidered in the future.
(Of ourse, users strongly on erned about portability should indi ate expli itly in ea h
bit-eld whether it is signed or not. In this way, they write programs whi h have the
same meaning in both C diale ts.)
Undening __STDC__ when `-ansi' is not used.
Currently, GCC denes __STDC__ un onditionally. This provides good results in pra ti e.
Programmers normally use onditionals on __STDC__ to ask whether it is safe to use
ertain features of ISO C, su h as fun tion prototypes or ISO token on atenation.
Sin e plain g supports all the features of ISO C, the orre t answer to these questions
is \yes".
Some users try to use __STDC__ to he k for the availability of ertain library fa ilities.
This is a tually in orre t usage in an ISO C program, be ause the ISO C standard says
that a onforming freestanding implementation should dene __STDC__ even though it
does not have the library fa ilities. `g -ansi -pedanti ' is a onforming freestanding
implementation, and it is therefore required to dene __STDC__, even though it does
not ome with an ISO C library.
Sometimes people say that dening __STDC__ in a ompiler that does not ompletely
onform to the ISO C standard somehow violates the standard. This is illogi al. The
standard is a standard for ompilers that laim to support ISO C, su h as `g -ansi'|
not for other ompilers su h as plain g . Whatever the ISO C standard says is
relevant to the design of plain g without `-ansi' only for pragmati reasons, not as
a requirement.
GCC normally denes __STDC__ to be 1, and in addition denes __STRICT_ANSI__ if
you spe ify the `-ansi' option, or a `-std' option for stri t onforman e to some version
of ISO C. On some hosts, system in lude les use a dierent onvention, where __STDC_
_ is normally 0, but is 1 if the user spe ies stri t onforman e to the C Standard. GCC
follows the host onvention when pro essing system in lude les, but when pro essing
user les it follows the usual GNU C onvention.
Undening __STDC__ in C++.
Programs written to ompile with C++-to-C translators get the value of __STDC__ that
goes with the C ompiler that is subsequently used. These programs must test __STDC_
_ to determine what kind of C prepro essor that ompiler uses: whether they should
on atenate tokens in the ISO C fashion or in the traditional fashion.
These programs work properly with GNU C++ if __STDC__ is dened. They would not
work otherwise.
In addition, many header les are written to provide prototypes in ISO C but not in
traditional C. Many of these header les an work without hange in C++ provided
__STDC__ is dened. If __STDC__ is not dened, they will all fail, and will all need to
be hanged to test expli itly for C++ as well.
Deleting \empty" loops.

378

Using the GNU Compiler Colle tion (GCC)

Histori ally, GCC has not deleted \empty" loops under the assumption that the most
likely reason you would put one in a program is to have a delay, so deleting them will
not make real programs run any faster.
However, the rationale here is that optimization of a nonempty loop annot produ e
an empty one. This held for arefully written C ompiled with less powerful optimizers
but is not always the ase for arefully written C++ or with more powerful optimizers.
Thus GCC will remove operations from loops whenever it an determine those operations are not externally visible (apart from the time taken to exe ute them, of ourse).
As GCC improves, it will remove the loop itself. Indeed, with `-funroll-loops' small
loops an already be removed, so leaving an empty non-unrolled loop is both suboptimal and in onsistent.
Be aware of this when performing timing tests, for instan e the following loop an be
ompletely removed, provided some_expression an provably not hange any global
state.
{

int sum = 0;
int ix;
for (ix = 0; ix != 10000; ix++)
sum += some_expression;

Even though sum is a umulated in the loop, no use is made of that summation, so the
a umulation an be removed.
Making side ee ts happen in the same order as in some other ompiler.
It is never safe to depend on the order of evaluation of side ee ts. For example, a
fun tion all like this may very well behave dierently from one ompiler to another:
void fun (int, int);
int i = 2;
fun (i++, i++);

There is no guarantee (in either the C or the C++ standard language denitions) that the
in rements will be evaluated in any parti ular order. Either in rement might happen
rst. fun might get the arguments `2, 3', or it might get `3, 2', or even `2, 2'.
Making ertain warnings into errors by default.
Some ISO C testsuites report failure when the ompiler does not produ e an error
message for a ertain program.
ISO C requires a \diagnosti " message for ertain kinds of invalid programs, but a
warning is dened by GCC to ount as a diagnosti . If GCC produ es a warning but
not an error, that is orre t ISO C support. If testsuites all this \failure", they should
be run with the GCC option `-pedanti -errors', whi h will turn these warnings into
errors.

10.11 Warning Messages and Error Messages

The GNU ompiler an produ e two kinds of diagnosti s: errors and warnings. Ea h kind
has a dierent purpose:

Chapter 10: Known Causes of Trouble with GCC

379

Errors report problems that make it impossible to ompile your program. GCC reports
errors with the sour e le name and line number where the problem is apparent.
Warnings report other unusual onditions in your ode that may indi ate a problem,
although ompilation an (and does) pro eed. Warning messages also report the sour e
le name and line number, but in lude the text `warning:' to distinguish them from
error messages.
Warnings may indi ate danger points where you should he k to make sure that your
program really does what you intend; or the use of obsolete features; or the use of nonstandard features of GNU C or C++. Many warnings are issued only if you ask for them, with
one of the `-W' options (for instan e, `-Wall' requests a variety of useful warnings).
GCC always tries to ompile your program if possible; it never gratuitously reje ts a
program whose meaning is lear merely be ause (for instan e) it fails to onform to a
standard. In some ases, however, the C and C++ standards spe ify that ertain extensions
are forbidden, and a diagnosti must be issued by a onforming ompiler. The `-pedanti '
option tells GCC to issue warnings in su h ases; `-pedanti -errors' says to make them
errors instead. This does not mean that all non-ISO onstru ts get warnings or errors.
See Se tion 3.8 [Options to Request or Suppress Warnings, page 34, for more detail on
these and related ommand-line options.

380

Using the GNU Compiler Colle tion (GCC)

Chapter 11: Reporting Bugs

381

11 Reporting Bugs
Your bug reports play an essential role in making GCC reliable.
When you en ounter a problem, the rst thing to do is to see if it is already known. See
Chapter 10 [Trouble, page 363. If it isn't known, then you should report the problem.

11.1 Have You Found a Bug?

If you are not sure whether you have found a bug, here are some guidelines:
 If the ompiler gets a fatal signal, for any input whatever, that is a ompiler bug.
Reliable ompilers never rash.
 If the ompiler produ es invalid assembly ode, for any input whatever (ex ept an
asm statement), that is a ompiler bug, unless the ompiler reports errors (not just
warnings) whi h would ordinarily prevent the assembler from being run.
 If the ompiler produ es valid assembly ode that does not orre tly exe ute the input
sour e ode, that is a ompiler bug.
However, you must double- he k to make sure, be ause you may have a program whose
behavior is undened, whi h happened by han e to give the desired results with another C or C++ ompiler.
For example, in many nonoptimizing ompilers, you an write `x;' at the end of a
fun tion instead of `return x;', with the same results. But the value of the fun tion
is undened if return is omitted; it is not a bug when GCC produ es dierent results.
Problems often result from expressions with two in rement operators, as in f (*p++,
*p++). Your previous ompiler might have interpreted that expression the way you
intended; GCC might interpret it another way. Neither ompiler is wrong. The bug is
in your ode.
After you have lo alized the error to a single sour e line, it should be easy to he k for
these things. If your program is orre t and well dened, you have found a ompiler
bug.
 If the ompiler produ es an error message for valid input, that is a ompiler bug.
 If the ompiler does not produ e an error message for invalid input, that is a ompiler
bug. However, you should note that your idea of \invalid input" might be someone
else's idea of \an extension" or \support for traditional pra ti e".
 If you are an experien ed user of one of the languages GCC supports, your suggestions
for improvement of GCC are wel ome in any ase.

11.2 How and where to Report Bugs

Bugs should be reported to the GCC bug database. Please refer to http://g .gnu.org/bugs.html
for up-to-date instru tions how to submit bug reports. Copies of this le in HTML
(`bugs.html') and plain text (`BUGS') are also part of GCC releases.

382

Using the GNU Compiler Colle tion (GCC)

Chapter 12: How To Get Help with GCC

383

12 How To Get Help with GCC

If you need help installing, using or hanging GCC, there are two ways to nd it:
 Send a message to a suitable network mailing list. First try g -helpg .gnu.org (for
help installing or using GCC), and if that brings no response, try g g .gnu.org.
For help hanging GCC, ask g g .gnu.org. If you think you have found a bug in
GCC, please report it following the instru tions at see Se tion 11.2 [Bug Reporting,
page 381.
 Look in the servi e dire tory for someone who might help you for a fee. The servi e
dire tory is found at http://www.gnu.org/prep/servi e.html.
For further information, see http://g .gnu.org/faq.html#support.

384

Using the GNU Compiler Colle tion (GCC)

Chapter 13: Contributing to GCC Development

385

13 Contributing to GCC Development

If you would like to help pretest GCC releases to assure they work well, urrent development
sour es are available by CVS (see http://g .gnu.org/ vs.html). Sour e and binary
snapshots are also available for FTP; see http://g .gnu.org/snapshots.html.
If you would like to work on improvements to GCC, please read the advi e at these URLs:
http://g .gnu.org/ ontribute.html
http://g .gnu.org/ ontributewhy.html

for information on how to make useful ontributions and avoid dupli ation of eort. Suggested proje ts are listed at http://g .gnu.org/proje ts/.

386

Using the GNU Compiler Colle tion (GCC)

Chapter 13: Funding Free Software

387

Funding Free Software

If you want to have more free software a few years from now, it makes sense for you to
help en ourage people to ontribute funds for its development. The most ee tive approa h
known is to en ourage ommer ial redistributors to donate.
Users of free software systems an boost the pa e of development by en ouraging for-afee distributors to donate part of their selling pri e to free software developers|the Free
Software Foundation, and others.
The way to onvin e distributors to do this is to demand it and expe t it from them. So
when you ompare distributors, judge them partly by how mu h they give to free software
development. Show distributors they must ompete to be the one who gives the most.
To make this approa h work, you must insist on numbers that you an ompare, su h as,
\We will donate ten dollars to the Frobnitz proje t for ea h disk sold." Don't be satised
with a vague promise, su h as \A portion of the prots are donated," sin e it doesn't give
a basis for omparison.
Even a pre ise fra tion \of the prots from this disk" is not very meaningful, sin e reative
a ounting and unrelated business de isions an greatly alter what fra tion of the sales pri e
ounts as prot. If the pri e you pay is $50, ten per ent of the prot is probably less than
a dollar; it might be a few ents, or nothing at all.
Some redistributors do development work themselves. This is useful too; but to keep
everyone honest, you need to inquire how mu h they do, and what kind. Some kinds of
development make mu h more long-term dieren e than others. For example, maintaining
a separate version of a program ontributes very little; maintaining the standard version
of a program for the whole ommunity ontributes mu h. Easy new ports ontribute little,
sin e someone else would surely do them; di ult ports su h as adding a new CPU to the
GNU Compiler Colle tion ontribute more; major new features or pa kages ontribute the
most.
By establishing the idea that supporting further development is \the proper thing to
do" when distributing free software for a fee, we an assure a steady ow of resour es into
making more free software.
1994 Free Software Foundation, In .
Copyright
Verbatim opying and redistribution of this se tion is permitted
without royalty; alteration is not permitted.

388

Using the GNU Compiler Colle tion (GCC)

Chapter 13: The GNU Proje t and GNU/Linux

389

The GNU Proje t and GNU/Linux

The GNU Proje t was laun hed in 1984 to develop a omplete Unix-like operating system
whi h is free software: the GNU system. (GNU is a re ursive a ronym for \GNU's Not
Unix"; it is pronoun ed \guh-NEW".) Variants of the GNU operating system, whi h use the
kernel Linux, are now widely used; though these systems are often referred to as \Linux",
they are more a urately alled GNU/Linux systems.
For more information, see:
http://www.gnu.org/
http://www.gnu.org/gnu/linux-and-gnu.html

390

Using the GNU Compiler Colle tion (GCC)

Chapter 13: GNU GENERAL PUBLIC LICENSE

391

GNU GENERAL PUBLIC LICENSE

Version 2, June 1991

1989, 1991 Free Software Foundation, In .

Copyright
59 Temple Pla e - Suite 330, Boston, MA 02111-1307, USA
Everyone is permitted to opy and distribute verbatim opies
of this li ense do ument, but hanging it is not allowed.

Preamble
The li enses for most software are designed to take away your freedom to share and hange
it. By ontrast, the GNU General Publi Li ense is intended to guarantee your freedom
to share and hange free software|to make sure the software is free for all its users. This
General Publi Li ense applies to most of the Free Software Foundation's software and to
any other program whose authors ommit to using it. (Some other Free Software Foundation
software is overed by the GNU Library General Publi Li ense instead.) You an apply it
to your programs, too.
When we speak of free software, we are referring to freedom, not pri e. Our General
Publi Li enses are designed to make sure that you have the freedom to distribute opies
of free software (and harge for this servi e if you wish), that you re eive sour e ode or
an get it if you want it, that you an hange the software or use pie es of it in new free
programs; and that you know you an do these things.
To prote t your rights, we need to make restri tions that forbid anyone to deny you
these rights or to ask you to surrender the rights. These restri tions translate to ertain
responsibilities for you if you distribute opies of the software, or if you modify it.
For example, if you distribute opies of su h a program, whether gratis or for a fee, you
must give the re ipients all the rights that you have. You must make sure that they, too,
re eive or an get the sour e ode. And you must show them these terms so they know
their rights.
We prote t your rights with two steps: (1) opyright the software, and (2) oer you this
li ense whi h gives you legal permission to opy, distribute and/or modify the software.
Also, for ea h author's prote tion and ours, we want to make ertain that everyone
understands that there is no warranty for this free software. If the software is modied by
someone else and passed on, we want its re ipients to know that what they have is not the
original, so that any problems introdu ed by others will not re e t on the original authors'
reputations.
Finally, any free program is threatened onstantly by software patents. We wish to avoid
the danger that redistributors of a free program will individually obtain patent li enses, in
ee t making the program proprietary. To prevent this, we have made it lear that any
patent must be li ensed for everyone's free use or not li ensed at all.
The pre ise terms and onditions for opying, distribution and modi ation follow.

392

Using the GNU Compiler Colle tion (GCC)

TERMS AND CONDITIONS FOR COPYING,

DISTRIBUTION AND MODIFICATION
0. This Li ense applies to any program or other work whi h ontains a noti e pla ed
by the opyright holder saying it may be distributed under the terms of this General
Publi Li ense. The \Program", below, refers to any su h program or work, and a
\work based on the Program" means either the Program or any derivative work under
opyright law: that is to say, a work ontaining the Program or a portion of it, either
verbatim or with modi ations and/or translated into another language. (Hereinafter,
translation is in luded without limitation in the term \modi ation".) Ea h li ensee is
addressed as \you".
A tivities other than opying, distribution and modi ation are not overed by this
Li ense; they are outside its s ope. The a t of running the Program is not restri ted,
and the output from the Program is overed only if its ontents onstitute 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 opy and distribute verbatim opies of the Program's sour e ode as you
re eive it, in any medium, provided that you onspi uously and appropriately publish
on ea h opy an appropriate opyright noti e and dis laimer of warranty; keep inta t
all the noti es that refer to this Li ense and to the absen e of any warranty; and give
any other re ipients of the Program a opy of this Li ense along with the Program.
You may harge a fee for the physi al a t of transferring a opy, and you may at your
option oer warranty prote tion in ex hange for a fee.
2. You may modify your opy or opies of the Program or any portion of it, thus forming a
work based on the Program, and opy and distribute su h modi ations or work under
the terms of Se tion 1 above, provided that you also meet all of these onditions:
a. You must ause the modied les to arry prominent noti es stating that you
hanged the les and the date of any hange.
b. You must ause any work that you distribute or publish, that in whole or in part
ontains or is derived from the Program or any part thereof, to be li ensed as a
whole at no harge to all third parties under the terms of this Li ense.
. If the modied program normally reads ommands intera tively when run, you
must ause it, when started running for su h intera tive use in the most ordinary
way, to print or display an announ ement in luding an appropriate opyright noti e
and a noti e that there is no warranty (or else, saying that you provide a warranty)
and that users may redistribute the program under these onditions, and telling
the user how to view a opy of this Li ense. (Ex eption: if the Program itself is
intera tive but does not normally print su h an announ ement, your work based
on the Program is not required to print an announ ement.)
These requirements apply to the modied work as a whole. If identiable se tions
of that work are not derived from the Program, and an be reasonably onsidered
independent and separate works in themselves, then this Li ense, and its terms, do not
apply to those se tions when you distribute them as separate works. But when you
distribute the same se tions as part of a whole whi h is a work based on the Program,
the distribution of the whole must be on the terms of this Li ense, whose permissions
for other li ensees extend to the entire whole, and thus to ea h and every part regardless
of who wrote it.

Chapter 13: GNU GENERAL PUBLIC LICENSE

393

Thus, it is not the intent of this se tion to laim rights or ontest your rights to
work written entirely by you; rather, the intent is to exer ise the right to ontrol the
distribution of derivative or olle tive 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 s ope of this Li ense.
3. You may opy and distribute the Program (or a work based on it, under Se tion 2)
in obje t ode or exe utable form under the terms of Se tions 1 and 2 above provided
that you also do one of the following:
a. A ompany it with the omplete orresponding ma hine-readable sour e ode,
whi h must be distributed under the terms of Se tions 1 and 2 above on a medium
ustomarily used for software inter hange; or,
b. A ompany it with a written oer, valid for at least three years, to give any third
party, for a harge no more than your ost of physi ally performing sour e distribution, a omplete ma hine-readable opy of the orresponding sour e ode, to be
distributed under the terms of Se tions 1 and 2 above on a medium ustomarily
used for software inter hange; or,
. A ompany it with the information you re eived as to the oer to distribute orresponding sour e ode. (This alternative is allowed only for non ommer ial distribution and only if you re eived the program in obje t ode or exe utable form
with su h an oer, in a ord with Subse tion b above.)
The sour e ode for a work means the preferred form of the work for making modi ations to it. For an exe utable work, omplete sour e ode means all the sour e ode
for all modules it ontains, plus any asso iated interfa e denition les, plus the s ripts
used to ontrol ompilation and installation of the exe utable. However, as a spe ial ex eption, the sour e ode distributed need not in lude anything that is normally
distributed (in either sour e or binary form) with the major omponents ( ompiler,
kernel, and so on) of the operating system on whi h the exe utable runs, unless that
omponent itself a ompanies the exe utable.
If distribution of exe utable or obje t ode is made by oering a ess to opy from
a designated pla e, then oering equivalent a ess to opy the sour e ode from the
same pla e ounts as distribution of the sour e ode, even though third parties are not
ompelled to opy the sour e along with the obje t ode.
4. You may not opy, modify, subli ense, or distribute the Program ex ept as expressly
provided under this Li ense. Any attempt otherwise to opy, modify, subli ense or
distribute the Program is void, and will automati ally terminate your rights under this
Li ense. However, parties who have re eived opies, or rights, from you under this
Li ense will not have their li enses terminated so long as su h parties remain in full
omplian e.
5. You are not required to a ept this Li ense, sin e you have not signed it. However,
nothing else grants you permission to modify or distribute the Program or its derivative
works. These a tions are prohibited by law if you do not a ept this Li ense. Therefore,
by modifying or distributing the Program (or any work based on the Program), you
indi ate your a eptan e of this Li ense to do so, and all its terms and onditions for
opying, distributing or modifying the Program or works based on it.

394

Using the GNU Compiler Colle tion (GCC)

6. Ea h time you redistribute the Program (or any work based on the Program), the
re ipient automati ally re eives a li ense from the original li ensor to opy, distribute
or modify the Program subje t to these terms and onditions. You may not impose
any further restri tions on the re ipients' exer ise of the rights granted herein. You are
not responsible for enfor ing omplian e by third parties to this Li ense.
7. If, as a onsequen e of a ourt judgment or allegation of patent infringement or for any
other reason (not limited to patent issues), onditions are imposed on you (whether by
ourt order, agreement or otherwise) that ontradi t the onditions of this Li ense, they
do not ex use you from the onditions of this Li ense. If you annot distribute so as
to satisfy simultaneously your obligations under this Li ense and any other pertinent
obligations, then as a onsequen e you may not distribute the Program at all. For
example, if a patent li ense would not permit royalty-free redistribution of the Program
by all those who re eive opies dire tly or indire tly through you, then the only way
you ould satisfy both it and this Li ense would be to refrain entirely from distribution
of the Program.
If any portion of this se tion is held invalid or unenfor eable under any parti ular
ir umstan e, the balan e of the se tion is intended to apply and the se tion as a
whole is intended to apply in other ir umstan es.
It is not the purpose of this se tion to indu e you to infringe any patents or other
property right laims or to ontest validity of any su h laims; this se tion has the
sole purpose of prote ting the integrity of the free software distribution system, whi h
is implemented by publi li ense pra ti es. Many people have made generous ontributions to the wide range of software distributed through that system in relian e on
onsistent appli ation of that system; it is up to the author/donor to de ide if he or
she is willing to distribute software through any other system and a li ensee annot
impose that hoi e.
This se tion is intended to make thoroughly lear what is believed to be a onsequen e
of the rest of this Li ense.
8. If the distribution and/or use of the Program is restri ted in ertain ountries either
by patents or by opyrighted interfa es, the original opyright holder who pla es the
Program under this Li ense may add an expli it geographi al distribution limitation
ex luding those ountries, so that distribution is permitted only in or among ountries
not thus ex luded. In su h ase, this Li ense in orporates the limitation as if written
in the body of this Li ense.
9. The Free Software Foundation may publish revised and/or new versions of the General
Publi Li ense from time to time. Su h new versions will be similar in spirit to the
present version, but may dier in detail to address new problems or on erns.
Ea h version is given a distinguishing version number. If the Program spe ies a
version number of this Li ense whi h applies to it and \any later version", you have
the option of following the terms and onditions either of that version or of any later
version published by the Free Software Foundation. If the Program does not spe ify a
version number of this Li ense, you may hoose any version ever published by the Free
Software Foundation.
10. If you wish to in orporate parts of the Program into other free programs whose distribution onditions are dierent, write to the author to ask for permission. For software

Chapter 13: GNU GENERAL PUBLIC LICENSE

395

whi h is opyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make ex eptions for this. Our de ision 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

396

Using the GNU Compiler Colle tion (GCC)

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 publi ,
the best way to a hieve this is to make it free software whi h everyone an redistribute and
hange under these terms.
To do so, atta h the following noti es to the program. It is safest to atta h them to the
start of ea h sour e le to most ee tively onvey the ex lusion of warranty; and ea h le
should have at least the \ opyright" line and a pointer to where the full noti e is found.
one line to give the program's name and a brief idea of what it does.
Copyright (C) year name of author
This program is free software; you an redistribute it and/or modify
it under the terms of the GNU General Publi Li ense as published by
the Free Software Foundation; either version 2 of the Li ense, 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 Publi Li ense for more details.
You should have re eived a opy of the GNU General Publi Li ense
along with this program; if not, write to the Free Software Foundation,
In ., 59 Temple Pla e - Suite 330, Boston, MA 02111-1307, USA.

Also add information on how to onta t you by ele troni and paper mail.
If the program is intera tive, make it output a short noti e like this when it starts in an
intera tive mode:
Gnomovision version 69, Copyright (C) year name of author
Gnomovision omes with ABSOLUTELY NO WARRANTY; for details
type `show w'.
This is free software, and you are wel ome to redistribute it
under ertain onditions; type `show ' for details.

The hypotheti al ommands `show w' and `show ' should show the appropriate parts of
the General Publi Li ense. Of ourse, the ommands you use may be alled something
other than `show w' and `show '; they ould even be mouse- li ks or menu items|whatever
suits your program.
You should also get your employer (if you work as a programmer) or your s hool, if any,
to sign a \ opyright dis laimer" for the program, if ne essary. Here is a sample; alter the
names:
Yoyodyne, In ., hereby dis laims all opyright interest in the program
`Gnomovision' (whi h makes passes at ompilers) written by James Ha ker.
signature of Ty Coon, 1 April 1989
Ty Coon, President of Vi e

This General Publi Li ense does not permit in orporating your program into proprietary
programs. If your program is a subroutine library, you may onsider it more useful to permit
linking proprietary appli ations with the library. If this is what you want to do, use the
GNU Library General Publi Li ense instead of this Li ense.

Chapter 13: GNU Free Do umentation Li ense

397

GNU Free Do umentation Li ense

Version 1.2, November 2002

Copyright 2000,2001,2002 Free Software Foundation, In .
59 Temple Pla e, Suite 330, Boston, MA 02111-1307, USA
Everyone is permitted to opy and distribute verbatim opies
of this li ense do ument, but hanging it is not allowed.
0. PREAMBLE
The purpose of this Li ense is to make a manual, textbook, or other fun tional and
useful do ument free in the sense of freedom: to assure everyone the ee tive freedom
to opy and redistribute it, with or without modifying it, either ommer ially or non ommer ially. Se ondarily, this Li ense preserves for the author and publisher a way
to get redit for their work, while not being onsidered responsible for modi ations
made by others.
This Li ense is a kind of \ opyleft", whi h means that derivative works of the do ument
must themselves be free in the same sense. It omplements the GNU General Publi
Li ense, whi h is a opyleft li ense designed for free software.
We have designed this Li ense in order to use it for manuals for free software, be ause
free software needs free do umentation: a free program should ome with manuals
providing the same freedoms that the software does. But this Li ense is not limited to
software manuals; it an be used for any textual work, regardless of subje t matter or
whether it is published as a printed book. We re ommend this Li ense prin ipally for
works whose purpose is instru tion or referen e.
1. APPLICABILITY AND DEFINITIONS
This Li ense applies to any manual or other work, in any medium, that ontains a
noti e pla ed by the opyright holder saying it an be distributed under the terms
of this Li ense. Su h a noti e grants a world-wide, royalty-free li ense, unlimited in
duration, to use that work under the onditions stated herein. The \Do ument",
below, refers to any su h manual or work. Any member of the publi is a li ensee, and
is addressed as \you". You a ept the li ense if you opy, modify or distribute the work
in a way requiring permission under opyright law.
A \Modied Version" of the Do ument means any work ontaining the Do ument or
a portion of it, either opied verbatim, or with modi ations and/or translated into
another language.
A \Se ondary Se tion" is a named appendix or a front-matter se tion of the Do ument
that deals ex lusively with the relationship of the publishers or authors of the Do ument
to the Do ument's overall subje t (or to related matters) and ontains nothing that
ould fall dire tly within that overall subje t. (Thus, if the Do ument is in part a
textbook of mathemati s, a Se ondary Se tion may not explain any mathemati s.) The
relationship ould be a matter of histori al onne tion with the subje t or with related
matters, or of legal, ommer ial, philosophi al, ethi al or politi al position regarding
them.
The \Invariant Se tions" are ertain Se ondary Se tions whose titles are designated, as
being those of Invariant Se tions, in the noti e that says that the Do ument is released

398

Using the GNU Compiler Colle tion (GCC)

under this Li ense. If a se tion does not t the above denition of Se ondary then it is
not allowed to be designated as Invariant. The Do ument may ontain zero Invariant
Se tions. If the Do ument does not identify any Invariant Se tions then there are none.
The \Cover Texts" are ertain short passages of text that are listed, as Front-Cover
Texts or Ba k-Cover Texts, in the noti e that says that the Do ument is released under
this Li ense. A Front-Cover Text may be at most 5 words, and a Ba k-Cover Text may
be at most 25 words.
A \Transparent" opy of the Do ument means a ma hine-readable opy, represented
in a format whose spe i ation is available to the general publi , that is suitable for
revising the do ument straightforwardly with generi text editors or (for images omposed of pixels) generi paint programs or (for drawings) some widely available drawing
editor, and that is suitable for input to text formatters or for automati translation to
a variety of formats suitable for input to text formatters. A opy made in an otherwise
Transparent le format whose markup, or absen e of markup, has been arranged to
thwart or dis ourage subsequent modi ation by readers is not Transparent. An image
format is not Transparent if used for any substantial amount of text. A opy that is
not \Transparent" is alled \Opaque".
Examples of suitable formats for Transparent opies in lude plain as ii without
markup, Texinfo input format, LaTEX input format, SGML or XML using a publi ly
available DTD, and standard- onforming simple HTML, PostS ript or PDF designed
for human modi ation. Examples of transparent image formats in lude PNG, XCF
and JPG. Opaque formats in lude proprietary formats that an be read and edited
only by proprietary word pro essors, SGML or XML for whi h the DTD and/or
pro essing tools are not generally available, and the ma hine-generated HTML,
PostS ript or PDF produ ed by some word pro essors for output purposes only.
The \Title Page" means, for a printed book, the title page itself, plus su h following
pages as are needed to hold, legibly, the material this Li ense requires to appear in the
title page. For works in formats whi h do not have any title page as su h, \Title Page"
means the text near the most prominent appearan e of the work's title, pre eding the
beginning of the body of the text.
A se tion \Entitled XYZ" means a named subunit of the Do ument whose title either
is pre isely XYZ or ontains XYZ in parentheses following text that translates XYZ in
another language. (Here XYZ stands for a spe i se tion name mentioned below, su h
as \A knowledgements", \Dedi ations", \Endorsements", or \History".) To \Preserve
the Title" of su h a se tion when you modify the Do ument means that it remains a
se tion \Entitled XYZ" a ording to this denition.
The Do ument may in lude Warranty Dis laimers next to the noti e whi h states that
this Li ense applies to the Do ument. These Warranty Dis laimers are onsidered to
be in luded by referen e in this Li ense, but only as regards dis laiming warranties:
any other impli ation that these Warranty Dis laimers may have is void and has no
ee t on the meaning of this Li ense.
2. VERBATIM COPYING
You may opy and distribute the Do ument in any medium, either ommer ially or
non ommer ially, provided that this Li ense, the opyright noti es, and the li ense
noti e saying this Li ense applies to the Do ument are reprodu ed in all opies, and

Chapter 13: GNU Free Do umentation Li ense

399

that you add no other onditions whatsoever to those of this Li ense. You may not use
te hni al measures to obstru t or ontrol the reading or further opying of the opies
you make or distribute. However, you may a ept ompensation in ex hange for opies.
If you distribute a large enough number of opies you must also follow the onditions
in se tion 3.
You may also lend opies, under the same onditions stated above, and you may publi ly
display opies.
3. COPYING IN QUANTITY
If you publish printed opies (or opies in media that ommonly have printed overs) of
the Do ument, numbering more than 100, and the Do ument's li ense noti e requires
Cover Texts, you must en lose the opies in overs that arry, learly and legibly, all
these Cover Texts: Front-Cover Texts on the front over, and Ba k-Cover Texts on
the ba k over. Both overs must also learly and legibly identify you as the publisher
of these opies. The front over must present the full title with all words of the title
equally prominent and visible. You may add other material on the overs in addition.
Copying with hanges limited to the overs, as long as they preserve the title of the
Do ument and satisfy these onditions, an be treated as verbatim opying in other
respe ts.
If the required texts for either over are too voluminous to t legibly, you should put
the rst ones listed (as many as t reasonably) on the a tual over, and ontinue the
rest onto adja ent pages.
If you publish or distribute Opaque opies of the Do ument numbering more than 100,
you must either in lude a ma hine-readable Transparent opy along with ea h Opaque
opy, or state in or with ea h Opaque opy a omputer-network lo ation from whi h
the general network-using publi has a ess to download using publi -standard network
proto ols a omplete Transparent opy of the Do ument, free of added material. If
you use the latter option, you must take reasonably prudent steps, when you begin
distribution of Opaque opies in quantity, to ensure that this Transparent opy will
remain thus a essible at the stated lo ation until at least one year after the last time
you distribute an Opaque opy (dire tly or through your agents or retailers) of that
edition to the publi .
It is requested, but not required, that you onta t the authors of the Do ument well
before redistributing any large number of opies, to give them a han e to provide you
with an updated version of the Do ument.
4. MODIFICATIONS
You may opy and distribute a Modied Version of the Do ument under the onditions
of se tions 2 and 3 above, provided that you release the Modied Version under pre isely
this Li ense, with the Modied Version lling the role of the Do ument, thus li ensing
distribution and modi ation of the Modied Version to whoever possesses a opy of
it. In addition, you must do these things in the Modied Version:
A. Use in the Title Page (and on the overs, if any) a title distin t from that of the
Do ument, and from those of previous versions (whi h should, if there were any,
be listed in the History se tion of the Do ument). You may use the same title as
a previous version if the original publisher of that version gives permission.

400

Using the GNU Compiler Colle tion (GCC)

B. List on the Title Page, as authors, one or more persons or entities responsible for
authorship of the modi ations in the Modied Version, together with at least ve
of the prin ipal authors of the Do ument (all of its prin ipal authors, if it has fewer
than ve), unless they release you from this requirement.
C. State on the Title page the name of the publisher of the Modied Version, as the
publisher.
D. Preserve all the opyright noti es of the Do ument.
E. Add an appropriate opyright noti e for your modi ations adja ent to the other
opyright noti es.
F. In lude, immediately after the opyright noti es, a li ense noti e giving the publi
permission to use the Modied Version under the terms of this Li ense, in the form
shown in the Addendum below.
G. Preserve in that li ense noti e the full lists of Invariant Se tions and required Cover
Texts given in the Do ument's li ense noti e.
H. In lude an unaltered opy of this Li ense.
I. Preserve the se tion Entitled \History", Preserve its Title, and add to it an item
stating at least the title, year, new authors, and publisher of the Modied Version
as given on the Title Page. If there is no se tion Entitled \History" in the Do ument, reate one stating the title, year, authors, and publisher of the Do ument
as given on its Title Page, then add an item des ribing the Modied Version as
stated in the previous senten e.
J. Preserve the network lo ation, if any, given in the Do ument for publi a ess to
a Transparent opy of the Do ument, and likewise the network lo ations given in
the Do ument for previous versions it was based on. These may be pla ed in the
\History" se tion. You may omit a network lo ation for a work that was published
at least four years before the Do ument itself, or if the original publisher of the
version it refers to gives permission.
K. For any se tion Entitled \A knowledgements" or \Dedi ations", Preserve the Title
of the se tion, and preserve in the se tion all the substan e and tone of ea h of the
ontributor a knowledgements and/or dedi ations given therein.
L. Preserve all the Invariant Se tions of the Do ument, unaltered in their text and
in their titles. Se tion numbers or the equivalent are not onsidered part of the
se tion titles.
M. Delete any se tion Entitled \Endorsements". Su h a se tion may not be in luded
in the Modied Version.
N. Do not retitle any existing se tion to be Entitled \Endorsements" or to on i t in
title with any Invariant Se tion.
O. Preserve any Warranty Dis laimers.
If the Modied Version in ludes new front-matter se tions or appendi es that qualify
as Se ondary Se tions and ontain no material opied from the Do ument, you may at
your option designate some or all of these se tions as invariant. To do this, add their
titles to the list of Invariant Se tions in the Modied Version's li ense noti e. These
titles must be distin t from any other se tion titles.

Chapter 13: GNU Free Do umentation Li ense

401

You may add a se tion Entitled \Endorsements", provided it ontains nothing but
endorsements of your Modied Version by various parties|for example, statements of
peer review or that the text has been approved by an organization as the authoritative
denition of a standard.
You may add a passage of up to ve words as a Front-Cover Text, and a passage of up
to 25 words as a Ba k-Cover Text, to the end of the list of Cover Texts in the Modied
Version. Only one passage of Front-Cover Text and one of Ba k-Cover Text may be
added by (or through arrangements made by) any one entity. If the Do ument already
in ludes a over text for the same over, previously added by you or by arrangement
made by the same entity you are a ting on behalf of, you may not add another; but
you may repla e the old one, on expli it permission from the previous publisher that
added the old one.
The author(s) and publisher(s) of the Do ument do not by this Li ense give permission
to use their names for publi ity for or to assert or imply endorsement of any Modied
Version.
5. COMBINING DOCUMENTS
You may ombine the Do ument with other do uments released under this Li ense,
under the terms dened in se tion 4 above for modied versions, provided that you
in lude in the ombination all of the Invariant Se tions of all of the original do uments,
unmodied, and list them all as Invariant Se tions of your ombined work in its li ense
noti e, and that you preserve all their Warranty Dis laimers.
The ombined work need only ontain one opy of this Li ense, and multiple identi al
Invariant Se tions may be repla ed with a single opy. If there are multiple Invariant
Se tions with the same name but dierent ontents, make the title of ea h su h se tion
unique by adding at the end of it, in parentheses, the name of the original author or
publisher of that se tion if known, or else a unique number. Make the same adjustment
to the se tion titles in the list of Invariant Se tions in the li ense noti e of the ombined
work.
In the ombination, you must ombine any se tions Entitled \History" in the various original do uments, forming one se tion Entitled \History"; likewise ombine any
se tions Entitled \A knowledgements", and any se tions Entitled \Dedi ations". You
must delete all se tions Entitled \Endorsements."
6. COLLECTIONS OF DOCUMENTS
You may make a olle tion onsisting of the Do ument and other do uments released
under this Li ense, and repla e the individual opies of this Li ense in the various
do uments with a single opy that is in luded in the olle tion, provided that you
follow the rules of this Li ense for verbatim opying of ea h of the do uments in all
other respe ts.
You may extra t a single do ument from su h a olle tion, and distribute it individually under this Li ense, provided you insert a opy of this Li ense into the extra ted
do ument, and follow this Li ense in all other respe ts regarding verbatim opying of
that do ument.
7. AGGREGATION WITH INDEPENDENT WORKS
A ompilation of the Do ument or its derivatives with other separate and independent
do uments or works, in or on a volume of a storage or distribution medium, is alled

402

Using the GNU Compiler Colle tion (GCC)

an \aggregate" if the opyright resulting from the ompilation is not used to limit the
legal rights of the ompilation's users beyond what the individual works permit. When
the Do ument is in luded an aggregate, this Li ense does not apply to the other works
in the aggregate whi h are not themselves derivative works of the Do ument.
If the Cover Text requirement of se tion 3 is appli able to these opies of the Do ument,
then if the Do ument is less than one half of the entire aggregate, the Do ument's Cover
Texts may be pla ed on overs that bra ket the Do ument within the aggregate, or the
ele troni equivalent of overs if the Do ument is in ele troni form. Otherwise they
must appear on printed overs that bra ket the whole aggregate.
8. TRANSLATION
Translation is onsidered a kind of modi ation, so you may distribute translations
of the Do ument under the terms of se tion 4. Repla ing Invariant Se tions with
translations requires spe ial permission from their opyright holders, but you may
in lude translations of some or all Invariant Se tions in addition to the original versions
of these Invariant Se tions. You may in lude a translation of this Li ense, and all the
li ense noti es in the Do ument, and any Warrany Dis laimers, provided that you
also in lude the original English version of this Li ense and the original versions of
those noti es and dis laimers. In ase of a disagreement between the translation and
the original version of this Li ense or a noti e or dis laimer, the original version will
prevail.
If a se tion in the Do ument is Entitled \A knowledgements", \Dedi ations", or \History", the requirement (se tion 4) to Preserve its Title (se tion 1) will typi ally require
hanging the a tual title.
9. TERMINATION
You may not opy, modify, subli ense, or distribute the Do ument ex ept as expressly
provided for under this Li ense. Any other attempt to opy, modify, subli ense or
distribute the Do ument is void, and will automati ally terminate your rights under
this Li ense. However, parties who have re eived opies, or rights, from you under this
Li ense will not have their li enses terminated so long as su h parties remain in full
omplian e.
10. FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions of the GNU Free
Do umentation Li ense from time to time. Su h new versions will be similar in spirit
to the present version, but may dier in detail to address new problems or on erns.
See http://www.gnu.org/ opyleft/.
Ea h version of the Li ense is given a distinguishing version number. If the Do ument
spe ies that a parti ular numbered version of this Li ense \or any later version"
applies to it, you have the option of following the terms and onditions either of that
spe ied version or of any later version that has been published (not as a draft) by
the Free Software Foundation. If the Do ument does not spe ify a version number of
this Li ense, you may hoose any version ever published (not as a draft) by the Free
Software Foundation.

Chapter 13: GNU Free Do umentation Li ense

403

ADDENDUM: How to use this Li ense for your do uments

To use this Li ense in a do ument you have written, in lude a opy of the Li ense in the
do ument and put the following opyright and li ense noti es just after the title page:
Copyright (C) year your name.
Permission is granted to opy, distribute and/or modify this do ument
under the terms of the GNU Free Do umentation Li ense, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Se tions, no Front-Cover Texts, and no Ba k-Cover Texts.
A opy of the li ense is in luded in the se tion entitled ``GNU
Free Do umentation Li ense''.

If you have Invariant Se tions, Front-Cover Texts and Ba k-Cover Texts, repla e the
\with...Texts." line with this:
with the Invariant Se tions being list their titles, with
the Front-Cover Texts being list, and with the Ba k-Cover Texts
being list.

If you have Invariant Se tions without Cover Texts, or some other ombination of the
three, merge those two alternatives to suit the situation.
If your do ument ontains nontrivial examples of program ode, we re ommend releasing
these examples in parallel under your hoi e of free software li ense, su h as the GNU
General Publi Li ense, to permit their use in free software.

404

Using the GNU Compiler Colle tion (GCC)

Chapter 13: Contributors to GCC

405

Contributors to GCC
The GCC proje t would like to thank its many ontributors. Without them the proje t
would not have been nearly as su essful as it has been. Any omissions in this list are
a idental. Feel free to onta t lawredhat. om or geraldpfeifer. om if you have been
left out or some of your ontributions are not listed. Please keep this list in alphabeti al
order.
 Analog Devi es helped implement the support for omplex data types and iterators.
 John David Anglin for threading-related xes and improvements to libstd ++-v3, and
the HP-UX port.
 James van Artsdalen wrote the ode that makes e ient use of the Intel 80387 register
sta k.
 Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta Series port.
 Alasdair Baird for various bug xes.
 Giovanni Bajo for analyzing lots of ompli ated C++ problem reports.
 Peter Barada for his work to improve ode generation for new ColdFire ores.
 Gerald Baumgartner added the signature extension to the C++ front end.
 Godmar Ba k for his Java improvements and en ouragement.
 S ott Bambrough for help porting the Java ompiler.
 Wolfgang Bangerth for pro essing tons of bug reports.
 Jon Beniston for his Mi rosoft Windows port of Java.
 Daniel Berlin for better DWARF2 support, faster/better optimizations, improved alias
analysis, plus migrating GCC to Bugzilla.
 Geo Berry for his Java obje t serialization work and various pat hes.
 Eri Blake for helping to make GCJ and libg j onform to the spe i ations.
 Janne Blomqvist for ontributions to gfortran.
 Segher Boessenkool for various xes.
 Hans-J. Boehm for his garbage olle tor, IA-64 lib port, and other Java work.
 Neil Booth for work on pplib, lang hooks, debug hooks and other mis ellaneous leanups.
 Steven Boss her for integrating the gfortran front end into GCC and for ontributing
to the tree-ssa bran h.
 Eri Bot azou for xing middle- and ba kend bugs left and right.
 Per Bothner for his dire tion via the steering ommittee and various improvements
to the infrastru ture for supporting new languages. Chill front end implementation.
Initial implementations of pplib, x-header, ong.guess, libio, and past C++ library
(libg++) maintainer. Dreaming up, designing and implementing mu h of GCJ.
 Devon Bowen helped port GCC to the Tahoe.
 Don Bowman for mips-vxworks ontributions.
 Dave Brolley for work on pplib and Chill.
 Paul Brook for work on the ARM ar hite ture and maintaining gfortran.

406

Using the GNU Compiler Colle tion (GCC)










Robert Brown implemented the support for En ore 32000 systems.

Christian Bruel for improvements to lo al store elimination.
Herman A.J. ten Brugge for various xes.
Joerg Brunsmann for Java ompiler ha king and help with the GCJ FAQ.
Joe Bu k for his dire tion via the steering ommittee.
Craig Burley for leadership of the G77 Fortran eort.
Stephan Buys for ontributing Doxygen notes for libstd ++.
Paolo Carlini for libstd ++ work: lots of e ien y improvements to the C++ strings,
streambufs and formatted I/O, hard dete tive work on the frustrating lo alization
issues, and keeping up with the problem reports.
John Carr for his alias work, SPARC ha king, infrastru ture improvements, previous
ontributions to the steering ommittee, loop optimizations, et .
Stephane Carrez for 68HC11 and 68HC12 ports.
Steve Chamberlain for support for the Renesas SH and H8 pro essors and the Pi oJava
pro essor, and for GCJ ong xes.
Glenn Chambers for help with the GCJ FAQ.
John-Mar Chandonia for various libg j pat hes.
S ott Christley for his Obje tive-C ontributions.
Eri Christopher for his Java porting help and lean-ups.
Branko Cibej for more warning ontributions.
The GNU Classpath proje t for all of their merged runtime ode.
Ni k Clifton for arm, m ore, fr30, v850, m32r work, `--help', and other random ha king.
Mi hael Cook for libstd ++ leanup pat hes to redu e warnings.
R. Kelley Cook for making GCC buildable from a read-only dire tory as well as other
mis ellaneous build pro ess and do umentation lean-ups.
Ralf Corsepius for SH testing and minor bugxing.
Stan Cox for are and feeding of the x86 port and lots of behind the s enes ha king.
Alex Crain provided hanges for the 3b1.
Ian Dall for major improvements to the NS32k port.
Paul Dale for his work to add uClinux platform support to the m68k ba kend.
Dario Dariol ontributed the four varieties of sample programs that print a opy of
their sour e.
Russell Davidson for fstream and stringstream xes in libstd ++.
Bud Davis for work on the G77 and gfortran ompilers.
Mo DeJong for GCJ and libg j bug xes.
DJ Delorie for the DJGPP port, build and libiberty maintenan e, and various bug
xes.
Arnaud Desitter for helping to debug gfortran.

























Chapter 13: Contributors to GCC


























407

Gabriel Dos Reis for ontributions to G++, ontributions and maintenan e of GCC
diagnosti s infrastru ture, libstd ++-v3, in luding valarray<>, omplex<>, maintaining the numeri s library (in luding that pesky <limits> :-) and keeping up-to-date
anything to do with numbers.
Ulri h Drepper for his work on glib , testing of GCC using glib , ISO C99 support,
CFG dumping support, et ., plus support of the C++ runtime libraries in luding for all
kinds of C interfa e issues, ontributing and maintaining omplex<>, sanity he king
and disbursement, onguration ar hite ture, libio maintenan e, and early math work.
Zdenek Dvorak for a new loop unroller and various xes.
Ri hard Earnshaw for his ongoing work with the ARM.
David Edelsohn for his dire tion via the steering ommittee, ongoing work with the
RS6000/PowerPC port, help leaning up Haifa loop hanges, doing the entire AIX
port of libstd ++ with his bare hands, and for ensuring GCC properly keeps working
on AIX.
Kevin Ediger for the oating point formatting of num put::do put in libstd ++.
Phil Edwards for libstd ++ work in luding onguration ha kery, do umentation maintainer, hief breaker of the web pages, the o asional iostream bug x, and work on
shared library symbol versioning.
Paul Eggert for random ha king all over GCC.
Mark Elbre ht for various DJGPP improvements, and for libstd ++ onguration support for lo ales and fstream-related xes.
Vadim Egorov for libstd ++ xes in strings, streambufs, and iostreams.
Christian Ehrhardt for dealing with bug reports.
Ben Elliston for his work to move the Obje tive-C runtime into its own subdire tory
and for his work on auto onf.
Mar Espie for OpenBSD support.
Doug Evans for mu h of the global optimization framework, ar , m32r, and SPARC
work.
Christopher Faylor for his work on the Cygwin port and for aring and feeding the
g .gnu.org box and saving its users tons of spam.
Fred Fish for BeOS support and Ada xes.
Ivan Fontes Gar ia for the Portuguese translation of the GCJ FAQ.
Peter Gerwinski for various bug xes and the Pas al front end.
Kaveh Ghazi for his dire tion via the steering ommittee, amazing work to make `-W
-Wall' useful, and ontinuously testing GCC on a plethora of platforms.
John Gilmore for a donation to the FSF earmarked improving GNU Java.
Judy Goldberg for ++ ontributions.
Torbjorn Granlund for various xes and the -torture testsuite, multiply- and divideby- onstant optimization, improved long long support, improved leaf fun tion register
allo ation, and his dire tion via the steering ommittee.
Anthony Green for his `-Os' ontributions and Java front end work.
Stu Grossman for gdb ha king, allowing GCJ developers to debug Java ode.

408

Using the GNU Compiler Colle tion (GCC)




Mi hael K. Gs hwind ontributed the port to the PDP-11.

Ron Guilmette implemented the protoize and unprotoize tools, the support for
Dwarf symboli debugging information, and mu h of the support for System V Release 4. He has also worked heavily on the Intel 386 and 860 support.
Bruno Haible for improvements in the runtime overhead for EH, new warnings and
assorted bug xes.
Andrew Haley for his amazing Java ompiler and library eorts.
Chris Hanson assisted in making GCC work on HP-UX for the 9000 series 300.
Mi hael Hayes for various thankless work he's done trying to get the 30/ 40 ports
fun tional. Lots of loop and unroll improvements and xes.
Dara Hazeghi for wading through myriads of target-spe i bug reports.
Kate Hedstrom for staking the G77 folks with an initial testsuite.
Ri hard Henderson for his ongoing SPARC, alpha, ia32, and ia64 work, loop opts, and
generally xing lots of old problems we've ignored for years, ow rewrite and lots of
further stu, in luding reviewing tons of pat hes.
Aldy Hernandez for working on the PowerPC port, SIMD support, and various xes.
Nobuyuki Hiki hi of Software Resear h Asso iates, Tokyo, ontributed the support for
the Sony NEWS ma hine.
Kazu Hirata for aring and feeding the Renesas H8/300 port and various xes.
Katherine Hol omb for work on gfortran.
Manfred Hollstein for his ongoing work to keep the m88k alive, lots of testing and bug
xing, parti ularly of GCC ongury ode.
Steve Holmgren for Ma hTen pat hes.
Jan Hubi ka for his x86 port improvements.
Falk Huener for working on C and optimization bug reports.
Bernardo Inno enti for his m68k work, in luding merging of ColdFire improvements
and uClinux support.
Christian Iseli for various bug xes.
Kamil Iskra for general m68k ha king.
Lee Iverson for random xes and MIPS testing.
Andreas Jaeger for testing and ben hmarking of GCC and various bug xes.
Jakub Jelinek for his SPARC work and sibling all optimizations as well as lots of bug
xes and test ases, and for improving the Java build system.
Janis Johnson for ia64 testing and xes, her quality improvement sidetra ks, and web
page maintenan e.
Kean Johnston for SCO OpenServer support and various xes.
Tim Josling for the sample language treelang based originally on Ri hard Kenner's
\toy" language.
Ni olai Josuttis for additional libstd ++ do umentation.
Klaus Kaempf for his ongoing work to make alpha-vms a viable target.
Steven G. Kargl for work on gfortran.





























Chapter 13: Contributors to GCC



























409

David Kashtan of SRI adapted GCC to VMS.

Ryszard Kabatek for many, many libstd ++ bug xes and optimizations of strings,
espe ially member fun tions, and for auto ptr xes.
Georey Keating for his ongoing work to make the PPC work for GNU/Linux and his
automati regression tester.
Brendan Kehoe for his ongoing work with G++ and for a lot of early work in just about
every part of libstd ++.
Oliver M. Kellogg of Deuts he Aerospa e ontributed the port to the MIL-STD-1750A.
Ri hard Kenner of the New York University Ultra omputer Resear h Laboratory wrote
the ma hine des riptions for the AMD 29000, the DEC Alpha, the IBM RT PC, and
the IBM RS/6000 as well as the support for instru tion attributes. He also made
hanges to better support RISC pro essors in luding hanges to ommon subexpression
elimination, strength redu tion, fun tion alling sequen e handling, and ondition ode
support, in addition to generalizing the ode for frame pointer elimination and delay
slot s heduling. Ri hard Kenner was also the head maintainer of GCC for several years.
Mumit Khan for various ontributions to the Cygwin and Mingw32 ports and maintaining binary releases for Mi rosoft Windows hosts, and for massive libstd ++ porting
work to Cygwin/Mingw32.
Robin Kirkham for pu32 support.
Mark Klein for PA improvements.
Thomas Koenig for various bug xes.
Bru e Korb for the new and improved xin ludes ode.
Benjamin Kosnik for his G++ work and for leading the libstd ++-v3 eort.
Charles LaBre ontributed the support for the Integrated Solutions 68020 system.
Je Law for his dire tion via the steering ommittee, oordinating the entire eg s
proje t and GCC 2.95, rolling out snapshots and releases, handling merges from GCC2,
reviewing tons of pat hes that might have fallen through the ra ks else, and random
but extensive ha king.
Mar Lehmann for his dire tion via the steering ommittee and helping with analysis
and improvements of x86 performan e.
Vi tor Leikehman for work on gfortran.
Ted Lemon wrote parts of the RTL reader and printer.
Kriang Lerdsuwanakij for C++ improvements in luding template as template parameter
support, and many C++ xes.
Warren Levy for tremendous work on libg j (Java Runtime Library) and random work
on the Java front end.
Alain Li hnewsky ported GCC to the MIPS CPU.
Oskar Liljeblad for ha king on AWT and his many Java bug reports and pat hes.
Robert Lipe for OpenServer support, new testsuites, testing, et .
Weiwen Liu for testing and various bug xes.
Dave Love for his ongoing work with the Fortran front end and runtime libraries.

410

Using the GNU Compiler Colle tion (GCC)

Martin von Lowis for internal onsisten y he king infrastru ture, various C++ improvements in luding namespa e support, and tons of assistan e with libstd ++/ ompiler
merges.
H.J. Lu for his previous ontributions to the steering ommittee, many x86 bug reports,
prototype pat hes, and keeping the GNU/Linux ports working.
Greg M Gary for random xes and (someday) bounded pointers.
Andrew Ma Leod for his ongoing work in building a real EH system, various ode
generation improvements, work on the global optimizer, et .
Vladimir Makarov for ha king some ugly i960 problems, PowerPC ha king improvements to ompile-time performan e, overall knowledge and dire tion in the area of
instru tion s heduling, and design and implementation of the automaton based instru tion s heduler.
Bob Manson for his behind the s enes work on dejagnu.
Philip Martin for lots of libstd ++ string and ve tor iterator xes and improvements,
and string lean up and testsuites.
All of the Mauve proje t ontributors, for Java test ode.
Bry e M Kinlay for numerous GCJ and libg j xes and improvements.
Adam Mega z for his work on the Mi rosoft Windows port of GCJ.
Mi hael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS, powerp , haifa,
ECOFF debug support, and other assorted ha king.
Jason Merrill for his dire tion via the steering ommittee and leading the G++ eort.
David Miller for his dire tion via the steering ommittee, lots of SPARC work, improvements in jump. and interfa ing with the Linux kernel developers.
Gary Miller ported GCC to Charles River Data Systems ma hines.
Alfred Minarik for libstd ++ string and ios bug xes, and turning the entire libstd ++
testsuite namespa e- ompatible.
Mark Mit hell for his dire tion via the steering ommittee, mountains of C++ work,
load/store hoisting out of loops, alias analysis improvements, ISO C restri t support,
and serving as release manager for GCC 3.x.
Alan Modra for various GNU/Linux bits and testing.
Toon Moene for his dire tion via the steering ommittee, Fortran maintenan e, and his
ongoing work to make us make Fortran run fast.
Jason Molenda for major help in the are and feeding of all the servi es on the
g .gnu.org (formerly eg s. ygnus. om) ma hine|mail, web servi es, ftp servi es, et
et . Doing all this work on s rap paper and the ba ks of envelopes would have been. . .
di ult.
Catherine Moore for xing various ugly problems we have sent her way, in luding the
haifa bug whi h was killing the Alpha & PowerPC Linux kernels.
Mike Moreton for his various Java pat hes.
David Mosberger-Tang for various Alpha improvements, and for the initial IA-64 port.
Stephen Moshier ontributed the oating point emulator that assists in ross ompilation and permits support for oating point numbers wider than 64 bits and
for ISO C99 support.
























Chapter 13: Contributors to GCC




























411

Bill Moyer for his behind the s enes work on various issues.
Philippe De Muyter for his work on the m68k port.
Joseph S. Myers for his work on the PDP-11 port, format he king and ISO C99
support, and ontinuous emphasis on (and ontributions to) do umentation.
Nathan Myers for his work on libstd ++-v3: ar hite ture and authorship through the
rst three snapshots, in luding implementation of lo ale infrastru ture, string, shadow
C headers, and the initial proje t do umentation (DESIGN, CHECKLIST, and so
forth). Later, more work on MT-safe string and shadow headers.
Felix Natter for do umentation on porting libstd ++.
Nathanael Nerode for leaning up the onguration/build pro ess.
NeXT, In . donated the front end that supports the Obje tive-C language.
Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to the sear h engine
setup, various do umentation xes and other small xes.
Geo Noer for his work on getting ygwin native builds working.
Diego Novillo for his SPEC performan e tra king web pages and assorted xes in the
middle end and various ba k ends.
David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64, FreeBSD/ARM,
FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and related infrastru ture
improvements.
Alexandre Oliva for various build infrastru ture improvements, s ripts and amazing
testing work, in luding keeping libtool issues sane and happy.
Stefan Olsson for work on mt allo .
Melissa O'Neill for various NeXT xes.
Rainer Orth for random MIPS work, in luding improvements to GCC's o32 ABI support, improvements to dejagnu's MIPS support, Java onguration lean-ups and porting work, et .
Hartmut Penner for work on the s390 port.
Paul Petersen wrote the ma hine des ription for the Alliant FX/8.
Alexandre Petit-Bian o for implementing mu h of the Java ompiler and ontinued
Java maintainership.
Matthias Pfaller for major improvements to the NS32k port.
Gerald Pfeifer for his dire tion via the steering ommittee, pointing out lots of problems
we need to solve, maintenan e of the web pages, and taking are of do umentation
maintenan e in general.
Andrew Pinski for pro essing bug reports by the dozen.
Ovidiu Predes u for his work on the Obje tive-C front end and runtime libraries.
Jerry Quinn for major performan e improvements in C++ formatted I/O.
Ken Raeburn for various improvements to he ker, MIPS ports and various leanups
in the ompiler.
Rolf W. Rasmussen for ha king on AWT.
David Reese of Sun Mi rosystems ontributed to the Solaris on PowerPC port.

412

Using the GNU Compiler Colle tion (GCC)





Volker Rei helt for keeping up with the problem reports.

Joern Renne ke for maintaining the sh port, loop, regmove & reload ha king.
Loren J. Rittle for improvements to libstd ++-v3 in luding the FreeBSD port, threading
xes, thread-related ongury hanges, riti al threading do umentation, and solutions
to really tri ky I/O problems, as well as keeping GCC properly working on FreeBSD
and ontinuous testing.
Craig Rodrigues for pro essing tons of bug reports.
Ola Ronnerup for work on mt allo .
Gavin Romig-Ko h for lots of behind the s enes MIPS work.
David Ronis inspired and en ouraged Craig to rewrite the G77 do umentation in texinfo
format by ontributing a rst pass at a translation of the old `g77-0.5.16/f/DOC' le.
Ken Rose for xes to GCC's delay slot lling ode.
Paul Rubin wrote most of the prepro essor.
Petur Runolfsson for major performan e improvements in C++ formatted I/O and large
le support in C++ lebuf.
Chip Salzenberg for libstd ++ pat hes and improvements to lo ales, traits, Makeles,
libio, libtool ha kery, and \long long" support.
Juha Sarlin for improvements to the H8 ode generator.
Greg Satz assisted in making GCC work on HP-UX for the 9000 series 300.
Roger Sayle for improvements to onstant folding and GCC's RTL optimizers as well
as for xing numerous bugs.
Bradley S hatz for his work on the GCJ FAQ.
Peter S hauer wrote the ode to allow debugging to work on the Alpha.
William S helter did most of the work on the Intel 80386 support.
Tobias S hluter for work on gfortran.
Bernd S hmidt for various ode generation improvements and major work in the reload
pass as well a serving as release manager for GCC 2.95.3.
Peter S hmid for onstant testing of libstd ++|espe ially appli ation testing, going
above and beyond what was requested for the release riteria|and libstd ++ header
le tweaks.
Jason S hroeder for j f-dump pat hes.
Andreas S hwab for his work on the m68k port.
Lars Segerlund for work on gfortran.
Joel Sherrill for his dire tion via the steering ommittee, RTEMS ontributions and
RTEMS testing.
Nathan Sidwell for many C++ xes/improvements.
Jerey Siegal for helping RMS with the original design of GCC, some ode whi h
handles the parse tree and RTL data stru tures, onstant folding and help with the
original VAX & m68k ports.
Kenny Simpson for prompting libstd ++ xes due to defe t reports from the LWG
(thereby keeping GCC in line with updates from the ISO).


























Chapter 13: Contributors to GCC

































413

Franz Sirl for his ongoing work with making the PPC port stable for GNU/Linux.
Andrey Slepuhin for assorted AIX ha king.
Christopher Smith did the port for Convex ma hines.
Danny Smith for his major eorts on the Mingw (and Cygwin) ports.
Randy Smith nished the Sun FPA support.
S ott Snyder for queue, iterator, istream, and string xes and libstd ++ testsuite entries. Also for providing the pat h to G77 to add rudimentary support for INTEGER*1,
INTEGER*2, and LOGICAL*1.
Brad Spen er for ontributions to the GLIBCPP FORCE NEW te hnique.
Ri hard Stallman, for writing the original GCC and laun hing the GNU proje t.
Jan Stein of the Chalmers Computer So iety provided support for Genix, as well as
part of the 32000 ma hine des ription.
Nigel Stephens for various mips16 related xes/improvements.
Jonathan Stone wrote the ma hine des ription for the Pyramid omputer.
Graham Stott for various infrastru ture improvements.
John Stra ke for his Java HTTP proto ol xes.
Mike Stump for his Elxsi port, G++ ontributions over the years and more re ently his
vxworks ontributions
Je Sturm for Java porting help, bug xes, and en ouragement.
Shigeya Suzuki for this xes for the bsdi platforms.
Ian Lan e Taylor for his mips16 work, general ongury ha king, xin ludes, et .
Holger Teuts h provided the support for the Clipper CPU.
Gary Thomas for his ongoing work to make the PPC work for GNU/Linux.
Philipp Thomas for random bug xes throughout the ompiler
Jason Thorpe for thread support in libstd ++ on NetBSD.
Kresten Krab Thorup wrote the run time support for the Obje tive-C language and
the fantasti Java byte ode interpreter.
Mi hael Tiemann for random bug xes, the rst instru tion s heduler, initial C++
support, fun tion integration, NS32k, SPARC and M88k ma hine des ription work,
delay slot s heduling.
Andreas Tobler for his work porting libg j to Darwin.
Teemu Torma for thread safe ex eption handling support.
Leonard Tower wrote parts of the parser, RTL generator, and RTL denitions, and of
the VAX ma hine des ription.
Tom Tromey for internationalization support and for his many Java ontributions and
libg j maintainership.
Lassi Tuura for improvements to ong.guess to determine HP pro essor types.
Petter Urkedal for libstd ++ CXXFLAGS, math, and algorithms xes.
Andy Vaught for the design and initial implementation of the gfortran front end.
Brent Verner for work with the libstd ++ shadow les and their asso iated ongure
steps.

414





Using the GNU Compiler Colle tion (GCC)

Todd Vierling for ontributions for NetBSD ports.

Jonathan Wakely for ontributing libstd ++ Doxygen notes and XHTML guidan e.
Dean Wakerley for onverting the install do umentation from HTML to texinfo in time
for GCC 3.0.
 Krister Walfridsson for random bug xes.
 Feng Wang for ontributions to gfortran.
 Stephen M. Webb for time and eort on making libstd ++ shadow les work with the
tri ky Solaris 8+ headers, and for pushing the build-time header tree.
 John Wehle for various improvements for the x86 ode generator, related infrastru ture
improvements to help x86 ode generation, value range propagation and other work,
WE32k port.
 Ulri h Weigand for work on the s390 port.
 Za k Weinberg for major work on pplib and various other bug xes.
 Matt Welsh for help with Linux Threads support in GCJ.
 Urban Widmark for help xing java.io.
 Mark Wielaard for new Java library ode and his work integrating with Classpath.
 Dale Wiles helped port GCC to the Tahoe.
 Bob Wilson from Tensili a, In . for the Xtensa port.
 Jim Wilson for his dire tion via the steering ommittee, ta kling hard problems in
various pla es that nobody else wanted to work on, strength redu tion and other loop
optimizations.
 Carlo Wood for various xes.
 Tom Wood for work on the m88k port.
 Canqun Yang for work on gfortran.
 Masanobu Yuhara of Fujitsu Laboratories implemented the ma hine des ription for the
Tron ar hite ture (spe i ally, the Gmi ro).
 Kevin Za hmann helped port GCC to the Tahoe.
 Xiaoqiang Zhang for work on gfortran.
 Gilles Zunino for help porting Java to Irix.
The following people are re ognized for their ontributions to GNAT, the Ada front end
of GCC:
 Bernard Banner
 Romain Berrendonner
 Geert Bos h
 Emmanuel Briot
 Joel Brobe ker
 Ben Brosgol
 Vin ent Celier
 Arnaud Charlet
 Chien Chieng

Chapter 13: Contributors to GCC








































Cyrille Comar
Cyrille Crozes
Robert Dewar
Gary Dismukes
Robert Du
Ed Falis
Ramon Fernandez
Sam Figueroa
Vasiliy Fofanov
Mi hael Friess
Fran o Gasperoni
Ted Giering
Matthew Gingell
Laurent Guerby
Jerome Guitton
Olivier Hainque
Jerome Hugues
Hristian Kirt hev
Jerome Lambourg
Bruno Le ler
Albert Lee
Sean M Neil
Javier Miranda
Laurent Nana
Pas al Obry
Dong-Ik Oh
Laurent Pautet
Brett Porter
Thomas Quinot
Ni olas Ro he
Pat Rogers
Jose Ruiz
Douglas Rupp
Sergey Rybin
Gail S henker
Ed S honberg
Ni olas Setton
Samuel Tardieu

415

416

Using the GNU Compiler Colle tion (GCC)

In addition to the above, all of whi h also ontributed time and energy in testing GCC,
we would like to thank the following for their ontributions to testing:
 Mi hael Abd-El-Malek
 Thomas Arend
 Bonzo Armstrong
 Steven Ashe
 Chris Baldwin
 David Billinghurst
 Jim Blandy
 Stephane Bortzmeyer
 Horst von Brand
 Frank Braun
 Rodney Brown
 Sidney Cadot
 Bradford Castalia
 Jonathan Corbet
 Ralph Don aster
 Ri hard Emberson
 Levente Farkas
 Graham Faw ett
 Mark Fernyhough
 Robert A. Fren h
 Jorgen Freyh
 Mark K. Gardner
 Charles-Antoine Gauthier
 Yung Shing Gene
 David Gilbert
 Simon Gornall
 Fred Gray
 John Grin
 Patrik Hagglund
 Phil Hargett
 Aman io Hasty
 Takafumi Hayashi
 Bryan W. Headley
 Kevin B. Hendri ks
 Joep Jansen
 Christian Joensson
 Mi hel Kern

Chapter 13: Contributors to GCC









































David Kidd
Tobias Kuipers
Anand Krishnaswamy
A. O. V. Le Blan
llewelly
Damon Love
Brad Lu ier
Matthias Klose
Martin Knoblau h
Ri k Lutowski
Jesse Ma nish
Stefan Morrell
Anon A. Mous
Matthias Mueller
Pekka Nikander
Ri k Niles
Jon Olson
Magnus Persson
Chris Pollard
Ri hard Polton
Derk Reefman
David Rees
Paul Reilly
Tom Reilly
Torsten Rueger
Danny Sadino
Mar S hifer
Erik S hnetter
Wayne K. S hroll
David S huler
Vin Shelton
Tim Souder
Adam Sulmi ki
Bill Thorson
George Talbot
Pedro A. M. Vazquez
Gregory Warnes
Ian Watson
David E. Young

417

418

Using the GNU Compiler Colle tion (GCC)

And many others

And nally we'd like to thank everyone who uses the ompiler, submits bug reports and
generally reminds us why we're doing this work in the rst pla e.

Chapter 13: Option Index

419

Option Index
GCC's ommand line options are indexed here without any initial `-' or `--'. Where an
option has both positive and negative forms (su h as `-foption ' and `-fno-option '), relevant entries in the manual are indexed under the most appropriate form; it may sometimes
be useful to look up both forms.

### . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

-dynami lib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

-for e_ pusubtype_ALL . . . . . . . . . . . . . . . . . . . . 117
-fsplit-ivs-in-unroller . . . . . . . . . . . . . . . . . . . 72
-fvariable-expansion-in-unroller . . . . . . . . . . 73
-gfull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
-gused . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
-mone-byte-bool . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
all_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
allowable_ lient . . . . . . . . . . . . . . . . . . . . . . . . . . 118
ansi . . . . . . . . . . . . . . . . . . . . . . . . . 5, 20, 92, 272, 377
ar h_errors_fatal . . . . . . . . . . . . . . . . . . . . . . . . . 117
aux-info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

b ..........................................
B ..........................................
b opy-builtin . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
bind_at_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
bundle_loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

108
100
154
117
117
117

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18, 97
C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
lient_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
ombine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
ompatibility_version . . . . . . . . . . . . . . . . . . . . 118
rossjumping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
urrent_version . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

d ...........................................
D ...........................................
da . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
dA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
db . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53
88
56
53
53

dB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
dC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
dd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
dD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53, 95
dE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
dead_strip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
dependen y-file . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
df . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
dg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
dG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
dh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
dH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
di . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
dI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
dj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
dk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
dl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
dL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
dm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55, 56
dM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55, 95
dn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
dN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55, 95
do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
dp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
dP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
dr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
dR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
ds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
dS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
dt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
dT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
dumpma hine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
dumpspe s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
dumpversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
dv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
dV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
dw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
dx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
dy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
dylib_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
dylinker_install_name . . . . . . . . . . . . . . . . . . . . 118
dynami . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
dz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
dZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 97

420

Using the GNU Compiler Colle tion (GCC)

EB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109, 145
EL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109, 145
exported_symbols_list . . . . . . . . . . . . . . . . . . . . 118

fdump-rtl-life . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
fdump-rtl-loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
fdump-rtl-loop2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
fdump-rtl-lreg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
fdump-rtl-ma h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
fdump-rtl-peephole2 . . . . . . . . . . . . . . . . . . . . . . . . 56
fdump-rtl-postreload . . . . . . . . . . . . . . . . . . . . . . . 55
fdump-rtl-regmove . . . . . . . . . . . . . . . . . . . . . . . . . . 55
fdump-rtl-rnreg . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
fdump-rtl-s hed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
fdump-rtl-s hed2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
fdump-rtl-sibling . . . . . . . . . . . . . . . . . . . . . . . . . . 54
fdump-rtl-sms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
fdump-rtl-sta k . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
fdump-rtl-tra er . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
fdump-rtl-vartra k . . . . . . . . . . . . . . . . . . . . . . . . . 55
fdump-rtl-vpt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
fdump-rtl-web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
fdump-translation-unit . . . . . . . . . . . . . . . . . . . . 56
fdump-tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
fdump-tree-alias . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
fdump-tree-all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
fdump-tree- p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
fdump-tree- fg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
fdump-tree- h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
fdump-tree- opyrename . . . . . . . . . . . . . . . . . . . . . 59
fdump-tree-d e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
fdump-tree-dom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
fdump-tree-dse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
fdump-tree-forwprop . . . . . . . . . . . . . . . . . . . . . . . . 59
fdump-tree-fre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
fdump-tree-gimple . . . . . . . . . . . . . . . . . . . . . . . . . . 58
fdump-tree-mudflap . . . . . . . . . . . . . . . . . . . . . . . . . 58
fdump-tree-nrv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
fdump-tree-phiopt . . . . . . . . . . . . . . . . . . . . . . . . . . 58
fdump-tree-pre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
fdump-tree-sra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
fdump-tree-ssa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
fdump-tree-v g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
fdump-tree-ve t . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
fdump-unnumbered . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
feliminate-dwarf2-dups . . . . . . . . . . . . . . . . . . . . 51
feliminate-unused-debug-symbols . . . . . . . . . . . 50
feliminate-unused-debug-types . . . . . . . . . . . . . 61
fex eptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
fexe - harset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
fexpensive-optimizations . . . . . . . . . . . . . . . . . . 69
ffast-math . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
ffinite-math-only . . . . . . . . . . . . . . . . . . . . . . . . . . 77
ffix-and- ontinue . . . . . . . . . . . . . . . . . . . . . . . . . 117
ffixed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
ffloat-store . . . . . . . . . . . . . . . . . . . . . . . . . . . 76, 370
ffor-s ope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
ffor e-addr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
ffor e-mem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
ffreestanding . . . . . . . . . . . . . . . . . . . . 6, 23, 36, 221
ffun tion-se tions . . . . . . . . . . . . . . . . . . . . . . . . . 80
fg se . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
fabi-version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
falign-fun tions . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
falign-jumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
falign-labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
falign-loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
fargument-alias . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
fargument-noalias . . . . . . . . . . . . . . . . . . . . . . . . . 183
fargument-noalias-global . . . . . . . . . . . . . . . . . 183
fasyn hronous-unwind-tables . . . . . . . . . . . . . . 179
fbounds- he k . . . . . . . . . . . . . . . . . . . . . . . . . . 66, 178
fbran h-probabilities . . . . . . . . . . . . . . . . . . . . . 79
fbran h-target-load-optimize . . . . . . . . . . . . . . 81
fbran h-target-load-optimize2 . . . . . . . . . . . . . 81
fbtr-bb-ex lusive . . . . . . . . . . . . . . . . . . . . . . . . . . 81
f all-saved . . . . . . . . . . . . . . . . . . . . . . . . . . . 181, 365
f all-used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
f aller-saves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
f he k-new . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
f ommon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
f ond-mismat h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
f onserve-spa e . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
f onstant-string- lass . . . . . . . . . . . . . . . . . . . . 31
f se-follow-jumps . . . . . . . . . . . . . . . . . . . . . . . . . . 67
f se-skip-blo ks . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
f x-limited-range . . . . . . . . . . . . . . . . . . . . . . . . . . 78
fdata-se tions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
fdelayed-bran h . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
fdelete-null-pointer- he ks . . . . . . . . . . . . . . . 68
fdiagnosti s-show-lo ation . . . . . . . . . . . . . . . . 34
fdollars-in-identifiers . . . . . . . . . . . . . . . 94, 365
fdump- lass-hierar hy . . . . . . . . . . . . . . . . . . . . . 56
fdump-ipa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
fdump-rtl-all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
fdump-rtl-bbro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
fdump-rtl-bp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
fdump-rtl-btl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
fdump-rtl-bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
fdump-rtl- e1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
fdump-rtl- e2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
fdump-rtl- e3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
fdump-rtl- fg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
fdump-rtl- ombine . . . . . . . . . . . . . . . . . . . . . . . . . . 53
fdump-rtl- se . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
fdump-rtl- se2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
fdump-rtl-dbr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
fdump-rtl-eh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
fdump-rtl-expand . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
fdump-rtl-flow2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
fdump-rtl-g se . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
fdump-rtl-greg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
fdump-rtl-jump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Chapter 13: Option Index

fg se-after-reload . . . . . . . . . . . . . . . . . . . . . . . . . 68
fg se-las . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
fg se-lm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
fg se-sm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
fgnu-runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
fhosted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
filelist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
findire t-data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
finhibit-size-dire tive . . . . . . . . . . . . . . . . . . 180
finline-fun tions . . . . . . . . . . . . . . . . . . . . . . . . . . 64
finline-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
finput- harset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
finstrument-fun tions . . . . . . . . . . . . . . . . 182, 224
fkeep-inline-fun tions . . . . . . . . . . . . . . . . 65, 243
fkeep-stati - onsts . . . . . . . . . . . . . . . . . . . . . . . . 65
flat_namespa e . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
fleading-unders ore . . . . . . . . . . . . . . . . . . . . . . . 183
floop-optimize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
floop-optimize2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
fmem-report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
fmessage-length . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
fmodulo-s hed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
fmove-loop-invariants . . . . . . . . . . . . . . . . . . . . . 80
fms-extensions . . . . . . . . . . . . . . . . . . . . . 23, 26, 330
fmudflap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
fmudflapir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
fmudflapth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
fnext-runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
fno-a ess- ontrol . . . . . . . . . . . . . . . . . . . . . . . . . 24
fno-asm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
fno-bran h- ount-reg . . . . . . . . . . . . . . . . . . . . . . . 65
fno-builtin . . . . . . . . . . . . . . . . . . . . 22, 36, 221, 272
fno- ommon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180, 234
fno- onst-strings . . . . . . . . . . . . . . . . . . . . . . . . . . 25
fno- prop-registers . . . . . . . . . . . . . . . . . . . . . . . . 76
fno- x-limited-range . . . . . . . . . . . . . . . . . . . . . . . 78
fno-default-inline . . . . . . . . . . . . . . . . . 27, 63, 243
fno-defer-pop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
fno-elide- onstru tors . . . . . . . . . . . . . . . . . . . . 25
fno-enfor e-eh-spe s . . . . . . . . . . . . . . . . . . . . . . . 25
fno-for-s ope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
fno-fun tion- se . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
fno-gnu-keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
fno-guess-bran h-probability . . . . . . . . . . . . . . 73
fno-ident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
fno-implement-inlines . . . . . . . . . . . . . . . . . 26, 339
fno-impli it-inline-templates . . . . . . . . . . . . . 26
fno-impli it-templates . . . . . . . . . . . . . . . . 26, 340
fno-inline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
fno-math-errno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
fno-nil-re eivers . . . . . . . . . . . . . . . . . . . . . . . . . . 31
fno-nonansi-builtins . . . . . . . . . . . . . . . . . . . . . . . 26
fno-operator-names . . . . . . . . . . . . . . . . . . . . . . . . . 26
fno-optional-diags . . . . . . . . . . . . . . . . . . . . . . . . . 26
fno-peephole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
fno-peephole2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
fno-rtti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
fno-s hed-interblo k . . . . . . . . . . . . . . . . . . . . . . . 69

421

fno-s hed-spe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
fno-show- olumn . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
fno-signed-bitfields . . . . . . . . . . . . . . . . . . . . . . . 24
fno-sta k-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
fno-threadsafe-stati s . . . . . . . . . . . . . . . . . . . . 27
fno-trapping-math . . . . . . . . . . . . . . . . . . . . . . . . . . 77
fno-unsigned-bitfields . . . . . . . . . . . . . . . . . . . . 24
fno-weak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
fno-working-dire tory . . . . . . . . . . . . . . . . . . . . . 94
fno-zero-initialized-in-bss . . . . . . . . . . . . . . . 66
fnon- all-ex eptions . . . . . . . . . . . . . . . . . . . . . . 179
fobj -ex eptions . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
fomit-frame-pointer . . . . . . . . . . . . . . . . . . . . . . . . 64
foptimize-register-move . . . . . . . . . . . . . . . . . . . 69
foptimize-sibling- alls . . . . . . . . . . . . . . . . . . . 64
for e_flat_namespa e . . . . . . . . . . . . . . . . . . . . . . 118
fpa k-stru t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
fp -stru t-return . . . . . . . . . . . . . . . . . . . 179, 368
fp h-deps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
fp h-prepro ess . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
fpeel-loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
fpermissive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
fpi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
fPIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
fpie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
fPIE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
fprefet h-loop-arrays . . . . . . . . . . . . . . . . . . 73, 80
fprepro essed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
fprofile-ar s . . . . . . . . . . . . . . . . . . . . . . . . . . 51, 275
fprofile-generate . . . . . . . . . . . . . . . . . . . . . . . . . . 76
fprofile-use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
fprofile-values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
frandom-string . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
freg-stru t-return . . . . . . . . . . . . . . . . . . . . . . . . 179
fregmove . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
frename-registers . . . . . . . . . . . . . . . . . . . . . . . . . . 79
freorder-blo ks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
freorder-blo ks-and-partition . . . . . . . . . . . . . 73
freorder-fun tions . . . . . . . . . . . . . . . . . . . . . . . . . 73
frepla e-obj - lasses . . . . . . . . . . . . . . . . . . . . . 33
frepo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26, 340
frerun- se-after-loop . . . . . . . . . . . . . . . . . . . . . 67
frerun-loop-opt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
frounding-math . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
fs hed-spe -load . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
fs hed-spe -load-dangerous . . . . . . . . . . . . . . . . 70
fs hed-stalled-insns . . . . . . . . . . . . . . . . . . . . . . . 70
fs hed-stalled-insns-dep . . . . . . . . . . . . . . . . . . 70
fs hed-verbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
fs hed2-use-superblo ks . . . . . . . . . . . . . . . . . . . 70
fs hed2-use-tra es . . . . . . . . . . . . . . . . . . . . . . . . . 70
fs hedule-insns . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
fs hedule-insns2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
fs heduling-in-modulo-s heduled-loops . . . . 70
fshared-data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
fshort-double . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
fshort-enums . . . . . . . . . . . . . . . . . 179, 197, 239, 376
fshort-w har . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

422

fsignaling-nans . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
fsigned-bitfields . . . . . . . . . . . . . . . . . . . . . 24, 376
fsigned- har . . . . . . . . . . . . . . . . . . . . . . . . . . . 24, 194
fsingle-pre ision- onstant . . . . . . . . . . . . . . . . 78
fspe ulative-prefet hing . . . . . . . . . . . . . . . . . . 79
fsta k- he k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
fsta k-limit-register . . . . . . . . . . . . . . . . . . . . 183
fsta k-limit-symbol . . . . . . . . . . . . . . . . . . . . . . . 183
fstats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
fstrength-redu e . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
fstri t-aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
fsyntax-only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
ftabstop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
ftemplate-depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
ftest- overage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
fthread-jumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
ftime-report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
ftra er . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72, 80
ftrapv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
ftree-based-profiling . . . . . . . . . . . . . . . . . . . . . 52
ftree-ve torizer-verbose . . . . . . . . . . . . . . . . . . 59
funit-at-a-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
funroll-all-loops . . . . . . . . . . . . . . . . . . . . . . 72, 80
funroll-loops . . . . . . . . . . . . . . . . . . . . . . 72, 80, 378
funsafe-math-optimizations . . . . . . . . . . . . . . . . 77
funsigned-bitfields . . . . . . . . . . . . . . . 24, 197, 376
funsigned- har . . . . . . . . . . . . . . . . . . . . . . . . . 23, 194
funswit h-loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
funwind-tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
fuse- xa-atexit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
fvar-tra king . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
fverbose-asm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
fvisibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
fvisibility-inlines-hidden . . . . . . . . . . . . . . . . 27
fvpt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
fweb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
fwide-exe - harset . . . . . . . . . . . . . . . . . . . . . . . . . 94
fworking-dire tory . . . . . . . . . . . . . . . . . . . . . . . . . 94
fwrapv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
fzero-link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140, 147, 164, 173
g off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
gdwarf-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
gen-de ls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
ggdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
gnu-ld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
gstabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
gstabs+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
gvms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
gx off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
gx off+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Using the GNU Compiler Colle tion (GCC)

H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
headerpad_max_install_names . . . . . . . . . . . . . . 118
help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 96
hp-ld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88, 100
I- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93, 101
idirafter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
if- onversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
if- onversion2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
ima ros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
image_base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
in lude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
install_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
iprefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
iquote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94, 100
isystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
iwithprefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
iwithprefixbefore . . . . . . . . . . . . . . . . . . . . . . . . . . 93

keep_private_externs . . . . . . . . . . . . . . . . . . . . . . 118

l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
L . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
lobj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
m1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
m10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
m128bit-long-double . . . . . . . . . . . . . . . . . . . . . . . 134
m16-bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
m2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
m210 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
m3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
m31 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
m32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137, 158, 172
m32-bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
m32032 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
m32081 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
m32332 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
m32381 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
m32532 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
m32r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
m32r2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
m32rx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
m340 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
m386 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Chapter 13: Option Index

m3dnow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m3e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m4-nofpu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m4-single . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m4-single-only . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m40 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m45 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m486 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m4a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m4a-nofpu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m4a-single . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m4a-single-only . . . . . . . . . . . . . . . . . . . . . . . . . . .
m4al . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m4byte-fun tions . . . . . . . . . . . . . . . . . . . . . . . . . .
m5200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m64 . . . . . . . . . . . . . . . . . . . . . . . . . . 137, 158, 166,
m68000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m68020 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m68020-40 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m68020-60 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m68030 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m68040 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m68060 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m6811 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m6812 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m68881 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m68h 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m68h 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m68h s12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m68S12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m8-bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m96bit-long-double . . . . . . . . . . . . . . . . . . . . . . . .
mabi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mabi-mmixware . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mabi=32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mabi=64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mabi=altive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mabi=eabi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mabi=gnu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mabi=n32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mabi=no-altive . . . . . . . . . . . . . . . . . . . . . . . . . . .
mabi=no-spe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mabi=o64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mabi=spe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mabi alls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mabort-on-noreturn . . . . . . . . . . . . . . . . . . . . . . . .
mabshi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ma 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ma -4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ma -8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ma umulate-outgoing-args . . . . . . . . . . . . . . . .
mads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
maix-stru t-return . . . . . . . . . . . . . . . . . . . . . . . .
maix32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
maix64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
malign-300 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
malign-double . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

423

135
167
168
167
167
167
154
154
132
168
168
168
168
168
144
141
172
141
141
141
142
141
141
141
143
143
141
143
143
143
143
115
134
109
151
146
146
162
146
151
146
162
157
146
157
146
111
154
154
125
125
136
163
162
158
158
127
133

malign-int . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
malign-labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
malign-loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
malign-natural . . . . . . . . . . . . . . . . . . . . . . . . . . . .
malign-power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mallo - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
malpha-as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
maltive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mam33 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
maout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
map s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
map s-frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mapp-regs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169,
mar h . . . . . . . . . . . 111, 114, 127, 130, 132, 145,
masm=diale t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mauto-in de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mauto-pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mba k hain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mbase-addresses . . . . . . . . . . . . . . . . . . . . . . . . . . .
mb opy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mbig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161,
mbig-endian . . . . . . . . . . . . . . . . . . 110, 137, 145,
mbig-memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mbig-swit h . . . . . . . . . . . . . . . . . . . . . . . . . . . 127,
mbigtable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mbit-align . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mbitfield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142,
mbk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mbran h- heap . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mbran h- ost=number . . . . . . . . . . . . . . . . . . . . . .
mbran h-expensive . . . . . . . . . . . . . . . . . . . . . . . . .
mbran h-likely . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mbran h-predi t . . . . . . . . . . . . . . . . . . . . . . . . . . .
mbuild- onstants . . . . . . . . . . . . . . . . . . . . . . . . . .
mbwx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m 68000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m 68020 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m all-gnu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m all-linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m all-netbsd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m all-prologues . . . . . . . . . . . . . . . . . . . . . . . . . . .
m all-solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m all-sysv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m all-sysv-eabi . . . . . . . . . . . . . . . . . . . . . . . . . . .
m all-sysv-noeabi . . . . . . . . . . . . . . . . . . . . . . . . .
m allee-super-interworking . . . . . . . . . . . . . . .
m aller-super-interworking . . . . . . . . . . . . . . .
m allgraph-data . . . . . . . . . . . . . . . . . . . . . . . . . . .
m -init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m he k-zero-division . . . . . . . . . . . . . . . . . . . . . .
m irrus-fix-invalid-insns . . . . . . . . . . . . . . . .
m ix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m model=embmedany . . . . . . . . . . . . . . . . . . . . . . . . .
m model=kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m model=large . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m model=medany . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m model=medium . . . . . . . . . . . . . . . . . . . . . . . . . . . .

142
125
140
159
159
124
121
157
152
115
109
109
176
166
133
144
138
168
165
151
154
173
161
173
176
168
160
153
173
155
140
155
150
151
121
121
141
141
162
162
162
114
162
161
162
162
113
113
144
115
148
112
121
172
137
137
172
137

424

Using the GNU Compiler Colle tion (GCC)

m model=medlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
m model=medmid . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
m model=small . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
m ond-exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
m ond-move . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
m onst-align . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
m onst16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
m onstant-gp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
m pu . . . 109, 110, 114, 122, 127, 132, 156, 170, 173
m pu32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
MD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
mdalign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
mdata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
mdata-align . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
mdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
mdebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140, 166
mde -asm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
mdisable- allt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
mdisable-fpregs . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
mdisable-indexing . . . . . . . . . . . . . . . . . . . . . . . . . 128
mdiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
mdivide-breaks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
mdivide-traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
mdouble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
mdouble-float . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
mdp-isr-reload . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
mdwarf2-asm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
mdword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
mdynami -no-pi . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
meabi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
mearly-stop-bits . . . . . . . . . . . . . . . . . . . . . . . . . . 138
melf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115, 151
melinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
melinux-sta ksize . . . . . . . . . . . . . . . . . . . . . . . . . 114
memb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
membedded-data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
mep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
mepsilon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
mesa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
metrax100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
metrax4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
mexpli it-relo s . . . . . . . . . . . . . . . . . . . . . 121, 148
MF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
mfast-fix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
mfast-indire t- alls . . . . . . . . . . . . . . . . . . . . . . 128
mfaster-stru ts . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
mfdpi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
mfix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
mfix-and- ontinue . . . . . . . . . . . . . . . . . . . . . . . . . 117
mfix-r4000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
mfix-r4400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
mfix-sb1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
mfix-vr4120 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
mfix-vr4130 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
mfixed- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
mfixed-range . . . . . . . . . . . . . . . . . . . . . . . . . . 128, 139
mfloat-abi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
mfloat-gprs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

mfloat-ieee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
mfloat-vax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
mfloat32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
mfloat64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
mflush-fun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
mflush-fun =name . . . . . . . . . . . . . . . . . . . . . . . . . . 140
mflush-trap=number . . . . . . . . . . . . . . . . . . . . . . . 140
mfmovd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
mfp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
mfp-ex eptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
mfp-reg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
mfp-rounding-mode . . . . . . . . . . . . . . . . . . . . . . . . . 120
mfp-trap-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
mfp32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
mfp64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
mfpe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
mfpr-32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
mfpr-64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
mfpu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111, 154, 169
mfull-to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
mfused-madd . . . . . . . . . . . . . . . . . . 149, 160, 167, 177
mg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
MG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
mgas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121, 128
mgnu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
mgnu-as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
mgnu-ld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
mgotplt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
mgp32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
mgp64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
mgpr-32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
mgpr-64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
mgprel-ro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
mh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
mhard-float . . . . . . . . . 110, 123, 147, 159, 165, 169
mhard-quad-float . . . . . . . . . . . . . . . . . . . . . . . . . . 169
mhardlit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
mhimem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
mhita hi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
mieee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119, 168
mieee- ompare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
mieee- onformant . . . . . . . . . . . . . . . . . . . . . . . . . . 121
mieee-fp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
mieee-with-inexa t . . . . . . . . . . . . . . . . . . . . . . . . 119
milp32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
mimpure-text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
minit-sta k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
minline-all-stringops . . . . . . . . . . . . . . . . . . . . 136
minline-float-divide-max-throughput . . . . . 138
minline-float-divide-min-laten y . . . . . . . . . 138
minline-int-divide-max-throughput . . . . . . . 138
minline-int-divide-min-laten y . . . . . . . . . . . 138
minline-plt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
minline-sqrt-max-throughput . . . . . . . . . . . . . . 138
minline-sqrt-min-laten y . . . . . . . . . . . . . . . . . 138
minmax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
minsert-s hed-nops . . . . . . . . . . . . . . . . . . . . . . . . 161
mint16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Chapter 13: Option Index

mint32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127, 154

mint64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
mint8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
mips1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
mips16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
mips2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
mips3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
mips32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
mips32r2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
mips3d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
mips4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
mips64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
misel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
misize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
missue-rate=number . . . . . . . . . . . . . . . . . . . . . . . 140
mjump-in-delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
mknuthdiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
ml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
mlarge-data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
mlarge-text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
mlibfun s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
mlibrary-pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
mlinked-fp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
mlinker-opt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
mlinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
mlittle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
mlittle-endian . . . . . . . . . . 110, 137, 145, 161, 172
mlong- alls . . . . . . . . . . . . . 111, 125, 144, 149, 175
mlong-load-store . . . . . . . . . . . . . . . . . . . . . . . . . . 128
mlong32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
mlong64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
mlong all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
mlong alls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
mloop-unsigned . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
mlp64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
MM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
mmad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
mmangle- pu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
mmax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
mmax-sta k-frame . . . . . . . . . . . . . . . . . . . . . . . . . . 114
mm u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
MMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
mmedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
mmem py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
mmemory-laten y . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
mmemparm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
mminimal-to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
mmmx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
mmodel=large . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
mmodel=medium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
mmodel=small . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
mmpyi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
mmul-bug-workaround . . . . . . . . . . . . . . . . . . . . . . . 114
mmuladd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
mmult-bug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
mmulti-add . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
mmulti- ond-exe . . . . . . . . . . . . . . . . . . . . . . . . . . 126
mmultiple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

425

mmv le . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mmvme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mnested- ond-exe . . . . . . . . . . . . . . . . . . . . . . . . .
mnew-mnemoni s . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-3dnow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-4byte-fun tions . . . . . . . . . . . . . . . . . . . . . . .
mno-abi alls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-abshi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-a 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-align-double . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-align-int . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-align-loops . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-align-stringops . . . . . . . . . . . . . . . . . . . . . . .
mno-altive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-am33 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-app-regs . . . . . . . . . . . . . . . . . . . . . . . . . . 169,
mno-ba k hain . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-base-addresses . . . . . . . . . . . . . . . . . . . . . . . .
mno-bit-align . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-bk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-bran h-likely . . . . . . . . . . . . . . . . . . . . . . . . .
mno-bran h-predi t . . . . . . . . . . . . . . . . . . . . . . . .
mno-bwx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno- allgraph-data . . . . . . . . . . . . . . . . . . . . . . . .
mno- he k-zero-division . . . . . . . . . . . . . . . . . .
mno- irrus-fix-invalid-insns . . . . . . . . . . . . .
mno- ix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno- ond-exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno- ond-move . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno- onst-align . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno- onst16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno- rt0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-data-align . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-db . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-div . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-double . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-dwarf2-asm . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-dword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-eabi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-early-stop-bits . . . . . . . . . . . . . . . . . . . . . . .
mno-eflags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-embedded-data . . . . . . . . . . . . . . . . . . . . . . . . .
mno-ep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-epsilon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-expli it-relo s . . . . . . . . . . . . . . . . . . 121,
mno-fan y-math-387 . . . . . . . . . . . . . . . . . . . . . . . .
mno-fast-fix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-faster-stru ts . . . . . . . . . . . . . . . . . . . . . . . .
mno-fix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-fix-r4000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-fix-r4400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-float32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-float64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-flush-fun . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-flush-trap . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-fp-in-to . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

166
162
127
126
156
135
144
146
154
154
133
142
140
136
157
152
176
165
151
160
173
150
151
121
144
148
112
121
126
125
115
177
152
115
173
166
144
124
138
124
163
138
125
148
175
151
148
133
174
170
121
149
149
154
154
140
140
158

426

mno-fp-regs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-fp-ret-in-387 . . . . . . . . . . . . . . . . . . . . . . . . .
mno-fpu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-fused-madd . . . . . . . . . . . . . . . 149, 160, 167,
mno-gnu-as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-gnu-ld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-gotplt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-hardlit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-ieee- ompare . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-ieee-fp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-int16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-int32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-knuthdiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-libfun s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-long- alls . . . . . . . . . . 111, 129, 144, 149,
mno-long all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-long alls . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-loop-unsigned . . . . . . . . . . . . . . . . . . . . . . . . .
mno-mad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-mem py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-mips16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-mips3d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-mmx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-mpyi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-mul-bug-workaround . . . . . . . . . . . . . . . . . . .
mno-muladd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-mult-bug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-multi- ond-exe . . . . . . . . . . . . . . . . . . . . . . .
mno-multiple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-mv le . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-nested- ond-exe . . . . . . . . . . . . . . . . . . . . . .
mno-pa k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-pa ked-sta k . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-paired-single . . . . . . . . . . . . . . . . . . . . . . . . .
mno-parallel-insns . . . . . . . . . . . . . . . . . . . . . . . .
mno-parallel-mpy . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-power2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-powerp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-powerp -gfxopt . . . . . . . . . . . . . . . . . . . . . . . .
mno-powerp -gpopt . . . . . . . . . . . . . . . . . . . . . . . . .
mno-powerp 64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-prolog-fun tion . . . . . . . . . . . . . . . . . . . . . . .
mno-prologue-epilogue . . . . . . . . . . . . . . . . . . . .
mno-prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-push-args . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-register-names . . . . . . . . . . . . . . . . . . . . . . . .
mno-regnames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-relax-immediate . . . . . . . . . . . . . . . . . . . . . . .
mno-relo atable . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-relo atable-lib . . . . . . . . . . . . . . . . . . . . . . .
mno-rptb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-rpts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mno-s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Using the GNU Compiler Colle tion (GCC)

119
133
169
177
137
137
115
144
153
133
154
154
114
151
151
175
164
177
174
149
121
124
148
146
147
135
174
114
124
152
126
159
166
126
125
165
147
175
175
137
155
155
155
155
155
155
175
115
162
136
138
164
144
160
160
174
174
126

mno-s hed-prolog . . . . . . . . . . . . . . . . . . . . . . . . . . 109

mno-sdata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138, 164
mno-side-effe ts . . . . . . . . . . . . . . . . . . . . . . . . . . 115
mno-single-exit . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
mno-slow-bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
mno-small-exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
mno-soft-float . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
mno-spa e-regs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
mno-split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
mno-split-addresses . . . . . . . . . . . . . . . . . . . . . . . 148
mno-sse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
mno-sta k-align . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
mno-sta k-bias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
mno-stri t-align . . . . . . . . . . . . . . . . . . . . . 143, 160
mno-string . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
mno-sum-in-to . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
mno-svr3-shlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
mno-sym32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
mno-tablejump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
mno-target-align . . . . . . . . . . . . . . . . . . . . . . . . . . 177
mno-text-se tion-literals . . . . . . . . . . . . . . . . 177
mno-to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
mno-toplevel-symbols . . . . . . . . . . . . . . . . . . . . . . 151
mno-tpf-tra e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
mno-unaligned-doubles . . . . . . . . . . . . . . . . . . . . 170
mno-uninit- onst-in-rodata . . . . . . . . . . . . . . . 148
mno-update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
mno-v8plus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
mno-vis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
mno-vliw-bran h . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
mno-volatile-asm-stop . . . . . . . . . . . . . . . . . . . . 138
mno-wide-bitfields . . . . . . . . . . . . . . . . . . . . . . . . 144
mno-xgot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
mno-xl- ompat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
mno-zero-extend . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
mnobitfield . . . . . . . . . . . . . . . . . . . . . . . . . . . 142, 153
mnohimem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
mnoma save . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
mnominmax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
mnomulti-add . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
mnop-fun-dllimport . . . . . . . . . . . . . . . . . . . . . . . . 112
mnoregparam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
mnosb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
mold-mnemoni s . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
momit-leaf-frame-pointer . . . . . . . . . . . . . . . . . 136
MP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
mpa-ris -1-0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
mpa-ris -1-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
mpa-ris -2-0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
mpa k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
mpa ked-sta k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
mpadstru t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
mpaired-single . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
mparallel-insns . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
mparallel-mpy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
mparanoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
mp rel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
mpdebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Chapter 13: Option Index

mpe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
mpentium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
mpentiumpro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
mpi -register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
mpoke-fun tion-name . . . . . . . . . . . . . . . . . . . . . . . 112
mportable-runtime . . . . . . . . . . . . . . . . . . . . . . . . . 128
mpower . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
mpower2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
mpowerp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
mpowerp -gfxopt . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
mpowerp -gpopt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
mpowerp 64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
mprefergot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
mpreferred-sta k-boundary . . . . . . . . . . . . . . . . 135
mprioritize-restri ted-insns . . . . . . . . . . . . . 161
mprolog-fun tion . . . . . . . . . . . . . . . . . . . . . . . . . . 175
mprologue-epilogue . . . . . . . . . . . . . . . . . . . . . . . . 115
mprototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
mpush-args . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
mregister-names . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
mregnames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
mregparam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
mregparm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135, 175
mrelax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127, 152, 168
mrelax-immediate . . . . . . . . . . . . . . . . . . . . . . . . . . 144
mrelo atable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
mrelo atable-lib . . . . . . . . . . . . . . . . . . . . . . . . . . 160
mrodata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
mrptb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
mrpts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
mrtd . . . . . . . . . . . . . . . . . . . . . . . . . 134, 142, 153, 218
ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
ms2600 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
msb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
ms hed- ostly-dep . . . . . . . . . . . . . . . . . . . . . . . . . 161
ms hedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
msda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
msdata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138, 163
msdata-data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
msdata=default . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
msdata=eabi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
msdata=none . . . . . . . . . . . . . . . . . . . . . . . . . . . 139, 164
msdata=sdata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
msdata=sysv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
msdata=use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
mshort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142, 144
msim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162, 176
msingle-exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
msingle-float . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
msingle-pi -base . . . . . . . . . . . . . . . . . . . . . . . . . . 112
msio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
msize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
mslow-bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
msmall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
msmall-data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
msmall-exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

427

msmall-memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
msmall-text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
msoft-float . . . . 110, 119, 124, 128, 133, 142, 147,

153, 154, 159, 165, 169

msoft-quad-float . . . . . . . . . . . . . . . . . . . . . . . . . . 169
msoft-reg- ount . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
mspa e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168, 175
mspe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
msplit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
msplit-addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 148
msse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
msta k-align . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
msta k-bias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
msta k-guard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
msta k-size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
mstri t-align . . . . . . . . . . . . . . . . . . . . . . . . . 143, 160
mstring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
mstru ture-size-boundary . . . . . . . . . . . . . . . . . 111
msvr3-shlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
msvr4-stru t-return . . . . . . . . . . . . . . . . . . . . . . . 162
msym32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
mt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
MT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
mtarget-align . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
mtda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
mtext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
mtext-se tion-literals . . . . . . . . . . . . . . . . . . . 177
mthreads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
mthumb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
mthumb-interwork . . . . . . . . . . . . . . . . . . . . . . . . . . 109
mti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
mtiny-sta k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
mtls-dire t-seg-refs . . . . . . . . . . . . . . . . . . . . . . 136
mtls-size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
mto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
mtom at-stats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
mtoplevel-symbols . . . . . . . . . . . . . . . . . . . . . . . . . 151
mtp s-frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
mtp s-leaf-frame . . . . . . . . . . . . . . . . . . . . . . . . . . 113
mtpf-tra e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
mtrap-pre ision . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
mtune . . . . . . 111, 114, 123, 130, 145, 157, 166, 171
mtune-ar h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
multi_module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
multilib-library-pi . . . . . . . . . . . . . . . . . . . . . . 125
multiply_defined . . . . . . . . . . . . . . . . . . . . . . . . . . 118
multiply_defined_unused . . . . . . . . . . . . . . . . . . 118
munaligned-doubles . . . . . . . . . . . . . . . . . . . . . . . . 170
muninit- onst-in-rodata . . . . . . . . . . . . . . . . . . 148
munix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
munix-asm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
mupdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
musermode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
mv850 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
mv850e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
mv850e1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
mv8plus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
mvis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

428

mvliw-bran h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mvms-return- odes . . . . . . . . . . . . . . . . . . . . . . . . .
mvolatile-asm-stop . . . . . . . . . . . . . . . . . . . . . . . .
mvr4130-align . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mvxworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mwarn-dynami sta k . . . . . . . . . . . . . . . . . . . . . . . .
mwarn-framesize . . . . . . . . . . . . . . . . . . . . . . . . . . .
mwide-bitfields . . . . . . . . . . . . . . . . . . . . . . . . . . .
mwindiss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mwords-little-endian . . . . . . . . . . . . . . . . . . . . . .
mxgot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mxl- ompat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
myellowknife . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mzar h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mzda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mzero-extend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Using the GNU Compiler Colle tion (GCC)

126
123
138
150
163
167
167
144
163
110
146
159
163
166
176
151

no-integrated- pp . . . . . . . . . . . . . . . . . . . . . . . . . . 23
no-red-zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
no_dead_strip_inits_and_terms . . . . . . . . . . . . 118
noall_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
no pp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
nodefaultlibs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
nofixprebinding . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
nolibdld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
nomultidefs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
noprebind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
noseglinkedit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
nostartfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
nostdin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
nostdin ++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27, 93
nostdlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19,
O ...........................................
O0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
O1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
O2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
O3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88
62
63
62
62
63
63

p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
pagezero_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
param . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
pass-exit- odes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
pedanti . . . . . . . . . . . . . . . . 5, 35, 90, 201, 268, 379
pedanti -errors . . . . . . . . . . . . . 5, 35, 90, 378, 379
pg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
pie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
pipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
prebind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

prebind_all_twolevel_modules . . . . . . . . . . . . . 118
prepro essor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
print-file-name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
print-libg -file-name . . . . . . . . . . . . . . . . . . . . 60
print-multi-dire tory . . . . . . . . . . . . . . . . . . . . . 60
print-multi-lib . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
print-obj -runtime-info . . . . . . . . . . . . . . . . . . . 34
print-prog-name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
print-sear h-dirs . . . . . . . . . . . . . . . . . . . . . . . . . . 60
private_bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
pthread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139, 164
pthreads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Q . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Qn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Qy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

read_only_relo s . . . . . . . . . . . . . . . . . . . . . . . . . . 118
remap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18, 97
save-temps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
se talign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
se t reate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
se tobje tsymbols . . . . . . . . . . . . . . . . . . . . . . . . . 118
se torder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
seg_addr_table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
seg_addr_table_filename . . . . . . . . . . . . . . . . . . 118
seg1addr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
segaddr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
seglinkedit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
segprot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
segs_read_only_addr . . . . . . . . . . . . . . . . . . . . . . . 118
segs_read_write_addr . . . . . . . . . . . . . . . . . . . . . . 118
shared . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
shared-libg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
sim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
sim2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
single_module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
spe s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
stati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98, 118, 130
stati -libg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
std . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5, 21, 272, 377
std= . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
sub_library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
sub_umbrella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
symboli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Chapter 13: Option Index

target-help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 96
threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130, 172
time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
tls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
traditional . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23, 365
traditional- pp . . . . . . . . . . . . . . . . . . . . . . . . . 23, 96
trigraphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23, 96
twolevel_namespa e . . . . . . . . . . . . . . . . . . . . . . . . 118

u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
U . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
umbrella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
undef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
undefined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
unexported_symbols_list . . . . . . . . . . . . . . . . . . 118

v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 96
V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20, 96

w . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35, 90
W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42, 47, 366
Wa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Wabi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Waggregate-return . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Wall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42, 88, 369
Wbad-fun tion- ast . . . . . . . . . . . . . . . . . . . . . . . . . 45
W ast-align . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
W ast-qual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
W har-subs ripts . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
W omment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36, 88
W omments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
W onversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46, 374
W tor-dtor-priva y . . . . . . . . . . . . . . . . . . . . . . . . . 29
Wde laration-after-statement . . . . . . . . . . . . . . 45
Wdisabled-optimization . . . . . . . . . . . . . . . . . . . . 49
Wdiv-by-zero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
weak_referen e_mismat hes . . . . . . . . . . . . . . . . 118
Weff ++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Wendif-labels . . . . . . . . . . . . . . . . . . . . . . . . . . . 45, 89
Werror . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49, 89
Werror-impli it-fun tion-de laration . . . . . 38
Wextra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42, 47
Wfatal-errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Wfloat-equal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Wformat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36, 47, 220
Wformat-nonliteral . . . . . . . . . . . . . . . . . . . . 37, 221
Wformat-se urity . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Wformat-y2k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

429

Wformat=2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
whatsloaded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
whyload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Wimpli it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Wimpli it-fun tion-de laration . . . . . . . . . . . . 38
Wimpli it-int . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Wimport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Winit-self . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Winline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48, 243
Winvalid-p h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Wl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Wlarger-than . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Wlong-long . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Wmain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Wmissing-bra es . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Wmissing-de larations . . . . . . . . . . . . . . . . . . . . . 47
Wmissing-field-initializers . . . . . . . . . . . . . . . 47
Wmissing-format-attribute . . . . . . . . . . . . . . . . . 47
Wmissing-in lude-dirs . . . . . . . . . . . . . . . . . . . . . 38
Wmissing-noreturn . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Wmissing-prototypes . . . . . . . . . . . . . . . . . . . . . . . . 46
Wmulti har . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Wnested-externs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Wno-depre ated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Wno-depre ated-de larations . . . . . . . . . . . . . . . 47
Wno-div-by-zero . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Wno-endif-labels . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Wno-format-extra-args . . . . . . . . . . . . . . . . . . . . . 36
Wno-format-zero-length . . . . . . . . . . . . . . . . . . . . 37
Wno-import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Wno-invalid-offsetof . . . . . . . . . . . . . . . . . . . . . . . 48
Wno-long-long . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Wno-multi har . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Wno-non-template-friend . . . . . . . . . . . . . . . . . . . 29
Wno-pmf- onversions . . . . . . . . . . . . . . . . . . . 30, 341
Wno-pointer-sign . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Wno-proto ol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Wno-variadi -ma ros . . . . . . . . . . . . . . . . . . . . . . . . 49
Wnon-virtual-dtor . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Wnonnull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Wold-style- ast . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Wold-style-definition . . . . . . . . . . . . . . . . . . . . . 46
Woverloaded-virtual . . . . . . . . . . . . . . . . . . . . . . . . 30
Wp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Wpa ked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Wpadded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Wparentheses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Wpointer-arith . . . . . . . . . . . . . . . . . . . . . . . . . 45, 214
Wredundant-de ls . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Wreorder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Wreturn-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Wsele tor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Wsequen e-point . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Wshadow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Wsign- ompare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Wsign-promo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Wstri t-aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Wstri t-aliasing=2 . . . . . . . . . . . . . . . . . . . . . . . . . 42

430

Wstri t-prototypes . . . . . . . . . . . . . . . . . . . . . . . . .
Wswit h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wswit h-enum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wswit h-swit h . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wsystem-headers . . . . . . . . . . . . . . . . . . . . . . . . . 43,
Wtraditional . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44,
Wtrigraphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40,
Wunde lared-sele tor . . . . . . . . . . . . . . . . . . . . . . .
Wundef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45,
Wuninitialized . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wunknown-pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wunrea hable- ode . . . . . . . . . . . . . . . . . . . . . . . . . .
Wunused . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wunused-fun tion . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wunused-label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wunused-ma ros . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Using the GNU Compiler Colle tion (GCC)

46
40
40
40
89
89
89
33
89
41
42
48
41
40
40
89

Wunused-parameter . . . . . . . . . . . . . . . . . . . . . . . . . .
Wunused-value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wunused-variable . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wvariadi -ma ros . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wwrite-strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40
41
40
49
46

x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18, 92
Xassembler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Xlinker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Ym . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
YP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Chapter 13: Keyword Index

431

Keyword Index
!

<

`!' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

`#' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

#pragma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
#pragma implementation . . . . . . . . . . . . . . . . . . . . 338
#pragma implementation, implied . . . . . . . . . . . . 338
#pragma interfa e . . . . . . . . . . . . . . . . . . . . . . . . . 338
#pragma, reason for not using . . . . . . . . . . . . . . . . 228

$ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

`%' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . .
%in lude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
%in lude noerr . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
%rename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

253
102
102
102

&

`&' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

'

' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

`*' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

`+' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

`-lg ', use with `-nodefaultlibs' . . . . . . . . . . . .

`-lg ', use with `-nostdlib' . . . . . . . . . . . . . . . . .
`-nodefaultlibs' and unresolved referen es . . . .
`-nostdlib' and unresolved referen es . . . . . . . . .

98
98
98
98

.sdata/.sdata2 referen es (PowerPC) . . . . . . . . . 164

// . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

`<' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

`=' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

>

`>' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

`?' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

?: extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
?: side ee t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

`_' in variables in ma ros . . . . . . . . . . . . . . . . . . . . 207

__builtin_apply . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
__builtin_apply_args . . . . . . . . . . . . . . . . . . . . . . 206
__builtin_ hoose_expr . . . . . . . . . . . . . . . . . . . . 274
__builtin_ lz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
__builtin_ lzl . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
__builtin_ lzll . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
__builtin_ onstant_p . . . . . . . . . . . . . . . . . . . . . . 275
__builtin_ tz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
__builtin_ tzl . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
__builtin_ tzll . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
__builtin_expe t . . . . . . . . . . . . . . . . . . . . . . . . . . 275
__builtin_ffs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
__builtin_ffsl . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
__builtin_ffsll . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
__builtin_frame_address . . . . . . . . . . . . . . . . . . 270
__builtin_huge_val . . . . . . . . . . . . . . . . . . . . . . . . 276
__builtin_huge_valf . . . . . . . . . . . . . . . . . . . . . . . 276
__builtin_huge_vall . . . . . . . . . . . . . . . . . . . . . . . 277
__builtin_inf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
__builtin_inff . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
__builtin_infl . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
__builtin_isgreater . . . . . . . . . . . . . . . . . . . . . . . 272
__builtin_isgreaterequal . . . . . . . . . . . . . . . . . 272
__builtin_isless . . . . . . . . . . . . . . . . . . . . . . . . . . 272
__builtin_islessequal . . . . . . . . . . . . . . . . . . . . 272
__builtin_islessgreater . . . . . . . . . . . . . . . . . . 272
__builtin_isunordered . . . . . . . . . . . . . . . . . . . . 272
__builtin_nan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
__builtin_nanf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
__builtin_nanl . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
__builtin_nans . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
__builtin_nansf . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
__builtin_nansl . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
__builtin_offsetof . . . . . . . . . . . . . . . . . . . . . . . . 272

432

Using the GNU Compiler Colle tion (GCC)

__builtin_parity . . . . . . . . . . . . . . . . . . . . . . . . . . 278
__builtin_parityl . . . . . . . . . . . . . . . . . . . . . . . . . 278
__builtin_parityll . . . . . . . . . . . . . . . . . . . . . . . . 278
__builtin_pop ount . . . . . . . . . . . . . . . . . . . . . . . . 278
__builtin_pop ountl . . . . . . . . . . . . . . . . . . . . . . . 278
__builtin_pop ountll . . . . . . . . . . . . . . . . . . . . . . 278
__builtin_powi . . . . . . . . . . . . . . . . . . . . . . . . 272, 278
__builtin_powif . . . . . . . . . . . . . . . . . . . . . . 272, 278
__builtin_powil . . . . . . . . . . . . . . . . . . . . . . 272, 278
__builtin_prefet h . . . . . . . . . . . . . . . . . . . . . . . . 276
__builtin_return . . . . . . . . . . . . . . . . . . . . . . . . . . 207
__builtin_return_address . . . . . . . . . . . . . . . . . 270
__builtin_types_ ompatible_p . . . . . . . . . . . . . 274
__ omplex__ keyword . . . . . . . . . . . . . . . . . . . . . . . 209
__de lspe (dllexport) . . . . . . . . . . . . . . . . . . . . 219
__de lspe (dllimport) . . . . . . . . . . . . . . . . . . . . 219
__extension__ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
__fun __ identier . . . . . . . . . . . . . . . . . . . . . . . . . . 269
__FUNCTION__ identier . . . . . . . . . . . . . . . . . . . . . 269
__imag__ keyword . . . . . . . . . . . . . . . . . . . . . . . . . . 209
__PRETTY_FUNCTION__ identier . . . . . . . . . . . . . . 269
__real__ keyword . . . . . . . . . . . . . . . . . . . . . . . . . . 209
__STDC_HOSTED__ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

ANSI C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
ANSI C standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
ANSI C89 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
ANSI support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
ANSI X3.159-1989 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
apostrophes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
appli ation binary interfa e . . . . . . . . . . . . . . . . . . 351
ARC Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
ARM [Annotated C++ Referen e Manual . . . . . 344
ARM options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
arrays of length zero . . . . . . . . . . . . . . . . . . . . . . . . 210
arrays of variable length . . . . . . . . . . . . . . . . . . . . . 211
arrays, non-lvalue . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
asin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
asinf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
asinh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
asinhf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
asinhl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
asinl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
asm onstraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
asm expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
assembler instru tions . . . . . . . . . . . . . . . . . . . . . . . 244
assembler names for identiers . . . . . . . . . . . . . . . 265
assembly ode, invalid . . . . . . . . . . . . . . . . . . . . . . . 381
atan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
atan2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
atan2f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
atan2l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
atanf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
atanh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
atanhf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
atanhl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
atanl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
attribute of types . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
attribute of variables . . . . . . . . . . . . . . . . . . . . . . . . 233
attribute syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
autoin rement/de rement addressing . . . . . . . . . 250
automati inline for C++ member fns . . . . . . . . 243
AVR Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

_Complex keyword . . . . . . . . . . . . . . . . . . . . . . . . . . 209

_exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
_Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

`0' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

ABI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

abort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
abs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

a essing volatiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

a os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
a osf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
a osh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
a oshf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
a oshl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
a osl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
address onstraints . . . . . . . . . . . . . . . . . . . . . . . . . . 252
address of a label . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
address_operand . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
alias attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
aliasing of parameters . . . . . . . . . . . . . . . . . . . . . . . 183
aligned attribute . . . . . . . . . . . . . . . . . . . . . . 233, 238
alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
allo a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
allo a vs variable-length arrays . . . . . . . . . . . . . 212
alternate keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 268
always_inline fun tion attribute . . . . . . . . . . . . 218
AMD x86-64 Options . . . . . . . . . . . . . . . . . . . . . . . 130
AMD1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Ba kwards Compatibility . . . . . . . . . . . . . . . . . . . . 344

base lass members . . . . . . . . . . . . . . . . . . . . . . . . . 371
b mp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
below100 attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 238
binary ompatibility . . . . . . . . . . . . . . . . . . . . . . . . 351
bound pointer to member fun tion . . . . . . . . . . . 341
bounds he king . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
bug riteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
bugs, known . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
built-in fun tions . . . . . . . . . . . . . . . . . . . . . . . . 22, 272
bzero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

C ompilation options . . . . . . . . . . . . . . . . . . . . . . . . . 7

Chapter 13: Keyword Index

C intermediate output, nonexistent . . . . . . . . . . . . . 3

C language extensions . . . . . . . . . . . . . . . . . . . . . . . 201
C language, traditional . . . . . . . . . . . . . . . . . . . . . . . 23
C standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
C standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
C++ omments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
C++ ompilation options . . . . . . . . . . . . . . . . . . . . . . . 7
C++ interfa e and implementation headers . . . . 337
C++ language extensions . . . . . . . . . . . . . . . . . . . . 335
C++ member fns, automati ally inline . . . . . . . 243
C++ misunderstandings . . . . . . . . . . . . . . . . . . . . . . 370
C++ options, ommand line . . . . . . . . . . . . . . . . . . . 24
C++ pragmas, ee t on inlining . . . . . . . . . . . . . . 339
C++ sour e le suxes . . . . . . . . . . . . . . . . . . . . . . . 20
C++ stati data, de laring and dening . . . . . . . 370
C_INCLUDE_PATH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
C89 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
C90 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
C94 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
C95 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
C99 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
C9X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
abs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
absf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
absl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
a os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
a osf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
a osh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
a oshf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
a oshl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
a osl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
alling fun tions through the fun tion ve tor on
the H8/300 pro essors . . . . . . . . . . . . . . . . . . 222
allo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
arg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
argf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
argl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
ase labels in initializers . . . . . . . . . . . . . . . . . . . . . 215
ase ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
asin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
asinf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
asinh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
asinhf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
asinhl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
asinl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
ast to a union . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
atan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
atanf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
atanh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
atanhf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
atanhl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
atanl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
brt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
brtf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
brtl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

433

272
272
272
272
272
272
272
272
272
272
272
hara ter set, exe ution . . . . . . . . . . . . . . . . . . . . . . 94
hara ter set, input . . . . . . . . . . . . . . . . . . . . . . . . . . 94
hara ter set, wide exe ution . . . . . . . . . . . . . . . . . 94
imag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
imagf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
imagl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
leanup attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
COBOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
ode generation onventions . . . . . . . . . . . . . . . . . 178
ode, mixed with de larations . . . . . . . . . . . . . . . . 217
ommand options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
omments, C++ style . . . . . . . . . . . . . . . . . . . . . . . . 232
ommon attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
omparison of signed and unsigned values, warning
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
ompiler bugs, reporting . . . . . . . . . . . . . . . . . . . . 381
ompiler ompared to C++ prepro essor . . . . . . . . . 3
ompiler options, C++ . . . . . . . . . . . . . . . . . . . . . . . . 24
ompiler options, Obje tive-C and Obje tive-C++
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
ompiler version, spe ifying . . . . . . . . . . . . . . . . . . 108
COMPILER_PATH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
omplex onjugation . . . . . . . . . . . . . . . . . . . . . . . . 209
omplex numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
ompound literals . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
omputed gotos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
onditional expressions, extensions . . . . . . . . . . . 208
on i ting types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
onj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
onjf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
onjl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
onst applied to fun tion . . . . . . . . . . . . . . . . . . . 217
onst fun tion attribute . . . . . . . . . . . . . . . . . . . . . 218
onstants in onstraints . . . . . . . . . . . . . . . . . . . . . 251
onstraint modier hara ters . . . . . . . . . . . . . . . . 253
onstraint, mat hing . . . . . . . . . . . . . . . . . . . . . . . . 252
onstraints, asm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
onstraints, ma hine spe i . . . . . . . . . . . . . . . . . 254
onstru ting alls . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
onstru tor expressions . . . . . . . . . . . . . . . . . . . . . . 214
onstru tor fun tion attribute . . . . . . . . . . . . . . 218
ontributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
opysign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
opysignf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
opysignl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
ore dump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
osf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
osh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
oshf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
oshl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
osl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
eil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
eilf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
eill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
exp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
expf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
expl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

434

osf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
osh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
oshf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
oshl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
osl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CPATH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CPLUS_INCLUDE_PATH . . . . . . . . . . . . . . . . . . . . . . . .
pow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
powf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
powl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
proj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
projf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
projl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
realf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
reall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CRIS Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ross ompiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

sin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
sinf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
sinh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
sinhf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
sinhl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
sinl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
sqrt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
sqrtf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
sqrtl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tanf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tanh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tanhf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tanhl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tanl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Using the GNU Compiler Colle tion (GCC)

272
272
272
272
272
186
186
272
272
272
272
272
272
272
272
272
114
108
272
272
272
272
272
272
272
272
272
272
272
272
272
272
272

Darwin options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

d gettext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
deallo ating variable length arrays . . . . . . . . . . . 212
debugging information options . . . . . . . . . . . . . . . . 49
de laration s ope . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
de larations inside expressions . . . . . . . . . . . . . . . 201
de larations, mixed with ode . . . . . . . . . . . . . . . . 217
de laring attributes of fun tions . . . . . . . . . . . . . 217
de laring stati data in C++ . . . . . . . . . . . . . . . . . 370
dening stati data in C++ . . . . . . . . . . . . . . . . . . 370
dependen ies for make as output . . . . . . . . . . . . . 187
dependen ies, make . . . . . . . . . . . . . . . . . . . . . . . . . . 90
DEPENDENCIES_OUTPUT . . . . . . . . . . . . . . . . . . . . . . . 187
dependent name lookup . . . . . . . . . . . . . . . . . . . . . 371
depre ated attribute . . . . . . . . . . . . . . . . . . . . . . . 234
depre ated attribute. . . . . . . . . . . . . . . . . . . . . . . . 218
designated initializers . . . . . . . . . . . . . . . . . . . . . . . 215
designator lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
designators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
destru tor fun tion attribute . . . . . . . . . . . . . . . 218
dgettext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
diagnosti messages . . . . . . . . . . . . . . . . . . . . . . . . . . 34

diale t options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
digits in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . 252
dire tory options . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
dollar signs in identier names . . . . . . . . . . . . . . . 232
double-word arithmeti . . . . . . . . . . . . . . . . . . . . . . 209
downward funargs . . . . . . . . . . . . . . . . . . . . . . . . . . 204
drem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
dremf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
dreml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

`E' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

early lobber operand . . . . . . . . . . . . . . . . . . . . . . . . 253
eight bit data on the H8/300, H8/300H, and H8S
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
empty stru tures . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
environment variables . . . . . . . . . . . . . . . . . . . . . . . 184
erf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
erf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
erf f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
erf l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
erff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
erfl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
error messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
es aped newlines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
ex lamation point . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
exp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
exp10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
exp10f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
exp10l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
exp2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
exp2f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
exp2l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
expf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
expl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
expli it register variables . . . . . . . . . . . . . . . . . . . . 266
expm1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
expm1f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
expm1l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
expressions ontaining statements . . . . . . . . . . . . 201
expressions, onstru tor . . . . . . . . . . . . . . . . . . . . . 214
extended asm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
extensible onstraints . . . . . . . . . . . . . . . . . . . . . . . 252
extensions, ?: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
extensions, C language . . . . . . . . . . . . . . . . . . . . . . 201
extensions, C++ language . . . . . . . . . . . . . . . . . . . . 335
external de laration s ope . . . . . . . . . . . . . . . . . . . 366

`F' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

fabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fabsf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fabsl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fatal signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
fdim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Chapter 13: Keyword Index

fdimf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fdiml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

FDL, GNU Free Do umentation Li ense . . . . . . 397

ffs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
le name sux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
le names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
exible array members . . . . . . . . . . . . . . . . . . . . . . 210
float as fun tion value type . . . . . . . . . . . . . . . . . 367
oating point pre ision . . . . . . . . . . . . . . . . . . 76, 370
floor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
floorf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
floorl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fmaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fmal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fmax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fmaxf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fmaxl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fminf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fminl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fmod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fmodf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fmodl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
format fun tion attribute . . . . . . . . . . . . . . . . . . . 220
format_arg fun tion attribute . . . . . . . . . . . . . . . 221
Fortran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
forwarding alls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
fprintf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fprintf_unlo ked . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fputs_unlo ked . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
freestanding environment . . . . . . . . . . . . . . . . . . . . . . 5
freestanding implementation . . . . . . . . . . . . . . . . . . . 5
frexp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
frexpf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
frexpl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
FRV Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
fs anf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
fs anf, and onstant strings . . . . . . . . . . . . . . . . . 366
fun tion addressability on the M32R/D . . . . . . . 223
fun tion attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 217
fun tion pointers, arithmeti . . . . . . . . . . . . . . . . . 214
fun tion prototype de larations . . . . . . . . . . . . . . 231
fun tion without a prologue/epilogue ode . . . . 223
fun tion, size of pointer to . . . . . . . . . . . . . . . . . . . 214
fun tions alled via pointer on the RS/6000 and
PowerPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
fun tions in arbitrary se tions . . . . . . . . . . . . . . . 217
fun tions that are passed arguments in registers on
the 386 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217, 225
fun tions that behave like mallo . . . . . . . . . . . . 217
fun tions that do not pop the argument sta k on
the 386 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
fun tions that do pop the argument sta k on the
386 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
fun tions that have no side ee ts . . . . . . . . . . . . 217
fun tions that never return . . . . . . . . . . . . . . . . . . 217

435

fun tions that pop the argument sta k on the 386

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217, 220, 226
fun tions whi h do not handle memory bank
swit hing on 68HC11/68HC12 . . . . . . . . . . . 223
fun tions whi h handle memory bank swit hing
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
fun tions with non-null pointer arguments . . . . 217
fun tions with printf, s anf, strftime or
strfmon style arguments . . . . . . . . . . . . . . . . 217

`g' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

`G' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
g++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
G++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
gamma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
gammaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
gammal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
GCC ommand options . . . . . . . . . . . . . . . . . . . . . . . 7
GCC_EXEC_PREFIX . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
g _stru t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
g _stru t attribute . . . . . . . . . . . . . . . . . . . . . . . 237
gettext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
global oset table . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
global register after longjmp . . . . . . . . . . . . . . . . . 267
global register variables . . . . . . . . . . . . . . . . . . . . . 266
GNAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
GNU C Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
GNU Compiler Colle tion . . . . . . . . . . . . . . . . . . . . . 3
goto with omputed label . . . . . . . . . . . . . . . . . . . 203
gp-relative referen es (MIPS) . . . . . . . . . . . . . . . . 147
gprof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
grouping options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

`H' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

hardware models and ongurations, spe ifying
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
hex oats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
hosted environment . . . . . . . . . . . . . . . . . . . . . . . . 5, 23
hosted implementation . . . . . . . . . . . . . . . . . . . . . . . . 5
HPPA Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
hypot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
hypotf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
hypotl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

`i' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`I' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i386 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IA-64 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IBM RS/6000 and PowerPC Options . . . . . . . . .
identier names, dollar signs in . . . . . . . . . . . . . .
identiers, names in assembler ode . . . . . . . . . .

251
251
130
137
155
232
265

436

ilogb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ilogbf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ilogbl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
imaxabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

implementation-dened behavior, C language

Using the GNU Compiler Colle tion (GCC)

272
272
272
272

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
implied #pragma implementation . . . . . . . . . . . . 338
in ompatibilities of GCC . . . . . . . . . . . . . . . . . . . . 365
in rement operators . . . . . . . . . . . . . . . . . . . . . . . . . 381
index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
indire t alls on ARM . . . . . . . . . . . . . . . . . . . . . . . 222
init priority attribute . . . . . . . . . . . . . . . . . . . . . . . 341
initializations in expressions . . . . . . . . . . . . . . . . . 214
initializers with labeled elements . . . . . . . . . . . . . 215
initializers, non- onstant . . . . . . . . . . . . . . . . . . . . 214
inline automati for C++ member fns . . . . . . . . 243
inline fun tions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
inline fun tions, omission of . . . . . . . . . . . . . . . . . 243
inlining and C++ pragmas . . . . . . . . . . . . . . . . . . . 339
installation trouble . . . . . . . . . . . . . . . . . . . . . . . . . 363
integrating fun tion ode . . . . . . . . . . . . . . . . . . . . 242
Intel 386 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
interfa e and implementation headers, C++ . . . 337
intermediate C version, nonexistent . . . . . . . . . . . . 3
interrupt handler fun tions . . . . . . . . . . . . . . . . . . 222
interrupt handler fun tions on the m68k, H8/300
and SH pro essors . . . . . . . . . . . . . . . . . . . . . . 222
introdu tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
invalid assembly ode . . . . . . . . . . . . . . . . . . . . . . . 381
invalid input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
invoking g++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
isalnum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
isalpha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
isas ii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
isblank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
is ntrl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
isdigit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
isgraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
islower . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
ISO 9899 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
ISO C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
ISO C standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
ISO C90 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
ISO C94 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
ISO C95 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
ISO C99 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
ISO C9X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
ISO support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
ISO/IEC 9899 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
isprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
ispun t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
isspa e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
isupper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
iswalnum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
iswalpha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
iswblank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
isw ntrl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
iswdigit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

iswgraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iswlower . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iswprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iswpun t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iswspa e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iswupper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iswxdigit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
isxdigit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

272
272
272
272
272
272
272
272

272
272
272
272
272
272
Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
java interfa e attribute . . . . . . . . . . . . . . . . . . . . . . 342
jn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
jnf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
jnl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
j0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
j0f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
j0l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
j1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
j1f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
j1l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

keywords, alternate . . . . . . . . . . . . . . . . . . . . . . . . . 268

known auses of trouble . . . . . . . . . . . . . . . . . . . . . 363

labeled elements in initializers . . . . . . . . . . . . . . . 215

labels as values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
labs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
LANG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185, 186
language diale t options . . . . . . . . . . . . . . . . . . . . . . 20
LC_ALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
LC_CTYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
LC_MESSAGES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
ldexp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
ldexpf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
ldexpl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
length-zero arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
lgamma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
lgammaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
lgammal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
LIBRARY_PATH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
link options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
LL integer sux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
llabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
llrint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
llrintf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
llrintl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
llround . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
llroundf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
llroundl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
load address instru tion . . . . . . . . . . . . . . . . . . . . . 252
lo al labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Chapter 13: Keyword Index

lo al variables in ma ros . . . . . . . . . . . . . . . . . . . .
lo al variables, spe ifying registers . . . . . . . . . . .
lo ale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
lo ale denition . . . . . . . . . . . . . . . . . . . . . . . . . . . .

207
267
185
186
log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
log10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
log10f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
log10l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
log1p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
log1pf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
log1pl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
log2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
log2f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
log2l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
logb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
logbf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
logbl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
logf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
logl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
long long data types . . . . . . . . . . . . . . . . . . . . . . . 209
longjmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
longjmp in ompatibilities . . . . . . . . . . . . . . . . . . . . 366
longjmp warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
lrint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
lrintf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
lrintl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
lround . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
lroundf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
lroundl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

`m' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

M32R/D options . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
M680x0 options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
M68h 1x options . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
ma hine dependent options . . . . . . . . . . . . . . . . . . 108
ma hine spe i onstraints . . . . . . . . . . . . . . . . . 254
ma ro with variable arguments . . . . . . . . . . . . . . 212
ma ros ontaining asm . . . . . . . . . . . . . . . . . . . . . . 247
ma ros, inline alternative . . . . . . . . . . . . . . . . . . . . 242
ma ros, lo al labels . . . . . . . . . . . . . . . . . . . . . . . . . 202
ma ros, lo al variables in . . . . . . . . . . . . . . . . . . . . 207
ma ros, statements in expressions . . . . . . . . . . . . 201
ma ros, types of arguments . . . . . . . . . . . . . . . . . . 207
make . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
mallo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
mallo attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
mat hing onstraint . . . . . . . . . . . . . . . . . . . . . . . . . 252
MCore options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
member fns, automati ally inline . . . . . . . . . . . 243
mem mp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
mem py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
memory referen es in onstraints . . . . . . . . . . . . . 250
memp py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
memset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Mer ury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
message formatting . . . . . . . . . . . . . . . . . . . . . . . . . . 34

437

messages, warning . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
messages, warning and error . . . . . . . . . . . . . . . . . 378
middle-operands, omitted . . . . . . . . . . . . . . . . . . . 208
MIPS options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
misunderstandings in C++ . . . . . . . . . . . . . . . . . . . 370
mixed de larations and ode . . . . . . . . . . . . . . . . . 217
mktemp, and onstant strings . . . . . . . . . . . . . . . . . 365
MMIX Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
MN10300 options . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
mode attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
modf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
modff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
modfl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
modiers in onstraints . . . . . . . . . . . . . . . . . . . . . 253
ms_stru t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
ms_stru t attribute . . . . . . . . . . . . . . . . . . . . . . . . 237
mud ap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
multiple alternative onstraints . . . . . . . . . . . . . . 252
multipre ision arithmeti . . . . . . . . . . . . . . . . . . . . 209

`n' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

names used in assembler ode . . . . . . . . . . . . . . . . 265
naming onvention, implementation headers . . 338
nearbyint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
nearbyintf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
nearbyintl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
nested fun tions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
newlines (es aped) . . . . . . . . . . . . . . . . . . . . . . . . . . 213
nextafter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
nextafterf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
nextafterl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
nexttoward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
nexttowardf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
nexttowardl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
no_instrument_fun tion fun tion attribute . . 224
no ommon attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 234
noinline fun tion attribute . . . . . . . . . . . . . . . . . 224
non- onstant initializers . . . . . . . . . . . . . . . . . . . . . 214
non-stati inline fun tion . . . . . . . . . . . . . . . . . . . . 243
nonnull fun tion attribute . . . . . . . . . . . . . . . . . . 224
noreturn fun tion attribute . . . . . . . . . . . . . . . . . 224
nothrow fun tion attribute . . . . . . . . . . . . . . . . . . 225
NS32K options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

`o' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

OBJC_INCLUDE_PATH . . . . . . . . . . . . . . . . . . . . . . . . . 186
Obje tive-C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 6
Obje tive-C and Obje tive-C++ options, ommand
line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Obje tive-C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 6
osettable address . . . . . . . . . . . . . . . . . . . . . . . . . . 250
old-style fun tion denitions . . . . . . . . . . . . . . . . . 231
omitted middle-operands . . . . . . . . . . . . . . . . . . . . 208
open oding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

438

Using the GNU Compiler Colle tion (GCC)

operand onstraints, asm . . . . . . . . . . . . . . . . . . . . 250

optimize options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
options to ontrol diagnosti s formatting . . . . . . 34
options to ontrol warnings . . . . . . . . . . . . . . . . . . . 34
options, C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
options, ode generation . . . . . . . . . . . . . . . . . . . . . 178
options, debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
options, diale t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
options, dire tory sear h . . . . . . . . . . . . . . . . . . . . 100
options, GCC ommand . . . . . . . . . . . . . . . . . . . . . . . 7
options, grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
options, linking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
options, Obje tive-C and Obje tive-C++ . . . . . . . 31
options, optimization . . . . . . . . . . . . . . . . . . . . . . . . . 61
options, order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
options, prepro essor . . . . . . . . . . . . . . . . . . . . . . . . . 87
order of evaluation, side ee ts . . . . . . . . . . . . . . 378
order of options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
other register onstraints . . . . . . . . . . . . . . . . . . . . 252
output le option . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
overloaded virtual fn, warning . . . . . . . . . . . . . . . . 30

pragmas in C++, ee t on inlining . . . . . . . . . . . . 339

pragmas, interfa e and implementation . . . . . . . 337
pragmas, warning of unknown . . . . . . . . . . . . . . . . 42
pre ompiled headers . . . . . . . . . . . . . . . . . . . . . . . . 187
prepro essing numbers . . . . . . . . . . . . . . . . . . . . . . 368
prepro essing tokens . . . . . . . . . . . . . . . . . . . . . . . . 368
prepro essor options . . . . . . . . . . . . . . . . . . . . . . . . . 87
printf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
printf_unlo ked . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
prof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
promotion of formal parameters . . . . . . . . . . . . . . 231
pure fun tion attribute . . . . . . . . . . . . . . . . . . . . . . 225
push address instru tion . . . . . . . . . . . . . . . . . . . . . 252
put har . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
puts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

`p' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

pa ked attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
parameter forward de laration . . . . . . . . . . . . . . . 212
parameters, aliased . . . . . . . . . . . . . . . . . . . . . . . . . 183
Pas al . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
PDP-11 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
PIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
pmf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
pointer arguments . . . . . . . . . . . . . . . . . . . . . . . . . . 218
pointer to member fun tion . . . . . . . . . . . . . . . . . . 341
portions of temporary obje ts, pointers to . . . . 372
pow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
pow10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
pow10f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
pow10l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
PowerPC options . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
powf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
powl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
pragma, align . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
pragma, extern prex . . . . . . . . . . . . . . . . . . . . . . . 329
pragma, ni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
pragma, init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
pragma, long alls . . . . . . . . . . . . . . . . . . . . . . . . . . 327
pragma, long alls o . . . . . . . . . . . . . . . . . . . . . . . 327
pragma, long all . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
pragma, mark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
pragma, no long alls . . . . . . . . . . . . . . . . . . . . . . . 327
pragma, options align . . . . . . . . . . . . . . . . . . . . . . . 328
pragma, reason for not using . . . . . . . . . . . . . . . . 228
pragma, redene extname . . . . . . . . . . . . . . . . . . . 329
pragma, segment . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
pragma, unused . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
pragma, weak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

qsort, and global register variables

. . . . . . . . . . 267
question mark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

`r' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ranges in ase statements . . . . . . . . . . . . . . . . . . . .
read-only strings . . . . . . . . . . . . . . . . . . . . . . . . . . . .
register variable after longjmp . . . . . . . . . . . . . . .
registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
registers for lo al variables . . . . . . . . . . . . . . . . . .
registers in onstraints . . . . . . . . . . . . . . . . . . . . . .
registers, global allo ation . . . . . . . . . . . . . . . . . . .
registers, global variables in . . . . . . . . . . . . . . . . .
regparm attribute . . . . . . . . . . . . . . . . . . . . . . . . . . .
relo ation trun ated to t (MIPS) . . . . . . . . . . .

251
216
365
267
244
267
251
266
266
225
146
remainder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
remainderf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
remainderl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
remquo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
remquof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
remquol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
reordering, warning . . . . . . . . . . . . . . . . . . . . . . . . . . 29
reporting bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
rest argument (in ma ro) . . . . . . . . . . . . . . . . . . . . 212
restri ted pointers . . . . . . . . . . . . . . . . . . . . . . . . . . 336
restri ted referen es . . . . . . . . . . . . . . . . . . . . . . . . . 336
restri ted this pointer . . . . . . . . . . . . . . . . . . . . . . . 336
rindex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
rint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
rintf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
rintl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
round . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
roundf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
roundl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
RS/6000 and PowerPC Options . . . . . . . . . . . . . . 155
RTTI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
run-time options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Chapter 13: Keyword Index

`s' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

S/390 and zSeries Options . . . . . . . . . . . . . . . . . . . 165
save all registers on the H8/300, H8/300H, and
H8S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
s alb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
s albf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
s albl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
s albln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
s alblnf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
s albn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
s albnf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
s anf, and onstant strings . . . . . . . . . . . . . . . . . . 366
s anfnl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
s ope of a variable length array . . . . . . . . . . . . . . 212
s ope of de laration . . . . . . . . . . . . . . . . . . . . . . . . . 369
s ope of external de larations . . . . . . . . . . . . . . . . 366
sear h path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
se tion fun tion attribute . . . . . . . . . . . . . . . . . . 225
se tion variable attribute . . . . . . . . . . . . . . . . . . . 235
sentinel fun tion attribute . . . . . . . . . . . . . . . . . 226
setjmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
setjmp in ompatibilities . . . . . . . . . . . . . . . . . . . . . 366
shared strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
shared variable attribute . . . . . . . . . . . . . . . . . . . . 236
side ee t in ?: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
side ee ts, ma ro argument . . . . . . . . . . . . . . . . . 201
side ee ts, order of evaluation . . . . . . . . . . . . . . 378
signal handler fun tions on the AVR pro essors
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
signbit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
signbitf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
signbitl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
signed and unsigned values, omparison warning
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
signifi and . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
signifi andf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
signifi andl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
simple onstraints . . . . . . . . . . . . . . . . . . . . . . . . . . 250
sin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
sin os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
sin osf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
sin osl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
sinf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
sinh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
sinhf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
sinhl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
sinl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
sizeof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
smaller data referen es . . . . . . . . . . . . . . . . . . . . . . 140
smaller data referen es (MIPS) . . . . . . . . . . . . . . 147
smaller data referen es (PowerPC) . . . . . . . . . . . 164
snprintf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
SPARC options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Spe Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
spe ied registers . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
spe ifying ompiler version and target ma hine
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

439

spe ifying hardware ong . . . . . . . . . . . . . . . . . . .

spe ifying ma hine version . . . . . . . . . . . . . . . . . . .
spe ifying registers for lo al variables . . . . . . . . .
speed of ompilation . . . . . . . . . . . . . . . . . . . . . . . .

108
108
267
187
sprintf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
sqrt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
sqrtf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
sqrtl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
ss anf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
ss anf, and onstant strings . . . . . . . . . . . . . . . . . 366
statements inside expressions . . . . . . . . . . . . . . . . 201
stati data in C++, de laring and dening . . . . . 370
stp py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
str at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
str hr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
str mp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
str py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
str spn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
strdup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
strfmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
strftime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
string onstants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
strlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
strn at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
strn mp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
strn py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
strpbrk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
strr hr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
strspn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
strstr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
stru t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
stru tures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
stru tures, onstru tor expression . . . . . . . . . . . . 214
submodel options . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
subs ripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
subs ripting and fun tion values . . . . . . . . . . . . . 213
suxes for C++ sour e . . . . . . . . . . . . . . . . . . . . . . . 20
SUNPRO_DEPENDENCIES . . . . . . . . . . . . . . . . . . . . . . . 187
suppressing warnings . . . . . . . . . . . . . . . . . . . . . . . . . 34
surprises in C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
syntax he king . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
system headers, warnings from . . . . . . . . . . . . . . . . 43

272
272
272
272
272
272
target ma hine, spe ifying . . . . . . . . . . . . . . . . . . . 108
target options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
TC1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
TC2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Te hni al Corrigenda . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Te hni al Corrigendum 1 . . . . . . . . . . . . . . . . . . . . . . 5
Te hni al Corrigendum 2 . . . . . . . . . . . . . . . . . . . . . . 5
tan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tanf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tanh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tanhf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tanhl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tanl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

440

Using the GNU Compiler Colle tion (GCC)

template instantiation . . . . . . . . . . . . . . . . . . . . . . . 339

temporaries, lifetime of . . . . . . . . . . . . . . . . . . . . . . 372
tgamma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
tgammaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
tgammal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Thread-Lo al Storage . . . . . . . . . . . . . . . . . . . . . . . 331
thunks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
tiny data se tion on the H8/300H and H8S . . . 226
TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
tls_model attribute . . . . . . . . . . . . . . . . . . . . . . . . 236
TMPDIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
TMS320C3x/C4x Options . . . . . . . . . . . . . . . . . . . 173
toas ii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
tolower . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
toupper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
towlower . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
towupper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
traditional C language . . . . . . . . . . . . . . . . . . . . . . . 23
treelang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 6
trun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
trun f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
trun l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
two-stage name lookup . . . . . . . . . . . . . . . . . . . . . . 371
type alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
type attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
type info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
typedef names as fun tion parameters . . . . . . . . 367
typeof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

variadi ma ros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

VAX alling onvention . . . . . . . . . . . . . . . . . . . . . 365
VAX options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
vfprintf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
vfs anf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
visibility attribute . . . . . . . . . . . . . . . . . . . . . . . 227
VLAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
void pointers, arithmeti . . . . . . . . . . . . . . . . . . . . 214
void, size of pointer to . . . . . . . . . . . . . . . . . . . . . . 214
volatile a ess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
volatile applied to fun tion . . . . . . . . . . . . . . . . 217
volatile read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
volatile write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
vprintf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
vs anf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
vsnprintf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
vsprintf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
vss anf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
vtable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

ULL integer sux . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Ultrix alling onvention . . . . . . . . . . . . . . . . . . . . 365

undened behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 381
undened fun tion value . . . . . . . . . . . . . . . . . . . . 381
unders ores in variables in ma ros . . . . . . . . . . . . 207
union . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
union, asting to a . . . . . . . . . . . . . . . . . . . . . . . . . . 216
unions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
unknown pragmas, warning . . . . . . . . . . . . . . . . . . . 42
unresolved referen es and `-nodefaultlibs' . . . . 98
unresolved referen es and `-nostdlib' . . . . . . . . . 98
unused attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
used attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

`V' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . .
V850 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vague linkage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
value after longjmp . . . . . . . . . . . . . . . . . . . . . . . . .
variable addressability on the IA-64 . . . . . . . . . .
variable addressability on the M32R/D . . . . . . .
variable alignment . . . . . . . . . . . . . . . . . . . . . . . . . .
variable attributes . . . . . . . . . . . . . . . . . . . . . . . . . .
variable number of arguments . . . . . . . . . . . . . . .
variable-length array s ope . . . . . . . . . . . . . . . . . .
variable-length arrays . . . . . . . . . . . . . . . . . . . . . . .
variables in spe ied registers . . . . . . . . . . . . . . . .
variables, lo al, in ma ros . . . . . . . . . . . . . . . . . . .
zSeries options . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

251
175
336
267
223
237
233
233
212
212
211
266
207
178

warn_unused_result attribute . . . . . . . . . . . . . . . 227

warning for omparison of signed and unsigned

values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
warning for overloaded virtual fn . . . . . . . . . . . . . . 30
warning for reordering of member initializers . . . 29
warning for unknown pragmas . . . . . . . . . . . . . . . . 42
warning messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
warnings from system headers . . . . . . . . . . . . . . . . 43
warnings vs errors . . . . . . . . . . . . . . . . . . . . . . . . . . 378
weak attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
whitespa e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

`X' in onstraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

X3.159-1989 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
x86-64 options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
x86-64 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Xstormy16 Options . . . . . . . . . . . . . . . . . . . . . . . . . 176
Xtensa Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

y0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
y0f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
y0l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
y1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
y1f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
y1l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
yn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ynf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ynl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

272
272
272
272
272
272
272
272
272

zero-length arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

zero-size stru tures . . . . . . . . . . . . . . . . . . . . . . . . . 211