1This is doc/gccint.info, produced by makeinfo version 4.12 from 2/space/rguenther/gcc-4.5.4/gcc-4.5.4/gcc/doc/gccint.texi. 3 4Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 51999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2010 Free 6Software Foundation, Inc. 7 8 Permission is granted to copy, distribute and/or modify this document 9under the terms of the GNU Free Documentation License, Version 1.2 or 10any later version published by the Free Software Foundation; with the 11Invariant Sections being "Funding Free Software", the Front-Cover Texts 12being (a) (see below), and with the Back-Cover Texts being (b) (see 13below). A copy of the license is included in the section entitled "GNU 14Free Documentation License". 15 16 (a) The FSF's Front-Cover Text is: 17 18 A GNU Manual 19 20 (b) The FSF's Back-Cover Text is: 21 22 You have freedom to copy and modify this GNU Manual, like GNU 23software. Copies published by the Free Software Foundation raise 24funds for GNU development. 25 26INFO-DIR-SECTION Software development 27START-INFO-DIR-ENTRY 28* gccint: (gccint). Internals of the GNU Compiler Collection. 29END-INFO-DIR-ENTRY 30 This file documents the internals of the GNU compilers. 31 32 Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 331999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2010 Free 34Software Foundation, Inc. 35 36 Permission is granted to copy, distribute and/or modify this document 37under the terms of the GNU Free Documentation License, Version 1.2 or 38any later version published by the Free Software Foundation; with the 39Invariant Sections being "Funding Free Software", the Front-Cover Texts 40being (a) (see below), and with the Back-Cover Texts being (b) (see 41below). A copy of the license is included in the section entitled "GNU 42Free Documentation License". 43 44 (a) The FSF's Front-Cover Text is: 45 46 A GNU Manual 47 48 (b) The FSF's Back-Cover Text is: 49 50 You have freedom to copy and modify this GNU Manual, like GNU 51software. Copies published by the Free Software Foundation raise 52funds for GNU development. 53 54 55 56File: gccint.info, Node: Top, Next: Contributing, Up: (DIR) 57 58Introduction 59************ 60 61This manual documents the internals of the GNU compilers, including how 62to port them to new targets and some information about how to write 63front ends for new languages. It corresponds to the compilers 64(GCC) version 4.5.4. The use of the GNU compilers is documented in a 65separate manual. *Note Introduction: (gcc)Top. 66 67 This manual is mainly a reference manual rather than a tutorial. It 68discusses how to contribute to GCC (*note Contributing::), the 69characteristics of the machines supported by GCC as hosts and targets 70(*note Portability::), how GCC relates to the ABIs on such systems 71(*note Interface::), and the characteristics of the languages for which 72GCC front ends are written (*note Languages::). It then describes the 73GCC source tree structure and build system, some of the interfaces to 74GCC front ends, and how support for a target system is implemented in 75GCC. 76 77 Additional tutorial information is linked to from 78`http://gcc.gnu.org/readings.html'. 79 80* Menu: 81 82* Contributing:: How to contribute to testing and developing GCC. 83* Portability:: Goals of GCC's portability features. 84* Interface:: Function-call interface of GCC output. 85* Libgcc:: Low-level runtime library used by GCC. 86* Languages:: Languages for which GCC front ends are written. 87* Source Tree:: GCC source tree structure and build system. 88* Testsuites:: GCC testsuites. 89* Options:: Option specification files. 90* Passes:: Order of passes, what they do, and what each file is for. 91* GENERIC:: Language-independent representation generated by Front Ends 92* GIMPLE:: Tuple representation used by Tree SSA optimizers 93* Tree SSA:: Analysis and optimization of GIMPLE 94* RTL:: Machine-dependent low-level intermediate representation. 95* Control Flow:: Maintaining and manipulating the control flow graph. 96* Loop Analysis and Representation:: Analysis and representation of loops 97* Machine Desc:: How to write machine description instruction patterns. 98* Target Macros:: How to write the machine description C macros and functions. 99* Host Config:: Writing the `xm-MACHINE.h' file. 100* Fragments:: Writing the `t-TARGET' and `x-HOST' files. 101* Collect2:: How `collect2' works; how it finds `ld'. 102* Header Dirs:: Understanding the standard header file directories. 103* Type Information:: GCC's memory management; generating type information. 104* Plugins:: Extending the compiler with plugins. 105 106* Funding:: How to help assure funding for free software. 107* GNU Project:: The GNU Project and GNU/Linux. 108 109* Copying:: GNU General Public License says 110 how you can copy and share GCC. 111* GNU Free Documentation License:: How you can copy and share this manual. 112* Contributors:: People who have contributed to GCC. 113 114* Option Index:: Index to command line options. 115* Concept Index:: Index of concepts and symbol names. 116 117 118File: gccint.info, Node: Contributing, Next: Portability, Prev: Top, Up: Top 119 1201 Contributing to GCC Development 121********************************* 122 123If you would like to help pretest GCC releases to assure they work well, 124current development sources are available by SVN (see 125`http://gcc.gnu.org/svn.html'). Source and binary snapshots are also 126available for FTP; see `http://gcc.gnu.org/snapshots.html'. 127 128 If you would like to work on improvements to GCC, please read the 129advice at these URLs: 130 131 `http://gcc.gnu.org/contribute.html' 132 `http://gcc.gnu.org/contributewhy.html' 133 134for information on how to make useful contributions and avoid 135duplication of effort. Suggested projects are listed at 136`http://gcc.gnu.org/projects/'. 137 138 139File: gccint.info, Node: Portability, Next: Interface, Prev: Contributing, Up: Top 140 1412 GCC and Portability 142********************* 143 144GCC itself aims to be portable to any machine where `int' is at least a 14532-bit type. It aims to target machines with a flat (non-segmented) 146byte addressed data address space (the code address space can be 147separate). Target ABIs may have 8, 16, 32 or 64-bit `int' type. `char' 148can be wider than 8 bits. 149 150 GCC gets most of the information about the target machine from a 151machine description which gives an algebraic formula for each of the 152machine's instructions. This is a very clean way to describe the 153target. But when the compiler needs information that is difficult to 154express in this fashion, ad-hoc parameters have been defined for 155machine descriptions. The purpose of portability is to reduce the 156total work needed on the compiler; it was not of interest for its own 157sake. 158 159 GCC does not contain machine dependent code, but it does contain code 160that depends on machine parameters such as endianness (whether the most 161significant byte has the highest or lowest address of the bytes in a 162word) and the availability of autoincrement addressing. In the 163RTL-generation pass, it is often necessary to have multiple strategies 164for generating code for a particular kind of syntax tree, strategies 165that are usable for different combinations of parameters. Often, not 166all possible cases have been addressed, but only the common ones or 167only the ones that have been encountered. As a result, a new target 168may require additional strategies. You will know if this happens 169because the compiler will call `abort'. Fortunately, the new 170strategies can be added in a machine-independent fashion, and will 171affect only the target machines that need them. 172 173 174File: gccint.info, Node: Interface, Next: Libgcc, Prev: Portability, Up: Top 175 1763 Interfacing to GCC Output 177*************************** 178 179GCC is normally configured to use the same function calling convention 180normally in use on the target system. This is done with the 181machine-description macros described (*note Target Macros::). 182 183 However, returning of structure and union values is done differently on 184some target machines. As a result, functions compiled with PCC 185returning such types cannot be called from code compiled with GCC, and 186vice versa. This does not cause trouble often because few Unix library 187routines return structures or unions. 188 189 GCC code returns structures and unions that are 1, 2, 4 or 8 bytes 190long in the same registers used for `int' or `double' return values. 191(GCC typically allocates variables of such types in registers also.) 192Structures and unions of other sizes are returned by storing them into 193an address passed by the caller (usually in a register). The target 194hook `TARGET_STRUCT_VALUE_RTX' tells GCC where to pass this address. 195 196 By contrast, PCC on most target machines returns structures and unions 197of any size by copying the data into an area of static storage, and then 198returning the address of that storage as if it were a pointer value. 199The caller must copy the data from that memory area to the place where 200the value is wanted. This is slower than the method used by GCC, and 201fails to be reentrant. 202 203 On some target machines, such as RISC machines and the 80386, the 204standard system convention is to pass to the subroutine the address of 205where to return the value. On these machines, GCC has been configured 206to be compatible with the standard compiler, when this method is used. 207It may not be compatible for structures of 1, 2, 4 or 8 bytes. 208 209 GCC uses the system's standard convention for passing arguments. On 210some machines, the first few arguments are passed in registers; in 211others, all are passed on the stack. It would be possible to use 212registers for argument passing on any machine, and this would probably 213result in a significant speedup. But the result would be complete 214incompatibility with code that follows the standard convention. So this 215change is practical only if you are switching to GCC as the sole C 216compiler for the system. We may implement register argument passing on 217certain machines once we have a complete GNU system so that we can 218compile the libraries with GCC. 219 220 On some machines (particularly the SPARC), certain types of arguments 221are passed "by invisible reference". This means that the value is 222stored in memory, and the address of the memory location is passed to 223the subroutine. 224 225 If you use `longjmp', beware of automatic variables. ISO C says that 226automatic variables that are not declared `volatile' have undefined 227values after a `longjmp'. And this is all GCC promises to do, because 228it is very difficult to restore register variables correctly, and one 229of GCC's features is that it can put variables in registers without 230your asking it to. 231 232 233File: gccint.info, Node: Libgcc, Next: Languages, Prev: Interface, Up: Top 234 2354 The GCC low-level runtime library 236*********************************** 237 238GCC provides a low-level runtime library, `libgcc.a' or `libgcc_s.so.1' 239on some platforms. GCC generates calls to routines in this library 240automatically, whenever it needs to perform some operation that is too 241complicated to emit inline code for. 242 243 Most of the routines in `libgcc' handle arithmetic operations that the 244target processor cannot perform directly. This includes integer 245multiply and divide on some machines, and all floating-point and 246fixed-point operations on other machines. `libgcc' also includes 247routines for exception handling, and a handful of miscellaneous 248operations. 249 250 Some of these routines can be defined in mostly machine-independent C. 251Others must be hand-written in assembly language for each processor 252that needs them. 253 254 GCC will also generate calls to C library routines, such as `memcpy' 255and `memset', in some cases. The set of routines that GCC may possibly 256use is documented in *note Other Builtins: (gcc)Other Builtins. 257 258 These routines take arguments and return values of a specific machine 259mode, not a specific C type. *Note Machine Modes::, for an explanation 260of this concept. For illustrative purposes, in this chapter the 261floating point type `float' is assumed to correspond to `SFmode'; 262`double' to `DFmode'; and `long double' to both `TFmode' and `XFmode'. 263Similarly, the integer types `int' and `unsigned int' correspond to 264`SImode'; `long' and `unsigned long' to `DImode'; and `long long' and 265`unsigned long long' to `TImode'. 266 267* Menu: 268 269* Integer library routines:: 270* Soft float library routines:: 271* Decimal float library routines:: 272* Fixed-point fractional library routines:: 273* Exception handling routines:: 274* Miscellaneous routines:: 275 276 277File: gccint.info, Node: Integer library routines, Next: Soft float library routines, Up: Libgcc 278 2794.1 Routines for integer arithmetic 280=================================== 281 282The integer arithmetic routines are used on platforms that don't provide 283hardware support for arithmetic operations on some modes. 284 2854.1.1 Arithmetic functions 286-------------------------- 287 288 -- Runtime Function: int __ashlsi3 (int A, int B) 289 -- Runtime Function: long __ashldi3 (long A, int B) 290 -- Runtime Function: long long __ashlti3 (long long A, int B) 291 These functions return the result of shifting A left by B bits. 292 293 -- Runtime Function: int __ashrsi3 (int A, int B) 294 -- Runtime Function: long __ashrdi3 (long A, int B) 295 -- Runtime Function: long long __ashrti3 (long long A, int B) 296 These functions return the result of arithmetically shifting A 297 right by B bits. 298 299 -- Runtime Function: int __divsi3 (int A, int B) 300 -- Runtime Function: long __divdi3 (long A, long B) 301 -- Runtime Function: long long __divti3 (long long A, long long B) 302 These functions return the quotient of the signed division of A and 303 B. 304 305 -- Runtime Function: int __lshrsi3 (int A, int B) 306 -- Runtime Function: long __lshrdi3 (long A, int B) 307 -- Runtime Function: long long __lshrti3 (long long A, int B) 308 These functions return the result of logically shifting A right by 309 B bits. 310 311 -- Runtime Function: int __modsi3 (int A, int B) 312 -- Runtime Function: long __moddi3 (long A, long B) 313 -- Runtime Function: long long __modti3 (long long A, long long B) 314 These functions return the remainder of the signed division of A 315 and B. 316 317 -- Runtime Function: int __mulsi3 (int A, int B) 318 -- Runtime Function: long __muldi3 (long A, long B) 319 -- Runtime Function: long long __multi3 (long long A, long long B) 320 These functions return the product of A and B. 321 322 -- Runtime Function: long __negdi2 (long A) 323 -- Runtime Function: long long __negti2 (long long A) 324 These functions return the negation of A. 325 326 -- Runtime Function: unsigned int __udivsi3 (unsigned int A, unsigned 327 int B) 328 -- Runtime Function: unsigned long __udivdi3 (unsigned long A, 329 unsigned long B) 330 -- Runtime Function: unsigned long long __udivti3 (unsigned long long 331 A, unsigned long long B) 332 These functions return the quotient of the unsigned division of A 333 and B. 334 335 -- Runtime Function: unsigned long __udivmoddi3 (unsigned long A, 336 unsigned long B, unsigned long *C) 337 -- Runtime Function: unsigned long long __udivti3 (unsigned long long 338 A, unsigned long long B, unsigned long long *C) 339 These functions calculate both the quotient and remainder of the 340 unsigned division of A and B. The return value is the quotient, 341 and the remainder is placed in variable pointed to by C. 342 343 -- Runtime Function: unsigned int __umodsi3 (unsigned int A, unsigned 344 int B) 345 -- Runtime Function: unsigned long __umoddi3 (unsigned long A, 346 unsigned long B) 347 -- Runtime Function: unsigned long long __umodti3 (unsigned long long 348 A, unsigned long long B) 349 These functions return the remainder of the unsigned division of A 350 and B. 351 3524.1.2 Comparison functions 353-------------------------- 354 355The following functions implement integral comparisons. These functions 356implement a low-level compare, upon which the higher level comparison 357operators (such as less than and greater than or equal to) can be 358constructed. The returned values lie in the range zero to two, to allow 359the high-level operators to be implemented by testing the returned 360result using either signed or unsigned comparison. 361 362 -- Runtime Function: int __cmpdi2 (long A, long B) 363 -- Runtime Function: int __cmpti2 (long long A, long long B) 364 These functions perform a signed comparison of A and B. If A is 365 less than B, they return 0; if A is greater than B, they return 2; 366 and if A and B are equal they return 1. 367 368 -- Runtime Function: int __ucmpdi2 (unsigned long A, unsigned long B) 369 -- Runtime Function: int __ucmpti2 (unsigned long long A, unsigned 370 long long B) 371 These functions perform an unsigned comparison of A and B. If A 372 is less than B, they return 0; if A is greater than B, they return 373 2; and if A and B are equal they return 1. 374 3754.1.3 Trapping arithmetic functions 376----------------------------------- 377 378The following functions implement trapping arithmetic. These functions 379call the libc function `abort' upon signed arithmetic overflow. 380 381 -- Runtime Function: int __absvsi2 (int A) 382 -- Runtime Function: long __absvdi2 (long A) 383 These functions return the absolute value of A. 384 385 -- Runtime Function: int __addvsi3 (int A, int B) 386 -- Runtime Function: long __addvdi3 (long A, long B) 387 These functions return the sum of A and B; that is `A + B'. 388 389 -- Runtime Function: int __mulvsi3 (int A, int B) 390 -- Runtime Function: long __mulvdi3 (long A, long B) 391 The functions return the product of A and B; that is `A * B'. 392 393 -- Runtime Function: int __negvsi2 (int A) 394 -- Runtime Function: long __negvdi2 (long A) 395 These functions return the negation of A; that is `-A'. 396 397 -- Runtime Function: int __subvsi3 (int A, int B) 398 -- Runtime Function: long __subvdi3 (long A, long B) 399 These functions return the difference between B and A; that is `A 400 - B'. 401 4024.1.4 Bit operations 403-------------------- 404 405 -- Runtime Function: int __clzsi2 (int A) 406 -- Runtime Function: int __clzdi2 (long A) 407 -- Runtime Function: int __clzti2 (long long A) 408 These functions return the number of leading 0-bits in A, starting 409 at the most significant bit position. If A is zero, the result is 410 undefined. 411 412 -- Runtime Function: int __ctzsi2 (int A) 413 -- Runtime Function: int __ctzdi2 (long A) 414 -- Runtime Function: int __ctzti2 (long long A) 415 These functions return the number of trailing 0-bits in A, starting 416 at the least significant bit position. If A is zero, the result is 417 undefined. 418 419 -- Runtime Function: int __ffsdi2 (long A) 420 -- Runtime Function: int __ffsti2 (long long A) 421 These functions return the index of the least significant 1-bit in 422 A, or the value zero if A is zero. The least significant bit is 423 index one. 424 425 -- Runtime Function: int __paritysi2 (int A) 426 -- Runtime Function: int __paritydi2 (long A) 427 -- Runtime Function: int __parityti2 (long long A) 428 These functions return the value zero if the number of bits set in 429 A is even, and the value one otherwise. 430 431 -- Runtime Function: int __popcountsi2 (int A) 432 -- Runtime Function: int __popcountdi2 (long A) 433 -- Runtime Function: int __popcountti2 (long long A) 434 These functions return the number of bits set in A. 435 436 -- Runtime Function: int32_t __bswapsi2 (int32_t A) 437 -- Runtime Function: int64_t __bswapdi2 (int64_t A) 438 These functions return the A byteswapped. 439 440 441File: gccint.info, Node: Soft float library routines, Next: Decimal float library routines, Prev: Integer library routines, Up: Libgcc 442 4434.2 Routines for floating point emulation 444========================================= 445 446The software floating point library is used on machines which do not 447have hardware support for floating point. It is also used whenever 448`-msoft-float' is used to disable generation of floating point 449instructions. (Not all targets support this switch.) 450 451 For compatibility with other compilers, the floating point emulation 452routines can be renamed with the `DECLARE_LIBRARY_RENAMES' macro (*note 453Library Calls::). In this section, the default names are used. 454 455 Presently the library does not support `XFmode', which is used for 456`long double' on some architectures. 457 4584.2.1 Arithmetic functions 459-------------------------- 460 461 -- Runtime Function: float __addsf3 (float A, float B) 462 -- Runtime Function: double __adddf3 (double A, double B) 463 -- Runtime Function: long double __addtf3 (long double A, long double 464 B) 465 -- Runtime Function: long double __addxf3 (long double A, long double 466 B) 467 These functions return the sum of A and B. 468 469 -- Runtime Function: float __subsf3 (float A, float B) 470 -- Runtime Function: double __subdf3 (double A, double B) 471 -- Runtime Function: long double __subtf3 (long double A, long double 472 B) 473 -- Runtime Function: long double __subxf3 (long double A, long double 474 B) 475 These functions return the difference between B and A; that is, 476 A - B. 477 478 -- Runtime Function: float __mulsf3 (float A, float B) 479 -- Runtime Function: double __muldf3 (double A, double B) 480 -- Runtime Function: long double __multf3 (long double A, long double 481 B) 482 -- Runtime Function: long double __mulxf3 (long double A, long double 483 B) 484 These functions return the product of A and B. 485 486 -- Runtime Function: float __divsf3 (float A, float B) 487 -- Runtime Function: double __divdf3 (double A, double B) 488 -- Runtime Function: long double __divtf3 (long double A, long double 489 B) 490 -- Runtime Function: long double __divxf3 (long double A, long double 491 B) 492 These functions return the quotient of A and B; that is, A / B. 493 494 -- Runtime Function: float __negsf2 (float A) 495 -- Runtime Function: double __negdf2 (double A) 496 -- Runtime Function: long double __negtf2 (long double A) 497 -- Runtime Function: long double __negxf2 (long double A) 498 These functions return the negation of A. They simply flip the 499 sign bit, so they can produce negative zero and negative NaN. 500 5014.2.2 Conversion functions 502-------------------------- 503 504 -- Runtime Function: double __extendsfdf2 (float A) 505 -- Runtime Function: long double __extendsftf2 (float A) 506 -- Runtime Function: long double __extendsfxf2 (float A) 507 -- Runtime Function: long double __extenddftf2 (double A) 508 -- Runtime Function: long double __extenddfxf2 (double A) 509 These functions extend A to the wider mode of their return type. 510 511 -- Runtime Function: double __truncxfdf2 (long double A) 512 -- Runtime Function: double __trunctfdf2 (long double A) 513 -- Runtime Function: float __truncxfsf2 (long double A) 514 -- Runtime Function: float __trunctfsf2 (long double A) 515 -- Runtime Function: float __truncdfsf2 (double A) 516 These functions truncate A to the narrower mode of their return 517 type, rounding toward zero. 518 519 -- Runtime Function: int __fixsfsi (float A) 520 -- Runtime Function: int __fixdfsi (double A) 521 -- Runtime Function: int __fixtfsi (long double A) 522 -- Runtime Function: int __fixxfsi (long double A) 523 These functions convert A to a signed integer, rounding toward 524 zero. 525 526 -- Runtime Function: long __fixsfdi (float A) 527 -- Runtime Function: long __fixdfdi (double A) 528 -- Runtime Function: long __fixtfdi (long double A) 529 -- Runtime Function: long __fixxfdi (long double A) 530 These functions convert A to a signed long, rounding toward zero. 531 532 -- Runtime Function: long long __fixsfti (float A) 533 -- Runtime Function: long long __fixdfti (double A) 534 -- Runtime Function: long long __fixtfti (long double A) 535 -- Runtime Function: long long __fixxfti (long double A) 536 These functions convert A to a signed long long, rounding toward 537 zero. 538 539 -- Runtime Function: unsigned int __fixunssfsi (float A) 540 -- Runtime Function: unsigned int __fixunsdfsi (double A) 541 -- Runtime Function: unsigned int __fixunstfsi (long double A) 542 -- Runtime Function: unsigned int __fixunsxfsi (long double A) 543 These functions convert A to an unsigned integer, rounding toward 544 zero. Negative values all become zero. 545 546 -- Runtime Function: unsigned long __fixunssfdi (float A) 547 -- Runtime Function: unsigned long __fixunsdfdi (double A) 548 -- Runtime Function: unsigned long __fixunstfdi (long double A) 549 -- Runtime Function: unsigned long __fixunsxfdi (long double A) 550 These functions convert A to an unsigned long, rounding toward 551 zero. Negative values all become zero. 552 553 -- Runtime Function: unsigned long long __fixunssfti (float A) 554 -- Runtime Function: unsigned long long __fixunsdfti (double A) 555 -- Runtime Function: unsigned long long __fixunstfti (long double A) 556 -- Runtime Function: unsigned long long __fixunsxfti (long double A) 557 These functions convert A to an unsigned long long, rounding 558 toward zero. Negative values all become zero. 559 560 -- Runtime Function: float __floatsisf (int I) 561 -- Runtime Function: double __floatsidf (int I) 562 -- Runtime Function: long double __floatsitf (int I) 563 -- Runtime Function: long double __floatsixf (int I) 564 These functions convert I, a signed integer, to floating point. 565 566 -- Runtime Function: float __floatdisf (long I) 567 -- Runtime Function: double __floatdidf (long I) 568 -- Runtime Function: long double __floatditf (long I) 569 -- Runtime Function: long double __floatdixf (long I) 570 These functions convert I, a signed long, to floating point. 571 572 -- Runtime Function: float __floattisf (long long I) 573 -- Runtime Function: double __floattidf (long long I) 574 -- Runtime Function: long double __floattitf (long long I) 575 -- Runtime Function: long double __floattixf (long long I) 576 These functions convert I, a signed long long, to floating point. 577 578 -- Runtime Function: float __floatunsisf (unsigned int I) 579 -- Runtime Function: double __floatunsidf (unsigned int I) 580 -- Runtime Function: long double __floatunsitf (unsigned int I) 581 -- Runtime Function: long double __floatunsixf (unsigned int I) 582 These functions convert I, an unsigned integer, to floating point. 583 584 -- Runtime Function: float __floatundisf (unsigned long I) 585 -- Runtime Function: double __floatundidf (unsigned long I) 586 -- Runtime Function: long double __floatunditf (unsigned long I) 587 -- Runtime Function: long double __floatundixf (unsigned long I) 588 These functions convert I, an unsigned long, to floating point. 589 590 -- Runtime Function: float __floatuntisf (unsigned long long I) 591 -- Runtime Function: double __floatuntidf (unsigned long long I) 592 -- Runtime Function: long double __floatuntitf (unsigned long long I) 593 -- Runtime Function: long double __floatuntixf (unsigned long long I) 594 These functions convert I, an unsigned long long, to floating 595 point. 596 5974.2.3 Comparison functions 598-------------------------- 599 600There are two sets of basic comparison functions. 601 602 -- Runtime Function: int __cmpsf2 (float A, float B) 603 -- Runtime Function: int __cmpdf2 (double A, double B) 604 -- Runtime Function: int __cmptf2 (long double A, long double B) 605 These functions calculate a <=> b. That is, if A is less than B, 606 they return -1; if A is greater than B, they return 1; and if A 607 and B are equal they return 0. If either argument is NaN they 608 return 1, but you should not rely on this; if NaN is a 609 possibility, use one of the higher-level comparison functions. 610 611 -- Runtime Function: int __unordsf2 (float A, float B) 612 -- Runtime Function: int __unorddf2 (double A, double B) 613 -- Runtime Function: int __unordtf2 (long double A, long double B) 614 These functions return a nonzero value if either argument is NaN, 615 otherwise 0. 616 617 There is also a complete group of higher level functions which 618correspond directly to comparison operators. They implement the ISO C 619semantics for floating-point comparisons, taking NaN into account. Pay 620careful attention to the return values defined for each set. Under the 621hood, all of these routines are implemented as 622 623 if (__unordXf2 (a, b)) 624 return E; 625 return __cmpXf2 (a, b); 626 627where E is a constant chosen to give the proper behavior for NaN. 628Thus, the meaning of the return value is different for each set. Do 629not rely on this implementation; only the semantics documented below 630are guaranteed. 631 632 -- Runtime Function: int __eqsf2 (float A, float B) 633 -- Runtime Function: int __eqdf2 (double A, double B) 634 -- Runtime Function: int __eqtf2 (long double A, long double B) 635 These functions return zero if neither argument is NaN, and A and 636 B are equal. 637 638 -- Runtime Function: int __nesf2 (float A, float B) 639 -- Runtime Function: int __nedf2 (double A, double B) 640 -- Runtime Function: int __netf2 (long double A, long double B) 641 These functions return a nonzero value if either argument is NaN, 642 or if A and B are unequal. 643 644 -- Runtime Function: int __gesf2 (float A, float B) 645 -- Runtime Function: int __gedf2 (double A, double B) 646 -- Runtime Function: int __getf2 (long double A, long double B) 647 These functions return a value greater than or equal to zero if 648 neither argument is NaN, and A is greater than or equal to B. 649 650 -- Runtime Function: int __ltsf2 (float A, float B) 651 -- Runtime Function: int __ltdf2 (double A, double B) 652 -- Runtime Function: int __lttf2 (long double A, long double B) 653 These functions return a value less than zero if neither argument 654 is NaN, and A is strictly less than B. 655 656 -- Runtime Function: int __lesf2 (float A, float B) 657 -- Runtime Function: int __ledf2 (double A, double B) 658 -- Runtime Function: int __letf2 (long double A, long double B) 659 These functions return a value less than or equal to zero if 660 neither argument is NaN, and A is less than or equal to B. 661 662 -- Runtime Function: int __gtsf2 (float A, float B) 663 -- Runtime Function: int __gtdf2 (double A, double B) 664 -- Runtime Function: int __gttf2 (long double A, long double B) 665 These functions return a value greater than zero if neither 666 argument is NaN, and A is strictly greater than B. 667 6684.2.4 Other floating-point functions 669------------------------------------ 670 671 -- Runtime Function: float __powisf2 (float A, int B) 672 -- Runtime Function: double __powidf2 (double A, int B) 673 -- Runtime Function: long double __powitf2 (long double A, int B) 674 -- Runtime Function: long double __powixf2 (long double A, int B) 675 These functions convert raise A to the power B. 676 677 -- Runtime Function: complex float __mulsc3 (float A, float B, float 678 C, float D) 679 -- Runtime Function: complex double __muldc3 (double A, double B, 680 double C, double D) 681 -- Runtime Function: complex long double __multc3 (long double A, long 682 double B, long double C, long double D) 683 -- Runtime Function: complex long double __mulxc3 (long double A, long 684 double B, long double C, long double D) 685 These functions return the product of A + iB and C + iD, following 686 the rules of C99 Annex G. 687 688 -- Runtime Function: complex float __divsc3 (float A, float B, float 689 C, float D) 690 -- Runtime Function: complex double __divdc3 (double A, double B, 691 double C, double D) 692 -- Runtime Function: complex long double __divtc3 (long double A, long 693 double B, long double C, long double D) 694 -- Runtime Function: complex long double __divxc3 (long double A, long 695 double B, long double C, long double D) 696 These functions return the quotient of A + iB and C + iD (i.e., (A 697 + iB) / (C + iD)), following the rules of C99 Annex G. 698 699 700File: gccint.info, Node: Decimal float library routines, Next: Fixed-point fractional library routines, Prev: Soft float library routines, Up: Libgcc 701 7024.3 Routines for decimal floating point emulation 703================================================= 704 705The software decimal floating point library implements IEEE 754-2008 706decimal floating point arithmetic and is only activated on selected 707targets. 708 709 The software decimal floating point library supports either DPD 710(Densely Packed Decimal) or BID (Binary Integer Decimal) encoding as 711selected at configure time. 712 7134.3.1 Arithmetic functions 714-------------------------- 715 716 -- Runtime Function: _Decimal32 __dpd_addsd3 (_Decimal32 A, _Decimal32 717 B) 718 -- Runtime Function: _Decimal32 __bid_addsd3 (_Decimal32 A, _Decimal32 719 B) 720 -- Runtime Function: _Decimal64 __dpd_adddd3 (_Decimal64 A, _Decimal64 721 B) 722 -- Runtime Function: _Decimal64 __bid_adddd3 (_Decimal64 A, _Decimal64 723 B) 724 -- Runtime Function: _Decimal128 __dpd_addtd3 (_Decimal128 A, 725 _Decimal128 B) 726 -- Runtime Function: _Decimal128 __bid_addtd3 (_Decimal128 A, 727 _Decimal128 B) 728 These functions return the sum of A and B. 729 730 -- Runtime Function: _Decimal32 __dpd_subsd3 (_Decimal32 A, _Decimal32 731 B) 732 -- Runtime Function: _Decimal32 __bid_subsd3 (_Decimal32 A, _Decimal32 733 B) 734 -- Runtime Function: _Decimal64 __dpd_subdd3 (_Decimal64 A, _Decimal64 735 B) 736 -- Runtime Function: _Decimal64 __bid_subdd3 (_Decimal64 A, _Decimal64 737 B) 738 -- Runtime Function: _Decimal128 __dpd_subtd3 (_Decimal128 A, 739 _Decimal128 B) 740 -- Runtime Function: _Decimal128 __bid_subtd3 (_Decimal128 A, 741 _Decimal128 B) 742 These functions return the difference between B and A; that is, 743 A - B. 744 745 -- Runtime Function: _Decimal32 __dpd_mulsd3 (_Decimal32 A, _Decimal32 746 B) 747 -- Runtime Function: _Decimal32 __bid_mulsd3 (_Decimal32 A, _Decimal32 748 B) 749 -- Runtime Function: _Decimal64 __dpd_muldd3 (_Decimal64 A, _Decimal64 750 B) 751 -- Runtime Function: _Decimal64 __bid_muldd3 (_Decimal64 A, _Decimal64 752 B) 753 -- Runtime Function: _Decimal128 __dpd_multd3 (_Decimal128 A, 754 _Decimal128 B) 755 -- Runtime Function: _Decimal128 __bid_multd3 (_Decimal128 A, 756 _Decimal128 B) 757 These functions return the product of A and B. 758 759 -- Runtime Function: _Decimal32 __dpd_divsd3 (_Decimal32 A, _Decimal32 760 B) 761 -- Runtime Function: _Decimal32 __bid_divsd3 (_Decimal32 A, _Decimal32 762 B) 763 -- Runtime Function: _Decimal64 __dpd_divdd3 (_Decimal64 A, _Decimal64 764 B) 765 -- Runtime Function: _Decimal64 __bid_divdd3 (_Decimal64 A, _Decimal64 766 B) 767 -- Runtime Function: _Decimal128 __dpd_divtd3 (_Decimal128 A, 768 _Decimal128 B) 769 -- Runtime Function: _Decimal128 __bid_divtd3 (_Decimal128 A, 770 _Decimal128 B) 771 These functions return the quotient of A and B; that is, A / B. 772 773 -- Runtime Function: _Decimal32 __dpd_negsd2 (_Decimal32 A) 774 -- Runtime Function: _Decimal32 __bid_negsd2 (_Decimal32 A) 775 -- Runtime Function: _Decimal64 __dpd_negdd2 (_Decimal64 A) 776 -- Runtime Function: _Decimal64 __bid_negdd2 (_Decimal64 A) 777 -- Runtime Function: _Decimal128 __dpd_negtd2 (_Decimal128 A) 778 -- Runtime Function: _Decimal128 __bid_negtd2 (_Decimal128 A) 779 These functions return the negation of A. They simply flip the 780 sign bit, so they can produce negative zero and negative NaN. 781 7824.3.2 Conversion functions 783-------------------------- 784 785 -- Runtime Function: _Decimal64 __dpd_extendsddd2 (_Decimal32 A) 786 -- Runtime Function: _Decimal64 __bid_extendsddd2 (_Decimal32 A) 787 -- Runtime Function: _Decimal128 __dpd_extendsdtd2 (_Decimal32 A) 788 -- Runtime Function: _Decimal128 __bid_extendsdtd2 (_Decimal32 A) 789 -- Runtime Function: _Decimal128 __dpd_extendddtd2 (_Decimal64 A) 790 -- Runtime Function: _Decimal128 __bid_extendddtd2 (_Decimal64 A) 791 -- Runtime Function: _Decimal32 __dpd_truncddsd2 (_Decimal64 A) 792 -- Runtime Function: _Decimal32 __bid_truncddsd2 (_Decimal64 A) 793 -- Runtime Function: _Decimal32 __dpd_trunctdsd2 (_Decimal128 A) 794 -- Runtime Function: _Decimal32 __bid_trunctdsd2 (_Decimal128 A) 795 -- Runtime Function: _Decimal64 __dpd_trunctddd2 (_Decimal128 A) 796 -- Runtime Function: _Decimal64 __bid_trunctddd2 (_Decimal128 A) 797 These functions convert the value A from one decimal floating type 798 to another. 799 800 -- Runtime Function: _Decimal64 __dpd_extendsfdd (float A) 801 -- Runtime Function: _Decimal64 __bid_extendsfdd (float A) 802 -- Runtime Function: _Decimal128 __dpd_extendsftd (float A) 803 -- Runtime Function: _Decimal128 __bid_extendsftd (float A) 804 -- Runtime Function: _Decimal128 __dpd_extenddftd (double A) 805 -- Runtime Function: _Decimal128 __bid_extenddftd (double A) 806 -- Runtime Function: _Decimal128 __dpd_extendxftd (long double A) 807 -- Runtime Function: _Decimal128 __bid_extendxftd (long double A) 808 -- Runtime Function: _Decimal32 __dpd_truncdfsd (double A) 809 -- Runtime Function: _Decimal32 __bid_truncdfsd (double A) 810 -- Runtime Function: _Decimal32 __dpd_truncxfsd (long double A) 811 -- Runtime Function: _Decimal32 __bid_truncxfsd (long double A) 812 -- Runtime Function: _Decimal32 __dpd_trunctfsd (long double A) 813 -- Runtime Function: _Decimal32 __bid_trunctfsd (long double A) 814 -- Runtime Function: _Decimal64 __dpd_truncxfdd (long double A) 815 -- Runtime Function: _Decimal64 __bid_truncxfdd (long double A) 816 -- Runtime Function: _Decimal64 __dpd_trunctfdd (long double A) 817 -- Runtime Function: _Decimal64 __bid_trunctfdd (long double A) 818 These functions convert the value of A from a binary floating type 819 to a decimal floating type of a different size. 820 821 -- Runtime Function: float __dpd_truncddsf (_Decimal64 A) 822 -- Runtime Function: float __bid_truncddsf (_Decimal64 A) 823 -- Runtime Function: float __dpd_trunctdsf (_Decimal128 A) 824 -- Runtime Function: float __bid_trunctdsf (_Decimal128 A) 825 -- Runtime Function: double __dpd_extendsddf (_Decimal32 A) 826 -- Runtime Function: double __bid_extendsddf (_Decimal32 A) 827 -- Runtime Function: double __dpd_trunctddf (_Decimal128 A) 828 -- Runtime Function: double __bid_trunctddf (_Decimal128 A) 829 -- Runtime Function: long double __dpd_extendsdxf (_Decimal32 A) 830 -- Runtime Function: long double __bid_extendsdxf (_Decimal32 A) 831 -- Runtime Function: long double __dpd_extendddxf (_Decimal64 A) 832 -- Runtime Function: long double __bid_extendddxf (_Decimal64 A) 833 -- Runtime Function: long double __dpd_trunctdxf (_Decimal128 A) 834 -- Runtime Function: long double __bid_trunctdxf (_Decimal128 A) 835 -- Runtime Function: long double __dpd_extendsdtf (_Decimal32 A) 836 -- Runtime Function: long double __bid_extendsdtf (_Decimal32 A) 837 -- Runtime Function: long double __dpd_extendddtf (_Decimal64 A) 838 -- Runtime Function: long double __bid_extendddtf (_Decimal64 A) 839 These functions convert the value of A from a decimal floating type 840 to a binary floating type of a different size. 841 842 -- Runtime Function: _Decimal32 __dpd_extendsfsd (float A) 843 -- Runtime Function: _Decimal32 __bid_extendsfsd (float A) 844 -- Runtime Function: _Decimal64 __dpd_extenddfdd (double A) 845 -- Runtime Function: _Decimal64 __bid_extenddfdd (double A) 846 -- Runtime Function: _Decimal128 __dpd_extendtftd (long double A) 847 -- Runtime Function: _Decimal128 __bid_extendtftd (long double A) 848 -- Runtime Function: float __dpd_truncsdsf (_Decimal32 A) 849 -- Runtime Function: float __bid_truncsdsf (_Decimal32 A) 850 -- Runtime Function: double __dpd_truncdddf (_Decimal64 A) 851 -- Runtime Function: double __bid_truncdddf (_Decimal64 A) 852 -- Runtime Function: long double __dpd_trunctdtf (_Decimal128 A) 853 -- Runtime Function: long double __bid_trunctdtf (_Decimal128 A) 854 These functions convert the value of A between decimal and binary 855 floating types of the same size. 856 857 -- Runtime Function: int __dpd_fixsdsi (_Decimal32 A) 858 -- Runtime Function: int __bid_fixsdsi (_Decimal32 A) 859 -- Runtime Function: int __dpd_fixddsi (_Decimal64 A) 860 -- Runtime Function: int __bid_fixddsi (_Decimal64 A) 861 -- Runtime Function: int __dpd_fixtdsi (_Decimal128 A) 862 -- Runtime Function: int __bid_fixtdsi (_Decimal128 A) 863 These functions convert A to a signed integer. 864 865 -- Runtime Function: long __dpd_fixsddi (_Decimal32 A) 866 -- Runtime Function: long __bid_fixsddi (_Decimal32 A) 867 -- Runtime Function: long __dpd_fixdddi (_Decimal64 A) 868 -- Runtime Function: long __bid_fixdddi (_Decimal64 A) 869 -- Runtime Function: long __dpd_fixtddi (_Decimal128 A) 870 -- Runtime Function: long __bid_fixtddi (_Decimal128 A) 871 These functions convert A to a signed long. 872 873 -- Runtime Function: unsigned int __dpd_fixunssdsi (_Decimal32 A) 874 -- Runtime Function: unsigned int __bid_fixunssdsi (_Decimal32 A) 875 -- Runtime Function: unsigned int __dpd_fixunsddsi (_Decimal64 A) 876 -- Runtime Function: unsigned int __bid_fixunsddsi (_Decimal64 A) 877 -- Runtime Function: unsigned int __dpd_fixunstdsi (_Decimal128 A) 878 -- Runtime Function: unsigned int __bid_fixunstdsi (_Decimal128 A) 879 These functions convert A to an unsigned integer. Negative values 880 all become zero. 881 882 -- Runtime Function: unsigned long __dpd_fixunssddi (_Decimal32 A) 883 -- Runtime Function: unsigned long __bid_fixunssddi (_Decimal32 A) 884 -- Runtime Function: unsigned long __dpd_fixunsdddi (_Decimal64 A) 885 -- Runtime Function: unsigned long __bid_fixunsdddi (_Decimal64 A) 886 -- Runtime Function: unsigned long __dpd_fixunstddi (_Decimal128 A) 887 -- Runtime Function: unsigned long __bid_fixunstddi (_Decimal128 A) 888 These functions convert A to an unsigned long. Negative values 889 all become zero. 890 891 -- Runtime Function: _Decimal32 __dpd_floatsisd (int I) 892 -- Runtime Function: _Decimal32 __bid_floatsisd (int I) 893 -- Runtime Function: _Decimal64 __dpd_floatsidd (int I) 894 -- Runtime Function: _Decimal64 __bid_floatsidd (int I) 895 -- Runtime Function: _Decimal128 __dpd_floatsitd (int I) 896 -- Runtime Function: _Decimal128 __bid_floatsitd (int I) 897 These functions convert I, a signed integer, to decimal floating 898 point. 899 900 -- Runtime Function: _Decimal32 __dpd_floatdisd (long I) 901 -- Runtime Function: _Decimal32 __bid_floatdisd (long I) 902 -- Runtime Function: _Decimal64 __dpd_floatdidd (long I) 903 -- Runtime Function: _Decimal64 __bid_floatdidd (long I) 904 -- Runtime Function: _Decimal128 __dpd_floatditd (long I) 905 -- Runtime Function: _Decimal128 __bid_floatditd (long I) 906 These functions convert I, a signed long, to decimal floating 907 point. 908 909 -- Runtime Function: _Decimal32 __dpd_floatunssisd (unsigned int I) 910 -- Runtime Function: _Decimal32 __bid_floatunssisd (unsigned int I) 911 -- Runtime Function: _Decimal64 __dpd_floatunssidd (unsigned int I) 912 -- Runtime Function: _Decimal64 __bid_floatunssidd (unsigned int I) 913 -- Runtime Function: _Decimal128 __dpd_floatunssitd (unsigned int I) 914 -- Runtime Function: _Decimal128 __bid_floatunssitd (unsigned int I) 915 These functions convert I, an unsigned integer, to decimal 916 floating point. 917 918 -- Runtime Function: _Decimal32 __dpd_floatunsdisd (unsigned long I) 919 -- Runtime Function: _Decimal32 __bid_floatunsdisd (unsigned long I) 920 -- Runtime Function: _Decimal64 __dpd_floatunsdidd (unsigned long I) 921 -- Runtime Function: _Decimal64 __bid_floatunsdidd (unsigned long I) 922 -- Runtime Function: _Decimal128 __dpd_floatunsditd (unsigned long I) 923 -- Runtime Function: _Decimal128 __bid_floatunsditd (unsigned long I) 924 These functions convert I, an unsigned long, to decimal floating 925 point. 926 9274.3.3 Comparison functions 928-------------------------- 929 930 -- Runtime Function: int __dpd_unordsd2 (_Decimal32 A, _Decimal32 B) 931 -- Runtime Function: int __bid_unordsd2 (_Decimal32 A, _Decimal32 B) 932 -- Runtime Function: int __dpd_unorddd2 (_Decimal64 A, _Decimal64 B) 933 -- Runtime Function: int __bid_unorddd2 (_Decimal64 A, _Decimal64 B) 934 -- Runtime Function: int __dpd_unordtd2 (_Decimal128 A, _Decimal128 B) 935 -- Runtime Function: int __bid_unordtd2 (_Decimal128 A, _Decimal128 B) 936 These functions return a nonzero value if either argument is NaN, 937 otherwise 0. 938 939 There is also a complete group of higher level functions which 940correspond directly to comparison operators. They implement the ISO C 941semantics for floating-point comparisons, taking NaN into account. Pay 942careful attention to the return values defined for each set. Under the 943hood, all of these routines are implemented as 944 945 if (__bid_unordXd2 (a, b)) 946 return E; 947 return __bid_cmpXd2 (a, b); 948 949where E is a constant chosen to give the proper behavior for NaN. 950Thus, the meaning of the return value is different for each set. Do 951not rely on this implementation; only the semantics documented below 952are guaranteed. 953 954 -- Runtime Function: int __dpd_eqsd2 (_Decimal32 A, _Decimal32 B) 955 -- Runtime Function: int __bid_eqsd2 (_Decimal32 A, _Decimal32 B) 956 -- Runtime Function: int __dpd_eqdd2 (_Decimal64 A, _Decimal64 B) 957 -- Runtime Function: int __bid_eqdd2 (_Decimal64 A, _Decimal64 B) 958 -- Runtime Function: int __dpd_eqtd2 (_Decimal128 A, _Decimal128 B) 959 -- Runtime Function: int __bid_eqtd2 (_Decimal128 A, _Decimal128 B) 960 These functions return zero if neither argument is NaN, and A and 961 B are equal. 962 963 -- Runtime Function: int __dpd_nesd2 (_Decimal32 A, _Decimal32 B) 964 -- Runtime Function: int __bid_nesd2 (_Decimal32 A, _Decimal32 B) 965 -- Runtime Function: int __dpd_nedd2 (_Decimal64 A, _Decimal64 B) 966 -- Runtime Function: int __bid_nedd2 (_Decimal64 A, _Decimal64 B) 967 -- Runtime Function: int __dpd_netd2 (_Decimal128 A, _Decimal128 B) 968 -- Runtime Function: int __bid_netd2 (_Decimal128 A, _Decimal128 B) 969 These functions return a nonzero value if either argument is NaN, 970 or if A and B are unequal. 971 972 -- Runtime Function: int __dpd_gesd2 (_Decimal32 A, _Decimal32 B) 973 -- Runtime Function: int __bid_gesd2 (_Decimal32 A, _Decimal32 B) 974 -- Runtime Function: int __dpd_gedd2 (_Decimal64 A, _Decimal64 B) 975 -- Runtime Function: int __bid_gedd2 (_Decimal64 A, _Decimal64 B) 976 -- Runtime Function: int __dpd_getd2 (_Decimal128 A, _Decimal128 B) 977 -- Runtime Function: int __bid_getd2 (_Decimal128 A, _Decimal128 B) 978 These functions return a value greater than or equal to zero if 979 neither argument is NaN, and A is greater than or equal to B. 980 981 -- Runtime Function: int __dpd_ltsd2 (_Decimal32 A, _Decimal32 B) 982 -- Runtime Function: int __bid_ltsd2 (_Decimal32 A, _Decimal32 B) 983 -- Runtime Function: int __dpd_ltdd2 (_Decimal64 A, _Decimal64 B) 984 -- Runtime Function: int __bid_ltdd2 (_Decimal64 A, _Decimal64 B) 985 -- Runtime Function: int __dpd_lttd2 (_Decimal128 A, _Decimal128 B) 986 -- Runtime Function: int __bid_lttd2 (_Decimal128 A, _Decimal128 B) 987 These functions return a value less than zero if neither argument 988 is NaN, and A is strictly less than B. 989 990 -- Runtime Function: int __dpd_lesd2 (_Decimal32 A, _Decimal32 B) 991 -- Runtime Function: int __bid_lesd2 (_Decimal32 A, _Decimal32 B) 992 -- Runtime Function: int __dpd_ledd2 (_Decimal64 A, _Decimal64 B) 993 -- Runtime Function: int __bid_ledd2 (_Decimal64 A, _Decimal64 B) 994 -- Runtime Function: int __dpd_letd2 (_Decimal128 A, _Decimal128 B) 995 -- Runtime Function: int __bid_letd2 (_Decimal128 A, _Decimal128 B) 996 These functions return a value less than or equal to zero if 997 neither argument is NaN, and A is less than or equal to B. 998 999 -- Runtime Function: int __dpd_gtsd2 (_Decimal32 A, _Decimal32 B) 1000 -- Runtime Function: int __bid_gtsd2 (_Decimal32 A, _Decimal32 B) 1001 -- Runtime Function: int __dpd_gtdd2 (_Decimal64 A, _Decimal64 B) 1002 -- Runtime Function: int __bid_gtdd2 (_Decimal64 A, _Decimal64 B) 1003 -- Runtime Function: int __dpd_gttd2 (_Decimal128 A, _Decimal128 B) 1004 -- Runtime Function: int __bid_gttd2 (_Decimal128 A, _Decimal128 B) 1005 These functions return a value greater than zero if neither 1006 argument is NaN, and A is strictly greater than B. 1007 1008 1009File: gccint.info, Node: Fixed-point fractional library routines, Next: Exception handling routines, Prev: Decimal float library routines, Up: Libgcc 1010 10114.4 Routines for fixed-point fractional emulation 1012================================================= 1013 1014The software fixed-point library implements fixed-point fractional 1015arithmetic, and is only activated on selected targets. 1016 1017 For ease of comprehension `fract' is an alias for the `_Fract' type, 1018`accum' an alias for `_Accum', and `sat' an alias for `_Sat'. 1019 1020 For illustrative purposes, in this section the fixed-point fractional 1021type `short fract' is assumed to correspond to machine mode `QQmode'; 1022`unsigned short fract' to `UQQmode'; `fract' to `HQmode'; 1023`unsigned fract' to `UHQmode'; `long fract' to `SQmode'; 1024`unsigned long fract' to `USQmode'; `long long fract' to `DQmode'; and 1025`unsigned long long fract' to `UDQmode'. Similarly the fixed-point 1026accumulator type `short accum' corresponds to `HAmode'; 1027`unsigned short accum' to `UHAmode'; `accum' to `SAmode'; 1028`unsigned accum' to `USAmode'; `long accum' to `DAmode'; 1029`unsigned long accum' to `UDAmode'; `long long accum' to `TAmode'; and 1030`unsigned long long accum' to `UTAmode'. 1031 10324.4.1 Arithmetic functions 1033-------------------------- 1034 1035 -- Runtime Function: short fract __addqq3 (short fract A, short fract 1036 B) 1037 -- Runtime Function: fract __addhq3 (fract A, fract B) 1038 -- Runtime Function: long fract __addsq3 (long fract A, long fract B) 1039 -- Runtime Function: long long fract __adddq3 (long long fract A, long 1040 long fract B) 1041 -- Runtime Function: unsigned short fract __adduqq3 (unsigned short 1042 fract A, unsigned short fract B) 1043 -- Runtime Function: unsigned fract __adduhq3 (unsigned fract A, 1044 unsigned fract B) 1045 -- Runtime Function: unsigned long fract __addusq3 (unsigned long 1046 fract A, unsigned long fract B) 1047 -- Runtime Function: unsigned long long fract __addudq3 (unsigned long 1048 long fract A, unsigned long long fract B) 1049 -- Runtime Function: short accum __addha3 (short accum A, short accum 1050 B) 1051 -- Runtime Function: accum __addsa3 (accum A, accum B) 1052 -- Runtime Function: long accum __addda3 (long accum A, long accum B) 1053 -- Runtime Function: long long accum __addta3 (long long accum A, long 1054 long accum B) 1055 -- Runtime Function: unsigned short accum __adduha3 (unsigned short 1056 accum A, unsigned short accum B) 1057 -- Runtime Function: unsigned accum __addusa3 (unsigned accum A, 1058 unsigned accum B) 1059 -- Runtime Function: unsigned long accum __adduda3 (unsigned long 1060 accum A, unsigned long accum B) 1061 -- Runtime Function: unsigned long long accum __adduta3 (unsigned long 1062 long accum A, unsigned long long accum B) 1063 These functions return the sum of A and B. 1064 1065 -- Runtime Function: short fract __ssaddqq3 (short fract A, short 1066 fract B) 1067 -- Runtime Function: fract __ssaddhq3 (fract A, fract B) 1068 -- Runtime Function: long fract __ssaddsq3 (long fract A, long fract B) 1069 -- Runtime Function: long long fract __ssadddq3 (long long fract A, 1070 long long fract B) 1071 -- Runtime Function: short accum __ssaddha3 (short accum A, short 1072 accum B) 1073 -- Runtime Function: accum __ssaddsa3 (accum A, accum B) 1074 -- Runtime Function: long accum __ssaddda3 (long accum A, long accum B) 1075 -- Runtime Function: long long accum __ssaddta3 (long long accum A, 1076 long long accum B) 1077 These functions return the sum of A and B with signed saturation. 1078 1079 -- Runtime Function: unsigned short fract __usadduqq3 (unsigned short 1080 fract A, unsigned short fract B) 1081 -- Runtime Function: unsigned fract __usadduhq3 (unsigned fract A, 1082 unsigned fract B) 1083 -- Runtime Function: unsigned long fract __usaddusq3 (unsigned long 1084 fract A, unsigned long fract B) 1085 -- Runtime Function: unsigned long long fract __usaddudq3 (unsigned 1086 long long fract A, unsigned long long fract B) 1087 -- Runtime Function: unsigned short accum __usadduha3 (unsigned short 1088 accum A, unsigned short accum B) 1089 -- Runtime Function: unsigned accum __usaddusa3 (unsigned accum A, 1090 unsigned accum B) 1091 -- Runtime Function: unsigned long accum __usadduda3 (unsigned long 1092 accum A, unsigned long accum B) 1093 -- Runtime Function: unsigned long long accum __usadduta3 (unsigned 1094 long long accum A, unsigned long long accum B) 1095 These functions return the sum of A and B with unsigned saturation. 1096 1097 -- Runtime Function: short fract __subqq3 (short fract A, short fract 1098 B) 1099 -- Runtime Function: fract __subhq3 (fract A, fract B) 1100 -- Runtime Function: long fract __subsq3 (long fract A, long fract B) 1101 -- Runtime Function: long long fract __subdq3 (long long fract A, long 1102 long fract B) 1103 -- Runtime Function: unsigned short fract __subuqq3 (unsigned short 1104 fract A, unsigned short fract B) 1105 -- Runtime Function: unsigned fract __subuhq3 (unsigned fract A, 1106 unsigned fract B) 1107 -- Runtime Function: unsigned long fract __subusq3 (unsigned long 1108 fract A, unsigned long fract B) 1109 -- Runtime Function: unsigned long long fract __subudq3 (unsigned long 1110 long fract A, unsigned long long fract B) 1111 -- Runtime Function: short accum __subha3 (short accum A, short accum 1112 B) 1113 -- Runtime Function: accum __subsa3 (accum A, accum B) 1114 -- Runtime Function: long accum __subda3 (long accum A, long accum B) 1115 -- Runtime Function: long long accum __subta3 (long long accum A, long 1116 long accum B) 1117 -- Runtime Function: unsigned short accum __subuha3 (unsigned short 1118 accum A, unsigned short accum B) 1119 -- Runtime Function: unsigned accum __subusa3 (unsigned accum A, 1120 unsigned accum B) 1121 -- Runtime Function: unsigned long accum __subuda3 (unsigned long 1122 accum A, unsigned long accum B) 1123 -- Runtime Function: unsigned long long accum __subuta3 (unsigned long 1124 long accum A, unsigned long long accum B) 1125 These functions return the difference of A and B; that is, `A - B'. 1126 1127 -- Runtime Function: short fract __sssubqq3 (short fract A, short 1128 fract B) 1129 -- Runtime Function: fract __sssubhq3 (fract A, fract B) 1130 -- Runtime Function: long fract __sssubsq3 (long fract A, long fract B) 1131 -- Runtime Function: long long fract __sssubdq3 (long long fract A, 1132 long long fract B) 1133 -- Runtime Function: short accum __sssubha3 (short accum A, short 1134 accum B) 1135 -- Runtime Function: accum __sssubsa3 (accum A, accum B) 1136 -- Runtime Function: long accum __sssubda3 (long accum A, long accum B) 1137 -- Runtime Function: long long accum __sssubta3 (long long accum A, 1138 long long accum B) 1139 These functions return the difference of A and B with signed 1140 saturation; that is, `A - B'. 1141 1142 -- Runtime Function: unsigned short fract __ussubuqq3 (unsigned short 1143 fract A, unsigned short fract B) 1144 -- Runtime Function: unsigned fract __ussubuhq3 (unsigned fract A, 1145 unsigned fract B) 1146 -- Runtime Function: unsigned long fract __ussubusq3 (unsigned long 1147 fract A, unsigned long fract B) 1148 -- Runtime Function: unsigned long long fract __ussubudq3 (unsigned 1149 long long fract A, unsigned long long fract B) 1150 -- Runtime Function: unsigned short accum __ussubuha3 (unsigned short 1151 accum A, unsigned short accum B) 1152 -- Runtime Function: unsigned accum __ussubusa3 (unsigned accum A, 1153 unsigned accum B) 1154 -- Runtime Function: unsigned long accum __ussubuda3 (unsigned long 1155 accum A, unsigned long accum B) 1156 -- Runtime Function: unsigned long long accum __ussubuta3 (unsigned 1157 long long accum A, unsigned long long accum B) 1158 These functions return the difference of A and B with unsigned 1159 saturation; that is, `A - B'. 1160 1161 -- Runtime Function: short fract __mulqq3 (short fract A, short fract 1162 B) 1163 -- Runtime Function: fract __mulhq3 (fract A, fract B) 1164 -- Runtime Function: long fract __mulsq3 (long fract A, long fract B) 1165 -- Runtime Function: long long fract __muldq3 (long long fract A, long 1166 long fract B) 1167 -- Runtime Function: unsigned short fract __muluqq3 (unsigned short 1168 fract A, unsigned short fract B) 1169 -- Runtime Function: unsigned fract __muluhq3 (unsigned fract A, 1170 unsigned fract B) 1171 -- Runtime Function: unsigned long fract __mulusq3 (unsigned long 1172 fract A, unsigned long fract B) 1173 -- Runtime Function: unsigned long long fract __muludq3 (unsigned long 1174 long fract A, unsigned long long fract B) 1175 -- Runtime Function: short accum __mulha3 (short accum A, short accum 1176 B) 1177 -- Runtime Function: accum __mulsa3 (accum A, accum B) 1178 -- Runtime Function: long accum __mulda3 (long accum A, long accum B) 1179 -- Runtime Function: long long accum __multa3 (long long accum A, long 1180 long accum B) 1181 -- Runtime Function: unsigned short accum __muluha3 (unsigned short 1182 accum A, unsigned short accum B) 1183 -- Runtime Function: unsigned accum __mulusa3 (unsigned accum A, 1184 unsigned accum B) 1185 -- Runtime Function: unsigned long accum __muluda3 (unsigned long 1186 accum A, unsigned long accum B) 1187 -- Runtime Function: unsigned long long accum __muluta3 (unsigned long 1188 long accum A, unsigned long long accum B) 1189 These functions return the product of A and B. 1190 1191 -- Runtime Function: short fract __ssmulqq3 (short fract A, short 1192 fract B) 1193 -- Runtime Function: fract __ssmulhq3 (fract A, fract B) 1194 -- Runtime Function: long fract __ssmulsq3 (long fract A, long fract B) 1195 -- Runtime Function: long long fract __ssmuldq3 (long long fract A, 1196 long long fract B) 1197 -- Runtime Function: short accum __ssmulha3 (short accum A, short 1198 accum B) 1199 -- Runtime Function: accum __ssmulsa3 (accum A, accum B) 1200 -- Runtime Function: long accum __ssmulda3 (long accum A, long accum B) 1201 -- Runtime Function: long long accum __ssmulta3 (long long accum A, 1202 long long accum B) 1203 These functions return the product of A and B with signed 1204 saturation. 1205 1206 -- Runtime Function: unsigned short fract __usmuluqq3 (unsigned short 1207 fract A, unsigned short fract B) 1208 -- Runtime Function: unsigned fract __usmuluhq3 (unsigned fract A, 1209 unsigned fract B) 1210 -- Runtime Function: unsigned long fract __usmulusq3 (unsigned long 1211 fract A, unsigned long fract B) 1212 -- Runtime Function: unsigned long long fract __usmuludq3 (unsigned 1213 long long fract A, unsigned long long fract B) 1214 -- Runtime Function: unsigned short accum __usmuluha3 (unsigned short 1215 accum A, unsigned short accum B) 1216 -- Runtime Function: unsigned accum __usmulusa3 (unsigned accum A, 1217 unsigned accum B) 1218 -- Runtime Function: unsigned long accum __usmuluda3 (unsigned long 1219 accum A, unsigned long accum B) 1220 -- Runtime Function: unsigned long long accum __usmuluta3 (unsigned 1221 long long accum A, unsigned long long accum B) 1222 These functions return the product of A and B with unsigned 1223 saturation. 1224 1225 -- Runtime Function: short fract __divqq3 (short fract A, short fract 1226 B) 1227 -- Runtime Function: fract __divhq3 (fract A, fract B) 1228 -- Runtime Function: long fract __divsq3 (long fract A, long fract B) 1229 -- Runtime Function: long long fract __divdq3 (long long fract A, long 1230 long fract B) 1231 -- Runtime Function: short accum __divha3 (short accum A, short accum 1232 B) 1233 -- Runtime Function: accum __divsa3 (accum A, accum B) 1234 -- Runtime Function: long accum __divda3 (long accum A, long accum B) 1235 -- Runtime Function: long long accum __divta3 (long long accum A, long 1236 long accum B) 1237 These functions return the quotient of the signed division of A 1238 and B. 1239 1240 -- Runtime Function: unsigned short fract __udivuqq3 (unsigned short 1241 fract A, unsigned short fract B) 1242 -- Runtime Function: unsigned fract __udivuhq3 (unsigned fract A, 1243 unsigned fract B) 1244 -- Runtime Function: unsigned long fract __udivusq3 (unsigned long 1245 fract A, unsigned long fract B) 1246 -- Runtime Function: unsigned long long fract __udivudq3 (unsigned 1247 long long fract A, unsigned long long fract B) 1248 -- Runtime Function: unsigned short accum __udivuha3 (unsigned short 1249 accum A, unsigned short accum B) 1250 -- Runtime Function: unsigned accum __udivusa3 (unsigned accum A, 1251 unsigned accum B) 1252 -- Runtime Function: unsigned long accum __udivuda3 (unsigned long 1253 accum A, unsigned long accum B) 1254 -- Runtime Function: unsigned long long accum __udivuta3 (unsigned 1255 long long accum A, unsigned long long accum B) 1256 These functions return the quotient of the unsigned division of A 1257 and B. 1258 1259 -- Runtime Function: short fract __ssdivqq3 (short fract A, short 1260 fract B) 1261 -- Runtime Function: fract __ssdivhq3 (fract A, fract B) 1262 -- Runtime Function: long fract __ssdivsq3 (long fract A, long fract B) 1263 -- Runtime Function: long long fract __ssdivdq3 (long long fract A, 1264 long long fract B) 1265 -- Runtime Function: short accum __ssdivha3 (short accum A, short 1266 accum B) 1267 -- Runtime Function: accum __ssdivsa3 (accum A, accum B) 1268 -- Runtime Function: long accum __ssdivda3 (long accum A, long accum B) 1269 -- Runtime Function: long long accum __ssdivta3 (long long accum A, 1270 long long accum B) 1271 These functions return the quotient of the signed division of A 1272 and B with signed saturation. 1273 1274 -- Runtime Function: unsigned short fract __usdivuqq3 (unsigned short 1275 fract A, unsigned short fract B) 1276 -- Runtime Function: unsigned fract __usdivuhq3 (unsigned fract A, 1277 unsigned fract B) 1278 -- Runtime Function: unsigned long fract __usdivusq3 (unsigned long 1279 fract A, unsigned long fract B) 1280 -- Runtime Function: unsigned long long fract __usdivudq3 (unsigned 1281 long long fract A, unsigned long long fract B) 1282 -- Runtime Function: unsigned short accum __usdivuha3 (unsigned short 1283 accum A, unsigned short accum B) 1284 -- Runtime Function: unsigned accum __usdivusa3 (unsigned accum A, 1285 unsigned accum B) 1286 -- Runtime Function: unsigned long accum __usdivuda3 (unsigned long 1287 accum A, unsigned long accum B) 1288 -- Runtime Function: unsigned long long accum __usdivuta3 (unsigned 1289 long long accum A, unsigned long long accum B) 1290 These functions return the quotient of the unsigned division of A 1291 and B with unsigned saturation. 1292 1293 -- Runtime Function: short fract __negqq2 (short fract A) 1294 -- Runtime Function: fract __neghq2 (fract A) 1295 -- Runtime Function: long fract __negsq2 (long fract A) 1296 -- Runtime Function: long long fract __negdq2 (long long fract A) 1297 -- Runtime Function: unsigned short fract __neguqq2 (unsigned short 1298 fract A) 1299 -- Runtime Function: unsigned fract __neguhq2 (unsigned fract A) 1300 -- Runtime Function: unsigned long fract __negusq2 (unsigned long 1301 fract A) 1302 -- Runtime Function: unsigned long long fract __negudq2 (unsigned long 1303 long fract A) 1304 -- Runtime Function: short accum __negha2 (short accum A) 1305 -- Runtime Function: accum __negsa2 (accum A) 1306 -- Runtime Function: long accum __negda2 (long accum A) 1307 -- Runtime Function: long long accum __negta2 (long long accum A) 1308 -- Runtime Function: unsigned short accum __neguha2 (unsigned short 1309 accum A) 1310 -- Runtime Function: unsigned accum __negusa2 (unsigned accum A) 1311 -- Runtime Function: unsigned long accum __neguda2 (unsigned long 1312 accum A) 1313 -- Runtime Function: unsigned long long accum __neguta2 (unsigned long 1314 long accum A) 1315 These functions return the negation of A. 1316 1317 -- Runtime Function: short fract __ssnegqq2 (short fract A) 1318 -- Runtime Function: fract __ssneghq2 (fract A) 1319 -- Runtime Function: long fract __ssnegsq2 (long fract A) 1320 -- Runtime Function: long long fract __ssnegdq2 (long long fract A) 1321 -- Runtime Function: short accum __ssnegha2 (short accum A) 1322 -- Runtime Function: accum __ssnegsa2 (accum A) 1323 -- Runtime Function: long accum __ssnegda2 (long accum A) 1324 -- Runtime Function: long long accum __ssnegta2 (long long accum A) 1325 These functions return the negation of A with signed saturation. 1326 1327 -- Runtime Function: unsigned short fract __usneguqq2 (unsigned short 1328 fract A) 1329 -- Runtime Function: unsigned fract __usneguhq2 (unsigned fract A) 1330 -- Runtime Function: unsigned long fract __usnegusq2 (unsigned long 1331 fract A) 1332 -- Runtime Function: unsigned long long fract __usnegudq2 (unsigned 1333 long long fract A) 1334 -- Runtime Function: unsigned short accum __usneguha2 (unsigned short 1335 accum A) 1336 -- Runtime Function: unsigned accum __usnegusa2 (unsigned accum A) 1337 -- Runtime Function: unsigned long accum __usneguda2 (unsigned long 1338 accum A) 1339 -- Runtime Function: unsigned long long accum __usneguta2 (unsigned 1340 long long accum A) 1341 These functions return the negation of A with unsigned saturation. 1342 1343 -- Runtime Function: short fract __ashlqq3 (short fract A, int B) 1344 -- Runtime Function: fract __ashlhq3 (fract A, int B) 1345 -- Runtime Function: long fract __ashlsq3 (long fract A, int B) 1346 -- Runtime Function: long long fract __ashldq3 (long long fract A, int 1347 B) 1348 -- Runtime Function: unsigned short fract __ashluqq3 (unsigned short 1349 fract A, int B) 1350 -- Runtime Function: unsigned fract __ashluhq3 (unsigned fract A, int 1351 B) 1352 -- Runtime Function: unsigned long fract __ashlusq3 (unsigned long 1353 fract A, int B) 1354 -- Runtime Function: unsigned long long fract __ashludq3 (unsigned 1355 long long fract A, int B) 1356 -- Runtime Function: short accum __ashlha3 (short accum A, int B) 1357 -- Runtime Function: accum __ashlsa3 (accum A, int B) 1358 -- Runtime Function: long accum __ashlda3 (long accum A, int B) 1359 -- Runtime Function: long long accum __ashlta3 (long long accum A, int 1360 B) 1361 -- Runtime Function: unsigned short accum __ashluha3 (unsigned short 1362 accum A, int B) 1363 -- Runtime Function: unsigned accum __ashlusa3 (unsigned accum A, int 1364 B) 1365 -- Runtime Function: unsigned long accum __ashluda3 (unsigned long 1366 accum A, int B) 1367 -- Runtime Function: unsigned long long accum __ashluta3 (unsigned 1368 long long accum A, int B) 1369 These functions return the result of shifting A left by B bits. 1370 1371 -- Runtime Function: short fract __ashrqq3 (short fract A, int B) 1372 -- Runtime Function: fract __ashrhq3 (fract A, int B) 1373 -- Runtime Function: long fract __ashrsq3 (long fract A, int B) 1374 -- Runtime Function: long long fract __ashrdq3 (long long fract A, int 1375 B) 1376 -- Runtime Function: short accum __ashrha3 (short accum A, int B) 1377 -- Runtime Function: accum __ashrsa3 (accum A, int B) 1378 -- Runtime Function: long accum __ashrda3 (long accum A, int B) 1379 -- Runtime Function: long long accum __ashrta3 (long long accum A, int 1380 B) 1381 These functions return the result of arithmetically shifting A 1382 right by B bits. 1383 1384 -- Runtime Function: unsigned short fract __lshruqq3 (unsigned short 1385 fract A, int B) 1386 -- Runtime Function: unsigned fract __lshruhq3 (unsigned fract A, int 1387 B) 1388 -- Runtime Function: unsigned long fract __lshrusq3 (unsigned long 1389 fract A, int B) 1390 -- Runtime Function: unsigned long long fract __lshrudq3 (unsigned 1391 long long fract A, int B) 1392 -- Runtime Function: unsigned short accum __lshruha3 (unsigned short 1393 accum A, int B) 1394 -- Runtime Function: unsigned accum __lshrusa3 (unsigned accum A, int 1395 B) 1396 -- Runtime Function: unsigned long accum __lshruda3 (unsigned long 1397 accum A, int B) 1398 -- Runtime Function: unsigned long long accum __lshruta3 (unsigned 1399 long long accum A, int B) 1400 These functions return the result of logically shifting A right by 1401 B bits. 1402 1403 -- Runtime Function: fract __ssashlhq3 (fract A, int B) 1404 -- Runtime Function: long fract __ssashlsq3 (long fract A, int B) 1405 -- Runtime Function: long long fract __ssashldq3 (long long fract A, 1406 int B) 1407 -- Runtime Function: short accum __ssashlha3 (short accum A, int B) 1408 -- Runtime Function: accum __ssashlsa3 (accum A, int B) 1409 -- Runtime Function: long accum __ssashlda3 (long accum A, int B) 1410 -- Runtime Function: long long accum __ssashlta3 (long long accum A, 1411 int B) 1412 These functions return the result of shifting A left by B bits 1413 with signed saturation. 1414 1415 -- Runtime Function: unsigned short fract __usashluqq3 (unsigned short 1416 fract A, int B) 1417 -- Runtime Function: unsigned fract __usashluhq3 (unsigned fract A, 1418 int B) 1419 -- Runtime Function: unsigned long fract __usashlusq3 (unsigned long 1420 fract A, int B) 1421 -- Runtime Function: unsigned long long fract __usashludq3 (unsigned 1422 long long fract A, int B) 1423 -- Runtime Function: unsigned short accum __usashluha3 (unsigned short 1424 accum A, int B) 1425 -- Runtime Function: unsigned accum __usashlusa3 (unsigned accum A, 1426 int B) 1427 -- Runtime Function: unsigned long accum __usashluda3 (unsigned long 1428 accum A, int B) 1429 -- Runtime Function: unsigned long long accum __usashluta3 (unsigned 1430 long long accum A, int B) 1431 These functions return the result of shifting A left by B bits 1432 with unsigned saturation. 1433 14344.4.2 Comparison functions 1435-------------------------- 1436 1437The following functions implement fixed-point comparisons. These 1438functions implement a low-level compare, upon which the higher level 1439comparison operators (such as less than and greater than or equal to) 1440can be constructed. The returned values lie in the range zero to two, 1441to allow the high-level operators to be implemented by testing the 1442returned result using either signed or unsigned comparison. 1443 1444 -- Runtime Function: int __cmpqq2 (short fract A, short fract B) 1445 -- Runtime Function: int __cmphq2 (fract A, fract B) 1446 -- Runtime Function: int __cmpsq2 (long fract A, long fract B) 1447 -- Runtime Function: int __cmpdq2 (long long fract A, long long fract 1448 B) 1449 -- Runtime Function: int __cmpuqq2 (unsigned short fract A, unsigned 1450 short fract B) 1451 -- Runtime Function: int __cmpuhq2 (unsigned fract A, unsigned fract B) 1452 -- Runtime Function: int __cmpusq2 (unsigned long fract A, unsigned 1453 long fract B) 1454 -- Runtime Function: int __cmpudq2 (unsigned long long fract A, 1455 unsigned long long fract B) 1456 -- Runtime Function: int __cmpha2 (short accum A, short accum B) 1457 -- Runtime Function: int __cmpsa2 (accum A, accum B) 1458 -- Runtime Function: int __cmpda2 (long accum A, long accum B) 1459 -- Runtime Function: int __cmpta2 (long long accum A, long long accum 1460 B) 1461 -- Runtime Function: int __cmpuha2 (unsigned short accum A, unsigned 1462 short accum B) 1463 -- Runtime Function: int __cmpusa2 (unsigned accum A, unsigned accum B) 1464 -- Runtime Function: int __cmpuda2 (unsigned long accum A, unsigned 1465 long accum B) 1466 -- Runtime Function: int __cmputa2 (unsigned long long accum A, 1467 unsigned long long accum B) 1468 These functions perform a signed or unsigned comparison of A and B 1469 (depending on the selected machine mode). If A is less than B, 1470 they return 0; if A is greater than B, they return 2; and if A and 1471 B are equal they return 1. 1472 14734.4.3 Conversion functions 1474-------------------------- 1475 1476 -- Runtime Function: fract __fractqqhq2 (short fract A) 1477 -- Runtime Function: long fract __fractqqsq2 (short fract A) 1478 -- Runtime Function: long long fract __fractqqdq2 (short fract A) 1479 -- Runtime Function: short accum __fractqqha (short fract A) 1480 -- Runtime Function: accum __fractqqsa (short fract A) 1481 -- Runtime Function: long accum __fractqqda (short fract A) 1482 -- Runtime Function: long long accum __fractqqta (short fract A) 1483 -- Runtime Function: unsigned short fract __fractqquqq (short fract A) 1484 -- Runtime Function: unsigned fract __fractqquhq (short fract A) 1485 -- Runtime Function: unsigned long fract __fractqqusq (short fract A) 1486 -- Runtime Function: unsigned long long fract __fractqqudq (short 1487 fract A) 1488 -- Runtime Function: unsigned short accum __fractqquha (short fract A) 1489 -- Runtime Function: unsigned accum __fractqqusa (short fract A) 1490 -- Runtime Function: unsigned long accum __fractqquda (short fract A) 1491 -- Runtime Function: unsigned long long accum __fractqquta (short 1492 fract A) 1493 -- Runtime Function: signed char __fractqqqi (short fract A) 1494 -- Runtime Function: short __fractqqhi (short fract A) 1495 -- Runtime Function: int __fractqqsi (short fract A) 1496 -- Runtime Function: long __fractqqdi (short fract A) 1497 -- Runtime Function: long long __fractqqti (short fract A) 1498 -- Runtime Function: float __fractqqsf (short fract A) 1499 -- Runtime Function: double __fractqqdf (short fract A) 1500 -- Runtime Function: short fract __fracthqqq2 (fract A) 1501 -- Runtime Function: long fract __fracthqsq2 (fract A) 1502 -- Runtime Function: long long fract __fracthqdq2 (fract A) 1503 -- Runtime Function: short accum __fracthqha (fract A) 1504 -- Runtime Function: accum __fracthqsa (fract A) 1505 -- Runtime Function: long accum __fracthqda (fract A) 1506 -- Runtime Function: long long accum __fracthqta (fract A) 1507 -- Runtime Function: unsigned short fract __fracthquqq (fract A) 1508 -- Runtime Function: unsigned fract __fracthquhq (fract A) 1509 -- Runtime Function: unsigned long fract __fracthqusq (fract A) 1510 -- Runtime Function: unsigned long long fract __fracthqudq (fract A) 1511 -- Runtime Function: unsigned short accum __fracthquha (fract A) 1512 -- Runtime Function: unsigned accum __fracthqusa (fract A) 1513 -- Runtime Function: unsigned long accum __fracthquda (fract A) 1514 -- Runtime Function: unsigned long long accum __fracthquta (fract A) 1515 -- Runtime Function: signed char __fracthqqi (fract A) 1516 -- Runtime Function: short __fracthqhi (fract A) 1517 -- Runtime Function: int __fracthqsi (fract A) 1518 -- Runtime Function: long __fracthqdi (fract A) 1519 -- Runtime Function: long long __fracthqti (fract A) 1520 -- Runtime Function: float __fracthqsf (fract A) 1521 -- Runtime Function: double __fracthqdf (fract A) 1522 -- Runtime Function: short fract __fractsqqq2 (long fract A) 1523 -- Runtime Function: fract __fractsqhq2 (long fract A) 1524 -- Runtime Function: long long fract __fractsqdq2 (long fract A) 1525 -- Runtime Function: short accum __fractsqha (long fract A) 1526 -- Runtime Function: accum __fractsqsa (long fract A) 1527 -- Runtime Function: long accum __fractsqda (long fract A) 1528 -- Runtime Function: long long accum __fractsqta (long fract A) 1529 -- Runtime Function: unsigned short fract __fractsquqq (long fract A) 1530 -- Runtime Function: unsigned fract __fractsquhq (long fract A) 1531 -- Runtime Function: unsigned long fract __fractsqusq (long fract A) 1532 -- Runtime Function: unsigned long long fract __fractsqudq (long fract 1533 A) 1534 -- Runtime Function: unsigned short accum __fractsquha (long fract A) 1535 -- Runtime Function: unsigned accum __fractsqusa (long fract A) 1536 -- Runtime Function: unsigned long accum __fractsquda (long fract A) 1537 -- Runtime Function: unsigned long long accum __fractsquta (long fract 1538 A) 1539 -- Runtime Function: signed char __fractsqqi (long fract A) 1540 -- Runtime Function: short __fractsqhi (long fract A) 1541 -- Runtime Function: int __fractsqsi (long fract A) 1542 -- Runtime Function: long __fractsqdi (long fract A) 1543 -- Runtime Function: long long __fractsqti (long fract A) 1544 -- Runtime Function: float __fractsqsf (long fract A) 1545 -- Runtime Function: double __fractsqdf (long fract A) 1546 -- Runtime Function: short fract __fractdqqq2 (long long fract A) 1547 -- Runtime Function: fract __fractdqhq2 (long long fract A) 1548 -- Runtime Function: long fract __fractdqsq2 (long long fract A) 1549 -- Runtime Function: short accum __fractdqha (long long fract A) 1550 -- Runtime Function: accum __fractdqsa (long long fract A) 1551 -- Runtime Function: long accum __fractdqda (long long fract A) 1552 -- Runtime Function: long long accum __fractdqta (long long fract A) 1553 -- Runtime Function: unsigned short fract __fractdquqq (long long 1554 fract A) 1555 -- Runtime Function: unsigned fract __fractdquhq (long long fract A) 1556 -- Runtime Function: unsigned long fract __fractdqusq (long long fract 1557 A) 1558 -- Runtime Function: unsigned long long fract __fractdqudq (long long 1559 fract A) 1560 -- Runtime Function: unsigned short accum __fractdquha (long long 1561 fract A) 1562 -- Runtime Function: unsigned accum __fractdqusa (long long fract A) 1563 -- Runtime Function: unsigned long accum __fractdquda (long long fract 1564 A) 1565 -- Runtime Function: unsigned long long accum __fractdquta (long long 1566 fract A) 1567 -- Runtime Function: signed char __fractdqqi (long long fract A) 1568 -- Runtime Function: short __fractdqhi (long long fract A) 1569 -- Runtime Function: int __fractdqsi (long long fract A) 1570 -- Runtime Function: long __fractdqdi (long long fract A) 1571 -- Runtime Function: long long __fractdqti (long long fract A) 1572 -- Runtime Function: float __fractdqsf (long long fract A) 1573 -- Runtime Function: double __fractdqdf (long long fract A) 1574 -- Runtime Function: short fract __fracthaqq (short accum A) 1575 -- Runtime Function: fract __fracthahq (short accum A) 1576 -- Runtime Function: long fract __fracthasq (short accum A) 1577 -- Runtime Function: long long fract __fracthadq (short accum A) 1578 -- Runtime Function: accum __fracthasa2 (short accum A) 1579 -- Runtime Function: long accum __fracthada2 (short accum A) 1580 -- Runtime Function: long long accum __fracthata2 (short accum A) 1581 -- Runtime Function: unsigned short fract __fracthauqq (short accum A) 1582 -- Runtime Function: unsigned fract __fracthauhq (short accum A) 1583 -- Runtime Function: unsigned long fract __fracthausq (short accum A) 1584 -- Runtime Function: unsigned long long fract __fracthaudq (short 1585 accum A) 1586 -- Runtime Function: unsigned short accum __fracthauha (short accum A) 1587 -- Runtime Function: unsigned accum __fracthausa (short accum A) 1588 -- Runtime Function: unsigned long accum __fracthauda (short accum A) 1589 -- Runtime Function: unsigned long long accum __fracthauta (short 1590 accum A) 1591 -- Runtime Function: signed char __fracthaqi (short accum A) 1592 -- Runtime Function: short __fracthahi (short accum A) 1593 -- Runtime Function: int __fracthasi (short accum A) 1594 -- Runtime Function: long __fracthadi (short accum A) 1595 -- Runtime Function: long long __fracthati (short accum A) 1596 -- Runtime Function: float __fracthasf (short accum A) 1597 -- Runtime Function: double __fracthadf (short accum A) 1598 -- Runtime Function: short fract __fractsaqq (accum A) 1599 -- Runtime Function: fract __fractsahq (accum A) 1600 -- Runtime Function: long fract __fractsasq (accum A) 1601 -- Runtime Function: long long fract __fractsadq (accum A) 1602 -- Runtime Function: short accum __fractsaha2 (accum A) 1603 -- Runtime Function: long accum __fractsada2 (accum A) 1604 -- Runtime Function: long long accum __fractsata2 (accum A) 1605 -- Runtime Function: unsigned short fract __fractsauqq (accum A) 1606 -- Runtime Function: unsigned fract __fractsauhq (accum A) 1607 -- Runtime Function: unsigned long fract __fractsausq (accum A) 1608 -- Runtime Function: unsigned long long fract __fractsaudq (accum A) 1609 -- Runtime Function: unsigned short accum __fractsauha (accum A) 1610 -- Runtime Function: unsigned accum __fractsausa (accum A) 1611 -- Runtime Function: unsigned long accum __fractsauda (accum A) 1612 -- Runtime Function: unsigned long long accum __fractsauta (accum A) 1613 -- Runtime Function: signed char __fractsaqi (accum A) 1614 -- Runtime Function: short __fractsahi (accum A) 1615 -- Runtime Function: int __fractsasi (accum A) 1616 -- Runtime Function: long __fractsadi (accum A) 1617 -- Runtime Function: long long __fractsati (accum A) 1618 -- Runtime Function: float __fractsasf (accum A) 1619 -- Runtime Function: double __fractsadf (accum A) 1620 -- Runtime Function: short fract __fractdaqq (long accum A) 1621 -- Runtime Function: fract __fractdahq (long accum A) 1622 -- Runtime Function: long fract __fractdasq (long accum A) 1623 -- Runtime Function: long long fract __fractdadq (long accum A) 1624 -- Runtime Function: short accum __fractdaha2 (long accum A) 1625 -- Runtime Function: accum __fractdasa2 (long accum A) 1626 -- Runtime Function: long long accum __fractdata2 (long accum A) 1627 -- Runtime Function: unsigned short fract __fractdauqq (long accum A) 1628 -- Runtime Function: unsigned fract __fractdauhq (long accum A) 1629 -- Runtime Function: unsigned long fract __fractdausq (long accum A) 1630 -- Runtime Function: unsigned long long fract __fractdaudq (long accum 1631 A) 1632 -- Runtime Function: unsigned short accum __fractdauha (long accum A) 1633 -- Runtime Function: unsigned accum __fractdausa (long accum A) 1634 -- Runtime Function: unsigned long accum __fractdauda (long accum A) 1635 -- Runtime Function: unsigned long long accum __fractdauta (long accum 1636 A) 1637 -- Runtime Function: signed char __fractdaqi (long accum A) 1638 -- Runtime Function: short __fractdahi (long accum A) 1639 -- Runtime Function: int __fractdasi (long accum A) 1640 -- Runtime Function: long __fractdadi (long accum A) 1641 -- Runtime Function: long long __fractdati (long accum A) 1642 -- Runtime Function: float __fractdasf (long accum A) 1643 -- Runtime Function: double __fractdadf (long accum A) 1644 -- Runtime Function: short fract __fracttaqq (long long accum A) 1645 -- Runtime Function: fract __fracttahq (long long accum A) 1646 -- Runtime Function: long fract __fracttasq (long long accum A) 1647 -- Runtime Function: long long fract __fracttadq (long long accum A) 1648 -- Runtime Function: short accum __fracttaha2 (long long accum A) 1649 -- Runtime Function: accum __fracttasa2 (long long accum A) 1650 -- Runtime Function: long accum __fracttada2 (long long accum A) 1651 -- Runtime Function: unsigned short fract __fracttauqq (long long 1652 accum A) 1653 -- Runtime Function: unsigned fract __fracttauhq (long long accum A) 1654 -- Runtime Function: unsigned long fract __fracttausq (long long accum 1655 A) 1656 -- Runtime Function: unsigned long long fract __fracttaudq (long long 1657 accum A) 1658 -- Runtime Function: unsigned short accum __fracttauha (long long 1659 accum A) 1660 -- Runtime Function: unsigned accum __fracttausa (long long accum A) 1661 -- Runtime Function: unsigned long accum __fracttauda (long long accum 1662 A) 1663 -- Runtime Function: unsigned long long accum __fracttauta (long long 1664 accum A) 1665 -- Runtime Function: signed char __fracttaqi (long long accum A) 1666 -- Runtime Function: short __fracttahi (long long accum A) 1667 -- Runtime Function: int __fracttasi (long long accum A) 1668 -- Runtime Function: long __fracttadi (long long accum A) 1669 -- Runtime Function: long long __fracttati (long long accum A) 1670 -- Runtime Function: float __fracttasf (long long accum A) 1671 -- Runtime Function: double __fracttadf (long long accum A) 1672 -- Runtime Function: short fract __fractuqqqq (unsigned short fract A) 1673 -- Runtime Function: fract __fractuqqhq (unsigned short fract A) 1674 -- Runtime Function: long fract __fractuqqsq (unsigned short fract A) 1675 -- Runtime Function: long long fract __fractuqqdq (unsigned short 1676 fract A) 1677 -- Runtime Function: short accum __fractuqqha (unsigned short fract A) 1678 -- Runtime Function: accum __fractuqqsa (unsigned short fract A) 1679 -- Runtime Function: long accum __fractuqqda (unsigned short fract A) 1680 -- Runtime Function: long long accum __fractuqqta (unsigned short 1681 fract A) 1682 -- Runtime Function: unsigned fract __fractuqquhq2 (unsigned short 1683 fract A) 1684 -- Runtime Function: unsigned long fract __fractuqqusq2 (unsigned 1685 short fract A) 1686 -- Runtime Function: unsigned long long fract __fractuqqudq2 (unsigned 1687 short fract A) 1688 -- Runtime Function: unsigned short accum __fractuqquha (unsigned 1689 short fract A) 1690 -- Runtime Function: unsigned accum __fractuqqusa (unsigned short 1691 fract A) 1692 -- Runtime Function: unsigned long accum __fractuqquda (unsigned short 1693 fract A) 1694 -- Runtime Function: unsigned long long accum __fractuqquta (unsigned 1695 short fract A) 1696 -- Runtime Function: signed char __fractuqqqi (unsigned short fract A) 1697 -- Runtime Function: short __fractuqqhi (unsigned short fract A) 1698 -- Runtime Function: int __fractuqqsi (unsigned short fract A) 1699 -- Runtime Function: long __fractuqqdi (unsigned short fract A) 1700 -- Runtime Function: long long __fractuqqti (unsigned short fract A) 1701 -- Runtime Function: float __fractuqqsf (unsigned short fract A) 1702 -- Runtime Function: double __fractuqqdf (unsigned short fract A) 1703 -- Runtime Function: short fract __fractuhqqq (unsigned fract A) 1704 -- Runtime Function: fract __fractuhqhq (unsigned fract A) 1705 -- Runtime Function: long fract __fractuhqsq (unsigned fract A) 1706 -- Runtime Function: long long fract __fractuhqdq (unsigned fract A) 1707 -- Runtime Function: short accum __fractuhqha (unsigned fract A) 1708 -- Runtime Function: accum __fractuhqsa (unsigned fract A) 1709 -- Runtime Function: long accum __fractuhqda (unsigned fract A) 1710 -- Runtime Function: long long accum __fractuhqta (unsigned fract A) 1711 -- Runtime Function: unsigned short fract __fractuhquqq2 (unsigned 1712 fract A) 1713 -- Runtime Function: unsigned long fract __fractuhqusq2 (unsigned 1714 fract A) 1715 -- Runtime Function: unsigned long long fract __fractuhqudq2 (unsigned 1716 fract A) 1717 -- Runtime Function: unsigned short accum __fractuhquha (unsigned 1718 fract A) 1719 -- Runtime Function: unsigned accum __fractuhqusa (unsigned fract A) 1720 -- Runtime Function: unsigned long accum __fractuhquda (unsigned fract 1721 A) 1722 -- Runtime Function: unsigned long long accum __fractuhquta (unsigned 1723 fract A) 1724 -- Runtime Function: signed char __fractuhqqi (unsigned fract A) 1725 -- Runtime Function: short __fractuhqhi (unsigned fract A) 1726 -- Runtime Function: int __fractuhqsi (unsigned fract A) 1727 -- Runtime Function: long __fractuhqdi (unsigned fract A) 1728 -- Runtime Function: long long __fractuhqti (unsigned fract A) 1729 -- Runtime Function: float __fractuhqsf (unsigned fract A) 1730 -- Runtime Function: double __fractuhqdf (unsigned fract A) 1731 -- Runtime Function: short fract __fractusqqq (unsigned long fract A) 1732 -- Runtime Function: fract __fractusqhq (unsigned long fract A) 1733 -- Runtime Function: long fract __fractusqsq (unsigned long fract A) 1734 -- Runtime Function: long long fract __fractusqdq (unsigned long fract 1735 A) 1736 -- Runtime Function: short accum __fractusqha (unsigned long fract A) 1737 -- Runtime Function: accum __fractusqsa (unsigned long fract A) 1738 -- Runtime Function: long accum __fractusqda (unsigned long fract A) 1739 -- Runtime Function: long long accum __fractusqta (unsigned long fract 1740 A) 1741 -- Runtime Function: unsigned short fract __fractusquqq2 (unsigned 1742 long fract A) 1743 -- Runtime Function: unsigned fract __fractusquhq2 (unsigned long 1744 fract A) 1745 -- Runtime Function: unsigned long long fract __fractusqudq2 (unsigned 1746 long fract A) 1747 -- Runtime Function: unsigned short accum __fractusquha (unsigned long 1748 fract A) 1749 -- Runtime Function: unsigned accum __fractusqusa (unsigned long fract 1750 A) 1751 -- Runtime Function: unsigned long accum __fractusquda (unsigned long 1752 fract A) 1753 -- Runtime Function: unsigned long long accum __fractusquta (unsigned 1754 long fract A) 1755 -- Runtime Function: signed char __fractusqqi (unsigned long fract A) 1756 -- Runtime Function: short __fractusqhi (unsigned long fract A) 1757 -- Runtime Function: int __fractusqsi (unsigned long fract A) 1758 -- Runtime Function: long __fractusqdi (unsigned long fract A) 1759 -- Runtime Function: long long __fractusqti (unsigned long fract A) 1760 -- Runtime Function: float __fractusqsf (unsigned long fract A) 1761 -- Runtime Function: double __fractusqdf (unsigned long fract A) 1762 -- Runtime Function: short fract __fractudqqq (unsigned long long 1763 fract A) 1764 -- Runtime Function: fract __fractudqhq (unsigned long long fract A) 1765 -- Runtime Function: long fract __fractudqsq (unsigned long long fract 1766 A) 1767 -- Runtime Function: long long fract __fractudqdq (unsigned long long 1768 fract A) 1769 -- Runtime Function: short accum __fractudqha (unsigned long long 1770 fract A) 1771 -- Runtime Function: accum __fractudqsa (unsigned long long fract A) 1772 -- Runtime Function: long accum __fractudqda (unsigned long long fract 1773 A) 1774 -- Runtime Function: long long accum __fractudqta (unsigned long long 1775 fract A) 1776 -- Runtime Function: unsigned short fract __fractudquqq2 (unsigned 1777 long long fract A) 1778 -- Runtime Function: unsigned fract __fractudquhq2 (unsigned long long 1779 fract A) 1780 -- Runtime Function: unsigned long fract __fractudqusq2 (unsigned long 1781 long fract A) 1782 -- Runtime Function: unsigned short accum __fractudquha (unsigned long 1783 long fract A) 1784 -- Runtime Function: unsigned accum __fractudqusa (unsigned long long 1785 fract A) 1786 -- Runtime Function: unsigned long accum __fractudquda (unsigned long 1787 long fract A) 1788 -- Runtime Function: unsigned long long accum __fractudquta (unsigned 1789 long long fract A) 1790 -- Runtime Function: signed char __fractudqqi (unsigned long long 1791 fract A) 1792 -- Runtime Function: short __fractudqhi (unsigned long long fract A) 1793 -- Runtime Function: int __fractudqsi (unsigned long long fract A) 1794 -- Runtime Function: long __fractudqdi (unsigned long long fract A) 1795 -- Runtime Function: long long __fractudqti (unsigned long long fract 1796 A) 1797 -- Runtime Function: float __fractudqsf (unsigned long long fract A) 1798 -- Runtime Function: double __fractudqdf (unsigned long long fract A) 1799 -- Runtime Function: short fract __fractuhaqq (unsigned short accum A) 1800 -- Runtime Function: fract __fractuhahq (unsigned short accum A) 1801 -- Runtime Function: long fract __fractuhasq (unsigned short accum A) 1802 -- Runtime Function: long long fract __fractuhadq (unsigned short 1803 accum A) 1804 -- Runtime Function: short accum __fractuhaha (unsigned short accum A) 1805 -- Runtime Function: accum __fractuhasa (unsigned short accum A) 1806 -- Runtime Function: long accum __fractuhada (unsigned short accum A) 1807 -- Runtime Function: long long accum __fractuhata (unsigned short 1808 accum A) 1809 -- Runtime Function: unsigned short fract __fractuhauqq (unsigned 1810 short accum A) 1811 -- Runtime Function: unsigned fract __fractuhauhq (unsigned short 1812 accum A) 1813 -- Runtime Function: unsigned long fract __fractuhausq (unsigned short 1814 accum A) 1815 -- Runtime Function: unsigned long long fract __fractuhaudq (unsigned 1816 short accum A) 1817 -- Runtime Function: unsigned accum __fractuhausa2 (unsigned short 1818 accum A) 1819 -- Runtime Function: unsigned long accum __fractuhauda2 (unsigned 1820 short accum A) 1821 -- Runtime Function: unsigned long long accum __fractuhauta2 (unsigned 1822 short accum A) 1823 -- Runtime Function: signed char __fractuhaqi (unsigned short accum A) 1824 -- Runtime Function: short __fractuhahi (unsigned short accum A) 1825 -- Runtime Function: int __fractuhasi (unsigned short accum A) 1826 -- Runtime Function: long __fractuhadi (unsigned short accum A) 1827 -- Runtime Function: long long __fractuhati (unsigned short accum A) 1828 -- Runtime Function: float __fractuhasf (unsigned short accum A) 1829 -- Runtime Function: double __fractuhadf (unsigned short accum A) 1830 -- Runtime Function: short fract __fractusaqq (unsigned accum A) 1831 -- Runtime Function: fract __fractusahq (unsigned accum A) 1832 -- Runtime Function: long fract __fractusasq (unsigned accum A) 1833 -- Runtime Function: long long fract __fractusadq (unsigned accum A) 1834 -- Runtime Function: short accum __fractusaha (unsigned accum A) 1835 -- Runtime Function: accum __fractusasa (unsigned accum A) 1836 -- Runtime Function: long accum __fractusada (unsigned accum A) 1837 -- Runtime Function: long long accum __fractusata (unsigned accum A) 1838 -- Runtime Function: unsigned short fract __fractusauqq (unsigned 1839 accum A) 1840 -- Runtime Function: unsigned fract __fractusauhq (unsigned accum A) 1841 -- Runtime Function: unsigned long fract __fractusausq (unsigned accum 1842 A) 1843 -- Runtime Function: unsigned long long fract __fractusaudq (unsigned 1844 accum A) 1845 -- Runtime Function: unsigned short accum __fractusauha2 (unsigned 1846 accum A) 1847 -- Runtime Function: unsigned long accum __fractusauda2 (unsigned 1848 accum A) 1849 -- Runtime Function: unsigned long long accum __fractusauta2 (unsigned 1850 accum A) 1851 -- Runtime Function: signed char __fractusaqi (unsigned accum A) 1852 -- Runtime Function: short __fractusahi (unsigned accum A) 1853 -- Runtime Function: int __fractusasi (unsigned accum A) 1854 -- Runtime Function: long __fractusadi (unsigned accum A) 1855 -- Runtime Function: long long __fractusati (unsigned accum A) 1856 -- Runtime Function: float __fractusasf (unsigned accum A) 1857 -- Runtime Function: double __fractusadf (unsigned accum A) 1858 -- Runtime Function: short fract __fractudaqq (unsigned long accum A) 1859 -- Runtime Function: fract __fractudahq (unsigned long accum A) 1860 -- Runtime Function: long fract __fractudasq (unsigned long accum A) 1861 -- Runtime Function: long long fract __fractudadq (unsigned long accum 1862 A) 1863 -- Runtime Function: short accum __fractudaha (unsigned long accum A) 1864 -- Runtime Function: accum __fractudasa (unsigned long accum A) 1865 -- Runtime Function: long accum __fractudada (unsigned long accum A) 1866 -- Runtime Function: long long accum __fractudata (unsigned long accum 1867 A) 1868 -- Runtime Function: unsigned short fract __fractudauqq (unsigned long 1869 accum A) 1870 -- Runtime Function: unsigned fract __fractudauhq (unsigned long accum 1871 A) 1872 -- Runtime Function: unsigned long fract __fractudausq (unsigned long 1873 accum A) 1874 -- Runtime Function: unsigned long long fract __fractudaudq (unsigned 1875 long accum A) 1876 -- Runtime Function: unsigned short accum __fractudauha2 (unsigned 1877 long accum A) 1878 -- Runtime Function: unsigned accum __fractudausa2 (unsigned long 1879 accum A) 1880 -- Runtime Function: unsigned long long accum __fractudauta2 (unsigned 1881 long accum A) 1882 -- Runtime Function: signed char __fractudaqi (unsigned long accum A) 1883 -- Runtime Function: short __fractudahi (unsigned long accum A) 1884 -- Runtime Function: int __fractudasi (unsigned long accum A) 1885 -- Runtime Function: long __fractudadi (unsigned long accum A) 1886 -- Runtime Function: long long __fractudati (unsigned long accum A) 1887 -- Runtime Function: float __fractudasf (unsigned long accum A) 1888 -- Runtime Function: double __fractudadf (unsigned long accum A) 1889 -- Runtime Function: short fract __fractutaqq (unsigned long long 1890 accum A) 1891 -- Runtime Function: fract __fractutahq (unsigned long long accum A) 1892 -- Runtime Function: long fract __fractutasq (unsigned long long accum 1893 A) 1894 -- Runtime Function: long long fract __fractutadq (unsigned long long 1895 accum A) 1896 -- Runtime Function: short accum __fractutaha (unsigned long long 1897 accum A) 1898 -- Runtime Function: accum __fractutasa (unsigned long long accum A) 1899 -- Runtime Function: long accum __fractutada (unsigned long long accum 1900 A) 1901 -- Runtime Function: long long accum __fractutata (unsigned long long 1902 accum A) 1903 -- Runtime Function: unsigned short fract __fractutauqq (unsigned long 1904 long accum A) 1905 -- Runtime Function: unsigned fract __fractutauhq (unsigned long long 1906 accum A) 1907 -- Runtime Function: unsigned long fract __fractutausq (unsigned long 1908 long accum A) 1909 -- Runtime Function: unsigned long long fract __fractutaudq (unsigned 1910 long long accum A) 1911 -- Runtime Function: unsigned short accum __fractutauha2 (unsigned 1912 long long accum A) 1913 -- Runtime Function: unsigned accum __fractutausa2 (unsigned long long 1914 accum A) 1915 -- Runtime Function: unsigned long accum __fractutauda2 (unsigned long 1916 long accum A) 1917 -- Runtime Function: signed char __fractutaqi (unsigned long long 1918 accum A) 1919 -- Runtime Function: short __fractutahi (unsigned long long accum A) 1920 -- Runtime Function: int __fractutasi (unsigned long long accum A) 1921 -- Runtime Function: long __fractutadi (unsigned long long accum A) 1922 -- Runtime Function: long long __fractutati (unsigned long long accum 1923 A) 1924 -- Runtime Function: float __fractutasf (unsigned long long accum A) 1925 -- Runtime Function: double __fractutadf (unsigned long long accum A) 1926 -- Runtime Function: short fract __fractqiqq (signed char A) 1927 -- Runtime Function: fract __fractqihq (signed char A) 1928 -- Runtime Function: long fract __fractqisq (signed char A) 1929 -- Runtime Function: long long fract __fractqidq (signed char A) 1930 -- Runtime Function: short accum __fractqiha (signed char A) 1931 -- Runtime Function: accum __fractqisa (signed char A) 1932 -- Runtime Function: long accum __fractqida (signed char A) 1933 -- Runtime Function: long long accum __fractqita (signed char A) 1934 -- Runtime Function: unsigned short fract __fractqiuqq (signed char A) 1935 -- Runtime Function: unsigned fract __fractqiuhq (signed char A) 1936 -- Runtime Function: unsigned long fract __fractqiusq (signed char A) 1937 -- Runtime Function: unsigned long long fract __fractqiudq (signed 1938 char A) 1939 -- Runtime Function: unsigned short accum __fractqiuha (signed char A) 1940 -- Runtime Function: unsigned accum __fractqiusa (signed char A) 1941 -- Runtime Function: unsigned long accum __fractqiuda (signed char A) 1942 -- Runtime Function: unsigned long long accum __fractqiuta (signed 1943 char A) 1944 -- Runtime Function: short fract __fracthiqq (short A) 1945 -- Runtime Function: fract __fracthihq (short A) 1946 -- Runtime Function: long fract __fracthisq (short A) 1947 -- Runtime Function: long long fract __fracthidq (short A) 1948 -- Runtime Function: short accum __fracthiha (short A) 1949 -- Runtime Function: accum __fracthisa (short A) 1950 -- Runtime Function: long accum __fracthida (short A) 1951 -- Runtime Function: long long accum __fracthita (short A) 1952 -- Runtime Function: unsigned short fract __fracthiuqq (short A) 1953 -- Runtime Function: unsigned fract __fracthiuhq (short A) 1954 -- Runtime Function: unsigned long fract __fracthiusq (short A) 1955 -- Runtime Function: unsigned long long fract __fracthiudq (short A) 1956 -- Runtime Function: unsigned short accum __fracthiuha (short A) 1957 -- Runtime Function: unsigned accum __fracthiusa (short A) 1958 -- Runtime Function: unsigned long accum __fracthiuda (short A) 1959 -- Runtime Function: unsigned long long accum __fracthiuta (short A) 1960 -- Runtime Function: short fract __fractsiqq (int A) 1961 -- Runtime Function: fract __fractsihq (int A) 1962 -- Runtime Function: long fract __fractsisq (int A) 1963 -- Runtime Function: long long fract __fractsidq (int A) 1964 -- Runtime Function: short accum __fractsiha (int A) 1965 -- Runtime Function: accum __fractsisa (int A) 1966 -- Runtime Function: long accum __fractsida (int A) 1967 -- Runtime Function: long long accum __fractsita (int A) 1968 -- Runtime Function: unsigned short fract __fractsiuqq (int A) 1969 -- Runtime Function: unsigned fract __fractsiuhq (int A) 1970 -- Runtime Function: unsigned long fract __fractsiusq (int A) 1971 -- Runtime Function: unsigned long long fract __fractsiudq (int A) 1972 -- Runtime Function: unsigned short accum __fractsiuha (int A) 1973 -- Runtime Function: unsigned accum __fractsiusa (int A) 1974 -- Runtime Function: unsigned long accum __fractsiuda (int A) 1975 -- Runtime Function: unsigned long long accum __fractsiuta (int A) 1976 -- Runtime Function: short fract __fractdiqq (long A) 1977 -- Runtime Function: fract __fractdihq (long A) 1978 -- Runtime Function: long fract __fractdisq (long A) 1979 -- Runtime Function: long long fract __fractdidq (long A) 1980 -- Runtime Function: short accum __fractdiha (long A) 1981 -- Runtime Function: accum __fractdisa (long A) 1982 -- Runtime Function: long accum __fractdida (long A) 1983 -- Runtime Function: long long accum __fractdita (long A) 1984 -- Runtime Function: unsigned short fract __fractdiuqq (long A) 1985 -- Runtime Function: unsigned fract __fractdiuhq (long A) 1986 -- Runtime Function: unsigned long fract __fractdiusq (long A) 1987 -- Runtime Function: unsigned long long fract __fractdiudq (long A) 1988 -- Runtime Function: unsigned short accum __fractdiuha (long A) 1989 -- Runtime Function: unsigned accum __fractdiusa (long A) 1990 -- Runtime Function: unsigned long accum __fractdiuda (long A) 1991 -- Runtime Function: unsigned long long accum __fractdiuta (long A) 1992 -- Runtime Function: short fract __fracttiqq (long long A) 1993 -- Runtime Function: fract __fracttihq (long long A) 1994 -- Runtime Function: long fract __fracttisq (long long A) 1995 -- Runtime Function: long long fract __fracttidq (long long A) 1996 -- Runtime Function: short accum __fracttiha (long long A) 1997 -- Runtime Function: accum __fracttisa (long long A) 1998 -- Runtime Function: long accum __fracttida (long long A) 1999 -- Runtime Function: long long accum __fracttita (long long A) 2000 -- Runtime Function: unsigned short fract __fracttiuqq (long long A) 2001 -- Runtime Function: unsigned fract __fracttiuhq (long long A) 2002 -- Runtime Function: unsigned long fract __fracttiusq (long long A) 2003 -- Runtime Function: unsigned long long fract __fracttiudq (long long 2004 A) 2005 -- Runtime Function: unsigned short accum __fracttiuha (long long A) 2006 -- Runtime Function: unsigned accum __fracttiusa (long long A) 2007 -- Runtime Function: unsigned long accum __fracttiuda (long long A) 2008 -- Runtime Function: unsigned long long accum __fracttiuta (long long 2009 A) 2010 -- Runtime Function: short fract __fractsfqq (float A) 2011 -- Runtime Function: fract __fractsfhq (float A) 2012 -- Runtime Function: long fract __fractsfsq (float A) 2013 -- Runtime Function: long long fract __fractsfdq (float A) 2014 -- Runtime Function: short accum __fractsfha (float A) 2015 -- Runtime Function: accum __fractsfsa (float A) 2016 -- Runtime Function: long accum __fractsfda (float A) 2017 -- Runtime Function: long long accum __fractsfta (float A) 2018 -- Runtime Function: unsigned short fract __fractsfuqq (float A) 2019 -- Runtime Function: unsigned fract __fractsfuhq (float A) 2020 -- Runtime Function: unsigned long fract __fractsfusq (float A) 2021 -- Runtime Function: unsigned long long fract __fractsfudq (float A) 2022 -- Runtime Function: unsigned short accum __fractsfuha (float A) 2023 -- Runtime Function: unsigned accum __fractsfusa (float A) 2024 -- Runtime Function: unsigned long accum __fractsfuda (float A) 2025 -- Runtime Function: unsigned long long accum __fractsfuta (float A) 2026 -- Runtime Function: short fract __fractdfqq (double A) 2027 -- Runtime Function: fract __fractdfhq (double A) 2028 -- Runtime Function: long fract __fractdfsq (double A) 2029 -- Runtime Function: long long fract __fractdfdq (double A) 2030 -- Runtime Function: short accum __fractdfha (double A) 2031 -- Runtime Function: accum __fractdfsa (double A) 2032 -- Runtime Function: long accum __fractdfda (double A) 2033 -- Runtime Function: long long accum __fractdfta (double A) 2034 -- Runtime Function: unsigned short fract __fractdfuqq (double A) 2035 -- Runtime Function: unsigned fract __fractdfuhq (double A) 2036 -- Runtime Function: unsigned long fract __fractdfusq (double A) 2037 -- Runtime Function: unsigned long long fract __fractdfudq (double A) 2038 -- Runtime Function: unsigned short accum __fractdfuha (double A) 2039 -- Runtime Function: unsigned accum __fractdfusa (double A) 2040 -- Runtime Function: unsigned long accum __fractdfuda (double A) 2041 -- Runtime Function: unsigned long long accum __fractdfuta (double A) 2042 These functions convert from fractional and signed non-fractionals 2043 to fractionals and signed non-fractionals, without saturation. 2044 2045 -- Runtime Function: fract __satfractqqhq2 (short fract A) 2046 -- Runtime Function: long fract __satfractqqsq2 (short fract A) 2047 -- Runtime Function: long long fract __satfractqqdq2 (short fract A) 2048 -- Runtime Function: short accum __satfractqqha (short fract A) 2049 -- Runtime Function: accum __satfractqqsa (short fract A) 2050 -- Runtime Function: long accum __satfractqqda (short fract A) 2051 -- Runtime Function: long long accum __satfractqqta (short fract A) 2052 -- Runtime Function: unsigned short fract __satfractqquqq (short fract 2053 A) 2054 -- Runtime Function: unsigned fract __satfractqquhq (short fract A) 2055 -- Runtime Function: unsigned long fract __satfractqqusq (short fract 2056 A) 2057 -- Runtime Function: unsigned long long fract __satfractqqudq (short 2058 fract A) 2059 -- Runtime Function: unsigned short accum __satfractqquha (short fract 2060 A) 2061 -- Runtime Function: unsigned accum __satfractqqusa (short fract A) 2062 -- Runtime Function: unsigned long accum __satfractqquda (short fract 2063 A) 2064 -- Runtime Function: unsigned long long accum __satfractqquta (short 2065 fract A) 2066 -- Runtime Function: short fract __satfracthqqq2 (fract A) 2067 -- Runtime Function: long fract __satfracthqsq2 (fract A) 2068 -- Runtime Function: long long fract __satfracthqdq2 (fract A) 2069 -- Runtime Function: short accum __satfracthqha (fract A) 2070 -- Runtime Function: accum __satfracthqsa (fract A) 2071 -- Runtime Function: long accum __satfracthqda (fract A) 2072 -- Runtime Function: long long accum __satfracthqta (fract A) 2073 -- Runtime Function: unsigned short fract __satfracthquqq (fract A) 2074 -- Runtime Function: unsigned fract __satfracthquhq (fract A) 2075 -- Runtime Function: unsigned long fract __satfracthqusq (fract A) 2076 -- Runtime Function: unsigned long long fract __satfracthqudq (fract A) 2077 -- Runtime Function: unsigned short accum __satfracthquha (fract A) 2078 -- Runtime Function: unsigned accum __satfracthqusa (fract A) 2079 -- Runtime Function: unsigned long accum __satfracthquda (fract A) 2080 -- Runtime Function: unsigned long long accum __satfracthquta (fract A) 2081 -- Runtime Function: short fract __satfractsqqq2 (long fract A) 2082 -- Runtime Function: fract __satfractsqhq2 (long fract A) 2083 -- Runtime Function: long long fract __satfractsqdq2 (long fract A) 2084 -- Runtime Function: short accum __satfractsqha (long fract A) 2085 -- Runtime Function: accum __satfractsqsa (long fract A) 2086 -- Runtime Function: long accum __satfractsqda (long fract A) 2087 -- Runtime Function: long long accum __satfractsqta (long fract A) 2088 -- Runtime Function: unsigned short fract __satfractsquqq (long fract 2089 A) 2090 -- Runtime Function: unsigned fract __satfractsquhq (long fract A) 2091 -- Runtime Function: unsigned long fract __satfractsqusq (long fract A) 2092 -- Runtime Function: unsigned long long fract __satfractsqudq (long 2093 fract A) 2094 -- Runtime Function: unsigned short accum __satfractsquha (long fract 2095 A) 2096 -- Runtime Function: unsigned accum __satfractsqusa (long fract A) 2097 -- Runtime Function: unsigned long accum __satfractsquda (long fract A) 2098 -- Runtime Function: unsigned long long accum __satfractsquta (long 2099 fract A) 2100 -- Runtime Function: short fract __satfractdqqq2 (long long fract A) 2101 -- Runtime Function: fract __satfractdqhq2 (long long fract A) 2102 -- Runtime Function: long fract __satfractdqsq2 (long long fract A) 2103 -- Runtime Function: short accum __satfractdqha (long long fract A) 2104 -- Runtime Function: accum __satfractdqsa (long long fract A) 2105 -- Runtime Function: long accum __satfractdqda (long long fract A) 2106 -- Runtime Function: long long accum __satfractdqta (long long fract A) 2107 -- Runtime Function: unsigned short fract __satfractdquqq (long long 2108 fract A) 2109 -- Runtime Function: unsigned fract __satfractdquhq (long long fract A) 2110 -- Runtime Function: unsigned long fract __satfractdqusq (long long 2111 fract A) 2112 -- Runtime Function: unsigned long long fract __satfractdqudq (long 2113 long fract A) 2114 -- Runtime Function: unsigned short accum __satfractdquha (long long 2115 fract A) 2116 -- Runtime Function: unsigned accum __satfractdqusa (long long fract A) 2117 -- Runtime Function: unsigned long accum __satfractdquda (long long 2118 fract A) 2119 -- Runtime Function: unsigned long long accum __satfractdquta (long 2120 long fract A) 2121 -- Runtime Function: short fract __satfracthaqq (short accum A) 2122 -- Runtime Function: fract __satfracthahq (short accum A) 2123 -- Runtime Function: long fract __satfracthasq (short accum A) 2124 -- Runtime Function: long long fract __satfracthadq (short accum A) 2125 -- Runtime Function: accum __satfracthasa2 (short accum A) 2126 -- Runtime Function: long accum __satfracthada2 (short accum A) 2127 -- Runtime Function: long long accum __satfracthata2 (short accum A) 2128 -- Runtime Function: unsigned short fract __satfracthauqq (short accum 2129 A) 2130 -- Runtime Function: unsigned fract __satfracthauhq (short accum A) 2131 -- Runtime Function: unsigned long fract __satfracthausq (short accum 2132 A) 2133 -- Runtime Function: unsigned long long fract __satfracthaudq (short 2134 accum A) 2135 -- Runtime Function: unsigned short accum __satfracthauha (short accum 2136 A) 2137 -- Runtime Function: unsigned accum __satfracthausa (short accum A) 2138 -- Runtime Function: unsigned long accum __satfracthauda (short accum 2139 A) 2140 -- Runtime Function: unsigned long long accum __satfracthauta (short 2141 accum A) 2142 -- Runtime Function: short fract __satfractsaqq (accum A) 2143 -- Runtime Function: fract __satfractsahq (accum A) 2144 -- Runtime Function: long fract __satfractsasq (accum A) 2145 -- Runtime Function: long long fract __satfractsadq (accum A) 2146 -- Runtime Function: short accum __satfractsaha2 (accum A) 2147 -- Runtime Function: long accum __satfractsada2 (accum A) 2148 -- Runtime Function: long long accum __satfractsata2 (accum A) 2149 -- Runtime Function: unsigned short fract __satfractsauqq (accum A) 2150 -- Runtime Function: unsigned fract __satfractsauhq (accum A) 2151 -- Runtime Function: unsigned long fract __satfractsausq (accum A) 2152 -- Runtime Function: unsigned long long fract __satfractsaudq (accum A) 2153 -- Runtime Function: unsigned short accum __satfractsauha (accum A) 2154 -- Runtime Function: unsigned accum __satfractsausa (accum A) 2155 -- Runtime Function: unsigned long accum __satfractsauda (accum A) 2156 -- Runtime Function: unsigned long long accum __satfractsauta (accum A) 2157 -- Runtime Function: short fract __satfractdaqq (long accum A) 2158 -- Runtime Function: fract __satfractdahq (long accum A) 2159 -- Runtime Function: long fract __satfractdasq (long accum A) 2160 -- Runtime Function: long long fract __satfractdadq (long accum A) 2161 -- Runtime Function: short accum __satfractdaha2 (long accum A) 2162 -- Runtime Function: accum __satfractdasa2 (long accum A) 2163 -- Runtime Function: long long accum __satfractdata2 (long accum A) 2164 -- Runtime Function: unsigned short fract __satfractdauqq (long accum 2165 A) 2166 -- Runtime Function: unsigned fract __satfractdauhq (long accum A) 2167 -- Runtime Function: unsigned long fract __satfractdausq (long accum A) 2168 -- Runtime Function: unsigned long long fract __satfractdaudq (long 2169 accum A) 2170 -- Runtime Function: unsigned short accum __satfractdauha (long accum 2171 A) 2172 -- Runtime Function: unsigned accum __satfractdausa (long accum A) 2173 -- Runtime Function: unsigned long accum __satfractdauda (long accum A) 2174 -- Runtime Function: unsigned long long accum __satfractdauta (long 2175 accum A) 2176 -- Runtime Function: short fract __satfracttaqq (long long accum A) 2177 -- Runtime Function: fract __satfracttahq (long long accum A) 2178 -- Runtime Function: long fract __satfracttasq (long long accum A) 2179 -- Runtime Function: long long fract __satfracttadq (long long accum A) 2180 -- Runtime Function: short accum __satfracttaha2 (long long accum A) 2181 -- Runtime Function: accum __satfracttasa2 (long long accum A) 2182 -- Runtime Function: long accum __satfracttada2 (long long accum A) 2183 -- Runtime Function: unsigned short fract __satfracttauqq (long long 2184 accum A) 2185 -- Runtime Function: unsigned fract __satfracttauhq (long long accum A) 2186 -- Runtime Function: unsigned long fract __satfracttausq (long long 2187 accum A) 2188 -- Runtime Function: unsigned long long fract __satfracttaudq (long 2189 long accum A) 2190 -- Runtime Function: unsigned short accum __satfracttauha (long long 2191 accum A) 2192 -- Runtime Function: unsigned accum __satfracttausa (long long accum A) 2193 -- Runtime Function: unsigned long accum __satfracttauda (long long 2194 accum A) 2195 -- Runtime Function: unsigned long long accum __satfracttauta (long 2196 long accum A) 2197 -- Runtime Function: short fract __satfractuqqqq (unsigned short fract 2198 A) 2199 -- Runtime Function: fract __satfractuqqhq (unsigned short fract A) 2200 -- Runtime Function: long fract __satfractuqqsq (unsigned short fract 2201 A) 2202 -- Runtime Function: long long fract __satfractuqqdq (unsigned short 2203 fract A) 2204 -- Runtime Function: short accum __satfractuqqha (unsigned short fract 2205 A) 2206 -- Runtime Function: accum __satfractuqqsa (unsigned short fract A) 2207 -- Runtime Function: long accum __satfractuqqda (unsigned short fract 2208 A) 2209 -- Runtime Function: long long accum __satfractuqqta (unsigned short 2210 fract A) 2211 -- Runtime Function: unsigned fract __satfractuqquhq2 (unsigned short 2212 fract A) 2213 -- Runtime Function: unsigned long fract __satfractuqqusq2 (unsigned 2214 short fract A) 2215 -- Runtime Function: unsigned long long fract __satfractuqqudq2 2216 (unsigned short fract A) 2217 -- Runtime Function: unsigned short accum __satfractuqquha (unsigned 2218 short fract A) 2219 -- Runtime Function: unsigned accum __satfractuqqusa (unsigned short 2220 fract A) 2221 -- Runtime Function: unsigned long accum __satfractuqquda (unsigned 2222 short fract A) 2223 -- Runtime Function: unsigned long long accum __satfractuqquta 2224 (unsigned short fract A) 2225 -- Runtime Function: short fract __satfractuhqqq (unsigned fract A) 2226 -- Runtime Function: fract __satfractuhqhq (unsigned fract A) 2227 -- Runtime Function: long fract __satfractuhqsq (unsigned fract A) 2228 -- Runtime Function: long long fract __satfractuhqdq (unsigned fract A) 2229 -- Runtime Function: short accum __satfractuhqha (unsigned fract A) 2230 -- Runtime Function: accum __satfractuhqsa (unsigned fract A) 2231 -- Runtime Function: long accum __satfractuhqda (unsigned fract A) 2232 -- Runtime Function: long long accum __satfractuhqta (unsigned fract A) 2233 -- Runtime Function: unsigned short fract __satfractuhquqq2 (unsigned 2234 fract A) 2235 -- Runtime Function: unsigned long fract __satfractuhqusq2 (unsigned 2236 fract A) 2237 -- Runtime Function: unsigned long long fract __satfractuhqudq2 2238 (unsigned fract A) 2239 -- Runtime Function: unsigned short accum __satfractuhquha (unsigned 2240 fract A) 2241 -- Runtime Function: unsigned accum __satfractuhqusa (unsigned fract A) 2242 -- Runtime Function: unsigned long accum __satfractuhquda (unsigned 2243 fract A) 2244 -- Runtime Function: unsigned long long accum __satfractuhquta 2245 (unsigned fract A) 2246 -- Runtime Function: short fract __satfractusqqq (unsigned long fract 2247 A) 2248 -- Runtime Function: fract __satfractusqhq (unsigned long fract A) 2249 -- Runtime Function: long fract __satfractusqsq (unsigned long fract A) 2250 -- Runtime Function: long long fract __satfractusqdq (unsigned long 2251 fract A) 2252 -- Runtime Function: short accum __satfractusqha (unsigned long fract 2253 A) 2254 -- Runtime Function: accum __satfractusqsa (unsigned long fract A) 2255 -- Runtime Function: long accum __satfractusqda (unsigned long fract A) 2256 -- Runtime Function: long long accum __satfractusqta (unsigned long 2257 fract A) 2258 -- Runtime Function: unsigned short fract __satfractusquqq2 (unsigned 2259 long fract A) 2260 -- Runtime Function: unsigned fract __satfractusquhq2 (unsigned long 2261 fract A) 2262 -- Runtime Function: unsigned long long fract __satfractusqudq2 2263 (unsigned long fract A) 2264 -- Runtime Function: unsigned short accum __satfractusquha (unsigned 2265 long fract A) 2266 -- Runtime Function: unsigned accum __satfractusqusa (unsigned long 2267 fract A) 2268 -- Runtime Function: unsigned long accum __satfractusquda (unsigned 2269 long fract A) 2270 -- Runtime Function: unsigned long long accum __satfractusquta 2271 (unsigned long fract A) 2272 -- Runtime Function: short fract __satfractudqqq (unsigned long long 2273 fract A) 2274 -- Runtime Function: fract __satfractudqhq (unsigned long long fract A) 2275 -- Runtime Function: long fract __satfractudqsq (unsigned long long 2276 fract A) 2277 -- Runtime Function: long long fract __satfractudqdq (unsigned long 2278 long fract A) 2279 -- Runtime Function: short accum __satfractudqha (unsigned long long 2280 fract A) 2281 -- Runtime Function: accum __satfractudqsa (unsigned long long fract A) 2282 -- Runtime Function: long accum __satfractudqda (unsigned long long 2283 fract A) 2284 -- Runtime Function: long long accum __satfractudqta (unsigned long 2285 long fract A) 2286 -- Runtime Function: unsigned short fract __satfractudquqq2 (unsigned 2287 long long fract A) 2288 -- Runtime Function: unsigned fract __satfractudquhq2 (unsigned long 2289 long fract A) 2290 -- Runtime Function: unsigned long fract __satfractudqusq2 (unsigned 2291 long long fract A) 2292 -- Runtime Function: unsigned short accum __satfractudquha (unsigned 2293 long long fract A) 2294 -- Runtime Function: unsigned accum __satfractudqusa (unsigned long 2295 long fract A) 2296 -- Runtime Function: unsigned long accum __satfractudquda (unsigned 2297 long long fract A) 2298 -- Runtime Function: unsigned long long accum __satfractudquta 2299 (unsigned long long fract A) 2300 -- Runtime Function: short fract __satfractuhaqq (unsigned short accum 2301 A) 2302 -- Runtime Function: fract __satfractuhahq (unsigned short accum A) 2303 -- Runtime Function: long fract __satfractuhasq (unsigned short accum 2304 A) 2305 -- Runtime Function: long long fract __satfractuhadq (unsigned short 2306 accum A) 2307 -- Runtime Function: short accum __satfractuhaha (unsigned short accum 2308 A) 2309 -- Runtime Function: accum __satfractuhasa (unsigned short accum A) 2310 -- Runtime Function: long accum __satfractuhada (unsigned short accum 2311 A) 2312 -- Runtime Function: long long accum __satfractuhata (unsigned short 2313 accum A) 2314 -- Runtime Function: unsigned short fract __satfractuhauqq (unsigned 2315 short accum A) 2316 -- Runtime Function: unsigned fract __satfractuhauhq (unsigned short 2317 accum A) 2318 -- Runtime Function: unsigned long fract __satfractuhausq (unsigned 2319 short accum A) 2320 -- Runtime Function: unsigned long long fract __satfractuhaudq 2321 (unsigned short accum A) 2322 -- Runtime Function: unsigned accum __satfractuhausa2 (unsigned short 2323 accum A) 2324 -- Runtime Function: unsigned long accum __satfractuhauda2 (unsigned 2325 short accum A) 2326 -- Runtime Function: unsigned long long accum __satfractuhauta2 2327 (unsigned short accum A) 2328 -- Runtime Function: short fract __satfractusaqq (unsigned accum A) 2329 -- Runtime Function: fract __satfractusahq (unsigned accum A) 2330 -- Runtime Function: long fract __satfractusasq (unsigned accum A) 2331 -- Runtime Function: long long fract __satfractusadq (unsigned accum A) 2332 -- Runtime Function: short accum __satfractusaha (unsigned accum A) 2333 -- Runtime Function: accum __satfractusasa (unsigned accum A) 2334 -- Runtime Function: long accum __satfractusada (unsigned accum A) 2335 -- Runtime Function: long long accum __satfractusata (unsigned accum A) 2336 -- Runtime Function: unsigned short fract __satfractusauqq (unsigned 2337 accum A) 2338 -- Runtime Function: unsigned fract __satfractusauhq (unsigned accum A) 2339 -- Runtime Function: unsigned long fract __satfractusausq (unsigned 2340 accum A) 2341 -- Runtime Function: unsigned long long fract __satfractusaudq 2342 (unsigned accum A) 2343 -- Runtime Function: unsigned short accum __satfractusauha2 (unsigned 2344 accum A) 2345 -- Runtime Function: unsigned long accum __satfractusauda2 (unsigned 2346 accum A) 2347 -- Runtime Function: unsigned long long accum __satfractusauta2 2348 (unsigned accum A) 2349 -- Runtime Function: short fract __satfractudaqq (unsigned long accum 2350 A) 2351 -- Runtime Function: fract __satfractudahq (unsigned long accum A) 2352 -- Runtime Function: long fract __satfractudasq (unsigned long accum A) 2353 -- Runtime Function: long long fract __satfractudadq (unsigned long 2354 accum A) 2355 -- Runtime Function: short accum __satfractudaha (unsigned long accum 2356 A) 2357 -- Runtime Function: accum __satfractudasa (unsigned long accum A) 2358 -- Runtime Function: long accum __satfractudada (unsigned long accum A) 2359 -- Runtime Function: long long accum __satfractudata (unsigned long 2360 accum A) 2361 -- Runtime Function: unsigned short fract __satfractudauqq (unsigned 2362 long accum A) 2363 -- Runtime Function: unsigned fract __satfractudauhq (unsigned long 2364 accum A) 2365 -- Runtime Function: unsigned long fract __satfractudausq (unsigned 2366 long accum A) 2367 -- Runtime Function: unsigned long long fract __satfractudaudq 2368 (unsigned long accum A) 2369 -- Runtime Function: unsigned short accum __satfractudauha2 (unsigned 2370 long accum A) 2371 -- Runtime Function: unsigned accum __satfractudausa2 (unsigned long 2372 accum A) 2373 -- Runtime Function: unsigned long long accum __satfractudauta2 2374 (unsigned long accum A) 2375 -- Runtime Function: short fract __satfractutaqq (unsigned long long 2376 accum A) 2377 -- Runtime Function: fract __satfractutahq (unsigned long long accum A) 2378 -- Runtime Function: long fract __satfractutasq (unsigned long long 2379 accum A) 2380 -- Runtime Function: long long fract __satfractutadq (unsigned long 2381 long accum A) 2382 -- Runtime Function: short accum __satfractutaha (unsigned long long 2383 accum A) 2384 -- Runtime Function: accum __satfractutasa (unsigned long long accum A) 2385 -- Runtime Function: long accum __satfractutada (unsigned long long 2386 accum A) 2387 -- Runtime Function: long long accum __satfractutata (unsigned long 2388 long accum A) 2389 -- Runtime Function: unsigned short fract __satfractutauqq (unsigned 2390 long long accum A) 2391 -- Runtime Function: unsigned fract __satfractutauhq (unsigned long 2392 long accum A) 2393 -- Runtime Function: unsigned long fract __satfractutausq (unsigned 2394 long long accum A) 2395 -- Runtime Function: unsigned long long fract __satfractutaudq 2396 (unsigned long long accum A) 2397 -- Runtime Function: unsigned short accum __satfractutauha2 (unsigned 2398 long long accum A) 2399 -- Runtime Function: unsigned accum __satfractutausa2 (unsigned long 2400 long accum A) 2401 -- Runtime Function: unsigned long accum __satfractutauda2 (unsigned 2402 long long accum A) 2403 -- Runtime Function: short fract __satfractqiqq (signed char A) 2404 -- Runtime Function: fract __satfractqihq (signed char A) 2405 -- Runtime Function: long fract __satfractqisq (signed char A) 2406 -- Runtime Function: long long fract __satfractqidq (signed char A) 2407 -- Runtime Function: short accum __satfractqiha (signed char A) 2408 -- Runtime Function: accum __satfractqisa (signed char A) 2409 -- Runtime Function: long accum __satfractqida (signed char A) 2410 -- Runtime Function: long long accum __satfractqita (signed char A) 2411 -- Runtime Function: unsigned short fract __satfractqiuqq (signed char 2412 A) 2413 -- Runtime Function: unsigned fract __satfractqiuhq (signed char A) 2414 -- Runtime Function: unsigned long fract __satfractqiusq (signed char 2415 A) 2416 -- Runtime Function: unsigned long long fract __satfractqiudq (signed 2417 char A) 2418 -- Runtime Function: unsigned short accum __satfractqiuha (signed char 2419 A) 2420 -- Runtime Function: unsigned accum __satfractqiusa (signed char A) 2421 -- Runtime Function: unsigned long accum __satfractqiuda (signed char 2422 A) 2423 -- Runtime Function: unsigned long long accum __satfractqiuta (signed 2424 char A) 2425 -- Runtime Function: short fract __satfracthiqq (short A) 2426 -- Runtime Function: fract __satfracthihq (short A) 2427 -- Runtime Function: long fract __satfracthisq (short A) 2428 -- Runtime Function: long long fract __satfracthidq (short A) 2429 -- Runtime Function: short accum __satfracthiha (short A) 2430 -- Runtime Function: accum __satfracthisa (short A) 2431 -- Runtime Function: long accum __satfracthida (short A) 2432 -- Runtime Function: long long accum __satfracthita (short A) 2433 -- Runtime Function: unsigned short fract __satfracthiuqq (short A) 2434 -- Runtime Function: unsigned fract __satfracthiuhq (short A) 2435 -- Runtime Function: unsigned long fract __satfracthiusq (short A) 2436 -- Runtime Function: unsigned long long fract __satfracthiudq (short A) 2437 -- Runtime Function: unsigned short accum __satfracthiuha (short A) 2438 -- Runtime Function: unsigned accum __satfracthiusa (short A) 2439 -- Runtime Function: unsigned long accum __satfracthiuda (short A) 2440 -- Runtime Function: unsigned long long accum __satfracthiuta (short A) 2441 -- Runtime Function: short fract __satfractsiqq (int A) 2442 -- Runtime Function: fract __satfractsihq (int A) 2443 -- Runtime Function: long fract __satfractsisq (int A) 2444 -- Runtime Function: long long fract __satfractsidq (int A) 2445 -- Runtime Function: short accum __satfractsiha (int A) 2446 -- Runtime Function: accum __satfractsisa (int A) 2447 -- Runtime Function: long accum __satfractsida (int A) 2448 -- Runtime Function: long long accum __satfractsita (int A) 2449 -- Runtime Function: unsigned short fract __satfractsiuqq (int A) 2450 -- Runtime Function: unsigned fract __satfractsiuhq (int A) 2451 -- Runtime Function: unsigned long fract __satfractsiusq (int A) 2452 -- Runtime Function: unsigned long long fract __satfractsiudq (int A) 2453 -- Runtime Function: unsigned short accum __satfractsiuha (int A) 2454 -- Runtime Function: unsigned accum __satfractsiusa (int A) 2455 -- Runtime Function: unsigned long accum __satfractsiuda (int A) 2456 -- Runtime Function: unsigned long long accum __satfractsiuta (int A) 2457 -- Runtime Function: short fract __satfractdiqq (long A) 2458 -- Runtime Function: fract __satfractdihq (long A) 2459 -- Runtime Function: long fract __satfractdisq (long A) 2460 -- Runtime Function: long long fract __satfractdidq (long A) 2461 -- Runtime Function: short accum __satfractdiha (long A) 2462 -- Runtime Function: accum __satfractdisa (long A) 2463 -- Runtime Function: long accum __satfractdida (long A) 2464 -- Runtime Function: long long accum __satfractdita (long A) 2465 -- Runtime Function: unsigned short fract __satfractdiuqq (long A) 2466 -- Runtime Function: unsigned fract __satfractdiuhq (long A) 2467 -- Runtime Function: unsigned long fract __satfractdiusq (long A) 2468 -- Runtime Function: unsigned long long fract __satfractdiudq (long A) 2469 -- Runtime Function: unsigned short accum __satfractdiuha (long A) 2470 -- Runtime Function: unsigned accum __satfractdiusa (long A) 2471 -- Runtime Function: unsigned long accum __satfractdiuda (long A) 2472 -- Runtime Function: unsigned long long accum __satfractdiuta (long A) 2473 -- Runtime Function: short fract __satfracttiqq (long long A) 2474 -- Runtime Function: fract __satfracttihq (long long A) 2475 -- Runtime Function: long fract __satfracttisq (long long A) 2476 -- Runtime Function: long long fract __satfracttidq (long long A) 2477 -- Runtime Function: short accum __satfracttiha (long long A) 2478 -- Runtime Function: accum __satfracttisa (long long A) 2479 -- Runtime Function: long accum __satfracttida (long long A) 2480 -- Runtime Function: long long accum __satfracttita (long long A) 2481 -- Runtime Function: unsigned short fract __satfracttiuqq (long long A) 2482 -- Runtime Function: unsigned fract __satfracttiuhq (long long A) 2483 -- Runtime Function: unsigned long fract __satfracttiusq (long long A) 2484 -- Runtime Function: unsigned long long fract __satfracttiudq (long 2485 long A) 2486 -- Runtime Function: unsigned short accum __satfracttiuha (long long A) 2487 -- Runtime Function: unsigned accum __satfracttiusa (long long A) 2488 -- Runtime Function: unsigned long accum __satfracttiuda (long long A) 2489 -- Runtime Function: unsigned long long accum __satfracttiuta (long 2490 long A) 2491 -- Runtime Function: short fract __satfractsfqq (float A) 2492 -- Runtime Function: fract __satfractsfhq (float A) 2493 -- Runtime Function: long fract __satfractsfsq (float A) 2494 -- Runtime Function: long long fract __satfractsfdq (float A) 2495 -- Runtime Function: short accum __satfractsfha (float A) 2496 -- Runtime Function: accum __satfractsfsa (float A) 2497 -- Runtime Function: long accum __satfractsfda (float A) 2498 -- Runtime Function: long long accum __satfractsfta (float A) 2499 -- Runtime Function: unsigned short fract __satfractsfuqq (float A) 2500 -- Runtime Function: unsigned fract __satfractsfuhq (float A) 2501 -- Runtime Function: unsigned long fract __satfractsfusq (float A) 2502 -- Runtime Function: unsigned long long fract __satfractsfudq (float A) 2503 -- Runtime Function: unsigned short accum __satfractsfuha (float A) 2504 -- Runtime Function: unsigned accum __satfractsfusa (float A) 2505 -- Runtime Function: unsigned long accum __satfractsfuda (float A) 2506 -- Runtime Function: unsigned long long accum __satfractsfuta (float A) 2507 -- Runtime Function: short fract __satfractdfqq (double A) 2508 -- Runtime Function: fract __satfractdfhq (double A) 2509 -- Runtime Function: long fract __satfractdfsq (double A) 2510 -- Runtime Function: long long fract __satfractdfdq (double A) 2511 -- Runtime Function: short accum __satfractdfha (double A) 2512 -- Runtime Function: accum __satfractdfsa (double A) 2513 -- Runtime Function: long accum __satfractdfda (double A) 2514 -- Runtime Function: long long accum __satfractdfta (double A) 2515 -- Runtime Function: unsigned short fract __satfractdfuqq (double A) 2516 -- Runtime Function: unsigned fract __satfractdfuhq (double A) 2517 -- Runtime Function: unsigned long fract __satfractdfusq (double A) 2518 -- Runtime Function: unsigned long long fract __satfractdfudq (double 2519 A) 2520 -- Runtime Function: unsigned short accum __satfractdfuha (double A) 2521 -- Runtime Function: unsigned accum __satfractdfusa (double A) 2522 -- Runtime Function: unsigned long accum __satfractdfuda (double A) 2523 -- Runtime Function: unsigned long long accum __satfractdfuta (double 2524 A) 2525 The functions convert from fractional and signed non-fractionals to 2526 fractionals, with saturation. 2527 2528 -- Runtime Function: unsigned char __fractunsqqqi (short fract A) 2529 -- Runtime Function: unsigned short __fractunsqqhi (short fract A) 2530 -- Runtime Function: unsigned int __fractunsqqsi (short fract A) 2531 -- Runtime Function: unsigned long __fractunsqqdi (short fract A) 2532 -- Runtime Function: unsigned long long __fractunsqqti (short fract A) 2533 -- Runtime Function: unsigned char __fractunshqqi (fract A) 2534 -- Runtime Function: unsigned short __fractunshqhi (fract A) 2535 -- Runtime Function: unsigned int __fractunshqsi (fract A) 2536 -- Runtime Function: unsigned long __fractunshqdi (fract A) 2537 -- Runtime Function: unsigned long long __fractunshqti (fract A) 2538 -- Runtime Function: unsigned char __fractunssqqi (long fract A) 2539 -- Runtime Function: unsigned short __fractunssqhi (long fract A) 2540 -- Runtime Function: unsigned int __fractunssqsi (long fract A) 2541 -- Runtime Function: unsigned long __fractunssqdi (long fract A) 2542 -- Runtime Function: unsigned long long __fractunssqti (long fract A) 2543 -- Runtime Function: unsigned char __fractunsdqqi (long long fract A) 2544 -- Runtime Function: unsigned short __fractunsdqhi (long long fract A) 2545 -- Runtime Function: unsigned int __fractunsdqsi (long long fract A) 2546 -- Runtime Function: unsigned long __fractunsdqdi (long long fract A) 2547 -- Runtime Function: unsigned long long __fractunsdqti (long long 2548 fract A) 2549 -- Runtime Function: unsigned char __fractunshaqi (short accum A) 2550 -- Runtime Function: unsigned short __fractunshahi (short accum A) 2551 -- Runtime Function: unsigned int __fractunshasi (short accum A) 2552 -- Runtime Function: unsigned long __fractunshadi (short accum A) 2553 -- Runtime Function: unsigned long long __fractunshati (short accum A) 2554 -- Runtime Function: unsigned char __fractunssaqi (accum A) 2555 -- Runtime Function: unsigned short __fractunssahi (accum A) 2556 -- Runtime Function: unsigned int __fractunssasi (accum A) 2557 -- Runtime Function: unsigned long __fractunssadi (accum A) 2558 -- Runtime Function: unsigned long long __fractunssati (accum A) 2559 -- Runtime Function: unsigned char __fractunsdaqi (long accum A) 2560 -- Runtime Function: unsigned short __fractunsdahi (long accum A) 2561 -- Runtime Function: unsigned int __fractunsdasi (long accum A) 2562 -- Runtime Function: unsigned long __fractunsdadi (long accum A) 2563 -- Runtime Function: unsigned long long __fractunsdati (long accum A) 2564 -- Runtime Function: unsigned char __fractunstaqi (long long accum A) 2565 -- Runtime Function: unsigned short __fractunstahi (long long accum A) 2566 -- Runtime Function: unsigned int __fractunstasi (long long accum A) 2567 -- Runtime Function: unsigned long __fractunstadi (long long accum A) 2568 -- Runtime Function: unsigned long long __fractunstati (long long 2569 accum A) 2570 -- Runtime Function: unsigned char __fractunsuqqqi (unsigned short 2571 fract A) 2572 -- Runtime Function: unsigned short __fractunsuqqhi (unsigned short 2573 fract A) 2574 -- Runtime Function: unsigned int __fractunsuqqsi (unsigned short 2575 fract A) 2576 -- Runtime Function: unsigned long __fractunsuqqdi (unsigned short 2577 fract A) 2578 -- Runtime Function: unsigned long long __fractunsuqqti (unsigned 2579 short fract A) 2580 -- Runtime Function: unsigned char __fractunsuhqqi (unsigned fract A) 2581 -- Runtime Function: unsigned short __fractunsuhqhi (unsigned fract A) 2582 -- Runtime Function: unsigned int __fractunsuhqsi (unsigned fract A) 2583 -- Runtime Function: unsigned long __fractunsuhqdi (unsigned fract A) 2584 -- Runtime Function: unsigned long long __fractunsuhqti (unsigned 2585 fract A) 2586 -- Runtime Function: unsigned char __fractunsusqqi (unsigned long 2587 fract A) 2588 -- Runtime Function: unsigned short __fractunsusqhi (unsigned long 2589 fract A) 2590 -- Runtime Function: unsigned int __fractunsusqsi (unsigned long fract 2591 A) 2592 -- Runtime Function: unsigned long __fractunsusqdi (unsigned long 2593 fract A) 2594 -- Runtime Function: unsigned long long __fractunsusqti (unsigned long 2595 fract A) 2596 -- Runtime Function: unsigned char __fractunsudqqi (unsigned long long 2597 fract A) 2598 -- Runtime Function: unsigned short __fractunsudqhi (unsigned long 2599 long fract A) 2600 -- Runtime Function: unsigned int __fractunsudqsi (unsigned long long 2601 fract A) 2602 -- Runtime Function: unsigned long __fractunsudqdi (unsigned long long 2603 fract A) 2604 -- Runtime Function: unsigned long long __fractunsudqti (unsigned long 2605 long fract A) 2606 -- Runtime Function: unsigned char __fractunsuhaqi (unsigned short 2607 accum A) 2608 -- Runtime Function: unsigned short __fractunsuhahi (unsigned short 2609 accum A) 2610 -- Runtime Function: unsigned int __fractunsuhasi (unsigned short 2611 accum A) 2612 -- Runtime Function: unsigned long __fractunsuhadi (unsigned short 2613 accum A) 2614 -- Runtime Function: unsigned long long __fractunsuhati (unsigned 2615 short accum A) 2616 -- Runtime Function: unsigned char __fractunsusaqi (unsigned accum A) 2617 -- Runtime Function: unsigned short __fractunsusahi (unsigned accum A) 2618 -- Runtime Function: unsigned int __fractunsusasi (unsigned accum A) 2619 -- Runtime Function: unsigned long __fractunsusadi (unsigned accum A) 2620 -- Runtime Function: unsigned long long __fractunsusati (unsigned 2621 accum A) 2622 -- Runtime Function: unsigned char __fractunsudaqi (unsigned long 2623 accum A) 2624 -- Runtime Function: unsigned short __fractunsudahi (unsigned long 2625 accum A) 2626 -- Runtime Function: unsigned int __fractunsudasi (unsigned long accum 2627 A) 2628 -- Runtime Function: unsigned long __fractunsudadi (unsigned long 2629 accum A) 2630 -- Runtime Function: unsigned long long __fractunsudati (unsigned long 2631 accum A) 2632 -- Runtime Function: unsigned char __fractunsutaqi (unsigned long long 2633 accum A) 2634 -- Runtime Function: unsigned short __fractunsutahi (unsigned long 2635 long accum A) 2636 -- Runtime Function: unsigned int __fractunsutasi (unsigned long long 2637 accum A) 2638 -- Runtime Function: unsigned long __fractunsutadi (unsigned long long 2639 accum A) 2640 -- Runtime Function: unsigned long long __fractunsutati (unsigned long 2641 long accum A) 2642 -- Runtime Function: short fract __fractunsqiqq (unsigned char A) 2643 -- Runtime Function: fract __fractunsqihq (unsigned char A) 2644 -- Runtime Function: long fract __fractunsqisq (unsigned char A) 2645 -- Runtime Function: long long fract __fractunsqidq (unsigned char A) 2646 -- Runtime Function: short accum __fractunsqiha (unsigned char A) 2647 -- Runtime Function: accum __fractunsqisa (unsigned char A) 2648 -- Runtime Function: long accum __fractunsqida (unsigned char A) 2649 -- Runtime Function: long long accum __fractunsqita (unsigned char A) 2650 -- Runtime Function: unsigned short fract __fractunsqiuqq (unsigned 2651 char A) 2652 -- Runtime Function: unsigned fract __fractunsqiuhq (unsigned char A) 2653 -- Runtime Function: unsigned long fract __fractunsqiusq (unsigned 2654 char A) 2655 -- Runtime Function: unsigned long long fract __fractunsqiudq 2656 (unsigned char A) 2657 -- Runtime Function: unsigned short accum __fractunsqiuha (unsigned 2658 char A) 2659 -- Runtime Function: unsigned accum __fractunsqiusa (unsigned char A) 2660 -- Runtime Function: unsigned long accum __fractunsqiuda (unsigned 2661 char A) 2662 -- Runtime Function: unsigned long long accum __fractunsqiuta 2663 (unsigned char A) 2664 -- Runtime Function: short fract __fractunshiqq (unsigned short A) 2665 -- Runtime Function: fract __fractunshihq (unsigned short A) 2666 -- Runtime Function: long fract __fractunshisq (unsigned short A) 2667 -- Runtime Function: long long fract __fractunshidq (unsigned short A) 2668 -- Runtime Function: short accum __fractunshiha (unsigned short A) 2669 -- Runtime Function: accum __fractunshisa (unsigned short A) 2670 -- Runtime Function: long accum __fractunshida (unsigned short A) 2671 -- Runtime Function: long long accum __fractunshita (unsigned short A) 2672 -- Runtime Function: unsigned short fract __fractunshiuqq (unsigned 2673 short A) 2674 -- Runtime Function: unsigned fract __fractunshiuhq (unsigned short A) 2675 -- Runtime Function: unsigned long fract __fractunshiusq (unsigned 2676 short A) 2677 -- Runtime Function: unsigned long long fract __fractunshiudq 2678 (unsigned short A) 2679 -- Runtime Function: unsigned short accum __fractunshiuha (unsigned 2680 short A) 2681 -- Runtime Function: unsigned accum __fractunshiusa (unsigned short A) 2682 -- Runtime Function: unsigned long accum __fractunshiuda (unsigned 2683 short A) 2684 -- Runtime Function: unsigned long long accum __fractunshiuta 2685 (unsigned short A) 2686 -- Runtime Function: short fract __fractunssiqq (unsigned int A) 2687 -- Runtime Function: fract __fractunssihq (unsigned int A) 2688 -- Runtime Function: long fract __fractunssisq (unsigned int A) 2689 -- Runtime Function: long long fract __fractunssidq (unsigned int A) 2690 -- Runtime Function: short accum __fractunssiha (unsigned int A) 2691 -- Runtime Function: accum __fractunssisa (unsigned int A) 2692 -- Runtime Function: long accum __fractunssida (unsigned int A) 2693 -- Runtime Function: long long accum __fractunssita (unsigned int A) 2694 -- Runtime Function: unsigned short fract __fractunssiuqq (unsigned 2695 int A) 2696 -- Runtime Function: unsigned fract __fractunssiuhq (unsigned int A) 2697 -- Runtime Function: unsigned long fract __fractunssiusq (unsigned int 2698 A) 2699 -- Runtime Function: unsigned long long fract __fractunssiudq 2700 (unsigned int A) 2701 -- Runtime Function: unsigned short accum __fractunssiuha (unsigned 2702 int A) 2703 -- Runtime Function: unsigned accum __fractunssiusa (unsigned int A) 2704 -- Runtime Function: unsigned long accum __fractunssiuda (unsigned int 2705 A) 2706 -- Runtime Function: unsigned long long accum __fractunssiuta 2707 (unsigned int A) 2708 -- Runtime Function: short fract __fractunsdiqq (unsigned long A) 2709 -- Runtime Function: fract __fractunsdihq (unsigned long A) 2710 -- Runtime Function: long fract __fractunsdisq (unsigned long A) 2711 -- Runtime Function: long long fract __fractunsdidq (unsigned long A) 2712 -- Runtime Function: short accum __fractunsdiha (unsigned long A) 2713 -- Runtime Function: accum __fractunsdisa (unsigned long A) 2714 -- Runtime Function: long accum __fractunsdida (unsigned long A) 2715 -- Runtime Function: long long accum __fractunsdita (unsigned long A) 2716 -- Runtime Function: unsigned short fract __fractunsdiuqq (unsigned 2717 long A) 2718 -- Runtime Function: unsigned fract __fractunsdiuhq (unsigned long A) 2719 -- Runtime Function: unsigned long fract __fractunsdiusq (unsigned 2720 long A) 2721 -- Runtime Function: unsigned long long fract __fractunsdiudq 2722 (unsigned long A) 2723 -- Runtime Function: unsigned short accum __fractunsdiuha (unsigned 2724 long A) 2725 -- Runtime Function: unsigned accum __fractunsdiusa (unsigned long A) 2726 -- Runtime Function: unsigned long accum __fractunsdiuda (unsigned 2727 long A) 2728 -- Runtime Function: unsigned long long accum __fractunsdiuta 2729 (unsigned long A) 2730 -- Runtime Function: short fract __fractunstiqq (unsigned long long A) 2731 -- Runtime Function: fract __fractunstihq (unsigned long long A) 2732 -- Runtime Function: long fract __fractunstisq (unsigned long long A) 2733 -- Runtime Function: long long fract __fractunstidq (unsigned long 2734 long A) 2735 -- Runtime Function: short accum __fractunstiha (unsigned long long A) 2736 -- Runtime Function: accum __fractunstisa (unsigned long long A) 2737 -- Runtime Function: long accum __fractunstida (unsigned long long A) 2738 -- Runtime Function: long long accum __fractunstita (unsigned long 2739 long A) 2740 -- Runtime Function: unsigned short fract __fractunstiuqq (unsigned 2741 long long A) 2742 -- Runtime Function: unsigned fract __fractunstiuhq (unsigned long 2743 long A) 2744 -- Runtime Function: unsigned long fract __fractunstiusq (unsigned 2745 long long A) 2746 -- Runtime Function: unsigned long long fract __fractunstiudq 2747 (unsigned long long A) 2748 -- Runtime Function: unsigned short accum __fractunstiuha (unsigned 2749 long long A) 2750 -- Runtime Function: unsigned accum __fractunstiusa (unsigned long 2751 long A) 2752 -- Runtime Function: unsigned long accum __fractunstiuda (unsigned 2753 long long A) 2754 -- Runtime Function: unsigned long long accum __fractunstiuta 2755 (unsigned long long A) 2756 These functions convert from fractionals to unsigned 2757 non-fractionals; and from unsigned non-fractionals to fractionals, 2758 without saturation. 2759 2760 -- Runtime Function: short fract __satfractunsqiqq (unsigned char A) 2761 -- Runtime Function: fract __satfractunsqihq (unsigned char A) 2762 -- Runtime Function: long fract __satfractunsqisq (unsigned char A) 2763 -- Runtime Function: long long fract __satfractunsqidq (unsigned char 2764 A) 2765 -- Runtime Function: short accum __satfractunsqiha (unsigned char A) 2766 -- Runtime Function: accum __satfractunsqisa (unsigned char A) 2767 -- Runtime Function: long accum __satfractunsqida (unsigned char A) 2768 -- Runtime Function: long long accum __satfractunsqita (unsigned char 2769 A) 2770 -- Runtime Function: unsigned short fract __satfractunsqiuqq (unsigned 2771 char A) 2772 -- Runtime Function: unsigned fract __satfractunsqiuhq (unsigned char 2773 A) 2774 -- Runtime Function: unsigned long fract __satfractunsqiusq (unsigned 2775 char A) 2776 -- Runtime Function: unsigned long long fract __satfractunsqiudq 2777 (unsigned char A) 2778 -- Runtime Function: unsigned short accum __satfractunsqiuha (unsigned 2779 char A) 2780 -- Runtime Function: unsigned accum __satfractunsqiusa (unsigned char 2781 A) 2782 -- Runtime Function: unsigned long accum __satfractunsqiuda (unsigned 2783 char A) 2784 -- Runtime Function: unsigned long long accum __satfractunsqiuta 2785 (unsigned char A) 2786 -- Runtime Function: short fract __satfractunshiqq (unsigned short A) 2787 -- Runtime Function: fract __satfractunshihq (unsigned short A) 2788 -- Runtime Function: long fract __satfractunshisq (unsigned short A) 2789 -- Runtime Function: long long fract __satfractunshidq (unsigned short 2790 A) 2791 -- Runtime Function: short accum __satfractunshiha (unsigned short A) 2792 -- Runtime Function: accum __satfractunshisa (unsigned short A) 2793 -- Runtime Function: long accum __satfractunshida (unsigned short A) 2794 -- Runtime Function: long long accum __satfractunshita (unsigned short 2795 A) 2796 -- Runtime Function: unsigned short fract __satfractunshiuqq (unsigned 2797 short A) 2798 -- Runtime Function: unsigned fract __satfractunshiuhq (unsigned short 2799 A) 2800 -- Runtime Function: unsigned long fract __satfractunshiusq (unsigned 2801 short A) 2802 -- Runtime Function: unsigned long long fract __satfractunshiudq 2803 (unsigned short A) 2804 -- Runtime Function: unsigned short accum __satfractunshiuha (unsigned 2805 short A) 2806 -- Runtime Function: unsigned accum __satfractunshiusa (unsigned short 2807 A) 2808 -- Runtime Function: unsigned long accum __satfractunshiuda (unsigned 2809 short A) 2810 -- Runtime Function: unsigned long long accum __satfractunshiuta 2811 (unsigned short A) 2812 -- Runtime Function: short fract __satfractunssiqq (unsigned int A) 2813 -- Runtime Function: fract __satfractunssihq (unsigned int A) 2814 -- Runtime Function: long fract __satfractunssisq (unsigned int A) 2815 -- Runtime Function: long long fract __satfractunssidq (unsigned int A) 2816 -- Runtime Function: short accum __satfractunssiha (unsigned int A) 2817 -- Runtime Function: accum __satfractunssisa (unsigned int A) 2818 -- Runtime Function: long accum __satfractunssida (unsigned int A) 2819 -- Runtime Function: long long accum __satfractunssita (unsigned int A) 2820 -- Runtime Function: unsigned short fract __satfractunssiuqq (unsigned 2821 int A) 2822 -- Runtime Function: unsigned fract __satfractunssiuhq (unsigned int A) 2823 -- Runtime Function: unsigned long fract __satfractunssiusq (unsigned 2824 int A) 2825 -- Runtime Function: unsigned long long fract __satfractunssiudq 2826 (unsigned int A) 2827 -- Runtime Function: unsigned short accum __satfractunssiuha (unsigned 2828 int A) 2829 -- Runtime Function: unsigned accum __satfractunssiusa (unsigned int A) 2830 -- Runtime Function: unsigned long accum __satfractunssiuda (unsigned 2831 int A) 2832 -- Runtime Function: unsigned long long accum __satfractunssiuta 2833 (unsigned int A) 2834 -- Runtime Function: short fract __satfractunsdiqq (unsigned long A) 2835 -- Runtime Function: fract __satfractunsdihq (unsigned long A) 2836 -- Runtime Function: long fract __satfractunsdisq (unsigned long A) 2837 -- Runtime Function: long long fract __satfractunsdidq (unsigned long 2838 A) 2839 -- Runtime Function: short accum __satfractunsdiha (unsigned long A) 2840 -- Runtime Function: accum __satfractunsdisa (unsigned long A) 2841 -- Runtime Function: long accum __satfractunsdida (unsigned long A) 2842 -- Runtime Function: long long accum __satfractunsdita (unsigned long 2843 A) 2844 -- Runtime Function: unsigned short fract __satfractunsdiuqq (unsigned 2845 long A) 2846 -- Runtime Function: unsigned fract __satfractunsdiuhq (unsigned long 2847 A) 2848 -- Runtime Function: unsigned long fract __satfractunsdiusq (unsigned 2849 long A) 2850 -- Runtime Function: unsigned long long fract __satfractunsdiudq 2851 (unsigned long A) 2852 -- Runtime Function: unsigned short accum __satfractunsdiuha (unsigned 2853 long A) 2854 -- Runtime Function: unsigned accum __satfractunsdiusa (unsigned long 2855 A) 2856 -- Runtime Function: unsigned long accum __satfractunsdiuda (unsigned 2857 long A) 2858 -- Runtime Function: unsigned long long accum __satfractunsdiuta 2859 (unsigned long A) 2860 -- Runtime Function: short fract __satfractunstiqq (unsigned long long 2861 A) 2862 -- Runtime Function: fract __satfractunstihq (unsigned long long A) 2863 -- Runtime Function: long fract __satfractunstisq (unsigned long long 2864 A) 2865 -- Runtime Function: long long fract __satfractunstidq (unsigned long 2866 long A) 2867 -- Runtime Function: short accum __satfractunstiha (unsigned long long 2868 A) 2869 -- Runtime Function: accum __satfractunstisa (unsigned long long A) 2870 -- Runtime Function: long accum __satfractunstida (unsigned long long 2871 A) 2872 -- Runtime Function: long long accum __satfractunstita (unsigned long 2873 long A) 2874 -- Runtime Function: unsigned short fract __satfractunstiuqq (unsigned 2875 long long A) 2876 -- Runtime Function: unsigned fract __satfractunstiuhq (unsigned long 2877 long A) 2878 -- Runtime Function: unsigned long fract __satfractunstiusq (unsigned 2879 long long A) 2880 -- Runtime Function: unsigned long long fract __satfractunstiudq 2881 (unsigned long long A) 2882 -- Runtime Function: unsigned short accum __satfractunstiuha (unsigned 2883 long long A) 2884 -- Runtime Function: unsigned accum __satfractunstiusa (unsigned long 2885 long A) 2886 -- Runtime Function: unsigned long accum __satfractunstiuda (unsigned 2887 long long A) 2888 -- Runtime Function: unsigned long long accum __satfractunstiuta 2889 (unsigned long long A) 2890 These functions convert from unsigned non-fractionals to 2891 fractionals, with saturation. 2892 2893 2894File: gccint.info, Node: Exception handling routines, Next: Miscellaneous routines, Prev: Fixed-point fractional library routines, Up: Libgcc 2895 28964.5 Language-independent routines for exception handling 2897======================================================== 2898 2899document me! 2900 2901 _Unwind_DeleteException 2902 _Unwind_Find_FDE 2903 _Unwind_ForcedUnwind 2904 _Unwind_GetGR 2905 _Unwind_GetIP 2906 _Unwind_GetLanguageSpecificData 2907 _Unwind_GetRegionStart 2908 _Unwind_GetTextRelBase 2909 _Unwind_GetDataRelBase 2910 _Unwind_RaiseException 2911 _Unwind_Resume 2912 _Unwind_SetGR 2913 _Unwind_SetIP 2914 _Unwind_FindEnclosingFunction 2915 _Unwind_SjLj_Register 2916 _Unwind_SjLj_Unregister 2917 _Unwind_SjLj_RaiseException 2918 _Unwind_SjLj_ForcedUnwind 2919 _Unwind_SjLj_Resume 2920 __deregister_frame 2921 __deregister_frame_info 2922 __deregister_frame_info_bases 2923 __register_frame 2924 __register_frame_info 2925 __register_frame_info_bases 2926 __register_frame_info_table 2927 __register_frame_info_table_bases 2928 __register_frame_table 2929 2930 2931File: gccint.info, Node: Miscellaneous routines, Prev: Exception handling routines, Up: Libgcc 2932 29334.6 Miscellaneous runtime library routines 2934========================================== 2935 29364.6.1 Cache control functions 2937----------------------------- 2938 2939 -- Runtime Function: void __clear_cache (char *BEG, char *END) 2940 This function clears the instruction cache between BEG and END. 2941 2942 2943File: gccint.info, Node: Languages, Next: Source Tree, Prev: Libgcc, Up: Top 2944 29455 Language Front Ends in GCC 2946**************************** 2947 2948The interface to front ends for languages in GCC, and in particular the 2949`tree' structure (*note GENERIC::), was initially designed for C, and 2950many aspects of it are still somewhat biased towards C and C-like 2951languages. It is, however, reasonably well suited to other procedural 2952languages, and front ends for many such languages have been written for 2953GCC. 2954 2955 Writing a compiler as a front end for GCC, rather than compiling 2956directly to assembler or generating C code which is then compiled by 2957GCC, has several advantages: 2958 2959 * GCC front ends benefit from the support for many different target 2960 machines already present in GCC. 2961 2962 * GCC front ends benefit from all the optimizations in GCC. Some of 2963 these, such as alias analysis, may work better when GCC is 2964 compiling directly from source code then when it is compiling from 2965 generated C code. 2966 2967 * Better debugging information is generated when compiling directly 2968 from source code than when going via intermediate generated C code. 2969 2970 Because of the advantages of writing a compiler as a GCC front end, 2971GCC front ends have also been created for languages very different from 2972those for which GCC was designed, such as the declarative 2973logic/functional language Mercury. For these reasons, it may also be 2974useful to implement compilers created for specialized purposes (for 2975example, as part of a research project) as GCC front ends. 2976 2977 2978File: gccint.info, Node: Source Tree, Next: Testsuites, Prev: Languages, Up: Top 2979 29806 Source Tree Structure and Build System 2981**************************************** 2982 2983This chapter describes the structure of the GCC source tree, and how 2984GCC is built. The user documentation for building and installing GCC 2985is in a separate manual (`http://gcc.gnu.org/install/'), with which it 2986is presumed that you are familiar. 2987 2988* Menu: 2989 2990* Configure Terms:: Configuration terminology and history. 2991* Top Level:: The top level source directory. 2992* gcc Directory:: The `gcc' subdirectory. 2993 2994 2995File: gccint.info, Node: Configure Terms, Next: Top Level, Up: Source Tree 2996 29976.1 Configure Terms and History 2998=============================== 2999 3000The configure and build process has a long and colorful history, and can 3001be confusing to anyone who doesn't know why things are the way they are. 3002While there are other documents which describe the configuration process 3003in detail, here are a few things that everyone working on GCC should 3004know. 3005 3006 There are three system names that the build knows about: the machine 3007you are building on ("build"), the machine that you are building for 3008("host"), and the machine that GCC will produce code for ("target"). 3009When you configure GCC, you specify these with `--build=', `--host=', 3010and `--target='. 3011 3012 Specifying the host without specifying the build should be avoided, as 3013`configure' may (and once did) assume that the host you specify is also 3014the build, which may not be true. 3015 3016 If build, host, and target are all the same, this is called a 3017"native". If build and host are the same but target is different, this 3018is called a "cross". If build, host, and target are all different this 3019is called a "canadian" (for obscure reasons dealing with Canada's 3020political party and the background of the person working on the build 3021at that time). If host and target are the same, but build is 3022different, you are using a cross-compiler to build a native for a 3023different system. Some people call this a "host-x-host", "crossed 3024native", or "cross-built native". If build and target are the same, 3025but host is different, you are using a cross compiler to build a cross 3026compiler that produces code for the machine you're building on. This 3027is rare, so there is no common way of describing it. There is a 3028proposal to call this a "crossback". 3029 3030 If build and host are the same, the GCC you are building will also be 3031used to build the target libraries (like `libstdc++'). If build and 3032host are different, you must have already built and installed a cross 3033compiler that will be used to build the target libraries (if you 3034configured with `--target=foo-bar', this compiler will be called 3035`foo-bar-gcc'). 3036 3037 In the case of target libraries, the machine you're building for is the 3038machine you specified with `--target'. So, build is the machine you're 3039building on (no change there), host is the machine you're building for 3040(the target libraries are built for the target, so host is the target 3041you specified), and target doesn't apply (because you're not building a 3042compiler, you're building libraries). The configure/make process will 3043adjust these variables as needed. It also sets `$with_cross_host' to 3044the original `--host' value in case you need it. 3045 3046 The `libiberty' support library is built up to three times: once for 3047the host, once for the target (even if they are the same), and once for 3048the build if build and host are different. This allows it to be used 3049by all programs which are generated in the course of the build process. 3050 3051 3052File: gccint.info, Node: Top Level, Next: gcc Directory, Prev: Configure Terms, Up: Source Tree 3053 30546.2 Top Level Source Directory 3055============================== 3056 3057The top level source directory in a GCC distribution contains several 3058files and directories that are shared with other software distributions 3059such as that of GNU Binutils. It also contains several subdirectories 3060that contain parts of GCC and its runtime libraries: 3061 3062`boehm-gc' 3063 The Boehm conservative garbage collector, used as part of the Java 3064 runtime library. 3065 3066`config' 3067 Autoconf macros and Makefile fragments used throughout the tree. 3068 3069`contrib' 3070 Contributed scripts that may be found useful in conjunction with 3071 GCC. One of these, `contrib/texi2pod.pl', is used to generate man 3072 pages from Texinfo manuals as part of the GCC build process. 3073 3074`fixincludes' 3075 The support for fixing system headers to work with GCC. See 3076 `fixincludes/README' for more information. The headers fixed by 3077 this mechanism are installed in `LIBSUBDIR/include-fixed'. Along 3078 with those headers, `README-fixinc' is also installed, as 3079 `LIBSUBDIR/include-fixed/README'. 3080 3081`gcc' 3082 The main sources of GCC itself (except for runtime libraries), 3083 including optimizers, support for different target architectures, 3084 language front ends, and testsuites. *Note The `gcc' 3085 Subdirectory: gcc Directory, for details. 3086 3087`gnattools' 3088 Support tools for GNAT. 3089 3090`include' 3091 Headers for the `libiberty' library. 3092 3093`intl' 3094 GNU `libintl', from GNU `gettext', for systems which do not 3095 include it in `libc'. 3096 3097`libada' 3098 The Ada runtime library. 3099 3100`libcpp' 3101 The C preprocessor library. 3102 3103`libdecnumber' 3104 The Decimal Float support library. 3105 3106`libffi' 3107 The `libffi' library, used as part of the Java runtime library. 3108 3109`libgcc' 3110 The GCC runtime library. 3111 3112`libgfortran' 3113 The Fortran runtime library. 3114 3115`libgomp' 3116 The GNU OpenMP runtime library. 3117 3118`libiberty' 3119 The `libiberty' library, used for portability and for some 3120 generally useful data structures and algorithms. *Note 3121 Introduction: (libiberty)Top, for more information about this 3122 library. 3123 3124`libjava' 3125 The Java runtime library. 3126 3127`libmudflap' 3128 The `libmudflap' library, used for instrumenting pointer and array 3129 dereferencing operations. 3130 3131`libobjc' 3132 The Objective-C and Objective-C++ runtime library. 3133 3134`libssp' 3135 The Stack protector runtime library. 3136 3137`libstdc++-v3' 3138 The C++ runtime library. 3139 3140`lto-plugin' 3141 Plugin used by `gold' if link-time optimizations are enabled. 3142 3143`maintainer-scripts' 3144 Scripts used by the `gccadmin' account on `gcc.gnu.org'. 3145 3146`zlib' 3147 The `zlib' compression library, used by the Java front end, as 3148 part of the Java runtime library, and for compressing and 3149 uncompressing GCC's intermediate language in LTO object files. 3150 3151 The build system in the top level directory, including how recursion 3152into subdirectories works and how building runtime libraries for 3153multilibs is handled, is documented in a separate manual, included with 3154GNU Binutils. *Note GNU configure and build system: (configure)Top, 3155for details. 3156 3157 3158File: gccint.info, Node: gcc Directory, Prev: Top Level, Up: Source Tree 3159 31606.3 The `gcc' Subdirectory 3161========================== 3162 3163The `gcc' directory contains many files that are part of the C sources 3164of GCC, other files used as part of the configuration and build 3165process, and subdirectories including documentation and a testsuite. 3166The files that are sources of GCC are documented in a separate chapter. 3167*Note Passes and Files of the Compiler: Passes. 3168 3169* Menu: 3170 3171* Subdirectories:: Subdirectories of `gcc'. 3172* Configuration:: The configuration process, and the files it uses. 3173* Build:: The build system in the `gcc' directory. 3174* Makefile:: Targets in `gcc/Makefile'. 3175* Library Files:: Library source files and headers under `gcc/'. 3176* Headers:: Headers installed by GCC. 3177* Documentation:: Building documentation in GCC. 3178* Front End:: Anatomy of a language front end. 3179* Back End:: Anatomy of a target back end. 3180 3181 3182File: gccint.info, Node: Subdirectories, Next: Configuration, Up: gcc Directory 3183 31846.3.1 Subdirectories of `gcc' 3185----------------------------- 3186 3187The `gcc' directory contains the following subdirectories: 3188 3189`LANGUAGE' 3190 Subdirectories for various languages. Directories containing a 3191 file `config-lang.in' are language subdirectories. The contents of 3192 the subdirectories `cp' (for C++), `lto' (for LTO), `objc' (for 3193 Objective-C) and `objcp' (for Objective-C++) are documented in 3194 this manual (*note Passes and Files of the Compiler: Passes.); 3195 those for other languages are not. *Note Anatomy of a Language 3196 Front End: Front End, for details of the files in these 3197 directories. 3198 3199`config' 3200 Configuration files for supported architectures and operating 3201 systems. *Note Anatomy of a Target Back End: Back End, for 3202 details of the files in this directory. 3203 3204`doc' 3205 Texinfo documentation for GCC, together with automatically 3206 generated man pages and support for converting the installation 3207 manual to HTML. *Note Documentation::. 3208 3209`ginclude' 3210 System headers installed by GCC, mainly those required by the C 3211 standard of freestanding implementations. *Note Headers Installed 3212 by GCC: Headers, for details of when these and other headers are 3213 installed. 3214 3215`po' 3216 Message catalogs with translations of messages produced by GCC into 3217 various languages, `LANGUAGE.po'. This directory also contains 3218 `gcc.pot', the template for these message catalogues, `exgettext', 3219 a wrapper around `gettext' to extract the messages from the GCC 3220 sources and create `gcc.pot', which is run by `make gcc.pot', and 3221 `EXCLUDES', a list of files from which messages should not be 3222 extracted. 3223 3224`testsuite' 3225 The GCC testsuites (except for those for runtime libraries). 3226 *Note Testsuites::. 3227 3228 3229File: gccint.info, Node: Configuration, Next: Build, Prev: Subdirectories, Up: gcc Directory 3230 32316.3.2 Configuration in the `gcc' Directory 3232------------------------------------------ 3233 3234The `gcc' directory is configured with an Autoconf-generated script 3235`configure'. The `configure' script is generated from `configure.ac' 3236and `aclocal.m4'. From the files `configure.ac' and `acconfig.h', 3237Autoheader generates the file `config.in'. The file `cstamp-h.in' is 3238used as a timestamp. 3239 3240* Menu: 3241 3242* Config Fragments:: Scripts used by `configure'. 3243* System Config:: The `config.build', `config.host', and 3244 `config.gcc' files. 3245* Configuration Files:: Files created by running `configure'. 3246 3247 3248File: gccint.info, Node: Config Fragments, Next: System Config, Up: Configuration 3249 32506.3.2.1 Scripts Used by `configure' 3251................................... 3252 3253`configure' uses some other scripts to help in its work: 3254 3255 * The standard GNU `config.sub' and `config.guess' files, kept in 3256 the top level directory, are used. 3257 3258 * The file `config.gcc' is used to handle configuration specific to 3259 the particular target machine. The file `config.build' is used to 3260 handle configuration specific to the particular build machine. 3261 The file `config.host' is used to handle configuration specific to 3262 the particular host machine. (In general, these should only be 3263 used for features that cannot reasonably be tested in Autoconf 3264 feature tests.) *Note The `config.build'; `config.host'; and 3265 `config.gcc' Files: System Config, for details of the contents of 3266 these files. 3267 3268 * Each language subdirectory has a file `LANGUAGE/config-lang.in' 3269 that is used for front-end-specific configuration. *Note The 3270 Front End `config-lang.in' File: Front End Config, for details of 3271 this file. 3272 3273 * A helper script `configure.frag' is used as part of creating the 3274 output of `configure'. 3275 3276 3277File: gccint.info, Node: System Config, Next: Configuration Files, Prev: Config Fragments, Up: Configuration 3278 32796.3.2.2 The `config.build'; `config.host'; and `config.gcc' Files 3280................................................................. 3281 3282The `config.build' file contains specific rules for particular systems 3283which GCC is built on. This should be used as rarely as possible, as 3284the behavior of the build system can always be detected by autoconf. 3285 3286 The `config.host' file contains specific rules for particular systems 3287which GCC will run on. This is rarely needed. 3288 3289 The `config.gcc' file contains specific rules for particular systems 3290which GCC will generate code for. This is usually needed. 3291 3292 Each file has a list of the shell variables it sets, with 3293descriptions, at the top of the file. 3294 3295 FIXME: document the contents of these files, and what variables should 3296be set to control build, host and target configuration. 3297 3298 3299File: gccint.info, Node: Configuration Files, Prev: System Config, Up: Configuration 3300 33016.3.2.3 Files Created by `configure' 3302.................................... 3303 3304Here we spell out what files will be set up by `configure' in the `gcc' 3305directory. Some other files are created as temporary files in the 3306configuration process, and are not used in the subsequent build; these 3307are not documented. 3308 3309 * `Makefile' is constructed from `Makefile.in', together with the 3310 host and target fragments (*note Makefile Fragments: Fragments.) 3311 `t-TARGET' and `x-HOST' from `config', if any, and language 3312 Makefile fragments `LANGUAGE/Make-lang.in'. 3313 3314 * `auto-host.h' contains information about the host machine 3315 determined by `configure'. If the host machine is different from 3316 the build machine, then `auto-build.h' is also created, containing 3317 such information about the build machine. 3318 3319 * `config.status' is a script that may be run to recreate the 3320 current configuration. 3321 3322 * `configargs.h' is a header containing details of the arguments 3323 passed to `configure' to configure GCC, and of the thread model 3324 used. 3325 3326 * `cstamp-h' is used as a timestamp. 3327 3328 * `gccbug', a script for reporting bugs in GCC, is constructed from 3329 `gccbug.in'. 3330 3331 * If a language `config-lang.in' file (*note The Front End 3332 `config-lang.in' File: Front End Config.) sets `outputs', then the 3333 files listed in `outputs' there are also generated. 3334 3335 The following configuration headers are created from the Makefile, 3336using `mkconfig.sh', rather than directly by `configure'. `config.h', 3337`bconfig.h' and `tconfig.h' all contain the `xm-MACHINE.h' header, if 3338any, appropriate to the host, build and target machines respectively, 3339the configuration headers for the target, and some definitions; for the 3340host and build machines, these include the autoconfigured headers 3341generated by `configure'. The other configuration headers are 3342determined by `config.gcc'. They also contain the typedefs for `rtx', 3343`rtvec' and `tree'. 3344 3345 * `config.h', for use in programs that run on the host machine. 3346 3347 * `bconfig.h', for use in programs that run on the build machine. 3348 3349 * `tconfig.h', for use in programs and libraries for the target 3350 machine. 3351 3352 * `tm_p.h', which includes the header `MACHINE-protos.h' that 3353 contains prototypes for functions in the target `.c' file. FIXME: 3354 why is such a separate header necessary? 3355 3356 3357File: gccint.info, Node: Build, Next: Makefile, Prev: Configuration, Up: gcc Directory 3358 33596.3.3 Build System in the `gcc' Directory 3360----------------------------------------- 3361 3362FIXME: describe the build system, including what is built in what 3363stages. Also list the various source files that are used in the build 3364process but aren't source files of GCC itself and so aren't documented 3365below (*note Passes::). 3366 3367 3368File: gccint.info, Node: Makefile, Next: Library Files, Prev: Build, Up: gcc Directory 3369 33706.3.4 Makefile Targets 3371---------------------- 3372 3373These targets are available from the `gcc' directory: 3374 3375`all' 3376 This is the default target. Depending on what your 3377 build/host/target configuration is, it coordinates all the things 3378 that need to be built. 3379 3380`doc' 3381 Produce info-formatted documentation and man pages. Essentially it 3382 calls `make man' and `make info'. 3383 3384`dvi' 3385 Produce DVI-formatted documentation. 3386 3387`pdf' 3388 Produce PDF-formatted documentation. 3389 3390`html' 3391 Produce HTML-formatted documentation. 3392 3393`man' 3394 Generate man pages. 3395 3396`info' 3397 Generate info-formatted pages. 3398 3399`mostlyclean' 3400 Delete the files made while building the compiler. 3401 3402`clean' 3403 That, and all the other files built by `make all'. 3404 3405`distclean' 3406 That, and all the files created by `configure'. 3407 3408`maintainer-clean' 3409 Distclean plus any file that can be generated from other files. 3410 Note that additional tools may be required beyond what is normally 3411 needed to build GCC. 3412 3413`srcextra' 3414 Generates files in the source directory that are not 3415 version-controlled but should go into a release tarball. 3416 3417`srcinfo' 3418`srcman' 3419 Copies the info-formatted and manpage documentation into the source 3420 directory usually for the purpose of generating a release tarball. 3421 3422`install' 3423 Installs GCC. 3424 3425`uninstall' 3426 Deletes installed files, though this is not supported. 3427 3428`check' 3429 Run the testsuite. This creates a `testsuite' subdirectory that 3430 has various `.sum' and `.log' files containing the results of the 3431 testing. You can run subsets with, for example, `make check-gcc'. 3432 You can specify specific tests by setting `RUNTESTFLAGS' to be the 3433 name of the `.exp' file, optionally followed by (for some tests) 3434 an equals and a file wildcard, like: 3435 3436 make check-gcc RUNTESTFLAGS="execute.exp=19980413-*" 3437 3438 Note that running the testsuite may require additional tools be 3439 installed, such as Tcl or DejaGnu. 3440 3441 The toplevel tree from which you start GCC compilation is not the GCC 3442directory, but rather a complex Makefile that coordinates the various 3443steps of the build, including bootstrapping the compiler and using the 3444new compiler to build target libraries. 3445 3446 When GCC is configured for a native configuration, the default action 3447for `make' is to do a full three-stage bootstrap. This means that GCC 3448is built three times--once with the native compiler, once with the 3449native-built compiler it just built, and once with the compiler it 3450built the second time. In theory, the last two should produce the same 3451results, which `make compare' can check. Each stage is configured 3452separately and compiled into a separate directory, to minimize problems 3453due to ABI incompatibilities between the native compiler and GCC. 3454 3455 If you do a change, rebuilding will also start from the first stage 3456and "bubble" up the change through the three stages. Each stage is 3457taken from its build directory (if it had been built previously), 3458rebuilt, and copied to its subdirectory. This will allow you to, for 3459example, continue a bootstrap after fixing a bug which causes the 3460stage2 build to crash. It does not provide as good coverage of the 3461compiler as bootstrapping from scratch, but it ensures that the new 3462code is syntactically correct (e.g., that you did not use GCC extensions 3463by mistake), and avoids spurious bootstrap comparison failures(1). 3464 3465 Other targets available from the top level include: 3466 3467`bootstrap-lean' 3468 Like `bootstrap', except that the various stages are removed once 3469 they're no longer needed. This saves disk space. 3470 3471`bootstrap2' 3472`bootstrap2-lean' 3473 Performs only the first two stages of bootstrap. Unlike a 3474 three-stage bootstrap, this does not perform a comparison to test 3475 that the compiler is running properly. Note that the disk space 3476 required by a "lean" bootstrap is approximately independent of the 3477 number of stages. 3478 3479`stageN-bubble (N = 1...4)' 3480 Rebuild all the stages up to N, with the appropriate flags, 3481 "bubbling" the changes as described above. 3482 3483`all-stageN (N = 1...4)' 3484 Assuming that stage N has already been built, rebuild it with the 3485 appropriate flags. This is rarely needed. 3486 3487`cleanstrap' 3488 Remove everything (`make clean') and rebuilds (`make bootstrap'). 3489 3490`compare' 3491 Compares the results of stages 2 and 3. This ensures that the 3492 compiler is running properly, since it should produce the same 3493 object files regardless of how it itself was compiled. 3494 3495`profiledbootstrap' 3496 Builds a compiler with profiling feedback information. For more 3497 information, see *note Building with profile feedback: 3498 (gccinstall)Building. 3499 3500`restrap' 3501 Restart a bootstrap, so that everything that was not built with 3502 the system compiler is rebuilt. 3503 3504`stageN-start (N = 1...4)' 3505 For each package that is bootstrapped, rename directories so that, 3506 for example, `gcc' points to the stageN GCC, compiled with the 3507 stageN-1 GCC(2). 3508 3509 You will invoke this target if you need to test or debug the 3510 stageN GCC. If you only need to execute GCC (but you need not run 3511 `make' either to rebuild it or to run test suites), you should be 3512 able to work directly in the `stageN-gcc' directory. This makes 3513 it easier to debug multiple stages in parallel. 3514 3515`stage' 3516 For each package that is bootstrapped, relocate its build directory 3517 to indicate its stage. For example, if the `gcc' directory points 3518 to the stage2 GCC, after invoking this target it will be renamed 3519 to `stage2-gcc'. 3520 3521 3522 If you wish to use non-default GCC flags when compiling the stage2 and 3523stage3 compilers, set `BOOT_CFLAGS' on the command line when doing 3524`make'. 3525 3526 Usually, the first stage only builds the languages that the compiler 3527is written in: typically, C and maybe Ada. If you are debugging a 3528miscompilation of a different stage2 front-end (for example, of the 3529Fortran front-end), you may want to have front-ends for other languages 3530in the first stage as well. To do so, set `STAGE1_LANGUAGES' on the 3531command line when doing `make'. 3532 3533 For example, in the aforementioned scenario of debugging a Fortran 3534front-end miscompilation caused by the stage1 compiler, you may need a 3535command like 3536 3537 make stage2-bubble STAGE1_LANGUAGES=c,fortran 3538 3539 Alternatively, you can use per-language targets to build and test 3540languages that are not enabled by default in stage1. For example, 3541`make f951' will build a Fortran compiler even in the stage1 build 3542directory. 3543 3544 ---------- Footnotes ---------- 3545 3546 (1) Except if the compiler was buggy and miscompiled some of the files 3547that were not modified. In this case, it's best to use `make restrap'. 3548 3549 (2) Customarily, the system compiler is also termed the `stage0' GCC. 3550 3551 3552File: gccint.info, Node: Library Files, Next: Headers, Prev: Makefile, Up: gcc Directory 3553 35546.3.5 Library Source Files and Headers under the `gcc' Directory 3555---------------------------------------------------------------- 3556 3557FIXME: list here, with explanation, all the C source files and headers 3558under the `gcc' directory that aren't built into the GCC executable but 3559rather are part of runtime libraries and object files, such as 3560`crtstuff.c' and `unwind-dw2.c'. *Note Headers Installed by GCC: 3561Headers, for more information about the `ginclude' directory. 3562 3563 3564File: gccint.info, Node: Headers, Next: Documentation, Prev: Library Files, Up: gcc Directory 3565 35666.3.6 Headers Installed by GCC 3567------------------------------ 3568 3569In general, GCC expects the system C library to provide most of the 3570headers to be used with it. However, GCC will fix those headers if 3571necessary to make them work with GCC, and will install some headers 3572required of freestanding implementations. These headers are installed 3573in `LIBSUBDIR/include'. Headers for non-C runtime libraries are also 3574installed by GCC; these are not documented here. (FIXME: document them 3575somewhere.) 3576 3577 Several of the headers GCC installs are in the `ginclude' directory. 3578These headers, `iso646.h', `stdarg.h', `stdbool.h', and `stddef.h', are 3579installed in `LIBSUBDIR/include', unless the target Makefile fragment 3580(*note Target Fragment::) overrides this by setting `USER_H'. 3581 3582 In addition to these headers and those generated by fixing system 3583headers to work with GCC, some other headers may also be installed in 3584`LIBSUBDIR/include'. `config.gcc' may set `extra_headers'; this 3585specifies additional headers under `config' to be installed on some 3586systems. 3587 3588 GCC installs its own version of `<float.h>', from `ginclude/float.h'. 3589This is done to cope with command-line options that change the 3590representation of floating point numbers. 3591 3592 GCC also installs its own version of `<limits.h>'; this is generated 3593from `glimits.h', together with `limitx.h' and `limity.h' if the system 3594also has its own version of `<limits.h>'. (GCC provides its own header 3595because it is required of ISO C freestanding implementations, but needs 3596to include the system header from its own header as well because other 3597standards such as POSIX specify additional values to be defined in 3598`<limits.h>'.) The system's `<limits.h>' header is used via 3599`LIBSUBDIR/include/syslimits.h', which is copied from `gsyslimits.h' if 3600it does not need fixing to work with GCC; if it needs fixing, 3601`syslimits.h' is the fixed copy. 3602 3603 GCC can also install `<tgmath.h>'. It will do this when `config.gcc' 3604sets `use_gcc_tgmath' to `yes'. 3605 3606 3607File: gccint.info, Node: Documentation, Next: Front End, Prev: Headers, Up: gcc Directory 3608 36096.3.7 Building Documentation 3610---------------------------- 3611 3612The main GCC documentation is in the form of manuals in Texinfo format. 3613These are installed in Info format; DVI versions may be generated by 3614`make dvi', PDF versions by `make pdf', and HTML versions by `make 3615html'. In addition, some man pages are generated from the Texinfo 3616manuals, there are some other text files with miscellaneous 3617documentation, and runtime libraries have their own documentation 3618outside the `gcc' directory. FIXME: document the documentation for 3619runtime libraries somewhere. 3620 3621* Menu: 3622 3623* Texinfo Manuals:: GCC manuals in Texinfo format. 3624* Man Page Generation:: Generating man pages from Texinfo manuals. 3625* Miscellaneous Docs:: Miscellaneous text files with documentation. 3626 3627 3628File: gccint.info, Node: Texinfo Manuals, Next: Man Page Generation, Up: Documentation 3629 36306.3.7.1 Texinfo Manuals 3631....................... 3632 3633The manuals for GCC as a whole, and the C and C++ front ends, are in 3634files `doc/*.texi'. Other front ends have their own manuals in files 3635`LANGUAGE/*.texi'. Common files `doc/include/*.texi' are provided 3636which may be included in multiple manuals; the following files are in 3637`doc/include': 3638 3639`fdl.texi' 3640 The GNU Free Documentation License. 3641 3642`funding.texi' 3643 The section "Funding Free Software". 3644 3645`gcc-common.texi' 3646 Common definitions for manuals. 3647 3648`gpl.texi' 3649`gpl_v3.texi' 3650 The GNU General Public License. 3651 3652`texinfo.tex' 3653 A copy of `texinfo.tex' known to work with the GCC manuals. 3654 3655 DVI-formatted manuals are generated by `make dvi', which uses 3656`texi2dvi' (via the Makefile macro `$(TEXI2DVI)'). PDF-formatted 3657manuals are generated by `make pdf', which uses `texi2pdf' (via the 3658Makefile macro `$(TEXI2PDF)'). HTML formatted manuals are generated by 3659`make html'. Info manuals are generated by `make info' (which is run 3660as part of a bootstrap); this generates the manuals in the source 3661directory, using `makeinfo' via the Makefile macro `$(MAKEINFO)', and 3662they are included in release distributions. 3663 3664 Manuals are also provided on the GCC web site, in both HTML and 3665PostScript forms. This is done via the script 3666`maintainer-scripts/update_web_docs'. Each manual to be provided 3667online must be listed in the definition of `MANUALS' in that file; a 3668file `NAME.texi' must only appear once in the source tree, and the 3669output manual must have the same name as the source file. (However, 3670other Texinfo files, included in manuals but not themselves the root 3671files of manuals, may have names that appear more than once in the 3672source tree.) The manual file `NAME.texi' should only include other 3673files in its own directory or in `doc/include'. HTML manuals will be 3674generated by `makeinfo --html', PostScript manuals by `texi2dvi' and 3675`dvips', and PDF manuals by `texi2pdf'. All Texinfo files that are 3676parts of manuals must be version-controlled, even if they are generated 3677files, for the generation of online manuals to work. 3678 3679 The installation manual, `doc/install.texi', is also provided on the 3680GCC web site. The HTML version is generated by the script 3681`doc/install.texi2html'. 3682 3683 3684File: gccint.info, Node: Man Page Generation, Next: Miscellaneous Docs, Prev: Texinfo Manuals, Up: Documentation 3685 36866.3.7.2 Man Page Generation 3687........................... 3688 3689Because of user demand, in addition to full Texinfo manuals, man pages 3690are provided which contain extracts from those manuals. These man 3691pages are generated from the Texinfo manuals using 3692`contrib/texi2pod.pl' and `pod2man'. (The man page for `g++', 3693`cp/g++.1', just contains a `.so' reference to `gcc.1', but all the 3694other man pages are generated from Texinfo manuals.) 3695 3696 Because many systems may not have the necessary tools installed to 3697generate the man pages, they are only generated if the `configure' 3698script detects that recent enough tools are installed, and the 3699Makefiles allow generating man pages to fail without aborting the 3700build. Man pages are also included in release distributions. They are 3701generated in the source directory. 3702 3703 Magic comments in Texinfo files starting `@c man' control what parts 3704of a Texinfo file go into a man page. Only a subset of Texinfo is 3705supported by `texi2pod.pl', and it may be necessary to add support for 3706more Texinfo features to this script when generating new man pages. To 3707improve the man page output, some special Texinfo macros are provided 3708in `doc/include/gcc-common.texi' which `texi2pod.pl' understands: 3709 3710`@gcctabopt' 3711 Use in the form `@table @gcctabopt' for tables of options, where 3712 for printed output the effect of `@code' is better than that of 3713 `@option' but for man page output a different effect is wanted. 3714 3715`@gccoptlist' 3716 Use for summary lists of options in manuals. 3717 3718`@gol' 3719 Use at the end of each line inside `@gccoptlist'. This is 3720 necessary to avoid problems with differences in how the 3721 `@gccoptlist' macro is handled by different Texinfo formatters. 3722 3723 FIXME: describe the `texi2pod.pl' input language and magic comments in 3724more detail. 3725 3726 3727File: gccint.info, Node: Miscellaneous Docs, Prev: Man Page Generation, Up: Documentation 3728 37296.3.7.3 Miscellaneous Documentation 3730................................... 3731 3732In addition to the formal documentation that is installed by GCC, there 3733are several other text files in the `gcc' subdirectory with 3734miscellaneous documentation: 3735 3736`ABOUT-GCC-NLS' 3737 Notes on GCC's Native Language Support. FIXME: this should be 3738 part of this manual rather than a separate file. 3739 3740`ABOUT-NLS' 3741 Notes on the Free Translation Project. 3742 3743`COPYING' 3744`COPYING3' 3745 The GNU General Public License, Versions 2 and 3. 3746 3747`COPYING.LIB' 3748`COPYING3.LIB' 3749 The GNU Lesser General Public License, Versions 2.1 and 3. 3750 3751`*ChangeLog*' 3752`*/ChangeLog*' 3753 Change log files for various parts of GCC. 3754 3755`LANGUAGES' 3756 Details of a few changes to the GCC front-end interface. FIXME: 3757 the information in this file should be part of general 3758 documentation of the front-end interface in this manual. 3759 3760`ONEWS' 3761 Information about new features in old versions of GCC. (For recent 3762 versions, the information is on the GCC web site.) 3763 3764`README.Portability' 3765 Information about portability issues when writing code in GCC. 3766 FIXME: why isn't this part of this manual or of the GCC Coding 3767 Conventions? 3768 3769 FIXME: document such files in subdirectories, at least `config', `cp', 3770`objc', `testsuite'. 3771 3772 3773File: gccint.info, Node: Front End, Next: Back End, Prev: Documentation, Up: gcc Directory 3774 37756.3.8 Anatomy of a Language Front End 3776------------------------------------- 3777 3778A front end for a language in GCC has the following parts: 3779 3780 * A directory `LANGUAGE' under `gcc' containing source files for 3781 that front end. *Note The Front End `LANGUAGE' Directory: Front 3782 End Directory, for details. 3783 3784 * A mention of the language in the list of supported languages in 3785 `gcc/doc/install.texi'. 3786 3787 * A mention of the name under which the language's runtime library is 3788 recognized by `--enable-shared=PACKAGE' in the documentation of 3789 that option in `gcc/doc/install.texi'. 3790 3791 * A mention of any special prerequisites for building the front end 3792 in the documentation of prerequisites in `gcc/doc/install.texi'. 3793 3794 * Details of contributors to that front end in 3795 `gcc/doc/contrib.texi'. If the details are in that front end's 3796 own manual then there should be a link to that manual's list in 3797 `contrib.texi'. 3798 3799 * Information about support for that language in 3800 `gcc/doc/frontends.texi'. 3801 3802 * Information about standards for that language, and the front end's 3803 support for them, in `gcc/doc/standards.texi'. This may be a link 3804 to such information in the front end's own manual. 3805 3806 * Details of source file suffixes for that language and `-x LANG' 3807 options supported, in `gcc/doc/invoke.texi'. 3808 3809 * Entries in `default_compilers' in `gcc.c' for source file suffixes 3810 for that language. 3811 3812 * Preferably testsuites, which may be under `gcc/testsuite' or 3813 runtime library directories. FIXME: document somewhere how to 3814 write testsuite harnesses. 3815 3816 * Probably a runtime library for the language, outside the `gcc' 3817 directory. FIXME: document this further. 3818 3819 * Details of the directories of any runtime libraries in 3820 `gcc/doc/sourcebuild.texi'. 3821 3822 * Check targets in `Makefile.def' for the top-level `Makefile' to 3823 check just the compiler or the compiler and runtime library for the 3824 language. 3825 3826 If the front end is added to the official GCC source repository, the 3827following are also necessary: 3828 3829 * At least one Bugzilla component for bugs in that front end and 3830 runtime libraries. This category needs to be mentioned in 3831 `gcc/gccbug.in', as well as being added to the Bugzilla database. 3832 3833 * Normally, one or more maintainers of that front end listed in 3834 `MAINTAINERS'. 3835 3836 * Mentions on the GCC web site in `index.html' and `frontends.html', 3837 with any relevant links on `readings.html'. (Front ends that are 3838 not an official part of GCC may also be listed on 3839 `frontends.html', with relevant links.) 3840 3841 * A news item on `index.html', and possibly an announcement on the 3842 <gcc-announce@gcc.gnu.org> mailing list. 3843 3844 * The front end's manuals should be mentioned in 3845 `maintainer-scripts/update_web_docs' (*note Texinfo Manuals::) and 3846 the online manuals should be linked to from 3847 `onlinedocs/index.html'. 3848 3849 * Any old releases or CVS repositories of the front end, before its 3850 inclusion in GCC, should be made available on the GCC FTP site 3851 `ftp://gcc.gnu.org/pub/gcc/old-releases/'. 3852 3853 * The release and snapshot script `maintainer-scripts/gcc_release' 3854 should be updated to generate appropriate tarballs for this front 3855 end. The associated `maintainer-scripts/snapshot-README' and 3856 `maintainer-scripts/snapshot-index.html' files should be updated 3857 to list the tarballs and diffs for this front end. 3858 3859 * If this front end includes its own version files that include the 3860 current date, `maintainer-scripts/update_version' should be 3861 updated accordingly. 3862 3863* Menu: 3864 3865* Front End Directory:: The front end `LANGUAGE' directory. 3866* Front End Config:: The front end `config-lang.in' file. 3867* Front End Makefile:: The front end `Make-lang.in' file. 3868 3869 3870File: gccint.info, Node: Front End Directory, Next: Front End Config, Up: Front End 3871 38726.3.8.1 The Front End `LANGUAGE' Directory 3873.......................................... 3874 3875A front end `LANGUAGE' directory contains the source files of that 3876front end (but not of any runtime libraries, which should be outside 3877the `gcc' directory). This includes documentation, and possibly some 3878subsidiary programs built alongside the front end. Certain files are 3879special and other parts of the compiler depend on their names: 3880 3881`config-lang.in' 3882 This file is required in all language subdirectories. *Note The 3883 Front End `config-lang.in' File: Front End Config, for details of 3884 its contents 3885 3886`Make-lang.in' 3887 This file is required in all language subdirectories. *Note The 3888 Front End `Make-lang.in' File: Front End Makefile, for details of 3889 its contents. 3890 3891`lang.opt' 3892 This file registers the set of switches that the front end accepts 3893 on the command line, and their `--help' text. *Note Options::. 3894 3895`lang-specs.h' 3896 This file provides entries for `default_compilers' in `gcc.c' 3897 which override the default of giving an error that a compiler for 3898 that language is not installed. 3899 3900`LANGUAGE-tree.def' 3901 This file, which need not exist, defines any language-specific tree 3902 codes. 3903 3904 3905File: gccint.info, Node: Front End Config, Next: Front End Makefile, Prev: Front End Directory, Up: Front End 3906 39076.3.8.2 The Front End `config-lang.in' File 3908........................................... 3909 3910Each language subdirectory contains a `config-lang.in' file. In 3911addition the main directory contains `c-config-lang.in', which contains 3912limited information for the C language. This file is a shell script 3913that may define some variables describing the language: 3914 3915`language' 3916 This definition must be present, and gives the name of the language 3917 for some purposes such as arguments to `--enable-languages'. 3918 3919`lang_requires' 3920 If defined, this variable lists (space-separated) language front 3921 ends other than C that this front end requires to be enabled (with 3922 the names given being their `language' settings). For example, the 3923 Java front end depends on the C++ front end, so sets 3924 `lang_requires=c++'. 3925 3926`subdir_requires' 3927 If defined, this variable lists (space-separated) front end 3928 directories other than C that this front end requires to be 3929 present. For example, the Objective-C++ front end uses source 3930 files from the C++ and Objective-C front ends, so sets 3931 `subdir_requires="cp objc"'. 3932 3933`target_libs' 3934 If defined, this variable lists (space-separated) targets in the 3935 top level `Makefile' to build the runtime libraries for this 3936 language, such as `target-libobjc'. 3937 3938`lang_dirs' 3939 If defined, this variable lists (space-separated) top level 3940 directories (parallel to `gcc'), apart from the runtime libraries, 3941 that should not be configured if this front end is not built. 3942 3943`build_by_default' 3944 If defined to `no', this language front end is not built unless 3945 enabled in a `--enable-languages' argument. Otherwise, front ends 3946 are built by default, subject to any special logic in 3947 `configure.ac' (as is present to disable the Ada front end if the 3948 Ada compiler is not already installed). 3949 3950`boot_language' 3951 If defined to `yes', this front end is built in stage1 of the 3952 bootstrap. This is only relevant to front ends written in their 3953 own languages. 3954 3955`compilers' 3956 If defined, a space-separated list of compiler executables that 3957 will be run by the driver. The names here will each end with 3958 `\$(exeext)'. 3959 3960`outputs' 3961 If defined, a space-separated list of files that should be 3962 generated by `configure' substituting values in them. This 3963 mechanism can be used to create a file `LANGUAGE/Makefile' from 3964 `LANGUAGE/Makefile.in', but this is deprecated, building 3965 everything from the single `gcc/Makefile' is preferred. 3966 3967`gtfiles' 3968 If defined, a space-separated list of files that should be scanned 3969 by `gengtype.c' to generate the garbage collection tables and 3970 routines for this language. This excludes the files that are 3971 common to all front ends. *Note Type Information::. 3972 3973 3974 3975File: gccint.info, Node: Front End Makefile, Prev: Front End Config, Up: Front End 3976 39776.3.8.3 The Front End `Make-lang.in' File 3978......................................... 3979 3980Each language subdirectory contains a `Make-lang.in' file. It contains 3981targets `LANG.HOOK' (where `LANG' is the setting of `language' in 3982`config-lang.in') for the following values of `HOOK', and any other 3983Makefile rules required to build those targets (which may if necessary 3984use other Makefiles specified in `outputs' in `config-lang.in', 3985although this is deprecated). It also adds any testsuite targets that 3986can use the standard rule in `gcc/Makefile.in' to the variable 3987`lang_checks'. 3988 3989`all.cross' 3990`start.encap' 3991`rest.encap' 3992 FIXME: exactly what goes in each of these targets? 3993 3994`tags' 3995 Build an `etags' `TAGS' file in the language subdirectory in the 3996 source tree. 3997 3998`info' 3999 Build info documentation for the front end, in the build directory. 4000 This target is only called by `make bootstrap' if a suitable 4001 version of `makeinfo' is available, so does not need to check for 4002 this, and should fail if an error occurs. 4003 4004`dvi' 4005 Build DVI documentation for the front end, in the build directory. 4006 This should be done using `$(TEXI2DVI)', with appropriate `-I' 4007 arguments pointing to directories of included files. 4008 4009`pdf' 4010 Build PDF documentation for the front end, in the build directory. 4011 This should be done using `$(TEXI2PDF)', with appropriate `-I' 4012 arguments pointing to directories of included files. 4013 4014`html' 4015 Build HTML documentation for the front end, in the build directory. 4016 4017`man' 4018 Build generated man pages for the front end from Texinfo manuals 4019 (*note Man Page Generation::), in the build directory. This target 4020 is only called if the necessary tools are available, but should 4021 ignore errors so as not to stop the build if errors occur; man 4022 pages are optional and the tools involved may be installed in a 4023 broken way. 4024 4025`install-common' 4026 Install everything that is part of the front end, apart from the 4027 compiler executables listed in `compilers' in `config-lang.in'. 4028 4029`install-info' 4030 Install info documentation for the front end, if it is present in 4031 the source directory. This target should have dependencies on 4032 info files that should be installed. 4033 4034`install-man' 4035 Install man pages for the front end. This target should ignore 4036 errors. 4037 4038`install-plugin' 4039 Install headers needed for plugins. 4040 4041`srcextra' 4042 Copies its dependencies into the source directory. This generally 4043 should be used for generated files such as Bison output files 4044 which are not version-controlled, but should be included in any 4045 release tarballs. This target will be executed during a bootstrap 4046 if `--enable-generated-files-in-srcdir' was specified as a 4047 `configure' option. 4048 4049`srcinfo' 4050`srcman' 4051 Copies its dependencies into the source directory. These targets 4052 will be executed during a bootstrap if 4053 `--enable-generated-files-in-srcdir' was specified as a 4054 `configure' option. 4055 4056`uninstall' 4057 Uninstall files installed by installing the compiler. This is 4058 currently documented not to be supported, so the hook need not do 4059 anything. 4060 4061`mostlyclean' 4062`clean' 4063`distclean' 4064`maintainer-clean' 4065 The language parts of the standard GNU `*clean' targets. *Note 4066 Standard Targets for Users: (standards)Standard Targets, for 4067 details of the standard targets. For GCC, `maintainer-clean' 4068 should delete all generated files in the source directory that are 4069 not version-controlled, but should not delete anything that is. 4070 4071 `Make-lang.in' must also define a variable `LANG_OBJS' to a list of 4072host object files that are used by that language. 4073 4074 4075File: gccint.info, Node: Back End, Prev: Front End, Up: gcc Directory 4076 40776.3.9 Anatomy of a Target Back End 4078---------------------------------- 4079 4080A back end for a target architecture in GCC has the following parts: 4081 4082 * A directory `MACHINE' under `gcc/config', containing a machine 4083 description `MACHINE.md' file (*note Machine Descriptions: Machine 4084 Desc.), header files `MACHINE.h' and `MACHINE-protos.h' and a 4085 source file `MACHINE.c' (*note Target Description Macros and 4086 Functions: Target Macros.), possibly a target Makefile fragment 4087 `t-MACHINE' (*note The Target Makefile Fragment: Target 4088 Fragment.), and maybe some other files. The names of these files 4089 may be changed from the defaults given by explicit specifications 4090 in `config.gcc'. 4091 4092 * If necessary, a file `MACHINE-modes.def' in the `MACHINE' 4093 directory, containing additional machine modes to represent 4094 condition codes. *Note Condition Code::, for further details. 4095 4096 * An optional `MACHINE.opt' file in the `MACHINE' directory, 4097 containing a list of target-specific options. You can also add 4098 other option files using the `extra_options' variable in 4099 `config.gcc'. *Note Options::. 4100 4101 * Entries in `config.gcc' (*note The `config.gcc' File: System 4102 Config.) for the systems with this target architecture. 4103 4104 * Documentation in `gcc/doc/invoke.texi' for any command-line 4105 options supported by this target (*note Run-time Target 4106 Specification: Run-time Target.). This means both entries in the 4107 summary table of options and details of the individual options. 4108 4109 * Documentation in `gcc/doc/extend.texi' for any target-specific 4110 attributes supported (*note Defining target-specific uses of 4111 `__attribute__': Target Attributes.), including where the same 4112 attribute is already supported on some targets, which are 4113 enumerated in the manual. 4114 4115 * Documentation in `gcc/doc/extend.texi' for any target-specific 4116 pragmas supported. 4117 4118 * Documentation in `gcc/doc/extend.texi' of any target-specific 4119 built-in functions supported. 4120 4121 * Documentation in `gcc/doc/extend.texi' of any target-specific 4122 format checking styles supported. 4123 4124 * Documentation in `gcc/doc/md.texi' of any target-specific 4125 constraint letters (*note Constraints for Particular Machines: 4126 Machine Constraints.). 4127 4128 * A note in `gcc/doc/contrib.texi' under the person or people who 4129 contributed the target support. 4130 4131 * Entries in `gcc/doc/install.texi' for all target triplets 4132 supported with this target architecture, giving details of any 4133 special notes about installation for this target, or saying that 4134 there are no special notes if there are none. 4135 4136 * Possibly other support outside the `gcc' directory for runtime 4137 libraries. FIXME: reference docs for this. The `libstdc++' 4138 porting manual needs to be installed as info for this to work, or 4139 to be a chapter of this manual. 4140 4141 If the back end is added to the official GCC source repository, the 4142following are also necessary: 4143 4144 * An entry for the target architecture in `readings.html' on the GCC 4145 web site, with any relevant links. 4146 4147 * Details of the properties of the back end and target architecture 4148 in `backends.html' on the GCC web site. 4149 4150 * A news item about the contribution of support for that target 4151 architecture, in `index.html' on the GCC web site. 4152 4153 * Normally, one or more maintainers of that target listed in 4154 `MAINTAINERS'. Some existing architectures may be unmaintained, 4155 but it would be unusual to add support for a target that does not 4156 have a maintainer when support is added. 4157 4158 4159File: gccint.info, Node: Testsuites, Next: Options, Prev: Source Tree, Up: Top 4160 41617 Testsuites 4162************ 4163 4164GCC contains several testsuites to help maintain compiler quality. 4165Most of the runtime libraries and language front ends in GCC have 4166testsuites. Currently only the C language testsuites are documented 4167here; FIXME: document the others. 4168 4169* Menu: 4170 4171* Test Idioms:: Idioms used in testsuite code. 4172* Test Directives:: Directives used within DejaGnu tests. 4173* Ada Tests:: The Ada language testsuites. 4174* C Tests:: The C language testsuites. 4175* libgcj Tests:: The Java library testsuites. 4176* LTO Testing:: Support for testing link-time optimizations. 4177* gcov Testing:: Support for testing gcov. 4178* profopt Testing:: Support for testing profile-directed optimizations. 4179* compat Testing:: Support for testing binary compatibility. 4180* Torture Tests:: Support for torture testing using multiple options. 4181 4182 4183File: gccint.info, Node: Test Idioms, Next: Test Directives, Up: Testsuites 4184 41857.1 Idioms Used in Testsuite Code 4186================================= 4187 4188In general, C testcases have a trailing `-N.c', starting with `-1.c', 4189in case other testcases with similar names are added later. If the 4190test is a test of some well-defined feature, it should have a name 4191referring to that feature such as `FEATURE-1.c'. If it does not test a 4192well-defined feature but just happens to exercise a bug somewhere in 4193the compiler, and a bug report has been filed for this bug in the GCC 4194bug database, `prBUG-NUMBER-1.c' is the appropriate form of name. 4195Otherwise (for miscellaneous bugs not filed in the GCC bug database), 4196and previously more generally, test cases are named after the date on 4197which they were added. This allows people to tell at a glance whether 4198a test failure is because of a recently found bug that has not yet been 4199fixed, or whether it may be a regression, but does not give any other 4200information about the bug or where discussion of it may be found. Some 4201other language testsuites follow similar conventions. 4202 4203 In the `gcc.dg' testsuite, it is often necessary to test that an error 4204is indeed a hard error and not just a warning--for example, where it is 4205a constraint violation in the C standard, which must become an error 4206with `-pedantic-errors'. The following idiom, where the first line 4207shown is line LINE of the file and the line that generates the error, 4208is used for this: 4209 4210 /* { dg-bogus "warning" "warning in place of error" } */ 4211 /* { dg-error "REGEXP" "MESSAGE" { target *-*-* } LINE } */ 4212 4213 It may be necessary to check that an expression is an integer constant 4214expression and has a certain value. To check that `E' has value `V', 4215an idiom similar to the following is used: 4216 4217 char x[((E) == (V) ? 1 : -1)]; 4218 4219 In `gcc.dg' tests, `__typeof__' is sometimes used to make assertions 4220about the types of expressions. See, for example, 4221`gcc.dg/c99-condexpr-1.c'. The more subtle uses depend on the exact 4222rules for the types of conditional expressions in the C standard; see, 4223for example, `gcc.dg/c99-intconst-1.c'. 4224 4225 It is useful to be able to test that optimizations are being made 4226properly. This cannot be done in all cases, but it can be done where 4227the optimization will lead to code being optimized away (for example, 4228where flow analysis or alias analysis should show that certain code 4229cannot be called) or to functions not being called because they have 4230been expanded as built-in functions. Such tests go in 4231`gcc.c-torture/execute'. Where code should be optimized away, a call 4232to a nonexistent function such as `link_failure ()' may be inserted; a 4233definition 4234 4235 #ifndef __OPTIMIZE__ 4236 void 4237 link_failure (void) 4238 { 4239 abort (); 4240 } 4241 #endif 4242 4243will also be needed so that linking still succeeds when the test is run 4244without optimization. When all calls to a built-in function should 4245have been optimized and no calls to the non-built-in version of the 4246function should remain, that function may be defined as `static' to 4247call `abort ()' (although redeclaring a function as static may not work 4248on all targets). 4249 4250 All testcases must be portable. Target-specific testcases must have 4251appropriate code to avoid causing failures on unsupported systems; 4252unfortunately, the mechanisms for this differ by directory. 4253 4254 FIXME: discuss non-C testsuites here. 4255 4256 4257File: gccint.info, Node: Test Directives, Next: Ada Tests, Prev: Test Idioms, Up: Testsuites 4258 42597.2 Directives used within DejaGnu tests 4260======================================== 4261 4262* Menu: 4263 4264* Directives:: Syntax and descriptions of test directives. 4265* Selectors:: Selecting targets to which a test applies. 4266* Effective-Target Keywords:: Keywords describing target attributes. 4267* Add Options:: Features for `dg-add-options' 4268* Require Support:: Variants of `dg-require-SUPPORT' 4269* Final Actions:: Commands for use in `dg-final' 4270 4271 4272File: gccint.info, Node: Directives, Next: Selectors, Up: Test Directives 4273 42747.2.1 Syntax and Descriptions of test directives 4275------------------------------------------------ 4276 4277Test directives appear within comments in a test source file and begin 4278with `dg-'. Some of these are defined within DejaGnu and others are 4279local to the GCC testsuite. 4280 4281 The order in which test directives appear in a test can be important: 4282directives local to GCC sometimes override information used by the 4283DejaGnu directives, which know nothing about the GCC directives, so the 4284DejaGnu directives must precede GCC directives. 4285 4286 Several test directives include selectors (*note Selectors::) which 4287are usually preceded by the keyword `target' or `xfail'. 4288 42897.2.1.1 Specify how to build the test 4290..................................... 4291 4292`{ dg-do DO-WHAT-KEYWORD [{ target/xfail SELECTOR }] }' 4293 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 4294 is executed. It is one of: 4295 4296 `preprocess' 4297 Compile with `-E' to run only the preprocessor. 4298 4299 `compile' 4300 Compile with `-S' to produce an assembly code file. 4301 4302 `assemble' 4303 Compile with `-c' to produce a relocatable object file. 4304 4305 `link' 4306 Compile, assemble, and link to produce an executable file. 4307 4308 `run' 4309 Produce and run an executable file, which is expected to 4310 return an exit code of 0. 4311 4312 The default is `compile'. That can be overridden for a set of 4313 tests by redefining `dg-do-what-default' within the `.exp' file 4314 for those tests. 4315 4316 If the directive includes the optional `{ target SELECTOR }' then 4317 the test is skipped unless the target system matches the SELECTOR. 4318 4319 If DO-WHAT-KEYWORD is `run' and the directive includes the 4320 optional `{ xfail SELECTOR }' and the selector is met then the 4321 test is expected to fail. The `xfail' clause is ignored for other 4322 values of DO-WHAT-KEYWORD; those tests can use directive 4323 `dg-xfail-if'. 4324 43257.2.1.2 Specify additional compiler options 4326........................................... 4327 4328`{ dg-options OPTIONS [{ target SELECTOR }] }' 4329 This DejaGnu directive provides a list of compiler options, to be 4330 used if the target system matches SELECTOR, that replace the 4331 default options used for this set of tests. 4332 4333`{ dg-add-options FEATURE ... }' 4334 Add any compiler options that are needed to access certain 4335 features. This directive does nothing on targets that enable the 4336 features by default, or that don't provide them at all. It must 4337 come after all `dg-options' directives. For supported values of 4338 FEATURE see *note Add Options::. 4339 43407.2.1.3 Modify the test timeout value 4341..................................... 4342 4343The normal timeout limit, in seconds, is found by searching the 4344following in order: 4345 4346 * the value defined by an earlier `dg-timeout' directive in the test 4347 4348 * variable TOOL_TIMEOUT defined by the set of tests 4349 4350 * GCC,TIMEOUT set in the target board 4351 4352 * 300 4353 4354`{ dg-timeout N [{target SELECTOR }] }' 4355 Set the time limit for the compilation and for the execution of 4356 the test to the specified number of seconds. 4357 4358`{ dg-timeout-factor X [{ target SELECTOR }] }' 4359 Multiply the normal time limit for compilation and execution of 4360 the test by the specified floating-point factor. 4361 43627.2.1.4 Skip a test for some targets 4363.................................... 4364 4365`{ dg-skip-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4366 Arguments INCLUDE-OPTS and EXCLUDE-OPTS are lists in which each 4367 element is a string of zero or more GCC options. Skip the test if 4368 all of the following conditions are met: 4369 * the test system is included in SELECTOR 4370 4371 * for at least one of the option strings in INCLUDE-OPTS, every 4372 option from that string is in the set of options with which 4373 the test would be compiled; use `"*"' for an INCLUDE-OPTS list 4374 that matches any options; that is the default if INCLUDE-OPTS 4375 is not specified 4376 4377 * for each of the option strings in EXCLUDE-OPTS, at least one 4378 option from that string is not in the set of options with 4379 which the test would be compiled; use `""' for an empty 4380 EXCLUDE-OPTS list; that is the default if EXCLUDE-OPTS is not 4381 specified 4382 4383 For example, to skip a test if option `-Os' is present: 4384 4385 /* { dg-skip-if "" { *-*-* } { "-Os" } { "" } } */ 4386 4387 To skip a test if both options `-O2' and `-g' are present: 4388 4389 /* { dg-skip-if "" { *-*-* } { "-O2 -g" } { "" } } */ 4390 4391 To skip a test if either `-O2' or `-O3' is present: 4392 4393 /* { dg-skip-if "" { *-*-* } { "-O2" "-O3" } { "" } } */ 4394 4395 To skip a test unless option `-Os' is present: 4396 4397 /* { dg-skip-if "" { *-*-* } { "*" } { "-Os" } } */ 4398 4399 To skip a test if either `-O2' or `-O3' is used with `-g' but not 4400 if `-fpic' is also present: 4401 4402 /* { dg-skip-if "" { *-*-* } { "-O2 -g" "-O3 -g" } { "-fpic" } } */ 4403 4404`{ dg-require-effective-target KEYWORD [{ SELECTOR }] }' 4405 Skip the test if the test target, including current multilib flags, 4406 is not covered by the effective-target keyword. If the directive 4407 includes the optional `{ SELECTOR }' then the effective-target 4408 test is only performed if the target system matches the SELECTOR. 4409 This directive must appear after any `dg-do' directive in the test 4410 and before any `dg-additional-sources' directive. *Note 4411 Effective-Target Keywords::. 4412 4413`{ dg-require-SUPPORT args }' 4414 Skip the test if the target does not provide the required support. 4415 These directives must appear after any `dg-do' directive in the 4416 test and before any `dg-additional-sources' directive. They 4417 require at least one argument, which can be an empty string if the 4418 specific procedure does not examine the argument. *Note Require 4419 Support::, for a complete list of these directives. 4420 44217.2.1.5 Expect a test to fail for some targets 4422.............................................. 4423 4424`{ dg-xfail-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4425 Expect the test to fail if the conditions (which are the same as 4426 for `dg-skip-if') are met. This does not affect the execute step. 4427 4428`{ dg-xfail-run-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4429 Expect the execute step of a test to fail if the conditions (which 4430 are the same as for `dg-skip-if') are met. 4431 44327.2.1.6 Expect the test executable to fail 4433.......................................... 4434 4435`{ dg-shouldfail COMMENT [{ SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]]] }' 4436 Expect the test executable to return a nonzero exit status if the 4437 conditions (which are the same as for `dg-skip-if') are met. 4438 44397.2.1.7 Verify compiler messages 4440................................ 4441 4442`{ dg-error REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4443 This DejaGnu directive appears on a source line that is expected 4444 to get an error message, or else specifies the source line 4445 associated with the message. If there is no message for that line 4446 or if the text of that message is not matched by REGEXP then the 4447 check fails and COMMENT is included in the `FAIL' message. The 4448 check does not look for the string `error' unless it is part of 4449 REGEXP. 4450 4451`{ dg-warning REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4452 This DejaGnu directive appears on a source line that is expected 4453 to get a warning message, or else specifies the source line 4454 associated with the message. If there is no message for that line 4455 or if the text of that message is not matched by REGEXP then the 4456 check fails and COMMENT is included in the `FAIL' message. The 4457 check does not look for the string `warning' unless it is part of 4458 REGEXP. 4459 4460`{ dg-message REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4461 The line is expected to get a message other than an error or 4462 warning. If there is no message for that line or if the text of 4463 that message is not matched by REGEXP then the check fails and 4464 COMMENT is included in the `FAIL' message. 4465 4466`{ dg-bogus REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4467 This DejaGnu directive appears on a source line that should not 4468 get a message matching REGEXP, or else specifies the source line 4469 associated with the bogus message. It is usually used with `xfail' 4470 to indicate that the message is a known problem for a particular 4471 set of targets. 4472 4473`{ dg-excess-errors COMMENT [{ target/xfail SELECTOR }] }' 4474 This DejaGnu directive indicates that the test is expected to fail 4475 due to compiler messages that are not handled by `dg-error', 4476 `dg-warning' or `dg-bogus'. For this directive `xfail' has the 4477 same effect as `target'. 4478 4479`{ dg-prune-output REGEXP }' 4480 Prune messages matching REGEXP from the test output. 4481 44827.2.1.8 Verify output of the test executable 4483............................................ 4484 4485`{ dg-output REGEXP [{ target/xfail SELECTOR }] }' 4486 This DejaGnu directive compares REGEXP to the combined output that 4487 the test executable writes to `stdout' and `stderr'. 4488 44897.2.1.9 Specify additional files for a test 4490........................................... 4491 4492`{ dg-additional-files "FILELIST" }' 4493 Specify additional files, other than source files, that must be 4494 copied to the system where the compiler runs. 4495 4496`{ dg-additional-sources "FILELIST" }' 4497 Specify additional source files to appear in the compile line 4498 following the main test file. 4499 45007.2.1.10 Add checks at the end of a test 4501........................................ 4502 4503`{ dg-final { LOCAL-DIRECTIVE } }' 4504 This DejaGnu directive is placed within a comment anywhere in the 4505 source file and is processed after the test has been compiled and 4506 run. Multiple `dg-final' commands are processed in the order in 4507 which they appear in the source file. *Note Final Actions::, for 4508 a list of directives that can be used within `dg-final'. 4509 4510 4511File: gccint.info, Node: Selectors, Next: Effective-Target Keywords, Prev: Directives, Up: Test Directives 4512 45137.2.2 Selecting targets to which a test applies 4514----------------------------------------------- 4515 4516Several test directives include SELECTORs to limit the targets for 4517which a test is run or to declare that a test is expected to fail on 4518particular targets. 4519 4520 A selector is: 4521 * one or more target triplets, possibly including wildcard characters 4522 4523 * a single effective-target keyword (*note Effective-Target 4524 Keywords::) 4525 4526 * a logical expression 4527 4528 Depending on the context, the selector specifies whether a test is 4529skipped and reported as unsupported or is expected to fail. Use 4530`*-*-*' to match any target. 4531 4532 A selector expression appears within curly braces and uses a single 4533logical operator: one of `!', `&&', or `||'. An operand is another 4534selector expression, an effective-target keyword, a single target 4535triplet, or a list of target triplets within quotes or curly braces. 4536For example: 4537 4538 { target { ! "hppa*-*-* ia64*-*-*" } } 4539 { target { powerpc*-*-* && lp64 } } 4540 { xfail { lp64 || vect_no_align } } 4541 4542 4543File: gccint.info, Node: Effective-Target Keywords, Next: Add Options, Prev: Selectors, Up: Test Directives 4544 45457.2.3 Keywords describing target attributes 4546------------------------------------------- 4547 4548Effective-target keywords identify sets of targets that support 4549particular functionality. They are used to limit tests to be run only 4550for particular targets, or to specify that particular sets of targets 4551are expected to fail some tests. 4552 4553 Effective-target keywords are defined in `lib/target-supports.exp' in 4554the GCC testsuite, with the exception of those that are documented as 4555being local to a particular test directory. 4556 4557 The `effective target' takes into account all of the compiler options 4558with which the test will be compiled, including the multilib options. 4559By convention, keywords ending in `_nocache' can also include options 4560specified for the particular test in an earlier `dg-options' or 4561`dg-add-options' directive. 4562 45637.2.3.1 Data type sizes 4564....................... 4565 4566`ilp32' 4567 Target has 32-bit `int', `long', and pointers. 4568 4569`lp64' 4570 Target has 32-bit `int', 64-bit `long' and pointers. 4571 4572`llp64' 4573 Target has 32-bit `int' and `long', 64-bit `long long' and 4574 pointers. 4575 4576`double64' 4577 Target has 64-bit `double'. 4578 4579`double64plus' 4580 Target has `double' that is 64 bits or longer. 4581 4582`int32plus' 4583 Target has `int' that is at 32 bits or longer. 4584 4585`int16' 4586 Target has `int' that is 16 bits or shorter. 4587 4588`large_double' 4589 Target supports `double' that is longer than `float'. 4590 4591`large_long_double' 4592 Target supports `long double' that is longer than `double'. 4593 4594`ptr32plus' 4595 Target has pointers that are 32 bits or longer. 4596 4597`size32plus' 4598 Target supports array and structure sizes that are 32 bits or 4599 longer. 4600 4601`4byte_wchar_t' 4602 Target has `wchar_t' that is at least 4 bytes. 4603 46047.2.3.2 Fortran-specific attributes 4605................................... 4606 4607`fortran_integer_16' 4608 Target supports Fortran `integer' that is 16 bytes or longer. 4609 4610`fortran_large_int' 4611 Target supports Fortran `integer' kinds larger than `integer(8)'. 4612 4613`fortran_large_real' 4614 Target supports Fortran `real' kinds larger than `real(8)'. 4615 46167.2.3.3 Vector-specific attributes 4617.................................. 4618 4619`vect_condition' 4620 Target supports vector conditional operations. 4621 4622`vect_double' 4623 Target supports hardware vectors of `double'. 4624 4625`vect_float' 4626 Target supports hardware vectors of `float'. 4627 4628`vect_int' 4629 Target supports hardware vectors of `int'. 4630 4631`vect_int_mult' 4632 Target supports a vector widening multiplication of `short' 4633 operands into an `int' result, or supports promotion (unpacking) 4634 from `short' to `int' and a non-widening multiplication of `int'. 4635 4636`vect_long' 4637 Target supports hardware vectors of `long'. 4638 4639`vect_long_long' 4640 Target supports hardware vectors of `long long'. 4641 4642`vect_aligned_arrays' 4643 Target aligns arrays to vector alignment boundary. 4644 4645`vect_hw_misalign' 4646 Target supports a vector misalign access. 4647 4648`vect_no_align' 4649 Target does not support a vector alignment mechanism. 4650 4651`vect_no_int_max' 4652 Target does not support a vector max instruction on `int'. 4653 4654`vect_no_int_add' 4655 Target does not support a vector add instruction on `int'. 4656 4657`vect_no_bitwise' 4658 Target does not support vector bitwise instructions. 4659 4660`vect_char_mult' 4661 Target supports `vector char' multiplication. 4662 4663`vect_short_mult' 4664 Target supports `vector short' multiplication. 4665 4666`vect_int_mult' 4667 Target supports `vector int' multiplication. 4668 4669`vect_extract_even_odd' 4670 Target supports vector even/odd element extraction. 4671 4672`vect_extract_even_odd_wide' 4673 Target supports vector even/odd element extraction of vectors with 4674 elements `SImode' or larger. 4675 4676`vect_interleave' 4677 Target supports vector interleaving. 4678 4679`vect_strided' 4680 Target supports vector interleaving and extract even/odd. 4681 4682`vect_strided_wide' 4683 Target supports vector interleaving and extract even/odd for wide 4684 element types. 4685 4686`vect_perm' 4687 Target supports vector permutation. 4688 4689`vect_shift' 4690 Target supports a hardware vector shift operation. 4691 4692`vect_widen_sum_hi_to_si' 4693 Target supports a vector widening summation of `short' operands 4694 into `int' results, or can promote (unpack) from `short' to `int'. 4695 4696`vect_widen_sum_qi_to_hi' 4697 Target supports a vector widening summation of `char' operands 4698 into `short' results, or can promote (unpack) from `char' to 4699 `short'. 4700 4701`vect_widen_sum_qi_to_si' 4702 Target supports a vector widening summation of `char' operands 4703 into `int' results. 4704 4705`vect_widen_mult_qi_to_hi' 4706 Target supports a vector widening multiplication of `char' operands 4707 into `short' results, or can promote (unpack) from `char' to 4708 `short' and perform non-widening multiplication of `short'. 4709 4710`vect_widen_mult_hi_to_si' 4711 Target supports a vector widening multiplication of `short' 4712 operands into `int' results, or can promote (unpack) from `short' 4713 to `int' and perform non-widening multiplication of `int'. 4714 4715`vect_sdot_qi' 4716 Target supports a vector dot-product of `signed char'. 4717 4718`vect_udot_qi' 4719 Target supports a vector dot-product of `unsigned char'. 4720 4721`vect_sdot_hi' 4722 Target supports a vector dot-product of `signed short'. 4723 4724`vect_udot_hi' 4725 Target supports a vector dot-product of `unsigned short'. 4726 4727`vect_pack_trunc' 4728 Target supports a vector demotion (packing) of `short' to `char' 4729 and from `int' to `short' using modulo arithmetic. 4730 4731`vect_unpack' 4732 Target supports a vector promotion (unpacking) of `char' to `short' 4733 and from `char' to `int'. 4734 4735`vect_intfloat_cvt' 4736 Target supports conversion from `signed int' to `float'. 4737 4738`vect_uintfloat_cvt' 4739 Target supports conversion from `unsigned int' to `float'. 4740 4741`vect_floatint_cvt' 4742 Target supports conversion from `float' to `signed int'. 4743 4744`vect_floatuint_cvt' 4745 Target supports conversion from `float' to `unsigned int'. 4746 47477.2.3.4 Thread Local Storage attributes 4748....................................... 4749 4750`tls' 4751 Target supports thread-local storage. 4752 4753`tls_native' 4754 Target supports native (rather than emulated) thread-local storage. 4755 4756`tls_runtime' 4757 Test system supports executing TLS executables. 4758 47597.2.3.5 Decimal floating point attributes 4760......................................... 4761 4762`dfp' 4763 Targets supports compiling decimal floating point extension to C. 4764 4765`dfp_nocache' 4766 Including the options used to compile this particular test, the 4767 target supports compiling decimal floating point extension to C. 4768 4769`dfprt' 4770 Test system can execute decimal floating point tests. 4771 4772`dfprt_nocache' 4773 Including the options used to compile this particular test, the 4774 test system can execute decimal floating point tests. 4775 4776`hard_dfp' 4777 Target generates decimal floating point instructions with current 4778 options. 4779 47807.2.3.6 ARM-specific attributes 4781............................... 4782 4783`arm32' 4784 ARM target generates 32-bit code. 4785 4786`arm_eabi' 4787 ARM target adheres to the ABI for the ARM Architecture. 4788 4789`arm_hard_vfp_ok' 4790 ARM target supports `-mfpu=vfp -mfloat-abi=hard'. Some multilibs 4791 may be incompatible with these options. 4792 4793`arm_iwmmxt_ok' 4794 ARM target supports `-mcpu=iwmmxt'. Some multilibs may be 4795 incompatible with this option. 4796 4797`arm_neon' 4798 ARM target supports generating NEON instructions. 4799 4800`arm_neon_hw' 4801 Test system supports executing NEON instructions. 4802 4803`arm_neon_ok' 4804 ARM Target supports `-mfpu=neon -mfloat-abi=softfp'. Some 4805 multilibs may be incompatible with these options. 4806 4807`arm_thumb1_ok' 4808 ARM target generates Thumb-1 code for `-mthumb'. 4809 4810`arm_thumb2_ok' 4811 ARM target generates Thumb-2 code for `-mthumb'. 4812 4813`arm_vfp_ok' 4814 ARM target supports `-mfpu=vfp -mfloat-abi=softfp'. Some 4815 multilibs may be incompatible with these options. 4816 48177.2.3.7 MIPS-specific attributes 4818................................ 4819 4820`mips64' 4821 MIPS target supports 64-bit instructions. 4822 4823`nomips16' 4824 MIPS target does not produce MIPS16 code. 4825 4826`mips16_attribute' 4827 MIPS target can generate MIPS16 code. 4828 4829`mips_loongson' 4830 MIPS target is a Loongson-2E or -2F target using an ABI that 4831 supports the Loongson vector modes. 4832 4833`mips_newabi_large_long_double' 4834 MIPS target supports `long double' larger than `double' when using 4835 the new ABI. 4836 4837`mpaired_single' 4838 MIPS target supports `-mpaired-single'. 4839 48407.2.3.8 PowerPC-specific attributes 4841................................... 4842 4843`powerpc64' 4844 Test system supports executing 64-bit instructions. 4845 4846`powerpc_altivec' 4847 PowerPC target supports AltiVec. 4848 4849`powerpc_altivec_ok' 4850 PowerPC target supports `-maltivec'. 4851 4852`powerpc_fprs' 4853 PowerPC target supports floating-point registers. 4854 4855`powerpc_hard_double' 4856 PowerPC target supports hardware double-precision floating-point. 4857 4858`powerpc_ppu_ok' 4859 PowerPC target supports `-mcpu=cell'. 4860 4861`powerpc_spe' 4862 PowerPC target supports PowerPC SPE. 4863 4864`powerpc_spe_nocache' 4865 Including the options used to compile this particular test, the 4866 PowerPC target supports PowerPC SPE. 4867 4868`powerpc_spu' 4869 PowerPC target supports PowerPC SPU. 4870 4871`spu_auto_overlay' 4872 SPU target has toolchain that supports automatic overlay 4873 generation. 4874 4875`powerpc_vsx_ok' 4876 PowerPC target supports `-mvsx'. 4877 4878`powerpc_405_nocache' 4879 Including the options used to compile this particular test, the 4880 PowerPC target supports PowerPC 405. 4881 4882`vmx_hw' 4883 PowerPC target supports executing AltiVec instructions. 4884 48857.2.3.9 Other hardware attributes 4886................................. 4887 4888`avx' 4889 Target supports compiling AVX instructions. 4890 4891`cell_hw' 4892 Test system can execute AltiVec and Cell PPU instructions. 4893 4894`coldfire_fpu' 4895 Target uses a ColdFire FPU. 4896 4897`hard_float' 4898 Target supports FPU instructions. 4899 4900`sse' 4901 Target supports compiling `sse' instructions. 4902 4903`sse_runtime' 4904 Target supports the execution of `sse' instructions. 4905 4906`sse2' 4907 Target supports compiling `sse2' instructions. 4908 4909`sse2_runtime' 4910 Target supports the execution of `sse2' instructions. 4911 4912`sync_char_short' 4913 Target supports atomic operations on `char' and `short'. 4914 4915`sync_int_long' 4916 Target supports atomic operations on `int' and `long'. 4917 4918`ultrasparc_hw' 4919 Test environment appears to run executables on a simulator that 4920 accepts only `EM_SPARC' executables and chokes on `EM_SPARC32PLUS' 4921 or `EM_SPARCV9' executables. 4922 4923`vect_cmdline_needed' 4924 Target requires a command line argument to enable a SIMD 4925 instruction set. 4926 49277.2.3.10 Environment attributes 4928............................... 4929 4930`c' 4931 The language for the compiler under test is C. 4932 4933`c++' 4934 The language for the compiler under test is C++. 4935 4936`c99_runtime' 4937 Target provides a full C99 runtime. 4938 4939`correct_iso_cpp_string_wchar_protos' 4940 Target `string.h' and `wchar.h' headers provide C++ required 4941 overloads for `strchr' etc. functions. 4942 4943`dummy_wcsftime' 4944 Target uses a dummy `wcsftime' function that always returns zero. 4945 4946`fd_truncate' 4947 Target can truncate a file from a file descriptor, as used by 4948 `libgfortran/io/unix.c:fd_truncate'; i.e. `ftruncate' or `chsize'. 4949 4950`freestanding' 4951 Target is `freestanding' as defined in section 4 of the C99 4952 standard. Effectively, it is a target which supports no extra 4953 headers or libraries other than what is considered essential. 4954 4955`init_priority' 4956 Target supports constructors with initialization priority 4957 arguments. 4958 4959`inttypes_types' 4960 Target has the basic signed and unsigned types in `inttypes.h'. 4961 This is for tests that GCC's notions of these types agree with 4962 those in the header, as some systems have only `inttypes.h'. 4963 4964`lax_strtofp' 4965 Target might have errors of a few ULP in string to floating-point 4966 conversion functions and overflow is not always detected correctly 4967 by those functions. 4968 4969`newlib' 4970 Target supports Newlib. 4971 4972`pow10' 4973 Target provides `pow10' function. 4974 4975`pthread' 4976 Target can compile using `pthread.h' with no errors or warnings. 4977 4978`pthread_h' 4979 Target has `pthread.h'. 4980 4981`run_expensive_tests' 4982 Expensive testcases (usually those that consume excessive amounts 4983 of CPU time) should be run on this target. This can be enabled by 4984 setting the `GCC_TEST_RUN_EXPENSIVE' environment variable to a 4985 non-empty string. 4986 4987`simulator' 4988 Test system runs executables on a simulator (i.e. slowly) rather 4989 than hardware (i.e. fast). 4990 4991`stdint_types' 4992 Target has the basic signed and unsigned C types in `stdint.h'. 4993 This will be obsolete when GCC ensures a working `stdint.h' for 4994 all targets. 4995 4996`trampolines' 4997 Target supports trampolines. 4998 4999`uclibc' 5000 Target supports uClibc. 5001 5002`unwrapped' 5003 Target does not use a status wrapper. 5004 5005`vxworks_kernel' 5006 Target is a VxWorks kernel. 5007 5008`vxworks_rtp' 5009 Target is a VxWorks RTP. 5010 5011`wchar' 5012 Target supports wide characters. 5013 50147.2.3.11 Other attributes 5015......................... 5016 5017`automatic_stack_alignment' 5018 Target supports automatic stack alignment. 5019 5020`cxa_atexit' 5021 Target uses `__cxa_atexit'. 5022 5023`default_packed' 5024 Target has packed layout of structure members by default. 5025 5026`fgraphite' 5027 Target supports Graphite optimizations. 5028 5029`fixed_point' 5030 Target supports fixed-point extension to C. 5031 5032`fopenmp' 5033 Target supports OpenMP via `-fopenmp'. 5034 5035`fpic' 5036 Target supports `-fpic' and `-fPIC'. 5037 5038`freorder' 5039 Target supports `-freorder-blocks-and-partition'. 5040 5041`fstack_protector' 5042 Target supports `-fstack-protector'. 5043 5044`gas' 5045 Target uses GNU `as'. 5046 5047`gc_sections' 5048 Target supports `--gc-sections'. 5049 5050`keeps_null_pointer_checks' 5051 Target keeps null pointer checks, either due to the use of 5052 `-fno-delete-null-pointer-checks' or hardwired into the target. 5053 5054`lto' 5055 Compiler has been configured to support link-time optimization 5056 (LTO). 5057 5058`named_sections' 5059 Target supports named sections. 5060 5061`natural_alignment_32' 5062 Target uses natural alignment (aligned to type size) for types of 5063 32 bits or less. 5064 5065`target_natural_alignment_64' 5066 Target uses natural alignment (aligned to type size) for types of 5067 64 bits or less. 5068 5069`nonpic' 5070 Target does not generate PIC by default. 5071 5072`pcc_bitfield_type_matters' 5073 Target defines `PCC_BITFIELD_TYPE_MATTERS'. 5074 5075`pe_aligned_commons' 5076 Target supports `-mpe-aligned-commons'. 5077 5078`section_anchors' 5079 Target supports section anchors. 5080 5081`short_enums' 5082 Target defaults to short enums. 5083 5084`static' 5085 Target supports `-static'. 5086 5087`static_libgfortran' 5088 Target supports statically linking `libgfortran'. 5089 5090`string_merging' 5091 Target supports merging string constants at link time. 5092 5093`ucn' 5094 Target supports compiling and assembling UCN. 5095 5096`ucn_nocache' 5097 Including the options used to compile this particular test, the 5098 target supports compiling and assembling UCN. 5099 5100`unaligned_stack' 5101 Target does not guarantee that its `STACK_BOUNDARY' is greater than 5102 or equal to the required vector alignment. 5103 5104`vector_alignment_reachable' 5105 Vector alignment is reachable for types of 32 bits or less. 5106 5107`vector_alignment_reachable_for_64bit' 5108 Vector alignment is reachable for types of 64 bits or less. 5109 5110`wchar_t_char16_t_compatible' 5111 Target supports `wchar_t' that is compatible with `char16_t'. 5112 5113`wchar_t_char32_t_compatible' 5114 Target supports `wchar_t' that is compatible with `char32_t'. 5115 51167.2.3.12 Local to tests in `gcc.target/i386' 5117............................................ 5118 5119`3dnow' 5120 Target supports compiling `3dnow' instructions. 5121 5122`aes' 5123 Target supports compiling `aes' instructions. 5124 5125`fma4' 5126 Target supports compiling `fma4' instructions. 5127 5128`ms_hook_prologue' 5129 Target supports attribute `ms_hook_prologue'. 5130 5131`pclmul' 5132 Target supports compiling `pclmul' instructions. 5133 5134`sse3' 5135 Target supports compiling `sse3' instructions. 5136 5137`sse4' 5138 Target supports compiling `sse4' instructions. 5139 5140`sse4a' 5141 Target supports compiling `sse4a' instructions. 5142 5143`ssse3' 5144 Target supports compiling `ssse3' instructions. 5145 5146`vaes' 5147 Target supports compiling `vaes' instructions. 5148 5149`vpclmul' 5150 Target supports compiling `vpclmul' instructions. 5151 5152`xop' 5153 Target supports compiling `xop' instructions. 5154 51557.2.3.13 Local to tests in `gcc.target/spu/ea' 5156.............................................. 5157 5158`ealib' 5159 Target `__ea' library functions are available. 5160 51617.2.3.14 Local to tests in `gcc.test-framework' 5162............................................... 5163 5164`no' 5165 Always returns 0. 5166 5167`yes' 5168 Always returns 1. 5169 5170 5171File: gccint.info, Node: Add Options, Next: Require Support, Prev: Effective-Target Keywords, Up: Test Directives 5172 51737.2.4 Features for `dg-add-options' 5174----------------------------------- 5175 5176The supported values of FEATURE for directive `dg-add-options' are: 5177 5178`bind_pic_locally' 5179 Add the target-specific flags needed to enable functions to bind 5180 locally when using pic/PIC passes in the testsuite. 5181 5182`c99_runtime' 5183 Add the target-specific flags needed to access the C99 runtime. 5184 5185`ieee' 5186 Add the target-specific flags needed to enable full IEEE 5187 compliance mode. 5188 5189`mips16_attribute' 5190 `mips16' function attributes. Only MIPS targets support this 5191 feature, and only then in certain modes. 5192 5193`tls' 5194 Add the target-specific flags needed to use thread-local storage. 5195 5196 5197File: gccint.info, Node: Require Support, Next: Final Actions, Prev: Add Options, Up: Test Directives 5198 51997.2.5 Variants of `dg-require-SUPPORT' 5200-------------------------------------- 5201 5202A few of the `dg-require' directives take arguments. 5203 5204`dg-require-iconv CODESET' 5205 Skip the test if the target does not support iconv. CODESET is 5206 the codeset to convert to. 5207 5208`dg-require-profiling PROFOPT' 5209 Skip the test if the target does not support profiling with option 5210 PROFOPT. 5211 5212`dg-require-visibility VIS' 5213 Skip the test if the target does not support the `visibility' 5214 attribute. If VIS is `""', support for `visibility("hidden")' is 5215 checked, for `visibility("VIS")' otherwise. 5216 5217 The original `dg-require' directives were defined before there was 5218support for effective-target keywords. The directives that do not take 5219arguments could be replaced with effective-target keywords. 5220 5221`dg-require-alias ""' 5222 Skip the test if the target does not support the `alias' attribute. 5223 5224`dg-require-ascii-locale ""' 5225 Skip the test if the host does not support an ASCII locale. 5226 5227`dg-require-compat-dfp ""' 5228 Skip this test unless both compilers in a `compat' testsuite 5229 support decimal floating point. 5230 5231`dg-require-cxa-atexit ""' 5232 Skip the test if the target does not support `__cxa_atexit'. This 5233 is equivalent to `dg-require-effective-target cxa_atexit'. 5234 5235`dg-require-dll ""' 5236 Skip the test if the target does not support DLL attributes. 5237 5238`dg-require-fork ""' 5239 Skip the test if the target does not support `fork'. 5240 5241`dg-require-gc-sections ""' 5242 Skip the test if the target's linker does not support the 5243 `--gc-sections' flags. This is equivalent to 5244 `dg-require-effective-target gc-sections'. 5245 5246`dg-require-host-local ""' 5247 Skip the test if the host is remote, rather than the same as the 5248 build system. Some tests are incompatible with DejaGnu's handling 5249 of remote hosts, which involves copying the source file to the 5250 host and compiling it with a relative path and "`-o a.out'". 5251 5252`dg-require-mkfifo ""' 5253 Skip the test if the target does not support `mkfifo'. 5254 5255`dg-require-named-sections ""' 5256 Skip the test is the target does not support named sections. This 5257 is equivalent to `dg-require-effective-target named_sections'. 5258 5259`dg-require-weak ""' 5260 Skip the test if the target does not support weak symbols. 5261 5262`dg-require-weak-override ""' 5263 Skip the test if the target does not support overriding weak 5264 symbols. 5265 5266 5267File: gccint.info, Node: Final Actions, Prev: Require Support, Up: Test Directives 5268 52697.2.6 Commands for use in `dg-final' 5270------------------------------------ 5271 5272The GCC testsuite defines the following directives to be used within 5273`dg-final'. 5274 52757.2.6.1 Scan a particular file 5276.............................. 5277 5278`scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]' 5279 Passes if REGEXP matches text in FILENAME. 5280 5281`scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]' 5282 Passes if REGEXP does not match text in FILENAME. 5283 5284`scan-module MODULE REGEXP [{ target/xfail SELECTOR }]' 5285 Passes if REGEXP matches in Fortran module MODULE. 5286 52877.2.6.2 Scan the assembly output 5288................................ 5289 5290`scan-assembler REGEX [{ target/xfail SELECTOR }]' 5291 Passes if REGEX matches text in the test's assembler output. 5292 5293`scan-assembler-not REGEX [{ target/xfail SELECTOR }]' 5294 Passes if REGEX does not match text in the test's assembler output. 5295 5296`scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]' 5297 Passes if REGEX is matched exactly NUM times in the test's 5298 assembler output. 5299 5300`scan-assembler-dem REGEX [{ target/xfail SELECTOR }]' 5301 Passes if REGEX matches text in the test's demangled assembler 5302 output. 5303 5304`scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]' 5305 Passes if REGEX does not match text in the test's demangled 5306 assembler output. 5307 5308`scan-hidden SYMBOL [{ target/xfail SELECTOR }]' 5309 Passes if SYMBOL is defined as a hidden symbol in the test's 5310 assembly output. 5311 5312`scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]' 5313 Passes if SYMBOL is not defined as a hidden symbol in the test's 5314 assembly output. 5315 53167.2.6.3 Scan optimization dump files 5317.................................... 5318 5319These commands are available for KIND of `tree', `rtl', and `ipa'. 5320 5321`scan-KIND-dump REGEX SUFFIX [{ target/xfail SELECTOR }]' 5322 Passes if REGEX matches text in the dump file with suffix SUFFIX. 5323 5324`scan-KIND-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5325 Passes if REGEX does not match text in the dump file with suffix 5326 SUFFIX. 5327 5328`scan-KIND-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]' 5329 Passes if REGEX is found exactly NUM times in the dump file with 5330 suffix SUFFIX. 5331 5332`scan-KIND-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]' 5333 Passes if REGEX matches demangled text in the dump file with 5334 suffix SUFFIX. 5335 5336`scan-KIND-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5337 Passes if REGEX does not match demangled text in the dump file with 5338 suffix SUFFIX. 5339 53407.2.6.4 Verify that an output files exists or not 5341................................................. 5342 5343`output-exists [{ target/xfail SELECTOR }]' 5344 Passes if compiler output file exists. 5345 5346`output-exists-not [{ target/xfail SELECTOR }]' 5347 Passes if compiler output file does not exist. 5348 53497.2.6.5 Check for LTO tests 5350........................... 5351 5352`scan-symbol REGEXP [{ target/xfail SELECTOR }]' 5353 Passes if the pattern is present in the final executable. 5354 53557.2.6.6 Checks for `gcov' tests 5356............................... 5357 5358`run-gcov SOURCEFILE' 5359 Check line counts in `gcov' tests. 5360 5361`run-gcov [branches] [calls] { OPTS SOURCEFILE }' 5362 Check branch and/or call counts, in addition to line counts, in 5363 `gcov' tests. 5364 53657.2.6.7 Clean up generated test files 5366..................................... 5367 5368`cleanup-coverage-files' 5369 Removes coverage data files generated for this test. 5370 5371`cleanup-ipa-dump SUFFIX' 5372 Removes IPA dump files generated for this test. 5373 5374`cleanup-modules' 5375 Removes Fortran module files generated for this test. 5376 5377`cleanup-profile-file' 5378 Removes profiling files generated for this test. 5379 5380`cleanup-repo-files' 5381 Removes files generated for this test for `-frepo'. 5382 5383`cleanup-rtl-dump SUFFIX' 5384 Removes RTL dump files generated for this test. 5385 5386`cleanup-saved-temps' 5387 Removes files for the current test which were kept for 5388 `-save-temps'. 5389 5390`cleanup-tree-dump SUFFIX' 5391 Removes tree dump files matching SUFFIX which were generated for 5392 this test. 5393 5394 5395File: gccint.info, Node: Ada Tests, Next: C Tests, Prev: Test Directives, Up: Testsuites 5396 53977.3 Ada Language Testsuites 5398=========================== 5399 5400The Ada testsuite includes executable tests from the ACATS 2.5 5401testsuite, publicly available at 5402`http://www.adaic.org/compilers/acats/2.5'. 5403 5404 These tests are integrated in the GCC testsuite in the `ada/acats' 5405directory, and enabled automatically when running `make check', assuming 5406the Ada language has been enabled when configuring GCC. 5407 5408 You can also run the Ada testsuite independently, using `make 5409check-ada', or run a subset of the tests by specifying which chapter to 5410run, e.g.: 5411 5412 $ make check-ada CHAPTERS="c3 c9" 5413 5414 The tests are organized by directory, each directory corresponding to 5415a chapter of the Ada Reference Manual. So for example, `c9' corresponds 5416to chapter 9, which deals with tasking features of the language. 5417 5418 There is also an extra chapter called `gcc' containing a template for 5419creating new executable tests, although this is deprecated in favor of 5420the `gnat.dg' testsuite. 5421 5422 The tests are run using two `sh' scripts: `run_acats' and 5423`run_all.sh'. To run the tests using a simulator or a cross target, 5424see the small customization section at the top of `run_all.sh'. 5425 5426 These tests are run using the build tree: they can be run without doing 5427a `make install'. 5428 5429 5430File: gccint.info, Node: C Tests, Next: libgcj Tests, Prev: Ada Tests, Up: Testsuites 5431 54327.4 C Language Testsuites 5433========================= 5434 5435GCC contains the following C language testsuites, in the 5436`gcc/testsuite' directory: 5437 5438`gcc.dg' 5439 This contains tests of particular features of the C compiler, 5440 using the more modern `dg' harness. Correctness tests for various 5441 compiler features should go here if possible. 5442 5443 Magic comments determine whether the file is preprocessed, 5444 compiled, linked or run. In these tests, error and warning 5445 message texts are compared against expected texts or regular 5446 expressions given in comments. These tests are run with the 5447 options `-ansi -pedantic' unless other options are given in the 5448 test. Except as noted below they are not run with multiple 5449 optimization options. 5450 5451`gcc.dg/compat' 5452 This subdirectory contains tests for binary compatibility using 5453 `lib/compat.exp', which in turn uses the language-independent 5454 support (*note Support for testing binary compatibility: compat 5455 Testing.). 5456 5457`gcc.dg/cpp' 5458 This subdirectory contains tests of the preprocessor. 5459 5460`gcc.dg/debug' 5461 This subdirectory contains tests for debug formats. Tests in this 5462 subdirectory are run for each debug format that the compiler 5463 supports. 5464 5465`gcc.dg/format' 5466 This subdirectory contains tests of the `-Wformat' format 5467 checking. Tests in this directory are run with and without 5468 `-DWIDE'. 5469 5470`gcc.dg/noncompile' 5471 This subdirectory contains tests of code that should not compile 5472 and does not need any special compilation options. They are run 5473 with multiple optimization options, since sometimes invalid code 5474 crashes the compiler with optimization. 5475 5476`gcc.dg/special' 5477 FIXME: describe this. 5478 5479`gcc.c-torture' 5480 This contains particular code fragments which have historically 5481 broken easily. These tests are run with multiple optimization 5482 options, so tests for features which only break at some 5483 optimization levels belong here. This also contains tests to 5484 check that certain optimizations occur. It might be worthwhile to 5485 separate the correctness tests cleanly from the code quality 5486 tests, but it hasn't been done yet. 5487 5488`gcc.c-torture/compat' 5489 FIXME: describe this. 5490 5491 This directory should probably not be used for new tests. 5492 5493`gcc.c-torture/compile' 5494 This testsuite contains test cases that should compile, but do not 5495 need to link or run. These test cases are compiled with several 5496 different combinations of optimization options. All warnings are 5497 disabled for these test cases, so this directory is not suitable if 5498 you wish to test for the presence or absence of compiler warnings. 5499 While special options can be set, and tests disabled on specific 5500 platforms, by the use of `.x' files, mostly these test cases 5501 should not contain platform dependencies. FIXME: discuss how 5502 defines such as `NO_LABEL_VALUES' and `STACK_SIZE' are used. 5503 5504`gcc.c-torture/execute' 5505 This testsuite contains test cases that should compile, link and 5506 run; otherwise the same comments as for `gcc.c-torture/compile' 5507 apply. 5508 5509`gcc.c-torture/execute/ieee' 5510 This contains tests which are specific to IEEE floating point. 5511 5512`gcc.c-torture/unsorted' 5513 FIXME: describe this. 5514 5515 This directory should probably not be used for new tests. 5516 5517`gcc.misc-tests' 5518 This directory contains C tests that require special handling. 5519 Some of these tests have individual expect files, and others share 5520 special-purpose expect files: 5521 5522 ``bprob*.c'' 5523 Test `-fbranch-probabilities' using 5524 `gcc.misc-tests/bprob.exp', which in turn uses the generic, 5525 language-independent framework (*note Support for testing 5526 profile-directed optimizations: profopt Testing.). 5527 5528 ``gcov*.c'' 5529 Test `gcov' output using `gcov.exp', which in turn uses the 5530 language-independent support (*note Support for testing gcov: 5531 gcov Testing.). 5532 5533 ``i386-pf-*.c'' 5534 Test i386-specific support for data prefetch using 5535 `i386-prefetch.exp'. 5536 5537`gcc.test-framework' 5538 5539 ``dg-*.c'' 5540 Test the testsuite itself using 5541 `gcc.test-framework/test-framework.exp'. 5542 5543 5544 FIXME: merge in `testsuite/README.gcc' and discuss the format of test 5545cases and magic comments more. 5546 5547 5548File: gccint.info, Node: libgcj Tests, Next: LTO Testing, Prev: C Tests, Up: Testsuites 5549 55507.5 The Java library testsuites. 5551================================ 5552 5553Runtime tests are executed via `make check' in the 5554`TARGET/libjava/testsuite' directory in the build tree. Additional 5555runtime tests can be checked into this testsuite. 5556 5557 Regression testing of the core packages in libgcj is also covered by 5558the Mauve testsuite. The Mauve Project develops tests for the Java 5559Class Libraries. These tests are run as part of libgcj testing by 5560placing the Mauve tree within the libjava testsuite sources at 5561`libjava/testsuite/libjava.mauve/mauve', or by specifying the location 5562of that tree when invoking `make', as in `make MAUVEDIR=~/mauve check'. 5563 5564 To detect regressions, a mechanism in `mauve.exp' compares the 5565failures for a test run against the list of expected failures in 5566`libjava/testsuite/libjava.mauve/xfails' from the source hierarchy. 5567Update this file when adding new failing tests to Mauve, or when fixing 5568bugs in libgcj that had caused Mauve test failures. 5569 5570 We encourage developers to contribute test cases to Mauve. 5571 5572 5573File: gccint.info, Node: LTO Testing, Next: gcov Testing, Prev: libgcj Tests, Up: Testsuites 5574 55757.6 Support for testing link-time optimizations 5576=============================================== 5577 5578Tests for link-time optimizations usually require multiple source files 5579that are compiled separately, perhaps with different sets of options. 5580There are several special-purpose test directives used for these tests. 5581 5582`{ dg-lto-do DO-WHAT-KEYWORD }' 5583 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 5584 is executed. It is one of: 5585 5586 `assemble' 5587 Compile with `-c' to produce a relocatable object file. 5588 5589 `link' 5590 Compile, assemble, and link to produce an executable file. 5591 5592 `run' 5593 Produce and run an executable file, which is expected to 5594 return an exit code of 0. 5595 5596 The default is `assemble'. That can be overridden for a set of 5597 tests by redefining `dg-do-what-default' within the `.exp' file 5598 for those tests. 5599 5600 Unlike `dg-do', `dg-lto-do' does not support an optional `target' 5601 or `xfail' list. Use `dg-skip-if', `dg-xfail-if', or 5602 `dg-xfail-run-if'. 5603 5604`{ dg-lto-options { { OPTIONS } [{ OPTIONS }] } [{ target SELECTOR }]}' 5605 This directive provides a list of one or more sets of compiler 5606 options to override LTO_OPTIONS. Each test will be compiled and 5607 run with each of these sets of options. 5608 5609`{ dg-extra-ld-options OPTIONS }' 5610 This directive adds OPTIONS to the linker options used. 5611 5612`{ dg-suppress-ld-options OPTIONS }' 5613 This directive removes OPTIONS from the set of linker options used. 5614 5615 5616File: gccint.info, Node: gcov Testing, Next: profopt Testing, Prev: LTO Testing, Up: Testsuites 5617 56187.7 Support for testing `gcov' 5619============================== 5620 5621Language-independent support for testing `gcov', and for checking that 5622branch profiling produces expected values, is provided by the expect 5623file `lib/gcov.exp'. `gcov' tests also rely on procedures in 5624`lib/gcc-dg.exp' to compile and run the test program. A typical `gcov' 5625test contains the following DejaGnu commands within comments: 5626 5627 { dg-options "-fprofile-arcs -ftest-coverage" } 5628 { dg-do run { target native } } 5629 { dg-final { run-gcov sourcefile } } 5630 5631 Checks of `gcov' output can include line counts, branch percentages, 5632and call return percentages. All of these checks are requested via 5633commands that appear in comments in the test's source file. Commands 5634to check line counts are processed by default. Commands to check 5635branch percentages and call return percentages are processed if the 5636`run-gcov' command has arguments `branches' or `calls', respectively. 5637For example, the following specifies checking both, as well as passing 5638`-b' to `gcov': 5639 5640 { dg-final { run-gcov branches calls { -b sourcefile } } } 5641 5642 A line count command appears within a comment on the source line that 5643is expected to get the specified count and has the form `count(CNT)'. 5644A test should only check line counts for lines that will get the same 5645count for any architecture. 5646 5647 Commands to check branch percentages (`branch') and call return 5648percentages (`returns') are very similar to each other. A beginning 5649command appears on or before the first of a range of lines that will 5650report the percentage, and the ending command follows that range of 5651lines. The beginning command can include a list of percentages, all of 5652which are expected to be found within the range. A range is terminated 5653by the next command of the same kind. A command `branch(end)' or 5654`returns(end)' marks the end of a range without starting a new one. 5655For example: 5656 5657 if (i > 10 && j > i && j < 20) /* branch(27 50 75) */ 5658 /* branch(end) */ 5659 foo (i, j); 5660 5661 For a call return percentage, the value specified is the percentage of 5662calls reported to return. For a branch percentage, the value is either 5663the expected percentage or 100 minus that value, since the direction of 5664a branch can differ depending on the target or the optimization level. 5665 5666 Not all branches and calls need to be checked. A test should not 5667check for branches that might be optimized away or replaced with 5668predicated instructions. Don't check for calls inserted by the 5669compiler or ones that might be inlined or optimized away. 5670 5671 A single test can check for combinations of line counts, branch 5672percentages, and call return percentages. The command to check a line 5673count must appear on the line that will report that count, but commands 5674to check branch percentages and call return percentages can bracket the 5675lines that report them. 5676 5677 5678File: gccint.info, Node: profopt Testing, Next: compat Testing, Prev: gcov Testing, Up: Testsuites 5679 56807.8 Support for testing profile-directed optimizations 5681====================================================== 5682 5683The file `profopt.exp' provides language-independent support for 5684checking correct execution of a test built with profile-directed 5685optimization. This testing requires that a test program be built and 5686executed twice. The first time it is compiled to generate profile 5687data, and the second time it is compiled to use the data that was 5688generated during the first execution. The second execution is to 5689verify that the test produces the expected results. 5690 5691 To check that the optimization actually generated better code, a test 5692can be built and run a third time with normal optimizations to verify 5693that the performance is better with the profile-directed optimizations. 5694`profopt.exp' has the beginnings of this kind of support. 5695 5696 `profopt.exp' provides generic support for profile-directed 5697optimizations. Each set of tests that uses it provides information 5698about a specific optimization: 5699 5700`tool' 5701 tool being tested, e.g., `gcc' 5702 5703`profile_option' 5704 options used to generate profile data 5705 5706`feedback_option' 5707 options used to optimize using that profile data 5708 5709`prof_ext' 5710 suffix of profile data files 5711 5712`PROFOPT_OPTIONS' 5713 list of options with which to run each test, similar to the lists 5714 for torture tests 5715 5716`{ dg-final-generate { LOCAL-DIRECTIVE } }' 5717 This directive is similar to `dg-final', but the LOCAL-DIRECTIVE 5718 is run after the generation of profile data. 5719 5720`{ dg-final-use { LOCAL-DIRECTIVE } }' 5721 The LOCAL-DIRECTIVE is run after the profile data have been used. 5722 5723 5724File: gccint.info, Node: compat Testing, Next: Torture Tests, Prev: profopt Testing, Up: Testsuites 5725 57267.9 Support for testing binary compatibility 5727============================================ 5728 5729The file `compat.exp' provides language-independent support for binary 5730compatibility testing. It supports testing interoperability of two 5731compilers that follow the same ABI, or of multiple sets of compiler 5732options that should not affect binary compatibility. It is intended to 5733be used for testsuites that complement ABI testsuites. 5734 5735 A test supported by this framework has three parts, each in a separate 5736source file: a main program and two pieces that interact with each 5737other to split up the functionality being tested. 5738 5739`TESTNAME_main.SUFFIX' 5740 Contains the main program, which calls a function in file 5741 `TESTNAME_x.SUFFIX'. 5742 5743`TESTNAME_x.SUFFIX' 5744 Contains at least one call to a function in `TESTNAME_y.SUFFIX'. 5745 5746`TESTNAME_y.SUFFIX' 5747 Shares data with, or gets arguments from, `TESTNAME_x.SUFFIX'. 5748 5749 Within each test, the main program and one functional piece are 5750compiled by the GCC under test. The other piece can be compiled by an 5751alternate compiler. If no alternate compiler is specified, then all 5752three source files are all compiled by the GCC under test. You can 5753specify pairs of sets of compiler options. The first element of such a 5754pair specifies options used with the GCC under test, and the second 5755element of the pair specifies options used with the alternate compiler. 5756Each test is compiled with each pair of options. 5757 5758 `compat.exp' defines default pairs of compiler options. These can be 5759overridden by defining the environment variable `COMPAT_OPTIONS' as: 5760 5761 COMPAT_OPTIONS="[list [list {TST1} {ALT1}] 5762 ...[list {TSTN} {ALTN}]]" 5763 5764 where TSTI and ALTI are lists of options, with TSTI used by the 5765compiler under test and ALTI used by the alternate compiler. For 5766example, with `[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]', 5767the test is first built with `-g -O0' by the compiler under test and 5768with `-O3' by the alternate compiler. The test is built a second time 5769using `-fpic' by the compiler under test and `-fPIC -O2' by the 5770alternate compiler. 5771 5772 An alternate compiler is specified by defining an environment variable 5773to be the full pathname of an installed compiler; for C define 5774`ALT_CC_UNDER_TEST', and for C++ define `ALT_CXX_UNDER_TEST'. These 5775will be written to the `site.exp' file used by DejaGnu. The default is 5776to build each test with the compiler under test using the first of each 5777pair of compiler options from `COMPAT_OPTIONS'. When 5778`ALT_CC_UNDER_TEST' or `ALT_CXX_UNDER_TEST' is `same', each test is 5779built using the compiler under test but with combinations of the 5780options from `COMPAT_OPTIONS'. 5781 5782 To run only the C++ compatibility suite using the compiler under test 5783and another version of GCC using specific compiler options, do the 5784following from `OBJDIR/gcc': 5785 5786 rm site.exp 5787 make -k \ 5788 ALT_CXX_UNDER_TEST=${alt_prefix}/bin/g++ \ 5789 COMPAT_OPTIONS="LISTS AS SHOWN ABOVE" \ 5790 check-c++ \ 5791 RUNTESTFLAGS="compat.exp" 5792 5793 A test that fails when the source files are compiled with different 5794compilers, but passes when the files are compiled with the same 5795compiler, demonstrates incompatibility of the generated code or runtime 5796support. A test that fails for the alternate compiler but passes for 5797the compiler under test probably tests for a bug that was fixed in the 5798compiler under test but is present in the alternate compiler. 5799 5800 The binary compatibility tests support a small number of test framework 5801commands that appear within comments in a test file. 5802 5803`dg-require-*' 5804 These commands can be used in `TESTNAME_main.SUFFIX' to skip the 5805 test if specific support is not available on the target. 5806 5807`dg-options' 5808 The specified options are used for compiling this particular source 5809 file, appended to the options from `COMPAT_OPTIONS'. When this 5810 command appears in `TESTNAME_main.SUFFIX' the options are also 5811 used to link the test program. 5812 5813`dg-xfail-if' 5814 This command can be used in a secondary source file to specify that 5815 compilation is expected to fail for particular options on 5816 particular targets. 5817 5818 5819File: gccint.info, Node: Torture Tests, Prev: compat Testing, Up: Testsuites 5820 58217.10 Support for torture testing using multiple options 5822======================================================= 5823 5824Throughout the compiler testsuite there are several directories whose 5825tests are run multiple times, each with a different set of options. 5826These are known as torture tests. `lib/torture-options.exp' defines 5827procedures to set up these lists: 5828 5829`torture-init' 5830 Initialize use of torture lists. 5831 5832`set-torture-options' 5833 Set lists of torture options to use for tests with and without 5834 loops. Optionally combine a set of torture options with a set of 5835 other options, as is done with Objective-C runtime options. 5836 5837`torture-finish' 5838 Finalize use of torture lists. 5839 5840 The `.exp' file for a set of tests that use torture options must 5841include calls to these three procedures if: 5842 5843 * It calls `gcc-dg-runtest' and overrides DG_TORTURE_OPTIONS. 5844 5845 * It calls ${TOOL}`-torture' or ${TOOL}`-torture-execute', where 5846 TOOL is `c', `fortran', or `objc'. 5847 5848 * It calls `dg-pch'. 5849 5850 It is not necessary for a `.exp' file that calls `gcc-dg-runtest' to 5851call the torture procedures if the tests should use the list in 5852DG_TORTURE_OPTIONS defined in `gcc-dg.exp'. 5853 5854 Most uses of torture options can override the default lists by defining 5855TORTURE_OPTIONS or add to the default list by defining 5856ADDITIONAL_TORTURE_OPTIONS. Define these in a `.dejagnurc' file or add 5857them to the `site.exp' file; for example 5858 5859 set ADDITIONAL_TORTURE_OPTIONS [list \ 5860 { -O2 -ftree-loop-linear } \ 5861 { -O2 -fpeel-loops } ] 5862 5863 5864File: gccint.info, Node: Options, Next: Passes, Prev: Testsuites, Up: Top 5865 58668 Option specification files 5867**************************** 5868 5869Most GCC command-line options are described by special option 5870definition files, the names of which conventionally end in `.opt'. 5871This chapter describes the format of these files. 5872 5873* Menu: 5874 5875* Option file format:: The general layout of the files 5876* Option properties:: Supported option properties 5877 5878 5879File: gccint.info, Node: Option file format, Next: Option properties, Up: Options 5880 58818.1 Option file format 5882====================== 5883 5884Option files are a simple list of records in which each field occupies 5885its own line and in which the records themselves are separated by blank 5886lines. Comments may appear on their own line anywhere within the file 5887and are preceded by semicolons. Whitespace is allowed before the 5888semicolon. 5889 5890 The files can contain the following types of record: 5891 5892 * A language definition record. These records have two fields: the 5893 string `Language' and the name of the language. Once a language 5894 has been declared in this way, it can be used as an option 5895 property. *Note Option properties::. 5896 5897 * A target specific save record to save additional information. These 5898 records have two fields: the string `TargetSave', and a 5899 declaration type to go in the `cl_target_option' structure. 5900 5901 * An option definition record. These records have the following 5902 fields: 5903 1. the name of the option, with the leading "-" removed 5904 5905 2. a space-separated list of option properties (*note Option 5906 properties::) 5907 5908 3. the help text to use for `--help' (omitted if the second field 5909 contains the `Undocumented' property). 5910 5911 By default, all options beginning with "f", "W" or "m" are 5912 implicitly assumed to take a "no-" form. This form should not be 5913 listed separately. If an option beginning with one of these 5914 letters does not have a "no-" form, you can use the 5915 `RejectNegative' property to reject it. 5916 5917 The help text is automatically line-wrapped before being displayed. 5918 Normally the name of the option is printed on the left-hand side of 5919 the output and the help text is printed on the right. However, if 5920 the help text contains a tab character, the text to the left of 5921 the tab is used instead of the option's name and the text to the 5922 right of the tab forms the help text. This allows you to 5923 elaborate on what type of argument the option takes. 5924 5925 * A target mask record. These records have one field of the form 5926 `Mask(X)'. The options-processing script will automatically 5927 allocate a bit in `target_flags' (*note Run-time Target::) for 5928 each mask name X and set the macro `MASK_X' to the appropriate 5929 bitmask. It will also declare a `TARGET_X' macro that has the 5930 value 1 when bit `MASK_X' is set and 0 otherwise. 5931 5932 They are primarily intended to declare target masks that are not 5933 associated with user options, either because these masks represent 5934 internal switches or because the options are not available on all 5935 configurations and yet the masks always need to be defined. 5936 5937 5938File: gccint.info, Node: Option properties, Prev: Option file format, Up: Options 5939 59408.2 Option properties 5941===================== 5942 5943The second field of an option record can specify any of the following 5944properties. When an option takes an argument, it is enclosed in 5945parentheses following the option property name. The parser that 5946handles option files is quite simplistic, and will be tricked by any 5947nested parentheses within the argument text itself; in this case, the 5948entire option argument can be wrapped in curly braces within the 5949parentheses to demarcate it, e.g.: 5950 5951 Condition({defined (USE_CYGWIN_LIBSTDCXX_WRAPPERS)}) 5952 5953`Common' 5954 The option is available for all languages and targets. 5955 5956`Target' 5957 The option is available for all languages but is target-specific. 5958 5959`LANGUAGE' 5960 The option is available when compiling for the given language. 5961 5962 It is possible to specify several different languages for the same 5963 option. Each LANGUAGE must have been declared by an earlier 5964 `Language' record. *Note Option file format::. 5965 5966`RejectNegative' 5967 The option does not have a "no-" form. All options beginning with 5968 "f", "W" or "m" are assumed to have a "no-" form unless this 5969 property is used. 5970 5971`Negative(OTHERNAME)' 5972 The option will turn off another option OTHERNAME, which is the 5973 option name with the leading "-" removed. This chain action will 5974 propagate through the `Negative' property of the option to be 5975 turned off. 5976 5977`Joined' 5978`Separate' 5979 The option takes a mandatory argument. `Joined' indicates that 5980 the option and argument can be included in the same `argv' entry 5981 (as with `-mflush-func=NAME', for example). `Separate' indicates 5982 that the option and argument can be separate `argv' entries (as 5983 with `-o'). An option is allowed to have both of these properties. 5984 5985`JoinedOrMissing' 5986 The option takes an optional argument. If the argument is given, 5987 it will be part of the same `argv' entry as the option itself. 5988 5989 This property cannot be used alongside `Joined' or `Separate'. 5990 5991`UInteger' 5992 The option's argument is a non-negative integer. The option parser 5993 will check and convert the argument before passing it to the 5994 relevant option handler. `UInteger' should also be used on 5995 options like `-falign-loops' where both `-falign-loops' and 5996 `-falign-loops'=N are supported to make sure the saved options are 5997 given a full integer. 5998 5999`Var(VAR)' 6000 The state of this option should be stored in variable VAR. The 6001 way that the state is stored depends on the type of option: 6002 6003 * If the option uses the `Mask' or `InverseMask' properties, 6004 VAR is the integer variable that contains the mask. 6005 6006 * If the option is a normal on/off switch, VAR is an integer 6007 variable that is nonzero when the option is enabled. The 6008 options parser will set the variable to 1 when the positive 6009 form of the option is used and 0 when the "no-" form is used. 6010 6011 * If the option takes an argument and has the `UInteger' 6012 property, VAR is an integer variable that stores the value of 6013 the argument. 6014 6015 * Otherwise, if the option takes an argument, VAR is a pointer 6016 to the argument string. The pointer will be null if the 6017 argument is optional and wasn't given. 6018 6019 The option-processing script will usually declare VAR in 6020 `options.c' and leave it to be zero-initialized at start-up time. 6021 You can modify this behavior using `VarExists' and `Init'. 6022 6023`Var(VAR, SET)' 6024 The option controls an integer variable VAR and is active when VAR 6025 equals SET. The option parser will set VAR to SET when the 6026 positive form of the option is used and `!SET' when the "no-" form 6027 is used. 6028 6029 VAR is declared in the same way as for the single-argument form 6030 described above. 6031 6032`VarExists' 6033 The variable specified by the `Var' property already exists. No 6034 definition should be added to `options.c' in response to this 6035 option record. 6036 6037 You should use this property only if the variable is declared 6038 outside `options.c'. 6039 6040`Init(VALUE)' 6041 The variable specified by the `Var' property should be statically 6042 initialized to VALUE. 6043 6044`Mask(NAME)' 6045 The option is associated with a bit in the `target_flags' variable 6046 (*note Run-time Target::) and is active when that bit is set. You 6047 may also specify `Var' to select a variable other than 6048 `target_flags'. 6049 6050 The options-processing script will automatically allocate a unique 6051 bit for the option. If the option is attached to `target_flags', 6052 the script will set the macro `MASK_NAME' to the appropriate 6053 bitmask. It will also declare a `TARGET_NAME' macro that has the 6054 value 1 when the option is active and 0 otherwise. If you use 6055 `Var' to attach the option to a different variable, the associated 6056 macros are called `OPTION_MASK_NAME' and `OPTION_NAME' 6057 respectively. 6058 6059 You can disable automatic bit allocation using `MaskExists'. 6060 6061`InverseMask(OTHERNAME)' 6062`InverseMask(OTHERNAME, THISNAME)' 6063 The option is the inverse of another option that has the 6064 `Mask(OTHERNAME)' property. If THISNAME is given, the 6065 options-processing script will declare a `TARGET_THISNAME' macro 6066 that is 1 when the option is active and 0 otherwise. 6067 6068`MaskExists' 6069 The mask specified by the `Mask' property already exists. No 6070 `MASK' or `TARGET' definitions should be added to `options.h' in 6071 response to this option record. 6072 6073 The main purpose of this property is to support synonymous options. 6074 The first option should use `Mask(NAME)' and the others should use 6075 `Mask(NAME) MaskExists'. 6076 6077`Report' 6078 The state of the option should be printed by `-fverbose-asm'. 6079 6080`Undocumented' 6081 The option is deliberately missing documentation and should not be 6082 included in the `--help' output. 6083 6084`Condition(COND)' 6085 The option should only be accepted if preprocessor condition COND 6086 is true. Note that any C declarations associated with the option 6087 will be present even if COND is false; COND simply controls 6088 whether the option is accepted and whether it is printed in the 6089 `--help' output. 6090 6091`Save' 6092 Build the `cl_target_option' structure to hold a copy of the 6093 option, add the functions `cl_target_option_save' and 6094 `cl_target_option_restore' to save and restore the options. 6095 6096 6097File: gccint.info, Node: Passes, Next: GENERIC, Prev: Options, Up: Top 6098 60999 Passes and Files of the Compiler 6100********************************** 6101 6102This chapter is dedicated to giving an overview of the optimization and 6103code generation passes of the compiler. In the process, it describes 6104some of the language front end interface, though this description is no 6105where near complete. 6106 6107* Menu: 6108 6109* Parsing pass:: The language front end turns text into bits. 6110* Gimplification pass:: The bits are turned into something we can optimize. 6111* Pass manager:: Sequencing the optimization passes. 6112* Tree SSA passes:: Optimizations on a high-level representation. 6113* RTL passes:: Optimizations on a low-level representation. 6114 6115 6116File: gccint.info, Node: Parsing pass, Next: Gimplification pass, Up: Passes 6117 61189.1 Parsing pass 6119================ 6120 6121The language front end is invoked only once, via 6122`lang_hooks.parse_file', to parse the entire input. The language front 6123end may use any intermediate language representation deemed 6124appropriate. The C front end uses GENERIC trees (CROSSREF), plus a 6125double handful of language specific tree codes defined in 6126`c-common.def'. The Fortran front end uses a completely different 6127private representation. 6128 6129 At some point the front end must translate the representation used in 6130the front end to a representation understood by the language-independent 6131portions of the compiler. Current practice takes one of two forms. 6132The C front end manually invokes the gimplifier (CROSSREF) on each 6133function, and uses the gimplifier callbacks to convert the 6134language-specific tree nodes directly to GIMPLE (CROSSREF) before 6135passing the function off to be compiled. The Fortran front end 6136converts from a private representation to GENERIC, which is later 6137lowered to GIMPLE when the function is compiled. Which route to choose 6138probably depends on how well GENERIC (plus extensions) can be made to 6139match up with the source language and necessary parsing data structures. 6140 6141 BUG: Gimplification must occur before nested function lowering, and 6142nested function lowering must be done by the front end before passing 6143the data off to cgraph. 6144 6145 TODO: Cgraph should control nested function lowering. It would only 6146be invoked when it is certain that the outer-most function is used. 6147 6148 TODO: Cgraph needs a gimplify_function callback. It should be invoked 6149when (1) it is certain that the function is used, (2) warning flags 6150specified by the user require some amount of compilation in order to 6151honor, (3) the language indicates that semantic analysis is not 6152complete until gimplification occurs. Hum... this sounds overly 6153complicated. Perhaps we should just have the front end gimplify 6154always; in most cases it's only one function call. 6155 6156 The front end needs to pass all function definitions and top level 6157declarations off to the middle-end so that they can be compiled and 6158emitted to the object file. For a simple procedural language, it is 6159usually most convenient to do this as each top level declaration or 6160definition is seen. There is also a distinction to be made between 6161generating functional code and generating complete debug information. 6162The only thing that is absolutely required for functional code is that 6163function and data _definitions_ be passed to the middle-end. For 6164complete debug information, function, data and type declarations should 6165all be passed as well. 6166 6167 In any case, the front end needs each complete top-level function or 6168data declaration, and each data definition should be passed to 6169`rest_of_decl_compilation'. Each complete type definition should be 6170passed to `rest_of_type_compilation'. Each function definition should 6171be passed to `cgraph_finalize_function'. 6172 6173 TODO: I know rest_of_compilation currently has all sorts of RTL 6174generation semantics. I plan to move all code generation bits (both 6175Tree and RTL) to compile_function. Should we hide cgraph from the 6176front ends and move back to rest_of_compilation as the official 6177interface? Possibly we should rename all three interfaces such that 6178the names match in some meaningful way and that is more descriptive 6179than "rest_of". 6180 6181 The middle-end will, at its option, emit the function and data 6182definitions immediately or queue them for later processing. 6183 6184 6185File: gccint.info, Node: Gimplification pass, Next: Pass manager, Prev: Parsing pass, Up: Passes 6186 61879.2 Gimplification pass 6188======================= 6189 6190"Gimplification" is a whimsical term for the process of converting the 6191intermediate representation of a function into the GIMPLE language 6192(CROSSREF). The term stuck, and so words like "gimplification", 6193"gimplify", "gimplifier" and the like are sprinkled throughout this 6194section of code. 6195 6196 While a front end may certainly choose to generate GIMPLE directly if 6197it chooses, this can be a moderately complex process unless the 6198intermediate language used by the front end is already fairly simple. 6199Usually it is easier to generate GENERIC trees plus extensions and let 6200the language-independent gimplifier do most of the work. 6201 6202 The main entry point to this pass is `gimplify_function_tree' located 6203in `gimplify.c'. From here we process the entire function gimplifying 6204each statement in turn. The main workhorse for this pass is 6205`gimplify_expr'. Approximately everything passes through here at least 6206once, and it is from here that we invoke the `lang_hooks.gimplify_expr' 6207callback. 6208 6209 The callback should examine the expression in question and return 6210`GS_UNHANDLED' if the expression is not a language specific construct 6211that requires attention. Otherwise it should alter the expression in 6212some way to such that forward progress is made toward producing valid 6213GIMPLE. If the callback is certain that the transformation is complete 6214and the expression is valid GIMPLE, it should return `GS_ALL_DONE'. 6215Otherwise it should return `GS_OK', which will cause the expression to 6216be processed again. If the callback encounters an error during the 6217transformation (because the front end is relying on the gimplification 6218process to finish semantic checks), it should return `GS_ERROR'. 6219 6220 6221File: gccint.info, Node: Pass manager, Next: Tree SSA passes, Prev: Gimplification pass, Up: Passes 6222 62239.3 Pass manager 6224================ 6225 6226The pass manager is located in `passes.c', `tree-optimize.c' and 6227`tree-pass.h'. Its job is to run all of the individual passes in the 6228correct order, and take care of standard bookkeeping that applies to 6229every pass. 6230 6231 The theory of operation is that each pass defines a structure that 6232represents everything we need to know about that pass--when it should 6233be run, how it should be run, what intermediate language form or 6234on-the-side data structures it needs. We register the pass to be run 6235in some particular order, and the pass manager arranges for everything 6236to happen in the correct order. 6237 6238 The actuality doesn't completely live up to the theory at present. 6239Command-line switches and `timevar_id_t' enumerations must still be 6240defined elsewhere. The pass manager validates constraints but does not 6241attempt to (re-)generate data structures or lower intermediate language 6242form based on the requirements of the next pass. Nevertheless, what is 6243present is useful, and a far sight better than nothing at all. 6244 6245 Each pass should have a unique name. Each pass may have its own dump 6246file (for GCC debugging purposes). Passes with a name starting with a 6247star do not dump anything. Sometimes passes are supposed to share a 6248dump file / option name. To still give these unique names, you can use 6249a prefix that is delimited by a space from the part that is used for 6250the dump file / option name. E.g. When the pass name is "ud dce", the 6251name used for dump file/options is "dce". 6252 6253 TODO: describe the global variables set up by the pass manager, and a 6254brief description of how a new pass should use it. I need to look at 6255what info RTL passes use first... 6256 6257 6258File: gccint.info, Node: Tree SSA passes, Next: RTL passes, Prev: Pass manager, Up: Passes 6259 62609.4 Tree SSA passes 6261=================== 6262 6263The following briefly describes the Tree optimization passes that are 6264run after gimplification and what source files they are located in. 6265 6266 * Remove useless statements 6267 6268 This pass is an extremely simple sweep across the gimple code in 6269 which we identify obviously dead code and remove it. Here we do 6270 things like simplify `if' statements with constant conditions, 6271 remove exception handling constructs surrounding code that 6272 obviously cannot throw, remove lexical bindings that contain no 6273 variables, and other assorted simplistic cleanups. The idea is to 6274 get rid of the obvious stuff quickly rather than wait until later 6275 when it's more work to get rid of it. This pass is located in 6276 `tree-cfg.c' and described by `pass_remove_useless_stmts'. 6277 6278 * Mudflap declaration registration 6279 6280 If mudflap (*note -fmudflap -fmudflapth -fmudflapir: (gcc)Optimize 6281 Options.) is enabled, we generate code to register some variable 6282 declarations with the mudflap runtime. Specifically, the runtime 6283 tracks the lifetimes of those variable declarations that have 6284 their addresses taken, or whose bounds are unknown at compile time 6285 (`extern'). This pass generates new exception handling constructs 6286 (`try'/`finally'), and so must run before those are lowered. In 6287 addition, the pass enqueues declarations of static variables whose 6288 lifetimes extend to the entire program. The pass is located in 6289 `tree-mudflap.c' and is described by `pass_mudflap_1'. 6290 6291 * OpenMP lowering 6292 6293 If OpenMP generation (`-fopenmp') is enabled, this pass lowers 6294 OpenMP constructs into GIMPLE. 6295 6296 Lowering of OpenMP constructs involves creating replacement 6297 expressions for local variables that have been mapped using data 6298 sharing clauses, exposing the control flow of most synchronization 6299 directives and adding region markers to facilitate the creation of 6300 the control flow graph. The pass is located in `omp-low.c' and is 6301 described by `pass_lower_omp'. 6302 6303 * OpenMP expansion 6304 6305 If OpenMP generation (`-fopenmp') is enabled, this pass expands 6306 parallel regions into their own functions to be invoked by the 6307 thread library. The pass is located in `omp-low.c' and is 6308 described by `pass_expand_omp'. 6309 6310 * Lower control flow 6311 6312 This pass flattens `if' statements (`COND_EXPR') and moves lexical 6313 bindings (`BIND_EXPR') out of line. After this pass, all `if' 6314 statements will have exactly two `goto' statements in its `then' 6315 and `else' arms. Lexical binding information for each statement 6316 will be found in `TREE_BLOCK' rather than being inferred from its 6317 position under a `BIND_EXPR'. This pass is found in 6318 `gimple-low.c' and is described by `pass_lower_cf'. 6319 6320 * Lower exception handling control flow 6321 6322 This pass decomposes high-level exception handling constructs 6323 (`TRY_FINALLY_EXPR' and `TRY_CATCH_EXPR') into a form that 6324 explicitly represents the control flow involved. After this pass, 6325 `lookup_stmt_eh_region' will return a non-negative number for any 6326 statement that may have EH control flow semantics; examine 6327 `tree_can_throw_internal' or `tree_can_throw_external' for exact 6328 semantics. Exact control flow may be extracted from 6329 `foreach_reachable_handler'. The EH region nesting tree is defined 6330 in `except.h' and built in `except.c'. The lowering pass itself 6331 is in `tree-eh.c' and is described by `pass_lower_eh'. 6332 6333 * Build the control flow graph 6334 6335 This pass decomposes a function into basic blocks and creates all 6336 of the edges that connect them. It is located in `tree-cfg.c' and 6337 is described by `pass_build_cfg'. 6338 6339 * Find all referenced variables 6340 6341 This pass walks the entire function and collects an array of all 6342 variables referenced in the function, `referenced_vars'. The 6343 index at which a variable is found in the array is used as a UID 6344 for the variable within this function. This data is needed by the 6345 SSA rewriting routines. The pass is located in `tree-dfa.c' and 6346 is described by `pass_referenced_vars'. 6347 6348 * Enter static single assignment form 6349 6350 This pass rewrites the function such that it is in SSA form. After 6351 this pass, all `is_gimple_reg' variables will be referenced by 6352 `SSA_NAME', and all occurrences of other variables will be 6353 annotated with `VDEFS' and `VUSES'; PHI nodes will have been 6354 inserted as necessary for each basic block. This pass is located 6355 in `tree-ssa.c' and is described by `pass_build_ssa'. 6356 6357 * Warn for uninitialized variables 6358 6359 This pass scans the function for uses of `SSA_NAME's that are fed 6360 by default definition. For non-parameter variables, such uses are 6361 uninitialized. The pass is run twice, before and after 6362 optimization (if turned on). In the first pass we only warn for 6363 uses that are positively uninitialized; in the second pass we warn 6364 for uses that are possibly uninitialized. The pass is located in 6365 `tree-ssa.c' and is defined by `pass_early_warn_uninitialized' and 6366 `pass_late_warn_uninitialized'. 6367 6368 * Dead code elimination 6369 6370 This pass scans the function for statements without side effects 6371 whose result is unused. It does not do memory life analysis, so 6372 any value that is stored in memory is considered used. The pass 6373 is run multiple times throughout the optimization process. It is 6374 located in `tree-ssa-dce.c' and is described by `pass_dce'. 6375 6376 * Dominator optimizations 6377 6378 This pass performs trivial dominator-based copy and constant 6379 propagation, expression simplification, and jump threading. It is 6380 run multiple times throughout the optimization process. It is 6381 located in `tree-ssa-dom.c' and is described by `pass_dominator'. 6382 6383 * Forward propagation of single-use variables 6384 6385 This pass attempts to remove redundant computation by substituting 6386 variables that are used once into the expression that uses them and 6387 seeing if the result can be simplified. It is located in 6388 `tree-ssa-forwprop.c' and is described by `pass_forwprop'. 6389 6390 * Copy Renaming 6391 6392 This pass attempts to change the name of compiler temporaries 6393 involved in copy operations such that SSA->normal can coalesce the 6394 copy away. When compiler temporaries are copies of user 6395 variables, it also renames the compiler temporary to the user 6396 variable resulting in better use of user symbols. It is located 6397 in `tree-ssa-copyrename.c' and is described by `pass_copyrename'. 6398 6399 * PHI node optimizations 6400 6401 This pass recognizes forms of PHI inputs that can be represented as 6402 conditional expressions and rewrites them into straight line code. 6403 It is located in `tree-ssa-phiopt.c' and is described by 6404 `pass_phiopt'. 6405 6406 * May-alias optimization 6407 6408 This pass performs a flow sensitive SSA-based points-to analysis. 6409 The resulting may-alias, must-alias, and escape analysis 6410 information is used to promote variables from in-memory 6411 addressable objects to non-aliased variables that can be renamed 6412 into SSA form. We also update the `VDEF'/`VUSE' memory tags for 6413 non-renameable aggregates so that we get fewer false kills. The 6414 pass is located in `tree-ssa-alias.c' and is described by 6415 `pass_may_alias'. 6416 6417 Interprocedural points-to information is located in 6418 `tree-ssa-structalias.c' and described by `pass_ipa_pta'. 6419 6420 * Profiling 6421 6422 This pass rewrites the function in order to collect runtime block 6423 and value profiling data. Such data may be fed back into the 6424 compiler on a subsequent run so as to allow optimization based on 6425 expected execution frequencies. The pass is located in 6426 `predict.c' and is described by `pass_profile'. 6427 6428 * Lower complex arithmetic 6429 6430 This pass rewrites complex arithmetic operations into their 6431 component scalar arithmetic operations. The pass is located in 6432 `tree-complex.c' and is described by `pass_lower_complex'. 6433 6434 * Scalar replacement of aggregates 6435 6436 This pass rewrites suitable non-aliased local aggregate variables 6437 into a set of scalar variables. The resulting scalar variables are 6438 rewritten into SSA form, which allows subsequent optimization 6439 passes to do a significantly better job with them. The pass is 6440 located in `tree-sra.c' and is described by `pass_sra'. 6441 6442 * Dead store elimination 6443 6444 This pass eliminates stores to memory that are subsequently 6445 overwritten by another store, without any intervening loads. The 6446 pass is located in `tree-ssa-dse.c' and is described by `pass_dse'. 6447 6448 * Tail recursion elimination 6449 6450 This pass transforms tail recursion into a loop. It is located in 6451 `tree-tailcall.c' and is described by `pass_tail_recursion'. 6452 6453 * Forward store motion 6454 6455 This pass sinks stores and assignments down the flowgraph closer 6456 to their use point. The pass is located in `tree-ssa-sink.c' and 6457 is described by `pass_sink_code'. 6458 6459 * Partial redundancy elimination 6460 6461 This pass eliminates partially redundant computations, as well as 6462 performing load motion. The pass is located in `tree-ssa-pre.c' 6463 and is described by `pass_pre'. 6464 6465 Just before partial redundancy elimination, if 6466 `-funsafe-math-optimizations' is on, GCC tries to convert 6467 divisions to multiplications by the reciprocal. The pass is 6468 located in `tree-ssa-math-opts.c' and is described by 6469 `pass_cse_reciprocal'. 6470 6471 * Full redundancy elimination 6472 6473 This is a simpler form of PRE that only eliminates redundancies 6474 that occur an all paths. It is located in `tree-ssa-pre.c' and 6475 described by `pass_fre'. 6476 6477 * Loop optimization 6478 6479 The main driver of the pass is placed in `tree-ssa-loop.c' and 6480 described by `pass_loop'. 6481 6482 The optimizations performed by this pass are: 6483 6484 Loop invariant motion. This pass moves only invariants that would 6485 be hard to handle on RTL level (function calls, operations that 6486 expand to nontrivial sequences of insns). With `-funswitch-loops' 6487 it also moves operands of conditions that are invariant out of the 6488 loop, so that we can use just trivial invariantness analysis in 6489 loop unswitching. The pass also includes store motion. The pass 6490 is implemented in `tree-ssa-loop-im.c'. 6491 6492 Canonical induction variable creation. This pass creates a simple 6493 counter for number of iterations of the loop and replaces the exit 6494 condition of the loop using it, in case when a complicated 6495 analysis is necessary to determine the number of iterations. 6496 Later optimizations then may determine the number easily. The 6497 pass is implemented in `tree-ssa-loop-ivcanon.c'. 6498 6499 Induction variable optimizations. This pass performs standard 6500 induction variable optimizations, including strength reduction, 6501 induction variable merging and induction variable elimination. 6502 The pass is implemented in `tree-ssa-loop-ivopts.c'. 6503 6504 Loop unswitching. This pass moves the conditional jumps that are 6505 invariant out of the loops. To achieve this, a duplicate of the 6506 loop is created for each possible outcome of conditional jump(s). 6507 The pass is implemented in `tree-ssa-loop-unswitch.c'. This pass 6508 should eventually replace the RTL level loop unswitching in 6509 `loop-unswitch.c', but currently the RTL level pass is not 6510 completely redundant yet due to deficiencies in tree level alias 6511 analysis. 6512 6513 The optimizations also use various utility functions contained in 6514 `tree-ssa-loop-manip.c', `cfgloop.c', `cfgloopanal.c' and 6515 `cfgloopmanip.c'. 6516 6517 Vectorization. This pass transforms loops to operate on vector 6518 types instead of scalar types. Data parallelism across loop 6519 iterations is exploited to group data elements from consecutive 6520 iterations into a vector and operate on them in parallel. 6521 Depending on available target support the loop is conceptually 6522 unrolled by a factor `VF' (vectorization factor), which is the 6523 number of elements operated upon in parallel in each iteration, 6524 and the `VF' copies of each scalar operation are fused to form a 6525 vector operation. Additional loop transformations such as peeling 6526 and versioning may take place to align the number of iterations, 6527 and to align the memory accesses in the loop. The pass is 6528 implemented in `tree-vectorizer.c' (the main driver), 6529 `tree-vect-loop.c' and `tree-vect-loop-manip.c' (loop specific 6530 parts and general loop utilities), `tree-vect-slp' (loop-aware SLP 6531 functionality), `tree-vect-stmts.c' and `tree-vect-data-refs.c'. 6532 Analysis of data references is in `tree-data-ref.c'. 6533 6534 SLP Vectorization. This pass performs vectorization of 6535 straight-line code. The pass is implemented in `tree-vectorizer.c' 6536 (the main driver), `tree-vect-slp.c', `tree-vect-stmts.c' and 6537 `tree-vect-data-refs.c'. 6538 6539 Autoparallelization. This pass splits the loop iteration space to 6540 run into several threads. The pass is implemented in 6541 `tree-parloops.c'. 6542 6543 Graphite is a loop transformation framework based on the polyhedral 6544 model. Graphite stands for Gimple Represented as Polyhedra. The 6545 internals of this infrastructure are documented in 6546 `http://gcc.gnu.org/wiki/Graphite'. The passes working on this 6547 representation are implemented in the various `graphite-*' files. 6548 6549 * Tree level if-conversion for vectorizer 6550 6551 This pass applies if-conversion to simple loops to help vectorizer. 6552 We identify if convertible loops, if-convert statements and merge 6553 basic blocks in one big block. The idea is to present loop in such 6554 form so that vectorizer can have one to one mapping between 6555 statements and available vector operations. This patch 6556 re-introduces COND_EXPR at GIMPLE level. This pass is located in 6557 `tree-if-conv.c' and is described by `pass_if_conversion'. 6558 6559 * Conditional constant propagation 6560 6561 This pass relaxes a lattice of values in order to identify those 6562 that must be constant even in the presence of conditional branches. 6563 The pass is located in `tree-ssa-ccp.c' and is described by 6564 `pass_ccp'. 6565 6566 A related pass that works on memory loads and stores, and not just 6567 register values, is located in `tree-ssa-ccp.c' and described by 6568 `pass_store_ccp'. 6569 6570 * Conditional copy propagation 6571 6572 This is similar to constant propagation but the lattice of values 6573 is the "copy-of" relation. It eliminates redundant copies from the 6574 code. The pass is located in `tree-ssa-copy.c' and described by 6575 `pass_copy_prop'. 6576 6577 A related pass that works on memory copies, and not just register 6578 copies, is located in `tree-ssa-copy.c' and described by 6579 `pass_store_copy_prop'. 6580 6581 * Value range propagation 6582 6583 This transformation is similar to constant propagation but instead 6584 of propagating single constant values, it propagates known value 6585 ranges. The implementation is based on Patterson's range 6586 propagation algorithm (Accurate Static Branch Prediction by Value 6587 Range Propagation, J. R. C. Patterson, PLDI '95). In contrast to 6588 Patterson's algorithm, this implementation does not propagate 6589 branch probabilities nor it uses more than a single range per SSA 6590 name. This means that the current implementation cannot be used 6591 for branch prediction (though adapting it would not be difficult). 6592 The pass is located in `tree-vrp.c' and is described by `pass_vrp'. 6593 6594 * Folding built-in functions 6595 6596 This pass simplifies built-in functions, as applicable, with 6597 constant arguments or with inferable string lengths. It is 6598 located in `tree-ssa-ccp.c' and is described by 6599 `pass_fold_builtins'. 6600 6601 * Split critical edges 6602 6603 This pass identifies critical edges and inserts empty basic blocks 6604 such that the edge is no longer critical. The pass is located in 6605 `tree-cfg.c' and is described by `pass_split_crit_edges'. 6606 6607 * Control dependence dead code elimination 6608 6609 This pass is a stronger form of dead code elimination that can 6610 eliminate unnecessary control flow statements. It is located in 6611 `tree-ssa-dce.c' and is described by `pass_cd_dce'. 6612 6613 * Tail call elimination 6614 6615 This pass identifies function calls that may be rewritten into 6616 jumps. No code transformation is actually applied here, but the 6617 data and control flow problem is solved. The code transformation 6618 requires target support, and so is delayed until RTL. In the 6619 meantime `CALL_EXPR_TAILCALL' is set indicating the possibility. 6620 The pass is located in `tree-tailcall.c' and is described by 6621 `pass_tail_calls'. The RTL transformation is handled by 6622 `fixup_tail_calls' in `calls.c'. 6623 6624 * Warn for function return without value 6625 6626 For non-void functions, this pass locates return statements that do 6627 not specify a value and issues a warning. Such a statement may 6628 have been injected by falling off the end of the function. This 6629 pass is run last so that we have as much time as possible to prove 6630 that the statement is not reachable. It is located in 6631 `tree-cfg.c' and is described by `pass_warn_function_return'. 6632 6633 * Mudflap statement annotation 6634 6635 If mudflap is enabled, we rewrite some memory accesses with code to 6636 validate that the memory access is correct. In particular, 6637 expressions involving pointer dereferences (`INDIRECT_REF', 6638 `ARRAY_REF', etc.) are replaced by code that checks the selected 6639 address range against the mudflap runtime's database of valid 6640 regions. This check includes an inline lookup into a 6641 direct-mapped cache, based on shift/mask operations of the pointer 6642 value, with a fallback function call into the runtime. The pass 6643 is located in `tree-mudflap.c' and is described by 6644 `pass_mudflap_2'. 6645 6646 * Leave static single assignment form 6647 6648 This pass rewrites the function such that it is in normal form. At 6649 the same time, we eliminate as many single-use temporaries as 6650 possible, so the intermediate language is no longer GIMPLE, but 6651 GENERIC. The pass is located in `tree-outof-ssa.c' and is 6652 described by `pass_del_ssa'. 6653 6654 * Merge PHI nodes that feed into one another 6655 6656 This is part of the CFG cleanup passes. It attempts to join PHI 6657 nodes from a forwarder CFG block into another block with PHI 6658 nodes. The pass is located in `tree-cfgcleanup.c' and is 6659 described by `pass_merge_phi'. 6660 6661 * Return value optimization 6662 6663 If a function always returns the same local variable, and that 6664 local variable is an aggregate type, then the variable is replaced 6665 with the return value for the function (i.e., the function's 6666 DECL_RESULT). This is equivalent to the C++ named return value 6667 optimization applied to GIMPLE. The pass is located in 6668 `tree-nrv.c' and is described by `pass_nrv'. 6669 6670 * Return slot optimization 6671 6672 If a function returns a memory object and is called as `var = 6673 foo()', this pass tries to change the call so that the address of 6674 `var' is sent to the caller to avoid an extra memory copy. This 6675 pass is located in `tree-nrv.c' and is described by 6676 `pass_return_slot'. 6677 6678 * Optimize calls to `__builtin_object_size' 6679 6680 This is a propagation pass similar to CCP that tries to remove 6681 calls to `__builtin_object_size' when the size of the object can be 6682 computed at compile-time. This pass is located in 6683 `tree-object-size.c' and is described by `pass_object_sizes'. 6684 6685 * Loop invariant motion 6686 6687 This pass removes expensive loop-invariant computations out of 6688 loops. The pass is located in `tree-ssa-loop.c' and described by 6689 `pass_lim'. 6690 6691 * Loop nest optimizations 6692 6693 This is a family of loop transformations that works on loop nests. 6694 It includes loop interchange, scaling, skewing and reversal and 6695 they are all geared to the optimization of data locality in array 6696 traversals and the removal of dependencies that hamper 6697 optimizations such as loop parallelization and vectorization. The 6698 pass is located in `tree-loop-linear.c' and described by 6699 `pass_linear_transform'. 6700 6701 * Removal of empty loops 6702 6703 This pass removes loops with no code in them. The pass is located 6704 in `tree-ssa-loop-ivcanon.c' and described by `pass_empty_loop'. 6705 6706 * Unrolling of small loops 6707 6708 This pass completely unrolls loops with few iterations. The pass 6709 is located in `tree-ssa-loop-ivcanon.c' and described by 6710 `pass_complete_unroll'. 6711 6712 * Predictive commoning 6713 6714 This pass makes the code reuse the computations from the previous 6715 iterations of the loops, especially loads and stores to memory. 6716 It does so by storing the values of these computations to a bank 6717 of temporary variables that are rotated at the end of loop. To 6718 avoid the need for this rotation, the loop is then unrolled and 6719 the copies of the loop body are rewritten to use the appropriate 6720 version of the temporary variable. This pass is located in 6721 `tree-predcom.c' and described by `pass_predcom'. 6722 6723 * Array prefetching 6724 6725 This pass issues prefetch instructions for array references inside 6726 loops. The pass is located in `tree-ssa-loop-prefetch.c' and 6727 described by `pass_loop_prefetch'. 6728 6729 * Reassociation 6730 6731 This pass rewrites arithmetic expressions to enable optimizations 6732 that operate on them, like redundancy elimination and 6733 vectorization. The pass is located in `tree-ssa-reassoc.c' and 6734 described by `pass_reassoc'. 6735 6736 * Optimization of `stdarg' functions 6737 6738 This pass tries to avoid the saving of register arguments into the 6739 stack on entry to `stdarg' functions. If the function doesn't use 6740 any `va_start' macros, no registers need to be saved. If 6741 `va_start' macros are used, the `va_list' variables don't escape 6742 the function, it is only necessary to save registers that will be 6743 used in `va_arg' macros. For instance, if `va_arg' is only used 6744 with integral types in the function, floating point registers 6745 don't need to be saved. This pass is located in `tree-stdarg.c' 6746 and described by `pass_stdarg'. 6747 6748 6749 6750File: gccint.info, Node: RTL passes, Prev: Tree SSA passes, Up: Passes 6751 67529.5 RTL passes 6753============== 6754 6755The following briefly describes the RTL generation and optimization 6756passes that are run after the Tree optimization passes. 6757 6758 * RTL generation 6759 6760 The source files for RTL generation include `stmt.c', `calls.c', 6761 `expr.c', `explow.c', `expmed.c', `function.c', `optabs.c' and 6762 `emit-rtl.c'. Also, the file `insn-emit.c', generated from the 6763 machine description by the program `genemit', is used in this 6764 pass. The header file `expr.h' is used for communication within 6765 this pass. 6766 6767 The header files `insn-flags.h' and `insn-codes.h', generated from 6768 the machine description by the programs `genflags' and `gencodes', 6769 tell this pass which standard names are available for use and 6770 which patterns correspond to them. 6771 6772 * Generation of exception landing pads 6773 6774 This pass generates the glue that handles communication between the 6775 exception handling library routines and the exception handlers 6776 within the function. Entry points in the function that are 6777 invoked by the exception handling library are called "landing 6778 pads". The code for this pass is located in `except.c'. 6779 6780 * Control flow graph cleanup 6781 6782 This pass removes unreachable code, simplifies jumps to next, 6783 jumps to jump, jumps across jumps, etc. The pass is run multiple 6784 times. For historical reasons, it is occasionally referred to as 6785 the "jump optimization pass". The bulk of the code for this pass 6786 is in `cfgcleanup.c', and there are support routines in `cfgrtl.c' 6787 and `jump.c'. 6788 6789 * Forward propagation of single-def values 6790 6791 This pass attempts to remove redundant computation by substituting 6792 variables that come from a single definition, and seeing if the 6793 result can be simplified. It performs copy propagation and 6794 addressing mode selection. The pass is run twice, with values 6795 being propagated into loops only on the second run. The code is 6796 located in `fwprop.c'. 6797 6798 * Common subexpression elimination 6799 6800 This pass removes redundant computation within basic blocks, and 6801 optimizes addressing modes based on cost. The pass is run twice. 6802 The code for this pass is located in `cse.c'. 6803 6804 * Global common subexpression elimination 6805 6806 This pass performs two different types of GCSE depending on 6807 whether you are optimizing for size or not (LCM based GCSE tends 6808 to increase code size for a gain in speed, while Morel-Renvoise 6809 based GCSE does not). When optimizing for size, GCSE is done 6810 using Morel-Renvoise Partial Redundancy Elimination, with the 6811 exception that it does not try to move invariants out of 6812 loops--that is left to the loop optimization pass. If MR PRE 6813 GCSE is done, code hoisting (aka unification) is also done, as 6814 well as load motion. If you are optimizing for speed, LCM (lazy 6815 code motion) based GCSE is done. LCM is based on the work of 6816 Knoop, Ruthing, and Steffen. LCM based GCSE also does loop 6817 invariant code motion. We also perform load and store motion when 6818 optimizing for speed. Regardless of which type of GCSE is used, 6819 the GCSE pass also performs global constant and copy propagation. 6820 The source file for this pass is `gcse.c', and the LCM routines 6821 are in `lcm.c'. 6822 6823 * Loop optimization 6824 6825 This pass performs several loop related optimizations. The source 6826 files `cfgloopanal.c' and `cfgloopmanip.c' contain generic loop 6827 analysis and manipulation code. Initialization and finalization 6828 of loop structures is handled by `loop-init.c'. A loop invariant 6829 motion pass is implemented in `loop-invariant.c'. Basic block 6830 level optimizations--unrolling, peeling and unswitching loops-- 6831 are implemented in `loop-unswitch.c' and `loop-unroll.c'. 6832 Replacing of the exit condition of loops by special 6833 machine-dependent instructions is handled by `loop-doloop.c'. 6834 6835 * Jump bypassing 6836 6837 This pass is an aggressive form of GCSE that transforms the control 6838 flow graph of a function by propagating constants into conditional 6839 branch instructions. The source file for this pass is `gcse.c'. 6840 6841 * If conversion 6842 6843 This pass attempts to replace conditional branches and surrounding 6844 assignments with arithmetic, boolean value producing comparison 6845 instructions, and conditional move instructions. In the very last 6846 invocation after reload, it will generate predicated instructions 6847 when supported by the target. The code is located in `ifcvt.c'. 6848 6849 * Web construction 6850 6851 This pass splits independent uses of each pseudo-register. This 6852 can improve effect of the other transformation, such as CSE or 6853 register allocation. The code for this pass is located in `web.c'. 6854 6855 * Instruction combination 6856 6857 This pass attempts to combine groups of two or three instructions 6858 that are related by data flow into single instructions. It 6859 combines the RTL expressions for the instructions by substitution, 6860 simplifies the result using algebra, and then attempts to match 6861 the result against the machine description. The code is located 6862 in `combine.c'. 6863 6864 * Register movement 6865 6866 This pass looks for cases where matching constraints would force an 6867 instruction to need a reload, and this reload would be a 6868 register-to-register move. It then attempts to change the 6869 registers used by the instruction to avoid the move instruction. 6870 The code is located in `regmove.c'. 6871 6872 * Mode switching optimization 6873 6874 This pass looks for instructions that require the processor to be 6875 in a specific "mode" and minimizes the number of mode changes 6876 required to satisfy all users. What these modes are, and what 6877 they apply to are completely target-specific. The code for this 6878 pass is located in `mode-switching.c'. 6879 6880 * Modulo scheduling 6881 6882 This pass looks at innermost loops and reorders their instructions 6883 by overlapping different iterations. Modulo scheduling is 6884 performed immediately before instruction scheduling. The code for 6885 this pass is located in `modulo-sched.c'. 6886 6887 * Instruction scheduling 6888 6889 This pass looks for instructions whose output will not be 6890 available by the time that it is used in subsequent instructions. 6891 Memory loads and floating point instructions often have this 6892 behavior on RISC machines. It re-orders instructions within a 6893 basic block to try to separate the definition and use of items 6894 that otherwise would cause pipeline stalls. This pass is 6895 performed twice, before and after register allocation. The code 6896 for this pass is located in `haifa-sched.c', `sched-deps.c', 6897 `sched-ebb.c', `sched-rgn.c' and `sched-vis.c'. 6898 6899 * Register allocation 6900 6901 These passes make sure that all occurrences of pseudo registers are 6902 eliminated, either by allocating them to a hard register, replacing 6903 them by an equivalent expression (e.g. a constant) or by placing 6904 them on the stack. This is done in several subpasses: 6905 6906 * Register move optimizations. This pass makes some simple RTL 6907 code transformations which improve the subsequent register 6908 allocation. The source file is `regmove.c'. 6909 6910 * The integrated register allocator (IRA). It is called 6911 integrated because coalescing, register live range splitting, 6912 and hard register preferencing are done on-the-fly during 6913 coloring. It also has better integration with the reload 6914 pass. Pseudo-registers spilled by the allocator or the 6915 reload have still a chance to get hard-registers if the 6916 reload evicts some pseudo-registers from hard-registers. The 6917 allocator helps to choose better pseudos for spilling based 6918 on their live ranges and to coalesce stack slots allocated 6919 for the spilled pseudo-registers. IRA is a regional register 6920 allocator which is transformed into Chaitin-Briggs allocator 6921 if there is one region. By default, IRA chooses regions using 6922 register pressure but the user can force it to use one region 6923 or regions corresponding to all loops. 6924 6925 Source files of the allocator are `ira.c', `ira-build.c', 6926 `ira-costs.c', `ira-conflicts.c', `ira-color.c', 6927 `ira-emit.c', `ira-lives', plus header files `ira.h' and 6928 `ira-int.h' used for the communication between the allocator 6929 and the rest of the compiler and between the IRA files. 6930 6931 * Reloading. This pass renumbers pseudo registers with the 6932 hardware registers numbers they were allocated. Pseudo 6933 registers that did not get hard registers are replaced with 6934 stack slots. Then it finds instructions that are invalid 6935 because a value has failed to end up in a register, or has 6936 ended up in a register of the wrong kind. It fixes up these 6937 instructions by reloading the problematical values 6938 temporarily into registers. Additional instructions are 6939 generated to do the copying. 6940 6941 The reload pass also optionally eliminates the frame pointer 6942 and inserts instructions to save and restore call-clobbered 6943 registers around calls. 6944 6945 Source files are `reload.c' and `reload1.c', plus the header 6946 `reload.h' used for communication between them. 6947 6948 * Basic block reordering 6949 6950 This pass implements profile guided code positioning. If profile 6951 information is not available, various types of static analysis are 6952 performed to make the predictions normally coming from the profile 6953 feedback (IE execution frequency, branch probability, etc). It is 6954 implemented in the file `bb-reorder.c', and the various prediction 6955 routines are in `predict.c'. 6956 6957 * Variable tracking 6958 6959 This pass computes where the variables are stored at each position 6960 in code and generates notes describing the variable locations to 6961 RTL code. The location lists are then generated according to these 6962 notes to debug information if the debugging information format 6963 supports location lists. The code is located in `var-tracking.c'. 6964 6965 * Delayed branch scheduling 6966 6967 This optional pass attempts to find instructions that can go into 6968 the delay slots of other instructions, usually jumps and calls. 6969 The code for this pass is located in `reorg.c'. 6970 6971 * Branch shortening 6972 6973 On many RISC machines, branch instructions have a limited range. 6974 Thus, longer sequences of instructions must be used for long 6975 branches. In this pass, the compiler figures out what how far 6976 each instruction will be from each other instruction, and 6977 therefore whether the usual instructions, or the longer sequences, 6978 must be used for each branch. The code for this pass is located 6979 in `final.c'. 6980 6981 * Register-to-stack conversion 6982 6983 Conversion from usage of some hard registers to usage of a register 6984 stack may be done at this point. Currently, this is supported only 6985 for the floating-point registers of the Intel 80387 coprocessor. 6986 The code for this pass is located in `reg-stack.c'. 6987 6988 * Final 6989 6990 This pass outputs the assembler code for the function. The source 6991 files are `final.c' plus `insn-output.c'; the latter is generated 6992 automatically from the machine description by the tool `genoutput'. 6993 The header file `conditions.h' is used for communication between 6994 these files. If mudflap is enabled, the queue of deferred 6995 declarations and any addressed constants (e.g., string literals) 6996 is processed by `mudflap_finish_file' into a synthetic constructor 6997 function containing calls into the mudflap runtime. 6998 6999 * Debugging information output 7000 7001 This is run after final because it must output the stack slot 7002 offsets for pseudo registers that did not get hard registers. 7003 Source files are `dbxout.c' for DBX symbol table format, 7004 `sdbout.c' for SDB symbol table format, `dwarfout.c' for DWARF 7005 symbol table format, files `dwarf2out.c' and `dwarf2asm.c' for 7006 DWARF2 symbol table format, and `vmsdbgout.c' for VMS debug symbol 7007 table format. 7008 7009 7010 7011File: gccint.info, Node: RTL, Next: Control Flow, Prev: Tree SSA, Up: Top 7012 701310 RTL Representation 7014********************* 7015 7016The last part of the compiler work is done on a low-level intermediate 7017representation called Register Transfer Language. In this language, the 7018instructions to be output are described, pretty much one by one, in an 7019algebraic form that describes what the instruction does. 7020 7021 RTL is inspired by Lisp lists. It has both an internal form, made up 7022of structures that point at other structures, and a textual form that 7023is used in the machine description and in printed debugging dumps. The 7024textual form uses nested parentheses to indicate the pointers in the 7025internal form. 7026 7027* Menu: 7028 7029* RTL Objects:: Expressions vs vectors vs strings vs integers. 7030* RTL Classes:: Categories of RTL expression objects, and their structure. 7031* Accessors:: Macros to access expression operands or vector elts. 7032* Special Accessors:: Macros to access specific annotations on RTL. 7033* Flags:: Other flags in an RTL expression. 7034* Machine Modes:: Describing the size and format of a datum. 7035* Constants:: Expressions with constant values. 7036* Regs and Memory:: Expressions representing register contents or memory. 7037* Arithmetic:: Expressions representing arithmetic on other expressions. 7038* Comparisons:: Expressions representing comparison of expressions. 7039* Bit-Fields:: Expressions representing bit-fields in memory or reg. 7040* Vector Operations:: Expressions involving vector datatypes. 7041* Conversions:: Extending, truncating, floating or fixing. 7042* RTL Declarations:: Declaring volatility, constancy, etc. 7043* Side Effects:: Expressions for storing in registers, etc. 7044* Incdec:: Embedded side-effects for autoincrement addressing. 7045* Assembler:: Representing `asm' with operands. 7046* Debug Information:: Expressions representing debugging information. 7047* Insns:: Expression types for entire insns. 7048* Calls:: RTL representation of function call insns. 7049* Sharing:: Some expressions are unique; others *must* be copied. 7050* Reading RTL:: Reading textual RTL from a file. 7051 7052 7053File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL 7054 705510.1 RTL Object Types 7056===================== 7057 7058RTL uses five kinds of objects: expressions, integers, wide integers, 7059strings and vectors. Expressions are the most important ones. An RTL 7060expression ("RTX", for short) is a C structure, but it is usually 7061referred to with a pointer; a type that is given the typedef name `rtx'. 7062 7063 An integer is simply an `int'; their written form uses decimal digits. 7064A wide integer is an integral object whose type is `HOST_WIDE_INT'; 7065their written form uses decimal digits. 7066 7067 A string is a sequence of characters. In core it is represented as a 7068`char *' in usual C fashion, and it is written in C syntax as well. 7069However, strings in RTL may never be null. If you write an empty 7070string in a machine description, it is represented in core as a null 7071pointer rather than as a pointer to a null character. In certain 7072contexts, these null pointers instead of strings are valid. Within RTL 7073code, strings are most commonly found inside `symbol_ref' expressions, 7074but they appear in other contexts in the RTL expressions that make up 7075machine descriptions. 7076 7077 In a machine description, strings are normally written with double 7078quotes, as you would in C. However, strings in machine descriptions may 7079extend over many lines, which is invalid C, and adjacent string 7080constants are not concatenated as they are in C. Any string constant 7081may be surrounded with a single set of parentheses. Sometimes this 7082makes the machine description easier to read. 7083 7084 There is also a special syntax for strings, which can be useful when C 7085code is embedded in a machine description. Wherever a string can 7086appear, it is also valid to write a C-style brace block. The entire 7087brace block, including the outermost pair of braces, is considered to be 7088the string constant. Double quote characters inside the braces are not 7089special. Therefore, if you write string constants in the C code, you 7090need not escape each quote character with a backslash. 7091 7092 A vector contains an arbitrary number of pointers to expressions. The 7093number of elements in the vector is explicitly present in the vector. 7094The written form of a vector consists of square brackets (`[...]') 7095surrounding the elements, in sequence and with whitespace separating 7096them. Vectors of length zero are not created; null pointers are used 7097instead. 7098 7099 Expressions are classified by "expression codes" (also called RTX 7100codes). The expression code is a name defined in `rtl.def', which is 7101also (in uppercase) a C enumeration constant. The possible expression 7102codes and their meanings are machine-independent. The code of an RTX 7103can be extracted with the macro `GET_CODE (X)' and altered with 7104`PUT_CODE (X, NEWCODE)'. 7105 7106 The expression code determines how many operands the expression 7107contains, and what kinds of objects they are. In RTL, unlike Lisp, you 7108cannot tell by looking at an operand what kind of object it is. 7109Instead, you must know from its context--from the expression code of 7110the containing expression. For example, in an expression of code 7111`subreg', the first operand is to be regarded as an expression and the 7112second operand as an integer. In an expression of code `plus', there 7113are two operands, both of which are to be regarded as expressions. In 7114a `symbol_ref' expression, there is one operand, which is to be 7115regarded as a string. 7116 7117 Expressions are written as parentheses containing the name of the 7118expression type, its flags and machine mode if any, and then the 7119operands of the expression (separated by spaces). 7120 7121 Expression code names in the `md' file are written in lowercase, but 7122when they appear in C code they are written in uppercase. In this 7123manual, they are shown as follows: `const_int'. 7124 7125 In a few contexts a null pointer is valid where an expression is 7126normally wanted. The written form of this is `(nil)'. 7127 7128 7129File: gccint.info, Node: RTL Classes, Next: Accessors, Prev: RTL Objects, Up: RTL 7130 713110.2 RTL Classes and Formats 7132============================ 7133 7134The various expression codes are divided into several "classes", which 7135are represented by single characters. You can determine the class of 7136an RTX code with the macro `GET_RTX_CLASS (CODE)'. Currently, 7137`rtl.def' defines these classes: 7138 7139`RTX_OBJ' 7140 An RTX code that represents an actual object, such as a register 7141 (`REG') or a memory location (`MEM', `SYMBOL_REF'). `LO_SUM') is 7142 also included; instead, `SUBREG' and `STRICT_LOW_PART' are not in 7143 this class, but in class `x'. 7144 7145`RTX_CONST_OBJ' 7146 An RTX code that represents a constant object. `HIGH' is also 7147 included in this class. 7148 7149`RTX_COMPARE' 7150 An RTX code for a non-symmetric comparison, such as `GEU' or `LT'. 7151 7152`RTX_COMM_COMPARE' 7153 An RTX code for a symmetric (commutative) comparison, such as `EQ' 7154 or `ORDERED'. 7155 7156`RTX_UNARY' 7157 An RTX code for a unary arithmetic operation, such as `NEG', 7158 `NOT', or `ABS'. This category also includes value extension 7159 (sign or zero) and conversions between integer and floating point. 7160 7161`RTX_COMM_ARITH' 7162 An RTX code for a commutative binary operation, such as `PLUS' or 7163 `AND'. `NE' and `EQ' are comparisons, so they have class `<'. 7164 7165`RTX_BIN_ARITH' 7166 An RTX code for a non-commutative binary operation, such as 7167 `MINUS', `DIV', or `ASHIFTRT'. 7168 7169`RTX_BITFIELD_OPS' 7170 An RTX code for a bit-field operation. Currently only 7171 `ZERO_EXTRACT' and `SIGN_EXTRACT'. These have three inputs and 7172 are lvalues (so they can be used for insertion as well). *Note 7173 Bit-Fields::. 7174 7175`RTX_TERNARY' 7176 An RTX code for other three input operations. Currently only 7177 `IF_THEN_ELSE' and `VEC_MERGE'. 7178 7179`RTX_INSN' 7180 An RTX code for an entire instruction: `INSN', `JUMP_INSN', and 7181 `CALL_INSN'. *Note Insns::. 7182 7183`RTX_MATCH' 7184 An RTX code for something that matches in insns, such as 7185 `MATCH_DUP'. These only occur in machine descriptions. 7186 7187`RTX_AUTOINC' 7188 An RTX code for an auto-increment addressing mode, such as 7189 `POST_INC'. 7190 7191`RTX_EXTRA' 7192 All other RTX codes. This category includes the remaining codes 7193 used only in machine descriptions (`DEFINE_*', etc.). It also 7194 includes all the codes describing side effects (`SET', `USE', 7195 `CLOBBER', etc.) and the non-insns that may appear on an insn 7196 chain, such as `NOTE', `BARRIER', and `CODE_LABEL'. `SUBREG' is 7197 also part of this class. 7198 7199 For each expression code, `rtl.def' specifies the number of contained 7200objects and their kinds using a sequence of characters called the 7201"format" of the expression code. For example, the format of `subreg' 7202is `ei'. 7203 7204 These are the most commonly used format characters: 7205 7206`e' 7207 An expression (actually a pointer to an expression). 7208 7209`i' 7210 An integer. 7211 7212`w' 7213 A wide integer. 7214 7215`s' 7216 A string. 7217 7218`E' 7219 A vector of expressions. 7220 7221 A few other format characters are used occasionally: 7222 7223`u' 7224 `u' is equivalent to `e' except that it is printed differently in 7225 debugging dumps. It is used for pointers to insns. 7226 7227`n' 7228 `n' is equivalent to `i' except that it is printed differently in 7229 debugging dumps. It is used for the line number or code number of 7230 a `note' insn. 7231 7232`S' 7233 `S' indicates a string which is optional. In the RTL objects in 7234 core, `S' is equivalent to `s', but when the object is read, from 7235 an `md' file, the string value of this operand may be omitted. An 7236 omitted string is taken to be the null string. 7237 7238`V' 7239 `V' indicates a vector which is optional. In the RTL objects in 7240 core, `V' is equivalent to `E', but when the object is read from 7241 an `md' file, the vector value of this operand may be omitted. An 7242 omitted vector is effectively the same as a vector of no elements. 7243 7244`B' 7245 `B' indicates a pointer to basic block structure. 7246 7247`0' 7248 `0' means a slot whose contents do not fit any normal category. 7249 `0' slots are not printed at all in dumps, and are often used in 7250 special ways by small parts of the compiler. 7251 7252 There are macros to get the number of operands and the format of an 7253expression code: 7254 7255`GET_RTX_LENGTH (CODE)' 7256 Number of operands of an RTX of code CODE. 7257 7258`GET_RTX_FORMAT (CODE)' 7259 The format of an RTX of code CODE, as a C string. 7260 7261 Some classes of RTX codes always have the same format. For example, it 7262is safe to assume that all comparison operations have format `ee'. 7263 7264`1' 7265 All codes of this class have format `e'. 7266 7267`<' 7268`c' 7269`2' 7270 All codes of these classes have format `ee'. 7271 7272`b' 7273`3' 7274 All codes of these classes have format `eee'. 7275 7276`i' 7277 All codes of this class have formats that begin with `iuueiee'. 7278 *Note Insns::. Note that not all RTL objects linked onto an insn 7279 chain are of class `i'. 7280 7281`o' 7282`m' 7283`x' 7284 You can make no assumptions about the format of these codes. 7285 7286 7287File: gccint.info, Node: Accessors, Next: Special Accessors, Prev: RTL Classes, Up: RTL 7288 728910.3 Access to Operands 7290======================= 7291 7292Operands of expressions are accessed using the macros `XEXP', `XINT', 7293`XWINT' and `XSTR'. Each of these macros takes two arguments: an 7294expression-pointer (RTX) and an operand number (counting from zero). 7295Thus, 7296 7297 XEXP (X, 2) 7298 7299accesses operand 2 of expression X, as an expression. 7300 7301 XINT (X, 2) 7302 7303accesses the same operand as an integer. `XSTR', used in the same 7304fashion, would access it as a string. 7305 7306 Any operand can be accessed as an integer, as an expression or as a 7307string. You must choose the correct method of access for the kind of 7308value actually stored in the operand. You would do this based on the 7309expression code of the containing expression. That is also how you 7310would know how many operands there are. 7311 7312 For example, if X is a `subreg' expression, you know that it has two 7313operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X, 73141)'. If you did `XINT (X, 0)', you would get the address of the 7315expression operand but cast as an integer; that might occasionally be 7316useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP 7317(X, 1)' would also compile without error, and would return the second, 7318integer operand cast as an expression pointer, which would probably 7319result in a crash when accessed. Nothing stops you from writing `XEXP 7320(X, 28)' either, but this will access memory past the end of the 7321expression with unpredictable results. 7322 7323 Access to operands which are vectors is more complicated. You can use 7324the macro `XVEC' to get the vector-pointer itself, or the macros 7325`XVECEXP' and `XVECLEN' to access the elements and length of a vector. 7326 7327`XVEC (EXP, IDX)' 7328 Access the vector-pointer which is operand number IDX in EXP. 7329 7330`XVECLEN (EXP, IDX)' 7331 Access the length (number of elements) in the vector which is in 7332 operand number IDX in EXP. This value is an `int'. 7333 7334`XVECEXP (EXP, IDX, ELTNUM)' 7335 Access element number ELTNUM in the vector which is in operand 7336 number IDX in EXP. This value is an RTX. 7337 7338 It is up to you to make sure that ELTNUM is not negative and is 7339 less than `XVECLEN (EXP, IDX)'. 7340 7341 All the macros defined in this section expand into lvalues and 7342therefore can be used to assign the operands, lengths and vector 7343elements as well as to access them. 7344 7345 7346File: gccint.info, Node: Special Accessors, Next: Flags, Prev: Accessors, Up: RTL 7347 734810.4 Access to Special Operands 7349=============================== 7350 7351Some RTL nodes have special annotations associated with them. 7352 7353`MEM' 7354 7355 `MEM_ALIAS_SET (X)' 7356 If 0, X is not in any alias set, and may alias anything. 7357 Otherwise, X can only alias `MEM's in a conflicting alias 7358 set. This value is set in a language-dependent manner in the 7359 front-end, and should not be altered in the back-end. In 7360 some front-ends, these numbers may correspond in some way to 7361 types, or other language-level entities, but they need not, 7362 and the back-end makes no such assumptions. These set 7363 numbers are tested with `alias_sets_conflict_p'. 7364 7365 `MEM_EXPR (X)' 7366 If this register is known to hold the value of some user-level 7367 declaration, this is that tree node. It may also be a 7368 `COMPONENT_REF', in which case this is some field reference, 7369 and `TREE_OPERAND (X, 0)' contains the declaration, or 7370 another `COMPONENT_REF', or null if there is no compile-time 7371 object associated with the reference. 7372 7373 `MEM_OFFSET (X)' 7374 The offset from the start of `MEM_EXPR' as a `CONST_INT' rtx. 7375 7376 `MEM_SIZE (X)' 7377 The size in bytes of the memory reference as a `CONST_INT' 7378 rtx. This is mostly relevant for `BLKmode' references as 7379 otherwise the size is implied by the mode. 7380 7381 `MEM_ALIGN (X)' 7382 The known alignment in bits of the memory reference. 7383 7384 `MEM_ADDR_SPACE (X)' 7385 The address space of the memory reference. This will 7386 commonly be zero for the generic address space. 7387 7388`REG' 7389 7390 `ORIGINAL_REGNO (X)' 7391 This field holds the number the register "originally" had; 7392 for a pseudo register turned into a hard reg this will hold 7393 the old pseudo register number. 7394 7395 `REG_EXPR (X)' 7396 If this register is known to hold the value of some user-level 7397 declaration, this is that tree node. 7398 7399 `REG_OFFSET (X)' 7400 If this register is known to hold the value of some user-level 7401 declaration, this is the offset into that logical storage. 7402 7403`SYMBOL_REF' 7404 7405 `SYMBOL_REF_DECL (X)' 7406 If the `symbol_ref' X was created for a `VAR_DECL' or a 7407 `FUNCTION_DECL', that tree is recorded here. If this value is 7408 null, then X was created by back end code generation routines, 7409 and there is no associated front end symbol table entry. 7410 7411 `SYMBOL_REF_DECL' may also point to a tree of class `'c'', 7412 that is, some sort of constant. In this case, the 7413 `symbol_ref' is an entry in the per-file constant pool; 7414 again, there is no associated front end symbol table entry. 7415 7416 `SYMBOL_REF_CONSTANT (X)' 7417 If `CONSTANT_POOL_ADDRESS_P (X)' is true, this is the constant 7418 pool entry for X. It is null otherwise. 7419 7420 `SYMBOL_REF_DATA (X)' 7421 A field of opaque type used to store `SYMBOL_REF_DECL' or 7422 `SYMBOL_REF_CONSTANT'. 7423 7424 `SYMBOL_REF_FLAGS (X)' 7425 In a `symbol_ref', this is used to communicate various 7426 predicates about the symbol. Some of these are common enough 7427 to be computed by common code, some are specific to the 7428 target. The common bits are: 7429 7430 `SYMBOL_FLAG_FUNCTION' 7431 Set if the symbol refers to a function. 7432 7433 `SYMBOL_FLAG_LOCAL' 7434 Set if the symbol is local to this "module". See 7435 `TARGET_BINDS_LOCAL_P'. 7436 7437 `SYMBOL_FLAG_EXTERNAL' 7438 Set if this symbol is not defined in this translation 7439 unit. Note that this is not the inverse of 7440 `SYMBOL_FLAG_LOCAL'. 7441 7442 `SYMBOL_FLAG_SMALL' 7443 Set if the symbol is located in the small data section. 7444 See `TARGET_IN_SMALL_DATA_P'. 7445 7446 `SYMBOL_REF_TLS_MODEL (X)' 7447 This is a multi-bit field accessor that returns the 7448 `tls_model' to be used for a thread-local storage 7449 symbol. It returns zero for non-thread-local symbols. 7450 7451 `SYMBOL_FLAG_HAS_BLOCK_INFO' 7452 Set if the symbol has `SYMBOL_REF_BLOCK' and 7453 `SYMBOL_REF_BLOCK_OFFSET' fields. 7454 7455 `SYMBOL_FLAG_ANCHOR' 7456 Set if the symbol is used as a section anchor. "Section 7457 anchors" are symbols that have a known position within 7458 an `object_block' and that can be used to access nearby 7459 members of that block. They are used to implement 7460 `-fsection-anchors'. 7461 7462 If this flag is set, then `SYMBOL_FLAG_HAS_BLOCK_INFO' 7463 will be too. 7464 7465 Bits beginning with `SYMBOL_FLAG_MACH_DEP' are available for 7466 the target's use. 7467 7468`SYMBOL_REF_BLOCK (X)' 7469 If `SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the `object_block' 7470 structure to which the symbol belongs, or `NULL' if it has not 7471 been assigned a block. 7472 7473`SYMBOL_REF_BLOCK_OFFSET (X)' 7474 If `SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the offset of X from 7475 the first object in `SYMBOL_REF_BLOCK (X)'. The value is negative 7476 if X has not yet been assigned to a block, or it has not been 7477 given an offset within that block. 7478 7479 7480File: gccint.info, Node: Flags, Next: Machine Modes, Prev: Special Accessors, Up: RTL 7481 748210.5 Flags in an RTL Expression 7483=============================== 7484 7485RTL expressions contain several flags (one-bit bit-fields) that are 7486used in certain types of expression. Most often they are accessed with 7487the following macros, which expand into lvalues. 7488 7489`CONSTANT_POOL_ADDRESS_P (X)' 7490 Nonzero in a `symbol_ref' if it refers to part of the current 7491 function's constant pool. For most targets these addresses are in 7492 a `.rodata' section entirely separate from the function, but for 7493 some targets the addresses are close to the beginning of the 7494 function. In either case GCC assumes these addresses can be 7495 addressed directly, perhaps with the help of base registers. 7496 Stored in the `unchanging' field and printed as `/u'. 7497 7498`RTL_CONST_CALL_P (X)' 7499 In a `call_insn' indicates that the insn represents a call to a 7500 const function. Stored in the `unchanging' field and printed as 7501 `/u'. 7502 7503`RTL_PURE_CALL_P (X)' 7504 In a `call_insn' indicates that the insn represents a call to a 7505 pure function. Stored in the `return_val' field and printed as 7506 `/i'. 7507 7508`RTL_CONST_OR_PURE_CALL_P (X)' 7509 In a `call_insn', true if `RTL_CONST_CALL_P' or `RTL_PURE_CALL_P' 7510 is true. 7511 7512`RTL_LOOPING_CONST_OR_PURE_CALL_P (X)' 7513 In a `call_insn' indicates that the insn represents a possibly 7514 infinite looping call to a const or pure function. Stored in the 7515 `call' field and printed as `/c'. Only true if one of 7516 `RTL_CONST_CALL_P' or `RTL_PURE_CALL_P' is true. 7517 7518`INSN_ANNULLED_BRANCH_P (X)' 7519 In a `jump_insn', `call_insn', or `insn' indicates that the branch 7520 is an annulling one. See the discussion under `sequence' below. 7521 Stored in the `unchanging' field and printed as `/u'. 7522 7523`INSN_DELETED_P (X)' 7524 In an `insn', `call_insn', `jump_insn', `code_label', `barrier', 7525 or `note', nonzero if the insn has been deleted. Stored in the 7526 `volatil' field and printed as `/v'. 7527 7528`INSN_FROM_TARGET_P (X)' 7529 In an `insn' or `jump_insn' or `call_insn' in a delay slot of a 7530 branch, indicates that the insn is from the target of the branch. 7531 If the branch insn has `INSN_ANNULLED_BRANCH_P' set, this insn 7532 will only be executed if the branch is taken. For annulled 7533 branches with `INSN_FROM_TARGET_P' clear, the insn will be 7534 executed only if the branch is not taken. When 7535 `INSN_ANNULLED_BRANCH_P' is not set, this insn will always be 7536 executed. Stored in the `in_struct' field and printed as `/s'. 7537 7538`LABEL_PRESERVE_P (X)' 7539 In a `code_label' or `note', indicates that the label is 7540 referenced by code or data not visible to the RTL of a given 7541 function. Labels referenced by a non-local goto will have this 7542 bit set. Stored in the `in_struct' field and printed as `/s'. 7543 7544`LABEL_REF_NONLOCAL_P (X)' 7545 In `label_ref' and `reg_label' expressions, nonzero if this is a 7546 reference to a non-local label. Stored in the `volatil' field and 7547 printed as `/v'. 7548 7549`MEM_IN_STRUCT_P (X)' 7550 In `mem' expressions, nonzero for reference to an entire structure, 7551 union or array, or to a component of one. Zero for references to a 7552 scalar variable or through a pointer to a scalar. If both this 7553 flag and `MEM_SCALAR_P' are clear, then we don't know whether this 7554 `mem' is in a structure or not. Both flags should never be 7555 simultaneously set. Stored in the `in_struct' field and printed 7556 as `/s'. 7557 7558`MEM_KEEP_ALIAS_SET_P (X)' 7559 In `mem' expressions, 1 if we should keep the alias set for this 7560 mem unchanged when we access a component. Set to 1, for example, 7561 when we are already in a non-addressable component of an aggregate. 7562 Stored in the `jump' field and printed as `/j'. 7563 7564`MEM_SCALAR_P (X)' 7565 In `mem' expressions, nonzero for reference to a scalar known not 7566 to be a member of a structure, union, or array. Zero for such 7567 references and for indirections through pointers, even pointers 7568 pointing to scalar types. If both this flag and `MEM_IN_STRUCT_P' 7569 are clear, then we don't know whether this `mem' is in a structure 7570 or not. Both flags should never be simultaneously set. Stored in 7571 the `return_val' field and printed as `/i'. 7572 7573`MEM_VOLATILE_P (X)' 7574 In `mem', `asm_operands', and `asm_input' expressions, nonzero for 7575 volatile memory references. Stored in the `volatil' field and 7576 printed as `/v'. 7577 7578`MEM_NOTRAP_P (X)' 7579 In `mem', nonzero for memory references that will not trap. 7580 Stored in the `call' field and printed as `/c'. 7581 7582`MEM_POINTER (X)' 7583 Nonzero in a `mem' if the memory reference holds a pointer. 7584 Stored in the `frame_related' field and printed as `/f'. 7585 7586`REG_FUNCTION_VALUE_P (X)' 7587 Nonzero in a `reg' if it is the place in which this function's 7588 value is going to be returned. (This happens only in a hard 7589 register.) Stored in the `return_val' field and printed as `/i'. 7590 7591`REG_POINTER (X)' 7592 Nonzero in a `reg' if the register holds a pointer. Stored in the 7593 `frame_related' field and printed as `/f'. 7594 7595`REG_USERVAR_P (X)' 7596 In a `reg', nonzero if it corresponds to a variable present in the 7597 user's source code. Zero for temporaries generated internally by 7598 the compiler. Stored in the `volatil' field and printed as `/v'. 7599 7600 The same hard register may be used also for collecting the values 7601 of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero 7602 in this kind of use. 7603 7604`RTX_FRAME_RELATED_P (X)' 7605 Nonzero in an `insn', `call_insn', `jump_insn', `barrier', or 7606 `set' which is part of a function prologue and sets the stack 7607 pointer, sets the frame pointer, or saves a register. This flag 7608 should also be set on an instruction that sets up a temporary 7609 register to use in place of the frame pointer. Stored in the 7610 `frame_related' field and printed as `/f'. 7611 7612 In particular, on RISC targets where there are limits on the sizes 7613 of immediate constants, it is sometimes impossible to reach the 7614 register save area directly from the stack pointer. In that case, 7615 a temporary register is used that is near enough to the register 7616 save area, and the Canonical Frame Address, i.e., DWARF2's logical 7617 frame pointer, register must (temporarily) be changed to be this 7618 temporary register. So, the instruction that sets this temporary 7619 register must be marked as `RTX_FRAME_RELATED_P'. 7620 7621 If the marked instruction is overly complex (defined in terms of 7622 what `dwarf2out_frame_debug_expr' can handle), you will also have 7623 to create a `REG_FRAME_RELATED_EXPR' note and attach it to the 7624 instruction. This note should contain a simple expression of the 7625 computation performed by this instruction, i.e., one that 7626 `dwarf2out_frame_debug_expr' can handle. 7627 7628 This flag is required for exception handling support on targets 7629 with RTL prologues. 7630 7631`MEM_READONLY_P (X)' 7632 Nonzero in a `mem', if the memory is statically allocated and 7633 read-only. 7634 7635 Read-only in this context means never modified during the lifetime 7636 of the program, not necessarily in ROM or in write-disabled pages. 7637 A common example of the later is a shared library's global offset 7638 table. This table is initialized by the runtime loader, so the 7639 memory is technically writable, but after control is transfered 7640 from the runtime loader to the application, this memory will never 7641 be subsequently modified. 7642 7643 Stored in the `unchanging' field and printed as `/u'. 7644 7645`SCHED_GROUP_P (X)' 7646 During instruction scheduling, in an `insn', `call_insn' or 7647 `jump_insn', indicates that the previous insn must be scheduled 7648 together with this insn. This is used to ensure that certain 7649 groups of instructions will not be split up by the instruction 7650 scheduling pass, for example, `use' insns before a `call_insn' may 7651 not be separated from the `call_insn'. Stored in the `in_struct' 7652 field and printed as `/s'. 7653 7654`SET_IS_RETURN_P (X)' 7655 For a `set', nonzero if it is for a return. Stored in the `jump' 7656 field and printed as `/j'. 7657 7658`SIBLING_CALL_P (X)' 7659 For a `call_insn', nonzero if the insn is a sibling call. Stored 7660 in the `jump' field and printed as `/j'. 7661 7662`STRING_POOL_ADDRESS_P (X)' 7663 For a `symbol_ref' expression, nonzero if it addresses this 7664 function's string constant pool. Stored in the `frame_related' 7665 field and printed as `/f'. 7666 7667`SUBREG_PROMOTED_UNSIGNED_P (X)' 7668 Returns a value greater then zero for a `subreg' that has 7669 `SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is 7670 kept zero-extended, zero if it is kept sign-extended, and less 7671 then zero if it is extended some other way via the `ptr_extend' 7672 instruction. Stored in the `unchanging' field and `volatil' 7673 field, printed as `/u' and `/v'. This macro may only be used to 7674 get the value it may not be used to change the value. Use 7675 `SUBREG_PROMOTED_UNSIGNED_SET' to change the value. 7676 7677`SUBREG_PROMOTED_UNSIGNED_SET (X)' 7678 Set the `unchanging' and `volatil' fields in a `subreg' to reflect 7679 zero, sign, or other extension. If `volatil' is zero, then 7680 `unchanging' as nonzero means zero extension and as zero means 7681 sign extension. If `volatil' is nonzero then some other type of 7682 extension was done via the `ptr_extend' instruction. 7683 7684`SUBREG_PROMOTED_VAR_P (X)' 7685 Nonzero in a `subreg' if it was made when accessing an object that 7686 was promoted to a wider mode in accord with the `PROMOTED_MODE' 7687 machine description macro (*note Storage Layout::). In this case, 7688 the mode of the `subreg' is the declared mode of the object and 7689 the mode of `SUBREG_REG' is the mode of the register that holds 7690 the object. Promoted variables are always either sign- or 7691 zero-extended to the wider mode on every assignment. Stored in 7692 the `in_struct' field and printed as `/s'. 7693 7694`SYMBOL_REF_USED (X)' 7695 In a `symbol_ref', indicates that X has been used. This is 7696 normally only used to ensure that X is only declared external 7697 once. Stored in the `used' field. 7698 7699`SYMBOL_REF_WEAK (X)' 7700 In a `symbol_ref', indicates that X has been declared weak. 7701 Stored in the `return_val' field and printed as `/i'. 7702 7703`SYMBOL_REF_FLAG (X)' 7704 In a `symbol_ref', this is used as a flag for machine-specific 7705 purposes. Stored in the `volatil' field and printed as `/v'. 7706 7707 Most uses of `SYMBOL_REF_FLAG' are historic and may be subsumed by 7708 `SYMBOL_REF_FLAGS'. Certainly use of `SYMBOL_REF_FLAGS' is 7709 mandatory if the target requires more than one bit of storage. 7710 7711`PREFETCH_SCHEDULE_BARRIER_P (X)' 7712 In a `prefetch', indicates that the prefetch is a scheduling 7713 barrier. No other INSNs will be moved over it. Stored in the 7714 `volatil' field and printed as `/v'. 7715 7716 These are the fields to which the above macros refer: 7717 7718`call' 7719 In a `mem', 1 means that the memory reference will not trap. 7720 7721 In a `call', 1 means that this pure or const call may possibly 7722 infinite loop. 7723 7724 In an RTL dump, this flag is represented as `/c'. 7725 7726`frame_related' 7727 In an `insn' or `set' expression, 1 means that it is part of a 7728 function prologue and sets the stack pointer, sets the frame 7729 pointer, saves a register, or sets up a temporary register to use 7730 in place of the frame pointer. 7731 7732 In `reg' expressions, 1 means that the register holds a pointer. 7733 7734 In `mem' expressions, 1 means that the memory reference holds a 7735 pointer. 7736 7737 In `symbol_ref' expressions, 1 means that the reference addresses 7738 this function's string constant pool. 7739 7740 In an RTL dump, this flag is represented as `/f'. 7741 7742`in_struct' 7743 In `mem' expressions, it is 1 if the memory datum referred to is 7744 all or part of a structure or array; 0 if it is (or might be) a 7745 scalar variable. A reference through a C pointer has 0 because 7746 the pointer might point to a scalar variable. This information 7747 allows the compiler to determine something about possible cases of 7748 aliasing. 7749 7750 In `reg' expressions, it is 1 if the register has its entire life 7751 contained within the test expression of some loop. 7752 7753 In `subreg' expressions, 1 means that the `subreg' is accessing an 7754 object that has had its mode promoted from a wider mode. 7755 7756 In `label_ref' expressions, 1 means that the referenced label is 7757 outside the innermost loop containing the insn in which the 7758 `label_ref' was found. 7759 7760 In `code_label' expressions, it is 1 if the label may never be 7761 deleted. This is used for labels which are the target of 7762 non-local gotos. Such a label that would have been deleted is 7763 replaced with a `note' of type `NOTE_INSN_DELETED_LABEL'. 7764 7765 In an `insn' during dead-code elimination, 1 means that the insn is 7766 dead code. 7767 7768 In an `insn' or `jump_insn' during reorg for an insn in the delay 7769 slot of a branch, 1 means that this insn is from the target of the 7770 branch. 7771 7772 In an `insn' during instruction scheduling, 1 means that this insn 7773 must be scheduled as part of a group together with the previous 7774 insn. 7775 7776 In an RTL dump, this flag is represented as `/s'. 7777 7778`return_val' 7779 In `reg' expressions, 1 means the register contains the value to 7780 be returned by the current function. On machines that pass 7781 parameters in registers, the same register number may be used for 7782 parameters as well, but this flag is not set on such uses. 7783 7784 In `mem' expressions, 1 means the memory reference is to a scalar 7785 known not to be a member of a structure, union, or array. 7786 7787 In `symbol_ref' expressions, 1 means the referenced symbol is weak. 7788 7789 In `call' expressions, 1 means the call is pure. 7790 7791 In an RTL dump, this flag is represented as `/i'. 7792 7793`jump' 7794 In a `mem' expression, 1 means we should keep the alias set for 7795 this mem unchanged when we access a component. 7796 7797 In a `set', 1 means it is for a return. 7798 7799 In a `call_insn', 1 means it is a sibling call. 7800 7801 In an RTL dump, this flag is represented as `/j'. 7802 7803`unchanging' 7804 In `reg' and `mem' expressions, 1 means that the value of the 7805 expression never changes. 7806 7807 In `subreg' expressions, it is 1 if the `subreg' references an 7808 unsigned object whose mode has been promoted to a wider mode. 7809 7810 In an `insn' or `jump_insn' in the delay slot of a branch 7811 instruction, 1 means an annulling branch should be used. 7812 7813 In a `symbol_ref' expression, 1 means that this symbol addresses 7814 something in the per-function constant pool. 7815 7816 In a `call_insn' 1 means that this instruction is a call to a const 7817 function. 7818 7819 In an RTL dump, this flag is represented as `/u'. 7820 7821`used' 7822 This flag is used directly (without an access macro) at the end of 7823 RTL generation for a function, to count the number of times an 7824 expression appears in insns. Expressions that appear more than 7825 once are copied, according to the rules for shared structure 7826 (*note Sharing::). 7827 7828 For a `reg', it is used directly (without an access macro) by the 7829 leaf register renumbering code to ensure that each register is only 7830 renumbered once. 7831 7832 In a `symbol_ref', it indicates that an external declaration for 7833 the symbol has already been written. 7834 7835`volatil' 7836 In a `mem', `asm_operands', or `asm_input' expression, it is 1 if 7837 the memory reference is volatile. Volatile memory references may 7838 not be deleted, reordered or combined. 7839 7840 In a `symbol_ref' expression, it is used for machine-specific 7841 purposes. 7842 7843 In a `reg' expression, it is 1 if the value is a user-level 7844 variable. 0 indicates an internal compiler temporary. 7845 7846 In an `insn', 1 means the insn has been deleted. 7847 7848 In `label_ref' and `reg_label' expressions, 1 means a reference to 7849 a non-local label. 7850 7851 In `prefetch' expressions, 1 means that the containing insn is a 7852 scheduling barrier. 7853 7854 In an RTL dump, this flag is represented as `/v'. 7855 7856 7857File: gccint.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL 7858 785910.6 Machine Modes 7860================== 7861 7862A machine mode describes a size of data object and the representation 7863used for it. In the C code, machine modes are represented by an 7864enumeration type, `enum machine_mode', defined in `machmode.def'. Each 7865RTL expression has room for a machine mode and so do certain kinds of 7866tree expressions (declarations and types, to be precise). 7867 7868 In debugging dumps and machine descriptions, the machine mode of an RTL 7869expression is written after the expression code with a colon to separate 7870them. The letters `mode' which appear at the end of each machine mode 7871name are omitted. For example, `(reg:SI 38)' is a `reg' expression 7872with machine mode `SImode'. If the mode is `VOIDmode', it is not 7873written at all. 7874 7875 Here is a table of machine modes. The term "byte" below refers to an 7876object of `BITS_PER_UNIT' bits (*note Storage Layout::). 7877 7878`BImode' 7879 "Bit" mode represents a single bit, for predicate registers. 7880 7881`QImode' 7882 "Quarter-Integer" mode represents a single byte treated as an 7883 integer. 7884 7885`HImode' 7886 "Half-Integer" mode represents a two-byte integer. 7887 7888`PSImode' 7889 "Partial Single Integer" mode represents an integer which occupies 7890 four bytes but which doesn't really use all four. On some 7891 machines, this is the right mode to use for pointers. 7892 7893`SImode' 7894 "Single Integer" mode represents a four-byte integer. 7895 7896`PDImode' 7897 "Partial Double Integer" mode represents an integer which occupies 7898 eight bytes but which doesn't really use all eight. On some 7899 machines, this is the right mode to use for certain pointers. 7900 7901`DImode' 7902 "Double Integer" mode represents an eight-byte integer. 7903 7904`TImode' 7905 "Tetra Integer" (?) mode represents a sixteen-byte integer. 7906 7907`OImode' 7908 "Octa Integer" (?) mode represents a thirty-two-byte integer. 7909 7910`QFmode' 7911 "Quarter-Floating" mode represents a quarter-precision (single 7912 byte) floating point number. 7913 7914`HFmode' 7915 "Half-Floating" mode represents a half-precision (two byte) 7916 floating point number. 7917 7918`TQFmode' 7919 "Three-Quarter-Floating" (?) mode represents a 7920 three-quarter-precision (three byte) floating point number. 7921 7922`SFmode' 7923 "Single Floating" mode represents a four byte floating point 7924 number. In the common case, of a processor with IEEE arithmetic 7925 and 8-bit bytes, this is a single-precision IEEE floating point 7926 number; it can also be used for double-precision (on processors 7927 with 16-bit bytes) and single-precision VAX and IBM types. 7928 7929`DFmode' 7930 "Double Floating" mode represents an eight byte floating point 7931 number. In the common case, of a processor with IEEE arithmetic 7932 and 8-bit bytes, this is a double-precision IEEE floating point 7933 number. 7934 7935`XFmode' 7936 "Extended Floating" mode represents an IEEE extended floating point 7937 number. This mode only has 80 meaningful bits (ten bytes). Some 7938 processors require such numbers to be padded to twelve bytes, 7939 others to sixteen; this mode is used for either. 7940 7941`SDmode' 7942 "Single Decimal Floating" mode represents a four byte decimal 7943 floating point number (as distinct from conventional binary 7944 floating point). 7945 7946`DDmode' 7947 "Double Decimal Floating" mode represents an eight byte decimal 7948 floating point number. 7949 7950`TDmode' 7951 "Tetra Decimal Floating" mode represents a sixteen byte decimal 7952 floating point number all 128 of whose bits are meaningful. 7953 7954`TFmode' 7955 "Tetra Floating" mode represents a sixteen byte floating point 7956 number all 128 of whose bits are meaningful. One common use is the 7957 IEEE quad-precision format. 7958 7959`QQmode' 7960 "Quarter-Fractional" mode represents a single byte treated as a 7961 signed fractional number. The default format is "s.7". 7962 7963`HQmode' 7964 "Half-Fractional" mode represents a two-byte signed fractional 7965 number. The default format is "s.15". 7966 7967`SQmode' 7968 "Single Fractional" mode represents a four-byte signed fractional 7969 number. The default format is "s.31". 7970 7971`DQmode' 7972 "Double Fractional" mode represents an eight-byte signed 7973 fractional number. The default format is "s.63". 7974 7975`TQmode' 7976 "Tetra Fractional" mode represents a sixteen-byte signed 7977 fractional number. The default format is "s.127". 7978 7979`UQQmode' 7980 "Unsigned Quarter-Fractional" mode represents a single byte 7981 treated as an unsigned fractional number. The default format is 7982 ".8". 7983 7984`UHQmode' 7985 "Unsigned Half-Fractional" mode represents a two-byte unsigned 7986 fractional number. The default format is ".16". 7987 7988`USQmode' 7989 "Unsigned Single Fractional" mode represents a four-byte unsigned 7990 fractional number. The default format is ".32". 7991 7992`UDQmode' 7993 "Unsigned Double Fractional" mode represents an eight-byte unsigned 7994 fractional number. The default format is ".64". 7995 7996`UTQmode' 7997 "Unsigned Tetra Fractional" mode represents a sixteen-byte unsigned 7998 fractional number. The default format is ".128". 7999 8000`HAmode' 8001 "Half-Accumulator" mode represents a two-byte signed accumulator. 8002 The default format is "s8.7". 8003 8004`SAmode' 8005 "Single Accumulator" mode represents a four-byte signed 8006 accumulator. The default format is "s16.15". 8007 8008`DAmode' 8009 "Double Accumulator" mode represents an eight-byte signed 8010 accumulator. The default format is "s32.31". 8011 8012`TAmode' 8013 "Tetra Accumulator" mode represents a sixteen-byte signed 8014 accumulator. The default format is "s64.63". 8015 8016`UHAmode' 8017 "Unsigned Half-Accumulator" mode represents a two-byte unsigned 8018 accumulator. The default format is "8.8". 8019 8020`USAmode' 8021 "Unsigned Single Accumulator" mode represents a four-byte unsigned 8022 accumulator. The default format is "16.16". 8023 8024`UDAmode' 8025 "Unsigned Double Accumulator" mode represents an eight-byte 8026 unsigned accumulator. The default format is "32.32". 8027 8028`UTAmode' 8029 "Unsigned Tetra Accumulator" mode represents a sixteen-byte 8030 unsigned accumulator. The default format is "64.64". 8031 8032`CCmode' 8033 "Condition Code" mode represents the value of a condition code, 8034 which is a machine-specific set of bits used to represent the 8035 result of a comparison operation. Other machine-specific modes 8036 may also be used for the condition code. These modes are not used 8037 on machines that use `cc0' (see *note Condition Code::). 8038 8039`BLKmode' 8040 "Block" mode represents values that are aggregates to which none of 8041 the other modes apply. In RTL, only memory references can have 8042 this mode, and only if they appear in string-move or vector 8043 instructions. On machines which have no such instructions, 8044 `BLKmode' will not appear in RTL. 8045 8046`VOIDmode' 8047 Void mode means the absence of a mode or an unspecified mode. For 8048 example, RTL expressions of code `const_int' have mode `VOIDmode' 8049 because they can be taken to have whatever mode the context 8050 requires. In debugging dumps of RTL, `VOIDmode' is expressed by 8051 the absence of any mode. 8052 8053`QCmode, HCmode, SCmode, DCmode, XCmode, TCmode' 8054 These modes stand for a complex number represented as a pair of 8055 floating point values. The floating point values are in `QFmode', 8056 `HFmode', `SFmode', `DFmode', `XFmode', and `TFmode', respectively. 8057 8058`CQImode, CHImode, CSImode, CDImode, CTImode, COImode' 8059 These modes stand for a complex number represented as a pair of 8060 integer values. The integer values are in `QImode', `HImode', 8061 `SImode', `DImode', `TImode', and `OImode', respectively. 8062 8063 The machine description defines `Pmode' as a C macro which expands 8064into the machine mode used for addresses. Normally this is the mode 8065whose size is `BITS_PER_WORD', `SImode' on 32-bit machines. 8066 8067 The only modes which a machine description must support are `QImode', 8068and the modes corresponding to `BITS_PER_WORD', `FLOAT_TYPE_SIZE' and 8069`DOUBLE_TYPE_SIZE'. The compiler will attempt to use `DImode' for 80708-byte structures and unions, but this can be prevented by overriding 8071the definition of `MAX_FIXED_MODE_SIZE'. Alternatively, you can have 8072the compiler use `TImode' for 16-byte structures and unions. Likewise, 8073you can arrange for the C type `short int' to avoid using `HImode'. 8074 8075 Very few explicit references to machine modes remain in the compiler 8076and these few references will soon be removed. Instead, the machine 8077modes are divided into mode classes. These are represented by the 8078enumeration type `enum mode_class' defined in `machmode.h'. The 8079possible mode classes are: 8080 8081`MODE_INT' 8082 Integer modes. By default these are `BImode', `QImode', `HImode', 8083 `SImode', `DImode', `TImode', and `OImode'. 8084 8085`MODE_PARTIAL_INT' 8086 The "partial integer" modes, `PQImode', `PHImode', `PSImode' and 8087 `PDImode'. 8088 8089`MODE_FLOAT' 8090 Floating point modes. By default these are `QFmode', `HFmode', 8091 `TQFmode', `SFmode', `DFmode', `XFmode' and `TFmode'. 8092 8093`MODE_DECIMAL_FLOAT' 8094 Decimal floating point modes. By default these are `SDmode', 8095 `DDmode' and `TDmode'. 8096 8097`MODE_FRACT' 8098 Signed fractional modes. By default these are `QQmode', `HQmode', 8099 `SQmode', `DQmode' and `TQmode'. 8100 8101`MODE_UFRACT' 8102 Unsigned fractional modes. By default these are `UQQmode', 8103 `UHQmode', `USQmode', `UDQmode' and `UTQmode'. 8104 8105`MODE_ACCUM' 8106 Signed accumulator modes. By default these are `HAmode', 8107 `SAmode', `DAmode' and `TAmode'. 8108 8109`MODE_UACCUM' 8110 Unsigned accumulator modes. By default these are `UHAmode', 8111 `USAmode', `UDAmode' and `UTAmode'. 8112 8113`MODE_COMPLEX_INT' 8114 Complex integer modes. (These are not currently implemented). 8115 8116`MODE_COMPLEX_FLOAT' 8117 Complex floating point modes. By default these are `QCmode', 8118 `HCmode', `SCmode', `DCmode', `XCmode', and `TCmode'. 8119 8120`MODE_FUNCTION' 8121 Algol or Pascal function variables including a static chain. 8122 (These are not currently implemented). 8123 8124`MODE_CC' 8125 Modes representing condition code values. These are `CCmode' plus 8126 any `CC_MODE' modes listed in the `MACHINE-modes.def'. *Note Jump 8127 Patterns::, also see *note Condition Code::. 8128 8129`MODE_RANDOM' 8130 This is a catchall mode class for modes which don't fit into the 8131 above classes. Currently `VOIDmode' and `BLKmode' are in 8132 `MODE_RANDOM'. 8133 8134 Here are some C macros that relate to machine modes: 8135 8136`GET_MODE (X)' 8137 Returns the machine mode of the RTX X. 8138 8139`PUT_MODE (X, NEWMODE)' 8140 Alters the machine mode of the RTX X to be NEWMODE. 8141 8142`NUM_MACHINE_MODES' 8143 Stands for the number of machine modes available on the target 8144 machine. This is one greater than the largest numeric value of any 8145 machine mode. 8146 8147`GET_MODE_NAME (M)' 8148 Returns the name of mode M as a string. 8149 8150`GET_MODE_CLASS (M)' 8151 Returns the mode class of mode M. 8152 8153`GET_MODE_WIDER_MODE (M)' 8154 Returns the next wider natural mode. For example, the expression 8155 `GET_MODE_WIDER_MODE (QImode)' returns `HImode'. 8156 8157`GET_MODE_SIZE (M)' 8158 Returns the size in bytes of a datum of mode M. 8159 8160`GET_MODE_BITSIZE (M)' 8161 Returns the size in bits of a datum of mode M. 8162 8163`GET_MODE_IBIT (M)' 8164 Returns the number of integral bits of a datum of fixed-point mode 8165 M. 8166 8167`GET_MODE_FBIT (M)' 8168 Returns the number of fractional bits of a datum of fixed-point 8169 mode M. 8170 8171`GET_MODE_MASK (M)' 8172 Returns a bitmask containing 1 for all bits in a word that fit 8173 within mode M. This macro can only be used for modes whose 8174 bitsize is less than or equal to `HOST_BITS_PER_INT'. 8175 8176`GET_MODE_ALIGNMENT (M)' 8177 Return the required alignment, in bits, for an object of mode M. 8178 8179`GET_MODE_UNIT_SIZE (M)' 8180 Returns the size in bytes of the subunits of a datum of mode M. 8181 This is the same as `GET_MODE_SIZE' except in the case of complex 8182 modes. For them, the unit size is the size of the real or 8183 imaginary part. 8184 8185`GET_MODE_NUNITS (M)' 8186 Returns the number of units contained in a mode, i.e., 8187 `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'. 8188 8189`GET_CLASS_NARROWEST_MODE (C)' 8190 Returns the narrowest mode in mode class C. 8191 8192 The global variables `byte_mode' and `word_mode' contain modes whose 8193classes are `MODE_INT' and whose bitsizes are either `BITS_PER_UNIT' or 8194`BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode' 8195and `SImode', respectively. 8196 8197 8198File: gccint.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL 8199 820010.7 Constant Expression Types 8201============================== 8202 8203The simplest RTL expressions are those that represent constant values. 8204 8205`(const_int I)' 8206 This type of expression represents the integer value I. I is 8207 customarily accessed with the macro `INTVAL' as in `INTVAL (EXP)', 8208 which is equivalent to `XWINT (EXP, 0)'. 8209 8210 Constants generated for modes with fewer bits than `HOST_WIDE_INT' 8211 must be sign extended to full width (e.g., with `gen_int_mode'). 8212 8213 There is only one expression object for the integer value zero; it 8214 is the value of the variable `const0_rtx'. Likewise, the only 8215 expression for integer value one is found in `const1_rtx', the only 8216 expression for integer value two is found in `const2_rtx', and the 8217 only expression for integer value negative one is found in 8218 `constm1_rtx'. Any attempt to create an expression of code 8219 `const_int' and value zero, one, two or negative one will return 8220 `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as 8221 appropriate. 8222 8223 Similarly, there is only one object for the integer whose value is 8224 `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If 8225 `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will 8226 point to the same object. If `STORE_FLAG_VALUE' is -1, 8227 `const_true_rtx' and `constm1_rtx' will point to the same object. 8228 8229`(const_double:M I0 I1 ...)' 8230 Represents either a floating-point constant of mode M or an 8231 integer constant too large to fit into `HOST_BITS_PER_WIDE_INT' 8232 bits but small enough to fit within twice that number of bits (GCC 8233 does not provide a mechanism to represent even larger constants). 8234 In the latter case, M will be `VOIDmode'. 8235 8236 If M is `VOIDmode', the bits of the value are stored in I0 and I1. 8237 I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' and 8238 I1 with `CONST_DOUBLE_HIGH'. 8239 8240 If the constant is floating point (regardless of its precision), 8241 then the number of integers used to store the value depends on the 8242 size of `REAL_VALUE_TYPE' (*note Floating Point::). The integers 8243 represent a floating point number, but not precisely in the target 8244 machine's or host machine's floating point format. To convert 8245 them to the precise bit pattern used by the target machine, use 8246 the macro `REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data 8247 Output::). 8248 8249`(const_fixed:M ...)' 8250 Represents a fixed-point constant of mode M. The operand is a 8251 data structure of type `struct fixed_value' and is accessed with 8252 the macro `CONST_FIXED_VALUE'. The high part of data is accessed 8253 with `CONST_FIXED_VALUE_HIGH'; the low part is accessed with 8254 `CONST_FIXED_VALUE_LOW'. 8255 8256`(const_vector:M [X0 X1 ...])' 8257 Represents a vector constant. The square brackets stand for the 8258 vector containing the constant elements. X0, X1 and so on are the 8259 `const_int', `const_double' or `const_fixed' elements. 8260 8261 The number of units in a `const_vector' is obtained with the macro 8262 `CONST_VECTOR_NUNITS' as in `CONST_VECTOR_NUNITS (V)'. 8263 8264 Individual elements in a vector constant are accessed with the 8265 macro `CONST_VECTOR_ELT' as in `CONST_VECTOR_ELT (V, N)' where V 8266 is the vector constant and N is the element desired. 8267 8268`(const_string STR)' 8269 Represents a constant string with value STR. Currently this is 8270 used only for insn attributes (*note Insn Attributes::) since 8271 constant strings in C are placed in memory. 8272 8273`(symbol_ref:MODE SYMBOL)' 8274 Represents the value of an assembler label for data. SYMBOL is a 8275 string that describes the name of the assembler label. If it 8276 starts with a `*', the label is the rest of SYMBOL not including 8277 the `*'. Otherwise, the label is SYMBOL, usually prefixed with 8278 `_'. 8279 8280 The `symbol_ref' contains a mode, which is usually `Pmode'. 8281 Usually that is the only mode for which a symbol is directly valid. 8282 8283`(label_ref:MODE LABEL)' 8284 Represents the value of an assembler label for code. It contains 8285 one operand, an expression, which must be a `code_label' or a 8286 `note' of type `NOTE_INSN_DELETED_LABEL' that appears in the 8287 instruction sequence to identify the place where the label should 8288 go. 8289 8290 The reason for using a distinct expression type for code label 8291 references is so that jump optimization can distinguish them. 8292 8293 The `label_ref' contains a mode, which is usually `Pmode'. 8294 Usually that is the only mode for which a label is directly valid. 8295 8296`(const:M EXP)' 8297 Represents a constant that is the result of an assembly-time 8298 arithmetic computation. The operand, EXP, is an expression that 8299 contains only constants (`const_int', `symbol_ref' and `label_ref' 8300 expressions) combined with `plus' and `minus'. However, not all 8301 combinations are valid, since the assembler cannot do arbitrary 8302 arithmetic on relocatable symbols. 8303 8304 M should be `Pmode'. 8305 8306`(high:M EXP)' 8307 Represents the high-order bits of EXP, usually a `symbol_ref'. 8308 The number of bits is machine-dependent and is normally the number 8309 of bits specified in an instruction that initializes the high 8310 order bits of a register. It is used with `lo_sum' to represent 8311 the typical two-instruction sequence used in RISC machines to 8312 reference a global memory location. 8313 8314 M should be `Pmode'. 8315 8316 The macro `CONST0_RTX (MODE)' refers to an expression with value 0 in 8317mode MODE. If mode MODE is of mode class `MODE_INT', it returns 8318`const0_rtx'. If mode MODE is of mode class `MODE_FLOAT', it returns a 8319`CONST_DOUBLE' expression in mode MODE. Otherwise, it returns a 8320`CONST_VECTOR' expression in mode MODE. Similarly, the macro 8321`CONST1_RTX (MODE)' refers to an expression with value 1 in mode MODE 8322and similarly for `CONST2_RTX'. The `CONST1_RTX' and `CONST2_RTX' 8323macros are undefined for vector modes. 8324 8325 8326File: gccint.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL 8327 832810.8 Registers and Memory 8329========================= 8330 8331Here are the RTL expression types for describing access to machine 8332registers and to main memory. 8333 8334`(reg:M N)' 8335 For small values of the integer N (those that are less than 8336 `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine 8337 register number N: a "hard register". For larger values of N, it 8338 stands for a temporary value or "pseudo register". The compiler's 8339 strategy is to generate code assuming an unlimited number of such 8340 pseudo registers, and later convert them into hard registers or 8341 into memory references. 8342 8343 M is the machine mode of the reference. It is necessary because 8344 machines can generally refer to each register in more than one 8345 mode. For example, a register may contain a full word but there 8346 may be instructions to refer to it as a half word or as a single 8347 byte, as well as instructions to refer to it as a floating point 8348 number of various precisions. 8349 8350 Even for a register that the machine can access in only one mode, 8351 the mode must always be specified. 8352 8353 The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine 8354 description, since the number of hard registers on the machine is 8355 an invariant characteristic of the machine. Note, however, that 8356 not all of the machine registers must be general registers. All 8357 the machine registers that can be used for storage of data are 8358 given hard register numbers, even those that can be used only in 8359 certain instructions or can hold only certain types of data. 8360 8361 A hard register may be accessed in various modes throughout one 8362 function, but each pseudo register is given a natural mode and is 8363 accessed only in that mode. When it is necessary to describe an 8364 access to a pseudo register using a nonnatural mode, a `subreg' 8365 expression is used. 8366 8367 A `reg' expression with a machine mode that specifies more than 8368 one word of data may actually stand for several consecutive 8369 registers. If in addition the register number specifies a 8370 hardware register, then it actually represents several consecutive 8371 hardware registers starting with the specified one. 8372 8373 Each pseudo register number used in a function's RTL code is 8374 represented by a unique `reg' expression. 8375 8376 Some pseudo register numbers, those within the range of 8377 `FIRST_VIRTUAL_REGISTER' to `LAST_VIRTUAL_REGISTER' only appear 8378 during the RTL generation phase and are eliminated before the 8379 optimization phases. These represent locations in the stack frame 8380 that cannot be determined until RTL generation for the function 8381 has been completed. The following virtual register numbers are 8382 defined: 8383 8384 `VIRTUAL_INCOMING_ARGS_REGNUM' 8385 This points to the first word of the incoming arguments 8386 passed on the stack. Normally these arguments are placed 8387 there by the caller, but the callee may have pushed some 8388 arguments that were previously passed in registers. 8389 8390 When RTL generation is complete, this virtual register is 8391 replaced by the sum of the register given by 8392 `ARG_POINTER_REGNUM' and the value of `FIRST_PARM_OFFSET'. 8393 8394 `VIRTUAL_STACK_VARS_REGNUM' 8395 If `FRAME_GROWS_DOWNWARD' is defined to a nonzero value, this 8396 points to immediately above the first variable on the stack. 8397 Otherwise, it points to the first variable on the stack. 8398 8399 `VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the 8400 register given by `FRAME_POINTER_REGNUM' and the value 8401 `STARTING_FRAME_OFFSET'. 8402 8403 `VIRTUAL_STACK_DYNAMIC_REGNUM' 8404 This points to the location of dynamically allocated memory 8405 on the stack immediately after the stack pointer has been 8406 adjusted by the amount of memory desired. 8407 8408 This virtual register is replaced by the sum of the register 8409 given by `STACK_POINTER_REGNUM' and the value 8410 `STACK_DYNAMIC_OFFSET'. 8411 8412 `VIRTUAL_OUTGOING_ARGS_REGNUM' 8413 This points to the location in the stack at which outgoing 8414 arguments should be written when the stack is pre-pushed 8415 (arguments pushed using push insns should always use 8416 `STACK_POINTER_REGNUM'). 8417 8418 This virtual register is replaced by the sum of the register 8419 given by `STACK_POINTER_REGNUM' and the value 8420 `STACK_POINTER_OFFSET'. 8421 8422`(subreg:M1 REG:M2 BYTENUM)' 8423 `subreg' expressions are used to refer to a register in a machine 8424 mode other than its natural one, or to refer to one register of a 8425 multi-part `reg' that actually refers to several registers. 8426 8427 Each pseudo register has a natural mode. If it is necessary to 8428 operate on it in a different mode, the register must be enclosed 8429 in a `subreg'. 8430 8431 There are currently three supported types for the first operand of 8432 a `subreg': 8433 * pseudo registers This is the most common case. Most 8434 `subreg's have pseudo `reg's as their first operand. 8435 8436 * mem `subreg's of `mem' were common in earlier versions of GCC 8437 and are still supported. During the reload pass these are 8438 replaced by plain `mem's. On machines that do not do 8439 instruction scheduling, use of `subreg's of `mem' are still 8440 used, but this is no longer recommended. Such `subreg's are 8441 considered to be `register_operand's rather than 8442 `memory_operand's before and during reload. Because of this, 8443 the scheduling passes cannot properly schedule instructions 8444 with `subreg's of `mem', so for machines that do scheduling, 8445 `subreg's of `mem' should never be used. To support this, 8446 the combine and recog passes have explicit code to inhibit 8447 the creation of `subreg's of `mem' when `INSN_SCHEDULING' is 8448 defined. 8449 8450 The use of `subreg's of `mem' after the reload pass is an area 8451 that is not well understood and should be avoided. There is 8452 still some code in the compiler to support this, but this 8453 code has possibly rotted. This use of `subreg's is 8454 discouraged and will most likely not be supported in the 8455 future. 8456 8457 * hard registers It is seldom necessary to wrap hard registers 8458 in `subreg's; such registers would normally reduce to a 8459 single `reg' rtx. This use of `subreg's is discouraged and 8460 may not be supported in the future. 8461 8462 8463 `subreg's of `subreg's are not supported. Using 8464 `simplify_gen_subreg' is the recommended way to avoid this problem. 8465 8466 `subreg's come in two distinct flavors, each having its own usage 8467 and rules: 8468 8469 Paradoxical subregs 8470 When M1 is strictly wider than M2, the `subreg' expression is 8471 called "paradoxical". The canonical test for this class of 8472 `subreg' is: 8473 8474 GET_MODE_SIZE (M1) > GET_MODE_SIZE (M2) 8475 8476 Paradoxical `subreg's can be used as both lvalues and rvalues. 8477 When used as an lvalue, the low-order bits of the source value 8478 are stored in REG and the high-order bits are discarded. 8479 When used as an rvalue, the low-order bits of the `subreg' are 8480 taken from REG while the high-order bits may or may not be 8481 defined. 8482 8483 The high-order bits of rvalues are in the following 8484 circumstances: 8485 8486 * `subreg's of `mem' When M2 is smaller than a word, the 8487 macro `LOAD_EXTEND_OP', can control how the high-order 8488 bits are defined. 8489 8490 * `subreg' of `reg's The upper bits are defined when 8491 `SUBREG_PROMOTED_VAR_P' is true. 8492 `SUBREG_PROMOTED_UNSIGNED_P' describes what the upper 8493 bits hold. Such subregs usually represent local 8494 variables, register variables and parameter pseudo 8495 variables that have been promoted to a wider mode. 8496 8497 8498 BYTENUM is always zero for a paradoxical `subreg', even on 8499 big-endian targets. 8500 8501 For example, the paradoxical `subreg': 8502 8503 (set (subreg:SI (reg:HI X) 0) Y) 8504 8505 stores the lower 2 bytes of Y in X and discards the upper 2 8506 bytes. A subsequent: 8507 8508 (set Z (subreg:SI (reg:HI X) 0)) 8509 8510 would set the lower two bytes of Z to Y and set the upper two 8511 bytes to an unknown value assuming `SUBREG_PROMOTED_VAR_P' is 8512 false. 8513 8514 Normal subregs 8515 When M1 is at least as narrow as M2 the `subreg' expression 8516 is called "normal". 8517 8518 Normal `subreg's restrict consideration to certain bits of 8519 REG. There are two cases. If M1 is smaller than a word, the 8520 `subreg' refers to the least-significant part (or "lowpart") 8521 of one word of REG. If M1 is word-sized or greater, the 8522 `subreg' refers to one or more complete words. 8523 8524 When used as an lvalue, `subreg' is a word-based accessor. 8525 Storing to a `subreg' modifies all the words of REG that 8526 overlap the `subreg', but it leaves the other words of REG 8527 alone. 8528 8529 When storing to a normal `subreg' that is smaller than a word, 8530 the other bits of the referenced word are usually left in an 8531 undefined state. This laxity makes it easier to generate 8532 efficient code for such instructions. To represent an 8533 instruction that preserves all the bits outside of those in 8534 the `subreg', use `strict_low_part' or `zero_extract' around 8535 the `subreg'. 8536 8537 BYTENUM must identify the offset of the first byte of the 8538 `subreg' from the start of REG, assuming that REG is laid out 8539 in memory order. The memory order of bytes is defined by two 8540 target macros, `WORDS_BIG_ENDIAN' and `BYTES_BIG_ENDIAN': 8541 8542 * `WORDS_BIG_ENDIAN', if set to 1, says that byte number 8543 zero is part of the most significant word; otherwise, it 8544 is part of the least significant word. 8545 8546 * `BYTES_BIG_ENDIAN', if set to 1, says that byte number 8547 zero is the most significant byte within a word; 8548 otherwise, it is the least significant byte within a 8549 word. 8550 8551 On a few targets, `FLOAT_WORDS_BIG_ENDIAN' disagrees with 8552 `WORDS_BIG_ENDIAN'. However, most parts of the compiler treat 8553 floating point values as if they had the same endianness as 8554 integer values. This works because they handle them solely 8555 as a collection of integer values, with no particular 8556 numerical value. Only real.c and the runtime libraries care 8557 about `FLOAT_WORDS_BIG_ENDIAN'. 8558 8559 Thus, 8560 8561 (subreg:HI (reg:SI X) 2) 8562 8563 on a `BYTES_BIG_ENDIAN', `UNITS_PER_WORD == 4' target is the 8564 same as 8565 8566 (subreg:HI (reg:SI X) 0) 8567 8568 on a little-endian, `UNITS_PER_WORD == 4' target. Both 8569 `subreg's access the lower two bytes of register X. 8570 8571 8572 A `MODE_PARTIAL_INT' mode behaves as if it were as wide as the 8573 corresponding `MODE_INT' mode, except that it has an unknown 8574 number of undefined bits. For example: 8575 8576 (subreg:PSI (reg:SI 0) 0) 8577 8578 accesses the whole of `(reg:SI 0)', but the exact relationship 8579 between the `PSImode' value and the `SImode' value is not defined. 8580 If we assume `UNITS_PER_WORD <= 4', then the following two 8581 `subreg's: 8582 8583 (subreg:PSI (reg:DI 0) 0) 8584 (subreg:PSI (reg:DI 0) 4) 8585 8586 represent independent 4-byte accesses to the two halves of 8587 `(reg:DI 0)'. Both `subreg's have an unknown number of undefined 8588 bits. 8589 8590 If `UNITS_PER_WORD <= 2' then these two `subreg's: 8591 8592 (subreg:HI (reg:PSI 0) 0) 8593 (subreg:HI (reg:PSI 0) 2) 8594 8595 represent independent 2-byte accesses that together span the whole 8596 of `(reg:PSI 0)'. Storing to the first `subreg' does not affect 8597 the value of the second, and vice versa. `(reg:PSI 0)' has an 8598 unknown number of undefined bits, so the assignment: 8599 8600 (set (subreg:HI (reg:PSI 0) 0) (reg:HI 4)) 8601 8602 does not guarantee that `(subreg:HI (reg:PSI 0) 0)' has the value 8603 `(reg:HI 4)'. 8604 8605 The rules above apply to both pseudo REGs and hard REGs. If the 8606 semantics are not correct for particular combinations of M1, M2 8607 and hard REG, the target-specific code must ensure that those 8608 combinations are never used. For example: 8609 8610 CANNOT_CHANGE_MODE_CLASS (M2, M1, CLASS) 8611 8612 must be true for every class CLASS that includes REG. 8613 8614 The first operand of a `subreg' expression is customarily accessed 8615 with the `SUBREG_REG' macro and the second operand is customarily 8616 accessed with the `SUBREG_BYTE' macro. 8617 8618 It has been several years since a platform in which 8619 `BYTES_BIG_ENDIAN' not equal to `WORDS_BIG_ENDIAN' has been 8620 tested. Anyone wishing to support such a platform in the future 8621 may be confronted with code rot. 8622 8623`(scratch:M)' 8624 This represents a scratch register that will be required for the 8625 execution of a single instruction and not used subsequently. It is 8626 converted into a `reg' by either the local register allocator or 8627 the reload pass. 8628 8629 `scratch' is usually present inside a `clobber' operation (*note 8630 Side Effects::). 8631 8632`(cc0)' 8633 This refers to the machine's condition code register. It has no 8634 operands and may not have a machine mode. There are two ways to 8635 use it: 8636 8637 * To stand for a complete set of condition code flags. This is 8638 best on most machines, where each comparison sets the entire 8639 series of flags. 8640 8641 With this technique, `(cc0)' may be validly used in only two 8642 contexts: as the destination of an assignment (in test and 8643 compare instructions) and in comparison operators comparing 8644 against zero (`const_int' with value zero; that is to say, 8645 `const0_rtx'). 8646 8647 * To stand for a single flag that is the result of a single 8648 condition. This is useful on machines that have only a 8649 single flag bit, and in which comparison instructions must 8650 specify the condition to test. 8651 8652 With this technique, `(cc0)' may be validly used in only two 8653 contexts: as the destination of an assignment (in test and 8654 compare instructions) where the source is a comparison 8655 operator, and as the first operand of `if_then_else' (in a 8656 conditional branch). 8657 8658 There is only one expression object of code `cc0'; it is the value 8659 of the variable `cc0_rtx'. Any attempt to create an expression of 8660 code `cc0' will return `cc0_rtx'. 8661 8662 Instructions can set the condition code implicitly. On many 8663 machines, nearly all instructions set the condition code based on 8664 the value that they compute or store. It is not necessary to 8665 record these actions explicitly in the RTL because the machine 8666 description includes a prescription for recognizing the 8667 instructions that do so (by means of the macro 8668 `NOTICE_UPDATE_CC'). *Note Condition Code::. Only instructions 8669 whose sole purpose is to set the condition code, and instructions 8670 that use the condition code, need mention `(cc0)'. 8671 8672 On some machines, the condition code register is given a register 8673 number and a `reg' is used instead of `(cc0)'. This is usually the 8674 preferable approach if only a small subset of instructions modify 8675 the condition code. Other machines store condition codes in 8676 general registers; in such cases a pseudo register should be used. 8677 8678 Some machines, such as the SPARC and RS/6000, have two sets of 8679 arithmetic instructions, one that sets and one that does not set 8680 the condition code. This is best handled by normally generating 8681 the instruction that does not set the condition code, and making a 8682 pattern that both performs the arithmetic and sets the condition 8683 code register (which would not be `(cc0)' in this case). For 8684 examples, search for `addcc' and `andcc' in `sparc.md'. 8685 8686`(pc)' 8687 This represents the machine's program counter. It has no operands 8688 and may not have a machine mode. `(pc)' may be validly used only 8689 in certain specific contexts in jump instructions. 8690 8691 There is only one expression object of code `pc'; it is the value 8692 of the variable `pc_rtx'. Any attempt to create an expression of 8693 code `pc' will return `pc_rtx'. 8694 8695 All instructions that do not jump alter the program counter 8696 implicitly by incrementing it, but there is no need to mention 8697 this in the RTL. 8698 8699`(mem:M ADDR ALIAS)' 8700 This RTX represents a reference to main memory at an address 8701 represented by the expression ADDR. M specifies how large a unit 8702 of memory is accessed. ALIAS specifies an alias set for the 8703 reference. In general two items are in different alias sets if 8704 they cannot reference the same memory address. 8705 8706 The construct `(mem:BLK (scratch))' is considered to alias all 8707 other memories. Thus it may be used as a memory barrier in 8708 epilogue stack deallocation patterns. 8709 8710`(concatM RTX RTX)' 8711 This RTX represents the concatenation of two other RTXs. This is 8712 used for complex values. It should only appear in the RTL 8713 attached to declarations and during RTL generation. It should not 8714 appear in the ordinary insn chain. 8715 8716`(concatnM [RTX ...])' 8717 This RTX represents the concatenation of all the RTX to make a 8718 single value. Like `concat', this should only appear in 8719 declarations, and not in the insn chain. 8720 8721 8722File: gccint.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL 8723 872410.9 RTL Expressions for Arithmetic 8725=================================== 8726 8727Unless otherwise specified, all the operands of arithmetic expressions 8728must be valid for mode M. An operand is valid for mode M if it has 8729mode M, or if it is a `const_int' or `const_double' and M is a mode of 8730class `MODE_INT'. 8731 8732 For commutative binary operations, constants should be placed in the 8733second operand. 8734 8735`(plus:M X Y)' 8736`(ss_plus:M X Y)' 8737`(us_plus:M X Y)' 8738 These three expressions all represent the sum of the values 8739 represented by X and Y carried out in machine mode M. They differ 8740 in their behavior on overflow of integer modes. `plus' wraps 8741 round modulo the width of M; `ss_plus' saturates at the maximum 8742 signed value representable in M; `us_plus' saturates at the 8743 maximum unsigned value. 8744 8745`(lo_sum:M X Y)' 8746 This expression represents the sum of X and the low-order bits of 8747 Y. It is used with `high' (*note Constants::) to represent the 8748 typical two-instruction sequence used in RISC machines to 8749 reference a global memory location. 8750 8751 The number of low order bits is machine-dependent but is normally 8752 the number of bits in a `Pmode' item minus the number of bits set 8753 by `high'. 8754 8755 M should be `Pmode'. 8756 8757`(minus:M X Y)' 8758`(ss_minus:M X Y)' 8759`(us_minus:M X Y)' 8760 These three expressions represent the result of subtracting Y from 8761 X, carried out in mode M. Behavior on overflow is the same as for 8762 the three variants of `plus' (see above). 8763 8764`(compare:M X Y)' 8765 Represents the result of subtracting Y from X for purposes of 8766 comparison. The result is computed without overflow, as if with 8767 infinite precision. 8768 8769 Of course, machines can't really subtract with infinite precision. 8770 However, they can pretend to do so when only the sign of the 8771 result will be used, which is the case when the result is stored 8772 in the condition code. And that is the _only_ way this kind of 8773 expression may validly be used: as a value to be stored in the 8774 condition codes, either `(cc0)' or a register. *Note 8775 Comparisons::. 8776 8777 The mode M is not related to the modes of X and Y, but instead is 8778 the mode of the condition code value. If `(cc0)' is used, it is 8779 `VOIDmode'. Otherwise it is some mode in class `MODE_CC', often 8780 `CCmode'. *Note Condition Code::. If M is `VOIDmode' or 8781 `CCmode', the operation returns sufficient information (in an 8782 unspecified format) so that any comparison operator can be applied 8783 to the result of the `COMPARE' operation. For other modes in 8784 class `MODE_CC', the operation only returns a subset of this 8785 information. 8786 8787 Normally, X and Y must have the same mode. Otherwise, `compare' 8788 is valid only if the mode of X is in class `MODE_INT' and Y is a 8789 `const_int' or `const_double' with mode `VOIDmode'. The mode of X 8790 determines what mode the comparison is to be done in; thus it must 8791 not be `VOIDmode'. 8792 8793 If one of the operands is a constant, it should be placed in the 8794 second operand and the comparison code adjusted as appropriate. 8795 8796 A `compare' specifying two `VOIDmode' constants is not valid since 8797 there is no way to know in what mode the comparison is to be 8798 performed; the comparison must either be folded during the 8799 compilation or the first operand must be loaded into a register 8800 while its mode is still known. 8801 8802`(neg:M X)' 8803`(ss_neg:M X)' 8804`(us_neg:M X)' 8805 These two expressions represent the negation (subtraction from 8806 zero) of the value represented by X, carried out in mode M. They 8807 differ in the behavior on overflow of integer modes. In the case 8808 of `neg', the negation of the operand may be a number not 8809 representable in mode M, in which case it is truncated to M. 8810 `ss_neg' and `us_neg' ensure that an out-of-bounds result 8811 saturates to the maximum or minimum signed or unsigned value. 8812 8813`(mult:M X Y)' 8814`(ss_mult:M X Y)' 8815`(us_mult:M X Y)' 8816 Represents the signed product of the values represented by X and Y 8817 carried out in machine mode M. `ss_mult' and `us_mult' ensure 8818 that an out-of-bounds result saturates to the maximum or minimum 8819 signed or unsigned value. 8820 8821 Some machines support a multiplication that generates a product 8822 wider than the operands. Write the pattern for this as 8823 8824 (mult:M (sign_extend:M X) (sign_extend:M Y)) 8825 8826 where M is wider than the modes of X and Y, which need not be the 8827 same. 8828 8829 For unsigned widening multiplication, use the same idiom, but with 8830 `zero_extend' instead of `sign_extend'. 8831 8832`(div:M X Y)' 8833`(ss_div:M X Y)' 8834 Represents the quotient in signed division of X by Y, carried out 8835 in machine mode M. If M is a floating point mode, it represents 8836 the exact quotient; otherwise, the integerized quotient. `ss_div' 8837 ensures that an out-of-bounds result saturates to the maximum or 8838 minimum signed value. 8839 8840 Some machines have division instructions in which the operands and 8841 quotient widths are not all the same; you should represent such 8842 instructions using `truncate' and `sign_extend' as in, 8843 8844 (truncate:M1 (div:M2 X (sign_extend:M2 Y))) 8845 8846`(udiv:M X Y)' 8847`(us_div:M X Y)' 8848 Like `div' but represents unsigned division. `us_div' ensures 8849 that an out-of-bounds result saturates to the maximum or minimum 8850 unsigned value. 8851 8852`(mod:M X Y)' 8853`(umod:M X Y)' 8854 Like `div' and `udiv' but represent the remainder instead of the 8855 quotient. 8856 8857`(smin:M X Y)' 8858`(smax:M X Y)' 8859 Represents the smaller (for `smin') or larger (for `smax') of X 8860 and Y, interpreted as signed values in mode M. When used with 8861 floating point, if both operands are zeros, or if either operand 8862 is `NaN', then it is unspecified which of the two operands is 8863 returned as the result. 8864 8865`(umin:M X Y)' 8866`(umax:M X Y)' 8867 Like `smin' and `smax', but the values are interpreted as unsigned 8868 integers. 8869 8870`(not:M X)' 8871 Represents the bitwise complement of the value represented by X, 8872 carried out in mode M, which must be a fixed-point machine mode. 8873 8874`(and:M X Y)' 8875 Represents the bitwise logical-and of the values represented by X 8876 and Y, carried out in machine mode M, which must be a fixed-point 8877 machine mode. 8878 8879`(ior:M X Y)' 8880 Represents the bitwise inclusive-or of the values represented by X 8881 and Y, carried out in machine mode M, which must be a fixed-point 8882 mode. 8883 8884`(xor:M X Y)' 8885 Represents the bitwise exclusive-or of the values represented by X 8886 and Y, carried out in machine mode M, which must be a fixed-point 8887 mode. 8888 8889`(ashift:M X C)' 8890`(ss_ashift:M X C)' 8891`(us_ashift:M X C)' 8892 These three expressions represent the result of arithmetically 8893 shifting X left by C places. They differ in their behavior on 8894 overflow of integer modes. An `ashift' operation is a plain shift 8895 with no special behavior in case of a change in the sign bit; 8896 `ss_ashift' and `us_ashift' saturates to the minimum or maximum 8897 representable value if any of the bits shifted out differs from 8898 the final sign bit. 8899 8900 X have mode M, a fixed-point machine mode. C be a fixed-point 8901 mode or be a constant with mode `VOIDmode'; which mode is 8902 determined by the mode called for in the machine description entry 8903 for the left-shift instruction. For example, on the VAX, the mode 8904 of C is `QImode' regardless of M. 8905 8906`(lshiftrt:M X C)' 8907`(ashiftrt:M X C)' 8908 Like `ashift' but for right shift. Unlike the case for left shift, 8909 these two operations are distinct. 8910 8911`(rotate:M X C)' 8912`(rotatert:M X C)' 8913 Similar but represent left and right rotate. If C is a constant, 8914 use `rotate'. 8915 8916`(abs:M X)' 8917 8918`(ss_abs:M X)' 8919 Represents the absolute value of X, computed in mode M. `ss_abs' 8920 ensures that an out-of-bounds result saturates to the maximum 8921 signed value. 8922 8923`(sqrt:M X)' 8924 Represents the square root of X, computed in mode M. Most often M 8925 will be a floating point mode. 8926 8927`(ffs:M X)' 8928 Represents one plus the index of the least significant 1-bit in X, 8929 represented as an integer of mode M. (The value is zero if X is 8930 zero.) The mode of X need not be M; depending on the target 8931 machine, various mode combinations may be valid. 8932 8933`(clz:M X)' 8934 Represents the number of leading 0-bits in X, represented as an 8935 integer of mode M, starting at the most significant bit position. 8936 If X is zero, the value is determined by 8937 `CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Note that this is one 8938 of the few expressions that is not invariant under widening. The 8939 mode of X will usually be an integer mode. 8940 8941`(ctz:M X)' 8942 Represents the number of trailing 0-bits in X, represented as an 8943 integer of mode M, starting at the least significant bit position. 8944 If X is zero, the value is determined by 8945 `CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Except for this case, 8946 `ctz(x)' is equivalent to `ffs(X) - 1'. The mode of X will 8947 usually be an integer mode. 8948 8949`(popcount:M X)' 8950 Represents the number of 1-bits in X, represented as an integer of 8951 mode M. The mode of X will usually be an integer mode. 8952 8953`(parity:M X)' 8954 Represents the number of 1-bits modulo 2 in X, represented as an 8955 integer of mode M. The mode of X will usually be an integer mode. 8956 8957`(bswap:M X)' 8958 Represents the value X with the order of bytes reversed, carried 8959 out in mode M, which must be a fixed-point machine mode. 8960 8961 8962File: gccint.info, Node: Comparisons, Next: Bit-Fields, Prev: Arithmetic, Up: RTL 8963 896410.10 Comparison Operations 8965=========================== 8966 8967Comparison operators test a relation on two operands and are considered 8968to represent a machine-dependent nonzero value described by, but not 8969necessarily equal to, `STORE_FLAG_VALUE' (*note Misc::) if the relation 8970holds, or zero if it does not, for comparison operators whose results 8971have a `MODE_INT' mode, `FLOAT_STORE_FLAG_VALUE' (*note Misc::) if the 8972relation holds, or zero if it does not, for comparison operators that 8973return floating-point values, and a vector of either 8974`VECTOR_STORE_FLAG_VALUE' (*note Misc::) if the relation holds, or of 8975zeros if it does not, for comparison operators that return vector 8976results. The mode of the comparison operation is independent of the 8977mode of the data being compared. If the comparison operation is being 8978tested (e.g., the first operand of an `if_then_else'), the mode must be 8979`VOIDmode'. 8980 8981 There are two ways that comparison operations may be used. The 8982comparison operators may be used to compare the condition codes `(cc0)' 8983against zero, as in `(eq (cc0) (const_int 0))'. Such a construct 8984actually refers to the result of the preceding instruction in which the 8985condition codes were set. The instruction setting the condition code 8986must be adjacent to the instruction using the condition code; only 8987`note' insns may separate them. 8988 8989 Alternatively, a comparison operation may directly compare two data 8990objects. The mode of the comparison is determined by the operands; they 8991must both be valid for a common machine mode. A comparison with both 8992operands constant would be invalid as the machine mode could not be 8993deduced from it, but such a comparison should never exist in RTL due to 8994constant folding. 8995 8996 In the example above, if `(cc0)' were last set to `(compare X Y)', the 8997comparison operation is identical to `(eq X Y)'. Usually only one style 8998of comparisons is supported on a particular machine, but the combine 8999pass will try to merge the operations to produce the `eq' shown in case 9000it exists in the context of the particular insn involved. 9001 9002 Inequality comparisons come in two flavors, signed and unsigned. Thus, 9003there are distinct expression codes `gt' and `gtu' for signed and 9004unsigned greater-than. These can produce different results for the same 9005pair of integer values: for example, 1 is signed greater-than -1 but not 9006unsigned greater-than, because -1 when regarded as unsigned is actually 9007`0xffffffff' which is greater than 1. 9008 9009 The signed comparisons are also used for floating point values. 9010Floating point comparisons are distinguished by the machine modes of 9011the operands. 9012 9013`(eq:M X Y)' 9014 `STORE_FLAG_VALUE' if the values represented by X and Y are equal, 9015 otherwise 0. 9016 9017`(ne:M X Y)' 9018 `STORE_FLAG_VALUE' if the values represented by X and Y are not 9019 equal, otherwise 0. 9020 9021`(gt:M X Y)' 9022 `STORE_FLAG_VALUE' if the X is greater than Y. If they are 9023 fixed-point, the comparison is done in a signed sense. 9024 9025`(gtu:M X Y)' 9026 Like `gt' but does unsigned comparison, on fixed-point numbers 9027 only. 9028 9029`(lt:M X Y)' 9030`(ltu:M X Y)' 9031 Like `gt' and `gtu' but test for "less than". 9032 9033`(ge:M X Y)' 9034`(geu:M X Y)' 9035 Like `gt' and `gtu' but test for "greater than or equal". 9036 9037`(le:M X Y)' 9038`(leu:M X Y)' 9039 Like `gt' and `gtu' but test for "less than or equal". 9040 9041`(if_then_else COND THEN ELSE)' 9042 This is not a comparison operation but is listed here because it is 9043 always used in conjunction with a comparison operation. To be 9044 precise, COND is a comparison expression. This expression 9045 represents a choice, according to COND, between the value 9046 represented by THEN and the one represented by ELSE. 9047 9048 On most machines, `if_then_else' expressions are valid only to 9049 express conditional jumps. 9050 9051`(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)' 9052 Similar to `if_then_else', but more general. Each of TEST1, 9053 TEST2, ... is performed in turn. The result of this expression is 9054 the VALUE corresponding to the first nonzero test, or DEFAULT if 9055 none of the tests are nonzero expressions. 9056 9057 This is currently not valid for instruction patterns and is 9058 supported only for insn attributes. *Note Insn Attributes::. 9059 9060 9061File: gccint.info, Node: Bit-Fields, Next: Vector Operations, Prev: Comparisons, Up: RTL 9062 906310.11 Bit-Fields 9064================ 9065 9066Special expression codes exist to represent bit-field instructions. 9067 9068`(sign_extract:M LOC SIZE POS)' 9069 This represents a reference to a sign-extended bit-field contained 9070 or starting in LOC (a memory or register reference). The bit-field 9071 is SIZE bits wide and starts at bit POS. The compilation option 9072 `BITS_BIG_ENDIAN' says which end of the memory unit POS counts 9073 from. 9074 9075 If LOC is in memory, its mode must be a single-byte integer mode. 9076 If LOC is in a register, the mode to use is specified by the 9077 operand of the `insv' or `extv' pattern (*note Standard Names::) 9078 and is usually a full-word integer mode, which is the default if 9079 none is specified. 9080 9081 The mode of POS is machine-specific and is also specified in the 9082 `insv' or `extv' pattern. 9083 9084 The mode M is the same as the mode that would be used for LOC if 9085 it were a register. 9086 9087 A `sign_extract' can not appear as an lvalue, or part thereof, in 9088 RTL. 9089 9090`(zero_extract:M LOC SIZE POS)' 9091 Like `sign_extract' but refers to an unsigned or zero-extended 9092 bit-field. The same sequence of bits are extracted, but they are 9093 filled to an entire word with zeros instead of by sign-extension. 9094 9095 Unlike `sign_extract', this type of expressions can be lvalues in 9096 RTL; they may appear on the left side of an assignment, indicating 9097 insertion of a value into the specified bit-field. 9098 9099 9100File: gccint.info, Node: Vector Operations, Next: Conversions, Prev: Bit-Fields, Up: RTL 9101 910210.12 Vector Operations 9103======================= 9104 9105All normal RTL expressions can be used with vector modes; they are 9106interpreted as operating on each part of the vector independently. 9107Additionally, there are a few new expressions to describe specific 9108vector operations. 9109 9110`(vec_merge:M VEC1 VEC2 ITEMS)' 9111 This describes a merge operation between two vectors. The result 9112 is a vector of mode M; its elements are selected from either VEC1 9113 or VEC2. Which elements are selected is described by ITEMS, which 9114 is a bit mask represented by a `const_int'; a zero bit indicates 9115 the corresponding element in the result vector is taken from VEC2 9116 while a set bit indicates it is taken from VEC1. 9117 9118`(vec_select:M VEC1 SELECTION)' 9119 This describes an operation that selects parts of a vector. VEC1 9120 is the source vector, and SELECTION is a `parallel' that contains a 9121 `const_int' for each of the subparts of the result vector, giving 9122 the number of the source subpart that should be stored into it. 9123 The result mode M is either the submode for a single element of 9124 VEC1 (if only one subpart is selected), or another vector mode 9125 with that element submode (if multiple subparts are selected). 9126 9127`(vec_concat:M VEC1 VEC2)' 9128 Describes a vector concat operation. The result is a 9129 concatenation of the vectors VEC1 and VEC2; its length is the sum 9130 of the lengths of the two inputs. 9131 9132`(vec_duplicate:M VEC)' 9133 This operation converts a small vector into a larger one by 9134 duplicating the input values. The output vector mode must have 9135 the same submodes as the input vector mode, and the number of 9136 output parts must be an integer multiple of the number of input 9137 parts. 9138 9139 9140 9141File: gccint.info, Node: Conversions, Next: RTL Declarations, Prev: Vector Operations, Up: RTL 9142 914310.13 Conversions 9144================= 9145 9146All conversions between machine modes must be represented by explicit 9147conversion operations. For example, an expression which is the sum of 9148a byte and a full word cannot be written as `(plus:SI (reg:QI 34) 9149(reg:SI 80))' because the `plus' operation requires two operands of the 9150same machine mode. Therefore, the byte-sized operand is enclosed in a 9151conversion operation, as in 9152 9153 (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) 9154 9155 The conversion operation is not a mere placeholder, because there may 9156be more than one way of converting from a given starting mode to the 9157desired final mode. The conversion operation code says how to do it. 9158 9159 For all conversion operations, X must not be `VOIDmode' because the 9160mode in which to do the conversion would not be known. The conversion 9161must either be done at compile-time or X must be placed into a register. 9162 9163`(sign_extend:M X)' 9164 Represents the result of sign-extending the value X to machine 9165 mode M. M must be a fixed-point mode and X a fixed-point value of 9166 a mode narrower than M. 9167 9168`(zero_extend:M X)' 9169 Represents the result of zero-extending the value X to machine 9170 mode M. M must be a fixed-point mode and X a fixed-point value of 9171 a mode narrower than M. 9172 9173`(float_extend:M X)' 9174 Represents the result of extending the value X to machine mode M. 9175 M must be a floating point mode and X a floating point value of a 9176 mode narrower than M. 9177 9178`(truncate:M X)' 9179 Represents the result of truncating the value X to machine mode M. 9180 M must be a fixed-point mode and X a fixed-point value of a mode 9181 wider than M. 9182 9183`(ss_truncate:M X)' 9184 Represents the result of truncating the value X to machine mode M, 9185 using signed saturation in the case of overflow. Both M and the 9186 mode of X must be fixed-point modes. 9187 9188`(us_truncate:M X)' 9189 Represents the result of truncating the value X to machine mode M, 9190 using unsigned saturation in the case of overflow. Both M and the 9191 mode of X must be fixed-point modes. 9192 9193`(float_truncate:M X)' 9194 Represents the result of truncating the value X to machine mode M. 9195 M must be a floating point mode and X a floating point value of a 9196 mode wider than M. 9197 9198`(float:M X)' 9199 Represents the result of converting fixed point value X, regarded 9200 as signed, to floating point mode M. 9201 9202`(unsigned_float:M X)' 9203 Represents the result of converting fixed point value X, regarded 9204 as unsigned, to floating point mode M. 9205 9206`(fix:M X)' 9207 When M is a floating-point mode, represents the result of 9208 converting floating point value X (valid for mode M) to an 9209 integer, still represented in floating point mode M, by rounding 9210 towards zero. 9211 9212 When M is a fixed-point mode, represents the result of converting 9213 floating point value X to mode M, regarded as signed. How 9214 rounding is done is not specified, so this operation may be used 9215 validly in compiling C code only for integer-valued operands. 9216 9217`(unsigned_fix:M X)' 9218 Represents the result of converting floating point value X to 9219 fixed point mode M, regarded as unsigned. How rounding is done is 9220 not specified. 9221 9222`(fract_convert:M X)' 9223 Represents the result of converting fixed-point value X to 9224 fixed-point mode M, signed integer value X to fixed-point mode M, 9225 floating-point value X to fixed-point mode M, fixed-point value X 9226 to integer mode M regarded as signed, or fixed-point value X to 9227 floating-point mode M. When overflows or underflows happen, the 9228 results are undefined. 9229 9230`(sat_fract:M X)' 9231 Represents the result of converting fixed-point value X to 9232 fixed-point mode M, signed integer value X to fixed-point mode M, 9233 or floating-point value X to fixed-point mode M. When overflows 9234 or underflows happen, the results are saturated to the maximum or 9235 the minimum. 9236 9237`(unsigned_fract_convert:M X)' 9238 Represents the result of converting fixed-point value X to integer 9239 mode M regarded as unsigned, or unsigned integer value X to 9240 fixed-point mode M. When overflows or underflows happen, the 9241 results are undefined. 9242 9243`(unsigned_sat_fract:M X)' 9244 Represents the result of converting unsigned integer value X to 9245 fixed-point mode M. When overflows or underflows happen, the 9246 results are saturated to the maximum or the minimum. 9247 9248 9249File: gccint.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL 9250 925110.14 Declarations 9252================== 9253 9254Declaration expression codes do not represent arithmetic operations but 9255rather state assertions about their operands. 9256 9257`(strict_low_part (subreg:M (reg:N R) 0))' 9258 This expression code is used in only one context: as the 9259 destination operand of a `set' expression. In addition, the 9260 operand of this expression must be a non-paradoxical `subreg' 9261 expression. 9262 9263 The presence of `strict_low_part' says that the part of the 9264 register which is meaningful in mode N, but is not part of mode M, 9265 is not to be altered. Normally, an assignment to such a subreg is 9266 allowed to have undefined effects on the rest of the register when 9267 M is less than a word. 9268 9269 9270File: gccint.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL 9271 927210.15 Side Effect Expressions 9273============================= 9274 9275The expression codes described so far represent values, not actions. 9276But machine instructions never produce values; they are meaningful only 9277for their side effects on the state of the machine. Special expression 9278codes are used to represent side effects. 9279 9280 The body of an instruction is always one of these side effect codes; 9281the codes described above, which represent values, appear only as the 9282operands of these. 9283 9284`(set LVAL X)' 9285 Represents the action of storing the value of X into the place 9286 represented by LVAL. LVAL must be an expression representing a 9287 place that can be stored in: `reg' (or `subreg', `strict_low_part' 9288 or `zero_extract'), `mem', `pc', `parallel', or `cc0'. 9289 9290 If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then 9291 X must be valid for that mode. 9292 9293 If LVAL is a `reg' whose machine mode is less than the full width 9294 of the register, then it means that the part of the register 9295 specified by the machine mode is given the specified value and the 9296 rest of the register receives an undefined value. Likewise, if 9297 LVAL is a `subreg' whose machine mode is narrower than the mode of 9298 the register, the rest of the register can be changed in an 9299 undefined way. 9300 9301 If LVAL is a `strict_low_part' of a subreg, then the part of the 9302 register specified by the machine mode of the `subreg' is given 9303 the value X and the rest of the register is not changed. 9304 9305 If LVAL is a `zero_extract', then the referenced part of the 9306 bit-field (a memory or register reference) specified by the 9307 `zero_extract' is given the value X and the rest of the bit-field 9308 is not changed. Note that `sign_extract' can not appear in LVAL. 9309 9310 If LVAL is `(cc0)', it has no machine mode, and X may be either a 9311 `compare' expression or a value that may have any mode. The 9312 latter case represents a "test" instruction. The expression `(set 9313 (cc0) (reg:M N))' is equivalent to `(set (cc0) (compare (reg:M N) 9314 (const_int 0)))'. Use the former expression to save space during 9315 the compilation. 9316 9317 If LVAL is a `parallel', it is used to represent the case of a 9318 function returning a structure in multiple registers. Each element 9319 of the `parallel' is an `expr_list' whose first operand is a `reg' 9320 and whose second operand is a `const_int' representing the offset 9321 (in bytes) into the structure at which the data in that register 9322 corresponds. The first element may be null to indicate that the 9323 structure is also passed partly in memory. 9324 9325 If LVAL is `(pc)', we have a jump instruction, and the 9326 possibilities for X are very limited. It may be a `label_ref' 9327 expression (unconditional jump). It may be an `if_then_else' 9328 (conditional jump), in which case either the second or the third 9329 operand must be `(pc)' (for the case which does not jump) and the 9330 other of the two must be a `label_ref' (for the case which does 9331 jump). X may also be a `mem' or `(plus:SI (pc) Y)', where Y may 9332 be a `reg' or a `mem'; these unusual patterns are used to 9333 represent jumps through branch tables. 9334 9335 If LVAL is neither `(cc0)' nor `(pc)', the mode of LVAL must not 9336 be `VOIDmode' and the mode of X must be valid for the mode of LVAL. 9337 9338 LVAL is customarily accessed with the `SET_DEST' macro and X with 9339 the `SET_SRC' macro. 9340 9341`(return)' 9342 As the sole expression in a pattern, represents a return from the 9343 current function, on machines where this can be done with one 9344 instruction, such as VAXen. On machines where a multi-instruction 9345 "epilogue" must be executed in order to return from the function, 9346 returning is done by jumping to a label which precedes the 9347 epilogue, and the `return' expression code is never used. 9348 9349 Inside an `if_then_else' expression, represents the value to be 9350 placed in `pc' to return to the caller. 9351 9352 Note that an insn pattern of `(return)' is logically equivalent to 9353 `(set (pc) (return))', but the latter form is never used. 9354 9355`(call FUNCTION NARGS)' 9356 Represents a function call. FUNCTION is a `mem' expression whose 9357 address is the address of the function to be called. NARGS is an 9358 expression which can be used for two purposes: on some machines it 9359 represents the number of bytes of stack argument; on others, it 9360 represents the number of argument registers. 9361 9362 Each machine has a standard machine mode which FUNCTION must have. 9363 The machine description defines macro `FUNCTION_MODE' to expand 9364 into the requisite mode name. The purpose of this mode is to 9365 specify what kind of addressing is allowed, on machines where the 9366 allowed kinds of addressing depend on the machine mode being 9367 addressed. 9368 9369`(clobber X)' 9370 Represents the storing or possible storing of an unpredictable, 9371 undescribed value into X, which must be a `reg', `scratch', 9372 `parallel' or `mem' expression. 9373 9374 One place this is used is in string instructions that store 9375 standard values into particular hard registers. It may not be 9376 worth the trouble to describe the values that are stored, but it 9377 is essential to inform the compiler that the registers will be 9378 altered, lest it attempt to keep data in them across the string 9379 instruction. 9380 9381 If X is `(mem:BLK (const_int 0))' or `(mem:BLK (scratch))', it 9382 means that all memory locations must be presumed clobbered. If X 9383 is a `parallel', it has the same meaning as a `parallel' in a 9384 `set' expression. 9385 9386 Note that the machine description classifies certain hard 9387 registers as "call-clobbered". All function call instructions are 9388 assumed by default to clobber these registers, so there is no need 9389 to use `clobber' expressions to indicate this fact. Also, each 9390 function call is assumed to have the potential to alter any memory 9391 location, unless the function is declared `const'. 9392 9393 If the last group of expressions in a `parallel' are each a 9394 `clobber' expression whose arguments are `reg' or `match_scratch' 9395 (*note RTL Template::) expressions, the combiner phase can add the 9396 appropriate `clobber' expressions to an insn it has constructed 9397 when doing so will cause a pattern to be matched. 9398 9399 This feature can be used, for example, on a machine that whose 9400 multiply and add instructions don't use an MQ register but which 9401 has an add-accumulate instruction that does clobber the MQ 9402 register. Similarly, a combined instruction might require a 9403 temporary register while the constituent instructions might not. 9404 9405 When a `clobber' expression for a register appears inside a 9406 `parallel' with other side effects, the register allocator 9407 guarantees that the register is unoccupied both before and after 9408 that insn if it is a hard register clobber. For pseudo-register 9409 clobber, the register allocator and the reload pass do not assign 9410 the same hard register to the clobber and the input operands if 9411 there is an insn alternative containing the `&' constraint (*note 9412 Modifiers::) for the clobber and the hard register is in register 9413 classes of the clobber in the alternative. You can clobber either 9414 a specific hard register, a pseudo register, or a `scratch' 9415 expression; in the latter two cases, GCC will allocate a hard 9416 register that is available there for use as a temporary. 9417 9418 For instructions that require a temporary register, you should use 9419 `scratch' instead of a pseudo-register because this will allow the 9420 combiner phase to add the `clobber' when required. You do this by 9421 coding (`clobber' (`match_scratch' ...)). If you do clobber a 9422 pseudo register, use one which appears nowhere else--generate a 9423 new one each time. Otherwise, you may confuse CSE. 9424 9425 There is one other known use for clobbering a pseudo register in a 9426 `parallel': when one of the input operands of the insn is also 9427 clobbered by the insn. In this case, using the same pseudo 9428 register in the clobber and elsewhere in the insn produces the 9429 expected results. 9430 9431`(use X)' 9432 Represents the use of the value of X. It indicates that the value 9433 in X at this point in the program is needed, even though it may 9434 not be apparent why this is so. Therefore, the compiler will not 9435 attempt to delete previous instructions whose only effect is to 9436 store a value in X. X must be a `reg' expression. 9437 9438 In some situations, it may be tempting to add a `use' of a 9439 register in a `parallel' to describe a situation where the value 9440 of a special register will modify the behavior of the instruction. 9441 A hypothetical example might be a pattern for an addition that can 9442 either wrap around or use saturating addition depending on the 9443 value of a special control register: 9444 9445 (parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3) 9446 (reg:SI 4)] 0)) 9447 (use (reg:SI 1))]) 9448 9449 This will not work, several of the optimizers only look at 9450 expressions locally; it is very likely that if you have multiple 9451 insns with identical inputs to the `unspec', they will be 9452 optimized away even if register 1 changes in between. 9453 9454 This means that `use' can _only_ be used to describe that the 9455 register is live. You should think twice before adding `use' 9456 statements, more often you will want to use `unspec' instead. The 9457 `use' RTX is most commonly useful to describe that a fixed 9458 register is implicitly used in an insn. It is also safe to use in 9459 patterns where the compiler knows for other reasons that the result 9460 of the whole pattern is variable, such as `movmemM' or `call' 9461 patterns. 9462 9463 During the reload phase, an insn that has a `use' as pattern can 9464 carry a reg_equal note. These `use' insns will be deleted before 9465 the reload phase exits. 9466 9467 During the delayed branch scheduling phase, X may be an insn. 9468 This indicates that X previously was located at this place in the 9469 code and its data dependencies need to be taken into account. 9470 These `use' insns will be deleted before the delayed branch 9471 scheduling phase exits. 9472 9473`(parallel [X0 X1 ...])' 9474 Represents several side effects performed in parallel. The square 9475 brackets stand for a vector; the operand of `parallel' is a vector 9476 of expressions. X0, X1 and so on are individual side effect 9477 expressions--expressions of code `set', `call', `return', 9478 `clobber' or `use'. 9479 9480 "In parallel" means that first all the values used in the 9481 individual side-effects are computed, and second all the actual 9482 side-effects are performed. For example, 9483 9484 (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) 9485 (set (mem:SI (reg:SI 1)) (reg:SI 1))]) 9486 9487 says unambiguously that the values of hard register 1 and the 9488 memory location addressed by it are interchanged. In both places 9489 where `(reg:SI 1)' appears as a memory address it refers to the 9490 value in register 1 _before_ the execution of the insn. 9491 9492 It follows that it is _incorrect_ to use `parallel' and expect the 9493 result of one `set' to be available for the next one. For 9494 example, people sometimes attempt to represent a jump-if-zero 9495 instruction this way: 9496 9497 (parallel [(set (cc0) (reg:SI 34)) 9498 (set (pc) (if_then_else 9499 (eq (cc0) (const_int 0)) 9500 (label_ref ...) 9501 (pc)))]) 9502 9503 But this is incorrect, because it says that the jump condition 9504 depends on the condition code value _before_ this instruction, not 9505 on the new value that is set by this instruction. 9506 9507 Peephole optimization, which takes place together with final 9508 assembly code output, can produce insns whose patterns consist of 9509 a `parallel' whose elements are the operands needed to output the 9510 resulting assembler code--often `reg', `mem' or constant 9511 expressions. This would not be well-formed RTL at any other stage 9512 in compilation, but it is ok then because no further optimization 9513 remains to be done. However, the definition of the macro 9514 `NOTICE_UPDATE_CC', if any, must deal with such insns if you 9515 define any peephole optimizations. 9516 9517`(cond_exec [COND EXPR])' 9518 Represents a conditionally executed expression. The EXPR is 9519 executed only if the COND is nonzero. The COND expression must 9520 not have side-effects, but the EXPR may very well have 9521 side-effects. 9522 9523`(sequence [INSNS ...])' 9524 Represents a sequence of insns. Each of the INSNS that appears in 9525 the vector is suitable for appearing in the chain of insns, so it 9526 must be an `insn', `jump_insn', `call_insn', `code_label', 9527 `barrier' or `note'. 9528 9529 A `sequence' RTX is never placed in an actual insn during RTL 9530 generation. It represents the sequence of insns that result from a 9531 `define_expand' _before_ those insns are passed to `emit_insn' to 9532 insert them in the chain of insns. When actually inserted, the 9533 individual sub-insns are separated out and the `sequence' is 9534 forgotten. 9535 9536 After delay-slot scheduling is completed, an insn and all the 9537 insns that reside in its delay slots are grouped together into a 9538 `sequence'. The insn requiring the delay slot is the first insn 9539 in the vector; subsequent insns are to be placed in the delay slot. 9540 9541 `INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to 9542 indicate that a branch insn should be used that will conditionally 9543 annul the effect of the insns in the delay slots. In such a case, 9544 `INSN_FROM_TARGET_P' indicates that the insn is from the target of 9545 the branch and should be executed only if the branch is taken; 9546 otherwise the insn should be executed only if the branch is not 9547 taken. *Note Delay Slots::. 9548 9549 These expression codes appear in place of a side effect, as the body of 9550an insn, though strictly speaking they do not always describe side 9551effects as such: 9552 9553`(asm_input S)' 9554 Represents literal assembler code as described by the string S. 9555 9556`(unspec [OPERANDS ...] INDEX)' 9557`(unspec_volatile [OPERANDS ...] INDEX)' 9558 Represents a machine-specific operation on OPERANDS. INDEX 9559 selects between multiple machine-specific operations. 9560 `unspec_volatile' is used for volatile operations and operations 9561 that may trap; `unspec' is used for other operations. 9562 9563 These codes may appear inside a `pattern' of an insn, inside a 9564 `parallel', or inside an expression. 9565 9566`(addr_vec:M [LR0 LR1 ...])' 9567 Represents a table of jump addresses. The vector elements LR0, 9568 etc., are `label_ref' expressions. The mode M specifies how much 9569 space is given to each address; normally M would be `Pmode'. 9570 9571`(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)' 9572 Represents a table of jump addresses expressed as offsets from 9573 BASE. The vector elements LR0, etc., are `label_ref' expressions 9574 and so is BASE. The mode M specifies how much space is given to 9575 each address-difference. MIN and MAX are set up by branch 9576 shortening and hold a label with a minimum and a maximum address, 9577 respectively. FLAGS indicates the relative position of BASE, MIN 9578 and MAX to the containing insn and of MIN and MAX to BASE. See 9579 rtl.def for details. 9580 9581`(prefetch:M ADDR RW LOCALITY)' 9582 Represents prefetch of memory at address ADDR. Operand RW is 1 if 9583 the prefetch is for data to be written, 0 otherwise; targets that 9584 do not support write prefetches should treat this as a normal 9585 prefetch. Operand LOCALITY specifies the amount of temporal 9586 locality; 0 if there is none or 1, 2, or 3 for increasing levels 9587 of temporal locality; targets that do not support locality hints 9588 should ignore this. 9589 9590 This insn is used to minimize cache-miss latency by moving data 9591 into a cache before it is accessed. It should use only 9592 non-faulting data prefetch instructions. 9593 9594 9595File: gccint.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL 9596 959710.16 Embedded Side-Effects on Addresses 9598======================================== 9599 9600Six special side-effect expression codes appear as memory addresses. 9601 9602`(pre_dec:M X)' 9603 Represents the side effect of decrementing X by a standard amount 9604 and represents also the value that X has after being decremented. 9605 X must be a `reg' or `mem', but most machines allow only a `reg'. 9606 M must be the machine mode for pointers on the machine in use. 9607 The amount X is decremented by is the length in bytes of the 9608 machine mode of the containing memory reference of which this 9609 expression serves as the address. Here is an example of its use: 9610 9611 (mem:DF (pre_dec:SI (reg:SI 39))) 9612 9613 This says to decrement pseudo register 39 by the length of a 9614 `DFmode' value and use the result to address a `DFmode' value. 9615 9616`(pre_inc:M X)' 9617 Similar, but specifies incrementing X instead of decrementing it. 9618 9619`(post_dec:M X)' 9620 Represents the same side effect as `pre_dec' but a different 9621 value. The value represented here is the value X has before being 9622 decremented. 9623 9624`(post_inc:M X)' 9625 Similar, but specifies incrementing X instead of decrementing it. 9626 9627`(post_modify:M X Y)' 9628 Represents the side effect of setting X to Y and represents X 9629 before X is modified. X must be a `reg' or `mem', but most 9630 machines allow only a `reg'. M must be the machine mode for 9631 pointers on the machine in use. 9632 9633 The expression Y must be one of three forms: `(plus:M X Z)', 9634 `(minus:M X Z)', or `(plus:M X I)', where Z is an index register 9635 and I is a constant. 9636 9637 Here is an example of its use: 9638 9639 (mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42) 9640 (reg:SI 48)))) 9641 9642 This says to modify pseudo register 42 by adding the contents of 9643 pseudo register 48 to it, after the use of what ever 42 points to. 9644 9645`(pre_modify:M X EXPR)' 9646 Similar except side effects happen before the use. 9647 9648 These embedded side effect expressions must be used with care. 9649Instruction patterns may not use them. Until the `flow' pass of the 9650compiler, they may occur only to represent pushes onto the stack. The 9651`flow' pass finds cases where registers are incremented or decremented 9652in one instruction and used as an address shortly before or after; 9653these cases are then transformed to use pre- or post-increment or 9654-decrement. 9655 9656 If a register used as the operand of these expressions is used in 9657another address in an insn, the original value of the register is used. 9658Uses of the register outside of an address are not permitted within the 9659same insn as a use in an embedded side effect expression because such 9660insns behave differently on different machines and hence must be treated 9661as ambiguous and disallowed. 9662 9663 An instruction that can be represented with an embedded side effect 9664could also be represented using `parallel' containing an additional 9665`set' to describe how the address register is altered. This is not 9666done because machines that allow these operations at all typically 9667allow them wherever a memory address is called for. Describing them as 9668additional parallel stores would require doubling the number of entries 9669in the machine description. 9670 9671 9672File: gccint.info, Node: Assembler, Next: Debug Information, Prev: Incdec, Up: RTL 9673 967410.17 Assembler Instructions as Expressions 9675=========================================== 9676 9677The RTX code `asm_operands' represents a value produced by a 9678user-specified assembler instruction. It is used to represent an `asm' 9679statement with arguments. An `asm' statement with a single output 9680operand, like this: 9681 9682 asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z)); 9683 9684is represented using a single `asm_operands' RTX which represents the 9685value that is stored in `outputvar': 9686 9687 (set RTX-FOR-OUTPUTVAR 9688 (asm_operands "foo %1,%2,%0" "a" 0 9689 [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z] 9690 [(asm_input:M1 "g") 9691 (asm_input:M2 "di")])) 9692 9693Here the operands of the `asm_operands' RTX are the assembler template 9694string, the output-operand's constraint, the index-number of the output 9695operand among the output operands specified, a vector of input operand 9696RTX's, and a vector of input-operand modes and constraints. The mode 9697M1 is the mode of the sum `x+y'; M2 is that of `*z'. 9698 9699 When an `asm' statement has multiple output values, its insn has 9700several such `set' RTX's inside of a `parallel'. Each `set' contains 9701an `asm_operands'; all of these share the same assembler template and 9702vectors, but each contains the constraint for the respective output 9703operand. They are also distinguished by the output-operand index 9704number, which is 0, 1, ... for successive output operands. 9705 9706 9707File: gccint.info, Node: Debug Information, Next: Insns, Prev: Assembler, Up: RTL 9708 970910.18 Variable Location Debug Information in RTL 9710================================================ 9711 9712Variable tracking relies on `MEM_EXPR' and `REG_EXPR' annotations to 9713determine what user variables memory and register references refer to. 9714 9715 Variable tracking at assignments uses these notes only when they refer 9716to variables that live at fixed locations (e.g., addressable variables, 9717global non-automatic variables). For variables whose location may 9718vary, it relies on the following types of notes. 9719 9720`(var_location:MODE VAR EXP STAT)' 9721 Binds variable `var', a tree, to value EXP, an RTL expression. It 9722 appears only in `NOTE_INSN_VAR_LOCATION' and `DEBUG_INSN's, with 9723 slightly different meanings. MODE, if present, represents the 9724 mode of EXP, which is useful if it is a modeless expression. STAT 9725 is only meaningful in notes, indicating whether the variable is 9726 known to be initialized or uninitialized. 9727 9728`(debug_expr:MODE DECL)' 9729 Stands for the value bound to the `DEBUG_EXPR_DECL' DECL, that 9730 points back to it, within value expressions in `VAR_LOCATION' 9731 nodes. 9732 9733 9734 9735File: gccint.info, Node: Insns, Next: Calls, Prev: Debug Information, Up: RTL 9736 973710.19 Insns 9738=========== 9739 9740The RTL representation of the code for a function is a doubly-linked 9741chain of objects called "insns". Insns are expressions with special 9742codes that are used for no other purpose. Some insns are actual 9743instructions; others represent dispatch tables for `switch' statements; 9744others represent labels to jump to or various sorts of declarative 9745information. 9746 9747 In addition to its own specific data, each insn must have a unique 9748id-number that distinguishes it from all other insns in the current 9749function (after delayed branch scheduling, copies of an insn with the 9750same id-number may be present in multiple places in a function, but 9751these copies will always be identical and will only appear inside a 9752`sequence'), and chain pointers to the preceding and following insns. 9753These three fields occupy the same position in every insn, independent 9754of the expression code of the insn. They could be accessed with `XEXP' 9755and `XINT', but instead three special macros are always used: 9756 9757`INSN_UID (I)' 9758 Accesses the unique id of insn I. 9759 9760`PREV_INSN (I)' 9761 Accesses the chain pointer to the insn preceding I. If I is the 9762 first insn, this is a null pointer. 9763 9764`NEXT_INSN (I)' 9765 Accesses the chain pointer to the insn following I. If I is the 9766 last insn, this is a null pointer. 9767 9768 The first insn in the chain is obtained by calling `get_insns'; the 9769last insn is the result of calling `get_last_insn'. Within the chain 9770delimited by these insns, the `NEXT_INSN' and `PREV_INSN' pointers must 9771always correspond: if INSN is not the first insn, 9772 9773 NEXT_INSN (PREV_INSN (INSN)) == INSN 9774 9775is always true and if INSN is not the last insn, 9776 9777 PREV_INSN (NEXT_INSN (INSN)) == INSN 9778 9779is always true. 9780 9781 After delay slot scheduling, some of the insns in the chain might be 9782`sequence' expressions, which contain a vector of insns. The value of 9783`NEXT_INSN' in all but the last of these insns is the next insn in the 9784vector; the value of `NEXT_INSN' of the last insn in the vector is the 9785same as the value of `NEXT_INSN' for the `sequence' in which it is 9786contained. Similar rules apply for `PREV_INSN'. 9787 9788 This means that the above invariants are not necessarily true for insns 9789inside `sequence' expressions. Specifically, if INSN is the first insn 9790in a `sequence', `NEXT_INSN (PREV_INSN (INSN))' is the insn containing 9791the `sequence' expression, as is the value of `PREV_INSN (NEXT_INSN 9792(INSN))' if INSN is the last insn in the `sequence' expression. You 9793can use these expressions to find the containing `sequence' expression. 9794 9795 Every insn has one of the following expression codes: 9796 9797`insn' 9798 The expression code `insn' is used for instructions that do not 9799 jump and do not do function calls. `sequence' expressions are 9800 always contained in insns with code `insn' even if one of those 9801 insns should jump or do function calls. 9802 9803 Insns with code `insn' have four additional fields beyond the three 9804 mandatory ones listed above. These four are described in a table 9805 below. 9806 9807`jump_insn' 9808 The expression code `jump_insn' is used for instructions that may 9809 jump (or, more generally, may contain `label_ref' expressions to 9810 which `pc' can be set in that instruction). If there is an 9811 instruction to return from the current function, it is recorded as 9812 a `jump_insn'. 9813 9814 `jump_insn' insns have the same extra fields as `insn' insns, 9815 accessed in the same way and in addition contain a field 9816 `JUMP_LABEL' which is defined once jump optimization has completed. 9817 9818 For simple conditional and unconditional jumps, this field contains 9819 the `code_label' to which this insn will (possibly conditionally) 9820 branch. In a more complex jump, `JUMP_LABEL' records one of the 9821 labels that the insn refers to; other jump target labels are 9822 recorded as `REG_LABEL_TARGET' notes. The exception is `addr_vec' 9823 and `addr_diff_vec', where `JUMP_LABEL' is `NULL_RTX' and the only 9824 way to find the labels is to scan the entire body of the insn. 9825 9826 Return insns count as jumps, but since they do not refer to any 9827 labels, their `JUMP_LABEL' is `NULL_RTX'. 9828 9829`call_insn' 9830 The expression code `call_insn' is used for instructions that may 9831 do function calls. It is important to distinguish these 9832 instructions because they imply that certain registers and memory 9833 locations may be altered unpredictably. 9834 9835 `call_insn' insns have the same extra fields as `insn' insns, 9836 accessed in the same way and in addition contain a field 9837 `CALL_INSN_FUNCTION_USAGE', which contains a list (chain of 9838 `expr_list' expressions) containing `use' and `clobber' 9839 expressions that denote hard registers and `MEM's used or 9840 clobbered by the called function. 9841 9842 A `MEM' generally points to a stack slots in which arguments passed 9843 to the libcall by reference (*note TARGET_PASS_BY_REFERENCE: 9844 Register Arguments.) are stored. If the argument is caller-copied 9845 (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot 9846 will be mentioned in `CLOBBER' and `USE' entries; if it's 9847 callee-copied, only a `USE' will appear, and the `MEM' may point 9848 to addresses that are not stack slots. 9849 9850 `CLOBBER'ed registers in this list augment registers specified in 9851 `CALL_USED_REGISTERS' (*note Register Basics::). 9852 9853`code_label' 9854 A `code_label' insn represents a label that a jump insn can jump 9855 to. It contains two special fields of data in addition to the 9856 three standard ones. `CODE_LABEL_NUMBER' is used to hold the 9857 "label number", a number that identifies this label uniquely among 9858 all the labels in the compilation (not just in the current 9859 function). Ultimately, the label is represented in the assembler 9860 output as an assembler label, usually of the form `LN' where N is 9861 the label number. 9862 9863 When a `code_label' appears in an RTL expression, it normally 9864 appears within a `label_ref' which represents the address of the 9865 label, as a number. 9866 9867 Besides as a `code_label', a label can also be represented as a 9868 `note' of type `NOTE_INSN_DELETED_LABEL'. 9869 9870 The field `LABEL_NUSES' is only defined once the jump optimization 9871 phase is completed. It contains the number of times this label is 9872 referenced in the current function. 9873 9874 The field `LABEL_KIND' differentiates four different types of 9875 labels: `LABEL_NORMAL', `LABEL_STATIC_ENTRY', 9876 `LABEL_GLOBAL_ENTRY', and `LABEL_WEAK_ENTRY'. The only labels 9877 that do not have type `LABEL_NORMAL' are "alternate entry points" 9878 to the current function. These may be static (visible only in the 9879 containing translation unit), global (exposed to all translation 9880 units), or weak (global, but can be overridden by another symbol 9881 with the same name). 9882 9883 Much of the compiler treats all four kinds of label identically. 9884 Some of it needs to know whether or not a label is an alternate 9885 entry point; for this purpose, the macro `LABEL_ALT_ENTRY_P' is 9886 provided. It is equivalent to testing whether `LABEL_KIND (label) 9887 == LABEL_NORMAL'. The only place that cares about the distinction 9888 between static, global, and weak alternate entry points, besides 9889 the front-end code that creates them, is the function 9890 `output_alternate_entry_point', in `final.c'. 9891 9892 To set the kind of a label, use the `SET_LABEL_KIND' macro. 9893 9894`barrier' 9895 Barriers are placed in the instruction stream when control cannot 9896 flow past them. They are placed after unconditional jump 9897 instructions to indicate that the jumps are unconditional and 9898 after calls to `volatile' functions, which do not return (e.g., 9899 `exit'). They contain no information beyond the three standard 9900 fields. 9901 9902`note' 9903 `note' insns are used to represent additional debugging and 9904 declarative information. They contain two nonstandard fields, an 9905 integer which is accessed with the macro `NOTE_LINE_NUMBER' and a 9906 string accessed with `NOTE_SOURCE_FILE'. 9907 9908 If `NOTE_LINE_NUMBER' is positive, the note represents the 9909 position of a source line and `NOTE_SOURCE_FILE' is the source 9910 file name that the line came from. These notes control generation 9911 of line number data in the assembler output. 9912 9913 Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a 9914 code with one of the following values (and `NOTE_SOURCE_FILE' must 9915 contain a null pointer): 9916 9917 `NOTE_INSN_DELETED' 9918 Such a note is completely ignorable. Some passes of the 9919 compiler delete insns by altering them into notes of this 9920 kind. 9921 9922 `NOTE_INSN_DELETED_LABEL' 9923 This marks what used to be a `code_label', but was not used 9924 for other purposes than taking its address and was 9925 transformed to mark that no code jumps to it. 9926 9927 `NOTE_INSN_BLOCK_BEG' 9928 `NOTE_INSN_BLOCK_END' 9929 These types of notes indicate the position of the beginning 9930 and end of a level of scoping of variable names. They 9931 control the output of debugging information. 9932 9933 `NOTE_INSN_EH_REGION_BEG' 9934 `NOTE_INSN_EH_REGION_END' 9935 These types of notes indicate the position of the beginning 9936 and end of a level of scoping for exception handling. 9937 `NOTE_BLOCK_NUMBER' identifies which `CODE_LABEL' or `note' 9938 of type `NOTE_INSN_DELETED_LABEL' is associated with the 9939 given region. 9940 9941 `NOTE_INSN_LOOP_BEG' 9942 `NOTE_INSN_LOOP_END' 9943 These types of notes indicate the position of the beginning 9944 and end of a `while' or `for' loop. They enable the loop 9945 optimizer to find loops quickly. 9946 9947 `NOTE_INSN_LOOP_CONT' 9948 Appears at the place in a loop that `continue' statements 9949 jump to. 9950 9951 `NOTE_INSN_LOOP_VTOP' 9952 This note indicates the place in a loop where the exit test 9953 begins for those loops in which the exit test has been 9954 duplicated. This position becomes another virtual start of 9955 the loop when considering loop invariants. 9956 9957 `NOTE_INSN_FUNCTION_BEG' 9958 Appears at the start of the function body, after the function 9959 prologue. 9960 9961 `NOTE_INSN_VAR_LOCATION' 9962 This note is used to generate variable location debugging 9963 information. It indicates that the user variable in its 9964 `VAR_LOCATION' operand is at the location given in the RTL 9965 expression, or holds a value that can be computed by 9966 evaluating the RTL expression from that static point in the 9967 program up to the next such note for the same user variable. 9968 9969 9970 These codes are printed symbolically when they appear in debugging 9971 dumps. 9972 9973`debug_insn' 9974 The expression code `debug_insn' is used for pseudo-instructions 9975 that hold debugging information for variable tracking at 9976 assignments (see `-fvar-tracking-assignments' option). They are 9977 the RTL representation of `GIMPLE_DEBUG' statements (*note 9978 `GIMPLE_DEBUG'::), with a `VAR_LOCATION' operand that binds a user 9979 variable tree to an RTL representation of the `value' in the 9980 corresponding statement. A `DEBUG_EXPR' in it stands for the 9981 value bound to the corresponding `DEBUG_EXPR_DECL'. 9982 9983 Throughout optimization passes, binding information is kept in 9984 pseudo-instruction form, so that, unlike notes, it gets the same 9985 treatment and adjustments that regular instructions would. It is 9986 the variable tracking pass that turns these pseudo-instructions 9987 into var location notes, analyzing control flow, value 9988 equivalences and changes to registers and memory referenced in 9989 value expressions, propagating the values of debug temporaries and 9990 determining expressions that can be used to compute the value of 9991 each user variable at as many points (ranges, actually) in the 9992 program as possible. 9993 9994 Unlike `NOTE_INSN_VAR_LOCATION', the value expression in an 9995 `INSN_VAR_LOCATION' denotes a value at that specific point in the 9996 program, rather than an expression that can be evaluated at any 9997 later point before an overriding `VAR_LOCATION' is encountered. 9998 E.g., if a user variable is bound to a `REG' and then a subsequent 9999 insn modifies the `REG', the note location would keep mapping the 10000 user variable to the register across the insn, whereas the insn 10001 location would keep the variable bound to the value, so that the 10002 variable tracking pass would emit another location note for the 10003 variable at the point in which the register is modified. 10004 10005 10006 The machine mode of an insn is normally `VOIDmode', but some phases 10007use the mode for various purposes. 10008 10009 The common subexpression elimination pass sets the mode of an insn to 10010`QImode' when it is the first insn in a block that has already been 10011processed. 10012 10013 The second Haifa scheduling pass, for targets that can multiple issue, 10014sets the mode of an insn to `TImode' when it is believed that the 10015instruction begins an issue group. That is, when the instruction 10016cannot issue simultaneously with the previous. This may be relied on 10017by later passes, in particular machine-dependent reorg. 10018 10019 Here is a table of the extra fields of `insn', `jump_insn' and 10020`call_insn' insns: 10021 10022`PATTERN (I)' 10023 An expression for the side effect performed by this insn. This 10024 must be one of the following codes: `set', `call', `use', 10025 `clobber', `return', `asm_input', `asm_output', `addr_vec', 10026 `addr_diff_vec', `trap_if', `unspec', `unspec_volatile', 10027 `parallel', `cond_exec', or `sequence'. If it is a `parallel', 10028 each element of the `parallel' must be one these codes, except that 10029 `parallel' expressions cannot be nested and `addr_vec' and 10030 `addr_diff_vec' are not permitted inside a `parallel' expression. 10031 10032`INSN_CODE (I)' 10033 An integer that says which pattern in the machine description 10034 matches this insn, or -1 if the matching has not yet been 10035 attempted. 10036 10037 Such matching is never attempted and this field remains -1 on an 10038 insn whose pattern consists of a single `use', `clobber', 10039 `asm_input', `addr_vec' or `addr_diff_vec' expression. 10040 10041 Matching is also never attempted on insns that result from an `asm' 10042 statement. These contain at least one `asm_operands' expression. 10043 The function `asm_noperands' returns a non-negative value for such 10044 insns. 10045 10046 In the debugging output, this field is printed as a number 10047 followed by a symbolic representation that locates the pattern in 10048 the `md' file as some small positive or negative offset from a 10049 named pattern. 10050 10051`LOG_LINKS (I)' 10052 A list (chain of `insn_list' expressions) giving information about 10053 dependencies between instructions within a basic block. Neither a 10054 jump nor a label may come between the related insns. These are 10055 only used by the schedulers and by combine. This is a deprecated 10056 data structure. Def-use and use-def chains are now preferred. 10057 10058`REG_NOTES (I)' 10059 A list (chain of `expr_list' and `insn_list' expressions) giving 10060 miscellaneous information about the insn. It is often information 10061 pertaining to the registers used in this insn. 10062 10063 The `LOG_LINKS' field of an insn is a chain of `insn_list' 10064expressions. Each of these has two operands: the first is an insn, and 10065the second is another `insn_list' expression (the next one in the 10066chain). The last `insn_list' in the chain has a null pointer as second 10067operand. The significant thing about the chain is which insns appear 10068in it (as first operands of `insn_list' expressions). Their order is 10069not significant. 10070 10071 This list is originally set up by the flow analysis pass; it is a null 10072pointer until then. Flow only adds links for those data dependencies 10073which can be used for instruction combination. For each insn, the flow 10074analysis pass adds a link to insns which store into registers values 10075that are used for the first time in this insn. 10076 10077 The `REG_NOTES' field of an insn is a chain similar to the `LOG_LINKS' 10078field but it includes `expr_list' expressions in addition to 10079`insn_list' expressions. There are several kinds of register notes, 10080which are distinguished by the machine mode, which in a register note 10081is really understood as being an `enum reg_note'. The first operand OP 10082of the note is data whose meaning depends on the kind of note. 10083 10084 The macro `REG_NOTE_KIND (X)' returns the kind of register note. Its 10085counterpart, the macro `PUT_REG_NOTE_KIND (X, NEWKIND)' sets the 10086register note type of X to be NEWKIND. 10087 10088 Register notes are of three classes: They may say something about an 10089input to an insn, they may say something about an output of an insn, or 10090they may create a linkage between two insns. There are also a set of 10091values that are only used in `LOG_LINKS'. 10092 10093 These register notes annotate inputs to an insn: 10094 10095`REG_DEAD' 10096 The value in OP dies in this insn; that is to say, altering the 10097 value immediately after this insn would not affect the future 10098 behavior of the program. 10099 10100 It does not follow that the register OP has no useful value after 10101 this insn since OP is not necessarily modified by this insn. 10102 Rather, no subsequent instruction uses the contents of OP. 10103 10104`REG_UNUSED' 10105 The register OP being set by this insn will not be used in a 10106 subsequent insn. This differs from a `REG_DEAD' note, which 10107 indicates that the value in an input will not be used subsequently. 10108 These two notes are independent; both may be present for the same 10109 register. 10110 10111`REG_INC' 10112 The register OP is incremented (or decremented; at this level 10113 there is no distinction) by an embedded side effect inside this 10114 insn. This means it appears in a `post_inc', `pre_inc', 10115 `post_dec' or `pre_dec' expression. 10116 10117`REG_NONNEG' 10118 The register OP is known to have a nonnegative value when this 10119 insn is reached. This is used so that decrement and branch until 10120 zero instructions, such as the m68k dbra, can be matched. 10121 10122 The `REG_NONNEG' note is added to insns only if the machine 10123 description has a `decrement_and_branch_until_zero' pattern. 10124 10125`REG_LABEL_OPERAND' 10126 This insn uses OP, a `code_label' or a `note' of type 10127 `NOTE_INSN_DELETED_LABEL', but is not a `jump_insn', or it is a 10128 `jump_insn' that refers to the operand as an ordinary operand. 10129 The label may still eventually be a jump target, but if so in an 10130 indirect jump in a subsequent insn. The presence of this note 10131 allows jump optimization to be aware that OP is, in fact, being 10132 used, and flow optimization to build an accurate flow graph. 10133 10134`REG_LABEL_TARGET' 10135 This insn is a `jump_insn' but not an `addr_vec' or 10136 `addr_diff_vec'. It uses OP, a `code_label' as a direct or 10137 indirect jump target. Its purpose is similar to that of 10138 `REG_LABEL_OPERAND'. This note is only present if the insn has 10139 multiple targets; the last label in the insn (in the highest 10140 numbered insn-field) goes into the `JUMP_LABEL' field and does not 10141 have a `REG_LABEL_TARGET' note. *Note JUMP_LABEL: Insns. 10142 10143`REG_CROSSING_JUMP' 10144 This insn is a branching instruction (either an unconditional jump 10145 or an indirect jump) which crosses between hot and cold sections, 10146 which could potentially be very far apart in the executable. The 10147 presence of this note indicates to other optimizations that this 10148 branching instruction should not be "collapsed" into a simpler 10149 branching construct. It is used when the optimization to 10150 partition basic blocks into hot and cold sections is turned on. 10151 10152`REG_SETJMP' 10153 Appears attached to each `CALL_INSN' to `setjmp' or a related 10154 function. 10155 10156 The following notes describe attributes of outputs of an insn: 10157 10158`REG_EQUIV' 10159`REG_EQUAL' 10160 This note is only valid on an insn that sets only one register and 10161 indicates that that register will be equal to OP at run time; the 10162 scope of this equivalence differs between the two types of notes. 10163 The value which the insn explicitly copies into the register may 10164 look different from OP, but they will be equal at run time. If the 10165 output of the single `set' is a `strict_low_part' expression, the 10166 note refers to the register that is contained in `SUBREG_REG' of 10167 the `subreg' expression. 10168 10169 For `REG_EQUIV', the register is equivalent to OP throughout the 10170 entire function, and could validly be replaced in all its 10171 occurrences by OP. ("Validly" here refers to the data flow of the 10172 program; simple replacement may make some insns invalid.) For 10173 example, when a constant is loaded into a register that is never 10174 assigned any other value, this kind of note is used. 10175 10176 When a parameter is copied into a pseudo-register at entry to a 10177 function, a note of this kind records that the register is 10178 equivalent to the stack slot where the parameter was passed. 10179 Although in this case the register may be set by other insns, it 10180 is still valid to replace the register by the stack slot 10181 throughout the function. 10182 10183 A `REG_EQUIV' note is also used on an instruction which copies a 10184 register parameter into a pseudo-register at entry to a function, 10185 if there is a stack slot where that parameter could be stored. 10186 Although other insns may set the pseudo-register, it is valid for 10187 the compiler to replace the pseudo-register by stack slot 10188 throughout the function, provided the compiler ensures that the 10189 stack slot is properly initialized by making the replacement in 10190 the initial copy instruction as well. This is used on machines 10191 for which the calling convention allocates stack space for 10192 register parameters. See `REG_PARM_STACK_SPACE' in *note Stack 10193 Arguments::. 10194 10195 In the case of `REG_EQUAL', the register that is set by this insn 10196 will be equal to OP at run time at the end of this insn but not 10197 necessarily elsewhere in the function. In this case, OP is 10198 typically an arithmetic expression. For example, when a sequence 10199 of insns such as a library call is used to perform an arithmetic 10200 operation, this kind of note is attached to the insn that produces 10201 or copies the final value. 10202 10203 These two notes are used in different ways by the compiler passes. 10204 `REG_EQUAL' is used by passes prior to register allocation (such as 10205 common subexpression elimination and loop optimization) to tell 10206 them how to think of that value. `REG_EQUIV' notes are used by 10207 register allocation to indicate that there is an available 10208 substitute expression (either a constant or a `mem' expression for 10209 the location of a parameter on the stack) that may be used in 10210 place of a register if insufficient registers are available. 10211 10212 Except for stack homes for parameters, which are indicated by a 10213 `REG_EQUIV' note and are not useful to the early optimization 10214 passes and pseudo registers that are equivalent to a memory 10215 location throughout their entire life, which is not detected until 10216 later in the compilation, all equivalences are initially indicated 10217 by an attached `REG_EQUAL' note. In the early stages of register 10218 allocation, a `REG_EQUAL' note is changed into a `REG_EQUIV' note 10219 if OP is a constant and the insn represents the only set of its 10220 destination register. 10221 10222 Thus, compiler passes prior to register allocation need only check 10223 for `REG_EQUAL' notes and passes subsequent to register allocation 10224 need only check for `REG_EQUIV' notes. 10225 10226 These notes describe linkages between insns. They occur in pairs: one 10227insn has one of a pair of notes that points to a second insn, which has 10228the inverse note pointing back to the first insn. 10229 10230`REG_CC_SETTER' 10231`REG_CC_USER' 10232 On machines that use `cc0', the insns which set and use `cc0' set 10233 and use `cc0' are adjacent. However, when branch delay slot 10234 filling is done, this may no longer be true. In this case a 10235 `REG_CC_USER' note will be placed on the insn setting `cc0' to 10236 point to the insn using `cc0' and a `REG_CC_SETTER' note will be 10237 placed on the insn using `cc0' to point to the insn setting `cc0'. 10238 10239 These values are only used in the `LOG_LINKS' field, and indicate the 10240type of dependency that each link represents. Links which indicate a 10241data dependence (a read after write dependence) do not use any code, 10242they simply have mode `VOIDmode', and are printed without any 10243descriptive text. 10244 10245`REG_DEP_TRUE' 10246 This indicates a true dependence (a read after write dependence). 10247 10248`REG_DEP_OUTPUT' 10249 This indicates an output dependence (a write after write 10250 dependence). 10251 10252`REG_DEP_ANTI' 10253 This indicates an anti dependence (a write after read dependence). 10254 10255 10256 These notes describe information gathered from gcov profile data. They 10257are stored in the `REG_NOTES' field of an insn as an `expr_list'. 10258 10259`REG_BR_PROB' 10260 This is used to specify the ratio of branches to non-branches of a 10261 branch insn according to the profile data. The value is stored as 10262 a value between 0 and REG_BR_PROB_BASE; larger values indicate a 10263 higher probability that the branch will be taken. 10264 10265`REG_BR_PRED' 10266 These notes are found in JUMP insns after delayed branch scheduling 10267 has taken place. They indicate both the direction and the 10268 likelihood of the JUMP. The format is a bitmask of ATTR_FLAG_* 10269 values. 10270 10271`REG_FRAME_RELATED_EXPR' 10272 This is used on an RTX_FRAME_RELATED_P insn wherein the attached 10273 expression is used in place of the actual insn pattern. This is 10274 done in cases where the pattern is either complex or misleading. 10275 10276 For convenience, the machine mode in an `insn_list' or `expr_list' is 10277printed using these symbolic codes in debugging dumps. 10278 10279 The only difference between the expression codes `insn_list' and 10280`expr_list' is that the first operand of an `insn_list' is assumed to 10281be an insn and is printed in debugging dumps as the insn's unique id; 10282the first operand of an `expr_list' is printed in the ordinary way as 10283an expression. 10284 10285 10286File: gccint.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL 10287 1028810.20 RTL Representation of Function-Call Insns 10289=============================================== 10290 10291Insns that call subroutines have the RTL expression code `call_insn'. 10292These insns must satisfy special rules, and their bodies must use a 10293special RTL expression code, `call'. 10294 10295 A `call' expression has two operands, as follows: 10296 10297 (call (mem:FM ADDR) NBYTES) 10298 10299Here NBYTES is an operand that represents the number of bytes of 10300argument data being passed to the subroutine, FM is a machine mode 10301(which must equal as the definition of the `FUNCTION_MODE' macro in the 10302machine description) and ADDR represents the address of the subroutine. 10303 10304 For a subroutine that returns no value, the `call' expression as shown 10305above is the entire body of the insn, except that the insn might also 10306contain `use' or `clobber' expressions. 10307 10308 For a subroutine that returns a value whose mode is not `BLKmode', the 10309value is returned in a hard register. If this register's number is R, 10310then the body of the call insn looks like this: 10311 10312 (set (reg:M R) 10313 (call (mem:FM ADDR) NBYTES)) 10314 10315This RTL expression makes it clear (to the optimizer passes) that the 10316appropriate register receives a useful value in this insn. 10317 10318 When a subroutine returns a `BLKmode' value, it is handled by passing 10319to the subroutine the address of a place to store the value. So the 10320call insn itself does not "return" any value, and it has the same RTL 10321form as a call that returns nothing. 10322 10323 On some machines, the call instruction itself clobbers some register, 10324for example to contain the return address. `call_insn' insns on these 10325machines should have a body which is a `parallel' that contains both 10326the `call' expression and `clobber' expressions that indicate which 10327registers are destroyed. Similarly, if the call instruction requires 10328some register other than the stack pointer that is not explicitly 10329mentioned in its RTL, a `use' subexpression should mention that 10330register. 10331 10332 Functions that are called are assumed to modify all registers listed in 10333the configuration macro `CALL_USED_REGISTERS' (*note Register Basics::) 10334and, with the exception of `const' functions and library calls, to 10335modify all of memory. 10336 10337 Insns containing just `use' expressions directly precede the 10338`call_insn' insn to indicate which registers contain inputs to the 10339function. Similarly, if registers other than those in 10340`CALL_USED_REGISTERS' are clobbered by the called function, insns 10341containing a single `clobber' follow immediately after the call to 10342indicate which registers. 10343 10344 10345File: gccint.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL 10346 1034710.21 Structure Sharing Assumptions 10348=================================== 10349 10350The compiler assumes that certain kinds of RTL expressions are unique; 10351there do not exist two distinct objects representing the same value. 10352In other cases, it makes an opposite assumption: that no RTL expression 10353object of a certain kind appears in more than one place in the 10354containing structure. 10355 10356 These assumptions refer to a single function; except for the RTL 10357objects that describe global variables and external functions, and a 10358few standard objects such as small integer constants, no RTL objects 10359are common to two functions. 10360 10361 * Each pseudo-register has only a single `reg' object to represent 10362 it, and therefore only a single machine mode. 10363 10364 * For any symbolic label, there is only one `symbol_ref' object 10365 referring to it. 10366 10367 * All `const_int' expressions with equal values are shared. 10368 10369 * There is only one `pc' expression. 10370 10371 * There is only one `cc0' expression. 10372 10373 * There is only one `const_double' expression with value 0 for each 10374 floating point mode. Likewise for values 1 and 2. 10375 10376 * There is only one `const_vector' expression with value 0 for each 10377 vector mode, be it an integer or a double constant vector. 10378 10379 * No `label_ref' or `scratch' appears in more than one place in the 10380 RTL structure; in other words, it is safe to do a tree-walk of all 10381 the insns in the function and assume that each time a `label_ref' 10382 or `scratch' is seen it is distinct from all others that are seen. 10383 10384 * Only one `mem' object is normally created for each static variable 10385 or stack slot, so these objects are frequently shared in all the 10386 places they appear. However, separate but equal objects for these 10387 variables are occasionally made. 10388 10389 * When a single `asm' statement has multiple output operands, a 10390 distinct `asm_operands' expression is made for each output operand. 10391 However, these all share the vector which contains the sequence of 10392 input operands. This sharing is used later on to test whether two 10393 `asm_operands' expressions come from the same statement, so all 10394 optimizations must carefully preserve the sharing if they copy the 10395 vector at all. 10396 10397 * No RTL object appears in more than one place in the RTL structure 10398 except as described above. Many passes of the compiler rely on 10399 this by assuming that they can modify RTL objects in place without 10400 unwanted side-effects on other insns. 10401 10402 * During initial RTL generation, shared structure is freely 10403 introduced. After all the RTL for a function has been generated, 10404 all shared structure is copied by `unshare_all_rtl' in 10405 `emit-rtl.c', after which the above rules are guaranteed to be 10406 followed. 10407 10408 * During the combiner pass, shared structure within an insn can exist 10409 temporarily. However, the shared structure is copied before the 10410 combiner is finished with the insn. This is done by calling 10411 `copy_rtx_if_shared', which is a subroutine of `unshare_all_rtl'. 10412 10413 10414File: gccint.info, Node: Reading RTL, Prev: Sharing, Up: RTL 10415 1041610.22 Reading RTL 10417================= 10418 10419To read an RTL object from a file, call `read_rtx'. It takes one 10420argument, a stdio stream, and returns a single RTL object. This routine 10421is defined in `read-rtl.c'. It is not available in the compiler 10422itself, only the various programs that generate the compiler back end 10423from the machine description. 10424 10425 People frequently have the idea of using RTL stored as text in a file 10426as an interface between a language front end and the bulk of GCC. This 10427idea is not feasible. 10428 10429 GCC was designed to use RTL internally only. Correct RTL for a given 10430program is very dependent on the particular target machine. And the RTL 10431does not contain all the information about the program. 10432 10433 The proper way to interface GCC to a new language front end is with 10434the "tree" data structure, described in the files `tree.h' and 10435`tree.def'. The documentation for this structure (*note GENERIC::) is 10436incomplete. 10437 10438 10439File: gccint.info, Node: GENERIC, Next: GIMPLE, Prev: Passes, Up: Top 10440 1044111 GENERIC 10442********** 10443 10444The purpose of GENERIC is simply to provide a language-independent way 10445of representing an entire function in trees. To this end, it was 10446necessary to add a few new tree codes to the back end, but most 10447everything was already there. If you can express it with the codes in 10448`gcc/tree.def', it's GENERIC. 10449 10450 Early on, there was a great deal of debate about how to think about 10451statements in a tree IL. In GENERIC, a statement is defined as any 10452expression whose value, if any, is ignored. A statement will always 10453have `TREE_SIDE_EFFECTS' set (or it will be discarded), but a 10454non-statement expression may also have side effects. A `CALL_EXPR', 10455for instance. 10456 10457 It would be possible for some local optimizations to work on the 10458GENERIC form of a function; indeed, the adapted tree inliner works fine 10459on GENERIC, but the current compiler performs inlining after lowering 10460to GIMPLE (a restricted form described in the next section). Indeed, 10461currently the frontends perform this lowering before handing off to 10462`tree_rest_of_compilation', but this seems inelegant. 10463 10464* Menu: 10465 10466* Deficiencies:: Topics net yet covered in this document. 10467* Tree overview:: All about `tree's. 10468* Types:: Fundamental and aggregate types. 10469* Declarations:: Type declarations and variables. 10470* Attributes:: Declaration and type attributes. 10471* Expressions: Expression trees. Operating on data. 10472* Statements:: Control flow and related trees. 10473* Functions:: Function bodies, linkage, and other aspects. 10474* Language-dependent trees:: Topics and trees specific to language front ends. 10475* C and C++ Trees:: Trees specific to C and C++. 10476* Java Trees:: Trees specific to Java. 10477 10478 10479File: gccint.info, Node: Deficiencies, Next: Tree overview, Up: GENERIC 10480 1048111.1 Deficiencies 10482================= 10483 10484There are many places in which this document is incomplet and incorrekt. 10485It is, as of yet, only _preliminary_ documentation. 10486 10487 10488File: gccint.info, Node: Tree overview, Next: Types, Prev: Deficiencies, Up: GENERIC 10489 1049011.2 Overview 10491============= 10492 10493The central data structure used by the internal representation is the 10494`tree'. These nodes, while all of the C type `tree', are of many 10495varieties. A `tree' is a pointer type, but the object to which it 10496points may be of a variety of types. From this point forward, we will 10497refer to trees in ordinary type, rather than in `this font', except 10498when talking about the actual C type `tree'. 10499 10500 You can tell what kind of node a particular tree is by using the 10501`TREE_CODE' macro. Many, many macros take trees as input and return 10502trees as output. However, most macros require a certain kind of tree 10503node as input. In other words, there is a type-system for trees, but 10504it is not reflected in the C type-system. 10505 10506 For safety, it is useful to configure GCC with `--enable-checking'. 10507Although this results in a significant performance penalty (since all 10508tree types are checked at run-time), and is therefore inappropriate in a 10509release version, it is extremely helpful during the development process. 10510 10511 Many macros behave as predicates. Many, although not all, of these 10512predicates end in `_P'. Do not rely on the result type of these macros 10513being of any particular type. You may, however, rely on the fact that 10514the type can be compared to `0', so that statements like 10515 if (TEST_P (t) && !TEST_P (y)) 10516 x = 1; 10517 and 10518 int i = (TEST_P (t) != 0); 10519 are legal. Macros that return `int' values now may be changed to 10520return `tree' values, or other pointers in the future. Even those that 10521continue to return `int' may return multiple nonzero codes where 10522previously they returned only zero and one. Therefore, you should not 10523write code like 10524 if (TEST_P (t) == 1) 10525 as this code is not guaranteed to work correctly in the future. 10526 10527 You should not take the address of values returned by the macros or 10528functions described here. In particular, no guarantee is given that the 10529values are lvalues. 10530 10531 In general, the names of macros are all in uppercase, while the names 10532of functions are entirely in lowercase. There are rare exceptions to 10533this rule. You should assume that any macro or function whose name is 10534made up entirely of uppercase letters may evaluate its arguments more 10535than once. You may assume that a macro or function whose name is made 10536up entirely of lowercase letters will evaluate its arguments only once. 10537 10538 The `error_mark_node' is a special tree. Its tree code is 10539`ERROR_MARK', but since there is only ever one node with that code, the 10540usual practice is to compare the tree against `error_mark_node'. (This 10541test is just a test for pointer equality.) If an error has occurred 10542during front-end processing the flag `errorcount' will be set. If the 10543front end has encountered code it cannot handle, it will issue a 10544message to the user and set `sorrycount'. When these flags are set, 10545any macro or function which normally returns a tree of a particular 10546kind may instead return the `error_mark_node'. Thus, if you intend to 10547do any processing of erroneous code, you must be prepared to deal with 10548the `error_mark_node'. 10549 10550 Occasionally, a particular tree slot (like an operand to an expression, 10551or a particular field in a declaration) will be referred to as 10552"reserved for the back end". These slots are used to store RTL when 10553the tree is converted to RTL for use by the GCC back end. However, if 10554that process is not taking place (e.g., if the front end is being hooked 10555up to an intelligent editor), then those slots may be used by the back 10556end presently in use. 10557 10558 If you encounter situations that do not match this documentation, such 10559as tree nodes of types not mentioned here, or macros documented to 10560return entities of a particular kind that instead return entities of 10561some different kind, you have found a bug, either in the front end or in 10562the documentation. Please report these bugs as you would any other bug. 10563 10564* Menu: 10565 10566* Macros and Functions::Macros and functions that can be used with all trees. 10567* Identifiers:: The names of things. 10568* Containers:: Lists and vectors. 10569 10570 10571File: gccint.info, Node: Macros and Functions, Next: Identifiers, Up: Tree overview 10572 1057311.2.1 Trees 10574------------ 10575 10576All GENERIC trees have two fields in common. First, `TREE_CHAIN' is a 10577pointer that can be used as a singly-linked list to other trees. The 10578other is `TREE_TYPE'. Many trees store the type of an expression or 10579declaration in this field. 10580 10581 These are some other functions for handling trees: 10582 10583`tree_size' 10584 Return the number of bytes a tree takes. 10585 10586`build0' 10587`build1' 10588`build2' 10589`build3' 10590`build4' 10591`build5' 10592`build6' 10593 These functions build a tree and supply values to put in each 10594 parameter. The basic signature is `code, type, [operands]'. 10595 `code' is the `TREE_CODE', and `type' is a tree representing the 10596 `TREE_TYPE'. These are followed by the operands, each of which is 10597 also a tree. 10598 10599 10600 10601File: gccint.info, Node: Identifiers, Next: Containers, Prev: Macros and Functions, Up: Tree overview 10602 1060311.2.2 Identifiers 10604------------------ 10605 10606An `IDENTIFIER_NODE' represents a slightly more general concept that 10607the standard C or C++ concept of identifier. In particular, an 10608`IDENTIFIER_NODE' may contain a `$', or other extraordinary characters. 10609 10610 There are never two distinct `IDENTIFIER_NODE's representing the same 10611identifier. Therefore, you may use pointer equality to compare 10612`IDENTIFIER_NODE's, rather than using a routine like `strcmp'. Use 10613`get_identifier' to obtain the unique `IDENTIFIER_NODE' for a supplied 10614string. 10615 10616 You can use the following macros to access identifiers: 10617`IDENTIFIER_POINTER' 10618 The string represented by the identifier, represented as a 10619 `char*'. This string is always `NUL'-terminated, and contains no 10620 embedded `NUL' characters. 10621 10622`IDENTIFIER_LENGTH' 10623 The length of the string returned by `IDENTIFIER_POINTER', not 10624 including the trailing `NUL'. This value of `IDENTIFIER_LENGTH 10625 (x)' is always the same as `strlen (IDENTIFIER_POINTER (x))'. 10626 10627`IDENTIFIER_OPNAME_P' 10628 This predicate holds if the identifier represents the name of an 10629 overloaded operator. In this case, you should not depend on the 10630 contents of either the `IDENTIFIER_POINTER' or the 10631 `IDENTIFIER_LENGTH'. 10632 10633`IDENTIFIER_TYPENAME_P' 10634 This predicate holds if the identifier represents the name of a 10635 user-defined conversion operator. In this case, the `TREE_TYPE' of 10636 the `IDENTIFIER_NODE' holds the type to which the conversion 10637 operator converts. 10638 10639 10640 10641File: gccint.info, Node: Containers, Prev: Identifiers, Up: Tree overview 10642 1064311.2.3 Containers 10644----------------- 10645 10646Two common container data structures can be represented directly with 10647tree nodes. A `TREE_LIST' is a singly linked list containing two trees 10648per node. These are the `TREE_PURPOSE' and `TREE_VALUE' of each node. 10649(Often, the `TREE_PURPOSE' contains some kind of tag, or additional 10650information, while the `TREE_VALUE' contains the majority of the 10651payload. In other cases, the `TREE_PURPOSE' is simply `NULL_TREE', 10652while in still others both the `TREE_PURPOSE' and `TREE_VALUE' are of 10653equal stature.) Given one `TREE_LIST' node, the next node is found by 10654following the `TREE_CHAIN'. If the `TREE_CHAIN' is `NULL_TREE', then 10655you have reached the end of the list. 10656 10657 A `TREE_VEC' is a simple vector. The `TREE_VEC_LENGTH' is an integer 10658(not a tree) giving the number of nodes in the vector. The nodes 10659themselves are accessed using the `TREE_VEC_ELT' macro, which takes two 10660arguments. The first is the `TREE_VEC' in question; the second is an 10661integer indicating which element in the vector is desired. The 10662elements are indexed from zero. 10663 10664 10665File: gccint.info, Node: Types, Next: Declarations, Prev: Tree overview, Up: GENERIC 10666 1066711.3 Types 10668========== 10669 10670All types have corresponding tree nodes. However, you should not assume 10671that there is exactly one tree node corresponding to each type. There 10672are often multiple nodes corresponding to the same type. 10673 10674 For the most part, different kinds of types have different tree codes. 10675(For example, pointer types use a `POINTER_TYPE' code while arrays use 10676an `ARRAY_TYPE' code.) However, pointers to member functions use the 10677`RECORD_TYPE' code. Therefore, when writing a `switch' statement that 10678depends on the code associated with a particular type, you should take 10679care to handle pointers to member functions under the `RECORD_TYPE' 10680case label. 10681 10682 The following functions and macros deal with cv-qualification of types: 10683`TYPE_MAIN_VARIANT' 10684 This macro returns the unqualified version of a type. It may be 10685 applied to an unqualified type, but it is not always the identity 10686 function in that case. 10687 10688 A few other macros and functions are usable with all types: 10689`TYPE_SIZE' 10690 The number of bits required to represent the type, represented as 10691 an `INTEGER_CST'. For an incomplete type, `TYPE_SIZE' will be 10692 `NULL_TREE'. 10693 10694`TYPE_ALIGN' 10695 The alignment of the type, in bits, represented as an `int'. 10696 10697`TYPE_NAME' 10698 This macro returns a declaration (in the form of a `TYPE_DECL') for 10699 the type. (Note this macro does _not_ return an 10700 `IDENTIFIER_NODE', as you might expect, given its name!) You can 10701 look at the `DECL_NAME' of the `TYPE_DECL' to obtain the actual 10702 name of the type. The `TYPE_NAME' will be `NULL_TREE' for a type 10703 that is not a built-in type, the result of a typedef, or a named 10704 class type. 10705 10706`TYPE_CANONICAL' 10707 This macro returns the "canonical" type for the given type node. 10708 Canonical types are used to improve performance in the C++ and 10709 Objective-C++ front ends by allowing efficient comparison between 10710 two type nodes in `same_type_p': if the `TYPE_CANONICAL' values of 10711 the types are equal, the types are equivalent; otherwise, the types 10712 are not equivalent. The notion of equivalence for canonical types 10713 is the same as the notion of type equivalence in the language 10714 itself. For instance, 10715 10716 When `TYPE_CANONICAL' is `NULL_TREE', there is no canonical type 10717 for the given type node. In this case, comparison between this 10718 type and any other type requires the compiler to perform a deep, 10719 "structural" comparison to see if the two type nodes have the same 10720 form and properties. 10721 10722 The canonical type for a node is always the most fundamental type 10723 in the equivalence class of types. For instance, `int' is its own 10724 canonical type. A typedef `I' of `int' will have `int' as its 10725 canonical type. Similarly, `I*' and a typedef `IP' (defined to 10726 `I*') will has `int*' as their canonical type. When building a new 10727 type node, be sure to set `TYPE_CANONICAL' to the appropriate 10728 canonical type. If the new type is a compound type (built from 10729 other types), and any of those other types require structural 10730 equality, use `SET_TYPE_STRUCTURAL_EQUALITY' to ensure that the 10731 new type also requires structural equality. Finally, if for some 10732 reason you cannot guarantee that `TYPE_CANONICAL' will point to 10733 the canonical type, use `SET_TYPE_STRUCTURAL_EQUALITY' to make 10734 sure that the new type-and any type constructed based on 10735 it-requires structural equality. If you suspect that the canonical 10736 type system is miscomparing types, pass `--param 10737 verify-canonical-types=1' to the compiler or configure with 10738 `--enable-checking' to force the compiler to verify its 10739 canonical-type comparisons against the structural comparisons; the 10740 compiler will then print any warnings if the canonical types 10741 miscompare. 10742 10743`TYPE_STRUCTURAL_EQUALITY_P' 10744 This predicate holds when the node requires structural equality 10745 checks, e.g., when `TYPE_CANONICAL' is `NULL_TREE'. 10746 10747`SET_TYPE_STRUCTURAL_EQUALITY' 10748 This macro states that the type node it is given requires 10749 structural equality checks, e.g., it sets `TYPE_CANONICAL' to 10750 `NULL_TREE'. 10751 10752`same_type_p' 10753 This predicate takes two types as input, and holds if they are the 10754 same type. For example, if one type is a `typedef' for the other, 10755 or both are `typedef's for the same type. This predicate also 10756 holds if the two trees given as input are simply copies of one 10757 another; i.e., there is no difference between them at the source 10758 level, but, for whatever reason, a duplicate has been made in the 10759 representation. You should never use `==' (pointer equality) to 10760 compare types; always use `same_type_p' instead. 10761 10762 Detailed below are the various kinds of types, and the macros that can 10763be used to access them. Although other kinds of types are used 10764elsewhere in G++, the types described here are the only ones that you 10765will encounter while examining the intermediate representation. 10766 10767`VOID_TYPE' 10768 Used to represent the `void' type. 10769 10770`INTEGER_TYPE' 10771 Used to represent the various integral types, including `char', 10772 `short', `int', `long', and `long long'. This code is not used 10773 for enumeration types, nor for the `bool' type. The 10774 `TYPE_PRECISION' is the number of bits used in the representation, 10775 represented as an `unsigned int'. (Note that in the general case 10776 this is not the same value as `TYPE_SIZE'; suppose that there were 10777 a 24-bit integer type, but that alignment requirements for the ABI 10778 required 32-bit alignment. Then, `TYPE_SIZE' would be an 10779 `INTEGER_CST' for 32, while `TYPE_PRECISION' would be 24.) The 10780 integer type is unsigned if `TYPE_UNSIGNED' holds; otherwise, it 10781 is signed. 10782 10783 The `TYPE_MIN_VALUE' is an `INTEGER_CST' for the smallest integer 10784 that may be represented by this type. Similarly, the 10785 `TYPE_MAX_VALUE' is an `INTEGER_CST' for the largest integer that 10786 may be represented by this type. 10787 10788`REAL_TYPE' 10789 Used to represent the `float', `double', and `long double' types. 10790 The number of bits in the floating-point representation is given 10791 by `TYPE_PRECISION', as in the `INTEGER_TYPE' case. 10792 10793`FIXED_POINT_TYPE' 10794 Used to represent the `short _Fract', `_Fract', `long _Fract', 10795 `long long _Fract', `short _Accum', `_Accum', `long _Accum', and 10796 `long long _Accum' types. The number of bits in the fixed-point 10797 representation is given by `TYPE_PRECISION', as in the 10798 `INTEGER_TYPE' case. There may be padding bits, fractional bits 10799 and integral bits. The number of fractional bits is given by 10800 `TYPE_FBIT', and the number of integral bits is given by 10801 `TYPE_IBIT'. The fixed-point type is unsigned if `TYPE_UNSIGNED' 10802 holds; otherwise, it is signed. The fixed-point type is 10803 saturating if `TYPE_SATURATING' holds; otherwise, it is not 10804 saturating. 10805 10806`COMPLEX_TYPE' 10807 Used to represent GCC built-in `__complex__' data types. The 10808 `TREE_TYPE' is the type of the real and imaginary parts. 10809 10810`ENUMERAL_TYPE' 10811 Used to represent an enumeration type. The `TYPE_PRECISION' gives 10812 (as an `int'), the number of bits used to represent the type. If 10813 there are no negative enumeration constants, `TYPE_UNSIGNED' will 10814 hold. The minimum and maximum enumeration constants may be 10815 obtained with `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE', respectively; 10816 each of these macros returns an `INTEGER_CST'. 10817 10818 The actual enumeration constants themselves may be obtained by 10819 looking at the `TYPE_VALUES'. This macro will return a 10820 `TREE_LIST', containing the constants. The `TREE_PURPOSE' of each 10821 node will be an `IDENTIFIER_NODE' giving the name of the constant; 10822 the `TREE_VALUE' will be an `INTEGER_CST' giving the value 10823 assigned to that constant. These constants will appear in the 10824 order in which they were declared. The `TREE_TYPE' of each of 10825 these constants will be the type of enumeration type itself. 10826 10827`BOOLEAN_TYPE' 10828 Used to represent the `bool' type. 10829 10830`POINTER_TYPE' 10831 Used to represent pointer types, and pointer to data member types. 10832 The `TREE_TYPE' gives the type to which this type points. 10833 10834`REFERENCE_TYPE' 10835 Used to represent reference types. The `TREE_TYPE' gives the type 10836 to which this type refers. 10837 10838`FUNCTION_TYPE' 10839 Used to represent the type of non-member functions and of static 10840 member functions. The `TREE_TYPE' gives the return type of the 10841 function. The `TYPE_ARG_TYPES' are a `TREE_LIST' of the argument 10842 types. The `TREE_VALUE' of each node in this list is the type of 10843 the corresponding argument; the `TREE_PURPOSE' is an expression 10844 for the default argument value, if any. If the last node in the 10845 list is `void_list_node' (a `TREE_LIST' node whose `TREE_VALUE' is 10846 the `void_type_node'), then functions of this type do not take 10847 variable arguments. Otherwise, they do take a variable number of 10848 arguments. 10849 10850 Note that in C (but not in C++) a function declared like `void f()' 10851 is an unprototyped function taking a variable number of arguments; 10852 the `TYPE_ARG_TYPES' of such a function will be `NULL'. 10853 10854`METHOD_TYPE' 10855 Used to represent the type of a non-static member function. Like a 10856 `FUNCTION_TYPE', the return type is given by the `TREE_TYPE'. The 10857 type of `*this', i.e., the class of which functions of this type 10858 are a member, is given by the `TYPE_METHOD_BASETYPE'. The 10859 `TYPE_ARG_TYPES' is the parameter list, as for a `FUNCTION_TYPE', 10860 and includes the `this' argument. 10861 10862`ARRAY_TYPE' 10863 Used to represent array types. The `TREE_TYPE' gives the type of 10864 the elements in the array. If the array-bound is present in the 10865 type, the `TYPE_DOMAIN' is an `INTEGER_TYPE' whose 10866 `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE' will be the lower and upper 10867 bounds of the array, respectively. The `TYPE_MIN_VALUE' will 10868 always be an `INTEGER_CST' for zero, while the `TYPE_MAX_VALUE' 10869 will be one less than the number of elements in the array, i.e., 10870 the highest value which may be used to index an element in the 10871 array. 10872 10873`RECORD_TYPE' 10874 Used to represent `struct' and `class' types, as well as pointers 10875 to member functions and similar constructs in other languages. 10876 `TYPE_FIELDS' contains the items contained in this type, each of 10877 which can be a `FIELD_DECL', `VAR_DECL', `CONST_DECL', or 10878 `TYPE_DECL'. You may not make any assumptions about the ordering 10879 of the fields in the type or whether one or more of them overlap. 10880 10881`UNION_TYPE' 10882 Used to represent `union' types. Similar to `RECORD_TYPE' except 10883 that all `FIELD_DECL' nodes in `TYPE_FIELD' start at bit position 10884 zero. 10885 10886`QUAL_UNION_TYPE' 10887 Used to represent part of a variant record in Ada. Similar to 10888 `UNION_TYPE' except that each `FIELD_DECL' has a `DECL_QUALIFIER' 10889 field, which contains a boolean expression that indicates whether 10890 the field is present in the object. The type will only have one 10891 field, so each field's `DECL_QUALIFIER' is only evaluated if none 10892 of the expressions in the previous fields in `TYPE_FIELDS' are 10893 nonzero. Normally these expressions will reference a field in the 10894 outer object using a `PLACEHOLDER_EXPR'. 10895 10896`LANG_TYPE' 10897 This node is used to represent a language-specific type. The front 10898 end must handle it. 10899 10900`OFFSET_TYPE' 10901 This node is used to represent a pointer-to-data member. For a 10902 data member `X::m' the `TYPE_OFFSET_BASETYPE' is `X' and the 10903 `TREE_TYPE' is the type of `m'. 10904 10905 10906 There are variables whose values represent some of the basic types. 10907These include: 10908`void_type_node' 10909 A node for `void'. 10910 10911`integer_type_node' 10912 A node for `int'. 10913 10914`unsigned_type_node.' 10915 A node for `unsigned int'. 10916 10917`char_type_node.' 10918 A node for `char'. 10919 It may sometimes be useful to compare one of these variables with a 10920type in hand, using `same_type_p'. 10921 10922 10923File: gccint.info, Node: Declarations, Next: Attributes, Prev: Types, Up: GENERIC 10924 1092511.4 Declarations 10926================= 10927 10928This section covers the various kinds of declarations that appear in the 10929internal representation, except for declarations of functions 10930(represented by `FUNCTION_DECL' nodes), which are described in *note 10931Functions::. 10932 10933* Menu: 10934 10935* Working with declarations:: Macros and functions that work on 10936declarations. 10937* Internal structure:: How declaration nodes are represented. 10938 10939 10940File: gccint.info, Node: Working with declarations, Next: Internal structure, Up: Declarations 10941 1094211.4.1 Working with declarations 10943-------------------------------- 10944 10945Some macros can be used with any kind of declaration. These include: 10946`DECL_NAME' 10947 This macro returns an `IDENTIFIER_NODE' giving the name of the 10948 entity. 10949 10950`TREE_TYPE' 10951 This macro returns the type of the entity declared. 10952 10953`EXPR_FILENAME' 10954 This macro returns the name of the file in which the entity was 10955 declared, as a `char*'. For an entity declared implicitly by the 10956 compiler (like `__builtin_memcpy'), this will be the string 10957 `"<internal>"'. 10958 10959`EXPR_LINENO' 10960 This macro returns the line number at which the entity was 10961 declared, as an `int'. 10962 10963`DECL_ARTIFICIAL' 10964 This predicate holds if the declaration was implicitly generated 10965 by the compiler. For example, this predicate will hold of an 10966 implicitly declared member function, or of the `TYPE_DECL' 10967 implicitly generated for a class type. Recall that in C++ code 10968 like: 10969 struct S {}; 10970 is roughly equivalent to C code like: 10971 struct S {}; 10972 typedef struct S S; 10973 The implicitly generated `typedef' declaration is represented by a 10974 `TYPE_DECL' for which `DECL_ARTIFICIAL' holds. 10975 10976 10977 The various kinds of declarations include: 10978`LABEL_DECL' 10979 These nodes are used to represent labels in function bodies. For 10980 more information, see *note Functions::. These nodes only appear 10981 in block scopes. 10982 10983`CONST_DECL' 10984 These nodes are used to represent enumeration constants. The 10985 value of the constant is given by `DECL_INITIAL' which will be an 10986 `INTEGER_CST' with the same type as the `TREE_TYPE' of the 10987 `CONST_DECL', i.e., an `ENUMERAL_TYPE'. 10988 10989`RESULT_DECL' 10990 These nodes represent the value returned by a function. When a 10991 value is assigned to a `RESULT_DECL', that indicates that the 10992 value should be returned, via bitwise copy, by the function. You 10993 can use `DECL_SIZE' and `DECL_ALIGN' on a `RESULT_DECL', just as 10994 with a `VAR_DECL'. 10995 10996`TYPE_DECL' 10997 These nodes represent `typedef' declarations. The `TREE_TYPE' is 10998 the type declared to have the name given by `DECL_NAME'. In some 10999 cases, there is no associated name. 11000 11001`VAR_DECL' 11002 These nodes represent variables with namespace or block scope, as 11003 well as static data members. The `DECL_SIZE' and `DECL_ALIGN' are 11004 analogous to `TYPE_SIZE' and `TYPE_ALIGN'. For a declaration, you 11005 should always use the `DECL_SIZE' and `DECL_ALIGN' rather than the 11006 `TYPE_SIZE' and `TYPE_ALIGN' given by the `TREE_TYPE', since 11007 special attributes may have been applied to the variable to give 11008 it a particular size and alignment. You may use the predicates 11009 `DECL_THIS_STATIC' or `DECL_THIS_EXTERN' to test whether the 11010 storage class specifiers `static' or `extern' were used to declare 11011 a variable. 11012 11013 If this variable is initialized (but does not require a 11014 constructor), the `DECL_INITIAL' will be an expression for the 11015 initializer. The initializer should be evaluated, and a bitwise 11016 copy into the variable performed. If the `DECL_INITIAL' is the 11017 `error_mark_node', there is an initializer, but it is given by an 11018 explicit statement later in the code; no bitwise copy is required. 11019 11020 GCC provides an extension that allows either automatic variables, 11021 or global variables, to be placed in particular registers. This 11022 extension is being used for a particular `VAR_DECL' if 11023 `DECL_REGISTER' holds for the `VAR_DECL', and if 11024 `DECL_ASSEMBLER_NAME' is not equal to `DECL_NAME'. In that case, 11025 `DECL_ASSEMBLER_NAME' is the name of the register into which the 11026 variable will be placed. 11027 11028`PARM_DECL' 11029 Used to represent a parameter to a function. Treat these nodes 11030 similarly to `VAR_DECL' nodes. These nodes only appear in the 11031 `DECL_ARGUMENTS' for a `FUNCTION_DECL'. 11032 11033 The `DECL_ARG_TYPE' for a `PARM_DECL' is the type that will 11034 actually be used when a value is passed to this function. It may 11035 be a wider type than the `TREE_TYPE' of the parameter; for 11036 example, the ordinary type might be `short' while the 11037 `DECL_ARG_TYPE' is `int'. 11038 11039`DEBUG_EXPR_DECL' 11040 Used to represent an anonymous debug-information temporary created 11041 to hold an expression as it is optimized away, so that its value 11042 can be referenced in debug bind statements. 11043 11044`FIELD_DECL' 11045 These nodes represent non-static data members. The `DECL_SIZE' and 11046 `DECL_ALIGN' behave as for `VAR_DECL' nodes. The position of the 11047 field within the parent record is specified by a combination of 11048 three attributes. `DECL_FIELD_OFFSET' is the position, counting 11049 in bytes, of the `DECL_OFFSET_ALIGN'-bit sized word containing the 11050 bit of the field closest to the beginning of the structure. 11051 `DECL_FIELD_BIT_OFFSET' is the bit offset of the first bit of the 11052 field within this word; this may be nonzero even for fields that 11053 are not bit-fields, since `DECL_OFFSET_ALIGN' may be greater than 11054 the natural alignment of the field's type. 11055 11056 If `DECL_C_BIT_FIELD' holds, this field is a bit-field. In a 11057 bit-field, `DECL_BIT_FIELD_TYPE' also contains the type that was 11058 originally specified for it, while DECL_TYPE may be a modified 11059 type with lesser precision, according to the size of the bit field. 11060 11061`NAMESPACE_DECL' 11062 Namespaces provide a name hierarchy for other declarations. They 11063 appear in the `DECL_CONTEXT' of other `_DECL' nodes. 11064 11065 11066 11067File: gccint.info, Node: Internal structure, Prev: Working with declarations, Up: Declarations 11068 1106911.4.2 Internal structure 11070------------------------- 11071 11072`DECL' nodes are represented internally as a hierarchy of structures. 11073 11074* Menu: 11075 11076* Current structure hierarchy:: The current DECL node structure 11077hierarchy. 11078* Adding new DECL node types:: How to add a new DECL node to a 11079frontend. 11080 11081 11082File: gccint.info, Node: Current structure hierarchy, Next: Adding new DECL node types, Up: Internal structure 11083 1108411.4.2.1 Current structure hierarchy 11085.................................... 11086 11087`struct tree_decl_minimal' 11088 This is the minimal structure to inherit from in order for common 11089 `DECL' macros to work. The fields it contains are a unique ID, 11090 source location, context, and name. 11091 11092`struct tree_decl_common' 11093 This structure inherits from `struct tree_decl_minimal'. It 11094 contains fields that most `DECL' nodes need, such as a field to 11095 store alignment, machine mode, size, and attributes. 11096 11097`struct tree_field_decl' 11098 This structure inherits from `struct tree_decl_common'. It is 11099 used to represent `FIELD_DECL'. 11100 11101`struct tree_label_decl' 11102 This structure inherits from `struct tree_decl_common'. It is 11103 used to represent `LABEL_DECL'. 11104 11105`struct tree_translation_unit_decl' 11106 This structure inherits from `struct tree_decl_common'. It is 11107 used to represent `TRANSLATION_UNIT_DECL'. 11108 11109`struct tree_decl_with_rtl' 11110 This structure inherits from `struct tree_decl_common'. It 11111 contains a field to store the low-level RTL associated with a 11112 `DECL' node. 11113 11114`struct tree_result_decl' 11115 This structure inherits from `struct tree_decl_with_rtl'. It is 11116 used to represent `RESULT_DECL'. 11117 11118`struct tree_const_decl' 11119 This structure inherits from `struct tree_decl_with_rtl'. It is 11120 used to represent `CONST_DECL'. 11121 11122`struct tree_parm_decl' 11123 This structure inherits from `struct tree_decl_with_rtl'. It is 11124 used to represent `PARM_DECL'. 11125 11126`struct tree_decl_with_vis' 11127 This structure inherits from `struct tree_decl_with_rtl'. It 11128 contains fields necessary to store visibility information, as well 11129 as a section name and assembler name. 11130 11131`struct tree_var_decl' 11132 This structure inherits from `struct tree_decl_with_vis'. It is 11133 used to represent `VAR_DECL'. 11134 11135`struct tree_function_decl' 11136 This structure inherits from `struct tree_decl_with_vis'. It is 11137 used to represent `FUNCTION_DECL'. 11138 11139 11140 11141File: gccint.info, Node: Adding new DECL node types, Prev: Current structure hierarchy, Up: Internal structure 11142 1114311.4.2.2 Adding new DECL node types 11144................................... 11145 11146Adding a new `DECL' tree consists of the following steps 11147 11148Add a new tree code for the `DECL' node 11149 For language specific `DECL' nodes, there is a `.def' file in each 11150 frontend directory where the tree code should be added. For 11151 `DECL' nodes that are part of the middle-end, the code should be 11152 added to `tree.def'. 11153 11154Create a new structure type for the `DECL' node 11155 These structures should inherit from one of the existing 11156 structures in the language hierarchy by using that structure as 11157 the first member. 11158 11159 struct tree_foo_decl 11160 { 11161 struct tree_decl_with_vis common; 11162 } 11163 11164 Would create a structure name `tree_foo_decl' that inherits from 11165 `struct tree_decl_with_vis'. 11166 11167 For language specific `DECL' nodes, this new structure type should 11168 go in the appropriate `.h' file. For `DECL' nodes that are part 11169 of the middle-end, the structure type should go in `tree.h'. 11170 11171Add a member to the tree structure enumerator for the node 11172 For garbage collection and dynamic checking purposes, each `DECL' 11173 node structure type is required to have a unique enumerator value 11174 specified with it. For language specific `DECL' nodes, this new 11175 enumerator value should go in the appropriate `.def' file. For 11176 `DECL' nodes that are part of the middle-end, the enumerator 11177 values are specified in `treestruct.def'. 11178 11179Update `union tree_node' 11180 In order to make your new structure type usable, it must be added 11181 to `union tree_node'. For language specific `DECL' nodes, a new 11182 entry should be added to the appropriate `.h' file of the form 11183 struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl; 11184 For `DECL' nodes that are part of the middle-end, the additional 11185 member goes directly into `union tree_node' in `tree.h'. 11186 11187Update dynamic checking info 11188 In order to be able to check whether accessing a named portion of 11189 `union tree_node' is legal, and whether a certain `DECL' node 11190 contains one of the enumerated `DECL' node structures in the 11191 hierarchy, a simple lookup table is used. This lookup table needs 11192 to be kept up to date with the tree structure hierarchy, or else 11193 checking and containment macros will fail inappropriately. 11194 11195 For language specific `DECL' nodes, their is an `init_ts' function 11196 in an appropriate `.c' file, which initializes the lookup table. 11197 Code setting up the table for new `DECL' nodes should be added 11198 there. For each `DECL' tree code and enumerator value 11199 representing a member of the inheritance hierarchy, the table 11200 should contain 1 if that tree code inherits (directly or 11201 indirectly) from that member. Thus, a `FOO_DECL' node derived 11202 from `struct decl_with_rtl', and enumerator value `TS_FOO_DECL', 11203 would be set up as follows 11204 tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1; 11205 tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1; 11206 tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1; 11207 tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1; 11208 11209 For `DECL' nodes that are part of the middle-end, the setup code 11210 goes into `tree.c'. 11211 11212Add macros to access any new fields and flags 11213 Each added field or flag should have a macro that is used to access 11214 it, that performs appropriate checking to ensure only the right 11215 type of `DECL' nodes access the field. 11216 11217 These macros generally take the following form 11218 #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname 11219 However, if the structure is simply a base class for further 11220 structures, something like the following should be used 11221 #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT) 11222 #define BASE_STRUCT_FIELDNAME(NODE) \ 11223 (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname 11224 11225 11226 11227File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: GENERIC 11228 1122911.5 Attributes in trees 11230======================== 11231 11232Attributes, as specified using the `__attribute__' keyword, are 11233represented internally as a `TREE_LIST'. The `TREE_PURPOSE' is the 11234name of the attribute, as an `IDENTIFIER_NODE'. The `TREE_VALUE' is a 11235`TREE_LIST' of the arguments of the attribute, if any, or `NULL_TREE' 11236if there are no arguments; the arguments are stored as the `TREE_VALUE' 11237of successive entries in the list, and may be identifiers or 11238expressions. The `TREE_CHAIN' of the attribute is the next attribute 11239in a list of attributes applying to the same declaration or type, or 11240`NULL_TREE' if there are no further attributes in the list. 11241 11242 Attributes may be attached to declarations and to types; these 11243attributes may be accessed with the following macros. All attributes 11244are stored in this way, and many also cause other changes to the 11245declaration or type or to other internal compiler data structures. 11246 11247 -- Tree Macro: tree DECL_ATTRIBUTES (tree DECL) 11248 This macro returns the attributes on the declaration DECL. 11249 11250 -- Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE) 11251 This macro returns the attributes on the type TYPE. 11252 11253 11254File: gccint.info, Node: Expression trees, Next: Statements, Prev: Attributes, Up: GENERIC 11255 1125611.6 Expressions 11257================ 11258 11259The internal representation for expressions is for the most part quite 11260straightforward. However, there are a few facts that one must bear in 11261mind. In particular, the expression "tree" is actually a directed 11262acyclic graph. (For example there may be many references to the integer 11263constant zero throughout the source program; many of these will be 11264represented by the same expression node.) You should not rely on 11265certain kinds of node being shared, nor should you rely on certain 11266kinds of nodes being unshared. 11267 11268 The following macros can be used with all expression nodes: 11269 11270`TREE_TYPE' 11271 Returns the type of the expression. This value may not be 11272 precisely the same type that would be given the expression in the 11273 original program. 11274 11275 In what follows, some nodes that one might expect to always have type 11276`bool' are documented to have either integral or boolean type. At some 11277point in the future, the C front end may also make use of this same 11278intermediate representation, and at this point these nodes will 11279certainly have integral type. The previous sentence is not meant to 11280imply that the C++ front end does not or will not give these nodes 11281integral type. 11282 11283 Below, we list the various kinds of expression nodes. Except where 11284noted otherwise, the operands to an expression are accessed using the 11285`TREE_OPERAND' macro. For example, to access the first operand to a 11286binary plus expression `expr', use: 11287 11288 TREE_OPERAND (expr, 0) 11289 As this example indicates, the operands are zero-indexed. 11290 11291* Menu: 11292 11293* Constants: Constant expressions. 11294* Storage References:: 11295* Unary and Binary Expressions:: 11296* Vectors:: 11297 11298 11299File: gccint.info, Node: Constant expressions, Next: Storage References, Up: Expression trees 11300 1130111.6.1 Constant expressions 11302--------------------------- 11303 11304The table below begins with constants, moves on to unary expressions, 11305then proceeds to binary expressions, and concludes with various other 11306kinds of expressions: 11307 11308`INTEGER_CST' 11309 These nodes represent integer constants. Note that the type of 11310 these constants is obtained with `TREE_TYPE'; they are not always 11311 of type `int'. In particular, `char' constants are represented 11312 with `INTEGER_CST' nodes. The value of the integer constant `e' is 11313 given by 11314 ((TREE_INT_CST_HIGH (e) << HOST_BITS_PER_WIDE_INT) 11315 + TREE_INST_CST_LOW (e)) 11316 HOST_BITS_PER_WIDE_INT is at least thirty-two on all platforms. 11317 Both `TREE_INT_CST_HIGH' and `TREE_INT_CST_LOW' return a 11318 `HOST_WIDE_INT'. The value of an `INTEGER_CST' is interpreted as 11319 a signed or unsigned quantity depending on the type of the 11320 constant. In general, the expression given above will overflow, 11321 so it should not be used to calculate the value of the constant. 11322 11323 The variable `integer_zero_node' is an integer constant with value 11324 zero. Similarly, `integer_one_node' is an integer constant with 11325 value one. The `size_zero_node' and `size_one_node' variables are 11326 analogous, but have type `size_t' rather than `int'. 11327 11328 The function `tree_int_cst_lt' is a predicate which holds if its 11329 first argument is less than its second. Both constants are 11330 assumed to have the same signedness (i.e., either both should be 11331 signed or both should be unsigned.) The full width of the 11332 constant is used when doing the comparison; the usual rules about 11333 promotions and conversions are ignored. Similarly, 11334 `tree_int_cst_equal' holds if the two constants are equal. The 11335 `tree_int_cst_sgn' function returns the sign of a constant. The 11336 value is `1', `0', or `-1' according on whether the constant is 11337 greater than, equal to, or less than zero. Again, the signedness 11338 of the constant's type is taken into account; an unsigned constant 11339 is never less than zero, no matter what its bit-pattern. 11340 11341`REAL_CST' 11342 FIXME: Talk about how to obtain representations of this constant, 11343 do comparisons, and so forth. 11344 11345`FIXED_CST' 11346 These nodes represent fixed-point constants. The type of these 11347 constants is obtained with `TREE_TYPE'. `TREE_FIXED_CST_PTR' 11348 points to a `struct fixed_value'; `TREE_FIXED_CST' returns the 11349 structure itself. `struct fixed_value' contains `data' with the 11350 size of two `HOST_BITS_PER_WIDE_INT' and `mode' as the associated 11351 fixed-point machine mode for `data'. 11352 11353`COMPLEX_CST' 11354 These nodes are used to represent complex number constants, that 11355 is a `__complex__' whose parts are constant nodes. The 11356 `TREE_REALPART' and `TREE_IMAGPART' return the real and the 11357 imaginary parts respectively. 11358 11359`VECTOR_CST' 11360 These nodes are used to represent vector constants, whose parts are 11361 constant nodes. Each individual constant node is either an 11362 integer or a double constant node. The first operand is a 11363 `TREE_LIST' of the constant nodes and is accessed through 11364 `TREE_VECTOR_CST_ELTS'. 11365 11366`STRING_CST' 11367 These nodes represent string-constants. The `TREE_STRING_LENGTH' 11368 returns the length of the string, as an `int'. The 11369 `TREE_STRING_POINTER' is a `char*' containing the string itself. 11370 The string may not be `NUL'-terminated, and it may contain 11371 embedded `NUL' characters. Therefore, the `TREE_STRING_LENGTH' 11372 includes the trailing `NUL' if it is present. 11373 11374 For wide string constants, the `TREE_STRING_LENGTH' is the number 11375 of bytes in the string, and the `TREE_STRING_POINTER' points to an 11376 array of the bytes of the string, as represented on the target 11377 system (that is, as integers in the target endianness). Wide and 11378 non-wide string constants are distinguished only by the `TREE_TYPE' 11379 of the `STRING_CST'. 11380 11381 FIXME: The formats of string constants are not well-defined when 11382 the target system bytes are not the same width as host system 11383 bytes. 11384 11385 11386 11387File: gccint.info, Node: Storage References, Next: Unary and Binary Expressions, Prev: Constant expressions, Up: Expression trees 11388 1138911.6.2 References to storage 11390---------------------------- 11391 11392`ARRAY_REF' 11393 These nodes represent array accesses. The first operand is the 11394 array; the second is the index. To calculate the address of the 11395 memory accessed, you must scale the index by the size of the type 11396 of the array elements. The type of these expressions must be the 11397 type of a component of the array. The third and fourth operands 11398 are used after gimplification to represent the lower bound and 11399 component size but should not be used directly; call 11400 `array_ref_low_bound' and `array_ref_element_size' instead. 11401 11402`ARRAY_RANGE_REF' 11403 These nodes represent access to a range (or "slice") of an array. 11404 The operands are the same as that for `ARRAY_REF' and have the same 11405 meanings. The type of these expressions must be an array whose 11406 component type is the same as that of the first operand. The 11407 range of that array type determines the amount of data these 11408 expressions access. 11409 11410`TARGET_MEM_REF' 11411 These nodes represent memory accesses whose address directly map to 11412 an addressing mode of the target architecture. The first argument 11413 is `TMR_SYMBOL' and must be a `VAR_DECL' of an object with a fixed 11414 address. The second argument is `TMR_BASE' and the third one is 11415 `TMR_INDEX'. The fourth argument is `TMR_STEP' and must be an 11416 `INTEGER_CST'. The fifth argument is `TMR_OFFSET' and must be an 11417 `INTEGER_CST'. Any of the arguments may be NULL if the 11418 appropriate component does not appear in the address. Address of 11419 the `TARGET_MEM_REF' is determined in the following way. 11420 11421 &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET 11422 11423 The sixth argument is the reference to the original memory access, 11424 which is preserved for the purposes of the RTL alias analysis. 11425 The seventh argument is a tag representing the results of tree 11426 level alias analysis. 11427 11428`ADDR_EXPR' 11429 These nodes are used to represent the address of an object. (These 11430 expressions will always have pointer or reference type.) The 11431 operand may be another expression, or it may be a declaration. 11432 11433 As an extension, GCC allows users to take the address of a label. 11434 In this case, the operand of the `ADDR_EXPR' will be a 11435 `LABEL_DECL'. The type of such an expression is `void*'. 11436 11437 If the object addressed is not an lvalue, a temporary is created, 11438 and the address of the temporary is used. 11439 11440`INDIRECT_REF' 11441 These nodes are used to represent the object pointed to by a 11442 pointer. The operand is the pointer being dereferenced; it will 11443 always have pointer or reference type. 11444 11445`COMPONENT_REF' 11446 These nodes represent non-static data member accesses. The first 11447 operand is the object (rather than a pointer to it); the second 11448 operand is the `FIELD_DECL' for the data member. The third 11449 operand represents the byte offset of the field, but should not be 11450 used directly; call `component_ref_field_offset' instead. 11451 11452 11453 11454File: gccint.info, Node: Unary and Binary Expressions, Next: Vectors, Prev: Storage References, Up: Expression trees 11455 1145611.6.3 Unary and Binary Expressions 11457----------------------------------- 11458 11459`NEGATE_EXPR' 11460 These nodes represent unary negation of the single operand, for 11461 both integer and floating-point types. The type of negation can be 11462 determined by looking at the type of the expression. 11463 11464 The behavior of this operation on signed arithmetic overflow is 11465 controlled by the `flag_wrapv' and `flag_trapv' variables. 11466 11467`ABS_EXPR' 11468 These nodes represent the absolute value of the single operand, for 11469 both integer and floating-point types. This is typically used to 11470 implement the `abs', `labs' and `llabs' builtins for integer 11471 types, and the `fabs', `fabsf' and `fabsl' builtins for floating 11472 point types. The type of abs operation can be determined by 11473 looking at the type of the expression. 11474 11475 This node is not used for complex types. To represent the modulus 11476 or complex abs of a complex value, use the `BUILT_IN_CABS', 11477 `BUILT_IN_CABSF' or `BUILT_IN_CABSL' builtins, as used to 11478 implement the C99 `cabs', `cabsf' and `cabsl' built-in functions. 11479 11480`BIT_NOT_EXPR' 11481 These nodes represent bitwise complement, and will always have 11482 integral type. The only operand is the value to be complemented. 11483 11484`TRUTH_NOT_EXPR' 11485 These nodes represent logical negation, and will always have 11486 integral (or boolean) type. The operand is the value being 11487 negated. The type of the operand and that of the result are 11488 always of `BOOLEAN_TYPE' or `INTEGER_TYPE'. 11489 11490`PREDECREMENT_EXPR' 11491`PREINCREMENT_EXPR' 11492`POSTDECREMENT_EXPR' 11493`POSTINCREMENT_EXPR' 11494 These nodes represent increment and decrement expressions. The 11495 value of the single operand is computed, and the operand 11496 incremented or decremented. In the case of `PREDECREMENT_EXPR' and 11497 `PREINCREMENT_EXPR', the value of the expression is the value 11498 resulting after the increment or decrement; in the case of 11499 `POSTDECREMENT_EXPR' and `POSTINCREMENT_EXPR' is the value before 11500 the increment or decrement occurs. The type of the operand, like 11501 that of the result, will be either integral, boolean, or 11502 floating-point. 11503 11504`FIX_TRUNC_EXPR' 11505 These nodes represent conversion of a floating-point value to an 11506 integer. The single operand will have a floating-point type, while 11507 the complete expression will have an integral (or boolean) type. 11508 The operand is rounded towards zero. 11509 11510`FLOAT_EXPR' 11511 These nodes represent conversion of an integral (or boolean) value 11512 to a floating-point value. The single operand will have integral 11513 type, while the complete expression will have a floating-point 11514 type. 11515 11516 FIXME: How is the operand supposed to be rounded? Is this 11517 dependent on `-mieee'? 11518 11519`COMPLEX_EXPR' 11520 These nodes are used to represent complex numbers constructed from 11521 two expressions of the same (integer or real) type. The first 11522 operand is the real part and the second operand is the imaginary 11523 part. 11524 11525`CONJ_EXPR' 11526 These nodes represent the conjugate of their operand. 11527 11528`REALPART_EXPR' 11529`IMAGPART_EXPR' 11530 These nodes represent respectively the real and the imaginary parts 11531 of complex numbers (their sole argument). 11532 11533`NON_LVALUE_EXPR' 11534 These nodes indicate that their one and only operand is not an 11535 lvalue. A back end can treat these identically to the single 11536 operand. 11537 11538`NOP_EXPR' 11539 These nodes are used to represent conversions that do not require 11540 any code-generation. For example, conversion of a `char*' to an 11541 `int*' does not require any code be generated; such a conversion is 11542 represented by a `NOP_EXPR'. The single operand is the expression 11543 to be converted. The conversion from a pointer to a reference is 11544 also represented with a `NOP_EXPR'. 11545 11546`CONVERT_EXPR' 11547 These nodes are similar to `NOP_EXPR's, but are used in those 11548 situations where code may need to be generated. For example, if an 11549 `int*' is converted to an `int' code may need to be generated on 11550 some platforms. These nodes are never used for C++-specific 11551 conversions, like conversions between pointers to different 11552 classes in an inheritance hierarchy. Any adjustments that need to 11553 be made in such cases are always indicated explicitly. Similarly, 11554 a user-defined conversion is never represented by a 11555 `CONVERT_EXPR'; instead, the function calls are made explicit. 11556 11557`FIXED_CONVERT_EXPR' 11558 These nodes are used to represent conversions that involve 11559 fixed-point values. For example, from a fixed-point value to 11560 another fixed-point value, from an integer to a fixed-point value, 11561 from a fixed-point value to an integer, from a floating-point 11562 value to a fixed-point value, or from a fixed-point value to a 11563 floating-point value. 11564 11565`LSHIFT_EXPR' 11566`RSHIFT_EXPR' 11567 These nodes represent left and right shifts, respectively. The 11568 first operand is the value to shift; it will always be of integral 11569 type. The second operand is an expression for the number of bits 11570 by which to shift. Right shift should be treated as arithmetic, 11571 i.e., the high-order bits should be zero-filled when the 11572 expression has unsigned type and filled with the sign bit when the 11573 expression has signed type. Note that the result is undefined if 11574 the second operand is larger than or equal to the first operand's 11575 type size. 11576 11577`BIT_IOR_EXPR' 11578`BIT_XOR_EXPR' 11579`BIT_AND_EXPR' 11580 These nodes represent bitwise inclusive or, bitwise exclusive or, 11581 and bitwise and, respectively. Both operands will always have 11582 integral type. 11583 11584`TRUTH_ANDIF_EXPR' 11585`TRUTH_ORIF_EXPR' 11586 These nodes represent logical "and" and logical "or", respectively. 11587 These operators are not strict; i.e., the second operand is 11588 evaluated only if the value of the expression is not determined by 11589 evaluation of the first operand. The type of the operands and 11590 that of the result are always of `BOOLEAN_TYPE' or `INTEGER_TYPE'. 11591 11592`TRUTH_AND_EXPR' 11593`TRUTH_OR_EXPR' 11594`TRUTH_XOR_EXPR' 11595 These nodes represent logical and, logical or, and logical 11596 exclusive or. They are strict; both arguments are always 11597 evaluated. There are no corresponding operators in C or C++, but 11598 the front end will sometimes generate these expressions anyhow, if 11599 it can tell that strictness does not matter. The type of the 11600 operands and that of the result are always of `BOOLEAN_TYPE' or 11601 `INTEGER_TYPE'. 11602 11603`POINTER_PLUS_EXPR' 11604 This node represents pointer arithmetic. The first operand is 11605 always a pointer/reference type. The second operand is always an 11606 unsigned integer type compatible with sizetype. This is the only 11607 binary arithmetic operand that can operate on pointer types. 11608 11609`PLUS_EXPR' 11610`MINUS_EXPR' 11611`MULT_EXPR' 11612 These nodes represent various binary arithmetic operations. 11613 Respectively, these operations are addition, subtraction (of the 11614 second operand from the first) and multiplication. Their operands 11615 may have either integral or floating type, but there will never be 11616 case in which one operand is of floating type and the other is of 11617 integral type. 11618 11619 The behavior of these operations on signed arithmetic overflow is 11620 controlled by the `flag_wrapv' and `flag_trapv' variables. 11621 11622`RDIV_EXPR' 11623 This node represents a floating point division operation. 11624 11625`TRUNC_DIV_EXPR' 11626`FLOOR_DIV_EXPR' 11627`CEIL_DIV_EXPR' 11628`ROUND_DIV_EXPR' 11629 These nodes represent integer division operations that return an 11630 integer result. `TRUNC_DIV_EXPR' rounds towards zero, 11631 `FLOOR_DIV_EXPR' rounds towards negative infinity, `CEIL_DIV_EXPR' 11632 rounds towards positive infinity and `ROUND_DIV_EXPR' rounds to 11633 the closest integer. Integer division in C and C++ is truncating, 11634 i.e. `TRUNC_DIV_EXPR'. 11635 11636 The behavior of these operations on signed arithmetic overflow, 11637 when dividing the minimum signed integer by minus one, is 11638 controlled by the `flag_wrapv' and `flag_trapv' variables. 11639 11640`TRUNC_MOD_EXPR' 11641`FLOOR_MOD_EXPR' 11642`CEIL_MOD_EXPR' 11643`ROUND_MOD_EXPR' 11644 These nodes represent the integer remainder or modulus operation. 11645 The integer modulus of two operands `a' and `b' is defined as `a - 11646 (a/b)*b' where the division calculated using the corresponding 11647 division operator. Hence for `TRUNC_MOD_EXPR' this definition 11648 assumes division using truncation towards zero, i.e. 11649 `TRUNC_DIV_EXPR'. Integer remainder in C and C++ uses truncating 11650 division, i.e. `TRUNC_MOD_EXPR'. 11651 11652`EXACT_DIV_EXPR' 11653 The `EXACT_DIV_EXPR' code is used to represent integer divisions 11654 where the numerator is known to be an exact multiple of the 11655 denominator. This allows the backend to choose between the faster 11656 of `TRUNC_DIV_EXPR', `CEIL_DIV_EXPR' and `FLOOR_DIV_EXPR' for the 11657 current target. 11658 11659`LT_EXPR' 11660`LE_EXPR' 11661`GT_EXPR' 11662`GE_EXPR' 11663`EQ_EXPR' 11664`NE_EXPR' 11665 These nodes represent the less than, less than or equal to, greater 11666 than, greater than or equal to, equal, and not equal comparison 11667 operators. The first and second operand with either be both of 11668 integral type or both of floating type. The result type of these 11669 expressions will always be of integral or boolean type. These 11670 operations return the result type's zero value for false, and the 11671 result type's one value for true. 11672 11673 For floating point comparisons, if we honor IEEE NaNs and either 11674 operand is NaN, then `NE_EXPR' always returns true and the 11675 remaining operators always return false. On some targets, 11676 comparisons against an IEEE NaN, other than equality and 11677 inequality, may generate a floating point exception. 11678 11679`ORDERED_EXPR' 11680`UNORDERED_EXPR' 11681 These nodes represent non-trapping ordered and unordered comparison 11682 operators. These operations take two floating point operands and 11683 determine whether they are ordered or unordered relative to each 11684 other. If either operand is an IEEE NaN, their comparison is 11685 defined to be unordered, otherwise the comparison is defined to be 11686 ordered. The result type of these expressions will always be of 11687 integral or boolean type. These operations return the result 11688 type's zero value for false, and the result type's one value for 11689 true. 11690 11691`UNLT_EXPR' 11692`UNLE_EXPR' 11693`UNGT_EXPR' 11694`UNGE_EXPR' 11695`UNEQ_EXPR' 11696`LTGT_EXPR' 11697 These nodes represent the unordered comparison operators. These 11698 operations take two floating point operands and determine whether 11699 the operands are unordered or are less than, less than or equal to, 11700 greater than, greater than or equal to, or equal respectively. For 11701 example, `UNLT_EXPR' returns true if either operand is an IEEE NaN 11702 or the first operand is less than the second. With the possible 11703 exception of `LTGT_EXPR', all of these operations are guaranteed 11704 not to generate a floating point exception. The result type of 11705 these expressions will always be of integral or boolean type. 11706 These operations return the result type's zero value for false, 11707 and the result type's one value for true. 11708 11709`MODIFY_EXPR' 11710 These nodes represent assignment. The left-hand side is the first 11711 operand; the right-hand side is the second operand. The left-hand 11712 side will be a `VAR_DECL', `INDIRECT_REF', `COMPONENT_REF', or 11713 other lvalue. 11714 11715 These nodes are used to represent not only assignment with `=' but 11716 also compound assignments (like `+='), by reduction to `=' 11717 assignment. In other words, the representation for `i += 3' looks 11718 just like that for `i = i + 3'. 11719 11720`INIT_EXPR' 11721 These nodes are just like `MODIFY_EXPR', but are used only when a 11722 variable is initialized, rather than assigned to subsequently. 11723 This means that we can assume that the target of the 11724 initialization is not used in computing its own value; any 11725 reference to the lhs in computing the rhs is undefined. 11726 11727`COMPOUND_EXPR' 11728 These nodes represent comma-expressions. The first operand is an 11729 expression whose value is computed and thrown away prior to the 11730 evaluation of the second operand. The value of the entire 11731 expression is the value of the second operand. 11732 11733`COND_EXPR' 11734 These nodes represent `?:' expressions. The first operand is of 11735 boolean or integral type. If it evaluates to a nonzero value, the 11736 second operand should be evaluated, and returned as the value of 11737 the expression. Otherwise, the third operand is evaluated, and 11738 returned as the value of the expression. 11739 11740 The second operand must have the same type as the entire 11741 expression, unless it unconditionally throws an exception or calls 11742 a noreturn function, in which case it should have void type. The 11743 same constraints apply to the third operand. This allows array 11744 bounds checks to be represented conveniently as `(i >= 0 && i < 11745 10) ? i : abort()'. 11746 11747 As a GNU extension, the C language front-ends allow the second 11748 operand of the `?:' operator may be omitted in the source. For 11749 example, `x ? : 3' is equivalent to `x ? x : 3', assuming that `x' 11750 is an expression without side-effects. In the tree 11751 representation, however, the second operand is always present, 11752 possibly protected by `SAVE_EXPR' if the first argument does cause 11753 side-effects. 11754 11755`CALL_EXPR' 11756 These nodes are used to represent calls to functions, including 11757 non-static member functions. `CALL_EXPR's are implemented as 11758 expression nodes with a variable number of operands. Rather than 11759 using `TREE_OPERAND' to extract them, it is preferable to use the 11760 specialized accessor macros and functions that operate 11761 specifically on `CALL_EXPR' nodes. 11762 11763 `CALL_EXPR_FN' returns a pointer to the function to call; it is 11764 always an expression whose type is a `POINTER_TYPE'. 11765 11766 The number of arguments to the call is returned by 11767 `call_expr_nargs', while the arguments themselves can be accessed 11768 with the `CALL_EXPR_ARG' macro. The arguments are zero-indexed 11769 and numbered left-to-right. You can iterate over the arguments 11770 using `FOR_EACH_CALL_EXPR_ARG', as in: 11771 11772 tree call, arg; 11773 call_expr_arg_iterator iter; 11774 FOR_EACH_CALL_EXPR_ARG (arg, iter, call) 11775 /* arg is bound to successive arguments of call. */ 11776 ...; 11777 11778 For non-static member functions, there will be an operand 11779 corresponding to the `this' pointer. There will always be 11780 expressions corresponding to all of the arguments, even if the 11781 function is declared with default arguments and some arguments are 11782 not explicitly provided at the call sites. 11783 11784 `CALL_EXPR's also have a `CALL_EXPR_STATIC_CHAIN' operand that is 11785 used to implement nested functions. This operand is otherwise 11786 null. 11787 11788`CLEANUP_POINT_EXPR' 11789 These nodes represent full-expressions. The single operand is an 11790 expression to evaluate. Any destructor calls engendered by the 11791 creation of temporaries during the evaluation of that expression 11792 should be performed immediately after the expression is evaluated. 11793 11794`CONSTRUCTOR' 11795 These nodes represent the brace-enclosed initializers for a 11796 structure or array. The first operand is reserved for use by the 11797 back end. The second operand is a `TREE_LIST'. If the 11798 `TREE_TYPE' of the `CONSTRUCTOR' is a `RECORD_TYPE' or 11799 `UNION_TYPE', then the `TREE_PURPOSE' of each node in the 11800 `TREE_LIST' will be a `FIELD_DECL' and the `TREE_VALUE' of each 11801 node will be the expression used to initialize that field. 11802 11803 If the `TREE_TYPE' of the `CONSTRUCTOR' is an `ARRAY_TYPE', then 11804 the `TREE_PURPOSE' of each element in the `TREE_LIST' will be an 11805 `INTEGER_CST' or a `RANGE_EXPR' of two `INTEGER_CST's. A single 11806 `INTEGER_CST' indicates which element of the array (indexed from 11807 zero) is being assigned to. A `RANGE_EXPR' indicates an inclusive 11808 range of elements to initialize. In both cases the `TREE_VALUE' 11809 is the corresponding initializer. It is re-evaluated for each 11810 element of a `RANGE_EXPR'. If the `TREE_PURPOSE' is `NULL_TREE', 11811 then the initializer is for the next available array element. 11812 11813 In the front end, you should not depend on the fields appearing in 11814 any particular order. However, in the middle end, fields must 11815 appear in declaration order. You should not assume that all 11816 fields will be represented. Unrepresented fields will be set to 11817 zero. 11818 11819`COMPOUND_LITERAL_EXPR' 11820 These nodes represent ISO C99 compound literals. The 11821 `COMPOUND_LITERAL_EXPR_DECL_EXPR' is a `DECL_EXPR' containing an 11822 anonymous `VAR_DECL' for the unnamed object represented by the 11823 compound literal; the `DECL_INITIAL' of that `VAR_DECL' is a 11824 `CONSTRUCTOR' representing the brace-enclosed list of initializers 11825 in the compound literal. That anonymous `VAR_DECL' can also be 11826 accessed directly by the `COMPOUND_LITERAL_EXPR_DECL' macro. 11827 11828`SAVE_EXPR' 11829 A `SAVE_EXPR' represents an expression (possibly involving 11830 side-effects) that is used more than once. The side-effects should 11831 occur only the first time the expression is evaluated. Subsequent 11832 uses should just reuse the computed value. The first operand to 11833 the `SAVE_EXPR' is the expression to evaluate. The side-effects 11834 should be executed where the `SAVE_EXPR' is first encountered in a 11835 depth-first preorder traversal of the expression tree. 11836 11837`TARGET_EXPR' 11838 A `TARGET_EXPR' represents a temporary object. The first operand 11839 is a `VAR_DECL' for the temporary variable. The second operand is 11840 the initializer for the temporary. The initializer is evaluated 11841 and, if non-void, copied (bitwise) into the temporary. If the 11842 initializer is void, that means that it will perform the 11843 initialization itself. 11844 11845 Often, a `TARGET_EXPR' occurs on the right-hand side of an 11846 assignment, or as the second operand to a comma-expression which is 11847 itself the right-hand side of an assignment, etc. In this case, 11848 we say that the `TARGET_EXPR' is "normal"; otherwise, we say it is 11849 "orphaned". For a normal `TARGET_EXPR' the temporary variable 11850 should be treated as an alias for the left-hand side of the 11851 assignment, rather than as a new temporary variable. 11852 11853 The third operand to the `TARGET_EXPR', if present, is a 11854 cleanup-expression (i.e., destructor call) for the temporary. If 11855 this expression is orphaned, then this expression must be executed 11856 when the statement containing this expression is complete. These 11857 cleanups must always be executed in the order opposite to that in 11858 which they were encountered. Note that if a temporary is created 11859 on one branch of a conditional operator (i.e., in the second or 11860 third operand to a `COND_EXPR'), the cleanup must be run only if 11861 that branch is actually executed. 11862 11863`VA_ARG_EXPR' 11864 This node is used to implement support for the C/C++ variable 11865 argument-list mechanism. It represents expressions like `va_arg 11866 (ap, type)'. Its `TREE_TYPE' yields the tree representation for 11867 `type' and its sole argument yields the representation for `ap'. 11868 11869 11870 11871File: gccint.info, Node: Vectors, Prev: Unary and Binary Expressions, Up: Expression trees 11872 1187311.6.4 Vectors 11874-------------- 11875 11876`VEC_LSHIFT_EXPR' 11877`VEC_RSHIFT_EXPR' 11878 These nodes represent whole vector left and right shifts, 11879 respectively. The first operand is the vector to shift; it will 11880 always be of vector type. The second operand is an expression for 11881 the number of bits by which to shift. Note that the result is 11882 undefined if the second operand is larger than or equal to the 11883 first operand's type size. 11884 11885`VEC_WIDEN_MULT_HI_EXPR' 11886`VEC_WIDEN_MULT_LO_EXPR' 11887 These nodes represent widening vector multiplication of the high 11888 and low parts of the two input vectors, respectively. Their 11889 operands are vectors that contain the same number of elements 11890 (`N') of the same integral type. The result is a vector that 11891 contains half as many elements, of an integral type whose size is 11892 twice as wide. In the case of `VEC_WIDEN_MULT_HI_EXPR' the high 11893 `N/2' elements of the two vector are multiplied to produce the 11894 vector of `N/2' products. In the case of `VEC_WIDEN_MULT_LO_EXPR' 11895 the low `N/2' elements of the two vector are multiplied to produce 11896 the vector of `N/2' products. 11897 11898`VEC_UNPACK_HI_EXPR' 11899`VEC_UNPACK_LO_EXPR' 11900 These nodes represent unpacking of the high and low parts of the 11901 input vector, respectively. The single operand is a vector that 11902 contains `N' elements of the same integral or floating point type. 11903 The result is a vector that contains half as many elements, of an 11904 integral or floating point type whose size is twice as wide. In 11905 the case of `VEC_UNPACK_HI_EXPR' the high `N/2' elements of the 11906 vector are extracted and widened (promoted). In the case of 11907 `VEC_UNPACK_LO_EXPR' the low `N/2' elements of the vector are 11908 extracted and widened (promoted). 11909 11910`VEC_UNPACK_FLOAT_HI_EXPR' 11911`VEC_UNPACK_FLOAT_LO_EXPR' 11912 These nodes represent unpacking of the high and low parts of the 11913 input vector, where the values are converted from fixed point to 11914 floating point. The single operand is a vector that contains `N' 11915 elements of the same integral type. The result is a vector that 11916 contains half as many elements of a floating point type whose size 11917 is twice as wide. In the case of `VEC_UNPACK_HI_EXPR' the high 11918 `N/2' elements of the vector are extracted, converted and widened. 11919 In the case of `VEC_UNPACK_LO_EXPR' the low `N/2' elements of the 11920 vector are extracted, converted and widened. 11921 11922`VEC_PACK_TRUNC_EXPR' 11923 This node represents packing of truncated elements of the two 11924 input vectors into the output vector. Input operands are vectors 11925 that contain the same number of elements of the same integral or 11926 floating point type. The result is a vector that contains twice 11927 as many elements of an integral or floating point type whose size 11928 is half as wide. The elements of the two vectors are demoted and 11929 merged (concatenated) to form the output vector. 11930 11931`VEC_PACK_SAT_EXPR' 11932 This node represents packing of elements of the two input vectors 11933 into the output vector using saturation. Input operands are 11934 vectors that contain the same number of elements of the same 11935 integral type. The result is a vector that contains twice as many 11936 elements of an integral type whose size is half as wide. The 11937 elements of the two vectors are demoted and merged (concatenated) 11938 to form the output vector. 11939 11940`VEC_PACK_FIX_TRUNC_EXPR' 11941 This node represents packing of elements of the two input vectors 11942 into the output vector, where the values are converted from 11943 floating point to fixed point. Input operands are vectors that 11944 contain the same number of elements of a floating point type. The 11945 result is a vector that contains twice as many elements of an 11946 integral type whose size is half as wide. The elements of the two 11947 vectors are merged (concatenated) to form the output vector. 11948 11949`VEC_EXTRACT_EVEN_EXPR' 11950`VEC_EXTRACT_ODD_EXPR' 11951 These nodes represent extracting of the even/odd elements of the 11952 two input vectors, respectively. Their operands and result are 11953 vectors that contain the same number of elements of the same type. 11954 11955`VEC_INTERLEAVE_HIGH_EXPR' 11956`VEC_INTERLEAVE_LOW_EXPR' 11957 These nodes represent merging and interleaving of the high/low 11958 elements of the two input vectors, respectively. The operands and 11959 the result are vectors that contain the same number of elements 11960 (`N') of the same type. In the case of 11961 `VEC_INTERLEAVE_HIGH_EXPR', the high `N/2' elements of the first 11962 input vector are interleaved with the high `N/2' elements of the 11963 second input vector. In the case of `VEC_INTERLEAVE_LOW_EXPR', the 11964 low `N/2' elements of the first input vector are interleaved with 11965 the low `N/2' elements of the second input vector. 11966 11967 11968 11969File: gccint.info, Node: Statements, Next: Functions, Prev: Expression trees, Up: GENERIC 11970 1197111.7 Statements 11972=============== 11973 11974Most statements in GIMPLE are assignment statements, represented by 11975`GIMPLE_ASSIGN'. No other C expressions can appear at statement level; 11976a reference to a volatile object is converted into a `GIMPLE_ASSIGN'. 11977 11978 There are also several varieties of complex statements. 11979 11980* Menu: 11981 11982* Basic Statements:: 11983* Blocks:: 11984* Statement Sequences:: 11985* Empty Statements:: 11986* Jumps:: 11987* Cleanups:: 11988* OpenMP:: 11989 11990 11991File: gccint.info, Node: Basic Statements, Next: Blocks, Up: Statements 11992 1199311.7.1 Basic Statements 11994----------------------- 11995 11996`ASM_EXPR' 11997 Used to represent an inline assembly statement. For an inline 11998 assembly statement like: 11999 asm ("mov x, y"); 12000 The `ASM_STRING' macro will return a `STRING_CST' node for `"mov 12001 x, y"'. If the original statement made use of the 12002 extended-assembly syntax, then `ASM_OUTPUTS', `ASM_INPUTS', and 12003 `ASM_CLOBBERS' will be the outputs, inputs, and clobbers for the 12004 statement, represented as `STRING_CST' nodes. The 12005 extended-assembly syntax looks like: 12006 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); 12007 The first string is the `ASM_STRING', containing the instruction 12008 template. The next two strings are the output and inputs, 12009 respectively; this statement has no clobbers. As this example 12010 indicates, "plain" assembly statements are merely a special case 12011 of extended assembly statements; they have no cv-qualifiers, 12012 outputs, inputs, or clobbers. All of the strings will be 12013 `NUL'-terminated, and will contain no embedded `NUL'-characters. 12014 12015 If the assembly statement is declared `volatile', or if the 12016 statement was not an extended assembly statement, and is therefore 12017 implicitly volatile, then the predicate `ASM_VOLATILE_P' will hold 12018 of the `ASM_EXPR'. 12019 12020`DECL_EXPR' 12021 Used to represent a local declaration. The `DECL_EXPR_DECL' macro 12022 can be used to obtain the entity declared. This declaration may 12023 be a `LABEL_DECL', indicating that the label declared is a local 12024 label. (As an extension, GCC allows the declaration of labels 12025 with scope.) In C, this declaration may be a `FUNCTION_DECL', 12026 indicating the use of the GCC nested function extension. For more 12027 information, *note Functions::. 12028 12029`LABEL_EXPR' 12030 Used to represent a label. The `LABEL_DECL' declared by this 12031 statement can be obtained with the `LABEL_EXPR_LABEL' macro. The 12032 `IDENTIFIER_NODE' giving the name of the label can be obtained from 12033 the `LABEL_DECL' with `DECL_NAME'. 12034 12035`GOTO_EXPR' 12036 Used to represent a `goto' statement. The `GOTO_DESTINATION' will 12037 usually be a `LABEL_DECL'. However, if the "computed goto" 12038 extension has been used, the `GOTO_DESTINATION' will be an 12039 arbitrary expression indicating the destination. This expression 12040 will always have pointer type. 12041 12042`RETURN_EXPR' 12043 Used to represent a `return' statement. Operand 0 represents the 12044 value to return. It should either be the `RESULT_DECL' for the 12045 containing function, or a `MODIFY_EXPR' or `INIT_EXPR' setting the 12046 function's `RESULT_DECL'. It will be `NULL_TREE' if the statement 12047 was just 12048 return; 12049 12050`LOOP_EXPR' 12051 These nodes represent "infinite" loops. The `LOOP_EXPR_BODY' 12052 represents the body of the loop. It should be executed forever, 12053 unless an `EXIT_EXPR' is encountered. 12054 12055`EXIT_EXPR' 12056 These nodes represent conditional exits from the nearest enclosing 12057 `LOOP_EXPR'. The single operand is the condition; if it is 12058 nonzero, then the loop should be exited. An `EXIT_EXPR' will only 12059 appear within a `LOOP_EXPR'. 12060 12061`SWITCH_STMT' 12062 Used to represent a `switch' statement. The `SWITCH_STMT_COND' is 12063 the expression on which the switch is occurring. See the 12064 documentation for an `IF_STMT' for more information on the 12065 representation used for the condition. The `SWITCH_STMT_BODY' is 12066 the body of the switch statement. The `SWITCH_STMT_TYPE' is the 12067 original type of switch expression as given in the source, before 12068 any compiler conversions. 12069 12070`CASE_LABEL_EXPR' 12071 Use to represent a `case' label, range of `case' labels, or a 12072 `default' label. If `CASE_LOW' is `NULL_TREE', then this is a 12073 `default' label. Otherwise, if `CASE_HIGH' is `NULL_TREE', then 12074 this is an ordinary `case' label. In this case, `CASE_LOW' is an 12075 expression giving the value of the label. Both `CASE_LOW' and 12076 `CASE_HIGH' are `INTEGER_CST' nodes. These values will have the 12077 same type as the condition expression in the switch statement. 12078 12079 Otherwise, if both `CASE_LOW' and `CASE_HIGH' are defined, the 12080 statement is a range of case labels. Such statements originate 12081 with the extension that allows users to write things of the form: 12082 case 2 ... 5: 12083 The first value will be `CASE_LOW', while the second will be 12084 `CASE_HIGH'. 12085 12086 12087 12088File: gccint.info, Node: Blocks, Next: Statement Sequences, Prev: Basic Statements, Up: Statements 12089 1209011.7.2 Blocks 12091------------- 12092 12093Block scopes and the variables they declare in GENERIC are expressed 12094using the `BIND_EXPR' code, which in previous versions of GCC was 12095primarily used for the C statement-expression extension. 12096 12097 Variables in a block are collected into `BIND_EXPR_VARS' in 12098declaration order through their `TREE_CHAIN' field. Any runtime 12099initialization is moved out of `DECL_INITIAL' and into a statement in 12100the controlled block. When gimplifying from C or C++, this 12101initialization replaces the `DECL_STMT'. These variables will never 12102require cleanups. The scope of these variables is just the body 12103 12104 Variable-length arrays (VLAs) complicate this process, as their size 12105often refers to variables initialized earlier in the block. To handle 12106this, we currently split the block at that point, and move the VLA into 12107a new, inner `BIND_EXPR'. This strategy may change in the future. 12108 12109 A C++ program will usually contain more `BIND_EXPR's than there are 12110syntactic blocks in the source code, since several C++ constructs have 12111implicit scopes associated with them. On the other hand, although the 12112C++ front end uses pseudo-scopes to handle cleanups for objects with 12113destructors, these don't translate into the GIMPLE form; multiple 12114declarations at the same level use the same `BIND_EXPR'. 12115 12116 12117File: gccint.info, Node: Statement Sequences, Next: Empty Statements, Prev: Blocks, Up: Statements 12118 1211911.7.3 Statement Sequences 12120-------------------------- 12121 12122Multiple statements at the same nesting level are collected into a 12123`STATEMENT_LIST'. Statement lists are modified and traversed using the 12124interface in `tree-iterator.h'. 12125 12126 12127File: gccint.info, Node: Empty Statements, Next: Jumps, Prev: Statement Sequences, Up: Statements 12128 1212911.7.4 Empty Statements 12130----------------------- 12131 12132Whenever possible, statements with no effect are discarded. But if 12133they are nested within another construct which cannot be discarded for 12134some reason, they are instead replaced with an empty statement, 12135generated by `build_empty_stmt'. Initially, all empty statements were 12136shared, after the pattern of the Java front end, but this caused a lot 12137of trouble in practice. 12138 12139 An empty statement is represented as `(void)0'. 12140 12141 12142File: gccint.info, Node: Jumps, Next: Cleanups, Prev: Empty Statements, Up: Statements 12143 1214411.7.5 Jumps 12145------------ 12146 12147Other jumps are expressed by either `GOTO_EXPR' or `RETURN_EXPR'. 12148 12149 The operand of a `GOTO_EXPR' must be either a label or a variable 12150containing the address to jump to. 12151 12152 The operand of a `RETURN_EXPR' is either `NULL_TREE', `RESULT_DECL', 12153or a `MODIFY_EXPR' which sets the return value. It would be nice to 12154move the `MODIFY_EXPR' into a separate statement, but the special 12155return semantics in `expand_return' make that difficult. It may still 12156happen in the future, perhaps by moving most of that logic into 12157`expand_assignment'. 12158 12159 12160File: gccint.info, Node: Cleanups, Next: OpenMP, Prev: Jumps, Up: Statements 12161 1216211.7.6 Cleanups 12163--------------- 12164 12165Destructors for local C++ objects and similar dynamic cleanups are 12166represented in GIMPLE by a `TRY_FINALLY_EXPR'. `TRY_FINALLY_EXPR' has 12167two operands, both of which are a sequence of statements to execute. 12168The first sequence is executed. When it completes the second sequence 12169is executed. 12170 12171 The first sequence may complete in the following ways: 12172 12173 1. Execute the last statement in the sequence and fall off the end. 12174 12175 2. Execute a goto statement (`GOTO_EXPR') to an ordinary label 12176 outside the sequence. 12177 12178 3. Execute a return statement (`RETURN_EXPR'). 12179 12180 4. Throw an exception. This is currently not explicitly represented 12181 in GIMPLE. 12182 12183 12184 The second sequence is not executed if the first sequence completes by 12185calling `setjmp' or `exit' or any other function that does not return. 12186The second sequence is also not executed if the first sequence 12187completes via a non-local goto or a computed goto (in general the 12188compiler does not know whether such a goto statement exits the first 12189sequence or not, so we assume that it doesn't). 12190 12191 After the second sequence is executed, if it completes normally by 12192falling off the end, execution continues wherever the first sequence 12193would have continued, by falling off the end, or doing a goto, etc. 12194 12195 `TRY_FINALLY_EXPR' complicates the flow graph, since the cleanup needs 12196to appear on every edge out of the controlled block; this reduces the 12197freedom to move code across these edges. Therefore, the EH lowering 12198pass which runs before most of the optimization passes eliminates these 12199expressions by explicitly adding the cleanup to each edge. Rethrowing 12200the exception is represented using `RESX_EXPR'. 12201 12202 12203File: gccint.info, Node: OpenMP, Prev: Cleanups, Up: Statements 12204 1220511.7.7 OpenMP 12206------------- 12207 12208All the statements starting with `OMP_' represent directives and 12209clauses used by the OpenMP API `http://www.openmp.org/'. 12210 12211`OMP_PARALLEL' 12212 Represents `#pragma omp parallel [clause1 ... clauseN]'. It has 12213 four operands: 12214 12215 Operand `OMP_PARALLEL_BODY' is valid while in GENERIC and High 12216 GIMPLE forms. It contains the body of code to be executed by all 12217 the threads. During GIMPLE lowering, this operand becomes `NULL' 12218 and the body is emitted linearly after `OMP_PARALLEL'. 12219 12220 Operand `OMP_PARALLEL_CLAUSES' is the list of clauses associated 12221 with the directive. 12222 12223 Operand `OMP_PARALLEL_FN' is created by `pass_lower_omp', it 12224 contains the `FUNCTION_DECL' for the function that will contain 12225 the body of the parallel region. 12226 12227 Operand `OMP_PARALLEL_DATA_ARG' is also created by 12228 `pass_lower_omp'. If there are shared variables to be communicated 12229 to the children threads, this operand will contain the `VAR_DECL' 12230 that contains all the shared values and variables. 12231 12232`OMP_FOR' 12233 Represents `#pragma omp for [clause1 ... clauseN]'. It has 5 12234 operands: 12235 12236 Operand `OMP_FOR_BODY' contains the loop body. 12237 12238 Operand `OMP_FOR_CLAUSES' is the list of clauses associated with 12239 the directive. 12240 12241 Operand `OMP_FOR_INIT' is the loop initialization code of the form 12242 `VAR = N1'. 12243 12244 Operand `OMP_FOR_COND' is the loop conditional expression of the 12245 form `VAR {<,>,<=,>=} N2'. 12246 12247 Operand `OMP_FOR_INCR' is the loop index increment of the form 12248 `VAR {+=,-=} INCR'. 12249 12250 Operand `OMP_FOR_PRE_BODY' contains side-effect code from operands 12251 `OMP_FOR_INIT', `OMP_FOR_COND' and `OMP_FOR_INC'. These 12252 side-effects are part of the `OMP_FOR' block but must be evaluated 12253 before the start of loop body. 12254 12255 The loop index variable `VAR' must be a signed integer variable, 12256 which is implicitly private to each thread. Bounds `N1' and `N2' 12257 and the increment expression `INCR' are required to be loop 12258 invariant integer expressions that are evaluated without any 12259 synchronization. The evaluation order, frequency of evaluation and 12260 side-effects are unspecified by the standard. 12261 12262`OMP_SECTIONS' 12263 Represents `#pragma omp sections [clause1 ... clauseN]'. 12264 12265 Operand `OMP_SECTIONS_BODY' contains the sections body, which in 12266 turn contains a set of `OMP_SECTION' nodes for each of the 12267 concurrent sections delimited by `#pragma omp section'. 12268 12269 Operand `OMP_SECTIONS_CLAUSES' is the list of clauses associated 12270 with the directive. 12271 12272`OMP_SECTION' 12273 Section delimiter for `OMP_SECTIONS'. 12274 12275`OMP_SINGLE' 12276 Represents `#pragma omp single'. 12277 12278 Operand `OMP_SINGLE_BODY' contains the body of code to be executed 12279 by a single thread. 12280 12281 Operand `OMP_SINGLE_CLAUSES' is the list of clauses associated 12282 with the directive. 12283 12284`OMP_MASTER' 12285 Represents `#pragma omp master'. 12286 12287 Operand `OMP_MASTER_BODY' contains the body of code to be executed 12288 by the master thread. 12289 12290`OMP_ORDERED' 12291 Represents `#pragma omp ordered'. 12292 12293 Operand `OMP_ORDERED_BODY' contains the body of code to be 12294 executed in the sequential order dictated by the loop index 12295 variable. 12296 12297`OMP_CRITICAL' 12298 Represents `#pragma omp critical [name]'. 12299 12300 Operand `OMP_CRITICAL_BODY' is the critical section. 12301 12302 Operand `OMP_CRITICAL_NAME' is an optional identifier to label the 12303 critical section. 12304 12305`OMP_RETURN' 12306 This does not represent any OpenMP directive, it is an artificial 12307 marker to indicate the end of the body of an OpenMP. It is used by 12308 the flow graph (`tree-cfg.c') and OpenMP region building code 12309 (`omp-low.c'). 12310 12311`OMP_CONTINUE' 12312 Similarly, this instruction does not represent an OpenMP 12313 directive, it is used by `OMP_FOR' and `OMP_SECTIONS' to mark the 12314 place where the code needs to loop to the next iteration (in the 12315 case of `OMP_FOR') or the next section (in the case of 12316 `OMP_SECTIONS'). 12317 12318 In some cases, `OMP_CONTINUE' is placed right before `OMP_RETURN'. 12319 But if there are cleanups that need to occur right after the 12320 looping body, it will be emitted between `OMP_CONTINUE' and 12321 `OMP_RETURN'. 12322 12323`OMP_ATOMIC' 12324 Represents `#pragma omp atomic'. 12325 12326 Operand 0 is the address at which the atomic operation is to be 12327 performed. 12328 12329 Operand 1 is the expression to evaluate. The gimplifier tries 12330 three alternative code generation strategies. Whenever possible, 12331 an atomic update built-in is used. If that fails, a 12332 compare-and-swap loop is attempted. If that also fails, a regular 12333 critical section around the expression is used. 12334 12335`OMP_CLAUSE' 12336 Represents clauses associated with one of the `OMP_' directives. 12337 Clauses are represented by separate sub-codes defined in `tree.h'. 12338 Clauses codes can be one of: `OMP_CLAUSE_PRIVATE', 12339 `OMP_CLAUSE_SHARED', `OMP_CLAUSE_FIRSTPRIVATE', 12340 `OMP_CLAUSE_LASTPRIVATE', `OMP_CLAUSE_COPYIN', 12341 `OMP_CLAUSE_COPYPRIVATE', `OMP_CLAUSE_IF', 12342 `OMP_CLAUSE_NUM_THREADS', `OMP_CLAUSE_SCHEDULE', 12343 `OMP_CLAUSE_NOWAIT', `OMP_CLAUSE_ORDERED', `OMP_CLAUSE_DEFAULT', 12344 and `OMP_CLAUSE_REDUCTION'. Each code represents the 12345 corresponding OpenMP clause. 12346 12347 Clauses associated with the same directive are chained together 12348 via `OMP_CLAUSE_CHAIN'. Those clauses that accept a list of 12349 variables are restricted to exactly one, accessed with 12350 `OMP_CLAUSE_VAR'. Therefore, multiple variables under the same 12351 clause `C' need to be represented as multiple `C' clauses chained 12352 together. This facilitates adding new clauses during compilation. 12353 12354 12355 12356File: gccint.info, Node: Functions, Next: Language-dependent trees, Prev: Statements, Up: GENERIC 12357 1235811.8 Functions 12359============== 12360 12361A function is represented by a `FUNCTION_DECL' node. It stores the 12362basic pieces of the function such as body, parameters, and return type 12363as well as information on the surrounding context, visibility, and 12364linkage. 12365 12366* Menu: 12367 12368* Function Basics:: Function names, body, and parameters. 12369* Function Properties:: Context, linkage, etc. 12370 12371 12372File: gccint.info, Node: Function Basics, Next: Function Properties, Up: Functions 12373 1237411.8.1 Function Basics 12375---------------------- 12376 12377A function has four core parts: the name, the parameters, the result, 12378and the body. The following macros and functions access these parts of 12379a `FUNCTION_DECL' as well as other basic features: 12380`DECL_NAME' 12381 This macro returns the unqualified name of the function, as an 12382 `IDENTIFIER_NODE'. For an instantiation of a function template, 12383 the `DECL_NAME' is the unqualified name of the template, not 12384 something like `f<int>'. The value of `DECL_NAME' is undefined 12385 when used on a constructor, destructor, overloaded operator, or 12386 type-conversion operator, or any function that is implicitly 12387 generated by the compiler. See below for macros that can be used 12388 to distinguish these cases. 12389 12390`DECL_ASSEMBLER_NAME' 12391 This macro returns the mangled name of the function, also an 12392 `IDENTIFIER_NODE'. This name does not contain leading underscores 12393 on systems that prefix all identifiers with underscores. The 12394 mangled name is computed in the same way on all platforms; if 12395 special processing is required to deal with the object file format 12396 used on a particular platform, it is the responsibility of the 12397 back end to perform those modifications. (Of course, the back end 12398 should not modify `DECL_ASSEMBLER_NAME' itself.) 12399 12400 Using `DECL_ASSEMBLER_NAME' will cause additional memory to be 12401 allocated (for the mangled name of the entity) so it should be used 12402 only when emitting assembly code. It should not be used within the 12403 optimizers to determine whether or not two declarations are the 12404 same, even though some of the existing optimizers do use it in 12405 that way. These uses will be removed over time. 12406 12407`DECL_ARGUMENTS' 12408 This macro returns the `PARM_DECL' for the first argument to the 12409 function. Subsequent `PARM_DECL' nodes can be obtained by 12410 following the `TREE_CHAIN' links. 12411 12412`DECL_RESULT' 12413 This macro returns the `RESULT_DECL' for the function. 12414 12415`DECL_SAVED_TREE' 12416 This macro returns the complete body of the function. 12417 12418`TREE_TYPE' 12419 This macro returns the `FUNCTION_TYPE' or `METHOD_TYPE' for the 12420 function. 12421 12422`DECL_INITIAL' 12423 A function that has a definition in the current translation unit 12424 will have a non-`NULL' `DECL_INITIAL'. However, back ends should 12425 not make use of the particular value given by `DECL_INITIAL'. 12426 12427 It should contain a tree of `BLOCK' nodes that mirrors the scopes 12428 that variables are bound in the function. Each block contains a 12429 list of decls declared in a basic block, a pointer to a chain of 12430 blocks at the next lower scope level, then a pointer to the next 12431 block at the same level and a backpointer to the parent `BLOCK' or 12432 `FUNCTION_DECL'. So given a function as follows: 12433 12434 void foo() 12435 { 12436 int a; 12437 { 12438 int b; 12439 } 12440 int c; 12441 } 12442 12443 you would get the following: 12444 12445 tree foo = FUNCTION_DECL; 12446 tree decl_a = VAR_DECL; 12447 tree decl_b = VAR_DECL; 12448 tree decl_c = VAR_DECL; 12449 tree block_a = BLOCK; 12450 tree block_b = BLOCK; 12451 tree block_c = BLOCK; 12452 BLOCK_VARS(block_a) = decl_a; 12453 BLOCK_SUBBLOCKS(block_a) = block_b; 12454 BLOCK_CHAIN(block_a) = block_c; 12455 BLOCK_SUPERCONTEXT(block_a) = foo; 12456 BLOCK_VARS(block_b) = decl_b; 12457 BLOCK_SUPERCONTEXT(block_b) = block_a; 12458 BLOCK_VARS(block_c) = decl_c; 12459 BLOCK_SUPERCONTEXT(block_c) = foo; 12460 DECL_INITIAL(foo) = block_a; 12461 12462 12463 12464File: gccint.info, Node: Function Properties, Prev: Function Basics, Up: Functions 12465 1246611.8.2 Function Properties 12467-------------------------- 12468 12469To determine the scope of a function, you can use the `DECL_CONTEXT' 12470macro. This macro will return the class (either a `RECORD_TYPE' or a 12471`UNION_TYPE') or namespace (a `NAMESPACE_DECL') of which the function 12472is a member. For a virtual function, this macro returns the class in 12473which the function was actually defined, not the base class in which 12474the virtual declaration occurred. 12475 12476 In C, the `DECL_CONTEXT' for a function maybe another function. This 12477representation indicates that the GNU nested function extension is in 12478use. For details on the semantics of nested functions, see the GCC 12479Manual. The nested function can refer to local variables in its 12480containing function. Such references are not explicitly marked in the 12481tree structure; back ends must look at the `DECL_CONTEXT' for the 12482referenced `VAR_DECL'. If the `DECL_CONTEXT' for the referenced 12483`VAR_DECL' is not the same as the function currently being processed, 12484and neither `DECL_EXTERNAL' nor `TREE_STATIC' hold, then the reference 12485is to a local variable in a containing function, and the back end must 12486take appropriate action. 12487 12488`DECL_EXTERNAL' 12489 This predicate holds if the function is undefined. 12490 12491`TREE_PUBLIC' 12492 This predicate holds if the function has external linkage. 12493 12494`TREE_STATIC' 12495 This predicate holds if the function has been defined. 12496 12497`TREE_THIS_VOLATILE' 12498 This predicate holds if the function does not return normally. 12499 12500`TREE_READONLY' 12501 This predicate holds if the function can only read its arguments. 12502 12503`DECL_PURE_P' 12504 This predicate holds if the function can only read its arguments, 12505 but may also read global memory. 12506 12507`DECL_VIRTUAL_P' 12508 This predicate holds if the function is virtual. 12509 12510`DECL_ARTIFICIAL' 12511 This macro holds if the function was implicitly generated by the 12512 compiler, rather than explicitly declared. In addition to 12513 implicitly generated class member functions, this macro holds for 12514 the special functions created to implement static initialization 12515 and destruction, to compute run-time type information, and so 12516 forth. 12517 12518`DECL_FUNCTION_SPECIFIC_TARGET' 12519 This macro returns a tree node that holds the target options that 12520 are to be used to compile this particular function or `NULL_TREE' 12521 if the function is to be compiled with the target options 12522 specified on the command line. 12523 12524`DECL_FUNCTION_SPECIFIC_OPTIMIZATION' 12525 This macro returns a tree node that holds the optimization options 12526 that are to be used to compile this particular function or 12527 `NULL_TREE' if the function is to be compiled with the 12528 optimization options specified on the command line. 12529 12530 1253111.8.2.1 Statements 12532................... 12533 12534There are tree nodes corresponding to all of the source-level statement 12535constructs, used within the C and C++ frontends. These are enumerated 12536here, together with a list of the various macros that can be used to 12537obtain information about them. There are a few macros that can be used 12538with all statements: 12539 12540 12541File: gccint.info, Node: Language-dependent trees, Next: C and C++ Trees, Prev: Functions, Up: GENERIC 12542 1254311.9 Language-dependent trees 12544============================= 12545 12546Front ends may wish to keep some state associated with various GENERIC 12547trees while parsing. To support this, trees provide a set of flags 12548that may be used by the front end. They are accessed using 12549`TREE_LANG_FLAG_n' where `n' is currently 0 through 6. 12550 12551 If necessary, a front end can use some language-dependent tree codes 12552in its GENERIC representation, so long as it provides a hook for 12553converting them to GIMPLE and doesn't expect them to work with any 12554(hypothetical) optimizers that run before the conversion to GIMPLE. The 12555intermediate representation used while parsing C and C++ looks very 12556little like GENERIC, but the C and C++ gimplifier hooks are perfectly 12557happy to take it as input and spit out GIMPLE. 12558 12559 12560File: gccint.info, Node: C and C++ Trees, Next: Java Trees, Prev: Language-dependent trees, Up: GENERIC 12561 1256211.10 C and C++ Trees 12563===================== 12564 12565This section documents the internal representation used by GCC to 12566represent C and C++ source programs. When presented with a C or C++ 12567source program, GCC parses the program, performs semantic analysis 12568(including the generation of error messages), and then produces the 12569internal representation described here. This representation contains a 12570complete representation for the entire translation unit provided as 12571input to the front end. This representation is then typically processed 12572by a code-generator in order to produce machine code, but could also be 12573used in the creation of source browsers, intelligent editors, automatic 12574documentation generators, interpreters, and any other programs needing 12575the ability to process C or C++ code. 12576 12577 This section explains the internal representation. In particular, it 12578documents the internal representation for C and C++ source constructs, 12579and the macros, functions, and variables that can be used to access 12580these constructs. The C++ representation is largely a superset of the 12581representation used in the C front end. There is only one construct 12582used in C that does not appear in the C++ front end and that is the GNU 12583"nested function" extension. Many of the macros documented here do not 12584apply in C because the corresponding language constructs do not appear 12585in C. 12586 12587 The C and C++ front ends generate a mix of GENERIC trees and ones 12588specific to C and C++. These language-specific trees are higher-level 12589constructs than the ones in GENERIC to make the parser's job easier. 12590This section describes those trees that aren't part of GENERIC as well 12591as aspects of GENERIC trees that are treated in a language-specific 12592manner. 12593 12594 If you are developing a "back end", be it is a code-generator or some 12595other tool, that uses this representation, you may occasionally find 12596that you need to ask questions not easily answered by the functions and 12597macros available here. If that situation occurs, it is quite likely 12598that GCC already supports the functionality you desire, but that the 12599interface is simply not documented here. In that case, you should ask 12600the GCC maintainers (via mail to <gcc@gcc.gnu.org>) about documenting 12601the functionality you require. Similarly, if you find yourself writing 12602functions that do not deal directly with your back end, but instead 12603might be useful to other people using the GCC front end, you should 12604submit your patches for inclusion in GCC. 12605 12606* Menu: 12607 12608* Types for C++:: Fundamental and aggregate types. 12609* Namespaces:: Namespaces. 12610* Classes:: Classes. 12611* Functions for C++:: Overloading and accessors for C++. 12612* Statements for C++:: Statements specific to C and C++. 12613* C++ Expressions:: From `typeid' to `throw'. 12614 12615 12616File: gccint.info, Node: Types for C++, Next: Namespaces, Up: C and C++ Trees 12617 1261811.10.1 Types for C++ 12619--------------------- 12620 12621In C++, an array type is not qualified; rather the type of the array 12622elements is qualified. This situation is reflected in the intermediate 12623representation. The macros described here will always examine the 12624qualification of the underlying element type when applied to an array 12625type. (If the element type is itself an array, then the recursion 12626continues until a non-array type is found, and the qualification of this 12627type is examined.) So, for example, `CP_TYPE_CONST_P' will hold of the 12628type `const int ()[7]', denoting an array of seven `int's. 12629 12630 The following functions and macros deal with cv-qualification of types: 12631`CP_TYPE_QUALS' 12632 This macro returns the set of type qualifiers applied to this type. 12633 This value is `TYPE_UNQUALIFIED' if no qualifiers have been 12634 applied. The `TYPE_QUAL_CONST' bit is set if the type is 12635 `const'-qualified. The `TYPE_QUAL_VOLATILE' bit is set if the 12636 type is `volatile'-qualified. The `TYPE_QUAL_RESTRICT' bit is set 12637 if the type is `restrict'-qualified. 12638 12639`CP_TYPE_CONST_P' 12640 This macro holds if the type is `const'-qualified. 12641 12642`CP_TYPE_VOLATILE_P' 12643 This macro holds if the type is `volatile'-qualified. 12644 12645`CP_TYPE_RESTRICT_P' 12646 This macro holds if the type is `restrict'-qualified. 12647 12648`CP_TYPE_CONST_NON_VOLATILE_P' 12649 This predicate holds for a type that is `const'-qualified, but 12650 _not_ `volatile'-qualified; other cv-qualifiers are ignored as 12651 well: only the `const'-ness is tested. 12652 12653 12654 A few other macros and functions are usable with all types: 12655`TYPE_SIZE' 12656 The number of bits required to represent the type, represented as 12657 an `INTEGER_CST'. For an incomplete type, `TYPE_SIZE' will be 12658 `NULL_TREE'. 12659 12660`TYPE_ALIGN' 12661 The alignment of the type, in bits, represented as an `int'. 12662 12663`TYPE_NAME' 12664 This macro returns a declaration (in the form of a `TYPE_DECL') for 12665 the type. (Note this macro does _not_ return an 12666 `IDENTIFIER_NODE', as you might expect, given its name!) You can 12667 look at the `DECL_NAME' of the `TYPE_DECL' to obtain the actual 12668 name of the type. The `TYPE_NAME' will be `NULL_TREE' for a type 12669 that is not a built-in type, the result of a typedef, or a named 12670 class type. 12671 12672`CP_INTEGRAL_TYPE' 12673 This predicate holds if the type is an integral type. Notice that 12674 in C++, enumerations are _not_ integral types. 12675 12676`ARITHMETIC_TYPE_P' 12677 This predicate holds if the type is an integral type (in the C++ 12678 sense) or a floating point type. 12679 12680`CLASS_TYPE_P' 12681 This predicate holds for a class-type. 12682 12683`TYPE_BUILT_IN' 12684 This predicate holds for a built-in type. 12685 12686`TYPE_PTRMEM_P' 12687 This predicate holds if the type is a pointer to data member. 12688 12689`TYPE_PTR_P' 12690 This predicate holds if the type is a pointer type, and the 12691 pointee is not a data member. 12692 12693`TYPE_PTRFN_P' 12694 This predicate holds for a pointer to function type. 12695 12696`TYPE_PTROB_P' 12697 This predicate holds for a pointer to object type. Note however 12698 that it does not hold for the generic pointer to object type `void 12699 *'. You may use `TYPE_PTROBV_P' to test for a pointer to object 12700 type as well as `void *'. 12701 12702 12703 The table below describes types specific to C and C++ as well as 12704language-dependent info about GENERIC types. 12705 12706`POINTER_TYPE' 12707 Used to represent pointer types, and pointer to data member types. 12708 If `TREE_TYPE' is a pointer to data member type, then 12709 `TYPE_PTRMEM_P' will hold. For a pointer to data member type of 12710 the form `T X::*', `TYPE_PTRMEM_CLASS_TYPE' will be the type `X', 12711 while `TYPE_PTRMEM_POINTED_TO_TYPE' will be the type `T'. 12712 12713`RECORD_TYPE' 12714 Used to represent `struct' and `class' types in C and C++. If 12715 `TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member 12716 type. In that case, the `TYPE_PTRMEMFUNC_FN_TYPE' is a 12717 `POINTER_TYPE' pointing to a `METHOD_TYPE'. The `METHOD_TYPE' is 12718 the type of a function pointed to by the pointer-to-member 12719 function. If `TYPE_PTRMEMFUNC_P' does not hold, this type is a 12720 class type. For more information, see *note Classes::. 12721 12722`UNKNOWN_TYPE' 12723 This node is used to represent a type the knowledge of which is 12724 insufficient for a sound processing. 12725 12726`TYPENAME_TYPE' 12727 Used to represent a construct of the form `typename T::A'. The 12728 `TYPE_CONTEXT' is `T'; the `TYPE_NAME' is an `IDENTIFIER_NODE' for 12729 `A'. If the type is specified via a template-id, then 12730 `TYPENAME_TYPE_FULLNAME' yields a `TEMPLATE_ID_EXPR'. The 12731 `TREE_TYPE' is non-`NULL' if the node is implicitly generated in 12732 support for the implicit typename extension; in which case the 12733 `TREE_TYPE' is a type node for the base-class. 12734 12735`TYPEOF_TYPE' 12736 Used to represent the `__typeof__' extension. The `TYPE_FIELDS' 12737 is the expression the type of which is being represented. 12738 12739 12740 12741File: gccint.info, Node: Namespaces, Next: Classes, Prev: Types for C++, Up: C and C++ Trees 12742 1274311.10.2 Namespaces 12744------------------ 12745 12746The root of the entire intermediate representation is the variable 12747`global_namespace'. This is the namespace specified with `::' in C++ 12748source code. All other namespaces, types, variables, functions, and so 12749forth can be found starting with this namespace. 12750 12751 However, except for the fact that it is distinguished as the root of 12752the representation, the global namespace is no different from any other 12753namespace. Thus, in what follows, we describe namespaces generally, 12754rather than the global namespace in particular. 12755 12756 A namespace is represented by a `NAMESPACE_DECL' node. 12757 12758 The following macros and functions can be used on a `NAMESPACE_DECL': 12759 12760`DECL_NAME' 12761 This macro is used to obtain the `IDENTIFIER_NODE' corresponding to 12762 the unqualified name of the name of the namespace (*note 12763 Identifiers::). The name of the global namespace is `::', even 12764 though in C++ the global namespace is unnamed. However, you 12765 should use comparison with `global_namespace', rather than 12766 `DECL_NAME' to determine whether or not a namespace is the global 12767 one. An unnamed namespace will have a `DECL_NAME' equal to 12768 `anonymous_namespace_name'. Within a single translation unit, all 12769 unnamed namespaces will have the same name. 12770 12771`DECL_CONTEXT' 12772 This macro returns the enclosing namespace. The `DECL_CONTEXT' for 12773 the `global_namespace' is `NULL_TREE'. 12774 12775`DECL_NAMESPACE_ALIAS' 12776 If this declaration is for a namespace alias, then 12777 `DECL_NAMESPACE_ALIAS' is the namespace for which this one is an 12778 alias. 12779 12780 Do not attempt to use `cp_namespace_decls' for a namespace which is 12781 an alias. Instead, follow `DECL_NAMESPACE_ALIAS' links until you 12782 reach an ordinary, non-alias, namespace, and call 12783 `cp_namespace_decls' there. 12784 12785`DECL_NAMESPACE_STD_P' 12786 This predicate holds if the namespace is the special `::std' 12787 namespace. 12788 12789`cp_namespace_decls' 12790 This function will return the declarations contained in the 12791 namespace, including types, overloaded functions, other 12792 namespaces, and so forth. If there are no declarations, this 12793 function will return `NULL_TREE'. The declarations are connected 12794 through their `TREE_CHAIN' fields. 12795 12796 Although most entries on this list will be declarations, 12797 `TREE_LIST' nodes may also appear. In this case, the `TREE_VALUE' 12798 will be an `OVERLOAD'. The value of the `TREE_PURPOSE' is 12799 unspecified; back ends should ignore this value. As with the 12800 other kinds of declarations returned by `cp_namespace_decls', the 12801 `TREE_CHAIN' will point to the next declaration in this list. 12802 12803 For more information on the kinds of declarations that can occur 12804 on this list, *Note Declarations::. Some declarations will not 12805 appear on this list. In particular, no `FIELD_DECL', 12806 `LABEL_DECL', or `PARM_DECL' nodes will appear here. 12807 12808 This function cannot be used with namespaces that have 12809 `DECL_NAMESPACE_ALIAS' set. 12810 12811 12812 12813File: gccint.info, Node: Classes, Next: Functions for C++, Prev: Namespaces, Up: C and C++ Trees 12814 1281511.10.3 Classes 12816--------------- 12817 12818Besides namespaces, the other high-level scoping construct in C++ is the 12819class. (Throughout this manual the term "class" is used to mean the 12820types referred to in the ANSI/ISO C++ Standard as classes; these include 12821types defined with the `class', `struct', and `union' keywords.) 12822 12823 A class type is represented by either a `RECORD_TYPE' or a 12824`UNION_TYPE'. A class declared with the `union' tag is represented by 12825a `UNION_TYPE', while classes declared with either the `struct' or the 12826`class' tag are represented by `RECORD_TYPE's. You can use the 12827`CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular 12828type is a `class' as opposed to a `struct'. This macro will be true 12829only for classes declared with the `class' tag. 12830 12831 Almost all non-function members are available on the `TYPE_FIELDS' 12832list. Given one member, the next can be found by following the 12833`TREE_CHAIN'. You should not depend in any way on the order in which 12834fields appear on this list. All nodes on this list will be `DECL' 12835nodes. A `FIELD_DECL' is used to represent a non-static data member, a 12836`VAR_DECL' is used to represent a static data member, and a `TYPE_DECL' 12837is used to represent a type. Note that the `CONST_DECL' for an 12838enumeration constant will appear on this list, if the enumeration type 12839was declared in the class. (Of course, the `TYPE_DECL' for the 12840enumeration type will appear here as well.) There are no entries for 12841base classes on this list. In particular, there is no `FIELD_DECL' for 12842the "base-class portion" of an object. 12843 12844 The `TYPE_VFIELD' is a compiler-generated field used to point to 12845virtual function tables. It may or may not appear on the `TYPE_FIELDS' 12846list. However, back ends should handle the `TYPE_VFIELD' just like all 12847the entries on the `TYPE_FIELDS' list. 12848 12849 The function members are available on the `TYPE_METHODS' list. Again, 12850subsequent members are found by following the `TREE_CHAIN' field. If a 12851function is overloaded, each of the overloaded functions appears; no 12852`OVERLOAD' nodes appear on the `TYPE_METHODS' list. Implicitly 12853declared functions (including default constructors, copy constructors, 12854assignment operators, and destructors) will appear on this list as well. 12855 12856 Every class has an associated "binfo", which can be obtained with 12857`TYPE_BINFO'. Binfos are used to represent base-classes. The binfo 12858given by `TYPE_BINFO' is the degenerate case, whereby every class is 12859considered to be its own base-class. The base binfos for a particular 12860binfo are held in a vector, whose length is obtained with 12861`BINFO_N_BASE_BINFOS'. The base binfos themselves are obtained with 12862`BINFO_BASE_BINFO' and `BINFO_BASE_ITERATE'. To add a new binfo, use 12863`BINFO_BASE_APPEND'. The vector of base binfos can be obtained with 12864`BINFO_BASE_BINFOS', but normally you do not need to use that. The 12865class type associated with a binfo is given by `BINFO_TYPE'. It is not 12866always the case that `BINFO_TYPE (TYPE_BINFO (x))', because of typedefs 12867and qualified types. Neither is it the case that `TYPE_BINFO 12868(BINFO_TYPE (y))' is the same binfo as `y'. The reason is that if `y' 12869is a binfo representing a base-class `B' of a derived class `D', then 12870`BINFO_TYPE (y)' will be `B', and `TYPE_BINFO (BINFO_TYPE (y))' will be 12871`B' as its own base-class, rather than as a base-class of `D'. 12872 12873 The access to a base type can be found with `BINFO_BASE_ACCESS'. This 12874will produce `access_public_node', `access_private_node' or 12875`access_protected_node'. If bases are always public, 12876`BINFO_BASE_ACCESSES' may be `NULL'. 12877 12878 `BINFO_VIRTUAL_P' is used to specify whether the binfo is inherited 12879virtually or not. The other flags, `BINFO_MARKED_P' and `BINFO_FLAG_1' 12880to `BINFO_FLAG_6' can be used for language specific use. 12881 12882 The following macros can be used on a tree node representing a 12883class-type. 12884 12885`LOCAL_CLASS_P' 12886 This predicate holds if the class is local class _i.e._ declared 12887 inside a function body. 12888 12889`TYPE_POLYMORPHIC_P' 12890 This predicate holds if the class has at least one virtual function 12891 (declared or inherited). 12892 12893`TYPE_HAS_DEFAULT_CONSTRUCTOR' 12894 This predicate holds whenever its argument represents a class-type 12895 with default constructor. 12896 12897`CLASSTYPE_HAS_MUTABLE' 12898`TYPE_HAS_MUTABLE_P' 12899 These predicates hold for a class-type having a mutable data 12900 member. 12901 12902`CLASSTYPE_NON_POD_P' 12903 This predicate holds only for class-types that are not PODs. 12904 12905`TYPE_HAS_NEW_OPERATOR' 12906 This predicate holds for a class-type that defines `operator new'. 12907 12908`TYPE_HAS_ARRAY_NEW_OPERATOR' 12909 This predicate holds for a class-type for which `operator new[]' 12910 is defined. 12911 12912`TYPE_OVERLOADS_CALL_EXPR' 12913 This predicate holds for class-type for which the function call 12914 `operator()' is overloaded. 12915 12916`TYPE_OVERLOADS_ARRAY_REF' 12917 This predicate holds for a class-type that overloads `operator[]' 12918 12919`TYPE_OVERLOADS_ARROW' 12920 This predicate holds for a class-type for which `operator->' is 12921 overloaded. 12922 12923 12924 12925File: gccint.info, Node: Functions for C++, Next: Statements for C++, Prev: Classes, Up: C and C++ Trees 12926 1292711.10.4 Functions for C++ 12928------------------------- 12929 12930A function is represented by a `FUNCTION_DECL' node. A set of 12931overloaded functions is sometimes represented by an `OVERLOAD' node. 12932 12933 An `OVERLOAD' node is not a declaration, so none of the `DECL_' macros 12934should be used on an `OVERLOAD'. An `OVERLOAD' node is similar to a 12935`TREE_LIST'. Use `OVL_CURRENT' to get the function associated with an 12936`OVERLOAD' node; use `OVL_NEXT' to get the next `OVERLOAD' node in the 12937list of overloaded functions. The macros `OVL_CURRENT' and `OVL_NEXT' 12938are actually polymorphic; you can use them to work with `FUNCTION_DECL' 12939nodes as well as with overloads. In the case of a `FUNCTION_DECL', 12940`OVL_CURRENT' will always return the function itself, and `OVL_NEXT' 12941will always be `NULL_TREE'. 12942 12943 To determine the scope of a function, you can use the `DECL_CONTEXT' 12944macro. This macro will return the class (either a `RECORD_TYPE' or a 12945`UNION_TYPE') or namespace (a `NAMESPACE_DECL') of which the function 12946is a member. For a virtual function, this macro returns the class in 12947which the function was actually defined, not the base class in which 12948the virtual declaration occurred. 12949 12950 If a friend function is defined in a class scope, the 12951`DECL_FRIEND_CONTEXT' macro can be used to determine the class in which 12952it was defined. For example, in 12953 class C { friend void f() {} }; 12954 the `DECL_CONTEXT' for `f' will be the `global_namespace', but the 12955`DECL_FRIEND_CONTEXT' will be the `RECORD_TYPE' for `C'. 12956 12957 The following macros and functions can be used on a `FUNCTION_DECL': 12958`DECL_MAIN_P' 12959 This predicate holds for a function that is the program entry point 12960 `::code'. 12961 12962`DECL_LOCAL_FUNCTION_P' 12963 This predicate holds if the function was declared at block scope, 12964 even though it has a global scope. 12965 12966`DECL_ANTICIPATED' 12967 This predicate holds if the function is a built-in function but its 12968 prototype is not yet explicitly declared. 12969 12970`DECL_EXTERN_C_FUNCTION_P' 12971 This predicate holds if the function is declared as an ``extern 12972 "C"'' function. 12973 12974`DECL_LINKONCE_P' 12975 This macro holds if multiple copies of this function may be 12976 emitted in various translation units. It is the responsibility of 12977 the linker to merge the various copies. Template instantiations 12978 are the most common example of functions for which 12979 `DECL_LINKONCE_P' holds; G++ instantiates needed templates in all 12980 translation units which require them, and then relies on the 12981 linker to remove duplicate instantiations. 12982 12983 FIXME: This macro is not yet implemented. 12984 12985`DECL_FUNCTION_MEMBER_P' 12986 This macro holds if the function is a member of a class, rather 12987 than a member of a namespace. 12988 12989`DECL_STATIC_FUNCTION_P' 12990 This predicate holds if the function a static member function. 12991 12992`DECL_NONSTATIC_MEMBER_FUNCTION_P' 12993 This macro holds for a non-static member function. 12994 12995`DECL_CONST_MEMFUNC_P' 12996 This predicate holds for a `const'-member function. 12997 12998`DECL_VOLATILE_MEMFUNC_P' 12999 This predicate holds for a `volatile'-member function. 13000 13001`DECL_CONSTRUCTOR_P' 13002 This macro holds if the function is a constructor. 13003 13004`DECL_NONCONVERTING_P' 13005 This predicate holds if the constructor is a non-converting 13006 constructor. 13007 13008`DECL_COMPLETE_CONSTRUCTOR_P' 13009 This predicate holds for a function which is a constructor for an 13010 object of a complete type. 13011 13012`DECL_BASE_CONSTRUCTOR_P' 13013 This predicate holds for a function which is a constructor for a 13014 base class sub-object. 13015 13016`DECL_COPY_CONSTRUCTOR_P' 13017 This predicate holds for a function which is a copy-constructor. 13018 13019`DECL_DESTRUCTOR_P' 13020 This macro holds if the function is a destructor. 13021 13022`DECL_COMPLETE_DESTRUCTOR_P' 13023 This predicate holds if the function is the destructor for an 13024 object a complete type. 13025 13026`DECL_OVERLOADED_OPERATOR_P' 13027 This macro holds if the function is an overloaded operator. 13028 13029`DECL_CONV_FN_P' 13030 This macro holds if the function is a type-conversion operator. 13031 13032`DECL_GLOBAL_CTOR_P' 13033 This predicate holds if the function is a file-scope initialization 13034 function. 13035 13036`DECL_GLOBAL_DTOR_P' 13037 This predicate holds if the function is a file-scope finalization 13038 function. 13039 13040`DECL_THUNK_P' 13041 This predicate holds if the function is a thunk. 13042 13043 These functions represent stub code that adjusts the `this' pointer 13044 and then jumps to another function. When the jumped-to function 13045 returns, control is transferred directly to the caller, without 13046 returning to the thunk. The first parameter to the thunk is 13047 always the `this' pointer; the thunk should add `THUNK_DELTA' to 13048 this value. (The `THUNK_DELTA' is an `int', not an `INTEGER_CST'.) 13049 13050 Then, if `THUNK_VCALL_OFFSET' (an `INTEGER_CST') is nonzero the 13051 adjusted `this' pointer must be adjusted again. The complete 13052 calculation is given by the following pseudo-code: 13053 13054 this += THUNK_DELTA 13055 if (THUNK_VCALL_OFFSET) 13056 this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET] 13057 13058 Finally, the thunk should jump to the location given by 13059 `DECL_INITIAL'; this will always be an expression for the address 13060 of a function. 13061 13062`DECL_NON_THUNK_FUNCTION_P' 13063 This predicate holds if the function is _not_ a thunk function. 13064 13065`GLOBAL_INIT_PRIORITY' 13066 If either `DECL_GLOBAL_CTOR_P' or `DECL_GLOBAL_DTOR_P' holds, then 13067 this gives the initialization priority for the function. The 13068 linker will arrange that all functions for which 13069 `DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority 13070 before `main' is called. When the program exits, all functions for 13071 which `DECL_GLOBAL_DTOR_P' holds are run in the reverse order. 13072 13073`TYPE_RAISES_EXCEPTIONS' 13074 This macro returns the list of exceptions that a (member-)function 13075 can raise. The returned list, if non `NULL', is comprised of nodes 13076 whose `TREE_VALUE' represents a type. 13077 13078`TYPE_NOTHROW_P' 13079 This predicate holds when the exception-specification of its 13080 arguments is of the form ``()''. 13081 13082`DECL_ARRAY_DELETE_OPERATOR_P' 13083 This predicate holds if the function an overloaded `operator 13084 delete[]'. 13085 13086 13087 13088File: gccint.info, Node: Statements for C++, Next: C++ Expressions, Prev: Functions for C++, Up: C and C++ Trees 13089 1309011.10.5 Statements for C++ 13091-------------------------- 13092 13093A function that has a definition in the current translation unit will 13094have a non-`NULL' `DECL_INITIAL'. However, back ends should not make 13095use of the particular value given by `DECL_INITIAL'. 13096 13097 The `DECL_SAVED_TREE' macro will give the complete body of the 13098function. 13099 1310011.10.5.1 Statements 13101.................... 13102 13103There are tree nodes corresponding to all of the source-level statement 13104constructs, used within the C and C++ frontends. These are enumerated 13105here, together with a list of the various macros that can be used to 13106obtain information about them. There are a few macros that can be used 13107with all statements: 13108 13109`STMT_IS_FULL_EXPR_P' 13110 In C++, statements normally constitute "full expressions"; 13111 temporaries created during a statement are destroyed when the 13112 statement is complete. However, G++ sometimes represents 13113 expressions by statements; these statements will not have 13114 `STMT_IS_FULL_EXPR_P' set. Temporaries created during such 13115 statements should be destroyed when the innermost enclosing 13116 statement with `STMT_IS_FULL_EXPR_P' set is exited. 13117 13118 13119 Here is the list of the various statement nodes, and the macros used to 13120access them. This documentation describes the use of these nodes in 13121non-template functions (including instantiations of template functions). 13122In template functions, the same nodes are used, but sometimes in 13123slightly different ways. 13124 13125 Many of the statements have substatements. For example, a `while' 13126loop will have a body, which is itself a statement. If the substatement 13127is `NULL_TREE', it is considered equivalent to a statement consisting 13128of a single `;', i.e., an expression statement in which the expression 13129has been omitted. A substatement may in fact be a list of statements, 13130connected via their `TREE_CHAIN's. So, you should always process the 13131statement tree by looping over substatements, like this: 13132 void process_stmt (stmt) 13133 tree stmt; 13134 { 13135 while (stmt) 13136 { 13137 switch (TREE_CODE (stmt)) 13138 { 13139 case IF_STMT: 13140 process_stmt (THEN_CLAUSE (stmt)); 13141 /* More processing here. */ 13142 break; 13143 13144 ... 13145 } 13146 13147 stmt = TREE_CHAIN (stmt); 13148 } 13149 } 13150 In other words, while the `then' clause of an `if' statement in C++ 13151can be only one statement (although that one statement may be a 13152compound statement), the intermediate representation will sometimes use 13153several statements chained together. 13154 13155`BREAK_STMT' 13156 Used to represent a `break' statement. There are no additional 13157 fields. 13158 13159`CLEANUP_STMT' 13160 Used to represent an action that should take place upon exit from 13161 the enclosing scope. Typically, these actions are calls to 13162 destructors for local objects, but back ends cannot rely on this 13163 fact. If these nodes are in fact representing such destructors, 13164 `CLEANUP_DECL' will be the `VAR_DECL' destroyed. Otherwise, 13165 `CLEANUP_DECL' will be `NULL_TREE'. In any case, the 13166 `CLEANUP_EXPR' is the expression to execute. The cleanups 13167 executed on exit from a scope should be run in the reverse order 13168 of the order in which the associated `CLEANUP_STMT's were 13169 encountered. 13170 13171`CONTINUE_STMT' 13172 Used to represent a `continue' statement. There are no additional 13173 fields. 13174 13175`CTOR_STMT' 13176 Used to mark the beginning (if `CTOR_BEGIN_P' holds) or end (if 13177 `CTOR_END_P' holds of the main body of a constructor. See also 13178 `SUBOBJECT' for more information on how to use these nodes. 13179 13180`DO_STMT' 13181 Used to represent a `do' loop. The body of the loop is given by 13182 `DO_BODY' while the termination condition for the loop is given by 13183 `DO_COND'. The condition for a `do'-statement is always an 13184 expression. 13185 13186`EMPTY_CLASS_EXPR' 13187 Used to represent a temporary object of a class with no data whose 13188 address is never taken. (All such objects are interchangeable.) 13189 The `TREE_TYPE' represents the type of the object. 13190 13191`EXPR_STMT' 13192 Used to represent an expression statement. Use `EXPR_STMT_EXPR' to 13193 obtain the expression. 13194 13195`FOR_STMT' 13196 Used to represent a `for' statement. The `FOR_INIT_STMT' is the 13197 initialization statement for the loop. The `FOR_COND' is the 13198 termination condition. The `FOR_EXPR' is the expression executed 13199 right before the `FOR_COND' on each loop iteration; often, this 13200 expression increments a counter. The body of the loop is given by 13201 `FOR_BODY'. Note that `FOR_INIT_STMT' and `FOR_BODY' return 13202 statements, while `FOR_COND' and `FOR_EXPR' return expressions. 13203 13204`HANDLER' 13205 Used to represent a C++ `catch' block. The `HANDLER_TYPE' is the 13206 type of exception that will be caught by this handler; it is equal 13207 (by pointer equality) to `NULL' if this handler is for all types. 13208 `HANDLER_PARMS' is the `DECL_STMT' for the catch parameter, and 13209 `HANDLER_BODY' is the code for the block itself. 13210 13211`IF_STMT' 13212 Used to represent an `if' statement. The `IF_COND' is the 13213 expression. 13214 13215 If the condition is a `TREE_LIST', then the `TREE_PURPOSE' is a 13216 statement (usually a `DECL_STMT'). Each time the condition is 13217 evaluated, the statement should be executed. Then, the 13218 `TREE_VALUE' should be used as the conditional expression itself. 13219 This representation is used to handle C++ code like this: 13220 13221 C++ distinguishes between this and `COND_EXPR' for handling 13222 templates. 13223 13224 if (int i = 7) ... 13225 13226 where there is a new local variable (or variables) declared within 13227 the condition. 13228 13229 The `THEN_CLAUSE' represents the statement given by the `then' 13230 condition, while the `ELSE_CLAUSE' represents the statement given 13231 by the `else' condition. 13232 13233`SUBOBJECT' 13234 In a constructor, these nodes are used to mark the point at which a 13235 subobject of `this' is fully constructed. If, after this point, an 13236 exception is thrown before a `CTOR_STMT' with `CTOR_END_P' set is 13237 encountered, the `SUBOBJECT_CLEANUP' must be executed. The 13238 cleanups must be executed in the reverse order in which they 13239 appear. 13240 13241`SWITCH_STMT' 13242 Used to represent a `switch' statement. The `SWITCH_STMT_COND' is 13243 the expression on which the switch is occurring. See the 13244 documentation for an `IF_STMT' for more information on the 13245 representation used for the condition. The `SWITCH_STMT_BODY' is 13246 the body of the switch statement. The `SWITCH_STMT_TYPE' is the 13247 original type of switch expression as given in the source, before 13248 any compiler conversions. 13249 13250`TRY_BLOCK' 13251 Used to represent a `try' block. The body of the try block is 13252 given by `TRY_STMTS'. Each of the catch blocks is a `HANDLER' 13253 node. The first handler is given by `TRY_HANDLERS'. Subsequent 13254 handlers are obtained by following the `TREE_CHAIN' link from one 13255 handler to the next. The body of the handler is given by 13256 `HANDLER_BODY'. 13257 13258 If `CLEANUP_P' holds of the `TRY_BLOCK', then the `TRY_HANDLERS' 13259 will not be a `HANDLER' node. Instead, it will be an expression 13260 that should be executed if an exception is thrown in the try 13261 block. It must rethrow the exception after executing that code. 13262 And, if an exception is thrown while the expression is executing, 13263 `terminate' must be called. 13264 13265`USING_STMT' 13266 Used to represent a `using' directive. The namespace is given by 13267 `USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL. This node 13268 is needed inside template functions, to implement using directives 13269 during instantiation. 13270 13271`WHILE_STMT' 13272 Used to represent a `while' loop. The `WHILE_COND' is the 13273 termination condition for the loop. See the documentation for an 13274 `IF_STMT' for more information on the representation used for the 13275 condition. 13276 13277 The `WHILE_BODY' is the body of the loop. 13278 13279 13280 13281File: gccint.info, Node: C++ Expressions, Prev: Statements for C++, Up: C and C++ Trees 13282 1328311.10.6 C++ Expressions 13284----------------------- 13285 13286This section describes expressions specific to the C and C++ front ends. 13287 13288`TYPEID_EXPR' 13289 Used to represent a `typeid' expression. 13290 13291`NEW_EXPR' 13292`VEC_NEW_EXPR' 13293 Used to represent a call to `new' and `new[]' respectively. 13294 13295`DELETE_EXPR' 13296`VEC_DELETE_EXPR' 13297 Used to represent a call to `delete' and `delete[]' respectively. 13298 13299`MEMBER_REF' 13300 Represents a reference to a member of a class. 13301 13302`THROW_EXPR' 13303 Represents an instance of `throw' in the program. Operand 0, 13304 which is the expression to throw, may be `NULL_TREE'. 13305 13306`AGGR_INIT_EXPR' 13307 An `AGGR_INIT_EXPR' represents the initialization as the return 13308 value of a function call, or as the result of a constructor. An 13309 `AGGR_INIT_EXPR' will only appear as a full-expression, or as the 13310 second operand of a `TARGET_EXPR'. `AGGR_INIT_EXPR's have a 13311 representation similar to that of `CALL_EXPR's. You can use the 13312 `AGGR_INIT_EXPR_FN' and `AGGR_INIT_EXPR_ARG' macros to access the 13313 function to call and the arguments to pass. 13314 13315 If `AGGR_INIT_VIA_CTOR_P' holds of the `AGGR_INIT_EXPR', then the 13316 initialization is via a constructor call. The address of the 13317 `AGGR_INIT_EXPR_SLOT' operand, which is always a `VAR_DECL', is 13318 taken, and this value replaces the first argument in the argument 13319 list. 13320 13321 In either case, the expression is void. 13322 13323 13324 13325File: gccint.info, Node: Java Trees, Prev: C and C++ Trees, Up: GENERIC 13326 1332711.11 Java Trees 13328================ 13329 13330 13331File: gccint.info, Node: GIMPLE, Next: Tree SSA, Prev: GENERIC, Up: Top 13332 1333312 GIMPLE 13334********* 13335 13336GIMPLE is a three-address representation derived from GENERIC by 13337breaking down GENERIC expressions into tuples of no more than 3 13338operands (with some exceptions like function calls). GIMPLE was 13339heavily influenced by the SIMPLE IL used by the McCAT compiler project 13340at McGill University, though we have made some different choices. For 13341one thing, SIMPLE doesn't support `goto'. 13342 13343 Temporaries are introduced to hold intermediate values needed to 13344compute complex expressions. Additionally, all the control structures 13345used in GENERIC are lowered into conditional jumps, lexical scopes are 13346removed and exception regions are converted into an on the side 13347exception region tree. 13348 13349 The compiler pass which converts GENERIC into GIMPLE is referred to as 13350the `gimplifier'. The gimplifier works recursively, generating GIMPLE 13351tuples out of the original GENERIC expressions. 13352 13353 One of the early implementation strategies used for the GIMPLE 13354representation was to use the same internal data structures used by 13355front ends to represent parse trees. This simplified implementation 13356because we could leverage existing functionality and interfaces. 13357However, GIMPLE is a much more restrictive representation than abstract 13358syntax trees (AST), therefore it does not require the full structural 13359complexity provided by the main tree data structure. 13360 13361 The GENERIC representation of a function is stored in the 13362`DECL_SAVED_TREE' field of the associated `FUNCTION_DECL' tree node. 13363It is converted to GIMPLE by a call to `gimplify_function_tree'. 13364 13365 If a front end wants to include language-specific tree codes in the 13366tree representation which it provides to the back end, it must provide a 13367definition of `LANG_HOOKS_GIMPLIFY_EXPR' which knows how to convert the 13368front end trees to GIMPLE. Usually such a hook will involve much of 13369the same code for expanding front end trees to RTL. This function can 13370return fully lowered GIMPLE, or it can return GENERIC trees and let the 13371main gimplifier lower them the rest of the way; this is often simpler. 13372GIMPLE that is not fully lowered is known as "High GIMPLE" and consists 13373of the IL before the pass `pass_lower_cf'. High GIMPLE contains some 13374container statements like lexical scopes (represented by `GIMPLE_BIND') 13375and nested expressions (e.g., `GIMPLE_TRY'), while "Low GIMPLE" exposes 13376all of the implicit jumps for control and exception expressions 13377directly in the IL and EH region trees. 13378 13379 The C and C++ front ends currently convert directly from front end 13380trees to GIMPLE, and hand that off to the back end rather than first 13381converting to GENERIC. Their gimplifier hooks know about all the 13382`_STMT' nodes and how to convert them to GENERIC forms. There was some 13383work done on a genericization pass which would run first, but the 13384existence of `STMT_EXPR' meant that in order to convert all of the C 13385statements into GENERIC equivalents would involve walking the entire 13386tree anyway, so it was simpler to lower all the way. This might change 13387in the future if someone writes an optimization pass which would work 13388better with higher-level trees, but currently the optimizers all expect 13389GIMPLE. 13390 13391 You can request to dump a C-like representation of the GIMPLE form 13392with the flag `-fdump-tree-gimple'. 13393 13394* Menu: 13395 13396* Tuple representation:: 13397* GIMPLE instruction set:: 13398* GIMPLE Exception Handling:: 13399* Temporaries:: 13400* Operands:: 13401* Manipulating GIMPLE statements:: 13402* Tuple specific accessors:: 13403* GIMPLE sequences:: 13404* Sequence iterators:: 13405* Adding a new GIMPLE statement code:: 13406* Statement and operand traversals:: 13407 13408 13409File: gccint.info, Node: Tuple representation, Next: GIMPLE instruction set, Up: GIMPLE 13410 1341112.1 Tuple representation 13412========================= 13413 13414GIMPLE instructions are tuples of variable size divided in two groups: 13415a header describing the instruction and its locations, and a variable 13416length body with all the operands. Tuples are organized into a 13417hierarchy with 3 main classes of tuples. 13418 1341912.1.1 `gimple_statement_base' (gsbase) 13420--------------------------------------- 13421 13422This is the root of the hierarchy, it holds basic information needed by 13423most GIMPLE statements. There are some fields that may not be relevant 13424to every GIMPLE statement, but those were moved into the base structure 13425to take advantage of holes left by other fields (thus making the 13426structure more compact). The structure takes 4 words (32 bytes) on 64 13427bit hosts: 13428 13429Field Size (bits) 13430`code' 8 13431`subcode' 16 13432`no_warning' 1 13433`visited' 1 13434`nontemporal_move' 1 13435`plf' 2 13436`modified' 1 13437`has_volatile_ops' 1 13438`references_memory_p' 1 13439`uid' 32 13440`location' 32 13441`num_ops' 32 13442`bb' 64 13443`block' 63 13444Total size 32 bytes 13445 13446 * `code' Main identifier for a GIMPLE instruction. 13447 13448 * `subcode' Used to distinguish different variants of the same basic 13449 instruction or provide flags applicable to a given code. The 13450 `subcode' flags field has different uses depending on the code of 13451 the instruction, but mostly it distinguishes instructions of the 13452 same family. The most prominent use of this field is in 13453 assignments, where subcode indicates the operation done on the RHS 13454 of the assignment. For example, a = b + c is encoded as 13455 `GIMPLE_ASSIGN <PLUS_EXPR, a, b, c>'. 13456 13457 * `no_warning' Bitflag to indicate whether a warning has already 13458 been issued on this statement. 13459 13460 * `visited' General purpose "visited" marker. Set and cleared by 13461 each pass when needed. 13462 13463 * `nontemporal_move' Bitflag used in assignments that represent 13464 non-temporal moves. Although this bitflag is only used in 13465 assignments, it was moved into the base to take advantage of the 13466 bit holes left by the previous fields. 13467 13468 * `plf' Pass Local Flags. This 2-bit mask can be used as general 13469 purpose markers by any pass. Passes are responsible for clearing 13470 and setting these two flags accordingly. 13471 13472 * `modified' Bitflag to indicate whether the statement has been 13473 modified. Used mainly by the operand scanner to determine when to 13474 re-scan a statement for operands. 13475 13476 * `has_volatile_ops' Bitflag to indicate whether this statement 13477 contains operands that have been marked volatile. 13478 13479 * `references_memory_p' Bitflag to indicate whether this statement 13480 contains memory references (i.e., its operands are either global 13481 variables, or pointer dereferences or anything that must reside in 13482 memory). 13483 13484 * `uid' This is an unsigned integer used by passes that want to 13485 assign IDs to every statement. These IDs must be assigned and used 13486 by each pass. 13487 13488 * `location' This is a `location_t' identifier to specify source code 13489 location for this statement. It is inherited from the front end. 13490 13491 * `num_ops' Number of operands that this statement has. This 13492 specifies the size of the operand vector embedded in the tuple. 13493 Only used in some tuples, but it is declared in the base tuple to 13494 take advantage of the 32-bit hole left by the previous fields. 13495 13496 * `bb' Basic block holding the instruction. 13497 13498 * `block' Lexical block holding this statement. Also used for debug 13499 information generation. 13500 1350112.1.2 `gimple_statement_with_ops' 13502---------------------------------- 13503 13504This tuple is actually split in two: `gimple_statement_with_ops_base' 13505and `gimple_statement_with_ops'. This is needed to accommodate the way 13506the operand vector is allocated. The operand vector is defined to be an 13507array of 1 element. So, to allocate a dynamic number of operands, the 13508memory allocator (`gimple_alloc') simply allocates enough memory to 13509hold the structure itself plus `N - 1' operands which run "off the end" 13510of the structure. For example, to allocate space for a tuple with 3 13511operands, `gimple_alloc' reserves `sizeof (struct 13512gimple_statement_with_ops) + 2 * sizeof (tree)' bytes. 13513 13514 On the other hand, several fields in this tuple need to be shared with 13515the `gimple_statement_with_memory_ops' tuple. So, these common fields 13516are placed in `gimple_statement_with_ops_base' which is then inherited 13517from the other two tuples. 13518 13519`gsbase' 256 13520`addresses_taken' 64 13521`def_ops' 64 13522`use_ops' 64 13523`op' `num_ops' * 64 13524Total size 56 + 8 * `num_ops' bytes 13525 13526 * `gsbase' Inherited from `struct gimple_statement_base'. 13527 13528 * `addresses_taken' Bitmap holding the UIDs of all the `VAR_DECL's 13529 whose addresses are taken by this statement. For example, a 13530 statement of the form `p = &b' will have the UID for symbol `b' in 13531 this set. 13532 13533 * `def_ops' Array of pointers into the operand array indicating all 13534 the slots that contain a variable written-to by the statement. 13535 This array is also used for immediate use chaining. Note that it 13536 would be possible to not rely on this array, but the changes 13537 required to implement this are pretty invasive. 13538 13539 * `use_ops' Similar to `def_ops' but for variables read by the 13540 statement. 13541 13542 * `op' Array of trees with `num_ops' slots. 13543 1354412.1.3 `gimple_statement_with_memory_ops' 13545----------------------------------------- 13546 13547This tuple is essentially identical to `gimple_statement_with_ops', 13548except that it contains 4 additional fields to hold vectors related 13549memory stores and loads. Similar to the previous case, the structure 13550is split in two to accommodate for the operand vector 13551(`gimple_statement_with_memory_ops_base' and 13552`gimple_statement_with_memory_ops'). 13553 13554Field Size (bits) 13555`gsbase' 256 13556`addresses_taken' 64 13557`def_ops' 64 13558`use_ops' 64 13559`vdef_ops' 64 13560`vuse_ops' 64 13561`stores' 64 13562`loads' 64 13563`op' `num_ops' * 64 13564Total size 88 + 8 * `num_ops' bytes 13565 13566 * `vdef_ops' Similar to `def_ops' but for `VDEF' operators. There is 13567 one entry per memory symbol written by this statement. This is 13568 used to maintain the memory SSA use-def and def-def chains. 13569 13570 * `vuse_ops' Similar to `use_ops' but for `VUSE' operators. There is 13571 one entry per memory symbol loaded by this statement. This is used 13572 to maintain the memory SSA use-def chains. 13573 13574 * `stores' Bitset with all the UIDs for the symbols written-to by the 13575 statement. This is different than `vdef_ops' in that all the 13576 affected symbols are mentioned in this set. If memory 13577 partitioning is enabled, the `vdef_ops' vector will refer to memory 13578 partitions. Furthermore, no SSA information is stored in this set. 13579 13580 * `loads' Similar to `stores', but for memory loads. (Note that there 13581 is some amount of redundancy here, it should be possible to reduce 13582 memory utilization further by removing these sets). 13583 13584 All the other tuples are defined in terms of these three basic ones. 13585Each tuple will add some fields. The main gimple type is defined to be 13586the union of all these structures (`GTY' markers elided for clarity): 13587 13588 union gimple_statement_d 13589 { 13590 struct gimple_statement_base gsbase; 13591 struct gimple_statement_with_ops gsops; 13592 struct gimple_statement_with_memory_ops gsmem; 13593 struct gimple_statement_omp omp; 13594 struct gimple_statement_bind gimple_bind; 13595 struct gimple_statement_catch gimple_catch; 13596 struct gimple_statement_eh_filter gimple_eh_filter; 13597 struct gimple_statement_phi gimple_phi; 13598 struct gimple_statement_resx gimple_resx; 13599 struct gimple_statement_try gimple_try; 13600 struct gimple_statement_wce gimple_wce; 13601 struct gimple_statement_asm gimple_asm; 13602 struct gimple_statement_omp_critical gimple_omp_critical; 13603 struct gimple_statement_omp_for gimple_omp_for; 13604 struct gimple_statement_omp_parallel gimple_omp_parallel; 13605 struct gimple_statement_omp_task gimple_omp_task; 13606 struct gimple_statement_omp_sections gimple_omp_sections; 13607 struct gimple_statement_omp_single gimple_omp_single; 13608 struct gimple_statement_omp_continue gimple_omp_continue; 13609 struct gimple_statement_omp_atomic_load gimple_omp_atomic_load; 13610 struct gimple_statement_omp_atomic_store gimple_omp_atomic_store; 13611 }; 13612 13613 13614File: gccint.info, Node: GIMPLE instruction set, Next: GIMPLE Exception Handling, Prev: Tuple representation, Up: GIMPLE 13615 1361612.2 GIMPLE instruction set 13617=========================== 13618 13619The following table briefly describes the GIMPLE instruction set. 13620 13621Instruction High GIMPLE Low GIMPLE 13622`GIMPLE_ASM' x x 13623`GIMPLE_ASSIGN' x x 13624`GIMPLE_BIND' x 13625`GIMPLE_CALL' x x 13626`GIMPLE_CATCH' x 13627`GIMPLE_COND' x x 13628`GIMPLE_DEBUG' x x 13629`GIMPLE_EH_FILTER' x 13630`GIMPLE_GOTO' x x 13631`GIMPLE_LABEL' x x 13632`GIMPLE_NOP' x x 13633`GIMPLE_OMP_ATOMIC_LOAD' x x 13634`GIMPLE_OMP_ATOMIC_STORE' x x 13635`GIMPLE_OMP_CONTINUE' x x 13636`GIMPLE_OMP_CRITICAL' x x 13637`GIMPLE_OMP_FOR' x x 13638`GIMPLE_OMP_MASTER' x x 13639`GIMPLE_OMP_ORDERED' x x 13640`GIMPLE_OMP_PARALLEL' x x 13641`GIMPLE_OMP_RETURN' x x 13642`GIMPLE_OMP_SECTION' x x 13643`GIMPLE_OMP_SECTIONS' x x 13644`GIMPLE_OMP_SECTIONS_SWITCH' x x 13645`GIMPLE_OMP_SINGLE' x x 13646`GIMPLE_PHI' x 13647`GIMPLE_RESX' x 13648`GIMPLE_RETURN' x x 13649`GIMPLE_SWITCH' x x 13650`GIMPLE_TRY' x 13651 13652 13653File: gccint.info, Node: GIMPLE Exception Handling, Next: Temporaries, Prev: GIMPLE instruction set, Up: GIMPLE 13654 1365512.3 Exception Handling 13656======================= 13657 13658Other exception handling constructs are represented using 13659`GIMPLE_TRY_CATCH'. `GIMPLE_TRY_CATCH' has two operands. The first 13660operand is a sequence of statements to execute. If executing these 13661statements does not throw an exception, then the second operand is 13662ignored. Otherwise, if an exception is thrown, then the second operand 13663of the `GIMPLE_TRY_CATCH' is checked. The second operand may have the 13664following forms: 13665 13666 1. A sequence of statements to execute. When an exception occurs, 13667 these statements are executed, and then the exception is rethrown. 13668 13669 2. A sequence of `GIMPLE_CATCH' statements. Each `GIMPLE_CATCH' has 13670 a list of applicable exception types and handler code. If the 13671 thrown exception matches one of the caught types, the associated 13672 handler code is executed. If the handler code falls off the 13673 bottom, execution continues after the original `GIMPLE_TRY_CATCH'. 13674 13675 3. A `GIMPLE_EH_FILTER' statement. This has a list of permitted 13676 exception types, and code to handle a match failure. If the 13677 thrown exception does not match one of the allowed types, the 13678 associated match failure code is executed. If the thrown exception 13679 does match, it continues unwinding the stack looking for the next 13680 handler. 13681 13682 13683 Currently throwing an exception is not directly represented in GIMPLE, 13684since it is implemented by calling a function. At some point in the 13685future we will want to add some way to express that the call will throw 13686an exception of a known type. 13687 13688 Just before running the optimizers, the compiler lowers the high-level 13689EH constructs above into a set of `goto's, magic labels, and EH 13690regions. Continuing to unwind at the end of a cleanup is represented 13691with a `GIMPLE_RESX'. 13692 13693 13694File: gccint.info, Node: Temporaries, Next: Operands, Prev: GIMPLE Exception Handling, Up: GIMPLE 13695 1369612.4 Temporaries 13697================ 13698 13699When gimplification encounters a subexpression that is too complex, it 13700creates a new temporary variable to hold the value of the 13701subexpression, and adds a new statement to initialize it before the 13702current statement. These special temporaries are known as `expression 13703temporaries', and are allocated using `get_formal_tmp_var'. The 13704compiler tries to always evaluate identical expressions into the same 13705temporary, to simplify elimination of redundant calculations. 13706 13707 We can only use expression temporaries when we know that it will not 13708be reevaluated before its value is used, and that it will not be 13709otherwise modified(1). Other temporaries can be allocated using 13710`get_initialized_tmp_var' or `create_tmp_var'. 13711 13712 Currently, an expression like `a = b + 5' is not reduced any further. 13713We tried converting it to something like 13714 T1 = b + 5; 13715 a = T1; 13716 but this bloated the representation for minimal benefit. However, a 13717variable which must live in memory cannot appear in an expression; its 13718value is explicitly loaded into a temporary first. Similarly, storing 13719the value of an expression to a memory variable goes through a 13720temporary. 13721 13722 ---------- Footnotes ---------- 13723 13724 (1) These restrictions are derived from those in Morgan 4.8. 13725 13726 13727File: gccint.info, Node: Operands, Next: Manipulating GIMPLE statements, Prev: Temporaries, Up: GIMPLE 13728 1372912.5 Operands 13730============= 13731 13732In general, expressions in GIMPLE consist of an operation and the 13733appropriate number of simple operands; these operands must either be a 13734GIMPLE rvalue (`is_gimple_val'), i.e. a constant or a register 13735variable. More complex operands are factored out into temporaries, so 13736that 13737 a = b + c + d 13738 becomes 13739 T1 = b + c; 13740 a = T1 + d; 13741 13742 The same rule holds for arguments to a `GIMPLE_CALL'. 13743 13744 The target of an assignment is usually a variable, but can also be an 13745`INDIRECT_REF' or a compound lvalue as described below. 13746 13747* Menu: 13748 13749* Compound Expressions:: 13750* Compound Lvalues:: 13751* Conditional Expressions:: 13752* Logical Operators:: 13753 13754 13755File: gccint.info, Node: Compound Expressions, Next: Compound Lvalues, Up: Operands 13756 1375712.5.1 Compound Expressions 13758--------------------------- 13759 13760The left-hand side of a C comma expression is simply moved into a 13761separate statement. 13762 13763 13764File: gccint.info, Node: Compound Lvalues, Next: Conditional Expressions, Prev: Compound Expressions, Up: Operands 13765 1376612.5.2 Compound Lvalues 13767----------------------- 13768 13769Currently compound lvalues involving array and structure field 13770references are not broken down; an expression like `a.b[2] = 42' is not 13771reduced any further (though complex array subscripts are). This 13772restriction is a workaround for limitations in later optimizers; if we 13773were to convert this to 13774 13775 T1 = &a.b; 13776 T1[2] = 42; 13777 13778 alias analysis would not remember that the reference to `T1[2]' came 13779by way of `a.b', so it would think that the assignment could alias 13780another member of `a'; this broke `struct-alias-1.c'. Future optimizer 13781improvements may make this limitation unnecessary. 13782 13783 13784File: gccint.info, Node: Conditional Expressions, Next: Logical Operators, Prev: Compound Lvalues, Up: Operands 13785 1378612.5.3 Conditional Expressions 13787------------------------------ 13788 13789A C `?:' expression is converted into an `if' statement with each 13790branch assigning to the same temporary. So, 13791 13792 a = b ? c : d; 13793 becomes 13794 if (b == 1) 13795 T1 = c; 13796 else 13797 T1 = d; 13798 a = T1; 13799 13800 The GIMPLE level if-conversion pass re-introduces `?:' expression, if 13801appropriate. It is used to vectorize loops with conditions using vector 13802conditional operations. 13803 13804 Note that in GIMPLE, `if' statements are represented using 13805`GIMPLE_COND', as described below. 13806 13807 13808File: gccint.info, Node: Logical Operators, Prev: Conditional Expressions, Up: Operands 13809 1381012.5.4 Logical Operators 13811------------------------ 13812 13813Except when they appear in the condition operand of a `GIMPLE_COND', 13814logical `and' and `or' operators are simplified as follows: `a = b && 13815c' becomes 13816 13817 T1 = (bool)b; 13818 if (T1 == true) 13819 T1 = (bool)c; 13820 a = T1; 13821 13822 Note that `T1' in this example cannot be an expression temporary, 13823because it has two different assignments. 13824 1382512.5.5 Manipulating operands 13826---------------------------- 13827 13828All gimple operands are of type `tree'. But only certain types of 13829trees are allowed to be used as operand tuples. Basic validation is 13830controlled by the function `get_gimple_rhs_class', which given a tree 13831code, returns an `enum' with the following values of type `enum 13832gimple_rhs_class' 13833 13834 * `GIMPLE_INVALID_RHS' The tree cannot be used as a GIMPLE operand. 13835 13836 * `GIMPLE_BINARY_RHS' The tree is a valid GIMPLE binary operation. 13837 13838 * `GIMPLE_UNARY_RHS' The tree is a valid GIMPLE unary operation. 13839 13840 * `GIMPLE_SINGLE_RHS' The tree is a single object, that cannot be 13841 split into simpler operands (for instance, `SSA_NAME', `VAR_DECL', 13842 `COMPONENT_REF', etc). 13843 13844 This operand class also acts as an escape hatch for tree nodes 13845 that may be flattened out into the operand vector, but would need 13846 more than two slots on the RHS. For instance, a `COND_EXPR' 13847 expression of the form `(a op b) ? x : y' could be flattened out 13848 on the operand vector using 4 slots, but it would also require 13849 additional processing to distinguish `c = a op b' from `c = a op b 13850 ? x : y'. Something similar occurs with `ASSERT_EXPR'. In time, 13851 these special case tree expressions should be flattened into the 13852 operand vector. 13853 13854 For tree nodes in the categories `GIMPLE_BINARY_RHS' and 13855`GIMPLE_UNARY_RHS', they cannot be stored inside tuples directly. They 13856first need to be flattened and separated into individual components. 13857For instance, given the GENERIC expression 13858 13859 a = b + c 13860 13861 its tree representation is: 13862 13863 MODIFY_EXPR <VAR_DECL <a>, PLUS_EXPR <VAR_DECL <b>, VAR_DECL <c>>> 13864 13865 In this case, the GIMPLE form for this statement is logically 13866identical to its GENERIC form but in GIMPLE, the `PLUS_EXPR' on the RHS 13867of the assignment is not represented as a tree, instead the two 13868operands are taken out of the `PLUS_EXPR' sub-tree and flattened into 13869the GIMPLE tuple as follows: 13870 13871 GIMPLE_ASSIGN <PLUS_EXPR, VAR_DECL <a>, VAR_DECL <b>, VAR_DECL <c>> 13872 1387312.5.6 Operand vector allocation 13874-------------------------------- 13875 13876The operand vector is stored at the bottom of the three tuple 13877structures that accept operands. This means, that depending on the code 13878of a given statement, its operand vector will be at different offsets 13879from the base of the structure. To access tuple operands use the 13880following accessors 13881 13882 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 13883 Returns the number of operands in statement G. 13884 13885 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 13886 Returns operand `I' from statement `G'. 13887 13888 -- GIMPLE function: tree *gimple_ops (gimple g) 13889 Returns a pointer into the operand vector for statement `G'. This 13890 is computed using an internal table called `gimple_ops_offset_'[]. 13891 This table is indexed by the gimple code of `G'. 13892 13893 When the compiler is built, this table is filled-in using the 13894 sizes of the structures used by each statement code defined in 13895 gimple.def. Since the operand vector is at the bottom of the 13896 structure, for a gimple code `C' the offset is computed as sizeof 13897 (struct-of `C') - sizeof (tree). 13898 13899 This mechanism adds one memory indirection to every access when 13900 using `gimple_op'(), if this becomes a bottleneck, a pass can 13901 choose to memoize the result from `gimple_ops'() and use that to 13902 access the operands. 13903 1390412.5.7 Operand validation 13905------------------------- 13906 13907When adding a new operand to a gimple statement, the operand will be 13908validated according to what each tuple accepts in its operand vector. 13909These predicates are called by the `gimple_<name>_set_...()'. Each 13910tuple will use one of the following predicates (Note, this list is not 13911exhaustive): 13912 13913 -- GIMPLE function: is_gimple_operand (tree t) 13914 This is the most permissive of the predicates. It essentially 13915 checks whether t has a `gimple_rhs_class' of `GIMPLE_SINGLE_RHS'. 13916 13917 -- GIMPLE function: is_gimple_val (tree t) 13918 Returns true if t is a "GIMPLE value", which are all the 13919 non-addressable stack variables (variables for which 13920 `is_gimple_reg' returns true) and constants (expressions for which 13921 `is_gimple_min_invariant' returns true). 13922 13923 -- GIMPLE function: is_gimple_addressable (tree t) 13924 Returns true if t is a symbol or memory reference whose address 13925 can be taken. 13926 13927 -- GIMPLE function: is_gimple_asm_val (tree t) 13928 Similar to `is_gimple_val' but it also accepts hard registers. 13929 13930 -- GIMPLE function: is_gimple_call_addr (tree t) 13931 Return true if t is a valid expression to use as the function 13932 called by a `GIMPLE_CALL'. 13933 13934 -- GIMPLE function: is_gimple_constant (tree t) 13935 Return true if t is a valid gimple constant. 13936 13937 -- GIMPLE function: is_gimple_min_invariant (tree t) 13938 Return true if t is a valid minimal invariant. This is different 13939 from constants, in that the specific value of t may not be known 13940 at compile time, but it is known that it doesn't change (e.g., the 13941 address of a function local variable). 13942 13943 -- GIMPLE function: is_gimple_min_invariant_address (tree t) 13944 Return true if t is an `ADDR_EXPR' that does not change once a 13945 function is running. 13946 13947 -- GIMPLE function: is_gimple_ip_invariant (tree t) 13948 Return true if t is an interprocedural invariant. This means that 13949 t is a valid invariant in all functions (e.g. it can be an address 13950 of a global variable but not of a local one). 13951 13952 -- GIMPLE function: is_gimple_ip_invariant_address (tree t) 13953 Return true if t is an `ADDR_EXPR' that does not change once the 13954 program is running (and which is valid in all functions). 13955 1395612.5.8 Statement validation 13957--------------------------- 13958 13959 -- GIMPLE function: is_gimple_assign (gimple g) 13960 Return true if the code of g is `GIMPLE_ASSIGN'. 13961 13962 -- GIMPLE function: is_gimple_call (gimple g) 13963 Return true if the code of g is `GIMPLE_CALL'. 13964 13965 -- GIMPLE function: is_gimple_debug (gimple g) 13966 Return true if the code of g is `GIMPLE_DEBUG'. 13967 13968 -- GIMPLE function: gimple_assign_cast_p (gimple g) 13969 Return true if g is a `GIMPLE_ASSIGN' that performs a type cast 13970 operation. 13971 13972 -- GIMPLE function: gimple_debug_bind_p (gimple g) 13973 Return true if g is a `GIMPLE_DEBUG' that binds the value of an 13974 expression to a variable. 13975 13976 13977File: gccint.info, Node: Manipulating GIMPLE statements, Next: Tuple specific accessors, Prev: Operands, Up: GIMPLE 13978 1397912.6 Manipulating GIMPLE statements 13980=================================== 13981 13982This section documents all the functions available to handle each of 13983the GIMPLE instructions. 13984 1398512.6.1 Common accessors 13986----------------------- 13987 13988The following are common accessors for gimple statements. 13989 13990 -- GIMPLE function: enum gimple_code gimple_code (gimple g) 13991 Return the code for statement `G'. 13992 13993 -- GIMPLE function: basic_block gimple_bb (gimple g) 13994 Return the basic block to which statement `G' belongs to. 13995 13996 -- GIMPLE function: tree gimple_block (gimple g) 13997 Return the lexical scope block holding statement `G'. 13998 13999 -- GIMPLE function: tree gimple_expr_type (gimple stmt) 14000 Return the type of the main expression computed by `STMT'. Return 14001 `void_type_node' if `STMT' computes nothing. This will only return 14002 something meaningful for `GIMPLE_ASSIGN', `GIMPLE_COND' and 14003 `GIMPLE_CALL'. For all other tuple codes, it will return 14004 `void_type_node'. 14005 14006 -- GIMPLE function: enum tree_code gimple_expr_code (gimple stmt) 14007 Return the tree code for the expression computed by `STMT'. This 14008 is only meaningful for `GIMPLE_CALL', `GIMPLE_ASSIGN' and 14009 `GIMPLE_COND'. If `STMT' is `GIMPLE_CALL', it will return 14010 `CALL_EXPR'. For `GIMPLE_COND', it returns the code of the 14011 comparison predicate. For `GIMPLE_ASSIGN' it returns the code of 14012 the operation performed by the `RHS' of the assignment. 14013 14014 -- GIMPLE function: void gimple_set_block (gimple g, tree block) 14015 Set the lexical scope block of `G' to `BLOCK'. 14016 14017 -- GIMPLE function: location_t gimple_locus (gimple g) 14018 Return locus information for statement `G'. 14019 14020 -- GIMPLE function: void gimple_set_locus (gimple g, location_t locus) 14021 Set locus information for statement `G'. 14022 14023 -- GIMPLE function: bool gimple_locus_empty_p (gimple g) 14024 Return true if `G' does not have locus information. 14025 14026 -- GIMPLE function: bool gimple_no_warning_p (gimple stmt) 14027 Return true if no warnings should be emitted for statement `STMT'. 14028 14029 -- GIMPLE function: void gimple_set_visited (gimple stmt, bool 14030 visited_p) 14031 Set the visited status on statement `STMT' to `VISITED_P'. 14032 14033 -- GIMPLE function: bool gimple_visited_p (gimple stmt) 14034 Return the visited status on statement `STMT'. 14035 14036 -- GIMPLE function: void gimple_set_plf (gimple stmt, enum plf_mask 14037 plf, bool val_p) 14038 Set pass local flag `PLF' on statement `STMT' to `VAL_P'. 14039 14040 -- GIMPLE function: unsigned int gimple_plf (gimple stmt, enum 14041 plf_mask plf) 14042 Return the value of pass local flag `PLF' on statement `STMT'. 14043 14044 -- GIMPLE function: bool gimple_has_ops (gimple g) 14045 Return true if statement `G' has register or memory operands. 14046 14047 -- GIMPLE function: bool gimple_has_mem_ops (gimple g) 14048 Return true if statement `G' has memory operands. 14049 14050 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 14051 Return the number of operands for statement `G'. 14052 14053 -- GIMPLE function: tree *gimple_ops (gimple g) 14054 Return the array of operands for statement `G'. 14055 14056 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 14057 Return operand `I' for statement `G'. 14058 14059 -- GIMPLE function: tree *gimple_op_ptr (gimple g, unsigned i) 14060 Return a pointer to operand `I' for statement `G'. 14061 14062 -- GIMPLE function: void gimple_set_op (gimple g, unsigned i, tree op) 14063 Set operand `I' of statement `G' to `OP'. 14064 14065 -- GIMPLE function: bitmap gimple_addresses_taken (gimple stmt) 14066 Return the set of symbols that have had their address taken by 14067 `STMT'. 14068 14069 -- GIMPLE function: struct def_optype_d *gimple_def_ops (gimple g) 14070 Return the set of `DEF' operands for statement `G'. 14071 14072 -- GIMPLE function: void gimple_set_def_ops (gimple g, struct 14073 def_optype_d *def) 14074 Set `DEF' to be the set of `DEF' operands for statement `G'. 14075 14076 -- GIMPLE function: struct use_optype_d *gimple_use_ops (gimple g) 14077 Return the set of `USE' operands for statement `G'. 14078 14079 -- GIMPLE function: void gimple_set_use_ops (gimple g, struct 14080 use_optype_d *use) 14081 Set `USE' to be the set of `USE' operands for statement `G'. 14082 14083 -- GIMPLE function: struct voptype_d *gimple_vuse_ops (gimple g) 14084 Return the set of `VUSE' operands for statement `G'. 14085 14086 -- GIMPLE function: void gimple_set_vuse_ops (gimple g, struct 14087 voptype_d *ops) 14088 Set `OPS' to be the set of `VUSE' operands for statement `G'. 14089 14090 -- GIMPLE function: struct voptype_d *gimple_vdef_ops (gimple g) 14091 Return the set of `VDEF' operands for statement `G'. 14092 14093 -- GIMPLE function: void gimple_set_vdef_ops (gimple g, struct 14094 voptype_d *ops) 14095 Set `OPS' to be the set of `VDEF' operands for statement `G'. 14096 14097 -- GIMPLE function: bitmap gimple_loaded_syms (gimple g) 14098 Return the set of symbols loaded by statement `G'. Each element of 14099 the set is the `DECL_UID' of the corresponding symbol. 14100 14101 -- GIMPLE function: bitmap gimple_stored_syms (gimple g) 14102 Return the set of symbols stored by statement `G'. Each element of 14103 the set is the `DECL_UID' of the corresponding symbol. 14104 14105 -- GIMPLE function: bool gimple_modified_p (gimple g) 14106 Return true if statement `G' has operands and the modified field 14107 has been set. 14108 14109 -- GIMPLE function: bool gimple_has_volatile_ops (gimple stmt) 14110 Return true if statement `STMT' contains volatile operands. 14111 14112 -- GIMPLE function: void gimple_set_has_volatile_ops (gimple stmt, 14113 bool volatilep) 14114 Return true if statement `STMT' contains volatile operands. 14115 14116 -- GIMPLE function: void update_stmt (gimple s) 14117 Mark statement `S' as modified, and update it. 14118 14119 -- GIMPLE function: void update_stmt_if_modified (gimple s) 14120 Update statement `S' if it has been marked modified. 14121 14122 -- GIMPLE function: gimple gimple_copy (gimple stmt) 14123 Return a deep copy of statement `STMT'. 14124 14125 14126File: gccint.info, Node: Tuple specific accessors, Next: GIMPLE sequences, Prev: Manipulating GIMPLE statements, Up: GIMPLE 14127 1412812.7 Tuple specific accessors 14129============================= 14130 14131* Menu: 14132 14133* `GIMPLE_ASM':: 14134* `GIMPLE_ASSIGN':: 14135* `GIMPLE_BIND':: 14136* `GIMPLE_CALL':: 14137* `GIMPLE_CATCH':: 14138* `GIMPLE_COND':: 14139* `GIMPLE_DEBUG':: 14140* `GIMPLE_EH_FILTER':: 14141* `GIMPLE_LABEL':: 14142* `GIMPLE_NOP':: 14143* `GIMPLE_OMP_ATOMIC_LOAD':: 14144* `GIMPLE_OMP_ATOMIC_STORE':: 14145* `GIMPLE_OMP_CONTINUE':: 14146* `GIMPLE_OMP_CRITICAL':: 14147* `GIMPLE_OMP_FOR':: 14148* `GIMPLE_OMP_MASTER':: 14149* `GIMPLE_OMP_ORDERED':: 14150* `GIMPLE_OMP_PARALLEL':: 14151* `GIMPLE_OMP_RETURN':: 14152* `GIMPLE_OMP_SECTION':: 14153* `GIMPLE_OMP_SECTIONS':: 14154* `GIMPLE_OMP_SINGLE':: 14155* `GIMPLE_PHI':: 14156* `GIMPLE_RESX':: 14157* `GIMPLE_RETURN':: 14158* `GIMPLE_SWITCH':: 14159* `GIMPLE_TRY':: 14160* `GIMPLE_WITH_CLEANUP_EXPR':: 14161 14162 14163File: gccint.info, Node: `GIMPLE_ASM', Next: `GIMPLE_ASSIGN', Up: Tuple specific accessors 14164 1416512.7.1 `GIMPLE_ASM' 14166------------------- 14167 14168 -- GIMPLE function: gimple gimple_build_asm (const char *string, 14169 ninputs, noutputs, nclobbers, ...) 14170 Build a `GIMPLE_ASM' statement. This statement is used for 14171 building in-line assembly constructs. `STRING' is the assembly 14172 code. `NINPUT' is the number of register inputs. `NOUTPUT' is the 14173 number of register outputs. `NCLOBBERS' is the number of clobbered 14174 registers. The rest of the arguments trees for each input, 14175 output, and clobbered registers. 14176 14177 -- GIMPLE function: gimple gimple_build_asm_vec (const char *, 14178 VEC(tree,gc) *, VEC(tree,gc) *, VEC(tree,gc) *) 14179 Identical to gimple_build_asm, but the arguments are passed in 14180 VECs. 14181 14182 -- GIMPLE function: gimple_asm_ninputs (gimple g) 14183 Return the number of input operands for `GIMPLE_ASM' `G'. 14184 14185 -- GIMPLE function: gimple_asm_noutputs (gimple g) 14186 Return the number of output operands for `GIMPLE_ASM' `G'. 14187 14188 -- GIMPLE function: gimple_asm_nclobbers (gimple g) 14189 Return the number of clobber operands for `GIMPLE_ASM' `G'. 14190 14191 -- GIMPLE function: tree gimple_asm_input_op (gimple g, unsigned index) 14192 Return input operand `INDEX' of `GIMPLE_ASM' `G'. 14193 14194 -- GIMPLE function: void gimple_asm_set_input_op (gimple g, unsigned 14195 index, tree in_op) 14196 Set `IN_OP' to be input operand `INDEX' in `GIMPLE_ASM' `G'. 14197 14198 -- GIMPLE function: tree gimple_asm_output_op (gimple g, unsigned 14199 index) 14200 Return output operand `INDEX' of `GIMPLE_ASM' `G'. 14201 14202 -- GIMPLE function: void gimple_asm_set_output_op (gimple g, unsigned 14203 index, tree out_op) 14204 Set `OUT_OP' to be output operand `INDEX' in `GIMPLE_ASM' `G'. 14205 14206 -- GIMPLE function: tree gimple_asm_clobber_op (gimple g, unsigned 14207 index) 14208 Return clobber operand `INDEX' of `GIMPLE_ASM' `G'. 14209 14210 -- GIMPLE function: void gimple_asm_set_clobber_op (gimple g, unsigned 14211 index, tree clobber_op) 14212 Set `CLOBBER_OP' to be clobber operand `INDEX' in `GIMPLE_ASM' `G'. 14213 14214 -- GIMPLE function: const char *gimple_asm_string (gimple g) 14215 Return the string representing the assembly instruction in 14216 `GIMPLE_ASM' `G'. 14217 14218 -- GIMPLE function: bool gimple_asm_volatile_p (gimple g) 14219 Return true if `G' is an asm statement marked volatile. 14220 14221 -- GIMPLE function: void gimple_asm_set_volatile (gimple g) 14222 Mark asm statement `G' as volatile. 14223 14224 -- GIMPLE function: void gimple_asm_clear_volatile (gimple g) 14225 Remove volatile marker from asm statement `G'. 14226 14227 14228File: gccint.info, Node: `GIMPLE_ASSIGN', Next: `GIMPLE_BIND', Prev: `GIMPLE_ASM', Up: Tuple specific accessors 14229 1423012.7.2 `GIMPLE_ASSIGN' 14231---------------------- 14232 14233 -- GIMPLE function: gimple gimple_build_assign (tree lhs, tree rhs) 14234 Build a `GIMPLE_ASSIGN' statement. The left-hand side is an lvalue 14235 passed in lhs. The right-hand side can be either a unary or 14236 binary tree expression. The expression tree rhs will be flattened 14237 and its operands assigned to the corresponding operand slots in 14238 the new statement. This function is useful when you already have 14239 a tree expression that you want to convert into a tuple. However, 14240 try to avoid building expression trees for the sole purpose of 14241 calling this function. If you already have the operands in 14242 separate trees, it is better to use `gimple_build_assign_with_ops'. 14243 14244 -- GIMPLE function: gimple gimplify_assign (tree dst, tree src, 14245 gimple_seq *seq_p) 14246 Build a new `GIMPLE_ASSIGN' tuple and append it to the end of 14247 `*SEQ_P'. 14248 14249 `DST'/`SRC' are the destination and source respectively. You can pass 14250ungimplified trees in `DST' or `SRC', in which case they will be 14251converted to a gimple operand if necessary. 14252 14253 This function returns the newly created `GIMPLE_ASSIGN' tuple. 14254 14255 -- GIMPLE function: gimple gimple_build_assign_with_ops (enum 14256 tree_code subcode, tree lhs, tree op1, tree op2) 14257 This function is similar to `gimple_build_assign', but is used to 14258 build a `GIMPLE_ASSIGN' statement when the operands of the 14259 right-hand side of the assignment are already split into different 14260 operands. 14261 14262 The left-hand side is an lvalue passed in lhs. Subcode is the 14263 `tree_code' for the right-hand side of the assignment. Op1 and op2 14264 are the operands. If op2 is null, subcode must be a `tree_code' 14265 for a unary expression. 14266 14267 -- GIMPLE function: enum tree_code gimple_assign_rhs_code (gimple g) 14268 Return the code of the expression computed on the `RHS' of 14269 assignment statement `G'. 14270 14271 -- GIMPLE function: enum gimple_rhs_class gimple_assign_rhs_class 14272 (gimple g) 14273 Return the gimple rhs class of the code for the expression 14274 computed on the rhs of assignment statement `G'. This will never 14275 return `GIMPLE_INVALID_RHS'. 14276 14277 -- GIMPLE function: tree gimple_assign_lhs (gimple g) 14278 Return the `LHS' of assignment statement `G'. 14279 14280 -- GIMPLE function: tree *gimple_assign_lhs_ptr (gimple g) 14281 Return a pointer to the `LHS' of assignment statement `G'. 14282 14283 -- GIMPLE function: tree gimple_assign_rhs1 (gimple g) 14284 Return the first operand on the `RHS' of assignment statement `G'. 14285 14286 -- GIMPLE function: tree *gimple_assign_rhs1_ptr (gimple g) 14287 Return the address of the first operand on the `RHS' of assignment 14288 statement `G'. 14289 14290 -- GIMPLE function: tree gimple_assign_rhs2 (gimple g) 14291 Return the second operand on the `RHS' of assignment statement `G'. 14292 14293 -- GIMPLE function: tree *gimple_assign_rhs2_ptr (gimple g) 14294 Return the address of the second operand on the `RHS' of assignment 14295 statement `G'. 14296 14297 -- GIMPLE function: void gimple_assign_set_lhs (gimple g, tree lhs) 14298 Set `LHS' to be the `LHS' operand of assignment statement `G'. 14299 14300 -- GIMPLE function: void gimple_assign_set_rhs1 (gimple g, tree rhs) 14301 Set `RHS' to be the first operand on the `RHS' of assignment 14302 statement `G'. 14303 14304 -- GIMPLE function: tree gimple_assign_rhs2 (gimple g) 14305 Return the second operand on the `RHS' of assignment statement `G'. 14306 14307 -- GIMPLE function: tree *gimple_assign_rhs2_ptr (gimple g) 14308 Return a pointer to the second operand on the `RHS' of assignment 14309 statement `G'. 14310 14311 -- GIMPLE function: void gimple_assign_set_rhs2 (gimple g, tree rhs) 14312 Set `RHS' to be the second operand on the `RHS' of assignment 14313 statement `G'. 14314 14315 -- GIMPLE function: bool gimple_assign_cast_p (gimple s) 14316 Return true if `S' is a type-cast assignment. 14317 14318 14319File: gccint.info, Node: `GIMPLE_BIND', Next: `GIMPLE_CALL', Prev: `GIMPLE_ASSIGN', Up: Tuple specific accessors 14320 1432112.7.3 `GIMPLE_BIND' 14322-------------------- 14323 14324 -- GIMPLE function: gimple gimple_build_bind (tree vars, gimple_seq 14325 body) 14326 Build a `GIMPLE_BIND' statement with a list of variables in `VARS' 14327 and a body of statements in sequence `BODY'. 14328 14329 -- GIMPLE function: tree gimple_bind_vars (gimple g) 14330 Return the variables declared in the `GIMPLE_BIND' statement `G'. 14331 14332 -- GIMPLE function: void gimple_bind_set_vars (gimple g, tree vars) 14333 Set `VARS' to be the set of variables declared in the `GIMPLE_BIND' 14334 statement `G'. 14335 14336 -- GIMPLE function: void gimple_bind_append_vars (gimple g, tree vars) 14337 Append `VARS' to the set of variables declared in the `GIMPLE_BIND' 14338 statement `G'. 14339 14340 -- GIMPLE function: gimple_seq gimple_bind_body (gimple g) 14341 Return the GIMPLE sequence contained in the `GIMPLE_BIND' statement 14342 `G'. 14343 14344 -- GIMPLE function: void gimple_bind_set_body (gimple g, gimple_seq 14345 seq) 14346 Set `SEQ' to be sequence contained in the `GIMPLE_BIND' statement 14347 `G'. 14348 14349 -- GIMPLE function: void gimple_bind_add_stmt (gimple gs, gimple stmt) 14350 Append a statement to the end of a `GIMPLE_BIND''s body. 14351 14352 -- GIMPLE function: void gimple_bind_add_seq (gimple gs, gimple_seq 14353 seq) 14354 Append a sequence of statements to the end of a `GIMPLE_BIND''s 14355 body. 14356 14357 -- GIMPLE function: tree gimple_bind_block (gimple g) 14358 Return the `TREE_BLOCK' node associated with `GIMPLE_BIND' 14359 statement `G'. This is analogous to the `BIND_EXPR_BLOCK' field in 14360 trees. 14361 14362 -- GIMPLE function: void gimple_bind_set_block (gimple g, tree block) 14363 Set `BLOCK' to be the `TREE_BLOCK' node associated with 14364 `GIMPLE_BIND' statement `G'. 14365 14366 14367File: gccint.info, Node: `GIMPLE_CALL', Next: `GIMPLE_CATCH', Prev: `GIMPLE_BIND', Up: Tuple specific accessors 14368 1436912.7.4 `GIMPLE_CALL' 14370-------------------- 14371 14372 -- GIMPLE function: gimple gimple_build_call (tree fn, unsigned nargs, 14373 ...) 14374 Build a `GIMPLE_CALL' statement to function `FN'. The argument 14375 `FN' must be either a `FUNCTION_DECL' or a gimple call address as 14376 determined by `is_gimple_call_addr'. `NARGS' are the number of 14377 arguments. The rest of the arguments follow the argument `NARGS', 14378 and must be trees that are valid as rvalues in gimple (i.e., each 14379 operand is validated with `is_gimple_operand'). 14380 14381 -- GIMPLE function: gimple gimple_build_call_from_tree (tree call_expr) 14382 Build a `GIMPLE_CALL' from a `CALL_EXPR' node. The arguments and 14383 the function are taken from the expression directly. This routine 14384 assumes that `call_expr' is already in GIMPLE form. That is, its 14385 operands are GIMPLE values and the function call needs no further 14386 simplification. All the call flags in `call_expr' are copied over 14387 to the new `GIMPLE_CALL'. 14388 14389 -- GIMPLE function: gimple gimple_build_call_vec (tree fn, `VEC'(tree, 14390 heap) *args) 14391 Identical to `gimple_build_call' but the arguments are stored in a 14392 `VEC'(). 14393 14394 -- GIMPLE function: tree gimple_call_lhs (gimple g) 14395 Return the `LHS' of call statement `G'. 14396 14397 -- GIMPLE function: tree *gimple_call_lhs_ptr (gimple g) 14398 Return a pointer to the `LHS' of call statement `G'. 14399 14400 -- GIMPLE function: void gimple_call_set_lhs (gimple g, tree lhs) 14401 Set `LHS' to be the `LHS' operand of call statement `G'. 14402 14403 -- GIMPLE function: tree gimple_call_fn (gimple g) 14404 Return the tree node representing the function called by call 14405 statement `G'. 14406 14407 -- GIMPLE function: void gimple_call_set_fn (gimple g, tree fn) 14408 Set `FN' to be the function called by call statement `G'. This has 14409 to be a gimple value specifying the address of the called function. 14410 14411 -- GIMPLE function: tree gimple_call_fndecl (gimple g) 14412 If a given `GIMPLE_CALL''s callee is a `FUNCTION_DECL', return it. 14413 Otherwise return `NULL'. This function is analogous to 14414 `get_callee_fndecl' in `GENERIC'. 14415 14416 -- GIMPLE function: tree gimple_call_set_fndecl (gimple g, tree fndecl) 14417 Set the called function to `FNDECL'. 14418 14419 -- GIMPLE function: tree gimple_call_return_type (gimple g) 14420 Return the type returned by call statement `G'. 14421 14422 -- GIMPLE function: tree gimple_call_chain (gimple g) 14423 Return the static chain for call statement `G'. 14424 14425 -- GIMPLE function: void gimple_call_set_chain (gimple g, tree chain) 14426 Set `CHAIN' to be the static chain for call statement `G'. 14427 14428 -- GIMPLE function: gimple_call_num_args (gimple g) 14429 Return the number of arguments used by call statement `G'. 14430 14431 -- GIMPLE function: tree gimple_call_arg (gimple g, unsigned index) 14432 Return the argument at position `INDEX' for call statement `G'. 14433 The first argument is 0. 14434 14435 -- GIMPLE function: tree *gimple_call_arg_ptr (gimple g, unsigned 14436 index) 14437 Return a pointer to the argument at position `INDEX' for call 14438 statement `G'. 14439 14440 -- GIMPLE function: void gimple_call_set_arg (gimple g, unsigned 14441 index, tree arg) 14442 Set `ARG' to be the argument at position `INDEX' for call statement 14443 `G'. 14444 14445 -- GIMPLE function: void gimple_call_set_tail (gimple s) 14446 Mark call statement `S' as being a tail call (i.e., a call just 14447 before the exit of a function). These calls are candidate for tail 14448 call optimization. 14449 14450 -- GIMPLE function: bool gimple_call_tail_p (gimple s) 14451 Return true if `GIMPLE_CALL' `S' is marked as a tail call. 14452 14453 -- GIMPLE function: void gimple_call_mark_uninlinable (gimple s) 14454 Mark `GIMPLE_CALL' `S' as being uninlinable. 14455 14456 -- GIMPLE function: bool gimple_call_cannot_inline_p (gimple s) 14457 Return true if `GIMPLE_CALL' `S' cannot be inlined. 14458 14459 -- GIMPLE function: bool gimple_call_noreturn_p (gimple s) 14460 Return true if `S' is a noreturn call. 14461 14462 -- GIMPLE function: gimple gimple_call_copy_skip_args (gimple stmt, 14463 bitmap args_to_skip) 14464 Build a `GIMPLE_CALL' identical to `STMT' but skipping the 14465 arguments in the positions marked by the set `ARGS_TO_SKIP'. 14466 14467 14468File: gccint.info, Node: `GIMPLE_CATCH', Next: `GIMPLE_COND', Prev: `GIMPLE_CALL', Up: Tuple specific accessors 14469 1447012.7.5 `GIMPLE_CATCH' 14471--------------------- 14472 14473 -- GIMPLE function: gimple gimple_build_catch (tree types, gimple_seq 14474 handler) 14475 Build a `GIMPLE_CATCH' statement. `TYPES' are the tree types this 14476 catch handles. `HANDLER' is a sequence of statements with the code 14477 for the handler. 14478 14479 -- GIMPLE function: tree gimple_catch_types (gimple g) 14480 Return the types handled by `GIMPLE_CATCH' statement `G'. 14481 14482 -- GIMPLE function: tree *gimple_catch_types_ptr (gimple g) 14483 Return a pointer to the types handled by `GIMPLE_CATCH' statement 14484 `G'. 14485 14486 -- GIMPLE function: gimple_seq gimple_catch_handler (gimple g) 14487 Return the GIMPLE sequence representing the body of the handler of 14488 `GIMPLE_CATCH' statement `G'. 14489 14490 -- GIMPLE function: void gimple_catch_set_types (gimple g, tree t) 14491 Set `T' to be the set of types handled by `GIMPLE_CATCH' `G'. 14492 14493 -- GIMPLE function: void gimple_catch_set_handler (gimple g, 14494 gimple_seq handler) 14495 Set `HANDLER' to be the body of `GIMPLE_CATCH' `G'. 14496 14497 14498File: gccint.info, Node: `GIMPLE_COND', Next: `GIMPLE_DEBUG', Prev: `GIMPLE_CATCH', Up: Tuple specific accessors 14499 1450012.7.6 `GIMPLE_COND' 14501-------------------- 14502 14503 -- GIMPLE function: gimple gimple_build_cond (enum tree_code 14504 pred_code, tree lhs, tree rhs, tree t_label, tree f_label) 14505 Build a `GIMPLE_COND' statement. `A' `GIMPLE_COND' statement 14506 compares `LHS' and `RHS' and if the condition in `PRED_CODE' is 14507 true, jump to the label in `t_label', otherwise jump to the label 14508 in `f_label'. `PRED_CODE' are relational operator tree codes like 14509 `EQ_EXPR', `LT_EXPR', `LE_EXPR', `NE_EXPR', etc. 14510 14511 -- GIMPLE function: gimple gimple_build_cond_from_tree (tree cond, 14512 tree t_label, tree f_label) 14513 Build a `GIMPLE_COND' statement from the conditional expression 14514 tree `COND'. `T_LABEL' and `F_LABEL' are as in 14515 `gimple_build_cond'. 14516 14517 -- GIMPLE function: enum tree_code gimple_cond_code (gimple g) 14518 Return the code of the predicate computed by conditional statement 14519 `G'. 14520 14521 -- GIMPLE function: void gimple_cond_set_code (gimple g, enum 14522 tree_code code) 14523 Set `CODE' to be the predicate code for the conditional statement 14524 `G'. 14525 14526 -- GIMPLE function: tree gimple_cond_lhs (gimple g) 14527 Return the `LHS' of the predicate computed by conditional statement 14528 `G'. 14529 14530 -- GIMPLE function: void gimple_cond_set_lhs (gimple g, tree lhs) 14531 Set `LHS' to be the `LHS' operand of the predicate computed by 14532 conditional statement `G'. 14533 14534 -- GIMPLE function: tree gimple_cond_rhs (gimple g) 14535 Return the `RHS' operand of the predicate computed by conditional 14536 `G'. 14537 14538 -- GIMPLE function: void gimple_cond_set_rhs (gimple g, tree rhs) 14539 Set `RHS' to be the `RHS' operand of the predicate computed by 14540 conditional statement `G'. 14541 14542 -- GIMPLE function: tree gimple_cond_true_label (gimple g) 14543 Return the label used by conditional statement `G' when its 14544 predicate evaluates to true. 14545 14546 -- GIMPLE function: void gimple_cond_set_true_label (gimple g, tree 14547 label) 14548 Set `LABEL' to be the label used by conditional statement `G' when 14549 its predicate evaluates to true. 14550 14551 -- GIMPLE function: void gimple_cond_set_false_label (gimple g, tree 14552 label) 14553 Set `LABEL' to be the label used by conditional statement `G' when 14554 its predicate evaluates to false. 14555 14556 -- GIMPLE function: tree gimple_cond_false_label (gimple g) 14557 Return the label used by conditional statement `G' when its 14558 predicate evaluates to false. 14559 14560 -- GIMPLE function: void gimple_cond_make_false (gimple g) 14561 Set the conditional `COND_STMT' to be of the form 'if (1 == 0)'. 14562 14563 -- GIMPLE function: void gimple_cond_make_true (gimple g) 14564 Set the conditional `COND_STMT' to be of the form 'if (1 == 1)'. 14565 14566 14567File: gccint.info, Node: `GIMPLE_DEBUG', Next: `GIMPLE_EH_FILTER', Prev: `GIMPLE_COND', Up: Tuple specific accessors 14568 1456912.7.7 `GIMPLE_DEBUG' 14570--------------------- 14571 14572 -- GIMPLE function: gimple gimple_build_debug_bind (tree var, tree 14573 value, gimple stmt) 14574 Build a `GIMPLE_DEBUG' statement with `GIMPLE_DEBUG_BIND' of 14575 `subcode'. The effect of this statement is to tell debug 14576 information generation machinery that the value of user variable 14577 `var' is given by `value' at that point, and to remain with that 14578 value until `var' runs out of scope, a dynamically-subsequent 14579 debug bind statement overrides the binding, or conflicting values 14580 reach a control flow merge point. Even if components of the 14581 `value' expression change afterwards, the variable is supposed to 14582 retain the same value, though not necessarily the same location. 14583 14584 It is expected that `var' be most often a tree for automatic user 14585 variables (`VAR_DECL' or `PARM_DECL') that satisfy the 14586 requirements for gimple registers, but it may also be a tree for a 14587 scalarized component of a user variable (`ARRAY_REF', 14588 `COMPONENT_REF'), or a debug temporary (`DEBUG_EXPR_DECL'). 14589 14590 As for `value', it can be an arbitrary tree expression, but it is 14591 recommended that it be in a suitable form for a gimple assignment 14592 `RHS'. It is not expected that user variables that could appear 14593 as `var' ever appear in `value', because in the latter we'd have 14594 their `SSA_NAME's instead, but even if they were not in SSA form, 14595 user variables appearing in `value' are to be regarded as part of 14596 the executable code space, whereas those in `var' are to be 14597 regarded as part of the source code space. There is no way to 14598 refer to the value bound to a user variable within a `value' 14599 expression. 14600 14601 If `value' is `GIMPLE_DEBUG_BIND_NOVALUE', debug information 14602 generation machinery is informed that the variable `var' is 14603 unbound, i.e., that its value is indeterminate, which sometimes 14604 means it is really unavailable, and other times that the compiler 14605 could not keep track of it. 14606 14607 Block and location information for the newly-created stmt are 14608 taken from `stmt', if given. 14609 14610 -- GIMPLE function: tree gimple_debug_bind_get_var (gimple stmt) 14611 Return the user variable VAR that is bound at `stmt'. 14612 14613 -- GIMPLE function: tree gimple_debug_bind_get_value (gimple stmt) 14614 Return the value expression that is bound to a user variable at 14615 `stmt'. 14616 14617 -- GIMPLE function: tree *gimple_debug_bind_get_value_ptr (gimple stmt) 14618 Return a pointer to the value expression that is bound to a user 14619 variable at `stmt'. 14620 14621 -- GIMPLE function: void gimple_debug_bind_set_var (gimple stmt, tree 14622 var) 14623 Modify the user variable bound at `stmt' to VAR. 14624 14625 -- GIMPLE function: void gimple_debug_bind_set_value (gimple stmt, 14626 tree var) 14627 Modify the value bound to the user variable bound at `stmt' to 14628 VALUE. 14629 14630 -- GIMPLE function: void gimple_debug_bind_reset_value (gimple stmt) 14631 Modify the value bound to the user variable bound at `stmt' so 14632 that the variable becomes unbound. 14633 14634 -- GIMPLE function: bool gimple_debug_bind_has_value_p (gimple stmt) 14635 Return `TRUE' if `stmt' binds a user variable to a value, and 14636 `FALSE' if it unbinds the variable. 14637 14638 14639File: gccint.info, Node: `GIMPLE_EH_FILTER', Next: `GIMPLE_LABEL', Prev: `GIMPLE_DEBUG', Up: Tuple specific accessors 14640 1464112.7.8 `GIMPLE_EH_FILTER' 14642------------------------- 14643 14644 -- GIMPLE function: gimple gimple_build_eh_filter (tree types, 14645 gimple_seq failure) 14646 Build a `GIMPLE_EH_FILTER' statement. `TYPES' are the filter's 14647 types. `FAILURE' is a sequence with the filter's failure action. 14648 14649 -- GIMPLE function: tree gimple_eh_filter_types (gimple g) 14650 Return the types handled by `GIMPLE_EH_FILTER' statement `G'. 14651 14652 -- GIMPLE function: tree *gimple_eh_filter_types_ptr (gimple g) 14653 Return a pointer to the types handled by `GIMPLE_EH_FILTER' 14654 statement `G'. 14655 14656 -- GIMPLE function: gimple_seq gimple_eh_filter_failure (gimple g) 14657 Return the sequence of statement to execute when `GIMPLE_EH_FILTER' 14658 statement fails. 14659 14660 -- GIMPLE function: void gimple_eh_filter_set_types (gimple g, tree 14661 types) 14662 Set `TYPES' to be the set of types handled by `GIMPLE_EH_FILTER' 14663 `G'. 14664 14665 -- GIMPLE function: void gimple_eh_filter_set_failure (gimple g, 14666 gimple_seq failure) 14667 Set `FAILURE' to be the sequence of statements to execute on 14668 failure for `GIMPLE_EH_FILTER' `G'. 14669 14670 -- GIMPLE function: bool gimple_eh_filter_must_not_throw (gimple g) 14671 Return the `EH_FILTER_MUST_NOT_THROW' flag. 14672 14673 -- GIMPLE function: void gimple_eh_filter_set_must_not_throw (gimple 14674 g, bool mntp) 14675 Set the `EH_FILTER_MUST_NOT_THROW' flag. 14676 14677 14678File: gccint.info, Node: `GIMPLE_LABEL', Next: `GIMPLE_NOP', Prev: `GIMPLE_EH_FILTER', Up: Tuple specific accessors 14679 1468012.7.9 `GIMPLE_LABEL' 14681--------------------- 14682 14683 -- GIMPLE function: gimple gimple_build_label (tree label) 14684 Build a `GIMPLE_LABEL' statement with corresponding to the tree 14685 label, `LABEL'. 14686 14687 -- GIMPLE function: tree gimple_label_label (gimple g) 14688 Return the `LABEL_DECL' node used by `GIMPLE_LABEL' statement `G'. 14689 14690 -- GIMPLE function: void gimple_label_set_label (gimple g, tree label) 14691 Set `LABEL' to be the `LABEL_DECL' node used by `GIMPLE_LABEL' 14692 statement `G'. 14693 14694 -- GIMPLE function: gimple gimple_build_goto (tree dest) 14695 Build a `GIMPLE_GOTO' statement to label `DEST'. 14696 14697 -- GIMPLE function: tree gimple_goto_dest (gimple g) 14698 Return the destination of the unconditional jump `G'. 14699 14700 -- GIMPLE function: void gimple_goto_set_dest (gimple g, tree dest) 14701 Set `DEST' to be the destination of the unconditional jump `G'. 14702 14703 14704File: gccint.info, Node: `GIMPLE_NOP', Next: `GIMPLE_OMP_ATOMIC_LOAD', Prev: `GIMPLE_LABEL', Up: Tuple specific accessors 14705 1470612.7.10 `GIMPLE_NOP' 14707-------------------- 14708 14709 -- GIMPLE function: gimple gimple_build_nop (void) 14710 Build a `GIMPLE_NOP' statement. 14711 14712 -- GIMPLE function: bool gimple_nop_p (gimple g) 14713 Returns `TRUE' if statement `G' is a `GIMPLE_NOP'. 14714 14715 14716File: gccint.info, Node: `GIMPLE_OMP_ATOMIC_LOAD', Next: `GIMPLE_OMP_ATOMIC_STORE', Prev: `GIMPLE_NOP', Up: Tuple specific accessors 14717 1471812.7.11 `GIMPLE_OMP_ATOMIC_LOAD' 14719-------------------------------- 14720 14721 -- GIMPLE function: gimple gimple_build_omp_atomic_load (tree lhs, 14722 tree rhs) 14723 Build a `GIMPLE_OMP_ATOMIC_LOAD' statement. `LHS' is the left-hand 14724 side of the assignment. `RHS' is the right-hand side of the 14725 assignment. 14726 14727 -- GIMPLE function: void gimple_omp_atomic_load_set_lhs (gimple g, 14728 tree lhs) 14729 Set the `LHS' of an atomic load. 14730 14731 -- GIMPLE function: tree gimple_omp_atomic_load_lhs (gimple g) 14732 Get the `LHS' of an atomic load. 14733 14734 -- GIMPLE function: void gimple_omp_atomic_load_set_rhs (gimple g, 14735 tree rhs) 14736 Set the `RHS' of an atomic set. 14737 14738 -- GIMPLE function: tree gimple_omp_atomic_load_rhs (gimple g) 14739 Get the `RHS' of an atomic set. 14740 14741 14742File: gccint.info, Node: `GIMPLE_OMP_ATOMIC_STORE', Next: `GIMPLE_OMP_CONTINUE', Prev: `GIMPLE_OMP_ATOMIC_LOAD', Up: Tuple specific accessors 14743 1474412.7.12 `GIMPLE_OMP_ATOMIC_STORE' 14745--------------------------------- 14746 14747 -- GIMPLE function: gimple gimple_build_omp_atomic_store (tree val) 14748 Build a `GIMPLE_OMP_ATOMIC_STORE' statement. `VAL' is the value to 14749 be stored. 14750 14751 -- GIMPLE function: void gimple_omp_atomic_store_set_val (gimple g, 14752 tree val) 14753 Set the value being stored in an atomic store. 14754 14755 -- GIMPLE function: tree gimple_omp_atomic_store_val (gimple g) 14756 Return the value being stored in an atomic store. 14757 14758 14759File: gccint.info, Node: `GIMPLE_OMP_CONTINUE', Next: `GIMPLE_OMP_CRITICAL', Prev: `GIMPLE_OMP_ATOMIC_STORE', Up: Tuple specific accessors 14760 1476112.7.13 `GIMPLE_OMP_CONTINUE' 14762----------------------------- 14763 14764 -- GIMPLE function: gimple gimple_build_omp_continue (tree 14765 control_def, tree control_use) 14766 Build a `GIMPLE_OMP_CONTINUE' statement. `CONTROL_DEF' is the 14767 definition of the control variable. `CONTROL_USE' is the use of 14768 the control variable. 14769 14770 -- GIMPLE function: tree gimple_omp_continue_control_def (gimple s) 14771 Return the definition of the control variable on a 14772 `GIMPLE_OMP_CONTINUE' in `S'. 14773 14774 -- GIMPLE function: tree gimple_omp_continue_control_def_ptr (gimple s) 14775 Same as above, but return the pointer. 14776 14777 -- GIMPLE function: tree gimple_omp_continue_set_control_def (gimple s) 14778 Set the control variable definition for a `GIMPLE_OMP_CONTINUE' 14779 statement in `S'. 14780 14781 -- GIMPLE function: tree gimple_omp_continue_control_use (gimple s) 14782 Return the use of the control variable on a `GIMPLE_OMP_CONTINUE' 14783 in `S'. 14784 14785 -- GIMPLE function: tree gimple_omp_continue_control_use_ptr (gimple s) 14786 Same as above, but return the pointer. 14787 14788 -- GIMPLE function: tree gimple_omp_continue_set_control_use (gimple s) 14789 Set the control variable use for a `GIMPLE_OMP_CONTINUE' statement 14790 in `S'. 14791 14792 14793File: gccint.info, Node: `GIMPLE_OMP_CRITICAL', Next: `GIMPLE_OMP_FOR', Prev: `GIMPLE_OMP_CONTINUE', Up: Tuple specific accessors 14794 1479512.7.14 `GIMPLE_OMP_CRITICAL' 14796----------------------------- 14797 14798 -- GIMPLE function: gimple gimple_build_omp_critical (gimple_seq body, 14799 tree name) 14800 Build a `GIMPLE_OMP_CRITICAL' statement. `BODY' is the sequence of 14801 statements for which only one thread can execute. `NAME' is an 14802 optional identifier for this critical block. 14803 14804 -- GIMPLE function: tree gimple_omp_critical_name (gimple g) 14805 Return the name associated with `OMP_CRITICAL' statement `G'. 14806 14807 -- GIMPLE function: tree *gimple_omp_critical_name_ptr (gimple g) 14808 Return a pointer to the name associated with `OMP' critical 14809 statement `G'. 14810 14811 -- GIMPLE function: void gimple_omp_critical_set_name (gimple g, tree 14812 name) 14813 Set `NAME' to be the name associated with `OMP' critical statement 14814 `G'. 14815 14816 14817File: gccint.info, Node: `GIMPLE_OMP_FOR', Next: `GIMPLE_OMP_MASTER', Prev: `GIMPLE_OMP_CRITICAL', Up: Tuple specific accessors 14818 1481912.7.15 `GIMPLE_OMP_FOR' 14820------------------------ 14821 14822 -- GIMPLE function: gimple gimple_build_omp_for (gimple_seq body, tree 14823 clauses, tree index, tree initial, tree final, tree incr, 14824 gimple_seq pre_body, enum tree_code omp_for_cond) 14825 Build a `GIMPLE_OMP_FOR' statement. `BODY' is sequence of 14826 statements inside the for loop. `CLAUSES', are any of the `OMP' 14827 loop construct's clauses: private, firstprivate, lastprivate, 14828 reductions, ordered, schedule, and nowait. `PRE_BODY' is the 14829 sequence of statements that are loop invariant. `INDEX' is the 14830 index variable. `INITIAL' is the initial value of `INDEX'. 14831 `FINAL' is final value of `INDEX'. OMP_FOR_COND is the predicate 14832 used to compare `INDEX' and `FINAL'. `INCR' is the increment 14833 expression. 14834 14835 -- GIMPLE function: tree gimple_omp_for_clauses (gimple g) 14836 Return the clauses associated with `OMP_FOR' `G'. 14837 14838 -- GIMPLE function: tree *gimple_omp_for_clauses_ptr (gimple g) 14839 Return a pointer to the `OMP_FOR' `G'. 14840 14841 -- GIMPLE function: void gimple_omp_for_set_clauses (gimple g, tree 14842 clauses) 14843 Set `CLAUSES' to be the list of clauses associated with `OMP_FOR' 14844 `G'. 14845 14846 -- GIMPLE function: tree gimple_omp_for_index (gimple g) 14847 Return the index variable for `OMP_FOR' `G'. 14848 14849 -- GIMPLE function: tree *gimple_omp_for_index_ptr (gimple g) 14850 Return a pointer to the index variable for `OMP_FOR' `G'. 14851 14852 -- GIMPLE function: void gimple_omp_for_set_index (gimple g, tree 14853 index) 14854 Set `INDEX' to be the index variable for `OMP_FOR' `G'. 14855 14856 -- GIMPLE function: tree gimple_omp_for_initial (gimple g) 14857 Return the initial value for `OMP_FOR' `G'. 14858 14859 -- GIMPLE function: tree *gimple_omp_for_initial_ptr (gimple g) 14860 Return a pointer to the initial value for `OMP_FOR' `G'. 14861 14862 -- GIMPLE function: void gimple_omp_for_set_initial (gimple g, tree 14863 initial) 14864 Set `INITIAL' to be the initial value for `OMP_FOR' `G'. 14865 14866 -- GIMPLE function: tree gimple_omp_for_final (gimple g) 14867 Return the final value for `OMP_FOR' `G'. 14868 14869 -- GIMPLE function: tree *gimple_omp_for_final_ptr (gimple g) 14870 turn a pointer to the final value for `OMP_FOR' `G'. 14871 14872 -- GIMPLE function: void gimple_omp_for_set_final (gimple g, tree 14873 final) 14874 Set `FINAL' to be the final value for `OMP_FOR' `G'. 14875 14876 -- GIMPLE function: tree gimple_omp_for_incr (gimple g) 14877 Return the increment value for `OMP_FOR' `G'. 14878 14879 -- GIMPLE function: tree *gimple_omp_for_incr_ptr (gimple g) 14880 Return a pointer to the increment value for `OMP_FOR' `G'. 14881 14882 -- GIMPLE function: void gimple_omp_for_set_incr (gimple g, tree incr) 14883 Set `INCR' to be the increment value for `OMP_FOR' `G'. 14884 14885 -- GIMPLE function: gimple_seq gimple_omp_for_pre_body (gimple g) 14886 Return the sequence of statements to execute before the `OMP_FOR' 14887 statement `G' starts. 14888 14889 -- GIMPLE function: void gimple_omp_for_set_pre_body (gimple g, 14890 gimple_seq pre_body) 14891 Set `PRE_BODY' to be the sequence of statements to execute before 14892 the `OMP_FOR' statement `G' starts. 14893 14894 -- GIMPLE function: void gimple_omp_for_set_cond (gimple g, enum 14895 tree_code cond) 14896 Set `COND' to be the condition code for `OMP_FOR' `G'. 14897 14898 -- GIMPLE function: enum tree_code gimple_omp_for_cond (gimple g) 14899 Return the condition code associated with `OMP_FOR' `G'. 14900 14901 14902File: gccint.info, Node: `GIMPLE_OMP_MASTER', Next: `GIMPLE_OMP_ORDERED', Prev: `GIMPLE_OMP_FOR', Up: Tuple specific accessors 14903 1490412.7.16 `GIMPLE_OMP_MASTER' 14905--------------------------- 14906 14907 -- GIMPLE function: gimple gimple_build_omp_master (gimple_seq body) 14908 Build a `GIMPLE_OMP_MASTER' statement. `BODY' is the sequence of 14909 statements to be executed by just the master. 14910 14911 14912File: gccint.info, Node: `GIMPLE_OMP_ORDERED', Next: `GIMPLE_OMP_PARALLEL', Prev: `GIMPLE_OMP_MASTER', Up: Tuple specific accessors 14913 1491412.7.17 `GIMPLE_OMP_ORDERED' 14915---------------------------- 14916 14917 -- GIMPLE function: gimple gimple_build_omp_ordered (gimple_seq body) 14918 Build a `GIMPLE_OMP_ORDERED' statement. 14919 14920 `BODY' is the sequence of statements inside a loop that will executed 14921in sequence. 14922 14923 14924File: gccint.info, Node: `GIMPLE_OMP_PARALLEL', Next: `GIMPLE_OMP_RETURN', Prev: `GIMPLE_OMP_ORDERED', Up: Tuple specific accessors 14925 1492612.7.18 `GIMPLE_OMP_PARALLEL' 14927----------------------------- 14928 14929 -- GIMPLE function: gimple gimple_build_omp_parallel (gimple_seq body, 14930 tree clauses, tree child_fn, tree data_arg) 14931 Build a `GIMPLE_OMP_PARALLEL' statement. 14932 14933 `BODY' is sequence of statements which are executed in parallel. 14934`CLAUSES', are the `OMP' parallel construct's clauses. `CHILD_FN' is 14935the function created for the parallel threads to execute. `DATA_ARG' 14936are the shared data argument(s). 14937 14938 -- GIMPLE function: bool gimple_omp_parallel_combined_p (gimple g) 14939 Return true if `OMP' parallel statement `G' has the 14940 `GF_OMP_PARALLEL_COMBINED' flag set. 14941 14942 -- GIMPLE function: void gimple_omp_parallel_set_combined_p (gimple g) 14943 Set the `GF_OMP_PARALLEL_COMBINED' field in `OMP' parallel 14944 statement `G'. 14945 14946 -- GIMPLE function: gimple_seq gimple_omp_body (gimple g) 14947 Return the body for the `OMP' statement `G'. 14948 14949 -- GIMPLE function: void gimple_omp_set_body (gimple g, gimple_seq 14950 body) 14951 Set `BODY' to be the body for the `OMP' statement `G'. 14952 14953 -- GIMPLE function: tree gimple_omp_parallel_clauses (gimple g) 14954 Return the clauses associated with `OMP_PARALLEL' `G'. 14955 14956 -- GIMPLE function: tree *gimple_omp_parallel_clauses_ptr (gimple g) 14957 Return a pointer to the clauses associated with `OMP_PARALLEL' `G'. 14958 14959 -- GIMPLE function: void gimple_omp_parallel_set_clauses (gimple g, 14960 tree clauses) 14961 Set `CLAUSES' to be the list of clauses associated with 14962 `OMP_PARALLEL' `G'. 14963 14964 -- GIMPLE function: tree gimple_omp_parallel_child_fn (gimple g) 14965 Return the child function used to hold the body of `OMP_PARALLEL' 14966 `G'. 14967 14968 -- GIMPLE function: tree *gimple_omp_parallel_child_fn_ptr (gimple g) 14969 Return a pointer to the child function used to hold the body of 14970 `OMP_PARALLEL' `G'. 14971 14972 -- GIMPLE function: void gimple_omp_parallel_set_child_fn (gimple g, 14973 tree child_fn) 14974 Set `CHILD_FN' to be the child function for `OMP_PARALLEL' `G'. 14975 14976 -- GIMPLE function: tree gimple_omp_parallel_data_arg (gimple g) 14977 Return the artificial argument used to send variables and values 14978 from the parent to the children threads in `OMP_PARALLEL' `G'. 14979 14980 -- GIMPLE function: tree *gimple_omp_parallel_data_arg_ptr (gimple g) 14981 Return a pointer to the data argument for `OMP_PARALLEL' `G'. 14982 14983 -- GIMPLE function: void gimple_omp_parallel_set_data_arg (gimple g, 14984 tree data_arg) 14985 Set `DATA_ARG' to be the data argument for `OMP_PARALLEL' `G'. 14986 14987 -- GIMPLE function: bool is_gimple_omp (gimple stmt) 14988 Returns true when the gimple statement `STMT' is any of the OpenMP 14989 types. 14990 14991 14992File: gccint.info, Node: `GIMPLE_OMP_RETURN', Next: `GIMPLE_OMP_SECTION', Prev: `GIMPLE_OMP_PARALLEL', Up: Tuple specific accessors 14993 1499412.7.19 `GIMPLE_OMP_RETURN' 14995--------------------------- 14996 14997 -- GIMPLE function: gimple gimple_build_omp_return (bool wait_p) 14998 Build a `GIMPLE_OMP_RETURN' statement. `WAIT_P' is true if this is 14999 a non-waiting return. 15000 15001 -- GIMPLE function: void gimple_omp_return_set_nowait (gimple s) 15002 Set the nowait flag on `GIMPLE_OMP_RETURN' statement `S'. 15003 15004 -- GIMPLE function: bool gimple_omp_return_nowait_p (gimple g) 15005 Return true if `OMP' return statement `G' has the 15006 `GF_OMP_RETURN_NOWAIT' flag set. 15007 15008 15009File: gccint.info, Node: `GIMPLE_OMP_SECTION', Next: `GIMPLE_OMP_SECTIONS', Prev: `GIMPLE_OMP_RETURN', Up: Tuple specific accessors 15010 1501112.7.20 `GIMPLE_OMP_SECTION' 15012---------------------------- 15013 15014 -- GIMPLE function: gimple gimple_build_omp_section (gimple_seq body) 15015 Build a `GIMPLE_OMP_SECTION' statement for a sections statement. 15016 15017 `BODY' is the sequence of statements in the section. 15018 15019 -- GIMPLE function: bool gimple_omp_section_last_p (gimple g) 15020 Return true if `OMP' section statement `G' has the 15021 `GF_OMP_SECTION_LAST' flag set. 15022 15023 -- GIMPLE function: void gimple_omp_section_set_last (gimple g) 15024 Set the `GF_OMP_SECTION_LAST' flag on `G'. 15025 15026 15027File: gccint.info, Node: `GIMPLE_OMP_SECTIONS', Next: `GIMPLE_OMP_SINGLE', Prev: `GIMPLE_OMP_SECTION', Up: Tuple specific accessors 15028 1502912.7.21 `GIMPLE_OMP_SECTIONS' 15030----------------------------- 15031 15032 -- GIMPLE function: gimple gimple_build_omp_sections (gimple_seq body, 15033 tree clauses) 15034 Build a `GIMPLE_OMP_SECTIONS' statement. `BODY' is a sequence of 15035 section statements. `CLAUSES' are any of the `OMP' sections 15036 construct's clauses: private, firstprivate, lastprivate, 15037 reduction, and nowait. 15038 15039 -- GIMPLE function: gimple gimple_build_omp_sections_switch (void) 15040 Build a `GIMPLE_OMP_SECTIONS_SWITCH' statement. 15041 15042 -- GIMPLE function: tree gimple_omp_sections_control (gimple g) 15043 Return the control variable associated with the 15044 `GIMPLE_OMP_SECTIONS' in `G'. 15045 15046 -- GIMPLE function: tree *gimple_omp_sections_control_ptr (gimple g) 15047 Return a pointer to the clauses associated with the 15048 `GIMPLE_OMP_SECTIONS' in `G'. 15049 15050 -- GIMPLE function: void gimple_omp_sections_set_control (gimple g, 15051 tree control) 15052 Set `CONTROL' to be the set of clauses associated with the 15053 `GIMPLE_OMP_SECTIONS' in `G'. 15054 15055 -- GIMPLE function: tree gimple_omp_sections_clauses (gimple g) 15056 Return the clauses associated with `OMP_SECTIONS' `G'. 15057 15058 -- GIMPLE function: tree *gimple_omp_sections_clauses_ptr (gimple g) 15059 Return a pointer to the clauses associated with `OMP_SECTIONS' `G'. 15060 15061 -- GIMPLE function: void gimple_omp_sections_set_clauses (gimple g, 15062 tree clauses) 15063 Set `CLAUSES' to be the set of clauses associated with 15064 `OMP_SECTIONS' `G'. 15065 15066 15067File: gccint.info, Node: `GIMPLE_OMP_SINGLE', Next: `GIMPLE_PHI', Prev: `GIMPLE_OMP_SECTIONS', Up: Tuple specific accessors 15068 1506912.7.22 `GIMPLE_OMP_SINGLE' 15070--------------------------- 15071 15072 -- GIMPLE function: gimple gimple_build_omp_single (gimple_seq body, 15073 tree clauses) 15074 Build a `GIMPLE_OMP_SINGLE' statement. `BODY' is the sequence of 15075 statements that will be executed once. `CLAUSES' are any of the 15076 `OMP' single construct's clauses: private, firstprivate, 15077 copyprivate, nowait. 15078 15079 -- GIMPLE function: tree gimple_omp_single_clauses (gimple g) 15080 Return the clauses associated with `OMP_SINGLE' `G'. 15081 15082 -- GIMPLE function: tree *gimple_omp_single_clauses_ptr (gimple g) 15083 Return a pointer to the clauses associated with `OMP_SINGLE' `G'. 15084 15085 -- GIMPLE function: void gimple_omp_single_set_clauses (gimple g, tree 15086 clauses) 15087 Set `CLAUSES' to be the clauses associated with `OMP_SINGLE' `G'. 15088 15089 15090File: gccint.info, Node: `GIMPLE_PHI', Next: `GIMPLE_RESX', Prev: `GIMPLE_OMP_SINGLE', Up: Tuple specific accessors 15091 1509212.7.23 `GIMPLE_PHI' 15093-------------------- 15094 15095 -- GIMPLE function: gimple make_phi_node (tree var, int len) 15096 Build a `PHI' node with len argument slots for variable var. 15097 15098 -- GIMPLE function: unsigned gimple_phi_capacity (gimple g) 15099 Return the maximum number of arguments supported by `GIMPLE_PHI' 15100 `G'. 15101 15102 -- GIMPLE function: unsigned gimple_phi_num_args (gimple g) 15103 Return the number of arguments in `GIMPLE_PHI' `G'. This must 15104 always be exactly the number of incoming edges for the basic block 15105 holding `G'. 15106 15107 -- GIMPLE function: tree gimple_phi_result (gimple g) 15108 Return the `SSA' name created by `GIMPLE_PHI' `G'. 15109 15110 -- GIMPLE function: tree *gimple_phi_result_ptr (gimple g) 15111 Return a pointer to the `SSA' name created by `GIMPLE_PHI' `G'. 15112 15113 -- GIMPLE function: void gimple_phi_set_result (gimple g, tree result) 15114 Set `RESULT' to be the `SSA' name created by `GIMPLE_PHI' `G'. 15115 15116 -- GIMPLE function: struct phi_arg_d *gimple_phi_arg (gimple g, index) 15117 Return the `PHI' argument corresponding to incoming edge `INDEX' 15118 for `GIMPLE_PHI' `G'. 15119 15120 -- GIMPLE function: void gimple_phi_set_arg (gimple g, index, struct 15121 phi_arg_d * phiarg) 15122 Set `PHIARG' to be the argument corresponding to incoming edge 15123 `INDEX' for `GIMPLE_PHI' `G'. 15124 15125 15126File: gccint.info, Node: `GIMPLE_RESX', Next: `GIMPLE_RETURN', Prev: `GIMPLE_PHI', Up: Tuple specific accessors 15127 1512812.7.24 `GIMPLE_RESX' 15129--------------------- 15130 15131 -- GIMPLE function: gimple gimple_build_resx (int region) 15132 Build a `GIMPLE_RESX' statement which is a statement. This 15133 statement is a placeholder for _Unwind_Resume before we know if a 15134 function call or a branch is needed. `REGION' is the exception 15135 region from which control is flowing. 15136 15137 -- GIMPLE function: int gimple_resx_region (gimple g) 15138 Return the region number for `GIMPLE_RESX' `G'. 15139 15140 -- GIMPLE function: void gimple_resx_set_region (gimple g, int region) 15141 Set `REGION' to be the region number for `GIMPLE_RESX' `G'. 15142 15143 15144File: gccint.info, Node: `GIMPLE_RETURN', Next: `GIMPLE_SWITCH', Prev: `GIMPLE_RESX', Up: Tuple specific accessors 15145 1514612.7.25 `GIMPLE_RETURN' 15147----------------------- 15148 15149 -- GIMPLE function: gimple gimple_build_return (tree retval) 15150 Build a `GIMPLE_RETURN' statement whose return value is retval. 15151 15152 -- GIMPLE function: tree gimple_return_retval (gimple g) 15153 Return the return value for `GIMPLE_RETURN' `G'. 15154 15155 -- GIMPLE function: void gimple_return_set_retval (gimple g, tree 15156 retval) 15157 Set `RETVAL' to be the return value for `GIMPLE_RETURN' `G'. 15158 15159 15160File: gccint.info, Node: `GIMPLE_SWITCH', Next: `GIMPLE_TRY', Prev: `GIMPLE_RETURN', Up: Tuple specific accessors 15161 1516212.7.26 `GIMPLE_SWITCH' 15163----------------------- 15164 15165 -- GIMPLE function: gimple gimple_build_switch ( nlabels, tree index, 15166 tree default_label, ...) 15167 Build a `GIMPLE_SWITCH' statement. `NLABELS' are the number of 15168 labels excluding the default label. The default label is passed 15169 in `DEFAULT_LABEL'. The rest of the arguments are trees 15170 representing the labels. Each label is a tree of code 15171 `CASE_LABEL_EXPR'. 15172 15173 -- GIMPLE function: gimple gimple_build_switch_vec (tree index, tree 15174 default_label, `VEC'(tree,heap) *args) 15175 This function is an alternate way of building `GIMPLE_SWITCH' 15176 statements. `INDEX' and `DEFAULT_LABEL' are as in 15177 gimple_build_switch. `ARGS' is a vector of `CASE_LABEL_EXPR' trees 15178 that contain the labels. 15179 15180 -- GIMPLE function: unsigned gimple_switch_num_labels (gimple g) 15181 Return the number of labels associated with the switch statement 15182 `G'. 15183 15184 -- GIMPLE function: void gimple_switch_set_num_labels (gimple g, 15185 unsigned nlabels) 15186 Set `NLABELS' to be the number of labels for the switch statement 15187 `G'. 15188 15189 -- GIMPLE function: tree gimple_switch_index (gimple g) 15190 Return the index variable used by the switch statement `G'. 15191 15192 -- GIMPLE function: void gimple_switch_set_index (gimple g, tree index) 15193 Set `INDEX' to be the index variable for switch statement `G'. 15194 15195 -- GIMPLE function: tree gimple_switch_label (gimple g, unsigned index) 15196 Return the label numbered `INDEX'. The default label is 0, followed 15197 by any labels in a switch statement. 15198 15199 -- GIMPLE function: void gimple_switch_set_label (gimple g, unsigned 15200 index, tree label) 15201 Set the label number `INDEX' to `LABEL'. 0 is always the default 15202 label. 15203 15204 -- GIMPLE function: tree gimple_switch_default_label (gimple g) 15205 Return the default label for a switch statement. 15206 15207 -- GIMPLE function: void gimple_switch_set_default_label (gimple g, 15208 tree label) 15209 Set the default label for a switch statement. 15210 15211 15212File: gccint.info, Node: `GIMPLE_TRY', Next: `GIMPLE_WITH_CLEANUP_EXPR', Prev: `GIMPLE_SWITCH', Up: Tuple specific accessors 15213 1521412.7.27 `GIMPLE_TRY' 15215-------------------- 15216 15217 -- GIMPLE function: gimple gimple_build_try (gimple_seq eval, 15218 gimple_seq cleanup, unsigned int kind) 15219 Build a `GIMPLE_TRY' statement. `EVAL' is a sequence with the 15220 expression to evaluate. `CLEANUP' is a sequence of statements to 15221 run at clean-up time. `KIND' is the enumeration value 15222 `GIMPLE_TRY_CATCH' if this statement denotes a try/catch construct 15223 or `GIMPLE_TRY_FINALLY' if this statement denotes a try/finally 15224 construct. 15225 15226 -- GIMPLE function: enum gimple_try_flags gimple_try_kind (gimple g) 15227 Return the kind of try block represented by `GIMPLE_TRY' `G'. This 15228 is either `GIMPLE_TRY_CATCH' or `GIMPLE_TRY_FINALLY'. 15229 15230 -- GIMPLE function: bool gimple_try_catch_is_cleanup (gimple g) 15231 Return the `GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 15232 15233 -- GIMPLE function: gimple_seq gimple_try_eval (gimple g) 15234 Return the sequence of statements used as the body for `GIMPLE_TRY' 15235 `G'. 15236 15237 -- GIMPLE function: gimple_seq gimple_try_cleanup (gimple g) 15238 Return the sequence of statements used as the cleanup body for 15239 `GIMPLE_TRY' `G'. 15240 15241 -- GIMPLE function: void gimple_try_set_catch_is_cleanup (gimple g, 15242 bool catch_is_cleanup) 15243 Set the `GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 15244 15245 -- GIMPLE function: void gimple_try_set_eval (gimple g, gimple_seq 15246 eval) 15247 Set `EVAL' to be the sequence of statements to use as the body for 15248 `GIMPLE_TRY' `G'. 15249 15250 -- GIMPLE function: void gimple_try_set_cleanup (gimple g, gimple_seq 15251 cleanup) 15252 Set `CLEANUP' to be the sequence of statements to use as the 15253 cleanup body for `GIMPLE_TRY' `G'. 15254 15255 15256File: gccint.info, Node: `GIMPLE_WITH_CLEANUP_EXPR', Prev: `GIMPLE_TRY', Up: Tuple specific accessors 15257 1525812.7.28 `GIMPLE_WITH_CLEANUP_EXPR' 15259---------------------------------- 15260 15261 -- GIMPLE function: gimple gimple_build_wce (gimple_seq cleanup) 15262 Build a `GIMPLE_WITH_CLEANUP_EXPR' statement. `CLEANUP' is the 15263 clean-up expression. 15264 15265 -- GIMPLE function: gimple_seq gimple_wce_cleanup (gimple g) 15266 Return the cleanup sequence for cleanup statement `G'. 15267 15268 -- GIMPLE function: void gimple_wce_set_cleanup (gimple g, gimple_seq 15269 cleanup) 15270 Set `CLEANUP' to be the cleanup sequence for `G'. 15271 15272 -- GIMPLE function: bool gimple_wce_cleanup_eh_only (gimple g) 15273 Return the `CLEANUP_EH_ONLY' flag for a `WCE' tuple. 15274 15275 -- GIMPLE function: void gimple_wce_set_cleanup_eh_only (gimple g, 15276 bool eh_only_p) 15277 Set the `CLEANUP_EH_ONLY' flag for a `WCE' tuple. 15278 15279 15280File: gccint.info, Node: GIMPLE sequences, Next: Sequence iterators, Prev: Tuple specific accessors, Up: GIMPLE 15281 1528212.8 GIMPLE sequences 15283===================== 15284 15285GIMPLE sequences are the tuple equivalent of `STATEMENT_LIST''s used in 15286`GENERIC'. They are used to chain statements together, and when used 15287in conjunction with sequence iterators, provide a framework for 15288iterating through statements. 15289 15290 GIMPLE sequences are of type struct `gimple_sequence', but are more 15291commonly passed by reference to functions dealing with sequences. The 15292type for a sequence pointer is `gimple_seq' which is the same as struct 15293`gimple_sequence' *. When declaring a local sequence, you can define a 15294local variable of type struct `gimple_sequence'. When declaring a 15295sequence allocated on the garbage collected heap, use the function 15296`gimple_seq_alloc' documented below. 15297 15298 There are convenience functions for iterating through sequences in the 15299section entitled Sequence Iterators. 15300 15301 Below is a list of functions to manipulate and query sequences. 15302 15303 -- GIMPLE function: void gimple_seq_add_stmt (gimple_seq *seq, gimple 15304 g) 15305 Link a gimple statement to the end of the sequence *`SEQ' if `G' is 15306 not `NULL'. If *`SEQ' is `NULL', allocate a sequence before 15307 linking. 15308 15309 -- GIMPLE function: void gimple_seq_add_seq (gimple_seq *dest, 15310 gimple_seq src) 15311 Append sequence `SRC' to the end of sequence *`DEST' if `SRC' is 15312 not `NULL'. If *`DEST' is `NULL', allocate a new sequence before 15313 appending. 15314 15315 -- GIMPLE function: gimple_seq gimple_seq_deep_copy (gimple_seq src) 15316 Perform a deep copy of sequence `SRC' and return the result. 15317 15318 -- GIMPLE function: gimple_seq gimple_seq_reverse (gimple_seq seq) 15319 Reverse the order of the statements in the sequence `SEQ'. Return 15320 `SEQ'. 15321 15322 -- GIMPLE function: gimple gimple_seq_first (gimple_seq s) 15323 Return the first statement in sequence `S'. 15324 15325 -- GIMPLE function: gimple gimple_seq_last (gimple_seq s) 15326 Return the last statement in sequence `S'. 15327 15328 -- GIMPLE function: void gimple_seq_set_last (gimple_seq s, gimple 15329 last) 15330 Set the last statement in sequence `S' to the statement in `LAST'. 15331 15332 -- GIMPLE function: void gimple_seq_set_first (gimple_seq s, gimple 15333 first) 15334 Set the first statement in sequence `S' to the statement in 15335 `FIRST'. 15336 15337 -- GIMPLE function: void gimple_seq_init (gimple_seq s) 15338 Initialize sequence `S' to an empty sequence. 15339 15340 -- GIMPLE function: gimple_seq gimple_seq_alloc (void) 15341 Allocate a new sequence in the garbage collected store and return 15342 it. 15343 15344 -- GIMPLE function: void gimple_seq_copy (gimple_seq dest, gimple_seq 15345 src) 15346 Copy the sequence `SRC' into the sequence `DEST'. 15347 15348 -- GIMPLE function: bool gimple_seq_empty_p (gimple_seq s) 15349 Return true if the sequence `S' is empty. 15350 15351 -- GIMPLE function: gimple_seq bb_seq (basic_block bb) 15352 Returns the sequence of statements in `BB'. 15353 15354 -- GIMPLE function: void set_bb_seq (basic_block bb, gimple_seq seq) 15355 Sets the sequence of statements in `BB' to `SEQ'. 15356 15357 -- GIMPLE function: bool gimple_seq_singleton_p (gimple_seq seq) 15358 Determine whether `SEQ' contains exactly one statement. 15359 15360 15361File: gccint.info, Node: Sequence iterators, Next: Adding a new GIMPLE statement code, Prev: GIMPLE sequences, Up: GIMPLE 15362 1536312.9 Sequence iterators 15364======================= 15365 15366Sequence iterators are convenience constructs for iterating through 15367statements in a sequence. Given a sequence `SEQ', here is a typical 15368use of gimple sequence iterators: 15369 15370 gimple_stmt_iterator gsi; 15371 15372 for (gsi = gsi_start (seq); !gsi_end_p (gsi); gsi_next (&gsi)) 15373 { 15374 gimple g = gsi_stmt (gsi); 15375 /* Do something with gimple statement `G'. */ 15376 } 15377 15378 Backward iterations are possible: 15379 15380 for (gsi = gsi_last (seq); !gsi_end_p (gsi); gsi_prev (&gsi)) 15381 15382 Forward and backward iterations on basic blocks are possible with 15383`gsi_start_bb' and `gsi_last_bb'. 15384 15385 In the documentation below we sometimes refer to enum 15386`gsi_iterator_update'. The valid options for this enumeration are: 15387 15388 * `GSI_NEW_STMT' Only valid when a single statement is added. Move 15389 the iterator to it. 15390 15391 * `GSI_SAME_STMT' Leave the iterator at the same statement. 15392 15393 * `GSI_CONTINUE_LINKING' Move iterator to whatever position is 15394 suitable for linking other statements in the same direction. 15395 15396 Below is a list of the functions used to manipulate and use statement 15397iterators. 15398 15399 -- GIMPLE function: gimple_stmt_iterator gsi_start (gimple_seq seq) 15400 Return a new iterator pointing to the sequence `SEQ''s first 15401 statement. If `SEQ' is empty, the iterator's basic block is 15402 `NULL'. Use `gsi_start_bb' instead when the iterator needs to 15403 always have the correct basic block set. 15404 15405 -- GIMPLE function: gimple_stmt_iterator gsi_start_bb (basic_block bb) 15406 Return a new iterator pointing to the first statement in basic 15407 block `BB'. 15408 15409 -- GIMPLE function: gimple_stmt_iterator gsi_last (gimple_seq seq) 15410 Return a new iterator initially pointing to the last statement of 15411 sequence `SEQ'. If `SEQ' is empty, the iterator's basic block is 15412 `NULL'. Use `gsi_last_bb' instead when the iterator needs to 15413 always have the correct basic block set. 15414 15415 -- GIMPLE function: gimple_stmt_iterator gsi_last_bb (basic_block bb) 15416 Return a new iterator pointing to the last statement in basic 15417 block `BB'. 15418 15419 -- GIMPLE function: bool gsi_end_p (gimple_stmt_iterator i) 15420 Return `TRUE' if at the end of `I'. 15421 15422 -- GIMPLE function: bool gsi_one_before_end_p (gimple_stmt_iterator i) 15423 Return `TRUE' if we're one statement before the end of `I'. 15424 15425 -- GIMPLE function: void gsi_next (gimple_stmt_iterator *i) 15426 Advance the iterator to the next gimple statement. 15427 15428 -- GIMPLE function: void gsi_prev (gimple_stmt_iterator *i) 15429 Advance the iterator to the previous gimple statement. 15430 15431 -- GIMPLE function: gimple gsi_stmt (gimple_stmt_iterator i) 15432 Return the current stmt. 15433 15434 -- GIMPLE function: gimple_stmt_iterator gsi_after_labels (basic_block 15435 bb) 15436 Return a block statement iterator that points to the first 15437 non-label statement in block `BB'. 15438 15439 -- GIMPLE function: gimple *gsi_stmt_ptr (gimple_stmt_iterator *i) 15440 Return a pointer to the current stmt. 15441 15442 -- GIMPLE function: basic_block gsi_bb (gimple_stmt_iterator i) 15443 Return the basic block associated with this iterator. 15444 15445 -- GIMPLE function: gimple_seq gsi_seq (gimple_stmt_iterator i) 15446 Return the sequence associated with this iterator. 15447 15448 -- GIMPLE function: void gsi_remove (gimple_stmt_iterator *i, bool 15449 remove_eh_info) 15450 Remove the current stmt from the sequence. The iterator is 15451 updated to point to the next statement. When `REMOVE_EH_INFO' is 15452 true we remove the statement pointed to by iterator `I' from the 15453 `EH' tables. Otherwise we do not modify the `EH' tables. 15454 Generally, `REMOVE_EH_INFO' should be true when the statement is 15455 going to be removed from the `IL' and not reinserted elsewhere. 15456 15457 -- GIMPLE function: void gsi_link_seq_before (gimple_stmt_iterator *i, 15458 gimple_seq seq, enum gsi_iterator_update mode) 15459 Links the sequence of statements `SEQ' before the statement pointed 15460 by iterator `I'. `MODE' indicates what to do with the iterator 15461 after insertion (see `enum gsi_iterator_update' above). 15462 15463 -- GIMPLE function: void gsi_link_before (gimple_stmt_iterator *i, 15464 gimple g, enum gsi_iterator_update mode) 15465 Links statement `G' before the statement pointed-to by iterator 15466 `I'. Updates iterator `I' according to `MODE'. 15467 15468 -- GIMPLE function: void gsi_link_seq_after (gimple_stmt_iterator *i, 15469 gimple_seq seq, enum gsi_iterator_update mode) 15470 Links sequence `SEQ' after the statement pointed-to by iterator 15471 `I'. `MODE' is as in `gsi_insert_after'. 15472 15473 -- GIMPLE function: void gsi_link_after (gimple_stmt_iterator *i, 15474 gimple g, enum gsi_iterator_update mode) 15475 Links statement `G' after the statement pointed-to by iterator `I'. 15476 `MODE' is as in `gsi_insert_after'. 15477 15478 -- GIMPLE function: gimple_seq gsi_split_seq_after 15479 (gimple_stmt_iterator i) 15480 Move all statements in the sequence after `I' to a new sequence. 15481 Return this new sequence. 15482 15483 -- GIMPLE function: gimple_seq gsi_split_seq_before 15484 (gimple_stmt_iterator *i) 15485 Move all statements in the sequence before `I' to a new sequence. 15486 Return this new sequence. 15487 15488 -- GIMPLE function: void gsi_replace (gimple_stmt_iterator *i, gimple 15489 stmt, bool update_eh_info) 15490 Replace the statement pointed-to by `I' to `STMT'. If 15491 `UPDATE_EH_INFO' is true, the exception handling information of 15492 the original statement is moved to the new statement. 15493 15494 -- GIMPLE function: void gsi_insert_before (gimple_stmt_iterator *i, 15495 gimple stmt, enum gsi_iterator_update mode) 15496 Insert statement `STMT' before the statement pointed-to by iterator 15497 `I', update `STMT''s basic block and scan it for new operands. 15498 `MODE' specifies how to update iterator `I' after insertion (see 15499 enum `gsi_iterator_update'). 15500 15501 -- GIMPLE function: void gsi_insert_seq_before (gimple_stmt_iterator 15502 *i, gimple_seq seq, enum gsi_iterator_update mode) 15503 Like `gsi_insert_before', but for all the statements in `SEQ'. 15504 15505 -- GIMPLE function: void gsi_insert_after (gimple_stmt_iterator *i, 15506 gimple stmt, enum gsi_iterator_update mode) 15507 Insert statement `STMT' after the statement pointed-to by iterator 15508 `I', update `STMT''s basic block and scan it for new operands. 15509 `MODE' specifies how to update iterator `I' after insertion (see 15510 enum `gsi_iterator_update'). 15511 15512 -- GIMPLE function: void gsi_insert_seq_after (gimple_stmt_iterator 15513 *i, gimple_seq seq, enum gsi_iterator_update mode) 15514 Like `gsi_insert_after', but for all the statements in `SEQ'. 15515 15516 -- GIMPLE function: gimple_stmt_iterator gsi_for_stmt (gimple stmt) 15517 Finds iterator for `STMT'. 15518 15519 -- GIMPLE function: void gsi_move_after (gimple_stmt_iterator *from, 15520 gimple_stmt_iterator *to) 15521 Move the statement at `FROM' so it comes right after the statement 15522 at `TO'. 15523 15524 -- GIMPLE function: void gsi_move_before (gimple_stmt_iterator *from, 15525 gimple_stmt_iterator *to) 15526 Move the statement at `FROM' so it comes right before the statement 15527 at `TO'. 15528 15529 -- GIMPLE function: void gsi_move_to_bb_end (gimple_stmt_iterator 15530 *from, basic_block bb) 15531 Move the statement at `FROM' to the end of basic block `BB'. 15532 15533 -- GIMPLE function: void gsi_insert_on_edge (edge e, gimple stmt) 15534 Add `STMT' to the pending list of edge `E'. No actual insertion is 15535 made until a call to `gsi_commit_edge_inserts'() is made. 15536 15537 -- GIMPLE function: void gsi_insert_seq_on_edge (edge e, gimple_seq 15538 seq) 15539 Add the sequence of statements in `SEQ' to the pending list of edge 15540 `E'. No actual insertion is made until a call to 15541 `gsi_commit_edge_inserts'() is made. 15542 15543 -- GIMPLE function: basic_block gsi_insert_on_edge_immediate (edge e, 15544 gimple stmt) 15545 Similar to `gsi_insert_on_edge'+`gsi_commit_edge_inserts'. If a 15546 new block has to be created, it is returned. 15547 15548 -- GIMPLE function: void gsi_commit_one_edge_insert (edge e, 15549 basic_block *new_bb) 15550 Commit insertions pending at edge `E'. If a new block is created, 15551 set `NEW_BB' to this block, otherwise set it to `NULL'. 15552 15553 -- GIMPLE function: void gsi_commit_edge_inserts (void) 15554 This routine will commit all pending edge insertions, creating any 15555 new basic blocks which are necessary. 15556 15557 15558File: gccint.info, Node: Adding a new GIMPLE statement code, Next: Statement and operand traversals, Prev: Sequence iterators, Up: GIMPLE 15559 1556012.10 Adding a new GIMPLE statement code 15561======================================== 15562 15563The first step in adding a new GIMPLE statement code, is modifying the 15564file `gimple.def', which contains all the GIMPLE codes. Then you must 15565add a corresponding structure, and an entry in `union 15566gimple_statement_d', both of which are located in `gimple.h'. This in 15567turn, will require you to add a corresponding `GTY' tag in 15568`gsstruct.def', and code to handle this tag in `gss_for_code' which is 15569located in `gimple.c'. 15570 15571 In order for the garbage collector to know the size of the structure 15572you created in `gimple.h', you need to add a case to handle your new 15573GIMPLE statement in `gimple_size' which is located in `gimple.c'. 15574 15575 You will probably want to create a function to build the new gimple 15576statement in `gimple.c'. The function should be called 15577`gimple_build_<`NEW_TUPLE_NAME'>', and should return the new tuple of 15578type gimple. 15579 15580 If your new statement requires accessors for any members or operands 15581it may have, put simple inline accessors in `gimple.h' and any 15582non-trivial accessors in `gimple.c' with a corresponding prototype in 15583`gimple.h'. 15584 15585 15586File: gccint.info, Node: Statement and operand traversals, Prev: Adding a new GIMPLE statement code, Up: GIMPLE 15587 1558812.11 Statement and operand traversals 15589====================================== 15590 15591There are two functions available for walking statements and sequences: 15592`walk_gimple_stmt' and `walk_gimple_seq', accordingly, and a third 15593function for walking the operands in a statement: `walk_gimple_op'. 15594 15595 -- GIMPLE function: tree walk_gimple_stmt (gimple_stmt_iterator *gsi, 15596 walk_stmt_fn callback_stmt, walk_tree_fn callback_op, struct 15597 walk_stmt_info *wi) 15598 This function is used to walk the current statement in `GSI', 15599 optionally using traversal state stored in `WI'. If `WI' is 15600 `NULL', no state is kept during the traversal. 15601 15602 The callback `CALLBACK_STMT' is called. If `CALLBACK_STMT' returns 15603 true, it means that the callback function has handled all the 15604 operands of the statement and it is not necessary to walk its 15605 operands. 15606 15607 If `CALLBACK_STMT' is `NULL' or it returns false, `CALLBACK_OP' is 15608 called on each operand of the statement via `walk_gimple_op'. If 15609 `walk_gimple_op' returns non-`NULL' for any operand, the remaining 15610 operands are not scanned. 15611 15612 The return value is that returned by the last call to 15613 `walk_gimple_op', or `NULL_TREE' if no `CALLBACK_OP' is specified. 15614 15615 -- GIMPLE function: tree walk_gimple_op (gimple stmt, walk_tree_fn 15616 callback_op, struct walk_stmt_info *wi) 15617 Use this function to walk the operands of statement `STMT'. Every 15618 operand is walked via `walk_tree' with optional state information 15619 in `WI'. 15620 15621 `CALLBACK_OP' is called on each operand of `STMT' via `walk_tree'. 15622 Additional parameters to `walk_tree' must be stored in `WI'. For 15623 each operand `OP', `walk_tree' is called as: 15624 15625 walk_tree (&`OP', `CALLBACK_OP', `WI', `WI'- `PSET') 15626 15627 If `CALLBACK_OP' returns non-`NULL' for an operand, the remaining 15628 operands are not scanned. The return value is that returned by 15629 the last call to `walk_tree', or `NULL_TREE' if no `CALLBACK_OP' is 15630 specified. 15631 15632 -- GIMPLE function: tree walk_gimple_seq (gimple_seq seq, walk_stmt_fn 15633 callback_stmt, walk_tree_fn callback_op, struct 15634 walk_stmt_info *wi) 15635 This function walks all the statements in the sequence `SEQ' 15636 calling `walk_gimple_stmt' on each one. `WI' is as in 15637 `walk_gimple_stmt'. If `walk_gimple_stmt' returns non-`NULL', the 15638 walk is stopped and the value returned. Otherwise, all the 15639 statements are walked and `NULL_TREE' returned. 15640 15641 15642File: gccint.info, Node: Tree SSA, Next: RTL, Prev: GIMPLE, Up: Top 15643 1564413 Analysis and Optimization of GIMPLE tuples 15645********************************************* 15646 15647GCC uses three main intermediate languages to represent the program 15648during compilation: GENERIC, GIMPLE and RTL. GENERIC is a 15649language-independent representation generated by each front end. It is 15650used to serve as an interface between the parser and optimizer. 15651GENERIC is a common representation that is able to represent programs 15652written in all the languages supported by GCC. 15653 15654 GIMPLE and RTL are used to optimize the program. GIMPLE is used for 15655target and language independent optimizations (e.g., inlining, constant 15656propagation, tail call elimination, redundancy elimination, etc). Much 15657like GENERIC, GIMPLE is a language independent, tree based 15658representation. However, it differs from GENERIC in that the GIMPLE 15659grammar is more restrictive: expressions contain no more than 3 15660operands (except function calls), it has no control flow structures and 15661expressions with side-effects are only allowed on the right hand side 15662of assignments. See the chapter describing GENERIC and GIMPLE for more 15663details. 15664 15665 This chapter describes the data structures and functions used in the 15666GIMPLE optimizers (also known as "tree optimizers" or "middle end"). 15667In particular, it focuses on all the macros, data structures, functions 15668and programming constructs needed to implement optimization passes for 15669GIMPLE. 15670 15671* Menu: 15672 15673* Annotations:: Attributes for variables. 15674* SSA Operands:: SSA names referenced by GIMPLE statements. 15675* SSA:: Static Single Assignment representation. 15676* Alias analysis:: Representing aliased loads and stores. 15677* Memory model:: Memory model used by the middle-end. 15678 15679 15680File: gccint.info, Node: Annotations, Next: SSA Operands, Up: Tree SSA 15681 1568213.1 Annotations 15683================ 15684 15685The optimizers need to associate attributes with variables during the 15686optimization process. For instance, we need to know whether a variable 15687has aliases. All these attributes are stored in data structures called 15688annotations which are then linked to the field `ann' in `struct 15689tree_common'. 15690 15691 Presently, we define annotations for variables (`var_ann_t'). 15692Annotations are defined and documented in `tree-flow.h'. 15693 15694 15695File: gccint.info, Node: SSA Operands, Next: SSA, Prev: Annotations, Up: Tree SSA 15696 1569713.2 SSA Operands 15698================= 15699 15700Almost every GIMPLE statement will contain a reference to a variable or 15701memory location. Since statements come in different shapes and sizes, 15702their operands are going to be located at various spots inside the 15703statement's tree. To facilitate access to the statement's operands, 15704they are organized into lists associated inside each statement's 15705annotation. Each element in an operand list is a pointer to a 15706`VAR_DECL', `PARM_DECL' or `SSA_NAME' tree node. This provides a very 15707convenient way of examining and replacing operands. 15708 15709 Data flow analysis and optimization is done on all tree nodes 15710representing variables. Any node for which `SSA_VAR_P' returns nonzero 15711is considered when scanning statement operands. However, not all 15712`SSA_VAR_P' variables are processed in the same way. For the purposes 15713of optimization, we need to distinguish between references to local 15714scalar variables and references to globals, statics, structures, 15715arrays, aliased variables, etc. The reason is simple, the compiler can 15716gather complete data flow information for a local scalar. On the other 15717hand, a global variable may be modified by a function call, it may not 15718be possible to keep track of all the elements of an array or the fields 15719of a structure, etc. 15720 15721 The operand scanner gathers two kinds of operands: "real" and 15722"virtual". An operand for which `is_gimple_reg' returns true is 15723considered real, otherwise it is a virtual operand. We also 15724distinguish between uses and definitions. An operand is used if its 15725value is loaded by the statement (e.g., the operand at the RHS of an 15726assignment). If the statement assigns a new value to the operand, the 15727operand is considered a definition (e.g., the operand at the LHS of an 15728assignment). 15729 15730 Virtual and real operands also have very different data flow 15731properties. Real operands are unambiguous references to the full 15732object that they represent. For instance, given 15733 15734 { 15735 int a, b; 15736 a = b 15737 } 15738 15739 Since `a' and `b' are non-aliased locals, the statement `a = b' will 15740have one real definition and one real use because variable `a' is 15741completely modified with the contents of variable `b'. Real definition 15742are also known as "killing definitions". Similarly, the use of `b' 15743reads all its bits. 15744 15745 In contrast, virtual operands are used with variables that can have a 15746partial or ambiguous reference. This includes structures, arrays, 15747globals, and aliased variables. In these cases, we have two types of 15748definitions. For globals, structures, and arrays, we can determine from 15749a statement whether a variable of these types has a killing definition. 15750If the variable does, then the statement is marked as having a "must 15751definition" of that variable. However, if a statement is only defining 15752a part of the variable (i.e. a field in a structure), or if we know 15753that a statement might define the variable but we cannot say for sure, 15754then we mark that statement as having a "may definition". For 15755instance, given 15756 15757 { 15758 int a, b, *p; 15759 15760 if (...) 15761 p = &a; 15762 else 15763 p = &b; 15764 *p = 5; 15765 return *p; 15766 } 15767 15768 The assignment `*p = 5' may be a definition of `a' or `b'. If we 15769cannot determine statically where `p' is pointing to at the time of the 15770store operation, we create virtual definitions to mark that statement 15771as a potential definition site for `a' and `b'. Memory loads are 15772similarly marked with virtual use operands. Virtual operands are shown 15773in tree dumps right before the statement that contains them. To 15774request a tree dump with virtual operands, use the `-vops' option to 15775`-fdump-tree': 15776 15777 { 15778 int a, b, *p; 15779 15780 if (...) 15781 p = &a; 15782 else 15783 p = &b; 15784 # a = VDEF <a> 15785 # b = VDEF <b> 15786 *p = 5; 15787 15788 # VUSE <a> 15789 # VUSE <b> 15790 return *p; 15791 } 15792 15793 Notice that `VDEF' operands have two copies of the referenced 15794variable. This indicates that this is not a killing definition of that 15795variable. In this case we refer to it as a "may definition" or 15796"aliased store". The presence of the second copy of the variable in 15797the `VDEF' operand will become important when the function is converted 15798into SSA form. This will be used to link all the non-killing 15799definitions to prevent optimizations from making incorrect assumptions 15800about them. 15801 15802 Operands are updated as soon as the statement is finished via a call 15803to `update_stmt'. If statement elements are changed via `SET_USE' or 15804`SET_DEF', then no further action is required (i.e., those macros take 15805care of updating the statement). If changes are made by manipulating 15806the statement's tree directly, then a call must be made to 15807`update_stmt' when complete. Calling one of the `bsi_insert' routines 15808or `bsi_replace' performs an implicit call to `update_stmt'. 15809 1581013.2.1 Operand Iterators And Access Routines 15811-------------------------------------------- 15812 15813Operands are collected by `tree-ssa-operands.c'. They are stored 15814inside each statement's annotation and can be accessed through either 15815the operand iterators or an access routine. 15816 15817 The following access routines are available for examining operands: 15818 15819 1. `SINGLE_SSA_{USE,DEF,TREE}_OPERAND': These accessors will return 15820 NULL unless there is exactly one operand matching the specified 15821 flags. If there is exactly one operand, the operand is returned 15822 as either a `tree', `def_operand_p', or `use_operand_p'. 15823 15824 tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags); 15825 use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES); 15826 def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS); 15827 15828 2. `ZERO_SSA_OPERANDS': This macro returns true if there are no 15829 operands matching the specified flags. 15830 15831 if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS)) 15832 return; 15833 15834 3. `NUM_SSA_OPERANDS': This macro Returns the number of operands 15835 matching 'flags'. This actually executes a loop to perform the 15836 count, so only use this if it is really needed. 15837 15838 int count = NUM_SSA_OPERANDS (stmt, flags) 15839 15840 If you wish to iterate over some or all operands, use the 15841`FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND' iterator. For example, to print 15842all the operands for a statement: 15843 15844 void 15845 print_ops (tree stmt) 15846 { 15847 ssa_op_iter; 15848 tree var; 15849 15850 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_ALL_OPERANDS) 15851 print_generic_expr (stderr, var, TDF_SLIM); 15852 } 15853 15854 How to choose the appropriate iterator: 15855 15856 1. Determine whether you are need to see the operand pointers, or 15857 just the trees, and choose the appropriate macro: 15858 15859 Need Macro: 15860 ---- ------- 15861 use_operand_p FOR_EACH_SSA_USE_OPERAND 15862 def_operand_p FOR_EACH_SSA_DEF_OPERAND 15863 tree FOR_EACH_SSA_TREE_OPERAND 15864 15865 2. You need to declare a variable of the type you are interested in, 15866 and an ssa_op_iter structure which serves as the loop controlling 15867 variable. 15868 15869 3. Determine which operands you wish to use, and specify the flags of 15870 those you are interested in. They are documented in 15871 `tree-ssa-operands.h': 15872 15873 #define SSA_OP_USE 0x01 /* Real USE operands. */ 15874 #define SSA_OP_DEF 0x02 /* Real DEF operands. */ 15875 #define SSA_OP_VUSE 0x04 /* VUSE operands. */ 15876 #define SSA_OP_VMAYUSE 0x08 /* USE portion of VDEFS. */ 15877 #define SSA_OP_VDEF 0x10 /* DEF portion of VDEFS. */ 15878 15879 /* These are commonly grouped operand flags. */ 15880 #define SSA_OP_VIRTUAL_USES (SSA_OP_VUSE | SSA_OP_VMAYUSE) 15881 #define SSA_OP_VIRTUAL_DEFS (SSA_OP_VDEF) 15882 #define SSA_OP_ALL_USES (SSA_OP_VIRTUAL_USES | SSA_OP_USE) 15883 #define SSA_OP_ALL_DEFS (SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF) 15884 #define SSA_OP_ALL_OPERANDS (SSA_OP_ALL_USES | SSA_OP_ALL_DEFS) 15885 15886 So if you want to look at the use pointers for all the `USE' and 15887`VUSE' operands, you would do something like: 15888 15889 use_operand_p use_p; 15890 ssa_op_iter iter; 15891 15892 FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE)) 15893 { 15894 process_use_ptr (use_p); 15895 } 15896 15897 The `TREE' macro is basically the same as the `USE' and `DEF' macros, 15898only with the use or def dereferenced via `USE_FROM_PTR (use_p)' and 15899`DEF_FROM_PTR (def_p)'. Since we aren't using operand pointers, use 15900and defs flags can be mixed. 15901 15902 tree var; 15903 ssa_op_iter iter; 15904 15905 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_VUSE) 15906 { 15907 print_generic_expr (stderr, var, TDF_SLIM); 15908 } 15909 15910 `VDEF's are broken into two flags, one for the `DEF' portion 15911(`SSA_OP_VDEF') and one for the USE portion (`SSA_OP_VMAYUSE'). If all 15912you want to look at are the `VDEF's together, there is a fourth 15913iterator macro for this, which returns both a def_operand_p and a 15914use_operand_p for each `VDEF' in the statement. Note that you don't 15915need any flags for this one. 15916 15917 use_operand_p use_p; 15918 def_operand_p def_p; 15919 ssa_op_iter iter; 15920 15921 FOR_EACH_SSA_MAYDEF_OPERAND (def_p, use_p, stmt, iter) 15922 { 15923 my_code; 15924 } 15925 15926 There are many examples in the code as well, as well as the 15927documentation in `tree-ssa-operands.h'. 15928 15929 There are also a couple of variants on the stmt iterators regarding PHI 15930nodes. 15931 15932 `FOR_EACH_PHI_ARG' Works exactly like `FOR_EACH_SSA_USE_OPERAND', 15933except it works over `PHI' arguments instead of statement operands. 15934 15935 /* Look at every virtual PHI use. */ 15936 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES) 15937 { 15938 my_code; 15939 } 15940 15941 /* Look at every real PHI use. */ 15942 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_USES) 15943 my_code; 15944 15945 /* Look at every PHI use. */ 15946 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES) 15947 my_code; 15948 15949 `FOR_EACH_PHI_OR_STMT_{USE,DEF}' works exactly like 15950`FOR_EACH_SSA_{USE,DEF}_OPERAND', except it will function on either a 15951statement or a `PHI' node. These should be used when it is appropriate 15952but they are not quite as efficient as the individual `FOR_EACH_PHI' 15953and `FOR_EACH_SSA' routines. 15954 15955 FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags) 15956 { 15957 my_code; 15958 } 15959 15960 FOR_EACH_PHI_OR_STMT_DEF (def_operand_p, phi, iter, flags) 15961 { 15962 my_code; 15963 } 15964 1596513.2.2 Immediate Uses 15966--------------------- 15967 15968Immediate use information is now always available. Using the immediate 15969use iterators, you may examine every use of any `SSA_NAME'. For 15970instance, to change each use of `ssa_var' to `ssa_var2' and call 15971fold_stmt on each stmt after that is done: 15972 15973 use_operand_p imm_use_p; 15974 imm_use_iterator iterator; 15975 tree ssa_var, stmt; 15976 15977 15978 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 15979 { 15980 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 15981 SET_USE (imm_use_p, ssa_var_2); 15982 fold_stmt (stmt); 15983 } 15984 15985 There are 2 iterators which can be used. `FOR_EACH_IMM_USE_FAST' is 15986used when the immediate uses are not changed, i.e., you are looking at 15987the uses, but not setting them. 15988 15989 If they do get changed, then care must be taken that things are not 15990changed under the iterators, so use the `FOR_EACH_IMM_USE_STMT' and 15991`FOR_EACH_IMM_USE_ON_STMT' iterators. They attempt to preserve the 15992sanity of the use list by moving all the uses for a statement into a 15993controlled position, and then iterating over those uses. Then the 15994optimization can manipulate the stmt when all the uses have been 15995processed. This is a little slower than the FAST version since it adds 15996a placeholder element and must sort through the list a bit for each 15997statement. This placeholder element must be also be removed if the 15998loop is terminated early. The macro `BREAK_FROM_IMM_USE_SAFE' is 15999provided to do this : 16000 16001 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 16002 { 16003 if (stmt == last_stmt) 16004 BREAK_FROM_SAFE_IMM_USE (iter); 16005 16006 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 16007 SET_USE (imm_use_p, ssa_var_2); 16008 fold_stmt (stmt); 16009 } 16010 16011 There are checks in `verify_ssa' which verify that the immediate use 16012list is up to date, as well as checking that an optimization didn't 16013break from the loop without using this macro. It is safe to simply 16014'break'; from a `FOR_EACH_IMM_USE_FAST' traverse. 16015 16016 Some useful functions and macros: 16017 1. `has_zero_uses (ssa_var)' : Returns true if there are no uses of 16018 `ssa_var'. 16019 16020 2. `has_single_use (ssa_var)' : Returns true if there is only a 16021 single use of `ssa_var'. 16022 16023 3. `single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)' : 16024 Returns true if there is only a single use of `ssa_var', and also 16025 returns the use pointer and statement it occurs in, in the second 16026 and third parameters. 16027 16028 4. `num_imm_uses (ssa_var)' : Returns the number of immediate uses of 16029 `ssa_var'. It is better not to use this if possible since it simply 16030 utilizes a loop to count the uses. 16031 16032 5. `PHI_ARG_INDEX_FROM_USE (use_p)' : Given a use within a `PHI' 16033 node, return the index number for the use. An assert is triggered 16034 if the use isn't located in a `PHI' node. 16035 16036 6. `USE_STMT (use_p)' : Return the statement a use occurs in. 16037 16038 Note that uses are not put into an immediate use list until their 16039statement is actually inserted into the instruction stream via a 16040`bsi_*' routine. 16041 16042 It is also still possible to utilize lazy updating of statements, but 16043this should be used only when absolutely required. Both alias analysis 16044and the dominator optimizations currently do this. 16045 16046 When lazy updating is being used, the immediate use information is out 16047of date and cannot be used reliably. Lazy updating is achieved by 16048simply marking statements modified via calls to `mark_stmt_modified' 16049instead of `update_stmt'. When lazy updating is no longer required, 16050all the modified statements must have `update_stmt' called in order to 16051bring them up to date. This must be done before the optimization is 16052finished, or `verify_ssa' will trigger an abort. 16053 16054 This is done with a simple loop over the instruction stream: 16055 block_stmt_iterator bsi; 16056 basic_block bb; 16057 FOR_EACH_BB (bb) 16058 { 16059 for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi)) 16060 update_stmt_if_modified (bsi_stmt (bsi)); 16061 } 16062 16063 16064File: gccint.info, Node: SSA, Next: Alias analysis, Prev: SSA Operands, Up: Tree SSA 16065 1606613.3 Static Single Assignment 16067============================= 16068 16069Most of the tree optimizers rely on the data flow information provided 16070by the Static Single Assignment (SSA) form. We implement the SSA form 16071as described in `R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K. 16072Zadeck. Efficiently Computing Static Single Assignment Form and the 16073Control Dependence Graph. ACM Transactions on Programming Languages 16074and Systems, 13(4):451-490, October 1991'. 16075 16076 The SSA form is based on the premise that program variables are 16077assigned in exactly one location in the program. Multiple assignments 16078to the same variable create new versions of that variable. Naturally, 16079actual programs are seldom in SSA form initially because variables tend 16080to be assigned multiple times. The compiler modifies the program 16081representation so that every time a variable is assigned in the code, a 16082new version of the variable is created. Different versions of the same 16083variable are distinguished by subscripting the variable name with its 16084version number. Variables used in the right-hand side of expressions 16085are renamed so that their version number matches that of the most 16086recent assignment. 16087 16088 We represent variable versions using `SSA_NAME' nodes. The renaming 16089process in `tree-ssa.c' wraps every real and virtual operand with an 16090`SSA_NAME' node which contains the version number and the statement 16091that created the `SSA_NAME'. Only definitions and virtual definitions 16092may create new `SSA_NAME' nodes. 16093 16094 Sometimes, flow of control makes it impossible to determine the most 16095recent version of a variable. In these cases, the compiler inserts an 16096artificial definition for that variable called "PHI function" or "PHI 16097node". This new definition merges all the incoming versions of the 16098variable to create a new name for it. For instance, 16099 16100 if (...) 16101 a_1 = 5; 16102 else if (...) 16103 a_2 = 2; 16104 else 16105 a_3 = 13; 16106 16107 # a_4 = PHI <a_1, a_2, a_3> 16108 return a_4; 16109 16110 Since it is not possible to determine which of the three branches will 16111be taken at runtime, we don't know which of `a_1', `a_2' or `a_3' to 16112use at the return statement. So, the SSA renamer creates a new version 16113`a_4' which is assigned the result of "merging" `a_1', `a_2' and `a_3'. 16114Hence, PHI nodes mean "one of these operands. I don't know which". 16115 16116 The following macros can be used to examine PHI nodes 16117 16118 -- Macro: PHI_RESULT (PHI) 16119 Returns the `SSA_NAME' created by PHI node PHI (i.e., PHI's LHS). 16120 16121 -- Macro: PHI_NUM_ARGS (PHI) 16122 Returns the number of arguments in PHI. This number is exactly 16123 the number of incoming edges to the basic block holding PHI. 16124 16125 -- Macro: PHI_ARG_ELT (PHI, I) 16126 Returns a tuple representing the Ith argument of PHI. Each 16127 element of this tuple contains an `SSA_NAME' VAR and the incoming 16128 edge through which VAR flows. 16129 16130 -- Macro: PHI_ARG_EDGE (PHI, I) 16131 Returns the incoming edge for the Ith argument of PHI. 16132 16133 -- Macro: PHI_ARG_DEF (PHI, I) 16134 Returns the `SSA_NAME' for the Ith argument of PHI. 16135 1613613.3.1 Preserving the SSA form 16137------------------------------ 16138 16139Some optimization passes make changes to the function that invalidate 16140the SSA property. This can happen when a pass has added new symbols or 16141changed the program so that variables that were previously aliased 16142aren't anymore. Whenever something like this happens, the affected 16143symbols must be renamed into SSA form again. Transformations that emit 16144new code or replicate existing statements will also need to update the 16145SSA form. 16146 16147 Since GCC implements two different SSA forms for register and virtual 16148variables, keeping the SSA form up to date depends on whether you are 16149updating register or virtual names. In both cases, the general idea 16150behind incremental SSA updates is similar: when new SSA names are 16151created, they typically are meant to replace other existing names in 16152the program. 16153 16154 For instance, given the following code: 16155 16156 1 L0: 16157 2 x_1 = PHI (0, x_5) 16158 3 if (x_1 < 10) 16159 4 if (x_1 > 7) 16160 5 y_2 = 0 16161 6 else 16162 7 y_3 = x_1 + x_7 16163 8 endif 16164 9 x_5 = x_1 + 1 16165 10 goto L0; 16166 11 endif 16167 16168 Suppose that we insert new names `x_10' and `x_11' (lines `4' and `8'). 16169 16170 1 L0: 16171 2 x_1 = PHI (0, x_5) 16172 3 if (x_1 < 10) 16173 4 x_10 = ... 16174 5 if (x_1 > 7) 16175 6 y_2 = 0 16176 7 else 16177 8 x_11 = ... 16178 9 y_3 = x_1 + x_7 16179 10 endif 16180 11 x_5 = x_1 + 1 16181 12 goto L0; 16182 13 endif 16183 16184 We want to replace all the uses of `x_1' with the new definitions of 16185`x_10' and `x_11'. Note that the only uses that should be replaced are 16186those at lines `5', `9' and `11'. Also, the use of `x_7' at line `9' 16187should _not_ be replaced (this is why we cannot just mark symbol `x' for 16188renaming). 16189 16190 Additionally, we may need to insert a PHI node at line `11' because 16191that is a merge point for `x_10' and `x_11'. So the use of `x_1' at 16192line `11' will be replaced with the new PHI node. The insertion of PHI 16193nodes is optional. They are not strictly necessary to preserve the SSA 16194form, and depending on what the caller inserted, they may not even be 16195useful for the optimizers. 16196 16197 Updating the SSA form is a two step process. First, the pass has to 16198identify which names need to be updated and/or which symbols need to be 16199renamed into SSA form for the first time. When new names are 16200introduced to replace existing names in the program, the mapping 16201between the old and the new names are registered by calling 16202`register_new_name_mapping' (note that if your pass creates new code by 16203duplicating basic blocks, the call to `tree_duplicate_bb' will set up 16204the necessary mappings automatically). On the other hand, if your pass 16205exposes a new symbol that should be put in SSA form for the first time, 16206the new symbol should be registered with `mark_sym_for_renaming'. 16207 16208 After the replacement mappings have been registered and new symbols 16209marked for renaming, a call to `update_ssa' makes the registered 16210changes. This can be done with an explicit call or by creating `TODO' 16211flags in the `tree_opt_pass' structure for your pass. There are 16212several `TODO' flags that control the behavior of `update_ssa': 16213 16214 * `TODO_update_ssa'. Update the SSA form inserting PHI nodes for 16215 newly exposed symbols and virtual names marked for updating. When 16216 updating real names, only insert PHI nodes for a real name `O_j' 16217 in blocks reached by all the new and old definitions for `O_j'. 16218 If the iterated dominance frontier for `O_j' is not pruned, we may 16219 end up inserting PHI nodes in blocks that have one or more edges 16220 with no incoming definition for `O_j'. This would lead to 16221 uninitialized warnings for `O_j''s symbol. 16222 16223 * `TODO_update_ssa_no_phi'. Update the SSA form without inserting 16224 any new PHI nodes at all. This is used by passes that have either 16225 inserted all the PHI nodes themselves or passes that need only to 16226 patch use-def and def-def chains for virtuals (e.g., DCE). 16227 16228 * `TODO_update_ssa_full_phi'. Insert PHI nodes everywhere they are 16229 needed. No pruning of the IDF is done. This is used by passes 16230 that need the PHI nodes for `O_j' even if it means that some 16231 arguments will come from the default definition of `O_j''s symbol 16232 (e.g., `pass_linear_transform'). 16233 16234 WARNING: If you need to use this flag, chances are that your pass 16235 may be doing something wrong. Inserting PHI nodes for an old name 16236 where not all edges carry a new replacement may lead to silent 16237 codegen errors or spurious uninitialized warnings. 16238 16239 * `TODO_update_ssa_only_virtuals'. Passes that update the SSA form 16240 on their own may want to delegate the updating of virtual names to 16241 the generic updater. Since FUD chains are easier to maintain, 16242 this simplifies the work they need to do. NOTE: If this flag is 16243 used, any OLD->NEW mappings for real names are explicitly 16244 destroyed and only the symbols marked for renaming are processed. 16245 1624613.3.2 Preserving the virtual SSA form 16247-------------------------------------- 16248 16249The virtual SSA form is harder to preserve than the non-virtual SSA form 16250mainly because the set of virtual operands for a statement may change at 16251what some would consider unexpected times. In general, statement 16252modifications should be bracketed between calls to `push_stmt_changes' 16253and `pop_stmt_changes'. For example, 16254 16255 munge_stmt (tree stmt) 16256 { 16257 push_stmt_changes (&stmt); 16258 ... rewrite STMT ... 16259 pop_stmt_changes (&stmt); 16260 } 16261 16262 The call to `push_stmt_changes' saves the current state of the 16263statement operands and the call to `pop_stmt_changes' compares the 16264saved state with the current one and does the appropriate symbol 16265marking for the SSA renamer. 16266 16267 It is possible to modify several statements at a time, provided that 16268`push_stmt_changes' and `pop_stmt_changes' are called in LIFO order, as 16269when processing a stack of statements. 16270 16271 Additionally, if the pass discovers that it did not need to make 16272changes to the statement after calling `push_stmt_changes', it can 16273simply discard the topmost change buffer by calling 16274`discard_stmt_changes'. This will avoid the expensive operand re-scan 16275operation and the buffer comparison that determines if symbols need to 16276be marked for renaming. 16277 1627813.3.3 Examining `SSA_NAME' nodes 16279--------------------------------- 16280 16281The following macros can be used to examine `SSA_NAME' nodes 16282 16283 -- Macro: SSA_NAME_DEF_STMT (VAR) 16284 Returns the statement S that creates the `SSA_NAME' VAR. If S is 16285 an empty statement (i.e., `IS_EMPTY_STMT (S)' returns `true'), it 16286 means that the first reference to this variable is a USE or a VUSE. 16287 16288 -- Macro: SSA_NAME_VERSION (VAR) 16289 Returns the version number of the `SSA_NAME' object VAR. 16290 1629113.3.4 Walking use-def chains 16292----------------------------- 16293 16294 -- Tree SSA function: void walk_use_def_chains (VAR, FN, DATA) 16295 Walks use-def chains starting at the `SSA_NAME' node VAR. Calls 16296 function FN at each reaching definition found. Function FN takes 16297 three arguments: VAR, its defining statement (DEF_STMT) and a 16298 generic pointer to whatever state information that FN may want to 16299 maintain (DATA). Function FN is able to stop the walk by 16300 returning `true', otherwise in order to continue the walk, FN 16301 should return `false'. 16302 16303 Note, that if DEF_STMT is a `PHI' node, the semantics are slightly 16304 different. For each argument ARG of the PHI node, this function 16305 will: 16306 16307 1. Walk the use-def chains for ARG. 16308 16309 2. Call `FN (ARG, PHI, DATA)'. 16310 16311 Note how the first argument to FN is no longer the original 16312 variable VAR, but the PHI argument currently being examined. If 16313 FN wants to get at VAR, it should call `PHI_RESULT' (PHI). 16314 1631513.3.5 Walking the dominator tree 16316--------------------------------- 16317 16318 -- Tree SSA function: void walk_dominator_tree (WALK_DATA, BB) 16319 This function walks the dominator tree for the current CFG calling 16320 a set of callback functions defined in STRUCT DOM_WALK_DATA in 16321 `domwalk.h'. The call back functions you need to define give you 16322 hooks to execute custom code at various points during traversal: 16323 16324 1. Once to initialize any local data needed while processing BB 16325 and its children. This local data is pushed into an internal 16326 stack which is automatically pushed and popped as the walker 16327 traverses the dominator tree. 16328 16329 2. Once before traversing all the statements in the BB. 16330 16331 3. Once for every statement inside BB. 16332 16333 4. Once after traversing all the statements and before recursing 16334 into BB's dominator children. 16335 16336 5. It then recurses into all the dominator children of BB. 16337 16338 6. After recursing into all the dominator children of BB it can, 16339 optionally, traverse every statement in BB again (i.e., 16340 repeating steps 2 and 3). 16341 16342 7. Once after walking the statements in BB and BB's dominator 16343 children. At this stage, the block local data stack is 16344 popped. 16345 16346 16347File: gccint.info, Node: Alias analysis, Next: Memory model, Prev: SSA, Up: Tree SSA 16348 1634913.4 Alias analysis 16350=================== 16351 16352Alias analysis in GIMPLE SSA form consists of two pieces. First the 16353virtual SSA web ties conflicting memory accesses and provides a SSA 16354use-def chain and SSA immediate-use chains for walking possibly 16355dependent memory accesses. Second an alias-oracle can be queried to 16356disambiguate explicit and implicit memory references. 16357 16358 1. Memory SSA form. 16359 16360 All statements that may use memory have exactly one accompanied 16361 use of a virtual SSA name that represents the state of memory at 16362 the given point in the IL. 16363 16364 All statements that may define memory have exactly one accompanied 16365 definition of a virtual SSA name using the previous state of memory 16366 and defining the new state of memory after the given point in the 16367 IL. 16368 16369 int i; 16370 int foo (void) 16371 { 16372 # .MEM_3 = VDEF <.MEM_2(D)> 16373 i = 1; 16374 # VUSE <.MEM_3> 16375 return i; 16376 } 16377 16378 The virtual SSA names in this case are `.MEM_2(D)' and `.MEM_3'. 16379 The store to the global variable `i' defines `.MEM_3' invalidating 16380 `.MEM_2(D)'. The load from `i' uses that new state `.MEM_3'. 16381 16382 The virtual SSA web serves as constraints to SSA optimizers 16383 preventing illegitimate code-motion and optimization. It also 16384 provides a way to walk related memory statements. 16385 16386 2. Points-to and escape analysis. 16387 16388 Points-to analysis builds a set of constraints from the GIMPLE SSA 16389 IL representing all pointer operations and facts we do or do not 16390 know about pointers. Solving this set of constraints yields a 16391 conservatively correct solution for each pointer variable in the 16392 program (though we are only interested in SSA name pointers) as to 16393 what it may possibly point to. 16394 16395 This points-to solution for a given SSA name pointer is stored in 16396 the `pt_solution' sub-structure of the `SSA_NAME_PTR_INFO' record. 16397 The following accessor functions are available: 16398 16399 * `pt_solution_includes' 16400 16401 * `pt_solutions_intersect' 16402 16403 Points-to analysis also computes the solution for two special set 16404 of pointers, `ESCAPED' and `CALLUSED'. Those represent all memory 16405 that has escaped the scope of analysis or that is used by pure or 16406 nested const calls. 16407 16408 3. Type-based alias analysis 16409 16410 Type-based alias analysis is frontend dependent though generic 16411 support is provided by the middle-end in `alias.c'. TBAA code is 16412 used by both tree optimizers and RTL optimizers. 16413 16414 Every language that wishes to perform language-specific alias 16415 analysis should define a function that computes, given a `tree' 16416 node, an alias set for the node. Nodes in different alias sets 16417 are not allowed to alias. For an example, see the C front-end 16418 function `c_get_alias_set'. 16419 16420 4. Tree alias-oracle 16421 16422 The tree alias-oracle provides means to disambiguate two memory 16423 references and memory references against statements. The following 16424 queries are available: 16425 16426 * `refs_may_alias_p' 16427 16428 * `ref_maybe_used_by_stmt_p' 16429 16430 * `stmt_may_clobber_ref_p' 16431 16432 In addition to those two kind of statement walkers are available 16433 walking statements related to a reference ref. 16434 `walk_non_aliased_vuses' walks over dominating memory defining 16435 statements and calls back if the statement does not clobber ref 16436 providing the non-aliased VUSE. The walk stops at the first 16437 clobbering statement or if asked to. `walk_aliased_vdefs' walks 16438 over dominating memory defining statements and calls back on each 16439 statement clobbering ref providing its aliasing VDEF. The walk 16440 stops if asked to. 16441 16442 16443 16444File: gccint.info, Node: Memory model, Prev: Alias analysis, Up: Tree SSA 16445 1644613.5 Memory model 16447================= 16448 16449The memory model used by the middle-end models that of the C/C++ 16450languages. The middle-end has the notion of an effective type of a 16451memory region which is used for type-based alias analysis. 16452 16453 The following is a refinement of ISO C99 6.5/6, clarifying the block 16454copy case to follow common sense and extending the concept of a dynamic 16455effective type to objects with a declared type as required for C++. 16456 16457 The effective type of an object for an access to its stored value is 16458 the declared type of the object or the effective type determined by 16459 a previous store to it. If a value is stored into an object through 16460 an lvalue having a type that is not a character type, then the 16461 type of the lvalue becomes the effective type of the object for that 16462 access and for subsequent accesses that do not modify the stored value. 16463 If a value is copied into an object using `memcpy' or `memmove', 16464 or is copied as an array of character type, then the effective type 16465 of the modified object for that access and for subsequent accesses that 16466 do not modify the value is undetermined. For all other accesses to an 16467 object, the effective type of the object is simply the type of the 16468 lvalue used for the access. 16469 16470 16471File: gccint.info, Node: Loop Analysis and Representation, Next: Machine Desc, Prev: Control Flow, Up: Top 16472 1647314 Analysis and Representation of Loops 16474*************************************** 16475 16476GCC provides extensive infrastructure for work with natural loops, i.e., 16477strongly connected components of CFG with only one entry block. This 16478chapter describes representation of loops in GCC, both on GIMPLE and in 16479RTL, as well as the interfaces to loop-related analyses (induction 16480variable analysis and number of iterations analysis). 16481 16482* Menu: 16483 16484* Loop representation:: Representation and analysis of loops. 16485* Loop querying:: Getting information about loops. 16486* Loop manipulation:: Loop manipulation functions. 16487* LCSSA:: Loop-closed SSA form. 16488* Scalar evolutions:: Induction variables on GIMPLE. 16489* loop-iv:: Induction variables on RTL. 16490* Number of iterations:: Number of iterations analysis. 16491* Dependency analysis:: Data dependency analysis. 16492* Lambda:: Linear loop transformations framework. 16493* Omega:: A solver for linear programming problems. 16494 16495 16496File: gccint.info, Node: Loop representation, Next: Loop querying, Up: Loop Analysis and Representation 16497 1649814.1 Loop representation 16499======================== 16500 16501This chapter describes the representation of loops in GCC, and functions 16502that can be used to build, modify and analyze this representation. Most 16503of the interfaces and data structures are declared in `cfgloop.h'. At 16504the moment, loop structures are analyzed and this information is 16505updated only by the optimization passes that deal with loops, but some 16506efforts are being made to make it available throughout most of the 16507optimization passes. 16508 16509 In general, a natural loop has one entry block (header) and possibly 16510several back edges (latches) leading to the header from the inside of 16511the loop. Loops with several latches may appear if several loops share 16512a single header, or if there is a branching in the middle of the loop. 16513The representation of loops in GCC however allows only loops with a 16514single latch. During loop analysis, headers of such loops are split and 16515forwarder blocks are created in order to disambiguate their structures. 16516Heuristic based on profile information and structure of the induction 16517variables in the loops is used to determine whether the latches 16518correspond to sub-loops or to control flow in a single loop. This means 16519that the analysis sometimes changes the CFG, and if you run it in the 16520middle of an optimization pass, you must be able to deal with the new 16521blocks. You may avoid CFG changes by passing 16522`LOOPS_MAY_HAVE_MULTIPLE_LATCHES' flag to the loop discovery, note 16523however that most other loop manipulation functions will not work 16524correctly for loops with multiple latch edges (the functions that only 16525query membership of blocks to loops and subloop relationships, or 16526enumerate and test loop exits, can be expected to work). 16527 16528 Body of the loop is the set of blocks that are dominated by its header, 16529and reachable from its latch against the direction of edges in CFG. The 16530loops are organized in a containment hierarchy (tree) such that all the 16531loops immediately contained inside loop L are the children of L in the 16532tree. This tree is represented by the `struct loops' structure. The 16533root of this tree is a fake loop that contains all blocks in the 16534function. Each of the loops is represented in a `struct loop' 16535structure. Each loop is assigned an index (`num' field of the `struct 16536loop' structure), and the pointer to the loop is stored in the 16537corresponding field of the `larray' vector in the loops structure. The 16538indices do not have to be continuous, there may be empty (`NULL') 16539entries in the `larray' created by deleting loops. Also, there is no 16540guarantee on the relative order of a loop and its subloops in the 16541numbering. The index of a loop never changes. 16542 16543 The entries of the `larray' field should not be accessed directly. 16544The function `get_loop' returns the loop description for a loop with 16545the given index. `number_of_loops' function returns number of loops in 16546the function. To traverse all loops, use `FOR_EACH_LOOP' macro. The 16547`flags' argument of the macro is used to determine the direction of 16548traversal and the set of loops visited. Each loop is guaranteed to be 16549visited exactly once, regardless of the changes to the loop tree, and 16550the loops may be removed during the traversal. The newly created loops 16551are never traversed, if they need to be visited, this must be done 16552separately after their creation. The `FOR_EACH_LOOP' macro allocates 16553temporary variables. If the `FOR_EACH_LOOP' loop were ended using 16554break or goto, they would not be released; `FOR_EACH_LOOP_BREAK' macro 16555must be used instead. 16556 16557 Each basic block contains the reference to the innermost loop it 16558belongs to (`loop_father'). For this reason, it is only possible to 16559have one `struct loops' structure initialized at the same time for each 16560CFG. The global variable `current_loops' contains the `struct loops' 16561structure. Many of the loop manipulation functions assume that 16562dominance information is up-to-date. 16563 16564 The loops are analyzed through `loop_optimizer_init' function. The 16565argument of this function is a set of flags represented in an integer 16566bitmask. These flags specify what other properties of the loop 16567structures should be calculated/enforced and preserved later: 16568 16569 * `LOOPS_MAY_HAVE_MULTIPLE_LATCHES': If this flag is set, no changes 16570 to CFG will be performed in the loop analysis, in particular, 16571 loops with multiple latch edges will not be disambiguated. If a 16572 loop has multiple latches, its latch block is set to NULL. Most of 16573 the loop manipulation functions will not work for loops in this 16574 shape. No other flags that require CFG changes can be passed to 16575 loop_optimizer_init. 16576 16577 * `LOOPS_HAVE_PREHEADERS': Forwarder blocks are created in such a 16578 way that each loop has only one entry edge, and additionally, the 16579 source block of this entry edge has only one successor. This 16580 creates a natural place where the code can be moved out of the 16581 loop, and ensures that the entry edge of the loop leads from its 16582 immediate super-loop. 16583 16584 * `LOOPS_HAVE_SIMPLE_LATCHES': Forwarder blocks are created to force 16585 the latch block of each loop to have only one successor. This 16586 ensures that the latch of the loop does not belong to any of its 16587 sub-loops, and makes manipulation with the loops significantly 16588 easier. Most of the loop manipulation functions assume that the 16589 loops are in this shape. Note that with this flag, the "normal" 16590 loop without any control flow inside and with one exit consists of 16591 two basic blocks. 16592 16593 * `LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS': Basic blocks and edges in 16594 the strongly connected components that are not natural loops (have 16595 more than one entry block) are marked with `BB_IRREDUCIBLE_LOOP' 16596 and `EDGE_IRREDUCIBLE_LOOP' flags. The flag is not set for blocks 16597 and edges that belong to natural loops that are in such an 16598 irreducible region (but it is set for the entry and exit edges of 16599 such a loop, if they lead to/from this region). 16600 16601 * `LOOPS_HAVE_RECORDED_EXITS': The lists of exits are recorded and 16602 updated for each loop. This makes some functions (e.g., 16603 `get_loop_exit_edges') more efficient. Some functions (e.g., 16604 `single_exit') can be used only if the lists of exits are recorded. 16605 16606 These properties may also be computed/enforced later, using functions 16607`create_preheaders', `force_single_succ_latches', 16608`mark_irreducible_loops' and `record_loop_exits'. 16609 16610 The memory occupied by the loops structures should be freed with 16611`loop_optimizer_finalize' function. 16612 16613 The CFG manipulation functions in general do not update loop 16614structures. Specialized versions that additionally do so are provided 16615for the most common tasks. On GIMPLE, `cleanup_tree_cfg_loop' function 16616can be used to cleanup CFG while updating the loops structures if 16617`current_loops' is set. 16618 16619 16620File: gccint.info, Node: Loop querying, Next: Loop manipulation, Prev: Loop representation, Up: Loop Analysis and Representation 16621 1662214.2 Loop querying 16623================== 16624 16625The functions to query the information about loops are declared in 16626`cfgloop.h'. Some of the information can be taken directly from the 16627structures. `loop_father' field of each basic block contains the 16628innermost loop to that the block belongs. The most useful fields of 16629loop structure (that are kept up-to-date at all times) are: 16630 16631 * `header', `latch': Header and latch basic blocks of the loop. 16632 16633 * `num_nodes': Number of basic blocks in the loop (including the 16634 basic blocks of the sub-loops). 16635 16636 * `depth': The depth of the loop in the loops tree, i.e., the number 16637 of super-loops of the loop. 16638 16639 * `outer', `inner', `next': The super-loop, the first sub-loop, and 16640 the sibling of the loop in the loops tree. 16641 16642 There are other fields in the loop structures, many of them used only 16643by some of the passes, or not updated during CFG changes; in general, 16644they should not be accessed directly. 16645 16646 The most important functions to query loop structures are: 16647 16648 * `flow_loops_dump': Dumps the information about loops to a file. 16649 16650 * `verify_loop_structure': Checks consistency of the loop structures. 16651 16652 * `loop_latch_edge': Returns the latch edge of a loop. 16653 16654 * `loop_preheader_edge': If loops have preheaders, returns the 16655 preheader edge of a loop. 16656 16657 * `flow_loop_nested_p': Tests whether loop is a sub-loop of another 16658 loop. 16659 16660 * `flow_bb_inside_loop_p': Tests whether a basic block belongs to a 16661 loop (including its sub-loops). 16662 16663 * `find_common_loop': Finds the common super-loop of two loops. 16664 16665 * `superloop_at_depth': Returns the super-loop of a loop with the 16666 given depth. 16667 16668 * `tree_num_loop_insns', `num_loop_insns': Estimates the number of 16669 insns in the loop, on GIMPLE and on RTL. 16670 16671 * `loop_exit_edge_p': Tests whether edge is an exit from a loop. 16672 16673 * `mark_loop_exit_edges': Marks all exit edges of all loops with 16674 `EDGE_LOOP_EXIT' flag. 16675 16676 * `get_loop_body', `get_loop_body_in_dom_order', 16677 `get_loop_body_in_bfs_order': Enumerates the basic blocks in the 16678 loop in depth-first search order in reversed CFG, ordered by 16679 dominance relation, and breath-first search order, respectively. 16680 16681 * `single_exit': Returns the single exit edge of the loop, or `NULL' 16682 if the loop has more than one exit. You can only use this 16683 function if LOOPS_HAVE_MARKED_SINGLE_EXITS property is used. 16684 16685 * `get_loop_exit_edges': Enumerates the exit edges of a loop. 16686 16687 * `just_once_each_iteration_p': Returns true if the basic block is 16688 executed exactly once during each iteration of a loop (that is, it 16689 does not belong to a sub-loop, and it dominates the latch of the 16690 loop). 16691 16692 16693File: gccint.info, Node: Loop manipulation, Next: LCSSA, Prev: Loop querying, Up: Loop Analysis and Representation 16694 1669514.3 Loop manipulation 16696====================== 16697 16698The loops tree can be manipulated using the following functions: 16699 16700 * `flow_loop_tree_node_add': Adds a node to the tree. 16701 16702 * `flow_loop_tree_node_remove': Removes a node from the tree. 16703 16704 * `add_bb_to_loop': Adds a basic block to a loop. 16705 16706 * `remove_bb_from_loops': Removes a basic block from loops. 16707 16708 Most low-level CFG functions update loops automatically. The following 16709functions handle some more complicated cases of CFG manipulations: 16710 16711 * `remove_path': Removes an edge and all blocks it dominates. 16712 16713 * `split_loop_exit_edge': Splits exit edge of the loop, ensuring 16714 that PHI node arguments remain in the loop (this ensures that 16715 loop-closed SSA form is preserved). Only useful on GIMPLE. 16716 16717 Finally, there are some higher-level loop transformations implemented. 16718While some of them are written so that they should work on non-innermost 16719loops, they are mostly untested in that case, and at the moment, they 16720are only reliable for the innermost loops: 16721 16722 * `create_iv': Creates a new induction variable. Only works on 16723 GIMPLE. `standard_iv_increment_position' can be used to find a 16724 suitable place for the iv increment. 16725 16726 * `duplicate_loop_to_header_edge', 16727 `tree_duplicate_loop_to_header_edge': These functions (on RTL and 16728 on GIMPLE) duplicate the body of the loop prescribed number of 16729 times on one of the edges entering loop header, thus performing 16730 either loop unrolling or loop peeling. `can_duplicate_loop_p' 16731 (`can_unroll_loop_p' on GIMPLE) must be true for the duplicated 16732 loop. 16733 16734 * `loop_version', `tree_ssa_loop_version': These function create a 16735 copy of a loop, and a branch before them that selects one of them 16736 depending on the prescribed condition. This is useful for 16737 optimizations that need to verify some assumptions in runtime (one 16738 of the copies of the loop is usually left unchanged, while the 16739 other one is transformed in some way). 16740 16741 * `tree_unroll_loop': Unrolls the loop, including peeling the extra 16742 iterations to make the number of iterations divisible by unroll 16743 factor, updating the exit condition, and removing the exits that 16744 now cannot be taken. Works only on GIMPLE. 16745 16746 16747File: gccint.info, Node: LCSSA, Next: Scalar evolutions, Prev: Loop manipulation, Up: Loop Analysis and Representation 16748 1674914.4 Loop-closed SSA form 16750========================= 16751 16752Throughout the loop optimizations on tree level, one extra condition is 16753enforced on the SSA form: No SSA name is used outside of the loop in 16754that it is defined. The SSA form satisfying this condition is called 16755"loop-closed SSA form" - LCSSA. To enforce LCSSA, PHI nodes must be 16756created at the exits of the loops for the SSA names that are used 16757outside of them. Only the real operands (not virtual SSA names) are 16758held in LCSSA, in order to save memory. 16759 16760 There are various benefits of LCSSA: 16761 16762 * Many optimizations (value range analysis, final value replacement) 16763 are interested in the values that are defined in the loop and used 16764 outside of it, i.e., exactly those for that we create new PHI 16765 nodes. 16766 16767 * In induction variable analysis, it is not necessary to specify the 16768 loop in that the analysis should be performed - the scalar 16769 evolution analysis always returns the results with respect to the 16770 loop in that the SSA name is defined. 16771 16772 * It makes updating of SSA form during loop transformations simpler. 16773 Without LCSSA, operations like loop unrolling may force creation 16774 of PHI nodes arbitrarily far from the loop, while in LCSSA, the 16775 SSA form can be updated locally. However, since we only keep real 16776 operands in LCSSA, we cannot use this advantage (we could have 16777 local updating of real operands, but it is not much more efficient 16778 than to use generic SSA form updating for it as well; the amount 16779 of changes to SSA is the same). 16780 16781 However, it also means LCSSA must be updated. This is usually 16782straightforward, unless you create a new value in loop and use it 16783outside, or unless you manipulate loop exit edges (functions are 16784provided to make these manipulations simple). 16785`rewrite_into_loop_closed_ssa' is used to rewrite SSA form to LCSSA, 16786and `verify_loop_closed_ssa' to check that the invariant of LCSSA is 16787preserved. 16788 16789 16790File: gccint.info, Node: Scalar evolutions, Next: loop-iv, Prev: LCSSA, Up: Loop Analysis and Representation 16791 1679214.5 Scalar evolutions 16793====================== 16794 16795Scalar evolutions (SCEV) are used to represent results of induction 16796variable analysis on GIMPLE. They enable us to represent variables with 16797complicated behavior in a simple and consistent way (we only use it to 16798express values of polynomial induction variables, but it is possible to 16799extend it). The interfaces to SCEV analysis are declared in 16800`tree-scalar-evolution.h'. To use scalar evolutions analysis, 16801`scev_initialize' must be used. To stop using SCEV, `scev_finalize' 16802should be used. SCEV analysis caches results in order to save time and 16803memory. This cache however is made invalid by most of the loop 16804transformations, including removal of code. If such a transformation 16805is performed, `scev_reset' must be called to clean the caches. 16806 16807 Given an SSA name, its behavior in loops can be analyzed using the 16808`analyze_scalar_evolution' function. The returned SCEV however does 16809not have to be fully analyzed and it may contain references to other 16810SSA names defined in the loop. To resolve these (potentially 16811recursive) references, `instantiate_parameters' or `resolve_mixers' 16812functions must be used. `instantiate_parameters' is useful when you 16813use the results of SCEV only for some analysis, and when you work with 16814whole nest of loops at once. It will try replacing all SSA names by 16815their SCEV in all loops, including the super-loops of the current loop, 16816thus providing a complete information about the behavior of the 16817variable in the loop nest. `resolve_mixers' is useful if you work with 16818only one loop at a time, and if you possibly need to create code based 16819on the value of the induction variable. It will only resolve the SSA 16820names defined in the current loop, leaving the SSA names defined 16821outside unchanged, even if their evolution in the outer loops is known. 16822 16823 The SCEV is a normal tree expression, except for the fact that it may 16824contain several special tree nodes. One of them is `SCEV_NOT_KNOWN', 16825used for SSA names whose value cannot be expressed. The other one is 16826`POLYNOMIAL_CHREC'. Polynomial chrec has three arguments - base, step 16827and loop (both base and step may contain further polynomial chrecs). 16828Type of the expression and of base and step must be the same. A 16829variable has evolution `POLYNOMIAL_CHREC(base, step, loop)' if it is 16830(in the specified loop) equivalent to `x_1' in the following example 16831 16832 while (...) 16833 { 16834 x_1 = phi (base, x_2); 16835 x_2 = x_1 + step; 16836 } 16837 16838 Note that this includes the language restrictions on the operations. 16839For example, if we compile C code and `x' has signed type, then the 16840overflow in addition would cause undefined behavior, and we may assume 16841that this does not happen. Hence, the value with this SCEV cannot 16842overflow (which restricts the number of iterations of such a loop). 16843 16844 In many cases, one wants to restrict the attention just to affine 16845induction variables. In this case, the extra expressive power of SCEV 16846is not useful, and may complicate the optimizations. In this case, 16847`simple_iv' function may be used to analyze a value - the result is a 16848loop-invariant base and step. 16849 16850 16851File: gccint.info, Node: loop-iv, Next: Number of iterations, Prev: Scalar evolutions, Up: Loop Analysis and Representation 16852 1685314.6 IV analysis on RTL 16854======================= 16855 16856The induction variable on RTL is simple and only allows analysis of 16857affine induction variables, and only in one loop at once. The interface 16858is declared in `cfgloop.h'. Before analyzing induction variables in a 16859loop L, `iv_analysis_loop_init' function must be called on L. After 16860the analysis (possibly calling `iv_analysis_loop_init' for several 16861loops) is finished, `iv_analysis_done' should be called. The following 16862functions can be used to access the results of the analysis: 16863 16864 * `iv_analyze': Analyzes a single register used in the given insn. 16865 If no use of the register in this insn is found, the following 16866 insns are scanned, so that this function can be called on the insn 16867 returned by get_condition. 16868 16869 * `iv_analyze_result': Analyzes result of the assignment in the 16870 given insn. 16871 16872 * `iv_analyze_expr': Analyzes a more complicated expression. All 16873 its operands are analyzed by `iv_analyze', and hence they must be 16874 used in the specified insn or one of the following insns. 16875 16876 The description of the induction variable is provided in `struct 16877rtx_iv'. In order to handle subregs, the representation is a bit 16878complicated; if the value of the `extend' field is not `UNKNOWN', the 16879value of the induction variable in the i-th iteration is 16880 16881 delta + mult * extend_{extend_mode} (subreg_{mode} (base + i * step)), 16882 16883 with the following exception: if `first_special' is true, then the 16884value in the first iteration (when `i' is zero) is `delta + mult * 16885base'. However, if `extend' is equal to `UNKNOWN', then 16886`first_special' must be false, `delta' 0, `mult' 1 and the value in the 16887i-th iteration is 16888 16889 subreg_{mode} (base + i * step) 16890 16891 The function `get_iv_value' can be used to perform these calculations. 16892 16893 16894File: gccint.info, Node: Number of iterations, Next: Dependency analysis, Prev: loop-iv, Up: Loop Analysis and Representation 16895 1689614.7 Number of iterations analysis 16897================================== 16898 16899Both on GIMPLE and on RTL, there are functions available to determine 16900the number of iterations of a loop, with a similar interface. The 16901number of iterations of a loop in GCC is defined as the number of 16902executions of the loop latch. In many cases, it is not possible to 16903determine the number of iterations unconditionally - the determined 16904number is correct only if some assumptions are satisfied. The analysis 16905tries to verify these conditions using the information contained in the 16906program; if it fails, the conditions are returned together with the 16907result. The following information and conditions are provided by the 16908analysis: 16909 16910 * `assumptions': If this condition is false, the rest of the 16911 information is invalid. 16912 16913 * `noloop_assumptions' on RTL, `may_be_zero' on GIMPLE: If this 16914 condition is true, the loop exits in the first iteration. 16915 16916 * `infinite': If this condition is true, the loop is infinite. This 16917 condition is only available on RTL. On GIMPLE, conditions for 16918 finiteness of the loop are included in `assumptions'. 16919 16920 * `niter_expr' on RTL, `niter' on GIMPLE: The expression that gives 16921 number of iterations. The number of iterations is defined as the 16922 number of executions of the loop latch. 16923 16924 Both on GIMPLE and on RTL, it necessary for the induction variable 16925analysis framework to be initialized (SCEV on GIMPLE, loop-iv on RTL). 16926On GIMPLE, the results are stored to `struct tree_niter_desc' 16927structure. Number of iterations before the loop is exited through a 16928given exit can be determined using `number_of_iterations_exit' 16929function. On RTL, the results are returned in `struct niter_desc' 16930structure. The corresponding function is named `check_simple_exit'. 16931There are also functions that pass through all the exits of a loop and 16932try to find one with easy to determine number of iterations - 16933`find_loop_niter' on GIMPLE and `find_simple_exit' on RTL. Finally, 16934there are functions that provide the same information, but additionally 16935cache it, so that repeated calls to number of iterations are not so 16936costly - `number_of_latch_executions' on GIMPLE and 16937`get_simple_loop_desc' on RTL. 16938 16939 Note that some of these functions may behave slightly differently than 16940others - some of them return only the expression for the number of 16941iterations, and fail if there are some assumptions. The function 16942`number_of_latch_executions' works only for single-exit loops. The 16943function `number_of_cond_exit_executions' can be used to determine 16944number of executions of the exit condition of a single-exit loop (i.e., 16945the `number_of_latch_executions' increased by one). 16946 16947 16948File: gccint.info, Node: Dependency analysis, Next: Lambda, Prev: Number of iterations, Up: Loop Analysis and Representation 16949 1695014.8 Data Dependency Analysis 16951============================= 16952 16953The code for the data dependence analysis can be found in 16954`tree-data-ref.c' and its interface and data structures are described 16955in `tree-data-ref.h'. The function that computes the data dependences 16956for all the array and pointer references for a given loop is 16957`compute_data_dependences_for_loop'. This function is currently used 16958by the linear loop transform and the vectorization passes. Before 16959calling this function, one has to allocate two vectors: a first vector 16960will contain the set of data references that are contained in the 16961analyzed loop body, and the second vector will contain the dependence 16962relations between the data references. Thus if the vector of data 16963references is of size `n', the vector containing the dependence 16964relations will contain `n*n' elements. However if the analyzed loop 16965contains side effects, such as calls that potentially can interfere 16966with the data references in the current analyzed loop, the analysis 16967stops while scanning the loop body for data references, and inserts a 16968single `chrec_dont_know' in the dependence relation array. 16969 16970 The data references are discovered in a particular order during the 16971scanning of the loop body: the loop body is analyzed in execution order, 16972and the data references of each statement are pushed at the end of the 16973data reference array. Two data references syntactically occur in the 16974program in the same order as in the array of data references. This 16975syntactic order is important in some classical data dependence tests, 16976and mapping this order to the elements of this array avoids costly 16977queries to the loop body representation. 16978 16979 Three types of data references are currently handled: ARRAY_REF, 16980INDIRECT_REF and COMPONENT_REF. The data structure for the data 16981reference is `data_reference', where `data_reference_p' is a name of a 16982pointer to the data reference structure. The structure contains the 16983following elements: 16984 16985 * `base_object_info': Provides information about the base object of 16986 the data reference and its access functions. These access functions 16987 represent the evolution of the data reference in the loop relative 16988 to its base, in keeping with the classical meaning of the data 16989 reference access function for the support of arrays. For example, 16990 for a reference `a.b[i][j]', the base object is `a.b' and the 16991 access functions, one for each array subscript, are: `{i_init, + 16992 i_step}_1, {j_init, +, j_step}_2'. 16993 16994 * `first_location_in_loop': Provides information about the first 16995 location accessed by the data reference in the loop and about the 16996 access function used to represent evolution relative to this 16997 location. This data is used to support pointers, and is not used 16998 for arrays (for which we have base objects). Pointer accesses are 16999 represented as a one-dimensional access that starts from the first 17000 location accessed in the loop. For example: 17001 17002 for1 i 17003 for2 j 17004 *((int *)p + i + j) = a[i][j]; 17005 17006 The access function of the pointer access is `{0, + 4B}_for2' 17007 relative to `p + i'. The access functions of the array are 17008 `{i_init, + i_step}_for1' and `{j_init, +, j_step}_for2' relative 17009 to `a'. 17010 17011 Usually, the object the pointer refers to is either unknown, or we 17012 can't prove that the access is confined to the boundaries of a 17013 certain object. 17014 17015 Two data references can be compared only if at least one of these 17016 two representations has all its fields filled for both data 17017 references. 17018 17019 The current strategy for data dependence tests is as follows: If 17020 both `a' and `b' are represented as arrays, compare 17021 `a.base_object' and `b.base_object'; if they are equal, apply 17022 dependence tests (use access functions based on base_objects). 17023 Else if both `a' and `b' are represented as pointers, compare 17024 `a.first_location' and `b.first_location'; if they are equal, 17025 apply dependence tests (use access functions based on first 17026 location). However, if `a' and `b' are represented differently, 17027 only try to prove that the bases are definitely different. 17028 17029 * Aliasing information. 17030 17031 * Alignment information. 17032 17033 The structure describing the relation between two data references is 17034`data_dependence_relation' and the shorter name for a pointer to such a 17035structure is `ddr_p'. This structure contains: 17036 17037 * a pointer to each data reference, 17038 17039 * a tree node `are_dependent' that is set to `chrec_known' if the 17040 analysis has proved that there is no dependence between these two 17041 data references, `chrec_dont_know' if the analysis was not able to 17042 determine any useful result and potentially there could exist a 17043 dependence between these data references, and `are_dependent' is 17044 set to `NULL_TREE' if there exist a dependence relation between the 17045 data references, and the description of this dependence relation is 17046 given in the `subscripts', `dir_vects', and `dist_vects' arrays, 17047 17048 * a boolean that determines whether the dependence relation can be 17049 represented by a classical distance vector, 17050 17051 * an array `subscripts' that contains a description of each 17052 subscript of the data references. Given two array accesses a 17053 subscript is the tuple composed of the access functions for a given 17054 dimension. For example, given `A[f1][f2][f3]' and 17055 `B[g1][g2][g3]', there are three subscripts: `(f1, g1), (f2, g2), 17056 (f3, g3)'. 17057 17058 * two arrays `dir_vects' and `dist_vects' that contain classical 17059 representations of the data dependences under the form of 17060 direction and distance dependence vectors, 17061 17062 * an array of loops `loop_nest' that contains the loops to which the 17063 distance and direction vectors refer to. 17064 17065 Several functions for pretty printing the information extracted by the 17066data dependence analysis are available: `dump_ddrs' prints with a 17067maximum verbosity the details of a data dependence relations array, 17068`dump_dist_dir_vectors' prints only the classical distance and 17069direction vectors for a data dependence relations array, and 17070`dump_data_references' prints the details of the data references 17071contained in a data reference array. 17072 17073 17074File: gccint.info, Node: Lambda, Next: Omega, Prev: Dependency analysis, Up: Loop Analysis and Representation 17075 1707614.9 Linear loop transformations framework 17077========================================== 17078 17079Lambda is a framework that allows transformations of loops using 17080non-singular matrix based transformations of the iteration space and 17081loop bounds. This allows compositions of skewing, scaling, interchange, 17082and reversal transformations. These transformations are often used to 17083improve cache behavior or remove inner loop dependencies to allow 17084parallelization and vectorization to take place. 17085 17086 To perform these transformations, Lambda requires that the loopnest be 17087converted into an internal form that can be matrix transformed easily. 17088To do this conversion, the function `gcc_loopnest_to_lambda_loopnest' 17089is provided. If the loop cannot be transformed using lambda, this 17090function will return NULL. 17091 17092 Once a `lambda_loopnest' is obtained from the conversion function, it 17093can be transformed by using `lambda_loopnest_transform', which takes a 17094transformation matrix to apply. Note that it is up to the caller to 17095verify that the transformation matrix is legal to apply to the loop 17096(dependence respecting, etc). Lambda simply applies whatever matrix it 17097is told to provide. It can be extended to make legal matrices out of 17098any non-singular matrix, but this is not currently implemented. 17099Legality of a matrix for a given loopnest can be verified using 17100`lambda_transform_legal_p'. 17101 17102 Given a transformed loopnest, conversion back into gcc IR is done by 17103`lambda_loopnest_to_gcc_loopnest'. This function will modify the loops 17104so that they match the transformed loopnest. 17105 17106 17107File: gccint.info, Node: Omega, Prev: Lambda, Up: Loop Analysis and Representation 17108 1710914.10 Omega a solver for linear programming problems 17110==================================================== 17111 17112The data dependence analysis contains several solvers triggered 17113sequentially from the less complex ones to the more sophisticated. For 17114ensuring the consistency of the results of these solvers, a data 17115dependence check pass has been implemented based on two different 17116solvers. The second method that has been integrated to GCC is based on 17117the Omega dependence solver, written in the 1990's by William Pugh and 17118David Wonnacott. Data dependence tests can be formulated using a 17119subset of the Presburger arithmetics that can be translated to linear 17120constraint systems. These linear constraint systems can then be solved 17121using the Omega solver. 17122 17123 The Omega solver is using Fourier-Motzkin's algorithm for variable 17124elimination: a linear constraint system containing `n' variables is 17125reduced to a linear constraint system with `n-1' variables. The Omega 17126solver can also be used for solving other problems that can be 17127expressed under the form of a system of linear equalities and 17128inequalities. The Omega solver is known to have an exponential worst 17129case, also known under the name of "omega nightmare" in the literature, 17130but in practice, the omega test is known to be efficient for the common 17131data dependence tests. 17132 17133 The interface used by the Omega solver for describing the linear 17134programming problems is described in `omega.h', and the solver is 17135`omega_solve_problem'. 17136 17137 17138File: gccint.info, Node: Control Flow, Next: Loop Analysis and Representation, Prev: RTL, Up: Top 17139 1714015 Control Flow Graph 17141********************* 17142 17143A control flow graph (CFG) is a data structure built on top of the 17144intermediate code representation (the RTL or `tree' instruction stream) 17145abstracting the control flow behavior of a function that is being 17146compiled. The CFG is a directed graph where the vertices represent 17147basic blocks and edges represent possible transfer of control flow from 17148one basic block to another. The data structures used to represent the 17149control flow graph are defined in `basic-block.h'. 17150 17151* Menu: 17152 17153* Basic Blocks:: The definition and representation of basic blocks. 17154* Edges:: Types of edges and their representation. 17155* Profile information:: Representation of frequencies and probabilities. 17156* Maintaining the CFG:: Keeping the control flow graph and up to date. 17157* Liveness information:: Using and maintaining liveness information. 17158 17159 17160File: gccint.info, Node: Basic Blocks, Next: Edges, Up: Control Flow 17161 1716215.1 Basic Blocks 17163================= 17164 17165A basic block is a straight-line sequence of code with only one entry 17166point and only one exit. In GCC, basic blocks are represented using 17167the `basic_block' data type. 17168 17169 Two pointer members of the `basic_block' structure are the pointers 17170`next_bb' and `prev_bb'. These are used to keep doubly linked chain of 17171basic blocks in the same order as the underlying instruction stream. 17172The chain of basic blocks is updated transparently by the provided API 17173for manipulating the CFG. The macro `FOR_EACH_BB' can be used to visit 17174all the basic blocks in lexicographical order. Dominator traversals 17175are also possible using `walk_dominator_tree'. Given two basic blocks 17176A and B, block A dominates block B if A is _always_ executed before B. 17177 17178 The `BASIC_BLOCK' array contains all basic blocks in an unspecified 17179order. Each `basic_block' structure has a field that holds a unique 17180integer identifier `index' that is the index of the block in the 17181`BASIC_BLOCK' array. The total number of basic blocks in the function 17182is `n_basic_blocks'. Both the basic block indices and the total number 17183of basic blocks may vary during the compilation process, as passes 17184reorder, create, duplicate, and destroy basic blocks. The index for 17185any block should never be greater than `last_basic_block'. 17186 17187 Special basic blocks represent possible entry and exit points of a 17188function. These blocks are called `ENTRY_BLOCK_PTR' and 17189`EXIT_BLOCK_PTR'. These blocks do not contain any code, and are not 17190elements of the `BASIC_BLOCK' array. Therefore they have been assigned 17191unique, negative index numbers. 17192 17193 Each `basic_block' also contains pointers to the first instruction 17194(the "head") and the last instruction (the "tail") or "end" of the 17195instruction stream contained in a basic block. In fact, since the 17196`basic_block' data type is used to represent blocks in both major 17197intermediate representations of GCC (`tree' and RTL), there are 17198pointers to the head and end of a basic block for both representations. 17199 17200 For RTL, these pointers are `rtx head, end'. In the RTL function 17201representation, the head pointer always points either to a 17202`NOTE_INSN_BASIC_BLOCK' or to a `CODE_LABEL', if present. In the RTL 17203representation of a function, the instruction stream contains not only 17204the "real" instructions, but also "notes". Any function that moves or 17205duplicates the basic blocks needs to take care of updating of these 17206notes. Many of these notes expect that the instruction stream consists 17207of linear regions, making such updates difficult. The 17208`NOTE_INSN_BASIC_BLOCK' note is the only kind of note that may appear 17209in the instruction stream contained in a basic block. The instruction 17210stream of a basic block always follows a `NOTE_INSN_BASIC_BLOCK', but 17211zero or more `CODE_LABEL' nodes can precede the block note. A basic 17212block ends by control flow instruction or last instruction before 17213following `CODE_LABEL' or `NOTE_INSN_BASIC_BLOCK'. A `CODE_LABEL' 17214cannot appear in the instruction stream of a basic block. 17215 17216 In addition to notes, the jump table vectors are also represented as 17217"pseudo-instructions" inside the insn stream. These vectors never 17218appear in the basic block and should always be placed just after the 17219table jump instructions referencing them. After removing the 17220table-jump it is often difficult to eliminate the code computing the 17221address and referencing the vector, so cleaning up these vectors is 17222postponed until after liveness analysis. Thus the jump table vectors 17223may appear in the insn stream unreferenced and without any purpose. 17224Before any edge is made "fall-thru", the existence of such construct in 17225the way needs to be checked by calling `can_fallthru' function. 17226 17227 For the `tree' representation, the head and end of the basic block are 17228being pointed to by the `stmt_list' field, but this special `tree' 17229should never be referenced directly. Instead, at the tree level 17230abstract containers and iterators are used to access statements and 17231expressions in basic blocks. These iterators are called "block 17232statement iterators" (BSIs). Grep for `^bsi' in the various `tree-*' 17233files. The following snippet will pretty-print all the statements of 17234the program in the GIMPLE representation. 17235 17236 FOR_EACH_BB (bb) 17237 { 17238 block_stmt_iterator si; 17239 17240 for (si = bsi_start (bb); !bsi_end_p (si); bsi_next (&si)) 17241 { 17242 tree stmt = bsi_stmt (si); 17243 print_generic_stmt (stderr, stmt, 0); 17244 } 17245 } 17246 17247 17248File: gccint.info, Node: Edges, Next: Profile information, Prev: Basic Blocks, Up: Control Flow 17249 1725015.2 Edges 17251========== 17252 17253Edges represent possible control flow transfers from the end of some 17254basic block A to the head of another basic block B. We say that A is a 17255predecessor of B, and B is a successor of A. Edges are represented in 17256GCC with the `edge' data type. Each `edge' acts as a link between two 17257basic blocks: the `src' member of an edge points to the predecessor 17258basic block of the `dest' basic block. The members `preds' and `succs' 17259of the `basic_block' data type point to type-safe vectors of edges to 17260the predecessors and successors of the block. 17261 17262 When walking the edges in an edge vector, "edge iterators" should be 17263used. Edge iterators are constructed using the `edge_iterator' data 17264structure and several methods are available to operate on them: 17265 17266`ei_start' 17267 This function initializes an `edge_iterator' that points to the 17268 first edge in a vector of edges. 17269 17270`ei_last' 17271 This function initializes an `edge_iterator' that points to the 17272 last edge in a vector of edges. 17273 17274`ei_end_p' 17275 This predicate is `true' if an `edge_iterator' represents the last 17276 edge in an edge vector. 17277 17278`ei_one_before_end_p' 17279 This predicate is `true' if an `edge_iterator' represents the 17280 second last edge in an edge vector. 17281 17282`ei_next' 17283 This function takes a pointer to an `edge_iterator' and makes it 17284 point to the next edge in the sequence. 17285 17286`ei_prev' 17287 This function takes a pointer to an `edge_iterator' and makes it 17288 point to the previous edge in the sequence. 17289 17290`ei_edge' 17291 This function returns the `edge' currently pointed to by an 17292 `edge_iterator'. 17293 17294`ei_safe_safe' 17295 This function returns the `edge' currently pointed to by an 17296 `edge_iterator', but returns `NULL' if the iterator is pointing at 17297 the end of the sequence. This function has been provided for 17298 existing code makes the assumption that a `NULL' edge indicates 17299 the end of the sequence. 17300 17301 17302 The convenience macro `FOR_EACH_EDGE' can be used to visit all of the 17303edges in a sequence of predecessor or successor edges. It must not be 17304used when an element might be removed during the traversal, otherwise 17305elements will be missed. Here is an example of how to use the macro: 17306 17307 edge e; 17308 edge_iterator ei; 17309 17310 FOR_EACH_EDGE (e, ei, bb->succs) 17311 { 17312 if (e->flags & EDGE_FALLTHRU) 17313 break; 17314 } 17315 17316 There are various reasons why control flow may transfer from one block 17317to another. One possibility is that some instruction, for example a 17318`CODE_LABEL', in a linearized instruction stream just always starts a 17319new basic block. In this case a "fall-thru" edge links the basic block 17320to the first following basic block. But there are several other 17321reasons why edges may be created. The `flags' field of the `edge' data 17322type is used to store information about the type of edge we are dealing 17323with. Each edge is of one of the following types: 17324 17325_jump_ 17326 No type flags are set for edges corresponding to jump instructions. 17327 These edges are used for unconditional or conditional jumps and in 17328 RTL also for table jumps. They are the easiest to manipulate as 17329 they may be freely redirected when the flow graph is not in SSA 17330 form. 17331 17332_fall-thru_ 17333 Fall-thru edges are present in case where the basic block may 17334 continue execution to the following one without branching. These 17335 edges have the `EDGE_FALLTHRU' flag set. Unlike other types of 17336 edges, these edges must come into the basic block immediately 17337 following in the instruction stream. The function 17338 `force_nonfallthru' is available to insert an unconditional jump 17339 in the case that redirection is needed. Note that this may 17340 require creation of a new basic block. 17341 17342_exception handling_ 17343 Exception handling edges represent possible control transfers from 17344 a trapping instruction to an exception handler. The definition of 17345 "trapping" varies. In C++, only function calls can throw, but for 17346 Java, exceptions like division by zero or segmentation fault are 17347 defined and thus each instruction possibly throwing this kind of 17348 exception needs to be handled as control flow instruction. 17349 Exception edges have the `EDGE_ABNORMAL' and `EDGE_EH' flags set. 17350 17351 When updating the instruction stream it is easy to change possibly 17352 trapping instruction to non-trapping, by simply removing the 17353 exception edge. The opposite conversion is difficult, but should 17354 not happen anyway. The edges can be eliminated via 17355 `purge_dead_edges' call. 17356 17357 In the RTL representation, the destination of an exception edge is 17358 specified by `REG_EH_REGION' note attached to the insn. In case 17359 of a trapping call the `EDGE_ABNORMAL_CALL' flag is set too. In 17360 the `tree' representation, this extra flag is not set. 17361 17362 In the RTL representation, the predicate `may_trap_p' may be used 17363 to check whether instruction still may trap or not. For the tree 17364 representation, the `tree_could_trap_p' predicate is available, 17365 but this predicate only checks for possible memory traps, as in 17366 dereferencing an invalid pointer location. 17367 17368_sibling calls_ 17369 Sibling calls or tail calls terminate the function in a 17370 non-standard way and thus an edge to the exit must be present. 17371 `EDGE_SIBCALL' and `EDGE_ABNORMAL' are set in such case. These 17372 edges only exist in the RTL representation. 17373 17374_computed jumps_ 17375 Computed jumps contain edges to all labels in the function 17376 referenced from the code. All those edges have `EDGE_ABNORMAL' 17377 flag set. The edges used to represent computed jumps often cause 17378 compile time performance problems, since functions consisting of 17379 many taken labels and many computed jumps may have _very_ dense 17380 flow graphs, so these edges need to be handled with special care. 17381 During the earlier stages of the compilation process, GCC tries to 17382 avoid such dense flow graphs by factoring computed jumps. For 17383 example, given the following series of jumps, 17384 17385 goto *x; 17386 [ ... ] 17387 17388 goto *x; 17389 [ ... ] 17390 17391 goto *x; 17392 [ ... ] 17393 17394 factoring the computed jumps results in the following code sequence 17395 which has a much simpler flow graph: 17396 17397 goto y; 17398 [ ... ] 17399 17400 goto y; 17401 [ ... ] 17402 17403 goto y; 17404 [ ... ] 17405 17406 y: 17407 goto *x; 17408 17409 However, the classic problem with this transformation is that it 17410 has a runtime cost in there resulting code: An extra jump. 17411 Therefore, the computed jumps are un-factored in the later passes 17412 of the compiler. Be aware of that when you work on passes in that 17413 area. There have been numerous examples already where the compile 17414 time for code with unfactored computed jumps caused some serious 17415 headaches. 17416 17417_nonlocal goto handlers_ 17418 GCC allows nested functions to return into caller using a `goto' 17419 to a label passed to as an argument to the callee. The labels 17420 passed to nested functions contain special code to cleanup after 17421 function call. Such sections of code are referred to as "nonlocal 17422 goto receivers". If a function contains such nonlocal goto 17423 receivers, an edge from the call to the label is created with the 17424 `EDGE_ABNORMAL' and `EDGE_ABNORMAL_CALL' flags set. 17425 17426_function entry points_ 17427 By definition, execution of function starts at basic block 0, so 17428 there is always an edge from the `ENTRY_BLOCK_PTR' to basic block 17429 0. There is no `tree' representation for alternate entry points at 17430 this moment. In RTL, alternate entry points are specified by 17431 `CODE_LABEL' with `LABEL_ALTERNATE_NAME' defined. This feature is 17432 currently used for multiple entry point prologues and is limited 17433 to post-reload passes only. This can be used by back-ends to emit 17434 alternate prologues for functions called from different contexts. 17435 In future full support for multiple entry functions defined by 17436 Fortran 90 needs to be implemented. 17437 17438_function exits_ 17439 In the pre-reload representation a function terminates after the 17440 last instruction in the insn chain and no explicit return 17441 instructions are used. This corresponds to the fall-thru edge 17442 into exit block. After reload, optimal RTL epilogues are used 17443 that use explicit (conditional) return instructions that are 17444 represented by edges with no flags set. 17445 17446 17447 17448File: gccint.info, Node: Profile information, Next: Maintaining the CFG, Prev: Edges, Up: Control Flow 17449 1745015.3 Profile information 17451======================== 17452 17453In many cases a compiler must make a choice whether to trade speed in 17454one part of code for speed in another, or to trade code size for code 17455speed. In such cases it is useful to know information about how often 17456some given block will be executed. That is the purpose for maintaining 17457profile within the flow graph. GCC can handle profile information 17458obtained through "profile feedback", but it can also estimate branch 17459probabilities based on statics and heuristics. 17460 17461 The feedback based profile is produced by compiling the program with 17462instrumentation, executing it on a train run and reading the numbers of 17463executions of basic blocks and edges back to the compiler while 17464re-compiling the program to produce the final executable. This method 17465provides very accurate information about where a program spends most of 17466its time on the train run. Whether it matches the average run of 17467course depends on the choice of train data set, but several studies 17468have shown that the behavior of a program usually changes just 17469marginally over different data sets. 17470 17471 When profile feedback is not available, the compiler may be asked to 17472attempt to predict the behavior of each branch in the program using a 17473set of heuristics (see `predict.def' for details) and compute estimated 17474frequencies of each basic block by propagating the probabilities over 17475the graph. 17476 17477 Each `basic_block' contains two integer fields to represent profile 17478information: `frequency' and `count'. The `frequency' is an estimation 17479how often is basic block executed within a function. It is represented 17480as an integer scaled in the range from 0 to `BB_FREQ_BASE'. The most 17481frequently executed basic block in function is initially set to 17482`BB_FREQ_BASE' and the rest of frequencies are scaled accordingly. 17483During optimization, the frequency of the most frequent basic block can 17484both decrease (for instance by loop unrolling) or grow (for instance by 17485cross-jumping optimization), so scaling sometimes has to be performed 17486multiple times. 17487 17488 The `count' contains hard-counted numbers of execution measured during 17489training runs and is nonzero only when profile feedback is available. 17490This value is represented as the host's widest integer (typically a 64 17491bit integer) of the special type `gcov_type'. 17492 17493 Most optimization passes can use only the frequency information of a 17494basic block, but a few passes may want to know hard execution counts. 17495The frequencies should always match the counts after scaling, however 17496during updating of the profile information numerical error may 17497accumulate into quite large errors. 17498 17499 Each edge also contains a branch probability field: an integer in the 17500range from 0 to `REG_BR_PROB_BASE'. It represents probability of 17501passing control from the end of the `src' basic block to the `dest' 17502basic block, i.e. the probability that control will flow along this 17503edge. The `EDGE_FREQUENCY' macro is available to compute how 17504frequently a given edge is taken. There is a `count' field for each 17505edge as well, representing same information as for a basic block. 17506 17507 The basic block frequencies are not represented in the instruction 17508stream, but in the RTL representation the edge frequencies are 17509represented for conditional jumps (via the `REG_BR_PROB' macro) since 17510they are used when instructions are output to the assembly file and the 17511flow graph is no longer maintained. 17512 17513 The probability that control flow arrives via a given edge to its 17514destination basic block is called "reverse probability" and is not 17515directly represented, but it may be easily computed from frequencies of 17516basic blocks. 17517 17518 Updating profile information is a delicate task that can unfortunately 17519not be easily integrated with the CFG manipulation API. Many of the 17520functions and hooks to modify the CFG, such as 17521`redirect_edge_and_branch', do not have enough information to easily 17522update the profile, so updating it is in the majority of cases left up 17523to the caller. It is difficult to uncover bugs in the profile updating 17524code, because they manifest themselves only by producing worse code, 17525and checking profile consistency is not possible because of numeric 17526error accumulation. Hence special attention needs to be given to this 17527issue in each pass that modifies the CFG. 17528 17529 It is important to point out that `REG_BR_PROB_BASE' and 17530`BB_FREQ_BASE' are both set low enough to be possible to compute second 17531power of any frequency or probability in the flow graph, it is not 17532possible to even square the `count' field, as modern CPUs are fast 17533enough to execute $2^32$ operations quickly. 17534 17535 17536File: gccint.info, Node: Maintaining the CFG, Next: Liveness information, Prev: Profile information, Up: Control Flow 17537 1753815.4 Maintaining the CFG 17539======================== 17540 17541An important task of each compiler pass is to keep both the control 17542flow graph and all profile information up-to-date. Reconstruction of 17543the control flow graph after each pass is not an option, since it may be 17544very expensive and lost profile information cannot be reconstructed at 17545all. 17546 17547 GCC has two major intermediate representations, and both use the 17548`basic_block' and `edge' data types to represent control flow. Both 17549representations share as much of the CFG maintenance code as possible. 17550For each representation, a set of "hooks" is defined so that each 17551representation can provide its own implementation of CFG manipulation 17552routines when necessary. These hooks are defined in `cfghooks.h'. 17553There are hooks for almost all common CFG manipulations, including 17554block splitting and merging, edge redirection and creating and deleting 17555basic blocks. These hooks should provide everything you need to 17556maintain and manipulate the CFG in both the RTL and `tree' 17557representation. 17558 17559 At the moment, the basic block boundaries are maintained transparently 17560when modifying instructions, so there rarely is a need to move them 17561manually (such as in case someone wants to output instruction outside 17562basic block explicitly). Often the CFG may be better viewed as 17563integral part of instruction chain, than structure built on the top of 17564it. However, in principle the control flow graph for the `tree' 17565representation is _not_ an integral part of the representation, in that 17566a function tree may be expanded without first building a flow graph 17567for the `tree' representation at all. This happens when compiling 17568without any `tree' optimization enabled. When the `tree' optimizations 17569are enabled and the instruction stream is rewritten in SSA form, the 17570CFG is very tightly coupled with the instruction stream. In 17571particular, statement insertion and removal has to be done with care. 17572In fact, the whole `tree' representation can not be easily used or 17573maintained without proper maintenance of the CFG simultaneously. 17574 17575 In the RTL representation, each instruction has a `BLOCK_FOR_INSN' 17576value that represents pointer to the basic block that contains the 17577instruction. In the `tree' representation, the function `bb_for_stmt' 17578returns a pointer to the basic block containing the queried statement. 17579 17580 When changes need to be applied to a function in its `tree' 17581representation, "block statement iterators" should be used. These 17582iterators provide an integrated abstraction of the flow graph and the 17583instruction stream. Block statement iterators are constructed using 17584the `block_stmt_iterator' data structure and several modifier are 17585available, including the following: 17586 17587`bsi_start' 17588 This function initializes a `block_stmt_iterator' that points to 17589 the first non-empty statement in a basic block. 17590 17591`bsi_last' 17592 This function initializes a `block_stmt_iterator' that points to 17593 the last statement in a basic block. 17594 17595`bsi_end_p' 17596 This predicate is `true' if a `block_stmt_iterator' represents the 17597 end of a basic block. 17598 17599`bsi_next' 17600 This function takes a `block_stmt_iterator' and makes it point to 17601 its successor. 17602 17603`bsi_prev' 17604 This function takes a `block_stmt_iterator' and makes it point to 17605 its predecessor. 17606 17607`bsi_insert_after' 17608 This function inserts a statement after the `block_stmt_iterator' 17609 passed in. The final parameter determines whether the statement 17610 iterator is updated to point to the newly inserted statement, or 17611 left pointing to the original statement. 17612 17613`bsi_insert_before' 17614 This function inserts a statement before the `block_stmt_iterator' 17615 passed in. The final parameter determines whether the statement 17616 iterator is updated to point to the newly inserted statement, or 17617 left pointing to the original statement. 17618 17619`bsi_remove' 17620 This function removes the `block_stmt_iterator' passed in and 17621 rechains the remaining statements in a basic block, if any. 17622 17623 In the RTL representation, the macros `BB_HEAD' and `BB_END' may be 17624used to get the head and end `rtx' of a basic block. No abstract 17625iterators are defined for traversing the insn chain, but you can just 17626use `NEXT_INSN' and `PREV_INSN' instead. *Note Insns::. 17627 17628 Usually a code manipulating pass simplifies the instruction stream and 17629the flow of control, possibly eliminating some edges. This may for 17630example happen when a conditional jump is replaced with an 17631unconditional jump, but also when simplifying possibly trapping 17632instruction to non-trapping while compiling Java. Updating of edges is 17633not transparent and each optimization pass is required to do so 17634manually. However only few cases occur in practice. The pass may call 17635`purge_dead_edges' on a given basic block to remove superfluous edges, 17636if any. 17637 17638 Another common scenario is redirection of branch instructions, but 17639this is best modeled as redirection of edges in the control flow graph 17640and thus use of `redirect_edge_and_branch' is preferred over more low 17641level functions, such as `redirect_jump' that operate on RTL chain 17642only. The CFG hooks defined in `cfghooks.h' should provide the 17643complete API required for manipulating and maintaining the CFG. 17644 17645 It is also possible that a pass has to insert control flow instruction 17646into the middle of a basic block, thus creating an entry point in the 17647middle of the basic block, which is impossible by definition: The block 17648must be split to make sure it only has one entry point, i.e. the head 17649of the basic block. The CFG hook `split_block' may be used when an 17650instruction in the middle of a basic block has to become the target of 17651a jump or branch instruction. 17652 17653 For a global optimizer, a common operation is to split edges in the 17654flow graph and insert instructions on them. In the RTL representation, 17655this can be easily done using the `insert_insn_on_edge' function that 17656emits an instruction "on the edge", caching it for a later 17657`commit_edge_insertions' call that will take care of moving the 17658inserted instructions off the edge into the instruction stream 17659contained in a basic block. This includes the creation of new basic 17660blocks where needed. In the `tree' representation, the equivalent 17661functions are `bsi_insert_on_edge' which inserts a block statement 17662iterator on an edge, and `bsi_commit_edge_inserts' which flushes the 17663instruction to actual instruction stream. 17664 17665 While debugging the optimization pass, a `verify_flow_info' function 17666may be useful to find bugs in the control flow graph updating code. 17667 17668 Note that at present, the representation of control flow in the `tree' 17669representation is discarded before expanding to RTL. Long term the CFG 17670should be maintained and "expanded" to the RTL representation along 17671with the function `tree' itself. 17672 17673 17674File: gccint.info, Node: Liveness information, Prev: Maintaining the CFG, Up: Control Flow 17675 1767615.5 Liveness information 17677========================= 17678 17679Liveness information is useful to determine whether some register is 17680"live" at given point of program, i.e. that it contains a value that 17681may be used at a later point in the program. This information is used, 17682for instance, during register allocation, as the pseudo registers only 17683need to be assigned to a unique hard register or to a stack slot if 17684they are live. The hard registers and stack slots may be freely reused 17685for other values when a register is dead. 17686 17687 Liveness information is available in the back end starting with 17688`pass_df_initialize' and ending with `pass_df_finish'. Three flavors 17689of live analysis are available: With `LR', it is possible to determine 17690at any point `P' in the function if the register may be used on some 17691path from `P' to the end of the function. With `UR', it is possible to 17692determine if there is a path from the beginning of the function to `P' 17693that defines the variable. `LIVE' is the intersection of the `LR' and 17694`UR' and a variable is live at `P' if there is both an assignment that 17695reaches it from the beginning of the function and a use that can be 17696reached on some path from `P' to the end of the function. 17697 17698 In general `LIVE' is the most useful of the three. The macros 17699`DF_[LR,UR,LIVE]_[IN,OUT]' can be used to access this information. The 17700macros take a basic block number and return a bitmap that is indexed by 17701the register number. This information is only guaranteed to be up to 17702date after calls are made to `df_analyze'. See the file `df-core.c' 17703for details on using the dataflow. 17704 17705 The liveness information is stored partly in the RTL instruction stream 17706and partly in the flow graph. Local information is stored in the 17707instruction stream: Each instruction may contain `REG_DEAD' notes 17708representing that the value of a given register is no longer needed, or 17709`REG_UNUSED' notes representing that the value computed by the 17710instruction is never used. The second is useful for instructions 17711computing multiple values at once. 17712 17713 17714File: gccint.info, Node: Machine Desc, Next: Target Macros, Prev: Loop Analysis and Representation, Up: Top 17715 1771616 Machine Descriptions 17717*********************** 17718 17719A machine description has two parts: a file of instruction patterns 17720(`.md' file) and a C header file of macro definitions. 17721 17722 The `.md' file for a target machine contains a pattern for each 17723instruction that the target machine supports (or at least each 17724instruction that is worth telling the compiler about). It may also 17725contain comments. A semicolon causes the rest of the line to be a 17726comment, unless the semicolon is inside a quoted string. 17727 17728 See the next chapter for information on the C header file. 17729 17730* Menu: 17731 17732* Overview:: How the machine description is used. 17733* Patterns:: How to write instruction patterns. 17734* Example:: An explained example of a `define_insn' pattern. 17735* RTL Template:: The RTL template defines what insns match a pattern. 17736* Output Template:: The output template says how to make assembler code 17737 from such an insn. 17738* Output Statement:: For more generality, write C code to output 17739 the assembler code. 17740* Predicates:: Controlling what kinds of operands can be used 17741 for an insn. 17742* Constraints:: Fine-tuning operand selection. 17743* Standard Names:: Names mark patterns to use for code generation. 17744* Pattern Ordering:: When the order of patterns makes a difference. 17745* Dependent Patterns:: Having one pattern may make you need another. 17746* Jump Patterns:: Special considerations for patterns for jump insns. 17747* Looping Patterns:: How to define patterns for special looping insns. 17748* Insn Canonicalizations::Canonicalization of Instructions 17749* Expander Definitions::Generating a sequence of several RTL insns 17750 for a standard operation. 17751* Insn Splitting:: Splitting Instructions into Multiple Instructions. 17752* Including Patterns:: Including Patterns in Machine Descriptions. 17753* Peephole Definitions::Defining machine-specific peephole optimizations. 17754* Insn Attributes:: Specifying the value of attributes for generated insns. 17755* Conditional Execution::Generating `define_insn' patterns for 17756 predication. 17757* Constant Definitions::Defining symbolic constants that can be used in the 17758 md file. 17759* Iterators:: Using iterators to generate patterns from a template. 17760 17761 17762File: gccint.info, Node: Overview, Next: Patterns, Up: Machine Desc 17763 1776416.1 Overview of How the Machine Description is Used 17765==================================================== 17766 17767There are three main conversions that happen in the compiler: 17768 17769 1. The front end reads the source code and builds a parse tree. 17770 17771 2. The parse tree is used to generate an RTL insn list based on named 17772 instruction patterns. 17773 17774 3. The insn list is matched against the RTL templates to produce 17775 assembler code. 17776 17777 17778 For the generate pass, only the names of the insns matter, from either 17779a named `define_insn' or a `define_expand'. The compiler will choose 17780the pattern with the right name and apply the operands according to the 17781documentation later in this chapter, without regard for the RTL 17782template or operand constraints. Note that the names the compiler looks 17783for are hard-coded in the compiler--it will ignore unnamed patterns and 17784patterns with names it doesn't know about, but if you don't provide a 17785named pattern it needs, it will abort. 17786 17787 If a `define_insn' is used, the template given is inserted into the 17788insn list. If a `define_expand' is used, one of three things happens, 17789based on the condition logic. The condition logic may manually create 17790new insns for the insn list, say via `emit_insn()', and invoke `DONE'. 17791For certain named patterns, it may invoke `FAIL' to tell the compiler 17792to use an alternate way of performing that task. If it invokes neither 17793`DONE' nor `FAIL', the template given in the pattern is inserted, as if 17794the `define_expand' were a `define_insn'. 17795 17796 Once the insn list is generated, various optimization passes convert, 17797replace, and rearrange the insns in the insn list. This is where the 17798`define_split' and `define_peephole' patterns get used, for example. 17799 17800 Finally, the insn list's RTL is matched up with the RTL templates in 17801the `define_insn' patterns, and those patterns are used to emit the 17802final assembly code. For this purpose, each named `define_insn' acts 17803like it's unnamed, since the names are ignored. 17804 17805 17806File: gccint.info, Node: Patterns, Next: Example, Prev: Overview, Up: Machine Desc 17807 1780816.2 Everything about Instruction Patterns 17809========================================== 17810 17811Each instruction pattern contains an incomplete RTL expression, with 17812pieces to be filled in later, operand constraints that restrict how the 17813pieces can be filled in, and an output pattern or C code to generate 17814the assembler output, all wrapped up in a `define_insn' expression. 17815 17816 A `define_insn' is an RTL expression containing four or five operands: 17817 17818 1. An optional name. The presence of a name indicate that this 17819 instruction pattern can perform a certain standard job for the 17820 RTL-generation pass of the compiler. This pass knows certain 17821 names and will use the instruction patterns with those names, if 17822 the names are defined in the machine description. 17823 17824 The absence of a name is indicated by writing an empty string 17825 where the name should go. Nameless instruction patterns are never 17826 used for generating RTL code, but they may permit several simpler 17827 insns to be combined later on. 17828 17829 Names that are not thus known and used in RTL-generation have no 17830 effect; they are equivalent to no name at all. 17831 17832 For the purpose of debugging the compiler, you may also specify a 17833 name beginning with the `*' character. Such a name is used only 17834 for identifying the instruction in RTL dumps; it is entirely 17835 equivalent to having a nameless pattern for all other purposes. 17836 17837 2. The "RTL template" (*note RTL Template::) is a vector of incomplete 17838 RTL expressions which show what the instruction should look like. 17839 It is incomplete because it may contain `match_operand', 17840 `match_operator', and `match_dup' expressions that stand for 17841 operands of the instruction. 17842 17843 If the vector has only one element, that element is the template 17844 for the instruction pattern. If the vector has multiple elements, 17845 then the instruction pattern is a `parallel' expression containing 17846 the elements described. 17847 17848 3. A condition. This is a string which contains a C expression that 17849 is the final test to decide whether an insn body matches this 17850 pattern. 17851 17852 For a named pattern, the condition (if present) may not depend on 17853 the data in the insn being matched, but only the 17854 target-machine-type flags. The compiler needs to test these 17855 conditions during initialization in order to learn exactly which 17856 named instructions are available in a particular run. 17857 17858 For nameless patterns, the condition is applied only when matching 17859 an individual insn, and only after the insn has matched the 17860 pattern's recognition template. The insn's operands may be found 17861 in the vector `operands'. For an insn where the condition has 17862 once matched, it can't be used to control register allocation, for 17863 example by excluding certain hard registers or hard register 17864 combinations. 17865 17866 4. The "output template": a string that says how to output matching 17867 insns as assembler code. `%' in this string specifies where to 17868 substitute the value of an operand. *Note Output Template::. 17869 17870 When simple substitution isn't general enough, you can specify a 17871 piece of C code to compute the output. *Note Output Statement::. 17872 17873 5. Optionally, a vector containing the values of attributes for insns 17874 matching this pattern. *Note Insn Attributes::. 17875 17876 17877File: gccint.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc 17878 1787916.3 Example of `define_insn' 17880============================= 17881 17882Here is an actual example of an instruction pattern, for the 1788368000/68020. 17884 17885 (define_insn "tstsi" 17886 [(set (cc0) 17887 (match_operand:SI 0 "general_operand" "rm"))] 17888 "" 17889 "* 17890 { 17891 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 17892 return \"tstl %0\"; 17893 return \"cmpl #0,%0\"; 17894 }") 17895 17896This can also be written using braced strings: 17897 17898 (define_insn "tstsi" 17899 [(set (cc0) 17900 (match_operand:SI 0 "general_operand" "rm"))] 17901 "" 17902 { 17903 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 17904 return "tstl %0"; 17905 return "cmpl #0,%0"; 17906 }) 17907 17908 This is an instruction that sets the condition codes based on the 17909value of a general operand. It has no condition, so any insn whose RTL 17910description has the form shown may be handled according to this 17911pattern. The name `tstsi' means "test a `SImode' value" and tells the 17912RTL generation pass that, when it is necessary to test such a value, an 17913insn to do so can be constructed using this pattern. 17914 17915 The output control string is a piece of C code which chooses which 17916output template to return based on the kind of operand and the specific 17917type of CPU for which code is being generated. 17918 17919 `"rm"' is an operand constraint. Its meaning is explained below. 17920 17921 17922File: gccint.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc 17923 1792416.4 RTL Template 17925================= 17926 17927The RTL template is used to define which insns match the particular 17928pattern and how to find their operands. For named patterns, the RTL 17929template also says how to construct an insn from specified operands. 17930 17931 Construction involves substituting specified operands into a copy of 17932the template. Matching involves determining the values that serve as 17933the operands in the insn being matched. Both of these activities are 17934controlled by special expression types that direct matching and 17935substitution of the operands. 17936 17937`(match_operand:M N PREDICATE CONSTRAINT)' 17938 This expression is a placeholder for operand number N of the insn. 17939 When constructing an insn, operand number N will be substituted at 17940 this point. When matching an insn, whatever appears at this 17941 position in the insn will be taken as operand number N; but it 17942 must satisfy PREDICATE or this instruction pattern will not match 17943 at all. 17944 17945 Operand numbers must be chosen consecutively counting from zero in 17946 each instruction pattern. There may be only one `match_operand' 17947 expression in the pattern for each operand number. Usually 17948 operands are numbered in the order of appearance in `match_operand' 17949 expressions. In the case of a `define_expand', any operand numbers 17950 used only in `match_dup' expressions have higher values than all 17951 other operand numbers. 17952 17953 PREDICATE is a string that is the name of a function that accepts 17954 two arguments, an expression and a machine mode. *Note 17955 Predicates::. During matching, the function will be called with 17956 the putative operand as the expression and M as the mode argument 17957 (if M is not specified, `VOIDmode' will be used, which normally 17958 causes PREDICATE to accept any mode). If it returns zero, this 17959 instruction pattern fails to match. PREDICATE may be an empty 17960 string; then it means no test is to be done on the operand, so 17961 anything which occurs in this position is valid. 17962 17963 Most of the time, PREDICATE will reject modes other than M--but 17964 not always. For example, the predicate `address_operand' uses M 17965 as the mode of memory ref that the address should be valid for. 17966 Many predicates accept `const_int' nodes even though their mode is 17967 `VOIDmode'. 17968 17969 CONSTRAINT controls reloading and the choice of the best register 17970 class to use for a value, as explained later (*note Constraints::). 17971 If the constraint would be an empty string, it can be omitted. 17972 17973 People are often unclear on the difference between the constraint 17974 and the predicate. The predicate helps decide whether a given 17975 insn matches the pattern. The constraint plays no role in this 17976 decision; instead, it controls various decisions in the case of an 17977 insn which does match. 17978 17979`(match_scratch:M N CONSTRAINT)' 17980 This expression is also a placeholder for operand number N and 17981 indicates that operand must be a `scratch' or `reg' expression. 17982 17983 When matching patterns, this is equivalent to 17984 17985 (match_operand:M N "scratch_operand" PRED) 17986 17987 but, when generating RTL, it produces a (`scratch':M) expression. 17988 17989 If the last few expressions in a `parallel' are `clobber' 17990 expressions whose operands are either a hard register or 17991 `match_scratch', the combiner can add or delete them when 17992 necessary. *Note Side Effects::. 17993 17994`(match_dup N)' 17995 This expression is also a placeholder for operand number N. It is 17996 used when the operand needs to appear more than once in the insn. 17997 17998 In construction, `match_dup' acts just like `match_operand': the 17999 operand is substituted into the insn being constructed. But in 18000 matching, `match_dup' behaves differently. It assumes that operand 18001 number N has already been determined by a `match_operand' 18002 appearing earlier in the recognition template, and it matches only 18003 an identical-looking expression. 18004 18005 Note that `match_dup' should not be used to tell the compiler that 18006 a particular register is being used for two operands (example: 18007 `add' that adds one register to another; the second register is 18008 both an input operand and the output operand). Use a matching 18009 constraint (*note Simple Constraints::) for those. `match_dup' is 18010 for the cases where one operand is used in two places in the 18011 template, such as an instruction that computes both a quotient and 18012 a remainder, where the opcode takes two input operands but the RTL 18013 template has to refer to each of those twice; once for the 18014 quotient pattern and once for the remainder pattern. 18015 18016`(match_operator:M N PREDICATE [OPERANDS...])' 18017 This pattern is a kind of placeholder for a variable RTL expression 18018 code. 18019 18020 When constructing an insn, it stands for an RTL expression whose 18021 expression code is taken from that of operand N, and whose 18022 operands are constructed from the patterns OPERANDS. 18023 18024 When matching an expression, it matches an expression if the 18025 function PREDICATE returns nonzero on that expression _and_ the 18026 patterns OPERANDS match the operands of the expression. 18027 18028 Suppose that the function `commutative_operator' is defined as 18029 follows, to match any expression whose operator is one of the 18030 commutative arithmetic operators of RTL and whose mode is MODE: 18031 18032 int 18033 commutative_integer_operator (x, mode) 18034 rtx x; 18035 enum machine_mode mode; 18036 { 18037 enum rtx_code code = GET_CODE (x); 18038 if (GET_MODE (x) != mode) 18039 return 0; 18040 return (GET_RTX_CLASS (code) == RTX_COMM_ARITH 18041 || code == EQ || code == NE); 18042 } 18043 18044 Then the following pattern will match any RTL expression consisting 18045 of a commutative operator applied to two general operands: 18046 18047 (match_operator:SI 3 "commutative_operator" 18048 [(match_operand:SI 1 "general_operand" "g") 18049 (match_operand:SI 2 "general_operand" "g")]) 18050 18051 Here the vector `[OPERANDS...]' contains two patterns because the 18052 expressions to be matched all contain two operands. 18053 18054 When this pattern does match, the two operands of the commutative 18055 operator are recorded as operands 1 and 2 of the insn. (This is 18056 done by the two instances of `match_operand'.) Operand 3 of the 18057 insn will be the entire commutative expression: use `GET_CODE 18058 (operands[3])' to see which commutative operator was used. 18059 18060 The machine mode M of `match_operator' works like that of 18061 `match_operand': it is passed as the second argument to the 18062 predicate function, and that function is solely responsible for 18063 deciding whether the expression to be matched "has" that mode. 18064 18065 When constructing an insn, argument 3 of the gen-function will 18066 specify the operation (i.e. the expression code) for the 18067 expression to be made. It should be an RTL expression, whose 18068 expression code is copied into a new expression whose operands are 18069 arguments 1 and 2 of the gen-function. The subexpressions of 18070 argument 3 are not used; only its expression code matters. 18071 18072 When `match_operator' is used in a pattern for matching an insn, 18073 it usually best if the operand number of the `match_operator' is 18074 higher than that of the actual operands of the insn. This improves 18075 register allocation because the register allocator often looks at 18076 operands 1 and 2 of insns to see if it can do register tying. 18077 18078 There is no way to specify constraints in `match_operator'. The 18079 operand of the insn which corresponds to the `match_operator' 18080 never has any constraints because it is never reloaded as a whole. 18081 However, if parts of its OPERANDS are matched by `match_operand' 18082 patterns, those parts may have constraints of their own. 18083 18084`(match_op_dup:M N[OPERANDS...])' 18085 Like `match_dup', except that it applies to operators instead of 18086 operands. When constructing an insn, operand number N will be 18087 substituted at this point. But in matching, `match_op_dup' behaves 18088 differently. It assumes that operand number N has already been 18089 determined by a `match_operator' appearing earlier in the 18090 recognition template, and it matches only an identical-looking 18091 expression. 18092 18093`(match_parallel N PREDICATE [SUBPAT...])' 18094 This pattern is a placeholder for an insn that consists of a 18095 `parallel' expression with a variable number of elements. This 18096 expression should only appear at the top level of an insn pattern. 18097 18098 When constructing an insn, operand number N will be substituted at 18099 this point. When matching an insn, it matches if the body of the 18100 insn is a `parallel' expression with at least as many elements as 18101 the vector of SUBPAT expressions in the `match_parallel', if each 18102 SUBPAT matches the corresponding element of the `parallel', _and_ 18103 the function PREDICATE returns nonzero on the `parallel' that is 18104 the body of the insn. It is the responsibility of the predicate 18105 to validate elements of the `parallel' beyond those listed in the 18106 `match_parallel'. 18107 18108 A typical use of `match_parallel' is to match load and store 18109 multiple expressions, which can contain a variable number of 18110 elements in a `parallel'. For example, 18111 18112 (define_insn "" 18113 [(match_parallel 0 "load_multiple_operation" 18114 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 18115 (match_operand:SI 2 "memory_operand" "m")) 18116 (use (reg:SI 179)) 18117 (clobber (reg:SI 179))])] 18118 "" 18119 "loadm 0,0,%1,%2") 18120 18121 This example comes from `a29k.md'. The function 18122 `load_multiple_operation' is defined in `a29k.c' and checks that 18123 subsequent elements in the `parallel' are the same as the `set' in 18124 the pattern, except that they are referencing subsequent registers 18125 and memory locations. 18126 18127 An insn that matches this pattern might look like: 18128 18129 (parallel 18130 [(set (reg:SI 20) (mem:SI (reg:SI 100))) 18131 (use (reg:SI 179)) 18132 (clobber (reg:SI 179)) 18133 (set (reg:SI 21) 18134 (mem:SI (plus:SI (reg:SI 100) 18135 (const_int 4)))) 18136 (set (reg:SI 22) 18137 (mem:SI (plus:SI (reg:SI 100) 18138 (const_int 8))))]) 18139 18140`(match_par_dup N [SUBPAT...])' 18141 Like `match_op_dup', but for `match_parallel' instead of 18142 `match_operator'. 18143 18144 18145 18146File: gccint.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc 18147 1814816.5 Output Templates and Operand Substitution 18149============================================== 18150 18151The "output template" is a string which specifies how to output the 18152assembler code for an instruction pattern. Most of the template is a 18153fixed string which is output literally. The character `%' is used to 18154specify where to substitute an operand; it can also be used to identify 18155places where different variants of the assembler require different 18156syntax. 18157 18158 In the simplest case, a `%' followed by a digit N says to output 18159operand N at that point in the string. 18160 18161 `%' followed by a letter and a digit says to output an operand in an 18162alternate fashion. Four letters have standard, built-in meanings 18163described below. The machine description macro `PRINT_OPERAND' can 18164define additional letters with nonstandard meanings. 18165 18166 `%cDIGIT' can be used to substitute an operand that is a constant 18167value without the syntax that normally indicates an immediate operand. 18168 18169 `%nDIGIT' is like `%cDIGIT' except that the value of the constant is 18170negated before printing. 18171 18172 `%aDIGIT' can be used to substitute an operand as if it were a memory 18173reference, with the actual operand treated as the address. This may be 18174useful when outputting a "load address" instruction, because often the 18175assembler syntax for such an instruction requires you to write the 18176operand as if it were a memory reference. 18177 18178 `%lDIGIT' is used to substitute a `label_ref' into a jump instruction. 18179 18180 `%=' outputs a number which is unique to each instruction in the 18181entire compilation. This is useful for making local labels to be 18182referred to more than once in a single template that generates multiple 18183assembler instructions. 18184 18185 `%' followed by a punctuation character specifies a substitution that 18186does not use an operand. Only one case is standard: `%%' outputs a `%' 18187into the assembler code. Other nonstandard cases can be defined in the 18188`PRINT_OPERAND' macro. You must also define which punctuation 18189characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro. 18190 18191 The template may generate multiple assembler instructions. Write the 18192text for the instructions, with `\;' between them. 18193 18194 When the RTL contains two operands which are required by constraint to 18195match each other, the output template must refer only to the 18196lower-numbered operand. Matching operands are not always identical, 18197and the rest of the compiler arranges to put the proper RTL expression 18198for printing into the lower-numbered operand. 18199 18200 One use of nonstandard letters or punctuation following `%' is to 18201distinguish between different assembler languages for the same machine; 18202for example, Motorola syntax versus MIT syntax for the 68000. Motorola 18203syntax requires periods in most opcode names, while MIT syntax does 18204not. For example, the opcode `movel' in MIT syntax is `move.l' in 18205Motorola syntax. The same file of patterns is used for both kinds of 18206output syntax, but the character sequence `%.' is used in each place 18207where Motorola syntax wants a period. The `PRINT_OPERAND' macro for 18208Motorola syntax defines the sequence to output a period; the macro for 18209MIT syntax defines it to do nothing. 18210 18211 As a special case, a template consisting of the single character `#' 18212instructs the compiler to first split the insn, and then output the 18213resulting instructions separately. This helps eliminate redundancy in 18214the output templates. If you have a `define_insn' that needs to emit 18215multiple assembler instructions, and there is a matching `define_split' 18216already defined, then you can simply use `#' as the output template 18217instead of writing an output template that emits the multiple assembler 18218instructions. 18219 18220 If the macro `ASSEMBLER_DIALECT' is defined, you can use construct of 18221the form `{option0|option1|option2}' in the templates. These describe 18222multiple variants of assembler language syntax. *Note Instruction 18223Output::. 18224 18225 18226File: gccint.info, Node: Output Statement, Next: Predicates, Prev: Output Template, Up: Machine Desc 18227 1822816.6 C Statements for Assembler Output 18229====================================== 18230 18231Often a single fixed template string cannot produce correct and 18232efficient assembler code for all the cases that are recognized by a 18233single instruction pattern. For example, the opcodes may depend on the 18234kinds of operands; or some unfortunate combinations of operands may 18235require extra machine instructions. 18236 18237 If the output control string starts with a `@', then it is actually a 18238series of templates, each on a separate line. (Blank lines and leading 18239spaces and tabs are ignored.) The templates correspond to the 18240pattern's constraint alternatives (*note Multi-Alternative::). For 18241example, if a target machine has a two-address add instruction `addr' 18242to add into a register and another `addm' to add a register to memory, 18243you might write this pattern: 18244 18245 (define_insn "addsi3" 18246 [(set (match_operand:SI 0 "general_operand" "=r,m") 18247 (plus:SI (match_operand:SI 1 "general_operand" "0,0") 18248 (match_operand:SI 2 "general_operand" "g,r")))] 18249 "" 18250 "@ 18251 addr %2,%0 18252 addm %2,%0") 18253 18254 If the output control string starts with a `*', then it is not an 18255output template but rather a piece of C program that should compute a 18256template. It should execute a `return' statement to return the 18257template-string you want. Most such templates use C string literals, 18258which require doublequote characters to delimit them. To include these 18259doublequote characters in the string, prefix each one with `\'. 18260 18261 If the output control string is written as a brace block instead of a 18262double-quoted string, it is automatically assumed to be C code. In that 18263case, it is not necessary to put in a leading asterisk, or to escape the 18264doublequotes surrounding C string literals. 18265 18266 The operands may be found in the array `operands', whose C data type 18267is `rtx []'. 18268 18269 It is very common to select different ways of generating assembler code 18270based on whether an immediate operand is within a certain range. Be 18271careful when doing this, because the result of `INTVAL' is an integer 18272on the host machine. If the host machine has more bits in an `int' 18273than the target machine has in the mode in which the constant will be 18274used, then some of the bits you get from `INTVAL' will be superfluous. 18275For proper results, you must carefully disregard the values of those 18276bits. 18277 18278 It is possible to output an assembler instruction and then go on to 18279output or compute more of them, using the subroutine `output_asm_insn'. 18280This receives two arguments: a template-string and a vector of 18281operands. The vector may be `operands', or it may be another array of 18282`rtx' that you declare locally and initialize yourself. 18283 18284 When an insn pattern has multiple alternatives in its constraints, 18285often the appearance of the assembler code is determined mostly by 18286which alternative was matched. When this is so, the C code can test 18287the variable `which_alternative', which is the ordinal number of the 18288alternative that was actually satisfied (0 for the first, 1 for the 18289second alternative, etc.). 18290 18291 For example, suppose there are two opcodes for storing zero, `clrreg' 18292for registers and `clrmem' for memory locations. Here is how a pattern 18293could use `which_alternative' to choose between them: 18294 18295 (define_insn "" 18296 [(set (match_operand:SI 0 "general_operand" "=r,m") 18297 (const_int 0))] 18298 "" 18299 { 18300 return (which_alternative == 0 18301 ? "clrreg %0" : "clrmem %0"); 18302 }) 18303 18304 The example above, where the assembler code to generate was _solely_ 18305determined by the alternative, could also have been specified as 18306follows, having the output control string start with a `@': 18307 18308 (define_insn "" 18309 [(set (match_operand:SI 0 "general_operand" "=r,m") 18310 (const_int 0))] 18311 "" 18312 "@ 18313 clrreg %0 18314 clrmem %0") 18315 18316 18317File: gccint.info, Node: Predicates, Next: Constraints, Prev: Output Statement, Up: Machine Desc 18318 1831916.7 Predicates 18320=============== 18321 18322A predicate determines whether a `match_operand' or `match_operator' 18323expression matches, and therefore whether the surrounding instruction 18324pattern will be used for that combination of operands. GCC has a 18325number of machine-independent predicates, and you can define 18326machine-specific predicates as needed. By convention, predicates used 18327with `match_operand' have names that end in `_operand', and those used 18328with `match_operator' have names that end in `_operator'. 18329 18330 All predicates are Boolean functions (in the mathematical sense) of 18331two arguments: the RTL expression that is being considered at that 18332position in the instruction pattern, and the machine mode that the 18333`match_operand' or `match_operator' specifies. In this section, the 18334first argument is called OP and the second argument MODE. Predicates 18335can be called from C as ordinary two-argument functions; this can be 18336useful in output templates or other machine-specific code. 18337 18338 Operand predicates can allow operands that are not actually acceptable 18339to the hardware, as long as the constraints give reload the ability to 18340fix them up (*note Constraints::). However, GCC will usually generate 18341better code if the predicates specify the requirements of the machine 18342instructions as closely as possible. Reload cannot fix up operands 18343that must be constants ("immediate operands"); you must use a predicate 18344that allows only constants, or else enforce the requirement in the 18345extra condition. 18346 18347 Most predicates handle their MODE argument in a uniform manner. If 18348MODE is `VOIDmode' (unspecified), then OP can have any mode. If MODE 18349is anything else, then OP must have the same mode, unless OP is a 18350`CONST_INT' or integer `CONST_DOUBLE'. These RTL expressions always 18351have `VOIDmode', so it would be counterproductive to check that their 18352mode matches. Instead, predicates that accept `CONST_INT' and/or 18353integer `CONST_DOUBLE' check that the value stored in the constant will 18354fit in the requested mode. 18355 18356 Predicates with this behavior are called "normal". `genrecog' can 18357optimize the instruction recognizer based on knowledge of how normal 18358predicates treat modes. It can also diagnose certain kinds of common 18359errors in the use of normal predicates; for instance, it is almost 18360always an error to use a normal predicate without specifying a mode. 18361 18362 Predicates that do something different with their MODE argument are 18363called "special". The generic predicates `address_operand' and 18364`pmode_register_operand' are special predicates. `genrecog' does not 18365do any optimizations or diagnosis when special predicates are used. 18366 18367* Menu: 18368 18369* Machine-Independent Predicates:: Predicates available to all back ends. 18370* Defining Predicates:: How to write machine-specific predicate 18371 functions. 18372 18373 18374File: gccint.info, Node: Machine-Independent Predicates, Next: Defining Predicates, Up: Predicates 18375 1837616.7.1 Machine-Independent Predicates 18377------------------------------------- 18378 18379These are the generic predicates available to all back ends. They are 18380defined in `recog.c'. The first category of predicates allow only 18381constant, or "immediate", operands. 18382 18383 -- Function: immediate_operand 18384 This predicate allows any sort of constant that fits in MODE. It 18385 is an appropriate choice for instructions that take operands that 18386 must be constant. 18387 18388 -- Function: const_int_operand 18389 This predicate allows any `CONST_INT' expression that fits in 18390 MODE. It is an appropriate choice for an immediate operand that 18391 does not allow a symbol or label. 18392 18393 -- Function: const_double_operand 18394 This predicate accepts any `CONST_DOUBLE' expression that has 18395 exactly MODE. If MODE is `VOIDmode', it will also accept 18396 `CONST_INT'. It is intended for immediate floating point 18397 constants. 18398 18399The second category of predicates allow only some kind of machine 18400register. 18401 18402 -- Function: register_operand 18403 This predicate allows any `REG' or `SUBREG' expression that is 18404 valid for MODE. It is often suitable for arithmetic instruction 18405 operands on a RISC machine. 18406 18407 -- Function: pmode_register_operand 18408 This is a slight variant on `register_operand' which works around 18409 a limitation in the machine-description reader. 18410 18411 (match_operand N "pmode_register_operand" CONSTRAINT) 18412 18413 means exactly what 18414 18415 (match_operand:P N "register_operand" CONSTRAINT) 18416 18417 would mean, if the machine-description reader accepted `:P' mode 18418 suffixes. Unfortunately, it cannot, because `Pmode' is an alias 18419 for some other mode, and might vary with machine-specific options. 18420 *Note Misc::. 18421 18422 -- Function: scratch_operand 18423 This predicate allows hard registers and `SCRATCH' expressions, 18424 but not pseudo-registers. It is used internally by 18425 `match_scratch'; it should not be used directly. 18426 18427The third category of predicates allow only some kind of memory 18428reference. 18429 18430 -- Function: memory_operand 18431 This predicate allows any valid reference to a quantity of mode 18432 MODE in memory, as determined by the weak form of 18433 `GO_IF_LEGITIMATE_ADDRESS' (*note Addressing Modes::). 18434 18435 -- Function: address_operand 18436 This predicate is a little unusual; it allows any operand that is a 18437 valid expression for the _address_ of a quantity of mode MODE, 18438 again determined by the weak form of `GO_IF_LEGITIMATE_ADDRESS'. 18439 To first order, if `(mem:MODE (EXP))' is acceptable to 18440 `memory_operand', then EXP is acceptable to `address_operand'. 18441 Note that EXP does not necessarily have the mode MODE. 18442 18443 -- Function: indirect_operand 18444 This is a stricter form of `memory_operand' which allows only 18445 memory references with a `general_operand' as the address 18446 expression. New uses of this predicate are discouraged, because 18447 `general_operand' is very permissive, so it's hard to tell what an 18448 `indirect_operand' does or does not allow. If a target has 18449 different requirements for memory operands for different 18450 instructions, it is better to define target-specific predicates 18451 which enforce the hardware's requirements explicitly. 18452 18453 -- Function: push_operand 18454 This predicate allows a memory reference suitable for pushing a 18455 value onto the stack. This will be a `MEM' which refers to 18456 `stack_pointer_rtx', with a side-effect in its address expression 18457 (*note Incdec::); which one is determined by the `STACK_PUSH_CODE' 18458 macro (*note Frame Layout::). 18459 18460 -- Function: pop_operand 18461 This predicate allows a memory reference suitable for popping a 18462 value off the stack. Again, this will be a `MEM' referring to 18463 `stack_pointer_rtx', with a side-effect in its address expression. 18464 However, this time `STACK_POP_CODE' is expected. 18465 18466The fourth category of predicates allow some combination of the above 18467operands. 18468 18469 -- Function: nonmemory_operand 18470 This predicate allows any immediate or register operand valid for 18471 MODE. 18472 18473 -- Function: nonimmediate_operand 18474 This predicate allows any register or memory operand valid for 18475 MODE. 18476 18477 -- Function: general_operand 18478 This predicate allows any immediate, register, or memory operand 18479 valid for MODE. 18480 18481Finally, there are two generic operator predicates. 18482 18483 -- Function: comparison_operator 18484 This predicate matches any expression which performs an arithmetic 18485 comparison in MODE; that is, `COMPARISON_P' is true for the 18486 expression code. 18487 18488 -- Function: ordered_comparison_operator 18489 This predicate matches any expression which performs an arithmetic 18490 comparison in MODE and whose expression code is valid for integer 18491 modes; that is, the expression code will be one of `eq', `ne', 18492 `lt', `ltu', `le', `leu', `gt', `gtu', `ge', `geu'. 18493 18494 18495File: gccint.info, Node: Defining Predicates, Prev: Machine-Independent Predicates, Up: Predicates 18496 1849716.7.2 Defining Machine-Specific Predicates 18498------------------------------------------- 18499 18500Many machines have requirements for their operands that cannot be 18501expressed precisely using the generic predicates. You can define 18502additional predicates using `define_predicate' and 18503`define_special_predicate' expressions. These expressions have three 18504operands: 18505 18506 * The name of the predicate, as it will be referred to in 18507 `match_operand' or `match_operator' expressions. 18508 18509 * An RTL expression which evaluates to true if the predicate allows 18510 the operand OP, false if it does not. This expression can only use 18511 the following RTL codes: 18512 18513 `MATCH_OPERAND' 18514 When written inside a predicate expression, a `MATCH_OPERAND' 18515 expression evaluates to true if the predicate it names would 18516 allow OP. The operand number and constraint are ignored. 18517 Due to limitations in `genrecog', you can only refer to 18518 generic predicates and predicates that have already been 18519 defined. 18520 18521 `MATCH_CODE' 18522 This expression evaluates to true if OP or a specified 18523 subexpression of OP has one of a given list of RTX codes. 18524 18525 The first operand of this expression is a string constant 18526 containing a comma-separated list of RTX code names (in lower 18527 case). These are the codes for which the `MATCH_CODE' will 18528 be true. 18529 18530 The second operand is a string constant which indicates what 18531 subexpression of OP to examine. If it is absent or the empty 18532 string, OP itself is examined. Otherwise, the string constant 18533 must be a sequence of digits and/or lowercase letters. Each 18534 character indicates a subexpression to extract from the 18535 current expression; for the first character this is OP, for 18536 the second and subsequent characters it is the result of the 18537 previous character. A digit N extracts `XEXP (E, N)'; a 18538 letter L extracts `XVECEXP (E, 0, N)' where N is the 18539 alphabetic ordinal of L (0 for `a', 1 for 'b', and so on). 18540 The `MATCH_CODE' then examines the RTX code of the 18541 subexpression extracted by the complete string. It is not 18542 possible to extract components of an `rtvec' that is not at 18543 position 0 within its RTX object. 18544 18545 `MATCH_TEST' 18546 This expression has one operand, a string constant containing 18547 a C expression. The predicate's arguments, OP and MODE, are 18548 available with those names in the C expression. The 18549 `MATCH_TEST' evaluates to true if the C expression evaluates 18550 to a nonzero value. `MATCH_TEST' expressions must not have 18551 side effects. 18552 18553 `AND' 18554 `IOR' 18555 `NOT' 18556 `IF_THEN_ELSE' 18557 The basic `MATCH_' expressions can be combined using these 18558 logical operators, which have the semantics of the C operators 18559 `&&', `||', `!', and `? :' respectively. As in Common Lisp, 18560 you may give an `AND' or `IOR' expression an arbitrary number 18561 of arguments; this has exactly the same effect as writing a 18562 chain of two-argument `AND' or `IOR' expressions. 18563 18564 * An optional block of C code, which should execute `return true' if 18565 the predicate is found to match and `return false' if it does not. 18566 It must not have any side effects. The predicate arguments, OP 18567 and MODE, are available with those names. 18568 18569 If a code block is present in a predicate definition, then the RTL 18570 expression must evaluate to true _and_ the code block must execute 18571 `return true' for the predicate to allow the operand. The RTL 18572 expression is evaluated first; do not re-check anything in the 18573 code block that was checked in the RTL expression. 18574 18575 The program `genrecog' scans `define_predicate' and 18576`define_special_predicate' expressions to determine which RTX codes are 18577possibly allowed. You should always make this explicit in the RTL 18578predicate expression, using `MATCH_OPERAND' and `MATCH_CODE'. 18579 18580 Here is an example of a simple predicate definition, from the IA64 18581machine description: 18582 18583 ;; True if OP is a `SYMBOL_REF' which refers to the sdata section. 18584 (define_predicate "small_addr_symbolic_operand" 18585 (and (match_code "symbol_ref") 18586 (match_test "SYMBOL_REF_SMALL_ADDR_P (op)"))) 18587 18588And here is another, showing the use of the C block. 18589 18590 ;; True if OP is a register operand that is (or could be) a GR reg. 18591 (define_predicate "gr_register_operand" 18592 (match_operand 0 "register_operand") 18593 { 18594 unsigned int regno; 18595 if (GET_CODE (op) == SUBREG) 18596 op = SUBREG_REG (op); 18597 18598 regno = REGNO (op); 18599 return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno)); 18600 }) 18601 18602 Predicates written with `define_predicate' automatically include a 18603test that MODE is `VOIDmode', or OP has the same mode as MODE, or OP is 18604a `CONST_INT' or `CONST_DOUBLE'. They do _not_ check specifically for 18605integer `CONST_DOUBLE', nor do they test that the value of either kind 18606of constant fits in the requested mode. This is because 18607target-specific predicates that take constants usually have to do more 18608stringent value checks anyway. If you need the exact same treatment of 18609`CONST_INT' or `CONST_DOUBLE' that the generic predicates provide, use 18610a `MATCH_OPERAND' subexpression to call `const_int_operand', 18611`const_double_operand', or `immediate_operand'. 18612 18613 Predicates written with `define_special_predicate' do not get any 18614automatic mode checks, and are treated as having special mode handling 18615by `genrecog'. 18616 18617 The program `genpreds' is responsible for generating code to test 18618predicates. It also writes a header file containing function 18619declarations for all machine-specific predicates. It is not necessary 18620to declare these predicates in `CPU-protos.h'. 18621 18622 18623File: gccint.info, Node: Constraints, Next: Standard Names, Prev: Predicates, Up: Machine Desc 18624 1862516.8 Operand Constraints 18626======================== 18627 18628Each `match_operand' in an instruction pattern can specify constraints 18629for the operands allowed. The constraints allow you to fine-tune 18630matching within the set of operands allowed by the predicate. 18631 18632 Constraints can say whether an operand may be in a register, and which 18633kinds of register; whether the operand can be a memory reference, and 18634which kinds of address; whether the operand may be an immediate 18635constant, and which possible values it may have. Constraints can also 18636require two operands to match. 18637 18638* Menu: 18639 18640* Simple Constraints:: Basic use of constraints. 18641* Multi-Alternative:: When an insn has two alternative constraint-patterns. 18642* Class Preferences:: Constraints guide which hard register to put things in. 18643* Modifiers:: More precise control over effects of constraints. 18644* Disable Insn Alternatives:: Disable insn alternatives using the `enabled' attribute. 18645* Machine Constraints:: Existing constraints for some particular machines. 18646* Define Constraints:: How to define machine-specific constraints. 18647* C Constraint Interface:: How to test constraints from C code. 18648 18649 18650File: gccint.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints 18651 1865216.8.1 Simple Constraints 18653------------------------- 18654 18655The simplest kind of constraint is a string full of letters, each of 18656which describes one kind of operand that is permitted. Here are the 18657letters that are allowed: 18658 18659whitespace 18660 Whitespace characters are ignored and can be inserted at any 18661 position except the first. This enables each alternative for 18662 different operands to be visually aligned in the machine 18663 description even if they have different number of constraints and 18664 modifiers. 18665 18666`m' 18667 A memory operand is allowed, with any kind of address that the 18668 machine supports in general. Note that the letter used for the 18669 general memory constraint can be re-defined by a back end using 18670 the `TARGET_MEM_CONSTRAINT' macro. 18671 18672`o' 18673 A memory operand is allowed, but only if the address is 18674 "offsettable". This means that adding a small integer (actually, 18675 the width in bytes of the operand, as determined by its machine 18676 mode) may be added to the address and the result is also a valid 18677 memory address. 18678 18679 For example, an address which is constant is offsettable; so is an 18680 address that is the sum of a register and a constant (as long as a 18681 slightly larger constant is also within the range of 18682 address-offsets supported by the machine); but an autoincrement or 18683 autodecrement address is not offsettable. More complicated 18684 indirect/indexed addresses may or may not be offsettable depending 18685 on the other addressing modes that the machine supports. 18686 18687 Note that in an output operand which can be matched by another 18688 operand, the constraint letter `o' is valid only when accompanied 18689 by both `<' (if the target machine has predecrement addressing) 18690 and `>' (if the target machine has preincrement addressing). 18691 18692`V' 18693 A memory operand that is not offsettable. In other words, 18694 anything that would fit the `m' constraint but not the `o' 18695 constraint. 18696 18697`<' 18698 A memory operand with autodecrement addressing (either 18699 predecrement or postdecrement) is allowed. 18700 18701`>' 18702 A memory operand with autoincrement addressing (either 18703 preincrement or postincrement) is allowed. 18704 18705`r' 18706 A register operand is allowed provided that it is in a general 18707 register. 18708 18709`i' 18710 An immediate integer operand (one with constant value) is allowed. 18711 This includes symbolic constants whose values will be known only at 18712 assembly time or later. 18713 18714`n' 18715 An immediate integer operand with a known numeric value is allowed. 18716 Many systems cannot support assembly-time constants for operands 18717 less than a word wide. Constraints for these operands should use 18718 `n' rather than `i'. 18719 18720`I', `J', `K', ... `P' 18721 Other letters in the range `I' through `P' may be defined in a 18722 machine-dependent fashion to permit immediate integer operands with 18723 explicit integer values in specified ranges. For example, on the 18724 68000, `I' is defined to stand for the range of values 1 to 8. 18725 This is the range permitted as a shift count in the shift 18726 instructions. 18727 18728`E' 18729 An immediate floating operand (expression code `const_double') is 18730 allowed, but only if the target floating point format is the same 18731 as that of the host machine (on which the compiler is running). 18732 18733`F' 18734 An immediate floating operand (expression code `const_double' or 18735 `const_vector') is allowed. 18736 18737`G', `H' 18738 `G' and `H' may be defined in a machine-dependent fashion to 18739 permit immediate floating operands in particular ranges of values. 18740 18741`s' 18742 An immediate integer operand whose value is not an explicit 18743 integer is allowed. 18744 18745 This might appear strange; if an insn allows a constant operand 18746 with a value not known at compile time, it certainly must allow 18747 any known value. So why use `s' instead of `i'? Sometimes it 18748 allows better code to be generated. 18749 18750 For example, on the 68000 in a fullword instruction it is possible 18751 to use an immediate operand; but if the immediate value is between 18752 -128 and 127, better code results from loading the value into a 18753 register and using the register. This is because the load into 18754 the register can be done with a `moveq' instruction. We arrange 18755 for this to happen by defining the letter `K' to mean "any integer 18756 outside the range -128 to 127", and then specifying `Ks' in the 18757 operand constraints. 18758 18759`g' 18760 Any register, memory or immediate integer operand is allowed, 18761 except for registers that are not general registers. 18762 18763`X' 18764 Any operand whatsoever is allowed, even if it does not satisfy 18765 `general_operand'. This is normally used in the constraint of a 18766 `match_scratch' when certain alternatives will not actually 18767 require a scratch register. 18768 18769`0', `1', `2', ... `9' 18770 An operand that matches the specified operand number is allowed. 18771 If a digit is used together with letters within the same 18772 alternative, the digit should come last. 18773 18774 This number is allowed to be more than a single digit. If multiple 18775 digits are encountered consecutively, they are interpreted as a 18776 single decimal integer. There is scant chance for ambiguity, 18777 since to-date it has never been desirable that `10' be interpreted 18778 as matching either operand 1 _or_ operand 0. Should this be 18779 desired, one can use multiple alternatives instead. 18780 18781 This is called a "matching constraint" and what it really means is 18782 that the assembler has only a single operand that fills two roles 18783 considered separate in the RTL insn. For example, an add insn has 18784 two input operands and one output operand in the RTL, but on most 18785 CISC machines an add instruction really has only two operands, one 18786 of them an input-output operand: 18787 18788 addl #35,r12 18789 18790 Matching constraints are used in these circumstances. More 18791 precisely, the two operands that match must include one input-only 18792 operand and one output-only operand. Moreover, the digit must be a 18793 smaller number than the number of the operand that uses it in the 18794 constraint. 18795 18796 For operands to match in a particular case usually means that they 18797 are identical-looking RTL expressions. But in a few special cases 18798 specific kinds of dissimilarity are allowed. For example, `*x' as 18799 an input operand will match `*x++' as an output operand. For 18800 proper results in such cases, the output template should always 18801 use the output-operand's number when printing the operand. 18802 18803`p' 18804 An operand that is a valid memory address is allowed. This is for 18805 "load address" and "push address" instructions. 18806 18807 `p' in the constraint must be accompanied by `address_operand' as 18808 the predicate in the `match_operand'. This predicate interprets 18809 the mode specified in the `match_operand' as the mode of the memory 18810 reference for which the address would be valid. 18811 18812OTHER-LETTERS 18813 Other letters can be defined in machine-dependent fashion to stand 18814 for particular classes of registers or other arbitrary operand 18815 types. `d', `a' and `f' are defined on the 68000/68020 to stand 18816 for data, address and floating point registers. 18817 18818 In order to have valid assembler code, each operand must satisfy its 18819constraint. But a failure to do so does not prevent the pattern from 18820applying to an insn. Instead, it directs the compiler to modify the 18821code so that the constraint will be satisfied. Usually this is done by 18822copying an operand into a register. 18823 18824 Contrast, therefore, the two instruction patterns that follow: 18825 18826 (define_insn "" 18827 [(set (match_operand:SI 0 "general_operand" "=r") 18828 (plus:SI (match_dup 0) 18829 (match_operand:SI 1 "general_operand" "r")))] 18830 "" 18831 "...") 18832 18833which has two operands, one of which must appear in two places, and 18834 18835 (define_insn "" 18836 [(set (match_operand:SI 0 "general_operand" "=r") 18837 (plus:SI (match_operand:SI 1 "general_operand" "0") 18838 (match_operand:SI 2 "general_operand" "r")))] 18839 "" 18840 "...") 18841 18842which has three operands, two of which are required by a constraint to 18843be identical. If we are considering an insn of the form 18844 18845 (insn N PREV NEXT 18846 (set (reg:SI 3) 18847 (plus:SI (reg:SI 6) (reg:SI 109))) 18848 ...) 18849 18850the first pattern would not apply at all, because this insn does not 18851contain two identical subexpressions in the right place. The pattern 18852would say, "That does not look like an add instruction; try other 18853patterns". The second pattern would say, "Yes, that's an add 18854instruction, but there is something wrong with it". It would direct 18855the reload pass of the compiler to generate additional insns to make 18856the constraint true. The results might look like this: 18857 18858 (insn N2 PREV N 18859 (set (reg:SI 3) (reg:SI 6)) 18860 ...) 18861 18862 (insn N N2 NEXT 18863 (set (reg:SI 3) 18864 (plus:SI (reg:SI 3) (reg:SI 109))) 18865 ...) 18866 18867 It is up to you to make sure that each operand, in each pattern, has 18868constraints that can handle any RTL expression that could be present for 18869that operand. (When multiple alternatives are in use, each pattern 18870must, for each possible combination of operand expressions, have at 18871least one alternative which can handle that combination of operands.) 18872The constraints don't need to _allow_ any possible operand--when this is 18873the case, they do not constrain--but they must at least point the way to 18874reloading any possible operand so that it will fit. 18875 18876 * If the constraint accepts whatever operands the predicate permits, 18877 there is no problem: reloading is never necessary for this operand. 18878 18879 For example, an operand whose constraints permit everything except 18880 registers is safe provided its predicate rejects registers. 18881 18882 An operand whose predicate accepts only constant values is safe 18883 provided its constraints include the letter `i'. If any possible 18884 constant value is accepted, then nothing less than `i' will do; if 18885 the predicate is more selective, then the constraints may also be 18886 more selective. 18887 18888 * Any operand expression can be reloaded by copying it into a 18889 register. So if an operand's constraints allow some kind of 18890 register, it is certain to be safe. It need not permit all 18891 classes of registers; the compiler knows how to copy a register 18892 into another register of the proper class in order to make an 18893 instruction valid. 18894 18895 * A nonoffsettable memory reference can be reloaded by copying the 18896 address into a register. So if the constraint uses the letter 18897 `o', all memory references are taken care of. 18898 18899 * A constant operand can be reloaded by allocating space in memory to 18900 hold it as preinitialized data. Then the memory reference can be 18901 used in place of the constant. So if the constraint uses the 18902 letters `o' or `m', constant operands are not a problem. 18903 18904 * If the constraint permits a constant and a pseudo register used in 18905 an insn was not allocated to a hard register and is equivalent to 18906 a constant, the register will be replaced with the constant. If 18907 the predicate does not permit a constant and the insn is 18908 re-recognized for some reason, the compiler will crash. Thus the 18909 predicate must always recognize any objects allowed by the 18910 constraint. 18911 18912 If the operand's predicate can recognize registers, but the constraint 18913does not permit them, it can make the compiler crash. When this 18914operand happens to be a register, the reload pass will be stymied, 18915because it does not know how to copy a register temporarily into memory. 18916 18917 If the predicate accepts a unary operator, the constraint applies to 18918the operand. For example, the MIPS processor at ISA level 3 supports an 18919instruction which adds two registers in `SImode' to produce a `DImode' 18920result, but only if the registers are correctly sign extended. This 18921predicate for the input operands accepts a `sign_extend' of an `SImode' 18922register. Write the constraint to indicate the type of register that 18923is required for the operand of the `sign_extend'. 18924 18925 18926File: gccint.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints 18927 1892816.8.2 Multiple Alternative Constraints 18929--------------------------------------- 18930 18931Sometimes a single instruction has multiple alternative sets of possible 18932operands. For example, on the 68000, a logical-or instruction can 18933combine register or an immediate value into memory, or it can combine 18934any kind of operand into a register; but it cannot combine one memory 18935location into another. 18936 18937 These constraints are represented as multiple alternatives. An 18938alternative can be described by a series of letters for each operand. 18939The overall constraint for an operand is made from the letters for this 18940operand from the first alternative, a comma, the letters for this 18941operand from the second alternative, a comma, and so on until the last 18942alternative. Here is how it is done for fullword logical-or on the 1894368000: 18944 18945 (define_insn "iorsi3" 18946 [(set (match_operand:SI 0 "general_operand" "=m,d") 18947 (ior:SI (match_operand:SI 1 "general_operand" "%0,0") 18948 (match_operand:SI 2 "general_operand" "dKs,dmKs")))] 18949 ...) 18950 18951 The first alternative has `m' (memory) for operand 0, `0' for operand 189521 (meaning it must match operand 0), and `dKs' for operand 2. The 18953second alternative has `d' (data register) for operand 0, `0' for 18954operand 1, and `dmKs' for operand 2. The `=' and `%' in the 18955constraints apply to all the alternatives; their meaning is explained 18956in the next section (*note Class Preferences::). 18957 18958 If all the operands fit any one alternative, the instruction is valid. 18959Otherwise, for each alternative, the compiler counts how many 18960instructions must be added to copy the operands so that that 18961alternative applies. The alternative requiring the least copying is 18962chosen. If two alternatives need the same amount of copying, the one 18963that comes first is chosen. These choices can be altered with the `?' 18964and `!' characters: 18965 18966`?' 18967 Disparage slightly the alternative that the `?' appears in, as a 18968 choice when no alternative applies exactly. The compiler regards 18969 this alternative as one unit more costly for each `?' that appears 18970 in it. 18971 18972`!' 18973 Disparage severely the alternative that the `!' appears in. This 18974 alternative can still be used if it fits without reloading, but if 18975 reloading is needed, some other alternative will be used. 18976 18977 When an insn pattern has multiple alternatives in its constraints, 18978often the appearance of the assembler code is determined mostly by which 18979alternative was matched. When this is so, the C code for writing the 18980assembler code can use the variable `which_alternative', which is the 18981ordinal number of the alternative that was actually satisfied (0 for 18982the first, 1 for the second alternative, etc.). *Note Output 18983Statement::. 18984 18985 18986File: gccint.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints 18987 1898816.8.3 Register Class Preferences 18989--------------------------------- 18990 18991The operand constraints have another function: they enable the compiler 18992to decide which kind of hardware register a pseudo register is best 18993allocated to. The compiler examines the constraints that apply to the 18994insns that use the pseudo register, looking for the machine-dependent 18995letters such as `d' and `a' that specify classes of registers. The 18996pseudo register is put in whichever class gets the most "votes". The 18997constraint letters `g' and `r' also vote: they vote in favor of a 18998general register. The machine description says which registers are 18999considered general. 19000 19001 Of course, on some machines all registers are equivalent, and no 19002register classes are defined. Then none of this complexity is relevant. 19003 19004 19005File: gccint.info, Node: Modifiers, Next: Disable Insn Alternatives, Prev: Class Preferences, Up: Constraints 19006 1900716.8.4 Constraint Modifier Characters 19008------------------------------------- 19009 19010Here are constraint modifier characters. 19011 19012`=' 19013 Means that this operand is write-only for this instruction: the 19014 previous value is discarded and replaced by output data. 19015 19016`+' 19017 Means that this operand is both read and written by the 19018 instruction. 19019 19020 When the compiler fixes up the operands to satisfy the constraints, 19021 it needs to know which operands are inputs to the instruction and 19022 which are outputs from it. `=' identifies an output; `+' 19023 identifies an operand that is both input and output; all other 19024 operands are assumed to be input only. 19025 19026 If you specify `=' or `+' in a constraint, you put it in the first 19027 character of the constraint string. 19028 19029`&' 19030 Means (in a particular alternative) that this operand is an 19031 "earlyclobber" operand, which is modified before the instruction is 19032 finished using the input operands. Therefore, this operand may 19033 not lie in a register that is used as an input operand or as part 19034 of any memory address. 19035 19036 `&' applies only to the alternative in which it is written. In 19037 constraints with multiple alternatives, sometimes one alternative 19038 requires `&' while others do not. See, for example, the `movdf' 19039 insn of the 68000. 19040 19041 An input operand can be tied to an earlyclobber operand if its only 19042 use as an input occurs before the early result is written. Adding 19043 alternatives of this form often allows GCC to produce better code 19044 when only some of the inputs can be affected by the earlyclobber. 19045 See, for example, the `mulsi3' insn of the ARM. 19046 19047 `&' does not obviate the need to write `='. 19048 19049`%' 19050 Declares the instruction to be commutative for this operand and the 19051 following operand. This means that the compiler may interchange 19052 the two operands if that is the cheapest way to make all operands 19053 fit the constraints. This is often used in patterns for addition 19054 instructions that really have only two operands: the result must 19055 go in one of the arguments. Here for example, is how the 68000 19056 halfword-add instruction is defined: 19057 19058 (define_insn "addhi3" 19059 [(set (match_operand:HI 0 "general_operand" "=m,r") 19060 (plus:HI (match_operand:HI 1 "general_operand" "%0,0") 19061 (match_operand:HI 2 "general_operand" "di,g")))] 19062 ...) 19063 GCC can only handle one commutative pair in an asm; if you use 19064 more, the compiler may fail. Note that you need not use the 19065 modifier if the two alternatives are strictly identical; this 19066 would only waste time in the reload pass. The modifier is not 19067 operational after register allocation, so the result of 19068 `define_peephole2' and `define_split's performed after reload 19069 cannot rely on `%' to make the intended insn match. 19070 19071`#' 19072 Says that all following characters, up to the next comma, are to be 19073 ignored as a constraint. They are significant only for choosing 19074 register preferences. 19075 19076`*' 19077 Says that the following character should be ignored when choosing 19078 register preferences. `*' has no effect on the meaning of the 19079 constraint as a constraint, and no effect on reloading. 19080 19081 Here is an example: the 68000 has an instruction to sign-extend a 19082 halfword in a data register, and can also sign-extend a value by 19083 copying it into an address register. While either kind of 19084 register is acceptable, the constraints on an address-register 19085 destination are less strict, so it is best if register allocation 19086 makes an address register its goal. Therefore, `*' is used so 19087 that the `d' constraint letter (for data register) is ignored when 19088 computing register preferences. 19089 19090 (define_insn "extendhisi2" 19091 [(set (match_operand:SI 0 "general_operand" "=*d,a") 19092 (sign_extend:SI 19093 (match_operand:HI 1 "general_operand" "0,g")))] 19094 ...) 19095 19096 19097File: gccint.info, Node: Machine Constraints, Next: Define Constraints, Prev: Disable Insn Alternatives, Up: Constraints 19098 1909916.8.5 Constraints for Particular Machines 19100------------------------------------------ 19101 19102Whenever possible, you should use the general-purpose constraint letters 19103in `asm' arguments, since they will convey meaning more readily to 19104people reading your code. Failing that, use the constraint letters 19105that usually have very similar meanings across architectures. The most 19106commonly used constraints are `m' and `r' (for memory and 19107general-purpose registers respectively; *note Simple Constraints::), and 19108`I', usually the letter indicating the most common immediate-constant 19109format. 19110 19111 Each architecture defines additional constraints. These constraints 19112are used by the compiler itself for instruction generation, as well as 19113for `asm' statements; therefore, some of the constraints are not 19114particularly useful for `asm'. Here is a summary of some of the 19115machine-dependent constraints available on some particular machines; it 19116includes both constraints that are useful for `asm' and constraints 19117that aren't. The compiler source file mentioned in the table heading 19118for each architecture is the definitive reference for the meanings of 19119that architecture's constraints. 19120 19121_ARM family--`config/arm/arm.h'_ 19122 19123 `f' 19124 Floating-point register 19125 19126 `w' 19127 VFP floating-point register 19128 19129 `F' 19130 One of the floating-point constants 0.0, 0.5, 1.0, 2.0, 3.0, 19131 4.0, 5.0 or 10.0 19132 19133 `G' 19134 Floating-point constant that would satisfy the constraint `F' 19135 if it were negated 19136 19137 `I' 19138 Integer that is valid as an immediate operand in a data 19139 processing instruction. That is, an integer in the range 0 19140 to 255 rotated by a multiple of 2 19141 19142 `J' 19143 Integer in the range -4095 to 4095 19144 19145 `K' 19146 Integer that satisfies constraint `I' when inverted (ones 19147 complement) 19148 19149 `L' 19150 Integer that satisfies constraint `I' when negated (twos 19151 complement) 19152 19153 `M' 19154 Integer in the range 0 to 32 19155 19156 `Q' 19157 A memory reference where the exact address is in a single 19158 register (``m'' is preferable for `asm' statements) 19159 19160 `R' 19161 An item in the constant pool 19162 19163 `S' 19164 A symbol in the text segment of the current file 19165 19166 `Uv' 19167 A memory reference suitable for VFP load/store insns 19168 (reg+constant offset) 19169 19170 `Uy' 19171 A memory reference suitable for iWMMXt load/store 19172 instructions. 19173 19174 `Uq' 19175 A memory reference suitable for the ARMv4 ldrsb instruction. 19176 19177_AVR family--`config/avr/constraints.md'_ 19178 19179 `l' 19180 Registers from r0 to r15 19181 19182 `a' 19183 Registers from r16 to r23 19184 19185 `d' 19186 Registers from r16 to r31 19187 19188 `w' 19189 Registers from r24 to r31. These registers can be used in 19190 `adiw' command 19191 19192 `e' 19193 Pointer register (r26-r31) 19194 19195 `b' 19196 Base pointer register (r28-r31) 19197 19198 `q' 19199 Stack pointer register (SPH:SPL) 19200 19201 `t' 19202 Temporary register r0 19203 19204 `x' 19205 Register pair X (r27:r26) 19206 19207 `y' 19208 Register pair Y (r29:r28) 19209 19210 `z' 19211 Register pair Z (r31:r30) 19212 19213 `I' 19214 Constant greater than -1, less than 64 19215 19216 `J' 19217 Constant greater than -64, less than 1 19218 19219 `K' 19220 Constant integer 2 19221 19222 `L' 19223 Constant integer 0 19224 19225 `M' 19226 Constant that fits in 8 bits 19227 19228 `N' 19229 Constant integer -1 19230 19231 `O' 19232 Constant integer 8, 16, or 24 19233 19234 `P' 19235 Constant integer 1 19236 19237 `G' 19238 A floating point constant 0.0 19239 19240 `R' 19241 Integer constant in the range -6 ... 5. 19242 19243 `Q' 19244 A memory address based on Y or Z pointer with displacement. 19245 19246_CRX Architecture--`config/crx/crx.h'_ 19247 19248 `b' 19249 Registers from r0 to r14 (registers without stack pointer) 19250 19251 `l' 19252 Register r16 (64-bit accumulator lo register) 19253 19254 `h' 19255 Register r17 (64-bit accumulator hi register) 19256 19257 `k' 19258 Register pair r16-r17. (64-bit accumulator lo-hi pair) 19259 19260 `I' 19261 Constant that fits in 3 bits 19262 19263 `J' 19264 Constant that fits in 4 bits 19265 19266 `K' 19267 Constant that fits in 5 bits 19268 19269 `L' 19270 Constant that is one of -1, 4, -4, 7, 8, 12, 16, 20, 32, 48 19271 19272 `G' 19273 Floating point constant that is legal for store immediate 19274 19275_Hewlett-Packard PA-RISC--`config/pa/pa.h'_ 19276 19277 `a' 19278 General register 1 19279 19280 `f' 19281 Floating point register 19282 19283 `q' 19284 Shift amount register 19285 19286 `x' 19287 Floating point register (deprecated) 19288 19289 `y' 19290 Upper floating point register (32-bit), floating point 19291 register (64-bit) 19292 19293 `Z' 19294 Any register 19295 19296 `I' 19297 Signed 11-bit integer constant 19298 19299 `J' 19300 Signed 14-bit integer constant 19301 19302 `K' 19303 Integer constant that can be deposited with a `zdepi' 19304 instruction 19305 19306 `L' 19307 Signed 5-bit integer constant 19308 19309 `M' 19310 Integer constant 0 19311 19312 `N' 19313 Integer constant that can be loaded with a `ldil' instruction 19314 19315 `O' 19316 Integer constant whose value plus one is a power of 2 19317 19318 `P' 19319 Integer constant that can be used for `and' operations in 19320 `depi' and `extru' instructions 19321 19322 `S' 19323 Integer constant 31 19324 19325 `U' 19326 Integer constant 63 19327 19328 `G' 19329 Floating-point constant 0.0 19330 19331 `A' 19332 A `lo_sum' data-linkage-table memory operand 19333 19334 `Q' 19335 A memory operand that can be used as the destination operand 19336 of an integer store instruction 19337 19338 `R' 19339 A scaled or unscaled indexed memory operand 19340 19341 `T' 19342 A memory operand for floating-point loads and stores 19343 19344 `W' 19345 A register indirect memory operand 19346 19347_picoChip family--`picochip.h'_ 19348 19349 `k' 19350 Stack register. 19351 19352 `f' 19353 Pointer register. A register which can be used to access 19354 memory without supplying an offset. Any other register can 19355 be used to access memory, but will need a constant offset. 19356 In the case of the offset being zero, it is more efficient to 19357 use a pointer register, since this reduces code size. 19358 19359 `t' 19360 A twin register. A register which may be paired with an 19361 adjacent register to create a 32-bit register. 19362 19363 `a' 19364 Any absolute memory address (e.g., symbolic constant, symbolic 19365 constant + offset). 19366 19367 `I' 19368 4-bit signed integer. 19369 19370 `J' 19371 4-bit unsigned integer. 19372 19373 `K' 19374 8-bit signed integer. 19375 19376 `M' 19377 Any constant whose absolute value is no greater than 4-bits. 19378 19379 `N' 19380 10-bit signed integer 19381 19382 `O' 19383 16-bit signed integer. 19384 19385 19386_PowerPC and IBM RS6000--`config/rs6000/rs6000.h'_ 19387 19388 `b' 19389 Address base register 19390 19391 `d' 19392 Floating point register (containing 64-bit value) 19393 19394 `f' 19395 Floating point register (containing 32-bit value) 19396 19397 `v' 19398 Altivec vector register 19399 19400 `wd' 19401 VSX vector register to hold vector double data 19402 19403 `wf' 19404 VSX vector register to hold vector float data 19405 19406 `ws' 19407 VSX vector register to hold scalar float data 19408 19409 `wa' 19410 Any VSX register 19411 19412 `h' 19413 `MQ', `CTR', or `LINK' register 19414 19415 `q' 19416 `MQ' register 19417 19418 `c' 19419 `CTR' register 19420 19421 `l' 19422 `LINK' register 19423 19424 `x' 19425 `CR' register (condition register) number 0 19426 19427 `y' 19428 `CR' register (condition register) 19429 19430 `z' 19431 `FPMEM' stack memory for FPR-GPR transfers 19432 19433 `I' 19434 Signed 16-bit constant 19435 19436 `J' 19437 Unsigned 16-bit constant shifted left 16 bits (use `L' 19438 instead for `SImode' constants) 19439 19440 `K' 19441 Unsigned 16-bit constant 19442 19443 `L' 19444 Signed 16-bit constant shifted left 16 bits 19445 19446 `M' 19447 Constant larger than 31 19448 19449 `N' 19450 Exact power of 2 19451 19452 `O' 19453 Zero 19454 19455 `P' 19456 Constant whose negation is a signed 16-bit constant 19457 19458 `G' 19459 Floating point constant that can be loaded into a register 19460 with one instruction per word 19461 19462 `H' 19463 Integer/Floating point constant that can be loaded into a 19464 register using three instructions 19465 19466 `m' 19467 Memory operand. Note that on PowerPC targets, `m' can include 19468 addresses that update the base register. It is therefore 19469 only safe to use `m' in an `asm' statement if that `asm' 19470 statement accesses the operand exactly once. The `asm' 19471 statement must also use `%U<OPNO>' as a placeholder for the 19472 "update" flag in the corresponding load or store instruction. 19473 For example: 19474 19475 asm ("st%U0 %1,%0" : "=m" (mem) : "r" (val)); 19476 19477 is correct but: 19478 19479 asm ("st %1,%0" : "=m" (mem) : "r" (val)); 19480 19481 is not. Use `es' rather than `m' if you don't want the base 19482 register to be updated. 19483 19484 `es' 19485 A "stable" memory operand; that is, one which does not 19486 include any automodification of the base register. Unlike 19487 `m', this constraint can be used in `asm' statements that 19488 might access the operand several times, or that might not 19489 access it at all. 19490 19491 `Q' 19492 Memory operand that is an offset from a register (it is 19493 usually better to use `m' or `es' in `asm' statements) 19494 19495 `Z' 19496 Memory operand that is an indexed or indirect from a register 19497 (it is usually better to use `m' or `es' in `asm' statements) 19498 19499 `R' 19500 AIX TOC entry 19501 19502 `a' 19503 Address operand that is an indexed or indirect from a 19504 register (`p' is preferable for `asm' statements) 19505 19506 `S' 19507 Constant suitable as a 64-bit mask operand 19508 19509 `T' 19510 Constant suitable as a 32-bit mask operand 19511 19512 `U' 19513 System V Release 4 small data area reference 19514 19515 `t' 19516 AND masks that can be performed by two rldic{l, r} 19517 instructions 19518 19519 `W' 19520 Vector constant that does not require memory 19521 19522 `j' 19523 Vector constant that is all zeros. 19524 19525 19526_Intel 386--`config/i386/constraints.md'_ 19527 19528 `R' 19529 Legacy register--the eight integer registers available on all 19530 i386 processors (`a', `b', `c', `d', `si', `di', `bp', `sp'). 19531 19532 `q' 19533 Any register accessible as `Rl'. In 32-bit mode, `a', `b', 19534 `c', and `d'; in 64-bit mode, any integer register. 19535 19536 `Q' 19537 Any register accessible as `Rh': `a', `b', `c', and `d'. 19538 19539 `l' 19540 Any register that can be used as the index in a base+index 19541 memory access: that is, any general register except the stack 19542 pointer. 19543 19544 `a' 19545 The `a' register. 19546 19547 `b' 19548 The `b' register. 19549 19550 `c' 19551 The `c' register. 19552 19553 `d' 19554 The `d' register. 19555 19556 `S' 19557 The `si' register. 19558 19559 `D' 19560 The `di' register. 19561 19562 `A' 19563 The `a' and `d' registers, as a pair (for instructions that 19564 return half the result in one and half in the other). 19565 19566 `f' 19567 Any 80387 floating-point (stack) register. 19568 19569 `t' 19570 Top of 80387 floating-point stack (`%st(0)'). 19571 19572 `u' 19573 Second from top of 80387 floating-point stack (`%st(1)'). 19574 19575 `y' 19576 Any MMX register. 19577 19578 `x' 19579 Any SSE register. 19580 19581 `Yz' 19582 First SSE register (`%xmm0'). 19583 19584 `Y2' 19585 Any SSE register, when SSE2 is enabled. 19586 19587 `Yi' 19588 Any SSE register, when SSE2 and inter-unit moves are enabled. 19589 19590 `Ym' 19591 Any MMX register, when inter-unit moves are enabled. 19592 19593 `I' 19594 Integer constant in the range 0 ... 31, for 32-bit shifts. 19595 19596 `J' 19597 Integer constant in the range 0 ... 63, for 64-bit shifts. 19598 19599 `K' 19600 Signed 8-bit integer constant. 19601 19602 `L' 19603 `0xFF' or `0xFFFF', for andsi as a zero-extending move. 19604 19605 `M' 19606 0, 1, 2, or 3 (shifts for the `lea' instruction). 19607 19608 `N' 19609 Unsigned 8-bit integer constant (for `in' and `out' 19610 instructions). 19611 19612 `O' 19613 Integer constant in the range 0 ... 127, for 128-bit shifts. 19614 19615 `G' 19616 Standard 80387 floating point constant. 19617 19618 `C' 19619 Standard SSE floating point constant. 19620 19621 `e' 19622 32-bit signed integer constant, or a symbolic reference known 19623 to fit that range (for immediate operands in sign-extending 19624 x86-64 instructions). 19625 19626 `Z' 19627 32-bit unsigned integer constant, or a symbolic reference 19628 known to fit that range (for immediate operands in 19629 zero-extending x86-64 instructions). 19630 19631 19632_Intel IA-64--`config/ia64/ia64.h'_ 19633 19634 `a' 19635 General register `r0' to `r3' for `addl' instruction 19636 19637 `b' 19638 Branch register 19639 19640 `c' 19641 Predicate register (`c' as in "conditional") 19642 19643 `d' 19644 Application register residing in M-unit 19645 19646 `e' 19647 Application register residing in I-unit 19648 19649 `f' 19650 Floating-point register 19651 19652 `m' 19653 Memory operand. Remember that `m' allows postincrement and 19654 postdecrement which require printing with `%Pn' on IA-64. 19655 Use `S' to disallow postincrement and postdecrement. 19656 19657 `G' 19658 Floating-point constant 0.0 or 1.0 19659 19660 `I' 19661 14-bit signed integer constant 19662 19663 `J' 19664 22-bit signed integer constant 19665 19666 `K' 19667 8-bit signed integer constant for logical instructions 19668 19669 `L' 19670 8-bit adjusted signed integer constant for compare pseudo-ops 19671 19672 `M' 19673 6-bit unsigned integer constant for shift counts 19674 19675 `N' 19676 9-bit signed integer constant for load and store 19677 postincrements 19678 19679 `O' 19680 The constant zero 19681 19682 `P' 19683 0 or -1 for `dep' instruction 19684 19685 `Q' 19686 Non-volatile memory for floating-point loads and stores 19687 19688 `R' 19689 Integer constant in the range 1 to 4 for `shladd' instruction 19690 19691 `S' 19692 Memory operand except postincrement and postdecrement 19693 19694_FRV--`config/frv/frv.h'_ 19695 19696 `a' 19697 Register in the class `ACC_REGS' (`acc0' to `acc7'). 19698 19699 `b' 19700 Register in the class `EVEN_ACC_REGS' (`acc0' to `acc7'). 19701 19702 `c' 19703 Register in the class `CC_REGS' (`fcc0' to `fcc3' and `icc0' 19704 to `icc3'). 19705 19706 `d' 19707 Register in the class `GPR_REGS' (`gr0' to `gr63'). 19708 19709 `e' 19710 Register in the class `EVEN_REGS' (`gr0' to `gr63'). Odd 19711 registers are excluded not in the class but through the use 19712 of a machine mode larger than 4 bytes. 19713 19714 `f' 19715 Register in the class `FPR_REGS' (`fr0' to `fr63'). 19716 19717 `h' 19718 Register in the class `FEVEN_REGS' (`fr0' to `fr63'). Odd 19719 registers are excluded not in the class but through the use 19720 of a machine mode larger than 4 bytes. 19721 19722 `l' 19723 Register in the class `LR_REG' (the `lr' register). 19724 19725 `q' 19726 Register in the class `QUAD_REGS' (`gr2' to `gr63'). 19727 Register numbers not divisible by 4 are excluded not in the 19728 class but through the use of a machine mode larger than 8 19729 bytes. 19730 19731 `t' 19732 Register in the class `ICC_REGS' (`icc0' to `icc3'). 19733 19734 `u' 19735 Register in the class `FCC_REGS' (`fcc0' to `fcc3'). 19736 19737 `v' 19738 Register in the class `ICR_REGS' (`cc4' to `cc7'). 19739 19740 `w' 19741 Register in the class `FCR_REGS' (`cc0' to `cc3'). 19742 19743 `x' 19744 Register in the class `QUAD_FPR_REGS' (`fr0' to `fr63'). 19745 Register numbers not divisible by 4 are excluded not in the 19746 class but through the use of a machine mode larger than 8 19747 bytes. 19748 19749 `z' 19750 Register in the class `SPR_REGS' (`lcr' and `lr'). 19751 19752 `A' 19753 Register in the class `QUAD_ACC_REGS' (`acc0' to `acc7'). 19754 19755 `B' 19756 Register in the class `ACCG_REGS' (`accg0' to `accg7'). 19757 19758 `C' 19759 Register in the class `CR_REGS' (`cc0' to `cc7'). 19760 19761 `G' 19762 Floating point constant zero 19763 19764 `I' 19765 6-bit signed integer constant 19766 19767 `J' 19768 10-bit signed integer constant 19769 19770 `L' 19771 16-bit signed integer constant 19772 19773 `M' 19774 16-bit unsigned integer constant 19775 19776 `N' 19777 12-bit signed integer constant that is negative--i.e. in the 19778 range of -2048 to -1 19779 19780 `O' 19781 Constant zero 19782 19783 `P' 19784 12-bit signed integer constant that is greater than 19785 zero--i.e. in the range of 1 to 2047. 19786 19787 19788_Blackfin family--`config/bfin/constraints.md'_ 19789 19790 `a' 19791 P register 19792 19793 `d' 19794 D register 19795 19796 `z' 19797 A call clobbered P register. 19798 19799 `qN' 19800 A single register. If N is in the range 0 to 7, the 19801 corresponding D register. If it is `A', then the register P0. 19802 19803 `D' 19804 Even-numbered D register 19805 19806 `W' 19807 Odd-numbered D register 19808 19809 `e' 19810 Accumulator register. 19811 19812 `A' 19813 Even-numbered accumulator register. 19814 19815 `B' 19816 Odd-numbered accumulator register. 19817 19818 `b' 19819 I register 19820 19821 `v' 19822 B register 19823 19824 `f' 19825 M register 19826 19827 `c' 19828 Registers used for circular buffering, i.e. I, B, or L 19829 registers. 19830 19831 `C' 19832 The CC register. 19833 19834 `t' 19835 LT0 or LT1. 19836 19837 `k' 19838 LC0 or LC1. 19839 19840 `u' 19841 LB0 or LB1. 19842 19843 `x' 19844 Any D, P, B, M, I or L register. 19845 19846 `y' 19847 Additional registers typically used only in prologues and 19848 epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and 19849 USP. 19850 19851 `w' 19852 Any register except accumulators or CC. 19853 19854 `Ksh' 19855 Signed 16 bit integer (in the range -32768 to 32767) 19856 19857 `Kuh' 19858 Unsigned 16 bit integer (in the range 0 to 65535) 19859 19860 `Ks7' 19861 Signed 7 bit integer (in the range -64 to 63) 19862 19863 `Ku7' 19864 Unsigned 7 bit integer (in the range 0 to 127) 19865 19866 `Ku5' 19867 Unsigned 5 bit integer (in the range 0 to 31) 19868 19869 `Ks4' 19870 Signed 4 bit integer (in the range -8 to 7) 19871 19872 `Ks3' 19873 Signed 3 bit integer (in the range -3 to 4) 19874 19875 `Ku3' 19876 Unsigned 3 bit integer (in the range 0 to 7) 19877 19878 `PN' 19879 Constant N, where N is a single-digit constant in the range 0 19880 to 4. 19881 19882 `PA' 19883 An integer equal to one of the MACFLAG_XXX constants that is 19884 suitable for use with either accumulator. 19885 19886 `PB' 19887 An integer equal to one of the MACFLAG_XXX constants that is 19888 suitable for use only with accumulator A1. 19889 19890 `M1' 19891 Constant 255. 19892 19893 `M2' 19894 Constant 65535. 19895 19896 `J' 19897 An integer constant with exactly a single bit set. 19898 19899 `L' 19900 An integer constant with all bits set except exactly one. 19901 19902 `H' 19903 19904 `Q' 19905 Any SYMBOL_REF. 19906 19907_M32C--`config/m32c/m32c.c'_ 19908 19909 `Rsp' 19910 `Rfb' 19911 `Rsb' 19912 `$sp', `$fb', `$sb'. 19913 19914 `Rcr' 19915 Any control register, when they're 16 bits wide (nothing if 19916 control registers are 24 bits wide) 19917 19918 `Rcl' 19919 Any control register, when they're 24 bits wide. 19920 19921 `R0w' 19922 `R1w' 19923 `R2w' 19924 `R3w' 19925 $r0, $r1, $r2, $r3. 19926 19927 `R02' 19928 $r0 or $r2, or $r2r0 for 32 bit values. 19929 19930 `R13' 19931 $r1 or $r3, or $r3r1 for 32 bit values. 19932 19933 `Rdi' 19934 A register that can hold a 64 bit value. 19935 19936 `Rhl' 19937 $r0 or $r1 (registers with addressable high/low bytes) 19938 19939 `R23' 19940 $r2 or $r3 19941 19942 `Raa' 19943 Address registers 19944 19945 `Raw' 19946 Address registers when they're 16 bits wide. 19947 19948 `Ral' 19949 Address registers when they're 24 bits wide. 19950 19951 `Rqi' 19952 Registers that can hold QI values. 19953 19954 `Rad' 19955 Registers that can be used with displacements ($a0, $a1, $sb). 19956 19957 `Rsi' 19958 Registers that can hold 32 bit values. 19959 19960 `Rhi' 19961 Registers that can hold 16 bit values. 19962 19963 `Rhc' 19964 Registers chat can hold 16 bit values, including all control 19965 registers. 19966 19967 `Rra' 19968 $r0 through R1, plus $a0 and $a1. 19969 19970 `Rfl' 19971 The flags register. 19972 19973 `Rmm' 19974 The memory-based pseudo-registers $mem0 through $mem15. 19975 19976 `Rpi' 19977 Registers that can hold pointers (16 bit registers for r8c, 19978 m16c; 24 bit registers for m32cm, m32c). 19979 19980 `Rpa' 19981 Matches multiple registers in a PARALLEL to form a larger 19982 register. Used to match function return values. 19983 19984 `Is3' 19985 -8 ... 7 19986 19987 `IS1' 19988 -128 ... 127 19989 19990 `IS2' 19991 -32768 ... 32767 19992 19993 `IU2' 19994 0 ... 65535 19995 19996 `In4' 19997 -8 ... -1 or 1 ... 8 19998 19999 `In5' 20000 -16 ... -1 or 1 ... 16 20001 20002 `In6' 20003 -32 ... -1 or 1 ... 32 20004 20005 `IM2' 20006 -65536 ... -1 20007 20008 `Ilb' 20009 An 8 bit value with exactly one bit set. 20010 20011 `Ilw' 20012 A 16 bit value with exactly one bit set. 20013 20014 `Sd' 20015 The common src/dest memory addressing modes. 20016 20017 `Sa' 20018 Memory addressed using $a0 or $a1. 20019 20020 `Si' 20021 Memory addressed with immediate addresses. 20022 20023 `Ss' 20024 Memory addressed using the stack pointer ($sp). 20025 20026 `Sf' 20027 Memory addressed using the frame base register ($fb). 20028 20029 `Ss' 20030 Memory addressed using the small base register ($sb). 20031 20032 `S1' 20033 $r1h 20034 20035_MeP--`config/mep/constraints.md'_ 20036 20037 `a' 20038 The $sp register. 20039 20040 `b' 20041 The $tp register. 20042 20043 `c' 20044 Any control register. 20045 20046 `d' 20047 Either the $hi or the $lo register. 20048 20049 `em' 20050 Coprocessor registers that can be directly loaded ($c0-$c15). 20051 20052 `ex' 20053 Coprocessor registers that can be moved to each other. 20054 20055 `er' 20056 Coprocessor registers that can be moved to core registers. 20057 20058 `h' 20059 The $hi register. 20060 20061 `j' 20062 The $rpc register. 20063 20064 `l' 20065 The $lo register. 20066 20067 `t' 20068 Registers which can be used in $tp-relative addressing. 20069 20070 `v' 20071 The $gp register. 20072 20073 `x' 20074 The coprocessor registers. 20075 20076 `y' 20077 The coprocessor control registers. 20078 20079 `z' 20080 The $0 register. 20081 20082 `A' 20083 User-defined register set A. 20084 20085 `B' 20086 User-defined register set B. 20087 20088 `C' 20089 User-defined register set C. 20090 20091 `D' 20092 User-defined register set D. 20093 20094 `I' 20095 Offsets for $gp-rel addressing. 20096 20097 `J' 20098 Constants that can be used directly with boolean insns. 20099 20100 `K' 20101 Constants that can be moved directly to registers. 20102 20103 `L' 20104 Small constants that can be added to registers. 20105 20106 `M' 20107 Long shift counts. 20108 20109 `N' 20110 Small constants that can be compared to registers. 20111 20112 `O' 20113 Constants that can be loaded into the top half of registers. 20114 20115 `S' 20116 Signed 8-bit immediates. 20117 20118 `T' 20119 Symbols encoded for $tp-rel or $gp-rel addressing. 20120 20121 `U' 20122 Non-constant addresses for loading/saving coprocessor 20123 registers. 20124 20125 `W' 20126 The top half of a symbol's value. 20127 20128 `Y' 20129 A register indirect address without offset. 20130 20131 `Z' 20132 Symbolic references to the control bus. 20133 20134 20135_MIPS--`config/mips/constraints.md'_ 20136 20137 `d' 20138 An address register. This is equivalent to `r' unless 20139 generating MIPS16 code. 20140 20141 `f' 20142 A floating-point register (if available). 20143 20144 `h' 20145 Formerly the `hi' register. This constraint is no longer 20146 supported. 20147 20148 `l' 20149 The `lo' register. Use this register to store values that are 20150 no bigger than a word. 20151 20152 `x' 20153 The concatenated `hi' and `lo' registers. Use this register 20154 to store doubleword values. 20155 20156 `c' 20157 A register suitable for use in an indirect jump. This will 20158 always be `$25' for `-mabicalls'. 20159 20160 `v' 20161 Register `$3'. Do not use this constraint in new code; it is 20162 retained only for compatibility with glibc. 20163 20164 `y' 20165 Equivalent to `r'; retained for backwards compatibility. 20166 20167 `z' 20168 A floating-point condition code register. 20169 20170 `I' 20171 A signed 16-bit constant (for arithmetic instructions). 20172 20173 `J' 20174 Integer zero. 20175 20176 `K' 20177 An unsigned 16-bit constant (for logic instructions). 20178 20179 `L' 20180 A signed 32-bit constant in which the lower 16 bits are zero. 20181 Such constants can be loaded using `lui'. 20182 20183 `M' 20184 A constant that cannot be loaded using `lui', `addiu' or 20185 `ori'. 20186 20187 `N' 20188 A constant in the range -65535 to -1 (inclusive). 20189 20190 `O' 20191 A signed 15-bit constant. 20192 20193 `P' 20194 A constant in the range 1 to 65535 (inclusive). 20195 20196 `G' 20197 Floating-point zero. 20198 20199 `R' 20200 An address that can be used in a non-macro load or store. 20201 20202_Motorola 680x0--`config/m68k/constraints.md'_ 20203 20204 `a' 20205 Address register 20206 20207 `d' 20208 Data register 20209 20210 `f' 20211 68881 floating-point register, if available 20212 20213 `I' 20214 Integer in the range 1 to 8 20215 20216 `J' 20217 16-bit signed number 20218 20219 `K' 20220 Signed number whose magnitude is greater than 0x80 20221 20222 `L' 20223 Integer in the range -8 to -1 20224 20225 `M' 20226 Signed number whose magnitude is greater than 0x100 20227 20228 `N' 20229 Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate 20230 20231 `O' 20232 16 (for rotate using swap) 20233 20234 `P' 20235 Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate 20236 20237 `R' 20238 Numbers that mov3q can handle 20239 20240 `G' 20241 Floating point constant that is not a 68881 constant 20242 20243 `S' 20244 Operands that satisfy 'm' when -mpcrel is in effect 20245 20246 `T' 20247 Operands that satisfy 's' when -mpcrel is not in effect 20248 20249 `Q' 20250 Address register indirect addressing mode 20251 20252 `U' 20253 Register offset addressing 20254 20255 `W' 20256 const_call_operand 20257 20258 `Cs' 20259 symbol_ref or const 20260 20261 `Ci' 20262 const_int 20263 20264 `C0' 20265 const_int 0 20266 20267 `Cj' 20268 Range of signed numbers that don't fit in 16 bits 20269 20270 `Cmvq' 20271 Integers valid for mvq 20272 20273 `Capsw' 20274 Integers valid for a moveq followed by a swap 20275 20276 `Cmvz' 20277 Integers valid for mvz 20278 20279 `Cmvs' 20280 Integers valid for mvs 20281 20282 `Ap' 20283 push_operand 20284 20285 `Ac' 20286 Non-register operands allowed in clr 20287 20288 20289_Motorola 68HC11 & 68HC12 families--`config/m68hc11/m68hc11.h'_ 20290 20291 `a' 20292 Register `a' 20293 20294 `b' 20295 Register `b' 20296 20297 `d' 20298 Register `d' 20299 20300 `q' 20301 An 8-bit register 20302 20303 `t' 20304 Temporary soft register _.tmp 20305 20306 `u' 20307 A soft register _.d1 to _.d31 20308 20309 `w' 20310 Stack pointer register 20311 20312 `x' 20313 Register `x' 20314 20315 `y' 20316 Register `y' 20317 20318 `z' 20319 Pseudo register `z' (replaced by `x' or `y' at the end) 20320 20321 `A' 20322 An address register: x, y or z 20323 20324 `B' 20325 An address register: x or y 20326 20327 `D' 20328 Register pair (x:d) to form a 32-bit value 20329 20330 `L' 20331 Constants in the range -65536 to 65535 20332 20333 `M' 20334 Constants whose 16-bit low part is zero 20335 20336 `N' 20337 Constant integer 1 or -1 20338 20339 `O' 20340 Constant integer 16 20341 20342 `P' 20343 Constants in the range -8 to 2 20344 20345 20346_Moxie--`config/moxie/constraints.md'_ 20347 20348 `A' 20349 An absolute address 20350 20351 `B' 20352 An offset address 20353 20354 `W' 20355 A register indirect memory operand 20356 20357 `I' 20358 A constant in the range of 0 to 255. 20359 20360 `N' 20361 A constant in the range of 0 to -255. 20362 20363 20364_RX--`config/rx/constraints.md'_ 20365 20366 `Q' 20367 An address which does not involve register indirect 20368 addressing or pre/post increment/decrement addressing. 20369 20370 `Symbol' 20371 A symbol reference. 20372 20373 `Int08' 20374 A constant in the range -256 to 255, inclusive. 20375 20376 `Sint08' 20377 A constant in the range -128 to 127, inclusive. 20378 20379 `Sint16' 20380 A constant in the range -32768 to 32767, inclusive. 20381 20382 `Sint24' 20383 A constant in the range -8388608 to 8388607, inclusive. 20384 20385 `Uint04' 20386 A constant in the range 0 to 15, inclusive. 20387 20388 20389_SPARC--`config/sparc/sparc.h'_ 20390 20391 `f' 20392 Floating-point register on the SPARC-V8 architecture and 20393 lower floating-point register on the SPARC-V9 architecture. 20394 20395 `e' 20396 Floating-point register. It is equivalent to `f' on the 20397 SPARC-V8 architecture and contains both lower and upper 20398 floating-point registers on the SPARC-V9 architecture. 20399 20400 `c' 20401 Floating-point condition code register. 20402 20403 `d' 20404 Lower floating-point register. It is only valid on the 20405 SPARC-V9 architecture when the Visual Instruction Set is 20406 available. 20407 20408 `b' 20409 Floating-point register. It is only valid on the SPARC-V9 20410 architecture when the Visual Instruction Set is available. 20411 20412 `h' 20413 64-bit global or out register for the SPARC-V8+ architecture. 20414 20415 `D' 20416 A vector constant 20417 20418 `I' 20419 Signed 13-bit constant 20420 20421 `J' 20422 Zero 20423 20424 `K' 20425 32-bit constant with the low 12 bits clear (a constant that 20426 can be loaded with the `sethi' instruction) 20427 20428 `L' 20429 A constant in the range supported by `movcc' instructions 20430 20431 `M' 20432 A constant in the range supported by `movrcc' instructions 20433 20434 `N' 20435 Same as `K', except that it verifies that bits that are not 20436 in the lower 32-bit range are all zero. Must be used instead 20437 of `K' for modes wider than `SImode' 20438 20439 `O' 20440 The constant 4096 20441 20442 `G' 20443 Floating-point zero 20444 20445 `H' 20446 Signed 13-bit constant, sign-extended to 32 or 64 bits 20447 20448 `Q' 20449 Floating-point constant whose integral representation can be 20450 moved into an integer register using a single sethi 20451 instruction 20452 20453 `R' 20454 Floating-point constant whose integral representation can be 20455 moved into an integer register using a single mov instruction 20456 20457 `S' 20458 Floating-point constant whose integral representation can be 20459 moved into an integer register using a high/lo_sum 20460 instruction sequence 20461 20462 `T' 20463 Memory address aligned to an 8-byte boundary 20464 20465 `U' 20466 Even register 20467 20468 `W' 20469 Memory address for `e' constraint registers 20470 20471 `Y' 20472 Vector zero 20473 20474 20475_SPU--`config/spu/spu.h'_ 20476 20477 `a' 20478 An immediate which can be loaded with the il/ila/ilh/ilhu 20479 instructions. const_int is treated as a 64 bit value. 20480 20481 `c' 20482 An immediate for and/xor/or instructions. const_int is 20483 treated as a 64 bit value. 20484 20485 `d' 20486 An immediate for the `iohl' instruction. const_int is 20487 treated as a 64 bit value. 20488 20489 `f' 20490 An immediate which can be loaded with `fsmbi'. 20491 20492 `A' 20493 An immediate which can be loaded with the il/ila/ilh/ilhu 20494 instructions. const_int is treated as a 32 bit value. 20495 20496 `B' 20497 An immediate for most arithmetic instructions. const_int is 20498 treated as a 32 bit value. 20499 20500 `C' 20501 An immediate for and/xor/or instructions. const_int is 20502 treated as a 32 bit value. 20503 20504 `D' 20505 An immediate for the `iohl' instruction. const_int is 20506 treated as a 32 bit value. 20507 20508 `I' 20509 A constant in the range [-64, 63] for shift/rotate 20510 instructions. 20511 20512 `J' 20513 An unsigned 7-bit constant for conversion/nop/channel 20514 instructions. 20515 20516 `K' 20517 A signed 10-bit constant for most arithmetic instructions. 20518 20519 `M' 20520 A signed 16 bit immediate for `stop'. 20521 20522 `N' 20523 An unsigned 16-bit constant for `iohl' and `fsmbi'. 20524 20525 `O' 20526 An unsigned 7-bit constant whose 3 least significant bits are 20527 0. 20528 20529 `P' 20530 An unsigned 3-bit constant for 16-byte rotates and shifts 20531 20532 `R' 20533 Call operand, reg, for indirect calls 20534 20535 `S' 20536 Call operand, symbol, for relative calls. 20537 20538 `T' 20539 Call operand, const_int, for absolute calls. 20540 20541 `U' 20542 An immediate which can be loaded with the il/ila/ilh/ilhu 20543 instructions. const_int is sign extended to 128 bit. 20544 20545 `W' 20546 An immediate for shift and rotate instructions. const_int is 20547 treated as a 32 bit value. 20548 20549 `Y' 20550 An immediate for and/xor/or instructions. const_int is sign 20551 extended as a 128 bit. 20552 20553 `Z' 20554 An immediate for the `iohl' instruction. const_int is sign 20555 extended to 128 bit. 20556 20557 20558_S/390 and zSeries--`config/s390/s390.h'_ 20559 20560 `a' 20561 Address register (general purpose register except r0) 20562 20563 `c' 20564 Condition code register 20565 20566 `d' 20567 Data register (arbitrary general purpose register) 20568 20569 `f' 20570 Floating-point register 20571 20572 `I' 20573 Unsigned 8-bit constant (0-255) 20574 20575 `J' 20576 Unsigned 12-bit constant (0-4095) 20577 20578 `K' 20579 Signed 16-bit constant (-32768-32767) 20580 20581 `L' 20582 Value appropriate as displacement. 20583 `(0..4095)' 20584 for short displacement 20585 20586 `(-524288..524287)' 20587 for long displacement 20588 20589 `M' 20590 Constant integer with a value of 0x7fffffff. 20591 20592 `N' 20593 Multiple letter constraint followed by 4 parameter letters. 20594 `0..9:' 20595 number of the part counting from most to least 20596 significant 20597 20598 `H,Q:' 20599 mode of the part 20600 20601 `D,S,H:' 20602 mode of the containing operand 20603 20604 `0,F:' 20605 value of the other parts (F--all bits set) 20606 The constraint matches if the specified part of a constant 20607 has a value different from its other parts. 20608 20609 `Q' 20610 Memory reference without index register and with short 20611 displacement. 20612 20613 `R' 20614 Memory reference with index register and short displacement. 20615 20616 `S' 20617 Memory reference without index register but with long 20618 displacement. 20619 20620 `T' 20621 Memory reference with index register and long displacement. 20622 20623 `U' 20624 Pointer with short displacement. 20625 20626 `W' 20627 Pointer with long displacement. 20628 20629 `Y' 20630 Shift count operand. 20631 20632 20633_Score family--`config/score/score.h'_ 20634 20635 `d' 20636 Registers from r0 to r32. 20637 20638 `e' 20639 Registers from r0 to r16. 20640 20641 `t' 20642 r8--r11 or r22--r27 registers. 20643 20644 `h' 20645 hi register. 20646 20647 `l' 20648 lo register. 20649 20650 `x' 20651 hi + lo register. 20652 20653 `q' 20654 cnt register. 20655 20656 `y' 20657 lcb register. 20658 20659 `z' 20660 scb register. 20661 20662 `a' 20663 cnt + lcb + scb register. 20664 20665 `c' 20666 cr0--cr15 register. 20667 20668 `b' 20669 cp1 registers. 20670 20671 `f' 20672 cp2 registers. 20673 20674 `i' 20675 cp3 registers. 20676 20677 `j' 20678 cp1 + cp2 + cp3 registers. 20679 20680 `I' 20681 High 16-bit constant (32-bit constant with 16 LSBs zero). 20682 20683 `J' 20684 Unsigned 5 bit integer (in the range 0 to 31). 20685 20686 `K' 20687 Unsigned 16 bit integer (in the range 0 to 65535). 20688 20689 `L' 20690 Signed 16 bit integer (in the range -32768 to 32767). 20691 20692 `M' 20693 Unsigned 14 bit integer (in the range 0 to 16383). 20694 20695 `N' 20696 Signed 14 bit integer (in the range -8192 to 8191). 20697 20698 `Z' 20699 Any SYMBOL_REF. 20700 20701_Xstormy16--`config/stormy16/stormy16.h'_ 20702 20703 `a' 20704 Register r0. 20705 20706 `b' 20707 Register r1. 20708 20709 `c' 20710 Register r2. 20711 20712 `d' 20713 Register r8. 20714 20715 `e' 20716 Registers r0 through r7. 20717 20718 `t' 20719 Registers r0 and r1. 20720 20721 `y' 20722 The carry register. 20723 20724 `z' 20725 Registers r8 and r9. 20726 20727 `I' 20728 A constant between 0 and 3 inclusive. 20729 20730 `J' 20731 A constant that has exactly one bit set. 20732 20733 `K' 20734 A constant that has exactly one bit clear. 20735 20736 `L' 20737 A constant between 0 and 255 inclusive. 20738 20739 `M' 20740 A constant between -255 and 0 inclusive. 20741 20742 `N' 20743 A constant between -3 and 0 inclusive. 20744 20745 `O' 20746 A constant between 1 and 4 inclusive. 20747 20748 `P' 20749 A constant between -4 and -1 inclusive. 20750 20751 `Q' 20752 A memory reference that is a stack push. 20753 20754 `R' 20755 A memory reference that is a stack pop. 20756 20757 `S' 20758 A memory reference that refers to a constant address of known 20759 value. 20760 20761 `T' 20762 The register indicated by Rx (not implemented yet). 20763 20764 `U' 20765 A constant that is not between 2 and 15 inclusive. 20766 20767 `Z' 20768 The constant 0. 20769 20770 20771_Xtensa--`config/xtensa/constraints.md'_ 20772 20773 `a' 20774 General-purpose 32-bit register 20775 20776 `b' 20777 One-bit boolean register 20778 20779 `A' 20780 MAC16 40-bit accumulator register 20781 20782 `I' 20783 Signed 12-bit integer constant, for use in MOVI instructions 20784 20785 `J' 20786 Signed 8-bit integer constant, for use in ADDI instructions 20787 20788 `K' 20789 Integer constant valid for BccI instructions 20790 20791 `L' 20792 Unsigned constant valid for BccUI instructions 20793 20794 20795 20796 20797File: gccint.info, Node: Disable Insn Alternatives, Next: Machine Constraints, Prev: Modifiers, Up: Constraints 20798 2079916.8.6 Disable insn alternatives using the `enabled' attribute 20800-------------------------------------------------------------- 20801 20802The `enabled' insn attribute may be used to disable certain insn 20803alternatives for machine-specific reasons. This is useful when adding 20804new instructions to an existing pattern which are only available for 20805certain cpu architecture levels as specified with the `-march=' option. 20806 20807 If an insn alternative is disabled, then it will never be used. The 20808compiler treats the constraints for the disabled alternative as 20809unsatisfiable. 20810 20811 In order to make use of the `enabled' attribute a back end has to add 20812in the machine description files: 20813 20814 1. A definition of the `enabled' insn attribute. The attribute is 20815 defined as usual using the `define_attr' command. This definition 20816 should be based on other insn attributes and/or target flags. The 20817 `enabled' attribute is a numeric attribute and should evaluate to 20818 `(const_int 1)' for an enabled alternative and to `(const_int 0)' 20819 otherwise. 20820 20821 2. A definition of another insn attribute used to describe for what 20822 reason an insn alternative might be available or not. E.g. 20823 `cpu_facility' as in the example below. 20824 20825 3. An assignment for the second attribute to each insn definition 20826 combining instructions which are not all available under the same 20827 circumstances. (Note: It obviously only makes sense for 20828 definitions with more than one alternative. Otherwise the insn 20829 pattern should be disabled or enabled using the insn condition.) 20830 20831 E.g. the following two patterns could easily be merged using the 20832`enabled' attribute: 20833 20834 20835 (define_insn "*movdi_old" 20836 [(set (match_operand:DI 0 "register_operand" "=d") 20837 (match_operand:DI 1 "register_operand" " d"))] 20838 "!TARGET_NEW" 20839 "lgr %0,%1") 20840 20841 (define_insn "*movdi_new" 20842 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 20843 (match_operand:DI 1 "register_operand" " d,d,f"))] 20844 "TARGET_NEW" 20845 "@ 20846 lgr %0,%1 20847 ldgr %0,%1 20848 lgdr %0,%1") 20849 20850 to: 20851 20852 20853 (define_insn "*movdi_combined" 20854 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 20855 (match_operand:DI 1 "register_operand" " d,d,f"))] 20856 "" 20857 "@ 20858 lgr %0,%1 20859 ldgr %0,%1 20860 lgdr %0,%1" 20861 [(set_attr "cpu_facility" "*,new,new")]) 20862 20863 with the `enabled' attribute defined like this: 20864 20865 20866 (define_attr "cpu_facility" "standard,new" (const_string "standard")) 20867 20868 (define_attr "enabled" "" 20869 (cond [(eq_attr "cpu_facility" "standard") (const_int 1) 20870 (and (eq_attr "cpu_facility" "new") 20871 (ne (symbol_ref "TARGET_NEW") (const_int 0))) 20872 (const_int 1)] 20873 (const_int 0))) 20874 20875 20876File: gccint.info, Node: Define Constraints, Next: C Constraint Interface, Prev: Machine Constraints, Up: Constraints 20877 2087816.8.7 Defining Machine-Specific Constraints 20879-------------------------------------------- 20880 20881Machine-specific constraints fall into two categories: register and 20882non-register constraints. Within the latter category, constraints 20883which allow subsets of all possible memory or address operands should 20884be specially marked, to give `reload' more information. 20885 20886 Machine-specific constraints can be given names of arbitrary length, 20887but they must be entirely composed of letters, digits, underscores 20888(`_'), and angle brackets (`< >'). Like C identifiers, they must begin 20889with a letter or underscore. 20890 20891 In order to avoid ambiguity in operand constraint strings, no 20892constraint can have a name that begins with any other constraint's 20893name. For example, if `x' is defined as a constraint name, `xy' may 20894not be, and vice versa. As a consequence of this rule, no constraint 20895may begin with one of the generic constraint letters: `E F V X g i m n 20896o p r s'. 20897 20898 Register constraints correspond directly to register classes. *Note 20899Register Classes::. There is thus not much flexibility in their 20900definitions. 20901 20902 -- MD Expression: define_register_constraint name regclass docstring 20903 All three arguments are string constants. NAME is the name of the 20904 constraint, as it will appear in `match_operand' expressions. If 20905 NAME is a multi-letter constraint its length shall be the same for 20906 all constraints starting with the same letter. REGCLASS can be 20907 either the name of the corresponding register class (*note 20908 Register Classes::), or a C expression which evaluates to the 20909 appropriate register class. If it is an expression, it must have 20910 no side effects, and it cannot look at the operand. The usual use 20911 of expressions is to map some register constraints to `NO_REGS' 20912 when the register class is not available on a given 20913 subarchitecture. 20914 20915 DOCSTRING is a sentence documenting the meaning of the constraint. 20916 Docstrings are explained further below. 20917 20918 Non-register constraints are more like predicates: the constraint 20919definition gives a Boolean expression which indicates whether the 20920constraint matches. 20921 20922 -- MD Expression: define_constraint name docstring exp 20923 The NAME and DOCSTRING arguments are the same as for 20924 `define_register_constraint', but note that the docstring comes 20925 immediately after the name for these expressions. EXP is an RTL 20926 expression, obeying the same rules as the RTL expressions in 20927 predicate definitions. *Note Defining Predicates::, for details. 20928 If it evaluates true, the constraint matches; if it evaluates 20929 false, it doesn't. Constraint expressions should indicate which 20930 RTL codes they might match, just like predicate expressions. 20931 20932 `match_test' C expressions have access to the following variables: 20933 20934 OP 20935 The RTL object defining the operand. 20936 20937 MODE 20938 The machine mode of OP. 20939 20940 IVAL 20941 `INTVAL (OP)', if OP is a `const_int'. 20942 20943 HVAL 20944 `CONST_DOUBLE_HIGH (OP)', if OP is an integer `const_double'. 20945 20946 LVAL 20947 `CONST_DOUBLE_LOW (OP)', if OP is an integer `const_double'. 20948 20949 RVAL 20950 `CONST_DOUBLE_REAL_VALUE (OP)', if OP is a floating-point 20951 `const_double'. 20952 20953 The *VAL variables should only be used once another piece of the 20954 expression has verified that OP is the appropriate kind of RTL 20955 object. 20956 20957 Most non-register constraints should be defined with 20958`define_constraint'. The remaining two definition expressions are only 20959appropriate for constraints that should be handled specially by 20960`reload' if they fail to match. 20961 20962 -- MD Expression: define_memory_constraint name docstring exp 20963 Use this expression for constraints that match a subset of all 20964 memory operands: that is, `reload' can make them match by 20965 converting the operand to the form `(mem (reg X))', where X is a 20966 base register (from the register class specified by 20967 `BASE_REG_CLASS', *note Register Classes::). 20968 20969 For example, on the S/390, some instructions do not accept 20970 arbitrary memory references, but only those that do not make use 20971 of an index register. The constraint letter `Q' is defined to 20972 represent a memory address of this type. If `Q' is defined with 20973 `define_memory_constraint', a `Q' constraint can handle any memory 20974 operand, because `reload' knows it can simply copy the memory 20975 address into a base register if required. This is analogous to 20976 the way an `o' constraint can handle any memory operand. 20977 20978 The syntax and semantics are otherwise identical to 20979 `define_constraint'. 20980 20981 -- MD Expression: define_address_constraint name docstring exp 20982 Use this expression for constraints that match a subset of all 20983 address operands: that is, `reload' can make the constraint match 20984 by converting the operand to the form `(reg X)', again with X a 20985 base register. 20986 20987 Constraints defined with `define_address_constraint' can only be 20988 used with the `address_operand' predicate, or machine-specific 20989 predicates that work the same way. They are treated analogously to 20990 the generic `p' constraint. 20991 20992 The syntax and semantics are otherwise identical to 20993 `define_constraint'. 20994 20995 For historical reasons, names beginning with the letters `G H' are 20996reserved for constraints that match only `const_double's, and names 20997beginning with the letters `I J K L M N O P' are reserved for 20998constraints that match only `const_int's. This may change in the 20999future. For the time being, constraints with these names must be 21000written in a stylized form, so that `genpreds' can tell you did it 21001correctly: 21002 21003 (define_constraint "[GHIJKLMNOP]..." 21004 "DOC..." 21005 (and (match_code "const_int") ; `const_double' for G/H 21006 CONDITION...)) ; usually a `match_test' 21007 21008 It is fine to use names beginning with other letters for constraints 21009that match `const_double's or `const_int's. 21010 21011 Each docstring in a constraint definition should be one or more 21012complete sentences, marked up in Texinfo format. _They are currently 21013unused._ In the future they will be copied into the GCC manual, in 21014*note Machine Constraints::, replacing the hand-maintained tables 21015currently found in that section. Also, in the future the compiler may 21016use this to give more helpful diagnostics when poor choice of `asm' 21017constraints causes a reload failure. 21018 21019 If you put the pseudo-Texinfo directive `@internal' at the beginning 21020of a docstring, then (in the future) it will appear only in the 21021internals manual's version of the machine-specific constraint tables. 21022Use this for constraints that should not appear in `asm' statements. 21023 21024 21025File: gccint.info, Node: C Constraint Interface, Prev: Define Constraints, Up: Constraints 21026 2102716.8.8 Testing constraints from C 21028--------------------------------- 21029 21030It is occasionally useful to test a constraint from C code rather than 21031implicitly via the constraint string in a `match_operand'. The 21032generated file `tm_p.h' declares a few interfaces for working with 21033machine-specific constraints. None of these interfaces work with the 21034generic constraints described in *note Simple Constraints::. This may 21035change in the future. 21036 21037 *Warning:* `tm_p.h' may declare other functions that operate on 21038constraints, besides the ones documented here. Do not use those 21039functions from machine-dependent code. They exist to implement the old 21040constraint interface that machine-independent components of the 21041compiler still expect. They will change or disappear in the future. 21042 21043 Some valid constraint names are not valid C identifiers, so there is a 21044mangling scheme for referring to them from C. Constraint names that do 21045not contain angle brackets or underscores are left unchanged. 21046Underscores are doubled, each `<' is replaced with `_l', and each `>' 21047with `_g'. Here are some examples: 21048 21049 *Original* *Mangled* 21050 `x' `x' 21051 `P42x' `P42x' 21052 `P4_x' `P4__x' 21053 `P4>x' `P4_gx' 21054 `P4>>' `P4_g_g' 21055 `P4_g>' `P4__g_g' 21056 21057 Throughout this section, the variable C is either a constraint in the 21058abstract sense, or a constant from `enum constraint_num'; the variable 21059M is a mangled constraint name (usually as part of a larger identifier). 21060 21061 -- Enum: constraint_num 21062 For each machine-specific constraint, there is a corresponding 21063 enumeration constant: `CONSTRAINT_' plus the mangled name of the 21064 constraint. Functions that take an `enum constraint_num' as an 21065 argument expect one of these constants. 21066 21067 Machine-independent constraints do not have associated constants. 21068 This may change in the future. 21069 21070 -- Function: inline bool satisfies_constraint_M (rtx EXP) 21071 For each machine-specific, non-register constraint M, there is one 21072 of these functions; it returns `true' if EXP satisfies the 21073 constraint. These functions are only visible if `rtl.h' was 21074 included before `tm_p.h'. 21075 21076 -- Function: bool constraint_satisfied_p (rtx EXP, enum constraint_num 21077 C) 21078 Like the `satisfies_constraint_M' functions, but the constraint to 21079 test is given as an argument, C. If C specifies a register 21080 constraint, this function will always return `false'. 21081 21082 -- Function: enum reg_class regclass_for_constraint (enum 21083 constraint_num C) 21084 Returns the register class associated with C. If C is not a 21085 register constraint, or those registers are not available for the 21086 currently selected subtarget, returns `NO_REGS'. 21087 21088 Here is an example use of `satisfies_constraint_M'. In peephole 21089optimizations (*note Peephole Definitions::), operand constraint 21090strings are ignored, so if there are relevant constraints, they must be 21091tested in the C condition. In the example, the optimization is applied 21092if operand 2 does _not_ satisfy the `K' constraint. (This is a 21093simplified version of a peephole definition from the i386 machine 21094description.) 21095 21096 (define_peephole2 21097 [(match_scratch:SI 3 "r") 21098 (set (match_operand:SI 0 "register_operand" "") 21099 (mult:SI (match_operand:SI 1 "memory_operand" "") 21100 (match_operand:SI 2 "immediate_operand" "")))] 21101 21102 "!satisfies_constraint_K (operands[2])" 21103 21104 [(set (match_dup 3) (match_dup 1)) 21105 (set (match_dup 0) (mult:SI (match_dup 3) (match_dup 2)))] 21106 21107 "") 21108 21109 21110File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc 21111 2111216.9 Standard Pattern Names For Generation 21113========================================== 21114 21115Here is a table of the instruction names that are meaningful in the RTL 21116generation pass of the compiler. Giving one of these names to an 21117instruction pattern tells the RTL generation pass that it can use the 21118pattern to accomplish a certain task. 21119 21120`movM' 21121 Here M stands for a two-letter machine mode name, in lowercase. 21122 This instruction pattern moves data with that machine mode from 21123 operand 1 to operand 0. For example, `movsi' moves full-word data. 21124 21125 If operand 0 is a `subreg' with mode M of a register whose own 21126 mode is wider than M, the effect of this instruction is to store 21127 the specified value in the part of the register that corresponds 21128 to mode M. Bits outside of M, but which are within the same 21129 target word as the `subreg' are undefined. Bits which are outside 21130 the target word are left unchanged. 21131 21132 This class of patterns is special in several ways. First of all, 21133 each of these names up to and including full word size _must_ be 21134 defined, because there is no other way to copy a datum from one 21135 place to another. If there are patterns accepting operands in 21136 larger modes, `movM' must be defined for integer modes of those 21137 sizes. 21138 21139 Second, these patterns are not used solely in the RTL generation 21140 pass. Even the reload pass can generate move insns to copy values 21141 from stack slots into temporary registers. When it does so, one 21142 of the operands is a hard register and the other is an operand 21143 that can need to be reloaded into a register. 21144 21145 Therefore, when given such a pair of operands, the pattern must 21146 generate RTL which needs no reloading and needs no temporary 21147 registers--no registers other than the operands. For example, if 21148 you support the pattern with a `define_expand', then in such a 21149 case the `define_expand' mustn't call `force_reg' or any other such 21150 function which might generate new pseudo registers. 21151 21152 This requirement exists even for subword modes on a RISC machine 21153 where fetching those modes from memory normally requires several 21154 insns and some temporary registers. 21155 21156 During reload a memory reference with an invalid address may be 21157 passed as an operand. Such an address will be replaced with a 21158 valid address later in the reload pass. In this case, nothing may 21159 be done with the address except to use it as it stands. If it is 21160 copied, it will not be replaced with a valid address. No attempt 21161 should be made to make such an address into a valid address and no 21162 routine (such as `change_address') that will do so may be called. 21163 Note that `general_operand' will fail when applied to such an 21164 address. 21165 21166 The global variable `reload_in_progress' (which must be explicitly 21167 declared if required) can be used to determine whether such special 21168 handling is required. 21169 21170 The variety of operands that have reloads depends on the rest of 21171 the machine description, but typically on a RISC machine these can 21172 only be pseudo registers that did not get hard registers, while on 21173 other machines explicit memory references will get optional 21174 reloads. 21175 21176 If a scratch register is required to move an object to or from 21177 memory, it can be allocated using `gen_reg_rtx' prior to life 21178 analysis. 21179 21180 If there are cases which need scratch registers during or after 21181 reload, you must provide an appropriate secondary_reload target 21182 hook. 21183 21184 The macro `can_create_pseudo_p' can be used to determine if it is 21185 unsafe to create new pseudo registers. If this variable is 21186 nonzero, then it is unsafe to call `gen_reg_rtx' to allocate a new 21187 pseudo. 21188 21189 The constraints on a `movM' must permit moving any hard register 21190 to any other hard register provided that `HARD_REGNO_MODE_OK' 21191 permits mode M in both registers and `REGISTER_MOVE_COST' applied 21192 to their classes returns a value of 2. 21193 21194 It is obligatory to support floating point `movM' instructions 21195 into and out of any registers that can hold fixed point values, 21196 because unions and structures (which have modes `SImode' or 21197 `DImode') can be in those registers and they may have floating 21198 point members. 21199 21200 There may also be a need to support fixed point `movM' 21201 instructions in and out of floating point registers. 21202 Unfortunately, I have forgotten why this was so, and I don't know 21203 whether it is still true. If `HARD_REGNO_MODE_OK' rejects fixed 21204 point values in floating point registers, then the constraints of 21205 the fixed point `movM' instructions must be designed to avoid ever 21206 trying to reload into a floating point register. 21207 21208`reload_inM' 21209`reload_outM' 21210 These named patterns have been obsoleted by the target hook 21211 `secondary_reload'. 21212 21213 Like `movM', but used when a scratch register is required to move 21214 between operand 0 and operand 1. Operand 2 describes the scratch 21215 register. See the discussion of the `SECONDARY_RELOAD_CLASS' 21216 macro in *note Register Classes::. 21217 21218 There are special restrictions on the form of the `match_operand's 21219 used in these patterns. First, only the predicate for the reload 21220 operand is examined, i.e., `reload_in' examines operand 1, but not 21221 the predicates for operand 0 or 2. Second, there may be only one 21222 alternative in the constraints. Third, only a single register 21223 class letter may be used for the constraint; subsequent constraint 21224 letters are ignored. As a special exception, an empty constraint 21225 string matches the `ALL_REGS' register class. This may relieve 21226 ports of the burden of defining an `ALL_REGS' constraint letter 21227 just for these patterns. 21228 21229`movstrictM' 21230 Like `movM' except that if operand 0 is a `subreg' with mode M of 21231 a register whose natural mode is wider, the `movstrictM' 21232 instruction is guaranteed not to alter any of the register except 21233 the part which belongs to mode M. 21234 21235`movmisalignM' 21236 This variant of a move pattern is designed to load or store a value 21237 from a memory address that is not naturally aligned for its mode. 21238 For a store, the memory will be in operand 0; for a load, the 21239 memory will be in operand 1. The other operand is guaranteed not 21240 to be a memory, so that it's easy to tell whether this is a load 21241 or store. 21242 21243 This pattern is used by the autovectorizer, and when expanding a 21244 `MISALIGNED_INDIRECT_REF' expression. 21245 21246`load_multiple' 21247 Load several consecutive memory locations into consecutive 21248 registers. Operand 0 is the first of the consecutive registers, 21249 operand 1 is the first memory location, and operand 2 is a 21250 constant: the number of consecutive registers. 21251 21252 Define this only if the target machine really has such an 21253 instruction; do not define this if the most efficient way of 21254 loading consecutive registers from memory is to do them one at a 21255 time. 21256 21257 On some machines, there are restrictions as to which consecutive 21258 registers can be stored into memory, such as particular starting or 21259 ending register numbers or only a range of valid counts. For those 21260 machines, use a `define_expand' (*note Expander Definitions::) and 21261 make the pattern fail if the restrictions are not met. 21262 21263 Write the generated insn as a `parallel' with elements being a 21264 `set' of one register from the appropriate memory location (you may 21265 also need `use' or `clobber' elements). Use a `match_parallel' 21266 (*note RTL Template::) to recognize the insn. See `rs6000.md' for 21267 examples of the use of this insn pattern. 21268 21269`store_multiple' 21270 Similar to `load_multiple', but store several consecutive registers 21271 into consecutive memory locations. Operand 0 is the first of the 21272 consecutive memory locations, operand 1 is the first register, and 21273 operand 2 is a constant: the number of consecutive registers. 21274 21275`vec_setM' 21276 Set given field in the vector value. Operand 0 is the vector to 21277 modify, operand 1 is new value of field and operand 2 specify the 21278 field index. 21279 21280`vec_extractM' 21281 Extract given field from the vector value. Operand 1 is the 21282 vector, operand 2 specify field index and operand 0 place to store 21283 value into. 21284 21285`vec_extract_evenM' 21286 Extract even elements from the input vectors (operand 1 and 21287 operand 2). The even elements of operand 2 are concatenated to 21288 the even elements of operand 1 in their original order. The result 21289 is stored in operand 0. The output and input vectors should have 21290 the same modes. 21291 21292`vec_extract_oddM' 21293 Extract odd elements from the input vectors (operand 1 and operand 21294 2). The odd elements of operand 2 are concatenated to the odd 21295 elements of operand 1 in their original order. The result is 21296 stored in operand 0. The output and input vectors should have the 21297 same modes. 21298 21299`vec_interleave_highM' 21300 Merge high elements of the two input vectors into the output 21301 vector. The output and input vectors should have the same modes 21302 (`N' elements). The high `N/2' elements of the first input vector 21303 are interleaved with the high `N/2' elements of the second input 21304 vector. 21305 21306`vec_interleave_lowM' 21307 Merge low elements of the two input vectors into the output 21308 vector. The output and input vectors should have the same modes 21309 (`N' elements). The low `N/2' elements of the first input vector 21310 are interleaved with the low `N/2' elements of the second input 21311 vector. 21312 21313`vec_initM' 21314 Initialize the vector to given values. Operand 0 is the vector to 21315 initialize and operand 1 is parallel containing values for 21316 individual fields. 21317 21318`pushM1' 21319 Output a push instruction. Operand 0 is value to push. Used only 21320 when `PUSH_ROUNDING' is defined. For historical reason, this 21321 pattern may be missing and in such case an `mov' expander is used 21322 instead, with a `MEM' expression forming the push operation. The 21323 `mov' expander method is deprecated. 21324 21325`addM3' 21326 Add operand 2 and operand 1, storing the result in operand 0. All 21327 operands must have mode M. This can be used even on two-address 21328 machines, by means of constraints requiring operands 1 and 0 to be 21329 the same location. 21330 21331`ssaddM3', `usaddM3' 21332 21333`subM3', `sssubM3', `ussubM3' 21334 21335`mulM3', `ssmulM3', `usmulM3' 21336`divM3', `ssdivM3' 21337`udivM3', `usdivM3' 21338`modM3', `umodM3' 21339`uminM3', `umaxM3' 21340`andM3', `iorM3', `xorM3' 21341 Similar, for other arithmetic operations. 21342 21343`sminM3', `smaxM3' 21344 Signed minimum and maximum operations. When used with floating 21345 point, if both operands are zeros, or if either operand is `NaN', 21346 then it is unspecified which of the two operands is returned as 21347 the result. 21348 21349`reduc_smin_M', `reduc_smax_M' 21350 Find the signed minimum/maximum of the elements of a vector. The 21351 vector is operand 1, and the scalar result is stored in the least 21352 significant bits of operand 0 (also a vector). The output and 21353 input vector should have the same modes. 21354 21355`reduc_umin_M', `reduc_umax_M' 21356 Find the unsigned minimum/maximum of the elements of a vector. The 21357 vector is operand 1, and the scalar result is stored in the least 21358 significant bits of operand 0 (also a vector). The output and 21359 input vector should have the same modes. 21360 21361`reduc_splus_M' 21362 Compute the sum of the signed elements of a vector. The vector is 21363 operand 1, and the scalar result is stored in the least 21364 significant bits of operand 0 (also a vector). The output and 21365 input vector should have the same modes. 21366 21367`reduc_uplus_M' 21368 Compute the sum of the unsigned elements of a vector. The vector 21369 is operand 1, and the scalar result is stored in the least 21370 significant bits of operand 0 (also a vector). The output and 21371 input vector should have the same modes. 21372 21373`sdot_prodM' 21374 21375`udot_prodM' 21376 Compute the sum of the products of two signed/unsigned elements. 21377 Operand 1 and operand 2 are of the same mode. Their product, which 21378 is of a wider mode, is computed and added to operand 3. Operand 3 21379 is of a mode equal or wider than the mode of the product. The 21380 result is placed in operand 0, which is of the same mode as 21381 operand 3. 21382 21383`ssum_widenM3' 21384 21385`usum_widenM3' 21386 Operands 0 and 2 are of the same mode, which is wider than the 21387 mode of operand 1. Add operand 1 to operand 2 and place the 21388 widened result in operand 0. (This is used express accumulation of 21389 elements into an accumulator of a wider mode.) 21390 21391`vec_shl_M', `vec_shr_M' 21392 Whole vector left/right shift in bits. Operand 1 is a vector to 21393 be shifted. Operand 2 is an integer shift amount in bits. 21394 Operand 0 is where the resulting shifted vector is stored. The 21395 output and input vectors should have the same modes. 21396 21397`vec_pack_trunc_M' 21398 Narrow (demote) and merge the elements of two vectors. Operands 1 21399 and 2 are vectors of the same mode having N integral or floating 21400 point elements of size S. Operand 0 is the resulting vector in 21401 which 2*N elements of size N/2 are concatenated after narrowing 21402 them down using truncation. 21403 21404`vec_pack_ssat_M', `vec_pack_usat_M' 21405 Narrow (demote) and merge the elements of two vectors. Operands 1 21406 and 2 are vectors of the same mode having N integral elements of 21407 size S. Operand 0 is the resulting vector in which the elements 21408 of the two input vectors are concatenated after narrowing them 21409 down using signed/unsigned saturating arithmetic. 21410 21411`vec_pack_sfix_trunc_M', `vec_pack_ufix_trunc_M' 21412 Narrow, convert to signed/unsigned integral type and merge the 21413 elements of two vectors. Operands 1 and 2 are vectors of the same 21414 mode having N floating point elements of size S. Operand 0 is the 21415 resulting vector in which 2*N elements of size N/2 are 21416 concatenated. 21417 21418`vec_unpacks_hi_M', `vec_unpacks_lo_M' 21419 Extract and widen (promote) the high/low part of a vector of signed 21420 integral or floating point elements. The input vector (operand 1) 21421 has N elements of size S. Widen (promote) the high/low elements 21422 of the vector using signed or floating point extension and place 21423 the resulting N/2 values of size 2*S in the output vector (operand 21424 0). 21425 21426`vec_unpacku_hi_M', `vec_unpacku_lo_M' 21427 Extract and widen (promote) the high/low part of a vector of 21428 unsigned integral elements. The input vector (operand 1) has N 21429 elements of size S. Widen (promote) the high/low elements of the 21430 vector using zero extension and place the resulting N/2 values of 21431 size 2*S in the output vector (operand 0). 21432 21433`vec_unpacks_float_hi_M', `vec_unpacks_float_lo_M' 21434`vec_unpacku_float_hi_M', `vec_unpacku_float_lo_M' 21435 Extract, convert to floating point type and widen the high/low 21436 part of a vector of signed/unsigned integral elements. The input 21437 vector (operand 1) has N elements of size S. Convert the high/low 21438 elements of the vector using floating point conversion and place 21439 the resulting N/2 values of size 2*S in the output vector (operand 21440 0). 21441 21442`vec_widen_umult_hi_M', `vec_widen_umult_lo_M' 21443`vec_widen_smult_hi_M', `vec_widen_smult_lo_M' 21444 Signed/Unsigned widening multiplication. The two inputs (operands 21445 1 and 2) are vectors with N signed/unsigned elements of size S. 21446 Multiply the high/low elements of the two vectors, and put the N/2 21447 products of size 2*S in the output vector (operand 0). 21448 21449`mulhisi3' 21450 Multiply operands 1 and 2, which have mode `HImode', and store a 21451 `SImode' product in operand 0. 21452 21453`mulqihi3', `mulsidi3' 21454 Similar widening-multiplication instructions of other widths. 21455 21456`umulqihi3', `umulhisi3', `umulsidi3' 21457 Similar widening-multiplication instructions that do unsigned 21458 multiplication. 21459 21460`usmulqihi3', `usmulhisi3', `usmulsidi3' 21461 Similar widening-multiplication instructions that interpret the 21462 first operand as unsigned and the second operand as signed, then 21463 do a signed multiplication. 21464 21465`smulM3_highpart' 21466 Perform a signed multiplication of operands 1 and 2, which have 21467 mode M, and store the most significant half of the product in 21468 operand 0. The least significant half of the product is discarded. 21469 21470`umulM3_highpart' 21471 Similar, but the multiplication is unsigned. 21472 21473`maddMN4' 21474 Multiply operands 1 and 2, sign-extend them to mode N, add operand 21475 3, and store the result in operand 0. Operands 1 and 2 have mode 21476 M and operands 0 and 3 have mode N. Both modes must be integer or 21477 fixed-point modes and N must be twice the size of M. 21478 21479 In other words, `maddMN4' is like `mulMN3' except that it also 21480 adds operand 3. 21481 21482 These instructions are not allowed to `FAIL'. 21483 21484`umaddMN4' 21485 Like `maddMN4', but zero-extend the multiplication operands 21486 instead of sign-extending them. 21487 21488`ssmaddMN4' 21489 Like `maddMN4', but all involved operations must be 21490 signed-saturating. 21491 21492`usmaddMN4' 21493 Like `umaddMN4', but all involved operations must be 21494 unsigned-saturating. 21495 21496`msubMN4' 21497 Multiply operands 1 and 2, sign-extend them to mode N, subtract the 21498 result from operand 3, and store the result in operand 0. 21499 Operands 1 and 2 have mode M and operands 0 and 3 have mode N. 21500 Both modes must be integer or fixed-point modes and N must be twice 21501 the size of M. 21502 21503 In other words, `msubMN4' is like `mulMN3' except that it also 21504 subtracts the result from operand 3. 21505 21506 These instructions are not allowed to `FAIL'. 21507 21508`umsubMN4' 21509 Like `msubMN4', but zero-extend the multiplication operands 21510 instead of sign-extending them. 21511 21512`ssmsubMN4' 21513 Like `msubMN4', but all involved operations must be 21514 signed-saturating. 21515 21516`usmsubMN4' 21517 Like `umsubMN4', but all involved operations must be 21518 unsigned-saturating. 21519 21520`divmodM4' 21521 Signed division that produces both a quotient and a remainder. 21522 Operand 1 is divided by operand 2 to produce a quotient stored in 21523 operand 0 and a remainder stored in operand 3. 21524 21525 For machines with an instruction that produces both a quotient and 21526 a remainder, provide a pattern for `divmodM4' but do not provide 21527 patterns for `divM3' and `modM3'. This allows optimization in the 21528 relatively common case when both the quotient and remainder are 21529 computed. 21530 21531 If an instruction that just produces a quotient or just a remainder 21532 exists and is more efficient than the instruction that produces 21533 both, write the output routine of `divmodM4' to call 21534 `find_reg_note' and look for a `REG_UNUSED' note on the quotient 21535 or remainder and generate the appropriate instruction. 21536 21537`udivmodM4' 21538 Similar, but does unsigned division. 21539 21540`ashlM3', `ssashlM3', `usashlM3' 21541 Arithmetic-shift operand 1 left by a number of bits specified by 21542 operand 2, and store the result in operand 0. Here M is the mode 21543 of operand 0 and operand 1; operand 2's mode is specified by the 21544 instruction pattern, and the compiler will convert the operand to 21545 that mode before generating the instruction. The meaning of 21546 out-of-range shift counts can optionally be specified by 21547 `TARGET_SHIFT_TRUNCATION_MASK'. *Note 21548 TARGET_SHIFT_TRUNCATION_MASK::. Operand 2 is always a scalar type. 21549 21550`ashrM3', `lshrM3', `rotlM3', `rotrM3' 21551 Other shift and rotate instructions, analogous to the `ashlM3' 21552 instructions. Operand 2 is always a scalar type. 21553 21554`vashlM3', `vashrM3', `vlshrM3', `vrotlM3', `vrotrM3' 21555 Vector shift and rotate instructions that take vectors as operand 2 21556 instead of a scalar type. 21557 21558`negM2', `ssnegM2', `usnegM2' 21559 Negate operand 1 and store the result in operand 0. 21560 21561`absM2' 21562 Store the absolute value of operand 1 into operand 0. 21563 21564`sqrtM2' 21565 Store the square root of operand 1 into operand 0. 21566 21567 The `sqrt' built-in function of C always uses the mode which 21568 corresponds to the C data type `double' and the `sqrtf' built-in 21569 function uses the mode which corresponds to the C data type 21570 `float'. 21571 21572`fmodM3' 21573 Store the remainder of dividing operand 1 by operand 2 into 21574 operand 0, rounded towards zero to an integer. 21575 21576 The `fmod' built-in function of C always uses the mode which 21577 corresponds to the C data type `double' and the `fmodf' built-in 21578 function uses the mode which corresponds to the C data type 21579 `float'. 21580 21581`remainderM3' 21582 Store the remainder of dividing operand 1 by operand 2 into 21583 operand 0, rounded to the nearest integer. 21584 21585 The `remainder' built-in function of C always uses the mode which 21586 corresponds to the C data type `double' and the `remainderf' 21587 built-in function uses the mode which corresponds to the C data 21588 type `float'. 21589 21590`cosM2' 21591 Store the cosine of operand 1 into operand 0. 21592 21593 The `cos' built-in function of C always uses the mode which 21594 corresponds to the C data type `double' and the `cosf' built-in 21595 function uses the mode which corresponds to the C data type 21596 `float'. 21597 21598`sinM2' 21599 Store the sine of operand 1 into operand 0. 21600 21601 The `sin' built-in function of C always uses the mode which 21602 corresponds to the C data type `double' and the `sinf' built-in 21603 function uses the mode which corresponds to the C data type 21604 `float'. 21605 21606`expM2' 21607 Store the exponential of operand 1 into operand 0. 21608 21609 The `exp' built-in function of C always uses the mode which 21610 corresponds to the C data type `double' and the `expf' built-in 21611 function uses the mode which corresponds to the C data type 21612 `float'. 21613 21614`logM2' 21615 Store the natural logarithm of operand 1 into operand 0. 21616 21617 The `log' built-in function of C always uses the mode which 21618 corresponds to the C data type `double' and the `logf' built-in 21619 function uses the mode which corresponds to the C data type 21620 `float'. 21621 21622`powM3' 21623 Store the value of operand 1 raised to the exponent operand 2 into 21624 operand 0. 21625 21626 The `pow' built-in function of C always uses the mode which 21627 corresponds to the C data type `double' and the `powf' built-in 21628 function uses the mode which corresponds to the C data type 21629 `float'. 21630 21631`atan2M3' 21632 Store the arc tangent (inverse tangent) of operand 1 divided by 21633 operand 2 into operand 0, using the signs of both arguments to 21634 determine the quadrant of the result. 21635 21636 The `atan2' built-in function of C always uses the mode which 21637 corresponds to the C data type `double' and the `atan2f' built-in 21638 function uses the mode which corresponds to the C data type 21639 `float'. 21640 21641`floorM2' 21642 Store the largest integral value not greater than argument. 21643 21644 The `floor' built-in function of C always uses the mode which 21645 corresponds to the C data type `double' and the `floorf' built-in 21646 function uses the mode which corresponds to the C data type 21647 `float'. 21648 21649`btruncM2' 21650 Store the argument rounded to integer towards zero. 21651 21652 The `trunc' built-in function of C always uses the mode which 21653 corresponds to the C data type `double' and the `truncf' built-in 21654 function uses the mode which corresponds to the C data type 21655 `float'. 21656 21657`roundM2' 21658 Store the argument rounded to integer away from zero. 21659 21660 The `round' built-in function of C always uses the mode which 21661 corresponds to the C data type `double' and the `roundf' built-in 21662 function uses the mode which corresponds to the C data type 21663 `float'. 21664 21665`ceilM2' 21666 Store the argument rounded to integer away from zero. 21667 21668 The `ceil' built-in function of C always uses the mode which 21669 corresponds to the C data type `double' and the `ceilf' built-in 21670 function uses the mode which corresponds to the C data type 21671 `float'. 21672 21673`nearbyintM2' 21674 Store the argument rounded according to the default rounding mode 21675 21676 The `nearbyint' built-in function of C always uses the mode which 21677 corresponds to the C data type `double' and the `nearbyintf' 21678 built-in function uses the mode which corresponds to the C data 21679 type `float'. 21680 21681`rintM2' 21682 Store the argument rounded according to the default rounding mode 21683 and raise the inexact exception when the result differs in value 21684 from the argument 21685 21686 The `rint' built-in function of C always uses the mode which 21687 corresponds to the C data type `double' and the `rintf' built-in 21688 function uses the mode which corresponds to the C data type 21689 `float'. 21690 21691`lrintMN2' 21692 Convert operand 1 (valid for floating point mode M) to fixed point 21693 mode N as a signed number according to the current rounding mode 21694 and store in operand 0 (which has mode N). 21695 21696`lroundM2' 21697 Convert operand 1 (valid for floating point mode M) to fixed point 21698 mode N as a signed number rounding to nearest and away from zero 21699 and store in operand 0 (which has mode N). 21700 21701`lfloorM2' 21702 Convert operand 1 (valid for floating point mode M) to fixed point 21703 mode N as a signed number rounding down and store in operand 0 21704 (which has mode N). 21705 21706`lceilM2' 21707 Convert operand 1 (valid for floating point mode M) to fixed point 21708 mode N as a signed number rounding up and store in operand 0 21709 (which has mode N). 21710 21711`copysignM3' 21712 Store a value with the magnitude of operand 1 and the sign of 21713 operand 2 into operand 0. 21714 21715 The `copysign' built-in function of C always uses the mode which 21716 corresponds to the C data type `double' and the `copysignf' 21717 built-in function uses the mode which corresponds to the C data 21718 type `float'. 21719 21720`ffsM2' 21721 Store into operand 0 one plus the index of the least significant 21722 1-bit of operand 1. If operand 1 is zero, store zero. M is the 21723 mode of operand 0; operand 1's mode is specified by the instruction 21724 pattern, and the compiler will convert the operand to that mode 21725 before generating the instruction. 21726 21727 The `ffs' built-in function of C always uses the mode which 21728 corresponds to the C data type `int'. 21729 21730`clzM2' 21731 Store into operand 0 the number of leading 0-bits in X, starting 21732 at the most significant bit position. If X is 0, the 21733 `CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 21734 result is undefined or has a useful value. M is the mode of 21735 operand 0; operand 1's mode is specified by the instruction 21736 pattern, and the compiler will convert the operand to that mode 21737 before generating the instruction. 21738 21739`ctzM2' 21740 Store into operand 0 the number of trailing 0-bits in X, starting 21741 at the least significant bit position. If X is 0, the 21742 `CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 21743 result is undefined or has a useful value. M is the mode of 21744 operand 0; operand 1's mode is specified by the instruction 21745 pattern, and the compiler will convert the operand to that mode 21746 before generating the instruction. 21747 21748`popcountM2' 21749 Store into operand 0 the number of 1-bits in X. M is the mode of 21750 operand 0; operand 1's mode is specified by the instruction 21751 pattern, and the compiler will convert the operand to that mode 21752 before generating the instruction. 21753 21754`parityM2' 21755 Store into operand 0 the parity of X, i.e. the number of 1-bits in 21756 X modulo 2. M is the mode of operand 0; operand 1's mode is 21757 specified by the instruction pattern, and the compiler will convert 21758 the operand to that mode before generating the instruction. 21759 21760`one_cmplM2' 21761 Store the bitwise-complement of operand 1 into operand 0. 21762 21763`movmemM' 21764 Block move instruction. The destination and source blocks of 21765 memory are the first two operands, and both are `mem:BLK's with an 21766 address in mode `Pmode'. 21767 21768 The number of bytes to move is the third operand, in mode M. 21769 Usually, you specify `word_mode' for M. However, if you can 21770 generate better code knowing the range of valid lengths is smaller 21771 than those representable in a full word, you should provide a 21772 pattern with a mode corresponding to the range of values you can 21773 handle efficiently (e.g., `QImode' for values in the range 0-127; 21774 note we avoid numbers that appear negative) and also a pattern 21775 with `word_mode'. 21776 21777 The fourth operand is the known shared alignment of the source and 21778 destination, in the form of a `const_int' rtx. Thus, if the 21779 compiler knows that both source and destination are word-aligned, 21780 it may provide the value 4 for this operand. 21781 21782 Optional operands 5 and 6 specify expected alignment and size of 21783 block respectively. The expected alignment differs from alignment 21784 in operand 4 in a way that the blocks are not required to be 21785 aligned according to it in all cases. This expected alignment is 21786 also in bytes, just like operand 4. Expected size, when unknown, 21787 is set to `(const_int -1)'. 21788 21789 Descriptions of multiple `movmemM' patterns can only be beneficial 21790 if the patterns for smaller modes have fewer restrictions on their 21791 first, second and fourth operands. Note that the mode M in 21792 `movmemM' does not impose any restriction on the mode of 21793 individually moved data units in the block. 21794 21795 These patterns need not give special consideration to the 21796 possibility that the source and destination strings might overlap. 21797 21798`movstr' 21799 String copy instruction, with `stpcpy' semantics. Operand 0 is an 21800 output operand in mode `Pmode'. The addresses of the destination 21801 and source strings are operands 1 and 2, and both are `mem:BLK's 21802 with addresses in mode `Pmode'. The execution of the expansion of 21803 this pattern should store in operand 0 the address in which the 21804 `NUL' terminator was stored in the destination string. 21805 21806`setmemM' 21807 Block set instruction. The destination string is the first 21808 operand, given as a `mem:BLK' whose address is in mode `Pmode'. 21809 The number of bytes to set is the second operand, in mode M. The 21810 value to initialize the memory with is the third operand. Targets 21811 that only support the clearing of memory should reject any value 21812 that is not the constant 0. See `movmemM' for a discussion of the 21813 choice of mode. 21814 21815 The fourth operand is the known alignment of the destination, in 21816 the form of a `const_int' rtx. Thus, if the compiler knows that 21817 the destination is word-aligned, it may provide the value 4 for 21818 this operand. 21819 21820 Optional operands 5 and 6 specify expected alignment and size of 21821 block respectively. The expected alignment differs from alignment 21822 in operand 4 in a way that the blocks are not required to be 21823 aligned according to it in all cases. This expected alignment is 21824 also in bytes, just like operand 4. Expected size, when unknown, 21825 is set to `(const_int -1)'. 21826 21827 The use for multiple `setmemM' is as for `movmemM'. 21828 21829`cmpstrnM' 21830 String compare instruction, with five operands. Operand 0 is the 21831 output; it has mode M. The remaining four operands are like the 21832 operands of `movmemM'. The two memory blocks specified are 21833 compared byte by byte in lexicographic order starting at the 21834 beginning of each string. The instruction is not allowed to 21835 prefetch more than one byte at a time since either string may end 21836 in the first byte and reading past that may access an invalid page 21837 or segment and cause a fault. The comparison terminates early if 21838 the fetched bytes are different or if they are equal to zero. The 21839 effect of the instruction is to store a value in operand 0 whose 21840 sign indicates the result of the comparison. 21841 21842`cmpstrM' 21843 String compare instruction, without known maximum length. Operand 21844 0 is the output; it has mode M. The second and third operand are 21845 the blocks of memory to be compared; both are `mem:BLK' with an 21846 address in mode `Pmode'. 21847 21848 The fourth operand is the known shared alignment of the source and 21849 destination, in the form of a `const_int' rtx. Thus, if the 21850 compiler knows that both source and destination are word-aligned, 21851 it may provide the value 4 for this operand. 21852 21853 The two memory blocks specified are compared byte by byte in 21854 lexicographic order starting at the beginning of each string. The 21855 instruction is not allowed to prefetch more than one byte at a 21856 time since either string may end in the first byte and reading 21857 past that may access an invalid page or segment and cause a fault. 21858 The comparison will terminate when the fetched bytes are different 21859 or if they are equal to zero. The effect of the instruction is to 21860 store a value in operand 0 whose sign indicates the result of the 21861 comparison. 21862 21863`cmpmemM' 21864 Block compare instruction, with five operands like the operands of 21865 `cmpstrM'. The two memory blocks specified are compared byte by 21866 byte in lexicographic order starting at the beginning of each 21867 block. Unlike `cmpstrM' the instruction can prefetch any bytes in 21868 the two memory blocks. Also unlike `cmpstrM' the comparison will 21869 not stop if both bytes are zero. The effect of the instruction is 21870 to store a value in operand 0 whose sign indicates the result of 21871 the comparison. 21872 21873`strlenM' 21874 Compute the length of a string, with three operands. Operand 0 is 21875 the result (of mode M), operand 1 is a `mem' referring to the 21876 first character of the string, operand 2 is the character to 21877 search for (normally zero), and operand 3 is a constant describing 21878 the known alignment of the beginning of the string. 21879 21880`floatMN2' 21881 Convert signed integer operand 1 (valid for fixed point mode M) to 21882 floating point mode N and store in operand 0 (which has mode N). 21883 21884`floatunsMN2' 21885 Convert unsigned integer operand 1 (valid for fixed point mode M) 21886 to floating point mode N and store in operand 0 (which has mode N). 21887 21888`fixMN2' 21889 Convert operand 1 (valid for floating point mode M) to fixed point 21890 mode N as a signed number and store in operand 0 (which has mode 21891 N). This instruction's result is defined only when the value of 21892 operand 1 is an integer. 21893 21894 If the machine description defines this pattern, it also needs to 21895 define the `ftrunc' pattern. 21896 21897`fixunsMN2' 21898 Convert operand 1 (valid for floating point mode M) to fixed point 21899 mode N as an unsigned number and store in operand 0 (which has 21900 mode N). This instruction's result is defined only when the value 21901 of operand 1 is an integer. 21902 21903`ftruncM2' 21904 Convert operand 1 (valid for floating point mode M) to an integer 21905 value, still represented in floating point mode M, and store it in 21906 operand 0 (valid for floating point mode M). 21907 21908`fix_truncMN2' 21909 Like `fixMN2' but works for any floating point value of mode M by 21910 converting the value to an integer. 21911 21912`fixuns_truncMN2' 21913 Like `fixunsMN2' but works for any floating point value of mode M 21914 by converting the value to an integer. 21915 21916`truncMN2' 21917 Truncate operand 1 (valid for mode M) to mode N and store in 21918 operand 0 (which has mode N). Both modes must be fixed point or 21919 both floating point. 21920 21921`extendMN2' 21922 Sign-extend operand 1 (valid for mode M) to mode N and store in 21923 operand 0 (which has mode N). Both modes must be fixed point or 21924 both floating point. 21925 21926`zero_extendMN2' 21927 Zero-extend operand 1 (valid for mode M) to mode N and store in 21928 operand 0 (which has mode N). Both modes must be fixed point. 21929 21930`fractMN2' 21931 Convert operand 1 of mode M to mode N and store in operand 0 21932 (which has mode N). Mode M and mode N could be fixed-point to 21933 fixed-point, signed integer to fixed-point, fixed-point to signed 21934 integer, floating-point to fixed-point, or fixed-point to 21935 floating-point. When overflows or underflows happen, the results 21936 are undefined. 21937 21938`satfractMN2' 21939 Convert operand 1 of mode M to mode N and store in operand 0 21940 (which has mode N). Mode M and mode N could be fixed-point to 21941 fixed-point, signed integer to fixed-point, or floating-point to 21942 fixed-point. When overflows or underflows happen, the instruction 21943 saturates the results to the maximum or the minimum. 21944 21945`fractunsMN2' 21946 Convert operand 1 of mode M to mode N and store in operand 0 21947 (which has mode N). Mode M and mode N could be unsigned integer 21948 to fixed-point, or fixed-point to unsigned integer. When 21949 overflows or underflows happen, the results are undefined. 21950 21951`satfractunsMN2' 21952 Convert unsigned integer operand 1 of mode M to fixed-point mode N 21953 and store in operand 0 (which has mode N). When overflows or 21954 underflows happen, the instruction saturates the results to the 21955 maximum or the minimum. 21956 21957`extv' 21958 Extract a bit-field from operand 1 (a register or memory operand), 21959 where operand 2 specifies the width in bits and operand 3 the 21960 starting bit, and store it in operand 0. Operand 0 must have mode 21961 `word_mode'. Operand 1 may have mode `byte_mode' or `word_mode'; 21962 often `word_mode' is allowed only for registers. Operands 2 and 3 21963 must be valid for `word_mode'. 21964 21965 The RTL generation pass generates this instruction only with 21966 constants for operands 2 and 3 and the constant is never zero for 21967 operand 2. 21968 21969 The bit-field value is sign-extended to a full word integer before 21970 it is stored in operand 0. 21971 21972`extzv' 21973 Like `extv' except that the bit-field value is zero-extended. 21974 21975`insv' 21976 Store operand 3 (which must be valid for `word_mode') into a 21977 bit-field in operand 0, where operand 1 specifies the width in 21978 bits and operand 2 the starting bit. Operand 0 may have mode 21979 `byte_mode' or `word_mode'; often `word_mode' is allowed only for 21980 registers. Operands 1 and 2 must be valid for `word_mode'. 21981 21982 The RTL generation pass generates this instruction only with 21983 constants for operands 1 and 2 and the constant is never zero for 21984 operand 1. 21985 21986`movMODEcc' 21987 Conditionally move operand 2 or operand 3 into operand 0 according 21988 to the comparison in operand 1. If the comparison is true, 21989 operand 2 is moved into operand 0, otherwise operand 3 is moved. 21990 21991 The mode of the operands being compared need not be the same as 21992 the operands being moved. Some machines, sparc64 for example, 21993 have instructions that conditionally move an integer value based 21994 on the floating point condition codes and vice versa. 21995 21996 If the machine does not have conditional move instructions, do not 21997 define these patterns. 21998 21999`addMODEcc' 22000 Similar to `movMODEcc' but for conditional addition. Conditionally 22001 move operand 2 or (operands 2 + operand 3) into operand 0 22002 according to the comparison in operand 1. If the comparison is 22003 true, operand 2 is moved into operand 0, otherwise (operand 2 + 22004 operand 3) is moved. 22005 22006`cstoreMODE4' 22007 Store zero or nonzero in operand 0 according to whether a 22008 comparison is true. Operand 1 is a comparison operator. Operand 22009 2 and operand 3 are the first and second operand of the 22010 comparison, respectively. You specify the mode that operand 0 22011 must have when you write the `match_operand' expression. The 22012 compiler automatically sees which mode you have used and supplies 22013 an operand of that mode. 22014 22015 The value stored for a true condition must have 1 as its low bit, 22016 or else must be negative. Otherwise the instruction is not 22017 suitable and you should omit it from the machine description. You 22018 describe to the compiler exactly which value is stored by defining 22019 the macro `STORE_FLAG_VALUE' (*note Misc::). If a description 22020 cannot be found that can be used for all the `sCOND' patterns, you 22021 should omit those operations from the machine description. 22022 22023 These operations may fail, but should do so only in relatively 22024 uncommon cases; if they would fail for common cases involving 22025 integer comparisons, it is best to omit these patterns. 22026 22027 If these operations are omitted, the compiler will usually 22028 generate code that copies the constant one to the target and 22029 branches around an assignment of zero to the target. If this code 22030 is more efficient than the potential instructions used for the 22031 `cstoreMODE4' pattern followed by those required to convert the 22032 result into a 1 or a zero in `SImode', you should omit the 22033 `cstoreMODE4' operations from the machine description. 22034 22035`cbranchMODE4' 22036 Conditional branch instruction combined with a compare instruction. 22037 Operand 0 is a comparison operator. Operand 1 and operand 2 are 22038 the first and second operands of the comparison, respectively. 22039 Operand 3 is a `label_ref' that refers to the label to jump to. 22040 22041`jump' 22042 A jump inside a function; an unconditional branch. Operand 0 is 22043 the `label_ref' of the label to jump to. This pattern name is 22044 mandatory on all machines. 22045 22046`call' 22047 Subroutine call instruction returning no value. Operand 0 is the 22048 function to call; operand 1 is the number of bytes of arguments 22049 pushed as a `const_int'; operand 2 is the number of registers used 22050 as operands. 22051 22052 On most machines, operand 2 is not actually stored into the RTL 22053 pattern. It is supplied for the sake of some RISC machines which 22054 need to put this information into the assembler code; they can put 22055 it in the RTL instead of operand 1. 22056 22057 Operand 0 should be a `mem' RTX whose address is the address of the 22058 function. Note, however, that this address can be a `symbol_ref' 22059 expression even if it would not be a legitimate memory address on 22060 the target machine. If it is also not a valid argument for a call 22061 instruction, the pattern for this operation should be a 22062 `define_expand' (*note Expander Definitions::) that places the 22063 address into a register and uses that register in the call 22064 instruction. 22065 22066`call_value' 22067 Subroutine call instruction returning a value. Operand 0 is the 22068 hard register in which the value is returned. There are three more 22069 operands, the same as the three operands of the `call' instruction 22070 (but with numbers increased by one). 22071 22072 Subroutines that return `BLKmode' objects use the `call' insn. 22073 22074`call_pop', `call_value_pop' 22075 Similar to `call' and `call_value', except used if defined and if 22076 `RETURN_POPS_ARGS' is nonzero. They should emit a `parallel' that 22077 contains both the function call and a `set' to indicate the 22078 adjustment made to the frame pointer. 22079 22080 For machines where `RETURN_POPS_ARGS' can be nonzero, the use of 22081 these patterns increases the number of functions for which the 22082 frame pointer can be eliminated, if desired. 22083 22084`untyped_call' 22085 Subroutine call instruction returning a value of any type. 22086 Operand 0 is the function to call; operand 1 is a memory location 22087 where the result of calling the function is to be stored; operand 22088 2 is a `parallel' expression where each element is a `set' 22089 expression that indicates the saving of a function return value 22090 into the result block. 22091 22092 This instruction pattern should be defined to support 22093 `__builtin_apply' on machines where special instructions are needed 22094 to call a subroutine with arbitrary arguments or to save the value 22095 returned. This instruction pattern is required on machines that 22096 have multiple registers that can hold a return value (i.e. 22097 `FUNCTION_VALUE_REGNO_P' is true for more than one register). 22098 22099`return' 22100 Subroutine return instruction. This instruction pattern name 22101 should be defined only if a single instruction can do all the work 22102 of returning from a function. 22103 22104 Like the `movM' patterns, this pattern is also used after the RTL 22105 generation phase. In this case it is to support machines where 22106 multiple instructions are usually needed to return from a 22107 function, but some class of functions only requires one 22108 instruction to implement a return. Normally, the applicable 22109 functions are those which do not need to save any registers or 22110 allocate stack space. 22111 22112 For such machines, the condition specified in this pattern should 22113 only be true when `reload_completed' is nonzero and the function's 22114 epilogue would only be a single instruction. For machines with 22115 register windows, the routine `leaf_function_p' may be used to 22116 determine if a register window push is required. 22117 22118 Machines that have conditional return instructions should define 22119 patterns such as 22120 22121 (define_insn "" 22122 [(set (pc) 22123 (if_then_else (match_operator 22124 0 "comparison_operator" 22125 [(cc0) (const_int 0)]) 22126 (return) 22127 (pc)))] 22128 "CONDITION" 22129 "...") 22130 22131 where CONDITION would normally be the same condition specified on 22132 the named `return' pattern. 22133 22134`untyped_return' 22135 Untyped subroutine return instruction. This instruction pattern 22136 should be defined to support `__builtin_return' on machines where 22137 special instructions are needed to return a value of any type. 22138 22139 Operand 0 is a memory location where the result of calling a 22140 function with `__builtin_apply' is stored; operand 1 is a 22141 `parallel' expression where each element is a `set' expression 22142 that indicates the restoring of a function return value from the 22143 result block. 22144 22145`nop' 22146 No-op instruction. This instruction pattern name should always be 22147 defined to output a no-op in assembler code. `(const_int 0)' will 22148 do as an RTL pattern. 22149 22150`indirect_jump' 22151 An instruction to jump to an address which is operand zero. This 22152 pattern name is mandatory on all machines. 22153 22154`casesi' 22155 Instruction to jump through a dispatch table, including bounds 22156 checking. This instruction takes five operands: 22157 22158 1. The index to dispatch on, which has mode `SImode'. 22159 22160 2. The lower bound for indices in the table, an integer constant. 22161 22162 3. The total range of indices in the table--the largest index 22163 minus the smallest one (both inclusive). 22164 22165 4. A label that precedes the table itself. 22166 22167 5. A label to jump to if the index has a value outside the 22168 bounds. 22169 22170 The table is an `addr_vec' or `addr_diff_vec' inside of a 22171 `jump_insn'. The number of elements in the table is one plus the 22172 difference between the upper bound and the lower bound. 22173 22174`tablejump' 22175 Instruction to jump to a variable address. This is a low-level 22176 capability which can be used to implement a dispatch table when 22177 there is no `casesi' pattern. 22178 22179 This pattern requires two operands: the address or offset, and a 22180 label which should immediately precede the jump table. If the 22181 macro `CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then 22182 the first operand is an offset which counts from the address of 22183 the table; otherwise, it is an absolute address to jump to. In 22184 either case, the first operand has mode `Pmode'. 22185 22186 The `tablejump' insn is always the last insn before the jump table 22187 it uses. Its assembler code normally has no need to use the 22188 second operand, but you should incorporate it in the RTL pattern so 22189 that the jump optimizer will not delete the table as unreachable 22190 code. 22191 22192`decrement_and_branch_until_zero' 22193 Conditional branch instruction that decrements a register and 22194 jumps if the register is nonzero. Operand 0 is the register to 22195 decrement and test; operand 1 is the label to jump to if the 22196 register is nonzero. *Note Looping Patterns::. 22197 22198 This optional instruction pattern is only used by the combiner, 22199 typically for loops reversed by the loop optimizer when strength 22200 reduction is enabled. 22201 22202`doloop_end' 22203 Conditional branch instruction that decrements a register and 22204 jumps if the register is nonzero. This instruction takes five 22205 operands: Operand 0 is the register to decrement and test; operand 22206 1 is the number of loop iterations as a `const_int' or 22207 `const0_rtx' if this cannot be determined until run-time; operand 22208 2 is the actual or estimated maximum number of iterations as a 22209 `const_int'; operand 3 is the number of enclosed loops as a 22210 `const_int' (an innermost loop has a value of 1); operand 4 is the 22211 label to jump to if the register is nonzero. *Note Looping 22212 Patterns::. 22213 22214 This optional instruction pattern should be defined for machines 22215 with low-overhead looping instructions as the loop optimizer will 22216 try to modify suitable loops to utilize it. If nested 22217 low-overhead looping is not supported, use a `define_expand' 22218 (*note Expander Definitions::) and make the pattern fail if 22219 operand 3 is not `const1_rtx'. Similarly, if the actual or 22220 estimated maximum number of iterations is too large for this 22221 instruction, make it fail. 22222 22223`doloop_begin' 22224 Companion instruction to `doloop_end' required for machines that 22225 need to perform some initialization, such as loading special 22226 registers used by a low-overhead looping instruction. If 22227 initialization insns do not always need to be emitted, use a 22228 `define_expand' (*note Expander Definitions::) and make it fail. 22229 22230`canonicalize_funcptr_for_compare' 22231 Canonicalize the function pointer in operand 1 and store the result 22232 into operand 0. 22233 22234 Operand 0 is always a `reg' and has mode `Pmode'; operand 1 may be 22235 a `reg', `mem', `symbol_ref', `const_int', etc and also has mode 22236 `Pmode'. 22237 22238 Canonicalization of a function pointer usually involves computing 22239 the address of the function which would be called if the function 22240 pointer were used in an indirect call. 22241 22242 Only define this pattern if function pointers on the target machine 22243 can have different values but still call the same function when 22244 used in an indirect call. 22245 22246`save_stack_block' 22247`save_stack_function' 22248`save_stack_nonlocal' 22249`restore_stack_block' 22250`restore_stack_function' 22251`restore_stack_nonlocal' 22252 Most machines save and restore the stack pointer by copying it to 22253 or from an object of mode `Pmode'. Do not define these patterns on 22254 such machines. 22255 22256 Some machines require special handling for stack pointer saves and 22257 restores. On those machines, define the patterns corresponding to 22258 the non-standard cases by using a `define_expand' (*note Expander 22259 Definitions::) that produces the required insns. The three types 22260 of saves and restores are: 22261 22262 1. `save_stack_block' saves the stack pointer at the start of a 22263 block that allocates a variable-sized object, and 22264 `restore_stack_block' restores the stack pointer when the 22265 block is exited. 22266 22267 2. `save_stack_function' and `restore_stack_function' do a 22268 similar job for the outermost block of a function and are 22269 used when the function allocates variable-sized objects or 22270 calls `alloca'. Only the epilogue uses the restored stack 22271 pointer, allowing a simpler save or restore sequence on some 22272 machines. 22273 22274 3. `save_stack_nonlocal' is used in functions that contain labels 22275 branched to by nested functions. It saves the stack pointer 22276 in such a way that the inner function can use 22277 `restore_stack_nonlocal' to restore the stack pointer. The 22278 compiler generates code to restore the frame and argument 22279 pointer registers, but some machines require saving and 22280 restoring additional data such as register window information 22281 or stack backchains. Place insns in these patterns to save 22282 and restore any such required data. 22283 22284 When saving the stack pointer, operand 0 is the save area and 22285 operand 1 is the stack pointer. The mode used to allocate the 22286 save area defaults to `Pmode' but you can override that choice by 22287 defining the `STACK_SAVEAREA_MODE' macro (*note Storage Layout::). 22288 You must specify an integral mode, or `VOIDmode' if no save area 22289 is needed for a particular type of save (either because no save is 22290 needed or because a machine-specific save area can be used). 22291 Operand 0 is the stack pointer and operand 1 is the save area for 22292 restore operations. If `save_stack_block' is defined, operand 0 22293 must not be `VOIDmode' since these saves can be arbitrarily nested. 22294 22295 A save area is a `mem' that is at a constant offset from 22296 `virtual_stack_vars_rtx' when the stack pointer is saved for use by 22297 nonlocal gotos and a `reg' in the other two cases. 22298 22299`allocate_stack' 22300 Subtract (or add if `STACK_GROWS_DOWNWARD' is undefined) operand 1 22301 from the stack pointer to create space for dynamically allocated 22302 data. 22303 22304 Store the resultant pointer to this space into operand 0. If you 22305 are allocating space from the main stack, do this by emitting a 22306 move insn to copy `virtual_stack_dynamic_rtx' to operand 0. If 22307 you are allocating the space elsewhere, generate code to copy the 22308 location of the space to operand 0. In the latter case, you must 22309 ensure this space gets freed when the corresponding space on the 22310 main stack is free. 22311 22312 Do not define this pattern if all that must be done is the 22313 subtraction. Some machines require other operations such as stack 22314 probes or maintaining the back chain. Define this pattern to emit 22315 those operations in addition to updating the stack pointer. 22316 22317`check_stack' 22318 If stack checking (*note Stack Checking::) cannot be done on your 22319 system by probing the stack, define this pattern to perform the 22320 needed check and signal an error if the stack has overflowed. The 22321 single operand is the address in the stack farthest from the 22322 current stack pointer that you need to validate. Normally, on 22323 platforms where this pattern is needed, you would obtain the stack 22324 limit from a global or thread-specific variable or register. 22325 22326`probe_stack' 22327 If stack checking (*note Stack Checking::) can be done on your 22328 system by probing the stack but doing it with a "store zero" 22329 instruction is not valid or optimal, define this pattern to do the 22330 probing differently and signal an error if the stack has 22331 overflowed. The single operand is the memory reference in the 22332 stack that needs to be probed. 22333 22334`nonlocal_goto' 22335 Emit code to generate a non-local goto, e.g., a jump from one 22336 function to a label in an outer function. This pattern has four 22337 arguments, each representing a value to be used in the jump. The 22338 first argument is to be loaded into the frame pointer, the second 22339 is the address to branch to (code to dispatch to the actual label), 22340 the third is the address of a location where the stack is saved, 22341 and the last is the address of the label, to be placed in the 22342 location for the incoming static chain. 22343 22344 On most machines you need not define this pattern, since GCC will 22345 already generate the correct code, which is to load the frame 22346 pointer and static chain, restore the stack (using the 22347 `restore_stack_nonlocal' pattern, if defined), and jump indirectly 22348 to the dispatcher. You need only define this pattern if this code 22349 will not work on your machine. 22350 22351`nonlocal_goto_receiver' 22352 This pattern, if defined, contains code needed at the target of a 22353 nonlocal goto after the code already generated by GCC. You will 22354 not normally need to define this pattern. A typical reason why 22355 you might need this pattern is if some value, such as a pointer to 22356 a global table, must be restored when the frame pointer is 22357 restored. Note that a nonlocal goto only occurs within a 22358 unit-of-translation, so a global table pointer that is shared by 22359 all functions of a given module need not be restored. There are 22360 no arguments. 22361 22362`exception_receiver' 22363 This pattern, if defined, contains code needed at the site of an 22364 exception handler that isn't needed at the site of a nonlocal 22365 goto. You will not normally need to define this pattern. A 22366 typical reason why you might need this pattern is if some value, 22367 such as a pointer to a global table, must be restored after 22368 control flow is branched to the handler of an exception. There 22369 are no arguments. 22370 22371`builtin_setjmp_setup' 22372 This pattern, if defined, contains additional code needed to 22373 initialize the `jmp_buf'. You will not normally need to define 22374 this pattern. A typical reason why you might need this pattern is 22375 if some value, such as a pointer to a global table, must be 22376 restored. Though it is preferred that the pointer value be 22377 recalculated if possible (given the address of a label for 22378 instance). The single argument is a pointer to the `jmp_buf'. 22379 Note that the buffer is five words long and that the first three 22380 are normally used by the generic mechanism. 22381 22382`builtin_setjmp_receiver' 22383 This pattern, if defined, contains code needed at the site of a 22384 built-in setjmp that isn't needed at the site of a nonlocal goto. 22385 You will not normally need to define this pattern. A typical 22386 reason why you might need this pattern is if some value, such as a 22387 pointer to a global table, must be restored. It takes one 22388 argument, which is the label to which builtin_longjmp transfered 22389 control; this pattern may be emitted at a small offset from that 22390 label. 22391 22392`builtin_longjmp' 22393 This pattern, if defined, performs the entire action of the 22394 longjmp. You will not normally need to define this pattern unless 22395 you also define `builtin_setjmp_setup'. The single argument is a 22396 pointer to the `jmp_buf'. 22397 22398`eh_return' 22399 This pattern, if defined, affects the way `__builtin_eh_return', 22400 and thence the call frame exception handling library routines, are 22401 built. It is intended to handle non-trivial actions needed along 22402 the abnormal return path. 22403 22404 The address of the exception handler to which the function should 22405 return is passed as operand to this pattern. It will normally 22406 need to copied by the pattern to some special register or memory 22407 location. If the pattern needs to determine the location of the 22408 target call frame in order to do so, it may use 22409 `EH_RETURN_STACKADJ_RTX', if defined; it will have already been 22410 assigned. 22411 22412 If this pattern is not defined, the default action will be to 22413 simply copy the return address to `EH_RETURN_HANDLER_RTX'. Either 22414 that macro or this pattern needs to be defined if call frame 22415 exception handling is to be used. 22416 22417`prologue' 22418 This pattern, if defined, emits RTL for entry to a function. The 22419 function entry is responsible for setting up the stack frame, 22420 initializing the frame pointer register, saving callee saved 22421 registers, etc. 22422 22423 Using a prologue pattern is generally preferred over defining 22424 `TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the 22425 prologue. 22426 22427 The `prologue' pattern is particularly useful for targets which 22428 perform instruction scheduling. 22429 22430`epilogue' 22431 This pattern emits RTL for exit from a function. The function 22432 exit is responsible for deallocating the stack frame, restoring 22433 callee saved registers and emitting the return instruction. 22434 22435 Using an epilogue pattern is generally preferred over defining 22436 `TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the 22437 epilogue. 22438 22439 The `epilogue' pattern is particularly useful for targets which 22440 perform instruction scheduling or which have delay slots for their 22441 return instruction. 22442 22443`sibcall_epilogue' 22444 This pattern, if defined, emits RTL for exit from a function 22445 without the final branch back to the calling function. This 22446 pattern will be emitted before any sibling call (aka tail call) 22447 sites. 22448 22449 The `sibcall_epilogue' pattern must not clobber any arguments used 22450 for parameter passing or any stack slots for arguments passed to 22451 the current function. 22452 22453`trap' 22454 This pattern, if defined, signals an error, typically by causing 22455 some kind of signal to be raised. Among other places, it is used 22456 by the Java front end to signal `invalid array index' exceptions. 22457 22458`ctrapMM4' 22459 Conditional trap instruction. Operand 0 is a piece of RTL which 22460 performs a comparison, and operands 1 and 2 are the arms of the 22461 comparison. Operand 3 is the trap code, an integer. 22462 22463 A typical `ctrap' pattern looks like 22464 22465 (define_insn "ctrapsi4" 22466 [(trap_if (match_operator 0 "trap_operator" 22467 [(match_operand 1 "register_operand") 22468 (match_operand 2 "immediate_operand")]) 22469 (match_operand 3 "const_int_operand" "i"))] 22470 "" 22471 "...") 22472 22473`prefetch' 22474 This pattern, if defined, emits code for a non-faulting data 22475 prefetch instruction. Operand 0 is the address of the memory to 22476 prefetch. Operand 1 is a constant 1 if the prefetch is preparing 22477 for a write to the memory address, or a constant 0 otherwise. 22478 Operand 2 is the expected degree of temporal locality of the data 22479 and is a value between 0 and 3, inclusive; 0 means that the data 22480 has no temporal locality, so it need not be left in the cache 22481 after the access; 3 means that the data has a high degree of 22482 temporal locality and should be left in all levels of cache 22483 possible; 1 and 2 mean, respectively, a low or moderate degree of 22484 temporal locality. 22485 22486 Targets that do not support write prefetches or locality hints can 22487 ignore the values of operands 1 and 2. 22488 22489`blockage' 22490 This pattern defines a pseudo insn that prevents the instruction 22491 scheduler from moving instructions across the boundary defined by 22492 the blockage insn. Normally an UNSPEC_VOLATILE pattern. 22493 22494`memory_barrier' 22495 If the target memory model is not fully synchronous, then this 22496 pattern should be defined to an instruction that orders both loads 22497 and stores before the instruction with respect to loads and stores 22498 after the instruction. This pattern has no operands. 22499 22500`sync_compare_and_swapMODE' 22501 This pattern, if defined, emits code for an atomic compare-and-swap 22502 operation. Operand 1 is the memory on which the atomic operation 22503 is performed. Operand 2 is the "old" value to be compared against 22504 the current contents of the memory location. Operand 3 is the 22505 "new" value to store in the memory if the compare succeeds. 22506 Operand 0 is the result of the operation; it should contain the 22507 contents of the memory before the operation. If the compare 22508 succeeds, this should obviously be a copy of operand 2. 22509 22510 This pattern must show that both operand 0 and operand 1 are 22511 modified. 22512 22513 This pattern must issue any memory barrier instructions such that 22514 all memory operations before the atomic operation occur before the 22515 atomic operation and all memory operations after the atomic 22516 operation occur after the atomic operation. 22517 22518 For targets where the success or failure of the compare-and-swap 22519 operation is available via the status flags, it is possible to 22520 avoid a separate compare operation and issue the subsequent branch 22521 or store-flag operation immediately after the compare-and-swap. 22522 To this end, GCC will look for a `MODE_CC' set in the output of 22523 `sync_compare_and_swapMODE'; if the machine description includes 22524 such a set, the target should also define special `cbranchcc4' 22525 and/or `cstorecc4' instructions. GCC will then be able to take 22526 the destination of the `MODE_CC' set and pass it to the 22527 `cbranchcc4' or `cstorecc4' pattern as the first operand of the 22528 comparison (the second will be `(const_int 0)'). 22529 22530`sync_addMODE', `sync_subMODE' 22531`sync_iorMODE', `sync_andMODE' 22532`sync_xorMODE', `sync_nandMODE' 22533 These patterns emit code for an atomic operation on memory. 22534 Operand 0 is the memory on which the atomic operation is performed. 22535 Operand 1 is the second operand to the binary operator. 22536 22537 This pattern must issue any memory barrier instructions such that 22538 all memory operations before the atomic operation occur before the 22539 atomic operation and all memory operations after the atomic 22540 operation occur after the atomic operation. 22541 22542 If these patterns are not defined, the operation will be 22543 constructed from a compare-and-swap operation, if defined. 22544 22545`sync_old_addMODE', `sync_old_subMODE' 22546`sync_old_iorMODE', `sync_old_andMODE' 22547`sync_old_xorMODE', `sync_old_nandMODE' 22548 These patterns are emit code for an atomic operation on memory, 22549 and return the value that the memory contained before the 22550 operation. Operand 0 is the result value, operand 1 is the memory 22551 on which the atomic operation is performed, and operand 2 is the 22552 second operand to the binary operator. 22553 22554 This pattern must issue any memory barrier instructions such that 22555 all memory operations before the atomic operation occur before the 22556 atomic operation and all memory operations after the atomic 22557 operation occur after the atomic operation. 22558 22559 If these patterns are not defined, the operation will be 22560 constructed from a compare-and-swap operation, if defined. 22561 22562`sync_new_addMODE', `sync_new_subMODE' 22563`sync_new_iorMODE', `sync_new_andMODE' 22564`sync_new_xorMODE', `sync_new_nandMODE' 22565 These patterns are like their `sync_old_OP' counterparts, except 22566 that they return the value that exists in the memory location 22567 after the operation, rather than before the operation. 22568 22569`sync_lock_test_and_setMODE' 22570 This pattern takes two forms, based on the capabilities of the 22571 target. In either case, operand 0 is the result of the operand, 22572 operand 1 is the memory on which the atomic operation is 22573 performed, and operand 2 is the value to set in the lock. 22574 22575 In the ideal case, this operation is an atomic exchange operation, 22576 in which the previous value in memory operand is copied into the 22577 result operand, and the value operand is stored in the memory 22578 operand. 22579 22580 For less capable targets, any value operand that is not the 22581 constant 1 should be rejected with `FAIL'. In this case the 22582 target may use an atomic test-and-set bit operation. The result 22583 operand should contain 1 if the bit was previously set and 0 if 22584 the bit was previously clear. The true contents of the memory 22585 operand are implementation defined. 22586 22587 This pattern must issue any memory barrier instructions such that 22588 the pattern as a whole acts as an acquire barrier, that is all 22589 memory operations after the pattern do not occur until the lock is 22590 acquired. 22591 22592 If this pattern is not defined, the operation will be constructed 22593 from a compare-and-swap operation, if defined. 22594 22595`sync_lock_releaseMODE' 22596 This pattern, if defined, releases a lock set by 22597 `sync_lock_test_and_setMODE'. Operand 0 is the memory that 22598 contains the lock; operand 1 is the value to store in the lock. 22599 22600 If the target doesn't implement full semantics for 22601 `sync_lock_test_and_setMODE', any value operand which is not the 22602 constant 0 should be rejected with `FAIL', and the true contents 22603 of the memory operand are implementation defined. 22604 22605 This pattern must issue any memory barrier instructions such that 22606 the pattern as a whole acts as a release barrier, that is the lock 22607 is released only after all previous memory operations have 22608 completed. 22609 22610 If this pattern is not defined, then a `memory_barrier' pattern 22611 will be emitted, followed by a store of the value to the memory 22612 operand. 22613 22614`stack_protect_set' 22615 This pattern, if defined, moves a `Pmode' value from the memory in 22616 operand 1 to the memory in operand 0 without leaving the value in 22617 a register afterward. This is to avoid leaking the value some 22618 place that an attacker might use to rewrite the stack guard slot 22619 after having clobbered it. 22620 22621 If this pattern is not defined, then a plain move pattern is 22622 generated. 22623 22624`stack_protect_test' 22625 This pattern, if defined, compares a `Pmode' value from the memory 22626 in operand 1 with the memory in operand 0 without leaving the 22627 value in a register afterward and branches to operand 2 if the 22628 values weren't equal. 22629 22630 If this pattern is not defined, then a plain compare pattern and 22631 conditional branch pattern is used. 22632 22633`clear_cache' 22634 This pattern, if defined, flushes the instruction cache for a 22635 region of memory. The region is bounded to by the Pmode pointers 22636 in operand 0 inclusive and operand 1 exclusive. 22637 22638 If this pattern is not defined, a call to the library function 22639 `__clear_cache' is used. 22640 22641 22642 22643File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc 22644 2264516.10 When the Order of Patterns Matters 22646======================================== 22647 22648Sometimes an insn can match more than one instruction pattern. Then the 22649pattern that appears first in the machine description is the one used. 22650Therefore, more specific patterns (patterns that will match fewer 22651things) and faster instructions (those that will produce better code 22652when they do match) should usually go first in the description. 22653 22654 In some cases the effect of ordering the patterns can be used to hide 22655a pattern when it is not valid. For example, the 68000 has an 22656instruction for converting a fullword to floating point and another for 22657converting a byte to floating point. An instruction converting an 22658integer to floating point could match either one. We put the pattern 22659to convert the fullword first to make sure that one will be used rather 22660than the other. (Otherwise a large integer might be generated as a 22661single-byte immediate quantity, which would not work.) Instead of 22662using this pattern ordering it would be possible to make the pattern 22663for convert-a-byte smart enough to deal properly with any constant 22664value. 22665 22666 22667File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc 22668 2266916.11 Interdependence of Patterns 22670================================= 22671 22672In some cases machines support instructions identical except for the 22673machine mode of one or more operands. For example, there may be 22674"sign-extend halfword" and "sign-extend byte" instructions whose 22675patterns are 22676 22677 (set (match_operand:SI 0 ...) 22678 (extend:SI (match_operand:HI 1 ...))) 22679 22680 (set (match_operand:SI 0 ...) 22681 (extend:SI (match_operand:QI 1 ...))) 22682 22683Constant integers do not specify a machine mode, so an instruction to 22684extend a constant value could match either pattern. The pattern it 22685actually will match is the one that appears first in the file. For 22686correct results, this must be the one for the widest possible mode 22687(`HImode', here). If the pattern matches the `QImode' instruction, the 22688results will be incorrect if the constant value does not actually fit 22689that mode. 22690 22691 Such instructions to extend constants are rarely generated because 22692they are optimized away, but they do occasionally happen in nonoptimized 22693compilations. 22694 22695 If a constraint in a pattern allows a constant, the reload pass may 22696replace a register with a constant permitted by the constraint in some 22697cases. Similarly for memory references. Because of this substitution, 22698you should not provide separate patterns for increment and decrement 22699instructions. Instead, they should be generated from the same pattern 22700that supports register-register add insns by examining the operands and 22701generating the appropriate machine instruction. 22702 22703 22704File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc 22705 2270616.12 Defining Jump Instruction Patterns 22707======================================== 22708 22709GCC does not assume anything about how the machine realizes jumps. The 22710machine description should define a single pattern, usually a 22711`define_expand', which expands to all the required insns. 22712 22713 Usually, this would be a comparison insn to set the condition code and 22714a separate branch insn testing the condition code and branching or not 22715according to its value. For many machines, however, separating 22716compares and branches is limiting, which is why the more flexible 22717approach with one `define_expand' is used in GCC. The machine 22718description becomes clearer for architectures that have 22719compare-and-branch instructions but no condition code. It also works 22720better when different sets of comparison operators are supported by 22721different kinds of conditional branches (e.g. integer vs. 22722floating-point), or by conditional branches with respect to conditional 22723stores. 22724 22725 Two separate insns are always used if the machine description 22726represents a condition code register using the legacy RTL expression 22727`(cc0)', and on most machines that use a separate condition code 22728register (*note Condition Code::). For machines that use `(cc0)', in 22729fact, the set and use of the condition code must be separate and 22730adjacent(1), thus allowing flags in `cc_status' to be used (*note 22731Condition Code::) and so that the comparison and branch insns could be 22732located from each other by using the functions `prev_cc0_setter' and 22733`next_cc0_user'. 22734 22735 Even in this case having a single entry point for conditional branches 22736is advantageous, because it handles equally well the case where a single 22737comparison instruction records the results of both signed and unsigned 22738comparison of the given operands (with the branch insns coming in 22739distinct signed and unsigned flavors) as in the x86 or SPARC, and the 22740case where there are distinct signed and unsigned compare instructions 22741and only one set of conditional branch instructions as in the PowerPC. 22742 22743 ---------- Footnotes ---------- 22744 22745 (1) `note' insns can separate them, though. 22746 22747 22748File: gccint.info, Node: Looping Patterns, Next: Insn Canonicalizations, Prev: Jump Patterns, Up: Machine Desc 22749 2275016.13 Defining Looping Instruction Patterns 22751=========================================== 22752 22753Some machines have special jump instructions that can be utilized to 22754make loops more efficient. A common example is the 68000 `dbra' 22755instruction which performs a decrement of a register and a branch if the 22756result was greater than zero. Other machines, in particular digital 22757signal processors (DSPs), have special block repeat instructions to 22758provide low-overhead loop support. For example, the TI TMS320C3x/C4x 22759DSPs have a block repeat instruction that loads special registers to 22760mark the top and end of a loop and to count the number of loop 22761iterations. This avoids the need for fetching and executing a 22762`dbra'-like instruction and avoids pipeline stalls associated with the 22763jump. 22764 22765 GCC has three special named patterns to support low overhead looping. 22766They are `decrement_and_branch_until_zero', `doloop_begin', and 22767`doloop_end'. The first pattern, `decrement_and_branch_until_zero', is 22768not emitted during RTL generation but may be emitted during the 22769instruction combination phase. This requires the assistance of the 22770loop optimizer, using information collected during strength reduction, 22771to reverse a loop to count down to zero. Some targets also require the 22772loop optimizer to add a `REG_NONNEG' note to indicate that the 22773iteration count is always positive. This is needed if the target 22774performs a signed loop termination test. For example, the 68000 uses a 22775pattern similar to the following for its `dbra' instruction: 22776 22777 (define_insn "decrement_and_branch_until_zero" 22778 [(set (pc) 22779 (if_then_else 22780 (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am") 22781 (const_int -1)) 22782 (const_int 0)) 22783 (label_ref (match_operand 1 "" "")) 22784 (pc))) 22785 (set (match_dup 0) 22786 (plus:SI (match_dup 0) 22787 (const_int -1)))] 22788 "find_reg_note (insn, REG_NONNEG, 0)" 22789 "...") 22790 22791 Note that since the insn is both a jump insn and has an output, it must 22792deal with its own reloads, hence the `m' constraints. Also note that 22793since this insn is generated by the instruction combination phase 22794combining two sequential insns together into an implicit parallel insn, 22795the iteration counter needs to be biased by the same amount as the 22796decrement operation, in this case -1. Note that the following similar 22797pattern will not be matched by the combiner. 22798 22799 (define_insn "decrement_and_branch_until_zero" 22800 [(set (pc) 22801 (if_then_else 22802 (ge (match_operand:SI 0 "general_operand" "+d*am") 22803 (const_int 1)) 22804 (label_ref (match_operand 1 "" "")) 22805 (pc))) 22806 (set (match_dup 0) 22807 (plus:SI (match_dup 0) 22808 (const_int -1)))] 22809 "find_reg_note (insn, REG_NONNEG, 0)" 22810 "...") 22811 22812 The other two special looping patterns, `doloop_begin' and 22813`doloop_end', are emitted by the loop optimizer for certain 22814well-behaved loops with a finite number of loop iterations using 22815information collected during strength reduction. 22816 22817 The `doloop_end' pattern describes the actual looping instruction (or 22818the implicit looping operation) and the `doloop_begin' pattern is an 22819optional companion pattern that can be used for initialization needed 22820for some low-overhead looping instructions. 22821 22822 Note that some machines require the actual looping instruction to be 22823emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting 22824the true RTL for a looping instruction at the top of the loop can cause 22825problems with flow analysis. So instead, a dummy `doloop' insn is 22826emitted at the end of the loop. The machine dependent reorg pass checks 22827for the presence of this `doloop' insn and then searches back to the 22828top of the loop, where it inserts the true looping insn (provided there 22829are no instructions in the loop which would cause problems). Any 22830additional labels can be emitted at this point. In addition, if the 22831desired special iteration counter register was not allocated, this 22832machine dependent reorg pass could emit a traditional compare and jump 22833instruction pair. 22834 22835 The essential difference between the `decrement_and_branch_until_zero' 22836and the `doloop_end' patterns is that the loop optimizer allocates an 22837additional pseudo register for the latter as an iteration counter. 22838This pseudo register cannot be used within the loop (i.e., general 22839induction variables cannot be derived from it), however, in many cases 22840the loop induction variable may become redundant and removed by the 22841flow pass. 22842 22843 22844File: gccint.info, Node: Insn Canonicalizations, Next: Expander Definitions, Prev: Looping Patterns, Up: Machine Desc 22845 2284616.14 Canonicalization of Instructions 22847====================================== 22848 22849There are often cases where multiple RTL expressions could represent an 22850operation performed by a single machine instruction. This situation is 22851most commonly encountered with logical, branch, and multiply-accumulate 22852instructions. In such cases, the compiler attempts to convert these 22853multiple RTL expressions into a single canonical form to reduce the 22854number of insn patterns required. 22855 22856 In addition to algebraic simplifications, following canonicalizations 22857are performed: 22858 22859 * For commutative and comparison operators, a constant is always 22860 made the second operand. If a machine only supports a constant as 22861 the second operand, only patterns that match a constant in the 22862 second operand need be supplied. 22863 22864 * For associative operators, a sequence of operators will always 22865 chain to the left; for instance, only the left operand of an 22866 integer `plus' can itself be a `plus'. `and', `ior', `xor', 22867 `plus', `mult', `smin', `smax', `umin', and `umax' are associative 22868 when applied to integers, and sometimes to floating-point. 22869 22870 * For these operators, if only one operand is a `neg', `not', 22871 `mult', `plus', or `minus' expression, it will be the first 22872 operand. 22873 22874 * In combinations of `neg', `mult', `plus', and `minus', the `neg' 22875 operations (if any) will be moved inside the operations as far as 22876 possible. For instance, `(neg (mult A B))' is canonicalized as 22877 `(mult (neg A) B)', but `(plus (mult (neg B) C) A)' is 22878 canonicalized as `(minus A (mult B C))'. 22879 22880 * For the `compare' operator, a constant is always the second operand 22881 if the first argument is a condition code register or `(cc0)'. 22882 22883 * An operand of `neg', `not', `mult', `plus', or `minus' is made the 22884 first operand under the same conditions as above. 22885 22886 * `(ltu (plus A B) B)' is converted to `(ltu (plus A B) A)'. 22887 Likewise with `geu' instead of `ltu'. 22888 22889 * `(minus X (const_int N))' is converted to `(plus X (const_int 22890 -N))'. 22891 22892 * Within address computations (i.e., inside `mem'), a left shift is 22893 converted into the appropriate multiplication by a power of two. 22894 22895 * De Morgan's Law is used to move bitwise negation inside a bitwise 22896 logical-and or logical-or operation. If this results in only one 22897 operand being a `not' expression, it will be the first one. 22898 22899 A machine that has an instruction that performs a bitwise 22900 logical-and of one operand with the bitwise negation of the other 22901 should specify the pattern for that instruction as 22902 22903 (define_insn "" 22904 [(set (match_operand:M 0 ...) 22905 (and:M (not:M (match_operand:M 1 ...)) 22906 (match_operand:M 2 ...)))] 22907 "..." 22908 "...") 22909 22910 Similarly, a pattern for a "NAND" instruction should be written 22911 22912 (define_insn "" 22913 [(set (match_operand:M 0 ...) 22914 (ior:M (not:M (match_operand:M 1 ...)) 22915 (not:M (match_operand:M 2 ...))))] 22916 "..." 22917 "...") 22918 22919 In both cases, it is not necessary to include patterns for the many 22920 logically equivalent RTL expressions. 22921 22922 * The only possible RTL expressions involving both bitwise 22923 exclusive-or and bitwise negation are `(xor:M X Y)' and `(not:M 22924 (xor:M X Y))'. 22925 22926 * The sum of three items, one of which is a constant, will only 22927 appear in the form 22928 22929 (plus:M (plus:M X Y) CONSTANT) 22930 22931 * Equality comparisons of a group of bits (usually a single bit) 22932 with zero will be written using `zero_extract' rather than the 22933 equivalent `and' or `sign_extract' operations. 22934 22935 22936 Further canonicalization rules are defined in the function 22937`commutative_operand_precedence' in `gcc/rtlanal.c'. 22938 22939 22940File: gccint.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Insn Canonicalizations, Up: Machine Desc 22941 2294216.15 Defining RTL Sequences for Code Generation 22943================================================ 22944 22945On some target machines, some standard pattern names for RTL generation 22946cannot be handled with single insn, but a sequence of RTL insns can 22947represent them. For these target machines, you can write a 22948`define_expand' to specify how to generate the sequence of RTL. 22949 22950 A `define_expand' is an RTL expression that looks almost like a 22951`define_insn'; but, unlike the latter, a `define_expand' is used only 22952for RTL generation and it can produce more than one RTL insn. 22953 22954 A `define_expand' RTX has four operands: 22955 22956 * The name. Each `define_expand' must have a name, since the only 22957 use for it is to refer to it by name. 22958 22959 * The RTL template. This is a vector of RTL expressions representing 22960 a sequence of separate instructions. Unlike `define_insn', there 22961 is no implicit surrounding `PARALLEL'. 22962 22963 * The condition, a string containing a C expression. This 22964 expression is used to express how the availability of this pattern 22965 depends on subclasses of target machine, selected by command-line 22966 options when GCC is run. This is just like the condition of a 22967 `define_insn' that has a standard name. Therefore, the condition 22968 (if present) may not depend on the data in the insn being matched, 22969 but only the target-machine-type flags. The compiler needs to 22970 test these conditions during initialization in order to learn 22971 exactly which named instructions are available in a particular run. 22972 22973 * The preparation statements, a string containing zero or more C 22974 statements which are to be executed before RTL code is generated 22975 from the RTL template. 22976 22977 Usually these statements prepare temporary registers for use as 22978 internal operands in the RTL template, but they can also generate 22979 RTL insns directly by calling routines such as `emit_insn', etc. 22980 Any such insns precede the ones that come from the RTL template. 22981 22982 Every RTL insn emitted by a `define_expand' must match some 22983`define_insn' in the machine description. Otherwise, the compiler will 22984crash when trying to generate code for the insn or trying to optimize 22985it. 22986 22987 The RTL template, in addition to controlling generation of RTL insns, 22988also describes the operands that need to be specified when this pattern 22989is used. In particular, it gives a predicate for each operand. 22990 22991 A true operand, which needs to be specified in order to generate RTL 22992from the pattern, should be described with a `match_operand' in its 22993first occurrence in the RTL template. This enters information on the 22994operand's predicate into the tables that record such things. GCC uses 22995the information to preload the operand into a register if that is 22996required for valid RTL code. If the operand is referred to more than 22997once, subsequent references should use `match_dup'. 22998 22999 The RTL template may also refer to internal "operands" which are 23000temporary registers or labels used only within the sequence made by the 23001`define_expand'. Internal operands are substituted into the RTL 23002template with `match_dup', never with `match_operand'. The values of 23003the internal operands are not passed in as arguments by the compiler 23004when it requests use of this pattern. Instead, they are computed 23005within the pattern, in the preparation statements. These statements 23006compute the values and store them into the appropriate elements of 23007`operands' so that `match_dup' can find them. 23008 23009 There are two special macros defined for use in the preparation 23010statements: `DONE' and `FAIL'. Use them with a following semicolon, as 23011a statement. 23012 23013`DONE' 23014 Use the `DONE' macro to end RTL generation for the pattern. The 23015 only RTL insns resulting from the pattern on this occasion will be 23016 those already emitted by explicit calls to `emit_insn' within the 23017 preparation statements; the RTL template will not be generated. 23018 23019`FAIL' 23020 Make the pattern fail on this occasion. When a pattern fails, it 23021 means that the pattern was not truly available. The calling 23022 routines in the compiler will try other strategies for code 23023 generation using other patterns. 23024 23025 Failure is currently supported only for binary (addition, 23026 multiplication, shifting, etc.) and bit-field (`extv', `extzv', 23027 and `insv') operations. 23028 23029 If the preparation falls through (invokes neither `DONE' nor `FAIL'), 23030then the `define_expand' acts like a `define_insn' in that the RTL 23031template is used to generate the insn. 23032 23033 The RTL template is not used for matching, only for generating the 23034initial insn list. If the preparation statement always invokes `DONE' 23035or `FAIL', the RTL template may be reduced to a simple list of 23036operands, such as this example: 23037 23038 (define_expand "addsi3" 23039 [(match_operand:SI 0 "register_operand" "") 23040 (match_operand:SI 1 "register_operand" "") 23041 (match_operand:SI 2 "register_operand" "")] 23042 "" 23043 " 23044 { 23045 handle_add (operands[0], operands[1], operands[2]); 23046 DONE; 23047 }") 23048 23049 Here is an example, the definition of left-shift for the SPUR chip: 23050 23051 (define_expand "ashlsi3" 23052 [(set (match_operand:SI 0 "register_operand" "") 23053 (ashift:SI 23054 (match_operand:SI 1 "register_operand" "") 23055 (match_operand:SI 2 "nonmemory_operand" "")))] 23056 "" 23057 " 23058 23059 { 23060 if (GET_CODE (operands[2]) != CONST_INT 23061 || (unsigned) INTVAL (operands[2]) > 3) 23062 FAIL; 23063 }") 23064 23065This example uses `define_expand' so that it can generate an RTL insn 23066for shifting when the shift-count is in the supported range of 0 to 3 23067but fail in other cases where machine insns aren't available. When it 23068fails, the compiler tries another strategy using different patterns 23069(such as, a library call). 23070 23071 If the compiler were able to handle nontrivial condition-strings in 23072patterns with names, then it would be possible to use a `define_insn' 23073in that case. Here is another case (zero-extension on the 68000) which 23074makes more use of the power of `define_expand': 23075 23076 (define_expand "zero_extendhisi2" 23077 [(set (match_operand:SI 0 "general_operand" "") 23078 (const_int 0)) 23079 (set (strict_low_part 23080 (subreg:HI 23081 (match_dup 0) 23082 0)) 23083 (match_operand:HI 1 "general_operand" ""))] 23084 "" 23085 "operands[1] = make_safe_from (operands[1], operands[0]);") 23086 23087Here two RTL insns are generated, one to clear the entire output operand 23088and the other to copy the input operand into its low half. This 23089sequence is incorrect if the input operand refers to [the old value of] 23090the output operand, so the preparation statement makes sure this isn't 23091so. The function `make_safe_from' copies the `operands[1]' into a 23092temporary register if it refers to `operands[0]'. It does this by 23093emitting another RTL insn. 23094 23095 Finally, a third example shows the use of an internal operand. 23096Zero-extension on the SPUR chip is done by `and'-ing the result against 23097a halfword mask. But this mask cannot be represented by a `const_int' 23098because the constant value is too large to be legitimate on this 23099machine. So it must be copied into a register with `force_reg' and 23100then the register used in the `and'. 23101 23102 (define_expand "zero_extendhisi2" 23103 [(set (match_operand:SI 0 "register_operand" "") 23104 (and:SI (subreg:SI 23105 (match_operand:HI 1 "register_operand" "") 23106 0) 23107 (match_dup 2)))] 23108 "" 23109 "operands[2] 23110 = force_reg (SImode, GEN_INT (65535)); ") 23111 23112 _Note:_ If the `define_expand' is used to serve a standard binary or 23113unary arithmetic operation or a bit-field operation, then the last insn 23114it generates must not be a `code_label', `barrier' or `note'. It must 23115be an `insn', `jump_insn' or `call_insn'. If you don't need a real insn 23116at the end, emit an insn to copy the result of the operation into 23117itself. Such an insn will generate no code, but it can avoid problems 23118in the compiler. 23119 23120 23121File: gccint.info, Node: Insn Splitting, Next: Including Patterns, Prev: Expander Definitions, Up: Machine Desc 23122 2312316.16 Defining How to Split Instructions 23124======================================== 23125 23126There are two cases where you should specify how to split a pattern 23127into multiple insns. On machines that have instructions requiring 23128delay slots (*note Delay Slots::) or that have instructions whose 23129output is not available for multiple cycles (*note Processor pipeline 23130description::), the compiler phases that optimize these cases need to 23131be able to move insns into one-instruction delay slots. However, some 23132insns may generate more than one machine instruction. These insns 23133cannot be placed into a delay slot. 23134 23135 Often you can rewrite the single insn as a list of individual insns, 23136each corresponding to one machine instruction. The disadvantage of 23137doing so is that it will cause the compilation to be slower and require 23138more space. If the resulting insns are too complex, it may also 23139suppress some optimizations. The compiler splits the insn if there is a 23140reason to believe that it might improve instruction or delay slot 23141scheduling. 23142 23143 The insn combiner phase also splits putative insns. If three insns are 23144merged into one insn with a complex expression that cannot be matched by 23145some `define_insn' pattern, the combiner phase attempts to split the 23146complex pattern into two insns that are recognized. Usually it can 23147break the complex pattern into two patterns by splitting out some 23148subexpression. However, in some other cases, such as performing an 23149addition of a large constant in two insns on a RISC machine, the way to 23150split the addition into two insns is machine-dependent. 23151 23152 The `define_split' definition tells the compiler how to split a 23153complex insn into several simpler insns. It looks like this: 23154 23155 (define_split 23156 [INSN-PATTERN] 23157 "CONDITION" 23158 [NEW-INSN-PATTERN-1 23159 NEW-INSN-PATTERN-2 23160 ...] 23161 "PREPARATION-STATEMENTS") 23162 23163 INSN-PATTERN is a pattern that needs to be split and CONDITION is the 23164final condition to be tested, as in a `define_insn'. When an insn 23165matching INSN-PATTERN and satisfying CONDITION is found, it is replaced 23166in the insn list with the insns given by NEW-INSN-PATTERN-1, 23167NEW-INSN-PATTERN-2, etc. 23168 23169 The PREPARATION-STATEMENTS are similar to those statements that are 23170specified for `define_expand' (*note Expander Definitions::) and are 23171executed before the new RTL is generated to prepare for the generated 23172code or emit some insns whose pattern is not fixed. Unlike those in 23173`define_expand', however, these statements must not generate any new 23174pseudo-registers. Once reload has completed, they also must not 23175allocate any space in the stack frame. 23176 23177 Patterns are matched against INSN-PATTERN in two different 23178circumstances. If an insn needs to be split for delay slot scheduling 23179or insn scheduling, the insn is already known to be valid, which means 23180that it must have been matched by some `define_insn' and, if 23181`reload_completed' is nonzero, is known to satisfy the constraints of 23182that `define_insn'. In that case, the new insn patterns must also be 23183insns that are matched by some `define_insn' and, if `reload_completed' 23184is nonzero, must also satisfy the constraints of those definitions. 23185 23186 As an example of this usage of `define_split', consider the following 23187example from `a29k.md', which splits a `sign_extend' from `HImode' to 23188`SImode' into a pair of shift insns: 23189 23190 (define_split 23191 [(set (match_operand:SI 0 "gen_reg_operand" "") 23192 (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] 23193 "" 23194 [(set (match_dup 0) 23195 (ashift:SI (match_dup 1) 23196 (const_int 16))) 23197 (set (match_dup 0) 23198 (ashiftrt:SI (match_dup 0) 23199 (const_int 16)))] 23200 " 23201 { operands[1] = gen_lowpart (SImode, operands[1]); }") 23202 23203 When the combiner phase tries to split an insn pattern, it is always 23204the case that the pattern is _not_ matched by any `define_insn'. The 23205combiner pass first tries to split a single `set' expression and then 23206the same `set' expression inside a `parallel', but followed by a 23207`clobber' of a pseudo-reg to use as a scratch register. In these 23208cases, the combiner expects exactly two new insn patterns to be 23209generated. It will verify that these patterns match some `define_insn' 23210definitions, so you need not do this test in the `define_split' (of 23211course, there is no point in writing a `define_split' that will never 23212produce insns that match). 23213 23214 Here is an example of this use of `define_split', taken from 23215`rs6000.md': 23216 23217 (define_split 23218 [(set (match_operand:SI 0 "gen_reg_operand" "") 23219 (plus:SI (match_operand:SI 1 "gen_reg_operand" "") 23220 (match_operand:SI 2 "non_add_cint_operand" "")))] 23221 "" 23222 [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3))) 23223 (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))] 23224 " 23225 { 23226 int low = INTVAL (operands[2]) & 0xffff; 23227 int high = (unsigned) INTVAL (operands[2]) >> 16; 23228 23229 if (low & 0x8000) 23230 high++, low |= 0xffff0000; 23231 23232 operands[3] = GEN_INT (high << 16); 23233 operands[4] = GEN_INT (low); 23234 }") 23235 23236 Here the predicate `non_add_cint_operand' matches any `const_int' that 23237is _not_ a valid operand of a single add insn. The add with the 23238smaller displacement is written so that it can be substituted into the 23239address of a subsequent operation. 23240 23241 An example that uses a scratch register, from the same file, generates 23242an equality comparison of a register and a large constant: 23243 23244 (define_split 23245 [(set (match_operand:CC 0 "cc_reg_operand" "") 23246 (compare:CC (match_operand:SI 1 "gen_reg_operand" "") 23247 (match_operand:SI 2 "non_short_cint_operand" ""))) 23248 (clobber (match_operand:SI 3 "gen_reg_operand" ""))] 23249 "find_single_use (operands[0], insn, 0) 23250 && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ 23251 || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)" 23252 [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4))) 23253 (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))] 23254 " 23255 { 23256 /* Get the constant we are comparing against, C, and see what it 23257 looks like sign-extended to 16 bits. Then see what constant 23258 could be XOR'ed with C to get the sign-extended value. */ 23259 23260 int c = INTVAL (operands[2]); 23261 int sextc = (c << 16) >> 16; 23262 int xorv = c ^ sextc; 23263 23264 operands[4] = GEN_INT (xorv); 23265 operands[5] = GEN_INT (sextc); 23266 }") 23267 23268 To avoid confusion, don't write a single `define_split' that accepts 23269some insns that match some `define_insn' as well as some insns that 23270don't. Instead, write two separate `define_split' definitions, one for 23271the insns that are valid and one for the insns that are not valid. 23272 23273 The splitter is allowed to split jump instructions into sequence of 23274jumps or create new jumps in while splitting non-jump instructions. As 23275the central flowgraph and branch prediction information needs to be 23276updated, several restriction apply. 23277 23278 Splitting of jump instruction into sequence that over by another jump 23279instruction is always valid, as compiler expect identical behavior of 23280new jump. When new sequence contains multiple jump instructions or new 23281labels, more assistance is needed. Splitter is required to create only 23282unconditional jumps, or simple conditional jump instructions. 23283Additionally it must attach a `REG_BR_PROB' note to each conditional 23284jump. A global variable `split_branch_probability' holds the 23285probability of the original branch in case it was a simple conditional 23286jump, -1 otherwise. To simplify recomputing of edge frequencies, the 23287new sequence is required to have only forward jumps to the newly 23288created labels. 23289 23290 For the common case where the pattern of a define_split exactly 23291matches the pattern of a define_insn, use `define_insn_and_split'. It 23292looks like this: 23293 23294 (define_insn_and_split 23295 [INSN-PATTERN] 23296 "CONDITION" 23297 "OUTPUT-TEMPLATE" 23298 "SPLIT-CONDITION" 23299 [NEW-INSN-PATTERN-1 23300 NEW-INSN-PATTERN-2 23301 ...] 23302 "PREPARATION-STATEMENTS" 23303 [INSN-ATTRIBUTES]) 23304 23305 INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used 23306as in `define_insn'. The NEW-INSN-PATTERN vector and the 23307PREPARATION-STATEMENTS are used as in a `define_split'. The 23308SPLIT-CONDITION is also used as in `define_split', with the additional 23309behavior that if the condition starts with `&&', the condition used for 23310the split will be the constructed as a logical "and" of the split 23311condition with the insn condition. For example, from i386.md: 23312 23313 (define_insn_and_split "zero_extendhisi2_and" 23314 [(set (match_operand:SI 0 "register_operand" "=r") 23315 (zero_extend:SI (match_operand:HI 1 "register_operand" "0"))) 23316 (clobber (reg:CC 17))] 23317 "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size" 23318 "#" 23319 "&& reload_completed" 23320 [(parallel [(set (match_dup 0) 23321 (and:SI (match_dup 0) (const_int 65535))) 23322 (clobber (reg:CC 17))])] 23323 "" 23324 [(set_attr "type" "alu1")]) 23325 23326 In this case, the actual split condition will be 23327`TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'. 23328 23329 The `define_insn_and_split' construction provides exactly the same 23330functionality as two separate `define_insn' and `define_split' 23331patterns. It exists for compactness, and as a maintenance tool to 23332prevent having to ensure the two patterns' templates match. 23333 23334 23335File: gccint.info, Node: Including Patterns, Next: Peephole Definitions, Prev: Insn Splitting, Up: Machine Desc 23336 2333716.17 Including Patterns in Machine Descriptions. 23338================================================= 23339 23340The `include' pattern tells the compiler tools where to look for 23341patterns that are in files other than in the file `.md'. This is used 23342only at build time and there is no preprocessing allowed. 23343 23344 It looks like: 23345 23346 23347 (include 23348 PATHNAME) 23349 23350 For example: 23351 23352 23353 (include "filestuff") 23354 23355 Where PATHNAME is a string that specifies the location of the file, 23356specifies the include file to be in `gcc/config/target/filestuff'. The 23357directory `gcc/config/target' is regarded as the default directory. 23358 23359 Machine descriptions may be split up into smaller more manageable 23360subsections and placed into subdirectories. 23361 23362 By specifying: 23363 23364 23365 (include "BOGUS/filestuff") 23366 23367 the include file is specified to be in 23368`gcc/config/TARGET/BOGUS/filestuff'. 23369 23370 Specifying an absolute path for the include file such as; 23371 23372 (include "/u2/BOGUS/filestuff") 23373 is permitted but is not encouraged. 23374 2337516.17.1 RTL Generation Tool Options for Directory Search 23376-------------------------------------------------------- 23377 23378The `-IDIR' option specifies directories to search for machine 23379descriptions. For example: 23380 23381 23382 genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md 23383 23384 Add the directory DIR to the head of the list of directories to be 23385searched for header files. This can be used to override a system 23386machine definition file, substituting your own version, since these 23387directories are searched before the default machine description file 23388directories. If you use more than one `-I' option, the directories are 23389scanned in left-to-right order; the standard default directory come 23390after. 23391 23392 23393File: gccint.info, Node: Peephole Definitions, Next: Insn Attributes, Prev: Including Patterns, Up: Machine Desc 23394 2339516.18 Machine-Specific Peephole Optimizers 23396========================================== 23397 23398In addition to instruction patterns the `md' file may contain 23399definitions of machine-specific peephole optimizations. 23400 23401 The combiner does not notice certain peephole optimizations when the 23402data flow in the program does not suggest that it should try them. For 23403example, sometimes two consecutive insns related in purpose can be 23404combined even though the second one does not appear to use a register 23405computed in the first one. A machine-specific peephole optimizer can 23406detect such opportunities. 23407 23408 There are two forms of peephole definitions that may be used. The 23409original `define_peephole' is run at assembly output time to match 23410insns and substitute assembly text. Use of `define_peephole' is 23411deprecated. 23412 23413 A newer `define_peephole2' matches insns and substitutes new insns. 23414The `peephole2' pass is run after register allocation but before 23415scheduling, which may result in much better code for targets that do 23416scheduling. 23417 23418* Menu: 23419 23420* define_peephole:: RTL to Text Peephole Optimizers 23421* define_peephole2:: RTL to RTL Peephole Optimizers 23422 23423 23424File: gccint.info, Node: define_peephole, Next: define_peephole2, Up: Peephole Definitions 23425 2342616.18.1 RTL to Text Peephole Optimizers 23427--------------------------------------- 23428 23429A definition looks like this: 23430 23431 (define_peephole 23432 [INSN-PATTERN-1 23433 INSN-PATTERN-2 23434 ...] 23435 "CONDITION" 23436 "TEMPLATE" 23437 "OPTIONAL-INSN-ATTRIBUTES") 23438 23439The last string operand may be omitted if you are not using any 23440machine-specific information in this machine description. If present, 23441it must obey the same rules as in a `define_insn'. 23442 23443 In this skeleton, INSN-PATTERN-1 and so on are patterns to match 23444consecutive insns. The optimization applies to a sequence of insns when 23445INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next, 23446and so on. 23447 23448 Each of the insns matched by a peephole must also match a 23449`define_insn'. Peepholes are checked only at the last stage just 23450before code generation, and only optionally. Therefore, any insn which 23451would match a peephole but no `define_insn' will cause a crash in code 23452generation in an unoptimized compilation, or at various optimization 23453stages. 23454 23455 The operands of the insns are matched with `match_operands', 23456`match_operator', and `match_dup', as usual. What is not usual is that 23457the operand numbers apply to all the insn patterns in the definition. 23458So, you can check for identical operands in two insns by using 23459`match_operand' in one insn and `match_dup' in the other. 23460 23461 The operand constraints used in `match_operand' patterns do not have 23462any direct effect on the applicability of the peephole, but they will 23463be validated afterward, so make sure your constraints are general enough 23464to apply whenever the peephole matches. If the peephole matches but 23465the constraints are not satisfied, the compiler will crash. 23466 23467 It is safe to omit constraints in all the operands of the peephole; or 23468you can write constraints which serve as a double-check on the criteria 23469previously tested. 23470 23471 Once a sequence of insns matches the patterns, the CONDITION is 23472checked. This is a C expression which makes the final decision whether 23473to perform the optimization (we do so if the expression is nonzero). If 23474CONDITION is omitted (in other words, the string is empty) then the 23475optimization is applied to every sequence of insns that matches the 23476patterns. 23477 23478 The defined peephole optimizations are applied after register 23479allocation is complete. Therefore, the peephole definition can check 23480which operands have ended up in which kinds of registers, just by 23481looking at the operands. 23482 23483 The way to refer to the operands in CONDITION is to write 23484`operands[I]' for operand number I (as matched by `(match_operand I 23485...)'). Use the variable `insn' to refer to the last of the insns 23486being matched; use `prev_active_insn' to find the preceding insns. 23487 23488 When optimizing computations with intermediate results, you can use 23489CONDITION to match only when the intermediate results are not used 23490elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where INSN 23491is the insn in which you expect the value to be used for the last time 23492(from the value of `insn', together with use of `prev_nonnote_insn'), 23493and OP is the intermediate value (from `operands[I]'). 23494 23495 Applying the optimization means replacing the sequence of insns with 23496one new insn. The TEMPLATE controls ultimate output of assembler code 23497for this combined insn. It works exactly like the template of a 23498`define_insn'. Operand numbers in this template are the same ones used 23499in matching the original sequence of insns. 23500 23501 The result of a defined peephole optimizer does not need to match any 23502of the insn patterns in the machine description; it does not even have 23503an opportunity to match them. The peephole optimizer definition itself 23504serves as the insn pattern to control how the insn is output. 23505 23506 Defined peephole optimizers are run as assembler code is being output, 23507so the insns they produce are never combined or rearranged in any way. 23508 23509 Here is an example, taken from the 68000 machine description: 23510 23511 (define_peephole 23512 [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) 23513 (set (match_operand:DF 0 "register_operand" "=f") 23514 (match_operand:DF 1 "register_operand" "ad"))] 23515 "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" 23516 { 23517 rtx xoperands[2]; 23518 xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1); 23519 #ifdef MOTOROLA 23520 output_asm_insn ("move.l %1,(sp)", xoperands); 23521 output_asm_insn ("move.l %1,-(sp)", operands); 23522 return "fmove.d (sp)+,%0"; 23523 #else 23524 output_asm_insn ("movel %1,sp@", xoperands); 23525 output_asm_insn ("movel %1,sp@-", operands); 23526 return "fmoved sp@+,%0"; 23527 #endif 23528 }) 23529 23530 The effect of this optimization is to change 23531 23532 jbsr _foobar 23533 addql #4,sp 23534 movel d1,sp@- 23535 movel d0,sp@- 23536 fmoved sp@+,fp0 23537 23538into 23539 23540 jbsr _foobar 23541 movel d1,sp@ 23542 movel d0,sp@- 23543 fmoved sp@+,fp0 23544 23545 INSN-PATTERN-1 and so on look _almost_ like the second operand of 23546`define_insn'. There is one important difference: the second operand 23547of `define_insn' consists of one or more RTX's enclosed in square 23548brackets. Usually, there is only one: then the same action can be 23549written as an element of a `define_peephole'. But when there are 23550multiple actions in a `define_insn', they are implicitly enclosed in a 23551`parallel'. Then you must explicitly write the `parallel', and the 23552square brackets within it, in the `define_peephole'. Thus, if an insn 23553pattern looks like this, 23554 23555 (define_insn "divmodsi4" 23556 [(set (match_operand:SI 0 "general_operand" "=d") 23557 (div:SI (match_operand:SI 1 "general_operand" "0") 23558 (match_operand:SI 2 "general_operand" "dmsK"))) 23559 (set (match_operand:SI 3 "general_operand" "=d") 23560 (mod:SI (match_dup 1) (match_dup 2)))] 23561 "TARGET_68020" 23562 "divsl%.l %2,%3:%0") 23563 23564then the way to mention this insn in a peephole is as follows: 23565 23566 (define_peephole 23567 [... 23568 (parallel 23569 [(set (match_operand:SI 0 "general_operand" "=d") 23570 (div:SI (match_operand:SI 1 "general_operand" "0") 23571 (match_operand:SI 2 "general_operand" "dmsK"))) 23572 (set (match_operand:SI 3 "general_operand" "=d") 23573 (mod:SI (match_dup 1) (match_dup 2)))]) 23574 ...] 23575 ...) 23576 23577 23578File: gccint.info, Node: define_peephole2, Prev: define_peephole, Up: Peephole Definitions 23579 2358016.18.2 RTL to RTL Peephole Optimizers 23581-------------------------------------- 23582 23583The `define_peephole2' definition tells the compiler how to substitute 23584one sequence of instructions for another sequence, what additional 23585scratch registers may be needed and what their lifetimes must be. 23586 23587 (define_peephole2 23588 [INSN-PATTERN-1 23589 INSN-PATTERN-2 23590 ...] 23591 "CONDITION" 23592 [NEW-INSN-PATTERN-1 23593 NEW-INSN-PATTERN-2 23594 ...] 23595 "PREPARATION-STATEMENTS") 23596 23597 The definition is almost identical to `define_split' (*note Insn 23598Splitting::) except that the pattern to match is not a single 23599instruction, but a sequence of instructions. 23600 23601 It is possible to request additional scratch registers for use in the 23602output template. If appropriate registers are not free, the pattern 23603will simply not match. 23604 23605 Scratch registers are requested with a `match_scratch' pattern at the 23606top level of the input pattern. The allocated register (initially) will 23607be dead at the point requested within the original sequence. If the 23608scratch is used at more than a single point, a `match_dup' pattern at 23609the top level of the input pattern marks the last position in the input 23610sequence at which the register must be available. 23611 23612 Here is an example from the IA-32 machine description: 23613 23614 (define_peephole2 23615 [(match_scratch:SI 2 "r") 23616 (parallel [(set (match_operand:SI 0 "register_operand" "") 23617 (match_operator:SI 3 "arith_or_logical_operator" 23618 [(match_dup 0) 23619 (match_operand:SI 1 "memory_operand" "")])) 23620 (clobber (reg:CC 17))])] 23621 "! optimize_size && ! TARGET_READ_MODIFY" 23622 [(set (match_dup 2) (match_dup 1)) 23623 (parallel [(set (match_dup 0) 23624 (match_op_dup 3 [(match_dup 0) (match_dup 2)])) 23625 (clobber (reg:CC 17))])] 23626 "") 23627 23628This pattern tries to split a load from its use in the hopes that we'll 23629be able to schedule around the memory load latency. It allocates a 23630single `SImode' register of class `GENERAL_REGS' (`"r"') that needs to 23631be live only at the point just before the arithmetic. 23632 23633 A real example requiring extended scratch lifetimes is harder to come 23634by, so here's a silly made-up example: 23635 23636 (define_peephole2 23637 [(match_scratch:SI 4 "r") 23638 (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" "")) 23639 (set (match_operand:SI 2 "" "") (match_dup 1)) 23640 (match_dup 4) 23641 (set (match_operand:SI 3 "" "") (match_dup 1))] 23642 "/* determine 1 does not overlap 0 and 2 */" 23643 [(set (match_dup 4) (match_dup 1)) 23644 (set (match_dup 0) (match_dup 4)) 23645 (set (match_dup 2) (match_dup 4))] 23646 (set (match_dup 3) (match_dup 4))] 23647 "") 23648 23649If we had not added the `(match_dup 4)' in the middle of the input 23650sequence, it might have been the case that the register we chose at the 23651beginning of the sequence is killed by the first or second `set'. 23652 23653 23654File: gccint.info, Node: Insn Attributes, Next: Conditional Execution, Prev: Peephole Definitions, Up: Machine Desc 23655 2365616.19 Instruction Attributes 23657============================ 23658 23659In addition to describing the instruction supported by the target 23660machine, the `md' file also defines a group of "attributes" and a set of 23661values for each. Every generated insn is assigned a value for each 23662attribute. One possible attribute would be the effect that the insn 23663has on the machine's condition code. This attribute can then be used 23664by `NOTICE_UPDATE_CC' to track the condition codes. 23665 23666* Menu: 23667 23668* Defining Attributes:: Specifying attributes and their values. 23669* Expressions:: Valid expressions for attribute values. 23670* Tagging Insns:: Assigning attribute values to insns. 23671* Attr Example:: An example of assigning attributes. 23672* Insn Lengths:: Computing the length of insns. 23673* Constant Attributes:: Defining attributes that are constant. 23674* Delay Slots:: Defining delay slots required for a machine. 23675* Processor pipeline description:: Specifying information for insn scheduling. 23676 23677 23678File: gccint.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes 23679 2368016.19.1 Defining Attributes and their Values 23681-------------------------------------------- 23682 23683The `define_attr' expression is used to define each attribute required 23684by the target machine. It looks like: 23685 23686 (define_attr NAME LIST-OF-VALUES DEFAULT) 23687 23688 NAME is a string specifying the name of the attribute being defined. 23689 23690 LIST-OF-VALUES is either a string that specifies a comma-separated 23691list of values that can be assigned to the attribute, or a null string 23692to indicate that the attribute takes numeric values. 23693 23694 DEFAULT is an attribute expression that gives the value of this 23695attribute for insns that match patterns whose definition does not 23696include an explicit value for this attribute. *Note Attr Example::, 23697for more information on the handling of defaults. *Note Constant 23698Attributes::, for information on attributes that do not depend on any 23699particular insn. 23700 23701 For each defined attribute, a number of definitions are written to the 23702`insn-attr.h' file. For cases where an explicit set of values is 23703specified for an attribute, the following are defined: 23704 23705 * A `#define' is written for the symbol `HAVE_ATTR_NAME'. 23706 23707 * An enumerated class is defined for `attr_NAME' with elements of 23708 the form `UPPER-NAME_UPPER-VALUE' where the attribute name and 23709 value are first converted to uppercase. 23710 23711 * A function `get_attr_NAME' is defined that is passed an insn and 23712 returns the attribute value for that insn. 23713 23714 For example, if the following is present in the `md' file: 23715 23716 (define_attr "type" "branch,fp,load,store,arith" ...) 23717 23718the following lines will be written to the file `insn-attr.h'. 23719 23720 #define HAVE_ATTR_type 23721 enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, 23722 TYPE_STORE, TYPE_ARITH}; 23723 extern enum attr_type get_attr_type (); 23724 23725 If the attribute takes numeric values, no `enum' type will be defined 23726and the function to obtain the attribute's value will return `int'. 23727 23728 There are attributes which are tied to a specific meaning. These 23729attributes are not free to use for other purposes: 23730 23731`length' 23732 The `length' attribute is used to calculate the length of emitted 23733 code chunks. This is especially important when verifying branch 23734 distances. *Note Insn Lengths::. 23735 23736`enabled' 23737 The `enabled' attribute can be defined to prevent certain 23738 alternatives of an insn definition from being used during code 23739 generation. *Note Disable Insn Alternatives::. 23740 23741 23742 23743File: gccint.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes 23744 2374516.19.2 Attribute Expressions 23746----------------------------- 23747 23748RTL expressions used to define attributes use the codes described above 23749plus a few specific to attribute definitions, to be discussed below. 23750Attribute value expressions must have one of the following forms: 23751 23752`(const_int I)' 23753 The integer I specifies the value of a numeric attribute. I must 23754 be non-negative. 23755 23756 The value of a numeric attribute can be specified either with a 23757 `const_int', or as an integer represented as a string in 23758 `const_string', `eq_attr' (see below), `attr', `symbol_ref', 23759 simple arithmetic expressions, and `set_attr' overrides on 23760 specific instructions (*note Tagging Insns::). 23761 23762`(const_string VALUE)' 23763 The string VALUE specifies a constant attribute value. If VALUE 23764 is specified as `"*"', it means that the default value of the 23765 attribute is to be used for the insn containing this expression. 23766 `"*"' obviously cannot be used in the DEFAULT expression of a 23767 `define_attr'. 23768 23769 If the attribute whose value is being specified is numeric, VALUE 23770 must be a string containing a non-negative integer (normally 23771 `const_int' would be used in this case). Otherwise, it must 23772 contain one of the valid values for the attribute. 23773 23774`(if_then_else TEST TRUE-VALUE FALSE-VALUE)' 23775 TEST specifies an attribute test, whose format is defined below. 23776 The value of this expression is TRUE-VALUE if TEST is true, 23777 otherwise it is FALSE-VALUE. 23778 23779`(cond [TEST1 VALUE1 ...] DEFAULT)' 23780 The first operand of this expression is a vector containing an even 23781 number of expressions and consisting of pairs of TEST and VALUE 23782 expressions. The value of the `cond' expression is that of the 23783 VALUE corresponding to the first true TEST expression. If none of 23784 the TEST expressions are true, the value of the `cond' expression 23785 is that of the DEFAULT expression. 23786 23787 TEST expressions can have one of the following forms: 23788 23789`(const_int I)' 23790 This test is true if I is nonzero and false otherwise. 23791 23792`(not TEST)' 23793`(ior TEST1 TEST2)' 23794`(and TEST1 TEST2)' 23795 These tests are true if the indicated logical function is true. 23796 23797`(match_operand:M N PRED CONSTRAINTS)' 23798 This test is true if operand N of the insn whose attribute value 23799 is being determined has mode M (this part of the test is ignored 23800 if M is `VOIDmode') and the function specified by the string PRED 23801 returns a nonzero value when passed operand N and mode M (this 23802 part of the test is ignored if PRED is the null string). 23803 23804 The CONSTRAINTS operand is ignored and should be the null string. 23805 23806`(le ARITH1 ARITH2)' 23807`(leu ARITH1 ARITH2)' 23808`(lt ARITH1 ARITH2)' 23809`(ltu ARITH1 ARITH2)' 23810`(gt ARITH1 ARITH2)' 23811`(gtu ARITH1 ARITH2)' 23812`(ge ARITH1 ARITH2)' 23813`(geu ARITH1 ARITH2)' 23814`(ne ARITH1 ARITH2)' 23815`(eq ARITH1 ARITH2)' 23816 These tests are true if the indicated comparison of the two 23817 arithmetic expressions is true. Arithmetic expressions are formed 23818 with `plus', `minus', `mult', `div', `mod', `abs', `neg', `and', 23819 `ior', `xor', `not', `ashift', `lshiftrt', and `ashiftrt' 23820 expressions. 23821 23822 `const_int' and `symbol_ref' are always valid terms (*note Insn 23823 Lengths::,for additional forms). `symbol_ref' is a string 23824 denoting a C expression that yields an `int' when evaluated by the 23825 `get_attr_...' routine. It should normally be a global variable. 23826 23827`(eq_attr NAME VALUE)' 23828 NAME is a string specifying the name of an attribute. 23829 23830 VALUE is a string that is either a valid value for attribute NAME, 23831 a comma-separated list of values, or `!' followed by a value or 23832 list. If VALUE does not begin with a `!', this test is true if 23833 the value of the NAME attribute of the current insn is in the list 23834 specified by VALUE. If VALUE begins with a `!', this test is true 23835 if the attribute's value is _not_ in the specified list. 23836 23837 For example, 23838 23839 (eq_attr "type" "load,store") 23840 23841 is equivalent to 23842 23843 (ior (eq_attr "type" "load") (eq_attr "type" "store")) 23844 23845 If NAME specifies an attribute of `alternative', it refers to the 23846 value of the compiler variable `which_alternative' (*note Output 23847 Statement::) and the values must be small integers. For example, 23848 23849 (eq_attr "alternative" "2,3") 23850 23851 is equivalent to 23852 23853 (ior (eq (symbol_ref "which_alternative") (const_int 2)) 23854 (eq (symbol_ref "which_alternative") (const_int 3))) 23855 23856 Note that, for most attributes, an `eq_attr' test is simplified in 23857 cases where the value of the attribute being tested is known for 23858 all insns matching a particular pattern. This is by far the most 23859 common case. 23860 23861`(attr_flag NAME)' 23862 The value of an `attr_flag' expression is true if the flag 23863 specified by NAME is true for the `insn' currently being scheduled. 23864 23865 NAME is a string specifying one of a fixed set of flags to test. 23866 Test the flags `forward' and `backward' to determine the direction 23867 of a conditional branch. Test the flags `very_likely', `likely', 23868 `very_unlikely', and `unlikely' to determine if a conditional 23869 branch is expected to be taken. 23870 23871 If the `very_likely' flag is true, then the `likely' flag is also 23872 true. Likewise for the `very_unlikely' and `unlikely' flags. 23873 23874 This example describes a conditional branch delay slot which can 23875 be nullified for forward branches that are taken (annul-true) or 23876 for backward branches which are not taken (annul-false). 23877 23878 (define_delay (eq_attr "type" "cbranch") 23879 [(eq_attr "in_branch_delay" "true") 23880 (and (eq_attr "in_branch_delay" "true") 23881 (attr_flag "forward")) 23882 (and (eq_attr "in_branch_delay" "true") 23883 (attr_flag "backward"))]) 23884 23885 The `forward' and `backward' flags are false if the current `insn' 23886 being scheduled is not a conditional branch. 23887 23888 The `very_likely' and `likely' flags are true if the `insn' being 23889 scheduled is not a conditional branch. The `very_unlikely' and 23890 `unlikely' flags are false if the `insn' being scheduled is not a 23891 conditional branch. 23892 23893 `attr_flag' is only used during delay slot scheduling and has no 23894 meaning to other passes of the compiler. 23895 23896`(attr NAME)' 23897 The value of another attribute is returned. This is most useful 23898 for numeric attributes, as `eq_attr' and `attr_flag' produce more 23899 efficient code for non-numeric attributes. 23900 23901 23902File: gccint.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes 23903 2390416.19.3 Assigning Attribute Values to Insns 23905------------------------------------------- 23906 23907The value assigned to an attribute of an insn is primarily determined by 23908which pattern is matched by that insn (or which `define_peephole' 23909generated it). Every `define_insn' and `define_peephole' can have an 23910optional last argument to specify the values of attributes for matching 23911insns. The value of any attribute not specified in a particular insn 23912is set to the default value for that attribute, as specified in its 23913`define_attr'. Extensive use of default values for attributes permits 23914the specification of the values for only one or two attributes in the 23915definition of most insn patterns, as seen in the example in the next 23916section. 23917 23918 The optional last argument of `define_insn' and `define_peephole' is a 23919vector of expressions, each of which defines the value for a single 23920attribute. The most general way of assigning an attribute's value is 23921to use a `set' expression whose first operand is an `attr' expression 23922giving the name of the attribute being set. The second operand of the 23923`set' is an attribute expression (*note Expressions::) giving the value 23924of the attribute. 23925 23926 When the attribute value depends on the `alternative' attribute (i.e., 23927which is the applicable alternative in the constraint of the insn), the 23928`set_attr_alternative' expression can be used. It allows the 23929specification of a vector of attribute expressions, one for each 23930alternative. 23931 23932 When the generality of arbitrary attribute expressions is not required, 23933the simpler `set_attr' expression can be used, which allows specifying 23934a string giving either a single attribute value or a list of attribute 23935values, one for each alternative. 23936 23937 The form of each of the above specifications is shown below. In each 23938case, NAME is a string specifying the attribute to be set. 23939 23940`(set_attr NAME VALUE-STRING)' 23941 VALUE-STRING is either a string giving the desired attribute value, 23942 or a string containing a comma-separated list giving the values for 23943 succeeding alternatives. The number of elements must match the 23944 number of alternatives in the constraint of the insn pattern. 23945 23946 Note that it may be useful to specify `*' for some alternative, in 23947 which case the attribute will assume its default value for insns 23948 matching that alternative. 23949 23950`(set_attr_alternative NAME [VALUE1 VALUE2 ...])' 23951 Depending on the alternative of the insn, the value will be one of 23952 the specified values. This is a shorthand for using a `cond' with 23953 tests on the `alternative' attribute. 23954 23955`(set (attr NAME) VALUE)' 23956 The first operand of this `set' must be the special RTL expression 23957 `attr', whose sole operand is a string giving the name of the 23958 attribute being set. VALUE is the value of the attribute. 23959 23960 The following shows three different ways of representing the same 23961attribute value specification: 23962 23963 (set_attr "type" "load,store,arith") 23964 23965 (set_attr_alternative "type" 23966 [(const_string "load") (const_string "store") 23967 (const_string "arith")]) 23968 23969 (set (attr "type") 23970 (cond [(eq_attr "alternative" "1") (const_string "load") 23971 (eq_attr "alternative" "2") (const_string "store")] 23972 (const_string "arith"))) 23973 23974 The `define_asm_attributes' expression provides a mechanism to specify 23975the attributes assigned to insns produced from an `asm' statement. It 23976has the form: 23977 23978 (define_asm_attributes [ATTR-SETS]) 23979 23980where ATTR-SETS is specified the same as for both the `define_insn' and 23981the `define_peephole' expressions. 23982 23983 These values will typically be the "worst case" attribute values. For 23984example, they might indicate that the condition code will be clobbered. 23985 23986 A specification for a `length' attribute is handled specially. The 23987way to compute the length of an `asm' insn is to multiply the length 23988specified in the expression `define_asm_attributes' by the number of 23989machine instructions specified in the `asm' statement, determined by 23990counting the number of semicolons and newlines in the string. 23991Therefore, the value of the `length' attribute specified in a 23992`define_asm_attributes' should be the maximum possible length of a 23993single machine instruction. 23994 23995 23996File: gccint.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes 23997 2399816.19.4 Example of Attribute Specifications 23999------------------------------------------- 24000 24001The judicious use of defaulting is important in the efficient use of 24002insn attributes. Typically, insns are divided into "types" and an 24003attribute, customarily called `type', is used to represent this value. 24004This attribute is normally used only to define the default value for 24005other attributes. An example will clarify this usage. 24006 24007 Assume we have a RISC machine with a condition code and in which only 24008full-word operations are performed in registers. Let us assume that we 24009can divide all insns into loads, stores, (integer) arithmetic 24010operations, floating point operations, and branches. 24011 24012 Here we will concern ourselves with determining the effect of an insn 24013on the condition code and will limit ourselves to the following possible 24014effects: The condition code can be set unpredictably (clobbered), not 24015be changed, be set to agree with the results of the operation, or only 24016changed if the item previously set into the condition code has been 24017modified. 24018 24019 Here is part of a sample `md' file for such a machine: 24020 24021 (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) 24022 24023 (define_attr "cc" "clobber,unchanged,set,change0" 24024 (cond [(eq_attr "type" "load") 24025 (const_string "change0") 24026 (eq_attr "type" "store,branch") 24027 (const_string "unchanged") 24028 (eq_attr "type" "arith") 24029 (if_then_else (match_operand:SI 0 "" "") 24030 (const_string "set") 24031 (const_string "clobber"))] 24032 (const_string "clobber"))) 24033 24034 (define_insn "" 24035 [(set (match_operand:SI 0 "general_operand" "=r,r,m") 24036 (match_operand:SI 1 "general_operand" "r,m,r"))] 24037 "" 24038 "@ 24039 move %0,%1 24040 load %0,%1 24041 store %0,%1" 24042 [(set_attr "type" "arith,load,store")]) 24043 24044 Note that we assume in the above example that arithmetic operations 24045performed on quantities smaller than a machine word clobber the 24046condition code since they will set the condition code to a value 24047corresponding to the full-word result. 24048 24049 24050File: gccint.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes 24051 2405216.19.5 Computing the Length of an Insn 24053--------------------------------------- 24054 24055For many machines, multiple types of branch instructions are provided, 24056each for different length branch displacements. In most cases, the 24057assembler will choose the correct instruction to use. However, when 24058the assembler cannot do so, GCC can when a special attribute, the 24059`length' attribute, is defined. This attribute must be defined to have 24060numeric values by specifying a null string in its `define_attr'. 24061 24062 In the case of the `length' attribute, two additional forms of 24063arithmetic terms are allowed in test expressions: 24064 24065`(match_dup N)' 24066 This refers to the address of operand N of the current insn, which 24067 must be a `label_ref'. 24068 24069`(pc)' 24070 This refers to the address of the _current_ insn. It might have 24071 been more consistent with other usage to make this the address of 24072 the _next_ insn but this would be confusing because the length of 24073 the current insn is to be computed. 24074 24075 For normal insns, the length will be determined by value of the 24076`length' attribute. In the case of `addr_vec' and `addr_diff_vec' insn 24077patterns, the length is computed as the number of vectors multiplied by 24078the size of each vector. 24079 24080 Lengths are measured in addressable storage units (bytes). 24081 24082 The following macros can be used to refine the length computation: 24083 24084`ADJUST_INSN_LENGTH (INSN, LENGTH)' 24085 If defined, modifies the length assigned to instruction INSN as a 24086 function of the context in which it is used. LENGTH is an lvalue 24087 that contains the initially computed length of the insn and should 24088 be updated with the correct length of the insn. 24089 24090 This macro will normally not be required. A case in which it is 24091 required is the ROMP. On this machine, the size of an `addr_vec' 24092 insn must be increased by two to compensate for the fact that 24093 alignment may be required. 24094 24095 The routine that returns `get_attr_length' (the value of the `length' 24096attribute) can be used by the output routine to determine the form of 24097the branch instruction to be written, as the example below illustrates. 24098 24099 As an example of the specification of variable-length branches, 24100consider the IBM 360. If we adopt the convention that a register will 24101be set to the starting address of a function, we can jump to labels 24102within 4k of the start using a four-byte instruction. Otherwise, we 24103need a six-byte sequence to load the address from memory and then 24104branch to it. 24105 24106 On such a machine, a pattern for a branch instruction might be 24107specified as follows: 24108 24109 (define_insn "jump" 24110 [(set (pc) 24111 (label_ref (match_operand 0 "" "")))] 24112 "" 24113 { 24114 return (get_attr_length (insn) == 4 24115 ? "b %l0" : "l r15,=a(%l0); br r15"); 24116 } 24117 [(set (attr "length") 24118 (if_then_else (lt (match_dup 0) (const_int 4096)) 24119 (const_int 4) 24120 (const_int 6)))]) 24121 24122 24123File: gccint.info, Node: Constant Attributes, Next: Delay Slots, Prev: Insn Lengths, Up: Insn Attributes 24124 2412516.19.6 Constant Attributes 24126--------------------------- 24127 24128A special form of `define_attr', where the expression for the default 24129value is a `const' expression, indicates an attribute that is constant 24130for a given run of the compiler. Constant attributes may be used to 24131specify which variety of processor is used. For example, 24132 24133 (define_attr "cpu" "m88100,m88110,m88000" 24134 (const 24135 (cond [(symbol_ref "TARGET_88100") (const_string "m88100") 24136 (symbol_ref "TARGET_88110") (const_string "m88110")] 24137 (const_string "m88000")))) 24138 24139 (define_attr "memory" "fast,slow" 24140 (const 24141 (if_then_else (symbol_ref "TARGET_FAST_MEM") 24142 (const_string "fast") 24143 (const_string "slow")))) 24144 24145 The routine generated for constant attributes has no parameters as it 24146does not depend on any particular insn. RTL expressions used to define 24147the value of a constant attribute may use the `symbol_ref' form, but 24148may not use either the `match_operand' form or `eq_attr' forms 24149involving insn attributes. 24150 24151 24152File: gccint.info, Node: Delay Slots, Next: Processor pipeline description, Prev: Constant Attributes, Up: Insn Attributes 24153 2415416.19.7 Delay Slot Scheduling 24155----------------------------- 24156 24157The insn attribute mechanism can be used to specify the requirements for 24158delay slots, if any, on a target machine. An instruction is said to 24159require a "delay slot" if some instructions that are physically after 24160the instruction are executed as if they were located before it. 24161Classic examples are branch and call instructions, which often execute 24162the following instruction before the branch or call is performed. 24163 24164 On some machines, conditional branch instructions can optionally 24165"annul" instructions in the delay slot. This means that the 24166instruction will not be executed for certain branch outcomes. Both 24167instructions that annul if the branch is true and instructions that 24168annul if the branch is false are supported. 24169 24170 Delay slot scheduling differs from instruction scheduling in that 24171determining whether an instruction needs a delay slot is dependent only 24172on the type of instruction being generated, not on data flow between the 24173instructions. See the next section for a discussion of data-dependent 24174instruction scheduling. 24175 24176 The requirement of an insn needing one or more delay slots is indicated 24177via the `define_delay' expression. It has the following form: 24178 24179 (define_delay TEST 24180 [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 24181 DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 24182 ...]) 24183 24184 TEST is an attribute test that indicates whether this `define_delay' 24185applies to a particular insn. If so, the number of required delay 24186slots is determined by the length of the vector specified as the second 24187argument. An insn placed in delay slot N must satisfy attribute test 24188DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns 24189may be annulled if the branch is true. Similarly, ANNUL-FALSE-N 24190specifies which insns in the delay slot may be annulled if the branch 24191is false. If annulling is not supported for that delay slot, `(nil)' 24192should be coded. 24193 24194 For example, in the common case where branch and call insns require a 24195single delay slot, which may contain any insn other than a branch or 24196call, the following would be placed in the `md' file: 24197 24198 (define_delay (eq_attr "type" "branch,call") 24199 [(eq_attr "type" "!branch,call") (nil) (nil)]) 24200 24201 Multiple `define_delay' expressions may be specified. In this case, 24202each such expression specifies different delay slot requirements and 24203there must be no insn for which tests in two `define_delay' expressions 24204are both true. 24205 24206 For example, if we have a machine that requires one delay slot for 24207branches but two for calls, no delay slot can contain a branch or call 24208insn, and any valid insn in the delay slot for the branch can be 24209annulled if the branch is true, we might represent this as follows: 24210 24211 (define_delay (eq_attr "type" "branch") 24212 [(eq_attr "type" "!branch,call") 24213 (eq_attr "type" "!branch,call") 24214 (nil)]) 24215 24216 (define_delay (eq_attr "type" "call") 24217 [(eq_attr "type" "!branch,call") (nil) (nil) 24218 (eq_attr "type" "!branch,call") (nil) (nil)]) 24219 24220 24221File: gccint.info, Node: Processor pipeline description, Prev: Delay Slots, Up: Insn Attributes 24222 2422316.19.8 Specifying processor pipeline description 24224------------------------------------------------- 24225 24226To achieve better performance, most modern processors (super-pipelined, 24227superscalar RISC, and VLIW processors) have many "functional units" on 24228which several instructions can be executed simultaneously. An 24229instruction starts execution if its issue conditions are satisfied. If 24230not, the instruction is stalled until its conditions are satisfied. 24231Such "interlock (pipeline) delay" causes interruption of the fetching 24232of successor instructions (or demands nop instructions, e.g. for some 24233MIPS processors). 24234 24235 There are two major kinds of interlock delays in modern processors. 24236The first one is a data dependence delay determining "instruction 24237latency time". The instruction execution is not started until all 24238source data have been evaluated by prior instructions (there are more 24239complex cases when the instruction execution starts even when the data 24240are not available but will be ready in given time after the instruction 24241execution start). Taking the data dependence delays into account is 24242simple. The data dependence (true, output, and anti-dependence) delay 24243between two instructions is given by a constant. In most cases this 24244approach is adequate. The second kind of interlock delays is a 24245reservation delay. The reservation delay means that two instructions 24246under execution will be in need of shared processors resources, i.e. 24247buses, internal registers, and/or functional units, which are reserved 24248for some time. Taking this kind of delay into account is complex 24249especially for modern RISC processors. 24250 24251 The task of exploiting more processor parallelism is solved by an 24252instruction scheduler. For a better solution to this problem, the 24253instruction scheduler has to have an adequate description of the 24254processor parallelism (or "pipeline description"). GCC machine 24255descriptions describe processor parallelism and functional unit 24256reservations for groups of instructions with the aid of "regular 24257expressions". 24258 24259 The GCC instruction scheduler uses a "pipeline hazard recognizer" to 24260figure out the possibility of the instruction issue by the processor on 24261a given simulated processor cycle. The pipeline hazard recognizer is 24262automatically generated from the processor pipeline description. The 24263pipeline hazard recognizer generated from the machine description is 24264based on a deterministic finite state automaton (DFA): the instruction 24265issue is possible if there is a transition from one automaton state to 24266another one. This algorithm is very fast, and furthermore, its speed 24267is not dependent on processor complexity(1). 24268 24269 The rest of this section describes the directives that constitute an 24270automaton-based processor pipeline description. The order of these 24271constructions within the machine description file is not important. 24272 24273 The following optional construction describes names of automata 24274generated and used for the pipeline hazards recognition. Sometimes the 24275generated finite state automaton used by the pipeline hazard recognizer 24276is large. If we use more than one automaton and bind functional units 24277to the automata, the total size of the automata is usually less than 24278the size of the single automaton. If there is no one such 24279construction, only one finite state automaton is generated. 24280 24281 (define_automaton AUTOMATA-NAMES) 24282 24283 AUTOMATA-NAMES is a string giving names of the automata. The names 24284are separated by commas. All the automata should have unique names. 24285The automaton name is used in the constructions `define_cpu_unit' and 24286`define_query_cpu_unit'. 24287 24288 Each processor functional unit used in the description of instruction 24289reservations should be described by the following construction. 24290 24291 (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 24292 24293 UNIT-NAMES is a string giving the names of the functional units 24294separated by commas. Don't use name `nothing', it is reserved for 24295other goals. 24296 24297 AUTOMATON-NAME is a string giving the name of the automaton with which 24298the unit is bound. The automaton should be described in construction 24299`define_automaton'. You should give "automaton-name", if there is a 24300defined automaton. 24301 24302 The assignment of units to automata are constrained by the uses of the 24303units in insn reservations. The most important constraint is: if a 24304unit reservation is present on a particular cycle of an alternative for 24305an insn reservation, then some unit from the same automaton must be 24306present on the same cycle for the other alternatives of the insn 24307reservation. The rest of the constraints are mentioned in the 24308description of the subsequent constructions. 24309 24310 The following construction describes CPU functional units analogously 24311to `define_cpu_unit'. The reservation of such units can be queried for 24312an automaton state. The instruction scheduler never queries 24313reservation of functional units for given automaton state. So as a 24314rule, you don't need this construction. This construction could be 24315used for future code generation goals (e.g. to generate VLIW insn 24316templates). 24317 24318 (define_query_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 24319 24320 UNIT-NAMES is a string giving names of the functional units separated 24321by commas. 24322 24323 AUTOMATON-NAME is a string giving the name of the automaton with which 24324the unit is bound. 24325 24326 The following construction is the major one to describe pipeline 24327characteristics of an instruction. 24328 24329 (define_insn_reservation INSN-NAME DEFAULT_LATENCY 24330 CONDITION REGEXP) 24331 24332 DEFAULT_LATENCY is a number giving latency time of the instruction. 24333There is an important difference between the old description and the 24334automaton based pipeline description. The latency time is used for all 24335dependencies when we use the old description. In the automaton based 24336pipeline description, the given latency time is only used for true 24337dependencies. The cost of anti-dependencies is always zero and the 24338cost of output dependencies is the difference between latency times of 24339the producing and consuming insns (if the difference is negative, the 24340cost is considered to be zero). You can always change the default 24341costs for any description by using the target hook 24342`TARGET_SCHED_ADJUST_COST' (*note Scheduling::). 24343 24344 INSN-NAME is a string giving the internal name of the insn. The 24345internal names are used in constructions `define_bypass' and in the 24346automaton description file generated for debugging. The internal name 24347has nothing in common with the names in `define_insn'. It is a good 24348practice to use insn classes described in the processor manual. 24349 24350 CONDITION defines what RTL insns are described by this construction. 24351You should remember that you will be in trouble if CONDITION for two or 24352more different `define_insn_reservation' constructions is TRUE for an 24353insn. In this case what reservation will be used for the insn is not 24354defined. Such cases are not checked during generation of the pipeline 24355hazards recognizer because in general recognizing that two conditions 24356may have the same value is quite difficult (especially if the conditions 24357contain `symbol_ref'). It is also not checked during the pipeline 24358hazard recognizer work because it would slow down the recognizer 24359considerably. 24360 24361 REGEXP is a string describing the reservation of the cpu's functional 24362units by the instruction. The reservations are described by a regular 24363expression according to the following syntax: 24364 24365 regexp = regexp "," oneof 24366 | oneof 24367 24368 oneof = oneof "|" allof 24369 | allof 24370 24371 allof = allof "+" repeat 24372 | repeat 24373 24374 repeat = element "*" number 24375 | element 24376 24377 element = cpu_function_unit_name 24378 | reservation_name 24379 | result_name 24380 | "nothing" 24381 | "(" regexp ")" 24382 24383 * `,' is used for describing the start of the next cycle in the 24384 reservation. 24385 24386 * `|' is used for describing a reservation described by the first 24387 regular expression *or* a reservation described by the second 24388 regular expression *or* etc. 24389 24390 * `+' is used for describing a reservation described by the first 24391 regular expression *and* a reservation described by the second 24392 regular expression *and* etc. 24393 24394 * `*' is used for convenience and simply means a sequence in which 24395 the regular expression are repeated NUMBER times with cycle 24396 advancing (see `,'). 24397 24398 * `cpu_function_unit_name' denotes reservation of the named 24399 functional unit. 24400 24401 * `reservation_name' -- see description of construction 24402 `define_reservation'. 24403 24404 * `nothing' denotes no unit reservations. 24405 24406 Sometimes unit reservations for different insns contain common parts. 24407In such case, you can simplify the pipeline description by describing 24408the common part by the following construction 24409 24410 (define_reservation RESERVATION-NAME REGEXP) 24411 24412 RESERVATION-NAME is a string giving name of REGEXP. Functional unit 24413names and reservation names are in the same name space. So the 24414reservation names should be different from the functional unit names 24415and can not be the reserved name `nothing'. 24416 24417 The following construction is used to describe exceptions in the 24418latency time for given instruction pair. This is so called bypasses. 24419 24420 (define_bypass NUMBER OUT_INSN_NAMES IN_INSN_NAMES 24421 [GUARD]) 24422 24423 NUMBER defines when the result generated by the instructions given in 24424string OUT_INSN_NAMES will be ready for the instructions given in 24425string IN_INSN_NAMES. The instructions in the string are separated by 24426commas. 24427 24428 GUARD is an optional string giving the name of a C function which 24429defines an additional guard for the bypass. The function will get the 24430two insns as parameters. If the function returns zero the bypass will 24431be ignored for this case. The additional guard is necessary to 24432recognize complicated bypasses, e.g. when the consumer is only an 24433address of insn `store' (not a stored value). 24434 24435 If there are more one bypass with the same output and input insns, the 24436chosen bypass is the first bypass with a guard in description whose 24437guard function returns nonzero. If there is no such bypass, then 24438bypass without the guard function is chosen. 24439 24440 The following five constructions are usually used to describe VLIW 24441processors, or more precisely, to describe a placement of small 24442instructions into VLIW instruction slots. They can be used for RISC 24443processors, too. 24444 24445 (exclusion_set UNIT-NAMES UNIT-NAMES) 24446 (presence_set UNIT-NAMES PATTERNS) 24447 (final_presence_set UNIT-NAMES PATTERNS) 24448 (absence_set UNIT-NAMES PATTERNS) 24449 (final_absence_set UNIT-NAMES PATTERNS) 24450 24451 UNIT-NAMES is a string giving names of functional units separated by 24452commas. 24453 24454 PATTERNS is a string giving patterns of functional units separated by 24455comma. Currently pattern is one unit or units separated by 24456white-spaces. 24457 24458 The first construction (`exclusion_set') means that each functional 24459unit in the first string can not be reserved simultaneously with a unit 24460whose name is in the second string and vice versa. For example, the 24461construction is useful for describing processors (e.g. some SPARC 24462processors) with a fully pipelined floating point functional unit which 24463can execute simultaneously only single floating point insns or only 24464double floating point insns. 24465 24466 The second construction (`presence_set') means that each functional 24467unit in the first string can not be reserved unless at least one of 24468pattern of units whose names are in the second string is reserved. 24469This is an asymmetric relation. For example, it is useful for 24470description that VLIW `slot1' is reserved after `slot0' reservation. 24471We could describe it by the following construction 24472 24473 (presence_set "slot1" "slot0") 24474 24475 Or `slot1' is reserved only after `slot0' and unit `b0' reservation. 24476In this case we could write 24477 24478 (presence_set "slot1" "slot0 b0") 24479 24480 The third construction (`final_presence_set') is analogous to 24481`presence_set'. The difference between them is when checking is done. 24482When an instruction is issued in given automaton state reflecting all 24483current and planned unit reservations, the automaton state is changed. 24484The first state is a source state, the second one is a result state. 24485Checking for `presence_set' is done on the source state reservation, 24486checking for `final_presence_set' is done on the result reservation. 24487This construction is useful to describe a reservation which is actually 24488two subsequent reservations. For example, if we use 24489 24490 (presence_set "slot1" "slot0") 24491 24492 the following insn will be never issued (because `slot1' requires 24493`slot0' which is absent in the source state). 24494 24495 (define_reservation "insn_and_nop" "slot0 + slot1") 24496 24497 but it can be issued if we use analogous `final_presence_set'. 24498 24499 The forth construction (`absence_set') means that each functional unit 24500in the first string can be reserved only if each pattern of units whose 24501names are in the second string is not reserved. This is an asymmetric 24502relation (actually `exclusion_set' is analogous to this one but it is 24503symmetric). For example it might be useful in a VLIW description to 24504say that `slot0' cannot be reserved after either `slot1' or `slot2' 24505have been reserved. This can be described as: 24506 24507 (absence_set "slot0" "slot1, slot2") 24508 24509 Or `slot2' can not be reserved if `slot0' and unit `b0' are reserved 24510or `slot1' and unit `b1' are reserved. In this case we could write 24511 24512 (absence_set "slot2" "slot0 b0, slot1 b1") 24513 24514 All functional units mentioned in a set should belong to the same 24515automaton. 24516 24517 The last construction (`final_absence_set') is analogous to 24518`absence_set' but checking is done on the result (state) reservation. 24519See comments for `final_presence_set'. 24520 24521 You can control the generator of the pipeline hazard recognizer with 24522the following construction. 24523 24524 (automata_option OPTIONS) 24525 24526 OPTIONS is a string giving options which affect the generated code. 24527Currently there are the following options: 24528 24529 * "no-minimization" makes no minimization of the automaton. This is 24530 only worth to do when we are debugging the description and need to 24531 look more accurately at reservations of states. 24532 24533 * "time" means printing time statistics about the generation of 24534 automata. 24535 24536 * "stats" means printing statistics about the generated automata 24537 such as the number of DFA states, NDFA states and arcs. 24538 24539 * "v" means a generation of the file describing the result automata. 24540 The file has suffix `.dfa' and can be used for the description 24541 verification and debugging. 24542 24543 * "w" means a generation of warning instead of error for 24544 non-critical errors. 24545 24546 * "ndfa" makes nondeterministic finite state automata. This affects 24547 the treatment of operator `|' in the regular expressions. The 24548 usual treatment of the operator is to try the first alternative 24549 and, if the reservation is not possible, the second alternative. 24550 The nondeterministic treatment means trying all alternatives, some 24551 of them may be rejected by reservations in the subsequent insns. 24552 24553 * "progress" means output of a progress bar showing how many states 24554 were generated so far for automaton being processed. This is 24555 useful during debugging a DFA description. If you see too many 24556 generated states, you could interrupt the generator of the pipeline 24557 hazard recognizer and try to figure out a reason for generation of 24558 the huge automaton. 24559 24560 As an example, consider a superscalar RISC machine which can issue 24561three insns (two integer insns and one floating point insn) on the 24562cycle but can finish only two insns. To describe this, we define the 24563following functional units. 24564 24565 (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline") 24566 (define_cpu_unit "port0, port1") 24567 24568 All simple integer insns can be executed in any integer pipeline and 24569their result is ready in two cycles. The simple integer insns are 24570issued into the first pipeline unless it is reserved, otherwise they 24571are issued into the second pipeline. Integer division and 24572multiplication insns can be executed only in the second integer 24573pipeline and their results are ready correspondingly in 8 and 4 cycles. 24574The integer division is not pipelined, i.e. the subsequent integer 24575division insn can not be issued until the current division insn 24576finished. Floating point insns are fully pipelined and their results 24577are ready in 3 cycles. Where the result of a floating point insn is 24578used by an integer insn, an additional delay of one cycle is incurred. 24579To describe all of this we could specify 24580 24581 (define_cpu_unit "div") 24582 24583 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 24584 "(i0_pipeline | i1_pipeline), (port0 | port1)") 24585 24586 (define_insn_reservation "mult" 4 (eq_attr "type" "mult") 24587 "i1_pipeline, nothing*2, (port0 | port1)") 24588 24589 (define_insn_reservation "div" 8 (eq_attr "type" "div") 24590 "i1_pipeline, div*7, div + (port0 | port1)") 24591 24592 (define_insn_reservation "float" 3 (eq_attr "type" "float") 24593 "f_pipeline, nothing, (port0 | port1)) 24594 24595 (define_bypass 4 "float" "simple,mult,div") 24596 24597 To simplify the description we could describe the following reservation 24598 24599 (define_reservation "finish" "port0|port1") 24600 24601 and use it in all `define_insn_reservation' as in the following 24602construction 24603 24604 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 24605 "(i0_pipeline | i1_pipeline), finish") 24606 24607 ---------- Footnotes ---------- 24608 24609 (1) However, the size of the automaton depends on processor 24610complexity. To limit this effect, machine descriptions can split 24611orthogonal parts of the machine description among several automata: but 24612then, since each of these must be stepped independently, this does 24613cause a small decrease in the algorithm's performance. 24614 24615 24616File: gccint.info, Node: Conditional Execution, Next: Constant Definitions, Prev: Insn Attributes, Up: Machine Desc 24617 2461816.20 Conditional Execution 24619=========================== 24620 24621A number of architectures provide for some form of conditional 24622execution, or predication. The hallmark of this feature is the ability 24623to nullify most of the instructions in the instruction set. When the 24624instruction set is large and not entirely symmetric, it can be quite 24625tedious to describe these forms directly in the `.md' file. An 24626alternative is the `define_cond_exec' template. 24627 24628 (define_cond_exec 24629 [PREDICATE-PATTERN] 24630 "CONDITION" 24631 "OUTPUT-TEMPLATE") 24632 24633 PREDICATE-PATTERN is the condition that must be true for the insn to 24634be executed at runtime and should match a relational operator. One can 24635use `match_operator' to match several relational operators at once. 24636Any `match_operand' operands must have no more than one alternative. 24637 24638 CONDITION is a C expression that must be true for the generated 24639pattern to match. 24640 24641 OUTPUT-TEMPLATE is a string similar to the `define_insn' output 24642template (*note Output Template::), except that the `*' and `@' special 24643cases do not apply. This is only useful if the assembly text for the 24644predicate is a simple prefix to the main insn. In order to handle the 24645general case, there is a global variable `current_insn_predicate' that 24646will contain the entire predicate if the current insn is predicated, 24647and will otherwise be `NULL'. 24648 24649 When `define_cond_exec' is used, an implicit reference to the 24650`predicable' instruction attribute is made. *Note Insn Attributes::. 24651This attribute must be boolean (i.e. have exactly two elements in its 24652LIST-OF-VALUES). Further, it must not be used with complex 24653expressions. That is, the default and all uses in the insns must be a 24654simple constant, not dependent on the alternative or anything else. 24655 24656 For each `define_insn' for which the `predicable' attribute is true, a 24657new `define_insn' pattern will be generated that matches a predicated 24658version of the instruction. For example, 24659 24660 (define_insn "addsi" 24661 [(set (match_operand:SI 0 "register_operand" "r") 24662 (plus:SI (match_operand:SI 1 "register_operand" "r") 24663 (match_operand:SI 2 "register_operand" "r")))] 24664 "TEST1" 24665 "add %2,%1,%0") 24666 24667 (define_cond_exec 24668 [(ne (match_operand:CC 0 "register_operand" "c") 24669 (const_int 0))] 24670 "TEST2" 24671 "(%0)") 24672 24673generates a new pattern 24674 24675 (define_insn "" 24676 [(cond_exec 24677 (ne (match_operand:CC 3 "register_operand" "c") (const_int 0)) 24678 (set (match_operand:SI 0 "register_operand" "r") 24679 (plus:SI (match_operand:SI 1 "register_operand" "r") 24680 (match_operand:SI 2 "register_operand" "r"))))] 24681 "(TEST2) && (TEST1)" 24682 "(%3) add %2,%1,%0") 24683 24684 24685File: gccint.info, Node: Constant Definitions, Next: Iterators, Prev: Conditional Execution, Up: Machine Desc 24686 2468716.21 Constant Definitions 24688========================== 24689 24690Using literal constants inside instruction patterns reduces legibility 24691and can be a maintenance problem. 24692 24693 To overcome this problem, you may use the `define_constants' 24694expression. It contains a vector of name-value pairs. From that point 24695on, wherever any of the names appears in the MD file, it is as if the 24696corresponding value had been written instead. You may use 24697`define_constants' multiple times; each appearance adds more constants 24698to the table. It is an error to redefine a constant with a different 24699value. 24700 24701 To come back to the a29k load multiple example, instead of 24702 24703 (define_insn "" 24704 [(match_parallel 0 "load_multiple_operation" 24705 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 24706 (match_operand:SI 2 "memory_operand" "m")) 24707 (use (reg:SI 179)) 24708 (clobber (reg:SI 179))])] 24709 "" 24710 "loadm 0,0,%1,%2") 24711 24712 You could write: 24713 24714 (define_constants [ 24715 (R_BP 177) 24716 (R_FC 178) 24717 (R_CR 179) 24718 (R_Q 180) 24719 ]) 24720 24721 (define_insn "" 24722 [(match_parallel 0 "load_multiple_operation" 24723 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 24724 (match_operand:SI 2 "memory_operand" "m")) 24725 (use (reg:SI R_CR)) 24726 (clobber (reg:SI R_CR))])] 24727 "" 24728 "loadm 0,0,%1,%2") 24729 24730 The constants that are defined with a define_constant are also output 24731in the insn-codes.h header file as #defines. 24732 24733 24734File: gccint.info, Node: Iterators, Prev: Constant Definitions, Up: Machine Desc 24735 2473616.22 Iterators 24737=============== 24738 24739Ports often need to define similar patterns for more than one machine 24740mode or for more than one rtx code. GCC provides some simple iterator 24741facilities to make this process easier. 24742 24743* Menu: 24744 24745* Mode Iterators:: Generating variations of patterns for different modes. 24746* Code Iterators:: Doing the same for codes. 24747 24748 24749File: gccint.info, Node: Mode Iterators, Next: Code Iterators, Up: Iterators 24750 2475116.22.1 Mode Iterators 24752---------------------- 24753 24754Ports often need to define similar patterns for two or more different 24755modes. For example: 24756 24757 * If a processor has hardware support for both single and double 24758 floating-point arithmetic, the `SFmode' patterns tend to be very 24759 similar to the `DFmode' ones. 24760 24761 * If a port uses `SImode' pointers in one configuration and `DImode' 24762 pointers in another, it will usually have very similar `SImode' 24763 and `DImode' patterns for manipulating pointers. 24764 24765 Mode iterators allow several patterns to be instantiated from one 24766`.md' file template. They can be used with any type of rtx-based 24767construct, such as a `define_insn', `define_split', or 24768`define_peephole2'. 24769 24770* Menu: 24771 24772* Defining Mode Iterators:: Defining a new mode iterator. 24773* Substitutions:: Combining mode iterators with substitutions 24774* Examples:: Examples 24775 24776 24777File: gccint.info, Node: Defining Mode Iterators, Next: Substitutions, Up: Mode Iterators 24778 2477916.22.1.1 Defining Mode Iterators 24780................................. 24781 24782The syntax for defining a mode iterator is: 24783 24784 (define_mode_iterator NAME [(MODE1 "COND1") ... (MODEN "CONDN")]) 24785 24786 This allows subsequent `.md' file constructs to use the mode suffix 24787`:NAME'. Every construct that does so will be expanded N times, once 24788with every use of `:NAME' replaced by `:MODE1', once with every use 24789replaced by `:MODE2', and so on. In the expansion for a particular 24790MODEI, every C condition will also require that CONDI be true. 24791 24792 For example: 24793 24794 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 24795 24796 defines a new mode suffix `:P'. Every construct that uses `:P' will 24797be expanded twice, once with every `:P' replaced by `:SI' and once with 24798every `:P' replaced by `:DI'. The `:SI' version will only apply if 24799`Pmode == SImode' and the `:DI' version will only apply if `Pmode == 24800DImode'. 24801 24802 As with other `.md' conditions, an empty string is treated as "always 24803true". `(MODE "")' can also be abbreviated to `MODE'. For example: 24804 24805 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 24806 24807 means that the `:DI' expansion only applies if `TARGET_64BIT' but that 24808the `:SI' expansion has no such constraint. 24809 24810 Iterators are applied in the order they are defined. This can be 24811significant if two iterators are used in a construct that requires 24812substitutions. *Note Substitutions::. 24813 24814 24815File: gccint.info, Node: Substitutions, Next: Examples, Prev: Defining Mode Iterators, Up: Mode Iterators 24816 2481716.22.1.2 Substitution in Mode Iterators 24818........................................ 24819 24820If an `.md' file construct uses mode iterators, each version of the 24821construct will often need slightly different strings or modes. For 24822example: 24823 24824 * When a `define_expand' defines several `addM3' patterns (*note 24825 Standard Names::), each expander will need to use the appropriate 24826 mode name for M. 24827 24828 * When a `define_insn' defines several instruction patterns, each 24829 instruction will often use a different assembler mnemonic. 24830 24831 * When a `define_insn' requires operands with different modes, using 24832 an iterator for one of the operand modes usually requires a 24833 specific mode for the other operand(s). 24834 24835 GCC supports such variations through a system of "mode attributes". 24836There are two standard attributes: `mode', which is the name of the 24837mode in lower case, and `MODE', which is the same thing in upper case. 24838You can define other attributes using: 24839 24840 (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")]) 24841 24842 where NAME is the name of the attribute and VALUEI is the value 24843associated with MODEI. 24844 24845 When GCC replaces some :ITERATOR with :MODE, it will scan each string 24846and mode in the pattern for sequences of the form `<ITERATOR:ATTR>', 24847where ATTR is the name of a mode attribute. If the attribute is 24848defined for MODE, the whole `<...>' sequence will be replaced by the 24849appropriate attribute value. 24850 24851 For example, suppose an `.md' file has: 24852 24853 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 24854 (define_mode_attr load [(SI "lw") (DI "ld")]) 24855 24856 If one of the patterns that uses `:P' contains the string 24857`"<P:load>\t%0,%1"', the `SI' version of that pattern will use 24858`"lw\t%0,%1"' and the `DI' version will use `"ld\t%0,%1"'. 24859 24860 Here is an example of using an attribute for a mode: 24861 24862 (define_mode_iterator LONG [SI DI]) 24863 (define_mode_attr SHORT [(SI "HI") (DI "SI")]) 24864 (define_insn ... 24865 (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...) 24866 24867 The `ITERATOR:' prefix may be omitted, in which case the substitution 24868will be attempted for every iterator expansion. 24869 24870 24871File: gccint.info, Node: Examples, Prev: Substitutions, Up: Mode Iterators 24872 2487316.22.1.3 Mode Iterator Examples 24874................................ 24875 24876Here is an example from the MIPS port. It defines the following modes 24877and attributes (among others): 24878 24879 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 24880 (define_mode_attr d [(SI "") (DI "d")]) 24881 24882 and uses the following template to define both `subsi3' and `subdi3': 24883 24884 (define_insn "sub<mode>3" 24885 [(set (match_operand:GPR 0 "register_operand" "=d") 24886 (minus:GPR (match_operand:GPR 1 "register_operand" "d") 24887 (match_operand:GPR 2 "register_operand" "d")))] 24888 "" 24889 "<d>subu\t%0,%1,%2" 24890 [(set_attr "type" "arith") 24891 (set_attr "mode" "<MODE>")]) 24892 24893 This is exactly equivalent to: 24894 24895 (define_insn "subsi3" 24896 [(set (match_operand:SI 0 "register_operand" "=d") 24897 (minus:SI (match_operand:SI 1 "register_operand" "d") 24898 (match_operand:SI 2 "register_operand" "d")))] 24899 "" 24900 "subu\t%0,%1,%2" 24901 [(set_attr "type" "arith") 24902 (set_attr "mode" "SI")]) 24903 24904 (define_insn "subdi3" 24905 [(set (match_operand:DI 0 "register_operand" "=d") 24906 (minus:DI (match_operand:DI 1 "register_operand" "d") 24907 (match_operand:DI 2 "register_operand" "d")))] 24908 "" 24909 "dsubu\t%0,%1,%2" 24910 [(set_attr "type" "arith") 24911 (set_attr "mode" "DI")]) 24912 24913 24914File: gccint.info, Node: Code Iterators, Prev: Mode Iterators, Up: Iterators 24915 2491616.22.2 Code Iterators 24917---------------------- 24918 24919Code iterators operate in a similar way to mode iterators. *Note Mode 24920Iterators::. 24921 24922 The construct: 24923 24924 (define_code_iterator NAME [(CODE1 "COND1") ... (CODEN "CONDN")]) 24925 24926 defines a pseudo rtx code NAME that can be instantiated as CODEI if 24927condition CONDI is true. Each CODEI must have the same rtx format. 24928*Note RTL Classes::. 24929 24930 As with mode iterators, each pattern that uses NAME will be expanded N 24931times, once with all uses of NAME replaced by CODE1, once with all uses 24932replaced by CODE2, and so on. *Note Defining Mode Iterators::. 24933 24934 It is possible to define attributes for codes as well as for modes. 24935There are two standard code attributes: `code', the name of the code in 24936lower case, and `CODE', the name of the code in upper case. Other 24937attributes are defined using: 24938 24939 (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")]) 24940 24941 Here's an example of code iterators in action, taken from the MIPS 24942port: 24943 24944 (define_code_iterator any_cond [unordered ordered unlt unge uneq ltgt unle ungt 24945 eq ne gt ge lt le gtu geu ltu leu]) 24946 24947 (define_expand "b<code>" 24948 [(set (pc) 24949 (if_then_else (any_cond:CC (cc0) 24950 (const_int 0)) 24951 (label_ref (match_operand 0 "")) 24952 (pc)))] 24953 "" 24954 { 24955 gen_conditional_branch (operands, <CODE>); 24956 DONE; 24957 }) 24958 24959 This is equivalent to: 24960 24961 (define_expand "bunordered" 24962 [(set (pc) 24963 (if_then_else (unordered:CC (cc0) 24964 (const_int 0)) 24965 (label_ref (match_operand 0 "")) 24966 (pc)))] 24967 "" 24968 { 24969 gen_conditional_branch (operands, UNORDERED); 24970 DONE; 24971 }) 24972 24973 (define_expand "bordered" 24974 [(set (pc) 24975 (if_then_else (ordered:CC (cc0) 24976 (const_int 0)) 24977 (label_ref (match_operand 0 "")) 24978 (pc)))] 24979 "" 24980 { 24981 gen_conditional_branch (operands, ORDERED); 24982 DONE; 24983 }) 24984 24985 ... 24986 24987 24988File: gccint.info, Node: Target Macros, Next: Host Config, Prev: Machine Desc, Up: Top 24989 2499017 Target Description Macros and Functions 24991****************************************** 24992 24993In addition to the file `MACHINE.md', a machine description includes a 24994C header file conventionally given the name `MACHINE.h' and a C source 24995file named `MACHINE.c'. The header file defines numerous macros that 24996convey the information about the target machine that does not fit into 24997the scheme of the `.md' file. The file `tm.h' should be a link to 24998`MACHINE.h'. The header file `config.h' includes `tm.h' and most 24999compiler source files include `config.h'. The source file defines a 25000variable `targetm', which is a structure containing pointers to 25001functions and data relating to the target machine. `MACHINE.c' should 25002also contain their definitions, if they are not defined elsewhere in 25003GCC, and other functions called through the macros defined in the `.h' 25004file. 25005 25006* Menu: 25007 25008* Target Structure:: The `targetm' variable. 25009* Driver:: Controlling how the driver runs the compilation passes. 25010* Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'. 25011* Per-Function Data:: Defining data structures for per-function information. 25012* Storage Layout:: Defining sizes and alignments of data. 25013* Type Layout:: Defining sizes and properties of basic user data types. 25014* Registers:: Naming and describing the hardware registers. 25015* Register Classes:: Defining the classes of hardware registers. 25016* Old Constraints:: The old way to define machine-specific constraints. 25017* Stack and Calling:: Defining which way the stack grows and by how much. 25018* Varargs:: Defining the varargs macros. 25019* Trampolines:: Code set up at run time to enter a nested function. 25020* Library Calls:: Controlling how library routines are implicitly called. 25021* Addressing Modes:: Defining addressing modes valid for memory operands. 25022* Anchored Addresses:: Defining how `-fsection-anchors' should work. 25023* Condition Code:: Defining how insns update the condition code. 25024* Costs:: Defining relative costs of different operations. 25025* Scheduling:: Adjusting the behavior of the instruction scheduler. 25026* Sections:: Dividing storage into text, data, and other sections. 25027* PIC:: Macros for position independent code. 25028* Assembler Format:: Defining how to write insns and pseudo-ops to output. 25029* Debugging Info:: Defining the format of debugging output. 25030* Floating Point:: Handling floating point for cross-compilers. 25031* Mode Switching:: Insertion of mode-switching instructions. 25032* Target Attributes:: Defining target-specific uses of `__attribute__'. 25033* Emulated TLS:: Emulated TLS support. 25034* MIPS Coprocessors:: MIPS coprocessor support and how to customize it. 25035* PCH Target:: Validity checking for precompiled headers. 25036* C++ ABI:: Controlling C++ ABI changes. 25037* Named Address Spaces:: Adding support for named address spaces 25038* Misc:: Everything else. 25039 25040 25041File: gccint.info, Node: Target Structure, Next: Driver, Up: Target Macros 25042 2504317.1 The Global `targetm' Variable 25044================================== 25045 25046 -- Variable: struct gcc_target targetm 25047 The target `.c' file must define the global `targetm' variable 25048 which contains pointers to functions and data relating to the 25049 target machine. The variable is declared in `target.h'; 25050 `target-def.h' defines the macro `TARGET_INITIALIZER' which is 25051 used to initialize the variable, and macros for the default 25052 initializers for elements of the structure. The `.c' file should 25053 override those macros for which the default definition is 25054 inappropriate. For example: 25055 #include "target.h" 25056 #include "target-def.h" 25057 25058 /* Initialize the GCC target structure. */ 25059 25060 #undef TARGET_COMP_TYPE_ATTRIBUTES 25061 #define TARGET_COMP_TYPE_ATTRIBUTES MACHINE_comp_type_attributes 25062 25063 struct gcc_target targetm = TARGET_INITIALIZER; 25064 25065Where a macro should be defined in the `.c' file in this manner to form 25066part of the `targetm' structure, it is documented below as a "Target 25067Hook" with a prototype. Many macros will change in future from being 25068defined in the `.h' file to being part of the `targetm' structure. 25069 25070 25071File: gccint.info, Node: Driver, Next: Run-time Target, Prev: Target Structure, Up: Target Macros 25072 2507317.2 Controlling the Compilation Driver, `gcc' 25074============================================== 25075 25076You can control the compilation driver. 25077 25078 -- Macro: SWITCH_TAKES_ARG (CHAR) 25079 A C expression which determines whether the option `-CHAR' takes 25080 arguments. The value should be the number of arguments that 25081 option takes-zero, for many options. 25082 25083 By default, this macro is defined as `DEFAULT_SWITCH_TAKES_ARG', 25084 which handles the standard options properly. You need not define 25085 `SWITCH_TAKES_ARG' unless you wish to add additional options which 25086 take arguments. Any redefinition should call 25087 `DEFAULT_SWITCH_TAKES_ARG' and then check for additional options. 25088 25089 -- Macro: WORD_SWITCH_TAKES_ARG (NAME) 25090 A C expression which determines whether the option `-NAME' takes 25091 arguments. The value should be the number of arguments that 25092 option takes-zero, for many options. This macro rather than 25093 `SWITCH_TAKES_ARG' is used for multi-character option names. 25094 25095 By default, this macro is defined as 25096 `DEFAULT_WORD_SWITCH_TAKES_ARG', which handles the standard options 25097 properly. You need not define `WORD_SWITCH_TAKES_ARG' unless you 25098 wish to add additional options which take arguments. Any 25099 redefinition should call `DEFAULT_WORD_SWITCH_TAKES_ARG' and then 25100 check for additional options. 25101 25102 -- Macro: SWITCH_CURTAILS_COMPILATION (CHAR) 25103 A C expression which determines whether the option `-CHAR' stops 25104 compilation before the generation of an executable. The value is 25105 boolean, nonzero if the option does stop an executable from being 25106 generated, zero otherwise. 25107 25108 By default, this macro is defined as 25109 `DEFAULT_SWITCH_CURTAILS_COMPILATION', which handles the standard 25110 options properly. You need not define 25111 `SWITCH_CURTAILS_COMPILATION' unless you wish to add additional 25112 options which affect the generation of an executable. Any 25113 redefinition should call `DEFAULT_SWITCH_CURTAILS_COMPILATION' and 25114 then check for additional options. 25115 25116 -- Macro: SWITCHES_NEED_SPACES 25117 A string-valued C expression which enumerates the options for which 25118 the linker needs a space between the option and its argument. 25119 25120 If this macro is not defined, the default value is `""'. 25121 25122 -- Macro: TARGET_OPTION_TRANSLATE_TABLE 25123 If defined, a list of pairs of strings, the first of which is a 25124 potential command line target to the `gcc' driver program, and the 25125 second of which is a space-separated (tabs and other whitespace 25126 are not supported) list of options with which to replace the first 25127 option. The target defining this list is responsible for assuring 25128 that the results are valid. Replacement options may not be the 25129 `--opt' style, they must be the `-opt' style. It is the intention 25130 of this macro to provide a mechanism for substitution that affects 25131 the multilibs chosen, such as one option that enables many 25132 options, some of which select multilibs. Example nonsensical 25133 definition, where `-malt-abi', `-EB', and `-mspoo' cause different 25134 multilibs to be chosen: 25135 25136 #define TARGET_OPTION_TRANSLATE_TABLE \ 25137 { "-fast", "-march=fast-foo -malt-abi -I/usr/fast-foo" }, \ 25138 { "-compat", "-EB -malign=4 -mspoo" } 25139 25140 -- Macro: DRIVER_SELF_SPECS 25141 A list of specs for the driver itself. It should be a suitable 25142 initializer for an array of strings, with no surrounding braces. 25143 25144 The driver applies these specs to its own command line between 25145 loading default `specs' files (but not command-line specified 25146 ones) and choosing the multilib directory or running any 25147 subcommands. It applies them in the order given, so each spec can 25148 depend on the options added by earlier ones. It is also possible 25149 to remove options using `%<OPTION' in the usual way. 25150 25151 This macro can be useful when a port has several interdependent 25152 target options. It provides a way of standardizing the command 25153 line so that the other specs are easier to write. 25154 25155 Do not define this macro if it does not need to do anything. 25156 25157 -- Macro: OPTION_DEFAULT_SPECS 25158 A list of specs used to support configure-time default options 25159 (i.e. `--with' options) in the driver. It should be a suitable 25160 initializer for an array of structures, each containing two 25161 strings, without the outermost pair of surrounding braces. 25162 25163 The first item in the pair is the name of the default. This must 25164 match the code in `config.gcc' for the target. The second item is 25165 a spec to apply if a default with this name was specified. The 25166 string `%(VALUE)' in the spec will be replaced by the value of the 25167 default everywhere it occurs. 25168 25169 The driver will apply these specs to its own command line between 25170 loading default `specs' files and processing `DRIVER_SELF_SPECS', 25171 using the same mechanism as `DRIVER_SELF_SPECS'. 25172 25173 Do not define this macro if it does not need to do anything. 25174 25175 -- Macro: CPP_SPEC 25176 A C string constant that tells the GCC driver program options to 25177 pass to CPP. It can also specify how to translate options you 25178 give to GCC into options for GCC to pass to the CPP. 25179 25180 Do not define this macro if it does not need to do anything. 25181 25182 -- Macro: CPLUSPLUS_CPP_SPEC 25183 This macro is just like `CPP_SPEC', but is used for C++, rather 25184 than C. If you do not define this macro, then the value of 25185 `CPP_SPEC' (if any) will be used instead. 25186 25187 -- Macro: CC1_SPEC 25188 A C string constant that tells the GCC driver program options to 25189 pass to `cc1', `cc1plus', `f771', and the other language front 25190 ends. It can also specify how to translate options you give to 25191 GCC into options for GCC to pass to front ends. 25192 25193 Do not define this macro if it does not need to do anything. 25194 25195 -- Macro: CC1PLUS_SPEC 25196 A C string constant that tells the GCC driver program options to 25197 pass to `cc1plus'. It can also specify how to translate options 25198 you give to GCC into options for GCC to pass to the `cc1plus'. 25199 25200 Do not define this macro if it does not need to do anything. Note 25201 that everything defined in CC1_SPEC is already passed to `cc1plus' 25202 so there is no need to duplicate the contents of CC1_SPEC in 25203 CC1PLUS_SPEC. 25204 25205 -- Macro: ASM_SPEC 25206 A C string constant that tells the GCC driver program options to 25207 pass to the assembler. It can also specify how to translate 25208 options you give to GCC into options for GCC to pass to the 25209 assembler. See the file `sun3.h' for an example of this. 25210 25211 Do not define this macro if it does not need to do anything. 25212 25213 -- Macro: ASM_FINAL_SPEC 25214 A C string constant that tells the GCC driver program how to run 25215 any programs which cleanup after the normal assembler. Normally, 25216 this is not needed. See the file `mips.h' for an example of this. 25217 25218 Do not define this macro if it does not need to do anything. 25219 25220 -- Macro: AS_NEEDS_DASH_FOR_PIPED_INPUT 25221 Define this macro, with no value, if the driver should give the 25222 assembler an argument consisting of a single dash, `-', to 25223 instruct it to read from its standard input (which will be a pipe 25224 connected to the output of the compiler proper). This argument is 25225 given after any `-o' option specifying the name of the output file. 25226 25227 If you do not define this macro, the assembler is assumed to read 25228 its standard input if given no non-option arguments. If your 25229 assembler cannot read standard input at all, use a `%{pipe:%e}' 25230 construct; see `mips.h' for instance. 25231 25232 -- Macro: LINK_SPEC 25233 A C string constant that tells the GCC driver program options to 25234 pass to the linker. It can also specify how to translate options 25235 you give to GCC into options for GCC to pass to the linker. 25236 25237 Do not define this macro if it does not need to do anything. 25238 25239 -- Macro: LIB_SPEC 25240 Another C string constant used much like `LINK_SPEC'. The 25241 difference between the two is that `LIB_SPEC' is used at the end 25242 of the command given to the linker. 25243 25244 If this macro is not defined, a default is provided that loads the 25245 standard C library from the usual place. See `gcc.c'. 25246 25247 -- Macro: LIBGCC_SPEC 25248 Another C string constant that tells the GCC driver program how 25249 and when to place a reference to `libgcc.a' into the linker 25250 command line. This constant is placed both before and after the 25251 value of `LIB_SPEC'. 25252 25253 If this macro is not defined, the GCC driver provides a default 25254 that passes the string `-lgcc' to the linker. 25255 25256 -- Macro: REAL_LIBGCC_SPEC 25257 By default, if `ENABLE_SHARED_LIBGCC' is defined, the 25258 `LIBGCC_SPEC' is not directly used by the driver program but is 25259 instead modified to refer to different versions of `libgcc.a' 25260 depending on the values of the command line flags `-static', 25261 `-shared', `-static-libgcc', and `-shared-libgcc'. On targets 25262 where these modifications are inappropriate, define 25263 `REAL_LIBGCC_SPEC' instead. `REAL_LIBGCC_SPEC' tells the driver 25264 how to place a reference to `libgcc' on the link command line, 25265 but, unlike `LIBGCC_SPEC', it is used unmodified. 25266 25267 -- Macro: USE_LD_AS_NEEDED 25268 A macro that controls the modifications to `LIBGCC_SPEC' mentioned 25269 in `REAL_LIBGCC_SPEC'. If nonzero, a spec will be generated that 25270 uses -as-needed and the shared libgcc in place of the static 25271 exception handler library, when linking without any of `-static', 25272 `-static-libgcc', or `-shared-libgcc'. 25273 25274 -- Macro: LINK_EH_SPEC 25275 If defined, this C string constant is added to `LINK_SPEC'. When 25276 `USE_LD_AS_NEEDED' is zero or undefined, it also affects the 25277 modifications to `LIBGCC_SPEC' mentioned in `REAL_LIBGCC_SPEC'. 25278 25279 -- Macro: STARTFILE_SPEC 25280 Another C string constant used much like `LINK_SPEC'. The 25281 difference between the two is that `STARTFILE_SPEC' is used at the 25282 very beginning of the command given to the linker. 25283 25284 If this macro is not defined, a default is provided that loads the 25285 standard C startup file from the usual place. See `gcc.c'. 25286 25287 -- Macro: ENDFILE_SPEC 25288 Another C string constant used much like `LINK_SPEC'. The 25289 difference between the two is that `ENDFILE_SPEC' is used at the 25290 very end of the command given to the linker. 25291 25292 Do not define this macro if it does not need to do anything. 25293 25294 -- Macro: THREAD_MODEL_SPEC 25295 GCC `-v' will print the thread model GCC was configured to use. 25296 However, this doesn't work on platforms that are multilibbed on 25297 thread models, such as AIX 4.3. On such platforms, define 25298 `THREAD_MODEL_SPEC' such that it evaluates to a string without 25299 blanks that names one of the recognized thread models. `%*', the 25300 default value of this macro, will expand to the value of 25301 `thread_file' set in `config.gcc'. 25302 25303 -- Macro: SYSROOT_SUFFIX_SPEC 25304 Define this macro to add a suffix to the target sysroot when GCC is 25305 configured with a sysroot. This will cause GCC to search for 25306 usr/lib, et al, within sysroot+suffix. 25307 25308 -- Macro: SYSROOT_HEADERS_SUFFIX_SPEC 25309 Define this macro to add a headers_suffix to the target sysroot 25310 when GCC is configured with a sysroot. This will cause GCC to 25311 pass the updated sysroot+headers_suffix to CPP, causing it to 25312 search for usr/include, et al, within sysroot+headers_suffix. 25313 25314 -- Macro: EXTRA_SPECS 25315 Define this macro to provide additional specifications to put in 25316 the `specs' file that can be used in various specifications like 25317 `CC1_SPEC'. 25318 25319 The definition should be an initializer for an array of structures, 25320 containing a string constant, that defines the specification name, 25321 and a string constant that provides the specification. 25322 25323 Do not define this macro if it does not need to do anything. 25324 25325 `EXTRA_SPECS' is useful when an architecture contains several 25326 related targets, which have various `..._SPECS' which are similar 25327 to each other, and the maintainer would like one central place to 25328 keep these definitions. 25329 25330 For example, the PowerPC System V.4 targets use `EXTRA_SPECS' to 25331 define either `_CALL_SYSV' when the System V calling sequence is 25332 used or `_CALL_AIX' when the older AIX-based calling sequence is 25333 used. 25334 25335 The `config/rs6000/rs6000.h' target file defines: 25336 25337 #define EXTRA_SPECS \ 25338 { "cpp_sysv_default", CPP_SYSV_DEFAULT }, 25339 25340 #define CPP_SYS_DEFAULT "" 25341 25342 The `config/rs6000/sysv.h' target file defines: 25343 #undef CPP_SPEC 25344 #define CPP_SPEC \ 25345 "%{posix: -D_POSIX_SOURCE } \ 25346 %{mcall-sysv: -D_CALL_SYSV } \ 25347 %{!mcall-sysv: %(cpp_sysv_default) } \ 25348 %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}" 25349 25350 #undef CPP_SYSV_DEFAULT 25351 #define CPP_SYSV_DEFAULT "-D_CALL_SYSV" 25352 25353 while the `config/rs6000/eabiaix.h' target file defines 25354 `CPP_SYSV_DEFAULT' as: 25355 25356 #undef CPP_SYSV_DEFAULT 25357 #define CPP_SYSV_DEFAULT "-D_CALL_AIX" 25358 25359 -- Macro: LINK_LIBGCC_SPECIAL_1 25360 Define this macro if the driver program should find the library 25361 `libgcc.a'. If you do not define this macro, the driver program 25362 will pass the argument `-lgcc' to tell the linker to do the search. 25363 25364 -- Macro: LINK_GCC_C_SEQUENCE_SPEC 25365 The sequence in which libgcc and libc are specified to the linker. 25366 By default this is `%G %L %G'. 25367 25368 -- Macro: LINK_COMMAND_SPEC 25369 A C string constant giving the complete command line need to 25370 execute the linker. When you do this, you will need to update 25371 your port each time a change is made to the link command line 25372 within `gcc.c'. Therefore, define this macro only if you need to 25373 completely redefine the command line for invoking the linker and 25374 there is no other way to accomplish the effect you need. 25375 Overriding this macro may be avoidable by overriding 25376 `LINK_GCC_C_SEQUENCE_SPEC' instead. 25377 25378 -- Macro: LINK_ELIMINATE_DUPLICATE_LDIRECTORIES 25379 A nonzero value causes `collect2' to remove duplicate 25380 `-LDIRECTORY' search directories from linking commands. Do not 25381 give it a nonzero value if removing duplicate search directories 25382 changes the linker's semantics. 25383 25384 -- Macro: MULTILIB_DEFAULTS 25385 Define this macro as a C expression for the initializer of an 25386 array of string to tell the driver program which options are 25387 defaults for this target and thus do not need to be handled 25388 specially when using `MULTILIB_OPTIONS'. 25389 25390 Do not define this macro if `MULTILIB_OPTIONS' is not defined in 25391 the target makefile fragment or if none of the options listed in 25392 `MULTILIB_OPTIONS' are set by default. *Note Target Fragment::. 25393 25394 -- Macro: RELATIVE_PREFIX_NOT_LINKDIR 25395 Define this macro to tell `gcc' that it should only translate a 25396 `-B' prefix into a `-L' linker option if the prefix indicates an 25397 absolute file name. 25398 25399 -- Macro: MD_EXEC_PREFIX 25400 If defined, this macro is an additional prefix to try after 25401 `STANDARD_EXEC_PREFIX'. `MD_EXEC_PREFIX' is not searched when the 25402 `-b' option is used, or the compiler is built as a cross compiler. 25403 If you define `MD_EXEC_PREFIX', then be sure to add it to the list 25404 of directories used to find the assembler in `configure.in'. 25405 25406 -- Macro: STANDARD_STARTFILE_PREFIX 25407 Define this macro as a C string constant if you wish to override 25408 the standard choice of `libdir' as the default prefix to try when 25409 searching for startup files such as `crt0.o'. 25410 `STANDARD_STARTFILE_PREFIX' is not searched when the compiler is 25411 built as a cross compiler. 25412 25413 -- Macro: STANDARD_STARTFILE_PREFIX_1 25414 Define this macro as a C string constant if you wish to override 25415 the standard choice of `/lib' as a prefix to try after the default 25416 prefix when searching for startup files such as `crt0.o'. 25417 `STANDARD_STARTFILE_PREFIX_1' is not searched when the compiler is 25418 built as a cross compiler. 25419 25420 -- Macro: STANDARD_STARTFILE_PREFIX_2 25421 Define this macro as a C string constant if you wish to override 25422 the standard choice of `/lib' as yet another prefix to try after 25423 the default prefix when searching for startup files such as 25424 `crt0.o'. `STANDARD_STARTFILE_PREFIX_2' is not searched when the 25425 compiler is built as a cross compiler. 25426 25427 -- Macro: MD_STARTFILE_PREFIX 25428 If defined, this macro supplies an additional prefix to try after 25429 the standard prefixes. `MD_EXEC_PREFIX' is not searched when the 25430 `-b' option is used, or when the compiler is built as a cross 25431 compiler. 25432 25433 -- Macro: MD_STARTFILE_PREFIX_1 25434 If defined, this macro supplies yet another prefix to try after the 25435 standard prefixes. It is not searched when the `-b' option is 25436 used, or when the compiler is built as a cross compiler. 25437 25438 -- Macro: INIT_ENVIRONMENT 25439 Define this macro as a C string constant if you wish to set 25440 environment variables for programs called by the driver, such as 25441 the assembler and loader. The driver passes the value of this 25442 macro to `putenv' to initialize the necessary environment 25443 variables. 25444 25445 -- Macro: LOCAL_INCLUDE_DIR 25446 Define this macro as a C string constant if you wish to override 25447 the standard choice of `/usr/local/include' as the default prefix 25448 to try when searching for local header files. `LOCAL_INCLUDE_DIR' 25449 comes before `SYSTEM_INCLUDE_DIR' in the search order. 25450 25451 Cross compilers do not search either `/usr/local/include' or its 25452 replacement. 25453 25454 -- Macro: MODIFY_TARGET_NAME 25455 Define this macro if you wish to define command-line switches that 25456 modify the default target name. 25457 25458 For each switch, you can include a string to be appended to the 25459 first part of the configuration name or a string to be deleted 25460 from the configuration name, if present. The definition should be 25461 an initializer for an array of structures. Each array element 25462 should have three elements: the switch name (a string constant, 25463 including the initial dash), one of the enumeration codes `ADD' or 25464 `DELETE' to indicate whether the string should be inserted or 25465 deleted, and the string to be inserted or deleted (a string 25466 constant). 25467 25468 For example, on a machine where `64' at the end of the 25469 configuration name denotes a 64-bit target and you want the `-32' 25470 and `-64' switches to select between 32- and 64-bit targets, you 25471 would code 25472 25473 #define MODIFY_TARGET_NAME \ 25474 { { "-32", DELETE, "64"}, \ 25475 {"-64", ADD, "64"}} 25476 25477 -- Macro: SYSTEM_INCLUDE_DIR 25478 Define this macro as a C string constant if you wish to specify a 25479 system-specific directory to search for header files before the 25480 standard directory. `SYSTEM_INCLUDE_DIR' comes before 25481 `STANDARD_INCLUDE_DIR' in the search order. 25482 25483 Cross compilers do not use this macro and do not search the 25484 directory specified. 25485 25486 -- Macro: STANDARD_INCLUDE_DIR 25487 Define this macro as a C string constant if you wish to override 25488 the standard choice of `/usr/include' as the default prefix to try 25489 when searching for header files. 25490 25491 Cross compilers ignore this macro and do not search either 25492 `/usr/include' or its replacement. 25493 25494 -- Macro: STANDARD_INCLUDE_COMPONENT 25495 The "component" corresponding to `STANDARD_INCLUDE_DIR'. See 25496 `INCLUDE_DEFAULTS', below, for the description of components. If 25497 you do not define this macro, no component is used. 25498 25499 -- Macro: INCLUDE_DEFAULTS 25500 Define this macro if you wish to override the entire default 25501 search path for include files. For a native compiler, the default 25502 search path usually consists of `GCC_INCLUDE_DIR', 25503 `LOCAL_INCLUDE_DIR', `SYSTEM_INCLUDE_DIR', 25504 `GPLUSPLUS_INCLUDE_DIR', and `STANDARD_INCLUDE_DIR'. In addition, 25505 `GPLUSPLUS_INCLUDE_DIR' and `GCC_INCLUDE_DIR' are defined 25506 automatically by `Makefile', and specify private search areas for 25507 GCC. The directory `GPLUSPLUS_INCLUDE_DIR' is used only for C++ 25508 programs. 25509 25510 The definition should be an initializer for an array of structures. 25511 Each array element should have four elements: the directory name (a 25512 string constant), the component name (also a string constant), a 25513 flag for C++-only directories, and a flag showing that the 25514 includes in the directory don't need to be wrapped in `extern `C'' 25515 when compiling C++. Mark the end of the array with a null element. 25516 25517 The component name denotes what GNU package the include file is 25518 part of, if any, in all uppercase letters. For example, it might 25519 be `GCC' or `BINUTILS'. If the package is part of a 25520 vendor-supplied operating system, code the component name as `0'. 25521 25522 For example, here is the definition used for VAX/VMS: 25523 25524 #define INCLUDE_DEFAULTS \ 25525 { \ 25526 { "GNU_GXX_INCLUDE:", "G++", 1, 1}, \ 25527 { "GNU_CC_INCLUDE:", "GCC", 0, 0}, \ 25528 { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \ 25529 { ".", 0, 0, 0}, \ 25530 { 0, 0, 0, 0} \ 25531 } 25532 25533 Here is the order of prefixes tried for exec files: 25534 25535 1. Any prefixes specified by the user with `-B'. 25536 25537 2. The environment variable `GCC_EXEC_PREFIX' or, if `GCC_EXEC_PREFIX' 25538 is not set and the compiler has not been installed in the 25539 configure-time PREFIX, the location in which the compiler has 25540 actually been installed. 25541 25542 3. The directories specified by the environment variable 25543 `COMPILER_PATH'. 25544 25545 4. The macro `STANDARD_EXEC_PREFIX', if the compiler has been 25546 installed in the configured-time PREFIX. 25547 25548 5. The location `/usr/libexec/gcc/', but only if this is a native 25549 compiler. 25550 25551 6. The location `/usr/lib/gcc/', but only if this is a native 25552 compiler. 25553 25554 7. The macro `MD_EXEC_PREFIX', if defined, but only if this is a 25555 native compiler. 25556 25557 Here is the order of prefixes tried for startfiles: 25558 25559 1. Any prefixes specified by the user with `-B'. 25560 25561 2. The environment variable `GCC_EXEC_PREFIX' or its automatically 25562 determined value based on the installed toolchain location. 25563 25564 3. The directories specified by the environment variable 25565 `LIBRARY_PATH' (or port-specific name; native only, cross 25566 compilers do not use this). 25567 25568 4. The macro `STANDARD_EXEC_PREFIX', but only if the toolchain is 25569 installed in the configured PREFIX or this is a native compiler. 25570 25571 5. The location `/usr/lib/gcc/', but only if this is a native 25572 compiler. 25573 25574 6. The macro `MD_EXEC_PREFIX', if defined, but only if this is a 25575 native compiler. 25576 25577 7. The macro `MD_STARTFILE_PREFIX', if defined, but only if this is a 25578 native compiler, or we have a target system root. 25579 25580 8. The macro `MD_STARTFILE_PREFIX_1', if defined, but only if this is 25581 a native compiler, or we have a target system root. 25582 25583 9. The macro `STANDARD_STARTFILE_PREFIX', with any sysroot 25584 modifications. If this path is relative it will be prefixed by 25585 `GCC_EXEC_PREFIX' and the machine suffix or `STANDARD_EXEC_PREFIX' 25586 and the machine suffix. 25587 25588 10. The macro `STANDARD_STARTFILE_PREFIX_1', but only if this is a 25589 native compiler, or we have a target system root. The default for 25590 this macro is `/lib/'. 25591 25592 11. The macro `STANDARD_STARTFILE_PREFIX_2', but only if this is a 25593 native compiler, or we have a target system root. The default for 25594 this macro is `/usr/lib/'. 25595 25596 25597File: gccint.info, Node: Run-time Target, Next: Per-Function Data, Prev: Driver, Up: Target Macros 25598 2559917.3 Run-time Target Specification 25600================================== 25601 25602Here are run-time target specifications. 25603 25604 -- Macro: TARGET_CPU_CPP_BUILTINS () 25605 This function-like macro expands to a block of code that defines 25606 built-in preprocessor macros and assertions for the target CPU, 25607 using the functions `builtin_define', `builtin_define_std' and 25608 `builtin_assert'. When the front end calls this macro it provides 25609 a trailing semicolon, and since it has finished command line 25610 option processing your code can use those results freely. 25611 25612 `builtin_assert' takes a string in the form you pass to the 25613 command-line option `-A', such as `cpu=mips', and creates the 25614 assertion. `builtin_define' takes a string in the form accepted 25615 by option `-D' and unconditionally defines the macro. 25616 25617 `builtin_define_std' takes a string representing the name of an 25618 object-like macro. If it doesn't lie in the user's namespace, 25619 `builtin_define_std' defines it unconditionally. Otherwise, it 25620 defines a version with two leading underscores, and another version 25621 with two leading and trailing underscores, and defines the original 25622 only if an ISO standard was not requested on the command line. For 25623 example, passing `unix' defines `__unix', `__unix__' and possibly 25624 `unix'; passing `_mips' defines `__mips', `__mips__' and possibly 25625 `_mips', and passing `_ABI64' defines only `_ABI64'. 25626 25627 You can also test for the C dialect being compiled. The variable 25628 `c_language' is set to one of `clk_c', `clk_cplusplus' or 25629 `clk_objective_c'. Note that if we are preprocessing assembler, 25630 this variable will be `clk_c' but the function-like macro 25631 `preprocessing_asm_p()' will return true, so you might want to 25632 check for that first. If you need to check for strict ANSI, the 25633 variable `flag_iso' can be used. The function-like macro 25634 `preprocessing_trad_p()' can be used to check for traditional 25635 preprocessing. 25636 25637 -- Macro: TARGET_OS_CPP_BUILTINS () 25638 Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional 25639 and is used for the target operating system instead. 25640 25641 -- Macro: TARGET_OBJFMT_CPP_BUILTINS () 25642 Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional 25643 and is used for the target object format. `elfos.h' uses this 25644 macro to define `__ELF__', so you probably do not need to define 25645 it yourself. 25646 25647 -- Variable: extern int target_flags 25648 This variable is declared in `options.h', which is included before 25649 any target-specific headers. 25650 25651 -- Target Hook: int TARGET_DEFAULT_TARGET_FLAGS 25652 This variable specifies the initial value of `target_flags'. Its 25653 default setting is 0. 25654 25655 -- Target Hook: bool TARGET_HANDLE_OPTION (size_t CODE, const char 25656 *ARG, int VALUE) 25657 This hook is called whenever the user specifies one of the 25658 target-specific options described by the `.opt' definition files 25659 (*note Options::). It has the opportunity to do some 25660 option-specific processing and should return true if the option is 25661 valid. The default definition does nothing but return true. 25662 25663 CODE specifies the `OPT_NAME' enumeration value associated with 25664 the selected option; NAME is just a rendering of the option name 25665 in which non-alphanumeric characters are replaced by underscores. 25666 ARG specifies the string argument and is null if no argument was 25667 given. If the option is flagged as a `UInteger' (*note Option 25668 properties::), VALUE is the numeric value of the argument. 25669 Otherwise VALUE is 1 if the positive form of the option was used 25670 and 0 if the "no-" form was. 25671 25672 -- Target Hook: bool TARGET_HANDLE_C_OPTION (size_t CODE, const char 25673 *ARG, int VALUE) 25674 This target hook is called whenever the user specifies one of the 25675 target-specific C language family options described by the `.opt' 25676 definition files(*note Options::). It has the opportunity to do 25677 some option-specific processing and should return true if the 25678 option is valid. The arguments are like for 25679 `TARGET_HANDLE_OPTION'. The default definition does nothing but 25680 return false. 25681 25682 In general, you should use `TARGET_HANDLE_OPTION' to handle 25683 options. However, if processing an option requires routines that 25684 are only available in the C (and related language) front ends, 25685 then you should use `TARGET_HANDLE_C_OPTION' instead. 25686 25687 -- Macro: TARGET_VERSION 25688 This macro is a C statement to print on `stderr' a string 25689 describing the particular machine description choice. Every 25690 machine description should define `TARGET_VERSION'. For example: 25691 25692 #ifdef MOTOROLA 25693 #define TARGET_VERSION \ 25694 fprintf (stderr, " (68k, Motorola syntax)"); 25695 #else 25696 #define TARGET_VERSION \ 25697 fprintf (stderr, " (68k, MIT syntax)"); 25698 #endif 25699 25700 -- Macro: OVERRIDE_OPTIONS 25701 Sometimes certain combinations of command options do not make 25702 sense on a particular target machine. You can define a macro 25703 `OVERRIDE_OPTIONS' to take account of this. This macro, if 25704 defined, is executed once just after all the command options have 25705 been parsed. 25706 25707 Don't use this macro to turn on various extra optimizations for 25708 `-O'. That is what `OPTIMIZATION_OPTIONS' is for. 25709 25710 If you need to do something whenever the optimization level is 25711 changed via the optimize attribute or pragma, see 25712 `TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE' 25713 25714 -- Target Hook: void TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE (void) 25715 This target function is similar to the macro `OVERRIDE_OPTIONS' 25716 but is called when the optimize level is changed via an attribute 25717 or pragma or when it is reset at the end of the code affected by 25718 the attribute or pragma. It is not called at the beginning of 25719 compilation when `OVERRIDE_OPTIONS' is called so if you want to 25720 perform these actions then, you should have `OVERRIDE_OPTIONS' call 25721 `TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE'. 25722 25723 -- Macro: C_COMMON_OVERRIDE_OPTIONS 25724 This is similar to `OVERRIDE_OPTIONS' but is only used in the C 25725 language frontends (C, Objective-C, C++, Objective-C++) and so can 25726 be used to alter option flag variables which only exist in those 25727 frontends. 25728 25729 -- Macro: OPTIMIZATION_OPTIONS (LEVEL, SIZE) 25730 Some machines may desire to change what optimizations are 25731 performed for various optimization levels. This macro, if 25732 defined, is executed once just after the optimization level is 25733 determined and before the remainder of the command options have 25734 been parsed. Values set in this macro are used as the default 25735 values for the other command line options. 25736 25737 LEVEL is the optimization level specified; 2 if `-O2' is 25738 specified, 1 if `-O' is specified, and 0 if neither is specified. 25739 25740 SIZE is nonzero if `-Os' is specified and zero otherwise. 25741 25742 This macro is run once at program startup and when the optimization 25743 options are changed via `#pragma GCC optimize' or by using the 25744 `optimize' attribute. 25745 25746 *Do not examine `write_symbols' in this macro!* The debugging 25747 options are not supposed to alter the generated code. 25748 25749 -- Target Hook: void TARGET_HELP (void) 25750 This hook is called in response to the user invoking 25751 `--target-help' on the command line. It gives the target a chance 25752 to display extra information on the target specific command line 25753 options found in its `.opt' file. 25754 25755 -- Macro: CAN_DEBUG_WITHOUT_FP 25756 Define this macro if debugging can be performed even without a 25757 frame pointer. If this macro is defined, GCC will turn on the 25758 `-fomit-frame-pointer' option whenever `-O' is specified. 25759 25760 25761File: gccint.info, Node: Per-Function Data, Next: Storage Layout, Prev: Run-time Target, Up: Target Macros 25762 2576317.4 Defining data structures for per-function information. 25764=========================================================== 25765 25766If the target needs to store information on a per-function basis, GCC 25767provides a macro and a couple of variables to allow this. Note, just 25768using statics to store the information is a bad idea, since GCC supports 25769nested functions, so you can be halfway through encoding one function 25770when another one comes along. 25771 25772 GCC defines a data structure called `struct function' which contains 25773all of the data specific to an individual function. This structure 25774contains a field called `machine' whose type is `struct 25775machine_function *', which can be used by targets to point to their own 25776specific data. 25777 25778 If a target needs per-function specific data it should define the type 25779`struct machine_function' and also the macro `INIT_EXPANDERS'. This 25780macro should be used to initialize the function pointer 25781`init_machine_status'. This pointer is explained below. 25782 25783 One typical use of per-function, target specific data is to create an 25784RTX to hold the register containing the function's return address. This 25785RTX can then be used to implement the `__builtin_return_address' 25786function, for level 0. 25787 25788 Note--earlier implementations of GCC used a single data area to hold 25789all of the per-function information. Thus when processing of a nested 25790function began the old per-function data had to be pushed onto a stack, 25791and when the processing was finished, it had to be popped off the 25792stack. GCC used to provide function pointers called 25793`save_machine_status' and `restore_machine_status' to handle the saving 25794and restoring of the target specific information. Since the single 25795data area approach is no longer used, these pointers are no longer 25796supported. 25797 25798 -- Macro: INIT_EXPANDERS 25799 Macro called to initialize any target specific information. This 25800 macro is called once per function, before generation of any RTL 25801 has begun. The intention of this macro is to allow the 25802 initialization of the function pointer `init_machine_status'. 25803 25804 -- Variable: void (*)(struct function *) init_machine_status 25805 If this function pointer is non-`NULL' it will be called once per 25806 function, before function compilation starts, in order to allow the 25807 target to perform any target specific initialization of the 25808 `struct function' structure. It is intended that this would be 25809 used to initialize the `machine' of that structure. 25810 25811 `struct machine_function' structures are expected to be freed by 25812 GC. Generally, any memory that they reference must be allocated 25813 by using `ggc_alloc', including the structure itself. 25814 25815 25816File: gccint.info, Node: Storage Layout, Next: Type Layout, Prev: Per-Function Data, Up: Target Macros 25817 2581817.5 Storage Layout 25819=================== 25820 25821Note that the definitions of the macros in this table which are sizes or 25822alignments measured in bits do not need to be constant. They can be C 25823expressions that refer to static variables, such as the `target_flags'. 25824*Note Run-time Target::. 25825 25826 -- Macro: BITS_BIG_ENDIAN 25827 Define this macro to have the value 1 if the most significant bit 25828 in a byte has the lowest number; otherwise define it to have the 25829 value zero. This means that bit-field instructions count from the 25830 most significant bit. If the machine has no bit-field 25831 instructions, then this must still be defined, but it doesn't 25832 matter which value it is defined to. This macro need not be a 25833 constant. 25834 25835 This macro does not affect the way structure fields are packed into 25836 bytes or words; that is controlled by `BYTES_BIG_ENDIAN'. 25837 25838 -- Macro: BYTES_BIG_ENDIAN 25839 Define this macro to have the value 1 if the most significant byte 25840 in a word has the lowest number. This macro need not be a 25841 constant. 25842 25843 -- Macro: WORDS_BIG_ENDIAN 25844 Define this macro to have the value 1 if, in a multiword object, 25845 the most significant word has the lowest number. This applies to 25846 both memory locations and registers; GCC fundamentally assumes 25847 that the order of words in memory is the same as the order in 25848 registers. This macro need not be a constant. 25849 25850 -- Macro: LIBGCC2_WORDS_BIG_ENDIAN 25851 Define this macro if `WORDS_BIG_ENDIAN' is not constant. This 25852 must be a constant value with the same meaning as 25853 `WORDS_BIG_ENDIAN', which will be used only when compiling 25854 `libgcc2.c'. Typically the value will be set based on 25855 preprocessor defines. 25856 25857 -- Macro: FLOAT_WORDS_BIG_ENDIAN 25858 Define this macro to have the value 1 if `DFmode', `XFmode' or 25859 `TFmode' floating point numbers are stored in memory with the word 25860 containing the sign bit at the lowest address; otherwise define it 25861 to have the value 0. This macro need not be a constant. 25862 25863 You need not define this macro if the ordering is the same as for 25864 multi-word integers. 25865 25866 -- Macro: BITS_PER_UNIT 25867 Define this macro to be the number of bits in an addressable 25868 storage unit (byte). If you do not define this macro the default 25869 is 8. 25870 25871 -- Macro: BITS_PER_WORD 25872 Number of bits in a word. If you do not define this macro, the 25873 default is `BITS_PER_UNIT * UNITS_PER_WORD'. 25874 25875 -- Macro: MAX_BITS_PER_WORD 25876 Maximum number of bits in a word. If this is undefined, the 25877 default is `BITS_PER_WORD'. Otherwise, it is the constant value 25878 that is the largest value that `BITS_PER_WORD' can have at 25879 run-time. 25880 25881 -- Macro: UNITS_PER_WORD 25882 Number of storage units in a word; normally the size of a 25883 general-purpose register, a power of two from 1 or 8. 25884 25885 -- Macro: MIN_UNITS_PER_WORD 25886 Minimum number of units in a word. If this is undefined, the 25887 default is `UNITS_PER_WORD'. Otherwise, it is the constant value 25888 that is the smallest value that `UNITS_PER_WORD' can have at 25889 run-time. 25890 25891 -- Macro: UNITS_PER_SIMD_WORD (MODE) 25892 Number of units in the vectors that the vectorizer can produce for 25893 scalar mode MODE. The default is equal to `UNITS_PER_WORD', 25894 because the vectorizer can do some transformations even in absence 25895 of specialized SIMD hardware. 25896 25897 -- Macro: POINTER_SIZE 25898 Width of a pointer, in bits. You must specify a value no wider 25899 than the width of `Pmode'. If it is not equal to the width of 25900 `Pmode', you must define `POINTERS_EXTEND_UNSIGNED'. If you do 25901 not specify a value the default is `BITS_PER_WORD'. 25902 25903 -- Macro: POINTERS_EXTEND_UNSIGNED 25904 A C expression that determines how pointers should be extended from 25905 `ptr_mode' to either `Pmode' or `word_mode'. It is greater than 25906 zero if pointers should be zero-extended, zero if they should be 25907 sign-extended, and negative if some other sort of conversion is 25908 needed. In the last case, the extension is done by the target's 25909 `ptr_extend' instruction. 25910 25911 You need not define this macro if the `ptr_mode', `Pmode' and 25912 `word_mode' are all the same width. 25913 25914 -- Macro: PROMOTE_MODE (M, UNSIGNEDP, TYPE) 25915 A macro to update M and UNSIGNEDP when an object whose type is 25916 TYPE and which has the specified mode and signedness is to be 25917 stored in a register. This macro is only called when TYPE is a 25918 scalar type. 25919 25920 On most RISC machines, which only have operations that operate on 25921 a full register, define this macro to set M to `word_mode' if M is 25922 an integer mode narrower than `BITS_PER_WORD'. In most cases, 25923 only integer modes should be widened because wider-precision 25924 floating-point operations are usually more expensive than their 25925 narrower counterparts. 25926 25927 For most machines, the macro definition does not change UNSIGNEDP. 25928 However, some machines, have instructions that preferentially 25929 handle either signed or unsigned quantities of certain modes. For 25930 example, on the DEC Alpha, 32-bit loads from memory and 32-bit add 25931 instructions sign-extend the result to 64 bits. On such machines, 25932 set UNSIGNEDP according to which kind of extension is more 25933 efficient. 25934 25935 Do not define this macro if it would never modify M. 25936 25937 -- Target Hook: enum machine_mode TARGET_PROMOTE_FUNCTION_MODE 25938 (const_tree TYPE, enum machine_mode MODE, int *PUNSIGNEDP, 25939 const_tree FUNTYPE, int FOR_RETURN) 25940 Like `PROMOTE_MODE', but it is applied to outgoing function 25941 arguments or function return values. The target hook should 25942 return the new mode and possibly change `*PUNSIGNEDP' if the 25943 promotion should change signedness. This function is called only 25944 for scalar _or pointer_ types. 25945 25946 FOR_RETURN allows to distinguish the promotion of arguments and 25947 return values. If it is `1', a return value is being promoted and 25948 `TARGET_FUNCTION_VALUE' must perform the same promotions done here. 25949 If it is `2', the returned mode should be that of the register in 25950 which an incoming parameter is copied, or the outgoing result is 25951 computed; then the hook should return the same mode as 25952 `promote_mode', though the signedness may be different. 25953 25954 The default is to not promote arguments and return values. You can 25955 also define the hook to 25956 `default_promote_function_mode_always_promote' if you would like 25957 to apply the same rules given by `PROMOTE_MODE'. 25958 25959 -- Macro: PARM_BOUNDARY 25960 Normal alignment required for function parameters on the stack, in 25961 bits. All stack parameters receive at least this much alignment 25962 regardless of data type. On most machines, this is the same as the 25963 size of an integer. 25964 25965 -- Macro: STACK_BOUNDARY 25966 Define this macro to the minimum alignment enforced by hardware 25967 for the stack pointer on this machine. The definition is a C 25968 expression for the desired alignment (measured in bits). This 25969 value is used as a default if `PREFERRED_STACK_BOUNDARY' is not 25970 defined. On most machines, this should be the same as 25971 `PARM_BOUNDARY'. 25972 25973 -- Macro: PREFERRED_STACK_BOUNDARY 25974 Define this macro if you wish to preserve a certain alignment for 25975 the stack pointer, greater than what the hardware enforces. The 25976 definition is a C expression for the desired alignment (measured 25977 in bits). This macro must evaluate to a value equal to or larger 25978 than `STACK_BOUNDARY'. 25979 25980 -- Macro: INCOMING_STACK_BOUNDARY 25981 Define this macro if the incoming stack boundary may be different 25982 from `PREFERRED_STACK_BOUNDARY'. This macro must evaluate to a 25983 value equal to or larger than `STACK_BOUNDARY'. 25984 25985 -- Macro: FUNCTION_BOUNDARY 25986 Alignment required for a function entry point, in bits. 25987 25988 -- Macro: BIGGEST_ALIGNMENT 25989 Biggest alignment that any data type can require on this machine, 25990 in bits. Note that this is not the biggest alignment that is 25991 supported, just the biggest alignment that, when violated, may 25992 cause a fault. 25993 25994 -- Macro: MALLOC_ABI_ALIGNMENT 25995 Alignment, in bits, a C conformant malloc implementation has to 25996 provide. If not defined, the default value is `BITS_PER_WORD'. 25997 25998 -- Macro: ATTRIBUTE_ALIGNED_VALUE 25999 Alignment used by the `__attribute__ ((aligned))' construct. If 26000 not defined, the default value is `BIGGEST_ALIGNMENT'. 26001 26002 -- Macro: MINIMUM_ATOMIC_ALIGNMENT 26003 If defined, the smallest alignment, in bits, that can be given to 26004 an object that can be referenced in one operation, without 26005 disturbing any nearby object. Normally, this is `BITS_PER_UNIT', 26006 but may be larger on machines that don't have byte or half-word 26007 store operations. 26008 26009 -- Macro: BIGGEST_FIELD_ALIGNMENT 26010 Biggest alignment that any structure or union field can require on 26011 this machine, in bits. If defined, this overrides 26012 `BIGGEST_ALIGNMENT' for structure and union fields only, unless 26013 the field alignment has been set by the `__attribute__ ((aligned 26014 (N)))' construct. 26015 26016 -- Macro: ADJUST_FIELD_ALIGN (FIELD, COMPUTED) 26017 An expression for the alignment of a structure field FIELD if the 26018 alignment computed in the usual way (including applying of 26019 `BIGGEST_ALIGNMENT' and `BIGGEST_FIELD_ALIGNMENT' to the 26020 alignment) is COMPUTED. It overrides alignment only if the field 26021 alignment has not been set by the `__attribute__ ((aligned (N)))' 26022 construct. 26023 26024 -- Macro: MAX_STACK_ALIGNMENT 26025 Biggest stack alignment guaranteed by the backend. Use this macro 26026 to specify the maximum alignment of a variable on stack. 26027 26028 If not defined, the default value is `STACK_BOUNDARY'. 26029 26030 26031 -- Macro: MAX_OFILE_ALIGNMENT 26032 Biggest alignment supported by the object file format of this 26033 machine. Use this macro to limit the alignment which can be 26034 specified using the `__attribute__ ((aligned (N)))' construct. If 26035 not defined, the default value is `BIGGEST_ALIGNMENT'. 26036 26037 On systems that use ELF, the default (in `config/elfos.h') is the 26038 largest supported 32-bit ELF section alignment representable on a 26039 32-bit host e.g. `(((unsigned HOST_WIDEST_INT) 1 << 28) * 8)'. On 26040 32-bit ELF the largest supported section alignment in bits is 26041 `(0x80000000 * 8)', but this is not representable on 32-bit hosts. 26042 26043 -- Macro: DATA_ALIGNMENT (TYPE, BASIC-ALIGN) 26044 If defined, a C expression to compute the alignment for a variable 26045 in the static store. TYPE is the data type, and BASIC-ALIGN is 26046 the alignment that the object would ordinarily have. The value of 26047 this macro is used instead of that alignment to align the object. 26048 26049 If this macro is not defined, then BASIC-ALIGN is used. 26050 26051 One use of this macro is to increase alignment of medium-size data 26052 to make it all fit in fewer cache lines. Another is to cause 26053 character arrays to be word-aligned so that `strcpy' calls that 26054 copy constants to character arrays can be done inline. 26055 26056 -- Macro: CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN) 26057 If defined, a C expression to compute the alignment given to a 26058 constant that is being placed in memory. CONSTANT is the constant 26059 and BASIC-ALIGN is the alignment that the object would ordinarily 26060 have. The value of this macro is used instead of that alignment to 26061 align the object. 26062 26063 If this macro is not defined, then BASIC-ALIGN is used. 26064 26065 The typical use of this macro is to increase alignment for string 26066 constants to be word aligned so that `strcpy' calls that copy 26067 constants can be done inline. 26068 26069 -- Macro: LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN) 26070 If defined, a C expression to compute the alignment for a variable 26071 in the local store. TYPE is the data type, and BASIC-ALIGN is the 26072 alignment that the object would ordinarily have. The value of this 26073 macro is used instead of that alignment to align the object. 26074 26075 If this macro is not defined, then BASIC-ALIGN is used. 26076 26077 One use of this macro is to increase alignment of medium-size data 26078 to make it all fit in fewer cache lines. 26079 26080 -- Macro: STACK_SLOT_ALIGNMENT (TYPE, MODE, BASIC-ALIGN) 26081 If defined, a C expression to compute the alignment for stack slot. 26082 TYPE is the data type, MODE is the widest mode available, and 26083 BASIC-ALIGN is the alignment that the slot would ordinarily have. 26084 The value of this macro is used instead of that alignment to align 26085 the slot. 26086 26087 If this macro is not defined, then BASIC-ALIGN is used when TYPE 26088 is `NULL'. Otherwise, `LOCAL_ALIGNMENT' will be used. 26089 26090 This macro is to set alignment of stack slot to the maximum 26091 alignment of all possible modes which the slot may have. 26092 26093 -- Macro: LOCAL_DECL_ALIGNMENT (DECL) 26094 If defined, a C expression to compute the alignment for a local 26095 variable DECL. 26096 26097 If this macro is not defined, then `LOCAL_ALIGNMENT (TREE_TYPE 26098 (DECL), DECL_ALIGN (DECL))' is used. 26099 26100 One use of this macro is to increase alignment of medium-size data 26101 to make it all fit in fewer cache lines. 26102 26103 -- Macro: MINIMUM_ALIGNMENT (EXP, MODE, ALIGN) 26104 If defined, a C expression to compute the minimum required 26105 alignment for dynamic stack realignment purposes for EXP (a type 26106 or decl), MODE, assuming normal alignment ALIGN. 26107 26108 If this macro is not defined, then ALIGN will be used. 26109 26110 -- Macro: EMPTY_FIELD_BOUNDARY 26111 Alignment in bits to be given to a structure bit-field that 26112 follows an empty field such as `int : 0;'. 26113 26114 If `PCC_BITFIELD_TYPE_MATTERS' is true, it overrides this macro. 26115 26116 -- Macro: STRUCTURE_SIZE_BOUNDARY 26117 Number of bits which any structure or union's size must be a 26118 multiple of. Each structure or union's size is rounded up to a 26119 multiple of this. 26120 26121 If you do not define this macro, the default is the same as 26122 `BITS_PER_UNIT'. 26123 26124 -- Macro: STRICT_ALIGNMENT 26125 Define this macro to be the value 1 if instructions will fail to 26126 work if given data not on the nominal alignment. If instructions 26127 will merely go slower in that case, define this macro as 0. 26128 26129 -- Macro: PCC_BITFIELD_TYPE_MATTERS 26130 Define this if you wish to imitate the way many other C compilers 26131 handle alignment of bit-fields and the structures that contain 26132 them. 26133 26134 The behavior is that the type written for a named bit-field (`int', 26135 `short', or other integer type) imposes an alignment for the entire 26136 structure, as if the structure really did contain an ordinary 26137 field of that type. In addition, the bit-field is placed within 26138 the structure so that it would fit within such a field, not 26139 crossing a boundary for it. 26140 26141 Thus, on most machines, a named bit-field whose type is written as 26142 `int' would not cross a four-byte boundary, and would force 26143 four-byte alignment for the whole structure. (The alignment used 26144 may not be four bytes; it is controlled by the other alignment 26145 parameters.) 26146 26147 An unnamed bit-field will not affect the alignment of the 26148 containing structure. 26149 26150 If the macro is defined, its definition should be a C expression; 26151 a nonzero value for the expression enables this behavior. 26152 26153 Note that if this macro is not defined, or its value is zero, some 26154 bit-fields may cross more than one alignment boundary. The 26155 compiler can support such references if there are `insv', `extv', 26156 and `extzv' insns that can directly reference memory. 26157 26158 The other known way of making bit-fields work is to define 26159 `STRUCTURE_SIZE_BOUNDARY' as large as `BIGGEST_ALIGNMENT'. Then 26160 every structure can be accessed with fullwords. 26161 26162 Unless the machine has bit-field instructions or you define 26163 `STRUCTURE_SIZE_BOUNDARY' that way, you must define 26164 `PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value. 26165 26166 If your aim is to make GCC use the same conventions for laying out 26167 bit-fields as are used by another compiler, here is how to 26168 investigate what the other compiler does. Compile and run this 26169 program: 26170 26171 struct foo1 26172 { 26173 char x; 26174 char :0; 26175 char y; 26176 }; 26177 26178 struct foo2 26179 { 26180 char x; 26181 int :0; 26182 char y; 26183 }; 26184 26185 main () 26186 { 26187 printf ("Size of foo1 is %d\n", 26188 sizeof (struct foo1)); 26189 printf ("Size of foo2 is %d\n", 26190 sizeof (struct foo2)); 26191 exit (0); 26192 } 26193 26194 If this prints 2 and 5, then the compiler's behavior is what you 26195 would get from `PCC_BITFIELD_TYPE_MATTERS'. 26196 26197 -- Macro: BITFIELD_NBYTES_LIMITED 26198 Like `PCC_BITFIELD_TYPE_MATTERS' except that its effect is limited 26199 to aligning a bit-field within the structure. 26200 26201 -- Target Hook: bool TARGET_ALIGN_ANON_BITFIELD (void) 26202 When `PCC_BITFIELD_TYPE_MATTERS' is true this hook will determine 26203 whether unnamed bitfields affect the alignment of the containing 26204 structure. The hook should return true if the structure should 26205 inherit the alignment requirements of an unnamed bitfield's type. 26206 26207 -- Target Hook: bool TARGET_NARROW_VOLATILE_BITFIELD (void) 26208 This target hook should return `true' if accesses to volatile 26209 bitfields should use the narrowest mode possible. It should 26210 return `false' if these accesses should use the bitfield container 26211 type. 26212 26213 The default is `!TARGET_STRICT_ALIGN'. 26214 26215 -- Macro: MEMBER_TYPE_FORCES_BLK (FIELD, MODE) 26216 Return 1 if a structure or array containing FIELD should be 26217 accessed using `BLKMODE'. 26218 26219 If FIELD is the only field in the structure, MODE is its mode, 26220 otherwise MODE is VOIDmode. MODE is provided in the case where 26221 structures of one field would require the structure's mode to 26222 retain the field's mode. 26223 26224 Normally, this is not needed. 26225 26226 -- Macro: ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED) 26227 Define this macro as an expression for the alignment of a type 26228 (given by TYPE as a tree node) if the alignment computed in the 26229 usual way is COMPUTED and the alignment explicitly specified was 26230 SPECIFIED. 26231 26232 The default is to use SPECIFIED if it is larger; otherwise, use 26233 the smaller of COMPUTED and `BIGGEST_ALIGNMENT' 26234 26235 -- Macro: MAX_FIXED_MODE_SIZE 26236 An integer expression for the size in bits of the largest integer 26237 machine mode that should actually be used. All integer machine 26238 modes of this size or smaller can be used for structures and 26239 unions with the appropriate sizes. If this macro is undefined, 26240 `GET_MODE_BITSIZE (DImode)' is assumed. 26241 26242 -- Macro: STACK_SAVEAREA_MODE (SAVE_LEVEL) 26243 If defined, an expression of type `enum machine_mode' that 26244 specifies the mode of the save area operand of a 26245 `save_stack_LEVEL' named pattern (*note Standard Names::). 26246 SAVE_LEVEL is one of `SAVE_BLOCK', `SAVE_FUNCTION', or 26247 `SAVE_NONLOCAL' and selects which of the three named patterns is 26248 having its mode specified. 26249 26250 You need not define this macro if it always returns `Pmode'. You 26251 would most commonly define this macro if the `save_stack_LEVEL' 26252 patterns need to support both a 32- and a 64-bit mode. 26253 26254 -- Macro: STACK_SIZE_MODE 26255 If defined, an expression of type `enum machine_mode' that 26256 specifies the mode of the size increment operand of an 26257 `allocate_stack' named pattern (*note Standard Names::). 26258 26259 You need not define this macro if it always returns `word_mode'. 26260 You would most commonly define this macro if the `allocate_stack' 26261 pattern needs to support both a 32- and a 64-bit mode. 26262 26263 -- Target Hook: enum machine_mode TARGET_LIBGCC_CMP_RETURN_MODE (void) 26264 This target hook should return the mode to be used for the return 26265 value of compare instructions expanded to libgcc calls. If not 26266 defined `word_mode' is returned which is the right choice for a 26267 majority of targets. 26268 26269 -- Target Hook: enum machine_mode TARGET_LIBGCC_SHIFT_COUNT_MODE (void) 26270 This target hook should return the mode to be used for the shift 26271 count operand of shift instructions expanded to libgcc calls. If 26272 not defined `word_mode' is returned which is the right choice for 26273 a majority of targets. 26274 26275 -- Target Hook: enum machine_mode TARGET_UNWIND_WORD_MODE (void) 26276 Return machine mode to be used for `_Unwind_Word' type. The 26277 default is to use `word_mode'. 26278 26279 -- Macro: ROUND_TOWARDS_ZERO 26280 If defined, this macro should be true if the prevailing rounding 26281 mode is towards zero. 26282 26283 Defining this macro only affects the way `libgcc.a' emulates 26284 floating-point arithmetic. 26285 26286 Not defining this macro is equivalent to returning zero. 26287 26288 -- Macro: LARGEST_EXPONENT_IS_NORMAL (SIZE) 26289 This macro should return true if floats with SIZE bits do not have 26290 a NaN or infinity representation, but use the largest exponent for 26291 normal numbers instead. 26292 26293 Defining this macro only affects the way `libgcc.a' emulates 26294 floating-point arithmetic. 26295 26296 The default definition of this macro returns false for all sizes. 26297 26298 -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (const_tree 26299 RECORD_TYPE) 26300 This target hook returns `true' if bit-fields in the given 26301 RECORD_TYPE are to be laid out following the rules of Microsoft 26302 Visual C/C++, namely: (i) a bit-field won't share the same storage 26303 unit with the previous bit-field if their underlying types have 26304 different sizes, and the bit-field will be aligned to the highest 26305 alignment of the underlying types of itself and of the previous 26306 bit-field; (ii) a zero-sized bit-field will affect the alignment of 26307 the whole enclosing structure, even if it is unnamed; except that 26308 (iii) a zero-sized bit-field will be disregarded unless it follows 26309 another bit-field of nonzero size. If this hook returns `true', 26310 other macros that control bit-field layout are ignored. 26311 26312 When a bit-field is inserted into a packed record, the whole size 26313 of the underlying type is used by one or more same-size adjacent 26314 bit-fields (that is, if its long:3, 32 bits is used in the record, 26315 and any additional adjacent long bit-fields are packed into the 26316 same chunk of 32 bits. However, if the size changes, a new field 26317 of that size is allocated). In an unpacked record, this is the 26318 same as using alignment, but not equivalent when packing. 26319 26320 If both MS bit-fields and `__attribute__((packed))' are used, the 26321 latter will take precedence. If `__attribute__((packed))' is used 26322 on a single field when MS bit-fields are in use, it will take 26323 precedence for that field, but the alignment of the rest of the 26324 structure may affect its placement. 26325 26326 -- Target Hook: bool TARGET_DECIMAL_FLOAT_SUPPORTED_P (void) 26327 Returns true if the target supports decimal floating point. 26328 26329 -- Target Hook: bool TARGET_FIXED_POINT_SUPPORTED_P (void) 26330 Returns true if the target supports fixed-point arithmetic. 26331 26332 -- Target Hook: void TARGET_EXPAND_TO_RTL_HOOK (void) 26333 This hook is called just before expansion into rtl, allowing the 26334 target to perform additional initializations or analysis before 26335 the expansion. For example, the rs6000 port uses it to allocate a 26336 scratch stack slot for use in copying SDmode values between memory 26337 and floating point registers whenever the function being expanded 26338 has any SDmode usage. 26339 26340 -- Target Hook: void TARGET_INSTANTIATE_DECLS (void) 26341 This hook allows the backend to perform additional instantiations 26342 on rtl that are not actually in any insns yet, but will be later. 26343 26344 -- Target Hook: const char * TARGET_MANGLE_TYPE (const_tree TYPE) 26345 If your target defines any fundamental types, or any types your 26346 target uses should be mangled differently from the default, define 26347 this hook to return the appropriate encoding for these types as 26348 part of a C++ mangled name. The TYPE argument is the tree 26349 structure representing the type to be mangled. The hook may be 26350 applied to trees which are not target-specific fundamental types; 26351 it should return `NULL' for all such types, as well as arguments 26352 it does not recognize. If the return value is not `NULL', it must 26353 point to a statically-allocated string constant. 26354 26355 Target-specific fundamental types might be new fundamental types or 26356 qualified versions of ordinary fundamental types. Encode new 26357 fundamental types as `u N NAME', where NAME is the name used for 26358 the type in source code, and N is the length of NAME in decimal. 26359 Encode qualified versions of ordinary types as `U N NAME CODE', 26360 where NAME is the name used for the type qualifier in source code, 26361 N is the length of NAME as above, and CODE is the code used to 26362 represent the unqualified version of this type. (See 26363 `write_builtin_type' in `cp/mangle.c' for the list of codes.) In 26364 both cases the spaces are for clarity; do not include any spaces 26365 in your string. 26366 26367 This hook is applied to types prior to typedef resolution. If the 26368 mangled name for a particular type depends only on that type's 26369 main variant, you can perform typedef resolution yourself using 26370 `TYPE_MAIN_VARIANT' before mangling. 26371 26372 The default version of this hook always returns `NULL', which is 26373 appropriate for a target that does not define any new fundamental 26374 types. 26375 26376 26377File: gccint.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros 26378 2637917.6 Layout of Source Language Data Types 26380========================================= 26381 26382These macros define the sizes and other characteristics of the standard 26383basic data types used in programs being compiled. Unlike the macros in 26384the previous section, these apply to specific features of C and related 26385languages, rather than to fundamental aspects of storage layout. 26386 26387 -- Macro: INT_TYPE_SIZE 26388 A C expression for the size in bits of the type `int' on the 26389 target machine. If you don't define this, the default is one word. 26390 26391 -- Macro: SHORT_TYPE_SIZE 26392 A C expression for the size in bits of the type `short' on the 26393 target machine. If you don't define this, the default is half a 26394 word. (If this would be less than one storage unit, it is rounded 26395 up to one unit.) 26396 26397 -- Macro: LONG_TYPE_SIZE 26398 A C expression for the size in bits of the type `long' on the 26399 target machine. If you don't define this, the default is one word. 26400 26401 -- Macro: ADA_LONG_TYPE_SIZE 26402 On some machines, the size used for the Ada equivalent of the type 26403 `long' by a native Ada compiler differs from that used by C. In 26404 that situation, define this macro to be a C expression to be used 26405 for the size of that type. If you don't define this, the default 26406 is the value of `LONG_TYPE_SIZE'. 26407 26408 -- Macro: LONG_LONG_TYPE_SIZE 26409 A C expression for the size in bits of the type `long long' on the 26410 target machine. If you don't define this, the default is two 26411 words. If you want to support GNU Ada on your machine, the value 26412 of this macro must be at least 64. 26413 26414 -- Macro: CHAR_TYPE_SIZE 26415 A C expression for the size in bits of the type `char' on the 26416 target machine. If you don't define this, the default is 26417 `BITS_PER_UNIT'. 26418 26419 -- Macro: BOOL_TYPE_SIZE 26420 A C expression for the size in bits of the C++ type `bool' and C99 26421 type `_Bool' on the target machine. If you don't define this, and 26422 you probably shouldn't, the default is `CHAR_TYPE_SIZE'. 26423 26424 -- Macro: FLOAT_TYPE_SIZE 26425 A C expression for the size in bits of the type `float' on the 26426 target machine. If you don't define this, the default is one word. 26427 26428 -- Macro: DOUBLE_TYPE_SIZE 26429 A C expression for the size in bits of the type `double' on the 26430 target machine. If you don't define this, the default is two 26431 words. 26432 26433 -- Macro: LONG_DOUBLE_TYPE_SIZE 26434 A C expression for the size in bits of the type `long double' on 26435 the target machine. If you don't define this, the default is two 26436 words. 26437 26438 -- Macro: SHORT_FRACT_TYPE_SIZE 26439 A C expression for the size in bits of the type `short _Fract' on 26440 the target machine. If you don't define this, the default is 26441 `BITS_PER_UNIT'. 26442 26443 -- Macro: FRACT_TYPE_SIZE 26444 A C expression for the size in bits of the type `_Fract' on the 26445 target machine. If you don't define this, the default is 26446 `BITS_PER_UNIT * 2'. 26447 26448 -- Macro: LONG_FRACT_TYPE_SIZE 26449 A C expression for the size in bits of the type `long _Fract' on 26450 the target machine. If you don't define this, the default is 26451 `BITS_PER_UNIT * 4'. 26452 26453 -- Macro: LONG_LONG_FRACT_TYPE_SIZE 26454 A C expression for the size in bits of the type `long long _Fract' 26455 on the target machine. If you don't define this, the default is 26456 `BITS_PER_UNIT * 8'. 26457 26458 -- Macro: SHORT_ACCUM_TYPE_SIZE 26459 A C expression for the size in bits of the type `short _Accum' on 26460 the target machine. If you don't define this, the default is 26461 `BITS_PER_UNIT * 2'. 26462 26463 -- Macro: ACCUM_TYPE_SIZE 26464 A C expression for the size in bits of the type `_Accum' on the 26465 target machine. If you don't define this, the default is 26466 `BITS_PER_UNIT * 4'. 26467 26468 -- Macro: LONG_ACCUM_TYPE_SIZE 26469 A C expression for the size in bits of the type `long _Accum' on 26470 the target machine. If you don't define this, the default is 26471 `BITS_PER_UNIT * 8'. 26472 26473 -- Macro: LONG_LONG_ACCUM_TYPE_SIZE 26474 A C expression for the size in bits of the type `long long _Accum' 26475 on the target machine. If you don't define this, the default is 26476 `BITS_PER_UNIT * 16'. 26477 26478 -- Macro: LIBGCC2_LONG_DOUBLE_TYPE_SIZE 26479 Define this macro if `LONG_DOUBLE_TYPE_SIZE' is not constant or if 26480 you want routines in `libgcc2.a' for a size other than 26481 `LONG_DOUBLE_TYPE_SIZE'. If you don't define this, the default is 26482 `LONG_DOUBLE_TYPE_SIZE'. 26483 26484 -- Macro: LIBGCC2_HAS_DF_MODE 26485 Define this macro if neither `LIBGCC2_DOUBLE_TYPE_SIZE' nor 26486 `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is `DFmode' but you want `DFmode' 26487 routines in `libgcc2.a' anyway. If you don't define this and 26488 either `LIBGCC2_DOUBLE_TYPE_SIZE' or 26489 `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 64 then the default is 1, 26490 otherwise it is 0. 26491 26492 -- Macro: LIBGCC2_HAS_XF_MODE 26493 Define this macro if `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not 26494 `XFmode' but you want `XFmode' routines in `libgcc2.a' anyway. If 26495 you don't define this and `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 80 26496 then the default is 1, otherwise it is 0. 26497 26498 -- Macro: LIBGCC2_HAS_TF_MODE 26499 Define this macro if `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not 26500 `TFmode' but you want `TFmode' routines in `libgcc2.a' anyway. If 26501 you don't define this and `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 128 26502 then the default is 1, otherwise it is 0. 26503 26504 -- Macro: SF_SIZE 26505 -- Macro: DF_SIZE 26506 -- Macro: XF_SIZE 26507 -- Macro: TF_SIZE 26508 Define these macros to be the size in bits of the mantissa of 26509 `SFmode', `DFmode', `XFmode' and `TFmode' values, if the defaults 26510 in `libgcc2.h' are inappropriate. By default, `FLT_MANT_DIG' is 26511 used for `SF_SIZE', `LDBL_MANT_DIG' for `XF_SIZE' and `TF_SIZE', 26512 and `DBL_MANT_DIG' or `LDBL_MANT_DIG' for `DF_SIZE' according to 26513 whether `LIBGCC2_DOUBLE_TYPE_SIZE' or 26514 `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 64. 26515 26516 -- Macro: TARGET_FLT_EVAL_METHOD 26517 A C expression for the value for `FLT_EVAL_METHOD' in `float.h', 26518 assuming, if applicable, that the floating-point control word is 26519 in its default state. If you do not define this macro the value of 26520 `FLT_EVAL_METHOD' will be zero. 26521 26522 -- Macro: WIDEST_HARDWARE_FP_SIZE 26523 A C expression for the size in bits of the widest floating-point 26524 format supported by the hardware. If you define this macro, you 26525 must specify a value less than or equal to the value of 26526 `LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the 26527 value of `LONG_DOUBLE_TYPE_SIZE' is the default. 26528 26529 -- Macro: DEFAULT_SIGNED_CHAR 26530 An expression whose value is 1 or 0, according to whether the type 26531 `char' should be signed or unsigned by default. The user can 26532 always override this default with the options `-fsigned-char' and 26533 `-funsigned-char'. 26534 26535 -- Target Hook: bool TARGET_DEFAULT_SHORT_ENUMS (void) 26536 This target hook should return true if the compiler should give an 26537 `enum' type only as many bytes as it takes to represent the range 26538 of possible values of that type. It should return false if all 26539 `enum' types should be allocated like `int'. 26540 26541 The default is to return false. 26542 26543 -- Macro: SIZE_TYPE 26544 A C expression for a string describing the name of the data type 26545 to use for size values. The typedef name `size_t' is defined 26546 using the contents of the string. 26547 26548 The string can contain more than one keyword. If so, separate 26549 them with spaces, and write first any length keyword, then 26550 `unsigned' if appropriate, and finally `int'. The string must 26551 exactly match one of the data type names defined in the function 26552 `init_decl_processing' in the file `c-decl.c'. You may not omit 26553 `int' or change the order--that would cause the compiler to crash 26554 on startup. 26555 26556 If you don't define this macro, the default is `"long unsigned 26557 int"'. 26558 26559 -- Macro: PTRDIFF_TYPE 26560 A C expression for a string describing the name of the data type 26561 to use for the result of subtracting two pointers. The typedef 26562 name `ptrdiff_t' is defined using the contents of the string. See 26563 `SIZE_TYPE' above for more information. 26564 26565 If you don't define this macro, the default is `"long int"'. 26566 26567 -- Macro: WCHAR_TYPE 26568 A C expression for a string describing the name of the data type 26569 to use for wide characters. The typedef name `wchar_t' is defined 26570 using the contents of the string. See `SIZE_TYPE' above for more 26571 information. 26572 26573 If you don't define this macro, the default is `"int"'. 26574 26575 -- Macro: WCHAR_TYPE_SIZE 26576 A C expression for the size in bits of the data type for wide 26577 characters. This is used in `cpp', which cannot make use of 26578 `WCHAR_TYPE'. 26579 26580 -- Macro: WINT_TYPE 26581 A C expression for a string describing the name of the data type to 26582 use for wide characters passed to `printf' and returned from 26583 `getwc'. The typedef name `wint_t' is defined using the contents 26584 of the string. See `SIZE_TYPE' above for more information. 26585 26586 If you don't define this macro, the default is `"unsigned int"'. 26587 26588 -- Macro: INTMAX_TYPE 26589 A C expression for a string describing the name of the data type 26590 that can represent any value of any standard or extended signed 26591 integer type. The typedef name `intmax_t' is defined using the 26592 contents of the string. See `SIZE_TYPE' above for more 26593 information. 26594 26595 If you don't define this macro, the default is the first of 26596 `"int"', `"long int"', or `"long long int"' that has as much 26597 precision as `long long int'. 26598 26599 -- Macro: UINTMAX_TYPE 26600 A C expression for a string describing the name of the data type 26601 that can represent any value of any standard or extended unsigned 26602 integer type. The typedef name `uintmax_t' is defined using the 26603 contents of the string. See `SIZE_TYPE' above for more 26604 information. 26605 26606 If you don't define this macro, the default is the first of 26607 `"unsigned int"', `"long unsigned int"', or `"long long unsigned 26608 int"' that has as much precision as `long long unsigned int'. 26609 26610 -- Macro: SIG_ATOMIC_TYPE 26611 -- Macro: INT8_TYPE 26612 -- Macro: INT16_TYPE 26613 -- Macro: INT32_TYPE 26614 -- Macro: INT64_TYPE 26615 -- Macro: UINT8_TYPE 26616 -- Macro: UINT16_TYPE 26617 -- Macro: UINT32_TYPE 26618 -- Macro: UINT64_TYPE 26619 -- Macro: INT_LEAST8_TYPE 26620 -- Macro: INT_LEAST16_TYPE 26621 -- Macro: INT_LEAST32_TYPE 26622 -- Macro: INT_LEAST64_TYPE 26623 -- Macro: UINT_LEAST8_TYPE 26624 -- Macro: UINT_LEAST16_TYPE 26625 -- Macro: UINT_LEAST32_TYPE 26626 -- Macro: UINT_LEAST64_TYPE 26627 -- Macro: INT_FAST8_TYPE 26628 -- Macro: INT_FAST16_TYPE 26629 -- Macro: INT_FAST32_TYPE 26630 -- Macro: INT_FAST64_TYPE 26631 -- Macro: UINT_FAST8_TYPE 26632 -- Macro: UINT_FAST16_TYPE 26633 -- Macro: UINT_FAST32_TYPE 26634 -- Macro: UINT_FAST64_TYPE 26635 -- Macro: INTPTR_TYPE 26636 -- Macro: UINTPTR_TYPE 26637 C expressions for the standard types `sig_atomic_t', `int8_t', 26638 `int16_t', `int32_t', `int64_t', `uint8_t', `uint16_t', 26639 `uint32_t', `uint64_t', `int_least8_t', `int_least16_t', 26640 `int_least32_t', `int_least64_t', `uint_least8_t', 26641 `uint_least16_t', `uint_least32_t', `uint_least64_t', 26642 `int_fast8_t', `int_fast16_t', `int_fast32_t', `int_fast64_t', 26643 `uint_fast8_t', `uint_fast16_t', `uint_fast32_t', `uint_fast64_t', 26644 `intptr_t', and `uintptr_t'. See `SIZE_TYPE' above for more 26645 information. 26646 26647 If any of these macros evaluates to a null pointer, the 26648 corresponding type is not supported; if GCC is configured to 26649 provide `<stdint.h>' in such a case, the header provided may not 26650 conform to C99, depending on the type in question. The defaults 26651 for all of these macros are null pointers. 26652 26653 -- Macro: TARGET_PTRMEMFUNC_VBIT_LOCATION 26654 The C++ compiler represents a pointer-to-member-function with a 26655 struct that looks like: 26656 26657 struct { 26658 union { 26659 void (*fn)(); 26660 ptrdiff_t vtable_index; 26661 }; 26662 ptrdiff_t delta; 26663 }; 26664 26665 The C++ compiler must use one bit to indicate whether the function 26666 that will be called through a pointer-to-member-function is 26667 virtual. Normally, we assume that the low-order bit of a function 26668 pointer must always be zero. Then, by ensuring that the 26669 vtable_index is odd, we can distinguish which variant of the union 26670 is in use. But, on some platforms function pointers can be odd, 26671 and so this doesn't work. In that case, we use the low-order bit 26672 of the `delta' field, and shift the remainder of the `delta' field 26673 to the left. 26674 26675 GCC will automatically make the right selection about where to 26676 store this bit using the `FUNCTION_BOUNDARY' setting for your 26677 platform. However, some platforms such as ARM/Thumb have 26678 `FUNCTION_BOUNDARY' set such that functions always start at even 26679 addresses, but the lowest bit of pointers to functions indicate 26680 whether the function at that address is in ARM or Thumb mode. If 26681 this is the case of your architecture, you should define this 26682 macro to `ptrmemfunc_vbit_in_delta'. 26683 26684 In general, you should not have to define this macro. On 26685 architectures in which function addresses are always even, 26686 according to `FUNCTION_BOUNDARY', GCC will automatically define 26687 this macro to `ptrmemfunc_vbit_in_pfn'. 26688 26689 -- Macro: TARGET_VTABLE_USES_DESCRIPTORS 26690 Normally, the C++ compiler uses function pointers in vtables. This 26691 macro allows the target to change to use "function descriptors" 26692 instead. Function descriptors are found on targets for whom a 26693 function pointer is actually a small data structure. Normally the 26694 data structure consists of the actual code address plus a data 26695 pointer to which the function's data is relative. 26696 26697 If vtables are used, the value of this macro should be the number 26698 of words that the function descriptor occupies. 26699 26700 -- Macro: TARGET_VTABLE_ENTRY_ALIGN 26701 By default, the vtable entries are void pointers, the so the 26702 alignment is the same as pointer alignment. The value of this 26703 macro specifies the alignment of the vtable entry in bits. It 26704 should be defined only when special alignment is necessary. */ 26705 26706 -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE 26707 There are a few non-descriptor entries in the vtable at offsets 26708 below zero. If these entries must be padded (say, to preserve the 26709 alignment specified by `TARGET_VTABLE_ENTRY_ALIGN'), set this to 26710 the number of words in each data entry. 26711 26712 26713File: gccint.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros 26714 2671517.7 Register Usage 26716=================== 26717 26718This section explains how to describe what registers the target machine 26719has, and how (in general) they can be used. 26720 26721 The description of which registers a specific instruction can use is 26722done with register classes; see *note Register Classes::. For 26723information on using registers to access a stack frame, see *note Frame 26724Registers::. For passing values in registers, see *note Register 26725Arguments::. For returning values in registers, see *note Scalar 26726Return::. 26727 26728* Menu: 26729 26730* Register Basics:: Number and kinds of registers. 26731* Allocation Order:: Order in which registers are allocated. 26732* Values in Registers:: What kinds of values each reg can hold. 26733* Leaf Functions:: Renumbering registers for leaf functions. 26734* Stack Registers:: Handling a register stack such as 80387. 26735 26736 26737File: gccint.info, Node: Register Basics, Next: Allocation Order, Up: Registers 26738 2673917.7.1 Basic Characteristics of Registers 26740----------------------------------------- 26741 26742Registers have various characteristics. 26743 26744 -- Macro: FIRST_PSEUDO_REGISTER 26745 Number of hardware registers known to the compiler. They receive 26746 numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first 26747 pseudo register's number really is assigned the number 26748 `FIRST_PSEUDO_REGISTER'. 26749 26750 -- Macro: FIXED_REGISTERS 26751 An initializer that says which registers are used for fixed 26752 purposes all throughout the compiled code and are therefore not 26753 available for general allocation. These would include the stack 26754 pointer, the frame pointer (except on machines where that can be 26755 used as a general register when no frame pointer is needed), the 26756 program counter on machines where that is considered one of the 26757 addressable registers, and any other numbered register with a 26758 standard use. 26759 26760 This information is expressed as a sequence of numbers, separated 26761 by commas and surrounded by braces. The Nth number is 1 if 26762 register N is fixed, 0 otherwise. 26763 26764 The table initialized from this macro, and the table initialized by 26765 the following one, may be overridden at run time either 26766 automatically, by the actions of the macro 26767 `CONDITIONAL_REGISTER_USAGE', or by the user with the command 26768 options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'. 26769 26770 -- Macro: CALL_USED_REGISTERS 26771 Like `FIXED_REGISTERS' but has 1 for each register that is 26772 clobbered (in general) by function calls as well as for fixed 26773 registers. This macro therefore identifies the registers that are 26774 not available for general allocation of values that must live 26775 across function calls. 26776 26777 If a register has 0 in `CALL_USED_REGISTERS', the compiler 26778 automatically saves it on function entry and restores it on 26779 function exit, if the register is used within the function. 26780 26781 -- Macro: CALL_REALLY_USED_REGISTERS 26782 Like `CALL_USED_REGISTERS' except this macro doesn't require that 26783 the entire set of `FIXED_REGISTERS' be included. 26784 (`CALL_USED_REGISTERS' must be a superset of `FIXED_REGISTERS'). 26785 This macro is optional. If not specified, it defaults to the value 26786 of `CALL_USED_REGISTERS'. 26787 26788 -- Macro: HARD_REGNO_CALL_PART_CLOBBERED (REGNO, MODE) 26789 A C expression that is nonzero if it is not permissible to store a 26790 value of mode MODE in hard register number REGNO across a call 26791 without some part of it being clobbered. For most machines this 26792 macro need not be defined. It is only required for machines that 26793 do not preserve the entire contents of a register across a call. 26794 26795 -- Macro: CONDITIONAL_REGISTER_USAGE 26796 Zero or more C statements that may conditionally modify five 26797 variables `fixed_regs', `call_used_regs', `global_regs', 26798 `reg_names', and `reg_class_contents', to take into account any 26799 dependence of these register sets on target flags. The first three 26800 of these are of type `char []' (interpreted as Boolean vectors). 26801 `global_regs' is a `const char *[]', and `reg_class_contents' is a 26802 `HARD_REG_SET'. Before the macro is called, `fixed_regs', 26803 `call_used_regs', `reg_class_contents', and `reg_names' have been 26804 initialized from `FIXED_REGISTERS', `CALL_USED_REGISTERS', 26805 `REG_CLASS_CONTENTS', and `REGISTER_NAMES', respectively. 26806 `global_regs' has been cleared, and any `-ffixed-REG', 26807 `-fcall-used-REG' and `-fcall-saved-REG' command options have been 26808 applied. 26809 26810 You need not define this macro if it has no work to do. 26811 26812 If the usage of an entire class of registers depends on the target 26813 flags, you may indicate this to GCC by using this macro to modify 26814 `fixed_regs' and `call_used_regs' to 1 for each of the registers 26815 in the classes which should not be used by GCC. Also define the 26816 macro `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' to 26817 return `NO_REGS' if it is called with a letter for a class that 26818 shouldn't be used. 26819 26820 (However, if this class is not included in `GENERAL_REGS' and all 26821 of the insn patterns whose constraints permit this class are 26822 controlled by target switches, then GCC will automatically avoid 26823 using these registers when the target switches are opposed to 26824 them.) 26825 26826 -- Macro: INCOMING_REGNO (OUT) 26827 Define this macro if the target machine has register windows. 26828 This C expression returns the register number as seen by the 26829 called function corresponding to the register number OUT as seen 26830 by the calling function. Return OUT if register number OUT is not 26831 an outbound register. 26832 26833 -- Macro: OUTGOING_REGNO (IN) 26834 Define this macro if the target machine has register windows. 26835 This C expression returns the register number as seen by the 26836 calling function corresponding to the register number IN as seen 26837 by the called function. Return IN if register number IN is not an 26838 inbound register. 26839 26840 -- Macro: LOCAL_REGNO (REGNO) 26841 Define this macro if the target machine has register windows. 26842 This C expression returns true if the register is call-saved but 26843 is in the register window. Unlike most call-saved registers, such 26844 registers need not be explicitly restored on function exit or 26845 during non-local gotos. 26846 26847 -- Macro: PC_REGNUM 26848 If the program counter has a register number, define this as that 26849 register number. Otherwise, do not define it. 26850 26851 26852File: gccint.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers 26853 2685417.7.2 Order of Allocation of Registers 26855--------------------------------------- 26856 26857Registers are allocated in order. 26858 26859 -- Macro: REG_ALLOC_ORDER 26860 If defined, an initializer for a vector of integers, containing the 26861 numbers of hard registers in the order in which GCC should prefer 26862 to use them (from most preferred to least). 26863 26864 If this macro is not defined, registers are used lowest numbered 26865 first (all else being equal). 26866 26867 One use of this macro is on machines where the highest numbered 26868 registers must always be saved and the save-multiple-registers 26869 instruction supports only sequences of consecutive registers. On 26870 such machines, define `REG_ALLOC_ORDER' to be an initializer that 26871 lists the highest numbered allocable register first. 26872 26873 -- Macro: ORDER_REGS_FOR_LOCAL_ALLOC 26874 A C statement (sans semicolon) to choose the order in which to 26875 allocate hard registers for pseudo-registers local to a basic 26876 block. 26877 26878 Store the desired register order in the array `reg_alloc_order'. 26879 Element 0 should be the register to allocate first; element 1, the 26880 next register; and so on. 26881 26882 The macro body should not assume anything about the contents of 26883 `reg_alloc_order' before execution of the macro. 26884 26885 On most machines, it is not necessary to define this macro. 26886 26887 -- Macro: IRA_HARD_REGNO_ADD_COST_MULTIPLIER (REGNO) 26888 In some case register allocation order is not enough for the 26889 Integrated Register Allocator (IRA) to generate a good code. If 26890 this macro is defined, it should return a floating point value 26891 based on REGNO. The cost of using REGNO for a pseudo will be 26892 increased by approximately the pseudo's usage frequency times the 26893 value returned by this macro. Not defining this macro is 26894 equivalent to having it always return `0.0'. 26895 26896 On most machines, it is not necessary to define this macro. 26897 26898 26899File: gccint.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers 26900 2690117.7.3 How Values Fit in Registers 26902---------------------------------- 26903 26904This section discusses the macros that describe which kinds of values 26905(specifically, which machine modes) each register can hold, and how many 26906consecutive registers are needed for a given mode. 26907 26908 -- Macro: HARD_REGNO_NREGS (REGNO, MODE) 26909 A C expression for the number of consecutive hard registers, 26910 starting at register number REGNO, required to hold a value of mode 26911 MODE. This macro must never return zero, even if a register 26912 cannot hold the requested mode - indicate that with 26913 HARD_REGNO_MODE_OK and/or CANNOT_CHANGE_MODE_CLASS instead. 26914 26915 On a machine where all registers are exactly one word, a suitable 26916 definition of this macro is 26917 26918 #define HARD_REGNO_NREGS(REGNO, MODE) \ 26919 ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \ 26920 / UNITS_PER_WORD) 26921 26922 -- Macro: HARD_REGNO_NREGS_HAS_PADDING (REGNO, MODE) 26923 A C expression that is nonzero if a value of mode MODE, stored in 26924 memory, ends with padding that causes it to take up more space than 26925 in registers starting at register number REGNO (as determined by 26926 multiplying GCC's notion of the size of the register when 26927 containing this mode by the number of registers returned by 26928 `HARD_REGNO_NREGS'). By default this is zero. 26929 26930 For example, if a floating-point value is stored in three 32-bit 26931 registers but takes up 128 bits in memory, then this would be 26932 nonzero. 26933 26934 This macros only needs to be defined if there are cases where 26935 `subreg_get_info' would otherwise wrongly determine that a 26936 `subreg' can be represented by an offset to the register number, 26937 when in fact such a `subreg' would contain some of the padding not 26938 stored in registers and so not be representable. 26939 26940 -- Macro: HARD_REGNO_NREGS_WITH_PADDING (REGNO, MODE) 26941 For values of REGNO and MODE for which 26942 `HARD_REGNO_NREGS_HAS_PADDING' returns nonzero, a C expression 26943 returning the greater number of registers required to hold the 26944 value including any padding. In the example above, the value 26945 would be four. 26946 26947 -- Macro: REGMODE_NATURAL_SIZE (MODE) 26948 Define this macro if the natural size of registers that hold values 26949 of mode MODE is not the word size. It is a C expression that 26950 should give the natural size in bytes for the specified mode. It 26951 is used by the register allocator to try to optimize its results. 26952 This happens for example on SPARC 64-bit where the natural size of 26953 floating-point registers is still 32-bit. 26954 26955 -- Macro: HARD_REGNO_MODE_OK (REGNO, MODE) 26956 A C expression that is nonzero if it is permissible to store a 26957 value of mode MODE in hard register number REGNO (or in several 26958 registers starting with that one). For a machine where all 26959 registers are equivalent, a suitable definition is 26960 26961 #define HARD_REGNO_MODE_OK(REGNO, MODE) 1 26962 26963 You need not include code to check for the numbers of fixed 26964 registers, because the allocation mechanism considers them to be 26965 always occupied. 26966 26967 On some machines, double-precision values must be kept in even/odd 26968 register pairs. You can implement that by defining this macro to 26969 reject odd register numbers for such modes. 26970 26971 The minimum requirement for a mode to be OK in a register is that 26972 the `movMODE' instruction pattern support moves between the 26973 register and other hard register in the same class and that moving 26974 a value into the register and back out not alter it. 26975 26976 Since the same instruction used to move `word_mode' will work for 26977 all narrower integer modes, it is not necessary on any machine for 26978 `HARD_REGNO_MODE_OK' to distinguish between these modes, provided 26979 you define patterns `movhi', etc., to take advantage of this. This 26980 is useful because of the interaction between `HARD_REGNO_MODE_OK' 26981 and `MODES_TIEABLE_P'; it is very desirable for all integer modes 26982 to be tieable. 26983 26984 Many machines have special registers for floating point arithmetic. 26985 Often people assume that floating point machine modes are allowed 26986 only in floating point registers. This is not true. Any 26987 registers that can hold integers can safely _hold_ a floating 26988 point machine mode, whether or not floating arithmetic can be done 26989 on it in those registers. Integer move instructions can be used 26990 to move the values. 26991 26992 On some machines, though, the converse is true: fixed-point machine 26993 modes may not go in floating registers. This is true if the 26994 floating registers normalize any value stored in them, because 26995 storing a non-floating value there would garble it. In this case, 26996 `HARD_REGNO_MODE_OK' should reject fixed-point machine modes in 26997 floating registers. But if the floating registers do not 26998 automatically normalize, if you can store any bit pattern in one 26999 and retrieve it unchanged without a trap, then any machine mode 27000 may go in a floating register, so you can define this macro to say 27001 so. 27002 27003 The primary significance of special floating registers is rather 27004 that they are the registers acceptable in floating point arithmetic 27005 instructions. However, this is of no concern to 27006 `HARD_REGNO_MODE_OK'. You handle it by writing the proper 27007 constraints for those instructions. 27008 27009 On some machines, the floating registers are especially slow to 27010 access, so that it is better to store a value in a stack frame 27011 than in such a register if floating point arithmetic is not being 27012 done. As long as the floating registers are not in class 27013 `GENERAL_REGS', they will not be used unless some pattern's 27014 constraint asks for one. 27015 27016 -- Macro: HARD_REGNO_RENAME_OK (FROM, TO) 27017 A C expression that is nonzero if it is OK to rename a hard 27018 register FROM to another hard register TO. 27019 27020 One common use of this macro is to prevent renaming of a register 27021 to another register that is not saved by a prologue in an interrupt 27022 handler. 27023 27024 The default is always nonzero. 27025 27026 -- Macro: MODES_TIEABLE_P (MODE1, MODE2) 27027 A C expression that is nonzero if a value of mode MODE1 is 27028 accessible in mode MODE2 without copying. 27029 27030 If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R, 27031 MODE2)' are always the same for any R, then `MODES_TIEABLE_P 27032 (MODE1, MODE2)' should be nonzero. If they differ for any R, you 27033 should define this macro to return zero unless some other 27034 mechanism ensures the accessibility of the value in a narrower 27035 mode. 27036 27037 You should define this macro to return nonzero in as many cases as 27038 possible since doing so will allow GCC to perform better register 27039 allocation. 27040 27041 -- Target Hook: bool TARGET_HARD_REGNO_SCRATCH_OK (unsigned int REGNO) 27042 This target hook should return `true' if it is OK to use a hard 27043 register REGNO as scratch reg in peephole2. 27044 27045 One common use of this macro is to prevent using of a register that 27046 is not saved by a prologue in an interrupt handler. 27047 27048 The default version of this hook always returns `true'. 27049 27050 -- Macro: AVOID_CCMODE_COPIES 27051 Define this macro if the compiler should avoid copies to/from 27052 `CCmode' registers. You should only define this macro if support 27053 for copying to/from `CCmode' is incomplete. 27054 27055 27056File: gccint.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers 27057 2705817.7.4 Handling Leaf Functions 27059------------------------------ 27060 27061On some machines, a leaf function (i.e., one which makes no calls) can 27062run more efficiently if it does not make its own register window. 27063Often this means it is required to receive its arguments in the 27064registers where they are passed by the caller, instead of the registers 27065where they would normally arrive. 27066 27067 The special treatment for leaf functions generally applies only when 27068other conditions are met; for example, often they may use only those 27069registers for its own variables and temporaries. We use the term "leaf 27070function" to mean a function that is suitable for this special 27071handling, so that functions with no calls are not necessarily "leaf 27072functions". 27073 27074 GCC assigns register numbers before it knows whether the function is 27075suitable for leaf function treatment. So it needs to renumber the 27076registers in order to output a leaf function. The following macros 27077accomplish this. 27078 27079 -- Macro: LEAF_REGISTERS 27080 Name of a char vector, indexed by hard register number, which 27081 contains 1 for a register that is allowable in a candidate for leaf 27082 function treatment. 27083 27084 If leaf function treatment involves renumbering the registers, 27085 then the registers marked here should be the ones before 27086 renumbering--those that GCC would ordinarily allocate. The 27087 registers which will actually be used in the assembler code, after 27088 renumbering, should not be marked with 1 in this vector. 27089 27090 Define this macro only if the target machine offers a way to 27091 optimize the treatment of leaf functions. 27092 27093 -- Macro: LEAF_REG_REMAP (REGNO) 27094 A C expression whose value is the register number to which REGNO 27095 should be renumbered, when a function is treated as a leaf 27096 function. 27097 27098 If REGNO is a register number which should not appear in a leaf 27099 function before renumbering, then the expression should yield -1, 27100 which will cause the compiler to abort. 27101 27102 Define this macro only if the target machine offers a way to 27103 optimize the treatment of leaf functions, and registers need to be 27104 renumbered to do this. 27105 27106 `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE' must 27107usually treat leaf functions specially. They can test the C variable 27108`current_function_is_leaf' which is nonzero for leaf functions. 27109`current_function_is_leaf' is set prior to local register allocation 27110and is valid for the remaining compiler passes. They can also test the 27111C variable `current_function_uses_only_leaf_regs' which is nonzero for 27112leaf functions which only use leaf registers. 27113`current_function_uses_only_leaf_regs' is valid after all passes that 27114modify the instructions have been run and is only useful if 27115`LEAF_REGISTERS' is defined. 27116 27117 27118File: gccint.info, Node: Stack Registers, Prev: Leaf Functions, Up: Registers 27119 2712017.7.5 Registers That Form a Stack 27121---------------------------------- 27122 27123There are special features to handle computers where some of the 27124"registers" form a stack. Stack registers are normally written by 27125pushing onto the stack, and are numbered relative to the top of the 27126stack. 27127 27128 Currently, GCC can only handle one group of stack-like registers, and 27129they must be consecutively numbered. Furthermore, the existing support 27130for stack-like registers is specific to the 80387 floating point 27131coprocessor. If you have a new architecture that uses stack-like 27132registers, you will need to do substantial work on `reg-stack.c' and 27133write your machine description to cooperate with it, as well as 27134defining these macros. 27135 27136 -- Macro: STACK_REGS 27137 Define this if the machine has any stack-like registers. 27138 27139 -- Macro: STACK_REG_COVER_CLASS 27140 This is a cover class containing the stack registers. Define this 27141 if the machine has any stack-like registers. 27142 27143 -- Macro: FIRST_STACK_REG 27144 The number of the first stack-like register. This one is the top 27145 of the stack. 27146 27147 -- Macro: LAST_STACK_REG 27148 The number of the last stack-like register. This one is the 27149 bottom of the stack. 27150 27151 27152File: gccint.info, Node: Register Classes, Next: Old Constraints, Prev: Registers, Up: Target Macros 27153 2715417.8 Register Classes 27155===================== 27156 27157On many machines, the numbered registers are not all equivalent. For 27158example, certain registers may not be allowed for indexed addressing; 27159certain registers may not be allowed in some instructions. These 27160machine restrictions are described to the compiler using "register 27161classes". 27162 27163 You define a number of register classes, giving each one a name and 27164saying which of the registers belong to it. Then you can specify 27165register classes that are allowed as operands to particular instruction 27166patterns. 27167 27168 In general, each register will belong to several classes. In fact, one 27169class must be named `ALL_REGS' and contain all the registers. Another 27170class must be named `NO_REGS' and contain no registers. Often the 27171union of two classes will be another class; however, this is not 27172required. 27173 27174 One of the classes must be named `GENERAL_REGS'. There is nothing 27175terribly special about the name, but the operand constraint letters `r' 27176and `g' specify this class. If `GENERAL_REGS' is the same as 27177`ALL_REGS', just define it as a macro which expands to `ALL_REGS'. 27178 27179 Order the classes so that if class X is contained in class Y then X 27180has a lower class number than Y. 27181 27182 The way classes other than `GENERAL_REGS' are specified in operand 27183constraints is through machine-dependent operand constraint letters. 27184You can define such letters to correspond to various classes, then use 27185them in operand constraints. 27186 27187 You should define a class for the union of two classes whenever some 27188instruction allows both classes. For example, if an instruction allows 27189either a floating point (coprocessor) register or a general register 27190for a certain operand, you should define a class `FLOAT_OR_GENERAL_REGS' 27191which includes both of them. Otherwise you will get suboptimal code. 27192 27193 You must also specify certain redundant information about the register 27194classes: for each class, which classes contain it and which ones are 27195contained in it; for each pair of classes, the largest class contained 27196in their union. 27197 27198 When a value occupying several consecutive registers is expected in a 27199certain class, all the registers used must belong to that class. 27200Therefore, register classes cannot be used to enforce a requirement for 27201a register pair to start with an even-numbered register. The way to 27202specify this requirement is with `HARD_REGNO_MODE_OK'. 27203 27204 Register classes used for input-operands of bitwise-and or shift 27205instructions have a special requirement: each such class must have, for 27206each fixed-point machine mode, a subclass whose registers can transfer 27207that mode to or from memory. For example, on some machines, the 27208operations for single-byte values (`QImode') are limited to certain 27209registers. When this is so, each register class that is used in a 27210bitwise-and or shift instruction must have a subclass consisting of 27211registers from which single-byte values can be loaded or stored. This 27212is so that `PREFERRED_RELOAD_CLASS' can always have a possible value to 27213return. 27214 27215 -- Data type: enum reg_class 27216 An enumerated type that must be defined with all the register 27217 class names as enumerated values. `NO_REGS' must be first. 27218 `ALL_REGS' must be the last register class, followed by one more 27219 enumerated value, `LIM_REG_CLASSES', which is not a register class 27220 but rather tells how many classes there are. 27221 27222 Each register class has a number, which is the value of casting 27223 the class name to type `int'. The number serves as an index in 27224 many of the tables described below. 27225 27226 -- Macro: N_REG_CLASSES 27227 The number of distinct register classes, defined as follows: 27228 27229 #define N_REG_CLASSES (int) LIM_REG_CLASSES 27230 27231 -- Macro: REG_CLASS_NAMES 27232 An initializer containing the names of the register classes as C 27233 string constants. These names are used in writing some of the 27234 debugging dumps. 27235 27236 -- Macro: REG_CLASS_CONTENTS 27237 An initializer containing the contents of the register classes, as 27238 integers which are bit masks. The Nth integer specifies the 27239 contents of class N. The way the integer MASK is interpreted is 27240 that register R is in the class if `MASK & (1 << R)' is 1. 27241 27242 When the machine has more than 32 registers, an integer does not 27243 suffice. Then the integers are replaced by sub-initializers, 27244 braced groupings containing several integers. Each 27245 sub-initializer must be suitable as an initializer for the type 27246 `HARD_REG_SET' which is defined in `hard-reg-set.h'. In this 27247 situation, the first integer in each sub-initializer corresponds to 27248 registers 0 through 31, the second integer to registers 32 through 27249 63, and so on. 27250 27251 -- Macro: REGNO_REG_CLASS (REGNO) 27252 A C expression whose value is a register class containing hard 27253 register REGNO. In general there is more than one such class; 27254 choose a class which is "minimal", meaning that no smaller class 27255 also contains the register. 27256 27257 -- Macro: BASE_REG_CLASS 27258 A macro whose definition is the name of the class to which a valid 27259 base register must belong. A base register is one used in an 27260 address which is the register value plus a displacement. 27261 27262 -- Macro: MODE_BASE_REG_CLASS (MODE) 27263 This is a variation of the `BASE_REG_CLASS' macro which allows the 27264 selection of a base register in a mode dependent manner. If MODE 27265 is VOIDmode then it should return the same value as 27266 `BASE_REG_CLASS'. 27267 27268 -- Macro: MODE_BASE_REG_REG_CLASS (MODE) 27269 A C expression whose value is the register class to which a valid 27270 base register must belong in order to be used in a base plus index 27271 register address. You should define this macro if base plus index 27272 addresses have different requirements than other base register 27273 uses. 27274 27275 -- Macro: MODE_CODE_BASE_REG_CLASS (MODE, OUTER_CODE, INDEX_CODE) 27276 A C expression whose value is the register class to which a valid 27277 base register must belong. OUTER_CODE and INDEX_CODE define the 27278 context in which the base register occurs. OUTER_CODE is the code 27279 of the immediately enclosing expression (`MEM' for the top level 27280 of an address, `ADDRESS' for something that occurs in an 27281 `address_operand'). INDEX_CODE is the code of the corresponding 27282 index expression if OUTER_CODE is `PLUS'; `SCRATCH' otherwise. 27283 27284 -- Macro: INDEX_REG_CLASS 27285 A macro whose definition is the name of the class to which a valid 27286 index register must belong. An index register is one used in an 27287 address where its value is either multiplied by a scale factor or 27288 added to another register (as well as added to a displacement). 27289 27290 -- Macro: REGNO_OK_FOR_BASE_P (NUM) 27291 A C expression which is nonzero if register number NUM is suitable 27292 for use as a base register in operand addresses. Like 27293 `TARGET_LEGITIMATE_ADDRESS_P', this macro should also define a 27294 strict and a non-strict variant. Both variants behave the same 27295 for hard register; for pseudos, the strict variant will pass only 27296 those that have been allocated to a valid hard registers, while 27297 the non-strict variant will pass all pseudos. 27298 27299 Compiler source files that want to use the strict variant of this 27300 and other macros define the macro `REG_OK_STRICT'. You should use 27301 an `#ifdef REG_OK_STRICT' conditional to define the strict variant 27302 in that case and the non-strict variant otherwise. 27303 27304 -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE) 27305 A C expression that is just like `REGNO_OK_FOR_BASE_P', except that 27306 that expression may examine the mode of the memory reference in 27307 MODE. You should define this macro if the mode of the memory 27308 reference affects whether a register may be used as a base 27309 register. If you define this macro, the compiler will use it 27310 instead of `REGNO_OK_FOR_BASE_P'. The mode may be `VOIDmode' for 27311 addresses that appear outside a `MEM', i.e., as an 27312 `address_operand'. 27313 27314 This macro also has strict and non-strict variants. 27315 27316 -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE) 27317 A C expression which is nonzero if register number NUM is suitable 27318 for use as a base register in base plus index operand addresses, 27319 accessing memory in mode MODE. It may be either a suitable hard 27320 register or a pseudo register that has been allocated such a hard 27321 register. You should define this macro if base plus index 27322 addresses have different requirements than other base register 27323 uses. 27324 27325 Use of this macro is deprecated; please use the more general 27326 `REGNO_MODE_CODE_OK_FOR_BASE_P'. 27327 27328 This macro also has strict and non-strict variants. 27329 27330 -- Macro: REGNO_MODE_CODE_OK_FOR_BASE_P (NUM, MODE, OUTER_CODE, 27331 INDEX_CODE) 27332 A C expression that is just like `REGNO_MODE_OK_FOR_BASE_P', except 27333 that that expression may examine the context in which the register 27334 appears in the memory reference. OUTER_CODE is the code of the 27335 immediately enclosing expression (`MEM' if at the top level of the 27336 address, `ADDRESS' for something that occurs in an 27337 `address_operand'). INDEX_CODE is the code of the corresponding 27338 index expression if OUTER_CODE is `PLUS'; `SCRATCH' otherwise. 27339 The mode may be `VOIDmode' for addresses that appear outside a 27340 `MEM', i.e., as an `address_operand'. 27341 27342 This macro also has strict and non-strict variants. 27343 27344 -- Macro: REGNO_OK_FOR_INDEX_P (NUM) 27345 A C expression which is nonzero if register number NUM is suitable 27346 for use as an index register in operand addresses. It may be 27347 either a suitable hard register or a pseudo register that has been 27348 allocated such a hard register. 27349 27350 The difference between an index register and a base register is 27351 that the index register may be scaled. If an address involves the 27352 sum of two registers, neither one of them scaled, then either one 27353 may be labeled the "base" and the other the "index"; but whichever 27354 labeling is used must fit the machine's constraints of which 27355 registers may serve in each capacity. The compiler will try both 27356 labelings, looking for one that is valid, and will reload one or 27357 both registers only if neither labeling works. 27358 27359 This macro also has strict and non-strict variants. 27360 27361 -- Macro: PREFERRED_RELOAD_CLASS (X, CLASS) 27362 A C expression that places additional restrictions on the register 27363 class to use when it is necessary to copy value X into a register 27364 in class CLASS. The value is a register class; perhaps CLASS, or 27365 perhaps another, smaller class. On many machines, the following 27366 definition is safe: 27367 27368 #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS 27369 27370 Sometimes returning a more restrictive class makes better code. 27371 For example, on the 68000, when X is an integer constant that is 27372 in range for a `moveq' instruction, the value of this macro is 27373 always `DATA_REGS' as long as CLASS includes the data registers. 27374 Requiring a data register guarantees that a `moveq' will be used. 27375 27376 One case where `PREFERRED_RELOAD_CLASS' must not return CLASS is 27377 if X is a legitimate constant which cannot be loaded into some 27378 register class. By returning `NO_REGS' you can force X into a 27379 memory location. For example, rs6000 can load immediate values 27380 into general-purpose registers, but does not have an instruction 27381 for loading an immediate value into a floating-point register, so 27382 `PREFERRED_RELOAD_CLASS' returns `NO_REGS' when X is a 27383 floating-point constant. If the constant can't be loaded into any 27384 kind of register, code generation will be better if 27385 `LEGITIMATE_CONSTANT_P' makes the constant illegitimate instead of 27386 using `PREFERRED_RELOAD_CLASS'. 27387 27388 If an insn has pseudos in it after register allocation, reload 27389 will go through the alternatives and call repeatedly 27390 `PREFERRED_RELOAD_CLASS' to find the best one. Returning 27391 `NO_REGS', in this case, makes reload add a `!' in front of the 27392 constraint: the x86 back-end uses this feature to discourage usage 27393 of 387 registers when math is done in the SSE registers (and vice 27394 versa). 27395 27396 -- Macro: PREFERRED_OUTPUT_RELOAD_CLASS (X, CLASS) 27397 Like `PREFERRED_RELOAD_CLASS', but for output reloads instead of 27398 input reloads. If you don't define this macro, the default is to 27399 use CLASS, unchanged. 27400 27401 You can also use `PREFERRED_OUTPUT_RELOAD_CLASS' to discourage 27402 reload from using some alternatives, like `PREFERRED_RELOAD_CLASS'. 27403 27404 -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS) 27405 A C expression that places additional restrictions on the register 27406 class to use when it is necessary to be able to hold a value of 27407 mode MODE in a reload register for which class CLASS would 27408 ordinarily be used. 27409 27410 Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when 27411 there are certain modes that simply can't go in certain reload 27412 classes. 27413 27414 The value is a register class; perhaps CLASS, or perhaps another, 27415 smaller class. 27416 27417 Don't define this macro unless the target machine has limitations 27418 which require the macro to do something nontrivial. 27419 27420 -- Target Hook: enum reg_class TARGET_SECONDARY_RELOAD (bool IN_P, rtx 27421 X, enum reg_class RELOAD_CLASS, enum machine_mode 27422 RELOAD_MODE, secondary_reload_info *SRI) 27423 Many machines have some registers that cannot be copied directly 27424 to or from memory or even from other types of registers. An 27425 example is the `MQ' register, which on most machines, can only be 27426 copied to or from general registers, but not memory. Below, we 27427 shall be using the term 'intermediate register' when a move 27428 operation cannot be performed directly, but has to be done by 27429 copying the source into the intermediate register first, and then 27430 copying the intermediate register to the destination. An 27431 intermediate register always has the same mode as source and 27432 destination. Since it holds the actual value being copied, reload 27433 might apply optimizations to re-use an intermediate register and 27434 eliding the copy from the source when it can determine that the 27435 intermediate register still holds the required value. 27436 27437 Another kind of secondary reload is required on some machines which 27438 allow copying all registers to and from memory, but require a 27439 scratch register for stores to some memory locations (e.g., those 27440 with symbolic address on the RT, and those with certain symbolic 27441 address on the SPARC when compiling PIC). Scratch registers need 27442 not have the same mode as the value being copied, and usually hold 27443 a different value than that being copied. Special patterns in the 27444 md file are needed to describe how the copy is performed with the 27445 help of the scratch register; these patterns also describe the 27446 number, register class(es) and mode(s) of the scratch register(s). 27447 27448 In some cases, both an intermediate and a scratch register are 27449 required. 27450 27451 For input reloads, this target hook is called with nonzero IN_P, 27452 and X is an rtx that needs to be copied to a register of class 27453 RELOAD_CLASS in RELOAD_MODE. For output reloads, this target hook 27454 is called with zero IN_P, and a register of class RELOAD_CLASS 27455 needs to be copied to rtx X in RELOAD_MODE. 27456 27457 If copying a register of RELOAD_CLASS from/to X requires an 27458 intermediate register, the hook `secondary_reload' should return 27459 the register class required for this intermediate register. If no 27460 intermediate register is required, it should return NO_REGS. If 27461 more than one intermediate register is required, describe the one 27462 that is closest in the copy chain to the reload register. 27463 27464 If scratch registers are needed, you also have to describe how to 27465 perform the copy from/to the reload register to/from this closest 27466 intermediate register. Or if no intermediate register is 27467 required, but still a scratch register is needed, describe the 27468 copy from/to the reload register to/from the reload operand X. 27469 27470 You do this by setting `sri->icode' to the instruction code of a 27471 pattern in the md file which performs the move. Operands 0 and 1 27472 are the output and input of this copy, respectively. Operands 27473 from operand 2 onward are for scratch operands. These scratch 27474 operands must have a mode, and a single-register-class output 27475 constraint. 27476 27477 When an intermediate register is used, the `secondary_reload' hook 27478 will be called again to determine how to copy the intermediate 27479 register to/from the reload operand X, so your hook must also have 27480 code to handle the register class of the intermediate operand. 27481 27482 X might be a pseudo-register or a `subreg' of a pseudo-register, 27483 which could either be in a hard register or in memory. Use 27484 `true_regnum' to find out; it will return -1 if the pseudo is in 27485 memory and the hard register number if it is in a register. 27486 27487 Scratch operands in memory (constraint `"=m"' / `"=&m"') are 27488 currently not supported. For the time being, you will have to 27489 continue to use `SECONDARY_MEMORY_NEEDED' for that purpose. 27490 27491 `copy_cost' also uses this target hook to find out how values are 27492 copied. If you want it to include some extra cost for the need to 27493 allocate (a) scratch register(s), set `sri->extra_cost' to the 27494 additional cost. Or if two dependent moves are supposed to have a 27495 lower cost than the sum of the individual moves due to expected 27496 fortuitous scheduling and/or special forwarding logic, you can set 27497 `sri->extra_cost' to a negative amount. 27498 27499 -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X) 27500 -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X) 27501 -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X) 27502 These macros are obsolete, new ports should use the target hook 27503 `TARGET_SECONDARY_RELOAD' instead. 27504 27505 These are obsolete macros, replaced by the 27506 `TARGET_SECONDARY_RELOAD' target hook. Older ports still define 27507 these macros to indicate to the reload phase that it may need to 27508 allocate at least one register for a reload in addition to the 27509 register to contain the data. Specifically, if copying X to a 27510 register CLASS in MODE requires an intermediate register, you were 27511 supposed to define `SECONDARY_INPUT_RELOAD_CLASS' to return the 27512 largest register class all of whose registers can be used as 27513 intermediate registers or scratch registers. 27514 27515 If copying a register CLASS in MODE to X requires an intermediate 27516 or scratch register, `SECONDARY_OUTPUT_RELOAD_CLASS' was supposed 27517 to be defined be defined to return the largest register class 27518 required. If the requirements for input and output reloads were 27519 the same, the macro `SECONDARY_RELOAD_CLASS' should have been used 27520 instead of defining both macros identically. 27521 27522 The values returned by these macros are often `GENERAL_REGS'. 27523 Return `NO_REGS' if no spare register is needed; i.e., if X can be 27524 directly copied to or from a register of CLASS in MODE without 27525 requiring a scratch register. Do not define this macro if it 27526 would always return `NO_REGS'. 27527 27528 If a scratch register is required (either with or without an 27529 intermediate register), you were supposed to define patterns for 27530 `reload_inM' or `reload_outM', as required (*note Standard 27531 Names::. These patterns, which were normally implemented with a 27532 `define_expand', should be similar to the `movM' patterns, except 27533 that operand 2 is the scratch register. 27534 27535 These patterns need constraints for the reload register and scratch 27536 register that contain a single register class. If the original 27537 reload register (whose class is CLASS) can meet the constraint 27538 given in the pattern, the value returned by these macros is used 27539 for the class of the scratch register. Otherwise, two additional 27540 reload registers are required. Their classes are obtained from 27541 the constraints in the insn pattern. 27542 27543 X might be a pseudo-register or a `subreg' of a pseudo-register, 27544 which could either be in a hard register or in memory. Use 27545 `true_regnum' to find out; it will return -1 if the pseudo is in 27546 memory and the hard register number if it is in a register. 27547 27548 These macros should not be used in the case where a particular 27549 class of registers can only be copied to memory and not to another 27550 class of registers. In that case, secondary reload registers are 27551 not needed and would not be helpful. Instead, a stack location 27552 must be used to perform the copy and the `movM' pattern should use 27553 memory as an intermediate storage. This case often occurs between 27554 floating-point and general registers. 27555 27556 -- Macro: SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M) 27557 Certain machines have the property that some registers cannot be 27558 copied to some other registers without using memory. Define this 27559 macro on those machines to be a C expression that is nonzero if 27560 objects of mode M in registers of CLASS1 can only be copied to 27561 registers of class CLASS2 by storing a register of CLASS1 into 27562 memory and loading that memory location into a register of CLASS2. 27563 27564 Do not define this macro if its value would always be zero. 27565 27566 -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE) 27567 Normally when `SECONDARY_MEMORY_NEEDED' is defined, the compiler 27568 allocates a stack slot for a memory location needed for register 27569 copies. If this macro is defined, the compiler instead uses the 27570 memory location defined by this macro. 27571 27572 Do not define this macro if you do not define 27573 `SECONDARY_MEMORY_NEEDED'. 27574 27575 -- Macro: SECONDARY_MEMORY_NEEDED_MODE (MODE) 27576 When the compiler needs a secondary memory location to copy 27577 between two registers of mode MODE, it normally allocates 27578 sufficient memory to hold a quantity of `BITS_PER_WORD' bits and 27579 performs the store and load operations in a mode that many bits 27580 wide and whose class is the same as that of MODE. 27581 27582 This is right thing to do on most machines because it ensures that 27583 all bits of the register are copied and prevents accesses to the 27584 registers in a narrower mode, which some machines prohibit for 27585 floating-point registers. 27586 27587 However, this default behavior is not correct on some machines, 27588 such as the DEC Alpha, that store short integers in floating-point 27589 registers differently than in integer registers. On those 27590 machines, the default widening will not work correctly and you 27591 must define this macro to suppress that widening in some cases. 27592 See the file `alpha.h' for details. 27593 27594 Do not define this macro if you do not define 27595 `SECONDARY_MEMORY_NEEDED' or if widening MODE to a mode that is 27596 `BITS_PER_WORD' bits wide is correct for your machine. 27597 27598 -- Macro: SMALL_REGISTER_CLASSES 27599 On some machines, it is risky to let hard registers live across 27600 arbitrary insns. Typically, these machines have instructions that 27601 require values to be in specific registers (like an accumulator), 27602 and reload will fail if the required hard register is used for 27603 another purpose across such an insn. 27604 27605 Define `SMALL_REGISTER_CLASSES' to be an expression with a nonzero 27606 value on these machines. When this macro has a nonzero value, the 27607 compiler will try to minimize the lifetime of hard registers. 27608 27609 It is always safe to define this macro with a nonzero value, but 27610 if you unnecessarily define it, you will reduce the amount of 27611 optimizations that can be performed in some cases. If you do not 27612 define this macro with a nonzero value when it is required, the 27613 compiler will run out of spill registers and print a fatal error 27614 message. For most machines, you should not define this macro at 27615 all. 27616 27617 -- Macro: CLASS_LIKELY_SPILLED_P (CLASS) 27618 A C expression whose value is nonzero if pseudos that have been 27619 assigned to registers of class CLASS would likely be spilled 27620 because registers of CLASS are needed for spill registers. 27621 27622 The default value of this macro returns 1 if CLASS has exactly one 27623 register and zero otherwise. On most machines, this default 27624 should be used. Only define this macro to some other expression 27625 if pseudos allocated by `local-alloc.c' end up in memory because 27626 their hard registers were needed for spill registers. If this 27627 macro returns nonzero for those classes, those pseudos will only 27628 be allocated by `global.c', which knows how to reallocate the 27629 pseudo to another register. If there would not be another 27630 register available for reallocation, you should not change the 27631 definition of this macro since the only effect of such a 27632 definition would be to slow down register allocation. 27633 27634 -- Macro: CLASS_MAX_NREGS (CLASS, MODE) 27635 A C expression for the maximum number of consecutive registers of 27636 class CLASS needed to hold a value of mode MODE. 27637 27638 This is closely related to the macro `HARD_REGNO_NREGS'. In fact, 27639 the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be 27640 the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all 27641 REGNO values in the class CLASS. 27642 27643 This macro helps control the handling of multiple-word values in 27644 the reload pass. 27645 27646 -- Macro: CANNOT_CHANGE_MODE_CLASS (FROM, TO, CLASS) 27647 If defined, a C expression that returns nonzero for a CLASS for 27648 which a change from mode FROM to mode TO is invalid. 27649 27650 For the example, loading 32-bit integer or floating-point objects 27651 into floating-point registers on the Alpha extends them to 64 bits. 27652 Therefore loading a 64-bit object and then storing it as a 32-bit 27653 object does not store the low-order 32 bits, as would be the case 27654 for a normal register. Therefore, `alpha.h' defines 27655 `CANNOT_CHANGE_MODE_CLASS' as below: 27656 27657 #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ 27658 (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \ 27659 ? reg_classes_intersect_p (FLOAT_REGS, (CLASS)) : 0) 27660 27661 -- Target Hook: const enum reg_class * TARGET_IRA_COVER_CLASSES (void) 27662 Return an array of cover classes for the Integrated Register 27663 Allocator (IRA). Cover classes are a set of non-intersecting 27664 register classes covering all hard registers used for register 27665 allocation purposes. If a move between two registers in the same 27666 cover class is possible, it should be cheaper than a load or store 27667 of the registers. The array is terminated by a `LIM_REG_CLASSES' 27668 element. 27669 27670 The order of cover classes in the array is important. If two 27671 classes have the same cost of usage for a pseudo, the class 27672 occurred first in the array is chosen for the pseudo. 27673 27674 This hook is called once at compiler startup, after the 27675 command-line options have been processed. It is then re-examined 27676 by every call to `target_reinit'. 27677 27678 The default implementation returns `IRA_COVER_CLASSES', if defined, 27679 otherwise there is no default implementation. You must define 27680 either this macro or `IRA_COVER_CLASSES' in order to use the 27681 integrated register allocator with Chaitin-Briggs coloring. If the 27682 macro is not defined, the only available coloring algorithm is 27683 Chow's priority coloring. 27684 27685 -- Macro: IRA_COVER_CLASSES 27686 See the documentation for `TARGET_IRA_COVER_CLASSES'. 27687 27688 27689File: gccint.info, Node: Old Constraints, Next: Stack and Calling, Prev: Register Classes, Up: Target Macros 27690 2769117.9 Obsolete Macros for Defining Constraints 27692============================================= 27693 27694Machine-specific constraints can be defined with these macros instead 27695of the machine description constructs described in *note Define 27696Constraints::. This mechanism is obsolete. New ports should not use 27697it; old ports should convert to the new mechanism. 27698 27699 -- Macro: CONSTRAINT_LEN (CHAR, STR) 27700 For the constraint at the start of STR, which starts with the 27701 letter C, return the length. This allows you to have register 27702 class / constant / extra constraints that are longer than a single 27703 letter; you don't need to define this macro if you can do with 27704 single-letter constraints only. The definition of this macro 27705 should use DEFAULT_CONSTRAINT_LEN for all the characters that you 27706 don't want to handle specially. There are some sanity checks in 27707 genoutput.c that check the constraint lengths for the md file, so 27708 you can also use this macro to help you while you are 27709 transitioning from a byzantine single-letter-constraint scheme: 27710 when you return a negative length for a constraint you want to 27711 re-use, genoutput will complain about every instance where it is 27712 used in the md file. 27713 27714 -- Macro: REG_CLASS_FROM_LETTER (CHAR) 27715 A C expression which defines the machine-dependent operand 27716 constraint letters for register classes. If CHAR is such a 27717 letter, the value should be the register class corresponding to 27718 it. Otherwise, the value should be `NO_REGS'. The register 27719 letter `r', corresponding to class `GENERAL_REGS', will not be 27720 passed to this macro; you do not need to handle it. 27721 27722 -- Macro: REG_CLASS_FROM_CONSTRAINT (CHAR, STR) 27723 Like `REG_CLASS_FROM_LETTER', but you also get the constraint 27724 string passed in STR, so that you can use suffixes to distinguish 27725 between different variants. 27726 27727 -- Macro: CONST_OK_FOR_LETTER_P (VALUE, C) 27728 A C expression that defines the machine-dependent operand 27729 constraint letters (`I', `J', `K', ... `P') that specify 27730 particular ranges of integer values. If C is one of those 27731 letters, the expression should check that VALUE, an integer, is in 27732 the appropriate range and return 1 if so, 0 otherwise. If C is 27733 not one of those letters, the value should be 0 regardless of 27734 VALUE. 27735 27736 -- Macro: CONST_OK_FOR_CONSTRAINT_P (VALUE, C, STR) 27737 Like `CONST_OK_FOR_LETTER_P', but you also get the constraint 27738 string passed in STR, so that you can use suffixes to distinguish 27739 between different variants. 27740 27741 -- Macro: CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C) 27742 A C expression that defines the machine-dependent operand 27743 constraint letters that specify particular ranges of 27744 `const_double' values (`G' or `H'). 27745 27746 If C is one of those letters, the expression should check that 27747 VALUE, an RTX of code `const_double', is in the appropriate range 27748 and return 1 if so, 0 otherwise. If C is not one of those 27749 letters, the value should be 0 regardless of VALUE. 27750 27751 `const_double' is used for all floating-point constants and for 27752 `DImode' fixed-point constants. A given letter can accept either 27753 or both kinds of values. It can use `GET_MODE' to distinguish 27754 between these kinds. 27755 27756 -- Macro: CONST_DOUBLE_OK_FOR_CONSTRAINT_P (VALUE, C, STR) 27757 Like `CONST_DOUBLE_OK_FOR_LETTER_P', but you also get the 27758 constraint string passed in STR, so that you can use suffixes to 27759 distinguish between different variants. 27760 27761 -- Macro: EXTRA_CONSTRAINT (VALUE, C) 27762 A C expression that defines the optional machine-dependent 27763 constraint letters that can be used to segregate specific types of 27764 operands, usually memory references, for the target machine. Any 27765 letter that is not elsewhere defined and not matched by 27766 `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' may be used. 27767 Normally this macro will not be defined. 27768 27769 If it is required for a particular target machine, it should 27770 return 1 if VALUE corresponds to the operand type represented by 27771 the constraint letter C. If C is not defined as an extra 27772 constraint, the value returned should be 0 regardless of VALUE. 27773 27774 For example, on the ROMP, load instructions cannot have their 27775 output in r0 if the memory reference contains a symbolic address. 27776 Constraint letter `Q' is defined as representing a memory address 27777 that does _not_ contain a symbolic address. An alternative is 27778 specified with a `Q' constraint on the input and `r' on the 27779 output. The next alternative specifies `m' on the input and a 27780 register class that does not include r0 on the output. 27781 27782 -- Macro: EXTRA_CONSTRAINT_STR (VALUE, C, STR) 27783 Like `EXTRA_CONSTRAINT', but you also get the constraint string 27784 passed in STR, so that you can use suffixes to distinguish between 27785 different variants. 27786 27787 -- Macro: EXTRA_MEMORY_CONSTRAINT (C, STR) 27788 A C expression that defines the optional machine-dependent 27789 constraint letters, amongst those accepted by `EXTRA_CONSTRAINT', 27790 that should be treated like memory constraints by the reload pass. 27791 27792 It should return 1 if the operand type represented by the 27793 constraint at the start of STR, the first letter of which is the 27794 letter C, comprises a subset of all memory references including 27795 all those whose address is simply a base register. This allows 27796 the reload pass to reload an operand, if it does not directly 27797 correspond to the operand type of C, by copying its address into a 27798 base register. 27799 27800 For example, on the S/390, some instructions do not accept 27801 arbitrary memory references, but only those that do not make use 27802 of an index register. The constraint letter `Q' is defined via 27803 `EXTRA_CONSTRAINT' as representing a memory address of this type. 27804 If the letter `Q' is marked as `EXTRA_MEMORY_CONSTRAINT', a `Q' 27805 constraint can handle any memory operand, because the reload pass 27806 knows it can be reloaded by copying the memory address into a base 27807 register if required. This is analogous to the way an `o' 27808 constraint can handle any memory operand. 27809 27810 -- Macro: EXTRA_ADDRESS_CONSTRAINT (C, STR) 27811 A C expression that defines the optional machine-dependent 27812 constraint letters, amongst those accepted by `EXTRA_CONSTRAINT' / 27813 `EXTRA_CONSTRAINT_STR', that should be treated like address 27814 constraints by the reload pass. 27815 27816 It should return 1 if the operand type represented by the 27817 constraint at the start of STR, which starts with the letter C, 27818 comprises a subset of all memory addresses including all those 27819 that consist of just a base register. This allows the reload pass 27820 to reload an operand, if it does not directly correspond to the 27821 operand type of STR, by copying it into a base register. 27822 27823 Any constraint marked as `EXTRA_ADDRESS_CONSTRAINT' can only be 27824 used with the `address_operand' predicate. It is treated 27825 analogously to the `p' constraint. 27826 27827 27828File: gccint.info, Node: Stack and Calling, Next: Varargs, Prev: Old Constraints, Up: Target Macros 27829 2783017.10 Stack Layout and Calling Conventions 27831========================================== 27832 27833This describes the stack layout and calling conventions. 27834 27835* Menu: 27836 27837* Frame Layout:: 27838* Exception Handling:: 27839* Stack Checking:: 27840* Frame Registers:: 27841* Elimination:: 27842* Stack Arguments:: 27843* Register Arguments:: 27844* Scalar Return:: 27845* Aggregate Return:: 27846* Caller Saves:: 27847* Function Entry:: 27848* Profiling:: 27849* Tail Calls:: 27850* Stack Smashing Protection:: 27851 27852 27853File: gccint.info, Node: Frame Layout, Next: Exception Handling, Up: Stack and Calling 27854 2785517.10.1 Basic Stack Layout 27856-------------------------- 27857 27858Here is the basic stack layout. 27859 27860 -- Macro: STACK_GROWS_DOWNWARD 27861 Define this macro if pushing a word onto the stack moves the stack 27862 pointer to a smaller address. 27863 27864 When we say, "define this macro if ...", it means that the 27865 compiler checks this macro only with `#ifdef' so the precise 27866 definition used does not matter. 27867 27868 -- Macro: STACK_PUSH_CODE 27869 This macro defines the operation used when something is pushed on 27870 the stack. In RTL, a push operation will be `(set (mem 27871 (STACK_PUSH_CODE (reg sp))) ...)' 27872 27873 The choices are `PRE_DEC', `POST_DEC', `PRE_INC', and `POST_INC'. 27874 Which of these is correct depends on the stack direction and on 27875 whether the stack pointer points to the last item on the stack or 27876 whether it points to the space for the next item on the stack. 27877 27878 The default is `PRE_DEC' when `STACK_GROWS_DOWNWARD' is defined, 27879 which is almost always right, and `PRE_INC' otherwise, which is 27880 often wrong. 27881 27882 -- Macro: FRAME_GROWS_DOWNWARD 27883 Define this macro to nonzero value if the addresses of local 27884 variable slots are at negative offsets from the frame pointer. 27885 27886 -- Macro: ARGS_GROW_DOWNWARD 27887 Define this macro if successive arguments to a function occupy 27888 decreasing addresses on the stack. 27889 27890 -- Macro: STARTING_FRAME_OFFSET 27891 Offset from the frame pointer to the first local variable slot to 27892 be allocated. 27893 27894 If `FRAME_GROWS_DOWNWARD', find the next slot's offset by 27895 subtracting the first slot's length from `STARTING_FRAME_OFFSET'. 27896 Otherwise, it is found by adding the length of the first slot to 27897 the value `STARTING_FRAME_OFFSET'. 27898 27899 -- Macro: STACK_ALIGNMENT_NEEDED 27900 Define to zero to disable final alignment of the stack during 27901 reload. The nonzero default for this macro is suitable for most 27902 ports. 27903 27904 On ports where `STARTING_FRAME_OFFSET' is nonzero or where there 27905 is a register save block following the local block that doesn't 27906 require alignment to `STACK_BOUNDARY', it may be beneficial to 27907 disable stack alignment and do it in the backend. 27908 27909 -- Macro: STACK_POINTER_OFFSET 27910 Offset from the stack pointer register to the first location at 27911 which outgoing arguments are placed. If not specified, the 27912 default value of zero is used. This is the proper value for most 27913 machines. 27914 27915 If `ARGS_GROW_DOWNWARD', this is the offset to the location above 27916 the first location at which outgoing arguments are placed. 27917 27918 -- Macro: FIRST_PARM_OFFSET (FUNDECL) 27919 Offset from the argument pointer register to the first argument's 27920 address. On some machines it may depend on the data type of the 27921 function. 27922 27923 If `ARGS_GROW_DOWNWARD', this is the offset to the location above 27924 the first argument's address. 27925 27926 -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL) 27927 Offset from the stack pointer register to an item dynamically 27928 allocated on the stack, e.g., by `alloca'. 27929 27930 The default value for this macro is `STACK_POINTER_OFFSET' plus the 27931 length of the outgoing arguments. The default is correct for most 27932 machines. See `function.c' for details. 27933 27934 -- Macro: INITIAL_FRAME_ADDRESS_RTX 27935 A C expression whose value is RTL representing the address of the 27936 initial stack frame. This address is passed to `RETURN_ADDR_RTX' 27937 and `DYNAMIC_CHAIN_ADDRESS'. If you don't define this macro, a 27938 reasonable default value will be used. Define this macro in order 27939 to make frame pointer elimination work in the presence of 27940 `__builtin_frame_address (count)' and `__builtin_return_address 27941 (count)' for `count' not equal to zero. 27942 27943 -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR) 27944 A C expression whose value is RTL representing the address in a 27945 stack frame where the pointer to the caller's frame is stored. 27946 Assume that FRAMEADDR is an RTL expression for the address of the 27947 stack frame itself. 27948 27949 If you don't define this macro, the default is to return the value 27950 of FRAMEADDR--that is, the stack frame address is also the address 27951 of the stack word that points to the previous frame. 27952 27953 -- Macro: SETUP_FRAME_ADDRESSES 27954 If defined, a C expression that produces the machine-specific code 27955 to setup the stack so that arbitrary frames can be accessed. For 27956 example, on the SPARC, we must flush all of the register windows 27957 to the stack before we can access arbitrary stack frames. You 27958 will seldom need to define this macro. 27959 27960 -- Target Hook: rtx TARGET_BUILTIN_SETJMP_FRAME_VALUE (void) 27961 This target hook should return an rtx that is used to store the 27962 address of the current frame into the built in `setjmp' buffer. 27963 The default value, `virtual_stack_vars_rtx', is correct for most 27964 machines. One reason you may need to define this target hook is if 27965 `hard_frame_pointer_rtx' is the appropriate value on your machine. 27966 27967 -- Macro: FRAME_ADDR_RTX (FRAMEADDR) 27968 A C expression whose value is RTL representing the value of the 27969 frame address for the current frame. FRAMEADDR is the frame 27970 pointer of the current frame. This is used for 27971 __builtin_frame_address. You need only define this macro if the 27972 frame address is not the same as the frame pointer. Most machines 27973 do not need to define it. 27974 27975 -- Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR) 27976 A C expression whose value is RTL representing the value of the 27977 return address for the frame COUNT steps up from the current 27978 frame, after the prologue. FRAMEADDR is the frame pointer of the 27979 COUNT frame, or the frame pointer of the COUNT - 1 frame if 27980 `RETURN_ADDR_IN_PREVIOUS_FRAME' is defined. 27981 27982 The value of the expression must always be the correct address when 27983 COUNT is zero, but may be `NULL_RTX' if there is no way to 27984 determine the return address of other frames. 27985 27986 -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME 27987 Define this if the return address of a particular stack frame is 27988 accessed from the frame pointer of the previous stack frame. 27989 27990 -- Macro: INCOMING_RETURN_ADDR_RTX 27991 A C expression whose value is RTL representing the location of the 27992 incoming return address at the beginning of any function, before 27993 the prologue. This RTL is either a `REG', indicating that the 27994 return value is saved in `REG', or a `MEM' representing a location 27995 in the stack. 27996 27997 You only need to define this macro if you want to support call 27998 frame debugging information like that provided by DWARF 2. 27999 28000 If this RTL is a `REG', you should also define 28001 `DWARF_FRAME_RETURN_COLUMN' to `DWARF_FRAME_REGNUM (REGNO)'. 28002 28003 -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN 28004 A C expression whose value is an integer giving a DWARF 2 column 28005 number that may be used as an alternative return column. The 28006 column must not correspond to any gcc hard register (that is, it 28007 must not be in the range of `DWARF_FRAME_REGNUM'). 28008 28009 This macro can be useful if `DWARF_FRAME_RETURN_COLUMN' is set to a 28010 general register, but an alternative column needs to be used for 28011 signal frames. Some targets have also used different frame return 28012 columns over time. 28013 28014 -- Macro: DWARF_ZERO_REG 28015 A C expression whose value is an integer giving a DWARF 2 register 28016 number that is considered to always have the value zero. This 28017 should only be defined if the target has an architected zero 28018 register, and someone decided it was a good idea to use that 28019 register number to terminate the stack backtrace. New ports 28020 should avoid this. 28021 28022 -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char 28023 *LABEL, rtx PATTERN, int INDEX) 28024 This target hook allows the backend to emit frame-related insns 28025 that contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame 28026 debugging info engine will invoke it on insns of the form 28027 (set (reg) (unspec [...] UNSPEC_INDEX)) 28028 and 28029 (set (reg) (unspec_volatile [...] UNSPECV_INDEX)). 28030 to let the backend emit the call frame instructions. LABEL is the 28031 CFI label attached to the insn, PATTERN is the pattern of the insn 28032 and INDEX is `UNSPEC_INDEX' or `UNSPECV_INDEX'. 28033 28034 -- Macro: INCOMING_FRAME_SP_OFFSET 28035 A C expression whose value is an integer giving the offset, in 28036 bytes, from the value of the stack pointer register to the top of 28037 the stack frame at the beginning of any function, before the 28038 prologue. The top of the frame is defined to be the value of the 28039 stack pointer in the previous frame, just before the call 28040 instruction. 28041 28042 You only need to define this macro if you want to support call 28043 frame debugging information like that provided by DWARF 2. 28044 28045 -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL) 28046 A C expression whose value is an integer giving the offset, in 28047 bytes, from the argument pointer to the canonical frame address 28048 (cfa). The final value should coincide with that calculated by 28049 `INCOMING_FRAME_SP_OFFSET'. Which is unfortunately not usable 28050 during virtual register instantiation. 28051 28052 The default value for this macro is `FIRST_PARM_OFFSET (fundecl) + 28053 crtl->args.pretend_args_size', which is correct for most machines; 28054 in general, the arguments are found immediately before the stack 28055 frame. Note that this is not the case on some targets that save 28056 registers into the caller's frame, such as SPARC and rs6000, and 28057 so such targets need to define this macro. 28058 28059 You only need to define this macro if the default is incorrect, 28060 and you want to support call frame debugging information like that 28061 provided by DWARF 2. 28062 28063 -- Macro: FRAME_POINTER_CFA_OFFSET (FUNDECL) 28064 If defined, a C expression whose value is an integer giving the 28065 offset in bytes from the frame pointer to the canonical frame 28066 address (cfa). The final value should coincide with that 28067 calculated by `INCOMING_FRAME_SP_OFFSET'. 28068 28069 Normally the CFA is calculated as an offset from the argument 28070 pointer, via `ARG_POINTER_CFA_OFFSET', but if the argument pointer 28071 is variable due to the ABI, this may not be possible. If this 28072 macro is defined, it implies that the virtual register 28073 instantiation should be based on the frame pointer instead of the 28074 argument pointer. Only one of `FRAME_POINTER_CFA_OFFSET' and 28075 `ARG_POINTER_CFA_OFFSET' should be defined. 28076 28077 -- Macro: CFA_FRAME_BASE_OFFSET (FUNDECL) 28078 If defined, a C expression whose value is an integer giving the 28079 offset in bytes from the canonical frame address (cfa) to the 28080 frame base used in DWARF 2 debug information. The default is 28081 zero. A different value may reduce the size of debug information 28082 on some ports. 28083 28084 28085File: gccint.info, Node: Exception Handling, Next: Stack Checking, Prev: Frame Layout, Up: Stack and Calling 28086 2808717.10.2 Exception Handling Support 28088---------------------------------- 28089 28090 -- Macro: EH_RETURN_DATA_REGNO (N) 28091 A C expression whose value is the Nth register number used for 28092 data by exception handlers, or `INVALID_REGNUM' if fewer than N 28093 registers are usable. 28094 28095 The exception handling library routines communicate with the 28096 exception handlers via a set of agreed upon registers. Ideally 28097 these registers should be call-clobbered; it is possible to use 28098 call-saved registers, but may negatively impact code size. The 28099 target must support at least 2 data registers, but should define 4 28100 if there are enough free registers. 28101 28102 You must define this macro if you want to support call frame 28103 exception handling like that provided by DWARF 2. 28104 28105 -- Macro: EH_RETURN_STACKADJ_RTX 28106 A C expression whose value is RTL representing a location in which 28107 to store a stack adjustment to be applied before function return. 28108 This is used to unwind the stack to an exception handler's call 28109 frame. It will be assigned zero on code paths that return 28110 normally. 28111 28112 Typically this is a call-clobbered hard register that is otherwise 28113 untouched by the epilogue, but could also be a stack slot. 28114 28115 Do not define this macro if the stack pointer is saved and restored 28116 by the regular prolog and epilog code in the call frame itself; in 28117 this case, the exception handling library routines will update the 28118 stack location to be restored in place. Otherwise, you must define 28119 this macro if you want to support call frame exception handling 28120 like that provided by DWARF 2. 28121 28122 -- Macro: EH_RETURN_HANDLER_RTX 28123 A C expression whose value is RTL representing a location in which 28124 to store the address of an exception handler to which we should 28125 return. It will not be assigned on code paths that return 28126 normally. 28127 28128 Typically this is the location in the call frame at which the 28129 normal return address is stored. For targets that return by 28130 popping an address off the stack, this might be a memory address 28131 just below the _target_ call frame rather than inside the current 28132 call frame. If defined, `EH_RETURN_STACKADJ_RTX' will have already 28133 been assigned, so it may be used to calculate the location of the 28134 target call frame. 28135 28136 Some targets have more complex requirements than storing to an 28137 address calculable during initial code generation. In that case 28138 the `eh_return' instruction pattern should be used instead. 28139 28140 If you want to support call frame exception handling, you must 28141 define either this macro or the `eh_return' instruction pattern. 28142 28143 -- Macro: RETURN_ADDR_OFFSET 28144 If defined, an integer-valued C expression for which rtl will be 28145 generated to add it to the exception handler address before it is 28146 searched in the exception handling tables, and to subtract it 28147 again from the address before using it to return to the exception 28148 handler. 28149 28150 -- Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL) 28151 This macro chooses the encoding of pointers embedded in the 28152 exception handling sections. If at all possible, this should be 28153 defined such that the exception handling section will not require 28154 dynamic relocations, and so may be read-only. 28155 28156 CODE is 0 for data, 1 for code labels, 2 for function pointers. 28157 GLOBAL is true if the symbol may be affected by dynamic 28158 relocations. The macro should return a combination of the 28159 `DW_EH_PE_*' defines as found in `dwarf2.h'. 28160 28161 If this macro is not defined, pointers will not be encoded but 28162 represented directly. 28163 28164 -- Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE, 28165 ADDR, DONE) 28166 This macro allows the target to emit whatever special magic is 28167 required to represent the encoding chosen by 28168 `ASM_PREFERRED_EH_DATA_FORMAT'. Generic code takes care of 28169 pc-relative and indirect encodings; this must be defined if the 28170 target uses text-relative or data-relative encodings. 28171 28172 This is a C statement that branches to DONE if the format was 28173 handled. ENCODING is the format chosen, SIZE is the number of 28174 bytes that the format occupies, ADDR is the `SYMBOL_REF' to be 28175 emitted. 28176 28177 -- Macro: MD_UNWIND_SUPPORT 28178 A string specifying a file to be #include'd in unwind-dw2.c. The 28179 file so included typically defines `MD_FALLBACK_FRAME_STATE_FOR'. 28180 28181 -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS) 28182 This macro allows the target to add CPU and operating system 28183 specific code to the call-frame unwinder for use when there is no 28184 unwind data available. The most common reason to implement this 28185 macro is to unwind through signal frames. 28186 28187 This macro is called from `uw_frame_state_for' in `unwind-dw2.c', 28188 `unwind-dw2-xtensa.c' and `unwind-ia64.c'. CONTEXT is an 28189 `_Unwind_Context'; FS is an `_Unwind_FrameState'. Examine 28190 `context->ra' for the address of the code being executed and 28191 `context->cfa' for the stack pointer value. If the frame can be 28192 decoded, the register save addresses should be updated in FS and 28193 the macro should evaluate to `_URC_NO_REASON'. If the frame 28194 cannot be decoded, the macro should evaluate to 28195 `_URC_END_OF_STACK'. 28196 28197 For proper signal handling in Java this macro is accompanied by 28198 `MAKE_THROW_FRAME', defined in `libjava/include/*-signal.h' 28199 headers. 28200 28201 -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS) 28202 This macro allows the target to add operating system specific code 28203 to the call-frame unwinder to handle the IA-64 `.unwabi' unwinding 28204 directive, usually used for signal or interrupt frames. 28205 28206 This macro is called from `uw_update_context' in `unwind-ia64.c'. 28207 CONTEXT is an `_Unwind_Context'; FS is an `_Unwind_FrameState'. 28208 Examine `fs->unwabi' for the abi and context in the `.unwabi' 28209 directive. If the `.unwabi' directive can be handled, the 28210 register save addresses should be updated in FS. 28211 28212 -- Macro: TARGET_USES_WEAK_UNWIND_INFO 28213 A C expression that evaluates to true if the target requires unwind 28214 info to be given comdat linkage. Define it to be `1' if comdat 28215 linkage is necessary. The default is `0'. 28216 28217 28218File: gccint.info, Node: Stack Checking, Next: Frame Registers, Prev: Exception Handling, Up: Stack and Calling 28219 2822017.10.3 Specifying How Stack Checking is Done 28221--------------------------------------------- 28222 28223GCC will check that stack references are within the boundaries of the 28224stack, if the option `-fstack-check' is specified, in one of three ways: 28225 28226 1. If the value of the `STACK_CHECK_BUILTIN' macro is nonzero, GCC 28227 will assume that you have arranged for full stack checking to be 28228 done at appropriate places in the configuration files. GCC will 28229 not do other special processing. 28230 28231 2. If `STACK_CHECK_BUILTIN' is zero and the value of the 28232 `STACK_CHECK_STATIC_BUILTIN' macro is nonzero, GCC will assume 28233 that you have arranged for static stack checking (checking of the 28234 static stack frame of functions) to be done at appropriate places 28235 in the configuration files. GCC will only emit code to do dynamic 28236 stack checking (checking on dynamic stack allocations) using the 28237 third approach below. 28238 28239 3. If neither of the above are true, GCC will generate code to 28240 periodically "probe" the stack pointer using the values of the 28241 macros defined below. 28242 28243 If neither STACK_CHECK_BUILTIN nor STACK_CHECK_STATIC_BUILTIN is 28244defined, GCC will change its allocation strategy for large objects if 28245the option `-fstack-check' is specified: they will always be allocated 28246dynamically if their size exceeds `STACK_CHECK_MAX_VAR_SIZE' bytes. 28247 28248 -- Macro: STACK_CHECK_BUILTIN 28249 A nonzero value if stack checking is done by the configuration 28250 files in a machine-dependent manner. You should define this macro 28251 if stack checking is required by the ABI of your machine or if you 28252 would like to do stack checking in some more efficient way than 28253 the generic approach. The default value of this macro is zero. 28254 28255 -- Macro: STACK_CHECK_STATIC_BUILTIN 28256 A nonzero value if static stack checking is done by the 28257 configuration files in a machine-dependent manner. You should 28258 define this macro if you would like to do static stack checking in 28259 some more efficient way than the generic approach. The default 28260 value of this macro is zero. 28261 28262 -- Macro: STACK_CHECK_PROBE_INTERVAL_EXP 28263 An integer specifying the interval at which GCC must generate 28264 stack probe instructions, defined as 2 raised to this integer. 28265 You will normally define this macro so that the interval be no 28266 larger than the size of the "guard pages" at the end of a stack 28267 area. The default value of 12 (4096-byte interval) is suitable 28268 for most systems. 28269 28270 -- Macro: STACK_CHECK_MOVING_SP 28271 An integer which is nonzero if GCC should move the stack pointer 28272 page by page when doing probes. This can be necessary on systems 28273 where the stack pointer contains the bottom address of the memory 28274 area accessible to the executing thread at any point in time. In 28275 this situation an alternate signal stack is required in order to 28276 be able to recover from a stack overflow. The default value of 28277 this macro is zero. 28278 28279 -- Macro: STACK_CHECK_PROTECT 28280 The number of bytes of stack needed to recover from a stack 28281 overflow, for languages where such a recovery is supported. The 28282 default value of 75 words with the `setjmp'/`longjmp'-based 28283 exception handling mechanism and 8192 bytes with other exception 28284 handling mechanisms should be adequate for most machines. 28285 28286 The following macros are relevant only if neither STACK_CHECK_BUILTIN 28287nor STACK_CHECK_STATIC_BUILTIN is defined; you can omit them altogether 28288in the opposite case. 28289 28290 -- Macro: STACK_CHECK_MAX_FRAME_SIZE 28291 The maximum size of a stack frame, in bytes. GCC will generate 28292 probe instructions in non-leaf functions to ensure at least this 28293 many bytes of stack are available. If a stack frame is larger 28294 than this size, stack checking will not be reliable and GCC will 28295 issue a warning. The default is chosen so that GCC only generates 28296 one instruction on most systems. You should normally not change 28297 the default value of this macro. 28298 28299 -- Macro: STACK_CHECK_FIXED_FRAME_SIZE 28300 GCC uses this value to generate the above warning message. It 28301 represents the amount of fixed frame used by a function, not 28302 including space for any callee-saved registers, temporaries and 28303 user variables. You need only specify an upper bound for this 28304 amount and will normally use the default of four words. 28305 28306 -- Macro: STACK_CHECK_MAX_VAR_SIZE 28307 The maximum size, in bytes, of an object that GCC will place in the 28308 fixed area of the stack frame when the user specifies 28309 `-fstack-check'. GCC computed the default from the values of the 28310 above macros and you will normally not need to override that 28311 default. 28312 28313 28314File: gccint.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling 28315 2831617.10.4 Registers That Address the Stack Frame 28317---------------------------------------------- 28318 28319This discusses registers that address the stack frame. 28320 28321 -- Macro: STACK_POINTER_REGNUM 28322 The register number of the stack pointer register, which must also 28323 be a fixed register according to `FIXED_REGISTERS'. On most 28324 machines, the hardware determines which register this is. 28325 28326 -- Macro: FRAME_POINTER_REGNUM 28327 The register number of the frame pointer register, which is used to 28328 access automatic variables in the stack frame. On some machines, 28329 the hardware determines which register this is. On other 28330 machines, you can choose any register you wish for this purpose. 28331 28332 -- Macro: HARD_FRAME_POINTER_REGNUM 28333 On some machines the offset between the frame pointer and starting 28334 offset of the automatic variables is not known until after register 28335 allocation has been done (for example, because the saved registers 28336 are between these two locations). On those machines, define 28337 `FRAME_POINTER_REGNUM' the number of a special, fixed register to 28338 be used internally until the offset is known, and define 28339 `HARD_FRAME_POINTER_REGNUM' to be the actual hard register number 28340 used for the frame pointer. 28341 28342 You should define this macro only in the very rare circumstances 28343 when it is not possible to calculate the offset between the frame 28344 pointer and the automatic variables until after register 28345 allocation has been completed. When this macro is defined, you 28346 must also indicate in your definition of `ELIMINABLE_REGS' how to 28347 eliminate `FRAME_POINTER_REGNUM' into either 28348 `HARD_FRAME_POINTER_REGNUM' or `STACK_POINTER_REGNUM'. 28349 28350 Do not define this macro if it would be the same as 28351 `FRAME_POINTER_REGNUM'. 28352 28353 -- Macro: ARG_POINTER_REGNUM 28354 The register number of the arg pointer register, which is used to 28355 access the function's argument list. On some machines, this is 28356 the same as the frame pointer register. On some machines, the 28357 hardware determines which register this is. On other machines, 28358 you can choose any register you wish for this purpose. If this is 28359 not the same register as the frame pointer register, then you must 28360 mark it as a fixed register according to `FIXED_REGISTERS', or 28361 arrange to be able to eliminate it (*note Elimination::). 28362 28363 -- Macro: RETURN_ADDRESS_POINTER_REGNUM 28364 The register number of the return address pointer register, which 28365 is used to access the current function's return address from the 28366 stack. On some machines, the return address is not at a fixed 28367 offset from the frame pointer or stack pointer or argument 28368 pointer. This register can be defined to point to the return 28369 address on the stack, and then be converted by `ELIMINABLE_REGS' 28370 into either the frame pointer or stack pointer. 28371 28372 Do not define this macro unless there is no other way to get the 28373 return address from the stack. 28374 28375 -- Macro: STATIC_CHAIN_REGNUM 28376 -- Macro: STATIC_CHAIN_INCOMING_REGNUM 28377 Register numbers used for passing a function's static chain 28378 pointer. If register windows are used, the register number as 28379 seen by the called function is `STATIC_CHAIN_INCOMING_REGNUM', 28380 while the register number as seen by the calling function is 28381 `STATIC_CHAIN_REGNUM'. If these registers are the same, 28382 `STATIC_CHAIN_INCOMING_REGNUM' need not be defined. 28383 28384 The static chain register need not be a fixed register. 28385 28386 If the static chain is passed in memory, these macros should not be 28387 defined; instead, the `TARGET_STATIC_CHAIN' hook should be used. 28388 28389 -- Target Hook: rtx TARGET_STATIC_CHAIN (const_tree FNDECL, bool 28390 INCOMING_P) 28391 This hook replaces the use of `STATIC_CHAIN_REGNUM' et al for 28392 targets that may use different static chain locations for different 28393 nested functions. This may be required if the target has function 28394 attributes that affect the calling conventions of the function and 28395 those calling conventions use different static chain locations. 28396 28397 The default version of this hook uses `STATIC_CHAIN_REGNUM' et al. 28398 28399 If the static chain is passed in memory, this hook should be used 28400 to provide rtx giving `mem' expressions that denote where they are 28401 stored. Often the `mem' expression as seen by the caller will be 28402 at an offset from the stack pointer and the `mem' expression as 28403 seen by the callee will be at an offset from the frame pointer. The 28404 variables `stack_pointer_rtx', `frame_pointer_rtx', and 28405 `arg_pointer_rtx' will have been initialized and should be used to 28406 refer to those items. 28407 28408 -- Macro: DWARF_FRAME_REGISTERS 28409 This macro specifies the maximum number of hard registers that can 28410 be saved in a call frame. This is used to size data structures 28411 used in DWARF2 exception handling. 28412 28413 Prior to GCC 3.0, this macro was needed in order to establish a 28414 stable exception handling ABI in the face of adding new hard 28415 registers for ISA extensions. In GCC 3.0 and later, the EH ABI is 28416 insulated from changes in the number of hard registers. 28417 Nevertheless, this macro can still be used to reduce the runtime 28418 memory requirements of the exception handling routines, which can 28419 be substantial if the ISA contains a lot of registers that are not 28420 call-saved. 28421 28422 If this macro is not defined, it defaults to 28423 `FIRST_PSEUDO_REGISTER'. 28424 28425 -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS 28426 This macro is similar to `DWARF_FRAME_REGISTERS', but is provided 28427 for backward compatibility in pre GCC 3.0 compiled code. 28428 28429 If this macro is not defined, it defaults to 28430 `DWARF_FRAME_REGISTERS'. 28431 28432 -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO) 28433 Define this macro if the target's representation for dwarf 28434 registers is different than the internal representation for unwind 28435 column. Given a dwarf register, this macro should return the 28436 internal unwind column number to use instead. 28437 28438 See the PowerPC's SPE target for an example. 28439 28440 -- Macro: DWARF_FRAME_REGNUM (REGNO) 28441 Define this macro if the target's representation for dwarf 28442 registers used in .eh_frame or .debug_frame is different from that 28443 used in other debug info sections. Given a GCC hard register 28444 number, this macro should return the .eh_frame register number. 28445 The default is `DBX_REGISTER_NUMBER (REGNO)'. 28446 28447 28448 -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH) 28449 Define this macro to map register numbers held in the call frame 28450 info that GCC has collected using `DWARF_FRAME_REGNUM' to those 28451 that should be output in .debug_frame (`FOR_EH' is zero) and 28452 .eh_frame (`FOR_EH' is nonzero). The default is to return `REGNO'. 28453 28454 28455 28456File: gccint.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling 28457 2845817.10.5 Eliminating Frame Pointer and Arg Pointer 28459------------------------------------------------- 28460 28461This is about eliminating the frame pointer and arg pointer. 28462 28463 -- Target Hook: bool TARGET_FRAME_POINTER_REQUIRED (void) 28464 This target hook should return `true' if a function must have and 28465 use a frame pointer. This target hook is called in the reload 28466 pass. If its return value is `true' the function will have a 28467 frame pointer. 28468 28469 This target hook can in principle examine the current function and 28470 decide according to the facts, but on most machines the constant 28471 `false' or the constant `true' suffices. Use `false' when the 28472 machine allows code to be generated with no frame pointer, and 28473 doing so saves some time or space. Use `true' when there is no 28474 possible advantage to avoiding a frame pointer. 28475 28476 In certain cases, the compiler does not know how to produce valid 28477 code without a frame pointer. The compiler recognizes those cases 28478 and automatically gives the function a frame pointer regardless of 28479 what `TARGET_FRAME_POINTER_REQUIRED' returns. You don't need to 28480 worry about them. 28481 28482 In a function that does not require a frame pointer, the frame 28483 pointer register can be allocated for ordinary usage, unless you 28484 mark it as a fixed register. See `FIXED_REGISTERS' for more 28485 information. 28486 28487 Default return value is `false'. 28488 28489 -- Macro: INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR) 28490 A C statement to store in the variable DEPTH-VAR the difference 28491 between the frame pointer and the stack pointer values immediately 28492 after the function prologue. The value would be computed from 28493 information such as the result of `get_frame_size ()' and the 28494 tables of registers `regs_ever_live' and `call_used_regs'. 28495 28496 If `ELIMINABLE_REGS' is defined, this macro will be not be used and 28497 need not be defined. Otherwise, it must be defined even if 28498 `TARGET_FRAME_POINTER_REQUIRED' always returns true; in that case, 28499 you may set DEPTH-VAR to anything. 28500 28501 -- Macro: ELIMINABLE_REGS 28502 If defined, this macro specifies a table of register pairs used to 28503 eliminate unneeded registers that point into the stack frame. If 28504 it is not defined, the only elimination attempted by the compiler 28505 is to replace references to the frame pointer with references to 28506 the stack pointer. 28507 28508 The definition of this macro is a list of structure 28509 initializations, each of which specifies an original and 28510 replacement register. 28511 28512 On some machines, the position of the argument pointer is not 28513 known until the compilation is completed. In such a case, a 28514 separate hard register must be used for the argument pointer. 28515 This register can be eliminated by replacing it with either the 28516 frame pointer or the argument pointer, depending on whether or not 28517 the frame pointer has been eliminated. 28518 28519 In this case, you might specify: 28520 #define ELIMINABLE_REGS \ 28521 {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ 28522 {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ 28523 {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}} 28524 28525 Note that the elimination of the argument pointer with the stack 28526 pointer is specified first since that is the preferred elimination. 28527 28528 -- Target Hook: bool TARGET_CAN_ELIMINATE (const int FROM_REG, const 28529 int TO_REG) 28530 This target hook should returns `true' if the compiler is allowed 28531 to try to replace register number FROM_REG with register number 28532 TO_REG. This target hook need only be defined if `ELIMINABLE_REGS' 28533 is defined, and will usually be `true', since most of the cases 28534 preventing register elimination are things that the compiler 28535 already knows about. 28536 28537 Default return value is `true'. 28538 28539 -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR) 28540 This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It 28541 specifies the initial difference between the specified pair of 28542 registers. This macro must be defined if `ELIMINABLE_REGS' is 28543 defined. 28544 28545 28546File: gccint.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling 28547 2854817.10.6 Passing Function Arguments on the Stack 28549----------------------------------------------- 28550 28551The macros in this section control how arguments are passed on the 28552stack. See the following section for other macros that control passing 28553certain arguments in registers. 28554 28555 -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (const_tree FNTYPE) 28556 This target hook returns `true' if an argument declared in a 28557 prototype as an integral type smaller than `int' should actually be 28558 passed as an `int'. In addition to avoiding errors in certain 28559 cases of mismatch, it also makes for better code on certain 28560 machines. The default is to not promote prototypes. 28561 28562 -- Macro: PUSH_ARGS 28563 A C expression. If nonzero, push insns will be used to pass 28564 outgoing arguments. If the target machine does not have a push 28565 instruction, set it to zero. That directs GCC to use an alternate 28566 strategy: to allocate the entire argument block and then store the 28567 arguments into it. When `PUSH_ARGS' is nonzero, `PUSH_ROUNDING' 28568 must be defined too. 28569 28570 -- Macro: PUSH_ARGS_REVERSED 28571 A C expression. If nonzero, function arguments will be evaluated 28572 from last to first, rather than from first to last. If this macro 28573 is not defined, it defaults to `PUSH_ARGS' on targets where the 28574 stack and args grow in opposite directions, and 0 otherwise. 28575 28576 -- Macro: PUSH_ROUNDING (NPUSHED) 28577 A C expression that is the number of bytes actually pushed onto the 28578 stack when an instruction attempts to push NPUSHED bytes. 28579 28580 On some machines, the definition 28581 28582 #define PUSH_ROUNDING(BYTES) (BYTES) 28583 28584 will suffice. But on other machines, instructions that appear to 28585 push one byte actually push two bytes in an attempt to maintain 28586 alignment. Then the definition should be 28587 28588 #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) 28589 28590 -- Macro: ACCUMULATE_OUTGOING_ARGS 28591 A C expression. If nonzero, the maximum amount of space required 28592 for outgoing arguments will be computed and placed into the 28593 variable `current_function_outgoing_args_size'. No space will be 28594 pushed onto the stack for each call; instead, the function 28595 prologue should increase the stack frame size by this amount. 28596 28597 Setting both `PUSH_ARGS' and `ACCUMULATE_OUTGOING_ARGS' is not 28598 proper. 28599 28600 -- Macro: REG_PARM_STACK_SPACE (FNDECL) 28601 Define this macro if functions should assume that stack space has 28602 been allocated for arguments even when their values are passed in 28603 registers. 28604 28605 The value of this macro is the size, in bytes, of the area 28606 reserved for arguments passed in registers for the function 28607 represented by FNDECL, which can be zero if GCC is calling a 28608 library function. The argument FNDECL can be the FUNCTION_DECL, 28609 or the type itself of the function. 28610 28611 This space can be allocated by the caller, or be a part of the 28612 machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' says 28613 which. 28614 28615 -- Macro: OUTGOING_REG_PARM_STACK_SPACE (FNTYPE) 28616 Define this to a nonzero value if it is the responsibility of the 28617 caller to allocate the area reserved for arguments passed in 28618 registers when calling a function of FNTYPE. FNTYPE may be NULL 28619 if the function called is a library function. 28620 28621 If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls 28622 whether the space for these arguments counts in the value of 28623 `current_function_outgoing_args_size'. 28624 28625 -- Macro: STACK_PARMS_IN_REG_PARM_AREA 28626 Define this macro if `REG_PARM_STACK_SPACE' is defined, but the 28627 stack parameters don't skip the area specified by it. 28628 28629 Normally, when a parameter is not passed in registers, it is 28630 placed on the stack beyond the `REG_PARM_STACK_SPACE' area. 28631 Defining this macro suppresses this behavior and causes the 28632 parameter to be passed on the stack in its natural location. 28633 28634 -- Macro: RETURN_POPS_ARGS (FUNDECL, FUNTYPE, STACK-SIZE) 28635 A C expression that should indicate the number of bytes of its own 28636 arguments that a function pops on returning, or 0 if the function 28637 pops no arguments and the caller must therefore pop them all after 28638 the function returns. 28639 28640 FUNDECL is a C variable whose value is a tree node that describes 28641 the function in question. Normally it is a node of type 28642 `FUNCTION_DECL' that describes the declaration of the function. 28643 From this you can obtain the `DECL_ATTRIBUTES' of the function. 28644 28645 FUNTYPE is a C variable whose value is a tree node that describes 28646 the function in question. Normally it is a node of type 28647 `FUNCTION_TYPE' that describes the data type of the function. 28648 From this it is possible to obtain the data types of the value and 28649 arguments (if known). 28650 28651 When a call to a library function is being considered, FUNDECL 28652 will contain an identifier node for the library function. Thus, if 28653 you need to distinguish among various library functions, you can 28654 do so by their names. Note that "library function" in this 28655 context means a function used to perform arithmetic, whose name is 28656 known specially in the compiler and was not mentioned in the C 28657 code being compiled. 28658 28659 STACK-SIZE is the number of bytes of arguments passed on the 28660 stack. If a variable number of bytes is passed, it is zero, and 28661 argument popping will always be the responsibility of the calling 28662 function. 28663 28664 On the VAX, all functions always pop their arguments, so the 28665 definition of this macro is STACK-SIZE. On the 68000, using the 28666 standard calling convention, no functions pop their arguments, so 28667 the value of the macro is always 0 in this case. But an 28668 alternative calling convention is available in which functions 28669 that take a fixed number of arguments pop them but other functions 28670 (such as `printf') pop nothing (the caller pops all). When this 28671 convention is in use, FUNTYPE is examined to determine whether a 28672 function takes a fixed number of arguments. 28673 28674 -- Macro: CALL_POPS_ARGS (CUM) 28675 A C expression that should indicate the number of bytes a call 28676 sequence pops off the stack. It is added to the value of 28677 `RETURN_POPS_ARGS' when compiling a function call. 28678 28679 CUM is the variable in which all arguments to the called function 28680 have been accumulated. 28681 28682 On certain architectures, such as the SH5, a call trampoline is 28683 used that pops certain registers off the stack, depending on the 28684 arguments that have been passed to the function. Since this is a 28685 property of the call site, not of the called function, 28686 `RETURN_POPS_ARGS' is not appropriate. 28687 28688 28689File: gccint.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling 28690 2869117.10.7 Passing Arguments in Registers 28692-------------------------------------- 28693 28694This section describes the macros which let you control how various 28695types of arguments are passed in registers or how they are arranged in 28696the stack. 28697 28698 -- Macro: FUNCTION_ARG (CUM, MODE, TYPE, NAMED) 28699 A C expression that controls whether a function argument is passed 28700 in a register, and which register. 28701 28702 The arguments are CUM, which summarizes all the previous 28703 arguments; MODE, the machine mode of the argument; TYPE, the data 28704 type of the argument as a tree node or 0 if that is not known 28705 (which happens for C support library functions); and NAMED, which 28706 is 1 for an ordinary argument and 0 for nameless arguments that 28707 correspond to `...' in the called function's prototype. TYPE can 28708 be an incomplete type if a syntax error has previously occurred. 28709 28710 The value of the expression is usually either a `reg' RTX for the 28711 hard register in which to pass the argument, or zero to pass the 28712 argument on the stack. 28713 28714 For machines like the VAX and 68000, where normally all arguments 28715 are pushed, zero suffices as a definition. 28716 28717 The value of the expression can also be a `parallel' RTX. This is 28718 used when an argument is passed in multiple locations. The mode 28719 of the `parallel' should be the mode of the entire argument. The 28720 `parallel' holds any number of `expr_list' pairs; each one 28721 describes where part of the argument is passed. In each 28722 `expr_list' the first operand must be a `reg' RTX for the hard 28723 register in which to pass this part of the argument, and the mode 28724 of the register RTX indicates how large this part of the argument 28725 is. The second operand of the `expr_list' is a `const_int' which 28726 gives the offset in bytes into the entire argument of where this 28727 part starts. As a special exception the first `expr_list' in the 28728 `parallel' RTX may have a first operand of zero. This indicates 28729 that the entire argument is also stored on the stack. 28730 28731 The last time this macro is called, it is called with `MODE == 28732 VOIDmode', and its result is passed to the `call' or `call_value' 28733 pattern as operands 2 and 3 respectively. 28734 28735 The usual way to make the ISO library `stdarg.h' work on a machine 28736 where some arguments are usually passed in registers, is to cause 28737 nameless arguments to be passed on the stack instead. This is done 28738 by making `FUNCTION_ARG' return 0 whenever NAMED is 0. 28739 28740 You may use the hook `targetm.calls.must_pass_in_stack' in the 28741 definition of this macro to determine if this argument is of a 28742 type that must be passed in the stack. If `REG_PARM_STACK_SPACE' 28743 is not defined and `FUNCTION_ARG' returns nonzero for such an 28744 argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is 28745 defined, the argument will be computed in the stack and then 28746 loaded into a register. 28747 28748 -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (enum machine_mode 28749 MODE, const_tree TYPE) 28750 This target hook should return `true' if we should not pass TYPE 28751 solely in registers. The file `expr.h' defines a definition that 28752 is usually appropriate, refer to `expr.h' for additional 28753 documentation. 28754 28755 -- Macro: FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED) 28756 Define this macro if the target machine has "register windows", so 28757 that the register in which a function sees an arguments is not 28758 necessarily the same as the one in which the caller passed the 28759 argument. 28760 28761 For such machines, `FUNCTION_ARG' computes the register in which 28762 the caller passes the value, and `FUNCTION_INCOMING_ARG' should be 28763 defined in a similar fashion to tell the function being called 28764 where the arguments will arrive. 28765 28766 If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves 28767 both purposes. 28768 28769 -- Target Hook: int TARGET_ARG_PARTIAL_BYTES (CUMULATIVE_ARGS *CUM, 28770 enum machine_mode MODE, tree TYPE, bool NAMED) 28771 This target hook returns the number of bytes at the beginning of an 28772 argument that must be put in registers. The value must be zero for 28773 arguments that are passed entirely in registers or that are 28774 entirely pushed on the stack. 28775 28776 On some machines, certain arguments must be passed partially in 28777 registers and partially in memory. On these machines, typically 28778 the first few words of arguments are passed in registers, and the 28779 rest on the stack. If a multi-word argument (a `double' or a 28780 structure) crosses that boundary, its first few words must be 28781 passed in registers and the rest must be pushed. This macro tells 28782 the compiler when this occurs, and how many bytes should go in 28783 registers. 28784 28785 `FUNCTION_ARG' for these arguments should return the first 28786 register to be used by the caller for this argument; likewise 28787 `FUNCTION_INCOMING_ARG', for the called function. 28788 28789 -- Target Hook: bool TARGET_PASS_BY_REFERENCE (CUMULATIVE_ARGS *CUM, 28790 enum machine_mode MODE, tree TYPE, bool NAMED) 28791 This target hook should return `true' if an argument at the 28792 position indicated by CUM should be passed by reference. This 28793 predicate is queried after target independent reasons for being 28794 passed by reference, such as `TREE_ADDRESSABLE (type)'. 28795 28796 If the hook returns true, a copy of that argument is made in 28797 memory and a pointer to the argument is passed instead of the 28798 argument itself. The pointer is passed in whatever way is 28799 appropriate for passing a pointer to that type. 28800 28801 -- Target Hook: bool TARGET_CALLEE_COPIES (CUMULATIVE_ARGS *CUM, enum 28802 machine_mode MODE, const_tree TYPE, bool NAMED) 28803 The function argument described by the parameters to this hook is 28804 known to be passed by reference. The hook should return true if 28805 the function argument should be copied by the callee instead of 28806 copied by the caller. 28807 28808 For any argument for which the hook returns true, if it can be 28809 determined that the argument is not modified, then a copy need not 28810 be generated. 28811 28812 The default version of this hook always returns false. 28813 28814 -- Macro: CUMULATIVE_ARGS 28815 A C type for declaring a variable that is used as the first 28816 argument of `FUNCTION_ARG' and other related values. For some 28817 target machines, the type `int' suffices and can hold the number 28818 of bytes of argument so far. 28819 28820 There is no need to record in `CUMULATIVE_ARGS' anything about the 28821 arguments that have been passed on the stack. The compiler has 28822 other variables to keep track of that. For target machines on 28823 which all arguments are passed on the stack, there is no need to 28824 store anything in `CUMULATIVE_ARGS'; however, the data structure 28825 must exist and should not be empty, so use `int'. 28826 28827 -- Macro: OVERRIDE_ABI_FORMAT (FNDECL) 28828 If defined, this macro is called before generating any code for a 28829 function, but after the CFUN descriptor for the function has been 28830 created. The back end may use this macro to update CFUN to 28831 reflect an ABI other than that which would normally be used by 28832 default. If the compiler is generating code for a 28833 compiler-generated function, FNDECL may be `NULL'. 28834 28835 -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL, 28836 N_NAMED_ARGS) 28837 A C statement (sans semicolon) for initializing the variable CUM 28838 for the state at the beginning of the argument list. The variable 28839 has type `CUMULATIVE_ARGS'. The value of FNTYPE is the tree node 28840 for the data type of the function which will receive the args, or 28841 0 if the args are to a compiler support library function. For 28842 direct calls that are not libcalls, FNDECL contain the declaration 28843 node of the function. FNDECL is also set when 28844 `INIT_CUMULATIVE_ARGS' is used to find arguments for the function 28845 being compiled. N_NAMED_ARGS is set to the number of named 28846 arguments, including a structure return address if it is passed as 28847 a parameter, when making a call. When processing incoming 28848 arguments, N_NAMED_ARGS is set to -1. 28849 28850 When processing a call to a compiler support library function, 28851 LIBNAME identifies which one. It is a `symbol_ref' rtx which 28852 contains the name of the function, as a string. LIBNAME is 0 when 28853 an ordinary C function call is being processed. Thus, each time 28854 this macro is called, either LIBNAME or FNTYPE is nonzero, but 28855 never both of them at once. 28856 28857 -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME) 28858 Like `INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls, 28859 it gets a `MODE' argument instead of FNTYPE, that would be `NULL'. 28860 INDIRECT would always be zero, too. If this macro is not defined, 28861 `INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is used instead. 28862 28863 -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME) 28864 Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of 28865 finding the arguments for the function being compiled. If this 28866 macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead. 28867 28868 The value passed for LIBNAME is always 0, since library routines 28869 with special calling conventions are never compiled with GCC. The 28870 argument LIBNAME exists for symmetry with `INIT_CUMULATIVE_ARGS'. 28871 28872 -- Macro: FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED) 28873 A C statement (sans semicolon) to update the summarizer variable 28874 CUM to advance past an argument in the argument list. The values 28875 MODE, TYPE and NAMED describe that argument. Once this is done, 28876 the variable CUM is suitable for analyzing the _following_ 28877 argument with `FUNCTION_ARG', etc. 28878 28879 This macro need not do anything if the argument in question was 28880 passed on the stack. The compiler knows how to track the amount 28881 of stack space used for arguments without any special help. 28882 28883 -- Macro: FUNCTION_ARG_OFFSET (MODE, TYPE) 28884 If defined, a C expression that is the number of bytes to add to 28885 the offset of the argument passed in memory. This is needed for 28886 the SPU, which passes `char' and `short' arguments in the preferred 28887 slot that is in the middle of the quad word instead of starting at 28888 the top. 28889 28890 -- Macro: FUNCTION_ARG_PADDING (MODE, TYPE) 28891 If defined, a C expression which determines whether, and in which 28892 direction, to pad out an argument with extra space. The value 28893 should be of type `enum direction': either `upward' to pad above 28894 the argument, `downward' to pad below, or `none' to inhibit 28895 padding. 28896 28897 The _amount_ of padding is always just enough to reach the next 28898 multiple of `FUNCTION_ARG_BOUNDARY'; this macro does not control 28899 it. 28900 28901 This macro has a default definition which is right for most 28902 systems. For little-endian machines, the default is to pad 28903 upward. For big-endian machines, the default is to pad downward 28904 for an argument of constant size shorter than an `int', and upward 28905 otherwise. 28906 28907 -- Macro: PAD_VARARGS_DOWN 28908 If defined, a C expression which determines whether the default 28909 implementation of va_arg will attempt to pad down before reading 28910 the next argument, if that argument is smaller than its aligned 28911 space as controlled by `PARM_BOUNDARY'. If this macro is not 28912 defined, all such arguments are padded down if `BYTES_BIG_ENDIAN' 28913 is true. 28914 28915 -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST) 28916 Specify padding for the last element of a block move between 28917 registers and memory. FIRST is nonzero if this is the only 28918 element. Defining this macro allows better control of register 28919 function parameters on big-endian machines, without using 28920 `PARALLEL' rtl. In particular, `MUST_PASS_IN_STACK' need not test 28921 padding and mode of types in registers, as there is no longer a 28922 "wrong" part of a register; For example, a three byte aggregate 28923 may be passed in the high part of a register if so required. 28924 28925 -- Macro: FUNCTION_ARG_BOUNDARY (MODE, TYPE) 28926 If defined, a C expression that gives the alignment boundary, in 28927 bits, of an argument with the specified mode and type. If it is 28928 not defined, `PARM_BOUNDARY' is used for all arguments. 28929 28930 -- Macro: FUNCTION_ARG_REGNO_P (REGNO) 28931 A C expression that is nonzero if REGNO is the number of a hard 28932 register in which function arguments are sometimes passed. This 28933 does _not_ include implicit arguments such as the static chain and 28934 the structure-value address. On many machines, no registers can be 28935 used for this purpose since all function arguments are pushed on 28936 the stack. 28937 28938 -- Target Hook: bool TARGET_SPLIT_COMPLEX_ARG (const_tree TYPE) 28939 This hook should return true if parameter of type TYPE are passed 28940 as two scalar parameters. By default, GCC will attempt to pack 28941 complex arguments into the target's word size. Some ABIs require 28942 complex arguments to be split and treated as their individual 28943 components. For example, on AIX64, complex floats should be 28944 passed in a pair of floating point registers, even though a 28945 complex float would fit in one 64-bit floating point register. 28946 28947 The default value of this hook is `NULL', which is treated as 28948 always false. 28949 28950 -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void) 28951 This hook returns a type node for `va_list' for the target. The 28952 default version of the hook returns `void*'. 28953 28954 -- Target Hook: tree TARGET_FN_ABI_VA_LIST (tree FNDECL) 28955 This hook returns the va_list type of the calling convention 28956 specified by FNDECL. The default version of this hook returns 28957 `va_list_type_node'. 28958 28959 -- Target Hook: tree TARGET_CANONICAL_VA_LIST_TYPE (tree TYPE) 28960 This hook returns the va_list type of the calling convention 28961 specified by the type of TYPE. If TYPE is not a valid va_list 28962 type, it returns `NULL_TREE'. 28963 28964 -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree 28965 TYPE, gimple_seq *PRE_P, gimple_seq *POST_P) 28966 This hook performs target-specific gimplification of 28967 `VA_ARG_EXPR'. The first two parameters correspond to the 28968 arguments to `va_arg'; the latter two are as in 28969 `gimplify.c:gimplify_expr'. 28970 28971 -- Target Hook: bool TARGET_VALID_POINTER_MODE (enum machine_mode MODE) 28972 Define this to return nonzero if the port can handle pointers with 28973 machine mode MODE. The default version of this hook returns true 28974 for both `ptr_mode' and `Pmode'. 28975 28976 -- Target Hook: bool TARGET_SCALAR_MODE_SUPPORTED_P (enum machine_mode 28977 MODE) 28978 Define this to return nonzero if the port is prepared to handle 28979 insns involving scalar mode MODE. For a scalar mode to be 28980 considered supported, all the basic arithmetic and comparisons 28981 must work. 28982 28983 The default version of this hook returns true for any mode 28984 required to handle the basic C types (as defined by the port). 28985 Included here are the double-word arithmetic supported by the code 28986 in `optabs.c'. 28987 28988 -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (enum machine_mode 28989 MODE) 28990 Define this to return nonzero if the port is prepared to handle 28991 insns involving vector mode MODE. At the very least, it must have 28992 move patterns for this mode. 28993 28994 28995File: gccint.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling 28996 2899717.10.8 How Scalar Function Values Are Returned 28998----------------------------------------------- 28999 29000This section discusses the macros that control returning scalars as 29001values--values that can fit in registers. 29002 29003 -- Target Hook: rtx TARGET_FUNCTION_VALUE (const_tree RET_TYPE, 29004 const_tree FN_DECL_OR_TYPE, bool OUTGOING) 29005 Define this to return an RTX representing the place where a 29006 function returns or receives a value of data type RET_TYPE, a tree 29007 node representing a data type. FN_DECL_OR_TYPE is a tree node 29008 representing `FUNCTION_DECL' or `FUNCTION_TYPE' of a function 29009 being called. If OUTGOING is false, the hook should compute the 29010 register in which the caller will see the return value. 29011 Otherwise, the hook should return an RTX representing the place 29012 where a function returns a value. 29013 29014 On many machines, only `TYPE_MODE (RET_TYPE)' is relevant. 29015 (Actually, on most machines, scalar values are returned in the same 29016 place regardless of mode.) The value of the expression is usually 29017 a `reg' RTX for the hard register where the return value is stored. 29018 The value can also be a `parallel' RTX, if the return value is in 29019 multiple places. See `FUNCTION_ARG' for an explanation of the 29020 `parallel' form. Note that the callee will populate every 29021 location specified in the `parallel', but if the first element of 29022 the `parallel' contains the whole return value, callers will use 29023 that element as the canonical location and ignore the others. The 29024 m68k port uses this type of `parallel' to return pointers in both 29025 `%a0' (the canonical location) and `%d0'. 29026 29027 If `TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply 29028 the same promotion rules specified in `PROMOTE_MODE' if VALTYPE is 29029 a scalar type. 29030 29031 If the precise function being called is known, FUNC is a tree node 29032 (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This 29033 makes it possible to use a different value-returning convention 29034 for specific functions when all their calls are known. 29035 29036 Some target machines have "register windows" so that the register 29037 in which a function returns its value is not the same as the one 29038 in which the caller sees the value. For such machines, you should 29039 return different RTX depending on OUTGOING. 29040 29041 `TARGET_FUNCTION_VALUE' is not used for return values with 29042 aggregate data types, because these are returned in another way. 29043 See `TARGET_STRUCT_VALUE_RTX' and related macros, below. 29044 29045 -- Macro: FUNCTION_VALUE (VALTYPE, FUNC) 29046 This macro has been deprecated. Use `TARGET_FUNCTION_VALUE' for a 29047 new target instead. 29048 29049 -- Macro: FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC) 29050 This macro has been deprecated. Use `TARGET_FUNCTION_VALUE' for a 29051 new target instead. 29052 29053 -- Macro: LIBCALL_VALUE (MODE) 29054 A C expression to create an RTX representing the place where a 29055 library function returns a value of mode MODE. 29056 29057 Note that "library function" in this context means a compiler 29058 support routine, used to perform arithmetic, whose name is known 29059 specially by the compiler and was not mentioned in the C code being 29060 compiled. 29061 29062 -- Target Hook: rtx TARGET_LIBCALL_VALUE (enum machine_mode 29063 MODE, const_rtx FUN) Define this hook if the back-end needs to 29064 know the name of the libcall function in order to determine where 29065 the result should be returned. 29066 29067 The mode of the result is given by MODE and the name of the called 29068 library function is given by FUN. The hook should return an RTX 29069 representing the place where the library function result will be 29070 returned. 29071 29072 If this hook is not defined, then LIBCALL_VALUE will be used. 29073 29074 -- Macro: FUNCTION_VALUE_REGNO_P (REGNO) 29075 A C expression that is nonzero if REGNO is the number of a hard 29076 register in which the values of called function may come back. 29077 29078 A register whose use for returning values is limited to serving as 29079 the second of a pair (for a value of type `double', say) need not 29080 be recognized by this macro. So for most machines, this definition 29081 suffices: 29082 29083 #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) 29084 29085 If the machine has register windows, so that the caller and the 29086 called function use different registers for the return value, this 29087 macro should recognize only the caller's register numbers. 29088 29089 -- Macro: TARGET_ENUM_VA_LIST (IDX, PNAME, PTYPE) 29090 This target macro is used in function `c_common_nodes_and_builtins' 29091 to iterate through the target specific builtin types for va_list. 29092 The variable IDX is used as iterator. PNAME has to be a pointer to 29093 a `const char *' and PTYPE a pointer to a `tree' typed variable. 29094 The arguments PNAME and PTYPE are used to store the result of this 29095 macro and are set to the name of the va_list builtin type and its 29096 internal type. If the return value of this macro is zero, then 29097 there is no more element. Otherwise the IDX should be increased 29098 for the next call of this macro to iterate through all types. 29099 29100 -- Macro: APPLY_RESULT_SIZE 29101 Define this macro if `untyped_call' and `untyped_return' need more 29102 space than is implied by `FUNCTION_VALUE_REGNO_P' for saving and 29103 restoring an arbitrary return value. 29104 29105 -- Target Hook: bool TARGET_RETURN_IN_MSB (const_tree TYPE) 29106 This hook should return true if values of type TYPE are returned 29107 at the most significant end of a register (in other words, if they 29108 are padded at the least significant end). You can assume that TYPE 29109 is returned in a register; the caller is required to check this. 29110 29111 Note that the register provided by `TARGET_FUNCTION_VALUE' must be 29112 able to hold the complete return value. For example, if a 1-, 2- 29113 or 3-byte structure is returned at the most significant end of a 29114 4-byte register, `TARGET_FUNCTION_VALUE' should provide an 29115 `SImode' rtx. 29116 29117 29118File: gccint.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling 29119 2912017.10.9 How Large Values Are Returned 29121------------------------------------- 29122 29123When a function value's mode is `BLKmode' (and in some other cases), 29124the value is not returned according to `TARGET_FUNCTION_VALUE' (*note 29125Scalar Return::). Instead, the caller passes the address of a block of 29126memory in which the value should be stored. This address is called the 29127"structure value address". 29128 29129 This section describes how to control returning structure values in 29130memory. 29131 29132 -- Target Hook: bool TARGET_RETURN_IN_MEMORY (const_tree TYPE, 29133 const_tree FNTYPE) 29134 This target hook should return a nonzero value to say to return the 29135 function value in memory, just as large structures are always 29136 returned. Here TYPE will be the data type of the value, and FNTYPE 29137 will be the type of the function doing the returning, or `NULL' for 29138 libcalls. 29139 29140 Note that values of mode `BLKmode' must be explicitly handled by 29141 this function. Also, the option `-fpcc-struct-return' takes 29142 effect regardless of this macro. On most systems, it is possible 29143 to leave the hook undefined; this causes a default definition to 29144 be used, whose value is the constant 1 for `BLKmode' values, and 0 29145 otherwise. 29146 29147 Do not use this hook to indicate that structures and unions should 29148 always be returned in memory. You should instead use 29149 `DEFAULT_PCC_STRUCT_RETURN' to indicate this. 29150 29151 -- Macro: DEFAULT_PCC_STRUCT_RETURN 29152 Define this macro to be 1 if all structure and union return values 29153 must be in memory. Since this results in slower code, this should 29154 be defined only if needed for compatibility with other compilers 29155 or with an ABI. If you define this macro to be 0, then the 29156 conventions used for structure and union return values are decided 29157 by the `TARGET_RETURN_IN_MEMORY' target hook. 29158 29159 If not defined, this defaults to the value 1. 29160 29161 -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING) 29162 This target hook should return the location of the structure value 29163 address (normally a `mem' or `reg'), or 0 if the address is passed 29164 as an "invisible" first argument. Note that FNDECL may be `NULL', 29165 for libcalls. You do not need to define this target hook if the 29166 address is always passed as an "invisible" first argument. 29167 29168 On some architectures the place where the structure value address 29169 is found by the called function is not the same place that the 29170 caller put it. This can be due to register windows, or it could 29171 be because the function prologue moves it to a different place. 29172 INCOMING is `1' or `2' when the location is needed in the context 29173 of the called function, and `0' in the context of the caller. 29174 29175 If INCOMING is nonzero and the address is to be found on the 29176 stack, return a `mem' which refers to the frame pointer. If 29177 INCOMING is `2', the result is being used to fetch the structure 29178 value address at the beginning of a function. If you need to emit 29179 adjusting code, you should do it at this point. 29180 29181 -- Macro: PCC_STATIC_STRUCT_RETURN 29182 Define this macro if the usual system convention on the target 29183 machine for returning structures and unions is for the called 29184 function to return the address of a static variable containing the 29185 value. 29186 29187 Do not define this if the usual system convention is for the 29188 caller to pass an address to the subroutine. 29189 29190 This macro has effect in `-fpcc-struct-return' mode, but it does 29191 nothing when you use `-freg-struct-return' mode. 29192 29193 29194File: gccint.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling 29195 2919617.10.10 Caller-Saves Register Allocation 29197----------------------------------------- 29198 29199If you enable it, GCC can save registers around function calls. This 29200makes it possible to use call-clobbered registers to hold variables that 29201must live across calls. 29202 29203 -- Macro: CALLER_SAVE_PROFITABLE (REFS, CALLS) 29204 A C expression to determine whether it is worthwhile to consider 29205 placing a pseudo-register in a call-clobbered hard register and 29206 saving and restoring it around each function call. The expression 29207 should be 1 when this is worth doing, and 0 otherwise. 29208 29209 If you don't define this macro, a default is used which is good on 29210 most machines: `4 * CALLS < REFS'. 29211 29212 -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS) 29213 A C expression specifying which mode is required for saving NREGS 29214 of a pseudo-register in call-clobbered hard register REGNO. If 29215 REGNO is unsuitable for caller save, `VOIDmode' should be 29216 returned. For most machines this macro need not be defined since 29217 GCC will select the smallest suitable mode. 29218 29219 29220File: gccint.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling 29221 2922217.10.11 Function Entry and Exit 29223-------------------------------- 29224 29225This section describes the macros that output function entry 29226("prologue") and exit ("epilogue") code. 29227 29228 -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE, 29229 HOST_WIDE_INT SIZE) 29230 If defined, a function that outputs the assembler code for entry 29231 to a function. The prologue is responsible for setting up the 29232 stack frame, initializing the frame pointer register, saving 29233 registers that must be saved, and allocating SIZE additional bytes 29234 of storage for the local variables. SIZE is an integer. FILE is 29235 a stdio stream to which the assembler code should be output. 29236 29237 The label for the beginning of the function need not be output by 29238 this macro. That has already been done when the macro is run. 29239 29240 To determine which registers to save, the macro can refer to the 29241 array `regs_ever_live': element R is nonzero if hard register R is 29242 used anywhere within the function. This implies the function 29243 prologue should save register R, provided it is not one of the 29244 call-used registers. (`TARGET_ASM_FUNCTION_EPILOGUE' must 29245 likewise use `regs_ever_live'.) 29246 29247 On machines that have "register windows", the function entry code 29248 does not save on the stack the registers that are in the windows, 29249 even if they are supposed to be preserved by function calls; 29250 instead it takes appropriate steps to "push" the register stack, 29251 if any non-call-used registers are used in the function. 29252 29253 On machines where functions may or may not have frame-pointers, the 29254 function entry code must vary accordingly; it must set up the frame 29255 pointer if one is wanted, and not otherwise. To determine whether 29256 a frame pointer is in wanted, the macro can refer to the variable 29257 `frame_pointer_needed'. The variable's value will be 1 at run 29258 time in a function that needs a frame pointer. *Note 29259 Elimination::. 29260 29261 The function entry code is responsible for allocating any stack 29262 space required for the function. This stack space consists of the 29263 regions listed below. In most cases, these regions are allocated 29264 in the order listed, with the last listed region closest to the 29265 top of the stack (the lowest address if `STACK_GROWS_DOWNWARD' is 29266 defined, and the highest address if it is not defined). You can 29267 use a different order for a machine if doing so is more convenient 29268 or required for compatibility reasons. Except in cases where 29269 required by standard or by a debugger, there is no reason why the 29270 stack layout used by GCC need agree with that used by other 29271 compilers for a machine. 29272 29273 -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE) 29274 If defined, a function that outputs assembler code at the end of a 29275 prologue. This should be used when the function prologue is being 29276 emitted as RTL, and you have some extra assembler that needs to be 29277 emitted. *Note prologue instruction pattern::. 29278 29279 -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE) 29280 If defined, a function that outputs assembler code at the start of 29281 an epilogue. This should be used when the function epilogue is 29282 being emitted as RTL, and you have some extra assembler that needs 29283 to be emitted. *Note epilogue instruction pattern::. 29284 29285 -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE, 29286 HOST_WIDE_INT SIZE) 29287 If defined, a function that outputs the assembler code for exit 29288 from a function. The epilogue is responsible for restoring the 29289 saved registers and stack pointer to their values when the 29290 function was called, and returning control to the caller. This 29291 macro takes the same arguments as the macro 29292 `TARGET_ASM_FUNCTION_PROLOGUE', and the registers to restore are 29293 determined from `regs_ever_live' and `CALL_USED_REGISTERS' in the 29294 same way. 29295 29296 On some machines, there is a single instruction that does all the 29297 work of returning from the function. On these machines, give that 29298 instruction the name `return' and do not define the macro 29299 `TARGET_ASM_FUNCTION_EPILOGUE' at all. 29300 29301 Do not define a pattern named `return' if you want the 29302 `TARGET_ASM_FUNCTION_EPILOGUE' to be used. If you want the target 29303 switches to control whether return instructions or epilogues are 29304 used, define a `return' pattern with a validity condition that 29305 tests the target switches appropriately. If the `return' 29306 pattern's validity condition is false, epilogues will be used. 29307 29308 On machines where functions may or may not have frame-pointers, the 29309 function exit code must vary accordingly. Sometimes the code for 29310 these two cases is completely different. To determine whether a 29311 frame pointer is wanted, the macro can refer to the variable 29312 `frame_pointer_needed'. The variable's value will be 1 when 29313 compiling a function that needs a frame pointer. 29314 29315 Normally, `TARGET_ASM_FUNCTION_PROLOGUE' and 29316 `TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially. 29317 The C variable `current_function_is_leaf' is nonzero for such a 29318 function. *Note Leaf Functions::. 29319 29320 On some machines, some functions pop their arguments on exit while 29321 others leave that for the caller to do. For example, the 68020 29322 when given `-mrtd' pops arguments in functions that take a fixed 29323 number of arguments. 29324 29325 Your definition of the macro `RETURN_POPS_ARGS' decides which 29326 functions pop their own arguments. `TARGET_ASM_FUNCTION_EPILOGUE' 29327 needs to know what was decided. The number of bytes of the current 29328 function's arguments that this function should pop is available in 29329 `crtl->args.pops_args'. *Note Scalar Return::. 29330 29331 * A region of `current_function_pretend_args_size' bytes of 29332 uninitialized space just underneath the first argument arriving on 29333 the stack. (This may not be at the very start of the allocated 29334 stack region if the calling sequence has pushed anything else 29335 since pushing the stack arguments. But usually, on such machines, 29336 nothing else has been pushed yet, because the function prologue 29337 itself does all the pushing.) This region is used on machines 29338 where an argument may be passed partly in registers and partly in 29339 memory, and, in some cases to support the features in `<stdarg.h>'. 29340 29341 * An area of memory used to save certain registers used by the 29342 function. The size of this area, which may also include space for 29343 such things as the return address and pointers to previous stack 29344 frames, is machine-specific and usually depends on which registers 29345 have been used in the function. Machines with register windows 29346 often do not require a save area. 29347 29348 * A region of at least SIZE bytes, possibly rounded up to an 29349 allocation boundary, to contain the local variables of the 29350 function. On some machines, this region and the save area may 29351 occur in the opposite order, with the save area closer to the top 29352 of the stack. 29353 29354 * Optionally, when `ACCUMULATE_OUTGOING_ARGS' is defined, a region of 29355 `current_function_outgoing_args_size' bytes to be used for outgoing 29356 argument lists of the function. *Note Stack Arguments::. 29357 29358 -- Macro: EXIT_IGNORE_STACK 29359 Define this macro as a C expression that is nonzero if the return 29360 instruction or the function epilogue ignores the value of the stack 29361 pointer; in other words, if it is safe to delete an instruction to 29362 adjust the stack pointer before a return from the function. The 29363 default is 0. 29364 29365 Note that this macro's value is relevant only for functions for 29366 which frame pointers are maintained. It is never safe to delete a 29367 final stack adjustment in a function that has no frame pointer, 29368 and the compiler knows this regardless of `EXIT_IGNORE_STACK'. 29369 29370 -- Macro: EPILOGUE_USES (REGNO) 29371 Define this macro as a C expression that is nonzero for registers 29372 that are used by the epilogue or the `return' pattern. The stack 29373 and frame pointer registers are already assumed to be used as 29374 needed. 29375 29376 -- Macro: EH_USES (REGNO) 29377 Define this macro as a C expression that is nonzero for registers 29378 that are used by the exception handling mechanism, and so should 29379 be considered live on entry to an exception edge. 29380 29381 -- Macro: DELAY_SLOTS_FOR_EPILOGUE 29382 Define this macro if the function epilogue contains delay slots to 29383 which instructions from the rest of the function can be "moved". 29384 The definition should be a C expression whose value is an integer 29385 representing the number of delay slots there. 29386 29387 -- Macro: ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N) 29388 A C expression that returns 1 if INSN can be placed in delay slot 29389 number N of the epilogue. 29390 29391 The argument N is an integer which identifies the delay slot now 29392 being considered (since different slots may have different rules of 29393 eligibility). It is never negative and is always less than the 29394 number of epilogue delay slots (what `DELAY_SLOTS_FOR_EPILOGUE' 29395 returns). If you reject a particular insn for a given delay slot, 29396 in principle, it may be reconsidered for a subsequent delay slot. 29397 Also, other insns may (at least in principle) be considered for 29398 the so far unfilled delay slot. 29399 29400 The insns accepted to fill the epilogue delay slots are put in an 29401 RTL list made with `insn_list' objects, stored in the variable 29402 `current_function_epilogue_delay_list'. The insn for the first 29403 delay slot comes first in the list. Your definition of the macro 29404 `TARGET_ASM_FUNCTION_EPILOGUE' should fill the delay slots by 29405 outputting the insns in this list, usually by calling 29406 `final_scan_insn'. 29407 29408 You need not define this macro if you did not define 29409 `DELAY_SLOTS_FOR_EPILOGUE'. 29410 29411 -- Target Hook: void TARGET_ASM_OUTPUT_MI_THUNK (FILE *FILE, tree 29412 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT 29413 VCALL_OFFSET, tree FUNCTION) 29414 A function that outputs the assembler code for a thunk function, 29415 used to implement C++ virtual function calls with multiple 29416 inheritance. The thunk acts as a wrapper around a virtual 29417 function, adjusting the implicit object parameter before handing 29418 control off to the real function. 29419 29420 First, emit code to add the integer DELTA to the location that 29421 contains the incoming first argument. Assume that this argument 29422 contains a pointer, and is the one used to pass the `this' pointer 29423 in C++. This is the incoming argument _before_ the function 29424 prologue, e.g. `%o0' on a sparc. The addition must preserve the 29425 values of all other incoming arguments. 29426 29427 Then, if VCALL_OFFSET is nonzero, an additional adjustment should 29428 be made after adding `delta'. In particular, if P is the adjusted 29429 pointer, the following adjustment should be made: 29430 29431 p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)] 29432 29433 After the additions, emit code to jump to FUNCTION, which is a 29434 `FUNCTION_DECL'. This is a direct pure jump, not a call, and does 29435 not touch the return address. Hence returning from FUNCTION will 29436 return to whoever called the current `thunk'. 29437 29438 The effect must be as if FUNCTION had been called directly with 29439 the adjusted first argument. This macro is responsible for 29440 emitting all of the code for a thunk function; 29441 `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE' 29442 are not invoked. 29443 29444 The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already 29445 been extracted from it.) It might possibly be useful on some 29446 targets, but probably not. 29447 29448 If you do not define this macro, the target-independent code in 29449 the C++ front end will generate a less efficient heavyweight thunk 29450 that calls FUNCTION instead of jumping to it. The generic 29451 approach does not support varargs. 29452 29453 -- Target Hook: bool TARGET_ASM_CAN_OUTPUT_MI_THUNK (const_tree 29454 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT 29455 VCALL_OFFSET, const_tree FUNCTION) 29456 A function that returns true if TARGET_ASM_OUTPUT_MI_THUNK would 29457 be able to output the assembler code for the thunk function 29458 specified by the arguments it is passed, and false otherwise. In 29459 the latter case, the generic approach will be used by the C++ 29460 front end, with the limitations previously exposed. 29461 29462 29463File: gccint.info, Node: Profiling, Next: Tail Calls, Prev: Function Entry, Up: Stack and Calling 29464 2946517.10.12 Generating Code for Profiling 29466-------------------------------------- 29467 29468These macros will help you generate code for profiling. 29469 29470 -- Macro: FUNCTION_PROFILER (FILE, LABELNO) 29471 A C statement or compound statement to output to FILE some 29472 assembler code to call the profiling subroutine `mcount'. 29473 29474 The details of how `mcount' expects to be called are determined by 29475 your operating system environment, not by GCC. To figure them out, 29476 compile a small program for profiling using the system's installed 29477 C compiler and look at the assembler code that results. 29478 29479 Older implementations of `mcount' expect the address of a counter 29480 variable to be loaded into some register. The name of this 29481 variable is `LP' followed by the number LABELNO, so you would 29482 generate the name using `LP%d' in a `fprintf'. 29483 29484 -- Macro: PROFILE_HOOK 29485 A C statement or compound statement to output to FILE some assembly 29486 code to call the profiling subroutine `mcount' even the target does 29487 not support profiling. 29488 29489 -- Macro: NO_PROFILE_COUNTERS 29490 Define this macro to be an expression with a nonzero value if the 29491 `mcount' subroutine on your system does not need a counter variable 29492 allocated for each function. This is true for almost all modern 29493 implementations. If you define this macro, you must not use the 29494 LABELNO argument to `FUNCTION_PROFILER'. 29495 29496 -- Macro: PROFILE_BEFORE_PROLOGUE 29497 Define this macro if the code for function profiling should come 29498 before the function prologue. Normally, the profiling code comes 29499 after. 29500 29501 29502File: gccint.info, Node: Tail Calls, Next: Stack Smashing Protection, Prev: Profiling, Up: Stack and Calling 29503 2950417.10.13 Permitting tail calls 29505------------------------------ 29506 29507 -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree 29508 EXP) 29509 True if it is ok to do sibling call optimization for the specified 29510 call expression EXP. DECL will be the called function, or `NULL' 29511 if this is an indirect call. 29512 29513 It is not uncommon for limitations of calling conventions to 29514 prevent tail calls to functions outside the current unit of 29515 translation, or during PIC compilation. The hook is used to 29516 enforce these restrictions, as the `sibcall' md pattern can not 29517 fail, or fall over to a "normal" call. The criteria for 29518 successful sibling call optimization may vary greatly between 29519 different architectures. 29520 29521 -- Target Hook: void TARGET_EXTRA_LIVE_ON_ENTRY (bitmap REGS) 29522 Add any hard registers to REGS that are live on entry to the 29523 function. This hook only needs to be defined to provide registers 29524 that cannot be found by examination of FUNCTION_ARG_REGNO_P, the 29525 callee saved registers, STATIC_CHAIN_INCOMING_REGNUM, 29526 STATIC_CHAIN_REGNUM, TARGET_STRUCT_VALUE_RTX, 29527 FRAME_POINTER_REGNUM, EH_USES, FRAME_POINTER_REGNUM, 29528 ARG_POINTER_REGNUM, and the PIC_OFFSET_TABLE_REGNUM. 29529 29530 29531File: gccint.info, Node: Stack Smashing Protection, Prev: Tail Calls, Up: Stack and Calling 29532 2953317.10.14 Stack smashing protection 29534---------------------------------- 29535 29536 -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void) 29537 This hook returns a `DECL' node for the external variable to use 29538 for the stack protection guard. This variable is initialized by 29539 the runtime to some random value and is used to initialize the 29540 guard value that is placed at the top of the local stack frame. 29541 The type of this variable must be `ptr_type_node'. 29542 29543 The default version of this hook creates a variable called 29544 `__stack_chk_guard', which is normally defined in `libgcc2.c'. 29545 29546 -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void) 29547 This hook returns a tree expression that alerts the runtime that 29548 the stack protect guard variable has been modified. This 29549 expression should involve a call to a `noreturn' function. 29550 29551 The default version of this hook invokes a function called 29552 `__stack_chk_fail', taking no arguments. This function is 29553 normally defined in `libgcc2.c'. 29554 29555 29556File: gccint.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros 29557 2955817.11 Implementing the Varargs Macros 29559===================================== 29560 29561GCC comes with an implementation of `<varargs.h>' and `<stdarg.h>' that 29562work without change on machines that pass arguments on the stack. 29563Other machines require their own implementations of varargs, and the 29564two machine independent header files must have conditionals to include 29565it. 29566 29567 ISO `<stdarg.h>' differs from traditional `<varargs.h>' mainly in the 29568calling convention for `va_start'. The traditional implementation 29569takes just one argument, which is the variable in which to store the 29570argument pointer. The ISO implementation of `va_start' takes an 29571additional second argument. The user is supposed to write the last 29572named argument of the function here. 29573 29574 However, `va_start' should not use this argument. The way to find the 29575end of the named arguments is with the built-in functions described 29576below. 29577 29578 -- Macro: __builtin_saveregs () 29579 Use this built-in function to save the argument registers in 29580 memory so that the varargs mechanism can access them. Both ISO 29581 and traditional versions of `va_start' must use 29582 `__builtin_saveregs', unless you use 29583 `TARGET_SETUP_INCOMING_VARARGS' (see below) instead. 29584 29585 On some machines, `__builtin_saveregs' is open-coded under the 29586 control of the target hook `TARGET_EXPAND_BUILTIN_SAVEREGS'. On 29587 other machines, it calls a routine written in assembler language, 29588 found in `libgcc2.c'. 29589 29590 Code generated for the call to `__builtin_saveregs' appears at the 29591 beginning of the function, as opposed to where the call to 29592 `__builtin_saveregs' is written, regardless of what the code is. 29593 This is because the registers must be saved before the function 29594 starts to use them for its own purposes. 29595 29596 -- Macro: __builtin_args_info (CATEGORY) 29597 Use this built-in function to find the first anonymous arguments in 29598 registers. 29599 29600 In general, a machine may have several categories of registers 29601 used for arguments, each for a particular category of data types. 29602 (For example, on some machines, floating-point registers are used 29603 for floating-point arguments while other arguments are passed in 29604 the general registers.) To make non-varargs functions use the 29605 proper calling convention, you have defined the `CUMULATIVE_ARGS' 29606 data type to record how many registers in each category have been 29607 used so far 29608 29609 `__builtin_args_info' accesses the same data structure of type 29610 `CUMULATIVE_ARGS' after the ordinary argument layout is finished 29611 with it, with CATEGORY specifying which word to access. Thus, the 29612 value indicates the first unused register in a given category. 29613 29614 Normally, you would use `__builtin_args_info' in the implementation 29615 of `va_start', accessing each category just once and storing the 29616 value in the `va_list' object. This is because `va_list' will 29617 have to update the values, and there is no way to alter the values 29618 accessed by `__builtin_args_info'. 29619 29620 -- Macro: __builtin_next_arg (LASTARG) 29621 This is the equivalent of `__builtin_args_info', for stack 29622 arguments. It returns the address of the first anonymous stack 29623 argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns 29624 the address of the location above the first anonymous stack 29625 argument. Use it in `va_start' to initialize the pointer for 29626 fetching arguments from the stack. Also use it in `va_start' to 29627 verify that the second parameter LASTARG is the last named argument 29628 of the current function. 29629 29630 -- Macro: __builtin_classify_type (OBJECT) 29631 Since each machine has its own conventions for which data types are 29632 passed in which kind of register, your implementation of `va_arg' 29633 has to embody these conventions. The easiest way to categorize the 29634 specified data type is to use `__builtin_classify_type' together 29635 with `sizeof' and `__alignof__'. 29636 29637 `__builtin_classify_type' ignores the value of OBJECT, considering 29638 only its data type. It returns an integer describing what kind of 29639 type that is--integer, floating, pointer, structure, and so on. 29640 29641 The file `typeclass.h' defines an enumeration that you can use to 29642 interpret the values of `__builtin_classify_type'. 29643 29644 These machine description macros help implement varargs: 29645 29646 -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void) 29647 If defined, this hook produces the machine-specific code for a 29648 call to `__builtin_saveregs'. This code will be moved to the very 29649 beginning of the function, before any parameter access are made. 29650 The return value of this function should be an RTX that contains 29651 the value to use as the return of `__builtin_saveregs'. 29652 29653 -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (CUMULATIVE_ARGS 29654 *ARGS_SO_FAR, enum machine_mode MODE, tree TYPE, int 29655 *PRETEND_ARGS_SIZE, int SECOND_TIME) 29656 This target hook offers an alternative to using 29657 `__builtin_saveregs' and defining the hook 29658 `TARGET_EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous 29659 register arguments into the stack so that all the arguments appear 29660 to have been passed consecutively on the stack. Once this is 29661 done, you can use the standard implementation of varargs that 29662 works for machines that pass all their arguments on the stack. 29663 29664 The argument ARGS_SO_FAR points to the `CUMULATIVE_ARGS' data 29665 structure, containing the values that are obtained after 29666 processing the named arguments. The arguments MODE and TYPE 29667 describe the last named argument--its machine mode and its data 29668 type as a tree node. 29669 29670 The target hook should do two things: first, push onto the stack 29671 all the argument registers _not_ used for the named arguments, and 29672 second, store the size of the data thus pushed into the 29673 `int'-valued variable pointed to by PRETEND_ARGS_SIZE. The value 29674 that you store here will serve as additional offset for setting up 29675 the stack frame. 29676 29677 Because you must generate code to push the anonymous arguments at 29678 compile time without knowing their data types, 29679 `TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that 29680 have just a single category of argument register and use it 29681 uniformly for all data types. 29682 29683 If the argument SECOND_TIME is nonzero, it means that the 29684 arguments of the function are being analyzed for the second time. 29685 This happens for an inline function, which is not actually 29686 compiled until the end of the source file. The hook 29687 `TARGET_SETUP_INCOMING_VARARGS' should not generate any 29688 instructions in this case. 29689 29690 -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (CUMULATIVE_ARGS 29691 *CA) 29692 Define this hook to return `true' if the location where a function 29693 argument is passed depends on whether or not it is a named 29694 argument. 29695 29696 This hook controls how the NAMED argument to `FUNCTION_ARG' is set 29697 for varargs and stdarg functions. If this hook returns `true', 29698 the NAMED argument is always true for named arguments, and false 29699 for unnamed arguments. If it returns `false', but 29700 `TARGET_PRETEND_OUTGOING_VARARGS_NAMED' returns `true', then all 29701 arguments are treated as named. Otherwise, all named arguments 29702 except the last are treated as named. 29703 29704 You need not define this hook if it always returns `false'. 29705 29706 -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED 29707 (CUMULATIVE_ARGS *CA) 29708 If you need to conditionally change ABIs so that one works with 29709 `TARGET_SETUP_INCOMING_VARARGS', but the other works like neither 29710 `TARGET_SETUP_INCOMING_VARARGS' nor 29711 `TARGET_STRICT_ARGUMENT_NAMING' was defined, then define this hook 29712 to return `true' if `TARGET_SETUP_INCOMING_VARARGS' is used, 29713 `false' otherwise. Otherwise, you should not define this hook. 29714 29715 29716File: gccint.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros 29717 2971817.12 Trampolines for Nested Functions 29719====================================== 29720 29721A "trampoline" is a small piece of code that is created at run time 29722when the address of a nested function is taken. It normally resides on 29723the stack, in the stack frame of the containing function. These macros 29724tell GCC how to generate code to allocate and initialize a trampoline. 29725 29726 The instructions in the trampoline must do two things: load a constant 29727address into the static chain register, and jump to the real address of 29728the nested function. On CISC machines such as the m68k, this requires 29729two instructions, a move immediate and a jump. Then the two addresses 29730exist in the trampoline as word-long immediate operands. On RISC 29731machines, it is often necessary to load each address into a register in 29732two parts. Then pieces of each address form separate immediate 29733operands. 29734 29735 The code generated to initialize the trampoline must store the variable 29736parts--the static chain value and the function address--into the 29737immediate operands of the instructions. On a CISC machine, this is 29738simply a matter of copying each address to a memory reference at the 29739proper offset from the start of the trampoline. On a RISC machine, it 29740may be necessary to take out pieces of the address and store them 29741separately. 29742 29743 -- Target Hook: void TARGET_ASM_TRAMPOLINE_TEMPLATE (FILE *F) 29744 This hook is called by `assemble_trampoline_template' to output, 29745 on the stream F, assembler code for a block of data that contains 29746 the constant parts of a trampoline. This code should not include a 29747 label--the label is taken care of automatically. 29748 29749 If you do not define this hook, it means no template is needed for 29750 the target. Do not define this hook on systems where the block 29751 move code to copy the trampoline into place would be larger than 29752 the code to generate it on the spot. 29753 29754 -- Macro: TRAMPOLINE_SECTION 29755 Return the section into which the trampoline template is to be 29756 placed (*note Sections::). The default value is 29757 `readonly_data_section'. 29758 29759 -- Macro: TRAMPOLINE_SIZE 29760 A C expression for the size in bytes of the trampoline, as an 29761 integer. 29762 29763 -- Macro: TRAMPOLINE_ALIGNMENT 29764 Alignment required for trampolines, in bits. 29765 29766 If you don't define this macro, the value of `FUNCTION_ALIGNMENT' 29767 is used for aligning trampolines. 29768 29769 -- Target Hook: void TARGET_TRAMPOLINE_INIT (rtx M_TRAMP, tree FNDECL, 29770 rtx STATIC_CHAIN) 29771 This hook is called to initialize a trampoline. M_TRAMP is an RTX 29772 for the memory block for the trampoline; FNDECL is the 29773 `FUNCTION_DECL' for the nested function; STATIC_CHAIN is an RTX 29774 for the static chain value that should be passed to the function 29775 when it is called. 29776 29777 If the target defines `TARGET_ASM_TRAMPOLINE_TEMPLATE', then the 29778 first thing this hook should do is emit a block move into M_TRAMP 29779 from the memory block returned by `assemble_trampoline_template'. 29780 Note that the block move need only cover the constant parts of the 29781 trampoline. If the target isolates the variable parts of the 29782 trampoline to the end, not all `TRAMPOLINE_SIZE' bytes need be 29783 copied. 29784 29785 If the target requires any other actions, such as flushing caches 29786 or enabling stack execution, these actions should be performed 29787 after initializing the trampoline proper. 29788 29789 -- Target Hook: rtx TARGET_TRAMPOLINE_ADJUST_ADDRESS (rtx ADDR) 29790 This hook should perform any machine-specific adjustment in the 29791 address of the trampoline. Its argument contains the address of 29792 the memory block that was passed to `TARGET_TRAMPOLINE_INIT'. In 29793 case the address to be used for a function call should be 29794 different from the address at which the template was stored, the 29795 different address should be returned; otherwise ADDR should be 29796 returned unchanged. If this hook is not defined, ADDR will be 29797 used for function calls. 29798 29799 Implementing trampolines is difficult on many machines because they 29800have separate instruction and data caches. Writing into a stack 29801location fails to clear the memory in the instruction cache, so when 29802the program jumps to that location, it executes the old contents. 29803 29804 Here are two possible solutions. One is to clear the relevant parts of 29805the instruction cache whenever a trampoline is set up. The other is to 29806make all trampolines identical, by having them jump to a standard 29807subroutine. The former technique makes trampoline execution faster; the 29808latter makes initialization faster. 29809 29810 To clear the instruction cache when a trampoline is initialized, define 29811the following macro. 29812 29813 -- Macro: CLEAR_INSN_CACHE (BEG, END) 29814 If defined, expands to a C expression clearing the _instruction 29815 cache_ in the specified interval. The definition of this macro 29816 would typically be a series of `asm' statements. Both BEG and END 29817 are both pointer expressions. 29818 29819 The operating system may also require the stack to be made executable 29820before calling the trampoline. To implement this requirement, define 29821the following macro. 29822 29823 -- Macro: ENABLE_EXECUTE_STACK 29824 Define this macro if certain operations must be performed before 29825 executing code located on the stack. The macro should expand to a 29826 series of C file-scope constructs (e.g. functions) and provide a 29827 unique entry point named `__enable_execute_stack'. The target is 29828 responsible for emitting calls to the entry point in the code, for 29829 example from the `TARGET_TRAMPOLINE_INIT' hook. 29830 29831 To use a standard subroutine, define the following macro. In addition, 29832you must make sure that the instructions in a trampoline fill an entire 29833cache line with identical instructions, or else ensure that the 29834beginning of the trampoline code is always aligned at the same point in 29835its cache line. Look in `m68k.h' as a guide. 29836 29837 -- Macro: TRANSFER_FROM_TRAMPOLINE 29838 Define this macro if trampolines need a special subroutine to do 29839 their work. The macro should expand to a series of `asm' 29840 statements which will be compiled with GCC. They go in a library 29841 function named `__transfer_from_trampoline'. 29842 29843 If you need to avoid executing the ordinary prologue code of a 29844 compiled C function when you jump to the subroutine, you can do so 29845 by placing a special label of your own in the assembler code. Use 29846 one `asm' statement to generate an assembler label, and another to 29847 make the label global. Then trampolines can use that label to 29848 jump directly to your special assembler code. 29849 29850 29851File: gccint.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros 29852 2985317.13 Implicit Calls to Library Routines 29854======================================== 29855 29856Here is an explanation of implicit calls to library routines. 29857 29858 -- Macro: DECLARE_LIBRARY_RENAMES 29859 This macro, if defined, should expand to a piece of C code that 29860 will get expanded when compiling functions for libgcc.a. It can 29861 be used to provide alternate names for GCC's internal library 29862 functions if there are ABI-mandated names that the compiler should 29863 provide. 29864 29865 -- Target Hook: void TARGET_INIT_LIBFUNCS (void) 29866 This hook should declare additional library routines or rename 29867 existing ones, using the functions `set_optab_libfunc' and 29868 `init_one_libfunc' defined in `optabs.c'. `init_optabs' calls 29869 this macro after initializing all the normal library routines. 29870 29871 The default is to do nothing. Most ports don't need to define 29872 this hook. 29873 29874 -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON) 29875 This macro should return `true' if the library routine that 29876 implements the floating point comparison operator COMPARISON in 29877 mode MODE will return a boolean, and FALSE if it will return a 29878 tristate. 29879 29880 GCC's own floating point libraries return tristates from the 29881 comparison operators, so the default returns false always. Most 29882 ports don't need to define this macro. 29883 29884 -- Macro: TARGET_LIB_INT_CMP_BIASED 29885 This macro should evaluate to `true' if the integer comparison 29886 functions (like `__cmpdi2') return 0 to indicate that the first 29887 operand is smaller than the second, 1 to indicate that they are 29888 equal, and 2 to indicate that the first operand is greater than 29889 the second. If this macro evaluates to `false' the comparison 29890 functions return -1, 0, and 1 instead of 0, 1, and 2. If the 29891 target uses the routines in `libgcc.a', you do not need to define 29892 this macro. 29893 29894 -- Macro: US_SOFTWARE_GOFAST 29895 Define this macro if your system C library uses the US Software 29896 GOFAST library to provide floating point emulation. 29897 29898 In addition to defining this macro, your architecture must set 29899 `TARGET_INIT_LIBFUNCS' to `gofast_maybe_init_libfuncs', or else 29900 call that function from its version of that hook. It is defined 29901 in `config/gofast.h', which must be included by your 29902 architecture's `CPU.c' file. See `sparc/sparc.c' for an example. 29903 29904 If this macro is defined, the 29905 `TARGET_FLOAT_LIB_COMPARE_RETURNS_BOOL' target hook must return 29906 false for `SFmode' and `DFmode' comparisons. 29907 29908 -- Macro: TARGET_EDOM 29909 The value of `EDOM' on the target machine, as a C integer constant 29910 expression. If you don't define this macro, GCC does not attempt 29911 to deposit the value of `EDOM' into `errno' directly. Look in 29912 `/usr/include/errno.h' to find the value of `EDOM' on your system. 29913 29914 If you do not define `TARGET_EDOM', then compiled code reports 29915 domain errors by calling the library function and letting it 29916 report the error. If mathematical functions on your system use 29917 `matherr' when there is an error, then you should leave 29918 `TARGET_EDOM' undefined so that `matherr' is used normally. 29919 29920 -- Macro: GEN_ERRNO_RTX 29921 Define this macro as a C expression to create an rtl expression 29922 that refers to the global "variable" `errno'. (On certain systems, 29923 `errno' may not actually be a variable.) If you don't define this 29924 macro, a reasonable default is used. 29925 29926 -- Macro: TARGET_C99_FUNCTIONS 29927 When this macro is nonzero, GCC will implicitly optimize `sin' 29928 calls into `sinf' and similarly for other functions defined by C99 29929 standard. The default is zero because a number of existing 29930 systems lack support for these functions in their runtime so this 29931 macro needs to be redefined to one on systems that do support the 29932 C99 runtime. 29933 29934 -- Macro: TARGET_HAS_SINCOS 29935 When this macro is nonzero, GCC will implicitly optimize calls to 29936 `sin' and `cos' with the same argument to a call to `sincos'. The 29937 default is zero. The target has to provide the following 29938 functions: 29939 void sincos(double x, double *sin, double *cos); 29940 void sincosf(float x, float *sin, float *cos); 29941 void sincosl(long double x, long double *sin, long double *cos); 29942 29943 -- Macro: NEXT_OBJC_RUNTIME 29944 Define this macro to generate code for Objective-C message sending 29945 using the calling convention of the NeXT system. This calling 29946 convention involves passing the object, the selector and the 29947 method arguments all at once to the method-lookup library function. 29948 29949 The default calling convention passes just the object and the 29950 selector to the lookup function, which returns a pointer to the 29951 method. 29952 29953 29954File: gccint.info, Node: Addressing Modes, Next: Anchored Addresses, Prev: Library Calls, Up: Target Macros 29955 2995617.14 Addressing Modes 29957====================== 29958 29959This is about addressing modes. 29960 29961 -- Macro: HAVE_PRE_INCREMENT 29962 -- Macro: HAVE_PRE_DECREMENT 29963 -- Macro: HAVE_POST_INCREMENT 29964 -- Macro: HAVE_POST_DECREMENT 29965 A C expression that is nonzero if the machine supports 29966 pre-increment, pre-decrement, post-increment, or post-decrement 29967 addressing respectively. 29968 29969 -- Macro: HAVE_PRE_MODIFY_DISP 29970 -- Macro: HAVE_POST_MODIFY_DISP 29971 A C expression that is nonzero if the machine supports pre- or 29972 post-address side-effect generation involving constants other than 29973 the size of the memory operand. 29974 29975 -- Macro: HAVE_PRE_MODIFY_REG 29976 -- Macro: HAVE_POST_MODIFY_REG 29977 A C expression that is nonzero if the machine supports pre- or 29978 post-address side-effect generation involving a register 29979 displacement. 29980 29981 -- Macro: CONSTANT_ADDRESS_P (X) 29982 A C expression that is 1 if the RTX X is a constant which is a 29983 valid address. On most machines the default definition of 29984 `(CONSTANT_P (X) && GET_CODE (X) != CONST_DOUBLE)' is acceptable, 29985 but a few machines are more restrictive as to which constant 29986 addresses are supported. 29987 29988 -- Macro: CONSTANT_P (X) 29989 `CONSTANT_P', which is defined by target-independent code, accepts 29990 integer-values expressions whose values are not explicitly known, 29991 such as `symbol_ref', `label_ref', and `high' expressions and 29992 `const' arithmetic expressions, in addition to `const_int' and 29993 `const_double' expressions. 29994 29995 -- Macro: MAX_REGS_PER_ADDRESS 29996 A number, the maximum number of registers that can appear in a 29997 valid memory address. Note that it is up to you to specify a 29998 value equal to the maximum number that 29999 `TARGET_LEGITIMATE_ADDRESS_P' would ever accept. 30000 30001 -- Target Hook: bool TARGET_LEGITIMATE_ADDRESS_P (enum machine_mode 30002 MODE, rtx X, bool STRICT) 30003 A function that returns whether X (an RTX) is a legitimate memory 30004 address on the target machine for a memory operand of mode MODE. 30005 30006 Legitimate addresses are defined in two variants: a strict variant 30007 and a non-strict one. The STRICT parameter chooses which variant 30008 is desired by the caller. 30009 30010 The strict variant is used in the reload pass. It must be defined 30011 so that any pseudo-register that has not been allocated a hard 30012 register is considered a memory reference. This is because in 30013 contexts where some kind of register is required, a 30014 pseudo-register with no hard register must be rejected. For 30015 non-hard registers, the strict variant should look up the 30016 `reg_renumber' array; it should then proceed using the hard 30017 register number in the array, or treat the pseudo as a memory 30018 reference if the array holds `-1'. 30019 30020 The non-strict variant is used in other passes. It must be 30021 defined to accept all pseudo-registers in every context where some 30022 kind of register is required. 30023 30024 Normally, constant addresses which are the sum of a `symbol_ref' 30025 and an integer are stored inside a `const' RTX to mark them as 30026 constant. Therefore, there is no need to recognize such sums 30027 specifically as legitimate addresses. Normally you would simply 30028 recognize any `const' as legitimate. 30029 30030 Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant 30031 sums that are not marked with `const'. It assumes that a naked 30032 `plus' indicates indexing. If so, then you _must_ reject such 30033 naked constant sums as illegitimate addresses, so that none of 30034 them will be given to `PRINT_OPERAND_ADDRESS'. 30035 30036 On some machines, whether a symbolic address is legitimate depends 30037 on the section that the address refers to. On these machines, 30038 define the target hook `TARGET_ENCODE_SECTION_INFO' to store the 30039 information into the `symbol_ref', and then check for it here. 30040 When you see a `const', you will have to look inside it to find the 30041 `symbol_ref' in order to determine the section. *Note Assembler 30042 Format::. 30043 30044 Some ports are still using a deprecated legacy substitute for this 30045 hook, the `GO_IF_LEGITIMATE_ADDRESS' macro. This macro has this 30046 syntax: 30047 30048 #define GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL) 30049 30050 and should `goto LABEL' if the address X is a valid address on the 30051 target machine for a memory operand of mode MODE. Whether the 30052 strict or non-strict variants are desired is defined by the 30053 `REG_OK_STRICT' macro introduced earlier in this section. Using 30054 the hook is usually simpler because it limits the number of files 30055 that are recompiled when changes are made. 30056 30057 -- Macro: TARGET_MEM_CONSTRAINT 30058 A single character to be used instead of the default `'m'' 30059 character for general memory addresses. This defines the 30060 constraint letter which matches the memory addresses accepted by 30061 `TARGET_LEGITIMATE_ADDRESS_P'. Define this macro if you want to 30062 support new address formats in your back end without changing the 30063 semantics of the `'m'' constraint. This is necessary in order to 30064 preserve functionality of inline assembly constructs using the 30065 `'m'' constraint. 30066 30067 -- Macro: FIND_BASE_TERM (X) 30068 A C expression to determine the base term of address X, or to 30069 provide a simplified version of X from which `alias.c' can easily 30070 find the base term. This macro is used in only two places: 30071 `find_base_value' and `find_base_term' in `alias.c'. 30072 30073 It is always safe for this macro to not be defined. It exists so 30074 that alias analysis can understand machine-dependent addresses. 30075 30076 The typical use of this macro is to handle addresses containing a 30077 label_ref or symbol_ref within an UNSPEC. 30078 30079 -- Target Hook: rtx TARGET_LEGITIMIZE_ADDRESS (rtx X, rtx OLDX, enum 30080 machine_mode MODE) 30081 This hook is given an invalid memory address X for an operand of 30082 mode MODE and should try to return a valid memory address. 30083 30084 X will always be the result of a call to `break_out_memory_refs', 30085 and OLDX will be the operand that was given to that function to 30086 produce X. 30087 30088 The code of the hook should not alter the substructure of X. If 30089 it transforms X into a more legitimate form, it should return the 30090 new X. 30091 30092 It is not necessary for this hook to come up with a legitimate 30093 address. The compiler has standard ways of doing so in all cases. 30094 In fact, it is safe to omit this hook or make it return X if it 30095 cannot find a valid way to legitimize the address. But often a 30096 machine-dependent strategy can generate better code. 30097 30098 -- Macro: LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS, 30099 WIN) 30100 A C compound statement that attempts to replace X, which is an 30101 address that needs reloading, with a valid memory address for an 30102 operand of mode MODE. WIN will be a C statement label elsewhere 30103 in the code. It is not necessary to define this macro, but it 30104 might be useful for performance reasons. 30105 30106 For example, on the i386, it is sometimes possible to use a single 30107 reload register instead of two by reloading a sum of two pseudo 30108 registers into a register. On the other hand, for number of RISC 30109 processors offsets are limited so that often an intermediate 30110 address needs to be generated in order to address a stack slot. 30111 By defining `LEGITIMIZE_RELOAD_ADDRESS' appropriately, the 30112 intermediate addresses generated for adjacent some stack slots can 30113 be made identical, and thus be shared. 30114 30115 _Note_: This macro should be used with caution. It is necessary 30116 to know something of how reload works in order to effectively use 30117 this, and it is quite easy to produce macros that build in too 30118 much knowledge of reload internals. 30119 30120 _Note_: This macro must be able to reload an address created by a 30121 previous invocation of this macro. If it fails to handle such 30122 addresses then the compiler may generate incorrect code or abort. 30123 30124 The macro definition should use `push_reload' to indicate parts 30125 that need reloading; OPNUM, TYPE and IND_LEVELS are usually 30126 suitable to be passed unaltered to `push_reload'. 30127 30128 The code generated by this macro must not alter the substructure of 30129 X. If it transforms X into a more legitimate form, it should 30130 assign X (which will always be a C variable) a new value. This 30131 also applies to parts that you change indirectly by calling 30132 `push_reload'. 30133 30134 The macro definition may use `strict_memory_address_p' to test if 30135 the address has become legitimate. 30136 30137 If you want to change only a part of X, one standard way of doing 30138 this is to use `copy_rtx'. Note, however, that it unshares only a 30139 single level of rtl. Thus, if the part to be changed is not at the 30140 top level, you'll need to replace first the top level. It is not 30141 necessary for this macro to come up with a legitimate address; 30142 but often a machine-dependent strategy can generate better code. 30143 30144 -- Macro: GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL) 30145 A C statement or compound statement with a conditional `goto 30146 LABEL;' executed if memory address X (an RTX) can have different 30147 meanings depending on the machine mode of the memory reference it 30148 is used for or if the address is valid for some modes but not 30149 others. 30150 30151 Autoincrement and autodecrement addresses typically have 30152 mode-dependent effects because the amount of the increment or 30153 decrement is the size of the operand being addressed. Some 30154 machines have other mode-dependent addresses. Many RISC machines 30155 have no mode-dependent addresses. 30156 30157 You may assume that ADDR is a valid address for the machine. 30158 30159 -- Macro: LEGITIMATE_CONSTANT_P (X) 30160 A C expression that is nonzero if X is a legitimate constant for 30161 an immediate operand on the target machine. You can assume that X 30162 satisfies `CONSTANT_P', so you need not check this. In fact, `1' 30163 is a suitable definition for this macro on machines where anything 30164 `CONSTANT_P' is valid. 30165 30166 -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X) 30167 This hook is used to undo the possibly obfuscating effects of the 30168 `LEGITIMIZE_ADDRESS' and `LEGITIMIZE_RELOAD_ADDRESS' target 30169 macros. Some backend implementations of these macros wrap symbol 30170 references inside an `UNSPEC' rtx to represent PIC or similar 30171 addressing modes. This target hook allows GCC's optimizers to 30172 understand the semantics of these opaque `UNSPEC's by converting 30173 them back into their original form. 30174 30175 -- Target Hook: bool TARGET_CANNOT_FORCE_CONST_MEM (rtx X) 30176 This hook should return true if X is of a form that cannot (or 30177 should not) be spilled to the constant pool. The default version 30178 of this hook returns false. 30179 30180 The primary reason to define this hook is to prevent reload from 30181 deciding that a non-legitimate constant would be better reloaded 30182 from the constant pool instead of spilling and reloading a register 30183 holding the constant. This restriction is often true of addresses 30184 of TLS symbols for various targets. 30185 30186 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_CONSTANT_P (enum 30187 machine_mode MODE, const_rtx X) 30188 This hook should return true if pool entries for constant X can be 30189 placed in an `object_block' structure. MODE is the mode of X. 30190 30191 The default version returns false for all constants. 30192 30193 -- Target Hook: tree TARGET_BUILTIN_RECIPROCAL (unsigned FN, bool 30194 MD_FN, bool SQRT) 30195 This hook should return the DECL of a function that implements 30196 reciprocal of the builtin function with builtin function code FN, 30197 or `NULL_TREE' if such a function is not available. MD_FN is true 30198 when FN is a code of a machine-dependent builtin function. When 30199 SQRT is true, additional optimizations that apply only to the 30200 reciprocal of a square root function are performed, and only 30201 reciprocals of `sqrt' function are valid. 30202 30203 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void) 30204 This hook should return the DECL of a function F that given an 30205 address ADDR as an argument returns a mask M that can be used to 30206 extract from two vectors the relevant data that resides in ADDR in 30207 case ADDR is not properly aligned. 30208 30209 The autovectorizer, when vectorizing a load operation from an 30210 address ADDR that may be unaligned, will generate two vector loads 30211 from the two aligned addresses around ADDR. It then generates a 30212 `REALIGN_LOAD' operation to extract the relevant data from the two 30213 loaded vectors. The first two arguments to `REALIGN_LOAD', V1 and 30214 V2, are the two vectors, each of size VS, and the third argument, 30215 OFF, defines how the data will be extracted from these two 30216 vectors: if OFF is 0, then the returned vector is V2; otherwise, 30217 the returned vector is composed from the last VS-OFF elements of 30218 V1 concatenated to the first OFF elements of V2. 30219 30220 If this hook is defined, the autovectorizer will generate a call 30221 to F (using the DECL tree that this hook returns) and will use the 30222 return value of F as the argument OFF to `REALIGN_LOAD'. 30223 Therefore, the mask M returned by F should comply with the 30224 semantics expected by `REALIGN_LOAD' described above. If this 30225 hook is not defined, then ADDR will be used as the argument OFF to 30226 `REALIGN_LOAD', in which case the low log2(VS) - 1 bits of ADDR 30227 will be considered. 30228 30229 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_EVEN (tree X) 30230 This hook should return the DECL of a function F that implements 30231 widening multiplication of the even elements of two input vectors 30232 of type X. 30233 30234 If this hook is defined, the autovectorizer will use it along with 30235 the `TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_ODD' target hook when 30236 vectorizing widening multiplication in cases that the order of the 30237 results does not have to be preserved (e.g. used only by a 30238 reduction computation). Otherwise, the `widen_mult_hi/lo' idioms 30239 will be used. 30240 30241 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_ODD (tree X) 30242 This hook should return the DECL of a function F that implements 30243 widening multiplication of the odd elements of two input vectors 30244 of type X. 30245 30246 If this hook is defined, the autovectorizer will use it along with 30247 the `TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_EVEN' target hook when 30248 vectorizing widening multiplication in cases that the order of the 30249 results does not have to be preserved (e.g. used only by a 30250 reduction computation). Otherwise, the `widen_mult_hi/lo' idioms 30251 will be used. 30252 30253 -- Target Hook: int TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST (bool 30254 RUNTIME_TEST) 30255 Returns the cost to be added to the overhead involved with 30256 executing the vectorized version of a loop. 30257 30258 -- Target Hook: bool TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE 30259 (const_tree TYPE, bool IS_PACKED) 30260 Return true if vector alignment is reachable (by peeling N 30261 iterations) for the given type. 30262 30263 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VEC_PERM (tree TYPE, 30264 tree *MASK_ELEMENT_TYPE) 30265 Target builtin that implements vector permute. 30266 30267 -- Target Hook: bool TARGET_VECTORIZE_BUILTIN_VEC_PERM_OK (tree 30268 VEC_TYPE, tree MASK) 30269 Return true if a vector created for `builtin_vec_perm' is valid. 30270 30271 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_CONVERSION (unsigned 30272 CODE, tree TYPE) 30273 This hook should return the DECL of a function that implements 30274 conversion of the input vector of type TYPE. If TYPE is an 30275 integral type, the result of the conversion is a vector of 30276 floating-point type of the same size. If TYPE is a floating-point 30277 type, the result of the conversion is a vector of integral type of 30278 the same size. The value of CODE is one of the enumerators in 30279 `enum tree_code' and specifies how the conversion is to be applied 30280 (truncation, rounding, etc.). 30281 30282 If this hook is defined, the autovectorizer will use the 30283 `TARGET_VECTORIZE_BUILTIN_CONVERSION' target hook when vectorizing 30284 conversion. Otherwise, it will return `NULL_TREE'. 30285 30286 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION 30287 (tree FNDECL, tree VEC_TYPE_OUT, tree VEC_TYPE_IN) 30288 This hook should return the decl of a function that implements the 30289 vectorized variant of the builtin function with builtin function 30290 code CODE or `NULL_TREE' if such a function is not available. The 30291 value of FNDECL is the builtin function declaration. The return 30292 type of the vectorized function shall be of vector type 30293 VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN. 30294 30295 -- Target Hook: bool TARGET_SUPPORT_VECTOR_MISALIGNMENT (enum 30296 machine_mode MODE, const_tree TYPE, int MISALIGNMENT, bool 30297 IS_PACKED) 30298 This hook should return true if the target supports misaligned 30299 vector store/load of a specific factor denoted in the MISALIGNMENT 30300 parameter. The vector store/load should be of machine mode MODE 30301 and the elements in the vectors should be of type TYPE. IS_PACKED 30302 parameter is true if the memory access is defined in a packed 30303 struct. 30304 30305 30306File: gccint.info, Node: Anchored Addresses, Next: Condition Code, Prev: Addressing Modes, Up: Target Macros 30307 3030817.15 Anchored Addresses 30309======================== 30310 30311GCC usually addresses every static object as a separate entity. For 30312example, if we have: 30313 30314 static int a, b, c; 30315 int foo (void) { return a + b + c; } 30316 30317 the code for `foo' will usually calculate three separate symbolic 30318addresses: those of `a', `b' and `c'. On some targets, it would be 30319better to calculate just one symbolic address and access the three 30320variables relative to it. The equivalent pseudocode would be something 30321like: 30322 30323 int foo (void) 30324 { 30325 register int *xr = &x; 30326 return xr[&a - &x] + xr[&b - &x] + xr[&c - &x]; 30327 } 30328 30329 (which isn't valid C). We refer to shared addresses like `x' as 30330"section anchors". Their use is controlled by `-fsection-anchors'. 30331 30332 The hooks below describe the target properties that GCC needs to know 30333in order to make effective use of section anchors. It won't use 30334section anchors at all unless either `TARGET_MIN_ANCHOR_OFFSET' or 30335`TARGET_MAX_ANCHOR_OFFSET' is set to a nonzero value. 30336 30337 -- Target Hook: HOST_WIDE_INT TARGET_MIN_ANCHOR_OFFSET 30338 The minimum offset that should be applied to a section anchor. On 30339 most targets, it should be the smallest offset that can be applied 30340 to a base register while still giving a legitimate address for 30341 every mode. The default value is 0. 30342 30343 -- Target Hook: HOST_WIDE_INT TARGET_MAX_ANCHOR_OFFSET 30344 Like `TARGET_MIN_ANCHOR_OFFSET', but the maximum (inclusive) 30345 offset that should be applied to section anchors. The default 30346 value is 0. 30347 30348 -- Target Hook: void TARGET_ASM_OUTPUT_ANCHOR (rtx X) 30349 Write the assembly code to define section anchor X, which is a 30350 `SYMBOL_REF' for which `SYMBOL_REF_ANCHOR_P (X)' is true. The 30351 hook is called with the assembly output position set to the 30352 beginning of `SYMBOL_REF_BLOCK (X)'. 30353 30354 If `ASM_OUTPUT_DEF' is available, the hook's default definition 30355 uses it to define the symbol as `. + SYMBOL_REF_BLOCK_OFFSET (X)'. 30356 If `ASM_OUTPUT_DEF' is not available, the hook's default definition 30357 is `NULL', which disables the use of section anchors altogether. 30358 30359 -- Target Hook: bool TARGET_USE_ANCHORS_FOR_SYMBOL_P (const_rtx X) 30360 Return true if GCC should attempt to use anchors to access 30361 `SYMBOL_REF' X. You can assume `SYMBOL_REF_HAS_BLOCK_INFO_P (X)' 30362 and `!SYMBOL_REF_ANCHOR_P (X)'. 30363 30364 The default version is correct for most targets, but you might 30365 need to intercept this hook to handle things like target-specific 30366 attributes or target-specific sections. 30367 30368 30369File: gccint.info, Node: Condition Code, Next: Costs, Prev: Anchored Addresses, Up: Target Macros 30370 3037117.16 Condition Code Status 30372=========================== 30373 30374The macros in this section can be split in two families, according to 30375the two ways of representing condition codes in GCC. 30376 30377 The first representation is the so called `(cc0)' representation 30378(*note Jump Patterns::), where all instructions can have an implicit 30379clobber of the condition codes. The second is the condition code 30380register representation, which provides better schedulability for 30381architectures that do have a condition code register, but on which most 30382instructions do not affect it. The latter category includes most RISC 30383machines. 30384 30385 The implicit clobbering poses a strong restriction on the placement of 30386the definition and use of the condition code, which need to be in 30387adjacent insns for machines using `(cc0)'. This can prevent important 30388optimizations on some machines. For example, on the IBM RS/6000, there 30389is a delay for taken branches unless the condition code register is set 30390three instructions earlier than the conditional branch. The instruction 30391scheduler cannot perform this optimization if it is not permitted to 30392separate the definition and use of the condition code register. 30393 30394 For this reason, it is possible and suggested to use a register to 30395represent the condition code for new ports. If there is a specific 30396condition code register in the machine, use a hard register. If the 30397condition code or comparison result can be placed in any general 30398register, or if there are multiple condition registers, use a pseudo 30399register. Registers used to store the condition code value will 30400usually have a mode that is in class `MODE_CC'. 30401 30402 Alternatively, you can use `BImode' if the comparison operator is 30403specified already in the compare instruction. In this case, you are not 30404interested in most macros in this section. 30405 30406* Menu: 30407 30408* CC0 Condition Codes:: Old style representation of condition codes. 30409* MODE_CC Condition Codes:: Modern representation of condition codes. 30410* Cond. Exec. Macros:: Macros to control conditional execution. 30411 30412 30413File: gccint.info, Node: CC0 Condition Codes, Next: MODE_CC Condition Codes, Up: Condition Code 30414 3041517.16.1 Representation of condition codes using `(cc0)' 30416------------------------------------------------------- 30417 30418The file `conditions.h' defines a variable `cc_status' to describe how 30419the condition code was computed (in case the interpretation of the 30420condition code depends on the instruction that it was set by). This 30421variable contains the RTL expressions on which the condition code is 30422currently based, and several standard flags. 30423 30424 Sometimes additional machine-specific flags must be defined in the 30425machine description header file. It can also add additional 30426machine-specific information by defining `CC_STATUS_MDEP'. 30427 30428 -- Macro: CC_STATUS_MDEP 30429 C code for a data type which is used for declaring the `mdep' 30430 component of `cc_status'. It defaults to `int'. 30431 30432 This macro is not used on machines that do not use `cc0'. 30433 30434 -- Macro: CC_STATUS_MDEP_INIT 30435 A C expression to initialize the `mdep' field to "empty". The 30436 default definition does nothing, since most machines don't use the 30437 field anyway. If you want to use the field, you should probably 30438 define this macro to initialize it. 30439 30440 This macro is not used on machines that do not use `cc0'. 30441 30442 -- Macro: NOTICE_UPDATE_CC (EXP, INSN) 30443 A C compound statement to set the components of `cc_status' 30444 appropriately for an insn INSN whose body is EXP. It is this 30445 macro's responsibility to recognize insns that set the condition 30446 code as a byproduct of other activity as well as those that 30447 explicitly set `(cc0)'. 30448 30449 This macro is not used on machines that do not use `cc0'. 30450 30451 If there are insns that do not set the condition code but do alter 30452 other machine registers, this macro must check to see whether they 30453 invalidate the expressions that the condition code is recorded as 30454 reflecting. For example, on the 68000, insns that store in address 30455 registers do not set the condition code, which means that usually 30456 `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns. 30457 But suppose that the previous insn set the condition code based on 30458 location `a4@(102)' and the current insn stores a new value in 30459 `a4'. Although the condition code is not changed by this, it will 30460 no longer be true that it reflects the contents of `a4@(102)'. 30461 Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case 30462 to say that nothing is known about the condition code value. 30463 30464 The definition of `NOTICE_UPDATE_CC' must be prepared to deal with 30465 the results of peephole optimization: insns whose patterns are 30466 `parallel' RTXs containing various `reg', `mem' or constants which 30467 are just the operands. The RTL structure of these insns is not 30468 sufficient to indicate what the insns actually do. What 30469 `NOTICE_UPDATE_CC' should do when it sees one is just to run 30470 `CC_STATUS_INIT'. 30471 30472 A possible definition of `NOTICE_UPDATE_CC' is to call a function 30473 that looks at an attribute (*note Insn Attributes::) named, for 30474 example, `cc'. This avoids having detailed information about 30475 patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'. 30476 30477 30478File: gccint.info, Node: MODE_CC Condition Codes, Next: Cond. Exec. Macros, Prev: CC0 Condition Codes, Up: Condition Code 30479 3048017.16.2 Representation of condition codes using registers 30481--------------------------------------------------------- 30482 30483 -- Macro: SELECT_CC_MODE (OP, X, Y) 30484 On many machines, the condition code may be produced by other 30485 instructions than compares, for example the branch can use 30486 directly the condition code set by a subtract instruction. 30487 However, on some machines when the condition code is set this way 30488 some bits (such as the overflow bit) are not set in the same way 30489 as a test instruction, so that a different branch instruction must 30490 be used for some conditional branches. When this happens, use the 30491 machine mode of the condition code register to record different 30492 formats of the condition code register. Modes can also be used to 30493 record which compare instruction (e.g. a signed or an unsigned 30494 comparison) produced the condition codes. 30495 30496 If other modes than `CCmode' are required, add them to 30497 `MACHINE-modes.def' and define `SELECT_CC_MODE' to choose a mode 30498 given an operand of a compare. This is needed because the modes 30499 have to be chosen not only during RTL generation but also, for 30500 example, by instruction combination. The result of 30501 `SELECT_CC_MODE' should be consistent with the mode used in the 30502 patterns; for example to support the case of the add on the SPARC 30503 discussed above, we have the pattern 30504 30505 (define_insn "" 30506 [(set (reg:CC_NOOV 0) 30507 (compare:CC_NOOV 30508 (plus:SI (match_operand:SI 0 "register_operand" "%r") 30509 (match_operand:SI 1 "arith_operand" "rI")) 30510 (const_int 0)))] 30511 "" 30512 "...") 30513 30514 together with a `SELECT_CC_MODE' that returns `CC_NOOVmode' for 30515 comparisons whose argument is a `plus': 30516 30517 #define SELECT_CC_MODE(OP,X,Y) \ 30518 (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \ 30519 ? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode) \ 30520 : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ 30521 || GET_CODE (X) == NEG) \ 30522 ? CC_NOOVmode : CCmode)) 30523 30524 Another reason to use modes is to retain information on which 30525 operands were used by the comparison; see `REVERSIBLE_CC_MODE' 30526 later in this section. 30527 30528 You should define this macro if and only if you define extra CC 30529 modes in `MACHINE-modes.def'. 30530 30531 -- Macro: CANONICALIZE_COMPARISON (CODE, OP0, OP1) 30532 On some machines not all possible comparisons are defined, but you 30533 can convert an invalid comparison into a valid one. For example, 30534 the Alpha does not have a `GT' comparison, but you can use an `LT' 30535 comparison instead and swap the order of the operands. 30536 30537 On such machines, define this macro to be a C statement to do any 30538 required conversions. CODE is the initial comparison code and OP0 30539 and OP1 are the left and right operands of the comparison, 30540 respectively. You should modify CODE, OP0, and OP1 as required. 30541 30542 GCC will not assume that the comparison resulting from this macro 30543 is valid but will see if the resulting insn matches a pattern in 30544 the `md' file. 30545 30546 You need not define this macro if it would never change the 30547 comparison code or operands. 30548 30549 -- Macro: REVERSIBLE_CC_MODE (MODE) 30550 A C expression whose value is one if it is always safe to reverse a 30551 comparison whose mode is MODE. If `SELECT_CC_MODE' can ever 30552 return MODE for a floating-point inequality comparison, then 30553 `REVERSIBLE_CC_MODE (MODE)' must be zero. 30554 30555 You need not define this macro if it would always returns zero or 30556 if the floating-point format is anything other than 30557 `IEEE_FLOAT_FORMAT'. For example, here is the definition used on 30558 the SPARC, where floating-point inequality comparisons are always 30559 given `CCFPEmode': 30560 30561 #define REVERSIBLE_CC_MODE(MODE) ((MODE) != CCFPEmode) 30562 30563 -- Macro: REVERSE_CONDITION (CODE, MODE) 30564 A C expression whose value is reversed condition code of the CODE 30565 for comparison done in CC_MODE MODE. The macro is used only in 30566 case `REVERSIBLE_CC_MODE (MODE)' is nonzero. Define this macro in 30567 case machine has some non-standard way how to reverse certain 30568 conditionals. For instance in case all floating point conditions 30569 are non-trapping, compiler may freely convert unordered compares 30570 to ordered one. Then definition may look like: 30571 30572 #define REVERSE_CONDITION(CODE, MODE) \ 30573 ((MODE) != CCFPmode ? reverse_condition (CODE) \ 30574 : reverse_condition_maybe_unordered (CODE)) 30575 30576 -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int 30577 *P1, unsigned int *P2) 30578 On targets which do not use `(cc0)', and which use a hard register 30579 rather than a pseudo-register to hold condition codes, the regular 30580 CSE passes are often not able to identify cases in which the hard 30581 register is set to a common value. Use this hook to enable a 30582 small pass which optimizes such cases. This hook should return 30583 true to enable this pass, and it should set the integers to which 30584 its arguments point to the hard register numbers used for 30585 condition codes. When there is only one such register, as is true 30586 on most systems, the integer pointed to by P2 should be set to 30587 `INVALID_REGNUM'. 30588 30589 The default version of this hook returns false. 30590 30591 -- Target Hook: enum machine_mode TARGET_CC_MODES_COMPATIBLE (enum 30592 machine_mode M1, enum machine_mode M2) 30593 On targets which use multiple condition code modes in class 30594 `MODE_CC', it is sometimes the case that a comparison can be 30595 validly done in more than one mode. On such a system, define this 30596 target hook to take two mode arguments and to return a mode in 30597 which both comparisons may be validly done. If there is no such 30598 mode, return `VOIDmode'. 30599 30600 The default version of this hook checks whether the modes are the 30601 same. If they are, it returns that mode. If they are different, 30602 it returns `VOIDmode'. 30603 30604 30605File: gccint.info, Node: Cond. Exec. Macros, Prev: MODE_CC Condition Codes, Up: Condition Code 30606 3060717.16.3 Macros to control conditional execution 30608----------------------------------------------- 30609 30610There is one macro that may need to be defined for targets supporting 30611conditional execution, independent of how they represent conditional 30612branches. 30613 30614 -- Macro: REVERSE_CONDEXEC_PREDICATES_P (OP1, OP2) 30615 A C expression that returns true if the conditional execution 30616 predicate OP1, a comparison operation, is the inverse of OP2 and 30617 vice versa. Define this to return 0 if the target has conditional 30618 execution predicates that cannot be reversed safely. There is no 30619 need to validate that the arguments of op1 and op2 are the same, 30620 this is done separately. If no expansion is specified, this macro 30621 is defined as follows: 30622 30623 #define REVERSE_CONDEXEC_PREDICATES_P (x, y) \ 30624 (GET_CODE ((x)) == reversed_comparison_code ((y), NULL)) 30625 30626 30627File: gccint.info, Node: Costs, Next: Scheduling, Prev: Condition Code, Up: Target Macros 30628 3062917.17 Describing Relative Costs of Operations 30630============================================= 30631 30632These macros let you describe the relative speed of various operations 30633on the target machine. 30634 30635 -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO) 30636 A C expression for the cost of moving data of mode MODE from a 30637 register in class FROM to one in class TO. The classes are 30638 expressed using the enumeration values such as `GENERAL_REGS'. A 30639 value of 2 is the default; other values are interpreted relative to 30640 that. 30641 30642 It is not required that the cost always equal 2 when FROM is the 30643 same as TO; on some machines it is expensive to move between 30644 registers if they are not general registers. 30645 30646 If reload sees an insn consisting of a single `set' between two 30647 hard registers, and if `REGISTER_MOVE_COST' applied to their 30648 classes returns a value of 2, reload does not check to ensure that 30649 the constraints of the insn are met. Setting a cost of other than 30650 2 will allow reload to verify that the constraints are met. You 30651 should do this if the `movM' pattern's constraints do not allow 30652 such copying. 30653 30654 -- Macro: MEMORY_MOVE_COST (MODE, CLASS, IN) 30655 A C expression for the cost of moving data of mode MODE between a 30656 register of class CLASS and memory; IN is zero if the value is to 30657 be written to memory, nonzero if it is to be read in. This cost 30658 is relative to those in `REGISTER_MOVE_COST'. If moving between 30659 registers and memory is more expensive than between two registers, 30660 you should define this macro to express the relative cost. 30661 30662 If you do not define this macro, GCC uses a default cost of 4 plus 30663 the cost of copying via a secondary reload register, if one is 30664 needed. If your machine requires a secondary reload register to 30665 copy between memory and a register of CLASS but the reload 30666 mechanism is more complex than copying via an intermediate, define 30667 this macro to reflect the actual cost of the move. 30668 30669 GCC defines the function `memory_move_secondary_cost' if secondary 30670 reloads are needed. It computes the costs due to copying via a 30671 secondary register. If your machine copies from memory using a 30672 secondary register in the conventional way but the default base 30673 value of 4 is not correct for your machine, define this macro to 30674 add some other value to the result of that function. The 30675 arguments to that function are the same as to this macro. 30676 30677 -- Macro: BRANCH_COST (SPEED_P, PREDICTABLE_P) 30678 A C expression for the cost of a branch instruction. A value of 1 30679 is the default; other values are interpreted relative to that. 30680 Parameter SPEED_P is true when the branch in question should be 30681 optimized for speed. When it is false, `BRANCH_COST' should be 30682 returning value optimal for code size rather then performance 30683 considerations. PREDICTABLE_P is true for well predictable 30684 branches. On many architectures the `BRANCH_COST' can be reduced 30685 then. 30686 30687 Here are additional macros which do not specify precise relative costs, 30688but only that certain actions are more expensive than GCC would 30689ordinarily expect. 30690 30691 -- Macro: SLOW_BYTE_ACCESS 30692 Define this macro as a C expression which is nonzero if accessing 30693 less than a word of memory (i.e. a `char' or a `short') is no 30694 faster than accessing a word of memory, i.e., if such access 30695 require more than one instruction or if there is no difference in 30696 cost between byte and (aligned) word loads. 30697 30698 When this macro is not defined, the compiler will access a field by 30699 finding the smallest containing object; when it is defined, a 30700 fullword load will be used if alignment permits. Unless bytes 30701 accesses are faster than word accesses, using word accesses is 30702 preferable since it may eliminate subsequent memory access if 30703 subsequent accesses occur to other fields in the same word of the 30704 structure, but to different bytes. 30705 30706 -- Macro: SLOW_UNALIGNED_ACCESS (MODE, ALIGNMENT) 30707 Define this macro to be the value 1 if memory accesses described 30708 by the MODE and ALIGNMENT parameters have a cost many times greater 30709 than aligned accesses, for example if they are emulated in a trap 30710 handler. 30711 30712 When this macro is nonzero, the compiler will act as if 30713 `STRICT_ALIGNMENT' were nonzero when generating code for block 30714 moves. This can cause significantly more instructions to be 30715 produced. Therefore, do not set this macro nonzero if unaligned 30716 accesses only add a cycle or two to the time for a memory access. 30717 30718 If the value of this macro is always zero, it need not be defined. 30719 If this macro is defined, it should produce a nonzero value when 30720 `STRICT_ALIGNMENT' is nonzero. 30721 30722 -- Macro: MOVE_RATIO (SPEED) 30723 The threshold of number of scalar memory-to-memory move insns, 30724 _below_ which a sequence of insns should be generated instead of a 30725 string move insn or a library call. Increasing the value will 30726 always make code faster, but eventually incurs high cost in 30727 increased code size. 30728 30729 Note that on machines where the corresponding move insn is a 30730 `define_expand' that emits a sequence of insns, this macro counts 30731 the number of such sequences. 30732 30733 The parameter SPEED is true if the code is currently being 30734 optimized for speed rather than size. 30735 30736 If you don't define this, a reasonable default is used. 30737 30738 -- Macro: MOVE_BY_PIECES_P (SIZE, ALIGNMENT) 30739 A C expression used to determine whether `move_by_pieces' will be 30740 used to copy a chunk of memory, or whether some other block move 30741 mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns' 30742 returns less than `MOVE_RATIO'. 30743 30744 -- Macro: MOVE_MAX_PIECES 30745 A C expression used by `move_by_pieces' to determine the largest 30746 unit a load or store used to copy memory is. Defaults to 30747 `MOVE_MAX'. 30748 30749 -- Macro: CLEAR_RATIO (SPEED) 30750 The threshold of number of scalar move insns, _below_ which a 30751 sequence of insns should be generated to clear memory instead of a 30752 string clear insn or a library call. Increasing the value will 30753 always make code faster, but eventually incurs high cost in 30754 increased code size. 30755 30756 The parameter SPEED is true if the code is currently being 30757 optimized for speed rather than size. 30758 30759 If you don't define this, a reasonable default is used. 30760 30761 -- Macro: CLEAR_BY_PIECES_P (SIZE, ALIGNMENT) 30762 A C expression used to determine whether `clear_by_pieces' will be 30763 used to clear a chunk of memory, or whether some other block clear 30764 mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns' 30765 returns less than `CLEAR_RATIO'. 30766 30767 -- Macro: SET_RATIO (SPEED) 30768 The threshold of number of scalar move insns, _below_ which a 30769 sequence of insns should be generated to set memory to a constant 30770 value, instead of a block set insn or a library call. Increasing 30771 the value will always make code faster, but eventually incurs high 30772 cost in increased code size. 30773 30774 The parameter SPEED is true if the code is currently being 30775 optimized for speed rather than size. 30776 30777 If you don't define this, it defaults to the value of `MOVE_RATIO'. 30778 30779 -- Macro: SET_BY_PIECES_P (SIZE, ALIGNMENT) 30780 A C expression used to determine whether `store_by_pieces' will be 30781 used to set a chunk of memory to a constant value, or whether some 30782 other mechanism will be used. Used by `__builtin_memset' when 30783 storing values other than constant zero. Defaults to 1 if 30784 `move_by_pieces_ninsns' returns less than `SET_RATIO'. 30785 30786 -- Macro: STORE_BY_PIECES_P (SIZE, ALIGNMENT) 30787 A C expression used to determine whether `store_by_pieces' will be 30788 used to set a chunk of memory to a constant string value, or 30789 whether some other mechanism will be used. Used by 30790 `__builtin_strcpy' when called with a constant source string. 30791 Defaults to 1 if `move_by_pieces_ninsns' returns less than 30792 `MOVE_RATIO'. 30793 30794 -- Macro: USE_LOAD_POST_INCREMENT (MODE) 30795 A C expression used to determine whether a load postincrement is a 30796 good thing to use for a given mode. Defaults to the value of 30797 `HAVE_POST_INCREMENT'. 30798 30799 -- Macro: USE_LOAD_POST_DECREMENT (MODE) 30800 A C expression used to determine whether a load postdecrement is a 30801 good thing to use for a given mode. Defaults to the value of 30802 `HAVE_POST_DECREMENT'. 30803 30804 -- Macro: USE_LOAD_PRE_INCREMENT (MODE) 30805 A C expression used to determine whether a load preincrement is a 30806 good thing to use for a given mode. Defaults to the value of 30807 `HAVE_PRE_INCREMENT'. 30808 30809 -- Macro: USE_LOAD_PRE_DECREMENT (MODE) 30810 A C expression used to determine whether a load predecrement is a 30811 good thing to use for a given mode. Defaults to the value of 30812 `HAVE_PRE_DECREMENT'. 30813 30814 -- Macro: USE_STORE_POST_INCREMENT (MODE) 30815 A C expression used to determine whether a store postincrement is 30816 a good thing to use for a given mode. Defaults to the value of 30817 `HAVE_POST_INCREMENT'. 30818 30819 -- Macro: USE_STORE_POST_DECREMENT (MODE) 30820 A C expression used to determine whether a store postdecrement is 30821 a good thing to use for a given mode. Defaults to the value of 30822 `HAVE_POST_DECREMENT'. 30823 30824 -- Macro: USE_STORE_PRE_INCREMENT (MODE) 30825 This macro is used to determine whether a store preincrement is a 30826 good thing to use for a given mode. Defaults to the value of 30827 `HAVE_PRE_INCREMENT'. 30828 30829 -- Macro: USE_STORE_PRE_DECREMENT (MODE) 30830 This macro is used to determine whether a store predecrement is a 30831 good thing to use for a given mode. Defaults to the value of 30832 `HAVE_PRE_DECREMENT'. 30833 30834 -- Macro: NO_FUNCTION_CSE 30835 Define this macro if it is as good or better to call a constant 30836 function address than to call an address kept in a register. 30837 30838 -- Macro: RANGE_TEST_NON_SHORT_CIRCUIT 30839 Define this macro if a non-short-circuit operation produced by 30840 `fold_range_test ()' is optimal. This macro defaults to true if 30841 `BRANCH_COST' is greater than or equal to the value 2. 30842 30843 -- Target Hook: bool TARGET_RTX_COSTS (rtx X, int CODE, int 30844 OUTER_CODE, int *TOTAL, bool SPEED) 30845 This target hook describes the relative costs of RTL expressions. 30846 30847 The cost may depend on the precise form of the expression, which is 30848 available for examination in X, and the rtx code of the expression 30849 in which it is contained, found in OUTER_CODE. CODE is the 30850 expression code--redundant, since it can be obtained with 30851 `GET_CODE (X)'. 30852 30853 In implementing this hook, you can use the construct 30854 `COSTS_N_INSNS (N)' to specify a cost equal to N fast instructions. 30855 30856 On entry to the hook, `*TOTAL' contains a default estimate for the 30857 cost of the expression. The hook should modify this value as 30858 necessary. Traditionally, the default costs are `COSTS_N_INSNS 30859 (5)' for multiplications, `COSTS_N_INSNS (7)' for division and 30860 modulus operations, and `COSTS_N_INSNS (1)' for all other 30861 operations. 30862 30863 When optimizing for code size, i.e. when `speed' is false, this 30864 target hook should be used to estimate the relative size cost of 30865 an expression, again relative to `COSTS_N_INSNS'. 30866 30867 The hook returns true when all subexpressions of X have been 30868 processed, and false when `rtx_cost' should recurse. 30869 30870 -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS, bool SPEED) 30871 This hook computes the cost of an addressing mode that contains 30872 ADDRESS. If not defined, the cost is computed from the ADDRESS 30873 expression and the `TARGET_RTX_COST' hook. 30874 30875 For most CISC machines, the default cost is a good approximation 30876 of the true cost of the addressing mode. However, on RISC 30877 machines, all instructions normally have the same length and 30878 execution time. Hence all addresses will have equal costs. 30879 30880 In cases where more than one form of an address is known, the form 30881 with the lowest cost will be used. If multiple forms have the 30882 same, lowest, cost, the one that is the most complex will be used. 30883 30884 For example, suppose an address that is equal to the sum of a 30885 register and a constant is used twice in the same basic block. 30886 When this macro is not defined, the address will be computed in a 30887 register and memory references will be indirect through that 30888 register. On machines where the cost of the addressing mode 30889 containing the sum is no higher than that of a simple indirect 30890 reference, this will produce an additional instruction and 30891 possibly require an additional register. Proper specification of 30892 this macro eliminates this overhead for such machines. 30893 30894 This hook is never called with an invalid address. 30895 30896 On machines where an address involving more than one register is as 30897 cheap as an address computation involving only one register, 30898 defining `TARGET_ADDRESS_COST' to reflect this can cause two 30899 registers to be live over a region of code where only one would 30900 have been if `TARGET_ADDRESS_COST' were not defined in that 30901 manner. This effect should be considered in the definition of 30902 this macro. Equivalent costs should probably only be given to 30903 addresses with different numbers of registers on machines with 30904 lots of registers. 30905 30906 30907File: gccint.info, Node: Scheduling, Next: Sections, Prev: Costs, Up: Target Macros 30908 3090917.18 Adjusting the Instruction Scheduler 30910========================================= 30911 30912The instruction scheduler may need a fair amount of machine-specific 30913adjustment in order to produce good code. GCC provides several target 30914hooks for this purpose. It is usually enough to define just a few of 30915them: try the first ones in this list first. 30916 30917 -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void) 30918 This hook returns the maximum number of instructions that can ever 30919 issue at the same time on the target machine. The default is one. 30920 Although the insn scheduler can define itself the possibility of 30921 issue an insn on the same cycle, the value can serve as an 30922 additional constraint to issue insns on the same simulated 30923 processor cycle (see hooks `TARGET_SCHED_REORDER' and 30924 `TARGET_SCHED_REORDER2'). This value must be constant over the 30925 entire compilation. If you need it to vary depending on what the 30926 instructions are, you must use `TARGET_SCHED_VARIABLE_ISSUE'. 30927 30928 -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int 30929 VERBOSE, rtx INSN, int MORE) 30930 This hook is executed by the scheduler after it has scheduled an 30931 insn from the ready list. It should return the number of insns 30932 which can still be issued in the current cycle. The default is 30933 `MORE - 1' for insns other than `CLOBBER' and `USE', which 30934 normally are not counted against the issue rate. You should 30935 define this hook if some insns take more machine resources than 30936 others, so that fewer insns can follow them in the same cycle. 30937 FILE is either a null pointer, or a stdio stream to write any 30938 debug output to. VERBOSE is the verbose level provided by 30939 `-fsched-verbose-N'. INSN is the instruction that was scheduled. 30940 30941 -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx INSN, rtx LINK, rtx 30942 DEP_INSN, int COST) 30943 This function corrects the value of COST based on the relationship 30944 between INSN and DEP_INSN through the dependence LINK. It should 30945 return the new value. The default is to make no adjustment to 30946 COST. This can be used for example to specify to the scheduler 30947 using the traditional pipeline description that an output- or 30948 anti-dependence does not incur the same cost as a data-dependence. 30949 If the scheduler using the automaton based pipeline description, 30950 the cost of anti-dependence is zero and the cost of 30951 output-dependence is maximum of one and the difference of latency 30952 times of the first and the second insns. If these values are not 30953 acceptable, you could use the hook to modify them too. See also 30954 *note Processor pipeline description::. 30955 30956 -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx INSN, int 30957 PRIORITY) 30958 This hook adjusts the integer scheduling priority PRIORITY of 30959 INSN. It should return the new priority. Increase the priority to 30960 execute INSN earlier, reduce the priority to execute INSN later. 30961 Do not define this hook if you do not need to adjust the 30962 scheduling priorities of insns. 30963 30964 -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, rtx 30965 *READY, int *N_READYP, int CLOCK) 30966 This hook is executed by the scheduler after it has scheduled the 30967 ready list, to allow the machine description to reorder it (for 30968 example to combine two small instructions together on `VLIW' 30969 machines). FILE is either a null pointer, or a stdio stream to 30970 write any debug output to. VERBOSE is the verbose level provided 30971 by `-fsched-verbose-N'. READY is a pointer to the ready list of 30972 instructions that are ready to be scheduled. N_READYP is a 30973 pointer to the number of elements in the ready list. The scheduler 30974 reads the ready list in reverse order, starting with 30975 READY[*N_READYP - 1] and going to READY[0]. CLOCK is the timer 30976 tick of the scheduler. You may modify the ready list and the 30977 number of ready insns. The return value is the number of insns 30978 that can issue this cycle; normally this is just `issue_rate'. 30979 See also `TARGET_SCHED_REORDER2'. 30980 30981 -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE, 30982 rtx *READY, int *N_READYP, int CLOCK) 30983 Like `TARGET_SCHED_REORDER', but called at a different time. That 30984 function is called whenever the scheduler starts a new cycle. 30985 This one is called once per iteration over a cycle, immediately 30986 after `TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list 30987 and return the number of insns to be scheduled in the same cycle. 30988 Defining this hook can be useful if there are frequent situations 30989 where scheduling one insn causes other insns to become ready in 30990 the same cycle. These other insns can then be taken into account 30991 properly. 30992 30993 -- Target Hook: void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK (rtx 30994 HEAD, rtx TAIL) 30995 This hook is called after evaluation forward dependencies of insns 30996 in chain given by two parameter values (HEAD and TAIL 30997 correspondingly) but before insns scheduling of the insn chain. 30998 For example, it can be used for better insn classification if it 30999 requires analysis of dependencies. This hook can use backward and 31000 forward dependencies of the insn scheduler because they are already 31001 calculated. 31002 31003 -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int 31004 MAX_READY) 31005 This hook is executed by the scheduler at the beginning of each 31006 block of instructions that are to be scheduled. FILE is either a 31007 null pointer, or a stdio stream to write any debug output to. 31008 VERBOSE is the verbose level provided by `-fsched-verbose-N'. 31009 MAX_READY is the maximum number of insns in the current scheduling 31010 region that can be live at the same time. This can be used to 31011 allocate scratch space if it is needed, e.g. by 31012 `TARGET_SCHED_REORDER'. 31013 31014 -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE) 31015 This hook is executed by the scheduler at the end of each block of 31016 instructions that are to be scheduled. It can be used to perform 31017 cleanup of any actions done by the other scheduling hooks. FILE 31018 is either a null pointer, or a stdio stream to write any debug 31019 output to. VERBOSE is the verbose level provided by 31020 `-fsched-verbose-N'. 31021 31022 -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int 31023 VERBOSE, int OLD_MAX_UID) 31024 This hook is executed by the scheduler after function level 31025 initializations. FILE is either a null pointer, or a stdio stream 31026 to write any debug output to. VERBOSE is the verbose level 31027 provided by `-fsched-verbose-N'. OLD_MAX_UID is the maximum insn 31028 uid when scheduling begins. 31029 31030 -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int 31031 VERBOSE) 31032 This is the cleanup hook corresponding to 31033 `TARGET_SCHED_INIT_GLOBAL'. FILE is either a null pointer, or a 31034 stdio stream to write any debug output to. VERBOSE is the verbose 31035 level provided by `-fsched-verbose-N'. 31036 31037 -- Target Hook: rtx TARGET_SCHED_DFA_PRE_CYCLE_INSN (void) 31038 The hook returns an RTL insn. The automaton state used in the 31039 pipeline hazard recognizer is changed as if the insn were scheduled 31040 when the new simulated processor cycle starts. Usage of the hook 31041 may simplify the automaton pipeline description for some VLIW 31042 processors. If the hook is defined, it is used only for the 31043 automaton based pipeline description. The default is not to 31044 change the state when the new simulated processor cycle starts. 31045 31046 -- Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void) 31047 The hook can be used to initialize data used by the previous hook. 31048 31049 -- Target Hook: rtx TARGET_SCHED_DFA_POST_CYCLE_INSN (void) 31050 The hook is analogous to `TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used 31051 to changed the state as if the insn were scheduled when the new 31052 simulated processor cycle finishes. 31053 31054 -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void) 31055 The hook is analogous to `TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but 31056 used to initialize data used by the previous hook. 31057 31058 -- Target Hook: void TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE (void) 31059 The hook to notify target that the current simulated cycle is 31060 about to finish. The hook is analogous to 31061 `TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used to change the state in 31062 more complicated situations - e.g., when advancing state on a 31063 single insn is not enough. 31064 31065 -- Target Hook: void TARGET_SCHED_DFA_POST_ADVANCE_CYCLE (void) 31066 The hook to notify target that new simulated cycle has just 31067 started. The hook is analogous to 31068 `TARGET_SCHED_DFA_POST_CYCLE_INSN' but used to change the state in 31069 more complicated situations - e.g., when advancing state on a 31070 single insn is not enough. 31071 31072 -- Target Hook: int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 31073 (void) 31074 This hook controls better choosing an insn from the ready insn 31075 queue for the DFA-based insn scheduler. Usually the scheduler 31076 chooses the first insn from the queue. If the hook returns a 31077 positive value, an additional scheduler code tries all 31078 permutations of `TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 31079 ()' subsequent ready insns to choose an insn whose issue will 31080 result in maximal number of issued insns on the same cycle. For 31081 the VLIW processor, the code could actually solve the problem of 31082 packing simple insns into the VLIW insn. Of course, if the rules 31083 of VLIW packing are described in the automaton. 31084 31085 This code also could be used for superscalar RISC processors. Let 31086 us consider a superscalar RISC processor with 3 pipelines. Some 31087 insns can be executed in pipelines A or B, some insns can be 31088 executed only in pipelines B or C, and one insn can be executed in 31089 pipeline B. The processor may issue the 1st insn into A and the 31090 2nd one into B. In this case, the 3rd insn will wait for freeing B 31091 until the next cycle. If the scheduler issues the 3rd insn the 31092 first, the processor could issue all 3 insns per cycle. 31093 31094 Actually this code demonstrates advantages of the automaton based 31095 pipeline hazard recognizer. We try quickly and easy many insn 31096 schedules to choose the best one. 31097 31098 The default is no multipass scheduling. 31099 31100 -- Target Hook: int 31101TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD (rtx INSN) 31102 This hook controls what insns from the ready insn queue will be 31103 considered for the multipass insn scheduling. If the hook returns 31104 zero for INSN, the insn will be not chosen to be issued. 31105 31106 The default is that any ready insns can be chosen to be issued. 31107 31108 -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *DUMP, int 31109 VERBOSE, rtx INSN, int LAST_CLOCK, int CLOCK, int *SORT_P) 31110 This hook is called by the insn scheduler before issuing INSN on 31111 cycle CLOCK. If the hook returns nonzero, INSN is not issued on 31112 this processor cycle. Instead, the processor cycle is advanced. 31113 If *SORT_P is zero, the insn ready queue is not sorted on the new 31114 cycle start as usually. DUMP and VERBOSE specify the file and 31115 verbosity level to use for debugging output. LAST_CLOCK and CLOCK 31116 are, respectively, the processor cycle on which the previous insn 31117 has been issued, and the current processor cycle. 31118 31119 -- Target Hook: bool TARGET_SCHED_IS_COSTLY_DEPENDENCE (struct _dep 31120 *_DEP, int COST, int DISTANCE) 31121 This hook is used to define which dependences are considered 31122 costly by the target, so costly that it is not advisable to 31123 schedule the insns that are involved in the dependence too close 31124 to one another. The parameters to this hook are as follows: The 31125 first parameter _DEP is the dependence being evaluated. The 31126 second parameter COST is the cost of the dependence as estimated 31127 by the scheduler, and the third parameter DISTANCE is the distance 31128 in cycles between the two insns. The hook returns `true' if 31129 considering the distance between the two insns the dependence 31130 between them is considered costly by the target, and `false' 31131 otherwise. 31132 31133 Defining this hook can be useful in multiple-issue out-of-order 31134 machines, where (a) it's practically hopeless to predict the 31135 actual data/resource delays, however: (b) there's a better chance 31136 to predict the actual grouping that will be formed, and (c) 31137 correctly emulating the grouping can be very important. In such 31138 targets one may want to allow issuing dependent insns closer to 31139 one another--i.e., closer than the dependence distance; however, 31140 not in cases of "costly dependences", which this hooks allows to 31141 define. 31142 31143 -- Target Hook: void TARGET_SCHED_H_I_D_EXTENDED (void) 31144 This hook is called by the insn scheduler after emitting a new 31145 instruction to the instruction stream. The hook notifies a target 31146 backend to extend its per instruction data structures. 31147 31148 -- Target Hook: void * TARGET_SCHED_ALLOC_SCHED_CONTEXT (void) 31149 Return a pointer to a store large enough to hold target scheduling 31150 context. 31151 31152 -- Target Hook: void TARGET_SCHED_INIT_SCHED_CONTEXT (void *TC, bool 31153 CLEAN_P) 31154 Initialize store pointed to by TC to hold target scheduling 31155 context. It CLEAN_P is true then initialize TC as if scheduler is 31156 at the beginning of the block. Otherwise, copy the current 31157 context into TC. 31158 31159 -- Target Hook: void TARGET_SCHED_SET_SCHED_CONTEXT (void *TC) 31160 Copy target scheduling context pointed to by TC to the current 31161 context. 31162 31163 -- Target Hook: void TARGET_SCHED_CLEAR_SCHED_CONTEXT (void *TC) 31164 Deallocate internal data in target scheduling context pointed to 31165 by TC. 31166 31167 -- Target Hook: void TARGET_SCHED_FREE_SCHED_CONTEXT (void *TC) 31168 Deallocate a store for target scheduling context pointed to by TC. 31169 31170 -- Target Hook: int TARGET_SCHED_SPECULATE_INSN (rtx INSN, int 31171 REQUEST, rtx *NEW_PAT) 31172 This hook is called by the insn scheduler when INSN has only 31173 speculative dependencies and therefore can be scheduled 31174 speculatively. The hook is used to check if the pattern of INSN 31175 has a speculative version and, in case of successful check, to 31176 generate that speculative pattern. The hook should return 1, if 31177 the instruction has a speculative form, or -1, if it doesn't. 31178 REQUEST describes the type of requested speculation. If the 31179 return value equals 1 then NEW_PAT is assigned the generated 31180 speculative pattern. 31181 31182 -- Target Hook: bool TARGET_SCHED_NEEDS_BLOCK_P (int DEP_STATUS) 31183 This hook is called by the insn scheduler during generation of 31184 recovery code for INSN. It should return `true', if the 31185 corresponding check instruction should branch to recovery code, or 31186 `false' otherwise. 31187 31188 -- Target Hook: rtx TARGET_SCHED_GEN_SPEC_CHECK (rtx INSN, rtx LABEL, 31189 int MUTATE_P) 31190 This hook is called by the insn scheduler to generate a pattern 31191 for recovery check instruction. If MUTATE_P is zero, then INSN is 31192 a speculative instruction for which the check should be generated. 31193 LABEL is either a label of a basic block, where recovery code 31194 should be emitted, or a null pointer, when requested check doesn't 31195 branch to recovery code (a simple check). If MUTATE_P is nonzero, 31196 then a pattern for a branchy check corresponding to a simple check 31197 denoted by INSN should be generated. In this case LABEL can't be 31198 null. 31199 31200 -- Target Hook: bool 31201TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC (const_rtx 31202 INSN) 31203 This hook is used as a workaround for 31204 `TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD' not being 31205 called on the first instruction of the ready list. The hook is 31206 used to discard speculative instructions that stand first in the 31207 ready list from being scheduled on the current cycle. If the hook 31208 returns `false', INSN will not be chosen to be issued. For 31209 non-speculative instructions, the hook should always return 31210 `true'. For example, in the ia64 backend the hook is used to 31211 cancel data speculative insns when the ALAT table is nearly full. 31212 31213 -- Target Hook: void TARGET_SCHED_SET_SCHED_FLAGS (struct 31214 spec_info_def *SPEC_INFO) 31215 This hook is used by the insn scheduler to find out what features 31216 should be enabled/used. The structure *SPEC_INFO should be filled 31217 in by the target. The structure describes speculation types that 31218 can be used in the scheduler. 31219 31220 -- Target Hook: int TARGET_SCHED_SMS_RES_MII (struct ddg *G) 31221 This hook is called by the swing modulo scheduler to calculate a 31222 resource-based lower bound which is based on the resources 31223 available in the machine and the resources required by each 31224 instruction. The target backend can use G to calculate such 31225 bound. A very simple lower bound will be used in case this hook 31226 is not implemented: the total number of instructions divided by 31227 the issue rate. 31228 31229 31230File: gccint.info, Node: Sections, Next: PIC, Prev: Scheduling, Up: Target Macros 31231 3123217.19 Dividing the Output into Sections (Texts, Data, ...) 31233========================================================== 31234 31235An object file is divided into sections containing different types of 31236data. In the most common case, there are three sections: the "text 31237section", which holds instructions and read-only data; the "data 31238section", which holds initialized writable data; and the "bss section", 31239which holds uninitialized data. Some systems have other kinds of 31240sections. 31241 31242 `varasm.c' provides several well-known sections, such as 31243`text_section', `data_section' and `bss_section'. The normal way of 31244controlling a `FOO_section' variable is to define the associated 31245`FOO_SECTION_ASM_OP' macro, as described below. The macros are only 31246read once, when `varasm.c' initializes itself, so their values must be 31247run-time constants. They may however depend on command-line flags. 31248 31249 _Note:_ Some run-time files, such `crtstuff.c', also make use of the 31250`FOO_SECTION_ASM_OP' macros, and expect them to be string literals. 31251 31252 Some assemblers require a different string to be written every time a 31253section is selected. If your assembler falls into this category, you 31254should define the `TARGET_ASM_INIT_SECTIONS' hook and use 31255`get_unnamed_section' to set up the sections. 31256 31257 You must always create a `text_section', either by defining 31258`TEXT_SECTION_ASM_OP' or by initializing `text_section' in 31259`TARGET_ASM_INIT_SECTIONS'. The same is true of `data_section' and 31260`DATA_SECTION_ASM_OP'. If you do not create a distinct 31261`readonly_data_section', the default is to reuse `text_section'. 31262 31263 All the other `varasm.c' sections are optional, and are null if the 31264target does not provide them. 31265 31266 -- Macro: TEXT_SECTION_ASM_OP 31267 A C expression whose value is a string, including spacing, 31268 containing the assembler operation that should precede 31269 instructions and read-only data. Normally `"\t.text"' is right. 31270 31271 -- Macro: HOT_TEXT_SECTION_NAME 31272 If defined, a C string constant for the name of the section 31273 containing most frequently executed functions of the program. If 31274 not defined, GCC will provide a default definition if the target 31275 supports named sections. 31276 31277 -- Macro: UNLIKELY_EXECUTED_TEXT_SECTION_NAME 31278 If defined, a C string constant for the name of the section 31279 containing unlikely executed functions in the program. 31280 31281 -- Macro: DATA_SECTION_ASM_OP 31282 A C expression whose value is a string, including spacing, 31283 containing the assembler operation to identify the following data 31284 as writable initialized data. Normally `"\t.data"' is right. 31285 31286 -- Macro: SDATA_SECTION_ASM_OP 31287 If defined, a C expression whose value is a string, including 31288 spacing, containing the assembler operation to identify the 31289 following data as initialized, writable small data. 31290 31291 -- Macro: READONLY_DATA_SECTION_ASM_OP 31292 A C expression whose value is a string, including spacing, 31293 containing the assembler operation to identify the following data 31294 as read-only initialized data. 31295 31296 -- Macro: BSS_SECTION_ASM_OP 31297 If defined, a C expression whose value is a string, including 31298 spacing, containing the assembler operation to identify the 31299 following data as uninitialized global data. If not defined, and 31300 neither `ASM_OUTPUT_BSS' nor `ASM_OUTPUT_ALIGNED_BSS' are defined, 31301 uninitialized global data will be output in the data section if 31302 `-fno-common' is passed, otherwise `ASM_OUTPUT_COMMON' will be 31303 used. 31304 31305 -- Macro: SBSS_SECTION_ASM_OP 31306 If defined, a C expression whose value is a string, including 31307 spacing, containing the assembler operation to identify the 31308 following data as uninitialized, writable small data. 31309 31310 -- Macro: TLS_COMMON_ASM_OP 31311 If defined, a C expression whose value is a string containing the 31312 assembler operation to identify the following data as thread-local 31313 common data. The default is `".tls_common"'. 31314 31315 -- Macro: TLS_SECTION_ASM_FLAG 31316 If defined, a C expression whose value is a character constant 31317 containing the flag used to mark a section as a TLS section. The 31318 default is `'T''. 31319 31320 -- Macro: INIT_SECTION_ASM_OP 31321 If defined, a C expression whose value is a string, including 31322 spacing, containing the assembler operation to identify the 31323 following data as initialization code. If not defined, GCC will 31324 assume such a section does not exist. This section has no 31325 corresponding `init_section' variable; it is used entirely in 31326 runtime code. 31327 31328 -- Macro: FINI_SECTION_ASM_OP 31329 If defined, a C expression whose value is a string, including 31330 spacing, containing the assembler operation to identify the 31331 following data as finalization code. If not defined, GCC will 31332 assume such a section does not exist. This section has no 31333 corresponding `fini_section' variable; it is used entirely in 31334 runtime code. 31335 31336 -- Macro: INIT_ARRAY_SECTION_ASM_OP 31337 If defined, a C expression whose value is a string, including 31338 spacing, containing the assembler operation to identify the 31339 following data as part of the `.init_array' (or equivalent) 31340 section. If not defined, GCC will assume such a section does not 31341 exist. Do not define both this macro and `INIT_SECTION_ASM_OP'. 31342 31343 -- Macro: FINI_ARRAY_SECTION_ASM_OP 31344 If defined, a C expression whose value is a string, including 31345 spacing, containing the assembler operation to identify the 31346 following data as part of the `.fini_array' (or equivalent) 31347 section. If not defined, GCC will assume such a section does not 31348 exist. Do not define both this macro and `FINI_SECTION_ASM_OP'. 31349 31350 -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION) 31351 If defined, an ASM statement that switches to a different section 31352 via SECTION_OP, calls FUNCTION, and switches back to the text 31353 section. This is used in `crtstuff.c' if `INIT_SECTION_ASM_OP' or 31354 `FINI_SECTION_ASM_OP' to calls to initialization and finalization 31355 functions from the init and fini sections. By default, this macro 31356 uses a simple function call. Some ports need hand-crafted 31357 assembly code to avoid dependencies on registers initialized in 31358 the function prologue or to ensure that constant pools don't end 31359 up too far way in the text section. 31360 31361 -- Macro: TARGET_LIBGCC_SDATA_SECTION 31362 If defined, a string which names the section into which small 31363 variables defined in crtstuff and libgcc should go. This is useful 31364 when the target has options for optimizing access to small data, 31365 and you want the crtstuff and libgcc routines to be conservative 31366 in what they expect of your application yet liberal in what your 31367 application expects. For example, for targets with a `.sdata' 31368 section (like MIPS), you could compile crtstuff with `-G 0' so 31369 that it doesn't require small data support from your application, 31370 but use this macro to put small data into `.sdata' so that your 31371 application can access these variables whether it uses small data 31372 or not. 31373 31374 -- Macro: FORCE_CODE_SECTION_ALIGN 31375 If defined, an ASM statement that aligns a code section to some 31376 arbitrary boundary. This is used to force all fragments of the 31377 `.init' and `.fini' sections to have to same alignment and thus 31378 prevent the linker from having to add any padding. 31379 31380 -- Macro: JUMP_TABLES_IN_TEXT_SECTION 31381 Define this macro to be an expression with a nonzero value if jump 31382 tables (for `tablejump' insns) should be output in the text 31383 section, along with the assembler instructions. Otherwise, the 31384 readonly data section is used. 31385 31386 This macro is irrelevant if there is no separate readonly data 31387 section. 31388 31389 -- Target Hook: void TARGET_ASM_INIT_SECTIONS (void) 31390 Define this hook if you need to do something special to set up the 31391 `varasm.c' sections, or if your target has some special sections 31392 of its own that you need to create. 31393 31394 GCC calls this hook after processing the command line, but before 31395 writing any assembly code, and before calling any of the 31396 section-returning hooks described below. 31397 31398 -- Target Hook: int TARGET_ASM_RELOC_RW_MASK (void) 31399 Return a mask describing how relocations should be treated when 31400 selecting sections. Bit 1 should be set if global relocations 31401 should be placed in a read-write section; bit 0 should be set if 31402 local relocations should be placed in a read-write section. 31403 31404 The default version of this function returns 3 when `-fpic' is in 31405 effect, and 0 otherwise. The hook is typically redefined when the 31406 target cannot support (some kinds of) dynamic relocations in 31407 read-only sections even in executables. 31408 31409 -- Target Hook: section * TARGET_ASM_SELECT_SECTION (tree EXP, int 31410 RELOC, unsigned HOST_WIDE_INT ALIGN) 31411 Return the section into which EXP should be placed. You can 31412 assume that EXP is either a `VAR_DECL' node or a constant of some 31413 sort. RELOC indicates whether the initial value of EXP requires 31414 link-time relocations. Bit 0 is set when variable contains local 31415 relocations only, while bit 1 is set for global relocations. 31416 ALIGN is the constant alignment in bits. 31417 31418 The default version of this function takes care of putting 31419 read-only variables in `readonly_data_section'. 31420 31421 See also USE_SELECT_SECTION_FOR_FUNCTIONS. 31422 31423 -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS 31424 Define this macro if you wish TARGET_ASM_SELECT_SECTION to be 31425 called for `FUNCTION_DECL's as well as for variables and constants. 31426 31427 In the case of a `FUNCTION_DECL', RELOC will be zero if the 31428 function has been determined to be likely to be called, and 31429 nonzero if it is unlikely to be called. 31430 31431 -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC) 31432 Build up a unique section name, expressed as a `STRING_CST' node, 31433 and assign it to `DECL_SECTION_NAME (DECL)'. As with 31434 `TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial 31435 value of EXP requires link-time relocations. 31436 31437 The default version of this function appends the symbol name to the 31438 ELF section name that would normally be used for the symbol. For 31439 example, the function `foo' would be placed in `.text.foo'. 31440 Whatever the actual target object format, this is often good 31441 enough. 31442 31443 -- Target Hook: section * TARGET_ASM_FUNCTION_RODATA_SECTION (tree 31444 DECL) 31445 Return the readonly data section associated with 31446 `DECL_SECTION_NAME (DECL)'. The default version of this function 31447 selects `.gnu.linkonce.r.name' if the function's section is 31448 `.gnu.linkonce.t.name', `.rodata.name' if function is in 31449 `.text.name', and the normal readonly-data section otherwise. 31450 31451 -- Target Hook: section * TARGET_ASM_SELECT_RTX_SECTION (enum 31452 machine_mode MODE, rtx X, unsigned HOST_WIDE_INT ALIGN) 31453 Return the section into which a constant X, of mode MODE, should 31454 be placed. You can assume that X is some kind of constant in RTL. 31455 The argument MODE is redundant except in the case of a `const_int' 31456 rtx. ALIGN is the constant alignment in bits. 31457 31458 The default version of this function takes care of putting symbolic 31459 constants in `flag_pic' mode in `data_section' and everything else 31460 in `readonly_data_section'. 31461 31462 -- Target Hook: tree TARGET_MANGLE_DECL_ASSEMBLER_NAME (tree DECL, 31463 tree ID) 31464 Define this hook if you need to postprocess the assembler name 31465 generated by target-independent code. The ID provided to this 31466 hook will be the computed name (e.g., the macro `DECL_NAME' of the 31467 DECL in C, or the mangled name of the DECL in C++). The return 31468 value of the hook is an `IDENTIFIER_NODE' for the appropriate 31469 mangled name on your target system. The default implementation of 31470 this hook just returns the ID provided. 31471 31472 -- Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, rtx RTL, 31473 int NEW_DECL_P) 31474 Define this hook if references to a symbol or a constant must be 31475 treated differently depending on something about the variable or 31476 function named by the symbol (such as what section it is in). 31477 31478 The hook is executed immediately after rtl has been created for 31479 DECL, which may be a variable or function declaration or an entry 31480 in the constant pool. In either case, RTL is the rtl in question. 31481 Do _not_ use `DECL_RTL (DECL)' in this hook; that field may not 31482 have been initialized yet. 31483 31484 In the case of a constant, it is safe to assume that the rtl is a 31485 `mem' whose address is a `symbol_ref'. Most decls will also have 31486 this form, but that is not guaranteed. Global register variables, 31487 for instance, will have a `reg' for their rtl. (Normally the 31488 right thing to do with such unusual rtl is leave it alone.) 31489 31490 The NEW_DECL_P argument will be true if this is the first time 31491 that `TARGET_ENCODE_SECTION_INFO' has been invoked on this decl. 31492 It will be false for subsequent invocations, which will happen for 31493 duplicate declarations. Whether or not anything must be done for 31494 the duplicate declaration depends on whether the hook examines 31495 `DECL_ATTRIBUTES'. NEW_DECL_P is always true when the hook is 31496 called for a constant. 31497 31498 The usual thing for this hook to do is to record flags in the 31499 `symbol_ref', using `SYMBOL_REF_FLAG' or `SYMBOL_REF_FLAGS'. 31500 Historically, the name string was modified if it was necessary to 31501 encode more than one bit of information, but this practice is now 31502 discouraged; use `SYMBOL_REF_FLAGS'. 31503 31504 The default definition of this hook, `default_encode_section_info' 31505 in `varasm.c', sets a number of commonly-useful bits in 31506 `SYMBOL_REF_FLAGS'. Check whether the default does what you need 31507 before overriding it. 31508 31509 -- Target Hook: const char * TARGET_STRIP_NAME_ENCODING (const char 31510 *NAME) 31511 Decode NAME and return the real name part, sans the characters 31512 that `TARGET_ENCODE_SECTION_INFO' may have added. 31513 31514 -- Target Hook: bool TARGET_IN_SMALL_DATA_P (const_tree EXP) 31515 Returns true if EXP should be placed into a "small data" section. 31516 The default version of this hook always returns false. 31517 31518 -- Target Hook: bool TARGET_HAVE_SRODATA_SECTION 31519 Contains the value true if the target places read-only "small 31520 data" into a separate section. The default value is false. 31521 31522 -- Target Hook: bool TARGET_BINDS_LOCAL_P (const_tree EXP) 31523 Returns true if EXP names an object for which name resolution 31524 rules must resolve to the current "module" (dynamic shared library 31525 or executable image). 31526 31527 The default version of this hook implements the name resolution 31528 rules for ELF, which has a looser model of global name binding 31529 than other currently supported object file formats. 31530 31531 -- Target Hook: bool TARGET_HAVE_TLS 31532 Contains the value true if the target supports thread-local 31533 storage. The default value is false. 31534 31535 31536File: gccint.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros 31537 3153817.20 Position Independent Code 31539=============================== 31540 31541This section describes macros that help implement generation of position 31542independent code. Simply defining these macros is not enough to 31543generate valid PIC; you must also add support to the hook 31544`TARGET_LEGITIMATE_ADDRESS_P' and to the macro `PRINT_OPERAND_ADDRESS', 31545as well as `LEGITIMIZE_ADDRESS'. You must modify the definition of 31546`movsi' to do something appropriate when the source operand contains a 31547symbolic address. You may also need to alter the handling of switch 31548statements so that they use relative addresses. 31549 31550 -- Macro: PIC_OFFSET_TABLE_REGNUM 31551 The register number of the register used to address a table of 31552 static data addresses in memory. In some cases this register is 31553 defined by a processor's "application binary interface" (ABI). 31554 When this macro is defined, RTL is generated for this register 31555 once, as with the stack pointer and frame pointer registers. If 31556 this macro is not defined, it is up to the machine-dependent files 31557 to allocate such a register (if necessary). Note that this 31558 register must be fixed when in use (e.g. when `flag_pic' is true). 31559 31560 -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED 31561 Define this macro if the register defined by 31562 `PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. Do not define 31563 this macro if `PIC_OFFSET_TABLE_REGNUM' is not defined. 31564 31565 -- Macro: LEGITIMATE_PIC_OPERAND_P (X) 31566 A C expression that is nonzero if X is a legitimate immediate 31567 operand on the target machine when generating position independent 31568 code. You can assume that X satisfies `CONSTANT_P', so you need 31569 not check this. You can also assume FLAG_PIC is true, so you need 31570 not check it either. You need not define this macro if all 31571 constants (including `SYMBOL_REF') can be immediate operands when 31572 generating position independent code. 31573 31574 31575File: gccint.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros 31576 3157717.21 Defining the Output Assembler Language 31578============================================ 31579 31580This section describes macros whose principal purpose is to describe how 31581to write instructions in assembler language--rather than what the 31582instructions do. 31583 31584* Menu: 31585 31586* File Framework:: Structural information for the assembler file. 31587* Data Output:: Output of constants (numbers, strings, addresses). 31588* Uninitialized Data:: Output of uninitialized variables. 31589* Label Output:: Output and generation of labels. 31590* Initialization:: General principles of initialization 31591 and termination routines. 31592* Macros for Initialization:: 31593 Specific macros that control the handling of 31594 initialization and termination routines. 31595* Instruction Output:: Output of actual instructions. 31596* Dispatch Tables:: Output of jump tables. 31597* Exception Region Output:: Output of exception region code. 31598* Alignment Output:: Pseudo ops for alignment and skipping data. 31599 31600 31601File: gccint.info, Node: File Framework, Next: Data Output, Up: Assembler Format 31602 3160317.21.1 The Overall Framework of an Assembler File 31604-------------------------------------------------- 31605 31606This describes the overall framework of an assembly file. 31607 31608 -- Target Hook: void TARGET_ASM_FILE_START (void) 31609 Output to `asm_out_file' any text which the assembler expects to 31610 find at the beginning of a file. The default behavior is 31611 controlled by two flags, documented below. Unless your target's 31612 assembler is quite unusual, if you override the default, you 31613 should call `default_file_start' at some point in your target 31614 hook. This lets other target files rely on these variables. 31615 31616 -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF 31617 If this flag is true, the text of the macro `ASM_APP_OFF' will be 31618 printed as the very first line in the assembly file, unless 31619 `-fverbose-asm' is in effect. (If that macro has been defined to 31620 the empty string, this variable has no effect.) With the normal 31621 definition of `ASM_APP_OFF', the effect is to notify the GNU 31622 assembler that it need not bother stripping comments or extra 31623 whitespace from its input. This allows it to work a bit faster. 31624 31625 The default is false. You should not set it to true unless you 31626 have verified that your port does not generate any extra 31627 whitespace or comments that will cause GAS to issue errors in 31628 NO_APP mode. 31629 31630 -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE 31631 If this flag is true, `output_file_directive' will be called for 31632 the primary source file, immediately after printing `ASM_APP_OFF' 31633 (if that is enabled). Most ELF assemblers expect this to be done. 31634 The default is false. 31635 31636 -- Target Hook: void TARGET_ASM_FILE_END (void) 31637 Output to `asm_out_file' any text which the assembler expects to 31638 find at the end of a file. The default is to output nothing. 31639 31640 -- Function: void file_end_indicate_exec_stack () 31641 Some systems use a common convention, the `.note.GNU-stack' 31642 special section, to indicate whether or not an object file relies 31643 on the stack being executable. If your system uses this 31644 convention, you should define `TARGET_ASM_FILE_END' to this 31645 function. If you need to do other things in that hook, have your 31646 hook function call this function. 31647 31648 -- Target Hook: void TARGET_ASM_LTO_START (void) 31649 Output to `asm_out_file' any text which the assembler expects to 31650 find at the start of an LTO section. The default is to output 31651 nothing. 31652 31653 -- Target Hook: void TARGET_ASM_LTO_END (void) 31654 Output to `asm_out_file' any text which the assembler expects to 31655 find at the end of an LTO section. The default is to output 31656 nothing. 31657 31658 -- Target Hook: void TARGET_ASM_CODE_END (void) 31659 Output to `asm_out_file' any text which is needed before emitting 31660 unwind info and debug info at the end of a file. Some targets emit 31661 here PIC setup thunks that cannot be emitted at the end of file, 31662 because they couldn't have unwind info then. The default is to 31663 output nothing. 31664 31665 -- Macro: ASM_COMMENT_START 31666 A C string constant describing how to begin a comment in the target 31667 assembler language. The compiler assumes that the comment will 31668 end at the end of the line. 31669 31670 -- Macro: ASM_APP_ON 31671 A C string constant for text to be output before each `asm' 31672 statement or group of consecutive ones. Normally this is 31673 `"#APP"', which is a comment that has no effect on most assemblers 31674 but tells the GNU assembler that it must check the lines that 31675 follow for all valid assembler constructs. 31676 31677 -- Macro: ASM_APP_OFF 31678 A C string constant for text to be output after each `asm' 31679 statement or group of consecutive ones. Normally this is 31680 `"#NO_APP"', which tells the GNU assembler to resume making the 31681 time-saving assumptions that are valid for ordinary compiler 31682 output. 31683 31684 -- Macro: ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME) 31685 A C statement to output COFF information or DWARF debugging 31686 information which indicates that filename NAME is the current 31687 source file to the stdio stream STREAM. 31688 31689 This macro need not be defined if the standard form of output for 31690 the file format in use is appropriate. 31691 31692 -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING) 31693 A C statement to output the string STRING to the stdio stream 31694 STREAM. If you do not call the function `output_quoted_string' in 31695 your config files, GCC will only call it to output filenames to 31696 the assembler source. So you can use it to canonicalize the format 31697 of the filename using this macro. 31698 31699 -- Macro: ASM_OUTPUT_IDENT (STREAM, STRING) 31700 A C statement to output something to the assembler file to handle a 31701 `#ident' directive containing the text STRING. If this macro is 31702 not defined, nothing is output for a `#ident' directive. 31703 31704 -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME, 31705 unsigned int FLAGS, tree DECL) 31706 Output assembly directives to switch to section NAME. The section 31707 should have attributes as specified by FLAGS, which is a bit mask 31708 of the `SECTION_*' flags defined in `output.h'. If DECL is 31709 non-NULL, it is the `VAR_DECL' or `FUNCTION_DECL' with which this 31710 section is associated. 31711 31712 -- Target Hook: bool TARGET_HAVE_NAMED_SECTIONS 31713 This flag is true if the target supports 31714 `TARGET_ASM_NAMED_SECTION'. 31715 31716 -- Target Hook: bool TARGET_HAVE_SWITCHABLE_BSS_SECTIONS 31717 This flag is true if we can create zeroed data by switching to a 31718 BSS section and then using `ASM_OUTPUT_SKIP' to allocate the space. 31719 This is true on most ELF targets. 31720 31721 -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL, 31722 const char *NAME, int RELOC) 31723 Choose a set of section attributes for use by 31724 `TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a 31725 section name, and whether or not the declaration's initializer may 31726 contain runtime relocations. DECL may be null, in which case 31727 read-write data should be assumed. 31728 31729 The default version of this function handles choosing code vs data, 31730 read-only vs read-write data, and `flag_pic'. You should only 31731 need to override this if your target has special flags that might 31732 be set via `__attribute__'. 31733 31734 -- Target Hook: int TARGET_ASM_RECORD_GCC_SWITCHES (print_switch_type 31735 TYPE, const char *TEXT) 31736 Provides the target with the ability to record the gcc command line 31737 switches that have been passed to the compiler, and options that 31738 are enabled. The TYPE argument specifies what is being recorded. 31739 It can take the following values: 31740 31741 `SWITCH_TYPE_PASSED' 31742 TEXT is a command line switch that has been set by the user. 31743 31744 `SWITCH_TYPE_ENABLED' 31745 TEXT is an option which has been enabled. This might be as a 31746 direct result of a command line switch, or because it is 31747 enabled by default or because it has been enabled as a side 31748 effect of a different command line switch. For example, the 31749 `-O2' switch enables various different individual 31750 optimization passes. 31751 31752 `SWITCH_TYPE_DESCRIPTIVE' 31753 TEXT is either NULL or some descriptive text which should be 31754 ignored. If TEXT is NULL then it is being used to warn the 31755 target hook that either recording is starting or ending. The 31756 first time TYPE is SWITCH_TYPE_DESCRIPTIVE and TEXT is NULL, 31757 the warning is for start up and the second time the warning 31758 is for wind down. This feature is to allow the target hook 31759 to make any necessary preparations before it starts to record 31760 switches and to perform any necessary tidying up after it has 31761 finished recording switches. 31762 31763 `SWITCH_TYPE_LINE_START' 31764 This option can be ignored by this target hook. 31765 31766 `SWITCH_TYPE_LINE_END' 31767 This option can be ignored by this target hook. 31768 31769 The hook's return value must be zero. Other return values may be 31770 supported in the future. 31771 31772 By default this hook is set to NULL, but an example implementation 31773 is provided for ELF based targets. Called ELF_RECORD_GCC_SWITCHES, 31774 it records the switches as ASCII text inside a new, string 31775 mergeable section in the assembler output file. The name of the 31776 new section is provided by the 31777 `TARGET_ASM_RECORD_GCC_SWITCHES_SECTION' target hook. 31778 31779 -- Target Hook: const char * TARGET_ASM_RECORD_GCC_SWITCHES_SECTION 31780 This is the name of the section that will be created by the example 31781 ELF implementation of the `TARGET_ASM_RECORD_GCC_SWITCHES' target 31782 hook. 31783 31784 31785File: gccint.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format 31786 3178717.21.2 Output of Data 31788---------------------- 31789 31790 -- Target Hook: const char * TARGET_ASM_BYTE_OP 31791 -- Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP 31792 -- Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP 31793 -- Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP 31794 -- Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP 31795 -- Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP 31796 -- Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP 31797 -- Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP 31798 -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP 31799 These hooks specify assembly directives for creating certain kinds 31800 of integer object. The `TARGET_ASM_BYTE_OP' directive creates a 31801 byte-sized object, the `TARGET_ASM_ALIGNED_HI_OP' one creates an 31802 aligned two-byte object, and so on. Any of the hooks may be 31803 `NULL', indicating that no suitable directive is available. 31804 31805 The compiler will print these strings at the start of a new line, 31806 followed immediately by the object's initial value. In most cases, 31807 the string should contain a tab, a pseudo-op, and then another tab. 31808 31809 -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int 31810 ALIGNED_P) 31811 The `assemble_integer' function uses this hook to output an 31812 integer object. X is the object's value, SIZE is its size in 31813 bytes and ALIGNED_P indicates whether it is aligned. The function 31814 should return `true' if it was able to output the object. If it 31815 returns false, `assemble_integer' will try to split the object 31816 into smaller parts. 31817 31818 The default implementation of this hook will use the 31819 `TARGET_ASM_BYTE_OP' family of strings, returning `false' when the 31820 relevant string is `NULL'. 31821 31822 -- Macro: OUTPUT_ADDR_CONST_EXTRA (STREAM, X, FAIL) 31823 A C statement to recognize RTX patterns that `output_addr_const' 31824 can't deal with, and output assembly code to STREAM corresponding 31825 to the pattern X. This may be used to allow machine-dependent 31826 `UNSPEC's to appear within constants. 31827 31828 If `OUTPUT_ADDR_CONST_EXTRA' fails to recognize a pattern, it must 31829 `goto fail', so that a standard error message is printed. If it 31830 prints an error message itself, by calling, for example, 31831 `output_operand_lossage', it may just complete normally. 31832 31833 -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN) 31834 A C statement to output to the stdio stream STREAM an assembler 31835 instruction to assemble a string constant containing the LEN bytes 31836 at PTR. PTR will be a C expression of type `char *' and LEN a C 31837 expression of type `int'. 31838 31839 If the assembler has a `.ascii' pseudo-op as found in the Berkeley 31840 Unix assembler, do not define the macro `ASM_OUTPUT_ASCII'. 31841 31842 -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N) 31843 A C statement to output word N of a function descriptor for DECL. 31844 This must be defined if `TARGET_VTABLE_USES_DESCRIPTORS' is 31845 defined, and is otherwise unused. 31846 31847 -- Macro: CONSTANT_POOL_BEFORE_FUNCTION 31848 You may define this macro as a C expression. You should define the 31849 expression to have a nonzero value if GCC should output the 31850 constant pool for a function before the code for the function, or 31851 a zero value if GCC should output the constant pool after the 31852 function. If you do not define this macro, the usual case, GCC 31853 will output the constant pool before the function. 31854 31855 -- Macro: ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE) 31856 A C statement to output assembler commands to define the start of 31857 the constant pool for a function. FUNNAME is a string giving the 31858 name of the function. Should the return type of the function be 31859 required, it can be obtained via FUNDECL. SIZE is the size, in 31860 bytes, of the constant pool that will be written immediately after 31861 this call. 31862 31863 If no constant-pool prefix is required, the usual case, this macro 31864 need not be defined. 31865 31866 -- Macro: ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, 31867 LABELNO, JUMPTO) 31868 A C statement (with or without semicolon) to output a constant in 31869 the constant pool, if it needs special treatment. (This macro 31870 need not do anything for RTL expressions that can be output 31871 normally.) 31872 31873 The argument FILE is the standard I/O stream to output the 31874 assembler code on. X is the RTL expression for the constant to 31875 output, and MODE is the machine mode (in case X is a `const_int'). 31876 ALIGN is the required alignment for the value X; you should output 31877 an assembler directive to force this much alignment. 31878 31879 The argument LABELNO is a number to use in an internal label for 31880 the address of this pool entry. The definition of this macro is 31881 responsible for outputting the label definition at the proper 31882 place. Here is how to do this: 31883 31884 `(*targetm.asm_out.internal_label)' (FILE, "LC", LABELNO); 31885 31886 When you output a pool entry specially, you should end with a 31887 `goto' to the label JUMPTO. This will prevent the same pool entry 31888 from being output a second time in the usual manner. 31889 31890 You need not define this macro if it would do nothing. 31891 31892 -- Macro: ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE) 31893 A C statement to output assembler commands to at the end of the 31894 constant pool for a function. FUNNAME is a string giving the name 31895 of the function. Should the return type of the function be 31896 required, you can obtain it via FUNDECL. SIZE is the size, in 31897 bytes, of the constant pool that GCC wrote immediately before this 31898 call. 31899 31900 If no constant-pool epilogue is required, the usual case, you need 31901 not define this macro. 31902 31903 -- Macro: IS_ASM_LOGICAL_LINE_SEPARATOR (C, STR) 31904 Define this macro as a C expression which is nonzero if C is used 31905 as a logical line separator by the assembler. STR points to the 31906 position in the string where C was found; this can be used if a 31907 line separator uses multiple characters. 31908 31909 If you do not define this macro, the default is that only the 31910 character `;' is treated as a logical line separator. 31911 31912 -- Target Hook: const char * TARGET_ASM_OPEN_PAREN 31913 -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN 31914 These target hooks are C string constants, describing the syntax 31915 in the assembler for grouping arithmetic expressions. If not 31916 overridden, they default to normal parentheses, which is correct 31917 for most assemblers. 31918 31919 These macros are provided by `real.h' for writing the definitions of 31920`ASM_OUTPUT_DOUBLE' and the like: 31921 31922 -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L) 31923 -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L) 31924 -- Macro: REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L) 31925 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL32 (X, L) 31926 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL64 (X, L) 31927 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL128 (X, L) 31928 These translate X, of type `REAL_VALUE_TYPE', to the target's 31929 floating point representation, and store its bit pattern in the 31930 variable L. For `REAL_VALUE_TO_TARGET_SINGLE' and 31931 `REAL_VALUE_TO_TARGET_DECIMAL32', this variable should be a simple 31932 `long int'. For the others, it should be an array of `long int'. 31933 The number of elements in this array is determined by the size of 31934 the desired target floating point data type: 32 bits of it go in 31935 each `long int' array element. Each array element holds 32 bits 31936 of the result, even if `long int' is wider than 32 bits on the 31937 host machine. 31938 31939 The array element values are designed so that you can print them 31940 out using `fprintf' in the order they should appear in the target 31941 machine's memory. 31942 31943 31944File: gccint.info, Node: Uninitialized Data, Next: Label Output, Prev: Data Output, Up: Assembler Format 31945 3194617.21.3 Output of Uninitialized Variables 31947----------------------------------------- 31948 31949Each of the macros in this section is used to do the whole job of 31950outputting a single uninitialized variable. 31951 31952 -- Macro: ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED) 31953 A C statement (sans semicolon) to output to the stdio stream 31954 STREAM the assembler definition of a common-label named NAME whose 31955 size is SIZE bytes. The variable ROUNDED is the size rounded up 31956 to whatever alignment the caller wants. It is possible that SIZE 31957 may be zero, for instance if a struct with no other member than a 31958 zero-length array is defined. In this case, the backend must 31959 output a symbol definition that allocates at least one byte, both 31960 so that the address of the resulting object does not compare equal 31961 to any other, and because some object formats cannot even express 31962 the concept of a zero-sized common symbol, as that is how they 31963 represent an ordinary undefined external. 31964 31965 Use the expression `assemble_name (STREAM, NAME)' to output the 31966 name itself; before and after that, output the additional 31967 assembler syntax for defining the name, and a newline. 31968 31969 This macro controls how the assembler definitions of uninitialized 31970 common global variables are output. 31971 31972 -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT) 31973 Like `ASM_OUTPUT_COMMON' except takes the required alignment as a 31974 separate, explicit argument. If you define this macro, it is used 31975 in place of `ASM_OUTPUT_COMMON', and gives you more flexibility in 31976 handling the required alignment of the variable. The alignment is 31977 specified as the number of bits. 31978 31979 -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE, 31980 ALIGNMENT) 31981 Like `ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable 31982 to be output, if there is one, or `NULL_TREE' if there is no 31983 corresponding variable. If you define this macro, GCC will use it 31984 in place of both `ASM_OUTPUT_COMMON' and 31985 `ASM_OUTPUT_ALIGNED_COMMON'. Define this macro when you need to 31986 see the variable's decl in order to chose what to output. 31987 31988 -- Macro: ASM_OUTPUT_BSS (STREAM, DECL, NAME, SIZE, ROUNDED) 31989 A C statement (sans semicolon) to output to the stdio stream 31990 STREAM the assembler definition of uninitialized global DECL named 31991 NAME whose size is SIZE bytes. The variable ROUNDED is the size 31992 rounded up to whatever alignment the caller wants. 31993 31994 Try to use function `asm_output_bss' defined in `varasm.c' when 31995 defining this macro. If unable, use the expression `assemble_name 31996 (STREAM, NAME)' to output the name itself; before and after that, 31997 output the additional assembler syntax for defining the name, and 31998 a newline. 31999 32000 There are two ways of handling global BSS. One is to define either 32001 this macro or its aligned counterpart, `ASM_OUTPUT_ALIGNED_BSS'. 32002 The other is to have `TARGET_ASM_SELECT_SECTION' return a 32003 switchable BSS section (*note 32004 TARGET_HAVE_SWITCHABLE_BSS_SECTIONS::). You do not need to do 32005 both. 32006 32007 Some languages do not have `common' data, and require a non-common 32008 form of global BSS in order to handle uninitialized globals 32009 efficiently. C++ is one example of this. However, if the target 32010 does not support global BSS, the front end may choose to make 32011 globals common in order to save space in the object file. 32012 32013 -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT) 32014 Like `ASM_OUTPUT_BSS' except takes the required alignment as a 32015 separate, explicit argument. If you define this macro, it is used 32016 in place of `ASM_OUTPUT_BSS', and gives you more flexibility in 32017 handling the required alignment of the variable. The alignment is 32018 specified as the number of bits. 32019 32020 Try to use function `asm_output_aligned_bss' defined in file 32021 `varasm.c' when defining this macro. 32022 32023 -- Macro: ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED) 32024 A C statement (sans semicolon) to output to the stdio stream 32025 STREAM the assembler definition of a local-common-label named NAME 32026 whose size is SIZE bytes. The variable ROUNDED is the size 32027 rounded up to whatever alignment the caller wants. 32028 32029 Use the expression `assemble_name (STREAM, NAME)' to output the 32030 name itself; before and after that, output the additional 32031 assembler syntax for defining the name, and a newline. 32032 32033 This macro controls how the assembler definitions of uninitialized 32034 static variables are output. 32035 32036 -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT) 32037 Like `ASM_OUTPUT_LOCAL' except takes the required alignment as a 32038 separate, explicit argument. If you define this macro, it is used 32039 in place of `ASM_OUTPUT_LOCAL', and gives you more flexibility in 32040 handling the required alignment of the variable. The alignment is 32041 specified as the number of bits. 32042 32043 -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE, 32044 ALIGNMENT) 32045 Like `ASM_OUTPUT_ALIGNED_DECL' except that DECL of the variable to 32046 be output, if there is one, or `NULL_TREE' if there is no 32047 corresponding variable. If you define this macro, GCC will use it 32048 in place of both `ASM_OUTPUT_DECL' and `ASM_OUTPUT_ALIGNED_DECL'. 32049 Define this macro when you need to see the variable's decl in 32050 order to chose what to output. 32051 32052 32053File: gccint.info, Node: Label Output, Next: Initialization, Prev: Uninitialized Data, Up: Assembler Format 32054 3205517.21.4 Output and Generation of Labels 32056--------------------------------------- 32057 32058This is about outputting labels. 32059 32060 -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME) 32061 A C statement (sans semicolon) to output to the stdio stream 32062 STREAM the assembler definition of a label named NAME. Use the 32063 expression `assemble_name (STREAM, NAME)' to output the name 32064 itself; before and after that, output the additional assembler 32065 syntax for defining the name, and a newline. A default definition 32066 of this macro is provided which is correct for most systems. 32067 32068 -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME) 32069 Identical to `ASM_OUTPUT_LABEL', except that NAME is known to 32070 refer to a compiler-generated label. The default definition uses 32071 `assemble_name_raw', which is like `assemble_name' except that it 32072 is more efficient. 32073 32074 -- Macro: SIZE_ASM_OP 32075 A C string containing the appropriate assembler directive to 32076 specify the size of a symbol, without any arguments. On systems 32077 that use ELF, the default (in `config/elfos.h') is `"\t.size\t"'; 32078 on other systems, the default is not to define this macro. 32079 32080 Define this macro only if it is correct to use the default 32081 definitions of `ASM_OUTPUT_SIZE_DIRECTIVE' and 32082 `ASM_OUTPUT_MEASURED_SIZE' for your system. If you need your own 32083 custom definitions of those macros, or if you do not need explicit 32084 symbol sizes at all, do not define this macro. 32085 32086 -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE) 32087 A C statement (sans semicolon) to output to the stdio stream 32088 STREAM a directive telling the assembler that the size of the 32089 symbol NAME is SIZE. SIZE is a `HOST_WIDE_INT'. If you define 32090 `SIZE_ASM_OP', a default definition of this macro is provided. 32091 32092 -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME) 32093 A C statement (sans semicolon) to output to the stdio stream 32094 STREAM a directive telling the assembler to calculate the size of 32095 the symbol NAME by subtracting its address from the current 32096 address. 32097 32098 If you define `SIZE_ASM_OP', a default definition of this macro is 32099 provided. The default assumes that the assembler recognizes a 32100 special `.' symbol as referring to the current address, and can 32101 calculate the difference between this and another symbol. If your 32102 assembler does not recognize `.' or cannot do calculations with 32103 it, you will need to redefine `ASM_OUTPUT_MEASURED_SIZE' to use 32104 some other technique. 32105 32106 -- Macro: TYPE_ASM_OP 32107 A C string containing the appropriate assembler directive to 32108 specify the type of a symbol, without any arguments. On systems 32109 that use ELF, the default (in `config/elfos.h') is `"\t.type\t"'; 32110 on other systems, the default is not to define this macro. 32111 32112 Define this macro only if it is correct to use the default 32113 definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 32114 need your own custom definition of this macro, or if you do not 32115 need explicit symbol types at all, do not define this macro. 32116 32117 -- Macro: TYPE_OPERAND_FMT 32118 A C string which specifies (using `printf' syntax) the format of 32119 the second operand to `TYPE_ASM_OP'. On systems that use ELF, the 32120 default (in `config/elfos.h') is `"@%s"'; on other systems, the 32121 default is not to define this macro. 32122 32123 Define this macro only if it is correct to use the default 32124 definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 32125 need your own custom definition of this macro, or if you do not 32126 need explicit symbol types at all, do not define this macro. 32127 32128 -- Macro: ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE) 32129 A C statement (sans semicolon) to output to the stdio stream 32130 STREAM a directive telling the assembler that the type of the 32131 symbol NAME is TYPE. TYPE is a C string; currently, that string 32132 is always either `"function"' or `"object"', but you should not 32133 count on this. 32134 32135 If you define `TYPE_ASM_OP' and `TYPE_OPERAND_FMT', a default 32136 definition of this macro is provided. 32137 32138 -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL) 32139 A C statement (sans semicolon) to output to the stdio stream 32140 STREAM any text necessary for declaring the name NAME of a 32141 function which is being defined. This macro is responsible for 32142 outputting the label definition (perhaps using 32143 `ASM_OUTPUT_LABEL'). The argument DECL is the `FUNCTION_DECL' 32144 tree node representing the function. 32145 32146 If this macro is not defined, then the function name is defined in 32147 the usual manner as a label (by means of `ASM_OUTPUT_LABEL'). 32148 32149 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 32150 of this macro. 32151 32152 -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL) 32153 A C statement (sans semicolon) to output to the stdio stream 32154 STREAM any text necessary for declaring the size of a function 32155 which is being defined. The argument NAME is the name of the 32156 function. The argument DECL is the `FUNCTION_DECL' tree node 32157 representing the function. 32158 32159 If this macro is not defined, then the function size is not 32160 defined. 32161 32162 You may wish to use `ASM_OUTPUT_MEASURED_SIZE' in the definition 32163 of this macro. 32164 32165 -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL) 32166 A C statement (sans semicolon) to output to the stdio stream 32167 STREAM any text necessary for declaring the name NAME of an 32168 initialized variable which is being defined. This macro must 32169 output the label definition (perhaps using `ASM_OUTPUT_LABEL'). 32170 The argument DECL is the `VAR_DECL' tree node representing the 32171 variable. 32172 32173 If this macro is not defined, then the variable name is defined in 32174 the usual manner as a label (by means of `ASM_OUTPUT_LABEL'). 32175 32176 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' and/or 32177 `ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro. 32178 32179 -- Macro: ASM_DECLARE_CONSTANT_NAME (STREAM, NAME, EXP, SIZE) 32180 A C statement (sans semicolon) to output to the stdio stream 32181 STREAM any text necessary for declaring the name NAME of a 32182 constant which is being defined. This macro is responsible for 32183 outputting the label definition (perhaps using 32184 `ASM_OUTPUT_LABEL'). The argument EXP is the value of the 32185 constant, and SIZE is the size of the constant in bytes. NAME 32186 will be an internal label. 32187 32188 If this macro is not defined, then the NAME is defined in the 32189 usual manner as a label (by means of `ASM_OUTPUT_LABEL'). 32190 32191 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 32192 of this macro. 32193 32194 -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME) 32195 A C statement (sans semicolon) to output to the stdio stream 32196 STREAM any text necessary for claiming a register REGNO for a 32197 global variable DECL with name NAME. 32198 32199 If you don't define this macro, that is equivalent to defining it 32200 to do nothing. 32201 32202 -- Macro: ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND) 32203 A C statement (sans semicolon) to finish up declaring a variable 32204 name once the compiler has processed its initializer fully and 32205 thus has had a chance to determine the size of an array when 32206 controlled by an initializer. This is used on systems where it's 32207 necessary to declare something about the size of the object. 32208 32209 If you don't define this macro, that is equivalent to defining it 32210 to do nothing. 32211 32212 You may wish to use `ASM_OUTPUT_SIZE_DIRECTIVE' and/or 32213 `ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro. 32214 32215 -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const 32216 char *NAME) 32217 This target hook is a function to output to the stdio stream 32218 STREAM some commands that will make the label NAME global; that 32219 is, available for reference from other files. 32220 32221 The default implementation relies on a proper definition of 32222 `GLOBAL_ASM_OP'. 32223 32224 -- Target Hook: void TARGET_ASM_GLOBALIZE_DECL_NAME (FILE *STREAM, 32225 tree DECL) 32226 This target hook is a function to output to the stdio stream 32227 STREAM some commands that will make the name associated with DECL 32228 global; that is, available for reference from other files. 32229 32230 The default implementation uses the TARGET_ASM_GLOBALIZE_LABEL 32231 target hook. 32232 32233 -- Macro: ASM_WEAKEN_LABEL (STREAM, NAME) 32234 A C statement (sans semicolon) to output to the stdio stream 32235 STREAM some commands that will make the label NAME weak; that is, 32236 available for reference from other files but only used if no other 32237 definition is available. Use the expression `assemble_name 32238 (STREAM, NAME)' to output the name itself; before and after that, 32239 output the additional assembler syntax for making that name weak, 32240 and a newline. 32241 32242 If you don't define this macro or `ASM_WEAKEN_DECL', GCC will not 32243 support weak symbols and you should not define the `SUPPORTS_WEAK' 32244 macro. 32245 32246 -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE) 32247 Combines (and replaces) the function of `ASM_WEAKEN_LABEL' and 32248 `ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function 32249 or variable decl. If VALUE is not `NULL', this C statement should 32250 output to the stdio stream STREAM assembler code which defines 32251 (equates) the weak symbol NAME to have the value VALUE. If VALUE 32252 is `NULL', it should output commands to make NAME weak. 32253 32254 -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE) 32255 Outputs a directive that enables NAME to be used to refer to 32256 symbol VALUE with weak-symbol semantics. `decl' is the 32257 declaration of `name'. 32258 32259 -- Macro: SUPPORTS_WEAK 32260 A C expression which evaluates to true if the target supports weak 32261 symbols. 32262 32263 If you don't define this macro, `defaults.h' provides a default 32264 definition. If either `ASM_WEAKEN_LABEL' or `ASM_WEAKEN_DECL' is 32265 defined, the default definition is `1'; otherwise, it is `0'. 32266 Define this macro if you want to control weak symbol support with 32267 a compiler flag such as `-melf'. 32268 32269 -- Macro: MAKE_DECL_ONE_ONLY (DECL) 32270 A C statement (sans semicolon) to mark DECL to be emitted as a 32271 public symbol such that extra copies in multiple translation units 32272 will be discarded by the linker. Define this macro if your object 32273 file format provides support for this concept, such as the `COMDAT' 32274 section flags in the Microsoft Windows PE/COFF format, and this 32275 support requires changes to DECL, such as putting it in a separate 32276 section. 32277 32278 -- Macro: SUPPORTS_ONE_ONLY 32279 A C expression which evaluates to true if the target supports 32280 one-only semantics. 32281 32282 If you don't define this macro, `varasm.c' provides a default 32283 definition. If `MAKE_DECL_ONE_ONLY' is defined, the default 32284 definition is `1'; otherwise, it is `0'. Define this macro if you 32285 want to control one-only symbol support with a compiler flag, or if 32286 setting the `DECL_ONE_ONLY' flag is enough to mark a declaration to 32287 be emitted as one-only. 32288 32289 -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, int 32290 VISIBILITY) 32291 This target hook is a function to output to ASM_OUT_FILE some 32292 commands that will make the symbol(s) associated with DECL have 32293 hidden, protected or internal visibility as specified by 32294 VISIBILITY. 32295 32296 -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC 32297 A C expression that evaluates to true if the target's linker 32298 expects that weak symbols do not appear in a static archive's 32299 table of contents. The default is `0'. 32300 32301 Leaving weak symbols out of an archive's table of contents means 32302 that, if a symbol will only have a definition in one translation 32303 unit and will have undefined references from other translation 32304 units, that symbol should not be weak. Defining this macro to be 32305 nonzero will thus have the effect that certain symbols that would 32306 normally be weak (explicit template instantiations, and vtables 32307 for polymorphic classes with noninline key methods) will instead 32308 be nonweak. 32309 32310 The C++ ABI requires this macro to be zero. Define this macro for 32311 targets where full C++ ABI compliance is impossible and where 32312 linker restrictions require weak symbols to be left out of a 32313 static archive's table of contents. 32314 32315 -- Macro: ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME) 32316 A C statement (sans semicolon) to output to the stdio stream 32317 STREAM any text necessary for declaring the name of an external 32318 symbol named NAME which is referenced in this compilation but not 32319 defined. The value of DECL is the tree node for the declaration. 32320 32321 This macro need not be defined if it does not need to output 32322 anything. The GNU assembler and most Unix assemblers don't 32323 require anything. 32324 32325 -- Target Hook: void TARGET_ASM_EXTERNAL_LIBCALL (rtx SYMREF) 32326 This target hook is a function to output to ASM_OUT_FILE an 32327 assembler pseudo-op to declare a library function name external. 32328 The name of the library function is given by SYMREF, which is a 32329 `symbol_ref'. 32330 32331 -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (const char 32332 *SYMBOL) 32333 This target hook is a function to output to ASM_OUT_FILE an 32334 assembler directive to annotate SYMBOL as used. The Darwin target 32335 uses the .no_dead_code_strip directive. 32336 32337 -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME) 32338 A C statement (sans semicolon) to output to the stdio stream 32339 STREAM a reference in assembler syntax to a label named NAME. 32340 This should add `_' to the front of the name, if that is customary 32341 on your operating system, as it is in most Berkeley Unix systems. 32342 This macro is used in `assemble_name'. 32343 32344 -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM) 32345 A C statement (sans semicolon) to output a reference to 32346 `SYMBOL_REF' SYM. If not defined, `assemble_name' will be used to 32347 output the name of the symbol. This macro may be used to modify 32348 the way a symbol is referenced depending on information encoded by 32349 `TARGET_ENCODE_SECTION_INFO'. 32350 32351 -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF) 32352 A C statement (sans semicolon) to output a reference to BUF, the 32353 result of `ASM_GENERATE_INTERNAL_LABEL'. If not defined, 32354 `assemble_name' will be used to output the name of the symbol. 32355 This macro is not used by `output_asm_label', or the `%l' 32356 specifier that calls it; the intention is that this macro should 32357 be set when it is necessary to output a label differently when its 32358 address is being taken. 32359 32360 -- Target Hook: void TARGET_ASM_INTERNAL_LABEL (FILE *STREAM, const 32361 char *PREFIX, unsigned long LABELNO) 32362 A function to output to the stdio stream STREAM a label whose name 32363 is made from the string PREFIX and the number LABELNO. 32364 32365 It is absolutely essential that these labels be distinct from the 32366 labels used for user-level functions and variables. Otherwise, 32367 certain programs will have name conflicts with internal labels. 32368 32369 It is desirable to exclude internal labels from the symbol table 32370 of the object file. Most assemblers have a naming convention for 32371 labels that should be excluded; on many systems, the letter `L' at 32372 the beginning of a label has this effect. You should find out what 32373 convention your system uses, and follow it. 32374 32375 The default version of this function utilizes 32376 `ASM_GENERATE_INTERNAL_LABEL'. 32377 32378 -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM) 32379 A C statement to output to the stdio stream STREAM a debug info 32380 label whose name is made from the string PREFIX and the number 32381 NUM. This is useful for VLIW targets, where debug info labels may 32382 need to be treated differently than branch target labels. On some 32383 systems, branch target labels must be at the beginning of 32384 instruction bundles, but debug info labels can occur in the middle 32385 of instruction bundles. 32386 32387 If this macro is not defined, then 32388 `(*targetm.asm_out.internal_label)' will be used. 32389 32390 -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM) 32391 A C statement to store into the string STRING a label whose name 32392 is made from the string PREFIX and the number NUM. 32393 32394 This string, when output subsequently by `assemble_name', should 32395 produce the output that `(*targetm.asm_out.internal_label)' would 32396 produce with the same PREFIX and NUM. 32397 32398 If the string begins with `*', then `assemble_name' will output 32399 the rest of the string unchanged. It is often convenient for 32400 `ASM_GENERATE_INTERNAL_LABEL' to use `*' in this way. If the 32401 string doesn't start with `*', then `ASM_OUTPUT_LABELREF' gets to 32402 output the string, and may change it. (Of course, 32403 `ASM_OUTPUT_LABELREF' is also part of your machine description, so 32404 you should know what it does on your machine.) 32405 32406 -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER) 32407 A C expression to assign to OUTVAR (which is a variable of type 32408 `char *') a newly allocated string made from the string NAME and 32409 the number NUMBER, with some suitable punctuation added. Use 32410 `alloca' to get space for the string. 32411 32412 The string will be used as an argument to `ASM_OUTPUT_LABELREF' to 32413 produce an assembler label for an internal static variable whose 32414 name is NAME. Therefore, the string must be such as to result in 32415 valid assembler code. The argument NUMBER is different each time 32416 this macro is executed; it prevents conflicts between 32417 similarly-named internal static variables in different scopes. 32418 32419 Ideally this string should not be a valid C identifier, to prevent 32420 any conflict with the user's own symbols. Most assemblers allow 32421 periods or percent signs in assembler symbols; putting at least 32422 one of these between the name and the number will suffice. 32423 32424 If this macro is not defined, a default definition will be provided 32425 which is correct for most systems. 32426 32427 -- Macro: ASM_OUTPUT_DEF (STREAM, NAME, VALUE) 32428 A C statement to output to the stdio stream STREAM assembler code 32429 which defines (equates) the symbol NAME to have the value VALUE. 32430 32431 If `SET_ASM_OP' is defined, a default definition is provided which 32432 is correct for most systems. 32433 32434 -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME, 32435 DECL_OF_VALUE) 32436 A C statement to output to the stdio stream STREAM assembler code 32437 which defines (equates) the symbol whose tree node is DECL_OF_NAME 32438 to have the value of the tree node DECL_OF_VALUE. This macro will 32439 be used in preference to `ASM_OUTPUT_DEF' if it is defined and if 32440 the tree nodes are available. 32441 32442 If `SET_ASM_OP' is defined, a default definition is provided which 32443 is correct for most systems. 32444 32445 -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE) 32446 A C statement that evaluates to true if the assembler code which 32447 defines (equates) the symbol whose tree node is DECL_OF_NAME to 32448 have the value of the tree node DECL_OF_VALUE should be emitted 32449 near the end of the current compilation unit. The default is to 32450 not defer output of defines. This macro affects defines output by 32451 `ASM_OUTPUT_DEF' and `ASM_OUTPUT_DEF_FROM_DECLS'. 32452 32453 -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE) 32454 A C statement to output to the stdio stream STREAM assembler code 32455 which defines (equates) the weak symbol NAME to have the value 32456 VALUE. If VALUE is `NULL', it defines NAME as an undefined weak 32457 symbol. 32458 32459 Define this macro if the target only supports weak aliases; define 32460 `ASM_OUTPUT_DEF' instead if possible. 32461 32462 -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME, 32463 SEL_NAME) 32464 Define this macro to override the default assembler names used for 32465 Objective-C methods. 32466 32467 The default name is a unique method number followed by the name of 32468 the class (e.g. `_1_Foo'). For methods in categories, the name of 32469 the category is also included in the assembler name (e.g. 32470 `_1_Foo_Bar'). 32471 32472 These names are safe on most systems, but make debugging difficult 32473 since the method's selector is not present in the name. 32474 Therefore, particular systems define other ways of computing names. 32475 32476 BUF is an expression of type `char *' which gives you a buffer in 32477 which to store the name; its length is as long as CLASS_NAME, 32478 CAT_NAME and SEL_NAME put together, plus 50 characters extra. 32479 32480 The argument IS_INST specifies whether the method is an instance 32481 method or a class method; CLASS_NAME is the name of the class; 32482 CAT_NAME is the name of the category (or `NULL' if the method is 32483 not in a category); and SEL_NAME is the name of the selector. 32484 32485 On systems where the assembler can handle quoted names, you can 32486 use this macro to provide more human-readable names. 32487 32488 -- Macro: ASM_DECLARE_CLASS_REFERENCE (STREAM, NAME) 32489 A C statement (sans semicolon) to output to the stdio stream 32490 STREAM commands to declare that the label NAME is an Objective-C 32491 class reference. This is only needed for targets whose linkers 32492 have special support for NeXT-style runtimes. 32493 32494 -- Macro: ASM_DECLARE_UNRESOLVED_REFERENCE (STREAM, NAME) 32495 A C statement (sans semicolon) to output to the stdio stream 32496 STREAM commands to declare that the label NAME is an unresolved 32497 Objective-C class reference. This is only needed for targets 32498 whose linkers have special support for NeXT-style runtimes. 32499 32500 32501File: gccint.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format 32502 3250317.21.5 How Initialization Functions Are Handled 32504------------------------------------------------ 32505 32506The compiled code for certain languages includes "constructors" (also 32507called "initialization routines")--functions to initialize data in the 32508program when the program is started. These functions need to be called 32509before the program is "started"--that is to say, before `main' is 32510called. 32511 32512 Compiling some languages generates "destructors" (also called 32513"termination routines") that should be called when the program 32514terminates. 32515 32516 To make the initialization and termination functions work, the compiler 32517must output something in the assembler code to cause those functions to 32518be called at the appropriate time. When you port the compiler to a new 32519system, you need to specify how to do this. 32520 32521 There are two major ways that GCC currently supports the execution of 32522initialization and termination functions. Each way has two variants. 32523Much of the structure is common to all four variations. 32524 32525 The linker must build two lists of these functions--a list of 32526initialization functions, called `__CTOR_LIST__', and a list of 32527termination functions, called `__DTOR_LIST__'. 32528 32529 Each list always begins with an ignored function pointer (which may 32530hold 0, -1, or a count of the function pointers after it, depending on 32531the environment). This is followed by a series of zero or more function 32532pointers to constructors (or destructors), followed by a function 32533pointer containing zero. 32534 32535 Depending on the operating system and its executable file format, 32536either `crtstuff.c' or `libgcc2.c' traverses these lists at startup 32537time and exit time. Constructors are called in reverse order of the 32538list; destructors in forward order. 32539 32540 The best way to handle static constructors works only for object file 32541formats which provide arbitrarily-named sections. A section is set 32542aside for a list of constructors, and another for a list of destructors. 32543Traditionally these are called `.ctors' and `.dtors'. Each object file 32544that defines an initialization function also puts a word in the 32545constructor section to point to that function. The linker accumulates 32546all these words into one contiguous `.ctors' section. Termination 32547functions are handled similarly. 32548 32549 This method will be chosen as the default by `target-def.h' if 32550`TARGET_ASM_NAMED_SECTION' is defined. A target that does not support 32551arbitrary sections, but does support special designated constructor and 32552destructor sections may define `CTORS_SECTION_ASM_OP' and 32553`DTORS_SECTION_ASM_OP' to achieve the same effect. 32554 32555 When arbitrary sections are available, there are two variants, 32556depending upon how the code in `crtstuff.c' is called. On systems that 32557support a ".init" section which is executed at program startup, parts 32558of `crtstuff.c' are compiled into that section. The program is linked 32559by the `gcc' driver like this: 32560 32561 ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o 32562 32563 The prologue of a function (`__init') appears in the `.init' section 32564of `crti.o'; the epilogue appears in `crtn.o'. Likewise for the 32565function `__fini' in the ".fini" section. Normally these files are 32566provided by the operating system or by the GNU C library, but are 32567provided by GCC for a few targets. 32568 32569 The objects `crtbegin.o' and `crtend.o' are (for most targets) 32570compiled from `crtstuff.c'. They contain, among other things, code 32571fragments within the `.init' and `.fini' sections that branch to 32572routines in the `.text' section. The linker will pull all parts of a 32573section together, which results in a complete `__init' function that 32574invokes the routines we need at startup. 32575 32576 To use this variant, you must define the `INIT_SECTION_ASM_OP' macro 32577properly. 32578 32579 If no init section is available, when GCC compiles any function called 32580`main' (or more accurately, any function designated as a program entry 32581point by the language front end calling `expand_main_function'), it 32582inserts a procedure call to `__main' as the first executable code after 32583the function prologue. The `__main' function is defined in `libgcc2.c' 32584and runs the global constructors. 32585 32586 In file formats that don't support arbitrary sections, there are again 32587two variants. In the simplest variant, the GNU linker (GNU `ld') and 32588an `a.out' format must be used. In this case, `TARGET_ASM_CONSTRUCTOR' 32589is defined to produce a `.stabs' entry of type `N_SETT', referencing 32590the name `__CTOR_LIST__', and with the address of the void function 32591containing the initialization code as its value. The GNU linker 32592recognizes this as a request to add the value to a "set"; the values 32593are accumulated, and are eventually placed in the executable as a 32594vector in the format described above, with a leading (ignored) count 32595and a trailing zero element. `TARGET_ASM_DESTRUCTOR' is handled 32596similarly. Since no init section is available, the absence of 32597`INIT_SECTION_ASM_OP' causes the compilation of `main' to call `__main' 32598as above, starting the initialization process. 32599 32600 The last variant uses neither arbitrary sections nor the GNU linker. 32601This is preferable when you want to do dynamic linking and when using 32602file formats which the GNU linker does not support, such as `ECOFF'. In 32603this case, `TARGET_HAVE_CTORS_DTORS' is false, initialization and 32604termination functions are recognized simply by their names. This 32605requires an extra program in the linkage step, called `collect2'. This 32606program pretends to be the linker, for use with GCC; it does its job by 32607running the ordinary linker, but also arranges to include the vectors of 32608initialization and termination functions. These functions are called 32609via `__main' as described above. In order to use this method, 32610`use_collect2' must be defined in the target in `config.gcc'. 32611 32612 The following section describes the specific macros that control and 32613customize the handling of initialization and termination functions. 32614 32615 32616File: gccint.info, Node: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format 32617 3261817.21.6 Macros Controlling Initialization Routines 32619-------------------------------------------------- 32620 32621Here are the macros that control how the compiler handles initialization 32622and termination functions: 32623 32624 -- Macro: INIT_SECTION_ASM_OP 32625 If defined, a C string constant, including spacing, for the 32626 assembler operation to identify the following data as 32627 initialization code. If not defined, GCC will assume such a 32628 section does not exist. When you are using special sections for 32629 initialization and termination functions, this macro also controls 32630 how `crtstuff.c' and `libgcc2.c' arrange to run the initialization 32631 functions. 32632 32633 -- Macro: HAS_INIT_SECTION 32634 If defined, `main' will not call `__main' as described above. 32635 This macro should be defined for systems that control start-up code 32636 on a symbol-by-symbol basis, such as OSF/1, and should not be 32637 defined explicitly for systems that support `INIT_SECTION_ASM_OP'. 32638 32639 -- Macro: LD_INIT_SWITCH 32640 If defined, a C string constant for a switch that tells the linker 32641 that the following symbol is an initialization routine. 32642 32643 -- Macro: LD_FINI_SWITCH 32644 If defined, a C string constant for a switch that tells the linker 32645 that the following symbol is a finalization routine. 32646 32647 -- Macro: COLLECT_SHARED_INIT_FUNC (STREAM, FUNC) 32648 If defined, a C statement that will write a function that can be 32649 automatically called when a shared library is loaded. The function 32650 should call FUNC, which takes no arguments. If not defined, and 32651 the object format requires an explicit initialization function, 32652 then a function called `_GLOBAL__DI' will be generated. 32653 32654 This function and the following one are used by collect2 when 32655 linking a shared library that needs constructors or destructors, 32656 or has DWARF2 exception tables embedded in the code. 32657 32658 -- Macro: COLLECT_SHARED_FINI_FUNC (STREAM, FUNC) 32659 If defined, a C statement that will write a function that can be 32660 automatically called when a shared library is unloaded. The 32661 function should call FUNC, which takes no arguments. If not 32662 defined, and the object format requires an explicit finalization 32663 function, then a function called `_GLOBAL__DD' will be generated. 32664 32665 -- Macro: INVOKE__main 32666 If defined, `main' will call `__main' despite the presence of 32667 `INIT_SECTION_ASM_OP'. This macro should be defined for systems 32668 where the init section is not actually run automatically, but is 32669 still useful for collecting the lists of constructors and 32670 destructors. 32671 32672 -- Macro: SUPPORTS_INIT_PRIORITY 32673 If nonzero, the C++ `init_priority' attribute is supported and the 32674 compiler should emit instructions to control the order of 32675 initialization of objects. If zero, the compiler will issue an 32676 error message upon encountering an `init_priority' attribute. 32677 32678 -- Target Hook: bool TARGET_HAVE_CTORS_DTORS 32679 This value is true if the target supports some "native" method of 32680 collecting constructors and destructors to be run at startup and 32681 exit. It is false if we must use `collect2'. 32682 32683 -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY) 32684 If defined, a function that outputs assembler code to arrange to 32685 call the function referenced by SYMBOL at initialization time. 32686 32687 Assume that SYMBOL is a `SYMBOL_REF' for a function taking no 32688 arguments and with no return value. If the target supports 32689 initialization priorities, PRIORITY is a value between 0 and 32690 `MAX_INIT_PRIORITY'; otherwise it must be `DEFAULT_INIT_PRIORITY'. 32691 32692 If this macro is not defined by the target, a suitable default will 32693 be chosen if (1) the target supports arbitrary section names, (2) 32694 the target defines `CTORS_SECTION_ASM_OP', or (3) `USE_COLLECT2' 32695 is not defined. 32696 32697 -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY) 32698 This is like `TARGET_ASM_CONSTRUCTOR' but used for termination 32699 functions rather than initialization functions. 32700 32701 If `TARGET_HAVE_CTORS_DTORS' is true, the initialization routine 32702generated for the generated object file will have static linkage. 32703 32704 If your system uses `collect2' as the means of processing 32705constructors, then that program normally uses `nm' to scan an object 32706file for constructor functions to be called. 32707 32708 On certain kinds of systems, you can define this macro to make 32709`collect2' work faster (and, in some cases, make it work at all): 32710 32711 -- Macro: OBJECT_FORMAT_COFF 32712 Define this macro if the system uses COFF (Common Object File 32713 Format) object files, so that `collect2' can assume this format 32714 and scan object files directly for dynamic constructor/destructor 32715 functions. 32716 32717 This macro is effective only in a native compiler; `collect2' as 32718 part of a cross compiler always uses `nm' for the target machine. 32719 32720 -- Macro: REAL_NM_FILE_NAME 32721 Define this macro as a C string constant containing the file name 32722 to use to execute `nm'. The default is to search the path 32723 normally for `nm'. 32724 32725 If your system supports shared libraries and has a program to list 32726 the dynamic dependencies of a given library or executable, you can 32727 define these macros to enable support for running initialization 32728 and termination functions in shared libraries: 32729 32730 -- Macro: LDD_SUFFIX 32731 Define this macro to a C string constant containing the name of 32732 the program which lists dynamic dependencies, like `"ldd"' under 32733 SunOS 4. 32734 32735 -- Macro: PARSE_LDD_OUTPUT (PTR) 32736 Define this macro to be C code that extracts filenames from the 32737 output of the program denoted by `LDD_SUFFIX'. PTR is a variable 32738 of type `char *' that points to the beginning of a line of output 32739 from `LDD_SUFFIX'. If the line lists a dynamic dependency, the 32740 code must advance PTR to the beginning of the filename on that 32741 line. Otherwise, it must set PTR to `NULL'. 32742 32743 -- Macro: SHLIB_SUFFIX 32744 Define this macro to a C string constant containing the default 32745 shared library extension of the target (e.g., `".so"'). `collect2' 32746 strips version information after this suffix when generating global 32747 constructor and destructor names. This define is only needed on 32748 targets that use `collect2' to process constructors and 32749 destructors. 32750 32751 32752File: gccint.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format 32753 3275417.21.7 Output of Assembler Instructions 32755---------------------------------------- 32756 32757This describes assembler instruction output. 32758 32759 -- Macro: REGISTER_NAMES 32760 A C initializer containing the assembler's names for the machine 32761 registers, each one as a C string constant. This is what 32762 translates register numbers in the compiler into assembler 32763 language. 32764 32765 -- Macro: ADDITIONAL_REGISTER_NAMES 32766 If defined, a C initializer for an array of structures containing 32767 a name and a register number. This macro defines additional names 32768 for hard registers, thus allowing the `asm' option in declarations 32769 to refer to registers using alternate names. 32770 32771 -- Macro: ASM_OUTPUT_OPCODE (STREAM, PTR) 32772 Define this macro if you are using an unusual assembler that 32773 requires different names for the machine instructions. 32774 32775 The definition is a C statement or statements which output an 32776 assembler instruction opcode to the stdio stream STREAM. The 32777 macro-operand PTR is a variable of type `char *' which points to 32778 the opcode name in its "internal" form--the form that is written 32779 in the machine description. The definition should output the 32780 opcode name to STREAM, performing any translation you desire, and 32781 increment the variable PTR to point at the end of the opcode so 32782 that it will not be output twice. 32783 32784 In fact, your macro definition may process less than the entire 32785 opcode name, or more than the opcode name; but if you want to 32786 process text that includes `%'-sequences to substitute operands, 32787 you must take care of the substitution yourself. Just be sure to 32788 increment PTR over whatever text should not be output normally. 32789 32790 If you need to look at the operand values, they can be found as the 32791 elements of `recog_data.operand'. 32792 32793 If the macro definition does nothing, the instruction is output in 32794 the usual way. 32795 32796 -- Macro: FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS) 32797 If defined, a C statement to be executed just prior to the output 32798 of assembler code for INSN, to modify the extracted operands so 32799 they will be output differently. 32800 32801 Here the argument OPVEC is the vector containing the operands 32802 extracted from INSN, and NOPERANDS is the number of elements of 32803 the vector which contain meaningful data for this insn. The 32804 contents of this vector are what will be used to convert the insn 32805 template into assembler code, so you can change the assembler 32806 output by changing the contents of the vector. 32807 32808 This macro is useful when various assembler syntaxes share a single 32809 file of instruction patterns; by defining this macro differently, 32810 you can cause a large class of instructions to be output 32811 differently (such as with rearranged operands). Naturally, 32812 variations in assembler syntax affecting individual insn patterns 32813 ought to be handled by writing conditional output routines in 32814 those patterns. 32815 32816 If this macro is not defined, it is equivalent to a null statement. 32817 32818 -- Target Hook: void TARGET_ASM_FINAL_POSTSCAN_INSN (FILE *FILE, rtx 32819 INSN, rtx *OPVEC, int NOPERANDS) 32820 If defined, this target hook is a function which is executed just 32821 after the output of assembler code for INSN, to change the mode of 32822 the assembler if necessary. 32823 32824 Here the argument OPVEC is the vector containing the operands 32825 extracted from INSN, and NOPERANDS is the number of elements of 32826 the vector which contain meaningful data for this insn. The 32827 contents of this vector are what was used to convert the insn 32828 template into assembler code, so you can change the assembler mode 32829 by checking the contents of the vector. 32830 32831 -- Macro: PRINT_OPERAND (STREAM, X, CODE) 32832 A C compound statement to output to stdio stream STREAM the 32833 assembler syntax for an instruction operand X. X is an RTL 32834 expression. 32835 32836 CODE is a value that can be used to specify one of several ways of 32837 printing the operand. It is used when identical operands must be 32838 printed differently depending on the context. CODE comes from the 32839 `%' specification that was used to request printing of the 32840 operand. If the specification was just `%DIGIT' then CODE is 0; 32841 if the specification was `%LTR DIGIT' then CODE is the ASCII code 32842 for LTR. 32843 32844 If X is a register, this macro should print the register's name. 32845 The names can be found in an array `reg_names' whose type is `char 32846 *[]'. `reg_names' is initialized from `REGISTER_NAMES'. 32847 32848 When the machine description has a specification `%PUNCT' (a `%' 32849 followed by a punctuation character), this macro is called with a 32850 null pointer for X and the punctuation character for CODE. 32851 32852 -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE) 32853 A C expression which evaluates to true if CODE is a valid 32854 punctuation character for use in the `PRINT_OPERAND' macro. If 32855 `PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no 32856 punctuation characters (except for the standard one, `%') are used 32857 in this way. 32858 32859 -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X) 32860 A C compound statement to output to stdio stream STREAM the 32861 assembler syntax for an instruction operand that is a memory 32862 reference whose address is X. X is an RTL expression. 32863 32864 On some machines, the syntax for a symbolic address depends on the 32865 section that the address refers to. On these machines, define the 32866 hook `TARGET_ENCODE_SECTION_INFO' to store the information into the 32867 `symbol_ref', and then check for it here. *Note Assembler 32868 Format::. 32869 32870 -- Macro: DBR_OUTPUT_SEQEND (FILE) 32871 A C statement, to be executed after all slot-filler instructions 32872 have been output. If necessary, call `dbr_sequence_length' to 32873 determine the number of slots filled in a sequence (zero if not 32874 currently outputting a sequence), to decide how many no-ops to 32875 output, or whatever. 32876 32877 Don't define this macro if it has nothing to do, but it is helpful 32878 in reading assembly output if the extent of the delay sequence is 32879 made explicit (e.g. with white space). 32880 32881 Note that output routines for instructions with delay slots must be 32882prepared to deal with not being output as part of a sequence (i.e. when 32883the scheduling pass is not run, or when no slot fillers could be 32884found.) The variable `final_sequence' is null when not processing a 32885sequence, otherwise it contains the `sequence' rtx being output. 32886 32887 -- Macro: REGISTER_PREFIX 32888 -- Macro: LOCAL_LABEL_PREFIX 32889 -- Macro: USER_LABEL_PREFIX 32890 -- Macro: IMMEDIATE_PREFIX 32891 If defined, C string expressions to be used for the `%R', `%L', 32892 `%U', and `%I' options of `asm_fprintf' (see `final.c'). These 32893 are useful when a single `md' file must support multiple assembler 32894 formats. In that case, the various `tm.h' files can define these 32895 macros differently. 32896 32897 -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT) 32898 If defined this macro should expand to a series of `case' 32899 statements which will be parsed inside the `switch' statement of 32900 the `asm_fprintf' function. This allows targets to define extra 32901 printf formats which may useful when generating their assembler 32902 statements. Note that uppercase letters are reserved for future 32903 generic extensions to asm_fprintf, and so are not available to 32904 target specific code. The output file is given by the parameter 32905 FILE. The varargs input pointer is ARGPTR and the rest of the 32906 format string, starting the character after the one that is being 32907 switched upon, is pointed to by FORMAT. 32908 32909 -- Macro: ASSEMBLER_DIALECT 32910 If your target supports multiple dialects of assembler language 32911 (such as different opcodes), define this macro as a C expression 32912 that gives the numeric index of the assembler language dialect to 32913 use, with zero as the first variant. 32914 32915 If this macro is defined, you may use constructs of the form 32916 `{option0|option1|option2...}' 32917 in the output templates of patterns (*note Output Template::) or 32918 in the first argument of `asm_fprintf'. This construct outputs 32919 `option0', `option1', `option2', etc., if the value of 32920 `ASSEMBLER_DIALECT' is zero, one, two, etc. Any special characters 32921 within these strings retain their usual meaning. If there are 32922 fewer alternatives within the braces than the value of 32923 `ASSEMBLER_DIALECT', the construct outputs nothing. 32924 32925 If you do not define this macro, the characters `{', `|' and `}' 32926 do not have any special meaning when used in templates or operands 32927 to `asm_fprintf'. 32928 32929 Define the macros `REGISTER_PREFIX', `LOCAL_LABEL_PREFIX', 32930 `USER_LABEL_PREFIX' and `IMMEDIATE_PREFIX' if you can express the 32931 variations in assembler language syntax with that mechanism. 32932 Define `ASSEMBLER_DIALECT' and use the `{option0|option1}' syntax 32933 if the syntax variant are larger and involve such things as 32934 different opcodes or operand order. 32935 32936 -- Macro: ASM_OUTPUT_REG_PUSH (STREAM, REGNO) 32937 A C expression to output to STREAM some assembler code which will 32938 push hard register number REGNO onto the stack. The code need not 32939 be optimal, since this macro is used only when profiling. 32940 32941 -- Macro: ASM_OUTPUT_REG_POP (STREAM, REGNO) 32942 A C expression to output to STREAM some assembler code which will 32943 pop hard register number REGNO off of the stack. The code need 32944 not be optimal, since this macro is used only when profiling. 32945 32946 32947File: gccint.info, Node: Dispatch Tables, Next: Exception Region Output, Prev: Instruction Output, Up: Assembler Format 32948 3294917.21.8 Output of Dispatch Tables 32950--------------------------------- 32951 32952This concerns dispatch tables. 32953 32954 -- Macro: ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL) 32955 A C statement to output to the stdio stream STREAM an assembler 32956 pseudo-instruction to generate a difference between two labels. 32957 VALUE and REL are the numbers of two internal labels. The 32958 definitions of these labels are output using 32959 `(*targetm.asm_out.internal_label)', and they must be printed in 32960 the same way here. For example, 32961 32962 fprintf (STREAM, "\t.word L%d-L%d\n", 32963 VALUE, REL) 32964 32965 You must provide this macro on machines where the addresses in a 32966 dispatch table are relative to the table's own address. If 32967 defined, GCC will also use this macro on all machines when 32968 producing PIC. BODY is the body of the `ADDR_DIFF_VEC'; it is 32969 provided so that the mode and flags can be read. 32970 32971 -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE) 32972 This macro should be provided on machines where the addresses in a 32973 dispatch table are absolute. 32974 32975 The definition should be a C statement to output to the stdio 32976 stream STREAM an assembler pseudo-instruction to generate a 32977 reference to a label. VALUE is the number of an internal label 32978 whose definition is output using 32979 `(*targetm.asm_out.internal_label)'. For example, 32980 32981 fprintf (STREAM, "\t.word L%d\n", VALUE) 32982 32983 -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE) 32984 Define this if the label before a jump-table needs to be output 32985 specially. The first three arguments are the same as for 32986 `(*targetm.asm_out.internal_label)'; the fourth argument is the 32987 jump-table which follows (a `jump_insn' containing an `addr_vec' 32988 or `addr_diff_vec'). 32989 32990 This feature is used on system V to output a `swbeg' statement for 32991 the table. 32992 32993 If this macro is not defined, these labels are output with 32994 `(*targetm.asm_out.internal_label)'. 32995 32996 -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE) 32997 Define this if something special must be output at the end of a 32998 jump-table. The definition should be a C statement to be executed 32999 after the assembler code for the table is written. It should write 33000 the appropriate code to stdio stream STREAM. The argument TABLE 33001 is the jump-table insn, and NUM is the label-number of the 33002 preceding label. 33003 33004 If this macro is not defined, nothing special is output at the end 33005 of the jump-table. 33006 33007 -- Target Hook: void TARGET_ASM_EMIT_UNWIND_LABEL (FILE *STREAM, tree 33008 DECL, int FOR_EH, int EMPTY) 33009 This target hook emits a label at the beginning of each FDE. It 33010 should be defined on targets where FDEs need special labels, and it 33011 should write the appropriate label, for the FDE associated with the 33012 function declaration DECL, to the stdio stream STREAM. The third 33013 argument, FOR_EH, is a boolean: true if this is for an exception 33014 table. The fourth argument, EMPTY, is a boolean: true if this is 33015 a placeholder label for an omitted FDE. 33016 33017 The default is that FDEs are not given nonlocal labels. 33018 33019 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL (FILE *STREAM) 33020 This target hook emits a label at the beginning of the exception 33021 table. It should be defined on targets where it is desirable for 33022 the table to be broken up according to function. 33023 33024 The default is that no label is emitted. 33025 33026 -- Target Hook: void TARGET_UNWIND_EMIT (FILE *STREAM, rtx INSN) 33027 This target hook emits assembly directives required to unwind the 33028 given instruction. This is only used when TARGET_UNWIND_INFO is 33029 set. 33030 33031 33032File: gccint.info, Node: Exception Region Output, Next: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format 33033 3303417.21.9 Assembler Commands for Exception Regions 33035------------------------------------------------ 33036 33037This describes commands marking the start and the end of an exception 33038region. 33039 33040 -- Macro: EH_FRAME_SECTION_NAME 33041 If defined, a C string constant for the name of the section 33042 containing exception handling frame unwind information. If not 33043 defined, GCC will provide a default definition if the target 33044 supports named sections. `crtstuff.c' uses this macro to switch 33045 to the appropriate section. 33046 33047 You should define this symbol if your target supports DWARF 2 frame 33048 unwind information and the default definition does not work. 33049 33050 -- Macro: EH_FRAME_IN_DATA_SECTION 33051 If defined, DWARF 2 frame unwind information will be placed in the 33052 data section even though the target supports named sections. This 33053 might be necessary, for instance, if the system linker does garbage 33054 collection and sections cannot be marked as not to be collected. 33055 33056 Do not define this macro unless `TARGET_ASM_NAMED_SECTION' is also 33057 defined. 33058 33059 -- Macro: EH_TABLES_CAN_BE_READ_ONLY 33060 Define this macro to 1 if your target is such that no frame unwind 33061 information encoding used with non-PIC code will ever require a 33062 runtime relocation, but the linker may not support merging 33063 read-only and read-write sections into a single read-write section. 33064 33065 -- Macro: MASK_RETURN_ADDR 33066 An rtx used to mask the return address found via 33067 `RETURN_ADDR_RTX', so that it does not contain any extraneous set 33068 bits in it. 33069 33070 -- Macro: DWARF2_UNWIND_INFO 33071 Define this macro to 0 if your target supports DWARF 2 frame unwind 33072 information, but it does not yet work with exception handling. 33073 Otherwise, if your target supports this information (if it defines 33074 `INCOMING_RETURN_ADDR_RTX' and either `UNALIGNED_INT_ASM_OP' or 33075 `OBJECT_FORMAT_ELF'), GCC will provide a default definition of 1. 33076 33077 If `TARGET_UNWIND_INFO' is defined, the target specific unwinder 33078 will be used in all cases. Defining this macro will enable the 33079 generation of DWARF 2 frame debugging information. 33080 33081 If `TARGET_UNWIND_INFO' is not defined, and this macro is defined 33082 to 1, the DWARF 2 unwinder will be the default exception handling 33083 mechanism; otherwise, the `setjmp'/`longjmp'-based scheme will be 33084 used by default. 33085 33086 -- Macro: TARGET_UNWIND_INFO 33087 Define this macro if your target has ABI specified unwind tables. 33088 Usually these will be output by `TARGET_UNWIND_EMIT'. 33089 33090 -- Target Hook: bool TARGET_UNWIND_TABLES_DEFAULT 33091 This variable should be set to `true' if the target ABI requires 33092 unwinding tables even when exceptions are not used. 33093 33094 -- Macro: MUST_USE_SJLJ_EXCEPTIONS 33095 This macro need only be defined if `DWARF2_UNWIND_INFO' is 33096 runtime-variable. In that case, `except.h' cannot correctly 33097 determine the corresponding definition of 33098 `MUST_USE_SJLJ_EXCEPTIONS', so the target must provide it directly. 33099 33100 -- Macro: DONT_USE_BUILTIN_SETJMP 33101 Define this macro to 1 if the `setjmp'/`longjmp'-based scheme 33102 should use the `setjmp'/`longjmp' functions from the C library 33103 instead of the `__builtin_setjmp'/`__builtin_longjmp' machinery. 33104 33105 -- Macro: DWARF_CIE_DATA_ALIGNMENT 33106 This macro need only be defined if the target might save registers 33107 in the function prologue at an offset to the stack pointer that is 33108 not aligned to `UNITS_PER_WORD'. The definition should be the 33109 negative minimum alignment if `STACK_GROWS_DOWNWARD' is defined, 33110 and the positive minimum alignment otherwise. *Note SDB and 33111 DWARF::. Only applicable if the target supports DWARF 2 frame 33112 unwind information. 33113 33114 -- Target Hook: bool TARGET_TERMINATE_DW2_EH_FRAME_INFO 33115 Contains the value true if the target should add a zero word onto 33116 the end of a Dwarf-2 frame info section when used for exception 33117 handling. Default value is false if `EH_FRAME_SECTION_NAME' is 33118 defined, and true otherwise. 33119 33120 -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG) 33121 Given a register, this hook should return a parallel of registers 33122 to represent where to find the register pieces. Define this hook 33123 if the register and its mode are represented in Dwarf in 33124 non-contiguous locations, or if the register should be represented 33125 in more than one register in Dwarf. Otherwise, this hook should 33126 return `NULL_RTX'. If not defined, the default is to return 33127 `NULL_RTX'. 33128 33129 -- Target Hook: void TARGET_INIT_DWARF_REG_SIZES_EXTRA (tree ADDRESS) 33130 If some registers are represented in Dwarf-2 unwind information in 33131 multiple pieces, define this hook to fill in information about the 33132 sizes of those pieces in the table used by the unwinder at runtime. 33133 It will be called by `expand_builtin_init_dwarf_reg_sizes' after 33134 filling in a single size corresponding to each hard register; 33135 ADDRESS is the address of the table. 33136 33137 -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM) 33138 This hook is used to output a reference from a frame unwinding 33139 table to the type_info object identified by SYM. It should return 33140 `true' if the reference was output. Returning `false' will cause 33141 the reference to be output using the normal Dwarf2 routines. 33142 33143 -- Target Hook: bool TARGET_ARM_EABI_UNWINDER 33144 This flag should be set to `true' on targets that use an ARM EABI 33145 based unwinding library, and `false' on other targets. This 33146 effects the format of unwinding tables, and how the unwinder in 33147 entered after running a cleanup. The default is `false'. 33148 33149 33150File: gccint.info, Node: Alignment Output, Prev: Exception Region Output, Up: Assembler Format 33151 3315217.21.10 Assembler Commands for Alignment 33153----------------------------------------- 33154 33155This describes commands for alignment. 33156 33157 -- Macro: JUMP_ALIGN (LABEL) 33158 The alignment (log base 2) to put in front of LABEL, which is a 33159 common destination of jumps and has no fallthru incoming edge. 33160 33161 This macro need not be defined if you don't want any special 33162 alignment to be done at such a time. Most machine descriptions do 33163 not currently define the macro. 33164 33165 Unless it's necessary to inspect the LABEL parameter, it is better 33166 to set the variable ALIGN_JUMPS in the target's 33167 `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's 33168 selection in ALIGN_JUMPS in a `JUMP_ALIGN' implementation. 33169 33170 -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL) 33171 The alignment (log base 2) to put in front of LABEL, which follows 33172 a `BARRIER'. 33173 33174 This macro need not be defined if you don't want any special 33175 alignment to be done at such a time. Most machine descriptions do 33176 not currently define the macro. 33177 33178 -- Macro: LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP 33179 The maximum number of bytes to skip when applying 33180 `LABEL_ALIGN_AFTER_BARRIER'. This works only if 33181 `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 33182 33183 -- Macro: LOOP_ALIGN (LABEL) 33184 The alignment (log base 2) to put in front of LABEL, which follows 33185 a `NOTE_INSN_LOOP_BEG' note. 33186 33187 This macro need not be defined if you don't want any special 33188 alignment to be done at such a time. Most machine descriptions do 33189 not currently define the macro. 33190 33191 Unless it's necessary to inspect the LABEL parameter, it is better 33192 to set the variable `align_loops' in the target's 33193 `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's 33194 selection in `align_loops' in a `LOOP_ALIGN' implementation. 33195 33196 -- Macro: LOOP_ALIGN_MAX_SKIP 33197 The maximum number of bytes to skip when applying `LOOP_ALIGN'. 33198 This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 33199 33200 -- Macro: LABEL_ALIGN (LABEL) 33201 The alignment (log base 2) to put in front of LABEL. If 33202 `LABEL_ALIGN_AFTER_BARRIER' / `LOOP_ALIGN' specify a different 33203 alignment, the maximum of the specified values is used. 33204 33205 Unless it's necessary to inspect the LABEL parameter, it is better 33206 to set the variable `align_labels' in the target's 33207 `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's 33208 selection in `align_labels' in a `LABEL_ALIGN' implementation. 33209 33210 -- Macro: LABEL_ALIGN_MAX_SKIP 33211 The maximum number of bytes to skip when applying `LABEL_ALIGN'. 33212 This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 33213 33214 -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES) 33215 A C statement to output to the stdio stream STREAM an assembler 33216 instruction to advance the location counter by NBYTES bytes. 33217 Those bytes should be zero when loaded. NBYTES will be a C 33218 expression of type `unsigned HOST_WIDE_INT'. 33219 33220 -- Macro: ASM_NO_SKIP_IN_TEXT 33221 Define this macro if `ASM_OUTPUT_SKIP' should not be used in the 33222 text section because it fails to put zeros in the bytes that are 33223 skipped. This is true on many Unix systems, where the pseudo-op 33224 to skip bytes produces no-op instructions rather than zeros when 33225 used in the text section. 33226 33227 -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER) 33228 A C statement to output to the stdio stream STREAM an assembler 33229 command to advance the location counter to a multiple of 2 to the 33230 POWER bytes. POWER will be a C expression of type `int'. 33231 33232 -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER) 33233 Like `ASM_OUTPUT_ALIGN', except that the "nop" instruction is used 33234 for padding, if necessary. 33235 33236 -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP) 33237 A C statement to output to the stdio stream STREAM an assembler 33238 command to advance the location counter to a multiple of 2 to the 33239 POWER bytes, but only if MAX_SKIP or fewer bytes are needed to 33240 satisfy the alignment request. POWER and MAX_SKIP will be a C 33241 expression of type `int'. 33242 33243 33244File: gccint.info, Node: Debugging Info, Next: Floating Point, Prev: Assembler Format, Up: Target Macros 33245 3324617.22 Controlling Debugging Information Format 33247============================================== 33248 33249This describes how to specify debugging information. 33250 33251* Menu: 33252 33253* All Debuggers:: Macros that affect all debugging formats uniformly. 33254* DBX Options:: Macros enabling specific options in DBX format. 33255* DBX Hooks:: Hook macros for varying DBX format. 33256* File Names and DBX:: Macros controlling output of file names in DBX format. 33257* SDB and DWARF:: Macros for SDB (COFF) and DWARF formats. 33258* VMS Debug:: Macros for VMS debug format. 33259 33260 33261File: gccint.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info 33262 3326317.22.1 Macros Affecting All Debugging Formats 33264---------------------------------------------- 33265 33266These macros affect all debugging formats. 33267 33268 -- Macro: DBX_REGISTER_NUMBER (REGNO) 33269 A C expression that returns the DBX register number for the 33270 compiler register number REGNO. In the default macro provided, 33271 the value of this expression will be REGNO itself. But sometimes 33272 there are some registers that the compiler knows about and DBX 33273 does not, or vice versa. In such cases, some register may need to 33274 have one number in the compiler and another for DBX. 33275 33276 If two registers have consecutive numbers inside GCC, and they can 33277 be used as a pair to hold a multiword value, then they _must_ have 33278 consecutive numbers after renumbering with `DBX_REGISTER_NUMBER'. 33279 Otherwise, debuggers will be unable to access such a pair, because 33280 they expect register pairs to be consecutive in their own 33281 numbering scheme. 33282 33283 If you find yourself defining `DBX_REGISTER_NUMBER' in way that 33284 does not preserve register pairs, then what you must do instead is 33285 redefine the actual register numbering scheme. 33286 33287 -- Macro: DEBUGGER_AUTO_OFFSET (X) 33288 A C expression that returns the integer offset value for an 33289 automatic variable having address X (an RTL expression). The 33290 default computation assumes that X is based on the frame-pointer 33291 and gives the offset from the frame-pointer. This is required for 33292 targets that produce debugging output for DBX or COFF-style 33293 debugging output for SDB and allow the frame-pointer to be 33294 eliminated when the `-g' options is used. 33295 33296 -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X) 33297 A C expression that returns the integer offset value for an 33298 argument having address X (an RTL expression). The nominal offset 33299 is OFFSET. 33300 33301 -- Macro: PREFERRED_DEBUGGING_TYPE 33302 A C expression that returns the type of debugging output GCC should 33303 produce when the user specifies just `-g'. Define this if you 33304 have arranged for GCC to support more than one format of debugging 33305 output. Currently, the allowable values are `DBX_DEBUG', 33306 `SDB_DEBUG', `DWARF_DEBUG', `DWARF2_DEBUG', `XCOFF_DEBUG', 33307 `VMS_DEBUG', and `VMS_AND_DWARF2_DEBUG'. 33308 33309 When the user specifies `-ggdb', GCC normally also uses the value 33310 of this macro to select the debugging output format, but with two 33311 exceptions. If `DWARF2_DEBUGGING_INFO' is defined, GCC uses the 33312 value `DWARF2_DEBUG'. Otherwise, if `DBX_DEBUGGING_INFO' is 33313 defined, GCC uses `DBX_DEBUG'. 33314 33315 The value of this macro only affects the default debugging output; 33316 the user can always get a specific type of output by using 33317 `-gstabs', `-gcoff', `-gdwarf-2', `-gxcoff', or `-gvms'. 33318 33319 33320File: gccint.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info 33321 3332217.22.2 Specific Options for DBX Output 33323--------------------------------------- 33324 33325These are specific options for DBX output. 33326 33327 -- Macro: DBX_DEBUGGING_INFO 33328 Define this macro if GCC should produce debugging output for DBX 33329 in response to the `-g' option. 33330 33331 -- Macro: XCOFF_DEBUGGING_INFO 33332 Define this macro if GCC should produce XCOFF format debugging 33333 output in response to the `-g' option. This is a variant of DBX 33334 format. 33335 33336 -- Macro: DEFAULT_GDB_EXTENSIONS 33337 Define this macro to control whether GCC should by default generate 33338 GDB's extended version of DBX debugging information (assuming 33339 DBX-format debugging information is enabled at all). If you don't 33340 define the macro, the default is 1: always generate the extended 33341 information if there is any occasion to. 33342 33343 -- Macro: DEBUG_SYMS_TEXT 33344 Define this macro if all `.stabs' commands should be output while 33345 in the text section. 33346 33347 -- Macro: ASM_STABS_OP 33348 A C string constant, including spacing, naming the assembler 33349 pseudo op to use instead of `"\t.stabs\t"' to define an ordinary 33350 debugging symbol. If you don't define this macro, `"\t.stabs\t"' 33351 is used. This macro applies only to DBX debugging information 33352 format. 33353 33354 -- Macro: ASM_STABD_OP 33355 A C string constant, including spacing, naming the assembler 33356 pseudo op to use instead of `"\t.stabd\t"' to define a debugging 33357 symbol whose value is the current location. If you don't define 33358 this macro, `"\t.stabd\t"' is used. This macro applies only to 33359 DBX debugging information format. 33360 33361 -- Macro: ASM_STABN_OP 33362 A C string constant, including spacing, naming the assembler 33363 pseudo op to use instead of `"\t.stabn\t"' to define a debugging 33364 symbol with no name. If you don't define this macro, 33365 `"\t.stabn\t"' is used. This macro applies only to DBX debugging 33366 information format. 33367 33368 -- Macro: DBX_NO_XREFS 33369 Define this macro if DBX on your system does not support the 33370 construct `xsTAGNAME'. On some systems, this construct is used to 33371 describe a forward reference to a structure named TAGNAME. On 33372 other systems, this construct is not supported at all. 33373 33374 -- Macro: DBX_CONTIN_LENGTH 33375 A symbol name in DBX-format debugging information is normally 33376 continued (split into two separate `.stabs' directives) when it 33377 exceeds a certain length (by default, 80 characters). On some 33378 operating systems, DBX requires this splitting; on others, 33379 splitting must not be done. You can inhibit splitting by defining 33380 this macro with the value zero. You can override the default 33381 splitting-length by defining this macro as an expression for the 33382 length you desire. 33383 33384 -- Macro: DBX_CONTIN_CHAR 33385 Normally continuation is indicated by adding a `\' character to 33386 the end of a `.stabs' string when a continuation follows. To use 33387 a different character instead, define this macro as a character 33388 constant for the character you want to use. Do not define this 33389 macro if backslash is correct for your system. 33390 33391 -- Macro: DBX_STATIC_STAB_DATA_SECTION 33392 Define this macro if it is necessary to go to the data section 33393 before outputting the `.stabs' pseudo-op for a non-global static 33394 variable. 33395 33396 -- Macro: DBX_TYPE_DECL_STABS_CODE 33397 The value to use in the "code" field of the `.stabs' directive for 33398 a typedef. The default is `N_LSYM'. 33399 33400 -- Macro: DBX_STATIC_CONST_VAR_CODE 33401 The value to use in the "code" field of the `.stabs' directive for 33402 a static variable located in the text section. DBX format does not 33403 provide any "right" way to do this. The default is `N_FUN'. 33404 33405 -- Macro: DBX_REGPARM_STABS_CODE 33406 The value to use in the "code" field of the `.stabs' directive for 33407 a parameter passed in registers. DBX format does not provide any 33408 "right" way to do this. The default is `N_RSYM'. 33409 33410 -- Macro: DBX_REGPARM_STABS_LETTER 33411 The letter to use in DBX symbol data to identify a symbol as a 33412 parameter passed in registers. DBX format does not customarily 33413 provide any way to do this. The default is `'P''. 33414 33415 -- Macro: DBX_FUNCTION_FIRST 33416 Define this macro if the DBX information for a function and its 33417 arguments should precede the assembler code for the function. 33418 Normally, in DBX format, the debugging information entirely 33419 follows the assembler code. 33420 33421 -- Macro: DBX_BLOCKS_FUNCTION_RELATIVE 33422 Define this macro, with value 1, if the value of a symbol 33423 describing the scope of a block (`N_LBRAC' or `N_RBRAC') should be 33424 relative to the start of the enclosing function. Normally, GCC 33425 uses an absolute address. 33426 33427 -- Macro: DBX_LINES_FUNCTION_RELATIVE 33428 Define this macro, with value 1, if the value of a symbol 33429 indicating the current line number (`N_SLINE') should be relative 33430 to the start of the enclosing function. Normally, GCC uses an 33431 absolute address. 33432 33433 -- Macro: DBX_USE_BINCL 33434 Define this macro if GCC should generate `N_BINCL' and `N_EINCL' 33435 stabs for included header files, as on Sun systems. This macro 33436 also directs GCC to output a type number as a pair of a file 33437 number and a type number within the file. Normally, GCC does not 33438 generate `N_BINCL' or `N_EINCL' stabs, and it outputs a single 33439 number for a type number. 33440 33441 33442File: gccint.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info 33443 3344417.22.3 Open-Ended Hooks for DBX Format 33445--------------------------------------- 33446 33447These are hooks for DBX format. 33448 33449 -- Macro: DBX_OUTPUT_LBRAC (STREAM, NAME) 33450 Define this macro to say how to output to STREAM the debugging 33451 information for the start of a scope level for variable names. The 33452 argument NAME is the name of an assembler symbol (for use with 33453 `assemble_name') whose value is the address where the scope begins. 33454 33455 -- Macro: DBX_OUTPUT_RBRAC (STREAM, NAME) 33456 Like `DBX_OUTPUT_LBRAC', but for the end of a scope level. 33457 33458 -- Macro: DBX_OUTPUT_NFUN (STREAM, LSCOPE_LABEL, DECL) 33459 Define this macro if the target machine requires special handling 33460 to output an `N_FUN' entry for the function DECL. 33461 33462 -- Macro: DBX_OUTPUT_SOURCE_LINE (STREAM, LINE, COUNTER) 33463 A C statement to output DBX debugging information before code for 33464 line number LINE of the current source file to the stdio stream 33465 STREAM. COUNTER is the number of time the macro was invoked, 33466 including the current invocation; it is intended to generate 33467 unique labels in the assembly output. 33468 33469 This macro should not be defined if the default output is correct, 33470 or if it can be made correct by defining 33471 `DBX_LINES_FUNCTION_RELATIVE'. 33472 33473 -- Macro: NO_DBX_FUNCTION_END 33474 Some stabs encapsulation formats (in particular ECOFF), cannot 33475 handle the `.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx 33476 extension construct. On those machines, define this macro to turn 33477 this feature off without disturbing the rest of the gdb extensions. 33478 33479 -- Macro: NO_DBX_BNSYM_ENSYM 33480 Some assemblers cannot handle the `.stabd BNSYM/ENSYM,0,0' gdb dbx 33481 extension construct. On those machines, define this macro to turn 33482 this feature off without disturbing the rest of the gdb extensions. 33483 33484 33485File: gccint.info, Node: File Names and DBX, Next: SDB and DWARF, Prev: DBX Hooks, Up: Debugging Info 33486 3348717.22.4 File Names in DBX Format 33488-------------------------------- 33489 33490This describes file names in DBX format. 33491 33492 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME) 33493 A C statement to output DBX debugging information to the stdio 33494 stream STREAM, which indicates that file NAME is the main source 33495 file--the file specified as the input file for compilation. This 33496 macro is called only once, at the beginning of compilation. 33497 33498 This macro need not be defined if the standard form of output for 33499 DBX debugging information is appropriate. 33500 33501 It may be necessary to refer to a label equal to the beginning of 33502 the text section. You can use `assemble_name (stream, 33503 ltext_label_name)' to do so. If you do this, you must also set 33504 the variable USED_LTEXT_LABEL_NAME to `true'. 33505 33506 -- Macro: NO_DBX_MAIN_SOURCE_DIRECTORY 33507 Define this macro, with value 1, if GCC should not emit an 33508 indication of the current directory for compilation and current 33509 source language at the beginning of the file. 33510 33511 -- Macro: NO_DBX_GCC_MARKER 33512 Define this macro, with value 1, if GCC should not emit an 33513 indication that this object file was compiled by GCC. The default 33514 is to emit an `N_OPT' stab at the beginning of every source file, 33515 with `gcc2_compiled.' for the string and value 0. 33516 33517 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME) 33518 A C statement to output DBX debugging information at the end of 33519 compilation of the main source file NAME. Output should be 33520 written to the stdio stream STREAM. 33521 33522 If you don't define this macro, nothing special is output at the 33523 end of compilation, which is correct for most machines. 33524 33525 -- Macro: DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END 33526 Define this macro _instead of_ defining 33527 `DBX_OUTPUT_MAIN_SOURCE_FILE_END', if what needs to be output at 33528 the end of compilation is an `N_SO' stab with an empty string, 33529 whose value is the highest absolute text address in the file. 33530 33531 33532File: gccint.info, Node: SDB and DWARF, Next: VMS Debug, Prev: File Names and DBX, Up: Debugging Info 33533 3353417.22.5 Macros for SDB and DWARF Output 33535--------------------------------------- 33536 33537Here are macros for SDB and DWARF output. 33538 33539 -- Macro: SDB_DEBUGGING_INFO 33540 Define this macro if GCC should produce COFF-style debugging output 33541 for SDB in response to the `-g' option. 33542 33543 -- Macro: DWARF2_DEBUGGING_INFO 33544 Define this macro if GCC should produce dwarf version 2 format 33545 debugging output in response to the `-g' option. 33546 33547 -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (const_tree 33548 FUNCTION) 33549 Define this to enable the dwarf attribute 33550 `DW_AT_calling_convention' to be emitted for each function. 33551 Instead of an integer return the enum value for the `DW_CC_' 33552 tag. 33553 33554 To support optional call frame debugging information, you must also 33555 define `INCOMING_RETURN_ADDR_RTX' and either set 33556 `RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the 33557 prologue, or call `dwarf2out_def_cfa' and `dwarf2out_reg_save' as 33558 appropriate from `TARGET_ASM_FUNCTION_PROLOGUE' if you don't. 33559 33560 -- Macro: DWARF2_FRAME_INFO 33561 Define this macro to a nonzero value if GCC should always output 33562 Dwarf 2 frame information. If `DWARF2_UNWIND_INFO' (*note 33563 Exception Region Output:: is nonzero, GCC will output this 33564 information not matter how you define `DWARF2_FRAME_INFO'. 33565 33566 -- Macro: DWARF2_ASM_LINE_DEBUG_INFO 33567 Define this macro to be a nonzero value if the assembler can 33568 generate Dwarf 2 line debug info sections. This will result in 33569 much more compact line number tables, and hence is desirable if it 33570 works. 33571 33572 -- Macro: ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2) 33573 A C statement to issue assembly directives that create a difference 33574 LAB1 minus LAB2, using an integer of the given SIZE. 33575 33576 -- Macro: ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL, SECTION) 33577 A C statement to issue assembly directives that create a 33578 section-relative reference to the given LABEL, using an integer of 33579 the given SIZE. The label is known to be defined in the given 33580 SECTION. 33581 33582 -- Macro: ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL) 33583 A C statement to issue assembly directives that create a 33584 self-relative reference to the given LABEL, using an integer of 33585 the given SIZE. 33586 33587 -- Macro: ASM_OUTPUT_DWARF_TABLE_REF (LABEL) 33588 A C statement to issue assembly directives that create a reference 33589 to the DWARF table identifier LABEL from the current section. This 33590 is used on some systems to avoid garbage collecting a DWARF table 33591 which is referenced by a function. 33592 33593 -- Target Hook: void TARGET_ASM_OUTPUT_DWARF_DTPREL (FILE *FILE, int 33594 SIZE, rtx X) 33595 If defined, this target hook is a function which outputs a 33596 DTP-relative reference to the given TLS symbol of the specified 33597 size. 33598 33599 -- Macro: PUT_SDB_... 33600 Define these macros to override the assembler syntax for the 33601 special SDB assembler directives. See `sdbout.c' for a list of 33602 these macros and their arguments. If the standard syntax is used, 33603 you need not define them yourself. 33604 33605 -- Macro: SDB_DELIM 33606 Some assemblers do not support a semicolon as a delimiter, even 33607 between SDB assembler directives. In that case, define this macro 33608 to be the delimiter to use (usually `\n'). It is not necessary to 33609 define a new set of `PUT_SDB_OP' macros if this is the only change 33610 required. 33611 33612 -- Macro: SDB_ALLOW_UNKNOWN_REFERENCES 33613 Define this macro to allow references to unknown structure, union, 33614 or enumeration tags to be emitted. Standard COFF does not allow 33615 handling of unknown references, MIPS ECOFF has support for it. 33616 33617 -- Macro: SDB_ALLOW_FORWARD_REFERENCES 33618 Define this macro to allow references to structure, union, or 33619 enumeration tags that have not yet been seen to be handled. Some 33620 assemblers choke if forward tags are used, while some require it. 33621 33622 -- Macro: SDB_OUTPUT_SOURCE_LINE (STREAM, LINE) 33623 A C statement to output SDB debugging information before code for 33624 line number LINE of the current source file to the stdio stream 33625 STREAM. The default is to emit an `.ln' directive. 33626 33627 33628File: gccint.info, Node: VMS Debug, Prev: SDB and DWARF, Up: Debugging Info 33629 3363017.22.6 Macros for VMS Debug Format 33631----------------------------------- 33632 33633Here are macros for VMS debug format. 33634 33635 -- Macro: VMS_DEBUGGING_INFO 33636 Define this macro if GCC should produce debugging output for VMS 33637 in response to the `-g' option. The default behavior for VMS is 33638 to generate minimal debug info for a traceback in the absence of 33639 `-g' unless explicitly overridden with `-g0'. This behavior is 33640 controlled by `OPTIMIZATION_OPTIONS' and `OVERRIDE_OPTIONS'. 33641 33642 33643File: gccint.info, Node: Floating Point, Next: Mode Switching, Prev: Debugging Info, Up: Target Macros 33644 3364517.23 Cross Compilation and Floating Point 33646========================================== 33647 33648While all modern machines use twos-complement representation for 33649integers, there are a variety of representations for floating point 33650numbers. This means that in a cross-compiler the representation of 33651floating point numbers in the compiled program may be different from 33652that used in the machine doing the compilation. 33653 33654 Because different representation systems may offer different amounts of 33655range and precision, all floating point constants must be represented in 33656the target machine's format. Therefore, the cross compiler cannot 33657safely use the host machine's floating point arithmetic; it must emulate 33658the target's arithmetic. To ensure consistency, GCC always uses 33659emulation to work with floating point values, even when the host and 33660target floating point formats are identical. 33661 33662 The following macros are provided by `real.h' for the compiler to use. 33663All parts of the compiler which generate or optimize floating-point 33664calculations must use these macros. They may evaluate their operands 33665more than once, so operands must not have side effects. 33666 33667 -- Macro: REAL_VALUE_TYPE 33668 The C data type to be used to hold a floating point value in the 33669 target machine's format. Typically this is a `struct' containing 33670 an array of `HOST_WIDE_INT', but all code should treat it as an 33671 opaque quantity. 33672 33673 -- Macro: int REAL_VALUES_EQUAL (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 33674 Compares for equality the two values, X and Y. If the target 33675 floating point format supports negative zeroes and/or NaNs, 33676 `REAL_VALUES_EQUAL (-0.0, 0.0)' is true, and `REAL_VALUES_EQUAL 33677 (NaN, NaN)' is false. 33678 33679 -- Macro: int REAL_VALUES_LESS (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 33680 Tests whether X is less than Y. 33681 33682 -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X) 33683 Truncates X to a signed integer, rounding toward zero. 33684 33685 -- Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX 33686 (REAL_VALUE_TYPE X) 33687 Truncates X to an unsigned integer, rounding toward zero. If X is 33688 negative, returns zero. 33689 33690 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, enum 33691 machine_mode MODE) 33692 Converts STRING into a floating point number in the target 33693 machine's representation for mode MODE. This routine can handle 33694 both decimal and hexadecimal floating point constants, using the 33695 syntax defined by the C language for both. 33696 33697 -- Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X) 33698 Returns 1 if X is negative (including negative zero), 0 otherwise. 33699 33700 -- Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X) 33701 Determines whether X represents infinity (positive or negative). 33702 33703 -- Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X) 33704 Determines whether X represents a "NaN" (not-a-number). 33705 33706 -- Macro: void REAL_ARITHMETIC (REAL_VALUE_TYPE OUTPUT, enum tree_code 33707 CODE, REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 33708 Calculates an arithmetic operation on the two floating point values 33709 X and Y, storing the result in OUTPUT (which must be a variable). 33710 33711 The operation to be performed is specified by CODE. Only the 33712 following codes are supported: `PLUS_EXPR', `MINUS_EXPR', 33713 `MULT_EXPR', `RDIV_EXPR', `MAX_EXPR', `MIN_EXPR'. 33714 33715 If `REAL_ARITHMETIC' is asked to evaluate division by zero and the 33716 target's floating point format cannot represent infinity, it will 33717 call `abort'. Callers should check for this situation first, using 33718 `MODE_HAS_INFINITIES'. *Note Storage Layout::. 33719 33720 -- Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X) 33721 Returns the negative of the floating point value X. 33722 33723 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X) 33724 Returns the absolute value of X. 33725 33726 -- Macro: REAL_VALUE_TYPE REAL_VALUE_TRUNCATE (REAL_VALUE_TYPE MODE, 33727 enum machine_mode X) 33728 Truncates the floating point value X to fit in MODE. The return 33729 value is still a full-size `REAL_VALUE_TYPE', but it has an 33730 appropriate bit pattern to be output as a floating constant whose 33731 precision accords with mode MODE. 33732 33733 -- Macro: void REAL_VALUE_TO_INT (HOST_WIDE_INT LOW, HOST_WIDE_INT 33734 HIGH, REAL_VALUE_TYPE X) 33735 Converts a floating point value X into a double-precision integer 33736 which is then stored into LOW and HIGH. If the value is not 33737 integral, it is truncated. 33738 33739 -- Macro: void REAL_VALUE_FROM_INT (REAL_VALUE_TYPE X, HOST_WIDE_INT 33740 LOW, HOST_WIDE_INT HIGH, enum machine_mode MODE) 33741 Converts a double-precision integer found in LOW and HIGH, into a 33742 floating point value which is then stored into X. The value is 33743 truncated to fit in mode MODE. 33744 33745 33746File: gccint.info, Node: Mode Switching, Next: Target Attributes, Prev: Floating Point, Up: Target Macros 33747 3374817.24 Mode Switching Instructions 33749================================= 33750 33751The following macros control mode switching optimizations: 33752 33753 -- Macro: OPTIMIZE_MODE_SWITCHING (ENTITY) 33754 Define this macro if the port needs extra instructions inserted 33755 for mode switching in an optimizing compilation. 33756 33757 For an example, the SH4 can perform both single and double 33758 precision floating point operations, but to perform a single 33759 precision operation, the FPSCR PR bit has to be cleared, while for 33760 a double precision operation, this bit has to be set. Changing 33761 the PR bit requires a general purpose register as a scratch 33762 register, hence these FPSCR sets have to be inserted before 33763 reload, i.e. you can't put this into instruction emitting or 33764 `TARGET_MACHINE_DEPENDENT_REORG'. 33765 33766 You can have multiple entities that are mode-switched, and select 33767 at run time which entities actually need it. 33768 `OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY 33769 that needs mode-switching. If you define this macro, you also 33770 have to define `NUM_MODES_FOR_MODE_SWITCHING', `MODE_NEEDED', 33771 `MODE_PRIORITY_TO_MODE' and `EMIT_MODE_SET'. `MODE_AFTER', 33772 `MODE_ENTRY', and `MODE_EXIT' are optional. 33773 33774 -- Macro: NUM_MODES_FOR_MODE_SWITCHING 33775 If you define `OPTIMIZE_MODE_SWITCHING', you have to define this as 33776 initializer for an array of integers. Each initializer element N 33777 refers to an entity that needs mode switching, and specifies the 33778 number of different modes that might need to be set for this 33779 entity. The position of the initializer in the 33780 initializer--starting counting at zero--determines the integer 33781 that is used to refer to the mode-switched entity in question. In 33782 macros that take mode arguments / yield a mode result, modes are 33783 represented as numbers 0 ... N - 1. N is used to specify that no 33784 mode switch is needed / supplied. 33785 33786 -- Macro: MODE_NEEDED (ENTITY, INSN) 33787 ENTITY is an integer specifying a mode-switched entity. If 33788 `OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro to 33789 return an integer value not larger than the corresponding element 33790 in `NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that ENTITY 33791 must be switched into prior to the execution of INSN. 33792 33793 -- Macro: MODE_AFTER (MODE, INSN) 33794 If this macro is defined, it is evaluated for every INSN during 33795 mode switching. It determines the mode that an insn results in (if 33796 different from the incoming mode). 33797 33798 -- Macro: MODE_ENTRY (ENTITY) 33799 If this macro is defined, it is evaluated for every ENTITY that 33800 needs mode switching. It should evaluate to an integer, which is 33801 a mode that ENTITY is assumed to be switched to at function entry. 33802 If `MODE_ENTRY' is defined then `MODE_EXIT' must be defined. 33803 33804 -- Macro: MODE_EXIT (ENTITY) 33805 If this macro is defined, it is evaluated for every ENTITY that 33806 needs mode switching. It should evaluate to an integer, which is 33807 a mode that ENTITY is assumed to be switched to at function exit. 33808 If `MODE_EXIT' is defined then `MODE_ENTRY' must be defined. 33809 33810 -- Macro: MODE_PRIORITY_TO_MODE (ENTITY, N) 33811 This macro specifies the order in which modes for ENTITY are 33812 processed. 0 is the highest priority, 33813 `NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest. The value 33814 of the macro should be an integer designating a mode for ENTITY. 33815 For any fixed ENTITY, `mode_priority_to_mode' (ENTITY, N) shall be 33816 a bijection in 0 ... `num_modes_for_mode_switching[ENTITY] - 1'. 33817 33818 -- Macro: EMIT_MODE_SET (ENTITY, MODE, HARD_REGS_LIVE) 33819 Generate one or more insns to set ENTITY to MODE. HARD_REG_LIVE 33820 is the set of hard registers live at the point where the insn(s) 33821 are to be inserted. 33822 33823 33824File: gccint.info, Node: Target Attributes, Next: Emulated TLS, Prev: Mode Switching, Up: Target Macros 33825 3382617.25 Defining target-specific uses of `__attribute__' 33827====================================================== 33828 33829Target-specific attributes may be defined for functions, data and types. 33830These are described using the following target hooks; they also need to 33831be documented in `extend.texi'. 33832 33833 -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE 33834 If defined, this target hook points to an array of `struct 33835 attribute_spec' (defined in `tree.h') specifying the machine 33836 specific attributes for this target and some of the restrictions 33837 on the entities to which these attributes are applied and the 33838 arguments they take. 33839 33840 -- Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (const_tree TYPE1, 33841 const_tree TYPE2) 33842 If defined, this target hook is a function which returns zero if 33843 the attributes on TYPE1 and TYPE2 are incompatible, one if they 33844 are compatible, and two if they are nearly compatible (which 33845 causes a warning to be generated). If this is not defined, 33846 machine-specific attributes are supposed always to be compatible. 33847 33848 -- Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE) 33849 If defined, this target hook is a function which assigns default 33850 attributes to the newly defined TYPE. 33851 33852 -- Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree 33853 TYPE2) 33854 Define this target hook if the merging of type attributes needs 33855 special handling. If defined, the result is a list of the combined 33856 `TYPE_ATTRIBUTES' of TYPE1 and TYPE2. It is assumed that 33857 `comptypes' has already been called and returned 1. This function 33858 may call `merge_attributes' to handle machine-independent merging. 33859 33860 -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree 33861 NEWDECL) 33862 Define this target hook if the merging of decl attributes needs 33863 special handling. If defined, the result is a list of the combined 33864 `DECL_ATTRIBUTES' of OLDDECL and NEWDECL. NEWDECL is a duplicate 33865 declaration of OLDDECL. Examples of when this is needed are when 33866 one attribute overrides another, or when an attribute is nullified 33867 by a subsequent definition. This function may call 33868 `merge_attributes' to handle machine-independent merging. 33869 33870 If the only target-specific handling you require is `dllimport' 33871 for Microsoft Windows targets, you should define the macro 33872 `TARGET_DLLIMPORT_DECL_ATTRIBUTES' to `1'. The compiler will then 33873 define a function called `merge_dllimport_decl_attributes' which 33874 can then be defined as the expansion of 33875 `TARGET_MERGE_DECL_ATTRIBUTES'. You can also add 33876 `handle_dll_attribute' in the attribute table for your port to 33877 perform initial processing of the `dllimport' and `dllexport' 33878 attributes. This is done in `i386/cygwin.h' and `i386/i386.c', 33879 for example. 33880 33881 -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (const_tree 33882 DECL) 33883 DECL is a variable or function with `__attribute__((dllimport))' 33884 specified. Use this hook if the target needs to add extra 33885 validation checks to `handle_dll_attribute'. 33886 33887 -- Macro: TARGET_DECLSPEC 33888 Define this macro to a nonzero value if you want to treat 33889 `__declspec(X)' as equivalent to `__attribute((X))'. By default, 33890 this behavior is enabled only for targets that define 33891 `TARGET_DLLIMPORT_DECL_ATTRIBUTES'. The current implementation of 33892 `__declspec' is via a built-in macro, but you should not rely on 33893 this implementation detail. 33894 33895 -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree 33896 *ATTR_PTR) 33897 Define this target hook if you want to be able to add attributes 33898 to a decl when it is being created. This is normally useful for 33899 back ends which wish to implement a pragma by using the attributes 33900 which correspond to the pragma's effect. The NODE argument is the 33901 decl which is being created. The ATTR_PTR argument is a pointer 33902 to the attribute list for this decl. The list itself should not 33903 be modified, since it may be shared with other decls, but 33904 attributes may be chained on the head of the list and `*ATTR_PTR' 33905 modified to point to the new attributes, or a copy of the list may 33906 be made if further changes are needed. 33907 33908 -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (const_tree 33909 FNDECL) 33910 This target hook returns `true' if it is ok to inline FNDECL into 33911 the current function, despite its having target-specific 33912 attributes, `false' otherwise. By default, if a function has a 33913 target specific attribute attached to it, it will not be inlined. 33914 33915 -- Target Hook: bool TARGET_OPTION_VALID_ATTRIBUTE_P (tree FNDECL, 33916 tree NAME, tree ARGS, int FLAGS) 33917 This hook is called to parse the `attribute(option("..."))', and 33918 it allows the function to set different target machine compile time 33919 options for the current function that might be different than the 33920 options specified on the command line. The hook should return 33921 `true' if the options are valid. 33922 33923 The hook should set the DECL_FUNCTION_SPECIFIC_TARGET field in the 33924 function declaration to hold a pointer to a target specific STRUCT 33925 CL_TARGET_OPTION structure. 33926 33927 -- Target Hook: void TARGET_OPTION_SAVE (struct cl_target_option *PTR) 33928 This hook is called to save any additional target specific 33929 information in the STRUCT CL_TARGET_OPTION structure for function 33930 specific options. *Note Option file format::. 33931 33932 -- Target Hook: void TARGET_OPTION_RESTORE (struct cl_target_option 33933 *PTR) 33934 This hook is called to restore any additional target specific 33935 information in the STRUCT CL_TARGET_OPTION structure for function 33936 specific options. 33937 33938 -- Target Hook: void TARGET_OPTION_PRINT (FILE *FILE, int INDENT, 33939 struct cl_target_option *PTR) 33940 This hook is called to print any additional target specific 33941 information in the STRUCT CL_TARGET_OPTION structure for function 33942 specific options. 33943 33944 -- Target Hook: bool TARGET_OPTION_PRAGMA_PARSE (target ARGS) 33945 This target hook parses the options for `#pragma GCC option' to 33946 set the machine specific options for functions that occur later in 33947 the input stream. The options should be the same as handled by the 33948 `TARGET_VALID_OPTION_ATTRIBUTE_P' hook. 33949 33950 -- Target Hook: bool TARGET_CAN_INLINE_P (tree CALLER, tree CALLEE) 33951 This target hook returns `false' if the CALLER function cannot 33952 inline CALLEE, based on target specific information. By default, 33953 inlining is not allowed if the callee function has function 33954 specific target options and the caller does not use the same 33955 options. 33956 33957 33958File: gccint.info, Node: Emulated TLS, Next: MIPS Coprocessors, Prev: Target Attributes, Up: Target Macros 33959 3396017.26 Emulating TLS 33961=================== 33962 33963For targets whose psABI does not provide Thread Local Storage via 33964specific relocations and instruction sequences, an emulation layer is 33965used. A set of target hooks allows this emulation layer to be 33966configured for the requirements of a particular target. For instance 33967the psABI may in fact specify TLS support in terms of an emulation 33968layer. 33969 33970 The emulation layer works by creating a control object for every TLS 33971object. To access the TLS object, a lookup function is provided which, 33972when given the address of the control object, will return the address 33973of the current thread's instance of the TLS object. 33974 33975 -- Target Hook: const char * TARGET_EMUTLS_GET_ADDRESS 33976 Contains the name of the helper function that uses a TLS control 33977 object to locate a TLS instance. The default causes libgcc's 33978 emulated TLS helper function to be used. 33979 33980 -- Target Hook: const char * TARGET_EMUTLS_REGISTER_COMMON 33981 Contains the name of the helper function that should be used at 33982 program startup to register TLS objects that are implicitly 33983 initialized to zero. If this is `NULL', all TLS objects will have 33984 explicit initializers. The default causes libgcc's emulated TLS 33985 registration function to be used. 33986 33987 -- Target Hook: const char * TARGET_EMUTLS_VAR_SECTION 33988 Contains the name of the section in which TLS control variables 33989 should be placed. The default of `NULL' allows these to be placed 33990 in any section. 33991 33992 -- Target Hook: const char * TARGET_EMUTLS_TMPL_SECTION 33993 Contains the name of the section in which TLS initializers should 33994 be placed. The default of `NULL' allows these to be placed in any 33995 section. 33996 33997 -- Target Hook: const char * TARGET_EMUTLS_VAR_PREFIX 33998 Contains the prefix to be prepended to TLS control variable names. 33999 The default of `NULL' uses a target-specific prefix. 34000 34001 -- Target Hook: const char * TARGET_EMUTLS_TMPL_PREFIX 34002 Contains the prefix to be prepended to TLS initializer objects. 34003 The default of `NULL' uses a target-specific prefix. 34004 34005 -- Target Hook: tree TARGET_EMUTLS_VAR_FIELDS (tree TYPE, tree *NAME) 34006 Specifies a function that generates the FIELD_DECLs for a TLS 34007 control object type. TYPE is the RECORD_TYPE the fields are for 34008 and NAME should be filled with the structure tag, if the default of 34009 `__emutls_object' is unsuitable. The default creates a type 34010 suitable for libgcc's emulated TLS function. 34011 34012 -- Target Hook: tree TARGET_EMUTLS_VAR_INIT (tree VAR, tree DECL, tree 34013 TMPL_ADDR) 34014 Specifies a function that generates the CONSTRUCTOR to initialize a 34015 TLS control object. VAR is the TLS control object, DECL is the 34016 TLS object and TMPL_ADDR is the address of the initializer. The 34017 default initializes libgcc's emulated TLS control object. 34018 34019 -- Target Hook: bool TARGET_EMUTLS_VAR_ALIGN_FIXED 34020 Specifies whether the alignment of TLS control variable objects is 34021 fixed and should not be increased as some backends may do to 34022 optimize single objects. The default is false. 34023 34024 -- Target Hook: bool TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS 34025 Specifies whether a DWARF `DW_OP_form_tls_address' location 34026 descriptor may be used to describe emulated TLS control objects. 34027 34028 34029File: gccint.info, Node: MIPS Coprocessors, Next: PCH Target, Prev: Emulated TLS, Up: Target Macros 34030 3403117.27 Defining coprocessor specifics for MIPS targets. 34032====================================================== 34033 34034The MIPS specification allows MIPS implementations to have as many as 4 34035coprocessors, each with as many as 32 private registers. GCC supports 34036accessing these registers and transferring values between the registers 34037and memory using asm-ized variables. For example: 34038 34039 register unsigned int cp0count asm ("c0r1"); 34040 unsigned int d; 34041 34042 d = cp0count + 3; 34043 34044 ("c0r1" is the default name of register 1 in coprocessor 0; alternate 34045names may be added as described below, or the default names may be 34046overridden entirely in `SUBTARGET_CONDITIONAL_REGISTER_USAGE'.) 34047 34048 Coprocessor registers are assumed to be epilogue-used; sets to them 34049will be preserved even if it does not appear that the register is used 34050again later in the function. 34051 34052 Another note: according to the MIPS spec, coprocessor 1 (if present) is 34053the FPU. One accesses COP1 registers through standard mips 34054floating-point support; they are not included in this mechanism. 34055 34056 There is one macro used in defining the MIPS coprocessor interface 34057which you may want to override in subtargets; it is described below. 34058 34059 -- Macro: ALL_COP_ADDITIONAL_REGISTER_NAMES 34060 A comma-separated list (with leading comma) of pairs describing the 34061 alternate names of coprocessor registers. The format of each 34062 entry should be 34063 { ALTERNATENAME, REGISTER_NUMBER} 34064 Default: empty. 34065 34066 34067File: gccint.info, Node: PCH Target, Next: C++ ABI, Prev: MIPS Coprocessors, Up: Target Macros 34068 3406917.28 Parameters for Precompiled Header Validity Checking 34070========================================================= 34071 34072 -- Target Hook: void * TARGET_GET_PCH_VALIDITY (size_t *SZ) 34073 This hook returns a pointer to the data needed by 34074 `TARGET_PCH_VALID_P' and sets `*SZ' to the size of the data in 34075 bytes. 34076 34077 -- Target Hook: const char * TARGET_PCH_VALID_P (const void *DATA, 34078 size_t SZ) 34079 This hook checks whether the options used to create a PCH file are 34080 compatible with the current settings. It returns `NULL' if so and 34081 a suitable error message if not. Error messages will be presented 34082 to the user and must be localized using `_(MSG)'. 34083 34084 DATA is the data that was returned by `TARGET_GET_PCH_VALIDITY' 34085 when the PCH file was created and SZ is the size of that data in 34086 bytes. It's safe to assume that the data was created by the same 34087 version of the compiler, so no format checking is needed. 34088 34089 The default definition of `default_pch_valid_p' should be suitable 34090 for most targets. 34091 34092 -- Target Hook: const char * TARGET_CHECK_PCH_TARGET_FLAGS (int 34093 PCH_FLAGS) 34094 If this hook is nonnull, the default implementation of 34095 `TARGET_PCH_VALID_P' will use it to check for compatible values of 34096 `target_flags'. PCH_FLAGS specifies the value that `target_flags' 34097 had when the PCH file was created. The return value is the same 34098 as for `TARGET_PCH_VALID_P'. 34099 34100 34101File: gccint.info, Node: C++ ABI, Next: Named Address Spaces, Prev: PCH Target, Up: Target Macros 34102 3410317.29 C++ ABI parameters 34104======================== 34105 34106 -- Target Hook: tree TARGET_CXX_GUARD_TYPE (void) 34107 Define this hook to override the integer type used for guard 34108 variables. These are used to implement one-time construction of 34109 static objects. The default is long_long_integer_type_node. 34110 34111 -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void) 34112 This hook determines how guard variables are used. It should 34113 return `false' (the default) if the first byte should be used. A 34114 return value of `true' indicates that only the least significant 34115 bit should be used. 34116 34117 -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE) 34118 This hook returns the size of the cookie to use when allocating an 34119 array whose elements have the indicated TYPE. Assumes that it is 34120 already known that a cookie is needed. The default is `max(sizeof 34121 (size_t), alignof(type))', as defined in section 2.7 of the 34122 IA64/Generic C++ ABI. 34123 34124 -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void) 34125 This hook should return `true' if the element size should be 34126 stored in array cookies. The default is to return `false'. 34127 34128 -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int 34129 IMPORT_EXPORT) 34130 If defined by a backend this hook allows the decision made to 34131 export class TYPE to be overruled. Upon entry IMPORT_EXPORT will 34132 contain 1 if the class is going to be exported, -1 if it is going 34133 to be imported and 0 otherwise. This function should return the 34134 modified value and perform any other actions necessary to support 34135 the backend's targeted operating system. 34136 34137 -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void) 34138 This hook should return `true' if constructors and destructors 34139 return the address of the object created/destroyed. The default 34140 is to return `false'. 34141 34142 -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void) 34143 This hook returns true if the key method for a class (i.e., the 34144 method which, if defined in the current translation unit, causes 34145 the virtual table to be emitted) may be an inline function. Under 34146 the standard Itanium C++ ABI the key method may be an inline 34147 function so long as the function is not declared inline in the 34148 class definition. Under some variants of the ABI, an inline 34149 function can never be the key method. The default is to return 34150 `true'. 34151 34152 -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree 34153 DECL) 34154 DECL is a virtual table, virtual table table, typeinfo object, or 34155 other similar implicit class data object that will be emitted with 34156 external linkage in this translation unit. No ELF visibility has 34157 been explicitly specified. If the target needs to specify a 34158 visibility other than that of the containing class, use this hook 34159 to set `DECL_VISIBILITY' and `DECL_VISIBILITY_SPECIFIED'. 34160 34161 -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void) 34162 This hook returns true (the default) if virtual tables and other 34163 similar implicit class data objects are always COMDAT if they have 34164 external linkage. If this hook returns false, then class data for 34165 classes whose virtual table will be emitted in only one translation 34166 unit will not be COMDAT. 34167 34168 -- Target Hook: bool TARGET_CXX_LIBRARY_RTTI_COMDAT (void) 34169 This hook returns true (the default) if the RTTI information for 34170 the basic types which is defined in the C++ runtime should always 34171 be COMDAT, false if it should not be COMDAT. 34172 34173 -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void) 34174 This hook returns true if `__aeabi_atexit' (as defined by the ARM 34175 EABI) should be used to register static destructors when 34176 `-fuse-cxa-atexit' is in effect. The default is to return false 34177 to use `__cxa_atexit'. 34178 34179 -- Target Hook: bool TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT (void) 34180 This hook returns true if the target `atexit' function can be used 34181 in the same manner as `__cxa_atexit' to register C++ static 34182 destructors. This requires that `atexit'-registered functions in 34183 shared libraries are run in the correct order when the libraries 34184 are unloaded. The default is to return false. 34185 34186 -- Target Hook: void TARGET_CXX_ADJUST_CLASS_AT_DEFINITION (tree TYPE) 34187 TYPE is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has 34188 just been defined. Use this hook to make adjustments to the class 34189 (eg, tweak visibility or perform any other required target 34190 modifications). 34191 34192 34193File: gccint.info, Node: Named Address Spaces, Next: Misc, Prev: C++ ABI, Up: Target Macros 34194 3419517.30 Adding support for named address spaces 34196============================================= 34197 34198The draft technical report of the ISO/IEC JTC1 S22 WG14 N1275 standards 34199committee, `Programming Languages - C - Extensions to support embedded 34200processors', specifies a syntax for embedded processors to specify 34201alternate address spaces. You can configure a GCC port to support 34202section 5.1 of the draft report to add support for address spaces other 34203than the default address space. These address spaces are new keywords 34204that are similar to the `volatile' and `const' type attributes. 34205 34206 Pointers to named address spaces can have a different size than 34207pointers to the generic address space. 34208 34209 For example, the SPU port uses the `__ea' address space to refer to 34210memory in the host processor, rather than memory local to the SPU 34211processor. Access to memory in the `__ea' address space involves 34212issuing DMA operations to move data between the host processor and the 34213local processor memory address space. Pointers in the `__ea' address 34214space are either 32 bits or 64 bits based on the `-mea32' or `-mea64' 34215switches (native SPU pointers are always 32 bits). 34216 34217 Internally, address spaces are represented as a small integer in the 34218range 0 to 15 with address space 0 being reserved for the generic 34219address space. 34220 34221 -- Macro: TARGET_ADDR_SPACE_KEYWORDS 34222 A list of `ADDR_SPACE_KEYWORD' macros to define each named address 34223 keyword. The `ADDR_SPACE_KEYWORD' macro takes two arguments, the 34224 keyword string and the number of the named address space. For 34225 example, the SPU port uses the following to declare `__ea' as the 34226 keyword for named address space #1: 34227 #define ADDR_SPACE_EA 1 34228 #define TARGET_ADDR_SPACE_KEYWORDS ADDR_SPACE_KEYWORD ("__ea", ADDR_SPACE_EA) 34229 34230 -- Target Hook: enum machine_mode TARGET_ADDR_SPACE_POINTER_MODE 34231 (addr_space_t ADDRESS_SPACE) 34232 Define this to return the machine mode to use for pointers to 34233 ADDRESS_SPACE if the target supports named address spaces. The 34234 default version of this hook returns `ptr_mode' for the generic 34235 address space only. 34236 34237 -- Target Hook: enum machine_mode TARGET_ADDR_SPACE_ADDRESS_MODE 34238 (addr_space_t ADDRESS_SPACE) 34239 Define this to return the machine mode to use for addresses in 34240 ADDRESS_SPACE if the target supports named address spaces. The 34241 default version of this hook returns `Pmode' for the generic 34242 address space only. 34243 34244 -- Target Hook: bool TARGET_ADDR_SPACE_VALID_POINTER_MODE (enum 34245 machine_mode MODE, addr_space_t AS) 34246 Define this to return nonzero if the port can handle pointers with 34247 machine mode MODE to address space AS. This target hook is the 34248 same as the `TARGET_VALID_POINTER_MODE' target hook, except that 34249 it includes explicit named address space support. The default 34250 version of this hook returns true for the modes returned by either 34251 the `TARGET_ADDR_SPACE_POINTER_MODE' or 34252 `TARGET_ADDR_SPACE_ADDRESS_MODE' target hooks for the given 34253 address space. 34254 34255 -- Target Hook: bool TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P (enum 34256 machine_mode MODE, rtx EXP, bool STRICT, addr_space_t AS) 34257 Define this to return true if EXP is a valid address for mode MODE 34258 in the named address space AS. The STRICT parameter says whether 34259 strict addressing is in effect after reload has finished. This 34260 target hook is the same as the `TARGET_LEGITIMATE_ADDRESS_P' 34261 target hook, except that it includes explicit named address space 34262 support. 34263 34264 -- Target Hook: rtx TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS (rtx X, rtx 34265 OLDX, enum machine_mode MODE, addr_space_t AS) 34266 Define this to modify an invalid address X to be a valid address 34267 with mode MODE in the named address space AS. This target hook is 34268 the same as the `TARGET_LEGITIMIZE_ADDRESS' target hook, except 34269 that it includes explicit named address space support. 34270 34271 -- Target Hook: bool TARGET_ADDR_SPACE_SUBSET_P (addr_space_t 34272 SUPERSET, addr_space_t SUBSET) 34273 Define this to return whether the SUBSET named address space is 34274 contained within the SUPERSET named address space. Pointers to a 34275 named address space that is a subset of another named address space 34276 will be converted automatically without a cast if used together in 34277 arithmetic operations. Pointers to a superset address space can be 34278 converted to pointers to a subset address space via explicit casts. 34279 34280 -- Target Hook: rtx TARGET_ADDR_SPACE_CONVERT (rtx OP, tree FROM_TYPE, 34281 tree TO_TYPE) 34282 Define this to convert the pointer expression represented by the 34283 RTL OP with type FROM_TYPE that points to a named address space to 34284 a new pointer expression with type TO_TYPE that points to a 34285 different named address space. When this hook it called, it is 34286 guaranteed that one of the two address spaces is a subset of the 34287 other, as determined by the `TARGET_ADDR_SPACE_SUBSET_P' target 34288 hook. 34289 34290 34291File: gccint.info, Node: Misc, Prev: Named Address Spaces, Up: Target Macros 34292 3429317.31 Miscellaneous Parameters 34294============================== 34295 34296Here are several miscellaneous parameters. 34297 34298 -- Macro: HAS_LONG_COND_BRANCH 34299 Define this boolean macro to indicate whether or not your 34300 architecture has conditional branches that can span all of memory. 34301 It is used in conjunction with an optimization that partitions hot 34302 and cold basic blocks into separate sections of the executable. 34303 If this macro is set to false, gcc will convert any conditional 34304 branches that attempt to cross between sections into unconditional 34305 branches or indirect jumps. 34306 34307 -- Macro: HAS_LONG_UNCOND_BRANCH 34308 Define this boolean macro to indicate whether or not your 34309 architecture has unconditional branches that can span all of 34310 memory. It is used in conjunction with an optimization that 34311 partitions hot and cold basic blocks into separate sections of the 34312 executable. If this macro is set to false, gcc will convert any 34313 unconditional branches that attempt to cross between sections into 34314 indirect jumps. 34315 34316 -- Macro: CASE_VECTOR_MODE 34317 An alias for a machine mode name. This is the machine mode that 34318 elements of a jump-table should have. 34319 34320 -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY) 34321 Optional: return the preferred mode for an `addr_diff_vec' when 34322 the minimum and maximum offset are known. If you define this, it 34323 enables extra code in branch shortening to deal with 34324 `addr_diff_vec'. To make this work, you also have to define 34325 `INSN_ALIGN' and make the alignment for `addr_diff_vec' explicit. 34326 The BODY argument is provided so that the offset_unsigned and scale 34327 flags can be updated. 34328 34329 -- Macro: CASE_VECTOR_PC_RELATIVE 34330 Define this macro to be a C expression to indicate when jump-tables 34331 should contain relative addresses. You need not define this macro 34332 if jump-tables never contain relative addresses, or jump-tables 34333 should contain relative addresses only when `-fPIC' or `-fPIC' is 34334 in effect. 34335 34336 -- Target Hook: unsigned int TARGET_CASE_VALUES_THRESHOLD (void) 34337 This function return the smallest number of different values for 34338 which it is best to use a jump-table instead of a tree of 34339 conditional branches. The default is four for machines with a 34340 `casesi' instruction and five otherwise. This is best for most 34341 machines. 34342 34343 -- Macro: CASE_USE_BIT_TESTS 34344 Define this macro to be a C expression to indicate whether C switch 34345 statements may be implemented by a sequence of bit tests. This is 34346 advantageous on processors that can efficiently implement left 34347 shift of 1 by the number of bits held in a register, but 34348 inappropriate on targets that would require a loop. By default, 34349 this macro returns `true' if the target defines an `ashlsi3' 34350 pattern, and `false' otherwise. 34351 34352 -- Macro: WORD_REGISTER_OPERATIONS 34353 Define this macro if operations between registers with integral 34354 mode smaller than a word are always performed on the entire 34355 register. Most RISC machines have this property and most CISC 34356 machines do not. 34357 34358 -- Macro: LOAD_EXTEND_OP (MEM_MODE) 34359 Define this macro to be a C expression indicating when insns that 34360 read memory in MEM_MODE, an integral mode narrower than a word, 34361 set the bits outside of MEM_MODE to be either the sign-extension 34362 or the zero-extension of the data read. Return `SIGN_EXTEND' for 34363 values of MEM_MODE for which the insn sign-extends, `ZERO_EXTEND' 34364 for which it zero-extends, and `UNKNOWN' for other modes. 34365 34366 This macro is not called with MEM_MODE non-integral or with a width 34367 greater than or equal to `BITS_PER_WORD', so you may return any 34368 value in this case. Do not define this macro if it would always 34369 return `UNKNOWN'. On machines where this macro is defined, you 34370 will normally define it as the constant `SIGN_EXTEND' or 34371 `ZERO_EXTEND'. 34372 34373 You may return a non-`UNKNOWN' value even if for some hard 34374 registers the sign extension is not performed, if for the 34375 `REGNO_REG_CLASS' of these hard registers 34376 `CANNOT_CHANGE_MODE_CLASS' returns nonzero when the FROM mode is 34377 MEM_MODE and the TO mode is any integral mode larger than this but 34378 not larger than `word_mode'. 34379 34380 You must return `UNKNOWN' if for some hard registers that allow 34381 this mode, `CANNOT_CHANGE_MODE_CLASS' says that they cannot change 34382 to `word_mode', but that they can change to another integral mode 34383 that is larger then MEM_MODE but still smaller than `word_mode'. 34384 34385 -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND 34386 Define this macro if loading short immediate values into registers 34387 sign extends. 34388 34389 -- Macro: FIXUNS_TRUNC_LIKE_FIX_TRUNC 34390 Define this macro if the same instructions that convert a floating 34391 point number to a signed fixed point number also convert validly 34392 to an unsigned one. 34393 34394 -- Target Hook: unsigned int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL (enum 34395 machine_mode MODE) 34396 When `-ffast-math' is in effect, GCC tries to optimize divisions 34397 by the same divisor, by turning them into multiplications by the 34398 reciprocal. This target hook specifies the minimum number of 34399 divisions that should be there for GCC to perform the optimization 34400 for a variable of mode MODE. The default implementation returns 3 34401 if the machine has an instruction for the division, and 2 if it 34402 does not. 34403 34404 -- Macro: MOVE_MAX 34405 The maximum number of bytes that a single instruction can move 34406 quickly between memory and registers or between two memory 34407 locations. 34408 34409 -- Macro: MAX_MOVE_MAX 34410 The maximum number of bytes that a single instruction can move 34411 quickly between memory and registers or between two memory 34412 locations. If this is undefined, the default is `MOVE_MAX'. 34413 Otherwise, it is the constant value that is the largest value that 34414 `MOVE_MAX' can have at run-time. 34415 34416 -- Macro: SHIFT_COUNT_TRUNCATED 34417 A C expression that is nonzero if on this machine the number of 34418 bits actually used for the count of a shift operation is equal to 34419 the number of bits needed to represent the size of the object 34420 being shifted. When this macro is nonzero, the compiler will 34421 assume that it is safe to omit a sign-extend, zero-extend, and 34422 certain bitwise `and' instructions that truncates the count of a 34423 shift operation. On machines that have instructions that act on 34424 bit-fields at variable positions, which may include `bit test' 34425 instructions, a nonzero `SHIFT_COUNT_TRUNCATED' also enables 34426 deletion of truncations of the values that serve as arguments to 34427 bit-field instructions. 34428 34429 If both types of instructions truncate the count (for shifts) and 34430 position (for bit-field operations), or if no variable-position 34431 bit-field instructions exist, you should define this macro. 34432 34433 However, on some machines, such as the 80386 and the 680x0, 34434 truncation only applies to shift operations and not the (real or 34435 pretended) bit-field operations. Define `SHIFT_COUNT_TRUNCATED' 34436 to be zero on such machines. Instead, add patterns to the `md' 34437 file that include the implied truncation of the shift instructions. 34438 34439 You need not define this macro if it would always have the value 34440 of zero. 34441 34442 -- Target Hook: unsigned HOST_WIDE_INT TARGET_SHIFT_TRUNCATION_MASK 34443 (enum machine_mode MODE) 34444 This function describes how the standard shift patterns for MODE 34445 deal with shifts by negative amounts or by more than the width of 34446 the mode. *Note shift patterns::. 34447 34448 On many machines, the shift patterns will apply a mask M to the 34449 shift count, meaning that a fixed-width shift of X by Y is 34450 equivalent to an arbitrary-width shift of X by Y & M. If this is 34451 true for mode MODE, the function should return M, otherwise it 34452 should return 0. A return value of 0 indicates that no particular 34453 behavior is guaranteed. 34454 34455 Note that, unlike `SHIFT_COUNT_TRUNCATED', this function does 34456 _not_ apply to general shift rtxes; it applies only to instructions 34457 that are generated by the named shift patterns. 34458 34459 The default implementation of this function returns 34460 `GET_MODE_BITSIZE (MODE) - 1' if `SHIFT_COUNT_TRUNCATED' and 0 34461 otherwise. This definition is always safe, but if 34462 `SHIFT_COUNT_TRUNCATED' is false, and some shift patterns 34463 nevertheless truncate the shift count, you may get better code by 34464 overriding it. 34465 34466 -- Macro: TRULY_NOOP_TRUNCATION (OUTPREC, INPREC) 34467 A C expression which is nonzero if on this machine it is safe to 34468 "convert" an integer of INPREC bits to one of OUTPREC bits (where 34469 OUTPREC is smaller than INPREC) by merely operating on it as if it 34470 had only OUTPREC bits. 34471 34472 On many machines, this expression can be 1. 34473 34474 When `TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for 34475 modes for which `MODES_TIEABLE_P' is 0, suboptimal code can result. 34476 If this is the case, making `TRULY_NOOP_TRUNCATION' return 0 in 34477 such cases may improve things. 34478 34479 -- Target Hook: int TARGET_MODE_REP_EXTENDED (enum machine_mode MODE, 34480 enum machine_mode REP_MODE) 34481 The representation of an integral mode can be such that the values 34482 are always extended to a wider integral mode. Return 34483 `SIGN_EXTEND' if values of MODE are represented in sign-extended 34484 form to REP_MODE. Return `UNKNOWN' otherwise. (Currently, none 34485 of the targets use zero-extended representation this way so unlike 34486 `LOAD_EXTEND_OP', `TARGET_MODE_REP_EXTENDED' is expected to return 34487 either `SIGN_EXTEND' or `UNKNOWN'. Also no target extends MODE to 34488 REP_MODE so that REP_MODE is not the next widest integral mode and 34489 currently we take advantage of this fact.) 34490 34491 Similarly to `LOAD_EXTEND_OP' you may return a non-`UNKNOWN' value 34492 even if the extension is not performed on certain hard registers 34493 as long as for the `REGNO_REG_CLASS' of these hard registers 34494 `CANNOT_CHANGE_MODE_CLASS' returns nonzero. 34495 34496 Note that `TARGET_MODE_REP_EXTENDED' and `LOAD_EXTEND_OP' describe 34497 two related properties. If you define `TARGET_MODE_REP_EXTENDED 34498 (mode, word_mode)' you probably also want to define 34499 `LOAD_EXTEND_OP (mode)' to return the same type of extension. 34500 34501 In order to enforce the representation of `mode', 34502 `TRULY_NOOP_TRUNCATION' should return false when truncating to 34503 `mode'. 34504 34505 -- Macro: STORE_FLAG_VALUE 34506 A C expression describing the value returned by a comparison 34507 operator with an integral mode and stored by a store-flag 34508 instruction (`sCOND') when the condition is true. This 34509 description must apply to _all_ the `sCOND' patterns and all the 34510 comparison operators whose results have a `MODE_INT' mode. 34511 34512 A value of 1 or -1 means that the instruction implementing the 34513 comparison operator returns exactly 1 or -1 when the comparison is 34514 true and 0 when the comparison is false. Otherwise, the value 34515 indicates which bits of the result are guaranteed to be 1 when the 34516 comparison is true. This value is interpreted in the mode of the 34517 comparison operation, which is given by the mode of the first 34518 operand in the `sCOND' pattern. Either the low bit or the sign 34519 bit of `STORE_FLAG_VALUE' be on. Presently, only those bits are 34520 used by the compiler. 34521 34522 If `STORE_FLAG_VALUE' is neither 1 or -1, the compiler will 34523 generate code that depends only on the specified bits. It can also 34524 replace comparison operators with equivalent operations if they 34525 cause the required bits to be set, even if the remaining bits are 34526 undefined. For example, on a machine whose comparison operators 34527 return an `SImode' value and where `STORE_FLAG_VALUE' is defined as 34528 `0x80000000', saying that just the sign bit is relevant, the 34529 expression 34530 34531 (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0)) 34532 34533 can be converted to 34534 34535 (ashift:SI X (const_int N)) 34536 34537 where N is the appropriate shift count to move the bit being 34538 tested into the sign bit. 34539 34540 There is no way to describe a machine that always sets the 34541 low-order bit for a true value, but does not guarantee the value 34542 of any other bits, but we do not know of any machine that has such 34543 an instruction. If you are trying to port GCC to such a machine, 34544 include an instruction to perform a logical-and of the result with 34545 1 in the pattern for the comparison operators and let us know at 34546 <gcc@gcc.gnu.org>. 34547 34548 Often, a machine will have multiple instructions that obtain a 34549 value from a comparison (or the condition codes). Here are rules 34550 to guide the choice of value for `STORE_FLAG_VALUE', and hence the 34551 instructions to be used: 34552 34553 * Use the shortest sequence that yields a valid definition for 34554 `STORE_FLAG_VALUE'. It is more efficient for the compiler to 34555 "normalize" the value (convert it to, e.g., 1 or 0) than for 34556 the comparison operators to do so because there may be 34557 opportunities to combine the normalization with other 34558 operations. 34559 34560 * For equal-length sequences, use a value of 1 or -1, with -1 34561 being slightly preferred on machines with expensive jumps and 34562 1 preferred on other machines. 34563 34564 * As a second choice, choose a value of `0x80000001' if 34565 instructions exist that set both the sign and low-order bits 34566 but do not define the others. 34567 34568 * Otherwise, use a value of `0x80000000'. 34569 34570 Many machines can produce both the value chosen for 34571 `STORE_FLAG_VALUE' and its negation in the same number of 34572 instructions. On those machines, you should also define a pattern 34573 for those cases, e.g., one matching 34574 34575 (set A (neg:M (ne:M B C))) 34576 34577 Some machines can also perform `and' or `plus' operations on 34578 condition code values with less instructions than the corresponding 34579 `sCOND' insn followed by `and' or `plus'. On those machines, 34580 define the appropriate patterns. Use the names `incscc' and 34581 `decscc', respectively, for the patterns which perform `plus' or 34582 `minus' operations on condition code values. See `rs6000.md' for 34583 some examples. The GNU Superoptizer can be used to find such 34584 instruction sequences on other machines. 34585 34586 If this macro is not defined, the default value, 1, is used. You 34587 need not define `STORE_FLAG_VALUE' if the machine has no store-flag 34588 instructions, or if the value generated by these instructions is 1. 34589 34590 -- Macro: FLOAT_STORE_FLAG_VALUE (MODE) 34591 A C expression that gives a nonzero `REAL_VALUE_TYPE' value that is 34592 returned when comparison operators with floating-point results are 34593 true. Define this macro on machines that have comparison 34594 operations that return floating-point values. If there are no 34595 such operations, do not define this macro. 34596 34597 -- Macro: VECTOR_STORE_FLAG_VALUE (MODE) 34598 A C expression that gives a rtx representing the nonzero true 34599 element for vector comparisons. The returned rtx should be valid 34600 for the inner mode of MODE which is guaranteed to be a vector 34601 mode. Define this macro on machines that have vector comparison 34602 operations that return a vector result. If there are no such 34603 operations, do not define this macro. Typically, this macro is 34604 defined as `const1_rtx' or `constm1_rtx'. This macro may return 34605 `NULL_RTX' to prevent the compiler optimizing such vector 34606 comparison operations for the given mode. 34607 34608 -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 34609 -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 34610 A C expression that indicates whether the architecture defines a 34611 value for `clz' or `ctz' with a zero operand. A result of `0' 34612 indicates the value is undefined. If the value is defined for 34613 only the RTL expression, the macro should evaluate to `1'; if the 34614 value applies also to the corresponding optab entry (which is 34615 normally the case if it expands directly into the corresponding 34616 RTL), then the macro should evaluate to `2'. In the cases where 34617 the value is defined, VALUE should be set to this value. 34618 34619 If this macro is not defined, the value of `clz' or `ctz' at zero 34620 is assumed to be undefined. 34621 34622 This macro must be defined if the target's expansion for `ffs' 34623 relies on a particular value to get correct results. Otherwise it 34624 is not necessary, though it may be used to optimize some corner 34625 cases, and to provide a default expansion for the `ffs' optab. 34626 34627 Note that regardless of this macro the "definedness" of `clz' and 34628 `ctz' at zero do _not_ extend to the builtin functions visible to 34629 the user. Thus one may be free to adjust the value at will to 34630 match the target expansion of these operations without fear of 34631 breaking the API. 34632 34633 -- Macro: Pmode 34634 An alias for the machine mode for pointers. On most machines, 34635 define this to be the integer mode corresponding to the width of a 34636 hardware pointer; `SImode' on 32-bit machine or `DImode' on 64-bit 34637 machines. On some machines you must define this to be one of the 34638 partial integer modes, such as `PSImode'. 34639 34640 The width of `Pmode' must be at least as large as the value of 34641 `POINTER_SIZE'. If it is not equal, you must define the macro 34642 `POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to 34643 `Pmode'. 34644 34645 -- Macro: FUNCTION_MODE 34646 An alias for the machine mode used for memory references to 34647 functions being called, in `call' RTL expressions. On most CISC 34648 machines, where an instruction can begin at any byte address, this 34649 should be `QImode'. On most RISC machines, where all instructions 34650 have fixed size and alignment, this should be a mode with the same 34651 size and alignment as the machine instruction words - typically 34652 `SImode' or `HImode'. 34653 34654 -- Macro: STDC_0_IN_SYSTEM_HEADERS 34655 In normal operation, the preprocessor expands `__STDC__' to the 34656 constant 1, to signify that GCC conforms to ISO Standard C. On 34657 some hosts, like Solaris, the system compiler uses a different 34658 convention, where `__STDC__' is normally 0, but is 1 if the user 34659 specifies strict conformance to the C Standard. 34660 34661 Defining `STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host 34662 convention when processing system header files, but when 34663 processing user files `__STDC__' will always expand to 1. 34664 34665 -- Macro: NO_IMPLICIT_EXTERN_C 34666 Define this macro if the system header files support C++ as well 34667 as C. This macro inhibits the usual method of using system header 34668 files in C++, which is to pretend that the file's contents are 34669 enclosed in `extern "C" {...}'. 34670 34671 -- Macro: REGISTER_TARGET_PRAGMAS () 34672 Define this macro if you want to implement any target-specific 34673 pragmas. If defined, it is a C expression which makes a series of 34674 calls to `c_register_pragma' or `c_register_pragma_with_expansion' 34675 for each pragma. The macro may also do any setup required for the 34676 pragmas. 34677 34678 The primary reason to define this macro is to provide 34679 compatibility with other compilers for the same target. In 34680 general, we discourage definition of target-specific pragmas for 34681 GCC. 34682 34683 If the pragma can be implemented by attributes then you should 34684 consider defining the target hook `TARGET_INSERT_ATTRIBUTES' as 34685 well. 34686 34687 Preprocessor macros that appear on pragma lines are not expanded. 34688 All `#pragma' directives that do not match any registered pragma 34689 are silently ignored, unless the user specifies 34690 `-Wunknown-pragmas'. 34691 34692 -- Function: void c_register_pragma (const char *SPACE, const char 34693 *NAME, void (*CALLBACK) (struct cpp_reader *)) 34694 -- Function: void c_register_pragma_with_expansion (const char *SPACE, 34695 const char *NAME, void (*CALLBACK) (struct cpp_reader *)) 34696 Each call to `c_register_pragma' or 34697 `c_register_pragma_with_expansion' establishes one pragma. The 34698 CALLBACK routine will be called when the preprocessor encounters a 34699 pragma of the form 34700 34701 #pragma [SPACE] NAME ... 34702 34703 SPACE is the case-sensitive namespace of the pragma, or `NULL' to 34704 put the pragma in the global namespace. The callback routine 34705 receives PFILE as its first argument, which can be passed on to 34706 cpplib's functions if necessary. You can lex tokens after the 34707 NAME by calling `pragma_lex'. Tokens that are not read by the 34708 callback will be silently ignored. The end of the line is 34709 indicated by a token of type `CPP_EOF'. Macro expansion occurs on 34710 the arguments of pragmas registered with 34711 `c_register_pragma_with_expansion' but not on the arguments of 34712 pragmas registered with `c_register_pragma'. 34713 34714 Note that the use of `pragma_lex' is specific to the C and C++ 34715 compilers. It will not work in the Java or Fortran compilers, or 34716 any other language compilers for that matter. Thus if 34717 `pragma_lex' is going to be called from target-specific code, it 34718 must only be done so when building the C and C++ compilers. This 34719 can be done by defining the variables `c_target_objs' and 34720 `cxx_target_objs' in the target entry in the `config.gcc' file. 34721 These variables should name the target-specific, language-specific 34722 object file which contains the code that uses `pragma_lex'. Note 34723 it will also be necessary to add a rule to the makefile fragment 34724 pointed to by `tmake_file' that shows how to build this object 34725 file. 34726 34727 -- Macro: HANDLE_SYSV_PRAGMA 34728 Define this macro (to a value of 1) if you want the System V style 34729 pragmas `#pragma pack(<n>)' and `#pragma weak <name> [=<value>]' 34730 to be supported by gcc. 34731 34732 The pack pragma specifies the maximum alignment (in bytes) of 34733 fields within a structure, in much the same way as the 34734 `__aligned__' and `__packed__' `__attribute__'s do. A pack value 34735 of zero resets the behavior to the default. 34736 34737 A subtlety for Microsoft Visual C/C++ style bit-field packing 34738 (e.g. -mms-bitfields) for targets that support it: When a 34739 bit-field is inserted into a packed record, the whole size of the 34740 underlying type is used by one or more same-size adjacent 34741 bit-fields (that is, if its long:3, 32 bits is used in the record, 34742 and any additional adjacent long bit-fields are packed into the 34743 same chunk of 32 bits. However, if the size changes, a new field 34744 of that size is allocated). 34745 34746 If both MS bit-fields and `__attribute__((packed))' are used, the 34747 latter will take precedence. If `__attribute__((packed))' is used 34748 on a single field when MS bit-fields are in use, it will take 34749 precedence for that field, but the alignment of the rest of the 34750 structure may affect its placement. 34751 34752 The weak pragma only works if `SUPPORTS_WEAK' and 34753 `ASM_WEAKEN_LABEL' are defined. If enabled it allows the creation 34754 of specifically named weak labels, optionally with a value. 34755 34756 -- Macro: HANDLE_PRAGMA_PACK_PUSH_POP 34757 Define this macro (to a value of 1) if you want to support the 34758 Win32 style pragmas `#pragma pack(push[,N])' and `#pragma 34759 pack(pop)'. The `pack(push,[N])' pragma specifies the maximum 34760 alignment (in bytes) of fields within a structure, in much the 34761 same way as the `__aligned__' and `__packed__' `__attribute__'s 34762 do. A pack value of zero resets the behavior to the default. 34763 Successive invocations of this pragma cause the previous values to 34764 be stacked, so that invocations of `#pragma pack(pop)' will return 34765 to the previous value. 34766 34767 -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION 34768 Define this macro, as well as `HANDLE_SYSV_PRAGMA', if macros 34769 should be expanded in the arguments of `#pragma pack'. 34770 34771 -- Target Hook: bool TARGET_HANDLE_PRAGMA_EXTERN_PREFIX 34772 True if `#pragma extern_prefix' is to be supported. 34773 34774 -- Macro: TARGET_DEFAULT_PACK_STRUCT 34775 If your target requires a structure packing default other than 0 34776 (meaning the machine default), define this macro to the necessary 34777 value (in bytes). This must be a value that would also be valid 34778 to use with `#pragma pack()' (that is, a small power of two). 34779 34780 -- Macro: DOLLARS_IN_IDENTIFIERS 34781 Define this macro to control use of the character `$' in 34782 identifier names for the C family of languages. 0 means `$' is 34783 not allowed by default; 1 means it is allowed. 1 is the default; 34784 there is no need to define this macro in that case. 34785 34786 -- Macro: NO_DOLLAR_IN_LABEL 34787 Define this macro if the assembler does not accept the character 34788 `$' in label names. By default constructors and destructors in 34789 G++ have `$' in the identifiers. If this macro is defined, `.' is 34790 used instead. 34791 34792 -- Macro: NO_DOT_IN_LABEL 34793 Define this macro if the assembler does not accept the character 34794 `.' in label names. By default constructors and destructors in G++ 34795 have names that use `.'. If this macro is defined, these names 34796 are rewritten to avoid `.'. 34797 34798 -- Macro: INSN_SETS_ARE_DELAYED (INSN) 34799 Define this macro as a C expression that is nonzero if it is safe 34800 for the delay slot scheduler to place instructions in the delay 34801 slot of INSN, even if they appear to use a resource set or 34802 clobbered in INSN. INSN is always a `jump_insn' or an `insn'; GCC 34803 knows that every `call_insn' has this behavior. On machines where 34804 some `insn' or `jump_insn' is really a function call and hence has 34805 this behavior, you should define this macro. 34806 34807 You need not define this macro if it would always return zero. 34808 34809 -- Macro: INSN_REFERENCES_ARE_DELAYED (INSN) 34810 Define this macro as a C expression that is nonzero if it is safe 34811 for the delay slot scheduler to place instructions in the delay 34812 slot of INSN, even if they appear to set or clobber a resource 34813 referenced in INSN. INSN is always a `jump_insn' or an `insn'. 34814 On machines where some `insn' or `jump_insn' is really a function 34815 call and its operands are registers whose use is actually in the 34816 subroutine it calls, you should define this macro. Doing so 34817 allows the delay slot scheduler to move instructions which copy 34818 arguments into the argument registers into the delay slot of INSN. 34819 34820 You need not define this macro if it would always return zero. 34821 34822 -- Macro: MULTIPLE_SYMBOL_SPACES 34823 Define this macro as a C expression that is nonzero if, in some 34824 cases, global symbols from one translation unit may not be bound 34825 to undefined symbols in another translation unit without user 34826 intervention. For instance, under Microsoft Windows symbols must 34827 be explicitly imported from shared libraries (DLLs). 34828 34829 You need not define this macro if it would always evaluate to zero. 34830 34831 -- Target Hook: tree TARGET_MD_ASM_CLOBBERS (tree OUTPUTS, tree 34832 INPUTS, tree CLOBBERS) 34833 This target hook should add to CLOBBERS `STRING_CST' trees for any 34834 hard regs the port wishes to automatically clobber for an asm. It 34835 should return the result of the last `tree_cons' used to add a 34836 clobber. The OUTPUTS, INPUTS and CLOBBER lists are the 34837 corresponding parameters to the asm and may be inspected to avoid 34838 clobbering a register that is an input or output of the asm. You 34839 can use `tree_overlaps_hard_reg_set', declared in `tree.h', to test 34840 for overlap with regards to asm-declared registers. 34841 34842 -- Macro: MATH_LIBRARY 34843 Define this macro as a C string constant for the linker argument 34844 to link in the system math library, or `""' if the target does not 34845 have a separate math library. 34846 34847 You need only define this macro if the default of `"-lm"' is wrong. 34848 34849 -- Macro: LIBRARY_PATH_ENV 34850 Define this macro as a C string constant for the environment 34851 variable that specifies where the linker should look for libraries. 34852 34853 You need only define this macro if the default of `"LIBRARY_PATH"' 34854 is wrong. 34855 34856 -- Macro: TARGET_POSIX_IO 34857 Define this macro if the target supports the following POSIX file 34858 functions, access, mkdir and file locking with fcntl / F_SETLKW. 34859 Defining `TARGET_POSIX_IO' will enable the test coverage code to 34860 use file locking when exiting a program, which avoids race 34861 conditions if the program has forked. It will also create 34862 directories at run-time for cross-profiling. 34863 34864 -- Macro: MAX_CONDITIONAL_EXECUTE 34865 A C expression for the maximum number of instructions to execute 34866 via conditional execution instructions instead of a branch. A 34867 value of `BRANCH_COST'+1 is the default if the machine does not 34868 use cc0, and 1 if it does use cc0. 34869 34870 -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR) 34871 Used if the target needs to perform machine-dependent 34872 modifications on the conditionals used for turning basic blocks 34873 into conditionally executed code. CE_INFO points to a data 34874 structure, `struct ce_if_block', which contains information about 34875 the currently processed blocks. TRUE_EXPR and FALSE_EXPR are the 34876 tests that are used for converting the then-block and the 34877 else-block, respectively. Set either TRUE_EXPR or FALSE_EXPR to a 34878 null pointer if the tests cannot be converted. 34879 34880 -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR, 34881 FALSE_EXPR) 34882 Like `IFCVT_MODIFY_TESTS', but used when converting more 34883 complicated if-statements into conditions combined by `and' and 34884 `or' operations. BB contains the basic block that contains the 34885 test that is currently being processed and about to be turned into 34886 a condition. 34887 34888 -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN) 34889 A C expression to modify the PATTERN of an INSN that is to be 34890 converted to conditional execution format. CE_INFO points to a 34891 data structure, `struct ce_if_block', which contains information 34892 about the currently processed blocks. 34893 34894 -- Macro: IFCVT_MODIFY_FINAL (CE_INFO) 34895 A C expression to perform any final machine dependent 34896 modifications in converting code to conditional execution. The 34897 involved basic blocks can be found in the `struct ce_if_block' 34898 structure that is pointed to by CE_INFO. 34899 34900 -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO) 34901 A C expression to cancel any machine dependent modifications in 34902 converting code to conditional execution. The involved basic 34903 blocks can be found in the `struct ce_if_block' structure that is 34904 pointed to by CE_INFO. 34905 34906 -- Macro: IFCVT_INIT_EXTRA_FIELDS (CE_INFO) 34907 A C expression to initialize any extra fields in a `struct 34908 ce_if_block' structure, which are defined by the 34909 `IFCVT_EXTRA_FIELDS' macro. 34910 34911 -- Macro: IFCVT_EXTRA_FIELDS 34912 If defined, it should expand to a set of field declarations that 34913 will be added to the `struct ce_if_block' structure. These should 34914 be initialized by the `IFCVT_INIT_EXTRA_FIELDS' macro. 34915 34916 -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG (void) 34917 If non-null, this hook performs a target-specific pass over the 34918 instruction stream. The compiler will run it at all optimization 34919 levels, just before the point at which it normally does 34920 delayed-branch scheduling. 34921 34922 The exact purpose of the hook varies from target to target. Some 34923 use it to do transformations that are necessary for correctness, 34924 such as laying out in-function constant pools or avoiding hardware 34925 hazards. Others use it as an opportunity to do some 34926 machine-dependent optimizations. 34927 34928 You need not implement the hook if it has nothing to do. The 34929 default definition is null. 34930 34931 -- Target Hook: void TARGET_INIT_BUILTINS (void) 34932 Define this hook if you have any machine-specific built-in 34933 functions that need to be defined. It should be a function that 34934 performs the necessary setup. 34935 34936 Machine specific built-in functions can be useful to expand 34937 special machine instructions that would otherwise not normally be 34938 generated because they have no equivalent in the source language 34939 (for example, SIMD vector instructions or prefetch instructions). 34940 34941 To create a built-in function, call the function 34942 `lang_hooks.builtin_function' which is defined by the language 34943 front end. You can use any type nodes set up by 34944 `build_common_tree_nodes' and `build_common_tree_nodes_2'; only 34945 language front ends that use those two functions will call 34946 `TARGET_INIT_BUILTINS'. 34947 34948 -- Target Hook: tree TARGET_BUILTIN_DECL (unsigned CODE, bool 34949 INITIALIZE_P) 34950 Define this hook if you have any machine-specific built-in 34951 functions that need to be defined. It should be a function that 34952 returns the builtin function declaration for the builtin function 34953 code CODE. If there is no such builtin and it cannot be 34954 initialized at this time if INITIALIZE_P is true the function 34955 should return `NULL_TREE'. If CODE is out of range the function 34956 should return `error_mark_node'. 34957 34958 -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx 34959 SUBTARGET, enum machine_mode MODE, int IGNORE) 34960 Expand a call to a machine specific built-in function that was set 34961 up by `TARGET_INIT_BUILTINS'. EXP is the expression for the 34962 function call; the result should go to TARGET if that is 34963 convenient, and have mode MODE if that is convenient. SUBTARGET 34964 may be used as the target for computing one of EXP's operands. 34965 IGNORE is nonzero if the value is to be ignored. This function 34966 should return the result of the call to the built-in function. 34967 34968 -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (unsigned int 34969 LOC, tree FNDECL, void *ARGLIST) 34970 Select a replacement for a machine specific built-in function that 34971 was set up by `TARGET_INIT_BUILTINS'. This is done _before_ 34972 regular type checking, and so allows the target to implement a 34973 crude form of function overloading. FNDECL is the declaration of 34974 the built-in function. ARGLIST is the list of arguments passed to 34975 the built-in function. The result is a complete expression that 34976 implements the operation, usually another `CALL_EXPR'. ARGLIST 34977 really has type `VEC(tree,gc)*' 34978 34979 -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, tree ARGLIST, 34980 bool IGNORE) 34981 Fold a call to a machine specific built-in function that was set 34982 up by `TARGET_INIT_BUILTINS'. FNDECL is the declaration of the 34983 built-in function. ARGLIST is the list of arguments passed to the 34984 built-in function. The result is another tree containing a 34985 simplified expression for the call's result. If IGNORE is true 34986 the value will be ignored. 34987 34988 -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (const_rtx 34989 INSN) 34990 Take an instruction in INSN and return NULL if it is valid within a 34991 low-overhead loop, otherwise return a string explaining why doloop 34992 could not be applied. 34993 34994 Many targets use special registers for low-overhead looping. For 34995 any instruction that clobbers these this function should return a 34996 string indicating the reason why the doloop could not be applied. 34997 By default, the RTL loop optimizer does not use a present doloop 34998 pattern for loops containing function calls or branch on table 34999 instructions. 35000 35001 -- Macro: MD_CAN_REDIRECT_BRANCH (BRANCH1, BRANCH2) 35002 Take a branch insn in BRANCH1 and another in BRANCH2. Return true 35003 if redirecting BRANCH1 to the destination of BRANCH2 is possible. 35004 35005 On some targets, branches may have a limited range. Optimizing the 35006 filling of delay slots can result in branches being redirected, 35007 and this may in turn cause a branch offset to overflow. 35008 35009 -- Target Hook: bool TARGET_COMMUTATIVE_P (const_rtx X, int OUTER_CODE) 35010 This target hook returns `true' if X is considered to be 35011 commutative. Usually, this is just COMMUTATIVE_P (X), but the HP 35012 PA doesn't consider PLUS to be commutative inside a MEM. 35013 OUTER_CODE is the rtx code of the enclosing rtl, if known, 35014 otherwise it is UNKNOWN. 35015 35016 -- Target Hook: rtx TARGET_ALLOCATE_INITIAL_VALUE (rtx HARD_REG) 35017 When the initial value of a hard register has been copied in a 35018 pseudo register, it is often not necessary to actually allocate 35019 another register to this pseudo register, because the original 35020 hard register or a stack slot it has been saved into can be used. 35021 `TARGET_ALLOCATE_INITIAL_VALUE' is called at the start of register 35022 allocation once for each hard register that had its initial value 35023 copied by using `get_func_hard_reg_initial_val' or 35024 `get_hard_reg_initial_val'. Possible values are `NULL_RTX', if 35025 you don't want to do any special allocation, a `REG' rtx--that 35026 would typically be the hard register itself, if it is known not to 35027 be clobbered--or a `MEM'. If you are returning a `MEM', this is 35028 only a hint for the allocator; it might decide to use another 35029 register anyways. You may use `current_function_leaf_function' in 35030 the hook, functions that use `REG_N_SETS', to determine if the hard 35031 register in question will not be clobbered. The default value of 35032 this hook is `NULL', which disables any special allocation. 35033 35034 -- Target Hook: int TARGET_UNSPEC_MAY_TRAP_P (const_rtx X, unsigned 35035 FLAGS) 35036 This target hook returns nonzero if X, an `unspec' or 35037 `unspec_volatile' operation, might cause a trap. Targets can use 35038 this hook to enhance precision of analysis for `unspec' and 35039 `unspec_volatile' operations. You may call `may_trap_p_1' to 35040 analyze inner elements of X in which case FLAGS should be passed 35041 along. 35042 35043 -- Target Hook: void TARGET_SET_CURRENT_FUNCTION (tree DECL) 35044 The compiler invokes this hook whenever it changes its current 35045 function context (`cfun'). You can define this function if the 35046 back end needs to perform any initialization or reset actions on a 35047 per-function basis. For example, it may be used to implement 35048 function attributes that affect register usage or code generation 35049 patterns. The argument DECL is the declaration for the new 35050 function context, and may be null to indicate that the compiler 35051 has left a function context and is returning to processing at the 35052 top level. The default hook function does nothing. 35053 35054 GCC sets `cfun' to a dummy function context during initialization 35055 of some parts of the back end. The hook function is not invoked 35056 in this situation; you need not worry about the hook being invoked 35057 recursively, or when the back end is in a partially-initialized 35058 state. `cfun' might be `NULL' to indicate processing at top level, 35059 outside of any function scope. 35060 35061 -- Macro: TARGET_OBJECT_SUFFIX 35062 Define this macro to be a C string representing the suffix for 35063 object files on your target machine. If you do not define this 35064 macro, GCC will use `.o' as the suffix for object files. 35065 35066 -- Macro: TARGET_EXECUTABLE_SUFFIX 35067 Define this macro to be a C string representing the suffix to be 35068 automatically added to executable files on your target machine. 35069 If you do not define this macro, GCC will use the null string as 35070 the suffix for executable files. 35071 35072 -- Macro: COLLECT_EXPORT_LIST 35073 If defined, `collect2' will scan the individual object files 35074 specified on its command line and create an export list for the 35075 linker. Define this macro for systems like AIX, where the linker 35076 discards object files that are not referenced from `main' and uses 35077 export lists. 35078 35079 -- Macro: MODIFY_JNI_METHOD_CALL (MDECL) 35080 Define this macro to a C expression representing a variant of the 35081 method call MDECL, if Java Native Interface (JNI) methods must be 35082 invoked differently from other methods on your target. For 35083 example, on 32-bit Microsoft Windows, JNI methods must be invoked 35084 using the `stdcall' calling convention and this macro is then 35085 defined as this expression: 35086 35087 build_type_attribute_variant (MDECL, 35088 build_tree_list 35089 (get_identifier ("stdcall"), 35090 NULL)) 35091 35092 -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void) 35093 This target hook returns `true' past the point in which new jump 35094 instructions could be created. On machines that require a 35095 register for every jump such as the SHmedia ISA of SH5, this point 35096 would typically be reload, so this target hook should be defined 35097 to a function such as: 35098 35099 static bool 35100 cannot_modify_jumps_past_reload_p () 35101 { 35102 return (reload_completed || reload_in_progress); 35103 } 35104 35105 -- Target Hook: enum reg_class TARGET_BRANCH_TARGET_REGISTER_CLASS 35106 (void) 35107 This target hook returns a register class for which branch target 35108 register optimizations should be applied. All registers in this 35109 class should be usable interchangeably. After reload, registers 35110 in this class will be re-allocated and loads will be hoisted out 35111 of loops and be subjected to inter-block scheduling. 35112 35113 -- Target Hook: bool TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (bool 35114 AFTER_PROLOGUE_EPILOGUE_GEN) 35115 Branch target register optimization will by default exclude 35116 callee-saved registers that are not already live during the 35117 current function; if this target hook returns true, they will be 35118 included. The target code must than make sure that all target 35119 registers in the class returned by 35120 `TARGET_BRANCH_TARGET_REGISTER_CLASS' that might need saving are 35121 saved. AFTER_PROLOGUE_EPILOGUE_GEN indicates if prologues and 35122 epilogues have already been generated. Note, even if you only 35123 return true when AFTER_PROLOGUE_EPILOGUE_GEN is false, you still 35124 are likely to have to make special provisions in 35125 `INITIAL_ELIMINATION_OFFSET' to reserve space for caller-saved 35126 target registers. 35127 35128 -- Target Hook: bool TARGET_HAVE_CONDITIONAL_EXECUTION (void) 35129 This target hook returns true if the target supports conditional 35130 execution. This target hook is required only when the target has 35131 several different modes and they have different conditional 35132 execution capability, such as ARM. 35133 35134 -- Macro: POWI_MAX_MULTS 35135 If defined, this macro is interpreted as a signed integer C 35136 expression that specifies the maximum number of floating point 35137 multiplications that should be emitted when expanding 35138 exponentiation by an integer constant inline. When this value is 35139 defined, exponentiation requiring more than this number of 35140 multiplications is implemented by calling the system library's 35141 `pow', `powf' or `powl' routines. The default value places no 35142 upper bound on the multiplication count. 35143 35144 -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char 35145 *IPREFIX, int STDINC) 35146 This target hook should register any extra include files for the 35147 target. The parameter STDINC indicates if normal include files 35148 are present. The parameter SYSROOT is the system root directory. 35149 The parameter IPREFIX is the prefix for the gcc directory. 35150 35151 -- Macro: void TARGET_EXTRA_PRE_INCLUDES (const char *SYSROOT, const 35152 char *IPREFIX, int STDINC) 35153 This target hook should register any extra include files for the 35154 target before any standard headers. The parameter STDINC 35155 indicates if normal include files are present. The parameter 35156 SYSROOT is the system root directory. The parameter IPREFIX is 35157 the prefix for the gcc directory. 35158 35159 -- Macro: void TARGET_OPTF (char *PATH) 35160 This target hook should register special include paths for the 35161 target. The parameter PATH is the include to register. On Darwin 35162 systems, this is used for Framework includes, which have semantics 35163 that are different from `-I'. 35164 35165 -- Macro: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL) 35166 This target macro returns `true' if it is safe to use a local alias 35167 for a virtual function FNDECL when constructing thunks, `false' 35168 otherwise. By default, the macro returns `true' for all 35169 functions, if a target supports aliases (i.e. defines 35170 `ASM_OUTPUT_DEF'), `false' otherwise, 35171 35172 -- Macro: TARGET_FORMAT_TYPES 35173 If defined, this macro is the name of a global variable containing 35174 target-specific format checking information for the `-Wformat' 35175 option. The default is to have no target-specific format checks. 35176 35177 -- Macro: TARGET_N_FORMAT_TYPES 35178 If defined, this macro is the number of entries in 35179 `TARGET_FORMAT_TYPES'. 35180 35181 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES 35182 If defined, this macro is the name of a global variable containing 35183 target-specific format overrides for the `-Wformat' option. The 35184 default is to have no target-specific format overrides. If defined, 35185 `TARGET_FORMAT_TYPES' must be defined, too. 35186 35187 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT 35188 If defined, this macro specifies the number of entries in 35189 `TARGET_OVERRIDES_FORMAT_ATTRIBUTES'. 35190 35191 -- Macro: TARGET_OVERRIDES_FORMAT_INIT 35192 If defined, this macro specifies the optional initialization 35193 routine for target specific customizations of the system printf 35194 and scanf formatter settings. 35195 35196 -- Target Hook: bool TARGET_RELAXED_ORDERING 35197 If set to `true', means that the target's memory model does not 35198 guarantee that loads which do not depend on one another will access 35199 main memory in the order of the instruction stream; if ordering is 35200 important, an explicit memory barrier must be used. This is true 35201 of many recent processors which implement a policy of "relaxed," 35202 "weak," or "release" memory consistency, such as Alpha, PowerPC, 35203 and ia64. The default is `false'. 35204 35205 -- Target Hook: const char * TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN 35206 (const_tree TYPELIST, const_tree FUNCDECL, const_tree VAL) 35207 If defined, this macro returns the diagnostic message when it is 35208 illegal to pass argument VAL to function FUNCDECL with prototype 35209 TYPELIST. 35210 35211 -- Target Hook: const char * TARGET_INVALID_CONVERSION (const_tree 35212 FROMTYPE, const_tree TOTYPE) 35213 If defined, this macro returns the diagnostic message when it is 35214 invalid to convert from FROMTYPE to TOTYPE, or `NULL' if validity 35215 should be determined by the front end. 35216 35217 -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP, 35218 const_tree TYPE) 35219 If defined, this macro returns the diagnostic message when it is 35220 invalid to apply operation OP (where unary plus is denoted by 35221 `CONVERT_EXPR') to an operand of type TYPE, or `NULL' if validity 35222 should be determined by the front end. 35223 35224 -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP, 35225 const_tree TYPE1, const_tree TYPE2) 35226 If defined, this macro returns the diagnostic message when it is 35227 invalid to apply operation OP to operands of types TYPE1 and 35228 TYPE2, or `NULL' if validity should be determined by the front end. 35229 35230 -- Target Hook: const char * TARGET_INVALID_PARAMETER_TYPE (const_tree 35231 TYPE) 35232 If defined, this macro returns the diagnostic message when it is 35233 invalid for functions to include parameters of type TYPE, or 35234 `NULL' if validity should be determined by the front end. This is 35235 currently used only by the C and C++ front ends. 35236 35237 -- Target Hook: const char * TARGET_INVALID_RETURN_TYPE (const_tree 35238 TYPE) 35239 If defined, this macro returns the diagnostic message when it is 35240 invalid for functions to have return type TYPE, or `NULL' if 35241 validity should be determined by the front end. This is currently 35242 used only by the C and C++ front ends. 35243 35244 -- Target Hook: tree TARGET_PROMOTED_TYPE (const_tree TYPE) 35245 If defined, this target hook returns the type to which values of 35246 TYPE should be promoted when they appear in expressions, analogous 35247 to the integer promotions, or `NULL_TREE' to use the front end's 35248 normal promotion rules. This hook is useful when there are 35249 target-specific types with special promotion rules. This is 35250 currently used only by the C and C++ front ends. 35251 35252 -- Target Hook: tree TARGET_CONVERT_TO_TYPE (tree TYPE, tree EXPR) 35253 If defined, this hook returns the result of converting EXPR to 35254 TYPE. It should return the converted expression, or `NULL_TREE' 35255 to apply the front end's normal conversion rules. This hook is 35256 useful when there are target-specific types with special 35257 conversion rules. This is currently used only by the C and C++ 35258 front ends. 35259 35260 -- Macro: TARGET_USE_JCR_SECTION 35261 This macro determines whether to use the JCR section to register 35262 Java classes. By default, TARGET_USE_JCR_SECTION is defined to 1 35263 if both SUPPORTS_WEAK and TARGET_HAVE_NAMED_SECTIONS are true, 35264 else 0. 35265 35266 -- Macro: OBJC_JBLEN 35267 This macro determines the size of the objective C jump buffer for 35268 the NeXT runtime. By default, OBJC_JBLEN is defined to an 35269 innocuous value. 35270 35271 -- Macro: LIBGCC2_UNWIND_ATTRIBUTE 35272 Define this macro if any target-specific attributes need to be 35273 attached to the functions in `libgcc' that provide low-level 35274 support for call stack unwinding. It is used in declarations in 35275 `unwind-generic.h' and the associated definitions of those 35276 functions. 35277 35278 -- Target Hook: void TARGET_UPDATE_STACK_BOUNDARY (void) 35279 Define this macro to update the current function stack boundary if 35280 necessary. 35281 35282 -- Target Hook: rtx TARGET_GET_DRAP_RTX (void) 35283 This hook should return an rtx for Dynamic Realign Argument 35284 Pointer (DRAP) if a different argument pointer register is needed 35285 to access the function's argument list due to stack realignment. 35286 Return `NULL' if no DRAP is needed. 35287 35288 -- Target Hook: bool TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS (void) 35289 When optimization is disabled, this hook indicates whether or not 35290 arguments should be allocated to stack slots. Normally, GCC 35291 allocates stacks slots for arguments when not optimizing in order 35292 to make debugging easier. However, when a function is declared 35293 with `__attribute__((naked))', there is no stack frame, and the 35294 compiler cannot safely move arguments from the registers in which 35295 they are passed to the stack. Therefore, this hook should return 35296 true in general, but false for naked functions. The default 35297 implementation always returns true. 35298 35299 -- Target Hook: unsigned HOST_WIDE_INT TARGET_CONST_ANCHOR 35300 On some architectures it can take multiple instructions to 35301 synthesize a constant. If there is another constant already in a 35302 register that is close enough in value then it is preferable that 35303 the new constant is computed from this register using immediate 35304 addition or subtraction. We accomplish this through CSE. Besides 35305 the value of the constant we also add a lower and an upper 35306 constant anchor to the available expressions. These are then 35307 queried when encountering new constants. The anchors are computed 35308 by rounding the constant up and down to a multiple of the value of 35309 `TARGET_CONST_ANCHOR'. `TARGET_CONST_ANCHOR' should be the 35310 maximum positive value accepted by immediate-add plus one. We 35311 currently assume that the value of `TARGET_CONST_ANCHOR' is a 35312 power of 2. For example, on MIPS, where add-immediate takes a 35313 16-bit signed value, `TARGET_CONST_ANCHOR' is set to `0x8000'. 35314 The default value is zero, which disables this optimization. 35315 35316 35317File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top 35318 3531918 Host Configuration 35320********************* 35321 35322Most details about the machine and system on which the compiler is 35323actually running are detected by the `configure' script. Some things 35324are impossible for `configure' to detect; these are described in two 35325ways, either by macros defined in a file named `xm-MACHINE.h' or by 35326hook functions in the file specified by the OUT_HOST_HOOK_OBJ variable 35327in `config.gcc'. (The intention is that very few hosts will need a 35328header file but nearly every fully supported host will need to override 35329some hooks.) 35330 35331 If you need to define only a few macros, and they have simple 35332definitions, consider using the `xm_defines' variable in your 35333`config.gcc' entry instead of creating a host configuration header. 35334*Note System Config::. 35335 35336* Menu: 35337 35338* Host Common:: Things every host probably needs implemented. 35339* Filesystem:: Your host can't have the letter `a' in filenames? 35340* Host Misc:: Rare configuration options for hosts. 35341 35342 35343File: gccint.info, Node: Host Common, Next: Filesystem, Up: Host Config 35344 3534518.1 Host Common 35346================ 35347 35348Some things are just not portable, even between similar operating 35349systems, and are too difficult for autoconf to detect. They get 35350implemented using hook functions in the file specified by the 35351HOST_HOOK_OBJ variable in `config.gcc'. 35352 35353 -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void) 35354 This host hook is used to set up handling for extra signals. The 35355 most common thing to do in this hook is to detect stack overflow. 35356 35357 -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE, int 35358 FD) 35359 This host hook returns the address of some space that is likely to 35360 be free in some subsequent invocation of the compiler. We intend 35361 to load the PCH data at this address such that the data need not 35362 be relocated. The area should be able to hold SIZE bytes. If the 35363 host uses `mmap', FD is an open file descriptor that can be used 35364 for probing. 35365 35366 -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS, 35367 size_t SIZE, int FD, size_t OFFSET) 35368 This host hook is called when a PCH file is about to be loaded. 35369 We want to load SIZE bytes from FD at OFFSET into memory at 35370 ADDRESS. The given address will be the result of a previous 35371 invocation of `HOST_HOOKS_GT_PCH_GET_ADDRESS'. Return -1 if we 35372 couldn't allocate SIZE bytes at ADDRESS. Return 0 if the memory 35373 is allocated but the data is not loaded. Return 1 if the hook has 35374 performed everything. 35375 35376 If the implementation uses reserved address space, free any 35377 reserved space beyond SIZE, regardless of the return value. If no 35378 PCH will be loaded, this hook may be called with SIZE zero, in 35379 which case all reserved address space should be freed. 35380 35381 Do not try to handle values of ADDRESS that could not have been 35382 returned by this executable; just return -1. Such values usually 35383 indicate an out-of-date PCH file (built by some other GCC 35384 executable), and such a PCH file won't work. 35385 35386 -- Host Hook: size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void); 35387 This host hook returns the alignment required for allocating 35388 virtual memory. Usually this is the same as getpagesize, but on 35389 some hosts the alignment for reserving memory differs from the 35390 pagesize for committing memory. 35391 35392 35393File: gccint.info, Node: Filesystem, Next: Host Misc, Prev: Host Common, Up: Host Config 35394 3539518.2 Host Filesystem 35396==================== 35397 35398GCC needs to know a number of things about the semantics of the host 35399machine's filesystem. Filesystems with Unix and MS-DOS semantics are 35400automatically detected. For other systems, you can define the 35401following macros in `xm-MACHINE.h'. 35402 35403`HAVE_DOS_BASED_FILE_SYSTEM' 35404 This macro is automatically defined by `system.h' if the host file 35405 system obeys the semantics defined by MS-DOS instead of Unix. DOS 35406 file systems are case insensitive, file specifications may begin 35407 with a drive letter, and both forward slash and backslash (`/' and 35408 `\') are directory separators. 35409 35410`DIR_SEPARATOR' 35411`DIR_SEPARATOR_2' 35412 If defined, these macros expand to character constants specifying 35413 separators for directory names within a file specification. 35414 `system.h' will automatically give them appropriate values on Unix 35415 and MS-DOS file systems. If your file system is neither of these, 35416 define one or both appropriately in `xm-MACHINE.h'. 35417 35418 However, operating systems like VMS, where constructing a pathname 35419 is more complicated than just stringing together directory names 35420 separated by a special character, should not define either of these 35421 macros. 35422 35423`PATH_SEPARATOR' 35424 If defined, this macro should expand to a character constant 35425 specifying the separator for elements of search paths. The default 35426 value is a colon (`:'). DOS-based systems usually, but not 35427 always, use semicolon (`;'). 35428 35429`VMS' 35430 Define this macro if the host system is VMS. 35431 35432`HOST_OBJECT_SUFFIX' 35433 Define this macro to be a C string representing the suffix for 35434 object files on your host machine. If you do not define this 35435 macro, GCC will use `.o' as the suffix for object files. 35436 35437`HOST_EXECUTABLE_SUFFIX' 35438 Define this macro to be a C string representing the suffix for 35439 executable files on your host machine. If you do not define this 35440 macro, GCC will use the null string as the suffix for executable 35441 files. 35442 35443`HOST_BIT_BUCKET' 35444 A pathname defined by the host operating system, which can be 35445 opened as a file and written to, but all the information written 35446 is discarded. This is commonly known as a "bit bucket" or "null 35447 device". If you do not define this macro, GCC will use 35448 `/dev/null' as the bit bucket. If the host does not support a bit 35449 bucket, define this macro to an invalid filename. 35450 35451`UPDATE_PATH_HOST_CANONICALIZE (PATH)' 35452 If defined, a C statement (sans semicolon) that performs 35453 host-dependent canonicalization when a path used in a compilation 35454 driver or preprocessor is canonicalized. PATH is a malloc-ed path 35455 to be canonicalized. If the C statement does canonicalize PATH 35456 into a different buffer, the old path should be freed and the new 35457 buffer should have been allocated with malloc. 35458 35459`DUMPFILE_FORMAT' 35460 Define this macro to be a C string representing the format to use 35461 for constructing the index part of debugging dump file names. The 35462 resultant string must fit in fifteen bytes. The full filename 35463 will be the concatenation of: the prefix of the assembler file 35464 name, the string resulting from applying this format to an index 35465 number, and a string unique to each dump file kind, e.g. `rtl'. 35466 35467 If you do not define this macro, GCC will use `.%02d.'. You should 35468 define this macro if using the default will create an invalid file 35469 name. 35470 35471`DELETE_IF_ORDINARY' 35472 Define this macro to be a C statement (sans semicolon) that 35473 performs host-dependent removal of ordinary temp files in the 35474 compilation driver. 35475 35476 If you do not define this macro, GCC will use the default version. 35477 You should define this macro if the default version does not 35478 reliably remove the temp file as, for example, on VMS which allows 35479 multiple versions of a file. 35480 35481`HOST_LACKS_INODE_NUMBERS' 35482 Define this macro if the host filesystem does not report 35483 meaningful inode numbers in struct stat. 35484 35485 35486File: gccint.info, Node: Host Misc, Prev: Filesystem, Up: Host Config 35487 3548818.3 Host Misc 35489============== 35490 35491`FATAL_EXIT_CODE' 35492 A C expression for the status code to be returned when the compiler 35493 exits after serious errors. The default is the system-provided 35494 macro `EXIT_FAILURE', or `1' if the system doesn't define that 35495 macro. Define this macro only if these defaults are incorrect. 35496 35497`SUCCESS_EXIT_CODE' 35498 A C expression for the status code to be returned when the compiler 35499 exits without serious errors. (Warnings are not serious errors.) 35500 The default is the system-provided macro `EXIT_SUCCESS', or `0' if 35501 the system doesn't define that macro. Define this macro only if 35502 these defaults are incorrect. 35503 35504`USE_C_ALLOCA' 35505 Define this macro if GCC should use the C implementation of 35506 `alloca' provided by `libiberty.a'. This only affects how some 35507 parts of the compiler itself allocate memory. It does not change 35508 code generation. 35509 35510 When GCC is built with a compiler other than itself, the C `alloca' 35511 is always used. This is because most other implementations have 35512 serious bugs. You should define this macro only on a system where 35513 no stack-based `alloca' can possibly work. For instance, if a 35514 system has a small limit on the size of the stack, GCC's builtin 35515 `alloca' will not work reliably. 35516 35517`COLLECT2_HOST_INITIALIZATION' 35518 If defined, a C statement (sans semicolon) that performs 35519 host-dependent initialization when `collect2' is being initialized. 35520 35521`GCC_DRIVER_HOST_INITIALIZATION' 35522 If defined, a C statement (sans semicolon) that performs 35523 host-dependent initialization when a compilation driver is being 35524 initialized. 35525 35526`HOST_LONG_LONG_FORMAT' 35527 If defined, the string used to indicate an argument of type `long 35528 long' to functions like `printf'. The default value is `"ll"'. 35529 35530`HOST_LONG_FORMAT' 35531 If defined, the string used to indicate an argument of type `long' 35532 to functions like `printf'. The default value is `"l"'. 35533 35534`HOST_PTR_PRINTF' 35535 If defined, the string used to indicate an argument of type `void 35536 *' to functions like `printf'. The default value is `"%p"'. 35537 35538 In addition, if `configure' generates an incorrect definition of any 35539of the macros in `auto-host.h', you can override that definition in a 35540host configuration header. If you need to do this, first see if it is 35541possible to fix `configure'. 35542 35543 35544File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top 35545 3554619 Makefile Fragments 35547********************* 35548 35549When you configure GCC using the `configure' script, it will construct 35550the file `Makefile' from the template file `Makefile.in'. When it does 35551this, it can incorporate makefile fragments from the `config' 35552directory. These are used to set Makefile parameters that are not 35553amenable to being calculated by autoconf. The list of fragments to 35554incorporate is set by `config.gcc' (and occasionally `config.build' and 35555`config.host'); *Note System Config::. 35556 35557 Fragments are named either `t-TARGET' or `x-HOST', depending on 35558whether they are relevant to configuring GCC to produce code for a 35559particular target, or to configuring GCC to run on a particular host. 35560Here TARGET and HOST are mnemonics which usually have some relationship 35561to the canonical system name, but no formal connection. 35562 35563 If these files do not exist, it means nothing needs to be added for a 35564given target or host. Most targets need a few `t-TARGET' fragments, 35565but needing `x-HOST' fragments is rare. 35566 35567* Menu: 35568 35569* Target Fragment:: Writing `t-TARGET' files. 35570* Host Fragment:: Writing `x-HOST' files. 35571 35572 35573File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments 35574 3557519.1 Target Makefile Fragments 35576============================== 35577 35578Target makefile fragments can set these Makefile variables. 35579 35580`LIBGCC2_CFLAGS' 35581 Compiler flags to use when compiling `libgcc2.c'. 35582 35583`LIB2FUNCS_EXTRA' 35584 A list of source file names to be compiled or assembled and 35585 inserted into `libgcc.a'. 35586 35587`Floating Point Emulation' 35588 To have GCC include software floating point libraries in `libgcc.a' 35589 define `FPBIT' and `DPBIT' along with a few rules as follows: 35590 # We want fine grained libraries, so use the new code 35591 # to build the floating point emulation libraries. 35592 FPBIT = fp-bit.c 35593 DPBIT = dp-bit.c 35594 35595 35596 fp-bit.c: $(srcdir)/config/fp-bit.c 35597 echo '#define FLOAT' > fp-bit.c 35598 cat $(srcdir)/config/fp-bit.c >> fp-bit.c 35599 35600 dp-bit.c: $(srcdir)/config/fp-bit.c 35601 cat $(srcdir)/config/fp-bit.c > dp-bit.c 35602 35603 You may need to provide additional #defines at the beginning of 35604 `fp-bit.c' and `dp-bit.c' to control target endianness and other 35605 options. 35606 35607`CRTSTUFF_T_CFLAGS' 35608 Special flags used when compiling `crtstuff.c'. *Note 35609 Initialization::. 35610 35611`CRTSTUFF_T_CFLAGS_S' 35612 Special flags used when compiling `crtstuff.c' for shared linking. 35613 Used if you use `crtbeginS.o' and `crtendS.o' in `EXTRA-PARTS'. 35614 *Note Initialization::. 35615 35616`MULTILIB_OPTIONS' 35617 For some targets, invoking GCC in different ways produces objects 35618 that can not be linked together. For example, for some targets GCC 35619 produces both big and little endian code. For these targets, you 35620 must arrange for multiple versions of `libgcc.a' to be compiled, 35621 one for each set of incompatible options. When GCC invokes the 35622 linker, it arranges to link in the right version of `libgcc.a', 35623 based on the command line options used. 35624 35625 The `MULTILIB_OPTIONS' macro lists the set of options for which 35626 special versions of `libgcc.a' must be built. Write options that 35627 are mutually incompatible side by side, separated by a slash. 35628 Write options that may be used together separated by a space. The 35629 build procedure will build all combinations of compatible options. 35630 35631 For example, if you set `MULTILIB_OPTIONS' to `m68000/m68020 35632 msoft-float', `Makefile' will build special versions of `libgcc.a' 35633 using the following sets of options: `-m68000', `-m68020', 35634 `-msoft-float', `-m68000 -msoft-float', and `-m68020 -msoft-float'. 35635 35636`MULTILIB_DIRNAMES' 35637 If `MULTILIB_OPTIONS' is used, this variable specifies the 35638 directory names that should be used to hold the various libraries. 35639 Write one element in `MULTILIB_DIRNAMES' for each element in 35640 `MULTILIB_OPTIONS'. If `MULTILIB_DIRNAMES' is not used, the 35641 default value will be `MULTILIB_OPTIONS', with all slashes treated 35642 as spaces. 35643 35644 For example, if `MULTILIB_OPTIONS' is set to `m68000/m68020 35645 msoft-float', then the default value of `MULTILIB_DIRNAMES' is 35646 `m68000 m68020 msoft-float'. You may specify a different value if 35647 you desire a different set of directory names. 35648 35649`MULTILIB_MATCHES' 35650 Sometimes the same option may be written in two different ways. 35651 If an option is listed in `MULTILIB_OPTIONS', GCC needs to know 35652 about any synonyms. In that case, set `MULTILIB_MATCHES' to a 35653 list of items of the form `option=option' to describe all relevant 35654 synonyms. For example, `m68000=mc68000 m68020=mc68020'. 35655 35656`MULTILIB_EXCEPTIONS' 35657 Sometimes when there are multiple sets of `MULTILIB_OPTIONS' being 35658 specified, there are combinations that should not be built. In 35659 that case, set `MULTILIB_EXCEPTIONS' to be all of the switch 35660 exceptions in shell case syntax that should not be built. 35661 35662 For example the ARM processor cannot execute both hardware floating 35663 point instructions and the reduced size THUMB instructions at the 35664 same time, so there is no need to build libraries with both of 35665 these options enabled. Therefore `MULTILIB_EXCEPTIONS' is set to: 35666 *mthumb/*mhard-float* 35667 35668`MULTILIB_EXTRA_OPTS' 35669 Sometimes it is desirable that when building multiple versions of 35670 `libgcc.a' certain options should always be passed on to the 35671 compiler. In that case, set `MULTILIB_EXTRA_OPTS' to be the list 35672 of options to be used for all builds. If you set this, you should 35673 probably set `CRTSTUFF_T_CFLAGS' to a dash followed by it. 35674 35675`NATIVE_SYSTEM_HEADER_DIR' 35676 If the default location for system headers is not `/usr/include', 35677 you must set this to the directory containing the headers. This 35678 value should match the value of the `SYSTEM_INCLUDE_DIR' macro. 35679 35680`SPECS' 35681 Unfortunately, setting `MULTILIB_EXTRA_OPTS' is not enough, since 35682 it does not affect the build of target libraries, at least not the 35683 build of the default multilib. One possible work-around is to use 35684 `DRIVER_SELF_SPECS' to bring options from the `specs' file as if 35685 they had been passed in the compiler driver command line. 35686 However, you don't want to be adding these options after the 35687 toolchain is installed, so you can instead tweak the `specs' file 35688 that will be used during the toolchain build, while you still 35689 install the original, built-in `specs'. The trick is to set 35690 `SPECS' to some other filename (say `specs.install'), that will 35691 then be created out of the built-in specs, and introduce a 35692 `Makefile' rule to generate the `specs' file that's going to be 35693 used at build time out of your `specs.install'. 35694 35695`T_CFLAGS' 35696 These are extra flags to pass to the C compiler. They are used 35697 both when building GCC, and when compiling things with the 35698 just-built GCC. This variable is deprecated and should not be 35699 used. 35700 35701 35702File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments 35703 3570419.2 Host Makefile Fragments 35705============================ 35706 35707The use of `x-HOST' fragments is discouraged. You should only use it 35708for makefile dependencies. 35709 35710 35711File: gccint.info, Node: Collect2, Next: Header Dirs, Prev: Fragments, Up: Top 35712 3571320 `collect2' 35714************* 35715 35716GCC uses a utility called `collect2' on nearly all systems to arrange 35717to call various initialization functions at start time. 35718 35719 The program `collect2' works by linking the program once and looking 35720through the linker output file for symbols with particular names 35721indicating they are constructor functions. If it finds any, it creates 35722a new temporary `.c' file containing a table of them, compiles it, and 35723links the program a second time including that file. 35724 35725 The actual calls to the constructors are carried out by a subroutine 35726called `__main', which is called (automatically) at the beginning of 35727the body of `main' (provided `main' was compiled with GNU CC). Calling 35728`__main' is necessary, even when compiling C code, to allow linking C 35729and C++ object code together. (If you use `-nostdlib', you get an 35730unresolved reference to `__main', since it's defined in the standard 35731GCC library. Include `-lgcc' at the end of your compiler command line 35732to resolve this reference.) 35733 35734 The program `collect2' is installed as `ld' in the directory where the 35735passes of the compiler are installed. When `collect2' needs to find 35736the _real_ `ld', it tries the following file names: 35737 35738 * a hard coded linker file name, if GCC was configured with the 35739 `--with-ld' option. 35740 35741 * `real-ld' in the directories listed in the compiler's search 35742 directories. 35743 35744 * `real-ld' in the directories listed in the environment variable 35745 `PATH'. 35746 35747 * The file specified in the `REAL_LD_FILE_NAME' configuration macro, 35748 if specified. 35749 35750 * `ld' in the compiler's search directories, except that `collect2' 35751 will not execute itself recursively. 35752 35753 * `ld' in `PATH'. 35754 35755 "The compiler's search directories" means all the directories where 35756`gcc' searches for passes of the compiler. This includes directories 35757that you specify with `-B'. 35758 35759 Cross-compilers search a little differently: 35760 35761 * `real-ld' in the compiler's search directories. 35762 35763 * `TARGET-real-ld' in `PATH'. 35764 35765 * The file specified in the `REAL_LD_FILE_NAME' configuration macro, 35766 if specified. 35767 35768 * `ld' in the compiler's search directories. 35769 35770 * `TARGET-ld' in `PATH'. 35771 35772 `collect2' explicitly avoids running `ld' using the file name under 35773which `collect2' itself was invoked. In fact, it remembers up a list 35774of such names--in case one copy of `collect2' finds another copy (or 35775version) of `collect2' installed as `ld' in a second place in the 35776search path. 35777 35778 `collect2' searches for the utilities `nm' and `strip' using the same 35779algorithm as above for `ld'. 35780 35781 35782File: gccint.info, Node: Header Dirs, Next: Type Information, Prev: Collect2, Up: Top 35783 3578421 Standard Header File Directories 35785*********************************** 35786 35787`GCC_INCLUDE_DIR' means the same thing for native and cross. It is 35788where GCC stores its private include files, and also where GCC stores 35789the fixed include files. A cross compiled GCC runs `fixincludes' on 35790the header files in `$(tooldir)/include'. (If the cross compilation 35791header files need to be fixed, they must be installed before GCC is 35792built. If the cross compilation header files are already suitable for 35793GCC, nothing special need be done). 35794 35795 `GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross. It 35796is where `g++' looks first for header files. The C++ library installs 35797only target independent header files in that directory. 35798 35799 `LOCAL_INCLUDE_DIR' is used only by native compilers. GCC doesn't 35800install anything there. It is normally `/usr/local/include'. This is 35801where local additions to a packaged system should place header files. 35802 35803 `CROSS_INCLUDE_DIR' is used only by cross compilers. GCC doesn't 35804install anything there. 35805 35806 `TOOL_INCLUDE_DIR' is used for both native and cross compilers. It is 35807the place for other packages to install header files that GCC will use. 35808For a cross-compiler, this is the equivalent of `/usr/include'. When 35809you build a cross-compiler, `fixincludes' processes any header files in 35810this directory. 35811 35812 35813File: gccint.info, Node: Type Information, Next: Plugins, Prev: Header Dirs, Up: Top 35814 3581522 Memory Management and Type Information 35816***************************************** 35817 35818GCC uses some fairly sophisticated memory management techniques, which 35819involve determining information about GCC's data structures from GCC's 35820source code and using this information to perform garbage collection and 35821implement precompiled headers. 35822 35823 A full C parser would be too complicated for this task, so a limited 35824subset of C is interpreted and special markers are used to determine 35825what parts of the source to look at. All `struct' and `union' 35826declarations that define data structures that are allocated under 35827control of the garbage collector must be marked. All global variables 35828that hold pointers to garbage-collected memory must also be marked. 35829Finally, all global variables that need to be saved and restored by a 35830precompiled header must be marked. (The precompiled header mechanism 35831can only save static variables if they're scalar. Complex data 35832structures must be allocated in garbage-collected memory to be saved in 35833a precompiled header.) 35834 35835 The full format of a marker is 35836 GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...)) 35837 but in most cases no options are needed. The outer double parentheses 35838are still necessary, though: `GTY(())'. Markers can appear: 35839 35840 * In a structure definition, before the open brace; 35841 35842 * In a global variable declaration, after the keyword `static' or 35843 `extern'; and 35844 35845 * In a structure field definition, before the name of the field. 35846 35847 Here are some examples of marking simple data structures and globals. 35848 35849 struct GTY(()) TAG 35850 { 35851 FIELDS... 35852 }; 35853 35854 typedef struct GTY(()) TAG 35855 { 35856 FIELDS... 35857 } *TYPENAME; 35858 35859 static GTY(()) struct TAG *LIST; /* points to GC memory */ 35860 static GTY(()) int COUNTER; /* save counter in a PCH */ 35861 35862 The parser understands simple typedefs such as `typedef struct TAG 35863*NAME;' and `typedef int NAME;'. These don't need to be marked. 35864 35865* Menu: 35866 35867* GTY Options:: What goes inside a `GTY(())'. 35868* GGC Roots:: Making global variables GGC roots. 35869* Files:: How the generated files work. 35870* Invoking the garbage collector:: How to invoke the garbage collector. 35871 35872 35873File: gccint.info, Node: GTY Options, Next: GGC Roots, Up: Type Information 35874 3587522.1 The Inside of a `GTY(())' 35876============================== 35877 35878Sometimes the C code is not enough to fully describe the type 35879structure. Extra information can be provided with `GTY' options and 35880additional markers. Some options take a parameter, which may be either 35881a string or a type name, depending on the parameter. If an option 35882takes no parameter, it is acceptable either to omit the parameter 35883entirely, or to provide an empty string as a parameter. For example, 35884`GTY ((skip))' and `GTY ((skip ("")))' are equivalent. 35885 35886 When the parameter is a string, often it is a fragment of C code. Four 35887special escapes may be used in these strings, to refer to pieces of the 35888data structure being marked: 35889 35890`%h' 35891 The current structure. 35892 35893`%1' 35894 The structure that immediately contains the current structure. 35895 35896`%0' 35897 The outermost structure that contains the current structure. 35898 35899`%a' 35900 A partial expression of the form `[i1][i2]...' that indexes the 35901 array item currently being marked. 35902 35903 For instance, suppose that you have a structure of the form 35904 struct A { 35905 ... 35906 }; 35907 struct B { 35908 struct A foo[12]; 35909 }; 35910 and `b' is a variable of type `struct B'. When marking `b.foo[11]', 35911`%h' would expand to `b.foo[11]', `%0' and `%1' would both expand to 35912`b', and `%a' would expand to `[11]'. 35913 35914 As in ordinary C, adjacent strings will be concatenated; this is 35915helpful when you have a complicated expression. 35916 GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE" 35917 " ? TYPE_NEXT_VARIANT (&%h.generic)" 35918 " : TREE_CHAIN (&%h.generic)"))) 35919 35920 The available options are: 35921 35922`length ("EXPRESSION")' 35923 There are two places the type machinery will need to be explicitly 35924 told the length of an array. The first case is when a structure 35925 ends in a variable-length array, like this: 35926 struct GTY(()) rtvec_def { 35927 int num_elem; /* number of elements */ 35928 rtx GTY ((length ("%h.num_elem"))) elem[1]; 35929 }; 35930 35931 In this case, the `length' option is used to override the specified 35932 array length (which should usually be `1'). The parameter of the 35933 option is a fragment of C code that calculates the length. 35934 35935 The second case is when a structure or a global variable contains a 35936 pointer to an array, like this: 35937 tree * 35938 GTY ((length ("%h.regno_pointer_align_length"))) regno_decl; 35939 In this case, `regno_decl' has been allocated by writing something 35940 like 35941 x->regno_decl = 35942 ggc_alloc (x->regno_pointer_align_length * sizeof (tree)); 35943 and the `length' provides the length of the field. 35944 35945 This second use of `length' also works on global variables, like: static GTY((length ("reg_base_value_size"))) 35946 rtx *reg_base_value; 35947 35948`skip' 35949 If `skip' is applied to a field, the type machinery will ignore it. 35950 This is somewhat dangerous; the only safe use is in a union when 35951 one field really isn't ever used. 35952 35953`desc ("EXPRESSION")' 35954`tag ("CONSTANT")' 35955`default' 35956 The type machinery needs to be told which field of a `union' is 35957 currently active. This is done by giving each field a constant 35958 `tag' value, and then specifying a discriminator using `desc'. 35959 The value of the expression given by `desc' is compared against 35960 each `tag' value, each of which should be different. If no `tag' 35961 is matched, the field marked with `default' is used if there is 35962 one, otherwise no field in the union will be marked. 35963 35964 In the `desc' option, the "current structure" is the union that it 35965 discriminates. Use `%1' to mean the structure containing it. 35966 There are no escapes available to the `tag' option, since it is a 35967 constant. 35968 35969 For example, 35970 struct GTY(()) tree_binding 35971 { 35972 struct tree_common common; 35973 union tree_binding_u { 35974 tree GTY ((tag ("0"))) scope; 35975 struct cp_binding_level * GTY ((tag ("1"))) level; 35976 } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope; 35977 tree value; 35978 }; 35979 35980 In this example, the value of BINDING_HAS_LEVEL_P when applied to a 35981 `struct tree_binding *' is presumed to be 0 or 1. If 1, the type 35982 mechanism will treat the field `level' as being present and if 0, 35983 will treat the field `scope' as being present. 35984 35985`param_is (TYPE)' 35986`use_param' 35987 Sometimes it's convenient to define some data structure to work on 35988 generic pointers (that is, `PTR') and then use it with a specific 35989 type. `param_is' specifies the real type pointed to, and 35990 `use_param' says where in the generic data structure that type 35991 should be put. 35992 35993 For instance, to have a `htab_t' that points to trees, one would 35994 write the definition of `htab_t' like this: 35995 typedef struct GTY(()) { 35996 ... 35997 void ** GTY ((use_param, ...)) entries; 35998 ... 35999 } htab_t; 36000 and then declare variables like this: 36001 static htab_t GTY ((param_is (union tree_node))) ict; 36002 36003`paramN_is (TYPE)' 36004`use_paramN' 36005 In more complicated cases, the data structure might need to work on 36006 several different types, which might not necessarily all be 36007 pointers. For this, `param1_is' through `param9_is' may be used to 36008 specify the real type of a field identified by `use_param1' through 36009 `use_param9'. 36010 36011`use_params' 36012 When a structure contains another structure that is parameterized, 36013 there's no need to do anything special, the inner structure 36014 inherits the parameters of the outer one. When a structure 36015 contains a pointer to a parameterized structure, the type 36016 machinery won't automatically detect this (it could, it just 36017 doesn't yet), so it's necessary to tell it that the pointed-to 36018 structure should use the same parameters as the outer structure. 36019 This is done by marking the pointer with the `use_params' option. 36020 36021`deletable' 36022 `deletable', when applied to a global variable, indicates that when 36023 garbage collection runs, there's no need to mark anything pointed 36024 to by this variable, it can just be set to `NULL' instead. This 36025 is used to keep a list of free structures around for re-use. 36026 36027`if_marked ("EXPRESSION")' 36028 Suppose you want some kinds of object to be unique, and so you put 36029 them in a hash table. If garbage collection marks the hash table, 36030 these objects will never be freed, even if the last other 36031 reference to them goes away. GGC has special handling to deal 36032 with this: if you use the `if_marked' option on a global hash 36033 table, GGC will call the routine whose name is the parameter to 36034 the option on each hash table entry. If the routine returns 36035 nonzero, the hash table entry will be marked as usual. If the 36036 routine returns zero, the hash table entry will be deleted. 36037 36038 The routine `ggc_marked_p' can be used to determine if an element 36039 has been marked already; in fact, the usual case is to use 36040 `if_marked ("ggc_marked_p")'. 36041 36042`mark_hook ("HOOK-ROUTINE-NAME")' 36043 If provided for a structure or union type, the given 36044 HOOK-ROUTINE-NAME (between double-quotes) is the name of a routine 36045 called when the garbage collector has just marked the data as 36046 reachable. This routine should not change the data, or call any ggc 36047 routine. Its only argument is a pointer to the just marked (const) 36048 structure or union. 36049 36050`maybe_undef' 36051 When applied to a field, `maybe_undef' indicates that it's OK if 36052 the structure that this fields points to is never defined, so long 36053 as this field is always `NULL'. This is used to avoid requiring 36054 backends to define certain optional structures. It doesn't work 36055 with language frontends. 36056 36057`nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")' 36058 The type machinery expects all pointers to point to the start of an 36059 object. Sometimes for abstraction purposes it's convenient to have 36060 a pointer which points inside an object. So long as it's possible 36061 to convert the original object to and from the pointer, such 36062 pointers can still be used. TYPE is the type of the original 36063 object, the TO EXPRESSION returns the pointer given the original 36064 object, and the FROM EXPRESSION returns the original object given 36065 the pointer. The pointer will be available using the `%h' escape. 36066 36067`chain_next ("EXPRESSION")' 36068`chain_prev ("EXPRESSION")' 36069`chain_circular ("EXPRESSION")' 36070 It's helpful for the type machinery to know if objects are often 36071 chained together in long lists; this lets it generate code that 36072 uses less stack space by iterating along the list instead of 36073 recursing down it. `chain_next' is an expression for the next 36074 item in the list, `chain_prev' is an expression for the previous 36075 item. For singly linked lists, use only `chain_next'; for doubly 36076 linked lists, use both. The machinery requires that taking the 36077 next item of the previous item gives the original item. 36078 `chain_circular' is similar to `chain_next', but can be used for 36079 circular single linked lists. 36080 36081`reorder ("FUNCTION NAME")' 36082 Some data structures depend on the relative ordering of pointers. 36083 If the precompiled header machinery needs to change that ordering, 36084 it will call the function referenced by the `reorder' option, 36085 before changing the pointers in the object that's pointed to by 36086 the field the option applies to. The function must take four 36087 arguments, with the signature 36088 `void *, void *, gt_pointer_operator, void *'. The first 36089 parameter is a pointer to the structure that contains the object 36090 being updated, or the object itself if there is no containing 36091 structure. The second parameter is a cookie that should be 36092 ignored. The third parameter is a routine that, given a pointer, 36093 will update it to its correct new value. The fourth parameter is 36094 a cookie that must be passed to the second parameter. 36095 36096 PCH cannot handle data structures that depend on the absolute 36097 values of pointers. `reorder' functions can be expensive. When 36098 possible, it is better to depend on properties of the data, like 36099 an ID number or the hash of a string instead. 36100 36101`special ("NAME")' 36102 The `special' option is used to mark types that have to be dealt 36103 with by special case machinery. The parameter is the name of the 36104 special case. See `gengtype.c' for further details. Avoid adding 36105 new special cases unless there is no other alternative. 36106 36107 36108File: gccint.info, Node: GGC Roots, Next: Files, Prev: GTY Options, Up: Type Information 36109 3611022.2 Marking Roots for the Garbage Collector 36111============================================ 36112 36113In addition to keeping track of types, the type machinery also locates 36114the global variables ("roots") that the garbage collector starts at. 36115Roots must be declared using one of the following syntaxes: 36116 36117 * `extern GTY(([OPTIONS])) TYPE NAME;' 36118 36119 * `static GTY(([OPTIONS])) TYPE NAME;' 36120 The syntax 36121 * `GTY(([OPTIONS])) TYPE NAME;' 36122 is _not_ accepted. There should be an `extern' declaration of such a 36123variable in a header somewhere--mark that, not the definition. Or, if 36124the variable is only used in one file, make it `static'. 36125 36126 36127File: gccint.info, Node: Files, Next: Invoking the garbage collector, Prev: GGC Roots, Up: Type Information 36128 3612922.3 Source Files Containing Type Information 36130============================================= 36131 36132Whenever you add `GTY' markers to a source file that previously had 36133none, or create a new source file containing `GTY' markers, there are 36134three things you need to do: 36135 36136 1. You need to add the file to the list of source files the type 36137 machinery scans. There are four cases: 36138 36139 a. For a back-end file, this is usually done automatically; if 36140 not, you should add it to `target_gtfiles' in the appropriate 36141 port's entries in `config.gcc'. 36142 36143 b. For files shared by all front ends, add the filename to the 36144 `GTFILES' variable in `Makefile.in'. 36145 36146 c. For files that are part of one front end, add the filename to 36147 the `gtfiles' variable defined in the appropriate 36148 `config-lang.in'. For C, the file is `c-config-lang.in'. 36149 Headers should appear before non-headers in this list. 36150 36151 d. For files that are part of some but not all front ends, add 36152 the filename to the `gtfiles' variable of _all_ the front ends 36153 that use it. 36154 36155 2. If the file was a header file, you'll need to check that it's 36156 included in the right place to be visible to the generated files. 36157 For a back-end header file, this should be done automatically. 36158 For a front-end header file, it needs to be included by the same 36159 file that includes `gtype-LANG.h'. For other header files, it 36160 needs to be included in `gtype-desc.c', which is a generated file, 36161 so add it to `ifiles' in `open_base_file' in `gengtype.c'. 36162 36163 For source files that aren't header files, the machinery will 36164 generate a header file that should be included in the source file 36165 you just changed. The file will be called `gt-PATH.h' where PATH 36166 is the pathname relative to the `gcc' directory with slashes 36167 replaced by -, so for example the header file to be included in 36168 `cp/parser.c' is called `gt-cp-parser.c'. The generated header 36169 file should be included after everything else in the source file. 36170 Don't forget to mention this file as a dependency in the 36171 `Makefile'! 36172 36173 36174 For language frontends, there is another file that needs to be included 36175somewhere. It will be called `gtype-LANG.h', where LANG is the name of 36176the subdirectory the language is contained in. 36177 36178 Plugins can add additional root tables. Run the `gengtype' utility in 36179plugin mode as `gengtype -P pluginout.h SOURCE-DIR FILE-LIST PLUGIN*.C' 36180with your plugin files PLUGIN*.C using `GTY' to generate the 36181PLUGINOUT.H file. The GCC build tree is needed to be present in that 36182mode. 36183 36184 36185File: gccint.info, Node: Invoking the garbage collector, Prev: Files, Up: Type Information 36186 3618722.4 How to invoke the garbage collector 36188======================================== 36189 36190The GCC garbage collector GGC is only invoked explicitly. In contrast 36191with many other garbage collectors, it is not implicitly invoked by 36192allocation routines when a lot of memory has been consumed. So the only 36193way to have GGC reclaim storage it to call the `ggc_collect' function 36194explicitly. This call is an expensive operation, as it may have to scan 36195the entire heap. Beware that local variables (on the GCC call stack) 36196are not followed by such an invocation (as many other garbage 36197collectors do): you should reference all your data from static or 36198external `GTY'-ed variables, and it is advised to call `ggc_collect' 36199with a shallow call stack. The GGC is an exact mark and sweep garbage 36200collector (so it does not scan the call stack for pointers). In 36201practice GCC passes don't often call `ggc_collect' themselves, because 36202it is called by the pass manager between passes. 36203 36204 36205File: gccint.info, Node: Plugins, Next: Funding, Prev: Type Information, Up: Top 36206 3620723 Plugins 36208********** 36209 3621023.1 Loading Plugins 36211==================== 36212 36213Plugins are supported on platforms that support `-ldl -rdynamic'. They 36214are loaded by the compiler using `dlopen' and invoked at pre-determined 36215locations in the compilation process. 36216 36217 Plugins are loaded with 36218 36219 `-fplugin=/path/to/NAME.so' `-fplugin-arg-NAME-<key1>[=<value1>]' 36220 36221 The plugin arguments are parsed by GCC and passed to respective 36222plugins as key-value pairs. Multiple plugins can be invoked by 36223specifying multiple `-fplugin' arguments. 36224 3622523.2 Plugin API 36226=============== 36227 36228Plugins are activated by the compiler at specific events as defined in 36229`gcc-plugin.h'. For each event of interest, the plugin should call 36230`register_callback' specifying the name of the event and address of the 36231callback function that will handle that event. 36232 36233 The header `gcc-plugin.h' must be the first gcc header to be included. 36234 3623523.2.1 Plugin license check 36236--------------------------- 36237 36238Every plugin should define the global symbol `plugin_is_GPL_compatible' 36239to assert that it has been licensed under a GPL-compatible license. If 36240this symbol does not exist, the compiler will emit a fatal error and 36241exit with the error message: 36242 36243 fatal error: plugin <name> is not licensed under a GPL-compatible license 36244 <name>: undefined symbol: plugin_is_GPL_compatible 36245 compilation terminated 36246 36247 The type of the symbol is irrelevant. The compiler merely asserts that 36248it exists in the global scope. Something like this is enough: 36249 36250 int plugin_is_GPL_compatible; 36251 3625223.2.2 Plugin initialization 36253---------------------------- 36254 36255Every plugin should export a function called `plugin_init' that is 36256called right after the plugin is loaded. This function is responsible 36257for registering all the callbacks required by the plugin and do any 36258other required initialization. 36259 36260 This function is called from `compile_file' right before invoking the 36261parser. The arguments to `plugin_init' are: 36262 36263 * `plugin_info': Plugin invocation information. 36264 36265 * `version': GCC version. 36266 36267 The `plugin_info' struct is defined as follows: 36268 36269 struct plugin_name_args 36270 { 36271 char *base_name; /* Short name of the plugin 36272 (filename without .so suffix). */ 36273 const char *full_name; /* Path to the plugin as specified with 36274 -fplugin=. */ 36275 int argc; /* Number of arguments specified with 36276 -fplugin-arg-.... */ 36277 struct plugin_argument *argv; /* Array of ARGC key-value pairs. */ 36278 const char *version; /* Version string provided by plugin. */ 36279 const char *help; /* Help string provided by plugin. */ 36280 } 36281 36282 If initialization fails, `plugin_init' must return a non-zero value. 36283Otherwise, it should return 0. 36284 36285 The version of the GCC compiler loading the plugin is described by the 36286following structure: 36287 36288 struct plugin_gcc_version 36289 { 36290 const char *basever; 36291 const char *datestamp; 36292 const char *devphase; 36293 const char *revision; 36294 const char *configuration_arguments; 36295 }; 36296 36297 The function `plugin_default_version_check' takes two pointers to such 36298structure and compare them field by field. It can be used by the 36299plugin's `plugin_init' function. 36300 36301 The version of GCC used to compile the plugin can be found in the 36302symbol `gcc_version' defined in the header `plugin-version.h'. The 36303recommended version check to perform looks like 36304 36305 #include "plugin-version.h" 36306 ... 36307 36308 int 36309 plugin_init (struct plugin_name_args *plugin_info, 36310 struct plugin_gcc_version *version) 36311 { 36312 if (!plugin_default_version_check (version, &gcc_version)) 36313 return 1; 36314 36315 } 36316 36317 but you can also check the individual fields if you want a less strict 36318check. 36319 3632023.2.3 Plugin callbacks 36321----------------------- 36322 36323Callback functions have the following prototype: 36324 36325 /* The prototype for a plugin callback function. 36326 gcc_data - event-specific data provided by GCC 36327 user_data - plugin-specific data provided by the plug-in. */ 36328 typedef void (*plugin_callback_func)(void *gcc_data, void *user_data); 36329 36330 Callbacks can be invoked at the following pre-determined events: 36331 36332 enum plugin_event 36333 { 36334 PLUGIN_PASS_MANAGER_SETUP, /* To hook into pass manager. */ 36335 PLUGIN_FINISH_TYPE, /* After finishing parsing a type. */ 36336 PLUGIN_FINISH_UNIT, /* Useful for summary processing. */ 36337 PLUGIN_PRE_GENERICIZE, /* Allows to see low level AST in C and C++ frontends. */ 36338 PLUGIN_FINISH, /* Called before GCC exits. */ 36339 PLUGIN_INFO, /* Information about the plugin. */ 36340 PLUGIN_GGC_START, /* Called at start of GCC Garbage Collection. */ 36341 PLUGIN_GGC_MARKING, /* Extend the GGC marking. */ 36342 PLUGIN_GGC_END, /* Called at end of GGC. */ 36343 PLUGIN_REGISTER_GGC_ROOTS, /* Register an extra GGC root table. */ 36344 PLUGIN_REGISTER_GGC_CACHES, /* Register an extra GGC cache table. */ 36345 PLUGIN_ATTRIBUTES, /* Called during attribute registration */ 36346 PLUGIN_START_UNIT, /* Called before processing a translation unit. */ 36347 PLUGIN_PRAGMAS, /* Called during pragma registration. */ 36348 /* Called before first pass from all_passes. */ 36349 PLUGIN_ALL_PASSES_START, 36350 /* Called after last pass from all_passes. */ 36351 PLUGIN_ALL_PASSES_END, 36352 /* Called before first ipa pass. */ 36353 PLUGIN_ALL_IPA_PASSES_START, 36354 /* Called after last ipa pass. */ 36355 PLUGIN_ALL_IPA_PASSES_END, 36356 /* Allows to override pass gate decision for current_pass. */ 36357 PLUGIN_OVERRIDE_GATE, 36358 /* Called before executing a pass. */ 36359 PLUGIN_PASS_EXECUTION, 36360 /* Called before executing subpasses of a GIMPLE_PASS in 36361 execute_ipa_pass_list. */ 36362 PLUGIN_EARLY_GIMPLE_PASSES_START, 36363 /* Called after executing subpasses of a GIMPLE_PASS in 36364 execute_ipa_pass_list. */ 36365 PLUGIN_EARLY_GIMPLE_PASSES_END, 36366 /* Called when a pass is first instantiated. */ 36367 PLUGIN_NEW_PASS, 36368 36369 PLUGIN_EVENT_FIRST_DYNAMIC /* Dummy event used for indexing callback 36370 array. */ 36371 }; 36372 36373 In addition, plugins can also look up the enumerator of a named event, 36374and / or generate new events dynamically, by calling the function 36375`get_named_event_id'. 36376 36377 To register a callback, the plugin calls `register_callback' with the 36378arguments: 36379 36380 * `char *name': Plugin name. 36381 36382 * `int event': The event code. 36383 36384 * `plugin_callback_func callback': The function that handles `event'. 36385 36386 * `void *user_data': Pointer to plugin-specific data. 36387 36388 For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, 36389PLUGIN_REGISTER_GGC_ROOTS and PLUGIN_REGISTER_GGC_CACHES pseudo-events 36390the `callback' should be null, and the `user_data' is specific. 36391 36392 When the PLUGIN_PRAGMAS event is triggered (with a null pointer as 36393data from GCC), plugins may register their own pragmas using functions 36394like `c_register_pragma' or `c_register_pragma_with_expansion'. 36395 3639623.3 Interacting with the pass manager 36397====================================== 36398 36399There needs to be a way to add/reorder/remove passes dynamically. This 36400is useful for both analysis plugins (plugging in after a certain pass 36401such as CFG or an IPA pass) and optimization plugins. 36402 36403 Basic support for inserting new passes or replacing existing passes is 36404provided. A plugin registers a new pass with GCC by calling 36405`register_callback' with the `PLUGIN_PASS_MANAGER_SETUP' event and a 36406pointer to a `struct register_pass_info' object defined as follows 36407 36408 enum pass_positioning_ops 36409 { 36410 PASS_POS_INSERT_AFTER, // Insert after the reference pass. 36411 PASS_POS_INSERT_BEFORE, // Insert before the reference pass. 36412 PASS_POS_REPLACE // Replace the reference pass. 36413 }; 36414 36415 struct register_pass_info 36416 { 36417 struct opt_pass *pass; /* New pass provided by the plugin. */ 36418 const char *reference_pass_name; /* Name of the reference pass for hooking 36419 up the new pass. */ 36420 int ref_pass_instance_number; /* Insert the pass at the specified 36421 instance number of the reference pass. */ 36422 /* Do it for every instance if it is 0. */ 36423 enum pass_positioning_ops pos_op; /* how to insert the new pass. */ 36424 }; 36425 36426 36427 /* Sample plugin code that registers a new pass. */ 36428 int 36429 plugin_init (struct plugin_name_args *plugin_info, 36430 struct plugin_gcc_version *version) 36431 { 36432 struct register_pass_info pass_info; 36433 36434 ... 36435 36436 /* Code to fill in the pass_info object with new pass information. */ 36437 36438 ... 36439 36440 /* Register the new pass. */ 36441 register_callback (plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, NULL, &pass_info); 36442 36443 ... 36444 } 36445 3644623.4 Interacting with the GCC Garbage Collector 36447=============================================== 36448 36449Some plugins may want to be informed when GGC (the GCC Garbage 36450Collector) is running. They can register callbacks for the 36451`PLUGIN_GGC_START' and `PLUGIN_GGC_END' events (for which the callback 36452is called with a null `gcc_data') to be notified of the start or end of 36453the GCC garbage collection. 36454 36455 Some plugins may need to have GGC mark additional data. This can be 36456done by registering a callback (called with a null `gcc_data') for the 36457`PLUGIN_GGC_MARKING' event. Such callbacks can call the `ggc_set_mark' 36458routine, preferably thru the `ggc_mark' macro (and conversely, these 36459routines should usually not be used in plugins outside of the 36460`PLUGIN_GGC_MARKING' event). 36461 36462 Some plugins may need to add extra GGC root tables, e.g. to handle 36463their own `GTY'-ed data. This can be done with the 36464`PLUGIN_REGISTER_GGC_ROOTS' pseudo-event with a null callback and the 36465extra root table (of type `struct ggc_root_tab*') as `user_data'. 36466Plugins that want to use the `if_marked' hash table option can add the 36467extra GGC cache tables generated by `gengtype' using the 36468`PLUGIN_REGISTER_GGC_CACHES' pseudo-event with a null callback and the 36469extra cache table (of type `struct ggc_cache_tab*') as `user_data'. 36470Running the `gengtype -p SOURCE-DIR FILE-LIST PLUGIN*.C ...' utility 36471generates these extra root tables. 36472 36473 You should understand the details of memory management inside GCC 36474before using `PLUGIN_GGC_MARKING', `PLUGIN_REGISTER_GGC_ROOTS' or 36475`PLUGIN_REGISTER_GGC_CACHES'. 36476 3647723.5 Giving information about a plugin 36478====================================== 36479 36480A plugin should give some information to the user about itself. This 36481uses the following structure: 36482 36483 struct plugin_info 36484 { 36485 const char *version; 36486 const char *help; 36487 }; 36488 36489 Such a structure is passed as the `user_data' by the plugin's init 36490routine using `register_callback' with the `PLUGIN_INFO' pseudo-event 36491and a null callback. 36492 3649323.6 Registering custom attributes or pragmas 36494============================================= 36495 36496For analysis (or other) purposes it is useful to be able to add custom 36497attributes or pragmas. 36498 36499 The `PLUGIN_ATTRIBUTES' callback is called during attribute 36500registration. Use the `register_attribute' function to register custom 36501attributes. 36502 36503 /* Attribute handler callback */ 36504 static tree 36505 handle_user_attribute (tree *node, tree name, tree args, 36506 int flags, bool *no_add_attrs) 36507 { 36508 return NULL_TREE; 36509 } 36510 36511 /* Attribute definition */ 36512 static struct attribute_spec user_attr = 36513 { "user", 1, 1, false, false, false, handle_user_attribute }; 36514 36515 /* Plugin callback called during attribute registration. 36516 Registered with register_callback (plugin_name, PLUGIN_ATTRIBUTES, register_attributes, NULL) 36517 */ 36518 static void 36519 register_attributes (void *event_data, void *data) 36520 { 36521 warning (0, G_("Callback to register attributes")); 36522 register_attribute (&user_attr); 36523 } 36524 36525 The `PLUGIN_PRAGMAS' callback is called during pragmas registration. 36526Use the `c_register_pragma' or `c_register_pragma_with_expansion' 36527functions to register custom pragmas. 36528 36529 /* Plugin callback called during pragmas registration. Registered with 36530 register_callback (plugin_name, PLUGIN_PRAGMAS, 36531 register_my_pragma, NULL); 36532 */ 36533 static void 36534 register_my_pragma (void *event_data, void *data) 36535 { 36536 warning (0, G_("Callback to register pragmas")); 36537 c_register_pragma ("GCCPLUGIN", "sayhello", handle_pragma_sayhello); 36538 } 36539 36540 It is suggested to pass `"GCCPLUGIN"' (or a short name identifying 36541your plugin) as the "space" argument of your pragma. 36542 3654323.7 Recording information about pass execution 36544=============================================== 36545 36546The event PLUGIN_PASS_EXECUTION passes the pointer to the executed pass 36547(the same as current_pass) as `gcc_data' to the callback. You can also 36548inspect cfun to find out about which function this pass is executed for. 36549Note that this event will only be invoked if the gate check (if 36550applicable, modified by PLUGIN_OVERRIDE_GATE) succeeds. You can use 36551other hooks, like `PLUGIN_ALL_PASSES_START', `PLUGIN_ALL_PASSES_END', 36552`PLUGIN_ALL_IPA_PASSES_START', `PLUGIN_ALL_IPA_PASSES_END', 36553`PLUGIN_EARLY_GIMPLE_PASSES_START', and/or 36554`PLUGIN_EARLY_GIMPLE_PASSES_END' to manipulate global state in your 36555plugin(s) in order to get context for the pass execution. 36556 3655723.8 Controlling which passes are being run 36558=========================================== 36559 36560After the original gate function for a pass is called, its result - the 36561gate status - is stored as an integer. Then the event 36562`PLUGIN_OVERRIDE_GATE' is invoked, with a pointer to the gate status in 36563the `gcc_data' parameter to the callback function. A nonzero value of 36564the gate status means that the pass is to be executed. You can both 36565read and write the gate status via the passed pointer. 36566 3656723.9 Keeping track of available passes 36568====================================== 36569 36570When your plugin is loaded, you can inspect the various pass lists to 36571determine what passes are available. However, other plugins might add 36572new passes. Also, future changes to GCC might cause generic passes to 36573be added after plugin loading. When a pass is first added to one of 36574the pass lists, the event `PLUGIN_NEW_PASS' is invoked, with the 36575callback parameter `gcc_data' pointing to the new pass. 36576 3657723.10 Building GCC plugins 36578========================== 36579 36580If plugins are enabled, GCC installs the headers needed to build a 36581plugin (somewhere in the installation tree, e.g. under `/usr/local'). 36582In particular a `plugin/include' directory is installed, containing all 36583the header files needed to build plugins. 36584 36585 On most systems, you can query this `plugin' directory by invoking 36586`gcc -print-file-name=plugin' (replace if needed `gcc' with the 36587appropriate program path). 36588 36589 The following GNU Makefile excerpt shows how to build a simple plugin: 36590 36591 GCC=gcc 36592 PLUGIN_SOURCE_FILES= plugin1.c plugin2.c 36593 PLUGIN_OBJECT_FILES= $(patsubst %.c,%.o,$(PLUGIN_SOURCE_FILES)) 36594 GCCPLUGINS_DIR:= $(shell $(GCC) -print-file-name=plugin) 36595 CFLAGS+= -I$(GCCPLUGINS_DIR)/include -fPIC -O2 36596 36597 plugin.so: $(PLUGIN_OBJECT_FILES) 36598 $(GCC) -shared $^ -o $@ 36599 36600 A single source file plugin may be built with `gcc -I`gcc 36601-print-file-name=plugin`/include -fPIC -shared -O2 plugin.c -o 36602plugin.so', using backquote shell syntax to query the `plugin' 36603directory. 36604 36605 Plugins needing to use `gengtype' require a GCC build directory for 36606the same version of GCC that they will be linked against. 36607 36608 36609File: gccint.info, Node: Funding, Next: GNU Project, Prev: Plugins, Up: Top 36610 36611Funding Free Software 36612********************* 36613 36614If you want to have more free software a few years from now, it makes 36615sense for you to help encourage people to contribute funds for its 36616development. The most effective approach known is to encourage 36617commercial redistributors to donate. 36618 36619 Users of free software systems can boost the pace of development by 36620encouraging for-a-fee distributors to donate part of their selling price 36621to free software developers--the Free Software Foundation, and others. 36622 36623 The way to convince distributors to do this is to demand it and expect 36624it from them. So when you compare distributors, judge them partly by 36625how much they give to free software development. Show distributors 36626they must compete to be the one who gives the most. 36627 36628 To make this approach work, you must insist on numbers that you can 36629compare, such as, "We will donate ten dollars to the Frobnitz project 36630for each disk sold." Don't be satisfied with a vague promise, such as 36631"A portion of the profits are donated," since it doesn't give a basis 36632for comparison. 36633 36634 Even a precise fraction "of the profits from this disk" is not very 36635meaningful, since creative accounting and unrelated business decisions 36636can greatly alter what fraction of the sales price counts as profit. 36637If the price you pay is $50, ten percent of the profit is probably less 36638than a dollar; it might be a few cents, or nothing at all. 36639 36640 Some redistributors do development work themselves. This is useful 36641too; but to keep everyone honest, you need to inquire how much they do, 36642and what kind. Some kinds of development make much more long-term 36643difference than others. For example, maintaining a separate version of 36644a program contributes very little; maintaining the standard version of a 36645program for the whole community contributes much. Easy new ports 36646contribute little, since someone else would surely do them; difficult 36647ports such as adding a new CPU to the GNU Compiler Collection 36648contribute more; major new features or packages contribute the most. 36649 36650 By establishing the idea that supporting further development is "the 36651proper thing to do" when distributing free software for a fee, we can 36652assure a steady flow of resources into making more free software. 36653 36654 Copyright (C) 1994 Free Software Foundation, Inc. 36655 Verbatim copying and redistribution of this section is permitted 36656 without royalty; alteration is not permitted. 36657 36658 36659File: gccint.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top 36660 36661The GNU Project and GNU/Linux 36662***************************** 36663 36664The GNU Project was launched in 1984 to develop a complete Unix-like 36665operating system which is free software: the GNU system. (GNU is a 36666recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".) 36667Variants of the GNU operating system, which use the kernel Linux, are 36668now widely used; though these systems are often referred to as "Linux", 36669they are more accurately called GNU/Linux systems. 36670 36671 For more information, see: 36672 `http://www.gnu.org/' 36673 `http://www.gnu.org/gnu/linux-and-gnu.html' 36674 36675 36676File: gccint.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top 36677 36678GNU General Public License 36679************************** 36680 36681 Version 3, 29 June 2007 36682 36683 Copyright (C) 2007 Free Software Foundation, Inc. `http://fsf.org/' 36684 36685 Everyone is permitted to copy and distribute verbatim copies of this 36686 license document, but changing it is not allowed. 36687 36688Preamble 36689======== 36690 36691The GNU General Public License is a free, copyleft license for software 36692and other kinds of works. 36693 36694 The licenses for most software and other practical works are designed 36695to take away your freedom to share and change the works. By contrast, 36696the GNU General Public License is intended to guarantee your freedom to 36697share and change all versions of a program-to make sure it remains free 36698software for all its users. We, the Free Software Foundation, use the 36699GNU General Public License for most of our software; it applies also to 36700any other work released this way by its authors. You can apply it to 36701your programs, too. 36702 36703 When we speak of free software, we are referring to freedom, not 36704price. Our General Public Licenses are designed to make sure that you 36705have the freedom to distribute copies of free software (and charge for 36706them if you wish), that you receive source code or can get it if you 36707want it, that you can change the software or use pieces of it in new 36708free programs, and that you know you can do these things. 36709 36710 To protect your rights, we need to prevent others from denying you 36711these rights or asking you to surrender the rights. Therefore, you 36712have certain responsibilities if you distribute copies of the software, 36713or if you modify it: responsibilities to respect the freedom of others. 36714 36715 For example, if you distribute copies of such a program, whether 36716gratis or for a fee, you must pass on to the recipients the same 36717freedoms that you received. You must make sure that they, too, receive 36718or can get the source code. And you must show them these terms so they 36719know their rights. 36720 36721 Developers that use the GNU GPL protect your rights with two steps: 36722(1) assert copyright on the software, and (2) offer you this License 36723giving you legal permission to copy, distribute and/or modify it. 36724 36725 For the developers' and authors' protection, the GPL clearly explains 36726that there is no warranty for this free software. For both users' and 36727authors' sake, the GPL requires that modified versions be marked as 36728changed, so that their problems will not be attributed erroneously to 36729authors of previous versions. 36730 36731 Some devices are designed to deny users access to install or run 36732modified versions of the software inside them, although the 36733manufacturer can do so. This is fundamentally incompatible with the 36734aim of protecting users' freedom to change the software. The 36735systematic pattern of such abuse occurs in the area of products for 36736individuals to use, which is precisely where it is most unacceptable. 36737Therefore, we have designed this version of the GPL to prohibit the 36738practice for those products. If such problems arise substantially in 36739other domains, we stand ready to extend this provision to those domains 36740in future versions of the GPL, as needed to protect the freedom of 36741users. 36742 36743 Finally, every program is threatened constantly by software patents. 36744States should not allow patents to restrict development and use of 36745software on general-purpose computers, but in those that do, we wish to 36746avoid the special danger that patents applied to a free program could 36747make it effectively proprietary. To prevent this, the GPL assures that 36748patents cannot be used to render the program non-free. 36749 36750 The precise terms and conditions for copying, distribution and 36751modification follow. 36752 36753TERMS AND CONDITIONS 36754==================== 36755 36756 0. Definitions. 36757 36758 "This License" refers to version 3 of the GNU General Public 36759 License. 36760 36761 "Copyright" also means copyright-like laws that apply to other 36762 kinds of works, such as semiconductor masks. 36763 36764 "The Program" refers to any copyrightable work licensed under this 36765 License. Each licensee is addressed as "you". "Licensees" and 36766 "recipients" may be individuals or organizations. 36767 36768 To "modify" a work means to copy from or adapt all or part of the 36769 work in a fashion requiring copyright permission, other than the 36770 making of an exact copy. The resulting work is called a "modified 36771 version" of the earlier work or a work "based on" the earlier work. 36772 36773 A "covered work" means either the unmodified Program or a work 36774 based on the Program. 36775 36776 To "propagate" a work means to do anything with it that, without 36777 permission, would make you directly or secondarily liable for 36778 infringement under applicable copyright law, except executing it 36779 on a computer or modifying a private copy. Propagation includes 36780 copying, distribution (with or without modification), making 36781 available to the public, and in some countries other activities as 36782 well. 36783 36784 To "convey" a work means any kind of propagation that enables other 36785 parties to make or receive copies. Mere interaction with a user 36786 through a computer network, with no transfer of a copy, is not 36787 conveying. 36788 36789 An interactive user interface displays "Appropriate Legal Notices" 36790 to the extent that it includes a convenient and prominently visible 36791 feature that (1) displays an appropriate copyright notice, and (2) 36792 tells the user that there is no warranty for the work (except to 36793 the extent that warranties are provided), that licensees may 36794 convey the work under this License, and how to view a copy of this 36795 License. If the interface presents a list of user commands or 36796 options, such as a menu, a prominent item in the list meets this 36797 criterion. 36798 36799 1. Source Code. 36800 36801 The "source code" for a work means the preferred form of the work 36802 for making modifications to it. "Object code" means any 36803 non-source form of a work. 36804 36805 A "Standard Interface" means an interface that either is an 36806 official standard defined by a recognized standards body, or, in 36807 the case of interfaces specified for a particular programming 36808 language, one that is widely used among developers working in that 36809 language. 36810 36811 The "System Libraries" of an executable work include anything, 36812 other than the work as a whole, that (a) is included in the normal 36813 form of packaging a Major Component, but which is not part of that 36814 Major Component, and (b) serves only to enable use of the work 36815 with that Major Component, or to implement a Standard Interface 36816 for which an implementation is available to the public in source 36817 code form. A "Major Component", in this context, means a major 36818 essential component (kernel, window system, and so on) of the 36819 specific operating system (if any) on which the executable work 36820 runs, or a compiler used to produce the work, or an object code 36821 interpreter used to run it. 36822 36823 The "Corresponding Source" for a work in object code form means all 36824 the source code needed to generate, install, and (for an executable 36825 work) run the object code and to modify the work, including 36826 scripts to control those activities. However, it does not include 36827 the work's System Libraries, or general-purpose tools or generally 36828 available free programs which are used unmodified in performing 36829 those activities but which are not part of the work. For example, 36830 Corresponding Source includes interface definition files 36831 associated with source files for the work, and the source code for 36832 shared libraries and dynamically linked subprograms that the work 36833 is specifically designed to require, such as by intimate data 36834 communication or control flow between those subprograms and other 36835 parts of the work. 36836 36837 The Corresponding Source need not include anything that users can 36838 regenerate automatically from other parts of the Corresponding 36839 Source. 36840 36841 The Corresponding Source for a work in source code form is that 36842 same work. 36843 36844 2. Basic Permissions. 36845 36846 All rights granted under this License are granted for the term of 36847 copyright on the Program, and are irrevocable provided the stated 36848 conditions are met. This License explicitly affirms your unlimited 36849 permission to run the unmodified Program. The output from running 36850 a covered work is covered by this License only if the output, 36851 given its content, constitutes a covered work. This License 36852 acknowledges your rights of fair use or other equivalent, as 36853 provided by copyright law. 36854 36855 You may make, run and propagate covered works that you do not 36856 convey, without conditions so long as your license otherwise 36857 remains in force. You may convey covered works to others for the 36858 sole purpose of having them make modifications exclusively for 36859 you, or provide you with facilities for running those works, 36860 provided that you comply with the terms of this License in 36861 conveying all material for which you do not control copyright. 36862 Those thus making or running the covered works for you must do so 36863 exclusively on your behalf, under your direction and control, on 36864 terms that prohibit them from making any copies of your 36865 copyrighted material outside their relationship with you. 36866 36867 Conveying under any other circumstances is permitted solely under 36868 the conditions stated below. Sublicensing is not allowed; section 36869 10 makes it unnecessary. 36870 36871 3. Protecting Users' Legal Rights From Anti-Circumvention Law. 36872 36873 No covered work shall be deemed part of an effective technological 36874 measure under any applicable law fulfilling obligations under 36875 article 11 of the WIPO copyright treaty adopted on 20 December 36876 1996, or similar laws prohibiting or restricting circumvention of 36877 such measures. 36878 36879 When you convey a covered work, you waive any legal power to forbid 36880 circumvention of technological measures to the extent such 36881 circumvention is effected by exercising rights under this License 36882 with respect to the covered work, and you disclaim any intention 36883 to limit operation or modification of the work as a means of 36884 enforcing, against the work's users, your or third parties' legal 36885 rights to forbid circumvention of technological measures. 36886 36887 4. Conveying Verbatim Copies. 36888 36889 You may convey verbatim copies of the Program's source code as you 36890 receive it, in any medium, provided that you conspicuously and 36891 appropriately publish on each copy an appropriate copyright notice; 36892 keep intact all notices stating that this License and any 36893 non-permissive terms added in accord with section 7 apply to the 36894 code; keep intact all notices of the absence of any warranty; and 36895 give all recipients a copy of this License along with the Program. 36896 36897 You may charge any price or no price for each copy that you convey, 36898 and you may offer support or warranty protection for a fee. 36899 36900 5. Conveying Modified Source Versions. 36901 36902 You may convey a work based on the Program, or the modifications to 36903 produce it from the Program, in the form of source code under the 36904 terms of section 4, provided that you also meet all of these 36905 conditions: 36906 36907 a. The work must carry prominent notices stating that you 36908 modified it, and giving a relevant date. 36909 36910 b. The work must carry prominent notices stating that it is 36911 released under this License and any conditions added under 36912 section 7. This requirement modifies the requirement in 36913 section 4 to "keep intact all notices". 36914 36915 c. You must license the entire work, as a whole, under this 36916 License to anyone who comes into possession of a copy. This 36917 License will therefore apply, along with any applicable 36918 section 7 additional terms, to the whole of the work, and all 36919 its parts, regardless of how they are packaged. This License 36920 gives no permission to license the work in any other way, but 36921 it does not invalidate such permission if you have separately 36922 received it. 36923 36924 d. If the work has interactive user interfaces, each must display 36925 Appropriate Legal Notices; however, if the Program has 36926 interactive interfaces that do not display Appropriate Legal 36927 Notices, your work need not make them do so. 36928 36929 A compilation of a covered work with other separate and independent 36930 works, which are not by their nature extensions of the covered 36931 work, and which are not combined with it such as to form a larger 36932 program, in or on a volume of a storage or distribution medium, is 36933 called an "aggregate" if the compilation and its resulting 36934 copyright are not used to limit the access or legal rights of the 36935 compilation's users beyond what the individual works permit. 36936 Inclusion of a covered work in an aggregate does not cause this 36937 License to apply to the other parts of the aggregate. 36938 36939 6. Conveying Non-Source Forms. 36940 36941 You may convey a covered work in object code form under the terms 36942 of sections 4 and 5, provided that you also convey the 36943 machine-readable Corresponding Source under the terms of this 36944 License, in one of these ways: 36945 36946 a. Convey the object code in, or embodied in, a physical product 36947 (including a physical distribution medium), accompanied by the 36948 Corresponding Source fixed on a durable physical medium 36949 customarily used for software interchange. 36950 36951 b. Convey the object code in, or embodied in, a physical product 36952 (including a physical distribution medium), accompanied by a 36953 written offer, valid for at least three years and valid for 36954 as long as you offer spare parts or customer support for that 36955 product model, to give anyone who possesses the object code 36956 either (1) a copy of the Corresponding Source for all the 36957 software in the product that is covered by this License, on a 36958 durable physical medium customarily used for software 36959 interchange, for a price no more than your reasonable cost of 36960 physically performing this conveying of source, or (2) access 36961 to copy the Corresponding Source from a network server at no 36962 charge. 36963 36964 c. Convey individual copies of the object code with a copy of 36965 the written offer to provide the Corresponding Source. This 36966 alternative is allowed only occasionally and noncommercially, 36967 and only if you received the object code with such an offer, 36968 in accord with subsection 6b. 36969 36970 d. Convey the object code by offering access from a designated 36971 place (gratis or for a charge), and offer equivalent access 36972 to the Corresponding Source in the same way through the same 36973 place at no further charge. You need not require recipients 36974 to copy the Corresponding Source along with the object code. 36975 If the place to copy the object code is a network server, the 36976 Corresponding Source may be on a different server (operated 36977 by you or a third party) that supports equivalent copying 36978 facilities, provided you maintain clear directions next to 36979 the object code saying where to find the Corresponding Source. 36980 Regardless of what server hosts the Corresponding Source, you 36981 remain obligated to ensure that it is available for as long 36982 as needed to satisfy these requirements. 36983 36984 e. Convey the object code using peer-to-peer transmission, 36985 provided you inform other peers where the object code and 36986 Corresponding Source of the work are being offered to the 36987 general public at no charge under subsection 6d. 36988 36989 36990 A separable portion of the object code, whose source code is 36991 excluded from the Corresponding Source as a System Library, need 36992 not be included in conveying the object code work. 36993 36994 A "User Product" is either (1) a "consumer product", which means 36995 any tangible personal property which is normally used for personal, 36996 family, or household purposes, or (2) anything designed or sold for 36997 incorporation into a dwelling. In determining whether a product 36998 is a consumer product, doubtful cases shall be resolved in favor of 36999 coverage. For a particular product received by a particular user, 37000 "normally used" refers to a typical or common use of that class of 37001 product, regardless of the status of the particular user or of the 37002 way in which the particular user actually uses, or expects or is 37003 expected to use, the product. A product is a consumer product 37004 regardless of whether the product has substantial commercial, 37005 industrial or non-consumer uses, unless such uses represent the 37006 only significant mode of use of the product. 37007 37008 "Installation Information" for a User Product means any methods, 37009 procedures, authorization keys, or other information required to 37010 install and execute modified versions of a covered work in that 37011 User Product from a modified version of its Corresponding Source. 37012 The information must suffice to ensure that the continued 37013 functioning of the modified object code is in no case prevented or 37014 interfered with solely because modification has been made. 37015 37016 If you convey an object code work under this section in, or with, 37017 or specifically for use in, a User Product, and the conveying 37018 occurs as part of a transaction in which the right of possession 37019 and use of the User Product is transferred to the recipient in 37020 perpetuity or for a fixed term (regardless of how the transaction 37021 is characterized), the Corresponding Source conveyed under this 37022 section must be accompanied by the Installation Information. But 37023 this requirement does not apply if neither you nor any third party 37024 retains the ability to install modified object code on the User 37025 Product (for example, the work has been installed in ROM). 37026 37027 The requirement to provide Installation Information does not 37028 include a requirement to continue to provide support service, 37029 warranty, or updates for a work that has been modified or 37030 installed by the recipient, or for the User Product in which it 37031 has been modified or installed. Access to a network may be denied 37032 when the modification itself materially and adversely affects the 37033 operation of the network or violates the rules and protocols for 37034 communication across the network. 37035 37036 Corresponding Source conveyed, and Installation Information 37037 provided, in accord with this section must be in a format that is 37038 publicly documented (and with an implementation available to the 37039 public in source code form), and must require no special password 37040 or key for unpacking, reading or copying. 37041 37042 7. Additional Terms. 37043 37044 "Additional permissions" are terms that supplement the terms of 37045 this License by making exceptions from one or more of its 37046 conditions. Additional permissions that are applicable to the 37047 entire Program shall be treated as though they were included in 37048 this License, to the extent that they are valid under applicable 37049 law. If additional permissions apply only to part of the Program, 37050 that part may be used separately under those permissions, but the 37051 entire Program remains governed by this License without regard to 37052 the additional permissions. 37053 37054 When you convey a copy of a covered work, you may at your option 37055 remove any additional permissions from that copy, or from any part 37056 of it. (Additional permissions may be written to require their own 37057 removal in certain cases when you modify the work.) You may place 37058 additional permissions on material, added by you to a covered work, 37059 for which you have or can give appropriate copyright permission. 37060 37061 Notwithstanding any other provision of this License, for material 37062 you add to a covered work, you may (if authorized by the copyright 37063 holders of that material) supplement the terms of this License 37064 with terms: 37065 37066 a. Disclaiming warranty or limiting liability differently from 37067 the terms of sections 15 and 16 of this License; or 37068 37069 b. Requiring preservation of specified reasonable legal notices 37070 or author attributions in that material or in the Appropriate 37071 Legal Notices displayed by works containing it; or 37072 37073 c. Prohibiting misrepresentation of the origin of that material, 37074 or requiring that modified versions of such material be 37075 marked in reasonable ways as different from the original 37076 version; or 37077 37078 d. Limiting the use for publicity purposes of names of licensors 37079 or authors of the material; or 37080 37081 e. Declining to grant rights under trademark law for use of some 37082 trade names, trademarks, or service marks; or 37083 37084 f. Requiring indemnification of licensors and authors of that 37085 material by anyone who conveys the material (or modified 37086 versions of it) with contractual assumptions of liability to 37087 the recipient, for any liability that these contractual 37088 assumptions directly impose on those licensors and authors. 37089 37090 All other non-permissive additional terms are considered "further 37091 restrictions" within the meaning of section 10. If the Program as 37092 you received it, or any part of it, contains a notice stating that 37093 it is governed by this License along with a term that is a further 37094 restriction, you may remove that term. If a license document 37095 contains a further restriction but permits relicensing or 37096 conveying under this License, you may add to a covered work 37097 material governed by the terms of that license document, provided 37098 that the further restriction does not survive such relicensing or 37099 conveying. 37100 37101 If you add terms to a covered work in accord with this section, you 37102 must place, in the relevant source files, a statement of the 37103 additional terms that apply to those files, or a notice indicating 37104 where to find the applicable terms. 37105 37106 Additional terms, permissive or non-permissive, may be stated in 37107 the form of a separately written license, or stated as exceptions; 37108 the above requirements apply either way. 37109 37110 8. Termination. 37111 37112 You may not propagate or modify a covered work except as expressly 37113 provided under this License. Any attempt otherwise to propagate or 37114 modify it is void, and will automatically terminate your rights 37115 under this License (including any patent licenses granted under 37116 the third paragraph of section 11). 37117 37118 However, if you cease all violation of this License, then your 37119 license from a particular copyright holder is reinstated (a) 37120 provisionally, unless and until the copyright holder explicitly 37121 and finally terminates your license, and (b) permanently, if the 37122 copyright holder fails to notify you of the violation by some 37123 reasonable means prior to 60 days after the cessation. 37124 37125 Moreover, your license from a particular copyright holder is 37126 reinstated permanently if the copyright holder notifies you of the 37127 violation by some reasonable means, this is the first time you have 37128 received notice of violation of this License (for any work) from 37129 that copyright holder, and you cure the violation prior to 30 days 37130 after your receipt of the notice. 37131 37132 Termination of your rights under this section does not terminate 37133 the licenses of parties who have received copies or rights from 37134 you under this License. If your rights have been terminated and 37135 not permanently reinstated, you do not qualify to receive new 37136 licenses for the same material under section 10. 37137 37138 9. Acceptance Not Required for Having Copies. 37139 37140 You are not required to accept this License in order to receive or 37141 run a copy of the Program. Ancillary propagation of a covered work 37142 occurring solely as a consequence of using peer-to-peer 37143 transmission to receive a copy likewise does not require 37144 acceptance. However, nothing other than this License grants you 37145 permission to propagate or modify any covered work. These actions 37146 infringe copyright if you do not accept this License. Therefore, 37147 by modifying or propagating a covered work, you indicate your 37148 acceptance of this License to do so. 37149 37150 10. Automatic Licensing of Downstream Recipients. 37151 37152 Each time you convey a covered work, the recipient automatically 37153 receives a license from the original licensors, to run, modify and 37154 propagate that work, subject to this License. You are not 37155 responsible for enforcing compliance by third parties with this 37156 License. 37157 37158 An "entity transaction" is a transaction transferring control of an 37159 organization, or substantially all assets of one, or subdividing an 37160 organization, or merging organizations. If propagation of a 37161 covered work results from an entity transaction, each party to that 37162 transaction who receives a copy of the work also receives whatever 37163 licenses to the work the party's predecessor in interest had or 37164 could give under the previous paragraph, plus a right to 37165 possession of the Corresponding Source of the work from the 37166 predecessor in interest, if the predecessor has it or can get it 37167 with reasonable efforts. 37168 37169 You may not impose any further restrictions on the exercise of the 37170 rights granted or affirmed under this License. For example, you 37171 may not impose a license fee, royalty, or other charge for 37172 exercise of rights granted under this License, and you may not 37173 initiate litigation (including a cross-claim or counterclaim in a 37174 lawsuit) alleging that any patent claim is infringed by making, 37175 using, selling, offering for sale, or importing the Program or any 37176 portion of it. 37177 37178 11. Patents. 37179 37180 A "contributor" is a copyright holder who authorizes use under this 37181 License of the Program or a work on which the Program is based. 37182 The work thus licensed is called the contributor's "contributor 37183 version". 37184 37185 A contributor's "essential patent claims" are all patent claims 37186 owned or controlled by the contributor, whether already acquired or 37187 hereafter acquired, that would be infringed by some manner, 37188 permitted by this License, of making, using, or selling its 37189 contributor version, but do not include claims that would be 37190 infringed only as a consequence of further modification of the 37191 contributor version. For purposes of this definition, "control" 37192 includes the right to grant patent sublicenses in a manner 37193 consistent with the requirements of this License. 37194 37195 Each contributor grants you a non-exclusive, worldwide, 37196 royalty-free patent license under the contributor's essential 37197 patent claims, to make, use, sell, offer for sale, import and 37198 otherwise run, modify and propagate the contents of its 37199 contributor version. 37200 37201 In the following three paragraphs, a "patent license" is any 37202 express agreement or commitment, however denominated, not to 37203 enforce a patent (such as an express permission to practice a 37204 patent or covenant not to sue for patent infringement). To 37205 "grant" such a patent license to a party means to make such an 37206 agreement or commitment not to enforce a patent against the party. 37207 37208 If you convey a covered work, knowingly relying on a patent 37209 license, and the Corresponding Source of the work is not available 37210 for anyone to copy, free of charge and under the terms of this 37211 License, through a publicly available network server or other 37212 readily accessible means, then you must either (1) cause the 37213 Corresponding Source to be so available, or (2) arrange to deprive 37214 yourself of the benefit of the patent license for this particular 37215 work, or (3) arrange, in a manner consistent with the requirements 37216 of this License, to extend the patent license to downstream 37217 recipients. "Knowingly relying" means you have actual knowledge 37218 that, but for the patent license, your conveying the covered work 37219 in a country, or your recipient's use of the covered work in a 37220 country, would infringe one or more identifiable patents in that 37221 country that you have reason to believe are valid. 37222 37223 If, pursuant to or in connection with a single transaction or 37224 arrangement, you convey, or propagate by procuring conveyance of, a 37225 covered work, and grant a patent license to some of the parties 37226 receiving the covered work authorizing them to use, propagate, 37227 modify or convey a specific copy of the covered work, then the 37228 patent license you grant is automatically extended to all 37229 recipients of the covered work and works based on it. 37230 37231 A patent license is "discriminatory" if it does not include within 37232 the scope of its coverage, prohibits the exercise of, or is 37233 conditioned on the non-exercise of one or more of the rights that 37234 are specifically granted under this License. You may not convey a 37235 covered work if you are a party to an arrangement with a third 37236 party that is in the business of distributing software, under 37237 which you make payment to the third party based on the extent of 37238 your activity of conveying the work, and under which the third 37239 party grants, to any of the parties who would receive the covered 37240 work from you, a discriminatory patent license (a) in connection 37241 with copies of the covered work conveyed by you (or copies made 37242 from those copies), or (b) primarily for and in connection with 37243 specific products or compilations that contain the covered work, 37244 unless you entered into that arrangement, or that patent license 37245 was granted, prior to 28 March 2007. 37246 37247 Nothing in this License shall be construed as excluding or limiting 37248 any implied license or other defenses to infringement that may 37249 otherwise be available to you under applicable patent law. 37250 37251 12. No Surrender of Others' Freedom. 37252 37253 If conditions are imposed on you (whether by court order, 37254 agreement or otherwise) that contradict the conditions of this 37255 License, they do not excuse you from the conditions of this 37256 License. If you cannot convey a covered work so as to satisfy 37257 simultaneously your obligations under this License and any other 37258 pertinent obligations, then as a consequence you may not convey it 37259 at all. For example, if you agree to terms that obligate you to 37260 collect a royalty for further conveying from those to whom you 37261 convey the Program, the only way you could satisfy both those 37262 terms and this License would be to refrain entirely from conveying 37263 the Program. 37264 37265 13. Use with the GNU Affero General Public License. 37266 37267 Notwithstanding any other provision of this License, you have 37268 permission to link or combine any covered work with a work licensed 37269 under version 3 of the GNU Affero General Public License into a 37270 single combined work, and to convey the resulting work. The terms 37271 of this License will continue to apply to the part which is the 37272 covered work, but the special requirements of the GNU Affero 37273 General Public License, section 13, concerning interaction through 37274 a network will apply to the combination as such. 37275 37276 14. Revised Versions of this License. 37277 37278 The Free Software Foundation may publish revised and/or new 37279 versions of the GNU General Public License from time to time. 37280 Such new versions will be similar in spirit to the present 37281 version, but may differ in detail to address new problems or 37282 concerns. 37283 37284 Each version is given a distinguishing version number. If the 37285 Program specifies that a certain numbered version of the GNU 37286 General Public License "or any later version" applies to it, you 37287 have the option of following the terms and conditions either of 37288 that numbered version or of any later version published by the 37289 Free Software Foundation. If the Program does not specify a 37290 version number of the GNU General Public License, you may choose 37291 any version ever published by the Free Software Foundation. 37292 37293 If the Program specifies that a proxy can decide which future 37294 versions of the GNU General Public License can be used, that 37295 proxy's public statement of acceptance of a version permanently 37296 authorizes you to choose that version for the Program. 37297 37298 Later license versions may give you additional or different 37299 permissions. However, no additional obligations are imposed on any 37300 author or copyright holder as a result of your choosing to follow a 37301 later version. 37302 37303 15. Disclaimer of Warranty. 37304 37305 THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY 37306 APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE 37307 COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" 37308 WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, 37309 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 37310 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE 37311 RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. 37312 SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL 37313 NECESSARY SERVICING, REPAIR OR CORRECTION. 37314 37315 16. Limitation of Liability. 37316 37317 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN 37318 WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES 37319 AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU 37320 FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR 37321 CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE 37322 THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA 37323 BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD 37324 PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER 37325 PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF 37326 THE POSSIBILITY OF SUCH DAMAGES. 37327 37328 17. Interpretation of Sections 15 and 16. 37329 37330 If the disclaimer of warranty and limitation of liability provided 37331 above cannot be given local legal effect according to their terms, 37332 reviewing courts shall apply local law that most closely 37333 approximates an absolute waiver of all civil liability in 37334 connection with the Program, unless a warranty or assumption of 37335 liability accompanies a copy of the Program in return for a fee. 37336 37337 37338END OF TERMS AND CONDITIONS 37339=========================== 37340 37341How to Apply These Terms to Your New Programs 37342============================================= 37343 37344If you develop a new program, and you want it to be of the greatest 37345possible use to the public, the best way to achieve this is to make it 37346free software which everyone can redistribute and change under these 37347terms. 37348 37349 To do so, attach the following notices to the program. It is safest 37350to attach them to the start of each source file to most effectively 37351state the exclusion of warranty; and each file should have at least the 37352"copyright" line and a pointer to where the full notice is found. 37353 37354 ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES. 37355 Copyright (C) YEAR NAME OF AUTHOR 37356 37357 This program is free software: you can redistribute it and/or modify 37358 it under the terms of the GNU General Public License as published by 37359 the Free Software Foundation, either version 3 of the License, or (at 37360 your option) any later version. 37361 37362 This program is distributed in the hope that it will be useful, but 37363 WITHOUT ANY WARRANTY; without even the implied warranty of 37364 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU 37365 General Public License for more details. 37366 37367 You should have received a copy of the GNU General Public License 37368 along with this program. If not, see `http://www.gnu.org/licenses/'. 37369 37370 Also add information on how to contact you by electronic and paper 37371mail. 37372 37373 If the program does terminal interaction, make it output a short 37374notice like this when it starts in an interactive mode: 37375 37376 PROGRAM Copyright (C) YEAR NAME OF AUTHOR 37377 This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'. 37378 This is free software, and you are welcome to redistribute it 37379 under certain conditions; type `show c' for details. 37380 37381 The hypothetical commands `show w' and `show c' should show the 37382appropriate parts of the General Public License. Of course, your 37383program's commands might be different; for a GUI interface, you would 37384use an "about box". 37385 37386 You should also get your employer (if you work as a programmer) or 37387school, if any, to sign a "copyright disclaimer" for the program, if 37388necessary. For more information on this, and how to apply and follow 37389the GNU GPL, see `http://www.gnu.org/licenses/'. 37390 37391 The GNU General Public License does not permit incorporating your 37392program into proprietary programs. If your program is a subroutine 37393library, you may consider it more useful to permit linking proprietary 37394applications with the library. If this is what you want to do, use the 37395GNU Lesser General Public License instead of this License. But first, 37396please read `http://www.gnu.org/philosophy/why-not-lgpl.html'. 37397 37398 37399File: gccint.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top 37400 37401GNU Free Documentation License 37402****************************** 37403 37404 Version 1.2, November 2002 37405 37406 Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 37407 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA 37408 37409 Everyone is permitted to copy and distribute verbatim copies 37410 of this license document, but changing it is not allowed. 37411 37412 0. PREAMBLE 37413 37414 The purpose of this License is to make a manual, textbook, or other 37415 functional and useful document "free" in the sense of freedom: to 37416 assure everyone the effective freedom to copy and redistribute it, 37417 with or without modifying it, either commercially or 37418 noncommercially. Secondarily, this License preserves for the 37419 author and publisher a way to get credit for their work, while not 37420 being considered responsible for modifications made by others. 37421 37422 This License is a kind of "copyleft", which means that derivative 37423 works of the document must themselves be free in the same sense. 37424 It complements the GNU General Public License, which is a copyleft 37425 license designed for free software. 37426 37427 We have designed this License in order to use it for manuals for 37428 free software, because free software needs free documentation: a 37429 free program should come with manuals providing the same freedoms 37430 that the software does. But this License is not limited to 37431 software manuals; it can be used for any textual work, regardless 37432 of subject matter or whether it is published as a printed book. 37433 We recommend this License principally for works whose purpose is 37434 instruction or reference. 37435 37436 1. APPLICABILITY AND DEFINITIONS 37437 37438 This License applies to any manual or other work, in any medium, 37439 that contains a notice placed by the copyright holder saying it 37440 can be distributed under the terms of this License. Such a notice 37441 grants a world-wide, royalty-free license, unlimited in duration, 37442 to use that work under the conditions stated herein. The 37443 "Document", below, refers to any such manual or work. Any member 37444 of the public is a licensee, and is addressed as "you". You 37445 accept the license if you copy, modify or distribute the work in a 37446 way requiring permission under copyright law. 37447 37448 A "Modified Version" of the Document means any work containing the 37449 Document or a portion of it, either copied verbatim, or with 37450 modifications and/or translated into another language. 37451 37452 A "Secondary Section" is a named appendix or a front-matter section 37453 of the Document that deals exclusively with the relationship of the 37454 publishers or authors of the Document to the Document's overall 37455 subject (or to related matters) and contains nothing that could 37456 fall directly within that overall subject. (Thus, if the Document 37457 is in part a textbook of mathematics, a Secondary Section may not 37458 explain any mathematics.) The relationship could be a matter of 37459 historical connection with the subject or with related matters, or 37460 of legal, commercial, philosophical, ethical or political position 37461 regarding them. 37462 37463 The "Invariant Sections" are certain Secondary Sections whose 37464 titles are designated, as being those of Invariant Sections, in 37465 the notice that says that the Document is released under this 37466 License. If a section does not fit the above definition of 37467 Secondary then it is not allowed to be designated as Invariant. 37468 The Document may contain zero Invariant Sections. If the Document 37469 does not identify any Invariant Sections then there are none. 37470 37471 The "Cover Texts" are certain short passages of text that are 37472 listed, as Front-Cover Texts or Back-Cover Texts, in the notice 37473 that says that the Document is released under this License. A 37474 Front-Cover Text may be at most 5 words, and a Back-Cover Text may 37475 be at most 25 words. 37476 37477 A "Transparent" copy of the Document means a machine-readable copy, 37478 represented in a format whose specification is available to the 37479 general public, that is suitable for revising the document 37480 straightforwardly with generic text editors or (for images 37481 composed of pixels) generic paint programs or (for drawings) some 37482 widely available drawing editor, and that is suitable for input to 37483 text formatters or for automatic translation to a variety of 37484 formats suitable for input to text formatters. A copy made in an 37485 otherwise Transparent file format whose markup, or absence of 37486 markup, has been arranged to thwart or discourage subsequent 37487 modification by readers is not Transparent. An image format is 37488 not Transparent if used for any substantial amount of text. A 37489 copy that is not "Transparent" is called "Opaque". 37490 37491 Examples of suitable formats for Transparent copies include plain 37492 ASCII without markup, Texinfo input format, LaTeX input format, 37493 SGML or XML using a publicly available DTD, and 37494 standard-conforming simple HTML, PostScript or PDF designed for 37495 human modification. Examples of transparent image formats include 37496 PNG, XCF and JPG. Opaque formats include proprietary formats that 37497 can be read and edited only by proprietary word processors, SGML or 37498 XML for which the DTD and/or processing tools are not generally 37499 available, and the machine-generated HTML, PostScript or PDF 37500 produced by some word processors for output purposes only. 37501 37502 The "Title Page" means, for a printed book, the title page itself, 37503 plus such following pages as are needed to hold, legibly, the 37504 material this License requires to appear in the title page. For 37505 works in formats which do not have any title page as such, "Title 37506 Page" means the text near the most prominent appearance of the 37507 work's title, preceding the beginning of the body of the text. 37508 37509 A section "Entitled XYZ" means a named subunit of the Document 37510 whose title either is precisely XYZ or contains XYZ in parentheses 37511 following text that translates XYZ in another language. (Here XYZ 37512 stands for a specific section name mentioned below, such as 37513 "Acknowledgements", "Dedications", "Endorsements", or "History".) 37514 To "Preserve the Title" of such a section when you modify the 37515 Document means that it remains a section "Entitled XYZ" according 37516 to this definition. 37517 37518 The Document may include Warranty Disclaimers next to the notice 37519 which states that this License applies to the Document. These 37520 Warranty Disclaimers are considered to be included by reference in 37521 this License, but only as regards disclaiming warranties: any other 37522 implication that these Warranty Disclaimers may have is void and 37523 has no effect on the meaning of this License. 37524 37525 2. VERBATIM COPYING 37526 37527 You may copy and distribute the Document in any medium, either 37528 commercially or noncommercially, provided that this License, the 37529 copyright notices, and the license notice saying this License 37530 applies to the Document are reproduced in all copies, and that you 37531 add no other conditions whatsoever to those of this License. You 37532 may not use technical measures to obstruct or control the reading 37533 or further copying of the copies you make or distribute. However, 37534 you may accept compensation in exchange for copies. If you 37535 distribute a large enough number of copies you must also follow 37536 the conditions in section 3. 37537 37538 You may also lend copies, under the same conditions stated above, 37539 and you may publicly display copies. 37540 37541 3. COPYING IN QUANTITY 37542 37543 If you publish printed copies (or copies in media that commonly 37544 have printed covers) of the Document, numbering more than 100, and 37545 the Document's license notice requires Cover Texts, you must 37546 enclose the copies in covers that carry, clearly and legibly, all 37547 these Cover Texts: Front-Cover Texts on the front cover, and 37548 Back-Cover Texts on the back cover. Both covers must also clearly 37549 and legibly identify you as the publisher of these copies. The 37550 front cover must present the full title with all words of the 37551 title equally prominent and visible. You may add other material 37552 on the covers in addition. Copying with changes limited to the 37553 covers, as long as they preserve the title of the Document and 37554 satisfy these conditions, can be treated as verbatim copying in 37555 other respects. 37556 37557 If the required texts for either cover are too voluminous to fit 37558 legibly, you should put the first ones listed (as many as fit 37559 reasonably) on the actual cover, and continue the rest onto 37560 adjacent pages. 37561 37562 If you publish or distribute Opaque copies of the Document 37563 numbering more than 100, you must either include a 37564 machine-readable Transparent copy along with each Opaque copy, or 37565 state in or with each Opaque copy a computer-network location from 37566 which the general network-using public has access to download 37567 using public-standard network protocols a complete Transparent 37568 copy of the Document, free of added material. If you use the 37569 latter option, you must take reasonably prudent steps, when you 37570 begin distribution of Opaque copies in quantity, to ensure that 37571 this Transparent copy will remain thus accessible at the stated 37572 location until at least one year after the last time you 37573 distribute an Opaque copy (directly or through your agents or 37574 retailers) of that edition to the public. 37575 37576 It is requested, but not required, that you contact the authors of 37577 the Document well before redistributing any large number of 37578 copies, to give them a chance to provide you with an updated 37579 version of the Document. 37580 37581 4. MODIFICATIONS 37582 37583 You may copy and distribute a Modified Version of the Document 37584 under the conditions of sections 2 and 3 above, provided that you 37585 release the Modified Version under precisely this License, with 37586 the Modified Version filling the role of the Document, thus 37587 licensing distribution and modification of the Modified Version to 37588 whoever possesses a copy of it. In addition, you must do these 37589 things in the Modified Version: 37590 37591 A. Use in the Title Page (and on the covers, if any) a title 37592 distinct from that of the Document, and from those of 37593 previous versions (which should, if there were any, be listed 37594 in the History section of the Document). You may use the 37595 same title as a previous version if the original publisher of 37596 that version gives permission. 37597 37598 B. List on the Title Page, as authors, one or more persons or 37599 entities responsible for authorship of the modifications in 37600 the Modified Version, together with at least five of the 37601 principal authors of the Document (all of its principal 37602 authors, if it has fewer than five), unless they release you 37603 from this requirement. 37604 37605 C. State on the Title page the name of the publisher of the 37606 Modified Version, as the publisher. 37607 37608 D. Preserve all the copyright notices of the Document. 37609 37610 E. Add an appropriate copyright notice for your modifications 37611 adjacent to the other copyright notices. 37612 37613 F. Include, immediately after the copyright notices, a license 37614 notice giving the public permission to use the Modified 37615 Version under the terms of this License, in the form shown in 37616 the Addendum below. 37617 37618 G. Preserve in that license notice the full lists of Invariant 37619 Sections and required Cover Texts given in the Document's 37620 license notice. 37621 37622 H. Include an unaltered copy of this License. 37623 37624 I. Preserve the section Entitled "History", Preserve its Title, 37625 and add to it an item stating at least the title, year, new 37626 authors, and publisher of the Modified Version as given on 37627 the Title Page. If there is no section Entitled "History" in 37628 the Document, create one stating the title, year, authors, 37629 and publisher of the Document as given on its Title Page, 37630 then add an item describing the Modified Version as stated in 37631 the previous sentence. 37632 37633 J. Preserve the network location, if any, given in the Document 37634 for public access to a Transparent copy of the Document, and 37635 likewise the network locations given in the Document for 37636 previous versions it was based on. These may be placed in 37637 the "History" section. You may omit a network location for a 37638 work that was published at least four years before the 37639 Document itself, or if the original publisher of the version 37640 it refers to gives permission. 37641 37642 K. For any section Entitled "Acknowledgements" or "Dedications", 37643 Preserve the Title of the section, and preserve in the 37644 section all the substance and tone of each of the contributor 37645 acknowledgements and/or dedications given therein. 37646 37647 L. Preserve all the Invariant Sections of the Document, 37648 unaltered in their text and in their titles. Section numbers 37649 or the equivalent are not considered part of the section 37650 titles. 37651 37652 M. Delete any section Entitled "Endorsements". Such a section 37653 may not be included in the Modified Version. 37654 37655 N. Do not retitle any existing section to be Entitled 37656 "Endorsements" or to conflict in title with any Invariant 37657 Section. 37658 37659 O. Preserve any Warranty Disclaimers. 37660 37661 If the Modified Version includes new front-matter sections or 37662 appendices that qualify as Secondary Sections and contain no 37663 material copied from the Document, you may at your option 37664 designate some or all of these sections as invariant. To do this, 37665 add their titles to the list of Invariant Sections in the Modified 37666 Version's license notice. These titles must be distinct from any 37667 other section titles. 37668 37669 You may add a section Entitled "Endorsements", provided it contains 37670 nothing but endorsements of your Modified Version by various 37671 parties--for example, statements of peer review or that the text 37672 has been approved by an organization as the authoritative 37673 definition of a standard. 37674 37675 You may add a passage of up to five words as a Front-Cover Text, 37676 and a passage of up to 25 words as a Back-Cover Text, to the end 37677 of the list of Cover Texts in the Modified Version. Only one 37678 passage of Front-Cover Text and one of Back-Cover Text may be 37679 added by (or through arrangements made by) any one entity. If the 37680 Document already includes a cover text for the same cover, 37681 previously added by you or by arrangement made by the same entity 37682 you are acting on behalf of, you may not add another; but you may 37683 replace the old one, on explicit permission from the previous 37684 publisher that added the old one. 37685 37686 The author(s) and publisher(s) of the Document do not by this 37687 License give permission to use their names for publicity for or to 37688 assert or imply endorsement of any Modified Version. 37689 37690 5. COMBINING DOCUMENTS 37691 37692 You may combine the Document with other documents released under 37693 this License, under the terms defined in section 4 above for 37694 modified versions, provided that you include in the combination 37695 all of the Invariant Sections of all of the original documents, 37696 unmodified, and list them all as Invariant Sections of your 37697 combined work in its license notice, and that you preserve all 37698 their Warranty Disclaimers. 37699 37700 The combined work need only contain one copy of this License, and 37701 multiple identical Invariant Sections may be replaced with a single 37702 copy. If there are multiple Invariant Sections with the same name 37703 but different contents, make the title of each such section unique 37704 by adding at the end of it, in parentheses, the name of the 37705 original author or publisher of that section if known, or else a 37706 unique number. Make the same adjustment to the section titles in 37707 the list of Invariant Sections in the license notice of the 37708 combined work. 37709 37710 In the combination, you must combine any sections Entitled 37711 "History" in the various original documents, forming one section 37712 Entitled "History"; likewise combine any sections Entitled 37713 "Acknowledgements", and any sections Entitled "Dedications". You 37714 must delete all sections Entitled "Endorsements." 37715 37716 6. COLLECTIONS OF DOCUMENTS 37717 37718 You may make a collection consisting of the Document and other 37719 documents released under this License, and replace the individual 37720 copies of this License in the various documents with a single copy 37721 that is included in the collection, provided that you follow the 37722 rules of this License for verbatim copying of each of the 37723 documents in all other respects. 37724 37725 You may extract a single document from such a collection, and 37726 distribute it individually under this License, provided you insert 37727 a copy of this License into the extracted document, and follow 37728 this License in all other respects regarding verbatim copying of 37729 that document. 37730 37731 7. AGGREGATION WITH INDEPENDENT WORKS 37732 37733 A compilation of the Document or its derivatives with other 37734 separate and independent documents or works, in or on a volume of 37735 a storage or distribution medium, is called an "aggregate" if the 37736 copyright resulting from the compilation is not used to limit the 37737 legal rights of the compilation's users beyond what the individual 37738 works permit. When the Document is included in an aggregate, this 37739 License does not apply to the other works in the aggregate which 37740 are not themselves derivative works of the Document. 37741 37742 If the Cover Text requirement of section 3 is applicable to these 37743 copies of the Document, then if the Document is less than one half 37744 of the entire aggregate, the Document's Cover Texts may be placed 37745 on covers that bracket the Document within the aggregate, or the 37746 electronic equivalent of covers if the Document is in electronic 37747 form. Otherwise they must appear on printed covers that bracket 37748 the whole aggregate. 37749 37750 8. TRANSLATION 37751 37752 Translation is considered a kind of modification, so you may 37753 distribute translations of the Document under the terms of section 37754 4. Replacing Invariant Sections with translations requires special 37755 permission from their copyright holders, but you may include 37756 translations of some or all Invariant Sections in addition to the 37757 original versions of these Invariant Sections. You may include a 37758 translation of this License, and all the license notices in the 37759 Document, and any Warranty Disclaimers, provided that you also 37760 include the original English version of this License and the 37761 original versions of those notices and disclaimers. In case of a 37762 disagreement between the translation and the original version of 37763 this License or a notice or disclaimer, the original version will 37764 prevail. 37765 37766 If a section in the Document is Entitled "Acknowledgements", 37767 "Dedications", or "History", the requirement (section 4) to 37768 Preserve its Title (section 1) will typically require changing the 37769 actual title. 37770 37771 9. TERMINATION 37772 37773 You may not copy, modify, sublicense, or distribute the Document 37774 except as expressly provided for under this License. Any other 37775 attempt to copy, modify, sublicense or distribute the Document is 37776 void, and will automatically terminate your rights under this 37777 License. However, parties who have received copies, or rights, 37778 from you under this License will not have their licenses 37779 terminated so long as such parties remain in full compliance. 37780 37781 10. FUTURE REVISIONS OF THIS LICENSE 37782 37783 The Free Software Foundation may publish new, revised versions of 37784 the GNU Free Documentation License from time to time. Such new 37785 versions will be similar in spirit to the present version, but may 37786 differ in detail to address new problems or concerns. See 37787 `http://www.gnu.org/copyleft/'. 37788 37789 Each version of the License is given a distinguishing version 37790 number. If the Document specifies that a particular numbered 37791 version of this License "or any later version" applies to it, you 37792 have the option of following the terms and conditions either of 37793 that specified version or of any later version that has been 37794 published (not as a draft) by the Free Software Foundation. If 37795 the Document does not specify a version number of this License, 37796 you may choose any version ever published (not as a draft) by the 37797 Free Software Foundation. 37798 37799ADDENDUM: How to use this License for your documents 37800==================================================== 37801 37802To use this License in a document you have written, include a copy of 37803the License in the document and put the following copyright and license 37804notices just after the title page: 37805 37806 Copyright (C) YEAR YOUR NAME. 37807 Permission is granted to copy, distribute and/or modify this document 37808 under the terms of the GNU Free Documentation License, Version 1.2 37809 or any later version published by the Free Software Foundation; 37810 with no Invariant Sections, no Front-Cover Texts, and no Back-Cover 37811 Texts. A copy of the license is included in the section entitled ``GNU 37812 Free Documentation License''. 37813 37814 If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, 37815replace the "with...Texts." line with this: 37816 37817 with the Invariant Sections being LIST THEIR TITLES, with 37818 the Front-Cover Texts being LIST, and with the Back-Cover Texts 37819 being LIST. 37820 37821 If you have Invariant Sections without Cover Texts, or some other 37822combination of the three, merge those two alternatives to suit the 37823situation. 37824 37825 If your document contains nontrivial examples of program code, we 37826recommend releasing these examples in parallel under your choice of 37827free software license, such as the GNU General Public License, to 37828permit their use in free software. 37829 37830 37831File: gccint.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top 37832 37833Contributors to GCC 37834******************* 37835 37836The GCC project would like to thank its many contributors. Without 37837them the project would not have been nearly as successful as it has 37838been. Any omissions in this list are accidental. Feel free to contact 37839<law@redhat.com> or <gerald@pfeifer.com> if you have been left out or 37840some of your contributions are not listed. Please keep this list in 37841alphabetical order. 37842 37843 * Analog Devices helped implement the support for complex data types 37844 and iterators. 37845 37846 * John David Anglin for threading-related fixes and improvements to 37847 libstdc++-v3, and the HP-UX port. 37848 37849 * James van Artsdalen wrote the code that makes efficient use of the 37850 Intel 80387 register stack. 37851 37852 * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta 37853 Series port. 37854 37855 * Alasdair Baird for various bug fixes. 37856 37857 * Giovanni Bajo for analyzing lots of complicated C++ problem 37858 reports. 37859 37860 * Peter Barada for his work to improve code generation for new 37861 ColdFire cores. 37862 37863 * Gerald Baumgartner added the signature extension to the C++ front 37864 end. 37865 37866 * Godmar Back for his Java improvements and encouragement. 37867 37868 * Scott Bambrough for help porting the Java compiler. 37869 37870 * Wolfgang Bangerth for processing tons of bug reports. 37871 37872 * Jon Beniston for his Microsoft Windows port of Java and port to 37873 Lattice Mico32. 37874 37875 * Daniel Berlin for better DWARF2 support, faster/better 37876 optimizations, improved alias analysis, plus migrating GCC to 37877 Bugzilla. 37878 37879 * Geoff Berry for his Java object serialization work and various 37880 patches. 37881 37882 * Uros Bizjak for the implementation of x87 math built-in functions 37883 and for various middle end and i386 back end improvements and bug 37884 fixes. 37885 37886 * Eric Blake for helping to make GCJ and libgcj conform to the 37887 specifications. 37888 37889 * Janne Blomqvist for contributions to GNU Fortran. 37890 37891 * Segher Boessenkool for various fixes. 37892 37893 * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and 37894 other Java work. 37895 37896 * Neil Booth for work on cpplib, lang hooks, debug hooks and other 37897 miscellaneous clean-ups. 37898 37899 * Steven Bosscher for integrating the GNU Fortran front end into GCC 37900 and for contributing to the tree-ssa branch. 37901 37902 * Eric Botcazou for fixing middle- and backend bugs left and right. 37903 37904 * Per Bothner for his direction via the steering committee and 37905 various improvements to the infrastructure for supporting new 37906 languages. Chill front end implementation. Initial 37907 implementations of cpplib, fix-header, config.guess, libio, and 37908 past C++ library (libg++) maintainer. Dreaming up, designing and 37909 implementing much of GCJ. 37910 37911 * Devon Bowen helped port GCC to the Tahoe. 37912 37913 * Don Bowman for mips-vxworks contributions. 37914 37915 * Dave Brolley for work on cpplib and Chill. 37916 37917 * Paul Brook for work on the ARM architecture and maintaining GNU 37918 Fortran. 37919 37920 * Robert Brown implemented the support for Encore 32000 systems. 37921 37922 * Christian Bruel for improvements to local store elimination. 37923 37924 * Herman A.J. ten Brugge for various fixes. 37925 37926 * Joerg Brunsmann for Java compiler hacking and help with the GCJ 37927 FAQ. 37928 37929 * Joe Buck for his direction via the steering committee. 37930 37931 * Craig Burley for leadership of the G77 Fortran effort. 37932 37933 * Stephan Buys for contributing Doxygen notes for libstdc++. 37934 37935 * Paolo Carlini for libstdc++ work: lots of efficiency improvements 37936 to the C++ strings, streambufs and formatted I/O, hard detective 37937 work on the frustrating localization issues, and keeping up with 37938 the problem reports. 37939 37940 * John Carr for his alias work, SPARC hacking, infrastructure 37941 improvements, previous contributions to the steering committee, 37942 loop optimizations, etc. 37943 37944 * Stephane Carrez for 68HC11 and 68HC12 ports. 37945 37946 * Steve Chamberlain for support for the Renesas SH and H8 processors 37947 and the PicoJava processor, and for GCJ config fixes. 37948 37949 * Glenn Chambers for help with the GCJ FAQ. 37950 37951 * John-Marc Chandonia for various libgcj patches. 37952 37953 * Denis Chertykov for contributing and maintaining the AVR port, the 37954 first GCC port for an 8-bit architecture. 37955 37956 * Scott Christley for his Objective-C contributions. 37957 37958 * Eric Christopher for his Java porting help and clean-ups. 37959 37960 * Branko Cibej for more warning contributions. 37961 37962 * The GNU Classpath project for all of their merged runtime code. 37963 37964 * Nick Clifton for arm, mcore, fr30, v850, m32r, rx work, `--help', 37965 and other random hacking. 37966 37967 * Michael Cook for libstdc++ cleanup patches to reduce warnings. 37968 37969 * R. Kelley Cook for making GCC buildable from a read-only directory 37970 as well as other miscellaneous build process and documentation 37971 clean-ups. 37972 37973 * Ralf Corsepius for SH testing and minor bug fixing. 37974 37975 * Stan Cox for care and feeding of the x86 port and lots of behind 37976 the scenes hacking. 37977 37978 * Alex Crain provided changes for the 3b1. 37979 37980 * Ian Dall for major improvements to the NS32k port. 37981 37982 * Paul Dale for his work to add uClinux platform support to the m68k 37983 backend. 37984 37985 * Dario Dariol contributed the four varieties of sample programs 37986 that print a copy of their source. 37987 37988 * Russell Davidson for fstream and stringstream fixes in libstdc++. 37989 37990 * Bud Davis for work on the G77 and GNU Fortran compilers. 37991 37992 * Mo DeJong for GCJ and libgcj bug fixes. 37993 37994 * DJ Delorie for the DJGPP port, build and libiberty maintenance, 37995 various bug fixes, and the M32C and MeP ports. 37996 37997 * Arnaud Desitter for helping to debug GNU Fortran. 37998 37999 * Gabriel Dos Reis for contributions to G++, contributions and 38000 maintenance of GCC diagnostics infrastructure, libstdc++-v3, 38001 including `valarray<>', `complex<>', maintaining the numerics 38002 library (including that pesky `<limits>' :-) and keeping 38003 up-to-date anything to do with numbers. 38004 38005 * Ulrich Drepper for his work on glibc, testing of GCC using glibc, 38006 ISO C99 support, CFG dumping support, etc., plus support of the 38007 C++ runtime libraries including for all kinds of C interface 38008 issues, contributing and maintaining `complex<>', sanity checking 38009 and disbursement, configuration architecture, libio maintenance, 38010 and early math work. 38011 38012 * Zdenek Dvorak for a new loop unroller and various fixes. 38013 38014 * Richard Earnshaw for his ongoing work with the ARM. 38015 38016 * David Edelsohn for his direction via the steering committee, 38017 ongoing work with the RS6000/PowerPC port, help cleaning up Haifa 38018 loop changes, doing the entire AIX port of libstdc++ with his bare 38019 hands, and for ensuring GCC properly keeps working on AIX. 38020 38021 * Kevin Ediger for the floating point formatting of num_put::do_put 38022 in libstdc++. 38023 38024 * Phil Edwards for libstdc++ work including configuration hackery, 38025 documentation maintainer, chief breaker of the web pages, the 38026 occasional iostream bug fix, and work on shared library symbol 38027 versioning. 38028 38029 * Paul Eggert for random hacking all over GCC. 38030 38031 * Mark Elbrecht for various DJGPP improvements, and for libstdc++ 38032 configuration support for locales and fstream-related fixes. 38033 38034 * Vadim Egorov for libstdc++ fixes in strings, streambufs, and 38035 iostreams. 38036 38037 * Christian Ehrhardt for dealing with bug reports. 38038 38039 * Ben Elliston for his work to move the Objective-C runtime into its 38040 own subdirectory and for his work on autoconf. 38041 38042 * Revital Eres for work on the PowerPC 750CL port. 38043 38044 * Marc Espie for OpenBSD support. 38045 38046 * Doug Evans for much of the global optimization framework, arc, 38047 m32r, and SPARC work. 38048 38049 * Christopher Faylor for his work on the Cygwin port and for caring 38050 and feeding the gcc.gnu.org box and saving its users tons of spam. 38051 38052 * Fred Fish for BeOS support and Ada fixes. 38053 38054 * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ. 38055 38056 * Peter Gerwinski for various bug fixes and the Pascal front end. 38057 38058 * Kaveh R. Ghazi for his direction via the steering committee, 38059 amazing work to make `-W -Wall -W* -Werror' useful, and 38060 continuously testing GCC on a plethora of platforms. Kaveh 38061 extends his gratitude to the CAIP Center at Rutgers University for 38062 providing him with computing resources to work on Free Software 38063 since the late 1980s. 38064 38065 * John Gilmore for a donation to the FSF earmarked improving GNU 38066 Java. 38067 38068 * Judy Goldberg for c++ contributions. 38069 38070 * Torbjorn Granlund for various fixes and the c-torture testsuite, 38071 multiply- and divide-by-constant optimization, improved long long 38072 support, improved leaf function register allocation, and his 38073 direction via the steering committee. 38074 38075 * Anthony Green for his `-Os' contributions, the moxie port, and 38076 Java front end work. 38077 38078 * Stu Grossman for gdb hacking, allowing GCJ developers to debug 38079 Java code. 38080 38081 * Michael K. Gschwind contributed the port to the PDP-11. 38082 38083 * Richard Guenther for his ongoing middle-end contributions and bug 38084 fixes and for release management. 38085 38086 * Ron Guilmette implemented the `protoize' and `unprotoize' tools, 38087 the support for Dwarf symbolic debugging information, and much of 38088 the support for System V Release 4. He has also worked heavily on 38089 the Intel 386 and 860 support. 38090 38091 * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload 38092 GCSE. 38093 38094 * Bruno Haible for improvements in the runtime overhead for EH, new 38095 warnings and assorted bug fixes. 38096 38097 * Andrew Haley for his amazing Java compiler and library efforts. 38098 38099 * Chris Hanson assisted in making GCC work on HP-UX for the 9000 38100 series 300. 38101 38102 * Michael Hayes for various thankless work he's done trying to get 38103 the c30/c40 ports functional. Lots of loop and unroll 38104 improvements and fixes. 38105 38106 * Dara Hazeghi for wading through myriads of target-specific bug 38107 reports. 38108 38109 * Kate Hedstrom for staking the G77 folks with an initial testsuite. 38110 38111 * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64 38112 work, loop opts, and generally fixing lots of old problems we've 38113 ignored for years, flow rewrite and lots of further stuff, 38114 including reviewing tons of patches. 38115 38116 * Aldy Hernandez for working on the PowerPC port, SIMD support, and 38117 various fixes. 38118 38119 * Nobuyuki Hikichi of Software Research Associates, Tokyo, 38120 contributed the support for the Sony NEWS machine. 38121 38122 * Kazu Hirata for caring and feeding the Renesas H8/300 port and 38123 various fixes. 38124 38125 * Katherine Holcomb for work on GNU Fortran. 38126 38127 * Manfred Hollstein for his ongoing work to keep the m88k alive, lots 38128 of testing and bug fixing, particularly of GCC configury code. 38129 38130 * Steve Holmgren for MachTen patches. 38131 38132 * Jan Hubicka for his x86 port improvements. 38133 38134 * Falk Hueffner for working on C and optimization bug reports. 38135 38136 * Bernardo Innocenti for his m68k work, including merging of 38137 ColdFire improvements and uClinux support. 38138 38139 * Christian Iseli for various bug fixes. 38140 38141 * Kamil Iskra for general m68k hacking. 38142 38143 * Lee Iverson for random fixes and MIPS testing. 38144 38145 * Andreas Jaeger for testing and benchmarking of GCC and various bug 38146 fixes. 38147 38148 * Jakub Jelinek for his SPARC work and sibling call optimizations as 38149 well as lots of bug fixes and test cases, and for improving the 38150 Java build system. 38151 38152 * Janis Johnson for ia64 testing and fixes, her quality improvement 38153 sidetracks, and web page maintenance. 38154 38155 * Kean Johnston for SCO OpenServer support and various fixes. 38156 38157 * Tim Josling for the sample language treelang based originally on 38158 Richard Kenner's "toy" language. 38159 38160 * Nicolai Josuttis for additional libstdc++ documentation. 38161 38162 * Klaus Kaempf for his ongoing work to make alpha-vms a viable 38163 target. 38164 38165 * Steven G. Kargl for work on GNU Fortran. 38166 38167 * David Kashtan of SRI adapted GCC to VMS. 38168 38169 * Ryszard Kabatek for many, many libstdc++ bug fixes and 38170 optimizations of strings, especially member functions, and for 38171 auto_ptr fixes. 38172 38173 * Geoffrey Keating for his ongoing work to make the PPC work for 38174 GNU/Linux and his automatic regression tester. 38175 38176 * Brendan Kehoe for his ongoing work with G++ and for a lot of early 38177 work in just about every part of libstdc++. 38178 38179 * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the 38180 MIL-STD-1750A. 38181 38182 * Richard Kenner of the New York University Ultracomputer Research 38183 Laboratory wrote the machine descriptions for the AMD 29000, the 38184 DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the 38185 support for instruction attributes. He also made changes to 38186 better support RISC processors including changes to common 38187 subexpression elimination, strength reduction, function calling 38188 sequence handling, and condition code support, in addition to 38189 generalizing the code for frame pointer elimination and delay slot 38190 scheduling. Richard Kenner was also the head maintainer of GCC 38191 for several years. 38192 38193 * Mumit Khan for various contributions to the Cygwin and Mingw32 38194 ports and maintaining binary releases for Microsoft Windows hosts, 38195 and for massive libstdc++ porting work to Cygwin/Mingw32. 38196 38197 * Robin Kirkham for cpu32 support. 38198 38199 * Mark Klein for PA improvements. 38200 38201 * Thomas Koenig for various bug fixes. 38202 38203 * Bruce Korb for the new and improved fixincludes code. 38204 38205 * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3 38206 effort. 38207 38208 * Charles LaBrec contributed the support for the Integrated Solutions 38209 68020 system. 38210 38211 * Asher Langton and Mike Kumbera for contributing Cray pointer 38212 support to GNU Fortran, and for other GNU Fortran improvements. 38213 38214 * Jeff Law for his direction via the steering committee, 38215 coordinating the entire egcs project and GCC 2.95, rolling out 38216 snapshots and releases, handling merges from GCC2, reviewing tons 38217 of patches that might have fallen through the cracks else, and 38218 random but extensive hacking. 38219 38220 * Marc Lehmann for his direction via the steering committee and 38221 helping with analysis and improvements of x86 performance. 38222 38223 * Victor Leikehman for work on GNU Fortran. 38224 38225 * Ted Lemon wrote parts of the RTL reader and printer. 38226 38227 * Kriang Lerdsuwanakij for C++ improvements including template as 38228 template parameter support, and many C++ fixes. 38229 38230 * Warren Levy for tremendous work on libgcj (Java Runtime Library) 38231 and random work on the Java front end. 38232 38233 * Alain Lichnewsky ported GCC to the MIPS CPU. 38234 38235 * Oskar Liljeblad for hacking on AWT and his many Java bug reports 38236 and patches. 38237 38238 * Robert Lipe for OpenServer support, new testsuites, testing, etc. 38239 38240 * Chen Liqin for various S+core related fixes/improvement, and for 38241 maintaining the S+core port. 38242 38243 * Weiwen Liu for testing and various bug fixes. 38244 38245 * Manuel Lo'pez-Iba'n~ez for improving `-Wconversion' and many other 38246 diagnostics fixes and improvements. 38247 38248 * Dave Love for his ongoing work with the Fortran front end and 38249 runtime libraries. 38250 38251 * Martin von Lo"wis for internal consistency checking infrastructure, 38252 various C++ improvements including namespace support, and tons of 38253 assistance with libstdc++/compiler merges. 38254 38255 * H.J. Lu for his previous contributions to the steering committee, 38256 many x86 bug reports, prototype patches, and keeping the GNU/Linux 38257 ports working. 38258 38259 * Greg McGary for random fixes and (someday) bounded pointers. 38260 38261 * Andrew MacLeod for his ongoing work in building a real EH system, 38262 various code generation improvements, work on the global 38263 optimizer, etc. 38264 38265 * Vladimir Makarov for hacking some ugly i960 problems, PowerPC 38266 hacking improvements to compile-time performance, overall 38267 knowledge and direction in the area of instruction scheduling, and 38268 design and implementation of the automaton based instruction 38269 scheduler. 38270 38271 * Bob Manson for his behind the scenes work on dejagnu. 38272 38273 * Philip Martin for lots of libstdc++ string and vector iterator 38274 fixes and improvements, and string clean up and testsuites. 38275 38276 * All of the Mauve project contributors, for Java test code. 38277 38278 * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements. 38279 38280 * Adam Megacz for his work on the Microsoft Windows port of GCJ. 38281 38282 * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS, 38283 powerpc, haifa, ECOFF debug support, and other assorted hacking. 38284 38285 * Jason Merrill for his direction via the steering committee and 38286 leading the G++ effort. 38287 38288 * Martin Michlmayr for testing GCC on several architectures using the 38289 entire Debian archive. 38290 38291 * David Miller for his direction via the steering committee, lots of 38292 SPARC work, improvements in jump.c and interfacing with the Linux 38293 kernel developers. 38294 38295 * Gary Miller ported GCC to Charles River Data Systems machines. 38296 38297 * Alfred Minarik for libstdc++ string and ios bug fixes, and turning 38298 the entire libstdc++ testsuite namespace-compatible. 38299 38300 * Mark Mitchell for his direction via the steering committee, 38301 mountains of C++ work, load/store hoisting out of loops, alias 38302 analysis improvements, ISO C `restrict' support, and serving as 38303 release manager for GCC 3.x. 38304 38305 * Alan Modra for various GNU/Linux bits and testing. 38306 38307 * Toon Moene for his direction via the steering committee, Fortran 38308 maintenance, and his ongoing work to make us make Fortran run fast. 38309 38310 * Jason Molenda for major help in the care and feeding of all the 38311 services on the gcc.gnu.org (formerly egcs.cygnus.com) 38312 machine--mail, web services, ftp services, etc etc. Doing all 38313 this work on scrap paper and the backs of envelopes would have 38314 been... difficult. 38315 38316 * Catherine Moore for fixing various ugly problems we have sent her 38317 way, including the haifa bug which was killing the Alpha & PowerPC 38318 Linux kernels. 38319 38320 * Mike Moreton for his various Java patches. 38321 38322 * David Mosberger-Tang for various Alpha improvements, and for the 38323 initial IA-64 port. 38324 38325 * Stephen Moshier contributed the floating point emulator that 38326 assists in cross-compilation and permits support for floating 38327 point numbers wider than 64 bits and for ISO C99 support. 38328 38329 * Bill Moyer for his behind the scenes work on various issues. 38330 38331 * Philippe De Muyter for his work on the m68k port. 38332 38333 * Joseph S. Myers for his work on the PDP-11 port, format checking 38334 and ISO C99 support, and continuous emphasis on (and contributions 38335 to) documentation. 38336 38337 * Nathan Myers for his work on libstdc++-v3: architecture and 38338 authorship through the first three snapshots, including 38339 implementation of locale infrastructure, string, shadow C headers, 38340 and the initial project documentation (DESIGN, CHECKLIST, and so 38341 forth). Later, more work on MT-safe string and shadow headers. 38342 38343 * Felix Natter for documentation on porting libstdc++. 38344 38345 * Nathanael Nerode for cleaning up the configuration/build process. 38346 38347 * NeXT, Inc. donated the front end that supports the Objective-C 38348 language. 38349 38350 * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to 38351 the search engine setup, various documentation fixes and other 38352 small fixes. 38353 38354 * Geoff Noer for his work on getting cygwin native builds working. 38355 38356 * Diego Novillo for his work on Tree SSA, OpenMP, SPEC performance 38357 tracking web pages, GIMPLE tuples, and assorted fixes. 38358 38359 * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64, 38360 FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and 38361 related infrastructure improvements. 38362 38363 * Alexandre Oliva for various build infrastructure improvements, 38364 scripts and amazing testing work, including keeping libtool issues 38365 sane and happy. 38366 38367 * Stefan Olsson for work on mt_alloc. 38368 38369 * Melissa O'Neill for various NeXT fixes. 38370 38371 * Rainer Orth for random MIPS work, including improvements to GCC's 38372 o32 ABI support, improvements to dejagnu's MIPS support, Java 38373 configuration clean-ups and porting work, and maintaining the 38374 IRIX, Solaris 2, and Tru64 UNIX ports. 38375 38376 * Hartmut Penner for work on the s390 port. 38377 38378 * Paul Petersen wrote the machine description for the Alliant FX/8. 38379 38380 * Alexandre Petit-Bianco for implementing much of the Java compiler 38381 and continued Java maintainership. 38382 38383 * Matthias Pfaller for major improvements to the NS32k port. 38384 38385 * Gerald Pfeifer for his direction via the steering committee, 38386 pointing out lots of problems we need to solve, maintenance of the 38387 web pages, and taking care of documentation maintenance in general. 38388 38389 * Andrew Pinski for processing bug reports by the dozen. 38390 38391 * Ovidiu Predescu for his work on the Objective-C front end and 38392 runtime libraries. 38393 38394 * Jerry Quinn for major performance improvements in C++ formatted 38395 I/O. 38396 38397 * Ken Raeburn for various improvements to checker, MIPS ports and 38398 various cleanups in the compiler. 38399 38400 * Rolf W. Rasmussen for hacking on AWT. 38401 38402 * David Reese of Sun Microsystems contributed to the Solaris on 38403 PowerPC port. 38404 38405 * Volker Reichelt for keeping up with the problem reports. 38406 38407 * Joern Rennecke for maintaining the sh port, loop, regmove & reload 38408 hacking. 38409 38410 * Loren J. Rittle for improvements to libstdc++-v3 including the 38411 FreeBSD port, threading fixes, thread-related configury changes, 38412 critical threading documentation, and solutions to really tricky 38413 I/O problems, as well as keeping GCC properly working on FreeBSD 38414 and continuous testing. 38415 38416 * Craig Rodrigues for processing tons of bug reports. 38417 38418 * Ola Ro"nnerup for work on mt_alloc. 38419 38420 * Gavin Romig-Koch for lots of behind the scenes MIPS work. 38421 38422 * David Ronis inspired and encouraged Craig to rewrite the G77 38423 documentation in texinfo format by contributing a first pass at a 38424 translation of the old `g77-0.5.16/f/DOC' file. 38425 38426 * Ken Rose for fixes to GCC's delay slot filling code. 38427 38428 * Paul Rubin wrote most of the preprocessor. 38429 38430 * Pe'tur Runo'lfsson for major performance improvements in C++ 38431 formatted I/O and large file support in C++ filebuf. 38432 38433 * Chip Salzenberg for libstdc++ patches and improvements to locales, 38434 traits, Makefiles, libio, libtool hackery, and "long long" support. 38435 38436 * Juha Sarlin for improvements to the H8 code generator. 38437 38438 * Greg Satz assisted in making GCC work on HP-UX for the 9000 series 38439 300. 38440 38441 * Roger Sayle for improvements to constant folding and GCC's RTL 38442 optimizers as well as for fixing numerous bugs. 38443 38444 * Bradley Schatz for his work on the GCJ FAQ. 38445 38446 * Peter Schauer wrote the code to allow debugging to work on the 38447 Alpha. 38448 38449 * William Schelter did most of the work on the Intel 80386 support. 38450 38451 * Tobias Schlu"ter for work on GNU Fortran. 38452 38453 * Bernd Schmidt for various code generation improvements and major 38454 work in the reload pass as well a serving as release manager for 38455 GCC 2.95.3. 38456 38457 * Peter Schmid for constant testing of libstdc++--especially 38458 application testing, going above and beyond what was requested for 38459 the release criteria--and libstdc++ header file tweaks. 38460 38461 * Jason Schroeder for jcf-dump patches. 38462 38463 * Andreas Schwab for his work on the m68k port. 38464 38465 * Lars Segerlund for work on GNU Fortran. 38466 38467 * Joel Sherrill for his direction via the steering committee, RTEMS 38468 contributions and RTEMS testing. 38469 38470 * Nathan Sidwell for many C++ fixes/improvements. 38471 38472 * Jeffrey Siegal for helping RMS with the original design of GCC, 38473 some code which handles the parse tree and RTL data structures, 38474 constant folding and help with the original VAX & m68k ports. 38475 38476 * Kenny Simpson for prompting libstdc++ fixes due to defect reports 38477 from the LWG (thereby keeping GCC in line with updates from the 38478 ISO). 38479 38480 * Franz Sirl for his ongoing work with making the PPC port stable 38481 for GNU/Linux. 38482 38483 * Andrey Slepuhin for assorted AIX hacking. 38484 38485 * Trevor Smigiel for contributing the SPU port. 38486 38487 * Christopher Smith did the port for Convex machines. 38488 38489 * Danny Smith for his major efforts on the Mingw (and Cygwin) ports. 38490 38491 * Randy Smith finished the Sun FPA support. 38492 38493 * Scott Snyder for queue, iterator, istream, and string fixes and 38494 libstdc++ testsuite entries. Also for providing the patch to G77 38495 to add rudimentary support for `INTEGER*1', `INTEGER*2', and 38496 `LOGICAL*1'. 38497 38498 * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique. 38499 38500 * Richard Stallman, for writing the original GCC and launching the 38501 GNU project. 38502 38503 * Jan Stein of the Chalmers Computer Society provided support for 38504 Genix, as well as part of the 32000 machine description. 38505 38506 * Nigel Stephens for various mips16 related fixes/improvements. 38507 38508 * Jonathan Stone wrote the machine description for the Pyramid 38509 computer. 38510 38511 * Graham Stott for various infrastructure improvements. 38512 38513 * John Stracke for his Java HTTP protocol fixes. 38514 38515 * Mike Stump for his Elxsi port, G++ contributions over the years 38516 and more recently his vxworks contributions 38517 38518 * Jeff Sturm for Java porting help, bug fixes, and encouragement. 38519 38520 * Shigeya Suzuki for this fixes for the bsdi platforms. 38521 38522 * Ian Lance Taylor for his mips16 work, general configury hacking, 38523 fixincludes, etc. 38524 38525 * Holger Teutsch provided the support for the Clipper CPU. 38526 38527 * Gary Thomas for his ongoing work to make the PPC work for 38528 GNU/Linux. 38529 38530 * Philipp Thomas for random bug fixes throughout the compiler 38531 38532 * Jason Thorpe for thread support in libstdc++ on NetBSD. 38533 38534 * Kresten Krab Thorup wrote the run time support for the Objective-C 38535 language and the fantastic Java bytecode interpreter. 38536 38537 * Michael Tiemann for random bug fixes, the first instruction 38538 scheduler, initial C++ support, function integration, NS32k, SPARC 38539 and M88k machine description work, delay slot scheduling. 38540 38541 * Andreas Tobler for his work porting libgcj to Darwin. 38542 38543 * Teemu Torma for thread safe exception handling support. 38544 38545 * Leonard Tower wrote parts of the parser, RTL generator, and RTL 38546 definitions, and of the VAX machine description. 38547 38548 * Daniel Towner and Hariharan Sandanagobalane contributed and 38549 maintain the picoChip port. 38550 38551 * Tom Tromey for internationalization support and for his many Java 38552 contributions and libgcj maintainership. 38553 38554 * Lassi Tuura for improvements to config.guess to determine HP 38555 processor types. 38556 38557 * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes. 38558 38559 * Andy Vaught for the design and initial implementation of the GNU 38560 Fortran front end. 38561 38562 * Brent Verner for work with the libstdc++ cshadow files and their 38563 associated configure steps. 38564 38565 * Todd Vierling for contributions for NetBSD ports. 38566 38567 * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML 38568 guidance. 38569 38570 * Dean Wakerley for converting the install documentation from HTML 38571 to texinfo in time for GCC 3.0. 38572 38573 * Krister Walfridsson for random bug fixes. 38574 38575 * Feng Wang for contributions to GNU Fortran. 38576 38577 * Stephen M. Webb for time and effort on making libstdc++ shadow 38578 files work with the tricky Solaris 8+ headers, and for pushing the 38579 build-time header tree. 38580 38581 * John Wehle for various improvements for the x86 code generator, 38582 related infrastructure improvements to help x86 code generation, 38583 value range propagation and other work, WE32k port. 38584 38585 * Ulrich Weigand for work on the s390 port. 38586 38587 * Zack Weinberg for major work on cpplib and various other bug fixes. 38588 38589 * Matt Welsh for help with Linux Threads support in GCJ. 38590 38591 * Urban Widmark for help fixing java.io. 38592 38593 * Mark Wielaard for new Java library code and his work integrating 38594 with Classpath. 38595 38596 * Dale Wiles helped port GCC to the Tahoe. 38597 38598 * Bob Wilson from Tensilica, Inc. for the Xtensa port. 38599 38600 * Jim Wilson for his direction via the steering committee, tackling 38601 hard problems in various places that nobody else wanted to work 38602 on, strength reduction and other loop optimizations. 38603 38604 * Paul Woegerer and Tal Agmon for the CRX port. 38605 38606 * Carlo Wood for various fixes. 38607 38608 * Tom Wood for work on the m88k port. 38609 38610 * Canqun Yang for work on GNU Fortran. 38611 38612 * Masanobu Yuhara of Fujitsu Laboratories implemented the machine 38613 description for the Tron architecture (specifically, the Gmicro). 38614 38615 * Kevin Zachmann helped port GCC to the Tahoe. 38616 38617 * Ayal Zaks for Swing Modulo Scheduling (SMS). 38618 38619 * Xiaoqiang Zhang for work on GNU Fortran. 38620 38621 * Gilles Zunino for help porting Java to Irix. 38622 38623 38624 The following people are recognized for their contributions to GNAT, 38625the Ada front end of GCC: 38626 * Bernard Banner 38627 38628 * Romain Berrendonner 38629 38630 * Geert Bosch 38631 38632 * Emmanuel Briot 38633 38634 * Joel Brobecker 38635 38636 * Ben Brosgol 38637 38638 * Vincent Celier 38639 38640 * Arnaud Charlet 38641 38642 * Chien Chieng 38643 38644 * Cyrille Comar 38645 38646 * Cyrille Crozes 38647 38648 * Robert Dewar 38649 38650 * Gary Dismukes 38651 38652 * Robert Duff 38653 38654 * Ed Falis 38655 38656 * Ramon Fernandez 38657 38658 * Sam Figueroa 38659 38660 * Vasiliy Fofanov 38661 38662 * Michael Friess 38663 38664 * Franco Gasperoni 38665 38666 * Ted Giering 38667 38668 * Matthew Gingell 38669 38670 * Laurent Guerby 38671 38672 * Jerome Guitton 38673 38674 * Olivier Hainque 38675 38676 * Jerome Hugues 38677 38678 * Hristian Kirtchev 38679 38680 * Jerome Lambourg 38681 38682 * Bruno Leclerc 38683 38684 * Albert Lee 38685 38686 * Sean McNeil 38687 38688 * Javier Miranda 38689 38690 * Laurent Nana 38691 38692 * Pascal Obry 38693 38694 * Dong-Ik Oh 38695 38696 * Laurent Pautet 38697 38698 * Brett Porter 38699 38700 * Thomas Quinot 38701 38702 * Nicolas Roche 38703 38704 * Pat Rogers 38705 38706 * Jose Ruiz 38707 38708 * Douglas Rupp 38709 38710 * Sergey Rybin 38711 38712 * Gail Schenker 38713 38714 * Ed Schonberg 38715 38716 * Nicolas Setton 38717 38718 * Samuel Tardieu 38719 38720 38721 The following people are recognized for their contributions of new 38722features, bug reports, testing and integration of classpath/libgcj for 38723GCC version 4.1: 38724 * Lillian Angel for `JTree' implementation and lots Free Swing 38725 additions and bug fixes. 38726 38727 * Wolfgang Baer for `GapContent' bug fixes. 38728 38729 * Anthony Balkissoon for `JList', Free Swing 1.5 updates and mouse 38730 event fixes, lots of Free Swing work including `JTable' editing. 38731 38732 * Stuart Ballard for RMI constant fixes. 38733 38734 * Goffredo Baroncelli for `HTTPURLConnection' fixes. 38735 38736 * Gary Benson for `MessageFormat' fixes. 38737 38738 * Daniel Bonniot for `Serialization' fixes. 38739 38740 * Chris Burdess for lots of gnu.xml and http protocol fixes, `StAX' 38741 and `DOM xml:id' support. 38742 38743 * Ka-Hing Cheung for `TreePath' and `TreeSelection' fixes. 38744 38745 * Archie Cobbs for build fixes, VM interface updates, 38746 `URLClassLoader' updates. 38747 38748 * Kelley Cook for build fixes. 38749 38750 * Martin Cordova for Suggestions for better `SocketTimeoutException'. 38751 38752 * David Daney for `BitSet' bug fixes, `HttpURLConnection' rewrite 38753 and improvements. 38754 38755 * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo 38756 2D support. Lots of imageio framework additions, lots of AWT and 38757 Free Swing bug fixes. 38758 38759 * Jeroen Frijters for `ClassLoader' and nio cleanups, serialization 38760 fixes, better `Proxy' support, bug fixes and IKVM integration. 38761 38762 * Santiago Gala for `AccessControlContext' fixes. 38763 38764 * Nicolas Geoffray for `VMClassLoader' and `AccessController' 38765 improvements. 38766 38767 * David Gilbert for `basic' and `metal' icon and plaf support and 38768 lots of documenting, Lots of Free Swing and metal theme additions. 38769 `MetalIconFactory' implementation. 38770 38771 * Anthony Green for `MIDI' framework, `ALSA' and `DSSI' providers. 38772 38773 * Andrew Haley for `Serialization' and `URLClassLoader' fixes, gcj 38774 build speedups. 38775 38776 * Kim Ho for `JFileChooser' implementation. 38777 38778 * Andrew John Hughes for `Locale' and net fixes, URI RFC2986 38779 updates, `Serialization' fixes, `Properties' XML support and 38780 generic branch work, VMIntegration guide update. 38781 38782 * Bastiaan Huisman for `TimeZone' bug fixing. 38783 38784 * Andreas Jaeger for mprec updates. 38785 38786 * Paul Jenner for better `-Werror' support. 38787 38788 * Ito Kazumitsu for `NetworkInterface' implementation and updates. 38789 38790 * Roman Kennke for `BoxLayout', `GrayFilter' and `SplitPane', plus 38791 bug fixes all over. Lots of Free Swing work including styled text. 38792 38793 * Simon Kitching for `String' cleanups and optimization suggestions. 38794 38795 * Michael Koch for configuration fixes, `Locale' updates, bug and 38796 build fixes. 38797 38798 * Guilhem Lavaux for configuration, thread and channel fixes and 38799 Kaffe integration. JCL native `Pointer' updates. Logger bug fixes. 38800 38801 * David Lichteblau for JCL support library global/local reference 38802 cleanups. 38803 38804 * Aaron Luchko for JDWP updates and documentation fixes. 38805 38806 * Ziga Mahkovec for `Graphics2D' upgraded to Cairo 0.5 and new regex 38807 features. 38808 38809 * Sven de Marothy for BMP imageio support, CSS and `TextLayout' 38810 fixes. `GtkImage' rewrite, 2D, awt, free swing and date/time fixes 38811 and implementing the Qt4 peers. 38812 38813 * Casey Marshall for crypto algorithm fixes, `FileChannel' lock, 38814 `SystemLogger' and `FileHandler' rotate implementations, NIO 38815 `FileChannel.map' support, security and policy updates. 38816 38817 * Bryce McKinlay for RMI work. 38818 38819 * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus 38820 testing and documenting. 38821 38822 * Kalle Olavi Niemitalo for build fixes. 38823 38824 * Rainer Orth for build fixes. 38825 38826 * Andrew Overholt for `File' locking fixes. 38827 38828 * Ingo Proetel for `Image', `Logger' and `URLClassLoader' updates. 38829 38830 * Olga Rodimina for `MenuSelectionManager' implementation. 38831 38832 * Jan Roehrich for `BasicTreeUI' and `JTree' fixes. 38833 38834 * Julian Scheid for documentation updates and gjdoc support. 38835 38836 * Christian Schlichtherle for zip fixes and cleanups. 38837 38838 * Robert Schuster for documentation updates and beans fixes, 38839 `TreeNode' enumerations and `ActionCommand' and various fixes, XML 38840 and URL, AWT and Free Swing bug fixes. 38841 38842 * Keith Seitz for lots of JDWP work. 38843 38844 * Christian Thalinger for 64-bit cleanups, Configuration and VM 38845 interface fixes and `CACAO' integration, `fdlibm' updates. 38846 38847 * Gael Thomas for `VMClassLoader' boot packages support suggestions. 38848 38849 * Andreas Tobler for Darwin and Solaris testing and fixing, `Qt4' 38850 support for Darwin/OS X, `Graphics2D' support, `gtk+' updates. 38851 38852 * Dalibor Topic for better `DEBUG' support, build cleanups and Kaffe 38853 integration. `Qt4' build infrastructure, `SHA1PRNG' and 38854 `GdkPixbugDecoder' updates. 38855 38856 * Tom Tromey for Eclipse integration, generics work, lots of bug 38857 fixes and gcj integration including coordinating The Big Merge. 38858 38859 * Mark Wielaard for bug fixes, packaging and release management, 38860 `Clipboard' implementation, system call interrupts and network 38861 timeouts and `GdkPixpufDecoder' fixes. 38862 38863 38864 In addition to the above, all of which also contributed time and 38865energy in testing GCC, we would like to thank the following for their 38866contributions to testing: 38867 38868 * Michael Abd-El-Malek 38869 38870 * Thomas Arend 38871 38872 * Bonzo Armstrong 38873 38874 * Steven Ashe 38875 38876 * Chris Baldwin 38877 38878 * David Billinghurst 38879 38880 * Jim Blandy 38881 38882 * Stephane Bortzmeyer 38883 38884 * Horst von Brand 38885 38886 * Frank Braun 38887 38888 * Rodney Brown 38889 38890 * Sidney Cadot 38891 38892 * Bradford Castalia 38893 38894 * Robert Clark 38895 38896 * Jonathan Corbet 38897 38898 * Ralph Doncaster 38899 38900 * Richard Emberson 38901 38902 * Levente Farkas 38903 38904 * Graham Fawcett 38905 38906 * Mark Fernyhough 38907 38908 * Robert A. French 38909 38910 * Jo"rgen Freyh 38911 38912 * Mark K. Gardner 38913 38914 * Charles-Antoine Gauthier 38915 38916 * Yung Shing Gene 38917 38918 * David Gilbert 38919 38920 * Simon Gornall 38921 38922 * Fred Gray 38923 38924 * John Griffin 38925 38926 * Patrik Hagglund 38927 38928 * Phil Hargett 38929 38930 * Amancio Hasty 38931 38932 * Takafumi Hayashi 38933 38934 * Bryan W. Headley 38935 38936 * Kevin B. Hendricks 38937 38938 * Joep Jansen 38939 38940 * Christian Joensson 38941 38942 * Michel Kern 38943 38944 * David Kidd 38945 38946 * Tobias Kuipers 38947 38948 * Anand Krishnaswamy 38949 38950 * A. O. V. Le Blanc 38951 38952 * llewelly 38953 38954 * Damon Love 38955 38956 * Brad Lucier 38957 38958 * Matthias Klose 38959 38960 * Martin Knoblauch 38961 38962 * Rick Lutowski 38963 38964 * Jesse Macnish 38965 38966 * Stefan Morrell 38967 38968 * Anon A. Mous 38969 38970 * Matthias Mueller 38971 38972 * Pekka Nikander 38973 38974 * Rick Niles 38975 38976 * Jon Olson 38977 38978 * Magnus Persson 38979 38980 * Chris Pollard 38981 38982 * Richard Polton 38983 38984 * Derk Reefman 38985 38986 * David Rees 38987 38988 * Paul Reilly 38989 38990 * Tom Reilly 38991 38992 * Torsten Rueger 38993 38994 * Danny Sadinoff 38995 38996 * Marc Schifer 38997 38998 * Erik Schnetter 38999 39000 * Wayne K. Schroll 39001 39002 * David Schuler 39003 39004 * Vin Shelton 39005 39006 * Tim Souder 39007 39008 * Adam Sulmicki 39009 39010 * Bill Thorson 39011 39012 * George Talbot 39013 39014 * Pedro A. M. Vazquez 39015 39016 * Gregory Warnes 39017 39018 * Ian Watson 39019 39020 * David E. Young 39021 39022 * And many others 39023 39024 And finally we'd like to thank everyone who uses the compiler, provides 39025feedback and generally reminds us why we're doing this work in the first 39026place. 39027 39028 39029File: gccint.info, Node: Option Index, Next: Concept Index, Prev: Contributors, Up: Top 39030 39031Option Index 39032************ 39033 39034GCC's command line options are indexed here without any initial `-' or 39035`--'. Where an option has both positive and negative forms (such as 39036`-fOPTION' and `-fno-OPTION'), relevant entries in the manual are 39037indexed under the most appropriate form; it may sometimes be useful to 39038look up both forms. 39039 39040�[index�] 39041* Menu: 39042 39043* msoft-float: Soft float library routines. 39044 (line 6) 39045 39046 39047File: gccint.info, Node: Concept Index, Prev: Option Index, Up: Top 39048 39049Concept Index 39050************* 39051 39052�[index�] 39053* Menu: 39054 39055* ! in constraint: Multi-Alternative. (line 47) 39056* # in constraint: Modifiers. (line 67) 39057* # in template: Output Template. (line 66) 39058* #pragma: Misc. (line 381) 39059* % in constraint: Modifiers. (line 45) 39060* % in GTY option: GTY Options. (line 18) 39061* % in template: Output Template. (line 6) 39062* & in constraint: Modifiers. (line 25) 39063* ( <1>: GIMPLE_CALL. (line 63) 39064* ( <2>: GIMPLE_ASM. (line 21) 39065* (: Logical Operators. (line 107) 39066* (nil): RTL Objects. (line 73) 39067* *: Host Common. (line 17) 39068* * in constraint: Modifiers. (line 72) 39069* * in template: Output Statement. (line 29) 39070* *gimple_assign_lhs_ptr: GIMPLE_ASSIGN. (line 54) 39071* *gimple_assign_rhs1_ptr: GIMPLE_ASSIGN. (line 60) 39072* *gimple_assign_rhs2_ptr: GIMPLE_ASSIGN. (line 67) 39073* *gimple_call_arg_ptr: GIMPLE_CALL. (line 71) 39074* *gimple_call_lhs_ptr: GIMPLE_CALL. (line 32) 39075* *gimple_catch_types_ptr: GIMPLE_CATCH. (line 16) 39076* *gimple_debug_bind_get_value_ptr: GIMPLE_DEBUG. (line 52) 39077* *gimple_eh_filter_types_ptr: GIMPLE_EH_FILTER. (line 15) 39078* *gimple_omp_critical_name_ptr: GIMPLE_OMP_CRITICAL. 39079 (line 16) 39080* *gimple_omp_for_clauses_ptr: GIMPLE_OMP_FOR. (line 23) 39081* *gimple_omp_for_final_ptr: GIMPLE_OMP_FOR. (line 54) 39082* *gimple_omp_for_incr_ptr: GIMPLE_OMP_FOR. (line 64) 39083* *gimple_omp_for_index_ptr: GIMPLE_OMP_FOR. (line 34) 39084* *gimple_omp_for_initial_ptr: GIMPLE_OMP_FOR. (line 44) 39085* *gimple_omp_parallel_child_fn_ptr: GIMPLE_OMP_PARALLEL. 39086 (line 46) 39087* *gimple_omp_parallel_clauses_ptr: GIMPLE_OMP_PARALLEL. 39088 (line 34) 39089* *gimple_omp_parallel_data_arg_ptr: GIMPLE_OMP_PARALLEL. 39090 (line 58) 39091* *gimple_omp_sections_clauses_ptr: GIMPLE_OMP_SECTIONS. 39092 (line 33) 39093* *gimple_omp_sections_control_ptr: GIMPLE_OMP_SECTIONS. 39094 (line 21) 39095* *gimple_omp_single_clauses_ptr: GIMPLE_OMP_SINGLE. (line 17) 39096* *gimple_op_ptr: Manipulating GIMPLE statements. 39097 (line 84) 39098* *gimple_ops <1>: Manipulating GIMPLE statements. 39099 (line 78) 39100* *gimple_ops: Logical Operators. (line 82) 39101* *gimple_phi_result_ptr: GIMPLE_PHI. (line 22) 39102* *gsi_stmt_ptr: Sequence iterators. (line 80) 39103* + in constraint: Modifiers. (line 12) 39104* -fsection-anchors <1>: Anchored Addresses. (line 6) 39105* -fsection-anchors: Special Accessors. (line 110) 39106* /c in RTL dump: Flags. (line 239) 39107* /f in RTL dump: Flags. (line 247) 39108* /i in RTL dump: Flags. (line 299) 39109* /j in RTL dump: Flags. (line 314) 39110* /s in RTL dump: Flags. (line 263) 39111* /u in RTL dump: Flags. (line 324) 39112* /v in RTL dump: Flags. (line 356) 39113* 0 in constraint: Simple Constraints. (line 120) 39114* < in constraint: Simple Constraints. (line 48) 39115* = in constraint: Modifiers. (line 8) 39116* > in constraint: Simple Constraints. (line 52) 39117* ? in constraint: Multi-Alternative. (line 41) 39118* \: Output Template. (line 46) 39119* __absvdi2: Integer library routines. 39120 (line 107) 39121* __absvsi2: Integer library routines. 39122 (line 106) 39123* __addda3: Fixed-point fractional library routines. 39124 (line 45) 39125* __adddf3: Soft float library routines. 39126 (line 23) 39127* __adddq3: Fixed-point fractional library routines. 39128 (line 33) 39129* __addha3: Fixed-point fractional library routines. 39130 (line 43) 39131* __addhq3: Fixed-point fractional library routines. 39132 (line 30) 39133* __addqq3: Fixed-point fractional library routines. 39134 (line 29) 39135* __addsa3: Fixed-point fractional library routines. 39136 (line 44) 39137* __addsf3: Soft float library routines. 39138 (line 22) 39139* __addsq3: Fixed-point fractional library routines. 39140 (line 31) 39141* __addta3: Fixed-point fractional library routines. 39142 (line 47) 39143* __addtf3: Soft float library routines. 39144 (line 25) 39145* __adduda3: Fixed-point fractional library routines. 39146 (line 53) 39147* __addudq3: Fixed-point fractional library routines. 39148 (line 41) 39149* __adduha3: Fixed-point fractional library routines. 39150 (line 49) 39151* __adduhq3: Fixed-point fractional library routines. 39152 (line 37) 39153* __adduqq3: Fixed-point fractional library routines. 39154 (line 35) 39155* __addusa3: Fixed-point fractional library routines. 39156 (line 51) 39157* __addusq3: Fixed-point fractional library routines. 39158 (line 39) 39159* __adduta3: Fixed-point fractional library routines. 39160 (line 55) 39161* __addvdi3: Integer library routines. 39162 (line 111) 39163* __addvsi3: Integer library routines. 39164 (line 110) 39165* __addxf3: Soft float library routines. 39166 (line 27) 39167* __ashlda3: Fixed-point fractional library routines. 39168 (line 351) 39169* __ashldi3: Integer library routines. 39170 (line 14) 39171* __ashldq3: Fixed-point fractional library routines. 39172 (line 340) 39173* __ashlha3: Fixed-point fractional library routines. 39174 (line 349) 39175* __ashlhq3: Fixed-point fractional library routines. 39176 (line 337) 39177* __ashlqq3: Fixed-point fractional library routines. 39178 (line 336) 39179* __ashlsa3: Fixed-point fractional library routines. 39180 (line 350) 39181* __ashlsi3: Integer library routines. 39182 (line 13) 39183* __ashlsq3: Fixed-point fractional library routines. 39184 (line 338) 39185* __ashlta3: Fixed-point fractional library routines. 39186 (line 353) 39187* __ashlti3: Integer library routines. 39188 (line 15) 39189* __ashluda3: Fixed-point fractional library routines. 39190 (line 359) 39191* __ashludq3: Fixed-point fractional library routines. 39192 (line 348) 39193* __ashluha3: Fixed-point fractional library routines. 39194 (line 355) 39195* __ashluhq3: Fixed-point fractional library routines. 39196 (line 344) 39197* __ashluqq3: Fixed-point fractional library routines. 39198 (line 342) 39199* __ashlusa3: Fixed-point fractional library routines. 39200 (line 357) 39201* __ashlusq3: Fixed-point fractional library routines. 39202 (line 346) 39203* __ashluta3: Fixed-point fractional library routines. 39204 (line 361) 39205* __ashrda3: Fixed-point fractional library routines. 39206 (line 371) 39207* __ashrdi3: Integer library routines. 39208 (line 19) 39209* __ashrdq3: Fixed-point fractional library routines. 39210 (line 368) 39211* __ashrha3: Fixed-point fractional library routines. 39212 (line 369) 39213* __ashrhq3: Fixed-point fractional library routines. 39214 (line 365) 39215* __ashrqq3: Fixed-point fractional library routines. 39216 (line 364) 39217* __ashrsa3: Fixed-point fractional library routines. 39218 (line 370) 39219* __ashrsi3: Integer library routines. 39220 (line 18) 39221* __ashrsq3: Fixed-point fractional library routines. 39222 (line 366) 39223* __ashrta3: Fixed-point fractional library routines. 39224 (line 373) 39225* __ashrti3: Integer library routines. 39226 (line 20) 39227* __bid_adddd3: Decimal float library routines. 39228 (line 25) 39229* __bid_addsd3: Decimal float library routines. 39230 (line 21) 39231* __bid_addtd3: Decimal float library routines. 39232 (line 29) 39233* __bid_divdd3: Decimal float library routines. 39234 (line 68) 39235* __bid_divsd3: Decimal float library routines. 39236 (line 64) 39237* __bid_divtd3: Decimal float library routines. 39238 (line 72) 39239* __bid_eqdd2: Decimal float library routines. 39240 (line 259) 39241* __bid_eqsd2: Decimal float library routines. 39242 (line 257) 39243* __bid_eqtd2: Decimal float library routines. 39244 (line 261) 39245* __bid_extendddtd2: Decimal float library routines. 39246 (line 92) 39247* __bid_extendddtf: Decimal float library routines. 39248 (line 140) 39249* __bid_extendddxf: Decimal float library routines. 39250 (line 134) 39251* __bid_extenddfdd: Decimal float library routines. 39252 (line 147) 39253* __bid_extenddftd: Decimal float library routines. 39254 (line 107) 39255* __bid_extendsddd2: Decimal float library routines. 39256 (line 88) 39257* __bid_extendsddf: Decimal float library routines. 39258 (line 128) 39259* __bid_extendsdtd2: Decimal float library routines. 39260 (line 90) 39261* __bid_extendsdtf: Decimal float library routines. 39262 (line 138) 39263* __bid_extendsdxf: Decimal float library routines. 39264 (line 132) 39265* __bid_extendsfdd: Decimal float library routines. 39266 (line 103) 39267* __bid_extendsfsd: Decimal float library routines. 39268 (line 145) 39269* __bid_extendsftd: Decimal float library routines. 39270 (line 105) 39271* __bid_extendtftd: Decimal float library routines. 39272 (line 149) 39273* __bid_extendxftd: Decimal float library routines. 39274 (line 109) 39275* __bid_fixdddi: Decimal float library routines. 39276 (line 170) 39277* __bid_fixddsi: Decimal float library routines. 39278 (line 162) 39279* __bid_fixsddi: Decimal float library routines. 39280 (line 168) 39281* __bid_fixsdsi: Decimal float library routines. 39282 (line 160) 39283* __bid_fixtddi: Decimal float library routines. 39284 (line 172) 39285* __bid_fixtdsi: Decimal float library routines. 39286 (line 164) 39287* __bid_fixunsdddi: Decimal float library routines. 39288 (line 187) 39289* __bid_fixunsddsi: Decimal float library routines. 39290 (line 178) 39291* __bid_fixunssddi: Decimal float library routines. 39292 (line 185) 39293* __bid_fixunssdsi: Decimal float library routines. 39294 (line 176) 39295* __bid_fixunstddi: Decimal float library routines. 39296 (line 189) 39297* __bid_fixunstdsi: Decimal float library routines. 39298 (line 180) 39299* __bid_floatdidd: Decimal float library routines. 39300 (line 205) 39301* __bid_floatdisd: Decimal float library routines. 39302 (line 203) 39303* __bid_floatditd: Decimal float library routines. 39304 (line 207) 39305* __bid_floatsidd: Decimal float library routines. 39306 (line 196) 39307* __bid_floatsisd: Decimal float library routines. 39308 (line 194) 39309* __bid_floatsitd: Decimal float library routines. 39310 (line 198) 39311* __bid_floatunsdidd: Decimal float library routines. 39312 (line 223) 39313* __bid_floatunsdisd: Decimal float library routines. 39314 (line 221) 39315* __bid_floatunsditd: Decimal float library routines. 39316 (line 225) 39317* __bid_floatunssidd: Decimal float library routines. 39318 (line 214) 39319* __bid_floatunssisd: Decimal float library routines. 39320 (line 212) 39321* __bid_floatunssitd: Decimal float library routines. 39322 (line 216) 39323* __bid_gedd2: Decimal float library routines. 39324 (line 277) 39325* __bid_gesd2: Decimal float library routines. 39326 (line 275) 39327* __bid_getd2: Decimal float library routines. 39328 (line 279) 39329* __bid_gtdd2: Decimal float library routines. 39330 (line 304) 39331* __bid_gtsd2: Decimal float library routines. 39332 (line 302) 39333* __bid_gttd2: Decimal float library routines. 39334 (line 306) 39335* __bid_ledd2: Decimal float library routines. 39336 (line 295) 39337* __bid_lesd2: Decimal float library routines. 39338 (line 293) 39339* __bid_letd2: Decimal float library routines. 39340 (line 297) 39341* __bid_ltdd2: Decimal float library routines. 39342 (line 286) 39343* __bid_ltsd2: Decimal float library routines. 39344 (line 284) 39345* __bid_lttd2: Decimal float library routines. 39346 (line 288) 39347* __bid_muldd3: Decimal float library routines. 39348 (line 54) 39349* __bid_mulsd3: Decimal float library routines. 39350 (line 50) 39351* __bid_multd3: Decimal float library routines. 39352 (line 58) 39353* __bid_nedd2: Decimal float library routines. 39354 (line 268) 39355* __bid_negdd2: Decimal float library routines. 39356 (line 78) 39357* __bid_negsd2: Decimal float library routines. 39358 (line 76) 39359* __bid_negtd2: Decimal float library routines. 39360 (line 80) 39361* __bid_nesd2: Decimal float library routines. 39362 (line 266) 39363* __bid_netd2: Decimal float library routines. 39364 (line 270) 39365* __bid_subdd3: Decimal float library routines. 39366 (line 39) 39367* __bid_subsd3: Decimal float library routines. 39368 (line 35) 39369* __bid_subtd3: Decimal float library routines. 39370 (line 43) 39371* __bid_truncdddf: Decimal float library routines. 39372 (line 153) 39373* __bid_truncddsd2: Decimal float library routines. 39374 (line 94) 39375* __bid_truncddsf: Decimal float library routines. 39376 (line 124) 39377* __bid_truncdfsd: Decimal float library routines. 39378 (line 111) 39379* __bid_truncsdsf: Decimal float library routines. 39380 (line 151) 39381* __bid_trunctddd2: Decimal float library routines. 39382 (line 98) 39383* __bid_trunctddf: Decimal float library routines. 39384 (line 130) 39385* __bid_trunctdsd2: Decimal float library routines. 39386 (line 96) 39387* __bid_trunctdsf: Decimal float library routines. 39388 (line 126) 39389* __bid_trunctdtf: Decimal float library routines. 39390 (line 155) 39391* __bid_trunctdxf: Decimal float library routines. 39392 (line 136) 39393* __bid_trunctfdd: Decimal float library routines. 39394 (line 119) 39395* __bid_trunctfsd: Decimal float library routines. 39396 (line 115) 39397* __bid_truncxfdd: Decimal float library routines. 39398 (line 117) 39399* __bid_truncxfsd: Decimal float library routines. 39400 (line 113) 39401* __bid_unorddd2: Decimal float library routines. 39402 (line 235) 39403* __bid_unordsd2: Decimal float library routines. 39404 (line 233) 39405* __bid_unordtd2: Decimal float library routines. 39406 (line 237) 39407* __bswapdi2: Integer library routines. 39408 (line 162) 39409* __bswapsi2: Integer library routines. 39410 (line 161) 39411* __builtin_args_info: Varargs. (line 42) 39412* __builtin_classify_type: Varargs. (line 76) 39413* __builtin_next_arg: Varargs. (line 66) 39414* __builtin_saveregs: Varargs. (line 24) 39415* __clear_cache: Miscellaneous routines. 39416 (line 10) 39417* __clzdi2: Integer library routines. 39418 (line 131) 39419* __clzsi2: Integer library routines. 39420 (line 130) 39421* __clzti2: Integer library routines. 39422 (line 132) 39423* __cmpda2: Fixed-point fractional library routines. 39424 (line 451) 39425* __cmpdf2: Soft float library routines. 39426 (line 164) 39427* __cmpdi2: Integer library routines. 39428 (line 87) 39429* __cmpdq2: Fixed-point fractional library routines. 39430 (line 441) 39431* __cmpha2: Fixed-point fractional library routines. 39432 (line 449) 39433* __cmphq2: Fixed-point fractional library routines. 39434 (line 438) 39435* __cmpqq2: Fixed-point fractional library routines. 39436 (line 437) 39437* __cmpsa2: Fixed-point fractional library routines. 39438 (line 450) 39439* __cmpsf2: Soft float library routines. 39440 (line 163) 39441* __cmpsq2: Fixed-point fractional library routines. 39442 (line 439) 39443* __cmpta2: Fixed-point fractional library routines. 39444 (line 453) 39445* __cmptf2: Soft float library routines. 39446 (line 165) 39447* __cmpti2: Integer library routines. 39448 (line 88) 39449* __cmpuda2: Fixed-point fractional library routines. 39450 (line 458) 39451* __cmpudq2: Fixed-point fractional library routines. 39452 (line 448) 39453* __cmpuha2: Fixed-point fractional library routines. 39454 (line 455) 39455* __cmpuhq2: Fixed-point fractional library routines. 39456 (line 444) 39457* __cmpuqq2: Fixed-point fractional library routines. 39458 (line 443) 39459* __cmpusa2: Fixed-point fractional library routines. 39460 (line 456) 39461* __cmpusq2: Fixed-point fractional library routines. 39462 (line 446) 39463* __cmputa2: Fixed-point fractional library routines. 39464 (line 460) 39465* __CTOR_LIST__: Initialization. (line 25) 39466* __ctzdi2: Integer library routines. 39467 (line 138) 39468* __ctzsi2: Integer library routines. 39469 (line 137) 39470* __ctzti2: Integer library routines. 39471 (line 139) 39472* __divda3: Fixed-point fractional library routines. 39473 (line 227) 39474* __divdc3: Soft float library routines. 39475 (line 252) 39476* __divdf3: Soft float library routines. 39477 (line 48) 39478* __divdi3: Integer library routines. 39479 (line 25) 39480* __divdq3: Fixed-point fractional library routines. 39481 (line 223) 39482* __divha3: Fixed-point fractional library routines. 39483 (line 225) 39484* __divhq3: Fixed-point fractional library routines. 39485 (line 220) 39486* __divqq3: Fixed-point fractional library routines. 39487 (line 219) 39488* __divsa3: Fixed-point fractional library routines. 39489 (line 226) 39490* __divsc3: Soft float library routines. 39491 (line 250) 39492* __divsf3: Soft float library routines. 39493 (line 47) 39494* __divsi3: Integer library routines. 39495 (line 24) 39496* __divsq3: Fixed-point fractional library routines. 39497 (line 221) 39498* __divta3: Fixed-point fractional library routines. 39499 (line 229) 39500* __divtc3: Soft float library routines. 39501 (line 254) 39502* __divtf3: Soft float library routines. 39503 (line 50) 39504* __divti3: Integer library routines. 39505 (line 26) 39506* __divxc3: Soft float library routines. 39507 (line 256) 39508* __divxf3: Soft float library routines. 39509 (line 52) 39510* __dpd_adddd3: Decimal float library routines. 39511 (line 23) 39512* __dpd_addsd3: Decimal float library routines. 39513 (line 19) 39514* __dpd_addtd3: Decimal float library routines. 39515 (line 27) 39516* __dpd_divdd3: Decimal float library routines. 39517 (line 66) 39518* __dpd_divsd3: Decimal float library routines. 39519 (line 62) 39520* __dpd_divtd3: Decimal float library routines. 39521 (line 70) 39522* __dpd_eqdd2: Decimal float library routines. 39523 (line 258) 39524* __dpd_eqsd2: Decimal float library routines. 39525 (line 256) 39526* __dpd_eqtd2: Decimal float library routines. 39527 (line 260) 39528* __dpd_extendddtd2: Decimal float library routines. 39529 (line 91) 39530* __dpd_extendddtf: Decimal float library routines. 39531 (line 139) 39532* __dpd_extendddxf: Decimal float library routines. 39533 (line 133) 39534* __dpd_extenddfdd: Decimal float library routines. 39535 (line 146) 39536* __dpd_extenddftd: Decimal float library routines. 39537 (line 106) 39538* __dpd_extendsddd2: Decimal float library routines. 39539 (line 87) 39540* __dpd_extendsddf: Decimal float library routines. 39541 (line 127) 39542* __dpd_extendsdtd2: Decimal float library routines. 39543 (line 89) 39544* __dpd_extendsdtf: Decimal float library routines. 39545 (line 137) 39546* __dpd_extendsdxf: Decimal float library routines. 39547 (line 131) 39548* __dpd_extendsfdd: Decimal float library routines. 39549 (line 102) 39550* __dpd_extendsfsd: Decimal float library routines. 39551 (line 144) 39552* __dpd_extendsftd: Decimal float library routines. 39553 (line 104) 39554* __dpd_extendtftd: Decimal float library routines. 39555 (line 148) 39556* __dpd_extendxftd: Decimal float library routines. 39557 (line 108) 39558* __dpd_fixdddi: Decimal float library routines. 39559 (line 169) 39560* __dpd_fixddsi: Decimal float library routines. 39561 (line 161) 39562* __dpd_fixsddi: Decimal float library routines. 39563 (line 167) 39564* __dpd_fixsdsi: Decimal float library routines. 39565 (line 159) 39566* __dpd_fixtddi: Decimal float library routines. 39567 (line 171) 39568* __dpd_fixtdsi: Decimal float library routines. 39569 (line 163) 39570* __dpd_fixunsdddi: Decimal float library routines. 39571 (line 186) 39572* __dpd_fixunsddsi: Decimal float library routines. 39573 (line 177) 39574* __dpd_fixunssddi: Decimal float library routines. 39575 (line 184) 39576* __dpd_fixunssdsi: Decimal float library routines. 39577 (line 175) 39578* __dpd_fixunstddi: Decimal float library routines. 39579 (line 188) 39580* __dpd_fixunstdsi: Decimal float library routines. 39581 (line 179) 39582* __dpd_floatdidd: Decimal float library routines. 39583 (line 204) 39584* __dpd_floatdisd: Decimal float library routines. 39585 (line 202) 39586* __dpd_floatditd: Decimal float library routines. 39587 (line 206) 39588* __dpd_floatsidd: Decimal float library routines. 39589 (line 195) 39590* __dpd_floatsisd: Decimal float library routines. 39591 (line 193) 39592* __dpd_floatsitd: Decimal float library routines. 39593 (line 197) 39594* __dpd_floatunsdidd: Decimal float library routines. 39595 (line 222) 39596* __dpd_floatunsdisd: Decimal float library routines. 39597 (line 220) 39598* __dpd_floatunsditd: Decimal float library routines. 39599 (line 224) 39600* __dpd_floatunssidd: Decimal float library routines. 39601 (line 213) 39602* __dpd_floatunssisd: Decimal float library routines. 39603 (line 211) 39604* __dpd_floatunssitd: Decimal float library routines. 39605 (line 215) 39606* __dpd_gedd2: Decimal float library routines. 39607 (line 276) 39608* __dpd_gesd2: Decimal float library routines. 39609 (line 274) 39610* __dpd_getd2: Decimal float library routines. 39611 (line 278) 39612* __dpd_gtdd2: Decimal float library routines. 39613 (line 303) 39614* __dpd_gtsd2: Decimal float library routines. 39615 (line 301) 39616* __dpd_gttd2: Decimal float library routines. 39617 (line 305) 39618* __dpd_ledd2: Decimal float library routines. 39619 (line 294) 39620* __dpd_lesd2: Decimal float library routines. 39621 (line 292) 39622* __dpd_letd2: Decimal float library routines. 39623 (line 296) 39624* __dpd_ltdd2: Decimal float library routines. 39625 (line 285) 39626* __dpd_ltsd2: Decimal float library routines. 39627 (line 283) 39628* __dpd_lttd2: Decimal float library routines. 39629 (line 287) 39630* __dpd_muldd3: Decimal float library routines. 39631 (line 52) 39632* __dpd_mulsd3: Decimal float library routines. 39633 (line 48) 39634* __dpd_multd3: Decimal float library routines. 39635 (line 56) 39636* __dpd_nedd2: Decimal float library routines. 39637 (line 267) 39638* __dpd_negdd2: Decimal float library routines. 39639 (line 77) 39640* __dpd_negsd2: Decimal float library routines. 39641 (line 75) 39642* __dpd_negtd2: Decimal float library routines. 39643 (line 79) 39644* __dpd_nesd2: Decimal float library routines. 39645 (line 265) 39646* __dpd_netd2: Decimal float library routines. 39647 (line 269) 39648* __dpd_subdd3: Decimal float library routines. 39649 (line 37) 39650* __dpd_subsd3: Decimal float library routines. 39651 (line 33) 39652* __dpd_subtd3: Decimal float library routines. 39653 (line 41) 39654* __dpd_truncdddf: Decimal float library routines. 39655 (line 152) 39656* __dpd_truncddsd2: Decimal float library routines. 39657 (line 93) 39658* __dpd_truncddsf: Decimal float library routines. 39659 (line 123) 39660* __dpd_truncdfsd: Decimal float library routines. 39661 (line 110) 39662* __dpd_truncsdsf: Decimal float library routines. 39663 (line 150) 39664* __dpd_trunctddd2: Decimal float library routines. 39665 (line 97) 39666* __dpd_trunctddf: Decimal float library routines. 39667 (line 129) 39668* __dpd_trunctdsd2: Decimal float library routines. 39669 (line 95) 39670* __dpd_trunctdsf: Decimal float library routines. 39671 (line 125) 39672* __dpd_trunctdtf: Decimal float library routines. 39673 (line 154) 39674* __dpd_trunctdxf: Decimal float library routines. 39675 (line 135) 39676* __dpd_trunctfdd: Decimal float library routines. 39677 (line 118) 39678* __dpd_trunctfsd: Decimal float library routines. 39679 (line 114) 39680* __dpd_truncxfdd: Decimal float library routines. 39681 (line 116) 39682* __dpd_truncxfsd: Decimal float library routines. 39683 (line 112) 39684* __dpd_unorddd2: Decimal float library routines. 39685 (line 234) 39686* __dpd_unordsd2: Decimal float library routines. 39687 (line 232) 39688* __dpd_unordtd2: Decimal float library routines. 39689 (line 236) 39690* __DTOR_LIST__: Initialization. (line 25) 39691* __eqdf2: Soft float library routines. 39692 (line 194) 39693* __eqsf2: Soft float library routines. 39694 (line 193) 39695* __eqtf2: Soft float library routines. 39696 (line 195) 39697* __extenddftf2: Soft float library routines. 39698 (line 68) 39699* __extenddfxf2: Soft float library routines. 39700 (line 69) 39701* __extendsfdf2: Soft float library routines. 39702 (line 65) 39703* __extendsftf2: Soft float library routines. 39704 (line 66) 39705* __extendsfxf2: Soft float library routines. 39706 (line 67) 39707* __ffsdi2: Integer library routines. 39708 (line 144) 39709* __ffsti2: Integer library routines. 39710 (line 145) 39711* __fixdfdi: Soft float library routines. 39712 (line 88) 39713* __fixdfsi: Soft float library routines. 39714 (line 81) 39715* __fixdfti: Soft float library routines. 39716 (line 94) 39717* __fixsfdi: Soft float library routines. 39718 (line 87) 39719* __fixsfsi: Soft float library routines. 39720 (line 80) 39721* __fixsfti: Soft float library routines. 39722 (line 93) 39723* __fixtfdi: Soft float library routines. 39724 (line 89) 39725* __fixtfsi: Soft float library routines. 39726 (line 82) 39727* __fixtfti: Soft float library routines. 39728 (line 95) 39729* __fixunsdfdi: Soft float library routines. 39730 (line 108) 39731* __fixunsdfsi: Soft float library routines. 39732 (line 101) 39733* __fixunsdfti: Soft float library routines. 39734 (line 115) 39735* __fixunssfdi: Soft float library routines. 39736 (line 107) 39737* __fixunssfsi: Soft float library routines. 39738 (line 100) 39739* __fixunssfti: Soft float library routines. 39740 (line 114) 39741* __fixunstfdi: Soft float library routines. 39742 (line 109) 39743* __fixunstfsi: Soft float library routines. 39744 (line 102) 39745* __fixunstfti: Soft float library routines. 39746 (line 116) 39747* __fixunsxfdi: Soft float library routines. 39748 (line 110) 39749* __fixunsxfsi: Soft float library routines. 39750 (line 103) 39751* __fixunsxfti: Soft float library routines. 39752 (line 117) 39753* __fixxfdi: Soft float library routines. 39754 (line 90) 39755* __fixxfsi: Soft float library routines. 39756 (line 83) 39757* __fixxfti: Soft float library routines. 39758 (line 96) 39759* __floatdidf: Soft float library routines. 39760 (line 128) 39761* __floatdisf: Soft float library routines. 39762 (line 127) 39763* __floatditf: Soft float library routines. 39764 (line 129) 39765* __floatdixf: Soft float library routines. 39766 (line 130) 39767* __floatsidf: Soft float library routines. 39768 (line 122) 39769* __floatsisf: Soft float library routines. 39770 (line 121) 39771* __floatsitf: Soft float library routines. 39772 (line 123) 39773* __floatsixf: Soft float library routines. 39774 (line 124) 39775* __floattidf: Soft float library routines. 39776 (line 134) 39777* __floattisf: Soft float library routines. 39778 (line 133) 39779* __floattitf: Soft float library routines. 39780 (line 135) 39781* __floattixf: Soft float library routines. 39782 (line 136) 39783* __floatundidf: Soft float library routines. 39784 (line 146) 39785* __floatundisf: Soft float library routines. 39786 (line 145) 39787* __floatunditf: Soft float library routines. 39788 (line 147) 39789* __floatundixf: Soft float library routines. 39790 (line 148) 39791* __floatunsidf: Soft float library routines. 39792 (line 140) 39793* __floatunsisf: Soft float library routines. 39794 (line 139) 39795* __floatunsitf: Soft float library routines. 39796 (line 141) 39797* __floatunsixf: Soft float library routines. 39798 (line 142) 39799* __floatuntidf: Soft float library routines. 39800 (line 152) 39801* __floatuntisf: Soft float library routines. 39802 (line 151) 39803* __floatuntitf: Soft float library routines. 39804 (line 153) 39805* __floatuntixf: Soft float library routines. 39806 (line 154) 39807* __fractdadf: Fixed-point fractional library routines. 39808 (line 636) 39809* __fractdadi: Fixed-point fractional library routines. 39810 (line 633) 39811* __fractdadq: Fixed-point fractional library routines. 39812 (line 616) 39813* __fractdaha2: Fixed-point fractional library routines. 39814 (line 617) 39815* __fractdahi: Fixed-point fractional library routines. 39816 (line 631) 39817* __fractdahq: Fixed-point fractional library routines. 39818 (line 614) 39819* __fractdaqi: Fixed-point fractional library routines. 39820 (line 630) 39821* __fractdaqq: Fixed-point fractional library routines. 39822 (line 613) 39823* __fractdasa2: Fixed-point fractional library routines. 39824 (line 618) 39825* __fractdasf: Fixed-point fractional library routines. 39826 (line 635) 39827* __fractdasi: Fixed-point fractional library routines. 39828 (line 632) 39829* __fractdasq: Fixed-point fractional library routines. 39830 (line 615) 39831* __fractdata2: Fixed-point fractional library routines. 39832 (line 619) 39833* __fractdati: Fixed-point fractional library routines. 39834 (line 634) 39835* __fractdauda: Fixed-point fractional library routines. 39836 (line 627) 39837* __fractdaudq: Fixed-point fractional library routines. 39838 (line 624) 39839* __fractdauha: Fixed-point fractional library routines. 39840 (line 625) 39841* __fractdauhq: Fixed-point fractional library routines. 39842 (line 621) 39843* __fractdauqq: Fixed-point fractional library routines. 39844 (line 620) 39845* __fractdausa: Fixed-point fractional library routines. 39846 (line 626) 39847* __fractdausq: Fixed-point fractional library routines. 39848 (line 622) 39849* __fractdauta: Fixed-point fractional library routines. 39850 (line 629) 39851* __fractdfda: Fixed-point fractional library routines. 39852 (line 1025) 39853* __fractdfdq: Fixed-point fractional library routines. 39854 (line 1022) 39855* __fractdfha: Fixed-point fractional library routines. 39856 (line 1023) 39857* __fractdfhq: Fixed-point fractional library routines. 39858 (line 1020) 39859* __fractdfqq: Fixed-point fractional library routines. 39860 (line 1019) 39861* __fractdfsa: Fixed-point fractional library routines. 39862 (line 1024) 39863* __fractdfsq: Fixed-point fractional library routines. 39864 (line 1021) 39865* __fractdfta: Fixed-point fractional library routines. 39866 (line 1026) 39867* __fractdfuda: Fixed-point fractional library routines. 39868 (line 1033) 39869* __fractdfudq: Fixed-point fractional library routines. 39870 (line 1030) 39871* __fractdfuha: Fixed-point fractional library routines. 39872 (line 1031) 39873* __fractdfuhq: Fixed-point fractional library routines. 39874 (line 1028) 39875* __fractdfuqq: Fixed-point fractional library routines. 39876 (line 1027) 39877* __fractdfusa: Fixed-point fractional library routines. 39878 (line 1032) 39879* __fractdfusq: Fixed-point fractional library routines. 39880 (line 1029) 39881* __fractdfuta: Fixed-point fractional library routines. 39882 (line 1034) 39883* __fractdida: Fixed-point fractional library routines. 39884 (line 975) 39885* __fractdidq: Fixed-point fractional library routines. 39886 (line 972) 39887* __fractdiha: Fixed-point fractional library routines. 39888 (line 973) 39889* __fractdihq: Fixed-point fractional library routines. 39890 (line 970) 39891* __fractdiqq: Fixed-point fractional library routines. 39892 (line 969) 39893* __fractdisa: Fixed-point fractional library routines. 39894 (line 974) 39895* __fractdisq: Fixed-point fractional library routines. 39896 (line 971) 39897* __fractdita: Fixed-point fractional library routines. 39898 (line 976) 39899* __fractdiuda: Fixed-point fractional library routines. 39900 (line 983) 39901* __fractdiudq: Fixed-point fractional library routines. 39902 (line 980) 39903* __fractdiuha: Fixed-point fractional library routines. 39904 (line 981) 39905* __fractdiuhq: Fixed-point fractional library routines. 39906 (line 978) 39907* __fractdiuqq: Fixed-point fractional library routines. 39908 (line 977) 39909* __fractdiusa: Fixed-point fractional library routines. 39910 (line 982) 39911* __fractdiusq: Fixed-point fractional library routines. 39912 (line 979) 39913* __fractdiuta: Fixed-point fractional library routines. 39914 (line 984) 39915* __fractdqda: Fixed-point fractional library routines. 39916 (line 544) 39917* __fractdqdf: Fixed-point fractional library routines. 39918 (line 566) 39919* __fractdqdi: Fixed-point fractional library routines. 39920 (line 563) 39921* __fractdqha: Fixed-point fractional library routines. 39922 (line 542) 39923* __fractdqhi: Fixed-point fractional library routines. 39924 (line 561) 39925* __fractdqhq2: Fixed-point fractional library routines. 39926 (line 540) 39927* __fractdqqi: Fixed-point fractional library routines. 39928 (line 560) 39929* __fractdqqq2: Fixed-point fractional library routines. 39930 (line 539) 39931* __fractdqsa: Fixed-point fractional library routines. 39932 (line 543) 39933* __fractdqsf: Fixed-point fractional library routines. 39934 (line 565) 39935* __fractdqsi: Fixed-point fractional library routines. 39936 (line 562) 39937* __fractdqsq2: Fixed-point fractional library routines. 39938 (line 541) 39939* __fractdqta: Fixed-point fractional library routines. 39940 (line 545) 39941* __fractdqti: Fixed-point fractional library routines. 39942 (line 564) 39943* __fractdquda: Fixed-point fractional library routines. 39944 (line 557) 39945* __fractdqudq: Fixed-point fractional library routines. 39946 (line 552) 39947* __fractdquha: Fixed-point fractional library routines. 39948 (line 554) 39949* __fractdquhq: Fixed-point fractional library routines. 39950 (line 548) 39951* __fractdquqq: Fixed-point fractional library routines. 39952 (line 547) 39953* __fractdqusa: Fixed-point fractional library routines. 39954 (line 555) 39955* __fractdqusq: Fixed-point fractional library routines. 39956 (line 550) 39957* __fractdquta: Fixed-point fractional library routines. 39958 (line 559) 39959* __fracthada2: Fixed-point fractional library routines. 39960 (line 572) 39961* __fracthadf: Fixed-point fractional library routines. 39962 (line 590) 39963* __fracthadi: Fixed-point fractional library routines. 39964 (line 587) 39965* __fracthadq: Fixed-point fractional library routines. 39966 (line 570) 39967* __fracthahi: Fixed-point fractional library routines. 39968 (line 585) 39969* __fracthahq: Fixed-point fractional library routines. 39970 (line 568) 39971* __fracthaqi: Fixed-point fractional library routines. 39972 (line 584) 39973* __fracthaqq: Fixed-point fractional library routines. 39974 (line 567) 39975* __fracthasa2: Fixed-point fractional library routines. 39976 (line 571) 39977* __fracthasf: Fixed-point fractional library routines. 39978 (line 589) 39979* __fracthasi: Fixed-point fractional library routines. 39980 (line 586) 39981* __fracthasq: Fixed-point fractional library routines. 39982 (line 569) 39983* __fracthata2: Fixed-point fractional library routines. 39984 (line 573) 39985* __fracthati: Fixed-point fractional library routines. 39986 (line 588) 39987* __fracthauda: Fixed-point fractional library routines. 39988 (line 581) 39989* __fracthaudq: Fixed-point fractional library routines. 39990 (line 578) 39991* __fracthauha: Fixed-point fractional library routines. 39992 (line 579) 39993* __fracthauhq: Fixed-point fractional library routines. 39994 (line 575) 39995* __fracthauqq: Fixed-point fractional library routines. 39996 (line 574) 39997* __fracthausa: Fixed-point fractional library routines. 39998 (line 580) 39999* __fracthausq: Fixed-point fractional library routines. 40000 (line 576) 40001* __fracthauta: Fixed-point fractional library routines. 40002 (line 583) 40003* __fracthida: Fixed-point fractional library routines. 40004 (line 943) 40005* __fracthidq: Fixed-point fractional library routines. 40006 (line 940) 40007* __fracthiha: Fixed-point fractional library routines. 40008 (line 941) 40009* __fracthihq: Fixed-point fractional library routines. 40010 (line 938) 40011* __fracthiqq: Fixed-point fractional library routines. 40012 (line 937) 40013* __fracthisa: Fixed-point fractional library routines. 40014 (line 942) 40015* __fracthisq: Fixed-point fractional library routines. 40016 (line 939) 40017* __fracthita: Fixed-point fractional library routines. 40018 (line 944) 40019* __fracthiuda: Fixed-point fractional library routines. 40020 (line 951) 40021* __fracthiudq: Fixed-point fractional library routines. 40022 (line 948) 40023* __fracthiuha: Fixed-point fractional library routines. 40024 (line 949) 40025* __fracthiuhq: Fixed-point fractional library routines. 40026 (line 946) 40027* __fracthiuqq: Fixed-point fractional library routines. 40028 (line 945) 40029* __fracthiusa: Fixed-point fractional library routines. 40030 (line 950) 40031* __fracthiusq: Fixed-point fractional library routines. 40032 (line 947) 40033* __fracthiuta: Fixed-point fractional library routines. 40034 (line 952) 40035* __fracthqda: Fixed-point fractional library routines. 40036 (line 498) 40037* __fracthqdf: Fixed-point fractional library routines. 40038 (line 514) 40039* __fracthqdi: Fixed-point fractional library routines. 40040 (line 511) 40041* __fracthqdq2: Fixed-point fractional library routines. 40042 (line 495) 40043* __fracthqha: Fixed-point fractional library routines. 40044 (line 496) 40045* __fracthqhi: Fixed-point fractional library routines. 40046 (line 509) 40047* __fracthqqi: Fixed-point fractional library routines. 40048 (line 508) 40049* __fracthqqq2: Fixed-point fractional library routines. 40050 (line 493) 40051* __fracthqsa: Fixed-point fractional library routines. 40052 (line 497) 40053* __fracthqsf: Fixed-point fractional library routines. 40054 (line 513) 40055* __fracthqsi: Fixed-point fractional library routines. 40056 (line 510) 40057* __fracthqsq2: Fixed-point fractional library routines. 40058 (line 494) 40059* __fracthqta: Fixed-point fractional library routines. 40060 (line 499) 40061* __fracthqti: Fixed-point fractional library routines. 40062 (line 512) 40063* __fracthquda: Fixed-point fractional library routines. 40064 (line 506) 40065* __fracthqudq: Fixed-point fractional library routines. 40066 (line 503) 40067* __fracthquha: Fixed-point fractional library routines. 40068 (line 504) 40069* __fracthquhq: Fixed-point fractional library routines. 40070 (line 501) 40071* __fracthquqq: Fixed-point fractional library routines. 40072 (line 500) 40073* __fracthqusa: Fixed-point fractional library routines. 40074 (line 505) 40075* __fracthqusq: Fixed-point fractional library routines. 40076 (line 502) 40077* __fracthquta: Fixed-point fractional library routines. 40078 (line 507) 40079* __fractqida: Fixed-point fractional library routines. 40080 (line 925) 40081* __fractqidq: Fixed-point fractional library routines. 40082 (line 922) 40083* __fractqiha: Fixed-point fractional library routines. 40084 (line 923) 40085* __fractqihq: Fixed-point fractional library routines. 40086 (line 920) 40087* __fractqiqq: Fixed-point fractional library routines. 40088 (line 919) 40089* __fractqisa: Fixed-point fractional library routines. 40090 (line 924) 40091* __fractqisq: Fixed-point fractional library routines. 40092 (line 921) 40093* __fractqita: Fixed-point fractional library routines. 40094 (line 926) 40095* __fractqiuda: Fixed-point fractional library routines. 40096 (line 934) 40097* __fractqiudq: Fixed-point fractional library routines. 40098 (line 931) 40099* __fractqiuha: Fixed-point fractional library routines. 40100 (line 932) 40101* __fractqiuhq: Fixed-point fractional library routines. 40102 (line 928) 40103* __fractqiuqq: Fixed-point fractional library routines. 40104 (line 927) 40105* __fractqiusa: Fixed-point fractional library routines. 40106 (line 933) 40107* __fractqiusq: Fixed-point fractional library routines. 40108 (line 929) 40109* __fractqiuta: Fixed-point fractional library routines. 40110 (line 936) 40111* __fractqqda: Fixed-point fractional library routines. 40112 (line 474) 40113* __fractqqdf: Fixed-point fractional library routines. 40114 (line 492) 40115* __fractqqdi: Fixed-point fractional library routines. 40116 (line 489) 40117* __fractqqdq2: Fixed-point fractional library routines. 40118 (line 471) 40119* __fractqqha: Fixed-point fractional library routines. 40120 (line 472) 40121* __fractqqhi: Fixed-point fractional library routines. 40122 (line 487) 40123* __fractqqhq2: Fixed-point fractional library routines. 40124 (line 469) 40125* __fractqqqi: Fixed-point fractional library routines. 40126 (line 486) 40127* __fractqqsa: Fixed-point fractional library routines. 40128 (line 473) 40129* __fractqqsf: Fixed-point fractional library routines. 40130 (line 491) 40131* __fractqqsi: Fixed-point fractional library routines. 40132 (line 488) 40133* __fractqqsq2: Fixed-point fractional library routines. 40134 (line 470) 40135* __fractqqta: Fixed-point fractional library routines. 40136 (line 475) 40137* __fractqqti: Fixed-point fractional library routines. 40138 (line 490) 40139* __fractqquda: Fixed-point fractional library routines. 40140 (line 483) 40141* __fractqqudq: Fixed-point fractional library routines. 40142 (line 480) 40143* __fractqquha: Fixed-point fractional library routines. 40144 (line 481) 40145* __fractqquhq: Fixed-point fractional library routines. 40146 (line 477) 40147* __fractqquqq: Fixed-point fractional library routines. 40148 (line 476) 40149* __fractqqusa: Fixed-point fractional library routines. 40150 (line 482) 40151* __fractqqusq: Fixed-point fractional library routines. 40152 (line 478) 40153* __fractqquta: Fixed-point fractional library routines. 40154 (line 485) 40155* __fractsada2: Fixed-point fractional library routines. 40156 (line 596) 40157* __fractsadf: Fixed-point fractional library routines. 40158 (line 612) 40159* __fractsadi: Fixed-point fractional library routines. 40160 (line 609) 40161* __fractsadq: Fixed-point fractional library routines. 40162 (line 594) 40163* __fractsaha2: Fixed-point fractional library routines. 40164 (line 595) 40165* __fractsahi: Fixed-point fractional library routines. 40166 (line 607) 40167* __fractsahq: Fixed-point fractional library routines. 40168 (line 592) 40169* __fractsaqi: Fixed-point fractional library routines. 40170 (line 606) 40171* __fractsaqq: Fixed-point fractional library routines. 40172 (line 591) 40173* __fractsasf: Fixed-point fractional library routines. 40174 (line 611) 40175* __fractsasi: Fixed-point fractional library routines. 40176 (line 608) 40177* __fractsasq: Fixed-point fractional library routines. 40178 (line 593) 40179* __fractsata2: Fixed-point fractional library routines. 40180 (line 597) 40181* __fractsati: Fixed-point fractional library routines. 40182 (line 610) 40183* __fractsauda: Fixed-point fractional library routines. 40184 (line 604) 40185* __fractsaudq: Fixed-point fractional library routines. 40186 (line 601) 40187* __fractsauha: Fixed-point fractional library routines. 40188 (line 602) 40189* __fractsauhq: Fixed-point fractional library routines. 40190 (line 599) 40191* __fractsauqq: Fixed-point fractional library routines. 40192 (line 598) 40193* __fractsausa: Fixed-point fractional library routines. 40194 (line 603) 40195* __fractsausq: Fixed-point fractional library routines. 40196 (line 600) 40197* __fractsauta: Fixed-point fractional library routines. 40198 (line 605) 40199* __fractsfda: Fixed-point fractional library routines. 40200 (line 1009) 40201* __fractsfdq: Fixed-point fractional library routines. 40202 (line 1006) 40203* __fractsfha: Fixed-point fractional library routines. 40204 (line 1007) 40205* __fractsfhq: Fixed-point fractional library routines. 40206 (line 1004) 40207* __fractsfqq: Fixed-point fractional library routines. 40208 (line 1003) 40209* __fractsfsa: Fixed-point fractional library routines. 40210 (line 1008) 40211* __fractsfsq: Fixed-point fractional library routines. 40212 (line 1005) 40213* __fractsfta: Fixed-point fractional library routines. 40214 (line 1010) 40215* __fractsfuda: Fixed-point fractional library routines. 40216 (line 1017) 40217* __fractsfudq: Fixed-point fractional library routines. 40218 (line 1014) 40219* __fractsfuha: Fixed-point fractional library routines. 40220 (line 1015) 40221* __fractsfuhq: Fixed-point fractional library routines. 40222 (line 1012) 40223* __fractsfuqq: Fixed-point fractional library routines. 40224 (line 1011) 40225* __fractsfusa: Fixed-point fractional library routines. 40226 (line 1016) 40227* __fractsfusq: Fixed-point fractional library routines. 40228 (line 1013) 40229* __fractsfuta: Fixed-point fractional library routines. 40230 (line 1018) 40231* __fractsida: Fixed-point fractional library routines. 40232 (line 959) 40233* __fractsidq: Fixed-point fractional library routines. 40234 (line 956) 40235* __fractsiha: Fixed-point fractional library routines. 40236 (line 957) 40237* __fractsihq: Fixed-point fractional library routines. 40238 (line 954) 40239* __fractsiqq: Fixed-point fractional library routines. 40240 (line 953) 40241* __fractsisa: Fixed-point fractional library routines. 40242 (line 958) 40243* __fractsisq: Fixed-point fractional library routines. 40244 (line 955) 40245* __fractsita: Fixed-point fractional library routines. 40246 (line 960) 40247* __fractsiuda: Fixed-point fractional library routines. 40248 (line 967) 40249* __fractsiudq: Fixed-point fractional library routines. 40250 (line 964) 40251* __fractsiuha: Fixed-point fractional library routines. 40252 (line 965) 40253* __fractsiuhq: Fixed-point fractional library routines. 40254 (line 962) 40255* __fractsiuqq: Fixed-point fractional library routines. 40256 (line 961) 40257* __fractsiusa: Fixed-point fractional library routines. 40258 (line 966) 40259* __fractsiusq: Fixed-point fractional library routines. 40260 (line 963) 40261* __fractsiuta: Fixed-point fractional library routines. 40262 (line 968) 40263* __fractsqda: Fixed-point fractional library routines. 40264 (line 520) 40265* __fractsqdf: Fixed-point fractional library routines. 40266 (line 538) 40267* __fractsqdi: Fixed-point fractional library routines. 40268 (line 535) 40269* __fractsqdq2: Fixed-point fractional library routines. 40270 (line 517) 40271* __fractsqha: Fixed-point fractional library routines. 40272 (line 518) 40273* __fractsqhi: Fixed-point fractional library routines. 40274 (line 533) 40275* __fractsqhq2: Fixed-point fractional library routines. 40276 (line 516) 40277* __fractsqqi: Fixed-point fractional library routines. 40278 (line 532) 40279* __fractsqqq2: Fixed-point fractional library routines. 40280 (line 515) 40281* __fractsqsa: Fixed-point fractional library routines. 40282 (line 519) 40283* __fractsqsf: Fixed-point fractional library routines. 40284 (line 537) 40285* __fractsqsi: Fixed-point fractional library routines. 40286 (line 534) 40287* __fractsqta: Fixed-point fractional library routines. 40288 (line 521) 40289* __fractsqti: Fixed-point fractional library routines. 40290 (line 536) 40291* __fractsquda: Fixed-point fractional library routines. 40292 (line 529) 40293* __fractsqudq: Fixed-point fractional library routines. 40294 (line 526) 40295* __fractsquha: Fixed-point fractional library routines. 40296 (line 527) 40297* __fractsquhq: Fixed-point fractional library routines. 40298 (line 523) 40299* __fractsquqq: Fixed-point fractional library routines. 40300 (line 522) 40301* __fractsqusa: Fixed-point fractional library routines. 40302 (line 528) 40303* __fractsqusq: Fixed-point fractional library routines. 40304 (line 524) 40305* __fractsquta: Fixed-point fractional library routines. 40306 (line 531) 40307* __fracttada2: Fixed-point fractional library routines. 40308 (line 643) 40309* __fracttadf: Fixed-point fractional library routines. 40310 (line 664) 40311* __fracttadi: Fixed-point fractional library routines. 40312 (line 661) 40313* __fracttadq: Fixed-point fractional library routines. 40314 (line 640) 40315* __fracttaha2: Fixed-point fractional library routines. 40316 (line 641) 40317* __fracttahi: Fixed-point fractional library routines. 40318 (line 659) 40319* __fracttahq: Fixed-point fractional library routines. 40320 (line 638) 40321* __fracttaqi: Fixed-point fractional library routines. 40322 (line 658) 40323* __fracttaqq: Fixed-point fractional library routines. 40324 (line 637) 40325* __fracttasa2: Fixed-point fractional library routines. 40326 (line 642) 40327* __fracttasf: Fixed-point fractional library routines. 40328 (line 663) 40329* __fracttasi: Fixed-point fractional library routines. 40330 (line 660) 40331* __fracttasq: Fixed-point fractional library routines. 40332 (line 639) 40333* __fracttati: Fixed-point fractional library routines. 40334 (line 662) 40335* __fracttauda: Fixed-point fractional library routines. 40336 (line 655) 40337* __fracttaudq: Fixed-point fractional library routines. 40338 (line 650) 40339* __fracttauha: Fixed-point fractional library routines. 40340 (line 652) 40341* __fracttauhq: Fixed-point fractional library routines. 40342 (line 646) 40343* __fracttauqq: Fixed-point fractional library routines. 40344 (line 645) 40345* __fracttausa: Fixed-point fractional library routines. 40346 (line 653) 40347* __fracttausq: Fixed-point fractional library routines. 40348 (line 648) 40349* __fracttauta: Fixed-point fractional library routines. 40350 (line 657) 40351* __fracttida: Fixed-point fractional library routines. 40352 (line 991) 40353* __fracttidq: Fixed-point fractional library routines. 40354 (line 988) 40355* __fracttiha: Fixed-point fractional library routines. 40356 (line 989) 40357* __fracttihq: Fixed-point fractional library routines. 40358 (line 986) 40359* __fracttiqq: Fixed-point fractional library routines. 40360 (line 985) 40361* __fracttisa: Fixed-point fractional library routines. 40362 (line 990) 40363* __fracttisq: Fixed-point fractional library routines. 40364 (line 987) 40365* __fracttita: Fixed-point fractional library routines. 40366 (line 992) 40367* __fracttiuda: Fixed-point fractional library routines. 40368 (line 1000) 40369* __fracttiudq: Fixed-point fractional library routines. 40370 (line 997) 40371* __fracttiuha: Fixed-point fractional library routines. 40372 (line 998) 40373* __fracttiuhq: Fixed-point fractional library routines. 40374 (line 994) 40375* __fracttiuqq: Fixed-point fractional library routines. 40376 (line 993) 40377* __fracttiusa: Fixed-point fractional library routines. 40378 (line 999) 40379* __fracttiusq: Fixed-point fractional library routines. 40380 (line 995) 40381* __fracttiuta: Fixed-point fractional library routines. 40382 (line 1002) 40383* __fractudada: Fixed-point fractional library routines. 40384 (line 858) 40385* __fractudadf: Fixed-point fractional library routines. 40386 (line 881) 40387* __fractudadi: Fixed-point fractional library routines. 40388 (line 878) 40389* __fractudadq: Fixed-point fractional library routines. 40390 (line 855) 40391* __fractudaha: Fixed-point fractional library routines. 40392 (line 856) 40393* __fractudahi: Fixed-point fractional library routines. 40394 (line 876) 40395* __fractudahq: Fixed-point fractional library routines. 40396 (line 852) 40397* __fractudaqi: Fixed-point fractional library routines. 40398 (line 875) 40399* __fractudaqq: Fixed-point fractional library routines. 40400 (line 851) 40401* __fractudasa: Fixed-point fractional library routines. 40402 (line 857) 40403* __fractudasf: Fixed-point fractional library routines. 40404 (line 880) 40405* __fractudasi: Fixed-point fractional library routines. 40406 (line 877) 40407* __fractudasq: Fixed-point fractional library routines. 40408 (line 853) 40409* __fractudata: Fixed-point fractional library routines. 40410 (line 860) 40411* __fractudati: Fixed-point fractional library routines. 40412 (line 879) 40413* __fractudaudq: Fixed-point fractional library routines. 40414 (line 868) 40415* __fractudauha2: Fixed-point fractional library routines. 40416 (line 870) 40417* __fractudauhq: Fixed-point fractional library routines. 40418 (line 864) 40419* __fractudauqq: Fixed-point fractional library routines. 40420 (line 862) 40421* __fractudausa2: Fixed-point fractional library routines. 40422 (line 872) 40423* __fractudausq: Fixed-point fractional library routines. 40424 (line 866) 40425* __fractudauta2: Fixed-point fractional library routines. 40426 (line 874) 40427* __fractudqda: Fixed-point fractional library routines. 40428 (line 766) 40429* __fractudqdf: Fixed-point fractional library routines. 40430 (line 791) 40431* __fractudqdi: Fixed-point fractional library routines. 40432 (line 787) 40433* __fractudqdq: Fixed-point fractional library routines. 40434 (line 761) 40435* __fractudqha: Fixed-point fractional library routines. 40436 (line 763) 40437* __fractudqhi: Fixed-point fractional library routines. 40438 (line 785) 40439* __fractudqhq: Fixed-point fractional library routines. 40440 (line 757) 40441* __fractudqqi: Fixed-point fractional library routines. 40442 (line 784) 40443* __fractudqqq: Fixed-point fractional library routines. 40444 (line 756) 40445* __fractudqsa: Fixed-point fractional library routines. 40446 (line 764) 40447* __fractudqsf: Fixed-point fractional library routines. 40448 (line 790) 40449* __fractudqsi: Fixed-point fractional library routines. 40450 (line 786) 40451* __fractudqsq: Fixed-point fractional library routines. 40452 (line 759) 40453* __fractudqta: Fixed-point fractional library routines. 40454 (line 768) 40455* __fractudqti: Fixed-point fractional library routines. 40456 (line 789) 40457* __fractudquda: Fixed-point fractional library routines. 40458 (line 780) 40459* __fractudquha: Fixed-point fractional library routines. 40460 (line 776) 40461* __fractudquhq2: Fixed-point fractional library routines. 40462 (line 772) 40463* __fractudquqq2: Fixed-point fractional library routines. 40464 (line 770) 40465* __fractudqusa: Fixed-point fractional library routines. 40466 (line 778) 40467* __fractudqusq2: Fixed-point fractional library routines. 40468 (line 774) 40469* __fractudquta: Fixed-point fractional library routines. 40470 (line 782) 40471* __fractuhada: Fixed-point fractional library routines. 40472 (line 799) 40473* __fractuhadf: Fixed-point fractional library routines. 40474 (line 822) 40475* __fractuhadi: Fixed-point fractional library routines. 40476 (line 819) 40477* __fractuhadq: Fixed-point fractional library routines. 40478 (line 796) 40479* __fractuhaha: Fixed-point fractional library routines. 40480 (line 797) 40481* __fractuhahi: Fixed-point fractional library routines. 40482 (line 817) 40483* __fractuhahq: Fixed-point fractional library routines. 40484 (line 793) 40485* __fractuhaqi: Fixed-point fractional library routines. 40486 (line 816) 40487* __fractuhaqq: Fixed-point fractional library routines. 40488 (line 792) 40489* __fractuhasa: Fixed-point fractional library routines. 40490 (line 798) 40491* __fractuhasf: Fixed-point fractional library routines. 40492 (line 821) 40493* __fractuhasi: Fixed-point fractional library routines. 40494 (line 818) 40495* __fractuhasq: Fixed-point fractional library routines. 40496 (line 794) 40497* __fractuhata: Fixed-point fractional library routines. 40498 (line 801) 40499* __fractuhati: Fixed-point fractional library routines. 40500 (line 820) 40501* __fractuhauda2: Fixed-point fractional library routines. 40502 (line 813) 40503* __fractuhaudq: Fixed-point fractional library routines. 40504 (line 809) 40505* __fractuhauhq: Fixed-point fractional library routines. 40506 (line 805) 40507* __fractuhauqq: Fixed-point fractional library routines. 40508 (line 803) 40509* __fractuhausa2: Fixed-point fractional library routines. 40510 (line 811) 40511* __fractuhausq: Fixed-point fractional library routines. 40512 (line 807) 40513* __fractuhauta2: Fixed-point fractional library routines. 40514 (line 815) 40515* __fractuhqda: Fixed-point fractional library routines. 40516 (line 702) 40517* __fractuhqdf: Fixed-point fractional library routines. 40518 (line 723) 40519* __fractuhqdi: Fixed-point fractional library routines. 40520 (line 720) 40521* __fractuhqdq: Fixed-point fractional library routines. 40522 (line 699) 40523* __fractuhqha: Fixed-point fractional library routines. 40524 (line 700) 40525* __fractuhqhi: Fixed-point fractional library routines. 40526 (line 718) 40527* __fractuhqhq: Fixed-point fractional library routines. 40528 (line 697) 40529* __fractuhqqi: Fixed-point fractional library routines. 40530 (line 717) 40531* __fractuhqqq: Fixed-point fractional library routines. 40532 (line 696) 40533* __fractuhqsa: Fixed-point fractional library routines. 40534 (line 701) 40535* __fractuhqsf: Fixed-point fractional library routines. 40536 (line 722) 40537* __fractuhqsi: Fixed-point fractional library routines. 40538 (line 719) 40539* __fractuhqsq: Fixed-point fractional library routines. 40540 (line 698) 40541* __fractuhqta: Fixed-point fractional library routines. 40542 (line 703) 40543* __fractuhqti: Fixed-point fractional library routines. 40544 (line 721) 40545* __fractuhquda: Fixed-point fractional library routines. 40546 (line 714) 40547* __fractuhqudq2: Fixed-point fractional library routines. 40548 (line 709) 40549* __fractuhquha: Fixed-point fractional library routines. 40550 (line 711) 40551* __fractuhquqq2: Fixed-point fractional library routines. 40552 (line 705) 40553* __fractuhqusa: Fixed-point fractional library routines. 40554 (line 712) 40555* __fractuhqusq2: Fixed-point fractional library routines. 40556 (line 707) 40557* __fractuhquta: Fixed-point fractional library routines. 40558 (line 716) 40559* __fractunsdadi: Fixed-point fractional library routines. 40560 (line 1555) 40561* __fractunsdahi: Fixed-point fractional library routines. 40562 (line 1553) 40563* __fractunsdaqi: Fixed-point fractional library routines. 40564 (line 1552) 40565* __fractunsdasi: Fixed-point fractional library routines. 40566 (line 1554) 40567* __fractunsdati: Fixed-point fractional library routines. 40568 (line 1556) 40569* __fractunsdida: Fixed-point fractional library routines. 40570 (line 1707) 40571* __fractunsdidq: Fixed-point fractional library routines. 40572 (line 1704) 40573* __fractunsdiha: Fixed-point fractional library routines. 40574 (line 1705) 40575* __fractunsdihq: Fixed-point fractional library routines. 40576 (line 1702) 40577* __fractunsdiqq: Fixed-point fractional library routines. 40578 (line 1701) 40579* __fractunsdisa: Fixed-point fractional library routines. 40580 (line 1706) 40581* __fractunsdisq: Fixed-point fractional library routines. 40582 (line 1703) 40583* __fractunsdita: Fixed-point fractional library routines. 40584 (line 1708) 40585* __fractunsdiuda: Fixed-point fractional library routines. 40586 (line 1720) 40587* __fractunsdiudq: Fixed-point fractional library routines. 40588 (line 1715) 40589* __fractunsdiuha: Fixed-point fractional library routines. 40590 (line 1717) 40591* __fractunsdiuhq: Fixed-point fractional library routines. 40592 (line 1711) 40593* __fractunsdiuqq: Fixed-point fractional library routines. 40594 (line 1710) 40595* __fractunsdiusa: Fixed-point fractional library routines. 40596 (line 1718) 40597* __fractunsdiusq: Fixed-point fractional library routines. 40598 (line 1713) 40599* __fractunsdiuta: Fixed-point fractional library routines. 40600 (line 1722) 40601* __fractunsdqdi: Fixed-point fractional library routines. 40602 (line 1539) 40603* __fractunsdqhi: Fixed-point fractional library routines. 40604 (line 1537) 40605* __fractunsdqqi: Fixed-point fractional library routines. 40606 (line 1536) 40607* __fractunsdqsi: Fixed-point fractional library routines. 40608 (line 1538) 40609* __fractunsdqti: Fixed-point fractional library routines. 40610 (line 1541) 40611* __fractunshadi: Fixed-point fractional library routines. 40612 (line 1545) 40613* __fractunshahi: Fixed-point fractional library routines. 40614 (line 1543) 40615* __fractunshaqi: Fixed-point fractional library routines. 40616 (line 1542) 40617* __fractunshasi: Fixed-point fractional library routines. 40618 (line 1544) 40619* __fractunshati: Fixed-point fractional library routines. 40620 (line 1546) 40621* __fractunshida: Fixed-point fractional library routines. 40622 (line 1663) 40623* __fractunshidq: Fixed-point fractional library routines. 40624 (line 1660) 40625* __fractunshiha: Fixed-point fractional library routines. 40626 (line 1661) 40627* __fractunshihq: Fixed-point fractional library routines. 40628 (line 1658) 40629* __fractunshiqq: Fixed-point fractional library routines. 40630 (line 1657) 40631* __fractunshisa: Fixed-point fractional library routines. 40632 (line 1662) 40633* __fractunshisq: Fixed-point fractional library routines. 40634 (line 1659) 40635* __fractunshita: Fixed-point fractional library routines. 40636 (line 1664) 40637* __fractunshiuda: Fixed-point fractional library routines. 40638 (line 1676) 40639* __fractunshiudq: Fixed-point fractional library routines. 40640 (line 1671) 40641* __fractunshiuha: Fixed-point fractional library routines. 40642 (line 1673) 40643* __fractunshiuhq: Fixed-point fractional library routines. 40644 (line 1667) 40645* __fractunshiuqq: Fixed-point fractional library routines. 40646 (line 1666) 40647* __fractunshiusa: Fixed-point fractional library routines. 40648 (line 1674) 40649* __fractunshiusq: Fixed-point fractional library routines. 40650 (line 1669) 40651* __fractunshiuta: Fixed-point fractional library routines. 40652 (line 1678) 40653* __fractunshqdi: Fixed-point fractional library routines. 40654 (line 1529) 40655* __fractunshqhi: Fixed-point fractional library routines. 40656 (line 1527) 40657* __fractunshqqi: Fixed-point fractional library routines. 40658 (line 1526) 40659* __fractunshqsi: Fixed-point fractional library routines. 40660 (line 1528) 40661* __fractunshqti: Fixed-point fractional library routines. 40662 (line 1530) 40663* __fractunsqida: Fixed-point fractional library routines. 40664 (line 1641) 40665* __fractunsqidq: Fixed-point fractional library routines. 40666 (line 1638) 40667* __fractunsqiha: Fixed-point fractional library routines. 40668 (line 1639) 40669* __fractunsqihq: Fixed-point fractional library routines. 40670 (line 1636) 40671* __fractunsqiqq: Fixed-point fractional library routines. 40672 (line 1635) 40673* __fractunsqisa: Fixed-point fractional library routines. 40674 (line 1640) 40675* __fractunsqisq: Fixed-point fractional library routines. 40676 (line 1637) 40677* __fractunsqita: Fixed-point fractional library routines. 40678 (line 1642) 40679* __fractunsqiuda: Fixed-point fractional library routines. 40680 (line 1654) 40681* __fractunsqiudq: Fixed-point fractional library routines. 40682 (line 1649) 40683* __fractunsqiuha: Fixed-point fractional library routines. 40684 (line 1651) 40685* __fractunsqiuhq: Fixed-point fractional library routines. 40686 (line 1645) 40687* __fractunsqiuqq: Fixed-point fractional library routines. 40688 (line 1644) 40689* __fractunsqiusa: Fixed-point fractional library routines. 40690 (line 1652) 40691* __fractunsqiusq: Fixed-point fractional library routines. 40692 (line 1647) 40693* __fractunsqiuta: Fixed-point fractional library routines. 40694 (line 1656) 40695* __fractunsqqdi: Fixed-point fractional library routines. 40696 (line 1524) 40697* __fractunsqqhi: Fixed-point fractional library routines. 40698 (line 1522) 40699* __fractunsqqqi: Fixed-point fractional library routines. 40700 (line 1521) 40701* __fractunsqqsi: Fixed-point fractional library routines. 40702 (line 1523) 40703* __fractunsqqti: Fixed-point fractional library routines. 40704 (line 1525) 40705* __fractunssadi: Fixed-point fractional library routines. 40706 (line 1550) 40707* __fractunssahi: Fixed-point fractional library routines. 40708 (line 1548) 40709* __fractunssaqi: Fixed-point fractional library routines. 40710 (line 1547) 40711* __fractunssasi: Fixed-point fractional library routines. 40712 (line 1549) 40713* __fractunssati: Fixed-point fractional library routines. 40714 (line 1551) 40715* __fractunssida: Fixed-point fractional library routines. 40716 (line 1685) 40717* __fractunssidq: Fixed-point fractional library routines. 40718 (line 1682) 40719* __fractunssiha: Fixed-point fractional library routines. 40720 (line 1683) 40721* __fractunssihq: Fixed-point fractional library routines. 40722 (line 1680) 40723* __fractunssiqq: Fixed-point fractional library routines. 40724 (line 1679) 40725* __fractunssisa: Fixed-point fractional library routines. 40726 (line 1684) 40727* __fractunssisq: Fixed-point fractional library routines. 40728 (line 1681) 40729* __fractunssita: Fixed-point fractional library routines. 40730 (line 1686) 40731* __fractunssiuda: Fixed-point fractional library routines. 40732 (line 1698) 40733* __fractunssiudq: Fixed-point fractional library routines. 40734 (line 1693) 40735* __fractunssiuha: Fixed-point fractional library routines. 40736 (line 1695) 40737* __fractunssiuhq: Fixed-point fractional library routines. 40738 (line 1689) 40739* __fractunssiuqq: Fixed-point fractional library routines. 40740 (line 1688) 40741* __fractunssiusa: Fixed-point fractional library routines. 40742 (line 1696) 40743* __fractunssiusq: Fixed-point fractional library routines. 40744 (line 1691) 40745* __fractunssiuta: Fixed-point fractional library routines. 40746 (line 1700) 40747* __fractunssqdi: Fixed-point fractional library routines. 40748 (line 1534) 40749* __fractunssqhi: Fixed-point fractional library routines. 40750 (line 1532) 40751* __fractunssqqi: Fixed-point fractional library routines. 40752 (line 1531) 40753* __fractunssqsi: Fixed-point fractional library routines. 40754 (line 1533) 40755* __fractunssqti: Fixed-point fractional library routines. 40756 (line 1535) 40757* __fractunstadi: Fixed-point fractional library routines. 40758 (line 1560) 40759* __fractunstahi: Fixed-point fractional library routines. 40760 (line 1558) 40761* __fractunstaqi: Fixed-point fractional library routines. 40762 (line 1557) 40763* __fractunstasi: Fixed-point fractional library routines. 40764 (line 1559) 40765* __fractunstati: Fixed-point fractional library routines. 40766 (line 1562) 40767* __fractunstida: Fixed-point fractional library routines. 40768 (line 1730) 40769* __fractunstidq: Fixed-point fractional library routines. 40770 (line 1727) 40771* __fractunstiha: Fixed-point fractional library routines. 40772 (line 1728) 40773* __fractunstihq: Fixed-point fractional library routines. 40774 (line 1724) 40775* __fractunstiqq: Fixed-point fractional library routines. 40776 (line 1723) 40777* __fractunstisa: Fixed-point fractional library routines. 40778 (line 1729) 40779* __fractunstisq: Fixed-point fractional library routines. 40780 (line 1725) 40781* __fractunstita: Fixed-point fractional library routines. 40782 (line 1732) 40783* __fractunstiuda: Fixed-point fractional library routines. 40784 (line 1746) 40785* __fractunstiudq: Fixed-point fractional library routines. 40786 (line 1740) 40787* __fractunstiuha: Fixed-point fractional library routines. 40788 (line 1742) 40789* __fractunstiuhq: Fixed-point fractional library routines. 40790 (line 1736) 40791* __fractunstiuqq: Fixed-point fractional library routines. 40792 (line 1734) 40793* __fractunstiusa: Fixed-point fractional library routines. 40794 (line 1744) 40795* __fractunstiusq: Fixed-point fractional library routines. 40796 (line 1738) 40797* __fractunstiuta: Fixed-point fractional library routines. 40798 (line 1748) 40799* __fractunsudadi: Fixed-point fractional library routines. 40800 (line 1622) 40801* __fractunsudahi: Fixed-point fractional library routines. 40802 (line 1618) 40803* __fractunsudaqi: Fixed-point fractional library routines. 40804 (line 1616) 40805* __fractunsudasi: Fixed-point fractional library routines. 40806 (line 1620) 40807* __fractunsudati: Fixed-point fractional library routines. 40808 (line 1624) 40809* __fractunsudqdi: Fixed-point fractional library routines. 40810 (line 1596) 40811* __fractunsudqhi: Fixed-point fractional library routines. 40812 (line 1592) 40813* __fractunsudqqi: Fixed-point fractional library routines. 40814 (line 1590) 40815* __fractunsudqsi: Fixed-point fractional library routines. 40816 (line 1594) 40817* __fractunsudqti: Fixed-point fractional library routines. 40818 (line 1598) 40819* __fractunsuhadi: Fixed-point fractional library routines. 40820 (line 1606) 40821* __fractunsuhahi: Fixed-point fractional library routines. 40822 (line 1602) 40823* __fractunsuhaqi: Fixed-point fractional library routines. 40824 (line 1600) 40825* __fractunsuhasi: Fixed-point fractional library routines. 40826 (line 1604) 40827* __fractunsuhati: Fixed-point fractional library routines. 40828 (line 1608) 40829* __fractunsuhqdi: Fixed-point fractional library routines. 40830 (line 1576) 40831* __fractunsuhqhi: Fixed-point fractional library routines. 40832 (line 1574) 40833* __fractunsuhqqi: Fixed-point fractional library routines. 40834 (line 1573) 40835* __fractunsuhqsi: Fixed-point fractional library routines. 40836 (line 1575) 40837* __fractunsuhqti: Fixed-point fractional library routines. 40838 (line 1578) 40839* __fractunsuqqdi: Fixed-point fractional library routines. 40840 (line 1570) 40841* __fractunsuqqhi: Fixed-point fractional library routines. 40842 (line 1566) 40843* __fractunsuqqqi: Fixed-point fractional library routines. 40844 (line 1564) 40845* __fractunsuqqsi: Fixed-point fractional library routines. 40846 (line 1568) 40847* __fractunsuqqti: Fixed-point fractional library routines. 40848 (line 1572) 40849* __fractunsusadi: Fixed-point fractional library routines. 40850 (line 1612) 40851* __fractunsusahi: Fixed-point fractional library routines. 40852 (line 1610) 40853* __fractunsusaqi: Fixed-point fractional library routines. 40854 (line 1609) 40855* __fractunsusasi: Fixed-point fractional library routines. 40856 (line 1611) 40857* __fractunsusati: Fixed-point fractional library routines. 40858 (line 1614) 40859* __fractunsusqdi: Fixed-point fractional library routines. 40860 (line 1586) 40861* __fractunsusqhi: Fixed-point fractional library routines. 40862 (line 1582) 40863* __fractunsusqqi: Fixed-point fractional library routines. 40864 (line 1580) 40865* __fractunsusqsi: Fixed-point fractional library routines. 40866 (line 1584) 40867* __fractunsusqti: Fixed-point fractional library routines. 40868 (line 1588) 40869* __fractunsutadi: Fixed-point fractional library routines. 40870 (line 1632) 40871* __fractunsutahi: Fixed-point fractional library routines. 40872 (line 1628) 40873* __fractunsutaqi: Fixed-point fractional library routines. 40874 (line 1626) 40875* __fractunsutasi: Fixed-point fractional library routines. 40876 (line 1630) 40877* __fractunsutati: Fixed-point fractional library routines. 40878 (line 1634) 40879* __fractuqqda: Fixed-point fractional library routines. 40880 (line 672) 40881* __fractuqqdf: Fixed-point fractional library routines. 40882 (line 695) 40883* __fractuqqdi: Fixed-point fractional library routines. 40884 (line 692) 40885* __fractuqqdq: Fixed-point fractional library routines. 40886 (line 669) 40887* __fractuqqha: Fixed-point fractional library routines. 40888 (line 670) 40889* __fractuqqhi: Fixed-point fractional library routines. 40890 (line 690) 40891* __fractuqqhq: Fixed-point fractional library routines. 40892 (line 666) 40893* __fractuqqqi: Fixed-point fractional library routines. 40894 (line 689) 40895* __fractuqqqq: Fixed-point fractional library routines. 40896 (line 665) 40897* __fractuqqsa: Fixed-point fractional library routines. 40898 (line 671) 40899* __fractuqqsf: Fixed-point fractional library routines. 40900 (line 694) 40901* __fractuqqsi: Fixed-point fractional library routines. 40902 (line 691) 40903* __fractuqqsq: Fixed-point fractional library routines. 40904 (line 667) 40905* __fractuqqta: Fixed-point fractional library routines. 40906 (line 674) 40907* __fractuqqti: Fixed-point fractional library routines. 40908 (line 693) 40909* __fractuqquda: Fixed-point fractional library routines. 40910 (line 686) 40911* __fractuqqudq2: Fixed-point fractional library routines. 40912 (line 680) 40913* __fractuqquha: Fixed-point fractional library routines. 40914 (line 682) 40915* __fractuqquhq2: Fixed-point fractional library routines. 40916 (line 676) 40917* __fractuqqusa: Fixed-point fractional library routines. 40918 (line 684) 40919* __fractuqqusq2: Fixed-point fractional library routines. 40920 (line 678) 40921* __fractuqquta: Fixed-point fractional library routines. 40922 (line 688) 40923* __fractusada: Fixed-point fractional library routines. 40924 (line 829) 40925* __fractusadf: Fixed-point fractional library routines. 40926 (line 850) 40927* __fractusadi: Fixed-point fractional library routines. 40928 (line 847) 40929* __fractusadq: Fixed-point fractional library routines. 40930 (line 826) 40931* __fractusaha: Fixed-point fractional library routines. 40932 (line 827) 40933* __fractusahi: Fixed-point fractional library routines. 40934 (line 845) 40935* __fractusahq: Fixed-point fractional library routines. 40936 (line 824) 40937* __fractusaqi: Fixed-point fractional library routines. 40938 (line 844) 40939* __fractusaqq: Fixed-point fractional library routines. 40940 (line 823) 40941* __fractusasa: Fixed-point fractional library routines. 40942 (line 828) 40943* __fractusasf: Fixed-point fractional library routines. 40944 (line 849) 40945* __fractusasi: Fixed-point fractional library routines. 40946 (line 846) 40947* __fractusasq: Fixed-point fractional library routines. 40948 (line 825) 40949* __fractusata: Fixed-point fractional library routines. 40950 (line 830) 40951* __fractusati: Fixed-point fractional library routines. 40952 (line 848) 40953* __fractusauda2: Fixed-point fractional library routines. 40954 (line 841) 40955* __fractusaudq: Fixed-point fractional library routines. 40956 (line 837) 40957* __fractusauha2: Fixed-point fractional library routines. 40958 (line 839) 40959* __fractusauhq: Fixed-point fractional library routines. 40960 (line 833) 40961* __fractusauqq: Fixed-point fractional library routines. 40962 (line 832) 40963* __fractusausq: Fixed-point fractional library routines. 40964 (line 835) 40965* __fractusauta2: Fixed-point fractional library routines. 40966 (line 843) 40967* __fractusqda: Fixed-point fractional library routines. 40968 (line 731) 40969* __fractusqdf: Fixed-point fractional library routines. 40970 (line 754) 40971* __fractusqdi: Fixed-point fractional library routines. 40972 (line 751) 40973* __fractusqdq: Fixed-point fractional library routines. 40974 (line 728) 40975* __fractusqha: Fixed-point fractional library routines. 40976 (line 729) 40977* __fractusqhi: Fixed-point fractional library routines. 40978 (line 749) 40979* __fractusqhq: Fixed-point fractional library routines. 40980 (line 725) 40981* __fractusqqi: Fixed-point fractional library routines. 40982 (line 748) 40983* __fractusqqq: Fixed-point fractional library routines. 40984 (line 724) 40985* __fractusqsa: Fixed-point fractional library routines. 40986 (line 730) 40987* __fractusqsf: Fixed-point fractional library routines. 40988 (line 753) 40989* __fractusqsi: Fixed-point fractional library routines. 40990 (line 750) 40991* __fractusqsq: Fixed-point fractional library routines. 40992 (line 726) 40993* __fractusqta: Fixed-point fractional library routines. 40994 (line 733) 40995* __fractusqti: Fixed-point fractional library routines. 40996 (line 752) 40997* __fractusquda: Fixed-point fractional library routines. 40998 (line 745) 40999* __fractusqudq2: Fixed-point fractional library routines. 41000 (line 739) 41001* __fractusquha: Fixed-point fractional library routines. 41002 (line 741) 41003* __fractusquhq2: Fixed-point fractional library routines. 41004 (line 737) 41005* __fractusquqq2: Fixed-point fractional library routines. 41006 (line 735) 41007* __fractusqusa: Fixed-point fractional library routines. 41008 (line 743) 41009* __fractusquta: Fixed-point fractional library routines. 41010 (line 747) 41011* __fractutada: Fixed-point fractional library routines. 41012 (line 893) 41013* __fractutadf: Fixed-point fractional library routines. 41014 (line 918) 41015* __fractutadi: Fixed-point fractional library routines. 41016 (line 914) 41017* __fractutadq: Fixed-point fractional library routines. 41018 (line 888) 41019* __fractutaha: Fixed-point fractional library routines. 41020 (line 890) 41021* __fractutahi: Fixed-point fractional library routines. 41022 (line 912) 41023* __fractutahq: Fixed-point fractional library routines. 41024 (line 884) 41025* __fractutaqi: Fixed-point fractional library routines. 41026 (line 911) 41027* __fractutaqq: Fixed-point fractional library routines. 41028 (line 883) 41029* __fractutasa: Fixed-point fractional library routines. 41030 (line 891) 41031* __fractutasf: Fixed-point fractional library routines. 41032 (line 917) 41033* __fractutasi: Fixed-point fractional library routines. 41034 (line 913) 41035* __fractutasq: Fixed-point fractional library routines. 41036 (line 886) 41037* __fractutata: Fixed-point fractional library routines. 41038 (line 895) 41039* __fractutati: Fixed-point fractional library routines. 41040 (line 916) 41041* __fractutauda2: Fixed-point fractional library routines. 41042 (line 909) 41043* __fractutaudq: Fixed-point fractional library routines. 41044 (line 903) 41045* __fractutauha2: Fixed-point fractional library routines. 41046 (line 905) 41047* __fractutauhq: Fixed-point fractional library routines. 41048 (line 899) 41049* __fractutauqq: Fixed-point fractional library routines. 41050 (line 897) 41051* __fractutausa2: Fixed-point fractional library routines. 41052 (line 907) 41053* __fractutausq: Fixed-point fractional library routines. 41054 (line 901) 41055* __gedf2: Soft float library routines. 41056 (line 206) 41057* __gesf2: Soft float library routines. 41058 (line 205) 41059* __getf2: Soft float library routines. 41060 (line 207) 41061* __gtdf2: Soft float library routines. 41062 (line 224) 41063* __gtsf2: Soft float library routines. 41064 (line 223) 41065* __gttf2: Soft float library routines. 41066 (line 225) 41067* __ledf2: Soft float library routines. 41068 (line 218) 41069* __lesf2: Soft float library routines. 41070 (line 217) 41071* __letf2: Soft float library routines. 41072 (line 219) 41073* __lshrdi3: Integer library routines. 41074 (line 31) 41075* __lshrsi3: Integer library routines. 41076 (line 30) 41077* __lshrti3: Integer library routines. 41078 (line 32) 41079* __lshruda3: Fixed-point fractional library routines. 41080 (line 390) 41081* __lshrudq3: Fixed-point fractional library routines. 41082 (line 384) 41083* __lshruha3: Fixed-point fractional library routines. 41084 (line 386) 41085* __lshruhq3: Fixed-point fractional library routines. 41086 (line 380) 41087* __lshruqq3: Fixed-point fractional library routines. 41088 (line 378) 41089* __lshrusa3: Fixed-point fractional library routines. 41090 (line 388) 41091* __lshrusq3: Fixed-point fractional library routines. 41092 (line 382) 41093* __lshruta3: Fixed-point fractional library routines. 41094 (line 392) 41095* __ltdf2: Soft float library routines. 41096 (line 212) 41097* __ltsf2: Soft float library routines. 41098 (line 211) 41099* __lttf2: Soft float library routines. 41100 (line 213) 41101* __main: Collect2. (line 15) 41102* __moddi3: Integer library routines. 41103 (line 37) 41104* __modsi3: Integer library routines. 41105 (line 36) 41106* __modti3: Integer library routines. 41107 (line 38) 41108* __mulda3: Fixed-point fractional library routines. 41109 (line 171) 41110* __muldc3: Soft float library routines. 41111 (line 241) 41112* __muldf3: Soft float library routines. 41113 (line 40) 41114* __muldi3: Integer library routines. 41115 (line 43) 41116* __muldq3: Fixed-point fractional library routines. 41117 (line 159) 41118* __mulha3: Fixed-point fractional library routines. 41119 (line 169) 41120* __mulhq3: Fixed-point fractional library routines. 41121 (line 156) 41122* __mulqq3: Fixed-point fractional library routines. 41123 (line 155) 41124* __mulsa3: Fixed-point fractional library routines. 41125 (line 170) 41126* __mulsc3: Soft float library routines. 41127 (line 239) 41128* __mulsf3: Soft float library routines. 41129 (line 39) 41130* __mulsi3: Integer library routines. 41131 (line 42) 41132* __mulsq3: Fixed-point fractional library routines. 41133 (line 157) 41134* __multa3: Fixed-point fractional library routines. 41135 (line 173) 41136* __multc3: Soft float library routines. 41137 (line 243) 41138* __multf3: Soft float library routines. 41139 (line 42) 41140* __multi3: Integer library routines. 41141 (line 44) 41142* __muluda3: Fixed-point fractional library routines. 41143 (line 179) 41144* __muludq3: Fixed-point fractional library routines. 41145 (line 167) 41146* __muluha3: Fixed-point fractional library routines. 41147 (line 175) 41148* __muluhq3: Fixed-point fractional library routines. 41149 (line 163) 41150* __muluqq3: Fixed-point fractional library routines. 41151 (line 161) 41152* __mulusa3: Fixed-point fractional library routines. 41153 (line 177) 41154* __mulusq3: Fixed-point fractional library routines. 41155 (line 165) 41156* __muluta3: Fixed-point fractional library routines. 41157 (line 181) 41158* __mulvdi3: Integer library routines. 41159 (line 115) 41160* __mulvsi3: Integer library routines. 41161 (line 114) 41162* __mulxc3: Soft float library routines. 41163 (line 245) 41164* __mulxf3: Soft float library routines. 41165 (line 44) 41166* __nedf2: Soft float library routines. 41167 (line 200) 41168* __negda2: Fixed-point fractional library routines. 41169 (line 299) 41170* __negdf2: Soft float library routines. 41171 (line 56) 41172* __negdi2: Integer library routines. 41173 (line 47) 41174* __negdq2: Fixed-point fractional library routines. 41175 (line 289) 41176* __negha2: Fixed-point fractional library routines. 41177 (line 297) 41178* __neghq2: Fixed-point fractional library routines. 41179 (line 287) 41180* __negqq2: Fixed-point fractional library routines. 41181 (line 286) 41182* __negsa2: Fixed-point fractional library routines. 41183 (line 298) 41184* __negsf2: Soft float library routines. 41185 (line 55) 41186* __negsq2: Fixed-point fractional library routines. 41187 (line 288) 41188* __negta2: Fixed-point fractional library routines. 41189 (line 300) 41190* __negtf2: Soft float library routines. 41191 (line 57) 41192* __negti2: Integer library routines. 41193 (line 48) 41194* __neguda2: Fixed-point fractional library routines. 41195 (line 305) 41196* __negudq2: Fixed-point fractional library routines. 41197 (line 296) 41198* __neguha2: Fixed-point fractional library routines. 41199 (line 302) 41200* __neguhq2: Fixed-point fractional library routines. 41201 (line 292) 41202* __neguqq2: Fixed-point fractional library routines. 41203 (line 291) 41204* __negusa2: Fixed-point fractional library routines. 41205 (line 303) 41206* __negusq2: Fixed-point fractional library routines. 41207 (line 294) 41208* __neguta2: Fixed-point fractional library routines. 41209 (line 307) 41210* __negvdi2: Integer library routines. 41211 (line 119) 41212* __negvsi2: Integer library routines. 41213 (line 118) 41214* __negxf2: Soft float library routines. 41215 (line 58) 41216* __nesf2: Soft float library routines. 41217 (line 199) 41218* __netf2: Soft float library routines. 41219 (line 201) 41220* __paritydi2: Integer library routines. 41221 (line 151) 41222* __paritysi2: Integer library routines. 41223 (line 150) 41224* __parityti2: Integer library routines. 41225 (line 152) 41226* __popcountdi2: Integer library routines. 41227 (line 157) 41228* __popcountsi2: Integer library routines. 41229 (line 156) 41230* __popcountti2: Integer library routines. 41231 (line 158) 41232* __powidf2: Soft float library routines. 41233 (line 233) 41234* __powisf2: Soft float library routines. 41235 (line 232) 41236* __powitf2: Soft float library routines. 41237 (line 234) 41238* __powixf2: Soft float library routines. 41239 (line 235) 41240* __satfractdadq: Fixed-point fractional library routines. 41241 (line 1153) 41242* __satfractdaha2: Fixed-point fractional library routines. 41243 (line 1154) 41244* __satfractdahq: Fixed-point fractional library routines. 41245 (line 1151) 41246* __satfractdaqq: Fixed-point fractional library routines. 41247 (line 1150) 41248* __satfractdasa2: Fixed-point fractional library routines. 41249 (line 1155) 41250* __satfractdasq: Fixed-point fractional library routines. 41251 (line 1152) 41252* __satfractdata2: Fixed-point fractional library routines. 41253 (line 1156) 41254* __satfractdauda: Fixed-point fractional library routines. 41255 (line 1166) 41256* __satfractdaudq: Fixed-point fractional library routines. 41257 (line 1162) 41258* __satfractdauha: Fixed-point fractional library routines. 41259 (line 1164) 41260* __satfractdauhq: Fixed-point fractional library routines. 41261 (line 1159) 41262* __satfractdauqq: Fixed-point fractional library routines. 41263 (line 1158) 41264* __satfractdausa: Fixed-point fractional library routines. 41265 (line 1165) 41266* __satfractdausq: Fixed-point fractional library routines. 41267 (line 1160) 41268* __satfractdauta: Fixed-point fractional library routines. 41269 (line 1168) 41270* __satfractdfda: Fixed-point fractional library routines. 41271 (line 1506) 41272* __satfractdfdq: Fixed-point fractional library routines. 41273 (line 1503) 41274* __satfractdfha: Fixed-point fractional library routines. 41275 (line 1504) 41276* __satfractdfhq: Fixed-point fractional library routines. 41277 (line 1501) 41278* __satfractdfqq: Fixed-point fractional library routines. 41279 (line 1500) 41280* __satfractdfsa: Fixed-point fractional library routines. 41281 (line 1505) 41282* __satfractdfsq: Fixed-point fractional library routines. 41283 (line 1502) 41284* __satfractdfta: Fixed-point fractional library routines. 41285 (line 1507) 41286* __satfractdfuda: Fixed-point fractional library routines. 41287 (line 1515) 41288* __satfractdfudq: Fixed-point fractional library routines. 41289 (line 1512) 41290* __satfractdfuha: Fixed-point fractional library routines. 41291 (line 1513) 41292* __satfractdfuhq: Fixed-point fractional library routines. 41293 (line 1509) 41294* __satfractdfuqq: Fixed-point fractional library routines. 41295 (line 1508) 41296* __satfractdfusa: Fixed-point fractional library routines. 41297 (line 1514) 41298* __satfractdfusq: Fixed-point fractional library routines. 41299 (line 1510) 41300* __satfractdfuta: Fixed-point fractional library routines. 41301 (line 1517) 41302* __satfractdida: Fixed-point fractional library routines. 41303 (line 1456) 41304* __satfractdidq: Fixed-point fractional library routines. 41305 (line 1453) 41306* __satfractdiha: Fixed-point fractional library routines. 41307 (line 1454) 41308* __satfractdihq: Fixed-point fractional library routines. 41309 (line 1451) 41310* __satfractdiqq: Fixed-point fractional library routines. 41311 (line 1450) 41312* __satfractdisa: Fixed-point fractional library routines. 41313 (line 1455) 41314* __satfractdisq: Fixed-point fractional library routines. 41315 (line 1452) 41316* __satfractdita: Fixed-point fractional library routines. 41317 (line 1457) 41318* __satfractdiuda: Fixed-point fractional library routines. 41319 (line 1464) 41320* __satfractdiudq: Fixed-point fractional library routines. 41321 (line 1461) 41322* __satfractdiuha: Fixed-point fractional library routines. 41323 (line 1462) 41324* __satfractdiuhq: Fixed-point fractional library routines. 41325 (line 1459) 41326* __satfractdiuqq: Fixed-point fractional library routines. 41327 (line 1458) 41328* __satfractdiusa: Fixed-point fractional library routines. 41329 (line 1463) 41330* __satfractdiusq: Fixed-point fractional library routines. 41331 (line 1460) 41332* __satfractdiuta: Fixed-point fractional library routines. 41333 (line 1465) 41334* __satfractdqda: Fixed-point fractional library routines. 41335 (line 1098) 41336* __satfractdqha: Fixed-point fractional library routines. 41337 (line 1096) 41338* __satfractdqhq2: Fixed-point fractional library routines. 41339 (line 1094) 41340* __satfractdqqq2: Fixed-point fractional library routines. 41341 (line 1093) 41342* __satfractdqsa: Fixed-point fractional library routines. 41343 (line 1097) 41344* __satfractdqsq2: Fixed-point fractional library routines. 41345 (line 1095) 41346* __satfractdqta: Fixed-point fractional library routines. 41347 (line 1099) 41348* __satfractdquda: Fixed-point fractional library routines. 41349 (line 1111) 41350* __satfractdqudq: Fixed-point fractional library routines. 41351 (line 1106) 41352* __satfractdquha: Fixed-point fractional library routines. 41353 (line 1108) 41354* __satfractdquhq: Fixed-point fractional library routines. 41355 (line 1102) 41356* __satfractdquqq: Fixed-point fractional library routines. 41357 (line 1101) 41358* __satfractdqusa: Fixed-point fractional library routines. 41359 (line 1109) 41360* __satfractdqusq: Fixed-point fractional library routines. 41361 (line 1104) 41362* __satfractdquta: Fixed-point fractional library routines. 41363 (line 1113) 41364* __satfracthada2: Fixed-point fractional library routines. 41365 (line 1119) 41366* __satfracthadq: Fixed-point fractional library routines. 41367 (line 1117) 41368* __satfracthahq: Fixed-point fractional library routines. 41369 (line 1115) 41370* __satfracthaqq: Fixed-point fractional library routines. 41371 (line 1114) 41372* __satfracthasa2: Fixed-point fractional library routines. 41373 (line 1118) 41374* __satfracthasq: Fixed-point fractional library routines. 41375 (line 1116) 41376* __satfracthata2: Fixed-point fractional library routines. 41377 (line 1120) 41378* __satfracthauda: Fixed-point fractional library routines. 41379 (line 1132) 41380* __satfracthaudq: Fixed-point fractional library routines. 41381 (line 1127) 41382* __satfracthauha: Fixed-point fractional library routines. 41383 (line 1129) 41384* __satfracthauhq: Fixed-point fractional library routines. 41385 (line 1123) 41386* __satfracthauqq: Fixed-point fractional library routines. 41387 (line 1122) 41388* __satfracthausa: Fixed-point fractional library routines. 41389 (line 1130) 41390* __satfracthausq: Fixed-point fractional library routines. 41391 (line 1125) 41392* __satfracthauta: Fixed-point fractional library routines. 41393 (line 1134) 41394* __satfracthida: Fixed-point fractional library routines. 41395 (line 1424) 41396* __satfracthidq: Fixed-point fractional library routines. 41397 (line 1421) 41398* __satfracthiha: Fixed-point fractional library routines. 41399 (line 1422) 41400* __satfracthihq: Fixed-point fractional library routines. 41401 (line 1419) 41402* __satfracthiqq: Fixed-point fractional library routines. 41403 (line 1418) 41404* __satfracthisa: Fixed-point fractional library routines. 41405 (line 1423) 41406* __satfracthisq: Fixed-point fractional library routines. 41407 (line 1420) 41408* __satfracthita: Fixed-point fractional library routines. 41409 (line 1425) 41410* __satfracthiuda: Fixed-point fractional library routines. 41411 (line 1432) 41412* __satfracthiudq: Fixed-point fractional library routines. 41413 (line 1429) 41414* __satfracthiuha: Fixed-point fractional library routines. 41415 (line 1430) 41416* __satfracthiuhq: Fixed-point fractional library routines. 41417 (line 1427) 41418* __satfracthiuqq: Fixed-point fractional library routines. 41419 (line 1426) 41420* __satfracthiusa: Fixed-point fractional library routines. 41421 (line 1431) 41422* __satfracthiusq: Fixed-point fractional library routines. 41423 (line 1428) 41424* __satfracthiuta: Fixed-point fractional library routines. 41425 (line 1433) 41426* __satfracthqda: Fixed-point fractional library routines. 41427 (line 1064) 41428* __satfracthqdq2: Fixed-point fractional library routines. 41429 (line 1061) 41430* __satfracthqha: Fixed-point fractional library routines. 41431 (line 1062) 41432* __satfracthqqq2: Fixed-point fractional library routines. 41433 (line 1059) 41434* __satfracthqsa: Fixed-point fractional library routines. 41435 (line 1063) 41436* __satfracthqsq2: Fixed-point fractional library routines. 41437 (line 1060) 41438* __satfracthqta: Fixed-point fractional library routines. 41439 (line 1065) 41440* __satfracthquda: Fixed-point fractional library routines. 41441 (line 1072) 41442* __satfracthqudq: Fixed-point fractional library routines. 41443 (line 1069) 41444* __satfracthquha: Fixed-point fractional library routines. 41445 (line 1070) 41446* __satfracthquhq: Fixed-point fractional library routines. 41447 (line 1067) 41448* __satfracthquqq: Fixed-point fractional library routines. 41449 (line 1066) 41450* __satfracthqusa: Fixed-point fractional library routines. 41451 (line 1071) 41452* __satfracthqusq: Fixed-point fractional library routines. 41453 (line 1068) 41454* __satfracthquta: Fixed-point fractional library routines. 41455 (line 1073) 41456* __satfractqida: Fixed-point fractional library routines. 41457 (line 1402) 41458* __satfractqidq: Fixed-point fractional library routines. 41459 (line 1399) 41460* __satfractqiha: Fixed-point fractional library routines. 41461 (line 1400) 41462* __satfractqihq: Fixed-point fractional library routines. 41463 (line 1397) 41464* __satfractqiqq: Fixed-point fractional library routines. 41465 (line 1396) 41466* __satfractqisa: Fixed-point fractional library routines. 41467 (line 1401) 41468* __satfractqisq: Fixed-point fractional library routines. 41469 (line 1398) 41470* __satfractqita: Fixed-point fractional library routines. 41471 (line 1403) 41472* __satfractqiuda: Fixed-point fractional library routines. 41473 (line 1415) 41474* __satfractqiudq: Fixed-point fractional library routines. 41475 (line 1410) 41476* __satfractqiuha: Fixed-point fractional library routines. 41477 (line 1412) 41478* __satfractqiuhq: Fixed-point fractional library routines. 41479 (line 1406) 41480* __satfractqiuqq: Fixed-point fractional library routines. 41481 (line 1405) 41482* __satfractqiusa: Fixed-point fractional library routines. 41483 (line 1413) 41484* __satfractqiusq: Fixed-point fractional library routines. 41485 (line 1408) 41486* __satfractqiuta: Fixed-point fractional library routines. 41487 (line 1417) 41488* __satfractqqda: Fixed-point fractional library routines. 41489 (line 1043) 41490* __satfractqqdq2: Fixed-point fractional library routines. 41491 (line 1040) 41492* __satfractqqha: Fixed-point fractional library routines. 41493 (line 1041) 41494* __satfractqqhq2: Fixed-point fractional library routines. 41495 (line 1038) 41496* __satfractqqsa: Fixed-point fractional library routines. 41497 (line 1042) 41498* __satfractqqsq2: Fixed-point fractional library routines. 41499 (line 1039) 41500* __satfractqqta: Fixed-point fractional library routines. 41501 (line 1044) 41502* __satfractqquda: Fixed-point fractional library routines. 41503 (line 1056) 41504* __satfractqqudq: Fixed-point fractional library routines. 41505 (line 1051) 41506* __satfractqquha: Fixed-point fractional library routines. 41507 (line 1053) 41508* __satfractqquhq: Fixed-point fractional library routines. 41509 (line 1047) 41510* __satfractqquqq: Fixed-point fractional library routines. 41511 (line 1046) 41512* __satfractqqusa: Fixed-point fractional library routines. 41513 (line 1054) 41514* __satfractqqusq: Fixed-point fractional library routines. 41515 (line 1049) 41516* __satfractqquta: Fixed-point fractional library routines. 41517 (line 1058) 41518* __satfractsada2: Fixed-point fractional library routines. 41519 (line 1140) 41520* __satfractsadq: Fixed-point fractional library routines. 41521 (line 1138) 41522* __satfractsaha2: Fixed-point fractional library routines. 41523 (line 1139) 41524* __satfractsahq: Fixed-point fractional library routines. 41525 (line 1136) 41526* __satfractsaqq: Fixed-point fractional library routines. 41527 (line 1135) 41528* __satfractsasq: Fixed-point fractional library routines. 41529 (line 1137) 41530* __satfractsata2: Fixed-point fractional library routines. 41531 (line 1141) 41532* __satfractsauda: Fixed-point fractional library routines. 41533 (line 1148) 41534* __satfractsaudq: Fixed-point fractional library routines. 41535 (line 1145) 41536* __satfractsauha: Fixed-point fractional library routines. 41537 (line 1146) 41538* __satfractsauhq: Fixed-point fractional library routines. 41539 (line 1143) 41540* __satfractsauqq: Fixed-point fractional library routines. 41541 (line 1142) 41542* __satfractsausa: Fixed-point fractional library routines. 41543 (line 1147) 41544* __satfractsausq: Fixed-point fractional library routines. 41545 (line 1144) 41546* __satfractsauta: Fixed-point fractional library routines. 41547 (line 1149) 41548* __satfractsfda: Fixed-point fractional library routines. 41549 (line 1490) 41550* __satfractsfdq: Fixed-point fractional library routines. 41551 (line 1487) 41552* __satfractsfha: Fixed-point fractional library routines. 41553 (line 1488) 41554* __satfractsfhq: Fixed-point fractional library routines. 41555 (line 1485) 41556* __satfractsfqq: Fixed-point fractional library routines. 41557 (line 1484) 41558* __satfractsfsa: Fixed-point fractional library routines. 41559 (line 1489) 41560* __satfractsfsq: Fixed-point fractional library routines. 41561 (line 1486) 41562* __satfractsfta: Fixed-point fractional library routines. 41563 (line 1491) 41564* __satfractsfuda: Fixed-point fractional library routines. 41565 (line 1498) 41566* __satfractsfudq: Fixed-point fractional library routines. 41567 (line 1495) 41568* __satfractsfuha: Fixed-point fractional library routines. 41569 (line 1496) 41570* __satfractsfuhq: Fixed-point fractional library routines. 41571 (line 1493) 41572* __satfractsfuqq: Fixed-point fractional library routines. 41573 (line 1492) 41574* __satfractsfusa: Fixed-point fractional library routines. 41575 (line 1497) 41576* __satfractsfusq: Fixed-point fractional library routines. 41577 (line 1494) 41578* __satfractsfuta: Fixed-point fractional library routines. 41579 (line 1499) 41580* __satfractsida: Fixed-point fractional library routines. 41581 (line 1440) 41582* __satfractsidq: Fixed-point fractional library routines. 41583 (line 1437) 41584* __satfractsiha: Fixed-point fractional library routines. 41585 (line 1438) 41586* __satfractsihq: Fixed-point fractional library routines. 41587 (line 1435) 41588* __satfractsiqq: Fixed-point fractional library routines. 41589 (line 1434) 41590* __satfractsisa: Fixed-point fractional library routines. 41591 (line 1439) 41592* __satfractsisq: Fixed-point fractional library routines. 41593 (line 1436) 41594* __satfractsita: Fixed-point fractional library routines. 41595 (line 1441) 41596* __satfractsiuda: Fixed-point fractional library routines. 41597 (line 1448) 41598* __satfractsiudq: Fixed-point fractional library routines. 41599 (line 1445) 41600* __satfractsiuha: Fixed-point fractional library routines. 41601 (line 1446) 41602* __satfractsiuhq: Fixed-point fractional library routines. 41603 (line 1443) 41604* __satfractsiuqq: Fixed-point fractional library routines. 41605 (line 1442) 41606* __satfractsiusa: Fixed-point fractional library routines. 41607 (line 1447) 41608* __satfractsiusq: Fixed-point fractional library routines. 41609 (line 1444) 41610* __satfractsiuta: Fixed-point fractional library routines. 41611 (line 1449) 41612* __satfractsqda: Fixed-point fractional library routines. 41613 (line 1079) 41614* __satfractsqdq2: Fixed-point fractional library routines. 41615 (line 1076) 41616* __satfractsqha: Fixed-point fractional library routines. 41617 (line 1077) 41618* __satfractsqhq2: Fixed-point fractional library routines. 41619 (line 1075) 41620* __satfractsqqq2: Fixed-point fractional library routines. 41621 (line 1074) 41622* __satfractsqsa: Fixed-point fractional library routines. 41623 (line 1078) 41624* __satfractsqta: Fixed-point fractional library routines. 41625 (line 1080) 41626* __satfractsquda: Fixed-point fractional library routines. 41627 (line 1090) 41628* __satfractsqudq: Fixed-point fractional library routines. 41629 (line 1086) 41630* __satfractsquha: Fixed-point fractional library routines. 41631 (line 1088) 41632* __satfractsquhq: Fixed-point fractional library routines. 41633 (line 1083) 41634* __satfractsquqq: Fixed-point fractional library routines. 41635 (line 1082) 41636* __satfractsqusa: Fixed-point fractional library routines. 41637 (line 1089) 41638* __satfractsqusq: Fixed-point fractional library routines. 41639 (line 1084) 41640* __satfractsquta: Fixed-point fractional library routines. 41641 (line 1092) 41642* __satfracttada2: Fixed-point fractional library routines. 41643 (line 1175) 41644* __satfracttadq: Fixed-point fractional library routines. 41645 (line 1172) 41646* __satfracttaha2: Fixed-point fractional library routines. 41647 (line 1173) 41648* __satfracttahq: Fixed-point fractional library routines. 41649 (line 1170) 41650* __satfracttaqq: Fixed-point fractional library routines. 41651 (line 1169) 41652* __satfracttasa2: Fixed-point fractional library routines. 41653 (line 1174) 41654* __satfracttasq: Fixed-point fractional library routines. 41655 (line 1171) 41656* __satfracttauda: Fixed-point fractional library routines. 41657 (line 1187) 41658* __satfracttaudq: Fixed-point fractional library routines. 41659 (line 1182) 41660* __satfracttauha: Fixed-point fractional library routines. 41661 (line 1184) 41662* __satfracttauhq: Fixed-point fractional library routines. 41663 (line 1178) 41664* __satfracttauqq: Fixed-point fractional library routines. 41665 (line 1177) 41666* __satfracttausa: Fixed-point fractional library routines. 41667 (line 1185) 41668* __satfracttausq: Fixed-point fractional library routines. 41669 (line 1180) 41670* __satfracttauta: Fixed-point fractional library routines. 41671 (line 1189) 41672* __satfracttida: Fixed-point fractional library routines. 41673 (line 1472) 41674* __satfracttidq: Fixed-point fractional library routines. 41675 (line 1469) 41676* __satfracttiha: Fixed-point fractional library routines. 41677 (line 1470) 41678* __satfracttihq: Fixed-point fractional library routines. 41679 (line 1467) 41680* __satfracttiqq: Fixed-point fractional library routines. 41681 (line 1466) 41682* __satfracttisa: Fixed-point fractional library routines. 41683 (line 1471) 41684* __satfracttisq: Fixed-point fractional library routines. 41685 (line 1468) 41686* __satfracttita: Fixed-point fractional library routines. 41687 (line 1473) 41688* __satfracttiuda: Fixed-point fractional library routines. 41689 (line 1481) 41690* __satfracttiudq: Fixed-point fractional library routines. 41691 (line 1478) 41692* __satfracttiuha: Fixed-point fractional library routines. 41693 (line 1479) 41694* __satfracttiuhq: Fixed-point fractional library routines. 41695 (line 1475) 41696* __satfracttiuqq: Fixed-point fractional library routines. 41697 (line 1474) 41698* __satfracttiusa: Fixed-point fractional library routines. 41699 (line 1480) 41700* __satfracttiusq: Fixed-point fractional library routines. 41701 (line 1476) 41702* __satfracttiuta: Fixed-point fractional library routines. 41703 (line 1483) 41704* __satfractudada: Fixed-point fractional library routines. 41705 (line 1351) 41706* __satfractudadq: Fixed-point fractional library routines. 41707 (line 1347) 41708* __satfractudaha: Fixed-point fractional library routines. 41709 (line 1349) 41710* __satfractudahq: Fixed-point fractional library routines. 41711 (line 1344) 41712* __satfractudaqq: Fixed-point fractional library routines. 41713 (line 1343) 41714* __satfractudasa: Fixed-point fractional library routines. 41715 (line 1350) 41716* __satfractudasq: Fixed-point fractional library routines. 41717 (line 1345) 41718* __satfractudata: Fixed-point fractional library routines. 41719 (line 1353) 41720* __satfractudaudq: Fixed-point fractional library routines. 41721 (line 1361) 41722* __satfractudauha2: Fixed-point fractional library routines. 41723 (line 1363) 41724* __satfractudauhq: Fixed-point fractional library routines. 41725 (line 1357) 41726* __satfractudauqq: Fixed-point fractional library routines. 41727 (line 1355) 41728* __satfractudausa2: Fixed-point fractional library routines. 41729 (line 1365) 41730* __satfractudausq: Fixed-point fractional library routines. 41731 (line 1359) 41732* __satfractudauta2: Fixed-point fractional library routines. 41733 (line 1367) 41734* __satfractudqda: Fixed-point fractional library routines. 41735 (line 1276) 41736* __satfractudqdq: Fixed-point fractional library routines. 41737 (line 1271) 41738* __satfractudqha: Fixed-point fractional library routines. 41739 (line 1273) 41740* __satfractudqhq: Fixed-point fractional library routines. 41741 (line 1267) 41742* __satfractudqqq: Fixed-point fractional library routines. 41743 (line 1266) 41744* __satfractudqsa: Fixed-point fractional library routines. 41745 (line 1274) 41746* __satfractudqsq: Fixed-point fractional library routines. 41747 (line 1269) 41748* __satfractudqta: Fixed-point fractional library routines. 41749 (line 1278) 41750* __satfractudquda: Fixed-point fractional library routines. 41751 (line 1290) 41752* __satfractudquha: Fixed-point fractional library routines. 41753 (line 1286) 41754* __satfractudquhq2: Fixed-point fractional library routines. 41755 (line 1282) 41756* __satfractudquqq2: Fixed-point fractional library routines. 41757 (line 1280) 41758* __satfractudqusa: Fixed-point fractional library routines. 41759 (line 1288) 41760* __satfractudqusq2: Fixed-point fractional library routines. 41761 (line 1284) 41762* __satfractudquta: Fixed-point fractional library routines. 41763 (line 1292) 41764* __satfractuhada: Fixed-point fractional library routines. 41765 (line 1304) 41766* __satfractuhadq: Fixed-point fractional library routines. 41767 (line 1299) 41768* __satfractuhaha: Fixed-point fractional library routines. 41769 (line 1301) 41770* __satfractuhahq: Fixed-point fractional library routines. 41771 (line 1295) 41772* __satfractuhaqq: Fixed-point fractional library routines. 41773 (line 1294) 41774* __satfractuhasa: Fixed-point fractional library routines. 41775 (line 1302) 41776* __satfractuhasq: Fixed-point fractional library routines. 41777 (line 1297) 41778* __satfractuhata: Fixed-point fractional library routines. 41779 (line 1306) 41780* __satfractuhauda2: Fixed-point fractional library routines. 41781 (line 1318) 41782* __satfractuhaudq: Fixed-point fractional library routines. 41783 (line 1314) 41784* __satfractuhauhq: Fixed-point fractional library routines. 41785 (line 1310) 41786* __satfractuhauqq: Fixed-point fractional library routines. 41787 (line 1308) 41788* __satfractuhausa2: Fixed-point fractional library routines. 41789 (line 1316) 41790* __satfractuhausq: Fixed-point fractional library routines. 41791 (line 1312) 41792* __satfractuhauta2: Fixed-point fractional library routines. 41793 (line 1320) 41794* __satfractuhqda: Fixed-point fractional library routines. 41795 (line 1224) 41796* __satfractuhqdq: Fixed-point fractional library routines. 41797 (line 1221) 41798* __satfractuhqha: Fixed-point fractional library routines. 41799 (line 1222) 41800* __satfractuhqhq: Fixed-point fractional library routines. 41801 (line 1219) 41802* __satfractuhqqq: Fixed-point fractional library routines. 41803 (line 1218) 41804* __satfractuhqsa: Fixed-point fractional library routines. 41805 (line 1223) 41806* __satfractuhqsq: Fixed-point fractional library routines. 41807 (line 1220) 41808* __satfractuhqta: Fixed-point fractional library routines. 41809 (line 1225) 41810* __satfractuhquda: Fixed-point fractional library routines. 41811 (line 1236) 41812* __satfractuhqudq2: Fixed-point fractional library routines. 41813 (line 1231) 41814* __satfractuhquha: Fixed-point fractional library routines. 41815 (line 1233) 41816* __satfractuhquqq2: Fixed-point fractional library routines. 41817 (line 1227) 41818* __satfractuhqusa: Fixed-point fractional library routines. 41819 (line 1234) 41820* __satfractuhqusq2: Fixed-point fractional library routines. 41821 (line 1229) 41822* __satfractuhquta: Fixed-point fractional library routines. 41823 (line 1238) 41824* __satfractunsdida: Fixed-point fractional library routines. 41825 (line 1834) 41826* __satfractunsdidq: Fixed-point fractional library routines. 41827 (line 1831) 41828* __satfractunsdiha: Fixed-point fractional library routines. 41829 (line 1832) 41830* __satfractunsdihq: Fixed-point fractional library routines. 41831 (line 1828) 41832* __satfractunsdiqq: Fixed-point fractional library routines. 41833 (line 1827) 41834* __satfractunsdisa: Fixed-point fractional library routines. 41835 (line 1833) 41836* __satfractunsdisq: Fixed-point fractional library routines. 41837 (line 1829) 41838* __satfractunsdita: Fixed-point fractional library routines. 41839 (line 1836) 41840* __satfractunsdiuda: Fixed-point fractional library routines. 41841 (line 1850) 41842* __satfractunsdiudq: Fixed-point fractional library routines. 41843 (line 1844) 41844* __satfractunsdiuha: Fixed-point fractional library routines. 41845 (line 1846) 41846* __satfractunsdiuhq: Fixed-point fractional library routines. 41847 (line 1840) 41848* __satfractunsdiuqq: Fixed-point fractional library routines. 41849 (line 1838) 41850* __satfractunsdiusa: Fixed-point fractional library routines. 41851 (line 1848) 41852* __satfractunsdiusq: Fixed-point fractional library routines. 41853 (line 1842) 41854* __satfractunsdiuta: Fixed-point fractional library routines. 41855 (line 1852) 41856* __satfractunshida: Fixed-point fractional library routines. 41857 (line 1786) 41858* __satfractunshidq: Fixed-point fractional library routines. 41859 (line 1783) 41860* __satfractunshiha: Fixed-point fractional library routines. 41861 (line 1784) 41862* __satfractunshihq: Fixed-point fractional library routines. 41863 (line 1780) 41864* __satfractunshiqq: Fixed-point fractional library routines. 41865 (line 1779) 41866* __satfractunshisa: Fixed-point fractional library routines. 41867 (line 1785) 41868* __satfractunshisq: Fixed-point fractional library routines. 41869 (line 1781) 41870* __satfractunshita: Fixed-point fractional library routines. 41871 (line 1788) 41872* __satfractunshiuda: Fixed-point fractional library routines. 41873 (line 1802) 41874* __satfractunshiudq: Fixed-point fractional library routines. 41875 (line 1796) 41876* __satfractunshiuha: Fixed-point fractional library routines. 41877 (line 1798) 41878* __satfractunshiuhq: Fixed-point fractional library routines. 41879 (line 1792) 41880* __satfractunshiuqq: Fixed-point fractional library routines. 41881 (line 1790) 41882* __satfractunshiusa: Fixed-point fractional library routines. 41883 (line 1800) 41884* __satfractunshiusq: Fixed-point fractional library routines. 41885 (line 1794) 41886* __satfractunshiuta: Fixed-point fractional library routines. 41887 (line 1804) 41888* __satfractunsqida: Fixed-point fractional library routines. 41889 (line 1760) 41890* __satfractunsqidq: Fixed-point fractional library routines. 41891 (line 1757) 41892* __satfractunsqiha: Fixed-point fractional library routines. 41893 (line 1758) 41894* __satfractunsqihq: Fixed-point fractional library routines. 41895 (line 1754) 41896* __satfractunsqiqq: Fixed-point fractional library routines. 41897 (line 1753) 41898* __satfractunsqisa: Fixed-point fractional library routines. 41899 (line 1759) 41900* __satfractunsqisq: Fixed-point fractional library routines. 41901 (line 1755) 41902* __satfractunsqita: Fixed-point fractional library routines. 41903 (line 1762) 41904* __satfractunsqiuda: Fixed-point fractional library routines. 41905 (line 1776) 41906* __satfractunsqiudq: Fixed-point fractional library routines. 41907 (line 1770) 41908* __satfractunsqiuha: Fixed-point fractional library routines. 41909 (line 1772) 41910* __satfractunsqiuhq: Fixed-point fractional library routines. 41911 (line 1766) 41912* __satfractunsqiuqq: Fixed-point fractional library routines. 41913 (line 1764) 41914* __satfractunsqiusa: Fixed-point fractional library routines. 41915 (line 1774) 41916* __satfractunsqiusq: Fixed-point fractional library routines. 41917 (line 1768) 41918* __satfractunsqiuta: Fixed-point fractional library routines. 41919 (line 1778) 41920* __satfractunssida: Fixed-point fractional library routines. 41921 (line 1811) 41922* __satfractunssidq: Fixed-point fractional library routines. 41923 (line 1808) 41924* __satfractunssiha: Fixed-point fractional library routines. 41925 (line 1809) 41926* __satfractunssihq: Fixed-point fractional library routines. 41927 (line 1806) 41928* __satfractunssiqq: Fixed-point fractional library routines. 41929 (line 1805) 41930* __satfractunssisa: Fixed-point fractional library routines. 41931 (line 1810) 41932* __satfractunssisq: Fixed-point fractional library routines. 41933 (line 1807) 41934* __satfractunssita: Fixed-point fractional library routines. 41935 (line 1812) 41936* __satfractunssiuda: Fixed-point fractional library routines. 41937 (line 1824) 41938* __satfractunssiudq: Fixed-point fractional library routines. 41939 (line 1819) 41940* __satfractunssiuha: Fixed-point fractional library routines. 41941 (line 1821) 41942* __satfractunssiuhq: Fixed-point fractional library routines. 41943 (line 1815) 41944* __satfractunssiuqq: Fixed-point fractional library routines. 41945 (line 1814) 41946* __satfractunssiusa: Fixed-point fractional library routines. 41947 (line 1822) 41948* __satfractunssiusq: Fixed-point fractional library routines. 41949 (line 1817) 41950* __satfractunssiuta: Fixed-point fractional library routines. 41951 (line 1826) 41952* __satfractunstida: Fixed-point fractional library routines. 41953 (line 1864) 41954* __satfractunstidq: Fixed-point fractional library routines. 41955 (line 1859) 41956* __satfractunstiha: Fixed-point fractional library routines. 41957 (line 1861) 41958* __satfractunstihq: Fixed-point fractional library routines. 41959 (line 1855) 41960* __satfractunstiqq: Fixed-point fractional library routines. 41961 (line 1854) 41962* __satfractunstisa: Fixed-point fractional library routines. 41963 (line 1862) 41964* __satfractunstisq: Fixed-point fractional library routines. 41965 (line 1857) 41966* __satfractunstita: Fixed-point fractional library routines. 41967 (line 1866) 41968* __satfractunstiuda: Fixed-point fractional library routines. 41969 (line 1880) 41970* __satfractunstiudq: Fixed-point fractional library routines. 41971 (line 1874) 41972* __satfractunstiuha: Fixed-point fractional library routines. 41973 (line 1876) 41974* __satfractunstiuhq: Fixed-point fractional library routines. 41975 (line 1870) 41976* __satfractunstiuqq: Fixed-point fractional library routines. 41977 (line 1868) 41978* __satfractunstiusa: Fixed-point fractional library routines. 41979 (line 1878) 41980* __satfractunstiusq: Fixed-point fractional library routines. 41981 (line 1872) 41982* __satfractunstiuta: Fixed-point fractional library routines. 41983 (line 1882) 41984* __satfractuqqda: Fixed-point fractional library routines. 41985 (line 1201) 41986* __satfractuqqdq: Fixed-point fractional library routines. 41987 (line 1196) 41988* __satfractuqqha: Fixed-point fractional library routines. 41989 (line 1198) 41990* __satfractuqqhq: Fixed-point fractional library routines. 41991 (line 1192) 41992* __satfractuqqqq: Fixed-point fractional library routines. 41993 (line 1191) 41994* __satfractuqqsa: Fixed-point fractional library routines. 41995 (line 1199) 41996* __satfractuqqsq: Fixed-point fractional library routines. 41997 (line 1194) 41998* __satfractuqqta: Fixed-point fractional library routines. 41999 (line 1203) 42000* __satfractuqquda: Fixed-point fractional library routines. 42001 (line 1215) 42002* __satfractuqqudq2: Fixed-point fractional library routines. 42003 (line 1209) 42004* __satfractuqquha: Fixed-point fractional library routines. 42005 (line 1211) 42006* __satfractuqquhq2: Fixed-point fractional library routines. 42007 (line 1205) 42008* __satfractuqqusa: Fixed-point fractional library routines. 42009 (line 1213) 42010* __satfractuqqusq2: Fixed-point fractional library routines. 42011 (line 1207) 42012* __satfractuqquta: Fixed-point fractional library routines. 42013 (line 1217) 42014* __satfractusada: Fixed-point fractional library routines. 42015 (line 1327) 42016* __satfractusadq: Fixed-point fractional library routines. 42017 (line 1324) 42018* __satfractusaha: Fixed-point fractional library routines. 42019 (line 1325) 42020* __satfractusahq: Fixed-point fractional library routines. 42021 (line 1322) 42022* __satfractusaqq: Fixed-point fractional library routines. 42023 (line 1321) 42024* __satfractusasa: Fixed-point fractional library routines. 42025 (line 1326) 42026* __satfractusasq: Fixed-point fractional library routines. 42027 (line 1323) 42028* __satfractusata: Fixed-point fractional library routines. 42029 (line 1328) 42030* __satfractusauda2: Fixed-point fractional library routines. 42031 (line 1339) 42032* __satfractusaudq: Fixed-point fractional library routines. 42033 (line 1335) 42034* __satfractusauha2: Fixed-point fractional library routines. 42035 (line 1337) 42036* __satfractusauhq: Fixed-point fractional library routines. 42037 (line 1331) 42038* __satfractusauqq: Fixed-point fractional library routines. 42039 (line 1330) 42040* __satfractusausq: Fixed-point fractional library routines. 42041 (line 1333) 42042* __satfractusauta2: Fixed-point fractional library routines. 42043 (line 1341) 42044* __satfractusqda: Fixed-point fractional library routines. 42045 (line 1248) 42046* __satfractusqdq: Fixed-point fractional library routines. 42047 (line 1244) 42048* __satfractusqha: Fixed-point fractional library routines. 42049 (line 1246) 42050* __satfractusqhq: Fixed-point fractional library routines. 42051 (line 1241) 42052* __satfractusqqq: Fixed-point fractional library routines. 42053 (line 1240) 42054* __satfractusqsa: Fixed-point fractional library routines. 42055 (line 1247) 42056* __satfractusqsq: Fixed-point fractional library routines. 42057 (line 1242) 42058* __satfractusqta: Fixed-point fractional library routines. 42059 (line 1250) 42060* __satfractusquda: Fixed-point fractional library routines. 42061 (line 1262) 42062* __satfractusqudq2: Fixed-point fractional library routines. 42063 (line 1256) 42064* __satfractusquha: Fixed-point fractional library routines. 42065 (line 1258) 42066* __satfractusquhq2: Fixed-point fractional library routines. 42067 (line 1254) 42068* __satfractusquqq2: Fixed-point fractional library routines. 42069 (line 1252) 42070* __satfractusqusa: Fixed-point fractional library routines. 42071 (line 1260) 42072* __satfractusquta: Fixed-point fractional library routines. 42073 (line 1264) 42074* __satfractutada: Fixed-point fractional library routines. 42075 (line 1379) 42076* __satfractutadq: Fixed-point fractional library routines. 42077 (line 1374) 42078* __satfractutaha: Fixed-point fractional library routines. 42079 (line 1376) 42080* __satfractutahq: Fixed-point fractional library routines. 42081 (line 1370) 42082* __satfractutaqq: Fixed-point fractional library routines. 42083 (line 1369) 42084* __satfractutasa: Fixed-point fractional library routines. 42085 (line 1377) 42086* __satfractutasq: Fixed-point fractional library routines. 42087 (line 1372) 42088* __satfractutata: Fixed-point fractional library routines. 42089 (line 1381) 42090* __satfractutauda2: Fixed-point fractional library routines. 42091 (line 1395) 42092* __satfractutaudq: Fixed-point fractional library routines. 42093 (line 1389) 42094* __satfractutauha2: Fixed-point fractional library routines. 42095 (line 1391) 42096* __satfractutauhq: Fixed-point fractional library routines. 42097 (line 1385) 42098* __satfractutauqq: Fixed-point fractional library routines. 42099 (line 1383) 42100* __satfractutausa2: Fixed-point fractional library routines. 42101 (line 1393) 42102* __satfractutausq: Fixed-point fractional library routines. 42103 (line 1387) 42104* __ssaddda3: Fixed-point fractional library routines. 42105 (line 67) 42106* __ssadddq3: Fixed-point fractional library routines. 42107 (line 63) 42108* __ssaddha3: Fixed-point fractional library routines. 42109 (line 65) 42110* __ssaddhq3: Fixed-point fractional library routines. 42111 (line 60) 42112* __ssaddqq3: Fixed-point fractional library routines. 42113 (line 59) 42114* __ssaddsa3: Fixed-point fractional library routines. 42115 (line 66) 42116* __ssaddsq3: Fixed-point fractional library routines. 42117 (line 61) 42118* __ssaddta3: Fixed-point fractional library routines. 42119 (line 69) 42120* __ssashlda3: Fixed-point fractional library routines. 42121 (line 402) 42122* __ssashldq3: Fixed-point fractional library routines. 42123 (line 399) 42124* __ssashlha3: Fixed-point fractional library routines. 42125 (line 400) 42126* __ssashlhq3: Fixed-point fractional library routines. 42127 (line 396) 42128* __ssashlsa3: Fixed-point fractional library routines. 42129 (line 401) 42130* __ssashlsq3: Fixed-point fractional library routines. 42131 (line 397) 42132* __ssashlta3: Fixed-point fractional library routines. 42133 (line 404) 42134* __ssdivda3: Fixed-point fractional library routines. 42135 (line 261) 42136* __ssdivdq3: Fixed-point fractional library routines. 42137 (line 257) 42138* __ssdivha3: Fixed-point fractional library routines. 42139 (line 259) 42140* __ssdivhq3: Fixed-point fractional library routines. 42141 (line 254) 42142* __ssdivqq3: Fixed-point fractional library routines. 42143 (line 253) 42144* __ssdivsa3: Fixed-point fractional library routines. 42145 (line 260) 42146* __ssdivsq3: Fixed-point fractional library routines. 42147 (line 255) 42148* __ssdivta3: Fixed-point fractional library routines. 42149 (line 263) 42150* __ssmulda3: Fixed-point fractional library routines. 42151 (line 193) 42152* __ssmuldq3: Fixed-point fractional library routines. 42153 (line 189) 42154* __ssmulha3: Fixed-point fractional library routines. 42155 (line 191) 42156* __ssmulhq3: Fixed-point fractional library routines. 42157 (line 186) 42158* __ssmulqq3: Fixed-point fractional library routines. 42159 (line 185) 42160* __ssmulsa3: Fixed-point fractional library routines. 42161 (line 192) 42162* __ssmulsq3: Fixed-point fractional library routines. 42163 (line 187) 42164* __ssmulta3: Fixed-point fractional library routines. 42165 (line 195) 42166* __ssnegda2: Fixed-point fractional library routines. 42167 (line 316) 42168* __ssnegdq2: Fixed-point fractional library routines. 42169 (line 313) 42170* __ssnegha2: Fixed-point fractional library routines. 42171 (line 314) 42172* __ssneghq2: Fixed-point fractional library routines. 42173 (line 311) 42174* __ssnegqq2: Fixed-point fractional library routines. 42175 (line 310) 42176* __ssnegsa2: Fixed-point fractional library routines. 42177 (line 315) 42178* __ssnegsq2: Fixed-point fractional library routines. 42179 (line 312) 42180* __ssnegta2: Fixed-point fractional library routines. 42181 (line 317) 42182* __sssubda3: Fixed-point fractional library routines. 42183 (line 129) 42184* __sssubdq3: Fixed-point fractional library routines. 42185 (line 125) 42186* __sssubha3: Fixed-point fractional library routines. 42187 (line 127) 42188* __sssubhq3: Fixed-point fractional library routines. 42189 (line 122) 42190* __sssubqq3: Fixed-point fractional library routines. 42191 (line 121) 42192* __sssubsa3: Fixed-point fractional library routines. 42193 (line 128) 42194* __sssubsq3: Fixed-point fractional library routines. 42195 (line 123) 42196* __sssubta3: Fixed-point fractional library routines. 42197 (line 131) 42198* __subda3: Fixed-point fractional library routines. 42199 (line 107) 42200* __subdf3: Soft float library routines. 42201 (line 31) 42202* __subdq3: Fixed-point fractional library routines. 42203 (line 95) 42204* __subha3: Fixed-point fractional library routines. 42205 (line 105) 42206* __subhq3: Fixed-point fractional library routines. 42207 (line 92) 42208* __subqq3: Fixed-point fractional library routines. 42209 (line 91) 42210* __subsa3: Fixed-point fractional library routines. 42211 (line 106) 42212* __subsf3: Soft float library routines. 42213 (line 30) 42214* __subsq3: Fixed-point fractional library routines. 42215 (line 93) 42216* __subta3: Fixed-point fractional library routines. 42217 (line 109) 42218* __subtf3: Soft float library routines. 42219 (line 33) 42220* __subuda3: Fixed-point fractional library routines. 42221 (line 115) 42222* __subudq3: Fixed-point fractional library routines. 42223 (line 103) 42224* __subuha3: Fixed-point fractional library routines. 42225 (line 111) 42226* __subuhq3: Fixed-point fractional library routines. 42227 (line 99) 42228* __subuqq3: Fixed-point fractional library routines. 42229 (line 97) 42230* __subusa3: Fixed-point fractional library routines. 42231 (line 113) 42232* __subusq3: Fixed-point fractional library routines. 42233 (line 101) 42234* __subuta3: Fixed-point fractional library routines. 42235 (line 117) 42236* __subvdi3: Integer library routines. 42237 (line 123) 42238* __subvsi3: Integer library routines. 42239 (line 122) 42240* __subxf3: Soft float library routines. 42241 (line 35) 42242* __truncdfsf2: Soft float library routines. 42243 (line 76) 42244* __trunctfdf2: Soft float library routines. 42245 (line 73) 42246* __trunctfsf2: Soft float library routines. 42247 (line 75) 42248* __truncxfdf2: Soft float library routines. 42249 (line 72) 42250* __truncxfsf2: Soft float library routines. 42251 (line 74) 42252* __ucmpdi2: Integer library routines. 42253 (line 93) 42254* __ucmpti2: Integer library routines. 42255 (line 95) 42256* __udivdi3: Integer library routines. 42257 (line 54) 42258* __udivmoddi3: Integer library routines. 42259 (line 61) 42260* __udivsi3: Integer library routines. 42261 (line 52) 42262* __udivti3: Integer library routines. 42263 (line 56) 42264* __udivuda3: Fixed-point fractional library routines. 42265 (line 246) 42266* __udivudq3: Fixed-point fractional library routines. 42267 (line 240) 42268* __udivuha3: Fixed-point fractional library routines. 42269 (line 242) 42270* __udivuhq3: Fixed-point fractional library routines. 42271 (line 236) 42272* __udivuqq3: Fixed-point fractional library routines. 42273 (line 234) 42274* __udivusa3: Fixed-point fractional library routines. 42275 (line 244) 42276* __udivusq3: Fixed-point fractional library routines. 42277 (line 238) 42278* __udivuta3: Fixed-point fractional library routines. 42279 (line 248) 42280* __umoddi3: Integer library routines. 42281 (line 71) 42282* __umodsi3: Integer library routines. 42283 (line 69) 42284* __umodti3: Integer library routines. 42285 (line 73) 42286* __unorddf2: Soft float library routines. 42287 (line 173) 42288* __unordsf2: Soft float library routines. 42289 (line 172) 42290* __unordtf2: Soft float library routines. 42291 (line 174) 42292* __usadduda3: Fixed-point fractional library routines. 42293 (line 85) 42294* __usaddudq3: Fixed-point fractional library routines. 42295 (line 79) 42296* __usadduha3: Fixed-point fractional library routines. 42297 (line 81) 42298* __usadduhq3: Fixed-point fractional library routines. 42299 (line 75) 42300* __usadduqq3: Fixed-point fractional library routines. 42301 (line 73) 42302* __usaddusa3: Fixed-point fractional library routines. 42303 (line 83) 42304* __usaddusq3: Fixed-point fractional library routines. 42305 (line 77) 42306* __usadduta3: Fixed-point fractional library routines. 42307 (line 87) 42308* __usashluda3: Fixed-point fractional library routines. 42309 (line 421) 42310* __usashludq3: Fixed-point fractional library routines. 42311 (line 415) 42312* __usashluha3: Fixed-point fractional library routines. 42313 (line 417) 42314* __usashluhq3: Fixed-point fractional library routines. 42315 (line 411) 42316* __usashluqq3: Fixed-point fractional library routines. 42317 (line 409) 42318* __usashlusa3: Fixed-point fractional library routines. 42319 (line 419) 42320* __usashlusq3: Fixed-point fractional library routines. 42321 (line 413) 42322* __usashluta3: Fixed-point fractional library routines. 42323 (line 423) 42324* __usdivuda3: Fixed-point fractional library routines. 42325 (line 280) 42326* __usdivudq3: Fixed-point fractional library routines. 42327 (line 274) 42328* __usdivuha3: Fixed-point fractional library routines. 42329 (line 276) 42330* __usdivuhq3: Fixed-point fractional library routines. 42331 (line 270) 42332* __usdivuqq3: Fixed-point fractional library routines. 42333 (line 268) 42334* __usdivusa3: Fixed-point fractional library routines. 42335 (line 278) 42336* __usdivusq3: Fixed-point fractional library routines. 42337 (line 272) 42338* __usdivuta3: Fixed-point fractional library routines. 42339 (line 282) 42340* __usmuluda3: Fixed-point fractional library routines. 42341 (line 212) 42342* __usmuludq3: Fixed-point fractional library routines. 42343 (line 206) 42344* __usmuluha3: Fixed-point fractional library routines. 42345 (line 208) 42346* __usmuluhq3: Fixed-point fractional library routines. 42347 (line 202) 42348* __usmuluqq3: Fixed-point fractional library routines. 42349 (line 200) 42350* __usmulusa3: Fixed-point fractional library routines. 42351 (line 210) 42352* __usmulusq3: Fixed-point fractional library routines. 42353 (line 204) 42354* __usmuluta3: Fixed-point fractional library routines. 42355 (line 214) 42356* __usneguda2: Fixed-point fractional library routines. 42357 (line 331) 42358* __usnegudq2: Fixed-point fractional library routines. 42359 (line 326) 42360* __usneguha2: Fixed-point fractional library routines. 42361 (line 328) 42362* __usneguhq2: Fixed-point fractional library routines. 42363 (line 322) 42364* __usneguqq2: Fixed-point fractional library routines. 42365 (line 321) 42366* __usnegusa2: Fixed-point fractional library routines. 42367 (line 329) 42368* __usnegusq2: Fixed-point fractional library routines. 42369 (line 324) 42370* __usneguta2: Fixed-point fractional library routines. 42371 (line 333) 42372* __ussubuda3: Fixed-point fractional library routines. 42373 (line 148) 42374* __ussubudq3: Fixed-point fractional library routines. 42375 (line 142) 42376* __ussubuha3: Fixed-point fractional library routines. 42377 (line 144) 42378* __ussubuhq3: Fixed-point fractional library routines. 42379 (line 138) 42380* __ussubuqq3: Fixed-point fractional library routines. 42381 (line 136) 42382* __ussubusa3: Fixed-point fractional library routines. 42383 (line 146) 42384* __ussubusq3: Fixed-point fractional library routines. 42385 (line 140) 42386* __ussubuta3: Fixed-point fractional library routines. 42387 (line 150) 42388* abort: Portability. (line 21) 42389* abs: Arithmetic. (line 195) 42390* abs and attributes: Expressions. (line 64) 42391* ABS_EXPR: Unary and Binary Expressions. 42392 (line 6) 42393* absence_set: Processor pipeline description. 42394 (line 220) 42395* absM2 instruction pattern: Standard Names. (line 452) 42396* absolute value: Arithmetic. (line 195) 42397* access to operands: Accessors. (line 6) 42398* access to special operands: Special Accessors. (line 6) 42399* accessors: Accessors. (line 6) 42400* ACCUM_TYPE_SIZE: Type Layout. (line 88) 42401* ACCUMULATE_OUTGOING_ARGS: Stack Arguments. (line 46) 42402* ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line 135) 42403* ADA_LONG_TYPE_SIZE: Type Layout. (line 26) 42404* Adding a new GIMPLE statement code: Adding a new GIMPLE statement code. 42405 (line 6) 42406* ADDITIONAL_REGISTER_NAMES: Instruction Output. (line 15) 42407* addM3 instruction pattern: Standard Names. (line 216) 42408* addMODEcc instruction pattern: Standard Names. (line 890) 42409* addr_diff_vec: Side Effects. (line 302) 42410* addr_diff_vec, length of: Insn Lengths. (line 26) 42411* ADDR_EXPR: Storage References. (line 6) 42412* addr_vec: Side Effects. (line 297) 42413* addr_vec, length of: Insn Lengths. (line 26) 42414* address constraints: Simple Constraints. (line 154) 42415* address_operand <1>: Simple Constraints. (line 158) 42416* address_operand: Machine-Independent Predicates. 42417 (line 63) 42418* addressing modes: Addressing Modes. (line 6) 42419* ADJUST_FIELD_ALIGN: Storage Layout. (line 202) 42420* ADJUST_INSN_LENGTH: Insn Lengths. (line 35) 42421* aggregates as return values: Aggregate Return. (line 6) 42422* alias: Alias analysis. (line 6) 42423* ALL_COP_ADDITIONAL_REGISTER_NAMES: MIPS Coprocessors. (line 32) 42424* ALL_REGS: Register Classes. (line 17) 42425* allocate_stack instruction pattern: Standard Names. (line 1190) 42426* alternate entry points: Insns. (line 140) 42427* anchored addresses: Anchored Addresses. (line 6) 42428* and: Arithmetic. (line 153) 42429* and and attributes: Expressions. (line 50) 42430* and, canonicalization of: Insn Canonicalizations. 42431 (line 52) 42432* andM3 instruction pattern: Standard Names. (line 222) 42433* annotations: Annotations. (line 6) 42434* APPLY_RESULT_SIZE: Scalar Return. (line 107) 42435* ARG_POINTER_CFA_OFFSET: Frame Layout. (line 194) 42436* ARG_POINTER_REGNUM: Frame Registers. (line 41) 42437* ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line 65) 42438* arg_pointer_rtx: Frame Registers. (line 90) 42439* ARGS_GROW_DOWNWARD: Frame Layout. (line 35) 42440* argument passing: Interface. (line 36) 42441* arguments in registers: Register Arguments. (line 6) 42442* arguments on stack: Stack Arguments. (line 6) 42443* arithmetic library: Soft float library routines. 42444 (line 6) 42445* arithmetic shift: Arithmetic. (line 168) 42446* arithmetic shift with signed saturation: Arithmetic. (line 168) 42447* arithmetic shift with unsigned saturation: Arithmetic. (line 168) 42448* arithmetic, in RTL: Arithmetic. (line 6) 42449* ARITHMETIC_TYPE_P: Types for C++. (line 61) 42450* array: Types. (line 6) 42451* ARRAY_RANGE_REF: Storage References. (line 6) 42452* ARRAY_REF: Storage References. (line 6) 42453* ARRAY_TYPE: Types. (line 6) 42454* AS_NEEDS_DASH_FOR_PIPED_INPUT: Driver. (line 151) 42455* ashift: Arithmetic. (line 168) 42456* ashift and attributes: Expressions. (line 64) 42457* ashiftrt: Arithmetic. (line 185) 42458* ashiftrt and attributes: Expressions. (line 64) 42459* ashlM3 instruction pattern: Standard Names. (line 431) 42460* ashrM3 instruction pattern: Standard Names. (line 441) 42461* ASM_APP_OFF: File Framework. (line 78) 42462* ASM_APP_ON: File Framework. (line 71) 42463* ASM_COMMENT_START: File Framework. (line 66) 42464* ASM_DECLARE_CLASS_REFERENCE: Label Output. (line 437) 42465* ASM_DECLARE_CONSTANT_NAME: Label Output. (line 128) 42466* ASM_DECLARE_FUNCTION_NAME: Label Output. (line 87) 42467* ASM_DECLARE_FUNCTION_SIZE: Label Output. (line 101) 42468* ASM_DECLARE_OBJECT_NAME: Label Output. (line 114) 42469* ASM_DECLARE_REGISTER_GLOBAL: Label Output. (line 143) 42470* ASM_DECLARE_UNRESOLVED_REFERENCE: Label Output. (line 443) 42471* ASM_FINAL_SPEC: Driver. (line 144) 42472* ASM_FINISH_DECLARE_OBJECT: Label Output. (line 151) 42473* ASM_FORMAT_PRIVATE_NAME: Label Output. (line 355) 42474* asm_fprintf: Instruction Output. (line 136) 42475* ASM_FPRINTF_EXTENSIONS: Instruction Output. (line 147) 42476* ASM_GENERATE_INTERNAL_LABEL: Label Output. (line 339) 42477* asm_input: Side Effects. (line 284) 42478* asm_input and /v: Flags. (line 94) 42479* ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX: Exception Handling. (line 82) 42480* ASM_NO_SKIP_IN_TEXT: Alignment Output. (line 72) 42481* asm_noperands: Insns. (line 307) 42482* asm_operands and /v: Flags. (line 94) 42483* asm_operands, RTL sharing: Sharing. (line 45) 42484* asm_operands, usage: Assembler. (line 6) 42485* ASM_OUTPUT_ADDR_DIFF_ELT: Dispatch Tables. (line 9) 42486* ASM_OUTPUT_ADDR_VEC_ELT: Dispatch Tables. (line 26) 42487* ASM_OUTPUT_ALIGN: Alignment Output. (line 79) 42488* ASM_OUTPUT_ALIGN_WITH_NOP: Alignment Output. (line 84) 42489* ASM_OUTPUT_ALIGNED_BSS: Uninitialized Data. (line 71) 42490* ASM_OUTPUT_ALIGNED_COMMON: Uninitialized Data. (line 30) 42491* ASM_OUTPUT_ALIGNED_DECL_COMMON: Uninitialized Data. (line 38) 42492* ASM_OUTPUT_ALIGNED_DECL_LOCAL: Uninitialized Data. (line 102) 42493* ASM_OUTPUT_ALIGNED_LOCAL: Uninitialized Data. (line 94) 42494* ASM_OUTPUT_ASCII: Data Output. (line 50) 42495* ASM_OUTPUT_BSS: Uninitialized Data. (line 46) 42496* ASM_OUTPUT_CASE_END: Dispatch Tables. (line 51) 42497* ASM_OUTPUT_CASE_LABEL: Dispatch Tables. (line 38) 42498* ASM_OUTPUT_COMMON: Uninitialized Data. (line 10) 42499* ASM_OUTPUT_DEBUG_LABEL: Label Output. (line 327) 42500* ASM_OUTPUT_DEF: Label Output. (line 376) 42501* ASM_OUTPUT_DEF_FROM_DECLS: Label Output. (line 384) 42502* ASM_OUTPUT_DWARF_DELTA: SDB and DWARF. (line 42) 42503* ASM_OUTPUT_DWARF_OFFSET: SDB and DWARF. (line 46) 42504* ASM_OUTPUT_DWARF_PCREL: SDB and DWARF. (line 52) 42505* ASM_OUTPUT_DWARF_TABLE_REF: SDB and DWARF. (line 57) 42506* ASM_OUTPUT_EXTERNAL: Label Output. (line 264) 42507* ASM_OUTPUT_FDESC: Data Output. (line 59) 42508* ASM_OUTPUT_IDENT: File Framework. (line 100) 42509* ASM_OUTPUT_INTERNAL_LABEL: Label Output. (line 17) 42510* ASM_OUTPUT_LABEL: Label Output. (line 9) 42511* ASM_OUTPUT_LABEL_REF: Label Output. (line 300) 42512* ASM_OUTPUT_LABELREF: Label Output. (line 286) 42513* ASM_OUTPUT_LOCAL: Uninitialized Data. (line 81) 42514* ASM_OUTPUT_MAX_SKIP_ALIGN: Alignment Output. (line 88) 42515* ASM_OUTPUT_MEASURED_SIZE: Label Output. (line 41) 42516* ASM_OUTPUT_OPCODE: Instruction Output. (line 21) 42517* ASM_OUTPUT_POOL_EPILOGUE: Data Output. (line 109) 42518* ASM_OUTPUT_POOL_PROLOGUE: Data Output. (line 72) 42519* ASM_OUTPUT_REG_POP: Instruction Output. (line 191) 42520* ASM_OUTPUT_REG_PUSH: Instruction Output. (line 186) 42521* ASM_OUTPUT_SIZE_DIRECTIVE: Label Output. (line 35) 42522* ASM_OUTPUT_SKIP: Alignment Output. (line 66) 42523* ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 85) 42524* ASM_OUTPUT_SPECIAL_POOL_ENTRY: Data Output. (line 84) 42525* ASM_OUTPUT_SYMBOL_REF: Label Output. (line 293) 42526* ASM_OUTPUT_TYPE_DIRECTIVE: Label Output. (line 77) 42527* ASM_OUTPUT_WEAK_ALIAS: Label Output. (line 402) 42528* ASM_OUTPUT_WEAKREF: Label Output. (line 203) 42529* ASM_PREFERRED_EH_DATA_FORMAT: Exception Handling. (line 67) 42530* ASM_SPEC: Driver. (line 136) 42531* ASM_STABD_OP: DBX Options. (line 36) 42532* ASM_STABN_OP: DBX Options. (line 43) 42533* ASM_STABS_OP: DBX Options. (line 29) 42534* ASM_WEAKEN_DECL: Label Output. (line 195) 42535* ASM_WEAKEN_LABEL: Label Output. (line 182) 42536* assemble_name: Label Output. (line 8) 42537* assemble_name_raw: Label Output. (line 16) 42538* assembler format: File Framework. (line 6) 42539* assembler instructions in RTL: Assembler. (line 6) 42540* ASSEMBLER_DIALECT: Instruction Output. (line 159) 42541* assigning attribute values to insns: Tagging Insns. (line 6) 42542* asterisk in template: Output Statement. (line 29) 42543* atan2M3 instruction pattern: Standard Names. (line 522) 42544* attr <1>: Tagging Insns. (line 54) 42545* attr: Expressions. (line 154) 42546* attr_flag: Expressions. (line 119) 42547* attribute expressions: Expressions. (line 6) 42548* attribute specifications: Attr Example. (line 6) 42549* attribute specifications example: Attr Example. (line 6) 42550* ATTRIBUTE_ALIGNED_VALUE: Storage Layout. (line 184) 42551* attributes: Attributes. (line 6) 42552* attributes, defining: Defining Attributes. 42553 (line 6) 42554* attributes, target-specific: Target Attributes. (line 6) 42555* autoincrement addressing, availability: Portability. (line 21) 42556* autoincrement/decrement addressing: Simple Constraints. (line 30) 42557* automata_option: Processor pipeline description. 42558 (line 301) 42559* automaton based pipeline description: Processor pipeline description. 42560 (line 6) 42561* automaton based scheduler: Processor pipeline description. 42562 (line 6) 42563* AVOID_CCMODE_COPIES: Values in Registers. 42564 (line 153) 42565* backslash: Output Template. (line 46) 42566* barrier: Insns. (line 160) 42567* barrier and /f: Flags. (line 125) 42568* barrier and /v: Flags. (line 44) 42569* BASE_REG_CLASS: Register Classes. (line 107) 42570* basic block: Basic Blocks. (line 6) 42571* Basic Statements: Basic Statements. (line 6) 42572* basic-block.h: Control Flow. (line 6) 42573* BASIC_BLOCK: Basic Blocks. (line 19) 42574* basic_block: Basic Blocks. (line 6) 42575* BB_HEAD, BB_END: Maintaining the CFG. 42576 (line 88) 42577* bb_seq: GIMPLE sequences. (line 73) 42578* BIGGEST_ALIGNMENT: Storage Layout. (line 174) 42579* BIGGEST_FIELD_ALIGNMENT: Storage Layout. (line 195) 42580* BImode: Machine Modes. (line 22) 42581* BIND_EXPR: Unary and Binary Expressions. 42582 (line 6) 42583* BINFO_TYPE: Classes. (line 6) 42584* bit-fields: Bit-Fields. (line 6) 42585* BIT_AND_EXPR: Unary and Binary Expressions. 42586 (line 6) 42587* BIT_IOR_EXPR: Unary and Binary Expressions. 42588 (line 6) 42589* BIT_NOT_EXPR: Unary and Binary Expressions. 42590 (line 6) 42591* BIT_XOR_EXPR: Unary and Binary Expressions. 42592 (line 6) 42593* BITFIELD_NBYTES_LIMITED: Storage Layout. (line 383) 42594* BITS_BIG_ENDIAN: Storage Layout. (line 12) 42595* BITS_BIG_ENDIAN, effect on sign_extract: Bit-Fields. (line 8) 42596* BITS_PER_UNIT: Storage Layout. (line 52) 42597* BITS_PER_WORD: Storage Layout. (line 57) 42598* bitwise complement: Arithmetic. (line 149) 42599* bitwise exclusive-or: Arithmetic. (line 163) 42600* bitwise inclusive-or: Arithmetic. (line 158) 42601* bitwise logical-and: Arithmetic. (line 153) 42602* BLKmode: Machine Modes. (line 183) 42603* BLKmode, and function return values: Calls. (line 23) 42604* block statement iterators <1>: Maintaining the CFG. 42605 (line 45) 42606* block statement iterators: Basic Blocks. (line 68) 42607* BLOCK_FOR_INSN, bb_for_stmt: Maintaining the CFG. 42608 (line 40) 42609* BLOCK_REG_PADDING: Register Arguments. (line 228) 42610* blockage instruction pattern: Standard Names. (line 1380) 42611* Blocks: Blocks. (line 6) 42612* bool: Misc. (line 876) 42613* BOOL_TYPE_SIZE: Type Layout. (line 44) 42614* BOOLEAN_TYPE: Types. (line 6) 42615* branch prediction: Profile information. 42616 (line 24) 42617* BRANCH_COST: Costs. (line 52) 42618* break_out_memory_refs: Addressing Modes. (line 131) 42619* BREAK_STMT: Statements for C++. (line 6) 42620* bsi_commit_edge_inserts: Maintaining the CFG. 42621 (line 118) 42622* bsi_end_p: Maintaining the CFG. 42623 (line 60) 42624* bsi_insert_after: Maintaining the CFG. 42625 (line 72) 42626* bsi_insert_before: Maintaining the CFG. 42627 (line 78) 42628* bsi_insert_on_edge: Maintaining the CFG. 42629 (line 118) 42630* bsi_last: Maintaining the CFG. 42631 (line 56) 42632* bsi_next: Maintaining the CFG. 42633 (line 64) 42634* bsi_prev: Maintaining the CFG. 42635 (line 68) 42636* bsi_remove: Maintaining the CFG. 42637 (line 84) 42638* bsi_start: Maintaining the CFG. 42639 (line 52) 42640* BSS_SECTION_ASM_OP: Sections. (line 68) 42641* bswap: Arithmetic. (line 236) 42642* btruncM2 instruction pattern: Standard Names. (line 540) 42643* build0: Macros and Functions. 42644 (line 16) 42645* build1: Macros and Functions. 42646 (line 17) 42647* build2: Macros and Functions. 42648 (line 18) 42649* build3: Macros and Functions. 42650 (line 19) 42651* build4: Macros and Functions. 42652 (line 20) 42653* build5: Macros and Functions. 42654 (line 21) 42655* build6: Macros and Functions. 42656 (line 22) 42657* builtin_longjmp instruction pattern: Standard Names. (line 1283) 42658* builtin_setjmp_receiver instruction pattern: Standard Names. 42659 (line 1273) 42660* builtin_setjmp_setup instruction pattern: Standard Names. (line 1262) 42661* byte_mode: Machine Modes. (line 336) 42662* BYTES_BIG_ENDIAN: Storage Layout. (line 24) 42663* BYTES_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 221) 42664* C statements for assembler output: Output Statement. (line 6) 42665* C99 math functions, implicit usage: Library Calls. (line 76) 42666* C_COMMON_OVERRIDE_OPTIONS: Run-time Target. (line 128) 42667* c_register_pragma: Misc. (line 404) 42668* c_register_pragma_with_expansion: Misc. (line 406) 42669* call <1>: Side Effects. (line 86) 42670* call: Flags. (line 239) 42671* call instruction pattern: Standard Names. (line 937) 42672* call usage: Calls. (line 10) 42673* call, in call_insn: Flags. (line 33) 42674* call, in mem: Flags. (line 99) 42675* call-clobbered register: Register Basics. (line 35) 42676* call-saved register: Register Basics. (line 35) 42677* call-used register: Register Basics. (line 35) 42678* CALL_EXPR: Unary and Binary Expressions. 42679 (line 6) 42680* call_insn: Insns. (line 95) 42681* call_insn and /c: Flags. (line 33) 42682* call_insn and /f: Flags. (line 125) 42683* call_insn and /i: Flags. (line 24) 42684* call_insn and /j: Flags. (line 179) 42685* call_insn and /s: Flags. (line 49) 42686* call_insn and /u: Flags. (line 19) 42687* call_insn and /u or /i: Flags. (line 29) 42688* call_insn and /v: Flags. (line 44) 42689* CALL_INSN_FUNCTION_USAGE: Insns. (line 101) 42690* call_pop instruction pattern: Standard Names. (line 965) 42691* CALL_POPS_ARGS: Stack Arguments. (line 130) 42692* CALL_REALLY_USED_REGISTERS: Register Basics. (line 46) 42693* CALL_USED_REGISTERS: Register Basics. (line 35) 42694* call_used_regs: Register Basics. (line 59) 42695* call_value instruction pattern: Standard Names. (line 957) 42696* call_value_pop instruction pattern: Standard Names. (line 965) 42697* CALLER_SAVE_PROFITABLE: Caller Saves. (line 11) 42698* calling conventions: Stack and Calling. (line 6) 42699* calling functions in RTL: Calls. (line 6) 42700* can_create_pseudo_p: Standard Names. (line 75) 42701* CAN_DEBUG_WITHOUT_FP: Run-time Target. (line 160) 42702* can_fallthru: Basic Blocks. (line 57) 42703* canadian: Configure Terms. (line 6) 42704* CANNOT_CHANGE_MODE_CLASS: Register Classes. (line 496) 42705* CANNOT_CHANGE_MODE_CLASS and subreg semantics: Regs and Memory. 42706 (line 280) 42707* canonicalization of instructions: Insn Canonicalizations. 42708 (line 6) 42709* CANONICALIZE_COMPARISON: MODE_CC Condition Codes. 42710 (line 55) 42711* canonicalize_funcptr_for_compare instruction pattern: Standard Names. 42712 (line 1121) 42713* CASE_USE_BIT_TESTS: Misc. (line 54) 42714* CASE_VECTOR_MODE: Misc. (line 27) 42715* CASE_VECTOR_PC_RELATIVE: Misc. (line 40) 42716* CASE_VECTOR_SHORTEN_MODE: Misc. (line 31) 42717* casesi instruction pattern: Standard Names. (line 1045) 42718* cbranchMODE4 instruction pattern: Standard Names. (line 926) 42719* cc0 <1>: CC0 Condition Codes. 42720 (line 6) 42721* cc0: Regs and Memory. (line 307) 42722* cc0, RTL sharing: Sharing. (line 27) 42723* cc0_rtx: Regs and Memory. (line 333) 42724* CC1_SPEC: Driver. (line 118) 42725* CC1PLUS_SPEC: Driver. (line 126) 42726* cc_status: CC0 Condition Codes. 42727 (line 6) 42728* CC_STATUS_MDEP: CC0 Condition Codes. 42729 (line 17) 42730* CC_STATUS_MDEP_INIT: CC0 Condition Codes. 42731 (line 23) 42732* CCmode <1>: MODE_CC Condition Codes. 42733 (line 6) 42734* CCmode: Machine Modes. (line 176) 42735* CDImode: Machine Modes. (line 202) 42736* CEIL_DIV_EXPR: Unary and Binary Expressions. 42737 (line 6) 42738* CEIL_MOD_EXPR: Unary and Binary Expressions. 42739 (line 6) 42740* ceilM2 instruction pattern: Standard Names. (line 556) 42741* CFA_FRAME_BASE_OFFSET: Frame Layout. (line 226) 42742* CFG, Control Flow Graph: Control Flow. (line 6) 42743* cfghooks.h: Maintaining the CFG. 42744 (line 6) 42745* cgraph_finalize_function: Parsing pass. (line 52) 42746* chain_circular: GTY Options. (line 195) 42747* chain_next: GTY Options. (line 195) 42748* chain_prev: GTY Options. (line 195) 42749* change_address: Standard Names. (line 47) 42750* char: GIMPLE_ASM. (line 53) 42751* CHAR_TYPE_SIZE: Type Layout. (line 39) 42752* check_stack instruction pattern: Standard Names. (line 1208) 42753* CHImode: Machine Modes. (line 202) 42754* class definitions, register: Register Classes. (line 6) 42755* class preference constraints: Class Preferences. (line 6) 42756* class, scope: Classes. (line 6) 42757* CLASS_LIKELY_SPILLED_P: Register Classes. (line 467) 42758* CLASS_MAX_NREGS: Register Classes. (line 484) 42759* CLASS_TYPE_P: Types for C++. (line 65) 42760* classes of RTX codes: RTL Classes. (line 6) 42761* CLASSTYPE_DECLARED_CLASS: Classes. (line 6) 42762* CLASSTYPE_HAS_MUTABLE: Classes. (line 85) 42763* CLASSTYPE_NON_POD_P: Classes. (line 90) 42764* CLEANUP_DECL: Statements for C++. (line 6) 42765* CLEANUP_EXPR: Statements for C++. (line 6) 42766* CLEANUP_POINT_EXPR: Unary and Binary Expressions. 42767 (line 6) 42768* CLEANUP_STMT: Statements for C++. (line 6) 42769* Cleanups: Cleanups. (line 6) 42770* CLEAR_BY_PIECES_P: Costs. (line 136) 42771* clear_cache instruction pattern: Standard Names. (line 1524) 42772* CLEAR_INSN_CACHE: Trampolines. (line 99) 42773* CLEAR_RATIO: Costs. (line 124) 42774* clobber: Side Effects. (line 100) 42775* clz: Arithmetic. (line 212) 42776* CLZ_DEFINED_VALUE_AT_ZERO: Misc. (line 319) 42777* clzM2 instruction pattern: Standard Names. (line 621) 42778* cmpmemM instruction pattern: Standard Names. (line 754) 42779* cmpstrM instruction pattern: Standard Names. (line 733) 42780* cmpstrnM instruction pattern: Standard Names. (line 720) 42781* code generation RTL sequences: Expander Definitions. 42782 (line 6) 42783* code iterators in .md files: Code Iterators. (line 6) 42784* code_label: Insns. (line 119) 42785* code_label and /i: Flags. (line 59) 42786* code_label and /v: Flags. (line 44) 42787* CODE_LABEL_NUMBER: Insns. (line 119) 42788* codes, RTL expression: RTL Objects. (line 47) 42789* COImode: Machine Modes. (line 202) 42790* COLLECT2_HOST_INITIALIZATION: Host Misc. (line 32) 42791* COLLECT_EXPORT_LIST: Misc. (line 783) 42792* COLLECT_SHARED_FINI_FUNC: Macros for Initialization. 42793 (line 44) 42794* COLLECT_SHARED_INIT_FUNC: Macros for Initialization. 42795 (line 33) 42796* commit_edge_insertions: Maintaining the CFG. 42797 (line 118) 42798* compare: Arithmetic. (line 43) 42799* compare, canonicalization of: Insn Canonicalizations. 42800 (line 37) 42801* comparison_operator: Machine-Independent Predicates. 42802 (line 111) 42803* compiler passes and files: Passes. (line 6) 42804* complement, bitwise: Arithmetic. (line 149) 42805* COMPLEX_CST: Constant expressions. 42806 (line 6) 42807* COMPLEX_EXPR: Unary and Binary Expressions. 42808 (line 6) 42809* COMPLEX_TYPE: Types. (line 6) 42810* COMPONENT_REF: Storage References. (line 6) 42811* Compound Expressions: Compound Expressions. 42812 (line 6) 42813* Compound Lvalues: Compound Lvalues. (line 6) 42814* COMPOUND_EXPR: Unary and Binary Expressions. 42815 (line 6) 42816* COMPOUND_LITERAL_EXPR: Unary and Binary Expressions. 42817 (line 6) 42818* COMPOUND_LITERAL_EXPR_DECL: Unary and Binary Expressions. 42819 (line 367) 42820* COMPOUND_LITERAL_EXPR_DECL_EXPR: Unary and Binary Expressions. 42821 (line 367) 42822* computed jump: Edges. (line 128) 42823* computing the length of an insn: Insn Lengths. (line 6) 42824* concat: Regs and Memory. (line 385) 42825* concatn: Regs and Memory. (line 391) 42826* cond: Comparisons. (line 90) 42827* cond and attributes: Expressions. (line 37) 42828* cond_exec: Side Effects. (line 248) 42829* COND_EXPR: Unary and Binary Expressions. 42830 (line 6) 42831* condition code register: Regs and Memory. (line 307) 42832* condition code status: Condition Code. (line 6) 42833* condition codes: Comparisons. (line 20) 42834* conditional execution <1>: Cond. Exec. Macros. (line 6) 42835* conditional execution: Conditional Execution. 42836 (line 6) 42837* Conditional Expressions: Conditional Expressions. 42838 (line 6) 42839* CONDITIONAL_REGISTER_USAGE: Register Basics. (line 60) 42840* conditions, in patterns: Patterns. (line 43) 42841* configuration file <1>: Host Misc. (line 6) 42842* configuration file: Filesystem. (line 6) 42843* configure terms: Configure Terms. (line 6) 42844* CONJ_EXPR: Unary and Binary Expressions. 42845 (line 6) 42846* const: Constants. (line 99) 42847* CONST0_RTX: Constants. (line 119) 42848* const0_rtx: Constants. (line 16) 42849* CONST1_RTX: Constants. (line 119) 42850* const1_rtx: Constants. (line 16) 42851* CONST2_RTX: Constants. (line 119) 42852* const2_rtx: Constants. (line 16) 42853* CONST_DECL: Declarations. (line 6) 42854* const_double: Constants. (line 32) 42855* const_double, RTL sharing: Sharing. (line 29) 42856* CONST_DOUBLE_LOW: Constants. (line 39) 42857* CONST_DOUBLE_OK_FOR_CONSTRAINT_P: Old Constraints. (line 69) 42858* CONST_DOUBLE_OK_FOR_LETTER_P: Old Constraints. (line 54) 42859* const_double_operand: Machine-Independent Predicates. 42860 (line 21) 42861* const_fixed: Constants. (line 52) 42862* const_int: Constants. (line 8) 42863* const_int and attribute tests: Expressions. (line 47) 42864* const_int and attributes: Expressions. (line 10) 42865* const_int, RTL sharing: Sharing. (line 23) 42866* const_int_operand: Machine-Independent Predicates. 42867 (line 16) 42868* CONST_OK_FOR_CONSTRAINT_P: Old Constraints. (line 49) 42869* CONST_OK_FOR_LETTER_P: Old Constraints. (line 40) 42870* const_string: Constants. (line 71) 42871* const_string and attributes: Expressions. (line 20) 42872* const_true_rtx: Constants. (line 26) 42873* const_vector: Constants. (line 59) 42874* const_vector, RTL sharing: Sharing. (line 32) 42875* constant attributes: Constant Attributes. 42876 (line 6) 42877* constant definitions: Constant Definitions. 42878 (line 6) 42879* CONSTANT_ADDRESS_P: Addressing Modes. (line 29) 42880* CONSTANT_ALIGNMENT: Storage Layout. (line 242) 42881* CONSTANT_P: Addressing Modes. (line 36) 42882* CONSTANT_POOL_ADDRESS_P: Flags. (line 10) 42883* CONSTANT_POOL_BEFORE_FUNCTION: Data Output. (line 64) 42884* constants in constraints: Simple Constraints. (line 60) 42885* constm1_rtx: Constants. (line 16) 42886* constraint modifier characters: Modifiers. (line 6) 42887* constraint, matching: Simple Constraints. (line 132) 42888* CONSTRAINT_LEN: Old Constraints. (line 12) 42889* constraint_num: C Constraint Interface. 42890 (line 38) 42891* constraint_satisfied_p: C Constraint Interface. 42892 (line 54) 42893* constraints: Constraints. (line 6) 42894* constraints, defining: Define Constraints. (line 6) 42895* constraints, defining, obsolete method: Old Constraints. (line 6) 42896* constraints, machine specific: Machine Constraints. 42897 (line 6) 42898* constraints, testing: C Constraint Interface. 42899 (line 6) 42900* CONSTRUCTOR: Unary and Binary Expressions. 42901 (line 6) 42902* constructors, automatic calls: Collect2. (line 15) 42903* constructors, output of: Initialization. (line 6) 42904* container: Containers. (line 6) 42905* CONTINUE_STMT: Statements for C++. (line 6) 42906* contributors: Contributors. (line 6) 42907* controlling register usage: Register Basics. (line 76) 42908* controlling the compilation driver: Driver. (line 6) 42909* conventions, run-time: Interface. (line 6) 42910* conversions: Conversions. (line 6) 42911* CONVERT_EXPR: Unary and Binary Expressions. 42912 (line 6) 42913* copy_rtx: Addressing Modes. (line 184) 42914* copy_rtx_if_shared: Sharing. (line 64) 42915* copysignM3 instruction pattern: Standard Names. (line 602) 42916* cosM2 instruction pattern: Standard Names. (line 481) 42917* costs of instructions: Costs. (line 6) 42918* CP_INTEGRAL_TYPE: Types for C++. (line 57) 42919* cp_namespace_decls: Namespaces. (line 49) 42920* CP_TYPE_CONST_NON_VOLATILE_P: Types for C++. (line 33) 42921* CP_TYPE_CONST_P: Types for C++. (line 24) 42922* CP_TYPE_QUALS: Types for C++. (line 6) 42923* CP_TYPE_RESTRICT_P: Types for C++. (line 30) 42924* CP_TYPE_VOLATILE_P: Types for C++. (line 27) 42925* CPLUSPLUS_CPP_SPEC: Driver. (line 113) 42926* CPP_SPEC: Driver. (line 106) 42927* CQImode: Machine Modes. (line 202) 42928* cross compilation and floating point: Floating Point. (line 6) 42929* CRT_CALL_STATIC_FUNCTION: Sections. (line 122) 42930* CRTSTUFF_T_CFLAGS: Target Fragment. (line 35) 42931* CRTSTUFF_T_CFLAGS_S: Target Fragment. (line 39) 42932* CSImode: Machine Modes. (line 202) 42933* cstoreMODE4 instruction pattern: Standard Names. (line 897) 42934* CTImode: Machine Modes. (line 202) 42935* ctrapMM4 instruction pattern: Standard Names. (line 1349) 42936* ctz: Arithmetic. (line 220) 42937* CTZ_DEFINED_VALUE_AT_ZERO: Misc. (line 320) 42938* ctzM2 instruction pattern: Standard Names. (line 630) 42939* CUMULATIVE_ARGS: Register Arguments. (line 127) 42940* current_function_epilogue_delay_list: Function Entry. (line 181) 42941* current_function_is_leaf: Leaf Functions. (line 51) 42942* current_function_outgoing_args_size: Stack Arguments. (line 45) 42943* current_function_pops_args: Function Entry. (line 106) 42944* current_function_pretend_args_size: Function Entry. (line 112) 42945* current_function_uses_only_leaf_regs: Leaf Functions. (line 51) 42946* current_insn_predicate: Conditional Execution. 42947 (line 26) 42948* DAmode: Machine Modes. (line 152) 42949* data bypass: Processor pipeline description. 42950 (line 106) 42951* data dependence delays: Processor pipeline description. 42952 (line 6) 42953* Data Dependency Analysis: Dependency analysis. 42954 (line 6) 42955* data structures: Per-Function Data. (line 6) 42956* DATA_ALIGNMENT: Storage Layout. (line 229) 42957* DATA_SECTION_ASM_OP: Sections. (line 53) 42958* DBR_OUTPUT_SEQEND: Instruction Output. (line 120) 42959* dbr_sequence_length: Instruction Output. (line 119) 42960* DBX_BLOCKS_FUNCTION_RELATIVE: DBX Options. (line 103) 42961* DBX_CONTIN_CHAR: DBX Options. (line 66) 42962* DBX_CONTIN_LENGTH: DBX Options. (line 56) 42963* DBX_DEBUGGING_INFO: DBX Options. (line 9) 42964* DBX_FUNCTION_FIRST: DBX Options. (line 97) 42965* DBX_LINES_FUNCTION_RELATIVE: DBX Options. (line 109) 42966* DBX_NO_XREFS: DBX Options. (line 50) 42967* DBX_OUTPUT_LBRAC: DBX Hooks. (line 9) 42968* DBX_OUTPUT_MAIN_SOURCE_FILE_END: File Names and DBX. (line 34) 42969* DBX_OUTPUT_MAIN_SOURCE_FILENAME: File Names and DBX. (line 9) 42970* DBX_OUTPUT_NFUN: DBX Hooks. (line 18) 42971* DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END: File Names and DBX. 42972 (line 42) 42973* DBX_OUTPUT_RBRAC: DBX Hooks. (line 15) 42974* DBX_OUTPUT_SOURCE_LINE: DBX Hooks. (line 22) 42975* DBX_REGISTER_NUMBER: All Debuggers. (line 9) 42976* DBX_REGPARM_STABS_CODE: DBX Options. (line 87) 42977* DBX_REGPARM_STABS_LETTER: DBX Options. (line 92) 42978* DBX_STATIC_CONST_VAR_CODE: DBX Options. (line 82) 42979* DBX_STATIC_STAB_DATA_SECTION: DBX Options. (line 73) 42980* DBX_TYPE_DECL_STABS_CODE: DBX Options. (line 78) 42981* DBX_USE_BINCL: DBX Options. (line 115) 42982* DCmode: Machine Modes. (line 197) 42983* DDmode: Machine Modes. (line 90) 42984* De Morgan's law: Insn Canonicalizations. 42985 (line 52) 42986* dead_or_set_p: define_peephole. (line 65) 42987* debug_expr: Debug Information. (line 22) 42988* DEBUG_EXPR_DECL: Declarations. (line 6) 42989* debug_insn: Insns. (line 239) 42990* DEBUG_SYMS_TEXT: DBX Options. (line 25) 42991* DEBUGGER_ARG_OFFSET: All Debuggers. (line 37) 42992* DEBUGGER_AUTO_OFFSET: All Debuggers. (line 28) 42993* decimal float library: Decimal float library routines. 42994 (line 6) 42995* DECL_ALIGN: Declarations. (line 6) 42996* DECL_ANTICIPATED: Functions for C++. (line 42) 42997* DECL_ARGUMENTS: Function Basics. (line 36) 42998* DECL_ARRAY_DELETE_OPERATOR_P: Functions for C++. (line 158) 42999* DECL_ARTIFICIAL <1>: Function Properties. 43000 (line 47) 43001* DECL_ARTIFICIAL <2>: Function Basics. (line 6) 43002* DECL_ARTIFICIAL: Working with declarations. 43003 (line 24) 43004* DECL_ASSEMBLER_NAME: Function Basics. (line 6) 43005* DECL_ATTRIBUTES: Attributes. (line 22) 43006* DECL_BASE_CONSTRUCTOR_P: Functions for C++. (line 88) 43007* DECL_COMPLETE_CONSTRUCTOR_P: Functions for C++. (line 84) 43008* DECL_COMPLETE_DESTRUCTOR_P: Functions for C++. (line 98) 43009* DECL_CONST_MEMFUNC_P: Functions for C++. (line 71) 43010* DECL_CONSTRUCTOR_P: Functions for C++. (line 77) 43011* DECL_CONTEXT: Namespaces. (line 31) 43012* DECL_CONV_FN_P: Functions for C++. (line 105) 43013* DECL_COPY_CONSTRUCTOR_P: Functions for C++. (line 92) 43014* DECL_DESTRUCTOR_P: Functions for C++. (line 95) 43015* DECL_EXTERN_C_FUNCTION_P: Functions for C++. (line 46) 43016* DECL_EXTERNAL <1>: Function Properties. 43017 (line 25) 43018* DECL_EXTERNAL: Declarations. (line 6) 43019* DECL_FUNCTION_MEMBER_P: Functions for C++. (line 61) 43020* DECL_FUNCTION_SPECIFIC_OPTIMIZATION <1>: Function Properties. 43021 (line 61) 43022* DECL_FUNCTION_SPECIFIC_OPTIMIZATION: Function Basics. (line 6) 43023* DECL_FUNCTION_SPECIFIC_TARGET <1>: Function Properties. 43024 (line 55) 43025* DECL_FUNCTION_SPECIFIC_TARGET: Function Basics. (line 6) 43026* DECL_GLOBAL_CTOR_P: Functions for C++. (line 108) 43027* DECL_GLOBAL_DTOR_P: Functions for C++. (line 112) 43028* DECL_INITIAL <1>: Function Basics. (line 51) 43029* DECL_INITIAL: Declarations. (line 6) 43030* DECL_LINKONCE_P: Functions for C++. (line 50) 43031* DECL_LOCAL_FUNCTION_P: Functions for C++. (line 38) 43032* DECL_MAIN_P: Functions for C++. (line 34) 43033* DECL_NAME <1>: Namespaces. (line 20) 43034* DECL_NAME <2>: Function Basics. (line 6) 43035* DECL_NAME: Working with declarations. 43036 (line 7) 43037* DECL_NAMESPACE_ALIAS: Namespaces. (line 35) 43038* DECL_NAMESPACE_STD_P: Namespaces. (line 45) 43039* DECL_NON_THUNK_FUNCTION_P: Functions for C++. (line 138) 43040* DECL_NONCONVERTING_P: Functions for C++. (line 80) 43041* DECL_NONSTATIC_MEMBER_FUNCTION_P: Functions for C++. (line 68) 43042* DECL_OVERLOADED_OPERATOR_P: Functions for C++. (line 102) 43043* DECL_PURE_P: Function Properties. 43044 (line 40) 43045* DECL_RESULT: Function Basics. (line 41) 43046* DECL_SAVED_TREE: Function Basics. (line 44) 43047* DECL_SIZE: Declarations. (line 6) 43048* DECL_STATIC_FUNCTION_P: Functions for C++. (line 65) 43049* DECL_STMT: Statements for C++. (line 6) 43050* DECL_STMT_DECL: Statements for C++. (line 6) 43051* DECL_THUNK_P: Functions for C++. (line 116) 43052* DECL_VIRTUAL_P: Function Properties. 43053 (line 44) 43054* DECL_VOLATILE_MEMFUNC_P: Functions for C++. (line 74) 43055* declaration: Declarations. (line 6) 43056* declarations, RTL: RTL Declarations. (line 6) 43057* DECLARE_LIBRARY_RENAMES: Library Calls. (line 9) 43058* decrement_and_branch_until_zero instruction pattern: Standard Names. 43059 (line 1083) 43060* def_optype_d: Manipulating GIMPLE statements. 43061 (line 94) 43062* default: GTY Options. (line 81) 43063* default_file_start: File Framework. (line 8) 43064* DEFAULT_GDB_EXTENSIONS: DBX Options. (line 18) 43065* DEFAULT_PCC_STRUCT_RETURN: Aggregate Return. (line 35) 43066* DEFAULT_SIGNED_CHAR: Type Layout. (line 154) 43067* define_address_constraint: Define Constraints. (line 107) 43068* define_asm_attributes: Tagging Insns. (line 73) 43069* define_attr: Defining Attributes. 43070 (line 6) 43071* define_automaton: Processor pipeline description. 43072 (line 53) 43073* define_bypass: Processor pipeline description. 43074 (line 197) 43075* define_code_attr: Code Iterators. (line 6) 43076* define_code_iterator: Code Iterators. (line 6) 43077* define_cond_exec: Conditional Execution. 43078 (line 13) 43079* define_constants: Constant Definitions. 43080 (line 6) 43081* define_constraint: Define Constraints. (line 48) 43082* define_cpu_unit: Processor pipeline description. 43083 (line 68) 43084* define_delay: Delay Slots. (line 25) 43085* define_expand: Expander Definitions. 43086 (line 11) 43087* define_insn: Patterns. (line 6) 43088* define_insn example: Example. (line 6) 43089* define_insn_and_split: Insn Splitting. (line 170) 43090* define_insn_reservation: Processor pipeline description. 43091 (line 106) 43092* define_memory_constraint: Define Constraints. (line 88) 43093* define_mode_attr: Substitutions. (line 6) 43094* define_mode_iterator: Defining Mode Iterators. 43095 (line 6) 43096* define_peephole: define_peephole. (line 6) 43097* define_peephole2: define_peephole2. (line 6) 43098* define_predicate: Defining Predicates. 43099 (line 6) 43100* define_query_cpu_unit: Processor pipeline description. 43101 (line 90) 43102* define_register_constraint: Define Constraints. (line 28) 43103* define_reservation: Processor pipeline description. 43104 (line 186) 43105* define_special_predicate: Defining Predicates. 43106 (line 6) 43107* define_split: Insn Splitting. (line 32) 43108* defining attributes and their values: Defining Attributes. 43109 (line 6) 43110* defining constraints: Define Constraints. (line 6) 43111* defining constraints, obsolete method: Old Constraints. (line 6) 43112* defining jump instruction patterns: Jump Patterns. (line 6) 43113* defining looping instruction patterns: Looping Patterns. (line 6) 43114* defining peephole optimizers: Peephole Definitions. 43115 (line 6) 43116* defining predicates: Defining Predicates. 43117 (line 6) 43118* defining RTL sequences for code generation: Expander Definitions. 43119 (line 6) 43120* delay slots, defining: Delay Slots. (line 6) 43121* DELAY_SLOTS_FOR_EPILOGUE: Function Entry. (line 163) 43122* deletable: GTY Options. (line 149) 43123* DELETE_IF_ORDINARY: Filesystem. (line 79) 43124* Dependent Patterns: Dependent Patterns. (line 6) 43125* desc: GTY Options. (line 81) 43126* destructors, output of: Initialization. (line 6) 43127* deterministic finite state automaton: Processor pipeline description. 43128 (line 6) 43129* DF_SIZE: Type Layout. (line 130) 43130* DFmode: Machine Modes. (line 73) 43131* digits in constraint: Simple Constraints. (line 120) 43132* DImode: Machine Modes. (line 45) 43133* DIR_SEPARATOR: Filesystem. (line 18) 43134* DIR_SEPARATOR_2: Filesystem. (line 19) 43135* directory options .md: Including Patterns. (line 44) 43136* disabling certain registers: Register Basics. (line 76) 43137* dispatch table: Dispatch Tables. (line 8) 43138* div: Arithmetic. (line 111) 43139* div and attributes: Expressions. (line 64) 43140* division: Arithmetic. (line 111) 43141* divM3 instruction pattern: Standard Names. (line 222) 43142* divmodM4 instruction pattern: Standard Names. (line 411) 43143* DO_BODY: Statements for C++. (line 6) 43144* DO_COND: Statements for C++. (line 6) 43145* DO_STMT: Statements for C++. (line 6) 43146* DOLLARS_IN_IDENTIFIERS: Misc. (line 491) 43147* doloop_begin instruction pattern: Standard Names. (line 1114) 43148* doloop_end instruction pattern: Standard Names. (line 1093) 43149* DONE: Expander Definitions. 43150 (line 74) 43151* DONT_USE_BUILTIN_SETJMP: Exception Region Output. 43152 (line 70) 43153* DOUBLE_TYPE_SIZE: Type Layout. (line 53) 43154* DQmode: Machine Modes. (line 115) 43155* driver: Driver. (line 6) 43156* DRIVER_SELF_SPECS: Driver. (line 71) 43157* DUMPFILE_FORMAT: Filesystem. (line 67) 43158* DWARF2_ASM_LINE_DEBUG_INFO: SDB and DWARF. (line 36) 43159* DWARF2_DEBUGGING_INFO: SDB and DWARF. (line 13) 43160* DWARF2_FRAME_INFO: SDB and DWARF. (line 30) 43161* DWARF2_FRAME_REG_OUT: Frame Registers. (line 136) 43162* DWARF2_UNWIND_INFO: Exception Region Output. 43163 (line 40) 43164* DWARF_ALT_FRAME_RETURN_COLUMN: Frame Layout. (line 152) 43165* DWARF_CIE_DATA_ALIGNMENT: Exception Region Output. 43166 (line 75) 43167* DWARF_FRAME_REGISTERS: Frame Registers. (line 96) 43168* DWARF_FRAME_REGNUM: Frame Registers. (line 128) 43169* DWARF_REG_TO_UNWIND_COLUMN: Frame Registers. (line 120) 43170* DWARF_ZERO_REG: Frame Layout. (line 163) 43171* DYNAMIC_CHAIN_ADDRESS: Frame Layout. (line 92) 43172* E in constraint: Simple Constraints. (line 79) 43173* earlyclobber operand: Modifiers. (line 25) 43174* edge: Edges. (line 6) 43175* edge in the flow graph: Edges. (line 6) 43176* edge iterators: Edges. (line 15) 43177* edge splitting: Maintaining the CFG. 43178 (line 118) 43179* EDGE_ABNORMAL: Edges. (line 128) 43180* EDGE_ABNORMAL, EDGE_ABNORMAL_CALL: Edges. (line 171) 43181* EDGE_ABNORMAL, EDGE_EH: Edges. (line 96) 43182* EDGE_ABNORMAL, EDGE_SIBCALL: Edges. (line 122) 43183* EDGE_FALLTHRU, force_nonfallthru: Edges. (line 86) 43184* EDOM, implicit usage: Library Calls. (line 58) 43185* EH_FRAME_IN_DATA_SECTION: Exception Region Output. 43186 (line 20) 43187* EH_FRAME_SECTION_NAME: Exception Region Output. 43188 (line 10) 43189* eh_return instruction pattern: Standard Names. (line 1289) 43190* EH_RETURN_DATA_REGNO: Exception Handling. (line 7) 43191* EH_RETURN_HANDLER_RTX: Exception Handling. (line 39) 43192* EH_RETURN_STACKADJ_RTX: Exception Handling. (line 22) 43193* EH_TABLES_CAN_BE_READ_ONLY: Exception Region Output. 43194 (line 29) 43195* EH_USES: Function Entry. (line 158) 43196* ei_edge: Edges. (line 43) 43197* ei_end_p: Edges. (line 27) 43198* ei_last: Edges. (line 23) 43199* ei_next: Edges. (line 35) 43200* ei_one_before_end_p: Edges. (line 31) 43201* ei_prev: Edges. (line 39) 43202* ei_safe_safe: Edges. (line 47) 43203* ei_start: Edges. (line 19) 43204* ELIGIBLE_FOR_EPILOGUE_DELAY: Function Entry. (line 169) 43205* ELIMINABLE_REGS: Elimination. (line 47) 43206* ELSE_CLAUSE: Statements for C++. (line 6) 43207* Embedded C: Fixed-point fractional library routines. 43208 (line 6) 43209* EMIT_MODE_SET: Mode Switching. (line 74) 43210* Empty Statements: Empty Statements. (line 6) 43211* EMPTY_CLASS_EXPR: Statements for C++. (line 6) 43212* EMPTY_FIELD_BOUNDARY: Storage Layout. (line 296) 43213* Emulated TLS: Emulated TLS. (line 6) 43214* ENABLE_EXECUTE_STACK: Trampolines. (line 109) 43215* enabled: Disable Insn Alternatives. 43216 (line 6) 43217* ENDFILE_SPEC: Driver. (line 218) 43218* endianness: Portability. (line 21) 43219* ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR: Basic Blocks. (line 28) 43220* enum machine_mode: Machine Modes. (line 6) 43221* enum reg_class: Register Classes. (line 65) 43222* ENUMERAL_TYPE: Types. (line 6) 43223* epilogue: Function Entry. (line 6) 43224* epilogue instruction pattern: Standard Names. (line 1321) 43225* EPILOGUE_USES: Function Entry. (line 152) 43226* eq: Comparisons. (line 52) 43227* eq and attributes: Expressions. (line 64) 43228* eq_attr: Expressions. (line 85) 43229* EQ_EXPR: Unary and Binary Expressions. 43230 (line 6) 43231* equal: Comparisons. (line 52) 43232* errno, implicit usage: Library Calls. (line 70) 43233* EXACT_DIV_EXPR: Unary and Binary Expressions. 43234 (line 6) 43235* examining SSA_NAMEs: SSA. (line 218) 43236* exception handling <1>: Exception Handling. (line 6) 43237* exception handling: Edges. (line 96) 43238* exception_receiver instruction pattern: Standard Names. (line 1253) 43239* exclamation point: Multi-Alternative. (line 47) 43240* exclusion_set: Processor pipeline description. 43241 (line 220) 43242* exclusive-or, bitwise: Arithmetic. (line 163) 43243* EXIT_EXPR: Unary and Binary Expressions. 43244 (line 6) 43245* EXIT_IGNORE_STACK: Function Entry. (line 140) 43246* expander definitions: Expander Definitions. 43247 (line 6) 43248* expM2 instruction pattern: Standard Names. (line 497) 43249* EXPR_FILENAME: Working with declarations. 43250 (line 14) 43251* EXPR_LINENO: Working with declarations. 43252 (line 20) 43253* expr_list: Insns. (line 545) 43254* EXPR_STMT: Statements for C++. (line 6) 43255* EXPR_STMT_EXPR: Statements for C++. (line 6) 43256* expression: Expression trees. (line 6) 43257* expression codes: RTL Objects. (line 47) 43258* extendMN2 instruction pattern: Standard Names. (line 812) 43259* extensible constraints: Simple Constraints. (line 163) 43260* EXTRA_ADDRESS_CONSTRAINT: Old Constraints. (line 123) 43261* EXTRA_CONSTRAINT: Old Constraints. (line 74) 43262* EXTRA_CONSTRAINT_STR: Old Constraints. (line 95) 43263* EXTRA_MEMORY_CONSTRAINT: Old Constraints. (line 100) 43264* EXTRA_SPECS: Driver. (line 245) 43265* extv instruction pattern: Standard Names. (line 848) 43266* extzv instruction pattern: Standard Names. (line 863) 43267* F in constraint: Simple Constraints. (line 84) 43268* FAIL: Expander Definitions. 43269 (line 80) 43270* fall-thru: Edges. (line 69) 43271* FATAL_EXIT_CODE: Host Misc. (line 6) 43272* FDL, GNU Free Documentation License: GNU Free Documentation License. 43273 (line 6) 43274* features, optional, in system conventions: Run-time Target. 43275 (line 59) 43276* ffs: Arithmetic. (line 206) 43277* ffsM2 instruction pattern: Standard Names. (line 611) 43278* FIELD_DECL: Declarations. (line 6) 43279* file_end_indicate_exec_stack: File Framework. (line 41) 43280* files and passes of the compiler: Passes. (line 6) 43281* files, generated: Files. (line 6) 43282* final_absence_set: Processor pipeline description. 43283 (line 220) 43284* FINAL_PRESCAN_INSN: Instruction Output. (line 46) 43285* final_presence_set: Processor pipeline description. 43286 (line 220) 43287* final_scan_insn: Function Entry. (line 181) 43288* final_sequence: Instruction Output. (line 130) 43289* FIND_BASE_TERM: Addressing Modes. (line 115) 43290* FINI_ARRAY_SECTION_ASM_OP: Sections. (line 115) 43291* FINI_SECTION_ASM_OP: Sections. (line 100) 43292* finite state automaton minimization: Processor pipeline description. 43293 (line 301) 43294* FIRST_PARM_OFFSET: Frame Layout. (line 67) 43295* FIRST_PARM_OFFSET and virtual registers: Regs and Memory. (line 65) 43296* FIRST_PSEUDO_REGISTER: Register Basics. (line 9) 43297* FIRST_STACK_REG: Stack Registers. (line 27) 43298* FIRST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 43299* fix: Conversions. (line 66) 43300* FIX_TRUNC_EXPR: Unary and Binary Expressions. 43301 (line 6) 43302* fix_truncMN2 instruction pattern: Standard Names. (line 799) 43303* fixed register: Register Basics. (line 15) 43304* fixed-point fractional library: Fixed-point fractional library routines. 43305 (line 6) 43306* FIXED_CONVERT_EXPR: Unary and Binary Expressions. 43307 (line 6) 43308* FIXED_CST: Constant expressions. 43309 (line 6) 43310* FIXED_POINT_TYPE: Types. (line 6) 43311* FIXED_REGISTERS: Register Basics. (line 15) 43312* fixed_regs: Register Basics. (line 59) 43313* fixMN2 instruction pattern: Standard Names. (line 779) 43314* FIXUNS_TRUNC_LIKE_FIX_TRUNC: Misc. (line 100) 43315* fixuns_truncMN2 instruction pattern: Standard Names. (line 803) 43316* fixunsMN2 instruction pattern: Standard Names. (line 788) 43317* flags in RTL expression: Flags. (line 6) 43318* float: Conversions. (line 58) 43319* FLOAT_EXPR: Unary and Binary Expressions. 43320 (line 6) 43321* float_extend: Conversions. (line 33) 43322* FLOAT_LIB_COMPARE_RETURNS_BOOL: Library Calls. (line 25) 43323* FLOAT_STORE_FLAG_VALUE: Misc. (line 301) 43324* float_truncate: Conversions. (line 53) 43325* FLOAT_TYPE_SIZE: Type Layout. (line 49) 43326* FLOAT_WORDS_BIG_ENDIAN: Storage Layout. (line 43) 43327* FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory. 43328 (line 226) 43329* floating point and cross compilation: Floating Point. (line 6) 43330* Floating Point Emulation: Target Fragment. (line 15) 43331* floating point emulation library, US Software GOFAST: Library Calls. 43332 (line 44) 43333* floatMN2 instruction pattern: Standard Names. (line 771) 43334* floatunsMN2 instruction pattern: Standard Names. (line 775) 43335* FLOOR_DIV_EXPR: Unary and Binary Expressions. 43336 (line 6) 43337* FLOOR_MOD_EXPR: Unary and Binary Expressions. 43338 (line 6) 43339* floorM2 instruction pattern: Standard Names. (line 532) 43340* flow-insensitive alias analysis: Alias analysis. (line 6) 43341* flow-sensitive alias analysis: Alias analysis. (line 6) 43342* fmodM3 instruction pattern: Standard Names. (line 463) 43343* FOR_BODY: Statements for C++. (line 6) 43344* FOR_COND: Statements for C++. (line 6) 43345* FOR_EXPR: Statements for C++. (line 6) 43346* FOR_INIT_STMT: Statements for C++. (line 6) 43347* FOR_STMT: Statements for C++. (line 6) 43348* FORCE_CODE_SECTION_ALIGN: Sections. (line 146) 43349* force_reg: Standard Names. (line 36) 43350* fract_convert: Conversions. (line 82) 43351* FRACT_TYPE_SIZE: Type Layout. (line 68) 43352* fractional types: Fixed-point fractional library routines. 43353 (line 6) 43354* fractMN2 instruction pattern: Standard Names. (line 821) 43355* fractunsMN2 instruction pattern: Standard Names. (line 836) 43356* frame layout: Frame Layout. (line 6) 43357* FRAME_ADDR_RTX: Frame Layout. (line 116) 43358* FRAME_GROWS_DOWNWARD: Frame Layout. (line 31) 43359* FRAME_GROWS_DOWNWARD and virtual registers: Regs and Memory. 43360 (line 69) 43361* FRAME_POINTER_CFA_OFFSET: Frame Layout. (line 212) 43362* frame_pointer_needed: Function Entry. (line 34) 43363* FRAME_POINTER_REGNUM: Frame Registers. (line 14) 43364* FRAME_POINTER_REGNUM and virtual registers: Regs and Memory. 43365 (line 74) 43366* frame_pointer_rtx: Frame Registers. (line 90) 43367* frame_related: Flags. (line 247) 43368* frame_related, in insn, call_insn, jump_insn, barrier, and set: Flags. 43369 (line 125) 43370* frame_related, in mem: Flags. (line 103) 43371* frame_related, in reg: Flags. (line 112) 43372* frame_related, in symbol_ref: Flags. (line 183) 43373* frequency, count, BB_FREQ_BASE: Profile information. 43374 (line 30) 43375* ftruncM2 instruction pattern: Standard Names. (line 794) 43376* function <1>: Functions for C++. (line 6) 43377* function: Functions. (line 6) 43378* function call conventions: Interface. (line 6) 43379* function entry and exit: Function Entry. (line 6) 43380* function entry point, alternate function entry point: Edges. 43381 (line 180) 43382* function properties: Function Properties. 43383 (line 6) 43384* function-call insns: Calls. (line 6) 43385* FUNCTION_ARG: Register Arguments. (line 11) 43386* FUNCTION_ARG_ADVANCE: Register Arguments. (line 185) 43387* FUNCTION_ARG_BOUNDARY: Register Arguments. (line 238) 43388* FUNCTION_ARG_OFFSET: Register Arguments. (line 196) 43389* FUNCTION_ARG_PADDING: Register Arguments. (line 203) 43390* FUNCTION_ARG_REGNO_P: Register Arguments. (line 243) 43391* FUNCTION_BOUNDARY: Storage Layout. (line 171) 43392* FUNCTION_DECL <1>: Functions for C++. (line 6) 43393* FUNCTION_DECL: Functions. (line 6) 43394* FUNCTION_INCOMING_ARG: Register Arguments. (line 68) 43395* FUNCTION_MODE: Misc. (line 356) 43396* FUNCTION_OUTGOING_VALUE: Scalar Return. (line 56) 43397* FUNCTION_PROFILER: Profiling. (line 9) 43398* FUNCTION_TYPE: Types. (line 6) 43399* FUNCTION_VALUE: Scalar Return. (line 52) 43400* FUNCTION_VALUE_REGNO_P: Scalar Return. (line 81) 43401* functions, leaf: Leaf Functions. (line 6) 43402* fundamental type: Types. (line 6) 43403* g in constraint: Simple Constraints. (line 110) 43404* G in constraint: Simple Constraints. (line 88) 43405* garbage collector, invocation: Invoking the garbage collector. 43406 (line 6) 43407* GCC and portability: Portability. (line 6) 43408* GCC_DRIVER_HOST_INITIALIZATION: Host Misc. (line 36) 43409* gcov_type: Profile information. 43410 (line 41) 43411* ge: Comparisons. (line 72) 43412* ge and attributes: Expressions. (line 64) 43413* GE_EXPR: Unary and Binary Expressions. 43414 (line 6) 43415* GEN_ERRNO_RTX: Library Calls. (line 71) 43416* gencodes: RTL passes. (line 18) 43417* general_operand: Machine-Independent Predicates. 43418 (line 105) 43419* GENERAL_REGS: Register Classes. (line 23) 43420* generated files: Files. (line 6) 43421* generating assembler output: Output Statement. (line 6) 43422* generating insns: RTL Template. (line 6) 43423* GENERIC <1>: GENERIC. (line 6) 43424* GENERIC <2>: Gimplification pass. 43425 (line 12) 43426* GENERIC: Parsing pass. (line 6) 43427* generic predicates: Machine-Independent Predicates. 43428 (line 6) 43429* genflags: RTL passes. (line 18) 43430* get_attr: Expressions. (line 80) 43431* get_attr_length: Insn Lengths. (line 46) 43432* GET_CLASS_NARROWEST_MODE: Machine Modes. (line 333) 43433* GET_CODE: RTL Objects. (line 47) 43434* get_frame_size: Elimination. (line 34) 43435* get_insns: Insns. (line 34) 43436* get_last_insn: Insns. (line 34) 43437* GET_MODE: Machine Modes. (line 280) 43438* GET_MODE_ALIGNMENT: Machine Modes. (line 320) 43439* GET_MODE_BITSIZE: Machine Modes. (line 304) 43440* GET_MODE_CLASS: Machine Modes. (line 294) 43441* GET_MODE_FBIT: Machine Modes. (line 311) 43442* GET_MODE_IBIT: Machine Modes. (line 307) 43443* GET_MODE_MASK: Machine Modes. (line 315) 43444* GET_MODE_NAME: Machine Modes. (line 291) 43445* GET_MODE_NUNITS: Machine Modes. (line 329) 43446* GET_MODE_SIZE: Machine Modes. (line 301) 43447* GET_MODE_UNIT_SIZE: Machine Modes. (line 323) 43448* GET_MODE_WIDER_MODE: Machine Modes. (line 297) 43449* GET_RTX_CLASS: RTL Classes. (line 6) 43450* GET_RTX_FORMAT: RTL Classes. (line 130) 43451* GET_RTX_LENGTH: RTL Classes. (line 127) 43452* geu: Comparisons. (line 72) 43453* geu and attributes: Expressions. (line 64) 43454* GGC: Type Information. (line 6) 43455* ggc_collect: Invoking the garbage collector. 43456 (line 6) 43457* GIMPLE <1>: GIMPLE. (line 6) 43458* GIMPLE <2>: Gimplification pass. 43459 (line 6) 43460* GIMPLE: Parsing pass. (line 14) 43461* GIMPLE Exception Handling: GIMPLE Exception Handling. 43462 (line 6) 43463* GIMPLE instruction set: GIMPLE instruction set. 43464 (line 6) 43465* GIMPLE sequences: GIMPLE sequences. (line 6) 43466* gimple_addresses_taken: Manipulating GIMPLE statements. 43467 (line 90) 43468* GIMPLE_ASM: GIMPLE_ASM. (line 6) 43469* gimple_asm_clear_volatile: GIMPLE_ASM. (line 63) 43470* gimple_asm_clobber_op: GIMPLE_ASM. (line 46) 43471* gimple_asm_input_op: GIMPLE_ASM. (line 30) 43472* gimple_asm_output_op: GIMPLE_ASM. (line 38) 43473* gimple_asm_set_clobber_op: GIMPLE_ASM. (line 50) 43474* gimple_asm_set_input_op: GIMPLE_ASM. (line 34) 43475* gimple_asm_set_output_op: GIMPLE_ASM. (line 42) 43476* gimple_asm_set_volatile: GIMPLE_ASM. (line 60) 43477* gimple_asm_volatile_p: GIMPLE_ASM. (line 57) 43478* GIMPLE_ASSIGN: GIMPLE_ASSIGN. (line 6) 43479* gimple_assign_cast_p: GIMPLE_ASSIGN. (line 89) 43480* gimple_assign_lhs: GIMPLE_ASSIGN. (line 51) 43481* gimple_assign_rhs1: GIMPLE_ASSIGN. (line 57) 43482* gimple_assign_rhs2: GIMPLE_ASSIGN. (line 64) 43483* gimple_assign_set_lhs: GIMPLE_ASSIGN. (line 71) 43484* gimple_assign_set_rhs1: GIMPLE_ASSIGN. (line 74) 43485* gimple_assign_set_rhs2: GIMPLE_ASSIGN. (line 85) 43486* gimple_bb: Manipulating GIMPLE statements. 43487 (line 18) 43488* GIMPLE_BIND: GIMPLE_BIND. (line 6) 43489* gimple_bind_add_seq: GIMPLE_BIND. (line 36) 43490* gimple_bind_add_stmt: GIMPLE_BIND. (line 32) 43491* gimple_bind_append_vars: GIMPLE_BIND. (line 19) 43492* gimple_bind_block: GIMPLE_BIND. (line 40) 43493* gimple_bind_body: GIMPLE_BIND. (line 23) 43494* gimple_bind_set_block: GIMPLE_BIND. (line 45) 43495* gimple_bind_set_body: GIMPLE_BIND. (line 28) 43496* gimple_bind_set_vars: GIMPLE_BIND. (line 15) 43497* gimple_bind_vars: GIMPLE_BIND. (line 12) 43498* gimple_block: Manipulating GIMPLE statements. 43499 (line 21) 43500* gimple_build_asm: GIMPLE_ASM. (line 8) 43501* gimple_build_asm_vec: GIMPLE_ASM. (line 17) 43502* gimple_build_assign: GIMPLE_ASSIGN. (line 7) 43503* gimple_build_assign_with_ops: GIMPLE_ASSIGN. (line 30) 43504* gimple_build_bind: GIMPLE_BIND. (line 8) 43505* gimple_build_call: GIMPLE_CALL. (line 8) 43506* gimple_build_call_from_tree: GIMPLE_CALL. (line 16) 43507* gimple_build_call_vec: GIMPLE_CALL. (line 25) 43508* gimple_build_catch: GIMPLE_CATCH. (line 8) 43509* gimple_build_cond: GIMPLE_COND. (line 8) 43510* gimple_build_cond_from_tree: GIMPLE_COND. (line 16) 43511* gimple_build_debug_bind: GIMPLE_DEBUG. (line 8) 43512* gimple_build_eh_filter: GIMPLE_EH_FILTER. (line 8) 43513* gimple_build_goto: GIMPLE_LABEL. (line 18) 43514* gimple_build_label: GIMPLE_LABEL. (line 7) 43515* gimple_build_nop: GIMPLE_NOP. (line 7) 43516* gimple_build_omp_atomic_load: GIMPLE_OMP_ATOMIC_LOAD. 43517 (line 8) 43518* gimple_build_omp_atomic_store: GIMPLE_OMP_ATOMIC_STORE. 43519 (line 7) 43520* gimple_build_omp_continue: GIMPLE_OMP_CONTINUE. 43521 (line 8) 43522* gimple_build_omp_critical: GIMPLE_OMP_CRITICAL. 43523 (line 8) 43524* gimple_build_omp_for: GIMPLE_OMP_FOR. (line 9) 43525* gimple_build_omp_master: GIMPLE_OMP_MASTER. (line 7) 43526* gimple_build_omp_ordered: GIMPLE_OMP_ORDERED. (line 7) 43527* gimple_build_omp_parallel: GIMPLE_OMP_PARALLEL. 43528 (line 8) 43529* gimple_build_omp_return: GIMPLE_OMP_RETURN. (line 7) 43530* gimple_build_omp_section: GIMPLE_OMP_SECTION. (line 7) 43531* gimple_build_omp_sections: GIMPLE_OMP_SECTIONS. 43532 (line 8) 43533* gimple_build_omp_sections_switch: GIMPLE_OMP_SECTIONS. 43534 (line 14) 43535* gimple_build_omp_single: GIMPLE_OMP_SINGLE. (line 8) 43536* gimple_build_resx: GIMPLE_RESX. (line 7) 43537* gimple_build_return: GIMPLE_RETURN. (line 7) 43538* gimple_build_switch: GIMPLE_SWITCH. (line 8) 43539* gimple_build_switch_vec: GIMPLE_SWITCH. (line 16) 43540* gimple_build_try: GIMPLE_TRY. (line 8) 43541* gimple_build_wce: GIMPLE_WITH_CLEANUP_EXPR. 43542 (line 7) 43543* GIMPLE_CALL: GIMPLE_CALL. (line 6) 43544* gimple_call_arg: GIMPLE_CALL. (line 66) 43545* gimple_call_cannot_inline_p: GIMPLE_CALL. (line 91) 43546* gimple_call_chain: GIMPLE_CALL. (line 57) 43547* gimple_call_copy_skip_args: GIMPLE_CALL. (line 98) 43548* gimple_call_fn: GIMPLE_CALL. (line 38) 43549* gimple_call_fndecl: GIMPLE_CALL. (line 46) 43550* gimple_call_lhs: GIMPLE_CALL. (line 29) 43551* gimple_call_mark_uninlinable: GIMPLE_CALL. (line 88) 43552* gimple_call_noreturn_p: GIMPLE_CALL. (line 94) 43553* gimple_call_return_type: GIMPLE_CALL. (line 54) 43554* gimple_call_set_arg: GIMPLE_CALL. (line 76) 43555* gimple_call_set_chain: GIMPLE_CALL. (line 60) 43556* gimple_call_set_fn: GIMPLE_CALL. (line 42) 43557* gimple_call_set_fndecl: GIMPLE_CALL. (line 51) 43558* gimple_call_set_lhs: GIMPLE_CALL. (line 35) 43559* gimple_call_set_tail: GIMPLE_CALL. (line 80) 43560* gimple_call_tail_p: GIMPLE_CALL. (line 85) 43561* GIMPLE_CATCH: GIMPLE_CATCH. (line 6) 43562* gimple_catch_handler: GIMPLE_CATCH. (line 20) 43563* gimple_catch_set_handler: GIMPLE_CATCH. (line 28) 43564* gimple_catch_set_types: GIMPLE_CATCH. (line 24) 43565* gimple_catch_types: GIMPLE_CATCH. (line 13) 43566* gimple_code: Manipulating GIMPLE statements. 43567 (line 15) 43568* GIMPLE_COND: GIMPLE_COND. (line 6) 43569* gimple_cond_false_label: GIMPLE_COND. (line 60) 43570* gimple_cond_lhs: GIMPLE_COND. (line 30) 43571* gimple_cond_make_false: GIMPLE_COND. (line 64) 43572* gimple_cond_make_true: GIMPLE_COND. (line 67) 43573* gimple_cond_rhs: GIMPLE_COND. (line 38) 43574* gimple_cond_set_code: GIMPLE_COND. (line 26) 43575* gimple_cond_set_false_label: GIMPLE_COND. (line 56) 43576* gimple_cond_set_lhs: GIMPLE_COND. (line 34) 43577* gimple_cond_set_rhs: GIMPLE_COND. (line 42) 43578* gimple_cond_set_true_label: GIMPLE_COND. (line 51) 43579* gimple_cond_true_label: GIMPLE_COND. (line 46) 43580* gimple_copy: Manipulating GIMPLE statements. 43581 (line 147) 43582* GIMPLE_DEBUG: GIMPLE_DEBUG. (line 6) 43583* GIMPLE_DEBUG_BIND: GIMPLE_DEBUG. (line 6) 43584* gimple_debug_bind_get_value: GIMPLE_DEBUG. (line 48) 43585* gimple_debug_bind_get_var: GIMPLE_DEBUG. (line 45) 43586* gimple_debug_bind_has_value_p: GIMPLE_DEBUG. (line 69) 43587* gimple_debug_bind_reset_value: GIMPLE_DEBUG. (line 65) 43588* gimple_debug_bind_set_value: GIMPLE_DEBUG. (line 61) 43589* gimple_debug_bind_set_var: GIMPLE_DEBUG. (line 57) 43590* GIMPLE_EH_FILTER: GIMPLE_EH_FILTER. (line 6) 43591* gimple_eh_filter_failure: GIMPLE_EH_FILTER. (line 19) 43592* gimple_eh_filter_must_not_throw: GIMPLE_EH_FILTER. (line 33) 43593* gimple_eh_filter_set_failure: GIMPLE_EH_FILTER. (line 29) 43594* gimple_eh_filter_set_must_not_throw: GIMPLE_EH_FILTER. (line 37) 43595* gimple_eh_filter_set_types: GIMPLE_EH_FILTER. (line 24) 43596* gimple_eh_filter_types: GIMPLE_EH_FILTER. (line 12) 43597* gimple_expr_type: Manipulating GIMPLE statements. 43598 (line 24) 43599* gimple_goto_dest: GIMPLE_LABEL. (line 21) 43600* gimple_goto_set_dest: GIMPLE_LABEL. (line 24) 43601* gimple_has_mem_ops: Manipulating GIMPLE statements. 43602 (line 72) 43603* gimple_has_ops: Manipulating GIMPLE statements. 43604 (line 69) 43605* gimple_has_volatile_ops: Manipulating GIMPLE statements. 43606 (line 134) 43607* GIMPLE_LABEL: GIMPLE_LABEL. (line 6) 43608* gimple_label_label: GIMPLE_LABEL. (line 11) 43609* gimple_label_set_label: GIMPLE_LABEL. (line 14) 43610* gimple_loaded_syms: Manipulating GIMPLE statements. 43611 (line 122) 43612* gimple_locus: Manipulating GIMPLE statements. 43613 (line 42) 43614* gimple_locus_empty_p: Manipulating GIMPLE statements. 43615 (line 48) 43616* gimple_modified_p: Manipulating GIMPLE statements. 43617 (line 130) 43618* gimple_no_warning_p: Manipulating GIMPLE statements. 43619 (line 51) 43620* GIMPLE_NOP: GIMPLE_NOP. (line 6) 43621* gimple_nop_p: GIMPLE_NOP. (line 10) 43622* gimple_num_ops <1>: Manipulating GIMPLE statements. 43623 (line 75) 43624* gimple_num_ops: Logical Operators. (line 76) 43625* GIMPLE_OMP_ATOMIC_LOAD: GIMPLE_OMP_ATOMIC_LOAD. 43626 (line 6) 43627* gimple_omp_atomic_load_lhs: GIMPLE_OMP_ATOMIC_LOAD. 43628 (line 17) 43629* gimple_omp_atomic_load_rhs: GIMPLE_OMP_ATOMIC_LOAD. 43630 (line 24) 43631* gimple_omp_atomic_load_set_lhs: GIMPLE_OMP_ATOMIC_LOAD. 43632 (line 14) 43633* gimple_omp_atomic_load_set_rhs: GIMPLE_OMP_ATOMIC_LOAD. 43634 (line 21) 43635* GIMPLE_OMP_ATOMIC_STORE: GIMPLE_OMP_ATOMIC_STORE. 43636 (line 6) 43637* gimple_omp_atomic_store_set_val: GIMPLE_OMP_ATOMIC_STORE. 43638 (line 12) 43639* gimple_omp_atomic_store_val: GIMPLE_OMP_ATOMIC_STORE. 43640 (line 15) 43641* gimple_omp_body: GIMPLE_OMP_PARALLEL. 43642 (line 24) 43643* GIMPLE_OMP_CONTINUE: GIMPLE_OMP_CONTINUE. 43644 (line 6) 43645* gimple_omp_continue_control_def: GIMPLE_OMP_CONTINUE. 43646 (line 13) 43647* gimple_omp_continue_control_def_ptr: GIMPLE_OMP_CONTINUE. 43648 (line 17) 43649* gimple_omp_continue_control_use: GIMPLE_OMP_CONTINUE. 43650 (line 24) 43651* gimple_omp_continue_control_use_ptr: GIMPLE_OMP_CONTINUE. 43652 (line 28) 43653* gimple_omp_continue_set_control_def: GIMPLE_OMP_CONTINUE. 43654 (line 20) 43655* gimple_omp_continue_set_control_use: GIMPLE_OMP_CONTINUE. 43656 (line 31) 43657* GIMPLE_OMP_CRITICAL: GIMPLE_OMP_CRITICAL. 43658 (line 6) 43659* gimple_omp_critical_name: GIMPLE_OMP_CRITICAL. 43660 (line 13) 43661* gimple_omp_critical_set_name: GIMPLE_OMP_CRITICAL. 43662 (line 21) 43663* GIMPLE_OMP_FOR: GIMPLE_OMP_FOR. (line 6) 43664* gimple_omp_for_clauses: GIMPLE_OMP_FOR. (line 20) 43665* gimple_omp_for_final: GIMPLE_OMP_FOR. (line 51) 43666* gimple_omp_for_incr: GIMPLE_OMP_FOR. (line 61) 43667* gimple_omp_for_index: GIMPLE_OMP_FOR. (line 31) 43668* gimple_omp_for_initial: GIMPLE_OMP_FOR. (line 41) 43669* gimple_omp_for_pre_body: GIMPLE_OMP_FOR. (line 70) 43670* gimple_omp_for_set_clauses: GIMPLE_OMP_FOR. (line 27) 43671* gimple_omp_for_set_cond: GIMPLE_OMP_FOR. (line 80) 43672* gimple_omp_for_set_final: GIMPLE_OMP_FOR. (line 58) 43673* gimple_omp_for_set_incr: GIMPLE_OMP_FOR. (line 67) 43674* gimple_omp_for_set_index: GIMPLE_OMP_FOR. (line 38) 43675* gimple_omp_for_set_initial: GIMPLE_OMP_FOR. (line 48) 43676* gimple_omp_for_set_pre_body: GIMPLE_OMP_FOR. (line 75) 43677* GIMPLE_OMP_MASTER: GIMPLE_OMP_MASTER. (line 6) 43678* GIMPLE_OMP_ORDERED: GIMPLE_OMP_ORDERED. (line 6) 43679* GIMPLE_OMP_PARALLEL: GIMPLE_OMP_PARALLEL. 43680 (line 6) 43681* gimple_omp_parallel_child_fn: GIMPLE_OMP_PARALLEL. 43682 (line 42) 43683* gimple_omp_parallel_clauses: GIMPLE_OMP_PARALLEL. 43684 (line 31) 43685* gimple_omp_parallel_combined_p: GIMPLE_OMP_PARALLEL. 43686 (line 16) 43687* gimple_omp_parallel_data_arg: GIMPLE_OMP_PARALLEL. 43688 (line 54) 43689* gimple_omp_parallel_set_child_fn: GIMPLE_OMP_PARALLEL. 43690 (line 51) 43691* gimple_omp_parallel_set_clauses: GIMPLE_OMP_PARALLEL. 43692 (line 38) 43693* gimple_omp_parallel_set_combined_p: GIMPLE_OMP_PARALLEL. 43694 (line 20) 43695* gimple_omp_parallel_set_data_arg: GIMPLE_OMP_PARALLEL. 43696 (line 62) 43697* GIMPLE_OMP_RETURN: GIMPLE_OMP_RETURN. (line 6) 43698* gimple_omp_return_nowait_p: GIMPLE_OMP_RETURN. (line 14) 43699* gimple_omp_return_set_nowait: GIMPLE_OMP_RETURN. (line 11) 43700* GIMPLE_OMP_SECTION: GIMPLE_OMP_SECTION. (line 6) 43701* gimple_omp_section_last_p: GIMPLE_OMP_SECTION. (line 12) 43702* gimple_omp_section_set_last: GIMPLE_OMP_SECTION. (line 16) 43703* GIMPLE_OMP_SECTIONS: GIMPLE_OMP_SECTIONS. 43704 (line 6) 43705* gimple_omp_sections_clauses: GIMPLE_OMP_SECTIONS. 43706 (line 30) 43707* gimple_omp_sections_control: GIMPLE_OMP_SECTIONS. 43708 (line 17) 43709* gimple_omp_sections_set_clauses: GIMPLE_OMP_SECTIONS. 43710 (line 37) 43711* gimple_omp_sections_set_control: GIMPLE_OMP_SECTIONS. 43712 (line 26) 43713* gimple_omp_set_body: GIMPLE_OMP_PARALLEL. 43714 (line 28) 43715* GIMPLE_OMP_SINGLE: GIMPLE_OMP_SINGLE. (line 6) 43716* gimple_omp_single_clauses: GIMPLE_OMP_SINGLE. (line 14) 43717* gimple_omp_single_set_clauses: GIMPLE_OMP_SINGLE. (line 21) 43718* gimple_op <1>: Manipulating GIMPLE statements. 43719 (line 81) 43720* gimple_op: Logical Operators. (line 79) 43721* GIMPLE_PHI: GIMPLE_PHI. (line 6) 43722* gimple_phi_capacity: GIMPLE_PHI. (line 10) 43723* gimple_phi_num_args: GIMPLE_PHI. (line 14) 43724* gimple_phi_result: GIMPLE_PHI. (line 19) 43725* gimple_phi_set_arg: GIMPLE_PHI. (line 33) 43726* gimple_phi_set_result: GIMPLE_PHI. (line 25) 43727* GIMPLE_RESX: GIMPLE_RESX. (line 6) 43728* gimple_resx_region: GIMPLE_RESX. (line 13) 43729* gimple_resx_set_region: GIMPLE_RESX. (line 16) 43730* GIMPLE_RETURN: GIMPLE_RETURN. (line 6) 43731* gimple_return_retval: GIMPLE_RETURN. (line 10) 43732* gimple_return_set_retval: GIMPLE_RETURN. (line 14) 43733* gimple_rhs_class: GIMPLE_ASSIGN. (line 46) 43734* gimple_seq_add_seq: GIMPLE sequences. (line 32) 43735* gimple_seq_add_stmt: GIMPLE sequences. (line 26) 43736* gimple_seq_alloc: GIMPLE sequences. (line 62) 43737* gimple_seq_copy: GIMPLE sequences. (line 67) 43738* gimple_seq_deep_copy: GIMPLE sequences. (line 37) 43739* gimple_seq_empty_p: GIMPLE sequences. (line 70) 43740* gimple_seq_first: GIMPLE sequences. (line 44) 43741* gimple_seq_init: GIMPLE sequences. (line 59) 43742* gimple_seq_last: GIMPLE sequences. (line 47) 43743* gimple_seq_reverse: GIMPLE sequences. (line 40) 43744* gimple_seq_set_first: GIMPLE sequences. (line 55) 43745* gimple_seq_set_last: GIMPLE sequences. (line 51) 43746* gimple_seq_singleton_p: GIMPLE sequences. (line 79) 43747* gimple_set_block: Manipulating GIMPLE statements. 43748 (line 39) 43749* gimple_set_def_ops: Manipulating GIMPLE statements. 43750 (line 98) 43751* gimple_set_has_volatile_ops: Manipulating GIMPLE statements. 43752 (line 138) 43753* gimple_set_locus: Manipulating GIMPLE statements. 43754 (line 45) 43755* gimple_set_op: Manipulating GIMPLE statements. 43756 (line 87) 43757* gimple_set_plf: Manipulating GIMPLE statements. 43758 (line 62) 43759* gimple_set_use_ops: Manipulating GIMPLE statements. 43760 (line 105) 43761* gimple_set_vdef_ops: Manipulating GIMPLE statements. 43762 (line 119) 43763* gimple_set_visited: Manipulating GIMPLE statements. 43764 (line 55) 43765* gimple_set_vuse_ops: Manipulating GIMPLE statements. 43766 (line 112) 43767* gimple_statement_base: Tuple representation. 43768 (line 14) 43769* gimple_statement_with_ops: Tuple representation. 43770 (line 96) 43771* gimple_stored_syms: Manipulating GIMPLE statements. 43772 (line 126) 43773* GIMPLE_SWITCH: GIMPLE_SWITCH. (line 6) 43774* gimple_switch_default_label: GIMPLE_SWITCH. (line 46) 43775* gimple_switch_index: GIMPLE_SWITCH. (line 31) 43776* gimple_switch_label: GIMPLE_SWITCH. (line 37) 43777* gimple_switch_num_labels: GIMPLE_SWITCH. (line 22) 43778* gimple_switch_set_default_label: GIMPLE_SWITCH. (line 50) 43779* gimple_switch_set_index: GIMPLE_SWITCH. (line 34) 43780* gimple_switch_set_label: GIMPLE_SWITCH. (line 42) 43781* gimple_switch_set_num_labels: GIMPLE_SWITCH. (line 27) 43782* GIMPLE_TRY: GIMPLE_TRY. (line 6) 43783* gimple_try_catch_is_cleanup: GIMPLE_TRY. (line 20) 43784* gimple_try_cleanup: GIMPLE_TRY. (line 27) 43785* gimple_try_eval: GIMPLE_TRY. (line 23) 43786* gimple_try_flags: GIMPLE_TRY. (line 16) 43787* gimple_try_set_catch_is_cleanup: GIMPLE_TRY. (line 32) 43788* gimple_try_set_cleanup: GIMPLE_TRY. (line 41) 43789* gimple_try_set_eval: GIMPLE_TRY. (line 36) 43790* gimple_visited_p: Manipulating GIMPLE statements. 43791 (line 58) 43792* gimple_wce_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 43793 (line 11) 43794* gimple_wce_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 43795 (line 18) 43796* gimple_wce_set_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 43797 (line 15) 43798* gimple_wce_set_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 43799 (line 22) 43800* GIMPLE_WITH_CLEANUP_EXPR: GIMPLE_WITH_CLEANUP_EXPR. 43801 (line 6) 43802* gimplification <1>: Gimplification pass. 43803 (line 6) 43804* gimplification: Parsing pass. (line 14) 43805* gimplifier: Parsing pass. (line 14) 43806* gimplify_assign: GIMPLE_ASSIGN. (line 19) 43807* gimplify_expr: Gimplification pass. 43808 (line 18) 43809* gimplify_function_tree: Gimplification pass. 43810 (line 18) 43811* GLOBAL_INIT_PRIORITY: Functions for C++. (line 141) 43812* global_regs: Register Basics. (line 59) 43813* GO_IF_LEGITIMATE_ADDRESS: Addressing Modes. (line 91) 43814* GO_IF_MODE_DEPENDENT_ADDRESS: Addressing Modes. (line 192) 43815* GOFAST, floating point emulation library: Library Calls. (line 44) 43816* gofast_maybe_init_libfuncs: Library Calls. (line 44) 43817* greater than: Comparisons. (line 60) 43818* gsi_after_labels: Sequence iterators. (line 76) 43819* gsi_bb: Sequence iterators. (line 83) 43820* gsi_commit_edge_inserts: Sequence iterators. (line 194) 43821* gsi_commit_one_edge_insert: Sequence iterators. (line 190) 43822* gsi_end_p: Sequence iterators. (line 60) 43823* gsi_for_stmt: Sequence iterators. (line 157) 43824* gsi_insert_after: Sequence iterators. (line 147) 43825* gsi_insert_before: Sequence iterators. (line 136) 43826* gsi_insert_on_edge: Sequence iterators. (line 174) 43827* gsi_insert_on_edge_immediate: Sequence iterators. (line 185) 43828* gsi_insert_seq_after: Sequence iterators. (line 154) 43829* gsi_insert_seq_before: Sequence iterators. (line 143) 43830* gsi_insert_seq_on_edge: Sequence iterators. (line 179) 43831* gsi_last: Sequence iterators. (line 50) 43832* gsi_last_bb: Sequence iterators. (line 56) 43833* gsi_link_after: Sequence iterators. (line 115) 43834* gsi_link_before: Sequence iterators. (line 105) 43835* gsi_link_seq_after: Sequence iterators. (line 110) 43836* gsi_link_seq_before: Sequence iterators. (line 99) 43837* gsi_move_after: Sequence iterators. (line 161) 43838* gsi_move_before: Sequence iterators. (line 166) 43839* gsi_move_to_bb_end: Sequence iterators. (line 171) 43840* gsi_next: Sequence iterators. (line 66) 43841* gsi_one_before_end_p: Sequence iterators. (line 63) 43842* gsi_prev: Sequence iterators. (line 69) 43843* gsi_remove: Sequence iterators. (line 90) 43844* gsi_replace: Sequence iterators. (line 130) 43845* gsi_seq: Sequence iterators. (line 86) 43846* gsi_split_seq_after: Sequence iterators. (line 120) 43847* gsi_split_seq_before: Sequence iterators. (line 125) 43848* gsi_start: Sequence iterators. (line 40) 43849* gsi_start_bb: Sequence iterators. (line 46) 43850* gsi_stmt: Sequence iterators. (line 72) 43851* gt: Comparisons. (line 60) 43852* gt and attributes: Expressions. (line 64) 43853* GT_EXPR: Unary and Binary Expressions. 43854 (line 6) 43855* gtu: Comparisons. (line 64) 43856* gtu and attributes: Expressions. (line 64) 43857* GTY: Type Information. (line 6) 43858* H in constraint: Simple Constraints. (line 88) 43859* HAmode: Machine Modes. (line 144) 43860* HANDLE_PRAGMA_PACK_PUSH_POP: Misc. (line 467) 43861* HANDLE_PRAGMA_PACK_WITH_EXPANSION: Misc. (line 478) 43862* HANDLE_SYSV_PRAGMA: Misc. (line 438) 43863* HANDLER: Statements for C++. (line 6) 43864* HANDLER_BODY: Statements for C++. (line 6) 43865* HANDLER_PARMS: Statements for C++. (line 6) 43866* hard registers: Regs and Memory. (line 9) 43867* HARD_FRAME_POINTER_REGNUM: Frame Registers. (line 20) 43868* HARD_REGNO_CALL_PART_CLOBBERED: Register Basics. (line 53) 43869* HARD_REGNO_CALLER_SAVE_MODE: Caller Saves. (line 20) 43870* HARD_REGNO_MODE_OK: Values in Registers. 43871 (line 58) 43872* HARD_REGNO_NREGS: Values in Registers. 43873 (line 11) 43874* HARD_REGNO_NREGS_HAS_PADDING: Values in Registers. 43875 (line 25) 43876* HARD_REGNO_NREGS_WITH_PADDING: Values in Registers. 43877 (line 43) 43878* HARD_REGNO_RENAME_OK: Values in Registers. 43879 (line 119) 43880* HAS_INIT_SECTION: Macros for Initialization. 43881 (line 19) 43882* HAS_LONG_COND_BRANCH: Misc. (line 9) 43883* HAS_LONG_UNCOND_BRANCH: Misc. (line 18) 43884* HAVE_DOS_BASED_FILE_SYSTEM: Filesystem. (line 11) 43885* HAVE_POST_DECREMENT: Addressing Modes. (line 12) 43886* HAVE_POST_INCREMENT: Addressing Modes. (line 11) 43887* HAVE_POST_MODIFY_DISP: Addressing Modes. (line 18) 43888* HAVE_POST_MODIFY_REG: Addressing Modes. (line 24) 43889* HAVE_PRE_DECREMENT: Addressing Modes. (line 10) 43890* HAVE_PRE_INCREMENT: Addressing Modes. (line 9) 43891* HAVE_PRE_MODIFY_DISP: Addressing Modes. (line 17) 43892* HAVE_PRE_MODIFY_REG: Addressing Modes. (line 23) 43893* HCmode: Machine Modes. (line 197) 43894* HFmode: Machine Modes. (line 58) 43895* high: Constants. (line 109) 43896* HImode: Machine Modes. (line 29) 43897* HImode, in insn: Insns. (line 272) 43898* host configuration: Host Config. (line 6) 43899* host functions: Host Common. (line 6) 43900* host hooks: Host Common. (line 6) 43901* host makefile fragment: Host Fragment. (line 6) 43902* HOST_BIT_BUCKET: Filesystem. (line 51) 43903* HOST_EXECUTABLE_SUFFIX: Filesystem. (line 45) 43904* HOST_HOOKS_EXTRA_SIGNALS: Host Common. (line 12) 43905* HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY: Host Common. (line 45) 43906* HOST_HOOKS_GT_PCH_USE_ADDRESS: Host Common. (line 26) 43907* HOST_LACKS_INODE_NUMBERS: Filesystem. (line 89) 43908* HOST_LONG_FORMAT: Host Misc. (line 45) 43909* HOST_LONG_LONG_FORMAT: Host Misc. (line 41) 43910* HOST_OBJECT_SUFFIX: Filesystem. (line 40) 43911* HOST_PTR_PRINTF: Host Misc. (line 49) 43912* HOT_TEXT_SECTION_NAME: Sections. (line 43) 43913* HQmode: Machine Modes. (line 107) 43914* I in constraint: Simple Constraints. (line 71) 43915* i in constraint: Simple Constraints. (line 60) 43916* identifier: Identifiers. (line 6) 43917* IDENTIFIER_LENGTH: Identifiers. (line 22) 43918* IDENTIFIER_NODE: Identifiers. (line 6) 43919* IDENTIFIER_OPNAME_P: Identifiers. (line 27) 43920* IDENTIFIER_POINTER: Identifiers. (line 17) 43921* IDENTIFIER_TYPENAME_P: Identifiers. (line 33) 43922* IEEE 754-2008: Decimal float library routines. 43923 (line 6) 43924* IF_COND: Statements for C++. (line 6) 43925* if_marked: GTY Options. (line 155) 43926* IF_STMT: Statements for C++. (line 6) 43927* if_then_else: Comparisons. (line 80) 43928* if_then_else and attributes: Expressions. (line 32) 43929* if_then_else usage: Side Effects. (line 56) 43930* IFCVT_EXTRA_FIELDS: Misc. (line 622) 43931* IFCVT_INIT_EXTRA_FIELDS: Misc. (line 617) 43932* IFCVT_MODIFY_CANCEL: Misc. (line 611) 43933* IFCVT_MODIFY_FINAL: Misc. (line 605) 43934* IFCVT_MODIFY_INSN: Misc. (line 599) 43935* IFCVT_MODIFY_MULTIPLE_TESTS: Misc. (line 592) 43936* IFCVT_MODIFY_TESTS: Misc. (line 581) 43937* IMAGPART_EXPR: Unary and Binary Expressions. 43938 (line 6) 43939* Immediate Uses: SSA Operands. (line 274) 43940* immediate_operand: Machine-Independent Predicates. 43941 (line 11) 43942* IMMEDIATE_PREFIX: Instruction Output. (line 140) 43943* in_struct: Flags. (line 263) 43944* in_struct, in code_label and note: Flags. (line 59) 43945* in_struct, in insn and jump_insn and call_insn: Flags. (line 49) 43946* in_struct, in insn, jump_insn and call_insn: Flags. (line 166) 43947* in_struct, in mem: Flags. (line 70) 43948* in_struct, in subreg: Flags. (line 205) 43949* include: Including Patterns. (line 6) 43950* INCLUDE_DEFAULTS: Driver. (line 430) 43951* inclusive-or, bitwise: Arithmetic. (line 158) 43952* INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 183) 43953* INCOMING_REGNO: Register Basics. (line 91) 43954* INCOMING_RETURN_ADDR_RTX: Frame Layout. (line 139) 43955* INCOMING_STACK_BOUNDARY: Storage Layout. (line 166) 43956* INDEX_REG_CLASS: Register Classes. (line 134) 43957* indirect_jump instruction pattern: Standard Names. (line 1041) 43958* indirect_operand: Machine-Independent Predicates. 43959 (line 71) 43960* INDIRECT_REF: Storage References. (line 6) 43961* INIT_ARRAY_SECTION_ASM_OP: Sections. (line 108) 43962* INIT_CUMULATIVE_ARGS: Register Arguments. (line 149) 43963* INIT_CUMULATIVE_INCOMING_ARGS: Register Arguments. (line 176) 43964* INIT_CUMULATIVE_LIBCALL_ARGS: Register Arguments. (line 170) 43965* INIT_ENVIRONMENT: Driver. (line 369) 43966* INIT_EXPANDERS: Per-Function Data. (line 39) 43967* INIT_EXPR: Unary and Binary Expressions. 43968 (line 6) 43969* init_machine_status: Per-Function Data. (line 45) 43970* init_one_libfunc: Library Calls. (line 15) 43971* INIT_SECTION_ASM_OP <1>: Macros for Initialization. 43972 (line 10) 43973* INIT_SECTION_ASM_OP: Sections. (line 92) 43974* INITIAL_ELIMINATION_OFFSET: Elimination. (line 85) 43975* INITIAL_FRAME_ADDRESS_RTX: Frame Layout. (line 83) 43976* INITIAL_FRAME_POINTER_OFFSET: Elimination. (line 35) 43977* initialization routines: Initialization. (line 6) 43978* inlining: Target Attributes. (line 87) 43979* insert_insn_on_edge: Maintaining the CFG. 43980 (line 118) 43981* insn: Insns. (line 63) 43982* insn and /f: Flags. (line 125) 43983* insn and /j: Flags. (line 175) 43984* insn and /s: Flags. (line 49) 43985* insn and /u: Flags. (line 39) 43986* insn and /v: Flags. (line 44) 43987* insn attributes: Insn Attributes. (line 6) 43988* insn canonicalization: Insn Canonicalizations. 43989 (line 6) 43990* insn includes: Including Patterns. (line 6) 43991* insn lengths, computing: Insn Lengths. (line 6) 43992* insn splitting: Insn Splitting. (line 6) 43993* insn-attr.h: Defining Attributes. 43994 (line 24) 43995* INSN_ANNULLED_BRANCH_P: Flags. (line 39) 43996* INSN_CODE: Insns. (line 298) 43997* INSN_DELETED_P: Flags. (line 44) 43998* INSN_FROM_TARGET_P: Flags. (line 49) 43999* insn_list: Insns. (line 545) 44000* INSN_REFERENCES_ARE_DELAYED: Misc. (line 520) 44001* INSN_SETS_ARE_DELAYED: Misc. (line 509) 44002* INSN_UID: Insns. (line 23) 44003* INSN_VAR_LOCATION: Insns. (line 239) 44004* insns: Insns. (line 6) 44005* insns, generating: RTL Template. (line 6) 44006* insns, recognizing: RTL Template. (line 6) 44007* instruction attributes: Insn Attributes. (line 6) 44008* instruction latency time: Processor pipeline description. 44009 (line 6) 44010* instruction patterns: Patterns. (line 6) 44011* instruction splitting: Insn Splitting. (line 6) 44012* insv instruction pattern: Standard Names. (line 866) 44013* int: Manipulating GIMPLE statements. 44014 (line 66) 44015* INT16_TYPE: Type Layout. (line 237) 44016* INT32_TYPE: Type Layout. (line 238) 44017* INT64_TYPE: Type Layout. (line 239) 44018* INT8_TYPE: Type Layout. (line 236) 44019* INT_FAST16_TYPE: Type Layout. (line 253) 44020* INT_FAST32_TYPE: Type Layout. (line 254) 44021* INT_FAST64_TYPE: Type Layout. (line 255) 44022* INT_FAST8_TYPE: Type Layout. (line 252) 44023* INT_LEAST16_TYPE: Type Layout. (line 245) 44024* INT_LEAST32_TYPE: Type Layout. (line 246) 44025* INT_LEAST64_TYPE: Type Layout. (line 247) 44026* INT_LEAST8_TYPE: Type Layout. (line 244) 44027* INT_TYPE_SIZE: Type Layout. (line 12) 44028* INTEGER_CST: Constant expressions. 44029 (line 6) 44030* INTEGER_TYPE: Types. (line 6) 44031* Interdependence of Patterns: Dependent Patterns. (line 6) 44032* interfacing to GCC output: Interface. (line 6) 44033* interlock delays: Processor pipeline description. 44034 (line 6) 44035* intermediate representation lowering: Parsing pass. (line 14) 44036* INTMAX_TYPE: Type Layout. (line 213) 44037* INTPTR_TYPE: Type Layout. (line 260) 44038* introduction: Top. (line 6) 44039* INVOKE__main: Macros for Initialization. 44040 (line 51) 44041* ior: Arithmetic. (line 158) 44042* ior and attributes: Expressions. (line 50) 44043* ior, canonicalization of: Insn Canonicalizations. 44044 (line 52) 44045* iorM3 instruction pattern: Standard Names. (line 222) 44046* IRA_COVER_CLASSES: Register Classes. (line 535) 44047* IRA_HARD_REGNO_ADD_COST_MULTIPLIER: Allocation Order. (line 37) 44048* IS_ASM_LOGICAL_LINE_SEPARATOR: Data Output. (line 120) 44049* is_gimple_omp: GIMPLE_OMP_PARALLEL. 44050 (line 65) 44051* iterators in .md files: Iterators. (line 6) 44052* IV analysis on GIMPLE: Scalar evolutions. (line 6) 44053* IV analysis on RTL: loop-iv. (line 6) 44054* jump: Flags. (line 314) 44055* jump instruction pattern: Standard Names. (line 932) 44056* jump instruction patterns: Jump Patterns. (line 6) 44057* jump instructions and set: Side Effects. (line 56) 44058* jump, in call_insn: Flags. (line 179) 44059* jump, in insn: Flags. (line 175) 44060* jump, in mem: Flags. (line 79) 44061* JUMP_ALIGN: Alignment Output. (line 9) 44062* jump_insn: Insns. (line 73) 44063* jump_insn and /f: Flags. (line 125) 44064* jump_insn and /s: Flags. (line 49) 44065* jump_insn and /u: Flags. (line 39) 44066* jump_insn and /v: Flags. (line 44) 44067* JUMP_LABEL: Insns. (line 80) 44068* JUMP_TABLES_IN_TEXT_SECTION: Sections. (line 152) 44069* Jumps: Jumps. (line 6) 44070* LABEL_ALIGN: Alignment Output. (line 52) 44071* LABEL_ALIGN_AFTER_BARRIER: Alignment Output. (line 22) 44072* LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP: Alignment Output. (line 30) 44073* LABEL_ALIGN_MAX_SKIP: Alignment Output. (line 62) 44074* LABEL_ALT_ENTRY_P: Insns. (line 140) 44075* LABEL_ALTERNATE_NAME: Edges. (line 180) 44076* LABEL_DECL: Declarations. (line 6) 44077* LABEL_KIND: Insns. (line 140) 44078* LABEL_NUSES: Insns. (line 136) 44079* LABEL_PRESERVE_P: Flags. (line 59) 44080* label_ref: Constants. (line 86) 44081* label_ref and /v: Flags. (line 65) 44082* label_ref, RTL sharing: Sharing. (line 35) 44083* LABEL_REF_NONLOCAL_P: Flags. (line 65) 44084* lang_hooks.gimplify_expr: Gimplification pass. 44085 (line 18) 44086* lang_hooks.parse_file: Parsing pass. (line 6) 44087* language-dependent trees: Language-dependent trees. 44088 (line 6) 44089* language-independent intermediate representation: Parsing pass. 44090 (line 14) 44091* large return values: Aggregate Return. (line 6) 44092* LARGEST_EXPONENT_IS_NORMAL: Storage Layout. (line 474) 44093* LAST_STACK_REG: Stack Registers. (line 31) 44094* LAST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 44095* lceilMN2: Standard Names. (line 597) 44096* LCSSA: LCSSA. (line 6) 44097* LD_FINI_SWITCH: Macros for Initialization. 44098 (line 29) 44099* LD_INIT_SWITCH: Macros for Initialization. 44100 (line 25) 44101* LDD_SUFFIX: Macros for Initialization. 44102 (line 116) 44103* le: Comparisons. (line 76) 44104* le and attributes: Expressions. (line 64) 44105* LE_EXPR: Unary and Binary Expressions. 44106 (line 6) 44107* leaf functions: Leaf Functions. (line 6) 44108* leaf_function_p: Standard Names. (line 1003) 44109* LEAF_REG_REMAP: Leaf Functions. (line 39) 44110* LEAF_REGISTERS: Leaf Functions. (line 25) 44111* left rotate: Arithmetic. (line 190) 44112* left shift: Arithmetic. (line 168) 44113* LEGITIMATE_CONSTANT_P: Addressing Modes. (line 207) 44114* LEGITIMATE_PIC_OPERAND_P: PIC. (line 31) 44115* LEGITIMIZE_RELOAD_ADDRESS: Addressing Modes. (line 147) 44116* length: GTY Options. (line 50) 44117* less than: Comparisons. (line 68) 44118* less than or equal: Comparisons. (line 76) 44119* leu: Comparisons. (line 76) 44120* leu and attributes: Expressions. (line 64) 44121* lfloorMN2: Standard Names. (line 592) 44122* LIB2FUNCS_EXTRA: Target Fragment. (line 11) 44123* LIB_SPEC: Driver. (line 170) 44124* LIBCALL_VALUE: Scalar Return. (line 60) 44125* libgcc.a: Library Calls. (line 6) 44126* LIBGCC2_CFLAGS: Target Fragment. (line 8) 44127* LIBGCC2_HAS_DF_MODE: Type Layout. (line 109) 44128* LIBGCC2_HAS_TF_MODE: Type Layout. (line 123) 44129* LIBGCC2_HAS_XF_MODE: Type Layout. (line 117) 44130* LIBGCC2_LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 103) 44131* LIBGCC2_UNWIND_ATTRIBUTE: Misc. (line 982) 44132* LIBGCC2_WORDS_BIG_ENDIAN: Storage Layout. (line 36) 44133* LIBGCC_SPEC: Driver. (line 178) 44134* library subroutine names: Library Calls. (line 6) 44135* LIBRARY_PATH_ENV: Misc. (line 560) 44136* LIMIT_RELOAD_CLASS: Register Classes. (line 254) 44137* Linear loop transformations framework: Lambda. (line 6) 44138* LINK_COMMAND_SPEC: Driver. (line 299) 44139* LINK_EH_SPEC: Driver. (line 205) 44140* LINK_ELIMINATE_DUPLICATE_LDIRECTORIES: Driver. (line 309) 44141* LINK_GCC_C_SEQUENCE_SPEC: Driver. (line 295) 44142* LINK_LIBGCC_SPECIAL_1: Driver. (line 290) 44143* LINK_SPEC: Driver. (line 163) 44144* list: Containers. (line 6) 44145* Liveness representation: Liveness information. 44146 (line 6) 44147* lo_sum: Arithmetic. (line 24) 44148* load address instruction: Simple Constraints. (line 154) 44149* LOAD_EXTEND_OP: Misc. (line 69) 44150* load_multiple instruction pattern: Standard Names. (line 137) 44151* LOCAL_ALIGNMENT: Storage Layout. (line 255) 44152* LOCAL_CLASS_P: Classes. (line 73) 44153* LOCAL_DECL_ALIGNMENT: Storage Layout. (line 279) 44154* LOCAL_INCLUDE_DIR: Driver. (line 376) 44155* LOCAL_LABEL_PREFIX: Instruction Output. (line 138) 44156* LOCAL_REGNO: Register Basics. (line 105) 44157* LOG_LINKS: Insns. (line 317) 44158* Logical Operators: Logical Operators. (line 6) 44159* logical-and, bitwise: Arithmetic. (line 153) 44160* logM2 instruction pattern: Standard Names. (line 505) 44161* LONG_ACCUM_TYPE_SIZE: Type Layout. (line 93) 44162* LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 58) 44163* LONG_FRACT_TYPE_SIZE: Type Layout. (line 73) 44164* LONG_LONG_ACCUM_TYPE_SIZE: Type Layout. (line 98) 44165* LONG_LONG_FRACT_TYPE_SIZE: Type Layout. (line 78) 44166* LONG_LONG_TYPE_SIZE: Type Layout. (line 33) 44167* LONG_TYPE_SIZE: Type Layout. (line 22) 44168* longjmp and automatic variables: Interface. (line 52) 44169* Loop analysis: Loop representation. 44170 (line 6) 44171* Loop manipulation: Loop manipulation. (line 6) 44172* Loop querying: Loop querying. (line 6) 44173* Loop representation: Loop representation. 44174 (line 6) 44175* Loop-closed SSA form: LCSSA. (line 6) 44176* LOOP_ALIGN: Alignment Output. (line 35) 44177* LOOP_ALIGN_MAX_SKIP: Alignment Output. (line 48) 44178* LOOP_EXPR: Unary and Binary Expressions. 44179 (line 6) 44180* looping instruction patterns: Looping Patterns. (line 6) 44181* lowering, language-dependent intermediate representation: Parsing pass. 44182 (line 14) 44183* lrintMN2: Standard Names. (line 582) 44184* lroundMN2: Standard Names. (line 587) 44185* LSHIFT_EXPR: Unary and Binary Expressions. 44186 (line 6) 44187* lshiftrt: Arithmetic. (line 185) 44188* lshiftrt and attributes: Expressions. (line 64) 44189* lshrM3 instruction pattern: Standard Names. (line 441) 44190* lt: Comparisons. (line 68) 44191* lt and attributes: Expressions. (line 64) 44192* LT_EXPR: Unary and Binary Expressions. 44193 (line 6) 44194* LTGT_EXPR: Unary and Binary Expressions. 44195 (line 6) 44196* ltu: Comparisons. (line 68) 44197* m in constraint: Simple Constraints. (line 17) 44198* machine attributes: Target Attributes. (line 6) 44199* machine description macros: Target Macros. (line 6) 44200* machine descriptions: Machine Desc. (line 6) 44201* machine mode conversions: Conversions. (line 6) 44202* machine modes: Machine Modes. (line 6) 44203* machine specific constraints: Machine Constraints. 44204 (line 6) 44205* machine-independent predicates: Machine-Independent Predicates. 44206 (line 6) 44207* macros, target description: Target Macros. (line 6) 44208* maddMN4 instruction pattern: Standard Names. (line 364) 44209* MAKE_DECL_ONE_ONLY: Label Output. (line 218) 44210* make_phi_node: GIMPLE_PHI. (line 7) 44211* make_safe_from: Expander Definitions. 44212 (line 148) 44213* makefile fragment: Fragments. (line 6) 44214* makefile targets: Makefile. (line 6) 44215* MALLOC_ABI_ALIGNMENT: Storage Layout. (line 180) 44216* Manipulating GIMPLE statements: Manipulating GIMPLE statements. 44217 (line 6) 44218* mark_hook: GTY Options. (line 170) 44219* marking roots: GGC Roots. (line 6) 44220* MASK_RETURN_ADDR: Exception Region Output. 44221 (line 35) 44222* match_dup <1>: define_peephole2. (line 28) 44223* match_dup: RTL Template. (line 73) 44224* match_dup and attributes: Insn Lengths. (line 16) 44225* match_op_dup: RTL Template. (line 163) 44226* match_operand: RTL Template. (line 16) 44227* match_operand and attributes: Expressions. (line 55) 44228* match_operator: RTL Template. (line 95) 44229* match_par_dup: RTL Template. (line 219) 44230* match_parallel: RTL Template. (line 172) 44231* match_scratch <1>: define_peephole2. (line 28) 44232* match_scratch: RTL Template. (line 58) 44233* matching constraint: Simple Constraints. (line 132) 44234* matching operands: Output Template. (line 49) 44235* math library: Soft float library routines. 44236 (line 6) 44237* math, in RTL: Arithmetic. (line 6) 44238* MATH_LIBRARY: Misc. (line 553) 44239* matherr: Library Calls. (line 58) 44240* MAX_BITS_PER_WORD: Storage Layout. (line 61) 44241* MAX_CONDITIONAL_EXECUTE: Misc. (line 575) 44242* MAX_FIXED_MODE_SIZE: Storage Layout. (line 421) 44243* MAX_MOVE_MAX: Misc. (line 120) 44244* MAX_OFILE_ALIGNMENT: Storage Layout. (line 217) 44245* MAX_REGS_PER_ADDRESS: Addressing Modes. (line 43) 44246* MAX_STACK_ALIGNMENT: Storage Layout. (line 210) 44247* maxM3 instruction pattern: Standard Names. (line 234) 44248* may_trap_p, tree_could_trap_p: Edges. (line 115) 44249* maybe_undef: GTY Options. (line 178) 44250* mcount: Profiling. (line 12) 44251* MD_CAN_REDIRECT_BRANCH: Misc. (line 712) 44252* MD_EXEC_PREFIX: Driver. (line 330) 44253* MD_FALLBACK_FRAME_STATE_FOR: Exception Handling. (line 98) 44254* MD_HANDLE_UNWABI: Exception Handling. (line 118) 44255* MD_STARTFILE_PREFIX: Driver. (line 358) 44256* MD_STARTFILE_PREFIX_1: Driver. (line 364) 44257* MD_UNWIND_SUPPORT: Exception Handling. (line 94) 44258* mem: Regs and Memory. (line 374) 44259* mem and /c: Flags. (line 99) 44260* mem and /f: Flags. (line 103) 44261* mem and /i: Flags. (line 85) 44262* mem and /j: Flags. (line 79) 44263* mem and /s: Flags. (line 70) 44264* mem and /u: Flags. (line 152) 44265* mem and /v: Flags. (line 94) 44266* mem, RTL sharing: Sharing. (line 40) 44267* MEM_ADDR_SPACE: Special Accessors. (line 39) 44268* MEM_ALIAS_SET: Special Accessors. (line 9) 44269* MEM_ALIGN: Special Accessors. (line 36) 44270* MEM_EXPR: Special Accessors. (line 20) 44271* MEM_IN_STRUCT_P: Flags. (line 70) 44272* MEM_KEEP_ALIAS_SET_P: Flags. (line 79) 44273* MEM_NOTRAP_P: Flags. (line 99) 44274* MEM_OFFSET: Special Accessors. (line 28) 44275* MEM_POINTER: Flags. (line 103) 44276* MEM_READONLY_P: Flags. (line 152) 44277* MEM_SCALAR_P: Flags. (line 85) 44278* MEM_SIZE: Special Accessors. (line 31) 44279* MEM_VOLATILE_P: Flags. (line 94) 44280* MEMBER_TYPE_FORCES_BLK: Storage Layout. (line 401) 44281* memory model: Memory model. (line 6) 44282* memory reference, nonoffsettable: Simple Constraints. (line 246) 44283* memory references in constraints: Simple Constraints. (line 17) 44284* memory_barrier instruction pattern: Standard Names. (line 1385) 44285* MEMORY_MOVE_COST: Costs. (line 29) 44286* memory_operand: Machine-Independent Predicates. 44287 (line 58) 44288* METHOD_TYPE: Types. (line 6) 44289* MIN_UNITS_PER_WORD: Storage Layout. (line 71) 44290* MINIMUM_ALIGNMENT: Storage Layout. (line 289) 44291* MINIMUM_ATOMIC_ALIGNMENT: Storage Layout. (line 188) 44292* minM3 instruction pattern: Standard Names. (line 234) 44293* minus: Arithmetic. (line 36) 44294* minus and attributes: Expressions. (line 64) 44295* minus, canonicalization of: Insn Canonicalizations. 44296 (line 27) 44297* MINUS_EXPR: Unary and Binary Expressions. 44298 (line 6) 44299* MIPS coprocessor-definition macros: MIPS Coprocessors. (line 6) 44300* mod: Arithmetic. (line 131) 44301* mod and attributes: Expressions. (line 64) 44302* mode classes: Machine Modes. (line 219) 44303* mode iterators in .md files: Mode Iterators. (line 6) 44304* mode switching: Mode Switching. (line 6) 44305* MODE_ACCUM: Machine Modes. (line 249) 44306* MODE_AFTER: Mode Switching. (line 49) 44307* MODE_BASE_REG_CLASS: Register Classes. (line 112) 44308* MODE_BASE_REG_REG_CLASS: Register Classes. (line 118) 44309* MODE_CC <1>: MODE_CC Condition Codes. 44310 (line 6) 44311* MODE_CC: Machine Modes. (line 268) 44312* MODE_CODE_BASE_REG_CLASS: Register Classes. (line 125) 44313* MODE_COMPLEX_FLOAT: Machine Modes. (line 260) 44314* MODE_COMPLEX_INT: Machine Modes. (line 257) 44315* MODE_DECIMAL_FLOAT: Machine Modes. (line 237) 44316* MODE_ENTRY: Mode Switching. (line 54) 44317* MODE_EXIT: Mode Switching. (line 60) 44318* MODE_FLOAT: Machine Modes. (line 233) 44319* MODE_FRACT: Machine Modes. (line 241) 44320* MODE_FUNCTION: Machine Modes. (line 264) 44321* MODE_INT: Machine Modes. (line 225) 44322* MODE_NEEDED: Mode Switching. (line 42) 44323* MODE_PARTIAL_INT: Machine Modes. (line 229) 44324* MODE_PRIORITY_TO_MODE: Mode Switching. (line 66) 44325* MODE_RANDOM: Machine Modes. (line 273) 44326* MODE_UACCUM: Machine Modes. (line 253) 44327* MODE_UFRACT: Machine Modes. (line 245) 44328* MODES_TIEABLE_P: Values in Registers. 44329 (line 129) 44330* modifiers in constraints: Modifiers. (line 6) 44331* MODIFY_EXPR: Unary and Binary Expressions. 44332 (line 6) 44333* MODIFY_JNI_METHOD_CALL: Misc. (line 790) 44334* MODIFY_TARGET_NAME: Driver. (line 385) 44335* modM3 instruction pattern: Standard Names. (line 222) 44336* modulo scheduling: RTL passes. (line 131) 44337* MOVE_BY_PIECES_P: Costs. (line 113) 44338* MOVE_MAX: Misc. (line 115) 44339* MOVE_MAX_PIECES: Costs. (line 119) 44340* MOVE_RATIO: Costs. (line 97) 44341* movM instruction pattern: Standard Names. (line 11) 44342* movmemM instruction pattern: Standard Names. (line 654) 44343* movmisalignM instruction pattern: Standard Names. (line 126) 44344* movMODEcc instruction pattern: Standard Names. (line 877) 44345* movstr instruction pattern: Standard Names. (line 689) 44346* movstrictM instruction pattern: Standard Names. (line 120) 44347* msubMN4 instruction pattern: Standard Names. (line 387) 44348* mulhisi3 instruction pattern: Standard Names. (line 340) 44349* mulM3 instruction pattern: Standard Names. (line 222) 44350* mulqihi3 instruction pattern: Standard Names. (line 344) 44351* mulsidi3 instruction pattern: Standard Names. (line 344) 44352* mult: Arithmetic. (line 92) 44353* mult and attributes: Expressions. (line 64) 44354* mult, canonicalization of: Insn Canonicalizations. 44355 (line 27) 44356* MULT_EXPR: Unary and Binary Expressions. 44357 (line 6) 44358* MULTILIB_DEFAULTS: Driver. (line 315) 44359* MULTILIB_DIRNAMES: Target Fragment. (line 64) 44360* MULTILIB_EXCEPTIONS: Target Fragment. (line 84) 44361* MULTILIB_EXTRA_OPTS: Target Fragment. (line 96) 44362* MULTILIB_MATCHES: Target Fragment. (line 77) 44363* MULTILIB_OPTIONS: Target Fragment. (line 44) 44364* multiple alternative constraints: Multi-Alternative. (line 6) 44365* MULTIPLE_SYMBOL_SPACES: Misc. (line 533) 44366* multiplication: Arithmetic. (line 92) 44367* multiplication with signed saturation: Arithmetic. (line 92) 44368* multiplication with unsigned saturation: Arithmetic. (line 92) 44369* MUST_USE_SJLJ_EXCEPTIONS: Exception Region Output. 44370 (line 64) 44371* n in constraint: Simple Constraints. (line 65) 44372* N_REG_CLASSES: Register Classes. (line 76) 44373* name: Identifiers. (line 6) 44374* named address spaces: Named Address Spaces. 44375 (line 6) 44376* named patterns and conditions: Patterns. (line 47) 44377* names, pattern: Standard Names. (line 6) 44378* namespace, scope: Namespaces. (line 6) 44379* NAMESPACE_DECL <1>: Namespaces. (line 6) 44380* NAMESPACE_DECL: Declarations. (line 6) 44381* NATIVE_SYSTEM_HEADER_DIR: Target Fragment. (line 103) 44382* ne: Comparisons. (line 56) 44383* ne and attributes: Expressions. (line 64) 44384* NE_EXPR: Unary and Binary Expressions. 44385 (line 6) 44386* nearbyintM2 instruction pattern: Standard Names. (line 564) 44387* neg: Arithmetic. (line 81) 44388* neg and attributes: Expressions. (line 64) 44389* neg, canonicalization of: Insn Canonicalizations. 44390 (line 27) 44391* NEGATE_EXPR: Unary and Binary Expressions. 44392 (line 6) 44393* negation: Arithmetic. (line 81) 44394* negation with signed saturation: Arithmetic. (line 81) 44395* negation with unsigned saturation: Arithmetic. (line 81) 44396* negM2 instruction pattern: Standard Names. (line 449) 44397* nested functions, trampolines for: Trampolines. (line 6) 44398* nested_ptr: GTY Options. (line 185) 44399* next_bb, prev_bb, FOR_EACH_BB: Basic Blocks. (line 10) 44400* NEXT_INSN: Insns. (line 30) 44401* NEXT_OBJC_RUNTIME: Library Calls. (line 94) 44402* nil: RTL Objects. (line 73) 44403* NO_DBX_BNSYM_ENSYM: DBX Hooks. (line 39) 44404* NO_DBX_FUNCTION_END: DBX Hooks. (line 33) 44405* NO_DBX_GCC_MARKER: File Names and DBX. (line 28) 44406* NO_DBX_MAIN_SOURCE_DIRECTORY: File Names and DBX. (line 23) 44407* NO_DOLLAR_IN_LABEL: Misc. (line 497) 44408* NO_DOT_IN_LABEL: Misc. (line 503) 44409* NO_FUNCTION_CSE: Costs. (line 209) 44410* NO_IMPLICIT_EXTERN_C: Misc. (line 376) 44411* NO_PROFILE_COUNTERS: Profiling. (line 28) 44412* NO_REGS: Register Classes. (line 17) 44413* NON_LVALUE_EXPR: Unary and Binary Expressions. 44414 (line 6) 44415* nondeterministic finite state automaton: Processor pipeline description. 44416 (line 301) 44417* nonimmediate_operand: Machine-Independent Predicates. 44418 (line 101) 44419* nonlocal goto handler: Edges. (line 171) 44420* nonlocal_goto instruction pattern: Standard Names. (line 1225) 44421* nonlocal_goto_receiver instruction pattern: Standard Names. 44422 (line 1242) 44423* nonmemory_operand: Machine-Independent Predicates. 44424 (line 97) 44425* nonoffsettable memory reference: Simple Constraints. (line 246) 44426* nop instruction pattern: Standard Names. (line 1036) 44427* NOP_EXPR: Unary and Binary Expressions. 44428 (line 6) 44429* normal predicates: Predicates. (line 31) 44430* not: Arithmetic. (line 149) 44431* not and attributes: Expressions. (line 50) 44432* not equal: Comparisons. (line 56) 44433* not, canonicalization of: Insn Canonicalizations. 44434 (line 27) 44435* note: Insns. (line 168) 44436* note and /i: Flags. (line 59) 44437* note and /v: Flags. (line 44) 44438* NOTE_INSN_BASIC_BLOCK, CODE_LABEL, notes: Basic Blocks. (line 41) 44439* NOTE_INSN_BLOCK_BEG: Insns. (line 193) 44440* NOTE_INSN_BLOCK_END: Insns. (line 193) 44441* NOTE_INSN_DELETED: Insns. (line 183) 44442* NOTE_INSN_DELETED_LABEL: Insns. (line 188) 44443* NOTE_INSN_EH_REGION_BEG: Insns. (line 199) 44444* NOTE_INSN_EH_REGION_END: Insns. (line 199) 44445* NOTE_INSN_FUNCTION_BEG: Insns. (line 223) 44446* NOTE_INSN_LOOP_BEG: Insns. (line 207) 44447* NOTE_INSN_LOOP_CONT: Insns. (line 213) 44448* NOTE_INSN_LOOP_END: Insns. (line 207) 44449* NOTE_INSN_LOOP_VTOP: Insns. (line 217) 44450* NOTE_INSN_VAR_LOCATION: Insns. (line 227) 44451* NOTE_LINE_NUMBER: Insns. (line 168) 44452* NOTE_SOURCE_FILE: Insns. (line 168) 44453* NOTE_VAR_LOCATION: Insns. (line 227) 44454* NOTICE_UPDATE_CC: CC0 Condition Codes. 44455 (line 31) 44456* NUM_MACHINE_MODES: Machine Modes. (line 286) 44457* NUM_MODES_FOR_MODE_SWITCHING: Mode Switching. (line 30) 44458* Number of iterations analysis: Number of iterations. 44459 (line 6) 44460* o in constraint: Simple Constraints. (line 23) 44461* OBJC_GEN_METHOD_LABEL: Label Output. (line 412) 44462* OBJC_JBLEN: Misc. (line 977) 44463* OBJECT_FORMAT_COFF: Macros for Initialization. 44464 (line 97) 44465* OFFSET_TYPE: Types. (line 6) 44466* offsettable address: Simple Constraints. (line 23) 44467* OImode: Machine Modes. (line 51) 44468* Omega a solver for linear programming problems: Omega. (line 6) 44469* OMP_ATOMIC: OpenMP. (line 6) 44470* OMP_CLAUSE: OpenMP. (line 6) 44471* OMP_CONTINUE: OpenMP. (line 6) 44472* OMP_CRITICAL: OpenMP. (line 6) 44473* OMP_FOR: OpenMP. (line 6) 44474* OMP_MASTER: OpenMP. (line 6) 44475* OMP_ORDERED: OpenMP. (line 6) 44476* OMP_PARALLEL: OpenMP. (line 6) 44477* OMP_RETURN: OpenMP. (line 6) 44478* OMP_SECTION: OpenMP. (line 6) 44479* OMP_SECTIONS: OpenMP. (line 6) 44480* OMP_SINGLE: OpenMP. (line 6) 44481* one_cmplM2 instruction pattern: Standard Names. (line 651) 44482* operand access: Accessors. (line 6) 44483* Operand Access Routines: SSA Operands. (line 119) 44484* operand constraints: Constraints. (line 6) 44485* Operand Iterators: SSA Operands. (line 119) 44486* operand predicates: Predicates. (line 6) 44487* operand substitution: Output Template. (line 6) 44488* operands <1>: Patterns. (line 53) 44489* operands: SSA Operands. (line 6) 44490* Operands: Operands. (line 6) 44491* operator predicates: Predicates. (line 6) 44492* optc-gen.awk: Options. (line 6) 44493* Optimization infrastructure for GIMPLE: Tree SSA. (line 6) 44494* OPTIMIZATION_OPTIONS: Run-time Target. (line 134) 44495* OPTIMIZE_MODE_SWITCHING: Mode Switching. (line 9) 44496* option specification files: Options. (line 6) 44497* OPTION_DEFAULT_SPECS: Driver. (line 88) 44498* optional hardware or system features: Run-time Target. (line 59) 44499* options, directory search: Including Patterns. (line 44) 44500* order of register allocation: Allocation Order. (line 6) 44501* ORDER_REGS_FOR_LOCAL_ALLOC: Allocation Order. (line 23) 44502* ordered_comparison_operator: Machine-Independent Predicates. 44503 (line 116) 44504* ORDERED_EXPR: Unary and Binary Expressions. 44505 (line 6) 44506* Ordering of Patterns: Pattern Ordering. (line 6) 44507* ORIGINAL_REGNO: Special Accessors. (line 44) 44508* other register constraints: Simple Constraints. (line 163) 44509* OUTGOING_REG_PARM_STACK_SPACE: Stack Arguments. (line 71) 44510* OUTGOING_REGNO: Register Basics. (line 98) 44511* output of assembler code: File Framework. (line 6) 44512* output statements: Output Statement. (line 6) 44513* output templates: Output Template. (line 6) 44514* OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 39) 44515* output_asm_insn: Output Statement. (line 53) 44516* OUTPUT_QUOTED_STRING: File Framework. (line 93) 44517* OVERLOAD: Functions for C++. (line 6) 44518* OVERRIDE_ABI_FORMAT: Register Arguments. (line 140) 44519* OVERRIDE_OPTIONS: Run-time Target. (line 105) 44520* OVL_CURRENT: Functions for C++. (line 6) 44521* OVL_NEXT: Functions for C++. (line 6) 44522* p in constraint: Simple Constraints. (line 154) 44523* PAD_VARARGS_DOWN: Register Arguments. (line 220) 44524* parallel: Side Effects. (line 204) 44525* param_is: GTY Options. (line 113) 44526* parameters, c++ abi: C++ ABI. (line 6) 44527* parameters, miscellaneous: Misc. (line 6) 44528* parameters, precompiled headers: PCH Target. (line 6) 44529* paramN_is: GTY Options. (line 131) 44530* parity: Arithmetic. (line 232) 44531* parityM2 instruction pattern: Standard Names. (line 645) 44532* PARM_BOUNDARY: Storage Layout. (line 145) 44533* PARM_DECL: Declarations. (line 6) 44534* PARSE_LDD_OUTPUT: Macros for Initialization. 44535 (line 121) 44536* passes and files of the compiler: Passes. (line 6) 44537* passing arguments: Interface. (line 36) 44538* PATH_SEPARATOR: Filesystem. (line 31) 44539* PATTERN: Insns. (line 288) 44540* pattern conditions: Patterns. (line 43) 44541* pattern names: Standard Names. (line 6) 44542* Pattern Ordering: Pattern Ordering. (line 6) 44543* patterns: Patterns. (line 6) 44544* pc: Regs and Memory. (line 361) 44545* pc and attributes: Insn Lengths. (line 20) 44546* pc, RTL sharing: Sharing. (line 25) 44547* PC_REGNUM: Register Basics. (line 112) 44548* pc_rtx: Regs and Memory. (line 366) 44549* PCC_BITFIELD_TYPE_MATTERS: Storage Layout. (line 315) 44550* PCC_STATIC_STRUCT_RETURN: Aggregate Return. (line 65) 44551* PDImode: Machine Modes. (line 40) 44552* peephole optimization, RTL representation: Side Effects. (line 238) 44553* peephole optimizer definitions: Peephole Definitions. 44554 (line 6) 44555* per-function data: Per-Function Data. (line 6) 44556* percent sign: Output Template. (line 6) 44557* PHI nodes: SSA. (line 31) 44558* phi_arg_d: GIMPLE_PHI. (line 28) 44559* PHI_ARG_DEF: SSA. (line 71) 44560* PHI_ARG_EDGE: SSA. (line 68) 44561* PHI_ARG_ELT: SSA. (line 63) 44562* PHI_NUM_ARGS: SSA. (line 59) 44563* PHI_RESULT: SSA. (line 56) 44564* PIC: PIC. (line 6) 44565* PIC_OFFSET_TABLE_REG_CALL_CLOBBERED: PIC. (line 26) 44566* PIC_OFFSET_TABLE_REGNUM: PIC. (line 16) 44567* pipeline hazard recognizer: Processor pipeline description. 44568 (line 6) 44569* Plugins: Plugins. (line 6) 44570* plus: Arithmetic. (line 14) 44571* plus and attributes: Expressions. (line 64) 44572* plus, canonicalization of: Insn Canonicalizations. 44573 (line 27) 44574* PLUS_EXPR: Unary and Binary Expressions. 44575 (line 6) 44576* Pmode: Misc. (line 344) 44577* pmode_register_operand: Machine-Independent Predicates. 44578 (line 35) 44579* pointer: Types. (line 6) 44580* POINTER_PLUS_EXPR: Unary and Binary Expressions. 44581 (line 6) 44582* POINTER_SIZE: Storage Layout. (line 83) 44583* POINTER_TYPE: Types. (line 6) 44584* POINTERS_EXTEND_UNSIGNED: Storage Layout. (line 89) 44585* pop_operand: Machine-Independent Predicates. 44586 (line 88) 44587* popcount: Arithmetic. (line 228) 44588* popcountM2 instruction pattern: Standard Names. (line 639) 44589* portability: Portability. (line 6) 44590* position independent code: PIC. (line 6) 44591* post_dec: Incdec. (line 25) 44592* post_inc: Incdec. (line 30) 44593* post_modify: Incdec. (line 33) 44594* POSTDECREMENT_EXPR: Unary and Binary Expressions. 44595 (line 6) 44596* POSTINCREMENT_EXPR: Unary and Binary Expressions. 44597 (line 6) 44598* POWI_MAX_MULTS: Misc. (line 845) 44599* powM3 instruction pattern: Standard Names. (line 513) 44600* pragma: Misc. (line 381) 44601* pre_dec: Incdec. (line 8) 44602* PRE_GCC3_DWARF_FRAME_REGISTERS: Frame Registers. (line 113) 44603* pre_inc: Incdec. (line 22) 44604* pre_modify: Incdec. (line 51) 44605* PREDECREMENT_EXPR: Unary and Binary Expressions. 44606 (line 6) 44607* predefined macros: Run-time Target. (line 6) 44608* predicates: Predicates. (line 6) 44609* predicates and machine modes: Predicates. (line 31) 44610* predication <1>: Cond. Exec. Macros. (line 6) 44611* predication: Conditional Execution. 44612 (line 6) 44613* predict.def: Profile information. 44614 (line 24) 44615* PREFERRED_DEBUGGING_TYPE: All Debuggers. (line 42) 44616* PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 246) 44617* PREFERRED_RELOAD_CLASS: Register Classes. (line 211) 44618* PREFERRED_STACK_BOUNDARY: Storage Layout. (line 159) 44619* prefetch: Side Effects. (line 312) 44620* prefetch and /v: Flags. (line 232) 44621* prefetch instruction pattern: Standard Names. (line 1364) 44622* PREFETCH_SCHEDULE_BARRIER_P: Flags. (line 232) 44623* PREINCREMENT_EXPR: Unary and Binary Expressions. 44624 (line 6) 44625* presence_set: Processor pipeline description. 44626 (line 220) 44627* preserving SSA form: SSA. (line 76) 44628* preserving virtual SSA form: SSA. (line 186) 44629* prev_active_insn: define_peephole. (line 60) 44630* PREV_INSN: Insns. (line 26) 44631* PRINT_OPERAND: Instruction Output. (line 81) 44632* PRINT_OPERAND_ADDRESS: Instruction Output. (line 109) 44633* PRINT_OPERAND_PUNCT_VALID_P: Instruction Output. (line 102) 44634* probe_stack instruction pattern: Standard Names. (line 1217) 44635* processor functional units: Processor pipeline description. 44636 (line 6) 44637* processor pipeline description: Processor pipeline description. 44638 (line 6) 44639* product: Arithmetic. (line 92) 44640* profile feedback: Profile information. 44641 (line 14) 44642* profile representation: Profile information. 44643 (line 6) 44644* PROFILE_BEFORE_PROLOGUE: Profiling. (line 35) 44645* PROFILE_HOOK: Profiling. (line 23) 44646* profiling, code generation: Profiling. (line 6) 44647* program counter: Regs and Memory. (line 362) 44648* prologue: Function Entry. (line 6) 44649* prologue instruction pattern: Standard Names. (line 1308) 44650* PROMOTE_MODE: Storage Layout. (line 100) 44651* pseudo registers: Regs and Memory. (line 9) 44652* PSImode: Machine Modes. (line 32) 44653* PTRDIFF_TYPE: Type Layout. (line 184) 44654* purge_dead_edges <1>: Maintaining the CFG. 44655 (line 93) 44656* purge_dead_edges: Edges. (line 104) 44657* push address instruction: Simple Constraints. (line 154) 44658* PUSH_ARGS: Stack Arguments. (line 18) 44659* PUSH_ARGS_REVERSED: Stack Arguments. (line 26) 44660* push_operand: Machine-Independent Predicates. 44661 (line 81) 44662* push_reload: Addressing Modes. (line 171) 44663* PUSH_ROUNDING: Stack Arguments. (line 32) 44664* pushM1 instruction pattern: Standard Names. (line 209) 44665* PUT_CODE: RTL Objects. (line 47) 44666* PUT_MODE: Machine Modes. (line 283) 44667* PUT_REG_NOTE_KIND: Insns. (line 350) 44668* PUT_SDB_: SDB and DWARF. (line 69) 44669* QCmode: Machine Modes. (line 197) 44670* QFmode: Machine Modes. (line 54) 44671* QImode: Machine Modes. (line 25) 44672* QImode, in insn: Insns. (line 272) 44673* QQmode: Machine Modes. (line 103) 44674* qualified type <1>: Types for C++. (line 6) 44675* qualified type: Types. (line 6) 44676* querying function unit reservations: Processor pipeline description. 44677 (line 90) 44678* question mark: Multi-Alternative. (line 41) 44679* quotient: Arithmetic. (line 111) 44680* r in constraint: Simple Constraints. (line 56) 44681* RANGE_TEST_NON_SHORT_CIRCUIT: Costs. (line 213) 44682* RDIV_EXPR: Unary and Binary Expressions. 44683 (line 6) 44684* READONLY_DATA_SECTION_ASM_OP: Sections. (line 63) 44685* real operands: SSA Operands. (line 6) 44686* REAL_ARITHMETIC: Floating Point. (line 66) 44687* REAL_CST: Constant expressions. 44688 (line 6) 44689* REAL_LIBGCC_SPEC: Driver. (line 187) 44690* REAL_NM_FILE_NAME: Macros for Initialization. 44691 (line 106) 44692* REAL_TYPE: Types. (line 6) 44693* REAL_VALUE_ABS: Floating Point. (line 82) 44694* REAL_VALUE_ATOF: Floating Point. (line 50) 44695* REAL_VALUE_FIX: Floating Point. (line 41) 44696* REAL_VALUE_FROM_INT: Floating Point. (line 99) 44697* REAL_VALUE_ISINF: Floating Point. (line 59) 44698* REAL_VALUE_ISNAN: Floating Point. (line 62) 44699* REAL_VALUE_NEGATE: Floating Point. (line 79) 44700* REAL_VALUE_NEGATIVE: Floating Point. (line 56) 44701* REAL_VALUE_TO_INT: Floating Point. (line 93) 44702* REAL_VALUE_TO_TARGET_DECIMAL128: Data Output. (line 144) 44703* REAL_VALUE_TO_TARGET_DECIMAL32: Data Output. (line 142) 44704* REAL_VALUE_TO_TARGET_DECIMAL64: Data Output. (line 143) 44705* REAL_VALUE_TO_TARGET_DOUBLE: Data Output. (line 140) 44706* REAL_VALUE_TO_TARGET_LONG_DOUBLE: Data Output. (line 141) 44707* REAL_VALUE_TO_TARGET_SINGLE: Data Output. (line 139) 44708* REAL_VALUE_TRUNCATE: Floating Point. (line 86) 44709* REAL_VALUE_TYPE: Floating Point. (line 26) 44710* REAL_VALUE_UNSIGNED_FIX: Floating Point. (line 45) 44711* REAL_VALUES_EQUAL: Floating Point. (line 32) 44712* REAL_VALUES_LESS: Floating Point. (line 38) 44713* REALPART_EXPR: Unary and Binary Expressions. 44714 (line 6) 44715* recog_data.operand: Instruction Output. (line 39) 44716* recognizing insns: RTL Template. (line 6) 44717* RECORD_TYPE <1>: Classes. (line 6) 44718* RECORD_TYPE: Types. (line 6) 44719* redirect_edge_and_branch: Profile information. 44720 (line 71) 44721* redirect_edge_and_branch, redirect_jump: Maintaining the CFG. 44722 (line 103) 44723* reduc_smax_M instruction pattern: Standard Names. (line 240) 44724* reduc_smin_M instruction pattern: Standard Names. (line 240) 44725* reduc_splus_M instruction pattern: Standard Names. (line 252) 44726* reduc_umax_M instruction pattern: Standard Names. (line 246) 44727* reduc_umin_M instruction pattern: Standard Names. (line 246) 44728* reduc_uplus_M instruction pattern: Standard Names. (line 258) 44729* reference: Types. (line 6) 44730* REFERENCE_TYPE: Types. (line 6) 44731* reg: Regs and Memory. (line 9) 44732* reg and /f: Flags. (line 112) 44733* reg and /i: Flags. (line 107) 44734* reg and /v: Flags. (line 116) 44735* reg, RTL sharing: Sharing. (line 17) 44736* REG_ALLOC_ORDER: Allocation Order. (line 9) 44737* REG_BR_PRED: Insns. (line 531) 44738* REG_BR_PROB: Insns. (line 525) 44739* REG_BR_PROB_BASE, BB_FREQ_BASE, count: Profile information. 44740 (line 82) 44741* REG_BR_PROB_BASE, EDGE_FREQUENCY: Profile information. 44742 (line 52) 44743* REG_CC_SETTER: Insns. (line 496) 44744* REG_CC_USER: Insns. (line 496) 44745* REG_CLASS_CONTENTS: Register Classes. (line 86) 44746* reg_class_contents: Register Basics. (line 59) 44747* REG_CLASS_FROM_CONSTRAINT: Old Constraints. (line 35) 44748* REG_CLASS_FROM_LETTER: Old Constraints. (line 27) 44749* REG_CLASS_NAMES: Register Classes. (line 81) 44750* REG_CROSSING_JUMP: Insns. (line 409) 44751* REG_DEAD: Insns. (line 361) 44752* REG_DEAD, REG_UNUSED: Liveness information. 44753 (line 32) 44754* REG_DEP_ANTI: Insns. (line 518) 44755* REG_DEP_OUTPUT: Insns. (line 514) 44756* REG_DEP_TRUE: Insns. (line 511) 44757* REG_EH_REGION, EDGE_ABNORMAL_CALL: Edges. (line 110) 44758* REG_EQUAL: Insns. (line 424) 44759* REG_EQUIV: Insns. (line 424) 44760* REG_EXPR: Special Accessors. (line 50) 44761* REG_FRAME_RELATED_EXPR: Insns. (line 537) 44762* REG_FUNCTION_VALUE_P: Flags. (line 107) 44763* REG_INC: Insns. (line 377) 44764* reg_label and /v: Flags. (line 65) 44765* REG_LABEL_OPERAND: Insns. (line 391) 44766* REG_LABEL_TARGET: Insns. (line 400) 44767* reg_names <1>: Instruction Output. (line 93) 44768* reg_names: Register Basics. (line 59) 44769* REG_NONNEG: Insns. (line 383) 44770* REG_NOTE_KIND: Insns. (line 350) 44771* REG_NOTES: Insns. (line 324) 44772* REG_OFFSET: Special Accessors. (line 54) 44773* REG_OK_STRICT: Register Classes. (line 148) 44774* REG_PARM_STACK_SPACE: Stack Arguments. (line 56) 44775* REG_PARM_STACK_SPACE, and FUNCTION_ARG: Register Arguments. 44776 (line 52) 44777* REG_POINTER: Flags. (line 112) 44778* REG_SETJMP: Insns. (line 418) 44779* REG_UNUSED: Insns. (line 370) 44780* REG_USERVAR_P: Flags. (line 116) 44781* regclass_for_constraint: C Constraint Interface. 44782 (line 60) 44783* register allocation order: Allocation Order. (line 6) 44784* register class definitions: Register Classes. (line 6) 44785* register class preference constraints: Class Preferences. (line 6) 44786* register pairs: Values in Registers. 44787 (line 69) 44788* Register Transfer Language (RTL): RTL. (line 6) 44789* register usage: Registers. (line 6) 44790* REGISTER_MOVE_COST: Costs. (line 10) 44791* REGISTER_NAMES: Instruction Output. (line 9) 44792* register_operand: Machine-Independent Predicates. 44793 (line 30) 44794* REGISTER_PREFIX: Instruction Output. (line 137) 44795* REGISTER_TARGET_PRAGMAS: Misc. (line 382) 44796* registers arguments: Register Arguments. (line 6) 44797* registers in constraints: Simple Constraints. (line 56) 44798* REGMODE_NATURAL_SIZE: Values in Registers. 44799 (line 50) 44800* REGNO_MODE_CODE_OK_FOR_BASE_P: Register Classes. (line 181) 44801* REGNO_MODE_OK_FOR_BASE_P: Register Classes. (line 154) 44802* REGNO_MODE_OK_FOR_REG_BASE_P: Register Classes. (line 166) 44803* REGNO_OK_FOR_BASE_P: Register Classes. (line 140) 44804* REGNO_OK_FOR_INDEX_P: Register Classes. (line 194) 44805* REGNO_REG_CLASS: Register Classes. (line 101) 44806* regs_ever_live: Function Entry. (line 21) 44807* regular expressions: Processor pipeline description. 44808 (line 6) 44809* relative costs: Costs. (line 6) 44810* RELATIVE_PREFIX_NOT_LINKDIR: Driver. (line 325) 44811* reload_completed: Standard Names. (line 1003) 44812* reload_in instruction pattern: Standard Names. (line 99) 44813* reload_in_progress: Standard Names. (line 57) 44814* reload_out instruction pattern: Standard Names. (line 99) 44815* reloading: RTL passes. (line 182) 44816* remainder: Arithmetic. (line 131) 44817* remainderM3 instruction pattern: Standard Names. (line 472) 44818* reorder: GTY Options. (line 209) 44819* representation of RTL: RTL. (line 6) 44820* reservation delays: Processor pipeline description. 44821 (line 6) 44822* rest_of_decl_compilation: Parsing pass. (line 52) 44823* rest_of_type_compilation: Parsing pass. (line 52) 44824* restore_stack_block instruction pattern: Standard Names. (line 1137) 44825* restore_stack_function instruction pattern: Standard Names. 44826 (line 1137) 44827* restore_stack_nonlocal instruction pattern: Standard Names. 44828 (line 1137) 44829* RESULT_DECL: Declarations. (line 6) 44830* return: Side Effects. (line 72) 44831* return instruction pattern: Standard Names. (line 990) 44832* return values in registers: Scalar Return. (line 6) 44833* RETURN_ADDR_IN_PREVIOUS_FRAME: Frame Layout. (line 135) 44834* RETURN_ADDR_OFFSET: Exception Handling. (line 60) 44835* RETURN_ADDR_RTX: Frame Layout. (line 124) 44836* RETURN_ADDRESS_POINTER_REGNUM: Frame Registers. (line 51) 44837* RETURN_EXPR: Statements for C++. (line 6) 44838* RETURN_POPS_ARGS: Stack Arguments. (line 90) 44839* RETURN_STMT: Statements for C++. (line 6) 44840* return_val: Flags. (line 299) 44841* return_val, in call_insn: Flags. (line 24) 44842* return_val, in mem: Flags. (line 85) 44843* return_val, in reg: Flags. (line 107) 44844* return_val, in symbol_ref: Flags. (line 220) 44845* returning aggregate values: Aggregate Return. (line 6) 44846* returning structures and unions: Interface. (line 10) 44847* reverse probability: Profile information. 44848 (line 66) 44849* REVERSE_CONDEXEC_PREDICATES_P: Cond. Exec. Macros. (line 11) 44850* REVERSE_CONDITION: MODE_CC Condition Codes. 44851 (line 87) 44852* REVERSIBLE_CC_MODE: MODE_CC Condition Codes. 44853 (line 73) 44854* right rotate: Arithmetic. (line 190) 44855* right shift: Arithmetic. (line 185) 44856* rintM2 instruction pattern: Standard Names. (line 572) 44857* RISC: Processor pipeline description. 44858 (line 6) 44859* roots, marking: GGC Roots. (line 6) 44860* rotate: Arithmetic. (line 190) 44861* rotatert: Arithmetic. (line 190) 44862* rotlM3 instruction pattern: Standard Names. (line 441) 44863* rotrM3 instruction pattern: Standard Names. (line 441) 44864* ROUND_DIV_EXPR: Unary and Binary Expressions. 44865 (line 6) 44866* ROUND_MOD_EXPR: Unary and Binary Expressions. 44867 (line 6) 44868* ROUND_TOWARDS_ZERO: Storage Layout. (line 465) 44869* ROUND_TYPE_ALIGN: Storage Layout. (line 412) 44870* roundM2 instruction pattern: Standard Names. (line 548) 44871* RSHIFT_EXPR: Unary and Binary Expressions. 44872 (line 6) 44873* RTL addition: Arithmetic. (line 14) 44874* RTL addition with signed saturation: Arithmetic. (line 14) 44875* RTL addition with unsigned saturation: Arithmetic. (line 14) 44876* RTL classes: RTL Classes. (line 6) 44877* RTL comparison: Arithmetic. (line 43) 44878* RTL comparison operations: Comparisons. (line 6) 44879* RTL constant expression types: Constants. (line 6) 44880* RTL constants: Constants. (line 6) 44881* RTL declarations: RTL Declarations. (line 6) 44882* RTL difference: Arithmetic. (line 36) 44883* RTL expression: RTL Objects. (line 6) 44884* RTL expressions for arithmetic: Arithmetic. (line 6) 44885* RTL format: RTL Classes. (line 71) 44886* RTL format characters: RTL Classes. (line 76) 44887* RTL function-call insns: Calls. (line 6) 44888* RTL insn template: RTL Template. (line 6) 44889* RTL integers: RTL Objects. (line 6) 44890* RTL memory expressions: Regs and Memory. (line 6) 44891* RTL object types: RTL Objects. (line 6) 44892* RTL postdecrement: Incdec. (line 6) 44893* RTL postincrement: Incdec. (line 6) 44894* RTL predecrement: Incdec. (line 6) 44895* RTL preincrement: Incdec. (line 6) 44896* RTL register expressions: Regs and Memory. (line 6) 44897* RTL representation: RTL. (line 6) 44898* RTL side effect expressions: Side Effects. (line 6) 44899* RTL strings: RTL Objects. (line 6) 44900* RTL structure sharing assumptions: Sharing. (line 6) 44901* RTL subtraction: Arithmetic. (line 36) 44902* RTL subtraction with signed saturation: Arithmetic. (line 36) 44903* RTL subtraction with unsigned saturation: Arithmetic. (line 36) 44904* RTL sum: Arithmetic. (line 14) 44905* RTL vectors: RTL Objects. (line 6) 44906* RTL_CONST_CALL_P: Flags. (line 19) 44907* RTL_CONST_OR_PURE_CALL_P: Flags. (line 29) 44908* RTL_LOOPING_CONST_OR_PURE_CALL_P: Flags. (line 33) 44909* RTL_PURE_CALL_P: Flags. (line 24) 44910* RTX (See RTL): RTL Objects. (line 6) 44911* RTX codes, classes of: RTL Classes. (line 6) 44912* RTX_FRAME_RELATED_P: Flags. (line 125) 44913* run-time conventions: Interface. (line 6) 44914* run-time target specification: Run-time Target. (line 6) 44915* s in constraint: Simple Constraints. (line 92) 44916* same_type_p: Types. (line 88) 44917* SAmode: Machine Modes. (line 148) 44918* sat_fract: Conversions. (line 90) 44919* satfractMN2 instruction pattern: Standard Names. (line 829) 44920* satfractunsMN2 instruction pattern: Standard Names. (line 842) 44921* satisfies_constraint_: C Constraint Interface. 44922 (line 47) 44923* SAVE_EXPR: Unary and Binary Expressions. 44924 (line 6) 44925* save_stack_block instruction pattern: Standard Names. (line 1137) 44926* save_stack_function instruction pattern: Standard Names. (line 1137) 44927* save_stack_nonlocal instruction pattern: Standard Names. (line 1137) 44928* SBSS_SECTION_ASM_OP: Sections. (line 77) 44929* Scalar evolutions: Scalar evolutions. (line 6) 44930* scalars, returned as values: Scalar Return. (line 6) 44931* SCHED_GROUP_P: Flags. (line 166) 44932* SCmode: Machine Modes. (line 197) 44933* scratch: Regs and Memory. (line 298) 44934* scratch operands: Regs and Memory. (line 298) 44935* scratch, RTL sharing: Sharing. (line 35) 44936* scratch_operand: Machine-Independent Predicates. 44937 (line 50) 44938* SDATA_SECTION_ASM_OP: Sections. (line 58) 44939* SDB_ALLOW_FORWARD_REFERENCES: SDB and DWARF. (line 87) 44940* SDB_ALLOW_UNKNOWN_REFERENCES: SDB and DWARF. (line 82) 44941* SDB_DEBUGGING_INFO: SDB and DWARF. (line 9) 44942* SDB_DELIM: SDB and DWARF. (line 75) 44943* SDB_OUTPUT_SOURCE_LINE: SDB and DWARF. (line 92) 44944* SDmode: Machine Modes. (line 85) 44945* sdot_prodM instruction pattern: Standard Names. (line 264) 44946* search options: Including Patterns. (line 44) 44947* SECONDARY_INPUT_RELOAD_CLASS: Register Classes. (line 350) 44948* SECONDARY_MEMORY_NEEDED: Register Classes. (line 406) 44949* SECONDARY_MEMORY_NEEDED_MODE: Register Classes. (line 425) 44950* SECONDARY_MEMORY_NEEDED_RTX: Register Classes. (line 416) 44951* SECONDARY_OUTPUT_RELOAD_CLASS: Register Classes. (line 351) 44952* SECONDARY_RELOAD_CLASS: Register Classes. (line 349) 44953* SELECT_CC_MODE: MODE_CC Condition Codes. 44954 (line 7) 44955* sequence: Side Effects. (line 254) 44956* Sequence iterators: Sequence iterators. (line 6) 44957* set: Side Effects. (line 15) 44958* set and /f: Flags. (line 125) 44959* SET_ASM_OP: Label Output. (line 379) 44960* set_attr: Tagging Insns. (line 31) 44961* set_attr_alternative: Tagging Insns. (line 49) 44962* set_bb_seq: GIMPLE sequences. (line 76) 44963* SET_BY_PIECES_P: Costs. (line 154) 44964* SET_DEST: Side Effects. (line 69) 44965* SET_IS_RETURN_P: Flags. (line 175) 44966* SET_LABEL_KIND: Insns. (line 140) 44967* set_optab_libfunc: Library Calls. (line 15) 44968* SET_RATIO: Costs. (line 142) 44969* SET_SRC: Side Effects. (line 69) 44970* SET_TYPE_STRUCTURAL_EQUALITY: Types. (line 6) 44971* setmemM instruction pattern: Standard Names. (line 697) 44972* SETUP_FRAME_ADDRESSES: Frame Layout. (line 102) 44973* SF_SIZE: Type Layout. (line 129) 44974* SFmode: Machine Modes. (line 66) 44975* sharing of RTL components: Sharing. (line 6) 44976* shift: Arithmetic. (line 168) 44977* SHIFT_COUNT_TRUNCATED: Misc. (line 127) 44978* SHLIB_SUFFIX: Macros for Initialization. 44979 (line 129) 44980* SHORT_ACCUM_TYPE_SIZE: Type Layout. (line 83) 44981* SHORT_FRACT_TYPE_SIZE: Type Layout. (line 63) 44982* SHORT_IMMEDIATES_SIGN_EXTEND: Misc. (line 96) 44983* SHORT_TYPE_SIZE: Type Layout. (line 16) 44984* sibcall_epilogue instruction pattern: Standard Names. (line 1334) 44985* sibling call: Edges. (line 122) 44986* SIBLING_CALL_P: Flags. (line 179) 44987* SIG_ATOMIC_TYPE: Type Layout. (line 235) 44988* sign_extend: Conversions. (line 23) 44989* sign_extract: Bit-Fields. (line 8) 44990* sign_extract, canonicalization of: Insn Canonicalizations. 44991 (line 88) 44992* signed division: Arithmetic. (line 111) 44993* signed division with signed saturation: Arithmetic. (line 111) 44994* signed maximum: Arithmetic. (line 136) 44995* signed minimum: Arithmetic. (line 136) 44996* SImode: Machine Modes. (line 37) 44997* simple constraints: Simple Constraints. (line 6) 44998* sincos math function, implicit usage: Library Calls. (line 84) 44999* sinM2 instruction pattern: Standard Names. (line 489) 45000* SIZE_ASM_OP: Label Output. (line 23) 45001* SIZE_TYPE: Type Layout. (line 168) 45002* skip: GTY Options. (line 76) 45003* SLOW_BYTE_ACCESS: Costs. (line 66) 45004* SLOW_UNALIGNED_ACCESS: Costs. (line 81) 45005* SMALL_REGISTER_CLASSES: Register Classes. (line 448) 45006* smax: Arithmetic. (line 136) 45007* smin: Arithmetic. (line 136) 45008* sms, swing, software pipelining: RTL passes. (line 131) 45009* smulM3_highpart instruction pattern: Standard Names. (line 356) 45010* soft float library: Soft float library routines. 45011 (line 6) 45012* special: GTY Options. (line 229) 45013* special predicates: Predicates. (line 31) 45014* SPECS: Target Fragment. (line 108) 45015* speed of instructions: Costs. (line 6) 45016* split_block: Maintaining the CFG. 45017 (line 110) 45018* splitting instructions: Insn Splitting. (line 6) 45019* SQmode: Machine Modes. (line 111) 45020* sqrt: Arithmetic. (line 202) 45021* sqrtM2 instruction pattern: Standard Names. (line 455) 45022* square root: Arithmetic. (line 202) 45023* ss_abs: Arithmetic. (line 195) 45024* ss_ashift: Arithmetic. (line 168) 45025* ss_div: Arithmetic. (line 111) 45026* ss_minus: Arithmetic. (line 36) 45027* ss_mult: Arithmetic. (line 92) 45028* ss_neg: Arithmetic. (line 81) 45029* ss_plus: Arithmetic. (line 14) 45030* ss_truncate: Conversions. (line 43) 45031* SSA: SSA. (line 6) 45032* SSA_NAME_DEF_STMT: SSA. (line 221) 45033* SSA_NAME_VERSION: SSA. (line 226) 45034* ssaddM3 instruction pattern: Standard Names. (line 222) 45035* ssashlM3 instruction pattern: Standard Names. (line 431) 45036* ssdivM3 instruction pattern: Standard Names. (line 222) 45037* ssmaddMN4 instruction pattern: Standard Names. (line 379) 45038* ssmsubMN4 instruction pattern: Standard Names. (line 403) 45039* ssmulM3 instruction pattern: Standard Names. (line 222) 45040* ssnegM2 instruction pattern: Standard Names. (line 449) 45041* sssubM3 instruction pattern: Standard Names. (line 222) 45042* ssum_widenM3 instruction pattern: Standard Names. (line 274) 45043* stack arguments: Stack Arguments. (line 6) 45044* stack frame layout: Frame Layout. (line 6) 45045* stack smashing protection: Stack Smashing Protection. 45046 (line 6) 45047* STACK_ALIGNMENT_NEEDED: Frame Layout. (line 48) 45048* STACK_BOUNDARY: Storage Layout. (line 151) 45049* STACK_CHECK_BUILTIN: Stack Checking. (line 32) 45050* STACK_CHECK_FIXED_FRAME_SIZE: Stack Checking. (line 83) 45051* STACK_CHECK_MAX_FRAME_SIZE: Stack Checking. (line 74) 45052* STACK_CHECK_MAX_VAR_SIZE: Stack Checking. (line 90) 45053* STACK_CHECK_MOVING_SP: Stack Checking. (line 54) 45054* STACK_CHECK_PROBE_INTERVAL_EXP: Stack Checking. (line 46) 45055* STACK_CHECK_PROTECT: Stack Checking. (line 63) 45056* STACK_CHECK_STATIC_BUILTIN: Stack Checking. (line 39) 45057* STACK_DYNAMIC_OFFSET: Frame Layout. (line 75) 45058* STACK_DYNAMIC_OFFSET and virtual registers: Regs and Memory. 45059 (line 83) 45060* STACK_GROWS_DOWNWARD: Frame Layout. (line 9) 45061* STACK_PARMS_IN_REG_PARM_AREA: Stack Arguments. (line 81) 45062* STACK_POINTER_OFFSET: Frame Layout. (line 58) 45063* STACK_POINTER_OFFSET and virtual registers: Regs and Memory. 45064 (line 93) 45065* STACK_POINTER_REGNUM: Frame Registers. (line 9) 45066* STACK_POINTER_REGNUM and virtual registers: Regs and Memory. 45067 (line 83) 45068* stack_pointer_rtx: Frame Registers. (line 90) 45069* stack_protect_set instruction pattern: Standard Names. (line 1505) 45070* stack_protect_test instruction pattern: Standard Names. (line 1515) 45071* STACK_PUSH_CODE: Frame Layout. (line 17) 45072* STACK_REG_COVER_CLASS: Stack Registers. (line 23) 45073* STACK_REGS: Stack Registers. (line 20) 45074* STACK_SAVEAREA_MODE: Storage Layout. (line 428) 45075* STACK_SIZE_MODE: Storage Layout. (line 440) 45076* STACK_SLOT_ALIGNMENT: Storage Layout. (line 266) 45077* standard pattern names: Standard Names. (line 6) 45078* STANDARD_INCLUDE_COMPONENT: Driver. (line 425) 45079* STANDARD_INCLUDE_DIR: Driver. (line 417) 45080* STANDARD_STARTFILE_PREFIX: Driver. (line 337) 45081* STANDARD_STARTFILE_PREFIX_1: Driver. (line 344) 45082* STANDARD_STARTFILE_PREFIX_2: Driver. (line 351) 45083* STARTFILE_SPEC: Driver. (line 210) 45084* STARTING_FRAME_OFFSET: Frame Layout. (line 39) 45085* STARTING_FRAME_OFFSET and virtual registers: Regs and Memory. 45086 (line 74) 45087* Statement and operand traversals: Statement and operand traversals. 45088 (line 6) 45089* Statement Sequences: Statement Sequences. 45090 (line 6) 45091* statements <1>: Statements for C++. (line 6) 45092* statements: Function Properties. 45093 (line 6) 45094* Statements: Statements. (line 6) 45095* Static profile estimation: Profile information. 45096 (line 24) 45097* static single assignment: SSA. (line 6) 45098* STATIC_CHAIN_INCOMING_REGNUM: Frame Registers. (line 64) 45099* STATIC_CHAIN_REGNUM: Frame Registers. (line 63) 45100* stdarg.h and register arguments: Register Arguments. (line 47) 45101* STDC_0_IN_SYSTEM_HEADERS: Misc. (line 365) 45102* STMT_EXPR: Unary and Binary Expressions. 45103 (line 6) 45104* STMT_IS_FULL_EXPR_P: Statements for C++. (line 22) 45105* storage layout: Storage Layout. (line 6) 45106* STORE_BY_PIECES_P: Costs. (line 161) 45107* STORE_FLAG_VALUE: Misc. (line 216) 45108* store_multiple instruction pattern: Standard Names. (line 160) 45109* strcpy: Storage Layout. (line 236) 45110* STRICT_ALIGNMENT: Storage Layout. (line 310) 45111* strict_low_part: RTL Declarations. (line 9) 45112* strict_memory_address_p: Addressing Modes. (line 181) 45113* STRING_CST: Constant expressions. 45114 (line 6) 45115* STRING_POOL_ADDRESS_P: Flags. (line 183) 45116* strlenM instruction pattern: Standard Names. (line 764) 45117* structure value address: Aggregate Return. (line 6) 45118* STRUCTURE_SIZE_BOUNDARY: Storage Layout. (line 302) 45119* structures, returning: Interface. (line 10) 45120* subM3 instruction pattern: Standard Names. (line 222) 45121* SUBOBJECT: Statements for C++. (line 6) 45122* SUBOBJECT_CLEANUP: Statements for C++. (line 6) 45123* subreg: Regs and Memory. (line 97) 45124* subreg and /s: Flags. (line 205) 45125* subreg and /u: Flags. (line 198) 45126* subreg and /u and /v: Flags. (line 188) 45127* subreg, in strict_low_part: RTL Declarations. (line 9) 45128* SUBREG_BYTE: Regs and Memory. (line 289) 45129* SUBREG_PROMOTED_UNSIGNED_P: Flags. (line 188) 45130* SUBREG_PROMOTED_UNSIGNED_SET: Flags. (line 198) 45131* SUBREG_PROMOTED_VAR_P: Flags. (line 205) 45132* SUBREG_REG: Regs and Memory. (line 289) 45133* SUCCESS_EXIT_CODE: Host Misc. (line 12) 45134* SUPPORTS_INIT_PRIORITY: Macros for Initialization. 45135 (line 58) 45136* SUPPORTS_ONE_ONLY: Label Output. (line 227) 45137* SUPPORTS_WEAK: Label Output. (line 208) 45138* SWITCH_BODY: Statements for C++. (line 6) 45139* SWITCH_COND: Statements for C++. (line 6) 45140* SWITCH_CURTAILS_COMPILATION: Driver. (line 33) 45141* SWITCH_STMT: Statements for C++. (line 6) 45142* SWITCH_TAKES_ARG: Driver. (line 9) 45143* SWITCHES_NEED_SPACES: Driver. (line 47) 45144* SYMBOL_FLAG_ANCHOR: Special Accessors. (line 110) 45145* SYMBOL_FLAG_EXTERNAL: Special Accessors. (line 92) 45146* SYMBOL_FLAG_FUNCTION: Special Accessors. (line 85) 45147* SYMBOL_FLAG_HAS_BLOCK_INFO: Special Accessors. (line 106) 45148* SYMBOL_FLAG_LOCAL: Special Accessors. (line 88) 45149* SYMBOL_FLAG_SMALL: Special Accessors. (line 97) 45150* SYMBOL_FLAG_TLS_SHIFT: Special Accessors. (line 101) 45151* symbol_ref: Constants. (line 76) 45152* symbol_ref and /f: Flags. (line 183) 45153* symbol_ref and /i: Flags. (line 220) 45154* symbol_ref and /u: Flags. (line 10) 45155* symbol_ref and /v: Flags. (line 224) 45156* symbol_ref, RTL sharing: Sharing. (line 20) 45157* SYMBOL_REF_ANCHOR_P: Special Accessors. (line 110) 45158* SYMBOL_REF_BLOCK: Special Accessors. (line 123) 45159* SYMBOL_REF_BLOCK_OFFSET: Special Accessors. (line 128) 45160* SYMBOL_REF_CONSTANT: Special Accessors. (line 71) 45161* SYMBOL_REF_DATA: Special Accessors. (line 75) 45162* SYMBOL_REF_DECL: Special Accessors. (line 59) 45163* SYMBOL_REF_EXTERNAL_P: Special Accessors. (line 92) 45164* SYMBOL_REF_FLAG: Flags. (line 224) 45165* SYMBOL_REF_FLAG, in TARGET_ENCODE_SECTION_INFO: Sections. (line 269) 45166* SYMBOL_REF_FLAGS: Special Accessors. (line 79) 45167* SYMBOL_REF_FUNCTION_P: Special Accessors. (line 85) 45168* SYMBOL_REF_HAS_BLOCK_INFO_P: Special Accessors. (line 106) 45169* SYMBOL_REF_LOCAL_P: Special Accessors. (line 88) 45170* SYMBOL_REF_SMALL_P: Special Accessors. (line 97) 45171* SYMBOL_REF_TLS_MODEL: Special Accessors. (line 101) 45172* SYMBOL_REF_USED: Flags. (line 215) 45173* SYMBOL_REF_WEAK: Flags. (line 220) 45174* symbolic label: Sharing. (line 20) 45175* sync_addMODE instruction pattern: Standard Names. (line 1421) 45176* sync_andMODE instruction pattern: Standard Names. (line 1421) 45177* sync_compare_and_swapMODE instruction pattern: Standard Names. 45178 (line 1391) 45179* sync_iorMODE instruction pattern: Standard Names. (line 1421) 45180* sync_lock_releaseMODE instruction pattern: Standard Names. (line 1486) 45181* sync_lock_test_and_setMODE instruction pattern: Standard Names. 45182 (line 1460) 45183* sync_nandMODE instruction pattern: Standard Names. (line 1421) 45184* sync_new_addMODE instruction pattern: Standard Names. (line 1453) 45185* sync_new_andMODE instruction pattern: Standard Names. (line 1453) 45186* sync_new_iorMODE instruction pattern: Standard Names. (line 1453) 45187* sync_new_nandMODE instruction pattern: Standard Names. (line 1453) 45188* sync_new_subMODE instruction pattern: Standard Names. (line 1453) 45189* sync_new_xorMODE instruction pattern: Standard Names. (line 1453) 45190* sync_old_addMODE instruction pattern: Standard Names. (line 1436) 45191* sync_old_andMODE instruction pattern: Standard Names. (line 1436) 45192* sync_old_iorMODE instruction pattern: Standard Names. (line 1436) 45193* sync_old_nandMODE instruction pattern: Standard Names. (line 1436) 45194* sync_old_subMODE instruction pattern: Standard Names. (line 1436) 45195* sync_old_xorMODE instruction pattern: Standard Names. (line 1436) 45196* sync_subMODE instruction pattern: Standard Names. (line 1421) 45197* sync_xorMODE instruction pattern: Standard Names. (line 1421) 45198* SYSROOT_HEADERS_SUFFIX_SPEC: Driver. (line 239) 45199* SYSROOT_SUFFIX_SPEC: Driver. (line 234) 45200* SYSTEM_INCLUDE_DIR: Driver. (line 408) 45201* t-TARGET: Target Fragment. (line 6) 45202* table jump: Basic Blocks. (line 57) 45203* tablejump instruction pattern: Standard Names. (line 1065) 45204* tag: GTY Options. (line 81) 45205* tagging insns: Tagging Insns. (line 6) 45206* tail calls: Tail Calls. (line 6) 45207* TAmode: Machine Modes. (line 156) 45208* target attributes: Target Attributes. (line 6) 45209* target description macros: Target Macros. (line 6) 45210* target functions: Target Structure. (line 6) 45211* target hooks: Target Structure. (line 6) 45212* target makefile fragment: Target Fragment. (line 6) 45213* target specifications: Run-time Target. (line 6) 45214* TARGET_ADDR_SPACE_ADDRESS_MODE: Named Address Spaces. 45215 (line 47) 45216* TARGET_ADDR_SPACE_CONVERT: Named Address Spaces. 45217 (line 90) 45218* TARGET_ADDR_SPACE_KEYWORDS: Named Address Spaces. 45219 (line 30) 45220* TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P: Named Address Spaces. 45221 (line 65) 45222* TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS: Named Address Spaces. 45223 (line 74) 45224* TARGET_ADDR_SPACE_POINTER_MODE: Named Address Spaces. 45225 (line 40) 45226* TARGET_ADDR_SPACE_SUBSET_P: Named Address Spaces. 45227 (line 81) 45228* TARGET_ADDR_SPACE_VALID_POINTER_MODE: Named Address Spaces. 45229 (line 54) 45230* TARGET_ADDRESS_COST: Costs. (line 245) 45231* TARGET_ALIGN_ANON_BITFIELD: Storage Layout. (line 387) 45232* TARGET_ALLOCATE_INITIAL_VALUE: Misc. (line 727) 45233* TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS: Misc. (line 999) 45234* TARGET_ARG_PARTIAL_BYTES: Register Arguments. (line 83) 45235* TARGET_ARM_EABI_UNWINDER: Exception Region Output. 45236 (line 113) 45237* TARGET_ASM_ALIGNED_DI_OP: Data Output. (line 10) 45238* TARGET_ASM_ALIGNED_HI_OP: Data Output. (line 8) 45239* TARGET_ASM_ALIGNED_SI_OP: Data Output. (line 9) 45240* TARGET_ASM_ALIGNED_TI_OP: Data Output. (line 11) 45241* TARGET_ASM_ASSEMBLE_VISIBILITY: Label Output. (line 239) 45242* TARGET_ASM_BYTE_OP: Data Output. (line 7) 45243* TARGET_ASM_CAN_OUTPUT_MI_THUNK: Function Entry. (line 237) 45244* TARGET_ASM_CLOSE_PAREN: Data Output. (line 130) 45245* TARGET_ASM_CODE_END: File Framework. (line 59) 45246* TARGET_ASM_CONSTRUCTOR: Macros for Initialization. 45247 (line 69) 45248* TARGET_ASM_DESTRUCTOR: Macros for Initialization. 45249 (line 83) 45250* TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL: Dispatch Tables. (line 74) 45251* TARGET_ASM_EMIT_UNWIND_LABEL: Dispatch Tables. (line 63) 45252* TARGET_ASM_EXTERNAL_LIBCALL: Label Output. (line 274) 45253* TARGET_ASM_FILE_END: File Framework. (line 37) 45254* TARGET_ASM_FILE_START: File Framework. (line 9) 45255* TARGET_ASM_FILE_START_APP_OFF: File Framework. (line 17) 45256* TARGET_ASM_FILE_START_FILE_DIRECTIVE: File Framework. (line 31) 45257* TARGET_ASM_FINAL_POSTSCAN_INSN: Instruction Output. (line 69) 45258* TARGET_ASM_FUNCTION_BEGIN_EPILOGUE: Function Entry. (line 61) 45259* TARGET_ASM_FUNCTION_END_PROLOGUE: Function Entry. (line 55) 45260* TARGET_ASM_FUNCTION_EPILOGUE: Function Entry. (line 68) 45261* TARGET_ASM_FUNCTION_PROLOGUE: Function Entry. (line 11) 45262* TARGET_ASM_FUNCTION_RODATA_SECTION: Sections. (line 216) 45263* TARGET_ASM_GLOBALIZE_DECL_NAME: Label Output. (line 174) 45264* TARGET_ASM_GLOBALIZE_LABEL: Label Output. (line 165) 45265* TARGET_ASM_INIT_SECTIONS: Sections. (line 161) 45266* TARGET_ASM_INTEGER: Data Output. (line 27) 45267* TARGET_ASM_INTERNAL_LABEL: Label Output. (line 310) 45268* TARGET_ASM_LTO_END: File Framework. (line 54) 45269* TARGET_ASM_LTO_START: File Framework. (line 49) 45270* TARGET_ASM_MARK_DECL_PRESERVED: Label Output. (line 281) 45271* TARGET_ASM_NAMED_SECTION: File Framework. (line 106) 45272* TARGET_ASM_OPEN_PAREN: Data Output. (line 129) 45273* TARGET_ASM_OUTPUT_ANCHOR: Anchored Addresses. (line 44) 45274* TARGET_ASM_OUTPUT_DWARF_DTPREL: SDB and DWARF. (line 64) 45275* TARGET_ASM_OUTPUT_MI_THUNK: Function Entry. (line 195) 45276* TARGET_ASM_RECORD_GCC_SWITCHES: File Framework. (line 136) 45277* TARGET_ASM_RECORD_GCC_SWITCHES_SECTION: File Framework. (line 180) 45278* TARGET_ASM_RELOC_RW_MASK: Sections. (line 170) 45279* TARGET_ASM_SELECT_RTX_SECTION: Sections. (line 224) 45280* TARGET_ASM_SELECT_SECTION: Sections. (line 182) 45281* TARGET_ASM_TRAMPOLINE_TEMPLATE: Trampolines. (line 29) 45282* TARGET_ASM_TTYPE: Exception Region Output. 45283 (line 107) 45284* TARGET_ASM_UNALIGNED_DI_OP: Data Output. (line 14) 45285* TARGET_ASM_UNALIGNED_HI_OP: Data Output. (line 12) 45286* TARGET_ASM_UNALIGNED_SI_OP: Data Output. (line 13) 45287* TARGET_ASM_UNALIGNED_TI_OP: Data Output. (line 15) 45288* TARGET_ASM_UNIQUE_SECTION: Sections. (line 203) 45289* TARGET_ATTRIBUTE_TABLE: Target Attributes. (line 11) 45290* TARGET_BINDS_LOCAL_P: Sections. (line 294) 45291* TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED: Misc. (line 825) 45292* TARGET_BRANCH_TARGET_REGISTER_CLASS: Misc. (line 817) 45293* TARGET_BUILD_BUILTIN_VA_LIST: Register Arguments. (line 263) 45294* TARGET_BUILTIN_DECL: Misc. (line 660) 45295* TARGET_BUILTIN_RECIPROCAL: Addressing Modes. (line 242) 45296* TARGET_BUILTIN_SETJMP_FRAME_VALUE: Frame Layout. (line 109) 45297* TARGET_C99_FUNCTIONS: Library Calls. (line 77) 45298* TARGET_CALLEE_COPIES: Register Arguments. (line 115) 45299* TARGET_CAN_ELIMINATE: Elimination. (line 75) 45300* TARGET_CAN_INLINE_P: Target Attributes. (line 128) 45301* TARGET_CANNOT_FORCE_CONST_MEM: Addressing Modes. (line 223) 45302* TARGET_CANNOT_MODIFY_JUMPS_P: Misc. (line 803) 45303* TARGET_CANONICAL_VA_LIST_TYPE: Register Arguments. (line 272) 45304* TARGET_CASE_VALUES_THRESHOLD: Misc. (line 47) 45305* TARGET_CC_MODES_COMPATIBLE: MODE_CC Condition Codes. 45306 (line 116) 45307* TARGET_CHECK_PCH_TARGET_FLAGS: PCH Target. (line 28) 45308* TARGET_COMMUTATIVE_P: Misc. (line 720) 45309* TARGET_COMP_TYPE_ATTRIBUTES: Target Attributes. (line 19) 45310* TARGET_CONST_ANCHOR: Misc. (line 1010) 45311* TARGET_CONVERT_TO_TYPE: Misc. (line 963) 45312* TARGET_CPU_CPP_BUILTINS: Run-time Target. (line 9) 45313* TARGET_CXX_ADJUST_CLASS_AT_DEFINITION: C++ ABI. (line 87) 45314* TARGET_CXX_CDTOR_RETURNS_THIS: C++ ABI. (line 38) 45315* TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT: C++ ABI. (line 62) 45316* TARGET_CXX_COOKIE_HAS_SIZE: C++ ABI. (line 25) 45317* TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY: C++ ABI. (line 54) 45318* TARGET_CXX_GET_COOKIE_SIZE: C++ ABI. (line 18) 45319* TARGET_CXX_GUARD_MASK_BIT: C++ ABI. (line 12) 45320* TARGET_CXX_GUARD_TYPE: C++ ABI. (line 7) 45321* TARGET_CXX_IMPORT_EXPORT_CLASS: C++ ABI. (line 30) 45322* TARGET_CXX_KEY_METHOD_MAY_BE_INLINE: C++ ABI. (line 43) 45323* TARGET_CXX_LIBRARY_RTTI_COMDAT: C++ ABI. (line 69) 45324* TARGET_CXX_USE_AEABI_ATEXIT: C++ ABI. (line 74) 45325* TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT: C++ ABI. (line 80) 45326* TARGET_DECIMAL_FLOAT_SUPPORTED_P: Storage Layout. (line 512) 45327* TARGET_DECLSPEC: Target Attributes. (line 65) 45328* TARGET_DEFAULT_PACK_STRUCT: Misc. (line 485) 45329* TARGET_DEFAULT_SHORT_ENUMS: Type Layout. (line 160) 45330* TARGET_DEFAULT_TARGET_FLAGS: Run-time Target. (line 56) 45331* TARGET_DEFERRED_OUTPUT_DEFS: Label Output. (line 394) 45332* TARGET_DELEGITIMIZE_ADDRESS: Addressing Modes. (line 214) 45333* TARGET_DLLIMPORT_DECL_ATTRIBUTES: Target Attributes. (line 47) 45334* TARGET_DWARF_CALLING_CONVENTION: SDB and DWARF. (line 18) 45335* TARGET_DWARF_HANDLE_FRAME_UNSPEC: Frame Layout. (line 172) 45336* TARGET_DWARF_REGISTER_SPAN: Exception Region Output. 45337 (line 90) 45338* TARGET_EDOM: Library Calls. (line 59) 45339* TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS: Emulated TLS. (line 68) 45340* TARGET_EMUTLS_GET_ADDRESS: Emulated TLS. (line 19) 45341* TARGET_EMUTLS_REGISTER_COMMON: Emulated TLS. (line 24) 45342* TARGET_EMUTLS_TMPL_PREFIX: Emulated TLS. (line 45) 45343* TARGET_EMUTLS_TMPL_SECTION: Emulated TLS. (line 36) 45344* TARGET_EMUTLS_VAR_ALIGN_FIXED: Emulated TLS. (line 63) 45345* TARGET_EMUTLS_VAR_FIELDS: Emulated TLS. (line 49) 45346* TARGET_EMUTLS_VAR_INIT: Emulated TLS. (line 57) 45347* TARGET_EMUTLS_VAR_PREFIX: Emulated TLS. (line 41) 45348* TARGET_EMUTLS_VAR_SECTION: Emulated TLS. (line 31) 45349* TARGET_ENCODE_SECTION_INFO: Sections. (line 245) 45350* TARGET_ENCODE_SECTION_INFO and address validation: Addressing Modes. 45351 (line 83) 45352* TARGET_ENCODE_SECTION_INFO usage: Instruction Output. (line 113) 45353* TARGET_ENUM_VA_LIST: Scalar Return. (line 96) 45354* TARGET_EXECUTABLE_SUFFIX: Misc. (line 777) 45355* TARGET_EXPAND_BUILTIN: Misc. (line 670) 45356* TARGET_EXPAND_BUILTIN_SAVEREGS: Varargs. (line 92) 45357* TARGET_EXPAND_TO_RTL_HOOK: Storage Layout. (line 518) 45358* TARGET_EXPR: Unary and Binary Expressions. 45359 (line 6) 45360* TARGET_EXTRA_INCLUDES: Misc. (line 856) 45361* TARGET_EXTRA_LIVE_ON_ENTRY: Tail Calls. (line 21) 45362* TARGET_EXTRA_PRE_INCLUDES: Misc. (line 863) 45363* TARGET_FIXED_CONDITION_CODE_REGS: MODE_CC Condition Codes. 45364 (line 101) 45365* TARGET_FIXED_POINT_SUPPORTED_P: Storage Layout. (line 515) 45366* target_flags: Run-time Target. (line 52) 45367* TARGET_FLT_EVAL_METHOD: Type Layout. (line 141) 45368* TARGET_FN_ABI_VA_LIST: Register Arguments. (line 267) 45369* TARGET_FOLD_BUILTIN: Misc. (line 691) 45370* TARGET_FORMAT_TYPES: Misc. (line 883) 45371* TARGET_FRAME_POINTER_REQUIRED: Elimination. (line 9) 45372* TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes. (line 87) 45373* TARGET_FUNCTION_OK_FOR_SIBCALL: Tail Calls. (line 8) 45374* TARGET_FUNCTION_VALUE: Scalar Return. (line 11) 45375* TARGET_GET_DRAP_RTX: Misc. (line 993) 45376* TARGET_GET_PCH_VALIDITY: PCH Target. (line 7) 45377* TARGET_GIMPLIFY_VA_ARG_EXPR: Register Arguments. (line 278) 45378* TARGET_HANDLE_C_OPTION: Run-time Target. (line 78) 45379* TARGET_HANDLE_OPTION: Run-time Target. (line 61) 45380* TARGET_HANDLE_PRAGMA_EXTERN_PREFIX: Misc. (line 482) 45381* TARGET_HARD_REGNO_SCRATCH_OK: Values in Registers. 45382 (line 144) 45383* TARGET_HAS_SINCOS: Library Calls. (line 85) 45384* TARGET_HAVE_CONDITIONAL_EXECUTION: Misc. (line 839) 45385* TARGET_HAVE_CTORS_DTORS: Macros for Initialization. 45386 (line 64) 45387* TARGET_HAVE_NAMED_SECTIONS: File Framework. (line 113) 45388* TARGET_HAVE_SRODATA_SECTION: Sections. (line 290) 45389* TARGET_HAVE_SWITCHABLE_BSS_SECTIONS: File Framework. (line 117) 45390* TARGET_HAVE_TLS: Sections. (line 303) 45391* TARGET_HELP: Run-time Target. (line 154) 45392* TARGET_IN_SMALL_DATA_P: Sections. (line 286) 45393* TARGET_INIT_BUILTINS: Misc. (line 642) 45394* TARGET_INIT_DWARF_REG_SIZES_EXTRA: Exception Region Output. 45395 (line 99) 45396* TARGET_INIT_LIBFUNCS: Library Calls. (line 16) 45397* TARGET_INSERT_ATTRIBUTES: Target Attributes. (line 74) 45398* TARGET_INSTANTIATE_DECLS: Storage Layout. (line 526) 45399* TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN: Misc. (line 917) 45400* TARGET_INVALID_BINARY_OP: Misc. (line 936) 45401* TARGET_INVALID_CONVERSION: Misc. (line 923) 45402* TARGET_INVALID_PARAMETER_TYPE: Misc. (line 942) 45403* TARGET_INVALID_RETURN_TYPE: Misc. (line 949) 45404* TARGET_INVALID_UNARY_OP: Misc. (line 929) 45405* TARGET_INVALID_WITHIN_DOLOOP: Misc. (line 700) 45406* TARGET_IRA_COVER_CLASSES: Register Classes. (line 511) 45407* TARGET_LEGITIMATE_ADDRESS_P: Addressing Modes. (line 50) 45408* TARGET_LEGITIMIZE_ADDRESS: Addressing Modes. (line 128) 45409* TARGET_LIB_INT_CMP_BIASED: Library Calls. (line 35) 45410* TARGET_LIBCALL_VALUE: Scalar Return. (line 69) 45411* TARGET_LIBGCC_CMP_RETURN_MODE: Storage Layout. (line 449) 45412* TARGET_LIBGCC_SDATA_SECTION: Sections. (line 133) 45413* TARGET_LIBGCC_SHIFT_COUNT_MODE: Storage Layout. (line 455) 45414* TARGET_MACHINE_DEPENDENT_REORG: Misc. (line 627) 45415* TARGET_MANGLE_DECL_ASSEMBLER_NAME: Sections. (line 235) 45416* TARGET_MANGLE_TYPE: Storage Layout. (line 530) 45417* TARGET_MAX_ANCHOR_OFFSET: Anchored Addresses. (line 39) 45418* TARGET_MD_ASM_CLOBBERS: Misc. (line 543) 45419* TARGET_MEM_CONSTRAINT: Addressing Modes. (line 105) 45420* TARGET_MEM_REF: Storage References. (line 6) 45421* TARGET_MERGE_DECL_ATTRIBUTES: Target Attributes. (line 39) 45422* TARGET_MERGE_TYPE_ATTRIBUTES: Target Attributes. (line 31) 45423* TARGET_MIN_ANCHOR_OFFSET: Anchored Addresses. (line 33) 45424* TARGET_MIN_DIVISIONS_FOR_RECIP_MUL: Misc. (line 106) 45425* TARGET_MODE_REP_EXTENDED: Misc. (line 191) 45426* TARGET_MS_BITFIELD_LAYOUT_P: Storage Layout. (line 485) 45427* TARGET_MUST_PASS_IN_STACK: Register Arguments. (line 62) 45428* TARGET_MUST_PASS_IN_STACK, and FUNCTION_ARG: Register Arguments. 45429 (line 52) 45430* TARGET_N_FORMAT_TYPES: Misc. (line 888) 45431* TARGET_NARROW_VOLATILE_BITFIELD: Storage Layout. (line 393) 45432* TARGET_OBJECT_SUFFIX: Misc. (line 772) 45433* TARGET_OBJFMT_CPP_BUILTINS: Run-time Target. (line 46) 45434* TARGET_OPTF: Misc. (line 870) 45435* TARGET_OPTION_PRAGMA_PARSE: Target Attributes. (line 122) 45436* TARGET_OPTION_PRINT: Target Attributes. (line 117) 45437* TARGET_OPTION_RESTORE: Target Attributes. (line 111) 45438* TARGET_OPTION_SAVE: Target Attributes. (line 105) 45439* TARGET_OPTION_TRANSLATE_TABLE: Driver. (line 53) 45440* TARGET_OPTION_VALID_ATTRIBUTE_P: Target Attributes. (line 94) 45441* TARGET_OS_CPP_BUILTINS: Run-time Target. (line 42) 45442* TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE: Run-time Target. (line 119) 45443* TARGET_OVERRIDES_FORMAT_ATTRIBUTES: Misc. (line 892) 45444* TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT: Misc. (line 898) 45445* TARGET_OVERRIDES_FORMAT_INIT: Misc. (line 902) 45446* TARGET_PASS_BY_REFERENCE: Register Arguments. (line 103) 45447* TARGET_PCH_VALID_P: PCH Target. (line 13) 45448* TARGET_POSIX_IO: Misc. (line 567) 45449* TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs. (line 153) 45450* TARGET_PROMOTE_FUNCTION_MODE: Storage Layout. (line 125) 45451* TARGET_PROMOTE_PROTOTYPES: Stack Arguments. (line 11) 45452* TARGET_PROMOTED_TYPE: Misc. (line 955) 45453* TARGET_PTRMEMFUNC_VBIT_LOCATION: Type Layout. (line 278) 45454* TARGET_RELAXED_ORDERING: Misc. (line 907) 45455* TARGET_RESOLVE_OVERLOADED_BUILTIN: Misc. (line 680) 45456* TARGET_RETURN_IN_MEMORY: Aggregate Return. (line 17) 45457* TARGET_RETURN_IN_MSB: Scalar Return. (line 112) 45458* TARGET_RTX_COSTS: Costs. (line 219) 45459* TARGET_SCALAR_MODE_SUPPORTED_P: Register Arguments. (line 290) 45460* TARGET_SCHED_ADJUST_COST: Scheduling. (line 37) 45461* TARGET_SCHED_ADJUST_PRIORITY: Scheduling. (line 52) 45462* TARGET_SCHED_ALLOC_SCHED_CONTEXT: Scheduling. (line 243) 45463* TARGET_SCHED_CLEAR_SCHED_CONTEXT: Scheduling. (line 258) 45464* TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling. (line 89) 45465* TARGET_SCHED_DFA_NEW_CYCLE: Scheduling. (line 204) 45466* TARGET_SCHED_DFA_POST_ADVANCE_CYCLE: Scheduling. (line 160) 45467* TARGET_SCHED_DFA_POST_CYCLE_INSN: Scheduling. (line 144) 45468* TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE: Scheduling. (line 153) 45469* TARGET_SCHED_DFA_PRE_CYCLE_INSN: Scheduling. (line 132) 45470* TARGET_SCHED_FINISH: Scheduling. (line 109) 45471* TARGET_SCHED_FINISH_GLOBAL: Scheduling. (line 126) 45472* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling. 45473 (line 168) 45474* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling. 45475 (line 196) 45476* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC: Scheduling. 45477 (line 297) 45478* TARGET_SCHED_FREE_SCHED_CONTEXT: Scheduling. (line 262) 45479* TARGET_SCHED_GEN_SPEC_CHECK: Scheduling. (line 284) 45480* TARGET_SCHED_H_I_D_EXTENDED: Scheduling. (line 238) 45481* TARGET_SCHED_INIT: Scheduling. (line 99) 45482* TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling. (line 149) 45483* TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN: Scheduling. (line 141) 45484* TARGET_SCHED_INIT_GLOBAL: Scheduling. (line 118) 45485* TARGET_SCHED_INIT_SCHED_CONTEXT: Scheduling. (line 248) 45486* TARGET_SCHED_IS_COSTLY_DEPENDENCE: Scheduling. (line 215) 45487* TARGET_SCHED_ISSUE_RATE: Scheduling. (line 12) 45488* TARGET_SCHED_NEEDS_BLOCK_P: Scheduling. (line 277) 45489* TARGET_SCHED_REORDER: Scheduling. (line 60) 45490* TARGET_SCHED_REORDER2: Scheduling. (line 77) 45491* TARGET_SCHED_SET_SCHED_CONTEXT: Scheduling. (line 254) 45492* TARGET_SCHED_SET_SCHED_FLAGS: Scheduling. (line 309) 45493* TARGET_SCHED_SMS_RES_MII: Scheduling. (line 315) 45494* TARGET_SCHED_SPECULATE_INSN: Scheduling. (line 266) 45495* TARGET_SCHED_VARIABLE_ISSUE: Scheduling. (line 24) 45496* TARGET_SECONDARY_RELOAD: Register Classes. (line 272) 45497* TARGET_SECTION_TYPE_FLAGS: File Framework. (line 123) 45498* TARGET_SET_CURRENT_FUNCTION: Misc. (line 754) 45499* TARGET_SET_DEFAULT_TYPE_ATTRIBUTES: Target Attributes. (line 26) 45500* TARGET_SETUP_INCOMING_VARARGS: Varargs. (line 101) 45501* TARGET_SHIFT_TRUNCATION_MASK: Misc. (line 154) 45502* TARGET_SPLIT_COMPLEX_ARG: Register Arguments. (line 251) 45503* TARGET_STACK_PROTECT_FAIL: Stack Smashing Protection. 45504 (line 17) 45505* TARGET_STACK_PROTECT_GUARD: Stack Smashing Protection. 45506 (line 7) 45507* TARGET_STATIC_CHAIN: Frame Registers. (line 78) 45508* TARGET_STRICT_ARGUMENT_NAMING: Varargs. (line 137) 45509* TARGET_STRIP_NAME_ENCODING: Sections. (line 282) 45510* TARGET_STRUCT_VALUE_RTX: Aggregate Return. (line 45) 45511* TARGET_SUPPORT_VECTOR_MISALIGNMENT: Addressing Modes. (line 345) 45512* TARGET_TERMINATE_DW2_EH_FRAME_INFO: Exception Region Output. 45513 (line 84) 45514* TARGET_TRAMPOLINE_ADJUST_ADDRESS: Trampolines. (line 75) 45515* TARGET_TRAMPOLINE_INIT: Trampolines. (line 56) 45516* TARGET_UNSPEC_MAY_TRAP_P: Misc. (line 746) 45517* TARGET_UNWIND_EMIT: Dispatch Tables. (line 81) 45518* TARGET_UNWIND_INFO: Exception Region Output. 45519 (line 56) 45520* TARGET_UNWIND_TABLES_DEFAULT: Exception Region Output. 45521 (line 60) 45522* TARGET_UNWIND_WORD_MODE: Storage Layout. (line 461) 45523* TARGET_UPDATE_STACK_BOUNDARY: Misc. (line 989) 45524* TARGET_USE_ANCHORS_FOR_SYMBOL_P: Anchored Addresses. (line 55) 45525* TARGET_USE_BLOCKS_FOR_CONSTANT_P: Addressing Modes. (line 235) 45526* TARGET_USE_JCR_SECTION: Misc. (line 971) 45527* TARGET_USES_WEAK_UNWIND_INFO: Exception Handling. (line 129) 45528* TARGET_VALID_DLLIMPORT_ATTRIBUTE_P: Target Attributes. (line 60) 45529* TARGET_VALID_POINTER_MODE: Register Arguments. (line 284) 45530* TARGET_VECTOR_MODE_SUPPORTED_P: Register Arguments. (line 302) 45531* TARGET_VECTORIZE_BUILTIN_CONVERSION: Addressing Modes. (line 320) 45532* TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD: Addressing Modes. (line 251) 45533* TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_EVEN: Addressing Modes. (line 277) 45534* TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_ODD: Addressing Modes. (line 289) 45535* TARGET_VECTORIZE_BUILTIN_VEC_PERM: Addressing Modes. (line 312) 45536* TARGET_VECTORIZE_BUILTIN_VEC_PERM_OK: Addressing Modes. (line 316) 45537* TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST: Addressing Modes. 45538 (line 302) 45539* TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION: Addressing Modes. 45540 (line 335) 45541* TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE: Addressing Modes. 45542 (line 307) 45543* TARGET_VERSION: Run-time Target. (line 92) 45544* TARGET_VTABLE_DATA_ENTRY_DISTANCE: Type Layout. (line 331) 45545* TARGET_VTABLE_ENTRY_ALIGN: Type Layout. (line 325) 45546* TARGET_VTABLE_USES_DESCRIPTORS: Type Layout. (line 314) 45547* TARGET_WEAK_NOT_IN_ARCHIVE_TOC: Label Output. (line 245) 45548* targetm: Target Structure. (line 7) 45549* targets, makefile: Makefile. (line 6) 45550* TCmode: Machine Modes. (line 197) 45551* TDmode: Machine Modes. (line 94) 45552* TEMPLATE_DECL: Declarations. (line 6) 45553* Temporaries: Temporaries. (line 6) 45554* termination routines: Initialization. (line 6) 45555* testing constraints: C Constraint Interface. 45556 (line 6) 45557* TEXT_SECTION_ASM_OP: Sections. (line 38) 45558* TF_SIZE: Type Layout. (line 132) 45559* TFmode: Machine Modes. (line 98) 45560* THEN_CLAUSE: Statements for C++. (line 6) 45561* THREAD_MODEL_SPEC: Driver. (line 225) 45562* THROW_EXPR: Unary and Binary Expressions. 45563 (line 6) 45564* THUNK_DECL: Declarations. (line 6) 45565* THUNK_DELTA: Declarations. (line 6) 45566* TImode: Machine Modes. (line 48) 45567* TImode, in insn: Insns. (line 272) 45568* TLS_COMMON_ASM_OP: Sections. (line 82) 45569* TLS_SECTION_ASM_FLAG: Sections. (line 87) 45570* tm.h macros: Target Macros. (line 6) 45571* TQFmode: Machine Modes. (line 62) 45572* TQmode: Machine Modes. (line 119) 45573* TRAMPOLINE_ALIGNMENT: Trampolines. (line 49) 45574* TRAMPOLINE_SECTION: Trampolines. (line 40) 45575* TRAMPOLINE_SIZE: Trampolines. (line 45) 45576* trampolines for nested functions: Trampolines. (line 6) 45577* TRANSFER_FROM_TRAMPOLINE: Trampolines. (line 123) 45578* trap instruction pattern: Standard Names. (line 1344) 45579* tree <1>: Macros and Functions. 45580 (line 6) 45581* tree: Tree overview. (line 6) 45582* Tree SSA: Tree SSA. (line 6) 45583* TREE_CHAIN: Macros and Functions. 45584 (line 6) 45585* tree_code <1>: GIMPLE_OMP_FOR. (line 83) 45586* tree_code <2>: GIMPLE_COND. (line 21) 45587* tree_code <3>: GIMPLE_ASSIGN. (line 41) 45588* tree_code: Manipulating GIMPLE statements. 45589 (line 31) 45590* TREE_CODE: Tree overview. (line 6) 45591* tree_int_cst_equal: Constant expressions. 45592 (line 6) 45593* TREE_INT_CST_HIGH: Constant expressions. 45594 (line 6) 45595* TREE_INT_CST_LOW: Constant expressions. 45596 (line 6) 45597* tree_int_cst_lt: Constant expressions. 45598 (line 6) 45599* TREE_LIST: Containers. (line 6) 45600* TREE_OPERAND: Expression trees. (line 6) 45601* TREE_PUBLIC <1>: Function Properties. 45602 (line 28) 45603* TREE_PUBLIC: Function Basics. (line 6) 45604* TREE_PURPOSE: Containers. (line 6) 45605* TREE_READONLY: Function Properties. 45606 (line 37) 45607* tree_size: Macros and Functions. 45608 (line 13) 45609* TREE_STATIC: Function Properties. 45610 (line 31) 45611* TREE_STRING_LENGTH: Constant expressions. 45612 (line 6) 45613* TREE_STRING_POINTER: Constant expressions. 45614 (line 6) 45615* TREE_THIS_VOLATILE: Function Properties. 45616 (line 34) 45617* TREE_TYPE <1>: Types for C++. (line 6) 45618* TREE_TYPE <2>: Function Basics. (line 47) 45619* TREE_TYPE <3>: Expression trees. (line 6) 45620* TREE_TYPE <4>: Working with declarations. 45621 (line 11) 45622* TREE_TYPE <5>: Types. (line 6) 45623* TREE_TYPE: Macros and Functions. 45624 (line 6) 45625* TREE_VALUE: Containers. (line 6) 45626* TREE_VEC: Containers. (line 6) 45627* TREE_VEC_ELT: Containers. (line 6) 45628* TREE_VEC_LENGTH: Containers. (line 6) 45629* TRULY_NOOP_TRUNCATION: Misc. (line 177) 45630* TRUNC_DIV_EXPR: Unary and Binary Expressions. 45631 (line 6) 45632* TRUNC_MOD_EXPR: Unary and Binary Expressions. 45633 (line 6) 45634* truncate: Conversions. (line 38) 45635* truncMN2 instruction pattern: Standard Names. (line 807) 45636* TRUTH_AND_EXPR: Unary and Binary Expressions. 45637 (line 6) 45638* TRUTH_ANDIF_EXPR: Unary and Binary Expressions. 45639 (line 6) 45640* TRUTH_NOT_EXPR: Unary and Binary Expressions. 45641 (line 6) 45642* TRUTH_OR_EXPR: Unary and Binary Expressions. 45643 (line 6) 45644* TRUTH_ORIF_EXPR: Unary and Binary Expressions. 45645 (line 6) 45646* TRUTH_XOR_EXPR: Unary and Binary Expressions. 45647 (line 6) 45648* TRY_BLOCK: Statements for C++. (line 6) 45649* TRY_HANDLERS: Statements for C++. (line 6) 45650* TRY_STMTS: Statements for C++. (line 6) 45651* Tuple specific accessors: Tuple specific accessors. 45652 (line 6) 45653* tuples: Tuple representation. 45654 (line 6) 45655* type: Types. (line 6) 45656* type declaration: Declarations. (line 6) 45657* TYPE_ALIGN <1>: Types for C++. (line 6) 45658* TYPE_ALIGN: Types. (line 6) 45659* TYPE_ARG_TYPES <1>: Types for C++. (line 6) 45660* TYPE_ARG_TYPES: Types. (line 6) 45661* TYPE_ASM_OP: Label Output. (line 55) 45662* TYPE_ATTRIBUTES: Attributes. (line 25) 45663* TYPE_BINFO: Classes. (line 6) 45664* TYPE_BUILT_IN: Types for C++. (line 68) 45665* TYPE_CANONICAL: Types. (line 6) 45666* TYPE_CONTEXT <1>: Types for C++. (line 6) 45667* TYPE_CONTEXT: Types. (line 6) 45668* TYPE_DECL: Declarations. (line 6) 45669* TYPE_FIELDS <1>: Classes. (line 6) 45670* TYPE_FIELDS <2>: Types for C++. (line 6) 45671* TYPE_FIELDS: Types. (line 6) 45672* TYPE_HAS_ARRAY_NEW_OPERATOR: Classes. (line 96) 45673* TYPE_HAS_DEFAULT_CONSTRUCTOR: Classes. (line 81) 45674* TYPE_HAS_MUTABLE_P: Classes. (line 86) 45675* TYPE_HAS_NEW_OPERATOR: Classes. (line 93) 45676* TYPE_MAIN_VARIANT <1>: Types for C++. (line 6) 45677* TYPE_MAIN_VARIANT: Types. (line 6) 45678* TYPE_MAX_VALUE: Types. (line 6) 45679* TYPE_METHOD_BASETYPE <1>: Types for C++. (line 6) 45680* TYPE_METHOD_BASETYPE: Types. (line 6) 45681* TYPE_METHODS: Classes. (line 6) 45682* TYPE_MIN_VALUE: Types. (line 6) 45683* TYPE_NAME <1>: Types for C++. (line 6) 45684* TYPE_NAME: Types. (line 6) 45685* TYPE_NOTHROW_P: Functions for C++. (line 154) 45686* TYPE_OFFSET_BASETYPE <1>: Types for C++. (line 6) 45687* TYPE_OFFSET_BASETYPE: Types. (line 6) 45688* TYPE_OPERAND_FMT: Label Output. (line 66) 45689* TYPE_OVERLOADS_ARRAY_REF: Classes. (line 104) 45690* TYPE_OVERLOADS_ARROW: Classes. (line 107) 45691* TYPE_OVERLOADS_CALL_EXPR: Classes. (line 100) 45692* TYPE_POLYMORPHIC_P: Classes. (line 77) 45693* TYPE_PRECISION <1>: Types for C++. (line 6) 45694* TYPE_PRECISION: Types. (line 6) 45695* TYPE_PTR_P: Types for C++. (line 74) 45696* TYPE_PTRFN_P: Types for C++. (line 78) 45697* TYPE_PTRMEM_P: Types for C++. (line 6) 45698* TYPE_PTROB_P: Types for C++. (line 81) 45699* TYPE_PTROBV_P: Types for C++. (line 6) 45700* TYPE_QUAL_CONST <1>: Types for C++. (line 6) 45701* TYPE_QUAL_CONST: Types. (line 6) 45702* TYPE_QUAL_RESTRICT <1>: Types for C++. (line 6) 45703* TYPE_QUAL_RESTRICT: Types. (line 6) 45704* TYPE_QUAL_VOLATILE <1>: Types for C++. (line 6) 45705* TYPE_QUAL_VOLATILE: Types. (line 6) 45706* TYPE_RAISES_EXCEPTIONS: Functions for C++. (line 149) 45707* TYPE_SIZE <1>: Types for C++. (line 6) 45708* TYPE_SIZE: Types. (line 6) 45709* TYPE_STRUCTURAL_EQUALITY_P: Types. (line 6) 45710* TYPE_UNQUALIFIED <1>: Types for C++. (line 6) 45711* TYPE_UNQUALIFIED: Types. (line 6) 45712* TYPE_VFIELD: Classes. (line 6) 45713* TYPENAME_TYPE: Types for C++. (line 6) 45714* TYPENAME_TYPE_FULLNAME <1>: Types for C++. (line 6) 45715* TYPENAME_TYPE_FULLNAME: Types. (line 6) 45716* TYPEOF_TYPE: Types for C++. (line 6) 45717* UDAmode: Machine Modes. (line 168) 45718* udiv: Arithmetic. (line 125) 45719* udivM3 instruction pattern: Standard Names. (line 222) 45720* udivmodM4 instruction pattern: Standard Names. (line 428) 45721* udot_prodM instruction pattern: Standard Names. (line 265) 45722* UDQmode: Machine Modes. (line 136) 45723* UHAmode: Machine Modes. (line 160) 45724* UHQmode: Machine Modes. (line 128) 45725* UINT16_TYPE: Type Layout. (line 241) 45726* UINT32_TYPE: Type Layout. (line 242) 45727* UINT64_TYPE: Type Layout. (line 243) 45728* UINT8_TYPE: Type Layout. (line 240) 45729* UINT_FAST16_TYPE: Type Layout. (line 257) 45730* UINT_FAST32_TYPE: Type Layout. (line 258) 45731* UINT_FAST64_TYPE: Type Layout. (line 259) 45732* UINT_FAST8_TYPE: Type Layout. (line 256) 45733* UINT_LEAST16_TYPE: Type Layout. (line 249) 45734* UINT_LEAST32_TYPE: Type Layout. (line 250) 45735* UINT_LEAST64_TYPE: Type Layout. (line 251) 45736* UINT_LEAST8_TYPE: Type Layout. (line 248) 45737* UINTMAX_TYPE: Type Layout. (line 224) 45738* UINTPTR_TYPE: Type Layout. (line 261) 45739* umaddMN4 instruction pattern: Standard Names. (line 375) 45740* umax: Arithmetic. (line 144) 45741* umaxM3 instruction pattern: Standard Names. (line 222) 45742* umin: Arithmetic. (line 144) 45743* uminM3 instruction pattern: Standard Names. (line 222) 45744* umod: Arithmetic. (line 131) 45745* umodM3 instruction pattern: Standard Names. (line 222) 45746* umsubMN4 instruction pattern: Standard Names. (line 399) 45747* umulhisi3 instruction pattern: Standard Names. (line 347) 45748* umulM3_highpart instruction pattern: Standard Names. (line 361) 45749* umulqihi3 instruction pattern: Standard Names. (line 347) 45750* umulsidi3 instruction pattern: Standard Names. (line 347) 45751* unchanging: Flags. (line 324) 45752* unchanging, in call_insn: Flags. (line 19) 45753* unchanging, in jump_insn, call_insn and insn: Flags. (line 39) 45754* unchanging, in mem: Flags. (line 152) 45755* unchanging, in subreg: Flags. (line 188) 45756* unchanging, in symbol_ref: Flags. (line 10) 45757* UNEQ_EXPR: Unary and Binary Expressions. 45758 (line 6) 45759* UNGE_EXPR: Unary and Binary Expressions. 45760 (line 6) 45761* UNGT_EXPR: Unary and Binary Expressions. 45762 (line 6) 45763* UNION_TYPE <1>: Classes. (line 6) 45764* UNION_TYPE: Types. (line 6) 45765* unions, returning: Interface. (line 10) 45766* UNITS_PER_SIMD_WORD: Storage Layout. (line 77) 45767* UNITS_PER_WORD: Storage Layout. (line 67) 45768* UNKNOWN_TYPE <1>: Types for C++. (line 6) 45769* UNKNOWN_TYPE: Types. (line 6) 45770* UNLE_EXPR: Unary and Binary Expressions. 45771 (line 6) 45772* UNLIKELY_EXECUTED_TEXT_SECTION_NAME: Sections. (line 49) 45773* UNLT_EXPR: Unary and Binary Expressions. 45774 (line 6) 45775* UNORDERED_EXPR: Unary and Binary Expressions. 45776 (line 6) 45777* unshare_all_rtl: Sharing. (line 58) 45778* unsigned division: Arithmetic. (line 125) 45779* unsigned division with unsigned saturation: Arithmetic. (line 125) 45780* unsigned greater than: Comparisons. (line 64) 45781* unsigned less than: Comparisons. (line 68) 45782* unsigned minimum and maximum: Arithmetic. (line 144) 45783* unsigned_fix: Conversions. (line 77) 45784* unsigned_float: Conversions. (line 62) 45785* unsigned_fract_convert: Conversions. (line 97) 45786* unsigned_sat_fract: Conversions. (line 103) 45787* unspec: Side Effects. (line 287) 45788* unspec_volatile: Side Effects. (line 287) 45789* untyped_call instruction pattern: Standard Names. (line 975) 45790* untyped_return instruction pattern: Standard Names. (line 1025) 45791* UPDATE_PATH_HOST_CANONICALIZE (PATH): Filesystem. (line 59) 45792* update_ssa: SSA. (line 76) 45793* update_stmt <1>: SSA Operands. (line 6) 45794* update_stmt: Manipulating GIMPLE statements. 45795 (line 141) 45796* update_stmt_if_modified: Manipulating GIMPLE statements. 45797 (line 144) 45798* UQQmode: Machine Modes. (line 123) 45799* US Software GOFAST, floating point emulation library: Library Calls. 45800 (line 44) 45801* us_ashift: Arithmetic. (line 168) 45802* us_minus: Arithmetic. (line 36) 45803* us_mult: Arithmetic. (line 92) 45804* us_neg: Arithmetic. (line 81) 45805* us_plus: Arithmetic. (line 14) 45806* US_SOFTWARE_GOFAST: Library Calls. (line 45) 45807* us_truncate: Conversions. (line 48) 45808* usaddM3 instruction pattern: Standard Names. (line 222) 45809* USAmode: Machine Modes. (line 164) 45810* usashlM3 instruction pattern: Standard Names. (line 431) 45811* usdivM3 instruction pattern: Standard Names. (line 222) 45812* use: Side Effects. (line 162) 45813* USE_C_ALLOCA: Host Misc. (line 19) 45814* USE_LD_AS_NEEDED: Driver. (line 198) 45815* USE_LOAD_POST_DECREMENT: Costs. (line 174) 45816* USE_LOAD_POST_INCREMENT: Costs. (line 169) 45817* USE_LOAD_PRE_DECREMENT: Costs. (line 184) 45818* USE_LOAD_PRE_INCREMENT: Costs. (line 179) 45819* use_optype_d: Manipulating GIMPLE statements. 45820 (line 101) 45821* use_param: GTY Options. (line 113) 45822* use_paramN: GTY Options. (line 131) 45823* use_params: GTY Options. (line 139) 45824* USE_SELECT_SECTION_FOR_FUNCTIONS: Sections. (line 195) 45825* USE_STORE_POST_DECREMENT: Costs. (line 194) 45826* USE_STORE_POST_INCREMENT: Costs. (line 189) 45827* USE_STORE_PRE_DECREMENT: Costs. (line 204) 45828* USE_STORE_PRE_INCREMENT: Costs. (line 199) 45829* used: Flags. (line 342) 45830* used, in symbol_ref: Flags. (line 215) 45831* USER_LABEL_PREFIX: Instruction Output. (line 139) 45832* USING_STMT: Statements for C++. (line 6) 45833* usmaddMN4 instruction pattern: Standard Names. (line 383) 45834* usmsubMN4 instruction pattern: Standard Names. (line 407) 45835* usmulhisi3 instruction pattern: Standard Names. (line 351) 45836* usmulM3 instruction pattern: Standard Names. (line 222) 45837* usmulqihi3 instruction pattern: Standard Names. (line 351) 45838* usmulsidi3 instruction pattern: Standard Names. (line 351) 45839* usnegM2 instruction pattern: Standard Names. (line 449) 45840* USQmode: Machine Modes. (line 132) 45841* ussubM3 instruction pattern: Standard Names. (line 222) 45842* usum_widenM3 instruction pattern: Standard Names. (line 275) 45843* UTAmode: Machine Modes. (line 172) 45844* UTQmode: Machine Modes. (line 140) 45845* V in constraint: Simple Constraints. (line 43) 45846* VA_ARG_EXPR: Unary and Binary Expressions. 45847 (line 6) 45848* values, returned by functions: Scalar Return. (line 6) 45849* VAR_DECL: Declarations. (line 6) 45850* var_location: Debug Information. (line 14) 45851* varargs implementation: Varargs. (line 6) 45852* variable: Declarations. (line 6) 45853* Variable Location Debug Information in RTL: Debug Information. 45854 (line 6) 45855* vashlM3 instruction pattern: Standard Names. (line 445) 45856* vashrM3 instruction pattern: Standard Names. (line 445) 45857* vec_concat: Vector Operations. (line 28) 45858* vec_duplicate: Vector Operations. (line 33) 45859* VEC_EXTRACT_EVEN_EXPR: Vectors. (line 6) 45860* vec_extract_evenM instruction pattern: Standard Names. (line 176) 45861* VEC_EXTRACT_ODD_EXPR: Vectors. (line 6) 45862* vec_extract_oddM instruction pattern: Standard Names. (line 183) 45863* vec_extractM instruction pattern: Standard Names. (line 171) 45864* vec_initM instruction pattern: Standard Names. (line 204) 45865* VEC_INTERLEAVE_HIGH_EXPR: Vectors. (line 6) 45866* vec_interleave_highM instruction pattern: Standard Names. (line 190) 45867* VEC_INTERLEAVE_LOW_EXPR: Vectors. (line 6) 45868* vec_interleave_lowM instruction pattern: Standard Names. (line 197) 45869* VEC_LSHIFT_EXPR: Vectors. (line 6) 45870* vec_merge: Vector Operations. (line 11) 45871* VEC_PACK_FIX_TRUNC_EXPR: Vectors. (line 6) 45872* VEC_PACK_SAT_EXPR: Vectors. (line 6) 45873* vec_pack_sfix_trunc_M instruction pattern: Standard Names. (line 302) 45874* vec_pack_ssat_M instruction pattern: Standard Names. (line 295) 45875* VEC_PACK_TRUNC_EXPR: Vectors. (line 6) 45876* vec_pack_trunc_M instruction pattern: Standard Names. (line 288) 45877* vec_pack_ufix_trunc_M instruction pattern: Standard Names. (line 302) 45878* vec_pack_usat_M instruction pattern: Standard Names. (line 295) 45879* VEC_RSHIFT_EXPR: Vectors. (line 6) 45880* vec_select: Vector Operations. (line 19) 45881* vec_setM instruction pattern: Standard Names. (line 166) 45882* vec_shl_M instruction pattern: Standard Names. (line 282) 45883* vec_shr_M instruction pattern: Standard Names. (line 282) 45884* VEC_UNPACK_FLOAT_HI_EXPR: Vectors. (line 6) 45885* VEC_UNPACK_FLOAT_LO_EXPR: Vectors. (line 6) 45886* VEC_UNPACK_HI_EXPR: Vectors. (line 6) 45887* VEC_UNPACK_LO_EXPR: Vectors. (line 6) 45888* vec_unpacks_float_hi_M instruction pattern: Standard Names. 45889 (line 324) 45890* vec_unpacks_float_lo_M instruction pattern: Standard Names. 45891 (line 324) 45892* vec_unpacks_hi_M instruction pattern: Standard Names. (line 309) 45893* vec_unpacks_lo_M instruction pattern: Standard Names. (line 309) 45894* vec_unpacku_float_hi_M instruction pattern: Standard Names. 45895 (line 324) 45896* vec_unpacku_float_lo_M instruction pattern: Standard Names. 45897 (line 324) 45898* vec_unpacku_hi_M instruction pattern: Standard Names. (line 317) 45899* vec_unpacku_lo_M instruction pattern: Standard Names. (line 317) 45900* VEC_WIDEN_MULT_HI_EXPR: Vectors. (line 6) 45901* VEC_WIDEN_MULT_LO_EXPR: Vectors. (line 6) 45902* vec_widen_smult_hi_M instruction pattern: Standard Names. (line 333) 45903* vec_widen_smult_lo_M instruction pattern: Standard Names. (line 333) 45904* vec_widen_umult_hi_M instruction pattern: Standard Names. (line 333) 45905* vec_widen_umult_lo__M instruction pattern: Standard Names. (line 333) 45906* vector: Containers. (line 6) 45907* vector operations: Vector Operations. (line 6) 45908* VECTOR_CST: Constant expressions. 45909 (line 6) 45910* VECTOR_STORE_FLAG_VALUE: Misc. (line 308) 45911* virtual operands: SSA Operands. (line 6) 45912* VIRTUAL_INCOMING_ARGS_REGNUM: Regs and Memory. (line 59) 45913* VIRTUAL_OUTGOING_ARGS_REGNUM: Regs and Memory. (line 87) 45914* VIRTUAL_STACK_DYNAMIC_REGNUM: Regs and Memory. (line 78) 45915* VIRTUAL_STACK_VARS_REGNUM: Regs and Memory. (line 69) 45916* VLIW: Processor pipeline description. 45917 (line 6) 45918* vlshrM3 instruction pattern: Standard Names. (line 445) 45919* VMS: Filesystem. (line 37) 45920* VMS_DEBUGGING_INFO: VMS Debug. (line 9) 45921* VOID_TYPE: Types. (line 6) 45922* VOIDmode: Machine Modes. (line 190) 45923* volatil: Flags. (line 356) 45924* volatil, in insn, call_insn, jump_insn, code_label, barrier, and note: Flags. 45925 (line 44) 45926* volatil, in label_ref and reg_label: Flags. (line 65) 45927* volatil, in mem, asm_operands, and asm_input: Flags. (line 94) 45928* volatil, in reg: Flags. (line 116) 45929* volatil, in subreg: Flags. (line 188) 45930* volatil, in symbol_ref: Flags. (line 224) 45931* volatile memory references: Flags. (line 357) 45932* volatile, in prefetch: Flags. (line 232) 45933* voptype_d: Manipulating GIMPLE statements. 45934 (line 108) 45935* voting between constraint alternatives: Class Preferences. (line 6) 45936* vrotlM3 instruction pattern: Standard Names. (line 445) 45937* vrotrM3 instruction pattern: Standard Names. (line 445) 45938* walk_dominator_tree: SSA. (line 256) 45939* walk_gimple_op: Statement and operand traversals. 45940 (line 32) 45941* walk_gimple_seq: Statement and operand traversals. 45942 (line 50) 45943* walk_gimple_stmt: Statement and operand traversals. 45944 (line 13) 45945* walk_use_def_chains: SSA. (line 232) 45946* WCHAR_TYPE: Type Layout. (line 192) 45947* WCHAR_TYPE_SIZE: Type Layout. (line 200) 45948* which_alternative: Output Statement. (line 59) 45949* WHILE_BODY: Statements for C++. (line 6) 45950* WHILE_COND: Statements for C++. (line 6) 45951* WHILE_STMT: Statements for C++. (line 6) 45952* WIDEST_HARDWARE_FP_SIZE: Type Layout. (line 147) 45953* WINT_TYPE: Type Layout. (line 205) 45954* word_mode: Machine Modes. (line 336) 45955* WORD_REGISTER_OPERATIONS: Misc. (line 63) 45956* WORD_SWITCH_TAKES_ARG: Driver. (line 20) 45957* WORDS_BIG_ENDIAN: Storage Layout. (line 29) 45958* WORDS_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 217) 45959* X in constraint: Simple Constraints. (line 114) 45960* x-HOST: Host Fragment. (line 6) 45961* XCmode: Machine Modes. (line 197) 45962* XCOFF_DEBUGGING_INFO: DBX Options. (line 13) 45963* XEXP: Accessors. (line 6) 45964* XF_SIZE: Type Layout. (line 131) 45965* XFmode: Machine Modes. (line 79) 45966* XINT: Accessors. (line 6) 45967* xm-MACHINE.h <1>: Host Misc. (line 6) 45968* xm-MACHINE.h: Filesystem. (line 6) 45969* xor: Arithmetic. (line 163) 45970* xor, canonicalization of: Insn Canonicalizations. 45971 (line 79) 45972* xorM3 instruction pattern: Standard Names. (line 222) 45973* XSTR: Accessors. (line 6) 45974* XVEC: Accessors. (line 41) 45975* XVECEXP: Accessors. (line 48) 45976* XVECLEN: Accessors. (line 44) 45977* XWINT: Accessors. (line 6) 45978* zero_extend: Conversions. (line 28) 45979* zero_extendMN2 instruction pattern: Standard Names. (line 817) 45980* zero_extract: Bit-Fields. (line 30) 45981* zero_extract, canonicalization of: Insn Canonicalizations. 45982 (line 88) 45983 45984 45985 45986Tag Table: 45987Node: Top2060 45988Node: Contributing5098 45989Node: Portability5839 45990Node: Interface7627 45991Node: Libgcc10667 45992Node: Integer library routines12508 45993Node: Soft float library routines19347 45994Node: Decimal float library routines31284 45995Node: Fixed-point fractional library routines47041 45996Node: Exception handling routines147439 45997Node: Miscellaneous routines148546 45998Node: Languages148929 45999Node: Source Tree150478 46000Node: Configure Terms151060 46001Node: Top Level154018 46002Node: gcc Directory157187 46003Node: Subdirectories158137 46004Node: Configuration160009 46005Node: Config Fragments160729 46006Node: System Config161958 46007Node: Configuration Files162894 46008Node: Build165341 46009Node: Makefile165753 46010Ref: Makefile-Footnote-1172401 46011Ref: Makefile-Footnote-2172546 46012Node: Library Files172618 46013Node: Headers173180 46014Node: Documentation175263 46015Node: Texinfo Manuals176122 46016Node: Man Page Generation178462 46017Node: Miscellaneous Docs180377 46018Node: Front End181766 46019Node: Front End Directory185685 46020Node: Front End Config187005 46021Node: Front End Makefile189947 46022Node: Back End193729 46023Node: Testsuites197408 46024Node: Test Idioms198339 46025Node: Test Directives201736 46026Node: Directives202263 46027Node: Selectors212331 46028Node: Effective-Target Keywords213473 46029Node: Add Options230018 46030Node: Require Support230815 46031Node: Final Actions233322 46032Node: Ada Tests237385 46033Node: C Tests238727 46034Node: libgcj Tests243150 46035Node: LTO Testing244277 46036Node: gcov Testing245882 46037Node: profopt Testing248869 46038Node: compat Testing250584 46039Node: Torture Tests254824 46040Node: Options256441 46041Node: Option file format256881 46042Node: Option properties259630 46043Node: Passes266105 46044Node: Parsing pass266849 46045Node: Gimplification pass270377 46046Node: Pass manager272204 46047Node: Tree SSA passes273998 46048Node: RTL passes296528 46049Node: RTL308871 46050Node: RTL Objects311059 46051Node: RTL Classes314933 46052Node: Accessors319885 46053Node: Special Accessors322279 46054Node: Flags327645 46055Node: Machine Modes343820 46056Node: Constants356136 46057Node: Regs and Memory362165 46058Node: Arithmetic380066 46059Node: Comparisons389698 46060Node: Bit-Fields393990 46061Node: Vector Operations395542 46062Node: Conversions397377 46063Node: RTL Declarations401875 46064Node: Side Effects402696 46065Node: Incdec419018 46066Node: Assembler422353 46067Node: Debug Information423898 46068Node: Insns425096 46069Node: Calls451296 46070Node: Sharing453889 46071Node: Reading RTL456999 46072Node: GENERIC457991 46073Node: Deficiencies459864 46074Node: Tree overview460105 46075Node: Macros and Functions464232 46076Node: Identifiers465057 46077Node: Containers466668 46078Node: Types467825 46079Node: Declarations479921 46080Node: Working with declarations480416 46081Node: Internal structure486022 46082Node: Current structure hierarchy486406 46083Node: Adding new DECL node types488500 46084Node: Attributes492573 46085Node: Expression trees493818 46086Node: Constant expressions495571 46087Node: Storage References499790 46088Node: Unary and Binary Expressions502964 46089Node: Vectors522382 46090Node: Statements527311 46091Node: Basic Statements527831 46092Node: Blocks532338 46093Node: Statement Sequences533742 46094Node: Empty Statements534075 46095Node: Jumps534649 46096Node: Cleanups535302 46097Node: OpenMP537070 46098Node: Functions542817 46099Node: Function Basics543288 46100Node: Function Properties546973 46101Node: Language-dependent trees550102 46102Node: C and C++ Trees550988 46103Node: Types for C++553892 46104Node: Namespaces558862 46105Node: Classes561969 46106Node: Functions for C++567047 46107Node: Statements for C++573300 46108Node: C++ Expressions581348 46109Node: Java Trees582849 46110Node: GIMPLE582962 46111Node: Tuple representation586583 46112Node: GIMPLE instruction set595238 46113Node: GIMPLE Exception Handling596906 46114Node: Temporaries598820 46115Ref: Temporaries-Footnote-1600139 46116Node: Operands600202 46117Node: Compound Expressions600976 46118Node: Compound Lvalues601210 46119Node: Conditional Expressions601976 46120Node: Logical Operators602646 46121Node: Manipulating GIMPLE statements609437 46122Node: Tuple specific accessors615365 46123Node: `GIMPLE_ASM'616184 46124Node: `GIMPLE_ASSIGN'618789 46125Node: `GIMPLE_BIND'622734 46126Node: `GIMPLE_CALL'624541 46127Node: `GIMPLE_CATCH'628800 46128Node: `GIMPLE_COND'629943 46129Node: `GIMPLE_DEBUG'632731 46130Node: `GIMPLE_EH_FILTER'636103 46131Node: `GIMPLE_LABEL'637590 46132Node: `GIMPLE_NOP'638565 46133Node: `GIMPLE_OMP_ATOMIC_LOAD'638934 46134Node: `GIMPLE_OMP_ATOMIC_STORE'639844 46135Node: `GIMPLE_OMP_CONTINUE'640483 46136Node: `GIMPLE_OMP_CRITICAL'641833 46137Node: `GIMPLE_OMP_FOR'642769 46138Node: `GIMPLE_OMP_MASTER'646279 46139Node: `GIMPLE_OMP_ORDERED'646662 46140Node: `GIMPLE_OMP_PARALLEL'647062 46141Node: `GIMPLE_OMP_RETURN'649831 46142Node: `GIMPLE_OMP_SECTION'650481 46143Node: `GIMPLE_OMP_SECTIONS'651147 46144Node: `GIMPLE_OMP_SINGLE'652751 46145Node: `GIMPLE_PHI'653687 46146Node: `GIMPLE_RESX'655100 46147Node: `GIMPLE_RETURN'655819 46148Node: `GIMPLE_SWITCH'656387 46149Node: `GIMPLE_TRY'658517 46150Node: `GIMPLE_WITH_CLEANUP_EXPR'660307 46151Node: GIMPLE sequences661190 46152Node: Sequence iterators664396 46153Node: Adding a new GIMPLE statement code672851 46154Node: Statement and operand traversals674131 46155Node: Tree SSA676741 46156Node: Annotations678527 46157Node: SSA Operands679053 46158Node: SSA693584 46159Node: Alias analysis705875 46160Node: Memory model709655 46161Node: Loop Analysis and Representation711018 46162Node: Loop representation712199 46163Node: Loop querying719119 46164Node: Loop manipulation721952 46165Node: LCSSA724320 46166Node: Scalar evolutions726392 46167Node: loop-iv729636 46168Node: Number of iterations731562 46169Node: Dependency analysis734371 46170Node: Lambda740739 46171Node: Omega742410 46172Node: Control Flow743975 46173Node: Basic Blocks744970 46174Node: Edges749538 46175Node: Profile information758100 46176Node: Maintaining the CFG762786 46177Node: Liveness information769663 46178Node: Machine Desc771789 46179Node: Overview774257 46180Node: Patterns776298 46181Node: Example779736 46182Node: RTL Template781171 46183Node: Output Template791826 46184Node: Output Statement795791 46185Node: Predicates799753 46186Node: Machine-Independent Predicates802671 46187Node: Defining Predicates807616 46188Node: Constraints813581 46189Node: Simple Constraints814829 46190Node: Multi-Alternative827035 46191Node: Class Preferences829876 46192Node: Modifiers830768 46193Node: Machine Constraints834900 46194Node: Disable Insn Alternatives871763 46195Node: Define Constraints874656 46196Node: C Constraint Interface881437 46197Node: Standard Names885078 46198Ref: shift patterns904006 46199Ref: prologue instruction pattern944017 46200Ref: epilogue instruction pattern944510 46201Node: Pattern Ordering954226 46202Node: Dependent Patterns955462 46203Node: Jump Patterns957082 46204Ref: Jump Patterns-Footnote-1959226 46205Node: Looping Patterns959272 46206Node: Insn Canonicalizations964000 46207Node: Expander Definitions967951 46208Node: Insn Splitting976069 46209Node: Including Patterns985671 46210Node: Peephole Definitions987451 46211Node: define_peephole988704 46212Node: define_peephole2995035 46213Node: Insn Attributes998102 46214Node: Defining Attributes999208 46215Node: Expressions1001728 46216Node: Tagging Insns1008330 46217Node: Attr Example1012683 46218Node: Insn Lengths1015057 46219Node: Constant Attributes1018116 46220Node: Delay Slots1019285 46221Node: Processor pipeline description1022509 46222Ref: Processor pipeline description-Footnote-11040127 46223Node: Conditional Execution1040449 46224Node: Constant Definitions1043302 46225Node: Iterators1044897 46226Node: Mode Iterators1045344 46227Node: Defining Mode Iterators1046322 46228Node: Substitutions1047816 46229Node: Examples1050057 46230Node: Code Iterators1051505 46231Node: Target Macros1053762 46232Node: Target Structure1056850 46233Node: Driver1058119 46234Node: Run-time Target1081800 46235Node: Per-Function Data1089672 46236Node: Storage Layout1092435 46237Node: Type Layout1118021 46238Node: Registers1132521 46239Node: Register Basics1133495 46240Node: Allocation Order1139062 46241Node: Values in Registers1141083 46242Node: Leaf Functions1148572 46243Node: Stack Registers1151430 46244Node: Register Classes1152702 46245Node: Old Constraints1180327 46246Node: Stack and Calling1187479 46247Node: Frame Layout1188013 46248Node: Exception Handling1198893 46249Node: Stack Checking1205271 46250Node: Frame Registers1210084 46251Node: Elimination1216977 46252Node: Stack Arguments1221206 46253Node: Register Arguments1228015 46254Node: Scalar Return1243493 46255Node: Aggregate Return1249585 46256Node: Caller Saves1253266 46257Node: Function Entry1254444 46258Node: Profiling1267072 46259Node: Tail Calls1268771 46260Node: Stack Smashing Protection1270137 46261Node: Varargs1271249 46262Node: Trampolines1279244 46263Node: Library Calls1285891 46264Node: Addressing Modes1290741 46265Node: Anchored Addresses1308150 46266Node: Condition Code1310799 46267Node: CC0 Condition Codes1312928 46268Node: MODE_CC Condition Codes1316174 46269Node: Cond. Exec. Macros1322403 46270Node: Costs1323382 46271Node: Scheduling1336843 46272Node: Sections1354110 46273Node: PIC1369178 46274Node: Assembler Format1371182 46275Node: File Framework1372320 46276Ref: TARGET_HAVE_SWITCHABLE_BSS_SECTIONS1377795 46277Node: Data Output1381060 46278Node: Uninitialized Data1388819 46279Node: Label Output1394383 46280Node: Initialization1416073 46281Node: Macros for Initialization1422035 46282Node: Instruction Output1428487 46283Node: Dispatch Tables1438158 46284Node: Exception Region Output1441973 46285Node: Alignment Output1447715 46286Node: Debugging Info1451878 46287Node: All Debuggers1452548 46288Node: DBX Options1455403 46289Node: DBX Hooks1460852 46290Node: File Names and DBX1462778 46291Node: SDB and DWARF1464890 46292Node: VMS Debug1469191 46293Node: Floating Point1469761 46294Node: Mode Switching1474584 46295Node: Target Attributes1478510 46296Node: Emulated TLS1485346 46297Node: MIPS Coprocessors1488736 46298Node: PCH Target1490305 46299Node: C++ ABI1491847 46300Node: Named Address Spaces1496496 46301Node: Misc1501598 46302Ref: TARGET_SHIFT_TRUNCATION_MASK1509026 46303Node: Host Config1553537 46304Node: Host Common1554605 46305Node: Filesystem1556984 46306Node: Host Misc1561099 46307Node: Fragments1563548 46308Node: Target Fragment1564743 46309Node: Host Fragment1570633 46310Node: Collect21570873 46311Node: Header Dirs1573509 46312Node: Type Information1574932 46313Node: GTY Options1577223 46314Node: GGC Roots1587898 46315Node: Files1588618 46316Node: Invoking the garbage collector1591364 46317Node: Plugins1592417 46318Node: Funding1608239 46319Node: GNU Project1610726 46320Node: Copying1611375 46321Node: GNU Free Documentation License1648906 46322Node: Contributors1671315 46323Node: Option Index1708002 46324Node: Concept Index1708587 46325 46326End Tag Table 46327