![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-11 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-11 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.7 root 1: This is Info file gcc.info, produced by Makeinfo-1.55 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:
1.1.1.8 ! root 6: Published by the Free Software Foundation 59 Temple Place - Suite 330
! 7: Boston, MA 02111-1307 USA
1.1.1.5 root 8:
1.1.1.8 ! root 9: Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995 Free Software
! 10: Foundation, Inc.
1.1 root 11:
1.1.1.3 root 12: Permission is granted to make and distribute verbatim copies of this
13: manual provided the copyright notice and this permission notice are
14: preserved on all copies.
1.1 root 15:
16: Permission is granted to copy and distribute modified versions of
17: this manual under the conditions for verbatim copying, provided also
1.1.1.7 root 18: that the sections entitled "GNU General Public License," "Funding for
19: Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
20: included exactly as in the original, and provided that the entire
21: resulting derived work is distributed under the terms of a permission
22: notice identical to this one.
1.1 root 23:
24: Permission is granted to copy and distribute translations of this
25: manual into another language, under the above conditions for modified
1.1.1.3 root 26: versions, except that the sections entitled "GNU General Public
1.1.1.7 root 27: License," "Funding for Free Software," and "Protect Your Freedom--Fight
28: `Look And Feel'", and this permission notice, may be included in
29: translations approved by the Free Software Foundation instead of in the
30: original English.
1.1.1.3 root 31:
32:
1.1.1.8 ! root 33: File: gcc.info, Node: Installation Problems, Next: Cross-Compiler Problems, Prev: Actual Bugs, Up: Trouble
1.1.1.6 root 34:
1.1.1.8 ! root 35: Installation Problems
! 36: =====================
1.1.1.6 root 37:
1.1.1.8 ! root 38: This is a list of problems (and some apparent problems which don't
! 39: really mean anything is wrong) that show up during installation of GNU
! 40: CC.
1.1.1.6 root 41:
1.1.1.8 ! root 42: * On certain systems, defining certain environment variables such as
! 43: `CC' can interfere with the functioning of `make'.
1.1.1.6 root 44:
1.1.1.8 ! root 45: * If you encounter seemingly strange errors when trying to build the
! 46: compiler in a directory other than the source directory, it could
! 47: be because you have previously configured the compiler in the
! 48: source directory. Make sure you have done all the necessary
! 49: preparations. *Note Other Dir::.
1.1.1.6 root 50:
1.1.1.8 ! root 51: * If you build GNU CC on a BSD system using a directory stored in a
! 52: System V file system, problems may occur in running `fixincludes'
! 53: if the System V file system doesn't support symbolic links. These
! 54: problems result in a failure to fix the declaration of `size_t' in
! 55: `sys/types.h'. If you find that `size_t' is a signed type and
! 56: that type mismatches occur, this could be the cause.
1.1.1.6 root 57:
1.1.1.8 ! root 58: The solution is not to use such a directory for building GNU CC.
1.1.1.7 root 59:
1.1.1.8 ! root 60: * In previous versions of GNU CC, the `gcc' driver program looked for
! 61: `as' and `ld' in various places; for example, in files beginning
! 62: with `/usr/local/lib/gcc-'. GNU CC version 2 looks for them in
! 63: the directory `/usr/local/lib/gcc-lib/TARGET/VERSION'.
! 64:
! 65: Thus, to use a version of `as' or `ld' that is not the system
! 66: default, for example `gas' or GNU `ld', you must put them in that
! 67: directory (or make links to them from that directory).
! 68:
! 69: * Some commands executed when making the compiler may fail (return a
! 70: non-zero status) and be ignored by `make'. These failures, which
! 71: are often due to files that were not found, are expected, and can
! 72: safely be ignored.
! 73:
! 74: * It is normal to have warnings in compiling certain files about
! 75: unreachable code and about enumeration type clashes. These files'
! 76: names begin with `insn-'. Also, `real.c' may get some warnings
! 77: that you can ignore.
! 78:
! 79: * Sometimes `make' recompiles parts of the compiler when installing
! 80: the compiler. In one case, this was traced down to a bug in
! 81: `make'. Either ignore the problem or switch to GNU Make.
! 82:
! 83: * If you have installed a program known as purify, you may find that
! 84: it causes errors while linking `enquire', which is part of building
! 85: GNU CC. The fix is to get rid of the file `real-ld' which purify
! 86: installs--so that GNU CC won't try to use it.
! 87:
! 88: * On Linux SLS 1.01, there is a problem with `libc.a': it does not
! 89: contain the obstack functions. However, GNU CC assumes that the
! 90: obstack functions are in `libc.a' when it is the GNU C library.
! 91: To work around this problem, change the `__GNU_LIBRARY__'
! 92: conditional around line 31 to `#if 1'.
! 93:
! 94: * On some 386 systems, building the compiler never finishes because
! 95: `enquire' hangs due to a hardware problem in the motherboard--it
! 96: reports floating point exceptions to the kernel incorrectly. You
! 97: can install GNU CC except for `float.h' by patching out the
! 98: command to run `enquire'. You may also be able to fix the problem
! 99: for real by getting a replacement motherboard. This problem was
! 100: observed in Revision E of the Micronics motherboard, and is fixed
! 101: in Revision F. It has also been observed in the MYLEX MXA-33
! 102: motherboard.
! 103:
! 104: If you encounter this problem, you may also want to consider
! 105: removing the FPU from the socket during the compilation.
! 106: Alternatively, if you are running SCO Unix, you can reboot and
! 107: force the FPU to be ignored. To do this, type `hd(40)unix auto
! 108: ignorefpu'.
! 109:
! 110: * On some 386 systems, GNU CC crashes trying to compile `enquire.c'.
! 111: This happens on machines that don't have a 387 FPU chip. On 386
! 112: machines, the system kernel is supposed to emulate the 387 when you
! 113: don't have one. The crash is due to a bug in the emulator.
! 114:
! 115: One of these systems is the Unix from Interactive Systems: 386/ix.
! 116: On this system, an alternate emulator is provided, and it does
! 117: work. To use it, execute this command as super-user:
! 118:
! 119: ln /etc/emulator.rel1 /etc/emulator
! 120:
! 121: and then reboot the system. (The default emulator file remains
! 122: present under the name `emulator.dflt'.)
! 123:
! 124: Try using `/etc/emulator.att', if you have such a problem on the
! 125: SCO system.
! 126:
! 127: Another system which has this problem is Esix. We don't know
! 128: whether it has an alternate emulator that works.
! 129:
! 130: On NetBSD 0.8, a similar problem manifests itself as these error
! 131: messages:
! 132:
! 133: enquire.c: In function `fprop':
! 134: enquire.c:2328: floating overflow
! 135:
! 136: * On SCO systems, when compiling GNU CC with the system's compiler,
! 137: do not use `-O'. Some versions of the system's compiler miscompile
! 138: GNU CC with `-O'.
! 139:
! 140: * Sometimes on a Sun 4 you may observe a crash in the program
! 141: `genflags' or `genoutput' while building GNU CC. This is said to
! 142: be due to a bug in `sh'. You can probably get around it by running
! 143: `genflags' or `genoutput' manually and then retrying the `make'.
! 144:
! 145: * On Solaris 2, executables of GNU CC version 2.0.2 are commonly
! 146: available, but they have a bug that shows up when compiling current
! 147: versions of GNU CC: undefined symbol errors occur during assembly
! 148: if you use `-g'.
! 149:
! 150: The solution is to compile the current version of GNU CC without
! 151: `-g'. That makes a working compiler which you can use to recompile
! 152: with `-g'.
! 153:
! 154: * Solaris 2 comes with a number of optional OS packages. Some of
! 155: these packages are needed to use GNU CC fully. If you did not
! 156: install all optional packages when installing Solaris, you will
! 157: need to verify that the packages that GNU CC needs are installed.
! 158:
! 159: To check whether an optional package is installed, use the
! 160: `pkginfo' command. To add an optional package, use the `pkgadd'
! 161: command. For further details, see the Solaris documentation.
! 162:
! 163: For Solaris 2.0 and 2.1, GNU CC needs six packages: `SUNWarc',
! 164: `SUNWbtool', `SUNWesu', `SUNWhea', `SUNWlibm', and `SUNWtoo'.
! 165:
! 166: For Solaris 2.2, GNU CC needs an additional seventh package:
! 167: `SUNWsprot'.
! 168:
! 169: * On Solaris 2, trying to use the linker and other tools in
! 170: `/usr/ucb' to install GNU CC has been observed to cause trouble.
! 171: For example, the linker may hang indefinitely. The fix is to
! 172: remove `/usr/ucb' from your `PATH'.
! 173:
! 174: * If you use the 1.31 version of the MIPS assembler (such as was
! 175: shipped with Ultrix 3.1), you will need to use the
! 176: -fno-delayed-branch switch when optimizing floating point code.
! 177: Otherwise, the assembler will complain when the GCC compiler fills
! 178: a branch delay slot with a floating point instruction, such as
! 179: `add.d'.
! 180:
! 181: * If on a MIPS system you get an error message saying "does not have
! 182: gp sections for all it's [sic] sectons [sic]", don't worry about
! 183: it. This happens whenever you use GAS with the MIPS linker, but
! 184: there is not really anything wrong, and it is okay to use the
! 185: output file. You can stop such warnings by installing the GNU
! 186: linker.
! 187:
! 188: It would be nice to extend GAS to produce the gp tables, but they
! 189: are optional, and there should not be a warning about their
! 190: absence.
! 191:
! 192: * In Ultrix 4.0 on the MIPS machine, `stdio.h' does not work with GNU
! 193: CC at all unless it has been fixed with `fixincludes'. This causes
! 194: problems in building GNU CC. Once GNU CC is installed, the
! 195: problems go away.
! 196:
! 197: To work around this problem, when making the stage 1 compiler,
! 198: specify this option to Make:
! 199:
! 200: GCC_FOR_TARGET="./xgcc -B./ -I./include"
! 201:
! 202: When making stage 2 and stage 3, specify this option:
! 203:
! 204: CFLAGS="-g -I./include"
! 205:
! 206: * Users have reported some problems with version 2.0 of the MIPS
! 207: compiler tools that were shipped with Ultrix 4.1. Version 2.10
! 208: which came with Ultrix 4.2 seems to work fine.
! 209:
! 210: Users have also reported some problems with version 2.20 of the
! 211: MIPS compiler tools that were shipped with RISC/os 4.x. The
! 212: earlier version 2.11 seems to work fine.
! 213:
! 214: * Some versions of the MIPS linker will issue an assertion failure
! 215: when linking code that uses `alloca' against shared libraries on
! 216: RISC-OS 5.0, and DEC's OSF/1 systems. This is a bug in the
! 217: linker, that is supposed to be fixed in future revisions. To
! 218: protect against this, GNU CC passes `-non_shared' to the linker
! 219: unless you pass an explicit `-shared' or `-call_shared' switch.
! 220:
! 221: * On System V release 3, you may get this error message while
! 222: linking:
! 223:
! 224: ld fatal: failed to write symbol name SOMETHING
! 225: in strings table for file WHATEVER
! 226:
! 227: This probably indicates that the disk is full or your ULIMIT won't
! 228: allow the file to be as large as it needs to be.
! 229:
! 230: This problem can also result because the kernel parameter `MAXUMEM'
! 231: is too small. If so, you must regenerate the kernel and make the
! 232: value much larger. The default value is reported to be 1024; a
! 233: value of 32768 is said to work. Smaller values may also work.
! 234:
! 235: * On System V, if you get an error like this,
! 236:
! 237: /usr/local/lib/bison.simple: In function `yyparse':
! 238: /usr/local/lib/bison.simple:625: virtual memory exhausted
! 239:
! 240: that too indicates a problem with disk space, ULIMIT, or `MAXUMEM'.
! 241:
! 242: * Current GNU CC versions probably do not work on version 2 of the
! 243: NeXT operating system.
! 244:
! 245: * On NeXTStep 3.0, the Objective C compiler does not work, due,
! 246: apparently, to a kernel bug that it happens to trigger. This
! 247: problem does not happen on 3.1.
! 248:
! 249: * On the Tower models 4N0 and 6N0, by default a process is not
! 250: allowed to have more than one megabyte of memory. GNU CC cannot
! 251: compile itself (or many other programs) with `-O' in that much
! 252: memory.
! 253:
! 254: To solve this problem, reconfigure the kernel adding the following
! 255: line to the configuration file:
! 256:
! 257: MAXUMEM = 4096
1.1.1.6 root 258:
1.1.1.8 ! root 259: * On HP 9000 series 300 or 400 running HP-UX release 8.0, there is a
! 260: bug in the assembler that must be fixed before GNU CC can be
! 261: built. This bug manifests itself during the first stage of
! 262: compilation, while building `libgcc2.a':
1.1.1.7 root 263:
1.1.1.8 ! root 264: _floatdisf
! 265: cc1: warning: `-g' option not supported on this version of GCC
! 266: cc1: warning: `-g1' option not supported on this version of GCC
! 267: ./xgcc: Internal compiler error: program as got fatal signal 11
1.1.1.7 root 268:
1.1.1.8 ! root 269: A patched version of the assembler is available by anonymous ftp
! 270: from `altdorf.ai.mit.edu' as the file
! 271: `archive/cph/hpux-8.0-assembler'. If you have HP software support,
! 272: the patch can also be obtained directly from HP, as described in
! 273: the following note:
1.1.1.7 root 274:
1.1.1.8 ! root 275: This is the patched assembler, to patch SR#1653-010439, where
! 276: the assembler aborts on floating point constants.
! 277:
! 278: The bug is not really in the assembler, but in the shared
! 279: library version of the function "cvtnum(3c)". The bug on
! 280: "cvtnum(3c)" is SR#4701-078451. Anyway, the attached
! 281: assembler uses the archive library version of "cvtnum(3c)"
! 282: and thus does not exhibit the bug.
! 283:
! 284: This patch is also known as PHCO_4484.
! 285:
! 286: * On HP-UX version 8.05, but not on 8.07 or more recent versions,
! 287: the `fixproto' shell script triggers a bug in the system shell.
! 288: If you encounter this problem, upgrade your operating system or
! 289: use BASH (the GNU shell) to run `fixproto'.
! 290:
! 291: * Some versions of the Pyramid C compiler are reported to be unable
! 292: to compile GNU CC. You must use an older version of GNU CC for
! 293: bootstrapping. One indication of this problem is if you get a
! 294: crash when GNU CC compiles the function `muldi3' in file
! 295: `libgcc2.c'.
! 296:
! 297: You may be able to succeed by getting GNU CC version 1, installing
! 298: it, and using it to compile GNU CC version 2. The bug in the
! 299: Pyramid C compiler does not seem to affect GNU CC version 1.
! 300:
! 301: * There may be similar problems on System V Release 3.1 on 386
! 302: systems.
! 303:
! 304: * On the Intel Paragon (an i860 machine), if you are using operating
! 305: system version 1.0, you will get warnings or errors about
! 306: redefinition of `va_arg' when you build GNU CC.
! 307:
! 308: If this happens, then you need to link most programs with the
! 309: library `iclib.a'. You must also modify `stdio.h' as follows:
! 310: before the lines
! 311:
! 312: #if defined(__i860__) && !defined(_VA_LIST)
! 313: #include <va_list.h>
! 314:
! 315: insert the line
! 316:
! 317: #if __PGC__
! 318:
! 319: and after the lines
! 320:
! 321: extern int vprintf(const char *, va_list );
! 322: extern int vsprintf(char *, const char *, va_list );
! 323: #endif
! 324:
! 325: insert the line
! 326:
! 327: #endif /* __PGC__ */
! 328:
! 329: These problems don't exist in operating system version 1.1.
! 330:
! 331: * On the Altos 3068, programs compiled with GNU CC won't work unless
! 332: you fix a kernel bug. This happens using system versions V.2.2
! 333: 1.0gT1 and V.2.2 1.0e and perhaps later versions as well. See the
! 334: file `README.ALTOS'.
! 335:
! 336: * You will get several sorts of compilation and linking errors on the
! 337: we32k if you don't follow the special instructions. *Note
! 338: Configurations::.
! 339:
! 340: * A bug in the HP-UX 8.05 (and earlier) shell will cause the fixproto
! 341: program to report an error of the form:
! 342:
! 343: ./fixproto: sh internal 1K buffer overflow
! 344:
! 345: To fix this, change the first line of the fixproto script to look
! 346: like:
! 347:
! 348: #!/bin/ksh
1.1.1.6 root 349:
350:
1.1.1.8 ! root 351: File: gcc.info, Node: Cross-Compiler Problems, Next: Interoperation, Prev: Installation Problems, Up: Trouble
1.1.1.6 root 352:
1.1.1.8 ! root 353: Cross-Compiler Problems
! 354: =======================
1.1.1.6 root 355:
1.1.1.8 ! root 356: You may run into problems with cross compilation on certain machines,
! 357: for several reasons.
1.1.1.6 root 358:
1.1.1.8 ! root 359: * Cross compilation can run into trouble for certain machines because
! 360: some target machines' assemblers require floating point numbers to
! 361: be written as *integer* constants in certain contexts.
! 362:
! 363: The compiler writes these integer constants by examining the
! 364: floating point value as an integer and printing that integer,
! 365: because this is simple to write and independent of the details of
! 366: the floating point representation. But this does not work if the
! 367: compiler is running on a different machine with an incompatible
! 368: floating point format, or even a different byte-ordering.
! 369:
! 370: In addition, correct constant folding of floating point values
! 371: requires representing them in the target machine's format. (The C
! 372: standard does not quite require this, but in practice it is the
! 373: only way to win.)
! 374:
! 375: It is now possible to overcome these problems by defining macros
! 376: such as `REAL_VALUE_TYPE'. But doing so is a substantial amount of
! 377: work for each target machine. *Note Cross-compilation::.
! 378:
! 379: * At present, the program `mips-tfile' which adds debug support to
! 380: object files on MIPS systems does not work in a cross compile
! 381: environment.
! 382:
! 383:
! 384: File: gcc.info, Node: Interoperation, Next: External Bugs, Prev: Cross-Compiler Problems, Up: Trouble
! 385:
! 386: Interoperation
! 387: ==============
1.1.1.7 root 388:
1.1.1.8 ! root 389: This section lists various difficulties encountered in using GNU C or
! 390: GNU C++ together with other compilers or with the assemblers, linkers,
! 391: libraries and debuggers on certain systems.
! 392:
! 393: * Objective C does not work on the RS/6000.
! 394:
! 395: * GNU C++ does not do name mangling in the same way as other C++
! 396: compilers. This means that object files compiled with one compiler
! 397: cannot be used with another.
! 398:
! 399: This effect is intentional, to protect you from more subtle
! 400: problems. Compilers differ as to many internal details of C++
! 401: implementation, including: how class instances are laid out, how
! 402: multiple inheritance is implemented, and how virtual function
! 403: calls are handled. If the name encoding were made the same, your
! 404: programs would link against libraries provided from other
! 405: compilers--but the programs would then crash when run.
! 406: Incompatible libraries are then detected at link time, rather than
! 407: at run time.
! 408:
! 409: * Older GDB versions sometimes fail to read the output of GNU CC
! 410: version 2. If you have trouble, get GDB version 4.4 or later.
! 411:
! 412: * DBX rejects some files produced by GNU CC, though it accepts
! 413: similar constructs in output from PCC. Until someone can supply a
! 414: coherent description of what is valid DBX input and what is not,
! 415: there is nothing I can do about these problems. You are on your
! 416: own.
! 417:
! 418: * The GNU assembler (GAS) does not support PIC. To generate PIC
! 419: code, you must use some other assembler, such as `/bin/as'.
! 420:
! 421: * On some BSD systems, including some versions of Ultrix, use of
! 422: profiling causes static variable destructors (currently used only
! 423: in C++) not to be run.
! 424:
! 425: * Use of `-I/usr/include' may cause trouble.
! 426:
! 427: Many systems come with header files that won't work with GNU CC
! 428: unless corrected by `fixincludes'. The corrected header files go
! 429: in a new directory; GNU CC searches this directory before
! 430: `/usr/include'. If you use `-I/usr/include', this tells GNU CC to
! 431: search `/usr/include' earlier on, before the corrected headers.
! 432: The result is that you get the uncorrected header files.
! 433:
! 434: Instead, you should use these options (when compiling C programs):
! 435:
! 436: -I/usr/local/lib/gcc-lib/TARGET/VERSION/include -I/usr/include
! 437:
! 438: For C++ programs, GNU CC also uses a special directory that
! 439: defines C++ interfaces to standard C subroutines. This directory
! 440: is meant to be searched *before* other standard include
! 441: directories, so that it takes precedence. If you are compiling
! 442: C++ programs and specifying include directories explicitly, use
! 443: this option first, then the two options above:
! 444:
! 445: -I/usr/local/lib/g++-include
! 446:
! 447: * On some SGI systems, when you use `-lgl_s' as an option, it gets
! 448: translated magically to `-lgl_s -lX11_s -lc_s'. Naturally, this
! 449: does not happen when you use GNU CC. You must specify all three
! 450: options explicitly.
! 451:
! 452: * On a Sparc, GNU CC aligns all values of type `double' on an 8-byte
! 453: boundary, and it expects every `double' to be so aligned. The Sun
! 454: compiler usually gives `double' values 8-byte alignment, with one
! 455: exception: function arguments of type `double' may not be aligned.
! 456:
! 457: As a result, if a function compiled with Sun CC takes the address
! 458: of an argument of type `double' and passes this pointer of type
! 459: `double *' to a function compiled with GNU CC, dereferencing the
! 460: pointer may cause a fatal signal.
! 461:
! 462: One way to solve this problem is to compile your entire program
! 463: with GNU CC. Another solution is to modify the function that is
! 464: compiled with Sun CC to copy the argument into a local variable;
! 465: local variables are always properly aligned. A third solution is
! 466: to modify the function that uses the pointer to dereference it via
! 467: the following function `access_double' instead of directly with
! 468: `*':
! 469:
! 470: inline double
! 471: access_double (double *unaligned_ptr)
! 472: {
! 473: union d2i { double d; int i[2]; };
! 474:
! 475: union d2i *p = (union d2i *) unaligned_ptr;
! 476: union d2i u;
! 477:
! 478: u.i[0] = p->i[0];
! 479: u.i[1] = p->i[1];
! 480:
! 481: return u.d;
! 482: }
! 483:
! 484: Storing into the pointer can be done likewise with the same union.
! 485:
! 486: * On Solaris, the `malloc' function in the `libmalloc.a' library may
! 487: allocate memory that is only 4 byte aligned. Since GNU CC on the
! 488: Sparc assumes that doubles are 8 byte aligned, this may result in a
! 489: fatal signal if doubles are stored in memory allocated by the
! 490: `libmalloc.a' library.
! 491:
! 492: The solution is to not use the `libmalloc.a' library. Use instead
! 493: `malloc' and related functions from `libc.a'; they do not have
! 494: this problem.
! 495:
! 496: * Sun forgot to include a static version of `libdl.a' with some
! 497: versions of SunOS (mainly 4.1). This results in undefined symbols
! 498: when linking static binaries (that is, if you use `-static'). If
! 499: you see undefined symbols `_dlclose', `_dlsym' or `_dlopen' when
! 500: linking, compile and link against the file `mit/util/misc/dlsym.c'
! 501: from the MIT version of X windows.
! 502:
! 503: * The 128-bit long double format that the Sparc port supports
! 504: currently works by using the architecturally defined quad-word
! 505: floating point instructions. Since there is no hardware that
! 506: supports these instructions they must be emulated by the operating
! 507: system. Long doubles do not work in Sun OS versions 4.0.3 and
! 508: earlier, because the kernel emulator uses an obsolete and
! 509: incompatible format. Long doubles do not work in Sun OS version
! 510: 4.1.1 due to a problem in a Sun library. Long doubles do work on
! 511: Sun OS versions 4.1.2 and higher, but GNU CC does not enable them
! 512: by default. Long doubles appear to work in Sun OS 5.x (Solaris
! 513: 2.x).
! 514:
! 515: * On HP-UX version 9.01 on the HP PA, the HP compiler `cc' does not
! 516: compile GNU CC correctly. We do not yet know why. However, GNU CC
! 517: compiled on earlier HP-UX versions works properly on HP-UX 9.01
! 518: and can compile itself properly on 9.01.
! 519:
! 520: * On the HP PA machine, ADB sometimes fails to work on functions
! 521: compiled with GNU CC. Specifically, it fails to work on functions
! 522: that use `alloca' or variable-size arrays. This is because GNU CC
! 523: doesn't generate HP-UX unwind descriptors for such functions. It
! 524: may even be impossible to generate them.
! 525:
! 526: * Debugging (`-g') is not supported on the HP PA machine, unless you
! 527: use the preliminary GNU tools (*note Installation::.).
! 528:
! 529: * Taking the address of a label may generate errors from the HP-UX
! 530: PA assembler. GAS for the PA does not have this problem.
! 531:
! 532: * Using floating point parameters for indirect calls to static
! 533: functions will not work when using the HP assembler. There simply
! 534: is no way for GCC to specify what registers hold arguments for
! 535: static functions when using the HP assembler. GAS for the PA does
! 536: not have this problem.
! 537:
! 538: * In extremely rare cases involving some very large functions you may
! 539: receive errors from the HP linker complaining about an out of
! 540: bounds unconditional branch offset. This used to occur more often
! 541: in previous versions of GNU CC, but is now exceptionally rare. If
! 542: you should run into it, you can work around by making your
! 543: function smaller.
! 544:
! 545: * GNU CC compiled code sometimes emits warnings from the HP-UX
! 546: assembler of the form:
! 547:
! 548: (warning) Use of GR3 when
! 549: frame >= 8192 may cause conflict.
! 550:
! 551: These warnings are harmless and can be safely ignored.
! 552:
! 553: * The current version of the assembler (`/bin/as') for the RS/6000
! 554: has certain problems that prevent the `-g' option in GCC from
! 555: working. Note that `Makefile.in' uses `-g' by default when
! 556: compiling `libgcc2.c'.
! 557:
! 558: IBM has produced a fixed version of the assembler. The upgraded
! 559: assembler unfortunately was not included in any of the AIX 3.2
! 560: update PTF releases (3.2.2, 3.2.3, or 3.2.3e). Users of AIX 3.1
! 561: should request PTF U403044 from IBM and users of AIX 3.2 should
! 562: request PTF U416277. See the file `README.RS6000' for more
! 563: details on these updates.
! 564:
! 565: You can test for the presense of a fixed assembler by using the
! 566: command
! 567:
! 568: as -u < /dev/null
! 569:
! 570: If the command exits normally, the assembler fix already is
! 571: installed. If the assembler complains that "-u" is an unknown
! 572: flag, you need to order the fix.
! 573:
! 574: * On the IBM RS/6000, compiling code of the form
! 575:
! 576: extern int foo;
! 577:
! 578: ... foo ...
! 579:
! 580: static int foo;
! 581:
! 582: will cause the linker to report an undefined symbol `foo'.
! 583: Although this behavior differs from most other systems, it is not a
! 584: bug because redefining an `extern' variable as `static' is
! 585: undefined in ANSI C.
! 586:
! 587: * AIX on the RS/6000 provides support (NLS) for environments outside
! 588: of the United States. Compilers and assemblers use NLS to support
! 589: locale-specific representations of various objects including
! 590: floating-point numbers ("." vs "," for separating decimal
! 591: fractions). There have been problems reported where the library
! 592: linked with GCC does not produce the same floating-point formats
! 593: that the assembler accepts. If you have this problem, set the
! 594: LANG environment variable to "C" or "En_US".
! 595:
! 596: * Even if you specify `-fdollars-in-identifiers', you cannot
! 597: successfully use `$' in identifiers on the RS/6000 due to a
! 598: restriction in the IBM assembler. GAS supports these identifiers.
! 599:
! 600: * On the RS/6000, XLC version 1.3.0.0 will miscompile `jump.c'. XLC
! 601: version 1.3.0.1 or later fixes this problem. You can obtain
! 602: XLC-1.3.0.2 by requesting PTF 421749 from IBM.
! 603:
! 604: * There is an assembler bug in versions of DG/UX prior to 5.4.2.01
! 605: that occurs when the `fldcr' instruction is used. GNU CC uses
! 606: `fldcr' on the 88100 to serialize volatile memory references. Use
! 607: the option `-mno-serialize-volatile' if your version of the
! 608: assembler has this bug.
! 609:
! 610: * On VMS, GAS versions 1.38.1 and earlier may cause spurious warning
! 611: messages from the linker. These warning messages complain of
! 612: mismatched psect attributes. You can ignore them. *Note VMS
! 613: Install::.
! 614:
! 615: * On NewsOS version 3, if you include both of the files `stddef.h'
! 616: and `sys/types.h', you get an error because there are two typedefs
! 617: of `size_t'. You should change `sys/types.h' by adding these
! 618: lines around the definition of `size_t':
! 619:
! 620: #ifndef _SIZE_T
! 621: #define _SIZE_T
! 622: ACTUAL TYPEDEF HERE
! 623: #endif
! 624:
! 625: * On the Alliant, the system's own convention for returning
! 626: structures and unions is unusual, and is not compatible with GNU
! 627: CC no matter what options are used.
! 628:
! 629: * On the IBM RT PC, the MetaWare HighC compiler (hc) uses a different
! 630: convention for structure and union returning. Use the option
! 631: `-mhc-struct-return' to tell GNU CC to use a convention compatible
! 632: with it.
! 633:
! 634: * On Ultrix, the Fortran compiler expects registers 2 through 5 to
! 635: be saved by function calls. However, the C compiler uses
! 636: conventions compatible with BSD Unix: registers 2 through 5 may be
! 637: clobbered by function calls.
! 638:
! 639: GNU CC uses the same convention as the Ultrix C compiler. You can
! 640: use these options to produce code compatible with the Fortran
! 641: compiler:
! 642:
! 643: -fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5
! 644:
! 645: * On the WE32k, you may find that programs compiled with GNU CC do
! 646: not work with the standard shared C library. You may need to link
! 647: with the ordinary C compiler. If you do so, you must specify the
! 648: following options:
! 649:
! 650: -L/usr/local/lib/gcc-lib/we32k-att-sysv/2.7.1 -lgcc -lc_s
! 651:
! 652: The first specifies where to find the library `libgcc.a' specified
! 653: with the `-lgcc' option.
! 654:
! 655: GNU CC does linking by invoking `ld', just as `cc' does, and there
! 656: is no reason why it *should* matter which compilation program you
! 657: use to invoke `ld'. If someone tracks this problem down, it can
! 658: probably be fixed easily.
! 659:
! 660: * On the Alpha, you may get assembler errors about invalid syntax as
! 661: a result of floating point constants. This is due to a bug in the
! 662: C library functions `ecvt', `fcvt' and `gcvt'. Given valid
! 663: floating point numbers, they sometimes print `NaN'.
! 664:
! 665: * On Irix 4.0.5F (and perhaps in some other versions), an assembler
! 666: bug sometimes reorders instructions incorrectly when optimization
! 667: is turned on. If you think this may be happening to you, try
! 668: using the GNU assembler; GAS version 2.1 supports ECOFF on Irix.
! 669:
! 670: Or use the `-noasmopt' option when you compile GNU CC with itself,
! 671: and then again when you compile your program. (This is a temporary
! 672: kludge to turn off assembler optimization on Irix.) If this
! 673: proves to be what you need, edit the assembler spec in the file
! 674: `specs' so that it unconditionally passes `-O0' to the assembler,
! 675: and never passes `-O2' or `-O3'.
1.1.1.6 root 676:
677:
1.1.1.8 ! root 678: File: gcc.info, Node: External Bugs, Next: Incompatibilities, Prev: Interoperation, Up: Trouble
1.1.1.6 root 679:
1.1.1.8 ! root 680: Problems Compiling Certain Programs
! 681: ===================================
! 682:
! 683: Certain programs have problems compiling.
! 684:
! 685: * Parse errors may occur compiling X11 on a Decstation running
! 686: Ultrix 4.2 because of problems in DEC's versions of the X11 header
! 687: files `X11/Xlib.h' and `X11/Xutil.h'. People recommend adding
! 688: `-I/usr/include/mit' to use the MIT versions of the header files,
! 689: using the `-traditional' switch to turn off ANSI C, or fixing the
! 690: header files by adding this:
! 691:
! 692: #ifdef __STDC__
! 693: #define NeedFunctionPrototypes 0
! 694: #endif
! 695:
! 696: * If you have trouble compiling Perl on a SunOS 4 system, it may be
! 697: because Perl specifies `-I/usr/ucbinclude'. This accesses the
! 698: unfixed header files. Perl specifies the options
! 699:
! 700: -traditional -Dvolatile=__volatile__
! 701: -I/usr/include/sun -I/usr/ucbinclude
! 702: -fpcc-struct-return
! 703:
! 704: most of which are unnecessary with GCC 2.4.5 and newer versions.
! 705: You can make a properly working Perl by setting `ccflags' to
! 706: `-fwritable-strings' (implied by the `-traditional' in the
! 707: original options) and `cppflags' to empty in `config.sh', then
! 708: typing `./doSH; make depend; make'.
1.1.1.6 root 709:
1.1.1.8 ! root 710: * On various 386 Unix systems derived from System V, including SCO,
! 711: ISC, and ESIX, you may get error messages about running out of
! 712: virtual memory while compiling certain programs.
! 713:
! 714: You can prevent this problem by linking GNU CC with the GNU malloc
! 715: (which thus replaces the malloc that comes with the system). GNU
! 716: malloc is available as a separate package, and also in the file
! 717: `src/gmalloc.c' in the GNU Emacs 19 distribution.
! 718:
! 719: If you have installed GNU malloc as a separate library package,
! 720: use this option when you relink GNU CC:
! 721:
! 722: MALLOC=/usr/local/lib/libgmalloc.a
! 723:
! 724: Alternatively, if you have compiled `gmalloc.c' from Emacs 19, copy
! 725: the object file to `gmalloc.o' and use this option when you relink
! 726: GNU CC:
! 727:
! 728: MALLOC=gmalloc.o
1.1.1.6 root 729:
730:
1.1.1.8 ! root 731: File: gcc.info, Node: Incompatibilities, Next: Fixed Headers, Prev: External Bugs, Up: Trouble
1.1.1.6 root 732:
1.1.1.8 ! root 733: Incompatibilities of GNU CC
1.1.1.7 root 734: ===========================
1.1.1.6 root 735:
1.1.1.8 ! root 736: There are several noteworthy incompatibilities between GNU C and most
! 737: existing (non-ANSI) versions of C. The `-traditional' option
! 738: eliminates many of these incompatibilities, *but not all*, by telling
! 739: GNU C to behave like the other C compilers.
! 740:
! 741: * GNU CC normally makes string constants read-only. If several
! 742: identical-looking string constants are used, GNU CC stores only one
! 743: copy of the string.
! 744:
! 745: One consequence is that you cannot call `mktemp' with a string
! 746: constant argument. The function `mktemp' always alters the string
! 747: its argument points to.
! 748:
! 749: Another consequence is that `sscanf' does not work on some systems
! 750: when passed a string constant as its format control string or
! 751: input. This is because `sscanf' incorrectly tries to write into
! 752: the string constant. Likewise `fscanf' and `scanf'.
! 753:
! 754: The best solution to these problems is to change the program to use
! 755: `char'-array variables with initialization strings for these
! 756: purposes instead of string constants. But if this is not possible,
! 757: you can use the `-fwritable-strings' flag, which directs GNU CC to
! 758: handle string constants the same way most C compilers do.
! 759: `-traditional' also has this effect, among others.
! 760:
! 761: * `-2147483648' is positive.
! 762:
! 763: This is because 2147483648 cannot fit in the type `int', so
! 764: (following the ANSI C rules) its data type is `unsigned long int'.
! 765: Negating this value yields 2147483648 again.
! 766:
! 767: * GNU CC does not substitute macro arguments when they appear inside
! 768: of string constants. For example, the following macro in GNU CC
! 769:
! 770: #define foo(a) "a"
! 771:
! 772: will produce output `"a"' regardless of what the argument A is.
! 773:
! 774: The `-traditional' option directs GNU CC to handle such cases
! 775: (among others) in the old-fashioned (non-ANSI) fashion.
! 776:
! 777: * When you use `setjmp' and `longjmp', the only automatic variables
! 778: guaranteed to remain valid are those declared `volatile'. This is
! 779: a consequence of automatic register allocation. Consider this
! 780: function:
! 781:
! 782: jmp_buf j;
! 783:
! 784: foo ()
! 785: {
! 786: int a, b;
! 787:
! 788: a = fun1 ();
! 789: if (setjmp (j))
! 790: return a;
! 791:
! 792: a = fun2 ();
! 793: /* `longjmp (j)' may occur in `fun3'. */
! 794: return a + fun3 ();
! 795: }
! 796:
! 797: Here `a' may or may not be restored to its first value when the
! 798: `longjmp' occurs. If `a' is allocated in a register, then its
! 799: first value is restored; otherwise, it keeps the last value stored
! 800: in it.
! 801:
! 802: If you use the `-W' option with the `-O' option, you will get a
! 803: warning when GNU CC thinks such a problem might be possible.
! 804:
! 805: The `-traditional' option directs GNU C to put variables in the
! 806: stack by default, rather than in registers, in functions that call
! 807: `setjmp'. This results in the behavior found in traditional C
! 808: compilers.
! 809:
! 810: * Programs that use preprocessing directives in the middle of macro
! 811: arguments do not work with GNU CC. For example, a program like
! 812: this will not work:
! 813:
! 814: foobar (
! 815: #define luser
! 816: hack)
! 817:
! 818: ANSI C does not permit such a construct. It would make sense to
! 819: support it when `-traditional' is used, but it is too much work to
! 820: implement.
! 821:
! 822: * Declarations of external variables and functions within a block
! 823: apply only to the block containing the declaration. In other
! 824: words, they have the same scope as any other declaration in the
! 825: same place.
! 826:
! 827: In some other C compilers, a `extern' declaration affects all the
! 828: rest of the file even if it happens within a block.
! 829:
! 830: The `-traditional' option directs GNU C to treat all `extern'
! 831: declarations as global, like traditional compilers.
! 832:
! 833: * In traditional C, you can combine `long', etc., with a typedef
! 834: name, as shown here:
! 835:
! 836: typedef int foo;
! 837: typedef long foo bar;
! 838:
! 839: In ANSI C, this is not allowed: `long' and other type modifiers
! 840: require an explicit `int'. Because this criterion is expressed by
! 841: Bison grammar rules rather than C code, the `-traditional' flag
! 842: cannot alter it.
! 843:
! 844: * PCC allows typedef names to be used as function parameters. The
! 845: difficulty described immediately above applies here too.
! 846:
! 847: * PCC allows whitespace in the middle of compound assignment
! 848: operators such as `+='. GNU CC, following the ANSI standard, does
! 849: not allow this. The difficulty described immediately above
! 850: applies here too.
! 851:
! 852: * GNU CC complains about unterminated character constants inside of
! 853: preprocessing conditionals that fail. Some programs have English
! 854: comments enclosed in conditionals that are guaranteed to fail; if
! 855: these comments contain apostrophes, GNU CC will probably report an
! 856: error. For example, this code would produce an error:
! 857:
! 858: #if 0
! 859: You can't expect this to work.
! 860: #endif
! 861:
! 862: The best solution to such a problem is to put the text into an
! 863: actual C comment delimited by `/*...*/'. However, `-traditional'
! 864: suppresses these error messages.
! 865:
! 866: * Many user programs contain the declaration `long time ();'. In the
! 867: past, the system header files on many systems did not actually
! 868: declare `time', so it did not matter what type your program
! 869: declared it to return. But in systems with ANSI C headers, `time'
! 870: is declared to return `time_t', and if that is not the same as
! 871: `long', then `long time ();' is erroneous.
! 872:
! 873: The solution is to change your program to use `time_t' as the
! 874: return type of `time'.
! 875:
! 876: * When compiling functions that return `float', PCC converts it to a
! 877: double. GNU CC actually returns a `float'. If you are concerned
! 878: with PCC compatibility, you should declare your functions to return
! 879: `double'; you might as well say what you mean.
! 880:
! 881: * When compiling functions that return structures or unions, GNU CC
! 882: output code normally uses a method different from that used on most
! 883: versions of Unix. As a result, code compiled with GNU CC cannot
! 884: call a structure-returning function compiled with PCC, and vice
! 885: versa.
! 886:
! 887: The method used by GNU CC is as follows: a structure or union
! 888: which is 1, 2, 4 or 8 bytes long is returned like a scalar. A
! 889: structure or union with any other size is stored into an address
! 890: supplied by the caller (usually in a special, fixed register, but
! 891: on some machines it is passed on the stack). The
! 892: machine-description macros `STRUCT_VALUE' and
! 893: `STRUCT_INCOMING_VALUE' tell GNU CC where to pass this address.
! 894:
! 895: By contrast, PCC on most target machines returns structures and
! 896: unions of any size by copying the data into an area of static
! 897: storage, and then returning the address of that storage as if it
! 898: were a pointer value. The caller must copy the data from that
! 899: memory area to the place where the value is wanted. GNU CC does
! 900: not use this method because it is slower and nonreentrant.
! 901:
! 902: On some newer machines, PCC uses a reentrant convention for all
! 903: structure and union returning. GNU CC on most of these machines
! 904: uses a compatible convention when returning structures and unions
! 905: in memory, but still returns small structures and unions in
! 906: registers.
! 907:
! 908: You can tell GNU CC to use a compatible convention for all
! 909: structure and union returning with the option
! 910: `-fpcc-struct-return'.
! 911:
! 912: * GNU C complains about program fragments such as `0x74ae-0x4000'
! 913: which appear to be two hexadecimal constants separated by the minus
! 914: operator. Actually, this string is a single "preprocessing token".
! 915: Each such token must correspond to one token in C. Since this
! 916: does not, GNU C prints an error message. Although it may appear
! 917: obvious that what is meant is an operator and two values, the ANSI
! 918: C standard specifically requires that this be treated as erroneous.
! 919:
! 920: A "preprocessing token" is a "preprocessing number" if it begins
! 921: with a digit and is followed by letters, underscores, digits,
! 922: periods and `e+', `e-', `E+', or `E-' character sequences.
! 923:
! 924: To make the above program fragment valid, place whitespace in
! 925: front of the minus sign. This whitespace will end the
! 926: preprocessing number.
1.1.1.6 root 927:
928:
1.1.1.8 ! root 929: File: gcc.info, Node: Fixed Headers, Next: Standard Libraries, Prev: Incompatibilities, Up: Trouble
1.1.1.3 root 930:
1.1.1.8 ! root 931: Fixed Header Files
! 932: ==================
1.1.1.3 root 933:
1.1.1.8 ! root 934: GNU CC needs to install corrected versions of some system header
! 935: files. This is because most target systems have some header files that
! 936: won't work with GNU CC unless they are changed. Some have bugs, some
! 937: are incompatible with ANSI C, and some depend on special features of
! 938: other compilers.
! 939:
! 940: Installing GNU CC automatically creates and installs the fixed header
! 941: files, by running a program called `fixincludes' (or for certain
! 942: targets an alternative such as `fixinc.svr4'). Normally, you don't
! 943: need to pay attention to this. But there are cases where it doesn't do
! 944: the right thing automatically.
! 945:
! 946: * If you update the system's header files, such as by installing a
! 947: new system version, the fixed header files of GNU CC are not
! 948: automatically updated. The easiest way to update them is to
! 949: reinstall GNU CC. (If you want to be clever, look in the makefile
! 950: and you can find a shortcut.)
! 951:
! 952: * On some systems, in particular SunOS 4, header file directories
! 953: contain machine-specific symbolic links in certain places. This
! 954: makes it possible to share most of the header files among hosts
! 955: running the same version of SunOS 4 on different machine models.
! 956:
! 957: The programs that fix the header files do not understand this
! 958: special way of using symbolic links; therefore, the directory of
! 959: fixed header files is good only for the machine model used to
! 960: build it.
! 961:
! 962: In SunOS 4, only programs that look inside the kernel will notice
! 963: the difference between machine models. Therefore, for most
! 964: purposes, you need not be concerned about this.
! 965:
! 966: It is possible to make separate sets of fixed header files for the
! 967: different machine models, and arrange a structure of symbolic
! 968: links so as to use the proper set, but you'll have to do this by
! 969: hand.
! 970:
! 971: * On Lynxos, GNU CC by default does not fix the header files. This
! 972: is because bugs in the shell cause the `fixincludes' script to
! 973: fail.
! 974:
! 975: This means you will encounter problems due to bugs in the system
! 976: header files. It may be no comfort that they aren't GNU CC's
! 977: fault, but it does mean that there's nothing for us to do about
! 978: them.
1.1.1.7 root 979:
1.1.1.8 ! root 980:
! 981: File: gcc.info, Node: Standard Libraries, Next: Disappointments, Prev: Fixed Headers, Up: Trouble
! 982:
! 983: Standard Libraries
! 984: ==================
! 985:
! 986: GNU CC by itself attempts to be what the ISO/ANSI C standard calls a
! 987: "conforming freestanding implementation". This means all ANSI C
! 988: language features are available, as well as the contents of `float.h',
! 989: `limits.h', `stdarg.h', and `stddef.h'. The rest of the C library is
! 990: supplied by the vendor of the operating system. If that C library
! 991: doesn't conform to the C standards, then your programs might get
! 992: warnings (especially when using `-Wall') that you don't expect.
! 993:
! 994: For example, the `sprintf' function on SunOS 4.1.3 returns `char *'
! 995: while the C standard says that `sprintf' returns an `int'. The
! 996: `fixincludes' program could make the prototype for this function match
! 997: the Standard, but that would be wrong, since the function will still
! 998: return `char *'.
! 999:
! 1000: If you need a Standard compliant library, then you need to find one,
! 1001: as GNU CC does not provide one. The GNU C library (called `glibc') has
! 1002: been ported to a number of operating systems, and provides ANSI/ISO,
! 1003: POSIX, BSD and SystemV compatibility. You could also ask your operating
! 1004: system vendor if newer libraries are available.
! 1005:
! 1006:
! 1007: File: gcc.info, Node: Disappointments, Next: C++ Misunderstandings, Prev: Standard Libraries, Up: Trouble
1.1.1.7 root 1008:
1.1.1.8 ! root 1009: Disappointments and Misunderstandings
! 1010: =====================================
! 1011:
! 1012: These problems are perhaps regrettable, but we don't know any
! 1013: practical way around them.
! 1014:
! 1015: * Certain local variables aren't recognized by debuggers when you
! 1016: compile with optimization.
! 1017:
! 1018: This occurs because sometimes GNU CC optimizes the variable out of
! 1019: existence. There is no way to tell the debugger how to compute the
! 1020: value such a variable "would have had", and it is not clear that
! 1021: would be desirable anyway. So GNU CC simply does not mention the
! 1022: eliminated variable when it writes debugging information.
! 1023:
! 1024: You have to expect a certain amount of disagreement between the
! 1025: executable and your source code, when you use optimization.
! 1026:
! 1027: * Users often think it is a bug when GNU CC reports an error for code
! 1028: like this:
! 1029:
! 1030: int foo (struct mumble *);
! 1031:
! 1032: struct mumble { ... };
! 1033:
! 1034: int foo (struct mumble *x)
! 1035: { ... }
! 1036:
! 1037: This code really is erroneous, because the scope of `struct
! 1038: mumble' in the prototype is limited to the argument list
! 1039: containing it. It does not refer to the `struct mumble' defined
! 1040: with file scope immediately below--they are two unrelated types
! 1041: with similar names in different scopes.
! 1042:
! 1043: But in the definition of `foo', the file-scope type is used
! 1044: because that is available to be inherited. Thus, the definition
! 1045: and the prototype do not match, and you get an error.
! 1046:
! 1047: This behavior may seem silly, but it's what the ANSI standard
! 1048: specifies. It is easy enough for you to make your code work by
! 1049: moving the definition of `struct mumble' above the prototype.
! 1050: It's not worth being incompatible with ANSI C just to avoid an
! 1051: error for the example shown above.
! 1052:
! 1053: * Accesses to bitfields even in volatile objects works by accessing
! 1054: larger objects, such as a byte or a word. You cannot rely on what
! 1055: size of object is accessed in order to read or write the bitfield;
! 1056: it may even vary for a given bitfield according to the precise
! 1057: usage.
! 1058:
! 1059: If you care about controlling the amount of memory that is
! 1060: accessed, use volatile but do not use bitfields.
! 1061:
! 1062: * GNU CC comes with shell scripts to fix certain known problems in
! 1063: system header files. They install corrected copies of various
! 1064: header files in a special directory where only GNU CC will
! 1065: normally look for them. The scripts adapt to various systems by
! 1066: searching all the system header files for the problem cases that
! 1067: we know about.
! 1068:
! 1069: If new system header files are installed, nothing automatically
! 1070: arranges to update the corrected header files. You will have to
! 1071: reinstall GNU CC to fix the new header files. More specifically,
! 1072: go to the build directory and delete the files `stmp-fixinc' and
! 1073: `stmp-headers', and the subdirectory `include'; then do `make
! 1074: install' again.
! 1075:
! 1076: * On 68000 systems, you can get paradoxical results if you test the
! 1077: precise values of floating point numbers. For example, you can
! 1078: find that a floating point value which is not a NaN is not equal
! 1079: to itself. This results from the fact that the the floating point
! 1080: registers hold a few more bits of precision than fit in a `double'
! 1081: in memory. Compiled code moves values between memory and floating
! 1082: point registers at its convenience, and moving them into memory
! 1083: truncates them.
! 1084:
! 1085: You can partially avoid this problem by using the `-ffloat-store'
! 1086: option (*note Optimize Options::.).
! 1087:
! 1088: * On the MIPS, variable argument functions using `varargs.h' cannot
! 1089: have a floating point value for the first argument. The reason
! 1090: for this is that in the absence of a prototype in scope, if the
! 1091: first argument is a floating point, it is passed in a floating
! 1092: point register, rather than an integer register.
! 1093:
! 1094: If the code is rewritten to use the ANSI standard `stdarg.h'
! 1095: method of variable arguments, and the prototype is in scope at the
! 1096: time of the call, everything will work fine.
1.1.1.5 root 1097:
1098:
1.1.1.8 ! root 1099: File: gcc.info, Node: C++ Misunderstandings, Next: Protoize Caveats, Prev: Disappointments, Up: Trouble
! 1100:
! 1101: Common Misunderstandings with GNU C++
! 1102: =====================================
1.1.1.5 root 1103:
1.1.1.8 ! root 1104: C++ is a complex language and an evolving one, and its standard
! 1105: definition (the ANSI C++ draft standard) is also evolving. As a result,
! 1106: your C++ compiler may occasionally surprise you, even when its behavior
! 1107: is correct. This section discusses some areas that frequently give
! 1108: rise to questions of this sort.
1.1.1.5 root 1109:
1.1.1.8 ! root 1110: * Menu:
! 1111:
! 1112: * Static Definitions:: Static member declarations are not definitions
! 1113: * Temporaries:: Temporaries may vanish before you expect
1.1.1.7 root 1114:
1115:
1.1.1.8 ! root 1116: File: gcc.info, Node: Static Definitions, Next: Temporaries, Up: C++ Misunderstandings
1.1.1.5 root 1117:
1.1.1.8 ! root 1118: Declare *and* Define Static Members
! 1119: -----------------------------------
1.1.1.5 root 1120:
1.1.1.8 ! root 1121: When a class has static data members, it is not enough to *declare*
! 1122: the static member; you must also *define* it. For example:
1.1.1.7 root 1123:
1.1.1.8 ! root 1124: class Foo
1.1.1.7 root 1125: {
1126: ...
1.1.1.8 ! root 1127: void method();
! 1128: static int bar;
! 1129: };
! 1130:
! 1131: This declaration only establishes that the class `Foo' has an `int'
! 1132: named `Foo::bar', and a member function named `Foo::method'. But you
! 1133: still need to define *both* `method' and `bar' elsewhere. According to
! 1134: the draft ANSI standard, you must supply an initializer in one (and
! 1135: only one) source file, such as:
! 1136:
! 1137: int Foo::bar = 0;
! 1138:
! 1139: Other C++ compilers may not correctly implement the standard
! 1140: behavior. As a result, when you switch to `g++' from one of these
! 1141: compilers, you may discover that a program that appeared to work
! 1142: correctly in fact does not conform to the standard: `g++' reports as
! 1143: undefined symbols any static data members that lack definitions.
1.1.1.5 root 1144:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.