diff options
Diffstat (limited to 'gcc')
| -rwxr-xr-x | gcc/README.ACORN | 18 | ||||
| -rwxr-xr-x | gcc/README.ALTOS | 55 | ||||
| -rwxr-xr-x | gcc/README.APOLLO | 112 | ||||
| -rwxr-xr-x | gcc/README.C4X | 48 | ||||
| -rwxr-xr-x | gcc/README.DWARF | 574 | ||||
| -rwxr-xr-x | gcc/README.FRESCO | 17 | ||||
| -rwxr-xr-x | gcc/README.NS32K | 179 | ||||
| -rwxr-xr-x | gcc/README.RS6000 | 141 | ||||
| -rwxr-xr-x | gcc/README.TRAD | 55 | ||||
| -rwxr-xr-x | gcc/README.X11 | 447 | ||||
| -rwxr-xr-x | gcc/README.g77 | 263 | ||||
| -rwxr-xr-x | gcc/README.gnat | 435 |
12 files changed, 0 insertions, 2344 deletions
diff --git a/gcc/README.ACORN b/gcc/README.ACORN deleted file mode 100755 index 769dba7..0000000 --- a/gcc/README.ACORN +++ /dev/null @@ -1,18 +0,0 @@ -Specifying the -g flag to GCC on a RISC iX machine requires upgrading the -standard assembler distributed with both RISC iX 1.1 and RISC iX 1.2 with a -replacement that is available from Acorn. This version of the assembler is -also an order of magnitude faster when assembling to an NFS mounted -file-system. - -Users of RISC iX 1.2 and above can obtain a copy of the assembler from the -following places: - -1) Via ftp from acorn.acorn.co.uk, directory pub/riscix. - -2) From Acorn Customer Services. - -3) From Granada Microcare. - -Users of versions of RISC iX prior 1.2 should contact Acorn Customer Services; -the assembler available on the net will not work with these versions due to -changes in the shared libraries and system call numbers. diff --git a/gcc/README.ALTOS b/gcc/README.ALTOS deleted file mode 100755 index c0a1a04..0000000 --- a/gcc/README.ALTOS +++ /dev/null @@ -1,55 +0,0 @@ -Since COFF-encapsulation is obsolete, this may not be needed anymore. - -Return-Path: <jkp@sauna.hut.fi> -Date: Mon, 10 Apr 89 10:13:45 +0300 -From: Jyrki Kuoppala <jkp@sauna.hut.fi> -Sender: jkp@sauna.hut.fi -To: info-gcc@prep.ai.mit.edu -Subject: Kernel fix needed for Altos 3068 to get coff-encapsulation working right -Organization: Helsinki University of Technology, Finland. - -Here's a description how to fix a kernel bug in Altos 3068 and get -gcc-compiled programs working. - -Author: Jyrki Kuoppala (jkp@cs.hut.fi) -Last modified: Mon Apr 10 09:28:40 1989 - -There's a bug in the Altos 3068 kernel that causes gcc-compiled -programs to fail in certain situations when the machine has a heavy -load and also in some other situations. The bug exists at least in -SVR 2.2 1.0gT1 and SVR 2.2 1.0e. - -If you have source code to your system, apply the following change to -os/exec.c (function gethead): - -Change the lines containing - - u.u_exdata.ux_tstart = sizeof(struct naout) + - sizeof(struct filhd) + (ep->ef.nscns * sizeof(struct scnhdr)); - -to - - u.u_exdata.ux_tstart = u.u_exdata.ux_txtorg; - -If you only have binary, use sdb to find out the address of the -previous lines (on our system it's gethead+0x140) and use your -favourite binary editor to change the bytes '3036 0162 fffc 0002 0280 -0000' to '23f9 01fb f4ca 01fb f4c2 6016'. This may or may not work in -your case, depending on the version of the operating system and the -phase of the moon. - -Here's what is just before gethead+0x140 to ease finding out the right place: - -0x9224 (gethead+0x122): 23f9 01fb f4ca 01fb f4ce mov.l &0x1fbf4ca.L,&0 -x1fbf4ce.L [] -0x922e (gethead+0x12c): 23f9 01fb f4c6 01fb f4ca mov.l &0x1fbf4c6.L,&0 -x1fbf4ca.L [] -0x9238 (gethead+0x136): 23f9 01fb f4c2 01fb f4c6 mov.l &0x1fbf4c2.L,&0 -x1fbf4c6.L [] - -Good luck ! - -//Jyrki - -jkp@cs.hut.fi - diff --git a/gcc/README.APOLLO b/gcc/README.APOLLO deleted file mode 100755 index ca02de1..0000000 --- a/gcc/README.APOLLO +++ /dev/null @@ -1,112 +0,0 @@ -README.apollo - -Building GCC 2.0 for 680x0 based Apollo systems requires the GNU -assembler (GAS) version 1.38.1, with John Vasta's patches applied. - -If you haven't done so yet, get `gas-1.38.1.tar.Z' from your favourite -GNU distribution site. Furthermore, get `apollo-gas-1.38.1.diffs' -from `labrea.stanford.edu:/pub/gnu', apply the patches, compile and -install gas (under the name as). This should go through without any -problems. - -After switching into the BSD environment, you can configure GCC 2.0 -with the command - -% ./configure m68k-apollo-bsd - -The Apollo's `/usr/include/setjmp.h' uses a nonstandard `#options()' -construct. You should create a local copy of this file and remove -these constructs from the declarations of SIGSETJMP and SIGLONGJMP. - -The Apollo's `/usr/include/sys/types.h' (BSD Version) doesn't allow -to test for the definition of `size_t'. This should be fixed by - - #ifndef _SIZE_T - #define _SIZE_T - typedef long size_t; - #endif - -The script `patch-apollo-includes' fixes these two problems, but does -_not_ pretend to be a full fledged `fixincludes' for this system. - -If you now follow the standard GCC installation instructions, building -GCC 2.0 (including G++ 2.0) should proceed without any problems. - -NB: Debugging is not yet supported for the Apollo. If someone wants - to do a _big_ favour to the Apollo users, he/she should consider - porting the Binary File Description library (BFD) to the Apollo. - This library can be found in the gdb-4.x distributions or in the - binutils-1.9x distributions. - - - - -#!/bin/sh -# patch-apollo-includes -- fix some (but not all!) Apollo brain damage. - -FILES_TO_PATCH='sys/types.h setjmp.h' - -mkdir sys - -for i in $FILES_TO_PATCH; -do - cp /bsd4.3/usr/include/$i ./$i -done - -patch -b -apollo <<'EOP' -*** /bsd4.3/usr/include/sys/types.h Fri Apr 8 20:29:06 1988 ---- sys/types.h Wed Feb 26 21:17:57 1992 -*************** -*** 38,44 **** ---- 38,47 ---- - typedef char * caddr_t; - typedef u_long ino_t; - typedef long swblk_t; -+ #ifndef _SIZE_T -+ #define _SIZE_T - typedef long size_t; -+ #endif - typedef long time_t; - typedef long dev_t; - typedef long off_t; -*** /bsd4.3/usr/include/setjmp.h Fri Feb 3 21:40:21 1989 ---- setjmp.h Sun Feb 23 19:06:55 1992 -*************** -*** 24,30 **** ---- 24,39 ---- - #endif - - -+ #ifdef __GNUC__ - #ifdef _PROTOTYPES -+ extern int sigsetjmp (sigjmp_buf env, int savemask); -+ extern void siglongjmp (sigjmp_buf env, int val); -+ #else -+ extern int sigsetjmp(); -+ extern void siglongjmp(); -+ #endif /* _PROTOTYPES */ -+ #else /* not __GNUC__ */ -+ #ifdef _PROTOTYPES - extern int sigsetjmp( - sigjmp_buf env, - int savemask -*************** -*** 37,43 **** - extern int sigsetjmp() #options(abnormal); - extern void siglongjmp() #options(noreturn); - #endif /* _PROTOTYPES */ -! - #undef _PROTOTYPES - - #ifdef __cplusplus ---- 46,52 ---- - extern int sigsetjmp() #options(abnormal); - extern void siglongjmp() #options(noreturn); - #endif /* _PROTOTYPES */ -! #endif /* not __GNUC__ */ - #undef _PROTOTYPES - - #ifdef __cplusplus -EOP - -exit 0 diff --git a/gcc/README.C4X b/gcc/README.C4X deleted file mode 100755 index 994e67d..0000000 --- a/gcc/README.C4X +++ /dev/null @@ -1,48 +0,0 @@ -This file describes the implementation notes of the GNU C Compiler for -the Texas Instruments Floating Point Digital Signal Processor -families, TMS320C3x and TMS320C4x (including the C30, C31, C32, C40, -and C44 chips). - - -Currently, only two code variants are generated---those for the C3x -and C4x architectures. Note that the new operand combinations for -parallel instructions, included in newer silicon revisions, are not -yet supported. These should be trivial to add for someone with the -newer chips and the inclination. - - -While the generated assembly code is fairly similar to that recognised -by the TI assembler, there are a few differences (currently the machine -option -mti, designed to enfore compatibility, is not fully -implemented). The major difference is the use of the ^ operator to -load the 16 MSBs of an address or constant for the C4x. - - -The generated assembly code requires the GNU assembler (GAS). This is -not currently included as part of the binutils package, due to the -many hacks required to be compatible with TI's kludged COFF -implementation, and the binutils not being designed for 32-bit bytes. -Patches against binutils-2.7.2 can be obtained from -http://www.elec.canterbury.ac.nz/c4x. This site also has patches for -the GNU debugger (GDB), incoporating a cycle accurate simulator that -can display profiles and histories of code execution, detailing -pipeline conflicts etc. - - -GCC can be configured as a cross compiler for both the C3x and C4x -architectures on the same system. Use `configure --target=c4x' to -configure GCC for both the C3x and C4x. Then use the -m30 option to -generate code for the C30 or -m40 (the default) for the C40. - - -Further installation notes and other optimization patches for the C4x -target can also be obtained from http://www.elec.canterbury.ac.nz/c4x. - - -A Majordomo mailing list, gcc_c40@atlantek.com.au, exists to discuss -related issues and suggestions for further optimizations. To -subscribe send a message with `subscribe gcc_c40' in the body to -majordomo@atlantek.com.au. - - -Michael Hayes, 26 Nov 98 diff --git a/gcc/README.DWARF b/gcc/README.DWARF deleted file mode 100755 index 9745950..0000000 --- a/gcc/README.DWARF +++ /dev/null @@ -1,574 +0,0 @@ -Notes on the GNU Implementation of DWARF Debugging Information --------------------------------------------------------------- -Last Updated: Sun Jul 17 08:17:42 PDT 1994 by rfg@segfault.us.com ------------------------------------------------------------- - -This file describes special and unique aspects of the GNU implementation -of the DWARF debugging information language, as provided in the GNU version -2.x compiler(s). - -For general information about the DWARF debugging information language, -you should obtain the DWARF version 1 specification document (and perhaps -also the DWARF version 2 draft specification document) developed by the -UNIX International Programming Languages Special Interest Group. A copy -of the DWARF version 1 specification (in PostScript form) may be -obtained either from me <rfg@netcom.com> or from the main Data General -FTP server. (See below.) The file you are looking at now only describes -known deviations from the DWARF version 1 specification, together with -those things which are allowed by the DWARF version 1 specification but -which are known to cause interoperability problems (e.g. with SVR4 SDB). - -To obtain a copy of the DWARF Version 1 and/or DWARF Version 2 specification -from Data General's FTP server, use the following procedure: - ---------------------------------------------------------------------------- - ftp to machine: "dg-rtp.dg.com" (128.222.1.2). - - Log in as "ftp". - cd to "plsig" - get any of the following file you are interested in: - - dwarf.1.0.3.ps - dwarf.2.0.0.index.ps - dwarf.2.0.0.ps ---------------------------------------------------------------------------- - -The generation of DWARF debugging information by the GNU version 2.x C -compiler has now been tested rather extensively for m88k, i386, i860, and -Sparc targets. The DWARF output of the GNU C compiler appears to inter- -operate well with the standard SVR4 SDB debugger on these kinds of target -systems (but of course, there are no guarantees). - -DWARF generation for the GNU g++ compiler is still not operable. This is -due primarily to the many remaining cases where the g++ front end does not -conform to the conventions used in the GNU C front end for representing -various kinds of declarations in the TREE data structure. It is not clear -at this time how these problems will be addressed. - -Future plans for the dwarfout.c module of the GNU compiler(s) includes the -addition of full support for GNU FORTRAN. (This should, in theory, be a -lot simpler to add than adding support for g++... but we'll see.) - -Many features of the DWARF version 2 specification have been adapted to -(and used in) the GNU implementation of DWARF (version 1). In most of -these cases, a DWARF version 2 approach is used in place of (or in addition -to) DWARF version 1 stuff simply because it is apparent that DWARF version -1 is not sufficiently expressive to provide the kinds of information which -may be necessary to support really robust debugging. In all of these cases -however, the use of DWARF version 2 features should not interfere in any -way with the interoperability (of GNU compilers) with generally available -"classic" (pre version 1) DWARF consumer tools (e.g. SVR4 SDB). - -The DWARF generation enhancement for the GNU compiler(s) was initially -donated to the Free Software Foundation by Network Computing Devices. -(Thanks NCD!) Additional development and maintenance of dwarfout.c has -been largely supported (i.e. funded) by Intel Corporation. (Thanks Intel!) - -If you have questions or comments about the DWARF generation feature, please -send mail to me <rfg@netcom.com>. I will be happy to investigate any bugs -reported and I may even provide fixes (but of course, I can make no promises). - -The DWARF debugging information produced by GCC may deviate in a few minor -(but perhaps significant) respects from the DWARF debugging information -currently produced by other C compilers. A serious attempt has been made -however to conform to the published specifications, to existing practice, -and to generally accepted norms in the GNU implementation of DWARF. - - ** IMPORTANT NOTE ** ** IMPORTANT NOTE ** ** IMPORTANT NOTE ** - -Under normal circumstances, the DWARF information generated by the GNU -compilers (in an assembly language file) is essentially impossible for -a human being to read. This fact can make it very difficult to debug -certain DWARF-related problems. In order to overcome this difficulty, -a feature has been added to dwarfout.c (enabled by the -fverbose-asm -option) which causes additional comments to be placed into the assembly -language output file, out to the right-hand side of most bits of DWARF -material. The comments indicate (far more clearly that the obscure -DWARF hex codes do) what is actually being encoded in DWARF. Thus, the --fverbose-asm option can be highly useful for those who must study the -DWARF output from the GNU compilers in detail. - ---------- - -(Footnote: Within this file, the term `Debugging Information Entry' will -be abbreviated as `DIE'.) - - -Release Notes (aka known bugs) -------------------------------- - -In one very obscure case involving dynamically sized arrays, the DWARF -"location information" for such an array may make it appear that the -array has been totally optimized out of existence, when in fact it -*must* actually exist. (This only happens when you are using *both* -g -*and* -O.) This is due to aggressive dead store elimination in the -compiler, and to the fact that the DECL_RTL expressions associated with -variables are not always updated to correctly reflect the effects of -GCC's aggressive dead store elimination. - -------------------------------- - -When attempting to set a breakpoint at the "start" of a function compiled -with -g1, the debugger currently has no way of knowing exactly where the -end of the prologue code for the function is. Thus, for most targets, -all the debugger can do is to set the breakpoint at the AT_low_pc address -for the function. But if you stop there and then try to look at one or -more of the formal parameter values, they may not have been "homed" yet, -so you may get inaccurate answers (or perhaps even addressing errors). - -Some people may consider this simply a non-feature, but I consider it a -bug, and I hope to provide some GNU-specific attributes (on function -DIEs) which will specify the address of the end of the prologue and the -address of the beginning of the epilogue in a future release. - -------------------------------- - -It is believed at this time that old bugs relating to the AT_bit_offset -values for bit-fields have been fixed. - -There may still be some very obscure bugs relating to the DWARF description -of type `long long' bit-fields for target machines (e.g. 80x86 machines) -where the alignment of type `long long' data objects is different from -(and less than) the size of a type `long long' data object. - -Please report any problems with the DWARF description of bit-fields as you -would any other GCC bug. (Procedures for bug reporting are given in the -GNU C compiler manual.) - --------------------------------- - -At this time, GCC does not know how to handle the GNU C "nested functions" -extension. (See the GCC manual for more info on this extension to ANSI C.) - --------------------------------- - -The GNU compilers now represent inline functions (and inlined instances -thereof) in exactly the manner described by the current DWARF version 2 -(draft) specification. The version 1 specification for handling inline -functions (and inlined instances) was known to be brain-damaged (by the -PLSIG) when the version 1 spec was finalized, but it was simply too late -in the cycle to get it removed before the version 1 spec was formally -released to the public (by UI). - --------------------------------- - -At this time, GCC does not generate the kind of really precise information -about the exact declared types of entities with signed integral types which -is required by the current DWARF draft specification. - -Specifically, the current DWARF draft specification seems to require that -the type of an non-unsigned integral bit-field member of a struct or union -type be represented as either a "signed" type or as a "plain" type, -depending upon the exact set of keywords that were used in the -type specification for the given bit-field member. It was felt (by the -UI/PLSIG) that this distinction between "plain" and "signed" integral types -could have some significance (in the case of bit-fields) because ANSI C -does not constrain the signedness of a plain bit-field, whereas it does -constrain the signedness of an explicitly "signed" bit-field. For this -reason, the current DWARF specification calls for compilers to produce -type information (for *all* integral typed entities... not just bit-fields) -which explicitly indicates the signedness of the relevant type to be -"signed" or "plain" or "unsigned". - -Unfortunately, the GNU DWARF implementation is currently incapable of making -such distinctions. - --------------------------------- - - -Known Interoperability Problems -------------------------------- - -Although the GNU implementation of DWARF conforms (for the most part) with -the current UI/PLSIG DWARF version 1 specification (with many compatible -version 2 features added in as "vendor specific extensions" just for good -measure) there are a few known cases where GCC's DWARF output can cause -some confusion for "classic" (pre version 1) DWARF consumers such as the -System V Release 4 SDB debugger. These cases are described in this section. - --------------------------------- - -The DWARF version 1 specification includes the fundamental type codes -FT_ext_prec_float, FT_complex, FT_dbl_prec_complex, and FT_ext_prec_complex. -Since GNU C is only a C compiler (and since C doesn't provide any "complex" -data types) the only one of these fundamental type codes which GCC ever -generates is FT_ext_prec_float. This fundamental type code is generated -by GCC for the `long double' data type. Unfortunately, due to an apparent -bug in the SVR4 SDB debugger, SDB can become very confused wherever any -attempt is made to print a variable, parameter, or field whose type was -given in terms of FT_ext_prec_float. - -(Actually, SVR4 SDB fails to understand *any* of the four fundamental type -codes mentioned here. This will fact will cause additional problems when -there is a GNU FORTRAN front-end.) - --------------------------------- - -In general, it appears that SVR4 SDB is not able to effectively ignore -fundamental type codes in the "implementation defined" range. This can -cause problems when a program being debugged uses the `long long' data -type (or the signed or unsigned varieties thereof) because these types -are not defined by ANSI C, and thus, GCC must use its own private fundamental -type codes (from the implementation-defined range) to represent these types. - --------------------------------- - - -General GNU DWARF extensions ----------------------------- - -In the current DWARF version 1 specification, no mechanism is specified by -which accurate information about executable code from include files can be -properly (and fully) described. (The DWARF version 2 specification *does* -specify such a mechanism, but it is about 10 times more complicated than -it needs to be so I'm not terribly anxious to try to implement it right -away.) - -In the GNU implementation of DWARF version 1, a fully downward-compatible -extension has been implemented which permits the GNU compilers to specify -which executable lines come from which files. This extension places -additional information (about source file names) in GNU-specific sections -(which should be totally ignored by all non-GNU DWARF consumers) so that -this extended information can be provided (to GNU DWARF consumers) in a way -which is totally transparent (and invisible) to non-GNU DWARF consumers -(e.g. the SVR4 SDB debugger). The additional information is placed *only* -in specialized GNU-specific sections, where it should never even be seen -by non-GNU DWARF consumers. - -To understand this GNU DWARF extension, imagine that the sequence of entries -in the .lines section is broken up into several subsections. Each contiguous -sequence of .line entries which relates to a sequence of lines (or statements) -from one particular file (either a `base' file or an `include' file) could -be called a `line entries chunk' (LEC). - -For each LEC there is one entry in the .debug_srcinfo section. - -Each normal entry in the .debug_srcinfo section consists of two 4-byte -words of data as follows: - - (1) The starting address (relative to the entire .line section) - of the first .line entry in the relevant LEC. - - (2) The starting address (relative to the entire .debug_sfnames - section) of a NUL terminated string representing the - relevant filename. (This filename name be either a - relative or an absolute filename, depending upon how the - given source file was located during compilation.) - -Obviously, each .debug_srcinfo entry allows you to find the relevant filename, -and it also points you to the first .line entry that was generated as a result -of having compiled a given source line from the given source file. - -Each subsequent .line entry should also be assumed to have been produced -as a result of compiling yet more lines from the same file. The end of -any given LEC is easily found by looking at the first 4-byte pointer in -the *next* .debug_srcinfo entry. That next .debug_srcinfo entry points -to a new and different LEC, so the preceding LEC (implicitly) must have -ended with the last .line section entry which occurs at the 2 1/2 words -just before the address given in the first pointer of the new .debug_srcinfo -entry. - -The following picture may help to clarify this feature. Let's assume that -`LE' stands for `.line entry'. Also, assume that `* 'stands for a pointer. - - - .line section .debug_srcinfo section .debug_sfnames section - ---------------------------------------------------------------- - - LE <---------------------- * - LE * -----------------> "foobar.c" <--- - LE | - LE | - LE <---------------------- * | - LE * -----------------> "foobar.h" <| | - LE | | - LE | | - LE <---------------------- * | | - LE * -----------------> "inner.h" | | - LE | | - LE <---------------------- * | | - LE * ------------------------------- | - LE | - LE | - LE | - LE | - LE <---------------------- * | - LE * ----------------------------------- - LE - LE - LE - -In effect, each entry in the .debug_srcinfo section points to *both* a -filename (in the .debug_sfnames section) and to the start of a block of -consecutive LEs (in the .line section). - -Note that just like in the .line section, there are specialized first and -last entries in the .debug_srcinfo section for each object file. These -special first and last entries for the .debug_srcinfo section are very -different from the normal .debug_srcinfo section entries. They provide -additional information which may be helpful to a debugger when it is -interpreting the data in the .debug_srcinfo, .debug_sfnames, and .line -sections. - -The first entry in the .debug_srcinfo section for each compilation unit -consists of five 4-byte words of data. The contents of these five words -should be interpreted (by debuggers) as follows: - - (1) The starting address (relative to the entire .line section) - of the .line section for this compilation unit. - - (2) The starting address (relative to the entire .debug_sfnames - section) of the .debug_sfnames section for this compilation - unit. - - (3) The starting address (in the execution virtual address space) - of the .text section for this compilation unit. - - (4) The ending address plus one (in the execution virtual address - space) of the .text section for this compilation unit. - - (5) The date/time (in seconds since midnight 1/1/70) at which the - compilation of this compilation unit occurred. This value - should be interpreted as an unsigned quantity because gcc - might be configured to generate a default value of 0xffffffff - in this field (in cases where it is desired to have object - files created at different times from identical source files - be byte-for-byte identical). By default, these timestamps - are *not* generated by dwarfout.c (so that object files - compiled at different times will be byte-for-byte identical). - If you wish to enable this "timestamp" feature however, you - can simply place a #define for the symbol `DWARF_TIMESTAMPS' - in your target configuration file and then rebuild the GNU - compiler(s). - -Note that the first string placed into the .debug_sfnames section for each -compilation unit is the name of the directory in which compilation occurred. -This string ends with a `/' (to help indicate that it is the pathname of a -directory). Thus, the second word of each specialized initial .debug_srcinfo -entry for each compilation unit may be used as a pointer to the (string) -name of the compilation directory, and that string may in turn be used to -"absolutize" any relative pathnames which may appear later on in the -.debug_sfnames section entries for the same compilation unit. - -The fifth and last word of each specialized starting entry for a compilation -unit in the .debug_srcinfo section may (depending upon your configuration) -indicate the date/time of compilation, and this may be used (by a debugger) -to determine if any of the source files which contributed code to this -compilation unit are newer than the object code for the compilation unit -itself. If so, the debugger may wish to print an "out-of-date" warning -about the compilation unit. - -The .debug_srcinfo section associated with each compilation will also have -a specialized terminating entry. This terminating .debug_srcinfo section -entry will consist of the following two 4-byte words of data: - - (1) The offset, measured from the start of the .line section to - the beginning of the terminating entry for the .line section. - - (2) A word containing the value 0xffffffff. - --------------------------------- - -In the current DWARF version 1 specification, no mechanism is specified by -which information about macro definitions and un-definitions may be provided -to the DWARF consumer. - -The DWARF version 2 (draft) specification does specify such a mechanism. -That specification was based on the GNU ("vendor specific extension") -which provided some support for macro definitions and un-definitions, -but the "official" DWARF version 2 (draft) specification mechanism for -handling macros and the GNU implementation have diverged somewhat. I -plan to update the GNU implementation to conform to the "official" -DWARF version 2 (draft) specification as soon as I get time to do that. - -Note that in the GNU implementation, additional information about macro -definitions and un-definitions is *only* provided when the -g3 level of -debug-info production is selected. (The default level is -g2 and the -plain old -g option is considered to be identical to -g2.) - -GCC records information about macro definitions and undefinitions primarily -in a section called the .debug_macinfo section. Normal entries in the -.debug_macinfo section consist of the following three parts: - - (1) A special "type" byte. - - (2) A 3-byte line-number/filename-offset field. - - (3) A NUL terminated string. - -The interpretation of the second and third parts is dependent upon the -value of the leading (type) byte. - -The type byte may have one of four values depending upon the type of the -.debug_macinfo entry which follows. The 1-byte MACINFO type codes presently -used, and their meanings are as follows: - - MACINFO_start A base file or an include file starts here. - MACINFO_resume The current base or include file ends here. - MACINFO_define A #define directive occurs here. - MACINFO_undef A #undef directive occur here. - -(Note that the MACINFO_... codes mentioned here are simply symbolic names -for constants which are defined in the GNU dwarf.h file.) - -For MACINFO_define and MACINFO_undef entries, the second (3-byte) field -contains the number of the source line (relative to the start of the current -base source file or the current include files) when the #define or #undef -directive appears. For a MACINFO_define entry, the following string field -contains the name of the macro which is defined, followed by its definition. -Note that the definition is always separated from the name of the macro -by at least one whitespace character. For a MACINFO_undef entry, the -string which follows the 3-byte line number field contains just the name -of the macro which is being undef'ed. - -For a MACINFO_start entry, the 3-byte field following the type byte contains -the offset, relative to the start of the .debug_sfnames section for the -current compilation unit, of a string which names the new source file which -is beginning its inclusion at this point. Following that 3-byte field, -each MACINFO_start entry always contains a zero length NUL terminated -string. - -For a MACINFO_resume entry, the 3-byte field following the type byte contains -the line number WITHIN THE INCLUDING FILE at which the inclusion of the -current file (whose inclusion ends here) was initiated. Following that -3-byte field, each MACINFO_resume entry always contains a zero length NUL -terminated string. - -Each set of .debug_macinfo entries for each compilation unit is terminated -by a special .debug_macinfo entry consisting of a 4-byte zero value followed -by a single NUL byte. - --------------------------------- - -In the current DWARF draft specification, no provision is made for providing -a separate level of (limited) debugging information necessary to support -tracebacks (only) through fully-debugged code (e.g. code in system libraries). - -A proposal to define such a level was submitted (by me) to the UI/PLSIG. -This proposal was rejected by the UI/PLSIG for inclusion into the DWARF -version 1 specification for two reasons. First, it was felt (by the PLSIG) -that the issues involved in supporting a "traceback only" subset of DWARF -were not well understood. Second, and perhaps more importantly, the PLSIG -is already having enough trouble agreeing on what it means to be "conforming" -to the DWARF specification, and it was felt that trying to specify multiple -different *levels* of conformance would only complicate our discussions of -this already divisive issue. Nonetheless, the GNU implementation of DWARF -provides an abbreviated "traceback only" level of debug-info production for -use with fully-debugged "system library" code. This level should only be -used for fully debugged system library code, and even then, it should only -be used where there is a very strong need to conserve disk space. This -abbreviated level of debug-info production can be used by specifying the --g1 option on the compilation command line. - --------------------------------- - -As mentioned above, the GNU implementation of DWARF currently uses the DWARF -version 2 (draft) approach for inline functions (and inlined instances -thereof). This is used in preference to the version 1 approach because -(quite simply) the version 1 approach is highly brain-damaged and probably -unworkable. - --------------------------------- - - -GNU DWARF Representation of GNU C Extensions to ANSI C ------------------------------------------------------- - -The file dwarfout.c has been designed and implemented so as to provide -some reasonable DWARF representation for each and every declarative -construct which is accepted by the GNU C compiler. Since the GNU C -compiler accepts a superset of ANSI C, this means that there are some -cases in which the DWARF information produced by GCC must take some -liberties in improvising DWARF representations for declarations which -are only valid in (extended) GNU C. - -In particular, GNU C provides at least three significant extensions to -ANSI C when it comes to declarations. These are (1) inline functions, -and (2) dynamic arrays, and (3) incomplete enum types. (See the GCC -manual for more information on these GNU extensions to ANSI C.) When -used, these GNU C extensions are represented (in the generated DWARF -output of GCC) in the most natural and intuitively obvious ways. - -In the case of inline functions, the DWARF representation is exactly as -called for in the DWARF version 2 (draft) specification for an identical -function written in C++; i.e. we "reuse" the representation of inline -functions which has been defined for C++ to support this GNU C extension. - -In the case of dynamic arrays, we use the most obvious representational -mechanism available; i.e. an array type in which the upper bound of -some dimension (usually the first and only dimension) is a variable -rather than a constant. (See the DWARF version 1 specification for more -details.) - -In the case of incomplete enum types, such types are represented simply -as TAG_enumeration_type DIEs which DO NOT contain either AT_byte_size -attributes or AT_element_list attributes. - --------------------------------- - - -Future Directions ------------------ - -The codes, formats, and other paraphernalia necessary to provide proper -support for symbolic debugging for the C++ language are still being worked -on by the UI/PLSIG. The vast majority of the additions to DWARF which will -be needed to completely support C++ have already been hashed out and agreed -upon, but a few small issues (e.g. anonymous unions, access declarations) -are still being discussed. Also, we in the PLSIG are still discussing -whether or not we need to do anything special for C++ templates. (At this -time it is not yet clear whether we even need to do anything special for -these.) - -Unfortunately, as mentioned above, there are quite a few problems in the -g++ front end itself, and these are currently responsible for severely -restricting the progress which can be made on adding DWARF support -specifically for the g++ front-end. Furthermore, Richard Stallman has -expressed the view that C++ friendships might not be important enough to -describe (in DWARF). This view directly conflicts with both the DWARF -version 1 and version 2 (draft) specifications, so until this small -misunderstanding is cleared up, DWARF support for g++ is unlikely. - -With regard to FORTRAN, the UI/PLSIG has defined what is believed to be a -complete and sufficient set of codes and rules for adequately representing -all of FORTRAN 77, and most of Fortran 90 in DWARF. While some support for -this has been implemented in dwarfout.c, further implementation and testing -will have to await the arrival of the GNU Fortran front-end (which is -currently in early alpha test as of this writing). - -GNU DWARF support for other languages (i.e. Pascal and Modula) is a moot -issue until there are GNU front-ends for these other languages. - -GNU DWARF support for DWARF version 2 will probably not be attempted until -such time as the version 2 specification is finalized. (More work needs -to be done on the version 2 specification to make the new "abbreviations" -feature of version 2 more easily implementable. Until then, it will be -a royal pain the ass to implement version 2 "abbreviations".) For the -time being, version 2 features will be added (in a version 1 compatible -manner) when and where these features seem necessary or extremely desirable. - -As currently defined, DWARF only describes a (binary) language which can -be used to communicate symbolic debugging information from a compiler -through an assembler and a linker, to a debugger. There is no clear -specification of what processing should be (or must be) done by the -assembler and/or the linker. Fortunately, the role of the assembler -is easily inferred (by anyone knowledgeable about assemblers) just by -looking at examples of assembly-level DWARF code. Sadly though, the -allowable (or required) processing steps performed by a linker are -harder to infer and (perhaps) even harder to agree upon. There are -several forms of very useful `post-processing' steps which intelligent -linkers *could* (in theory) perform on object files containing DWARF, -but any and all such link-time transformations are currently both disallowed -and unspecified. - -In particular, possible link-time transformations of DWARF code which could -provide significant benefits include (but are not limited to): - - Commonization of duplicate DIEs obtained from multiple input - (object) files. - - Cross-compilation type checking based upon DWARF type information - for objects and functions. - - Other possible `compacting' transformations designed to save disk - space and to reduce linker & debugger I/O activity. diff --git a/gcc/README.FRESCO b/gcc/README.FRESCO deleted file mode 100755 index 334e780..0000000 --- a/gcc/README.FRESCO +++ /dev/null @@ -1,17 +0,0 @@ -Compiling Fresco with g++ ------------------------------ - -Fresco is an evolving interface and toolkit for object-oriented -graphics. A preliminary version (written in C++) was released -with x11r6. - -Previous versions of Fresco have not compiled using g++, -partly because of the use of true and false as identifiers. -(They are now reserved words in g++, as required by the -ANSI/ISO draft standard for C++.) - -If you get x11r6 with public patch #5 or a later version -of Fresco, these problems should now be fixed. - -See http://www.faslab.com/fresco/HomePage.html for information -on Fresco, including how to get the latest version. diff --git a/gcc/README.NS32K b/gcc/README.NS32K deleted file mode 100755 index 8e3610e..0000000 --- a/gcc/README.NS32K +++ /dev/null @@ -1,179 +0,0 @@ -This file describes the implementation notes of the GNU C Compiler for -the National Semiconductor 32032 chip (and 32000 family). - -Much of this file was obsolete. It described restrictions caused by -bugs in early versions of of the ns32032 chip and by bugs in sequent -assemblers and linkers of the time. - -Many (all?) of the chip bugs were fixed in later revisions and -certainly fixed by later chips in the same series (ns32332 and -ns32532). - -Conditional code to support sequent assembler and/or linker restrictions -has not been removed deliberately, but has probably not been tested in -a *very* long time. - -Support for one sequent assembler bug has *not* been retained. -It was necessary to say: - - addr _x,rn - cmpd _p,rn - -rather than: - - cmpd _p,@_x - - -This used to be forced by the use of "rmn" register constraints rather -than "g". This is bad for other platforms which do not have this -restraint. - -It is likely that there are no Balance 8000's still in operation, but -if there are and the assembler bug was never fixed then the easiest -way to run gcc would be to also run gas. - -The code required by the sequent assembler is still generated when the --fpic flag is in effect and this is forced by the appropriate -definition of LEGITIMATE_PIC_OPERAND_P. If support for the old sequent -assembler bug is required, then this could be achieved by adding the -test from LEGITIMATE_PIC_OPERAND to the GO_IF_LEGITIMATE_ADDRESS -definition. Of course, this should be conditional on something in the -sequent.h config file. - -The original contents of this file appear below as an historical note. -SEQUENT_ADDRESS_BUG mentioned below has been replaced by -INDEX_RATHER_THAN_BASE. Note that merlin.h still defines -SEQUENT_ADDRESS_BUG even though it is not used anywhere. Since it has -been like this for a long time, presumably either the -SEQUENT_ADDRESS_BUG is not required for the merlin, or no one is using -gcc on the merlin anymore. - -HISTORICAL NOTE - -The 32032 machine description and configuration file for this compiler -is, for NS32000 family machine, primarily machine independent. -However, since this release still depends on vendor-supplied -assemblers and linkers, the compiler must obey the existing -conventions of the actual machine to which this compiler is targeted. -In this case, the actual machine which this compiler was targeted to -is a Sequent Balance 8000, running DYNIX 2.1. - -The assembler for DYNIX 2.1 (and DYNIX 3.0, alas) does not cope with -the full generality of the addressing mode REGISTER RELATIVE. -Specifically, it generates incorrect code for operands of the -following form: - - sym(rn) - -Where `rn' is one of the general registers. Correct code is generated -for operands of the form - - sym(pn) - -where `pn' is one of the special processor registers (sb, fp, or sp). - -An equivalent operand can be generated by the form - - sym[rn:b] - -although this addressing mode is about twice as slow on the 32032. - -The more efficient addressing mode is controlled by defining the -constant SEQUENT_ADDRESS_BUG to 0. It is currently defined to be 1. - -Another bug in the assembler makes it impossible to compute with -explicit addresses. In order to compute with a symbolic address, it -is necessary to load that address into a register using the "addr" -instruction. For example, it is not possible to say - - cmpd _p,@_x - -Rather one must say - - addr _x,rn - cmpd _p,rn - - -The ns32032 chip has a number of known bugs. Any attempt to make the -compiler unaware of these deficiencies will surely bring disaster. -The current list of know bugs are as follows (list provided by Richard -Stallman): - -1) instructions with two overlapping operands in memory -(unlikely in C code, perhaps impossible). - -2) floating point conversion instructions with constant -operands (these may never happen, but I'm not certain). - -3) operands crossing a page boundary. These can be prevented -by setting the flag in tm.h that requires strict alignment. - -4) Scaled indexing in an insn following an insn that has a read-write -operand in memory. This can be prevented by placing a no-op in -between. I, Michael Tiemann, do not understand what exactly is meant -by `read-write operand in memory'. If this is referring to the special -TOS mode, for example "addd 5,tos" then one need not fear, since this -will never be generated. However, is this includes "addd 5,-4(fp)" -then there is room for disaster. The Sequent compiler does not insert -a no-op for code involving the latter, and I have been informed that -Sequent is aware of this list of bugs, so I must assume that it is not -a problem. - -5) The 32032 cannot shift by 32 bits. It shifts modulo the word size -of the operand. Therefore, for 32-bit operations, 32-bit shifts are -interpreted as zero bit shifts. 32-bit shifts have been removed from -the compiler, but future hackers must be careful not to reintroduce -them. - -6) The ns32032 is a very slow chip; however, some instructions are -still very much slower than one might expect. For example, it is -almost always faster to double a quantity by adding it to itself than -by shifting it by one, even if that quantity is deep in memory. The -MOVM instruction has a 20-cycle setup time, after which it moves data -at about the speed that normal moves would. It is also faster to use -address generation instructions than shift instructions for left -shifts less than 4. I do not claim that I generate optimal code for all -given patterns, but where I did escape from National's "clean -architecture", I did so because the timing specification from the data -book says that I will win if I do. I suppose this is called the -"performance gap". - - -Signed bitfield extraction has not been implemented. It is not -provided by the NS32032, and while it is most certainly possible to do -better than the standard shift-left/shift-right sequence, it is also -quite hairy. Also, since signed bitfields do not yet exist in C, this -omission seems relatively harmless. - - -Zero extractions could be better implemented if it were possible in -GCC to provide sized zero extractions: i.e. a byte zero extraction -would be allowed to yield a byte result. The current implementation -of GCC manifests 68000-ist thinking, where bitfields are extracted -into a register, and automatically sign/zero extended to fill the -register. See comments in ns32k.md around the "extzv" insn for more -details. - - -It should be noted that while the NS32000 family was designed to -provide odd-aligned addressing capability for multi-byte data (also -provided by the 68020, but not by the 68000 or 68010), many machines -do not opt to take advantage of this. For example, on the sequent, -although there is no advantage to long-word aligning word data, shorts -must be int-aligned in structs. This is an example of another -machine-specific machine dependency. - - -Because the ns32032 is has a coherent byte-order/bit-order -architecture, many instructions which would be different for -68000-style machines, fold into the same instruction for the 32032. -The classic case is push effective address, where it does not matter -whether one is pushing a long, word, or byte address. They all will -push the same address. - - -The macro FUNCTION_VALUE_REGNO_P is probably not sufficient, what is -needed is FUNCTION_VALUE_P, which also takes a MODE parameter. In -this way it will be possible to determine more exactly whether a -register is really a function value register, or just one that happens -to look right. diff --git a/gcc/README.RS6000 b/gcc/README.RS6000 deleted file mode 100755 index 5e8225e..0000000 --- a/gcc/README.RS6000 +++ /dev/null @@ -1,141 +0,0 @@ - AIX 4.3 archive libraries - -AIX 4.3 utilizes a new "large format" archive to support both 32-bit and -64-bit object modules. The routines provided in AIX 4.3.0 and AIX 4.3.1 -to parse archive libraries did not handle the new format correctly. These -routines are used by GCC and result in error messages during linking such -as "not a COFF file". The version of the routines shipped with AIX 4.3.1 -should work for a 32-bit environment. The "-g" option of the archive -command may be used to create archives of 32-bit objects using the -original "small format". A correct version of the routines is shipped -with AIX 4.3.2. - - - AIX 4.3 assembler - -The AIX 4.3.0.0 assembler generates incorrect object files if the ".bs" -pseudo-op references symbols in certain sections. If GCC is invoked with -the -g debugging option (including during bootstrapping), incorrect object -files will be produced and the AIX linker will fail with a severe error. -A fix for APAR IX74254 (64BIT DISASSEMBLED OUPUT FROM COMPILER FAILS TO -ASSEMBLE/BIND) is available from IBM Customer Support and from its -service.boulder.ibm.com website as PTF U453956. - - - AIX 4.1 binder - -Some versions of the AIX binder (linker) can fail with a relocation -overflow severe error when the -bbigtoc option is used to link -GCC-produced object files into an executable that overflows the TOC. -Linking f771, the GNU Fortran backend, will fail in this manner. A fix -for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC) is -available from IBM Customer Support and from its website as PTF U455193. - -Due to changes in the way that GCC invokes the binder (linker) for AIX 4.1, -the link step now may produce warnings of duplicate symbols which were not -reported before. The assembly files generated by GCC for AIX always have -included multiple symbol definitions for certain global variable and -function declarations in the original program. The warnings should not -prevent the linker from producing a correct library or runnable executable. - - - AIX NLS problems - -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 ("." vs "," 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 LANG environment variable to "C" or -"En_US". - - - AIX 3.2.5 XLC-1.3 problems - -XLC version 1.3.0.0 distributed with AIX 3.2.5 will miscompile jump.c when -building the stage1 compiler during the bootstrap process. This will cause -GCC to crash and the bootstrap to fail later while compiling libgcc2.c. XLC -version 1.3.0.1 or later fixes this problem. XLC-1.3.0.19 also cannot -bootstrap GCC so please avoid that release as well. You can obtain -XLC-1.3.0.24 by requesting PTF 432238 from IBM, or just ask for the latest -release of XLC-1.3. - -There also have been reports of problems bootstrapping GCC with some older -releases of xlc-1.2.1, including xlc-1.2.1.8. Newer releases of xlc-1.2.1 -do not exhibit this problem: xlc-1.2.1.28 is known to bootstrap properly. - - - AIX 3.2 common-mode support - -AIX common-mode providing transparent support of both the POWER and PowerPC -architectures is usable in AIX 3.2.3 and above but an export file and -support for hidden export via libc.a will not exist until AIX 4.1. libgcc.a -also must be compiled in common-mode. Note that executables generated for -the POWER (RIOS1 and RSC) architecture will run directly on systems using -the MPC601 chip. Common-mode only improves the performance of a single -executable run on both POWER and PowerPC architecture platforms by not using -POWER- or PowerPC-specific instructions and eliminating the need to trap to -emulation (for POWER instructions run on PowerPC). - -To link a common-mode application prior to AIX 4.1 and run it on a system at -AIX level 3.2.3 or above, use the text between the "<>" as an export file -(e.g. milli.exp) - -<><><><><><><><><><><> -#! -__mulh 0x3100 -__mull 0x3180 -__divss 0x3200 -__divus 0x3280 -__quoss 0x3300 -__quous 0x3380 -<><><><><><><><><><><> - -and then link with -Wl,-bI:milli.exp. - - - AIX 3.1 and 3.2 assembler problems - -Specifying the -g flag to GCC on the RS/6000 requires upgrading the -standard AIX assembler distributed with AIX 3.1 and versions of AIX -3.2 earlier than 3.2.4 with a replacement that is available from IBM. -Note that Makefile.in specifies the -g when compiling libgcc2.c. - -You can test for the presence of a fixed assembler by entering the following: - % as -u < /dev/null -If the command exits normally, the assembler fix already is installed. -If the assembler complains that "-u" is an unknown flag, you need to order -the fix. - -If you are running AIX 3.1 (lslpp -h bos.obj output reports -03.01.0005.XXXX where the 0005 can be any higher number and the XXXX -can be any value), call IBM Support at 800-237-5511 and ask for -shipment of AIX/6000 fix PTF U403044 for APAR IX22829 (.extern foo -conflicts with defining foo). - -If you are running AIX 3.2 but not 3.2.4 or later (lslpp -h bos.obj -output reports 03.02.0000.0000), a newer update to the assembler fix -is available. Ask for shipment of AIX/6000 fix PTF U416277 for -IX32992 (.global prevents detection of duplicate symbol). - -If you are running AIX 3.2.4 or later, you already have the new -assembler. - -Any customer can order and get the replacement assembler, and install it on -one or more machines. It is available on diskette from IBM Customer Support -and from its website. - -If you contact IBM Customer Support, they may also ask you for your customer -number. If you do not know it, you will still be able to get the fix, but -you will have to be persistent. IBM has corresponding support organizations -outside of North America. Call your IBM branch office and ask them to put -you in touch with the department that handles fixes for AIX/6000. If that -doesn't work, ask for the department that handles software defect support -for AIX/6000 and ask for the APAR fix. - -If you use the GNU assembler instead of the system supplied assembler, you need -an assembler modified after October 16th, 1995 in order to build the GNU C -compiler. This is because the GNU C compiler wants to build a variant of its -library, libgcc.a with the -mcpu=common switch to support building programs -that can run on either the Power or PowerPC machines. diff --git a/gcc/README.TRAD b/gcc/README.TRAD deleted file mode 100755 index 07ccd16..0000000 --- a/gcc/README.TRAD +++ /dev/null @@ -1,55 +0,0 @@ -This is a partial list of how `gcc -traditional' disagrees with -traditional C compilers (perhaps only some of them). Most of these -differences are not bugs. - ---------------------------------------------------------------------------- -K&R-1 (2.4.3) says: - - "If the character following a backslash is not one of those - specified {in the table above}, the backslash is ignored." - -Up until recently, `gcc -traditional' complained about \x \a and \v -appearing in a character or string literal. I believe however that -this non-feature has been eliminated (recently). - ---------------------------------------------------------------------------- -When in -traditional mode, gcc allows the following erroneous pair of -declarations to appear together in a given scope: - - typedef int foo; - typedef foo foo; - ---------------------------------------------------------------------------- -K&R-1 (8.5) says: - - "No field may be wider than a word." - -Gcc however allows: - - struct S { int i:33; }; - ---------------------------------------------------------------------------- -In K&R-1 there is no restriction against comments crossing include file -boundaries. Gcc however doesn't allow this, even when in -traditional mode. - ---------------------------------------------------------------------------- -Regarding the length of identifiers, K&R-1 (2.2) says: - - "No more than the first eight characters are significant, - although more may be used." - -Gcc treats all characters of identifiers as significant, even when in --traditional mode. - ---------------------------------------------------------------------------- -K&R-1 (2.2) says: - - "An identifier is a sequence of letters and digits; the first - character must be a letter. The underscore _ counts as a letter." - -Gcc also allows dollar signs in identifiers. (This may also be an issue -for the -pedantic option.) - ---------------------------------------------------------------------------- - - diff --git a/gcc/README.X11 b/gcc/README.X11 deleted file mode 100755 index aa68854..0000000 --- a/gcc/README.X11 +++ /dev/null @@ -1,447 +0,0 @@ -[This file contains two alternative recipes for compiling X11 with GCC. -The first alternative puts libgcc.a into the shared X library; the second -does not. Neither alternative works on all kinds of systems. -It may be that when using GCC 2.4, both alternatives work okay on -relatively recent Sparc systems. The first alternative is likely -not to work on a Sun 3 without hardware floating point.] - -How to compile X11R5 (patch level 11) with GCC version 2: - -The patches include support for building the shared libraries with GCC -2 on the Sparc and 68k machines. This version includes the necessary -parts of libgcc.a in the shared library for X, in case functions in -that library need it. Thus the default behavior is now to build -everything, including the libraries, with gcc. - -If you build the shared library this way, it may not work with -executables made with older versions of GCC (2.3.3 and earlier). -If that happens, relink those executables with the latest GCC. -IF YOU THINK YOU MIGHT COMPILE X FOR SOLARIS 2, then you really don't -need this patch: get /contrib/R5.SunOS5.patch.tar.Z from -export.lcs.mit.edu instead. It has everything you need to do the -build for Solaris 2, sets you up to everything with GCC, and is -backward compatible with SunOS 4.*. Get the README -(/contrib/R5.SunOS5.patch.README at export) for more info. - -If you see undefined symbols _dlopen, _dlsym, or _dlclose when linking -with -lX11, compile and link against the file mit/util/misc/dlsym.c in -the MIT X11R5 distribution. Alternatively, do dynamic linking -by using a non-GNU ld. - -mit/config/Imake.tmpl -- Do not set -fstrength-reduce if we have GCC 2. -If -fstrength-reduce (or any other -f option) is a major win, then it -will most likely be turned on by -O2 optimization. - -mit/config/sunLib.rules -- If HasGcc and GccVersion > 1 are true, then -use gcc -fpic to generate PIC code. Make sure that gcc does not use -gas (the GNU assembler) when compiling PIC code; gas does not assemble -it correctly. - -***If you have gas installed where gcc uses it by default, you might have -to add -B/bin/ to the PositionIndependentCFlags.*** - -mit/config/site.def -- Define GccVersion to be 2. - -mit/config/sun.cf -- When compiling with GCC 2, use -O2 optimization. - -mit/config/sunLib.rules -- When compiling with GCC 2, use -fpic for -position independent code generation. - -mit/rgb/Imakefile -- No longer need to compile some modules with -cc on the Sparc since GCC 2 produces proper -fpcc-struct-return code. - -mit/server/os/Imakefile -- Likewise. - -mit/server/ddx/sun/Imakefile -- When compiling with GCC 2, some modules -should be compiled with -fvolatile. - -mit/clients/twm/Imakefile -- Fix bad decls of malloc, realloc in gram.c. - -mit/lib/X/Imakefile -- Make libgcc.a a required lib for libX11.so - -*** mit/clients/twm/Imakefile Mon May 17 22:05:22 1993 ---- new/clients/twm/Imakefile Mon May 17 22:28:46 1993 -*************** -*** 32,41 **** ---- 32,48 ---- - ComplexProgramTarget(twm) - InstallNonExecFile(system.twmrc,$(TWMDIR)) - -+ #if HasGcc && GccVersion > 1 && defined (SunArchitecture) - gram.h gram.c: gram.y - yacc $(YFLAGS) gram.y -+ sed -e 's/^extern char \*malloc(), \*realloc();//g' y.tab.c >gram.c -+ $(MV) y.tab.h gram.h -+ #else -+ gram.h gram.c: gram.y -+ yacc $(YFLAGS) gram.y - $(MV) y.tab.c gram.c - $(MV) y.tab.h gram.h -+ #endif - - clean:: - $(RM) y.tab.h y.tab.c lex.yy.c gram.h gram.c lex.c deftwmrc.c -*** mit/config/Imake.tmpl Mon May 17 22:02:57 1993 ---- new/config/Imake.tmpl Mon May 17 22:15:06 1993 -*************** -*** 500,506 **** ---- 500,510 ---- - #endif - #ifndef CcCmd - #if HasGcc -+ #if GccVersion > 1 -+ #define CcCmd gcc -fpcc-struct-return -+ #else - #define CcCmd gcc -fstrength-reduce -fpcc-struct-return -+ #endif - #else - #define CcCmd cc - #endif -*** mit/config/site.def Mon May 17 22:02:44 1993 ---- new/config/site.def Mon May 17 22:22:28 1993 -*************** -*** 25,31 **** - - #ifdef BeforeVendorCF - -! /* #define HasGcc YES */ - - #endif /* BeforeVendorCF */ - ---- 25,33 ---- - - #ifdef BeforeVendorCF - -! #define HasGcc YES -! /* GccVersion > 1 implies building shared libraries with gcc */ -! #define GccVersion 2 - - #endif /* BeforeVendorCF */ - -*** mit/config/sun.cf Mon May 17 22:03:02 1993 ---- new/config/sun.cf Mon May 17 22:24:55 1993 -*************** -*** 41,49 **** ---- 41,55 ---- - - #if HasGcc - -+ #if GccVersion > 1 -+ #define OptimizedCDebugFlags -O2 -+ #else -+ #define OptimizedCDebugFlags -O - #define SharedLibraryCcCmd cc - #define ExtraLoadFlags -B/usr/bin/ - #define AllocateLocalDefines /**/ -+ #endif -+ - - .c.o: - $(CC) -c $(CFLAGS) $*.c -*** mit/config/sunLib.rules Mon May 17 22:02:46 1993 ---- new/config/sunLib.rules Mon May 17 22:19:06 1993 -*************** -*** 23,29 **** ---- 23,33 ---- - #define SharedLibraryLoadFlags -assert pure-text - #endif - #ifndef PositionIndependentCFlags -+ #if defined(HasGcc) && GccVersion > 1 -+ #define PositionIndependentCFlags -fpic -+ #else - #define PositionIndependentCFlags -pic -+ #endif - #endif - - /* -*** mit/lib/X/Imakefile Mon May 17 22:05:03 1993 ---- new/lib/X/Imakefile Mon May 17 22:32:26 1993 -*************** -*** 9,14 **** ---- 9,31 ---- - #define MotifBC NO - #endif - -+ #if defined(SunArchitecture) -+ #if SystemV4 -+ #if HasGcc -+ REQUIREDLIBS= -lgcc -lc -+ #else -+ REQUIREDLIBS= -lc -+ #endif -+ #else -+ #if HasGcc && GccVersion > 1 -+ XCOMM Hack to fix gcc 2 ``-nostdlib'' deficiency on SunOS 4.x -+ REQUIREDLIBS= `gcc -v 2>&1 | awk '{print $$4}' | sed -e 's/specs$$/libgcc.a/'` -+ #else -+ REQUIREDLIBS= -+ #endif -+ #endif -+ #endif -+ - #ifndef BuildXimp - #define BuildXimp NO - #endif -*** mit/rgb/Imakefile Mon May 17 22:05:31 1993 ---- new/rgb/Imakefile Mon May 17 22:25:30 1993 -*************** -*** 17,23 **** - #if !(defined(SGIArchitecture) || SystemV4) - DBMLIB = -ldbm - #endif -! #if defined(SparcArchitecture) && HasGcc - CC = cc - CCOPTIONS = /**/ - EXTRA_LOAD_FLAGS = /**/ ---- 17,23 ---- - #if !(defined(SGIArchitecture) || SystemV4) - DBMLIB = -ldbm - #endif -! #if defined(SparcArchitecture) && HasGcc && GccVersion <= 1 - CC = cc - CCOPTIONS = /**/ - EXTRA_LOAD_FLAGS = /**/ -*** mit/server/ddx/sun/Imakefile Mon May 17 22:05:57 1993 ---- new/server/ddx/sun/Imakefile Mon May 17 22:27:23 1993 -*************** -*** 43,48 **** ---- 43,53 ---- - LinkFile(sunGX.o,sunGX.o.dist) - #endif - -+ #if HasGcc && GccVersion > 1 -+ SpecialObjectRule(sunCG2C.o,sunCG2C.c,-fvolatile) -+ SpecialObjectRule(sunCG2M.o,sunCG2M.c,-fvolatile) -+ #endif -+ - sunInitExtMono.o: $(ICONFIGFILES) - ObjectFromSpecialSource(sunInitExtMono,../mi/miinitext,-UPEXEXT) - ObjectFromSpecialSource(sunInitMono,sunInit,-DMONO_ONLY) -*** mit/server/os/Imakefile Mon May 17 22:05:46 1993 ---- new/server/os/Imakefile Mon May 17 22:26:02 1993 -*************** -*** 132,138 **** - SpecialObjectRule(osinit.o,$(ICONFIGFILES),$(ADM_DEFINES)) - SpecialObjectRule(WaitFor.o,$(ICONFIGFILES),$(EXT_DEFINES)) - SpecialObjectRule(fonttype.o,$(ICONFIGFILES),$(FONT_DEFINES)) -! #if defined(SparcArchitecture) && HasGcc - oscolor.o: $(ICONFIGFILES) - $(RM) $@ - cc -c $(DBM_DEFINES) $(CDEBUGFLAGS) $(ALLDEFINES) $*.c ---- 132,138 ---- - SpecialObjectRule(osinit.o,$(ICONFIGFILES),$(ADM_DEFINES)) - SpecialObjectRule(WaitFor.o,$(ICONFIGFILES),$(EXT_DEFINES)) - SpecialObjectRule(fonttype.o,$(ICONFIGFILES),$(FONT_DEFINES)) -! #if defined(SparcArchitecture) && HasGcc && GccVersion <= 1 - oscolor.o: $(ICONFIGFILES) - $(RM) $@ - cc -c $(DBM_DEFINES) $(CDEBUGFLAGS) $(ALLDEFINES) $*.c - - -[This is the older version] - -How to compile X11R5 (patch level 11) with GCC version 2: - -The patches include support for building the shared libraries with GCC 2 on -the Sparc and 68k machines. - -NOTE: Such shared libraries built with GCC version 2.3 DID NOT WORK -with executables previously linked using Sun CC! This is because -neither those executables nor the gcc-compiled shared libraries contain -libgcc.a. The shared libraries did work with executables linked using -GCC (running the Sun linker, of course) because GCC tells the linker to -link in libgcc.a. Because of these limitations the default behavior is -to NOT build the shared libraries with gcc. - -Changes in GCC 2.4 seem to have eliminated the problem, and such a -shared library now seems work with all executables. If you want the -gcc-compiled shared libraries turn on "Gcc2BuildLibs" in site.def. If -you try this, please tell bug-gcc@prep.ai.mit.edu whether it works. - -Sun forgot to include a static version of libdl.a with some versions -of SunOS (4.1 mainly). If you see undefined symbols _dlopen, _dlsym, -or _dlclose when linking with -lX11, compile and link against the file -mit/util/misc/dlsym.c in the MIT X11R5 distribution. - -mit/config/Imake.tmpl -- Do not set -fstrength-reduce if we have GCC 2. If --fstrength-reduce (or any other -f option) is a major win, then it will -most likely be turned on by -O2 optimization. - -mit/config/sunLib.rules -- If HasGcc2 and Gcc2BuildLibs are defined, then -use gcc -fpic to generate PIC code. Make sure that gcc does not use gas (the -GNU assembler) when compiling PIC code; gas does not assemble it correctly. -If you have gas installed where gcc uses it by default, you might have to add --B/bin/ to the PositionIndependentCFlags. - -mit/config/site.def -- Define HasGcc2 to be YES. - -mit/config/sun.cf -- When compiling with GCC 2, use -O2 optimization. - -mit/rgb/Imakefile -- No longer need to compile some modules with -cc on the Sparc since GCC 2 produces proper -fpcc-struct-return code. - -mit/server/os/Imakefile -- Likewise. - -mit/clients/twm/Imakefile -- fix bad decls of malloc, realloc in gram.c. - -*** mit/config/Imake.tmpl.ORIG Tue Dec 31 11:07:56 1991 ---- mit/config/Imake.tmpl Tue Dec 31 12:30:47 1991 -*************** -*** 499,508 **** ---- 499,512 ---- - #define HasGcc NO - #endif - #ifndef CcCmd -+ #if HasGcc2 -+ #define CcCmd gcc -fpcc-struct-return -+ #else - #if HasGcc - #define CcCmd gcc -fstrength-reduce -fpcc-struct-return - #else - #define CcCmd cc -+ #endif - #endif - #endif - #if HasFortran -*** mit/config/sunLib.rules.ORIG Tue Dec 31 11:11:24 1991 ---- mit/config/sunLib.rules Tue May 5 12:26:12 1992 -*************** -*** 23,30 **** ---- 23,34 ---- - #define SharedLibraryLoadFlags -assert pure-text - #endif - #ifndef PositionIndependentCFlags -+ #if defined(HasGcc2) && defined (Gcc2BuildLibs) -+ #define PositionIndependentCFlags -fpic -+ #else - #define PositionIndependentCFlags -pic - #endif -+ #endif - - /* - * InstallSharedLibrary - generate rules to install the shared library. -*** mit/config/site.def.ORIG Tue Dec 31 11:13:49 1991 ---- mit/config/site.def Tue Dec 31 12:02:59 1991 -*************** -*** 25,31 **** - - #ifdef BeforeVendorCF - -! /* #define HasGcc YES */ - - #endif /* BeforeVendorCF */ - ---- 25,33 ---- - - #ifdef BeforeVendorCF - -! #define HasGcc YES -! #define HasGcc2 YES -! /* #define Gcc2BuildLibs YES */ - - #endif /* BeforeVendorCF */ - -*** mit/config/sun.cf.ORIG Tue Dec 31 11:13:57 1991 ---- mit/config/sun.cf Tue May 5 12:29:50 1992 -*************** -*** 34,42 **** ---- 41,61 ---- - - #if HasGcc - -+ #if defined(HasGcc2) -+ #define OptimizedCDebugFlags -O2 -+ /* Leave Alone XXX */ -+ #else -+ #define OptimizedCDebugFlags -O - #define SharedLibraryCcCmd cc - #define ExtraLoadFlags -B/usr/bin/ - #define AllocateLocalDefines /**/ -+ #endif -+ -+ #if !defined(Gcc2BuildLibs) -+ #define SharedLibraryCcCmd cc -+ #define ExtraLoadFlags -B/usr/bin/ -+ #define AllocateLocalDefines /**/ -+ #endif - - .c.o: - $(CC) -c $(CFLAGS) $*.c -*** mit/rgb/Imakefile.ORIG Wed Jan 15 16:43:18 1992 ---- mit/rgb/Imakefile Thu Jan 2 13:34:09 1992 -*************** -*** 17,23 **** - #if !(defined(SGIArchitecture) || SystemV4) - DBMLIB = -ldbm - #endif -! #if defined(SparcArchitecture) && HasGcc - CC = cc - CCOPTIONS = /**/ - EXTRA_LOAD_FLAGS = /**/ ---- 17,23 ---- - #if !(defined(SGIArchitecture) || SystemV4) - DBMLIB = -ldbm - #endif -! #if defined(SparcArchitecture) && HasGcc && !defined(HasGcc2) - CC = cc - CCOPTIONS = /**/ - EXTRA_LOAD_FLAGS = /**/ -*** mit/server/os/Imakefile.ORIG Wed Jan 15 16:46:23 1992 ---- mit/server/os/Imakefile Wed Jan 15 16:46:48 1992 -*************** -*** 132,138 **** - SpecialObjectRule(osinit.o,$(ICONFIGFILES),$(ADM_DEFINES)) - SpecialObjectRule(WaitFor.o,$(ICONFIGFILES),$(EXT_DEFINES)) - SpecialObjectRule(fonttype.o,$(ICONFIGFILES),$(FONT_DEFINES)) -! #if defined(SparcArchitecture) && HasGcc - oscolor.o: $(ICONFIGFILES) - $(RM) $@ - cc -c $(DBM_DEFINES) $(CDEBUGFLAGS) $(ALLDEFINES) $*.c ---- 132,138 ---- - SpecialObjectRule(osinit.o,$(ICONFIGFILES),$(ADM_DEFINES)) - SpecialObjectRule(WaitFor.o,$(ICONFIGFILES),$(EXT_DEFINES)) - SpecialObjectRule(fonttype.o,$(ICONFIGFILES),$(FONT_DEFINES)) -! #if defined(SparcArchitecture) && HasGcc && !defined(HasGcc2) - oscolor.o: $(ICONFIGFILES) - $(RM) $@ - cc -c $(DBM_DEFINES) $(CDEBUGFLAGS) $(ALLDEFINES) $*.c -*** 1.1 1992/09/08 19:52:07 ---- mit/server/ddx/sun/Imakefile 1992/09/08 21:10:22 -*************** -*** 43,48 **** ---- 43,53 ---- - LinkFile(sunGX.o,sunGX.o.dist) - #endif - -+ #if HasGcc2 -+ SpecialObjectRule(sunCG2C.o,sunCG2C.c,-fvolatile) -+ SpecialObjectRule(sunCG2M.o,sunCG2M.c,-fvolatile) -+ #endif -+ - sunInitExtMono.o: $(ICONFIGFILES) - ObjectFromSpecialSource(sunInitExtMono,../mi/miinitext,-UPEXEXT) - ObjectFromSpecialSource(sunInitMono,sunInit,-DMONO_ONLY) - -*** /tmp/RCSAa24446 Tue Sep 15 12:23:32 1992 ---- mit/clients/twm/Imakefile Thu Aug 13 18:18:07 1992 -*************** -*** 32,41 **** ---- 32,48 ---- - ComplexProgramTarget(twm) - InstallNonExecFile(system.twmrc,$(TWMDIR)) - -+ #if HasGcc2 && defined (SunArchitecture) - gram.h gram.c: gram.y - yacc $(YFLAGS) gram.y -+ sed -e 's/^extern char \*malloc(), \*realloc();//g' y.tab.c >gram.c -+ $(MV) y.tab.h gram.h -+ #else -+ gram.h gram.c: gram.y -+ yacc $(YFLAGS) gram.y - $(MV) y.tab.c gram.c - $(MV) y.tab.h gram.h -+ #endif - - clean:: - $(RM) y.tab.h y.tab.c lex.yy.c gram.h gram.c lex.c deftwmrc.c - diff --git a/gcc/README.g77 b/gcc/README.g77 deleted file mode 100755 index f22f179..0000000 --- a/gcc/README.g77 +++ /dev/null @@ -1,263 +0,0 @@ -1998-08-11 - -This directory contains the egcs variant of version 0.5.24 of the -GNU Fortran compiler (g77). The GNU Fortran compiler is free software. -See the file COPYING.g77 for copying permission. - -Currently, two variants of g77 exist. One is the Free Software Foundation -(FSF) variant. The other is the egcs variant. As of egcs version 1.1, -these variants are kept fairly similar in most respects. Pertinent -differences, such as the layout of the source code, are specified below. - -Below, `[FSF]' denotes information applicable to only the FSF variant of -g77, while `[egcs]' denotes egcs-only information. - - -* IMPORTANT: Things you *must* do (or avoid) are marked with a * at the - beginning of the line in this file!!! - - -The email address to which bugs are to be reported is either -[FSF] <fortran@gnu.org> or [egcs] <egcs-bugs@cygnus.com>. - -* *DO NOT* send any email (reporting bugs, asking questions, etc.) to - either of these addresses without *first* reading the g77 documentation. - Use `info', Info mode in GNU Emacs, or a text viewer such as `more' to - do this. - - The g77 documentation is in the source files named `g77.info', - `g77.info-1', `g77.info-2', and so on in the `f' subdirectory. If these - files are not present or you can't find them, contact the person or - organization that put together the g77 distribution you are using (probably - not the FSF or egcs), or ask your system administrator for help. - - -This README applies to only the g77-specific portions of the source-code -tree that contains it. These portions include: - - - The README.g77 and [FSF] COPYING.g77 files, in this directory, "this - directory" being [FSF] the top-level directory containing a g77 - distribution or [egcs] the gcc/ subdirectory of an egcs distribution. - - - The g77 front end, in the f/ subdirectory of this directory. - - - The libg2c library, in [FSF] the f/runtime/ subdirectory of this - directory or [egcs] the libf2c/ directory under the top-level - directory of the egcs distribution. - - -* To build g77, you must have a source distribution of [FSF] gcc - version 2.8 or [egcs] egcs version 1.1. Do not attempt to use - any other version of gcc or egcs, because this version of g77 is - designed to work with only those versions. - - Note that you must have *source* copies of the gcc or egcs distribution! - You cannot build g77 just using binaries of gcc or egcs. Also, unless - you are an expert, avoid using any distribution of gcc or egcs not - identical to the ones distributed by the FSF and Cygnus Support, - respectively. The primary FSF distribution site is: - - <ftp://ftp.gnu.org/pub/gnu/> - - The primary egcs distribution site is: - - <ftp://ftp.cygnus.com/pub/egcs/> - - Both of these sites have approved mirror sites from which valid - distributions also may be obtained. - -* Do not attempt to combine the egcs version of g77 with the FSF - gcc distribution, or the FSF version of g77 with the egcs gcc - distribution. Although the differences are minor, they might - be sufficient to prevent g77 from building properly, or from - working properly if the build appears to succeed. - -[FSF] g77 is distributed as g77-<version>/f/ so that unpacking the g77 -distribution is done in the normal GNU way, resulting in a directory having -the version number in the name. However, to build g77, the g77 distribution -must be merged with an appropriate gcc distribution, normally in a gcc -source directory, before configuring, building, and installing g77. - -[FSF] If you have just unpacked the g77 distribution, before proceeding, -you must merge the contents of the g77 distribution with the appropriate -gcc distribution on your system. - -* [FSF] Read and follow the instructions in f/INSTALL that - explain how to merge a g77 source directory into a gcc source - directory. You can use Info to read the same installation - instructions via: - - info -f f/g77.info -n Unpacking - -[FSF] The resulting directory layout includes the following, where gcc/ -might be a link to, for example, gcc-2.8.1/: - - gcc/ Non-g77 files in gcc - gcc/COPYING.g77 A copy of the GPL, under which g77 is licensed - gcc/README.g77 This file - gcc/f/ GNU Fortran front end - gcc/f/runtime/ libg2c configuration and g2c.h file generation - gcc/f/runtime/libF77/ Non-I/O portion of libg2c - gcc/f/runtime/libI77/ I/O portion of libg2c - gcc/f/runtime/libU77/ Additional interfaces to libc for libg2c - -[FSF] Applying g77 patches in the form of .diff files is done by typing -`patch -p1 -d gcc' (where gcc/ contains the f/ subdirectory). That is, -g77 patches are distributed in the same form, and at the same directory -level, as patches to the gcc distribution. (Note: make sure you're -using GNU patch, version 2.5 or later! Other versions of patch -have trouble with g77-related patches.) - -[egcs] The egcs version of g77 is distributed already merged with -the rest of egcs (such as the gcc back end). - -[egcs] The resulting directory layout includes the following, where egcs/ -might be a link to, for example, egcs-1.1/: - - egcs/gcc/ Non-g77 files in gcc - egcs/gcc/README.g77 This file - egcs/gcc/f/ GNU Fortran front end - egcs/libf2c/ libg2c configuration and g2c.h file generation - egcs/libf2c/libF77/ Non-I/O portion of libg2c - egcs/libf2c/libI77/ I/O portion of libg2c - egcs/libf2c/libU77/ Additional interfaces to libc for libg2c - -[egcs] Applying g77-specific patches to egcs is done the same way as -applying other egcs patches. - - -Below, `libf2c/' shall denote [FSF] gcc/f/runtime/ or [egcs] egcs/libf2c/, -while `f/' shall denote [FSF] the rest of gcc/f/ or [egcs] egcs/gcc/f/. - - -Components of note in g77 are described below. - -f/ as a whole contains the program GNU Fortran (g77), while libf2c/ -contains a portion of the separate program f2c. Note: The libf2c -code is not part of the program g77, just distributed with it. - -f/ contains text files that document the Fortran compiler, source -files for the GNU Fortran Front End (FFE), and some other stuff. -The g77 compiler code is placed in f/ because it, along with its contents, -is designed to be a subdirectory of a GNU CC (gcc) source directory, gcc/, -which is structured so that language-specific front ends can be "dropped -in" as subdirectories. The C++ front end (g++), is an example of this -- -it resides in the cp/ subdirectory. Note that the C front end (also -referred to as gcc) is an exception to this, as its source files reside -in the gcc/ directory itself. - -libf2c/ contains the run-time libraries for the f2c program, also used -by g77. These libraries normally referred to collectively as libf2c. -When built as part of g77, libf2c is installed under the name libg2c to avoid -conflict with any existing version of libf2c, and thus is often referred -to as libg2c when the g77 version is specifically being referred to. - -The netlib version of libf2c/ contains two distinct libraries, libF77 and -libI77, each in their own subdirectories. In g77, this distinction is not -made, beyond maintaining the subdirectory structure in the source-code tree. - -libf2c/ is not part of the program g77, just distributed with it. It -contains files not present in the official (netlib) version of libf2c, -and also contains some minor changes made from libf2c, to fix some bugs, -and to facilitate automatic configuration, building, and installation of -libf2c (as libg2c) for use by g77 users. - -* See libf2c/README for more information, including licensing conditions - governing distribution of programs containing code from libg2c. - -libg2c, g77's version of libf2c, adds Dave Love's implementation of -libU77, in the libf2c/libU77/ directory. This library is distributed -under the GNU Library General Public License (LGPL) -- see the -file libf2c/libU77/COPYING.LIB for more information, as this license -governs distribution conditions for programs containing code from -this portion of the library. - - -Files of note in g77 are described below. - -f/BUGS lists some important bugs known to be in g77. Or: - - info -f f/g77.info -n "Actual Bugs" - -f/ChangeLog lists recent changes to g77 internals. - -libf2c/ChangeLog lists recent changes to libg2c internals. - -[FSF] f/INSTALL describes how to build and install GNU Fortran. Or: - - info -f f/g77.info -n Installation - -f/NEWS contains the per-release changes. These include the user-visible -changes described under "Changes" in the g77 documentation, plus internal -changes of import. Or: - - info -f f/g77.info -n News - -* All users of g77 (not just installers) should read f/g77.info* - as well, using the `more' command if neither the `info' command, - nor GNU Emacs (with its Info mode), are available, or if they - aren't yet accustomed to using these tools. Read f/BUGS and f/NEWS - plus, if you are planning on building or installing the FSF version - of g77, f/INSTALL, at the very least! All of these files are - readable as "plain text" files. - -* Also see <ftp://alpha.gnu.org/g77.plan> for up-to-date information - regarding g77 bug reports, known bugs, bug-fixes, and new versions. - - -The rest of this file is of note to only those who wish to -debug, modify, or test the FFE (in conjunction with the gcc back end). - -If you want to explore the FFE code, which lives entirely in f/, here -are a few clues. The file g77spec.c contains the g77-specific source code -for the `g77' command only -- this just forms a variant of the `gcc' -command, so, just as the `gcc' command itself does not contain -the C front end, the `g77' command does not contain the Fortran front -end (FFE). The FFE code ends up in an executable named `f771', which -does the actual compiling, so it contains the FFE plus the gcc back end -(the latter to do most of the optimization, and the code generation). - -The file parse.c is the source file for main() for a stand-alone FFE and -yyparse() for f771. (Stand-alone building of the FFE doesn't work these days.) -The file top.c contains the top-level FFE function ffe_file and it (along -with top.h) define all ffe_[a-z].*, ffe[A-Z].*, and FFE_[A-Za-z].* symbols. -The file fini.c is a main() program that is used when building the FFE to -generate C header and source files for recognizing keywords. The files -malloc.c and malloc.h comprise a memory manager that defines all -malloc_[a-z].*, malloc[A-Z].*, and MALLOC_[A-Za-z].* symbols. All other -modules named <xyz> are comprised of all files named <xyz>*.<ext> and -define all ffe<xyz>_[a-z].*, ffe<xyz>[A-Z].*, and FFE<XYZ>_[A-Za-z].* symbols. -If you understand all this, congratulations -- it's easier for me to remember -how it works than to type in these grep patterns (such as they are). But it -does make it easy to find where a symbol is defined -- for example, -the symbol "ffexyz_set_something" would be defined in xyz.h and implemented -there (if it's a macro) or in xyz.c. - -The "porting" files of note currently are: proj.h, which defines the -"language" used by all the other source files (the language being -Standard C plus some useful things like ARRAY_SIZE and such) -- change -this file when you find your system doesn't properly define a Standard C -macro or function, for example; target.h and target.c, which describe -the target machine in terms of what data types are supported, how they are -denoted (what C type does an INTEGER*8 map to, for example), how to convert -between them, and so on (though as of 0.5.3, more and more of this information -is being dynamically configured by ffecom_init_0); com.h and com.c, which -interface to the target back end (currently only FFE stand-alone and the GBE); -ste.c, which contains code for implementing recognized executable statements -in the target back end (again currently either FFE or GBE); src.h and src.c, -which describe information on the format(s) of source files (such as whether -they are never to be processed as case-insensitive with regard to Fortran -keywords); and proj.c, which contains whatever code is needed to support -the language defined by proj.h. - -If you want to debug the f771 executable, for example if it crashes, -note that the global variables "lineno" and "input_filename" are set -to reflect the current line being read by the lexer during the first-pass -analysis of a program unit and to reflect the current line being -processed during the second-pass compilation of a program unit. If -an invocation of the function ffestd_exec_end() is on the stack, -the compiler is in the second pass, otherwise it is in the first. -(This information might help you reduce a test case and/or work around -a bug in g77 until a fix is available.) - -Any questions or comments on these topics? Read the g77 documentation! diff --git a/gcc/README.gnat b/gcc/README.gnat deleted file mode 100755 index 2746665..0000000 --- a/gcc/README.gnat +++ /dev/null @@ -1,435 +0,0 @@ -The following patches are needed in order to build GNAT with EGCS. - -These patches were tested with egcs-980308 and gnat-3.10p on a mips-sgi-irix6.3 -system. The gnat build succeeded as per the instructions in the gnat -README.BUILD file for building one library, except that CFLAGS="-O -g" and -GNATLIBCFLAGS="-O -g" were substituted for the recommended "-O2" so that the -build could be debugged. There was no attempt to run the resulting build -against any testsuite or validation suite. - --- - -Developers Notes: - -Every use of sizetype in the Ada front end should be checked to see if perhaps -it should be using bitsizetype instead. The change to maybe_pad_type is just -a hack to work around this problem, and may not be desirable in the long term. - -There are many places in the Ada front end where it calls operand_equal_p to -see if two type sizes are the same. operand_equal_p fails if the two -arguments have different TYPE_MODEs. sizetype and bitsizetype can have -different TYPE_MODEs. Thus this code can fail if one type size is based -on sizetype, and the other is based on bitsizetype. The change to -maybe_pad_type fixes one very critical place where this happens. There may -be others. - --- - -Mon Mar 16 11:00:25 1998 Jim Wilson <wilson@cygnus.com> - - * a-gtran3.c (maybe_pad_type): Convert both size and orig_size to - sizetype if they have differing modes. - * a-misc.c (gnat_tree_code_type): Change from string to char array. - (init_lex): Delete realloc calls for tree_code_* globals. Adjust - bcopy call for gnat_tree_code_type change. - * a-tree.def: Adjust for tree_code_* type changes. - - * a-misc.c (init_lex): Rename to init_parse. - -diff -c ada/a-gtran3.c /home/brolley/comp/egcs/tmp/ada/a-gtran3.c -*** ada/a-gtran3.c Mon Mar 30 16:29:04 1998 ---- /home/brolley/comp/egcs/tmp/ada/a-gtran3.c Thu Apr 2 17:16:15 1998 -*************** -*** 3329,3334 **** ---- 3329,3341 ---- - isn't changing. Likewise, clear the alignment if it isn't being - changed. Then return if we aren't doing anything. */ - -+ if (size != 0 -+ && TYPE_MODE (TREE_TYPE (size)) != TYPE_MODE (TREE_TYPE (orig_size))) -+ { -+ size = convert (sizetype, size); -+ orig_size = convert (sizetype, orig_size); -+ } -+ - if (size != 0 - && (operand_equal_p (size, orig_size, 0) - || (TREE_CODE (orig_size) == INTEGER_CST -diff -c ada/a-misc.c /home/brolley/comp/egcs/tmp/ada/a-misc.c -*** ada/a-misc.c Mon Mar 30 16:29:05 1998 ---- /home/brolley/comp/egcs/tmp/ada/a-misc.c Thu Apr 2 17:36:19 1998 -*************** -*** 70,77 **** - - #define DEFTREECODE(SYM, NAME, TYPE, LENGTH) TYPE, - -! char *gnat_tree_code_type[] = { -! "x", - #include "a-tree.def" - }; - #undef DEFTREECODE ---- 70,77 ---- - - #define DEFTREECODE(SYM, NAME, TYPE, LENGTH) TYPE, - -! char gnat_tree_code_type[] = { -! 'x', - #include "a-tree.def" - }; - #undef DEFTREECODE -*************** -*** 254,259 **** ---- 254,268 ---- - print_lang_statistics () - {} - -+ void -+ lang_print_xnode (file, node, indent) -+ FILE *file; -+ tree node; -+ int indent; -+ { -+ } -+ -+ - /* integrate_decl_tree calls this function, but since we don't use the - DECL_LANG_SPECIFIC field, this is a no-op. */ - -*************** -*** 603,622 **** - it, but it's where g++ does it. */ - - void -! init_lex () - { - lang_expand_expr = gnat_expand_expr; - -- tree_code_type -- = (char **) realloc (tree_code_type, -- sizeof (char *) * LAST_GNAT_TREE_CODE); -- tree_code_length -- = (int *) realloc (tree_code_length, -- sizeof (int) * LAST_GNAT_TREE_CODE); -- tree_code_name -- = (char **) realloc (tree_code_name, -- sizeof (char *) * LAST_GNAT_TREE_CODE); -- - bcopy ((char *) gnat_tree_code_type, - (char *) (tree_code_type + (int) LAST_AND_UNUSED_TREE_CODE), - ((LAST_GNAT_TREE_CODE - (int) LAST_AND_UNUSED_TREE_CODE) ---- 612,622 ---- - it, but it's where g++ does it. */ - - void -! init_parse (filename) -! char *filename; - { - lang_expand_expr = gnat_expand_expr; - - bcopy ((char *) gnat_tree_code_type, - (char *) (tree_code_type + (int) LAST_AND_UNUSED_TREE_CODE), - ((LAST_GNAT_TREE_CODE - (int) LAST_AND_UNUSED_TREE_CODE) -*************** -*** 629,636 **** - - bcopy ((char *) gnat_tree_code_name, - (char *) (tree_code_name + (int) LAST_AND_UNUSED_TREE_CODE), -! ((LAST_GNAT_TREE_CODE - (int) LAST_AND_UNUSED_TREE_CODE) -! * sizeof (char *))); - } - - /* Sets some debug flags for the parsed. It does nothing here. */ ---- 629,640 ---- - - bcopy ((char *) gnat_tree_code_name, - (char *) (tree_code_name + (int) LAST_AND_UNUSED_TREE_CODE), -! LAST_GNAT_TREE_CODE - (int) LAST_AND_UNUSED_TREE_CODE); -! } -! -! void -! finish_parse () -! { - } - - /* Sets some debug flags for the parsed. It does nothing here. */ -diff -c ada/a-tree.def /home/brolley/comp/egcs/tmp/ada/a-tree.def -*** ada/a-tree.def Mon Mar 30 16:29:09 1998 ---- /home/brolley/comp/egcs/tmp/ada/a-tree.def Thu Apr 2 17:20:38 1998 -*************** -*** 31,69 **** - The only field used if TREE_COMPLEXITY, which contains the GNAT node - number. */ - -! DEFTREECODE (TRANSFORM_EXPR, "transform_expr", "e", 0) - - /* Perform an unchecked conversion between the input and the output. - if TREE_ADDRESSABLE is set, it means this is in an LHS; in that case, - we can only use techniques, such as pointer punning, that leave the - expression a "name". */ - -! DEFTREECODE (UNCHECKED_CONVERT_EXPR, "unchecked_convert_expr", "1", 1) - - /* A type that is an unconstrained array itself. This node is never passed - to GCC. TREE_TYPE is the type of the fat pointer and TYPE_OBJECT_RECORD_TYPE - is the type of a record containing the template and data. */ - -! DEFTREECODE (UNCONSTRAINED_ARRAY_TYPE, "unconstrained_array_type", "t", 0) - - /* A reference to an unconstrained array. This node only exists as an - intermediate node during the translation of a GNAT tree to a GCC tree; - it is never passed to GCC. The only field used is operand 0, which - is the fat pointer object. */ - -! DEFTREECODE (UNCONSTRAINED_ARRAY_REF, "unconstrained_array_ref", "r", 1) - - /* An expression that returns an RTL suitable for its type. Operand 0 - is an expression to be evaluated for side effects only. */ - -! DEFTREECODE (NULL_EXPR, "null_expr", "e", 1) - - /* An expression that emits a USE for its single operand. */ - -! DEFTREECODE (USE_EXPR, "use_expr", "e", 1) - - /* An expression that is treated as a conversion while generating code, but is - used to prevent infinite recursion when conversions of biased types are - involved. */ - -! DEFTREECODE (GNAT_NOP_EXPR, "gnat_nop_expr", "1", 1) ---- 31,69 ---- - The only field used if TREE_COMPLEXITY, which contains the GNAT node - number. */ - -! DEFTREECODE (TRANSFORM_EXPR, "transform_expr", 'e', 0) - - /* Perform an unchecked conversion between the input and the output. - if TREE_ADDRESSABLE is set, it means this is in an LHS; in that case, - we can only use techniques, such as pointer punning, that leave the - expression a "name". */ - -! DEFTREECODE (UNCHECKED_CONVERT_EXPR, "unchecked_convert_expr", '1', 1) - - /* A type that is an unconstrained array itself. This node is never passed - to GCC. TREE_TYPE is the type of the fat pointer and TYPE_OBJECT_RECORD_TYPE - is the type of a record containing the template and data. */ - -! DEFTREECODE (UNCONSTRAINED_ARRAY_TYPE, "unconstrained_array_type", 't', 0) - - /* A reference to an unconstrained array. This node only exists as an - intermediate node during the translation of a GNAT tree to a GCC tree; - it is never passed to GCC. The only field used is operand 0, which - is the fat pointer object. */ - -! DEFTREECODE (UNCONSTRAINED_ARRAY_REF, "unconstrained_array_ref", 'r', 1) - - /* An expression that returns an RTL suitable for its type. Operand 0 - is an expression to be evaluated for side effects only. */ - -! DEFTREECODE (NULL_EXPR, "null_expr", 'e', 1) - - /* An expression that emits a USE for its single operand. */ - -! DEFTREECODE (USE_EXPR, "use_expr", 'e', 1) - - /* An expression that is treated as a conversion while generating code, but is - used to prevent infinite recursion when conversions of biased types are - involved. */ - -! DEFTREECODE (GNAT_NOP_EXPR, "gnat_nop_expr", '1', 1) - - -This patch from Fred Fish to GNAT may make building simpler. We haven't -tested it. - -> I put a very short blurb in the faq. GNAT is complicated enough that -> we should probably write a whole page on how to build/install it. - -You may want to use some or all of these patches: - - * Make-lang.in (gnattools): Depends upon GCC_PARTS. - (ada.start.encap): Depends upon gnattools. - (ada.rest.encap): Depends upon gnatlib. - * Makefile.in (../stamp-gnatlib1): Since we are still in the rts - subdir when the rule runs, we need to touch ../../stamp-gnatlib1. - (../stamp-gnatlib1): Don't unconditionally remove the rts directory, - create it if one does not exist. - (gnatlib): Remove superflous leading blank char at *-*-pe line. - * a-init.c: Define NULL if not yet defined. - -Index: Make-lang.in -=================================================================== -RCS file: /cvsroot/gg/egcs/gcc/ada/Make-lang.in,v -retrieving revision 1.1.1.1 -retrieving revision 1.3 -diff -c -r1.1.1.1 -r1.3 -*** Make-lang.in 1997/10/17 06:19:09 1.1.1.1 ---- Make-lang.in 1998/03/17 14:26:14 1.3 -*************** -*** 100,106 **** - - # use host-gcc - # getopt*.o has to be built before CC=../xgcc -! gnattools: getopt.o getopt1.o force - $(MAKE) $(FLAGS_TO_PASS) $(ADA_FLAGS_TO_PASS)\ - CC="../xgcc -B../" GNATBIND="../gnatbind" \ - gnatf gnatlink gnatkr gnatmake gnatcmd gnatprep \ ---- 100,107 ---- - - # use host-gcc - # getopt*.o has to be built before CC=../xgcc -! # GCC_PARTS has to be built before CC=../xgcc -! gnattools: getopt.o getopt1.o $(GCC_PARTS) force - $(MAKE) $(FLAGS_TO_PASS) $(ADA_FLAGS_TO_PASS)\ - CC="../xgcc -B../" GNATBIND="../gnatbind" \ - gnatf gnatlink gnatkr gnatmake gnatcmd gnatprep \ -*************** -*** 163,170 **** - -if [ -f gnatls$(exeext) ] ; then\ - mv gnatls$(exeext) gnatls-cross$(exeext); fi - -! ada.start.encap: -! ada.rest.encap: - ada.info: - ada.dvi: - ---- 164,171 ---- - -if [ -f gnatls$(exeext) ] ; then\ - mv gnatls$(exeext) gnatls-cross$(exeext); fi - -! ada.start.encap: gnattools -! ada.rest.encap: gnatlib - ada.info: - ada.dvi: - -Index: Makefile.in -=================================================================== -RCS file: /cvsroot/gg/egcs/gcc/ada/Makefile.in,v -retrieving revision 1.1.1.1 -retrieving revision 1.5 -diff -c -r1.1.1.1 -r1.5 -*** Makefile.in 1997/10/17 06:19:09 1.1.1.1 ---- Makefile.in 1998/02/19 14:16:34 1.5 -*************** -*** 798,806 **** - # 3. copy 3xyyy.ad[sb] -->-- i-yyy.ad[sb] - - ../stamp-gnatlib1: Makefile ../stamp-gnatlib2 -! rm -rf rts -! mkdir rts -! chmod u+w rts - (\ - case $(target) in \ - sparc-sun-sunos4*) letter=u ;;\ ---- 800,806 ---- - # 3. copy 3xyyy.ad[sb] -->-- i-yyy.ad[sb] - - ../stamp-gnatlib1: Makefile ../stamp-gnatlib2 -! if [ -d rts ]; then true; else mkdir rts; chmod u+w rts; fi - (\ - case $(target) in \ - sparc-sun-sunos4*) letter=u ;;\ -*************** -*** 888,894 **** - done;; \ - esac ; \ - rm -f ../stamp-gnatlib ; \ -! touch ../stamp-gnatlib1) - - gnatlib-common: ../stamp-gnatlib1 - (subdir=`cd $(srcdir); pwd`; \ ---- 888,894 ---- - done;; \ - esac ; \ - rm -f ../stamp-gnatlib ; \ -! touch ../../stamp-gnatlib1) - - gnatlib-common: ../stamp-gnatlib1 - (subdir=`cd $(srcdir); pwd`; \ -*************** -*** 923,929 **** - mips-sni-* |\ - *-*-cygwin32* |\ - *-*-mingw32* |\ -! *-*-pe |\ - *) \ - \ - $(MAKE) CC="../../xgcc -B../../" \ ---- 923,929 ---- - mips-sni-* |\ - *-*-cygwin32* |\ - *-*-mingw32* |\ -! *-*-pe |\ - *) \ - \ - $(MAKE) CC="../../xgcc -B../../" \ -Index: a-init.c -=================================================================== -RCS file: /cvsroot/gg/egcs/gcc/ada/a-init.c,v -retrieving revision 1.1.1.1 -retrieving revision 1.2 -diff -c -r1.1.1.1 -r1.2 -*** a-init.c 1997/10/17 06:19:10 1.1.1.1 ---- a-init.c 1998/01/04 23:11:42 1.2 -*************** -*** 516,521 **** ---- 516,525 ---- - __gnat_raise (exception); - } - -+ #ifndef NULL -+ #define NULL 0 -+ #endif -+ - static void - __gnat_install_handler () - { - -Wed Jun 24 15:06:09 1998 Dave Brolley <brolley@cygnus.com> - - * a-misc.c (lang_decode_option): New interface. - * a-misc.h (lang_decode_option): New interface. - -*** /home/brolley/tmp/a-misc.c Wed Jun 24 15:01:22 1998 ---- ada/a-misc.c Wed Jun 24 15:02:42 1998 -*************** init_gnat_args () -*** 162,170 **** - it returns 0. */ - - int -! lang_decode_option (p) -! char *p; - { - extern int save_argc; - extern char **save_argv; - ---- 162,172 ---- - it returns 0. */ - - int -! lang_decode_option (argc, argv) -! int argc; -! char **argv; - { -+ char *p = argv[0]; - extern int save_argc; - extern char **save_argv; - -*** /home/brolley/tmp/a-misc.h Wed Jun 24 15:01:22 1998 ---- ada/a-misc.h Wed Jun 24 15:03:20 1998 -*************** enum gnat_tree_code { -*** 63,69 **** - option decoding phase of GCC calls this routine on the flags that it cannot - decode. This routine returns 1 if it is successful, otherwise it - returns 0. */ -! extern int lang_decode_option PROTO((char *)); - - /* Perform all the initialization steps that are language-specific. */ - extern void lang_init PROTO((void)); ---- 63,69 ---- - option decoding phase of GCC calls this routine on the flags that it cannot - decode. This routine returns 1 if it is successful, otherwise it - returns 0. */ -! extern int lang_decode_option PROTO((int, char **)); - - /* Perform all the initialization steps that are language-specific. */ - extern void lang_init PROTO((void)); |