From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7073 invoked by alias); 31 Oct 2002 00:35:44 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 7026 invoked from network); 31 Oct 2002 00:35:43 -0000 Received: from unknown (HELO e33.co.us.ibm.com) (32.97.110.131) by sources.redhat.com with SMTP; 31 Oct 2002 00:35:43 -0000 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9V0Zgwg008800 for ; Wed, 30 Oct 2002 19:35:43 -0500 Received: from dyn9-47-17-68.beaverton.ibm.com (dyn9-47-17-68.beaverton.ibm.com [9.47.17.68]) by westrelay05.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9V0aHgE165324 for ; Wed, 30 Oct 2002 17:36:17 -0700 Received: (from janis@localhost) by dyn9-47-17-68.beaverton.ibm.com (8.9.3/8.9.3) id QAA13728 for gcc-patches@gcc.gnu.org; Wed, 30 Oct 2002 16:37:44 -0800 Date: Wed, 30 Oct 2002 16:35:00 -0000 From: Janis Johnson To: gcc-patches@gcc.gnu.org Subject: [PATCH/RFC] gut Interoperation section of trouble.texi Message-ID: <20021030163743.A13719@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-SW-Source: 2002-10/txt/msg01876.txt.bz2 Most of the information in the Trouble/Interoperation section of the GCC manual is very old, and I suspect that much of it is no longer relevant. I propose that we remove everything that was there in egcs 1.1.2 unless someone comes forward soon to say a particular item still needs to be there. The current organization of this section makes it difficult to easily find information that is relevant to a particular platform. I propose splitting the items by platform, using the labeling convention now used for the list of supported targets in java/status.html. The patch below uses nested bullets, which doesn't fit into the current formatting of the manual, but I'm sure Joseph will have a good idea about how it ought to be done. Unlike the host/target specific information in the install instructions, this section is aimed at GCC users and can be useful if it's not overwhelmed by outdated cruft. In particular it would be a nice place to record information about interoperability with other C++ compilers and libraries. Tested with "make dvi" and "make info" on i686-pc-linux-gnu. 2002-10-30 Janis Johnson * doc/trouble.texi (Interoperation): Remove everything that's been there since egcs 1.1.2. Index: doc/trouble.texi =================================================================== RCS file: /cvs/gcc/gcc/gcc/doc/trouble.texi,v retrieving revision 1.12 diff -u -r1.12 trouble.texi --- doc/trouble.texi 15 Sep 2002 22:48:05 -0000 1.12 +++ doc/trouble.texi 31 Oct 2002 00:23:17 -0000 @@ -103,6 +103,10 @@ together with other compilers or with the assemblers, linkers, libraries and debuggers on certain systems. +@itemize +@item +Issues that affect many platforms + @itemize @bullet @item On many platforms, GCC supports a different ABI for C++ than do other @@ -120,178 +124,12 @@ run. Incompatible libraries are then detected at link time, rather than 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 I can do about these problems. You are on your own. - -@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}. -Naturally, this does not happen when you use GCC@. -You must specify all three options explicitly. - -@item -On a SPARC, GCC aligns all values of type @code{double} on an 8-byte -boundary, and it expects every @code{double} to be so aligned. The Sun -compiler usually gives @code{double} values 8-byte alignment, with one -exception: function arguments of type @code{double} may not be aligned. - -As a result, if a function compiled with Sun CC takes the address of an -argument of type @code{double} and passes this pointer of type -@code{double *} to a function compiled with GCC, dereferencing the -pointer may cause a fatal signal. - -One way to solve this problem is to compile your entire program with GCC@. -Another solution is to modify the function that is compiled with -Sun CC to copy the argument into a local variable; local variables -are always properly aligned. A third solution is to modify the function -that uses the pointer to dereference it via the following function -@code{access_double} instead of directly with @samp{*}: - -@smallexample -inline double -access_double (double *unaligned_ptr) -@{ - union d2i @{ double d; int i[2]; @}; - - union d2i *p = (union d2i *) unaligned_ptr; - union d2i u; - - u.i[0] = p->i[0]; - u.i[1] = p->i[1]; - - return u.d; -@} -@end smallexample - -@noindent -Storing into the pointer can be done likewise with the same union. - -@item -On Solaris, the @code{malloc} function in the @file{libmalloc.a} library -may allocate memory that is only 4 byte aligned. Since GCC on the -SPARC assumes that doubles are 8 byte aligned, this may result in a -fatal signal if doubles are stored in memory allocated by the -@file{libmalloc.a} library. - -The solution is to not use the @file{libmalloc.a} library. Use instead -@code{malloc} and related functions from @file{libc.a}; they do not have -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 -generate HP-UX unwind descriptors for such functions. It may even be -impossible to generate them. - -@item -Debugging (@option{-g}) is not supported on the HP PA machine, unless you use -the preliminary GNU tools. - -@item -Taking the address of a label may generate errors from the HP-UX -PA assembler. GAS for the PA does not have this problem. - -@item -Using floating point parameters for indirect calls to static functions -will not work when using the HP assembler. There simply is no way for GCC -to specify what registers hold arguments for static functions when using -the HP assembler. GAS for the PA does not have this problem. - -@item -In extremely rare cases involving some very large functions you may -receive errors from the HP linker complaining about an out of bounds -unconditional branch offset. This used to occur more often in previous -versions of GCC, but is now exceptionally rare. If you should run -into it, you can work around by making your function smaller. - -@item -GCC compiled code sometimes emits warnings from the HP-UX assembler of -the form: - -@smallexample -(warning) Use of GR3 when - frame >= 8192 may cause conflict. -@end smallexample - -These warnings are harmless and can be safely ignored. +@end itemize @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@. +AIX on IBM pSeries (PowerPC) architecture (rs6000-ibm-aix*, powerpc-ibm-aix*) +@itemize @bullet @item In extremely rare cases involving some very large functions you may receive errors from the AIX Assembler complaining about a displacement @@ -321,116 +159,7 @@ with ``runtime-linking'' option and the functions explicitly must be exported by the application (@option{-Wl,-brtl,-bE:exportfile}). -@item -AIX on the RS/6000 provides support (NLS) for environments outside of -the United States. Compilers and assemblers use NLS to support -locale-specific representations of various objects including -floating-point numbers (@samp{.} vs @samp{,} for separating decimal -fractions). There have been problems reported where the library linked -with GCC does not produce the same floating-point formats that the -assembler accepts. If you have this problem, set the @env{LANG} -environment variable to @samp{C} or @samp{En_US}. - -@item -@opindex fdollars-in-identifiers -Even if you specify @option{-fdollars-in-identifiers}, -you cannot successfully use @samp{$} in identifiers on the RS/6000 due -to a restriction in the IBM assembler. GAS supports these -identifiers. - -@item -@opindex mno-serialize-volatile -There is an assembler bug in versions of DG/UX prior to 5.4.2.01 that -occurs when the @samp{fldcr} instruction is used. GCC uses -@samp{fldcr} on the 88100 to serialize volatile memory references. Use -the option @option{-mno-serialize-volatile} if your version of the -assembler has this bug. - -@item -On VMS, GAS versions 1.38.1 and earlier may cause spurious warning -messages from the linker. These warning messages complain of mismatched -psect attributes. You can ignore them. - -@item -On NewsOS version 3, if you include both of the files @file{stddef.h} -and @file{sys/types.h}, you get an error because there are two typedefs -of @code{size_t}. You should change @file{sys/types.h} by adding these -lines around the definition of @code{size_t}: - -@smallexample -#ifndef _SIZE_T -#define _SIZE_T -@var{actual-typedef-here} -#endif -@end smallexample - -@cindex Alliant -@item -On the Alliant, the system's own convention for returning structures -and unions is unusual, and is not compatible with GCC no matter -what options are used. - -@cindex RT PC -@cindex IBM RT PC -@item -@opindex mhc-struct-return -On the IBM RT PC, the MetaWare HighC compiler (hc) uses a different -convention for structure and union returning. Use the option -@option{-mhc-struct-return} to tell GCC to use a convention compatible -with it. - -@cindex VAX calling convention -@cindex Ultrix calling convention -@item -@opindex fcall-saved -On Ultrix, the Fortran compiler expects registers 2 through 5 to be saved -by function calls. However, the C compiler uses conventions compatible -with BSD Unix: registers 2 through 5 may be clobbered by function calls. - -GCC uses the same convention as the Ultrix C compiler. You can use -these options to produce code compatible with the Fortran compiler: - -@smallexample --fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5 -@end smallexample - -@item -On the WE32k, you may find that programs compiled with GCC do not -work with the standard shared C library. You may need to link with -the ordinary C compiler. If you do so, you must specify the following -options: - -@smallexample --L/usr/local/lib/gcc-lib/we32k-att-sysv/2.8.1 -lgcc -lc_s -@end smallexample - -The first specifies where to find the library @file{libgcc.a} -specified with the @option{-lgcc} option. - -GCC does linking by invoking @command{ld}, just as @command{cc} does, and -there is no reason why it @emph{should} matter which compilation program -you use to invoke @command{ld}. If someone tracks this problem down, -it can probably be fixed easily. - -@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}. - -@item -On Irix 4.0.5F (and perhaps in some other versions), an assembler bug -sometimes reorders instructions incorrectly when optimization is turned -on. If you think this may be happening to you, try using the GNU -assembler; GAS version 2.1 supports ECOFF on Irix. - -@opindex noasmopt -Or use the @option{-noasmopt} option when you compile GCC with itself, -and then again when you compile your program. (This is a temporary -kludge to turn off assembler optimization on Irix.) If this proves to -be what you need, edit the assembler spec in the file @file{specs} so -that it unconditionally passes @option{-O0} to the assembler, and never -passes @option{-O2} or @option{-O3}. +@end itemize @end itemize @node External Bugs