![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-6 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-6 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.4 ! root 1: This is Info file gcc.info, produced by Makeinfo-1.49 from the input 1.1 root 2: file gcc.texi. 3: 4: This file documents the use and the internals of the GNU compiler. 5: 6: Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc. 7: 1.1.1.3 root 8: Permission is granted to make and distribute verbatim copies of this 9: manual provided the copyright notice and this permission notice are 10: preserved on all copies. 1.1 root 11: 12: Permission is granted to copy and distribute modified versions of 13: this manual under the conditions for verbatim copying, provided also 1.1.1.4 ! root 14: that the sections entitled "GNU General Public License" and "Protect ! 15: Your Freedom--Fight `Look And Feel'" are included exactly as in the ! 16: original, and provided that the entire resulting derived work is ! 17: distributed under the terms of a permission notice identical to this ! 18: one. 1.1 root 19: 20: Permission is granted to copy and distribute translations of this 21: manual into another language, under the above conditions for modified 1.1.1.3 root 22: versions, except that the sections entitled "GNU General Public 1.1.1.4 ! root 23: License" and "Protect Your Freedom--Fight `Look And Feel'", and this ! 24: permission notice, may be included in translations approved by the Free ! 25: Software Foundation instead of in the original English. 1.1 root 26: 27: 1.1.1.4 ! root 28: File: gcc.info, Node: Function Attributes, Next: Function Prototypes, Prev: Case Ranges, Up: Extensions 1.1.1.2 root 29: 1.1.1.4 ! root 30: Declaring Attributes of Functions ! 31: ================================= 1.1.1.2 root 32: 1.1.1.4 ! root 33: In GNU C, you declare certain things about functions called in your ! 34: program which help the compiler optimize function calls. 1.1.1.2 root 35: 1.1.1.4 ! root 36: A few standard library functions, such as `abort' and `exit', cannot ! 37: return. GNU CC knows this automatically. Some programs define their ! 38: own functions that never return. You can declare them `volatile' to ! 39: tell the compiler this fact. For example, ! 40: ! 41: extern void volatile fatal (); ! 42: ! 43: void ! 44: fatal (...) ! 45: { ! 46: ... /* Print error message. */ ... ! 47: exit (1); ! 48: } ! 49: ! 50: The `volatile' keyword tells the compiler to assume that `fatal' ! 51: cannot return. This makes slightly better code, but more importantly ! 52: it helps avoid spurious warnings of uninitialized variables. ! 53: ! 54: It does not make sense for a `volatile' function to have a return ! 55: type other than `void'. ! 56: ! 57: Many functions do not examine any values except their arguments, and ! 58: have no effects except the return value. Such a function can be subject ! 59: to common subexpression elimination and loop optimization just as an ! 60: arithmetic operator would be. These functions should be declared ! 61: `const'. For example, ! 62: ! 63: extern int const square (); ! 64: ! 65: says that the hypothetical function `square' is safe to call fewer ! 66: times than the program says. ! 67: ! 68: Note that a function that has pointer arguments and examines the data ! 69: pointed to must *not* be declared `const'. Likewise, a function that ! 70: calls a non-`const' function usually must not be `const'. It does not ! 71: make sense for a `const' function to return `void'. ! 72: ! 73: We recommend placing the keyword `const' after the function's return ! 74: type. It makes no difference in the example above, but when the return ! 75: type is a pointer, it is the only way to make the function itself ! 76: const. For example, ! 77: ! 78: const char *mincp (int); ! 79: ! 80: says that `mincp' returns `const char *'--a pointer to a const object. ! 81: To declare `mincp' const, you must write this: ! 82: ! 83: char * const mincp (int); ! 84: ! 85: Some people object to this feature, suggesting that ANSI C's ! 86: `#pragma' should be used instead. There are two reasons for not doing ! 87: this. ! 88: ! 89: 1. It is impossible to generate `#pragma' commands from a macro. ! 90: ! 91: 2. The `#pragma' command is just as likely as these keywords to mean ! 92: something else in another compiler. ! 93: ! 94: These two reasons apply to almost any application that might be ! 95: proposed for `#pragma'. It is basically a mistake to use `#pragma' for ! 96: *anything*. ! 97: ! 98: The keyword `__attribute__' allows you to specify special attributes ! 99: when making a declaration. This keyword is followed by an attribute ! 100: specification inside double parentheses. One attribute, `format', is ! 101: currently defined for functions. Others are implemented for variables ! 102: and structure fields (*note Function Attributes::.). ! 103: ! 104: `format (ARCHETYPE, STRING-INDEX, FIRST-TO-CHECK)' ! 105: The `format' attribute specifies that a function takes `printf' or ! 106: `scanf' style arguments which should be type-checked against a ! 107: format string. For example, the declaration: ! 108: ! 109: extern int ! 110: my_printf (void *my_object, const char *my_format, ...) ! 111: __attribute__ ((format (printf, 2, 3))); ! 112: ! 113: causes the compiler to check the arguments in calls to `my_printf' ! 114: for consistency with the `printf' style format string argument ! 115: `my_format'. ! 116: ! 117: The parameter ARCHETYPE determines how the format string is ! 118: interpreted, and should be either `printf' or `scanf'. The ! 119: parameter STRING-INDEX specifies which argument is the format ! 120: string argument (starting from 1), while FIRST-TO-CHECK is the ! 121: number of the first argument to check against the format string. ! 122: For functions where the arguments are not available to be checked ! 123: (such as `vprintf'), specify the third parameter as zero. In this ! 124: case the compiler only checks the format string for consistency. ! 125: ! 126: In the example above, the format string (`my_format') is the second ! 127: argument of the function `my_print', and the arguments to check ! 128: start with the third argument, so the correct parameters for the ! 129: format attribute are 2 and 3. ! 130: ! 131: The `format' attribute allows you to identify your own functions ! 132: which take format strings as arguments, so that GNU CC can check ! 133: the calls to these functions for errors. The compiler always ! 134: checks formats for the ANSI library functions `printf', `fprintf', ! 135: `sprintf', `scanf', `fscanf', `sscanf', `vprintf', `vfprintf' and ! 136: `vsprintf' whenever such warnings are requested (using ! 137: `-Wformat'), so there is no need to modify the header file ! 138: `stdio.h'. 1.1.1.2 root 139: 1.1.1.4 ! root 140: ! 141: File: gcc.info, Node: Function Prototypes, Next: Dollar Signs, Prev: Function Attributes, Up: Extensions 1.1.1.2 root 142: 1.1.1.4 ! root 143: Prototypes and Old-Style Function Definitions ! 144: ============================================= 1.1.1.2 root 145: 1.1.1.4 ! root 146: GNU C extends ANSI C to allow a function prototype to override a ! 147: later old-style non-prototype definition. Consider the following ! 148: example: ! 149: ! 150: /* Use prototypes unless the compiler is old-fashioned. */ ! 151: #if __STDC__ ! 152: #define P(x) (x) ! 153: #else ! 154: #define P(x) () ! 155: #endif ! 156: ! 157: /* Prototype function declaration. */ ! 158: int isroot P((uid_t)); ! 159: ! 160: /* Old-style function definition. */ ! 161: int ! 162: isroot (x) /* ??? lossage here ??? */ ! 163: uid_t x; ! 164: { ! 165: return x == 0; ! 166: } ! 167: ! 168: Suppose the type `uid_t' happens to be `short'. ANSI C does not ! 169: allow this example, because subword arguments in old-style ! 170: non-prototype definitions are promoted. Therefore in this example the ! 171: function definition's argument is really an `int', which does not match ! 172: the prototype argument type of `short'. ! 173: ! 174: This restriction of ANSI C makes it hard to write code that is ! 175: portable to traditional C compilers, because the programmer does not ! 176: know whether the `uid_t' type is `short', `int', or `long'. Therefore, ! 177: in cases like these GNU C allows a prototype to override a later ! 178: old-style definition. More precisely, in GNU C, a function prototype ! 179: argument type overrides the argument type specified by a later ! 180: old-style definition if the former type is the same as the latter type ! 181: before promotion. Thus in GNU C the above example is equivalent to the ! 182: following: ! 183: ! 184: int isroot (uid_t); ! 185: ! 186: int ! 187: isroot (uid_t x) ! 188: { ! 189: return x == 0; ! 190: } 1.1.1.2 root 191: 192: 1.1.1.4 ! root 193: File: gcc.info, Node: Dollar Signs, Next: Character Escapes, Prev: Function Prototypes, Up: Extensions 1.1 root 194: 1.1.1.4 ! root 195: Dollar Signs in Identifier Names ! 196: ================================ 1.1 root 197: 1.1.1.4 ! root 198: In GNU C, you may use dollar signs in identifier names. This is ! 199: because many traditional C implementations allow such identifiers. 1.1.1.3 root 200: 1.1.1.4 ! root 201: On some machines, dollar signs are allowed in identifiers if you ! 202: specify `-traditional'. On a few systems they are allowed by default, ! 203: even if you do not use `-traditional'. But they are never allowed if ! 204: you specify `-ansi'. ! 205: ! 206: There are certain ANSI C programs (obscure, to be sure) that would ! 207: compile incorrectly if dollar signs were permitted in identifiers. For ! 208: example: ! 209: ! 210: #define foo(a) #a ! 211: #define lose(b) foo (b) ! 212: #define test$ ! 213: lose (test) 1.1.1.3 root 214: 215: 1.1.1.4 ! root 216: File: gcc.info, Node: Character Escapes, Next: Variable Attributes, Prev: Dollar Signs, Up: Extensions 1.1.1.3 root 217: 1.1.1.4 ! root 218: The Character ESC in Constants ! 219: ============================== 1.1.1.3 root 220: 1.1.1.4 ! root 221: You can use the sequence `\e' in a string or character constant to ! 222: stand for the ASCII character ESC. 1.1.1.3 root 223: 1.1.1.4 ! root 224: ! 225: File: gcc.info, Node: Alignment, Next: Inline, Prev: Variable Attributes, Up: Extensions 1.1.1.3 root 226: 1.1.1.4 ! root 227: Inquiring on Alignment of Types or Variables ! 228: ============================================ 1.1.1.3 root 229: 1.1.1.4 ! root 230: The keyword `__alignof__' allows you to inquire about how an object ! 231: is aligned, or the minimum alignment usually required by a type. Its ! 232: syntax is just like `sizeof'. ! 233: ! 234: For example, if the target machine requires a `double' value to be ! 235: aligned on an 8-byte boundary, then `__alignof__ (double)' is 8. This ! 236: is true on many RISC machines. On more traditional machine designs, ! 237: `__alignof__ (double)' is 4 or even 2. ! 238: ! 239: Some machines never actually require alignment; they allow reference ! 240: to any data type even at an odd addresses. For these machines, ! 241: `__alignof__' reports the *recommended* alignment of a type. ! 242: ! 243: When the operand of `__alignof__' is an lvalue rather than a type, ! 244: the value is the largest alignment that the lvalue is known to have. ! 245: It may have this alignment as a result of its data type, or because it ! 246: is part of a structure and inherits alignment from that structure. For ! 247: example, after this declaration: ! 248: ! 249: struct foo { int x; char y; } foo1; ! 250: ! 251: the value of `__alignof__ (foo1.y)' is probably 2 or 4, the same as ! 252: `__alignof__ (int)', even though the data type of `foo1.y' does not ! 253: itself demand any alignment. 1.1.1.3 root 254: 1.1.1.4 ! root 255: A related feature which lets you specify the alignment of an object ! 256: is `__attribute__ ((aligned (ALIGNMENT)))'; see the following section. 1.1.1.3 root 257: 258: 1.1.1.4 ! root 259: File: gcc.info, Node: Variable Attributes, Next: Alignment, Prev: Character Escapes, Up: Extensions 1.1.1.3 root 260: 1.1.1.4 ! root 261: Specifying Attributes of Variables ! 262: ================================== 1.1.1.3 root 263: 1.1.1.4 ! root 264: The keyword `__attribute__' allows you to specify special attributes ! 265: of variables or structure fields. This keyword is followed by an ! 266: attribute specification inside double parentheses. Four attributes are ! 267: currently defined: `aligned', `format', `mode' and `packed'. `format' ! 268: is used for functions, and thus not documented here; see *Note Function ! 269: Attributes::. ! 270: ! 271: `aligned (ALIGNMENT)' ! 272: This attribute specifies the alignment of the variable or structure ! 273: field, measured in bytes. For example, the declaration: ! 274: ! 275: int x __attribute__ ((aligned (16))) = 0; ! 276: ! 277: causes the compiler to allocate the global variable `x' on a ! 278: 16-byte boundary. On a 68040, this could be used in conjunction ! 279: with an `asm' expression to access the `move16' instruction which ! 280: requires 16-byte aligned operands. ! 281: ! 282: You can also specify the alignment of structure fields. For ! 283: example, to create a double-word aligned `int' pair, you could ! 284: write: ! 285: ! 286: struct foo { int x[2] __attribute__ ((aligned (8))); }; ! 287: ! 288: This is an alternative to creating a union with a `double' member ! 289: that forces the union to be double-word aligned. ! 290: ! 291: It is not possible to specify the alignment of functions; the ! 292: alignment of functions is determined by the machine's requirements ! 293: and cannot be changed. You cannot specify alignment for a typedef ! 294: name because such a name is just an alias, not a distinct type. ! 295: ! 296: The linker of your operating system imposes a maximum alignment. ! 297: If the linker aligns each object file on a four byte boundary, ! 298: then it is beyond the compiler's power to cause anything to be ! 299: aligned to a larger boundary than that. For example, if the ! 300: linker happens to put this object file at address 136 (eight more ! 301: than a multiple of 64), then the compiler cannot guarantee an ! 302: alignment of more than 8 just by aligning variables in the object ! 303: file. ! 304: ! 305: `mode (MODE)' ! 306: This attribute specifies the data type for the ! 307: declaration--whichever type corresponds to the mode MODE. This in ! 308: effect lets you request an integer or floating point type ! 309: according to its width. ! 310: ! 311: `packed' ! 312: The `packed' attribute specifies that a variable or structure field ! 313: should have the smallest possible alignment--one byte for a ! 314: variable, and one bit for a field, unless you specify a larger ! 315: value with the `aligned' attribute. 1.1.1.3 root 316: 1.1.1.4 ! root 317: ! 318: File: gcc.info, Node: Inline, Next: Extended Asm, Prev: Alignment, Up: Extensions 1.1.1.3 root 319: 1.1.1.4 ! root 320: An Inline Function is As Fast As a Macro ! 321: ======================================== ! 322: ! 323: By declaring a function `inline', you can direct GNU CC to integrate ! 324: that function's code into the code for its callers. This makes ! 325: execution faster by eliminating the function-call overhead; in ! 326: addition, if any of the actual argument values are constant, their known ! 327: values may permit simplifications at compile time so that not all of the ! 328: inline function's code needs to be included. Inlining of functions is ! 329: an optimization and it really "works" only in optimizing compilation. ! 330: If you don't use `-O', no function is really inline. ! 331: ! 332: To declare a function inline, use the `inline' keyword in its ! 333: declaration, like this: ! 334: ! 335: inline int ! 336: inc (int *a) ! 337: { ! 338: (*a)++; ! 339: } ! 340: ! 341: (If you are writing a header file to be included in ANSI C programs, ! 342: write `__inline__' instead of `inline'. *Note Alternate Keywords::.) ! 343: ! 344: You can also make all "simple enough" functions inline with the ! 345: option `-finline-functions'. Note that certain usages in a function ! 346: definition can make it unsuitable for inline substitution. ! 347: ! 348: When a function is both inline and `static', if all calls to the ! 349: function are integrated into the caller, and the function's address is ! 350: never used, then the function's own assembler code is never referenced. ! 351: In this case, GNU CC does not actually output assembler code for the ! 352: function, unless you specify the option `-fkeep-inline-functions'. Some ! 353: calls cannot be integrated for various reasons (in particular, calls ! 354: that precede the function's definition cannot be integrated, and ! 355: neither can recursive calls within the definition). If there is a ! 356: nonintegrated call, then the function is compiled to assembler code as ! 357: usual. The function must also be compiled as usual if the program ! 358: refers to its address, because that can't be inlined. ! 359: ! 360: When an inline function is not `static', then the compiler must ! 361: assume that there may be calls from other source files; since a global ! 362: symbol can be defined only once in any program, the function must not ! 363: be defined in the other source files, so the calls therein cannot be ! 364: integrated. Therefore, a non-`static' inline function is always ! 365: compiled on its own in the usual fashion. ! 366: ! 367: If you specify both `inline' and `extern' in the function ! 368: definition, then the definition is used only for inlining. In no case ! 369: is the function compiled on its own, not even if you refer to its ! 370: address explicitly. Such an address becomes an external reference, as ! 371: if you had only declared the function, and had not defined it. ! 372: ! 373: This combination of `inline' and `extern' has almost the effect of a ! 374: macro. The way to use it is to put a function definition in a header ! 375: file with these keywords, and put another copy of the definition ! 376: (lacking `inline' and `extern') in a library file. The definition in ! 377: the header file will cause most calls to the function to be inlined. ! 378: If any uses of the function remain, they will refer to the single copy ! 379: in the library. ! 380: ! 381: GNU C does not inline any functions when not optimizing. It is not ! 382: clear whether it is better to inline or not, in this case, but we found ! 383: that a correct implementation when not optimizing was difficult. So we ! 384: did the easy thing, and turned it off. 1.1.1.3 root 385: 386: 1.1.1.4 ! root 387: File: gcc.info, Node: Extended Asm, Next: Asm Labels, Prev: Inline, Up: Extensions ! 388: ! 389: Assembler Instructions with C Expression Operands ! 390: ================================================= 1.1.1.3 root 391: 1.1.1.4 ! root 392: In an assembler instruction using `asm', you can now specify the ! 393: operands of the instruction using C expressions. This means no more ! 394: guessing which registers or memory locations will contain the data you ! 395: want to use. ! 396: ! 397: You must specify an assembler instruction template much like what ! 398: appears in a machine description, plus an operand constraint string for ! 399: each operand. ! 400: ! 401: For example, here is how to use the 68881's `fsinx' instruction: ! 402: ! 403: asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); ! 404: ! 405: Here `angle' is the C expression for the input operand while `result' ! 406: is that of the output operand. Each has `"f"' as its operand ! 407: constraint, saying that a floating point register is required. The `=' ! 408: in `=f' indicates that the operand is an output; all output operands' ! 409: constraints must use `='. The constraints use the same language used ! 410: in the machine description (*note Constraints::.). ! 411: ! 412: Each operand is described by an operand-constraint string followed by ! 413: the C expression in parentheses. A colon separates the assembler ! 414: template from the first output operand, and another separates the last ! 415: output operand from the first input, if any. Commas separate output ! 416: operands and separate inputs. The total number of operands is limited ! 417: to ten or to the maximum number of operands in any instruction pattern ! 418: in the machine description, whichever is greater. ! 419: ! 420: If there are no output operands, and there are input operands, then ! 421: there must be two consecutive colons surrounding the place where the ! 422: output operands would go. ! 423: ! 424: Output operand expressions must be lvalues; the compiler can check ! 425: this. The input operands need not be lvalues. The compiler cannot ! 426: check whether the operands have data types that are reasonable for the ! 427: instruction being executed. It does not parse the assembler ! 428: instruction template and does not know what it means, or whether it is ! 429: valid assembler input. The extended `asm' feature is most often used ! 430: for machine instructions that the compiler itself does not know exist. ! 431: ! 432: The output operands must be write-only; GNU CC will assume that the ! 433: values in these operands before the instruction are dead and need not be ! 434: generated. Extended asm does not support input-output or read-write ! 435: operands. For this reason, the constraint character `+', which ! 436: indicates such an operand, may not be used. ! 437: ! 438: When the assembler instruction has a read-write operand, or an ! 439: operand in which only some of the bits are to be changed, you must ! 440: logically split its function into two separate operands, one input ! 441: operand and one write-only output operand. The connection between them ! 442: is expressed by constraints which say they need to be in the same ! 443: location when the instruction executes. You can use the same C ! 444: expression for both operands, or different expressions. For example, ! 445: here we write the (fictitious) `combine' instruction with `bar' as its ! 446: read-only source operand and `foo' as its read-write destination: ! 447: ! 448: asm ("combine %2,%0" : "=r" (foo) : "0" (foo), "g" (bar)); ! 449: ! 450: The constraint `"0"' for operand 1 says that it must occupy the same ! 451: location as operand 0. A digit in constraint is allowed only in an ! 452: input operand, and it must refer to an output operand. ! 453: ! 454: Only a digit in the constraint can guarantee that one operand will ! 455: be in the same place as another. The mere fact that `foo' is the value ! 456: of both operands is not enough to guarantee that they will be in the ! 457: same place in the generated assembler code. The following would not ! 458: work: ! 459: ! 460: asm ("combine %2,%0" : "=r" (foo) : "r" (foo), "g" (bar)); ! 461: ! 462: Various optimizations or reloading could cause operands 0 and 1 to ! 463: be in different registers; GNU CC knows no reason not to do so. For ! 464: example, the compiler might find a copy of the value of `foo' in one ! 465: register and use it for operand 1, but generate the output operand 0 in ! 466: a different register (copying it afterward to `foo''s own address). Of ! 467: course, since the register for operand 1 is not even mentioned in the ! 468: assembler code, the result will not work, but GNU CC can't tell that. ! 469: ! 470: Some instructions clobber specific hard registers. To describe ! 471: this, write a third colon after the input operands, followed by the ! 472: names of the clobbered hard registers (given as strings). Here is a ! 473: realistic example for the Vax: ! 474: ! 475: asm volatile ("movc3 %0,%1,%2" ! 476: : /* no outputs */ ! 477: : "g" (from), "g" (to), "g" (count) ! 478: : "r0", "r1", "r2", "r3", "r4", "r5"); ! 479: ! 480: If you refer to a particular hardware register from the assembler ! 481: code, then you will probably have to list the register after the third ! 482: colon to tell the compiler that the register's value is modified. In ! 483: many assemblers, the register names begin with `%'; to produce one `%' ! 484: in the assembler code, you must write `%%' in the input. ! 485: ! 486: If your assembler instruction can alter the condition code register, ! 487: add `cc' to the list of clobbered registers. GNU CC on some machines ! 488: represents the condition codes as a specific hardware register; `cc' ! 489: serves to name this register. On other machines, the condition code is ! 490: handled differently, and specifying `cc' has no effect. But it is ! 491: valid no matter what the machine. ! 492: ! 493: If your assembler instruction modifies memory in an unpredicable ! 494: fashion, add `memory' to the list of clobbered registers. This will ! 495: cause GNU CC to not keep memory values cached in registers across the ! 496: assembler instruction. ! 497: ! 498: You can put multiple assembler instructions together in a single ! 499: `asm' template, separated either with newlines (written as `\n') or with ! 500: semicolons if the assembler allows such semicolons. The GNU assembler ! 501: allows semicolons and all Unix assemblers seem to do so. The input ! 502: operands are guaranteed not to use any of the clobbered registers, and ! 503: neither will the output operands' addresses, so you can read and write ! 504: the clobbered registers as many times as you like. Here is an example ! 505: of multiple instructions in a template; it assumes that the subroutine ! 506: `_foo' accepts arguments in registers 9 and 10: ! 507: ! 508: asm ("movl %0,r9;movl %1,r10;call _foo" ! 509: : /* no outputs */ ! 510: : "g" (from), "g" (to) ! 511: : "r9", "r10"); ! 512: ! 513: Unless an output operand has the `&' constraint modifier, GNU CC may ! 514: allocate it in the same register as an unrelated input operand, on the ! 515: assumption that the inputs are consumed before the outputs are produced. ! 516: This assumption may be false if the assembler code actually consists of ! 517: more than one instruction. In such a case, use `&' for each output ! 518: operand that may not overlap an input. *Note Modifiers::. ! 519: ! 520: If you want to test the condition code produced by an assembler ! 521: instruction, you must include a branch and a label in the `asm' ! 522: construct, as follows: ! 523: ! 524: asm ("clr %0;frob %1;beq 0f;mov #1,%0;0:" ! 525: : "g" (result) ! 526: : "g" (input)); ! 527: ! 528: This assumes your assembler supports local labels, as the GNU assembler ! 529: and most Unix assemblers do. ! 530: ! 531: Usually the most convenient way to use these `asm' instructions is to ! 532: encapsulate them in macros that look like functions. For example, ! 533: ! 534: #define sin(x) \ ! 535: ({ double __value, __arg = (x); \ ! 536: asm ("fsinx %1,%0": "=f" (__value): "f" (__arg)); \ ! 537: __value; }) ! 538: ! 539: Here the variable `__arg' is used to make sure that the instruction ! 540: operates on a proper `double' value, and to accept only those arguments ! 541: `x' which can convert automatically to a `double'. ! 542: ! 543: Another way to make sure the instruction operates on the correct ! 544: data type is to use a cast in the `asm'. This is different from using a ! 545: variable `__arg' in that it converts more different types. For ! 546: example, if the desired type were `int', casting the argument to `int' ! 547: would accept a pointer with no complaint, while assigning the argument ! 548: to an `int' variable named `__arg' would warn about using a pointer ! 549: unless the caller explicitly casts it. ! 550: ! 551: If an `asm' has output operands, GNU CC assumes for optimization ! 552: purposes that the instruction has no side effects except to change the ! 553: output operands. This does not mean that instructions with a side ! 554: effect cannot be used, but you must be careful, because the compiler ! 555: may eliminate them if the output operands aren't used, or move them out ! 556: of loops, or replace two with one if they constitute a common ! 557: subexpression. Also, if your instruction does have a side effect on a ! 558: variable that otherwise appears not to change, the old value of the ! 559: variable may be reused later if it happens to be found in a register. ! 560: ! 561: You can prevent an `asm' instruction from being deleted, moved ! 562: significantly, or combined, by writing the keyword `volatile' after the ! 563: `asm'. For example: ! 564: ! 565: #define set_priority(x) \ ! 566: asm volatile ("set_priority %0": /* no outputs */ : "g" (x)) ! 567: ! 568: An instruction without output operands will not be deleted or moved ! 569: significantly, regardless, unless it is unreachable. ! 570: ! 571: Note that even a volatile `asm' instruction can be moved in ways ! 572: that appear insignificant to the compiler, such as across jump ! 573: instructions. You can't expect a sequence of volatile `asm' ! 574: instructions to remain perfectly consecutive. If you want consecutive ! 575: output, use a single `asm'. ! 576: ! 577: It is a natural idea to look for a way to give access to the ! 578: condition code left by the assembler instruction. However, when we ! 579: attempted to implement this, we found no way to make it work reliably. ! 580: The problem is that output operands might need reloading, which would ! 581: result in additional following "store" instructions. On most machines, ! 582: these instructions would alter the condition code before there was time ! 583: to test it. This problem doesn't arise for ordinary "test" and ! 584: "compare" instructions because they don't have any output operands. 1.1.1.3 root 585: 1.1.1.4 ! root 586: If you are writing a header file that should be includable in ANSI C ! 587: programs, write `__asm__' instead of `asm'. *Note Alternate Keywords::. 1.1.1.3 root 588: 1.1.1.4 ! root 589: ! 590: File: gcc.info, Node: Asm Labels, Next: Explicit Reg Vars, Prev: Extended Asm, Up: Extensions 1.1.1.3 root 591: 1.1.1.4 ! root 592: Controlling Names Used in Assembler Code ! 593: ======================================== 1.1.1.3 root 594: 1.1.1.4 ! root 595: You can specify the name to be used in the assembler code for a C ! 596: function or variable by writing the `asm' (or `__asm__') keyword after ! 597: the declarator as follows: ! 598: ! 599: int foo asm ("myfoo") = 2; ! 600: ! 601: This specifies that the name to be used for the variable `foo' in the ! 602: assembler code should be `myfoo' rather than the usual `_foo'. ! 603: ! 604: On systems where an underscore is normally prepended to the name of ! 605: a C function or variable, this feature allows you to define names for ! 606: the linker that do not start with an underscore. ! 607: ! 608: You cannot use `asm' in this way in a function *definition*; but you ! 609: can get the same effect by writing a declaration for the function ! 610: before its definition and putting `asm' there, like this: ! 611: ! 612: extern func () asm ("FUNC"); ! 613: ! 614: func (x, y) ! 615: int x, y; ! 616: ... ! 617: ! 618: It is up to you to make sure that the assembler names you choose do ! 619: not conflict with any other assembler symbols. Also, you must not use a ! 620: register name; that would produce completely invalid assembler code. ! 621: GNU CC does not as yet have the ability to store static variables in ! 622: registers. Perhaps that will be added. 1.1.1.3 root 623: 1.1.1.4 ! root 624: ! 625: File: gcc.info, Node: Explicit Reg Vars, Next: Alternate Keywords, Prev: Asm Labels, Up: Extensions 1.1.1.3 root 626: 1.1.1.4 ! root 627: Variables in Specified Registers ! 628: ================================ 1.1.1.3 root 629: 1.1.1.4 ! root 630: GNU C allows you to put a few global variables into specified ! 631: hardware registers. You can also specify the register in which an ! 632: ordinary register variable should be allocated. ! 633: ! 634: * Global register variables reserve registers throughout the program. ! 635: This may be useful in programs such as programming language ! 636: interpreters which have a couple of global variables that are ! 637: accessed very often. ! 638: ! 639: * Local register variables in specific registers do not reserve the ! 640: registers. The compiler's data flow analysis is capable of ! 641: determining where the specified registers contain live values, and ! 642: where they are available for other uses. ! 643: ! 644: These local variables are sometimes convenient for use with the ! 645: extended `asm' feature (*note Extended Asm::.), if you want to ! 646: write one output of the assembler instruction directly into a ! 647: particular register. (This will work provided the register you ! 648: specify fits the constraints specified for that operand in the ! 649: `asm'.) 1.1.1.3 root 650: 1.1.1.4 ! root 651: * Menu: 1.1.1.3 root 652: 1.1.1.4 ! root 653: * Global Reg Vars:: ! 654: * Local Reg Vars:: 1.1.1.3 root 655: 656: 1.1.1.4 ! root 657: File: gcc.info, Node: Global Reg Vars, Next: Local Reg Vars, Up: Explicit Reg Vars 1.1.1.3 root 658: 1.1.1.4 ! root 659: Defining Global Register Variables ! 660: ---------------------------------- 1.1.1.3 root 661: 1.1.1.4 ! root 662: You can define a global register variable in GNU C like this: 1.1.1.3 root 663: 1.1.1.4 ! root 664: register int *foo asm ("a5"); 1.1.1.3 root 665: 1.1.1.4 ! root 666: Here `a5' is the name of the register which should be used. Choose a ! 667: register which is normally saved and restored by function calls on your ! 668: machine, so that library routines will not clobber it. ! 669: ! 670: Naturally the register name is cpu-dependent, so you would need to ! 671: conditionalize your program according to cpu type. The register `a5' ! 672: would be a good choice on a 68000 for a variable of pointer type. On ! 673: machines with register windows, be sure to choose a "global" register ! 674: that is not affected magically by the function call mechanism. ! 675: ! 676: In addition, operating systems on one type of cpu may differ in how ! 677: they name the registers; then you would need additional conditionals. ! 678: For example, some 68000 operating systems call this register `%a5'. ! 679: ! 680: Eventually there may be a way of asking the compiler to choose a ! 681: register automatically, but first we need to figure out how it should ! 682: choose and how to enable you to guide the choice. No solution is ! 683: evident. ! 684: ! 685: Defining a global register variable in a certain register reserves ! 686: that register entirely for this use, at least within the current ! 687: compilation. The register will not be allocated for any other purpose ! 688: in the functions in the current compilation. The register will not be ! 689: saved and restored by these functions. Stores into this register are ! 690: never deleted even if they would appear to be dead, but references may ! 691: be deleted or moved or simplified. ! 692: ! 693: It is not safe to access the global register variables from signal ! 694: handlers, or from more than one thread of control, because the system ! 695: library routines may temporarily use the register for other things ! 696: (unless you recompile them specially for the task at hand). ! 697: ! 698: It is not safe for one function that uses a global register variable ! 699: to call another such function `foo' by way of a third function `lose' ! 700: that was compiled without knowledge of this variable (i.e. in a ! 701: different source file in which the variable wasn't declared). This is ! 702: because `lose' might save the register and put some other value there. ! 703: For example, you can't expect a global register variable to be ! 704: available in the comparison-function that you pass to `qsort', since ! 705: `qsort' might have put something else in that register. (If you are ! 706: prepared to recompile `qsort' with the same global register variable, ! 707: you can solve this problem.) ! 708: ! 709: If you want to recompile `qsort' or other source files which do not ! 710: actually use your global register variable, so that they will not use ! 711: that register for any other purpose, then it suffices to specify the ! 712: compiler option `-ffixed-REG'. You need not actually add a global ! 713: register declaration to their source code. ! 714: ! 715: A function which can alter the value of a global register variable ! 716: cannot safely be called from a function compiled without this variable, ! 717: because it could clobber the value the caller expects to find there on ! 718: return. Therefore, the function which is the entry point into the part ! 719: of the program that uses the global register variable must explicitly ! 720: save and restore the value which belongs to its caller. ! 721: ! 722: On most machines, `longjmp' will restore to each global register ! 723: variable the value it had at the time of the `setjmp'. On some ! 724: machines, however, `longjmp' will not change the value of global ! 725: register variables. To be portable, the function that called `setjmp' ! 726: should make other arrangements to save the values of the global register ! 727: variables, and to restore them in a `longjmp'. This way, the same ! 728: thing will happen regardless of what `longjmp' does. ! 729: ! 730: All global register variable declarations must precede all function ! 731: definitions. If such a declaration could appear after function ! 732: definitions, the declaration would be too late to prevent the register ! 733: from being used for other purposes in the preceding functions. ! 734: ! 735: Global register variables may not have initial values, because an ! 736: executable file has no means to supply initial contents for a register. ! 737: ! 738: On the Sparc, there are reports that g3 ... g7 are suitable ! 739: registers, but certain library functions, such as `getwd', as well as ! 740: the subroutines for division and remainder, modify g3 and g4. g1 and ! 741: g2 are local temporaries. 1.1.1.3 root 742: 1.1.1.4 ! root 743: On the 68000, a2 ... a5 should be suitable, as should d2 ... d7. Of ! 744: course, it will not do to use more than a few of those. 1.1 root 745: 746: 1.1.1.4 ! root 747: File: gcc.info, Node: Local Reg Vars, Prev: Global Reg Vars, Up: Explicit Reg Vars 1.1.1.3 root 748: 1.1.1.4 ! root 749: Specifying Registers for Local Variables ! 750: ---------------------------------------- 1.1.1.3 root 751: 1.1.1.4 ! root 752: You can define a local register variable with a specified register ! 753: like this: 1.1.1.3 root 754: 1.1.1.4 ! root 755: register int *foo asm ("a5"); ! 756: ! 757: Here `a5' is the name of the register which should be used. Note that ! 758: this is the same syntax used for defining global register variables, ! 759: but for a local variable it would appear within a function. ! 760: ! 761: Naturally the register name is cpu-dependent, but this is not a ! 762: problem, since specific registers are most often useful with explicit ! 763: assembler instructions (*note Extended Asm::.). Both of these things ! 764: generally require that you conditionalize your program according to cpu ! 765: type. ! 766: ! 767: In addition, operating systems on one type of cpu may differ in how ! 768: they name the registers; then you would need additional conditionals. ! 769: For example, some 68000 operating systems call this register `%a5'. ! 770: ! 771: Eventually there may be a way of asking the compiler to choose a ! 772: register automatically, but first we need to figure out how it should ! 773: choose and how to enable you to guide the choice. No solution is ! 774: evident. ! 775: ! 776: Defining such a register variable does not reserve the register; it ! 777: remains available for other uses in places where flow control determines ! 778: the variable's value is not live. However, these registers are made ! 779: unavailable for use in the reload pass. I would not be surprised if ! 780: excessive use of this feature leaves the compiler too few available ! 781: registers to compile certain functions. 1.1.1.3 root 782: 783: 1.1.1.4 ! root 784: File: gcc.info, Node: Alternate Keywords, Next: Incomplete Enums, Prev: Explicit Reg Vars, Up: Extensions 1.1.1.3 root 785: 1.1.1.4 ! root 786: Alternate Keywords ! 787: ================== 1.1.1.3 root 788: 1.1.1.4 ! root 789: The option `-traditional' disables certain keywords; `-ansi' ! 790: disables certain others. This causes trouble when you want to use GNU C ! 791: extensions, or ANSI C features, in a general-purpose header file that ! 792: should be usable by all programs, including ANSI C programs and ! 793: traditional ones. The keywords `asm', `typeof' and `inline' cannot be ! 794: used since they won't work in a program compiled with `-ansi', while ! 795: the keywords `const', `volatile', `signed', `typeof' and `inline' won't ! 796: work in a program compiled with `-traditional'. ! 797: ! 798: The way to solve these problems is to put `__' at the beginning and ! 799: end of each problematical keyword. For example, use `__asm__' instead ! 800: of `asm', `__const__' instead of `const', and `__inline__' instead of ! 801: `inline'. ! 802: ! 803: Other C compilers won't accept these alternative keywords; if you ! 804: want to compile with another compiler, you can define the alternate ! 805: keywords as macros to replace them with the customary keywords. It ! 806: looks like this: 1.1.1.3 root 807: 1.1.1.4 ! root 808: #ifndef __GNUC__ ! 809: #define __asm__ asm ! 810: #endif 1.1.1.3 root 811: 1.1.1.4 ! root 812: `-pedantic' causes warnings for many GNU C extensions. You can ! 813: prevent such warnings within one expression by writing `__extension__' ! 814: before the expression. `__extension__' has no effect aside from this. 1.1.1.3 root 815: 816: 1.1.1.4 ! root 817: File: gcc.info, Node: Incomplete Enums, Prev: Alternate Keywords, Up: Extensions 1.1 root 818: 1.1.1.4 ! root 819: Incomplete `enum' Types ! 820: ======================= ! 821: ! 822: You can define an `enum' tag without specifying its possible values. ! 823: This results in an incomplete type, much like what you get if you write ! 824: `struct foo' without describing the elements. A later declaration ! 825: which does specify the possible values completes the type. ! 826: ! 827: You can't allocate variables or storage using the type while it is ! 828: incomplete. However, you can work with pointers to that type. ! 829: ! 830: This extension may not be very useful, but it makes the handling of ! 831: `enum' more consistent with the way `struct' and `union' are handled. ! 832: ! 833: ! 834: File: gcc.info, Node: Trouble, Next: Bugs, Prev: Extensions, Up: Top ! 835: ! 836: Known Causes of Trouble with GNU CC ! 837: *********************************** ! 838: ! 839: This section describes known problems that affect users of GNU CC. ! 840: Most of these are not GNU CC bugs per se--if they were, we would fix ! 841: them. But the result for a user may be like the result of a bug. ! 842: ! 843: Some of these problems are due to bugs in other software, some are ! 844: missing features that are too much work to add, and some are places ! 845: where people's opinions differ as to what is best. 1.1 root 846: 847: * Menu: 848: 1.1.1.4 ! root 849: * Actual Bugs:: Bugs we will fix later. ! 850: * Installation Problems:: Problems that manifest when you install GNU CC. ! 851: * Cross-Compiler Problems:: Common problems of cross compiling with GNU CC. ! 852: * Interoperation:: Problems using GNU CC with other compilers, ! 853: and with certain linkers, assemblers and debuggers. ! 854: * Incompatibilities:: GNU CC is incompatible with traditional C. ! 855: * Disappointments:: Regrettable things we can't change, but not quite bugs. ! 856: * Protoize Caveats:: Things to watch out for when using `protoize'. ! 857: * Non-bugs:: Things we think are right, but some others disagree. 1.1 root 858: 859: 1.1.1.4 ! root 860: File: gcc.info, Node: Actual Bugs, Next: Installation Problems, Up: Trouble 1.1 root 861: 1.1.1.4 ! root 862: Actual Bugs We Haven't Fixed Yet ! 863: ================================ 1.1 root 864: 1.1.1.4 ! root 865: * Loop unrolling doesn't work properly for certain C++ programs. ! 866: This is because of difficulty in updating the debugging ! 867: information within the loop being unrolled. We plan to revamp the ! 868: representation of debugging information so that this will work ! 869: properly, but we have not done this in version 2.3 because we ! 870: don't want to delay it any further. 1.1 root 871: 872: 1.1.1.4 ! root 873: File: gcc.info, Node: Installation Problems, Next: Cross-Compiler Problems, Prev: Actual Bugs, Up: Trouble 1.1 root 874: 1.1.1.4 ! root 875: Installation Problems ! 876: ===================== 1.1 root 877: 1.1.1.4 ! root 878: This is a list of problems (and some apparent problems which don't ! 879: really mean anything is wrong) that show up during installation of GNU ! 880: CC. ! 881: ! 882: * On certain systems, defining certain environment variables such as ! 883: `CC' can interfere with the functioning of `make'. ! 884: ! 885: * If you encounter seemingly strange errors when trying to build the ! 886: compiler in a directory other than the source directory, it could ! 887: be because you have previously configured the compiler in the ! 888: source directory. Make sure you have done all the necessary ! 889: preparations. *Note Other Dir::. ! 890: ! 891: * In previous versions of GNU CC, the `gcc' driver program looked for ! 892: `as' and `ld' in various places such as files beginning with ! 893: `/usr/local/lib/gcc-'. GNU CC version 2 looks for them in the ! 894: directory `/usr/local/lib/gcc-lib/TARGET/VERSION'. ! 895: ! 896: Thus, to use a version of `as' or `ld' that is not the system ! 897: default, for example `gas' or GNU `ld', you must put them in that ! 898: directory (or make links to them from that directory). ! 899: ! 900: * Some commands executed when making the compiler may fail (return a ! 901: non-zero status) and be ignored by `make'. These failures, which ! 902: are often due to files that were not found, are expected, and can ! 903: safely be ignored. ! 904: ! 905: * It is normal to have warnings in compiling certain files about ! 906: unreachable code and about enumeration type clashes. These files' ! 907: names begin with `insn-'. ! 908: ! 909: * Sometimes `make' recompiles parts of the compiler when installing ! 910: the compiler. In one case, this was traced down to a bug in ! 911: `make'. Either ignore the problem or switch to GNU Make. ! 912: ! 913: * On some 386 systems, building the compiler never finishes because ! 914: `enquire' hangs due to a hardware problem in the motherboard--it ! 915: reports floating point exceptions to the kernel incorrectly. You ! 916: can install GNU CC except for `float.h' by patching out the ! 917: command to run `enquire'. You may also be able to fix the problem ! 918: for real by getting a replacement motherboard. This problem was ! 919: observed in Revision E of the Micronics motherboard, and is fixed ! 920: in Revision F. ! 921: ! 922: * On some 386 systems, GNU CC crashes trying to compile `enquire.c'. ! 923: This happens on machines that don't have a 387 FPU chip. On 386 ! 924: machines, the system kernel is supposed to emulate the 387 when you ! 925: don't have one. The crash is due to a bug in the emulator. ! 926: ! 927: One of these systems is the Unix from Interactive Systems: 386/ix. ! 928: On this system, an alternate emulator is provided, and it does ! 929: work. To use it, execute this command as super-user: ! 930: ! 931: ln /etc/emulator.rel1 /etc/emulator ! 932: ! 933: and then reboot the system. (The default emulator file remains ! 934: present under the name `emulator.dflt'.) ! 935: ! 936: If you have such a problem on the SCO system, try using ! 937: `/etc/emulator.att'. ! 938: ! 939: Another system which has this problem is Esix. We don't know ! 940: whether it has an alternate emulator that works. ! 941: ! 942: * Sometimes on a Sun 4 you may observe a crash in the program ! 943: `genflags' or `genoutput' while building GNU CC. This is said to ! 944: be due to a bug in `sh'. You can probably get around it by running ! 945: `genflags' or `genoutput' manually and then retrying the `make'. ! 946: ! 947: * If you use the 1.31 version of the MIPS assembler (such as was ! 948: shipped with Ultrix 3.1), you will need to use the ! 949: -fno-delayed-branch switch when optimizing floating point code. ! 950: Otherwise, the assembler will complain when the GCC compiler fills ! 951: a branch delay slot with a floating point instruction, such as ! 952: add.d. ! 953: ! 954: * Users have reported some problems with version 2.0 of the MIPS ! 955: compiler tools that were shipped with Ultrix 4.1. Version 2.10 ! 956: which came with Ultrix 4.2 seems to work fine. ! 957: ! 958: * Some versions of the MIPS linker will issue an assertion failure ! 959: when linking code that uses `alloca' against shared libraries on ! 960: RISC-OS 5.0, and DEC's OSF/1 systems. This is a bug in the ! 961: linker, that is supposed to be fixed in future revisions. To ! 962: protect against this, GCC passes `-non_shared' to the linker ! 963: unless you pass an explicit `-shared' or `-call_shared' switch. ! 964: ! 965: * On System V release 3, you may get this error message while ! 966: linking: ! 967: ! 968: ld fatal: failed to write symbol name SOMETHING ! 969: in strings table for file WHATEVER ! 970: ! 971: This indicates that the disk is full or your ULIMIT won't allow ! 972: the file to be as large as it needs to be. ! 973: ! 974: * On HP 9000 series 300 or 400 running HP-UX release 8.0, there is a ! 975: bug in the assembler that must be fixed before GNU CC can be ! 976: built. This bug manifests itself during the first stage of ! 977: compilation, while building `libgcc2.a': ! 978: ! 979: _floatdisf ! 980: cc1: warning: `-g' option not supported on this version of GCC ! 981: cc1: warning: `-g1' option not supported on this version of GCC ! 982: ./gcc: Internal compiler error: program as got fatal signal 11 ! 983: ! 984: A patched version of the assembler is available by anonymous ftp ! 985: from `altdorf.ai.mit.edu' as the file ! 986: `archive/cph/hpux-8.0-assembler'. If you have HP software support, ! 987: the patch can also be obtained directly from HP, as described in ! 988: the following note: ! 989: ! 990: This is the patched assembler, to patch SR#1653-010439, where ! 991: the assembler aborts on floating point constants. ! 992: ! 993: The bug is not really in the assembler, but in the shared ! 994: library version of the function "cvtnum(3c)". The bug on ! 995: "cvtnum(3c)" is SR#4701-078451. Anyway, the attached ! 996: assembler uses the archive library version of "cvtnum(3c)" ! 997: and thus does not exhibit the bug. ! 998: ! 999: This patch is also known as PHCO_0800. ! 1000: ! 1001: * Another assembler problem on the HP PA results in an error message ! 1002: like this while compiling part of `libgcc2.a': ! 1003: ! 1004: as: /usr/tmp/cca08196.s @line#30 [err#1060] ! 1005: Argument 1 or 3 in FARG upper ! 1006: - lookahead = RTNVAL=GR ! 1007: ! 1008: This happens because HP changed the assembler syntax after system ! 1009: release 8.02. GNU CC assumes the newer syntax; if your assembler ! 1010: wants the older syntax, comment out this line in the file ! 1011: `pa1-hpux.h': ! 1012: ! 1013: #define HP_FP_ARG_DESCRIPTOR_REVERSED ! 1014: ! 1015: * Some versions of the Pyramid C compiler are reported to be unable ! 1016: to compile GNU CC. You must use an older version of GNU CC for ! 1017: bootstrapping. One indication of this problem is if you get a ! 1018: crash when GNU CC compiles the function `muldi3' in file ! 1019: `libgcc2.c'. ! 1020: ! 1021: You may be able to succeed by getting GNU CC version 1, installing ! 1022: it, and using it to compile GNU CC version 2. The bug in the ! 1023: Pyramid C compiler does not seem to affect GNU CC version 1. ! 1024: ! 1025: * On the Tower models 4N0 and 6N0, by default a process is not ! 1026: allowed to have more than one megabyte of memory. GNU CC cannot ! 1027: compile itself (or many other programs) with `-O' in that much ! 1028: memory. ! 1029: ! 1030: To solve this problem, reconfigure the kernel adding the following ! 1031: line to the configuration file: ! 1032: ! 1033: MAXUMEM = 4096 ! 1034: ! 1035: * On the Altos 3068, programs compiled with GNU CC won't work unless ! 1036: you fix a kernel bug. This happens using system versions V.2.2 ! 1037: 1.0gT1 and V.2.2 1.0e and perhaps later versions as well. See the ! 1038: file `README.ALTOS'. ! 1039: ! 1040: * You will get several sorts of compilation and linking errors on the ! 1041: we32k if you don't follow the special instructions. *Note WE32K ! 1042: Install::. 1.1 root 1043: 1.1.1.4 ! root 1044: ! 1045: File: gcc.info, Node: Cross-Compiler Problems, Next: Interoperation, Prev: Installation Problems, Up: Trouble 1.1 root 1046: 1.1.1.4 ! root 1047: Cross-Compiler Problems ! 1048: ======================= ! 1049: ! 1050: * Cross compilation can run into trouble for certain machines because ! 1051: some target machines' assemblers require floating point numbers to ! 1052: be written as *integer* constants in certain contexts. ! 1053: ! 1054: The compiler writes these integer constants by examining the ! 1055: floating point value as an integer and printing that integer, ! 1056: because this is simple to write and independent of the details of ! 1057: the floating point representation. But this does not work if the ! 1058: compiler is running on a different machine with an incompatible ! 1059: floating point format, or even a different byte-ordering. ! 1060: ! 1061: In addition, correct constant folding of floating point values ! 1062: requires representing them in the target machine's format. (The C ! 1063: standard does not quite require this, but in practice it is the ! 1064: only way to win.) ! 1065: ! 1066: It is now possible to overcome these problems by defining macros ! 1067: such as `REAL_VALUE_TYPE'. But doing so is a substantial amount of ! 1068: work for each target machine. *Note Cross-compilation::. ! 1069: ! 1070: * At present, the program `mips-tfile' which adds debug support to ! 1071: object files on MIPS systems does not work in a cross compile ! 1072: environment. 1.1 root 1073: 1074:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.