Patch to trouble.texi
Joseph S. Myers
jsm@polyomino.org.uk
Sat Sep 25 06:43:00 GMT 2004
This patch removes various obsolete information from trouble.texi:
* Information relating only to systems no longer supported.
* Information only relating to very old versions of assemblers /
linkers / debuggers.
* Information from before floating point was properly emulated for all
targets.
* The statement about -pedantic-errors seems to be about
int f();
int g();
int h() { return (f, g)(1); }
for which 2.7.2.3 gives an error; fixed long ago.
* Static after extern is now a hard error so target-specific
information on it is irrelevant.
* The problems with external programs are not ones recently seen
reported by users, and we should only document frequently seen
problems compiling external software rather than every piece of
software that might have problems compiling on some system.
* Information about regenerating fixincluded headers is updated.
It passes "make info" and "make dvi". Applied to mainline. Quite a
bit of the remaining information is probably also obsolete. Those
entries claimed to be actual bugs should go in Bugzilla if they really
are still present.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 4.0
jsm@polyomino.org.uk (personal mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)
2004-09-25 Joseph S. Myers <jsm@polyomino.org.uk>
* doc/trouble.texi: Remove obsolete information. Update
information on how to regenerate fixincluded headers.
diff -rupN doc.orig/trouble.texi doc/trouble.texi
--- doc.orig/trouble.texi 2004-09-17 18:14:27.000000000 +0000
+++ doc/trouble.texi 2004-09-24 23:39:20.000000000 +0000
@@ -22,7 +22,6 @@ where people's opinions differ as to wha
* Cross-Compiler Problems:: Common problems of cross compiling with GCC.
* Interoperation:: Problems using GCC with other compilers,
and with certain linkers, assemblers and debuggers.
-* External Bugs:: Problems compiling certain programs.
* Incompatibilities:: GCC is incompatible with traditional C.
* Fixed Headers:: GCC uses corrected versions of system header files.
This is necessary, but doesn't always work smoothly.
@@ -52,12 +51,6 @@ The @code{fixproto} script will sometime
@code{jmp_buf} type before that type is defined. To work around this,
edit the offending file and place the typedef in front of the
prototypes.
-
-@item
-@opindex pedantic-errors
-When @option{-pedantic-errors} is specified, GCC will incorrectly give
-an error message when a function name is specified in an expression
-involving the comma operator.
@end itemize
@node Cross-Compiler Problems
@@ -68,29 +61,6 @@ for several reasons.
@itemize @bullet
@item
-Cross compilation can run into trouble for certain machines because
-some target machines' assemblers require floating point numbers to be
-written as @emph{integer} constants in certain contexts.
-
-The compiler writes these integer constants by examining the floating
-point value as an integer and printing that integer, because this is
-simple to write and independent of the details of the floating point
-representation. But this does not work if the compiler is running on
-a different machine with an incompatible floating point format, or
-even a different byte-ordering.
-
-In addition, correct constant folding of floating point values
-requires representing them in the target machine's format.
-(The C standard does not quite require this, but in practice
-it is the only way to win.)
-
-It is now possible to overcome these problems by defining macros such
-as @code{REAL_VALUE_TYPE}. But doing so is a substantial amount of
-work for each target machine.
-@xref{Cross-compilation,,Cross Compilation and Floating Point,
-gccint, GNU Compiler Collection (GCC) Internals}.
-
-@item
At present, the program @file{mips-tfile} which adds debug
support to object files on MIPS systems does not work in a cross
compile environment.
@@ -121,41 +91,10 @@ run. Incompatible libraries are then de
at run time.
@item
-Older GDB versions sometimes fail to read the output of GCC version
-2. If you have trouble, get GDB version 4.4 or later.
-
-@item
-@cindex DBX
-DBX rejects some files produced by GCC, though it accepts similar
-constructs in output from PCC@. Until someone can supply a coherent
-description of what is valid DBX input and what is not, there is
-nothing that can be done about these problems.
-
-@item
-The GNU assembler (GAS) does not support PIC@. To generate PIC code, you
-must use some other assembler, such as @file{/bin/as}.
-
-@item
On some BSD systems, including some versions of Ultrix, use of profiling
causes static variable destructors (currently used only in C++) not to
be run.
-@ignore
-@cindex @code{vfork}, for the Sun-4
-@item
-There is a bug in @code{vfork} on the Sun-4 which causes the registers
-of the child process to clobber those of the parent. Because of this,
-programs that call @code{vfork} are likely to lose when compiled
-optimized with GCC when the child code alters registers which contain
-C variables in the parent. This affects variables which are live in the
-parent across the call to @code{vfork}.
-
-If you encounter this, you can work around the problem by declaring
-variables @code{volatile} in the function that calls @code{vfork}, until
-the problem goes away, or by not declaring them @code{register} and not
-using @option{-O} for those source files.
-@end ignore
-
@item
On some SGI systems, when you use @option{-lgl_s} as an option,
it gets translated magically to @samp{-lgl_s -lX11_s -lc_s}.
@@ -211,32 +150,6 @@ The solution is to not use the @file{lib
this problem.
@item
-Sun forgot to include a static version of @file{libdl.a} with some
-versions of SunOS (mainly 4.1). This results in undefined symbols when
-linking static binaries (that is, if you use @option{-static}). If you
-see undefined symbols @code{_dlclose}, @code{_dlsym} or @code{_dlopen}
-when linking, compile and link against the file
-@file{mit/util/misc/dlsym.c} from the MIT version of X windows.
-
-@item
-The 128-bit long double format that the SPARC port supports currently
-works by using the architecturally defined quad-word floating point
-instructions. Since there is no hardware that supports these
-instructions they must be emulated by the operating system. Long
-doubles do not work in Sun OS versions 4.0.3 and earlier, because the
-kernel emulator uses an obsolete and incompatible format. Long doubles
-do not work in Sun OS version 4.1.1 due to a problem in a Sun library.
-Long doubles do work on Sun OS versions 4.1.2 and higher, but GCC
-does not enable them by default. Long doubles appear to work in Sun OS
-5.x (Solaris 2.x).
-
-@item
-On HP-UX version 9.01 on the HP PA, the HP compiler @code{cc} does not
-compile GCC correctly. We do not yet know why. However, GCC
-compiled on earlier HP-UX versions works properly on HP-UX 9.01 and can
-compile itself properly on 9.01.
-
-@item
On the HP PA machine, ADB sometimes fails to work on functions compiled
with GCC@. Specifically, it fails to work on functions that use
@code{alloca} or variable-size arrays. This is because GCC doesn't
@@ -276,23 +189,6 @@ the form:
These warnings are harmless and can be safely ignored.
@item
-On the IBM RS/6000, compiling code of the form
-
-@smallexample
-extern int foo;
-
-@dots{} foo @dots{}
-
-static int foo;
-@end smallexample
-
-@noindent
-will cause the linker to report an undefined symbol @code{foo}.
-Although this behavior differs from most other systems, it is not a
-bug because redefining an @code{extern} variable as @code{static}
-is undefined in ISO C@.
-
-@item
In extremely rare cases involving some very large functions you may
receive errors from the AIX Assembler complaining about a displacement
that is too large. If you should run into it, you can work around by
@@ -352,58 +248,6 @@ these options to produce code compatible
@smallexample
-fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5
@end smallexample
-
-@item
-On the Alpha, you may get assembler errors about invalid syntax as a
-result of floating point constants. This is due to a bug in the C
-library functions @code{ecvt}, @code{fcvt} and @code{gcvt}. Given valid
-floating point numbers, they sometimes print @samp{NaN}.
-@end itemize
-
-@node External Bugs
-@section Problems Compiling Certain Programs
-
-@c prevent bad page break with this line
-Certain programs have problems compiling.
-
-@itemize @bullet
-@item
-Parse errors may occur compiling X11 on a Decstation running Ultrix 4.2
-because of problems in DEC's versions of the X11 header files
-@file{X11/Xlib.h} and @file{X11/Xutil.h}. People recommend adding
-@option{-I/usr/include/mit} to use the MIT versions of the header files,
-or fixing the header files by adding this:
-
-@smallexample
-#ifdef __STDC__
-#define NeedFunctionPrototypes 0
-#endif
-@end smallexample
-
-@item
-On various 386 Unix systems derived from System V, including SCO, ISC,
-and ESIX, you may get error messages about running out of virtual memory
-while compiling certain programs.
-
-You can prevent this problem by linking GCC with the GNU malloc
-(which thus replaces the malloc that comes with the system). GNU malloc
-is available as a separate package, and also in the file
-@file{src/gmalloc.c} in the GNU Emacs 19 distribution.
-
-If you have installed GNU malloc as a separate library package, use this
-option when you relink GCC:
-
-@smallexample
-MALLOC=/usr/local/lib/libgmalloc.a
-@end smallexample
-
-Alternatively, if you have compiled @file{gmalloc.c} from Emacs 19, copy
-the object file to @file{gmalloc.o} and use this option when you relink
-GCC:
-
-@smallexample
-MALLOC=gmalloc.o
-@end smallexample
@end itemize
@node Incompatibilities
@@ -662,8 +506,7 @@ incompatible with ISO C, and some depend
compilers.
Installing GCC automatically creates and installs the fixed header
-files, by running a program called @code{fixincludes} (or for certain
-targets an alternative such as @code{fixinc.svr4}). Normally, you
+files, by running a program called @code{fixincludes}. Normally, you
don't need to pay attention to this. But there are cases where it
doesn't do the right thing automatically.
@@ -671,35 +514,23 @@ doesn't do the right thing automatically
@item
If you update the system's header files, such as by installing a new
system version, the fixed header files of GCC are not automatically
-updated. The easiest way to update them is to reinstall GCC@. (If
-you want to be clever, look in the makefile and you can find a
-shortcut.)
+updated. They can be updated using the @command{mkheaders} script
+installed in
+@file{@var{libexecdir}/gcc/@var{target}/@var{version}/install-tools/}.
@item
-On some systems, in particular SunOS 4, header file directories contain
+On some systems, header file directories contain
machine-specific symbolic links in certain places. This makes it
possible to share most of the header files among hosts running the
-same version of SunOS 4 on different machine models.
+same version of the system on different machine models.
The programs that fix the header files do not understand this special
way of using symbolic links; therefore, the directory of fixed header
files is good only for the machine model used to build it.
-In SunOS 4, only programs that look inside the kernel will notice the
-difference between machine models. Therefore, for most purposes, you
-need not be concerned about this.
-
It is possible to make separate sets of fixed header files for the
different machine models, and arrange a structure of symbolic links so
as to use the proper set, but you'll have to do this by hand.
-
-@item
-On Lynxos, GCC by default does not fix the header files. This is
-because bugs in the shell cause the @code{fixincludes} script to fail.
-
-This means you will encounter problems due to bugs in the system header
-files. It may be no comfort that they aren't GCC's fault, but it
-does mean that there's nothing for us to do about them.
@end itemize
@node Standard Libraries
@@ -796,11 +627,9 @@ scripts adapt to various systems by sear
files for the problem cases that we know about.
If new system header files are installed, nothing automatically arranges
-to update the corrected header files. You will have to reinstall GCC
-to fix the new header files. More specifically, go to the build
-directory and delete the files @file{stmp-fixinc} and
-@file{stmp-headers}, and the subdirectory @code{include}; then do
-@samp{make install} again.
+to update the corrected header files. They can be updated using the
+@command{mkheaders} script installed in
+@file{@var{libexecdir}/gcc/@var{target}/@var{version}/install-tools/}.
@item
@cindex floating point precision
More information about the Gcc-patches
mailing list