This directory contains the GNU Compiler Collection (GCC) version 2.95.
It includes all of the support for compiling C, C++, Objective C, Fortran,
Java, and Chill.

The GNU Compiler Collection is free software.  See the file COPYING for copying
permission.

See the file gcc.texi (together with other files that it includes) for
installation and porting information.  The file INSTALL contains a
copy of the installation information, as plain ASCII.

Installing this package will create various files in subdirectories of
/usr/local/lib, which are passes used by the compiler and a library
named libgcc.a.  It will also create /usr/local/bin/gcc, which is
the user-level command to do a compilation.

See the Bugs chapter of the GCC Manual for how to report bugs
usefully.  An online readable version of the manual is in the files
gcc.info*.

The files pself.c and pself1.c are not part of GCC.
They are programs that print themselves on standard output.
They were written by Dario Dariol and Giovanni Cozzi, and are
included for your hacking pleasure.  Likewise pself2.c
(Who is the author of that?) and pself3.c (by Vlad Taeerov and Rashit
Fakhreyev).

The purpose of GCC pretesting is to verify that the new GCC
distribution, about to be released, works properly on your system *with
no change whatever*, when installed following the precise
recommendations that come with the distribution.

Here are some guidelines on how to do pretesting so as to make it
helpful.  All of them follow from common sense together with the
nature of the purpose and the situation.

* It is absolutely vital that you mention even the smallest change or
departure from the standard sources and installation procedure.

Otherwise, you are not testing the same program that I wrote.  Testing
a different program is usually of no use whatever.  It can even cause
trouble if you fail to tell me that you tested some other program
instead of what I know as GCC.  I might think that GCC works, when in
fact it has not been properly tried, and might have a glaring fault.

* Even changing the compilation options counts as a change in the
program.  The GCC sources specify which compilation options to use.
Some of them are specified in makefiles, and some in machine-specific
configuration files.

You have ways to override this--but if you do, then you are not
testing what ordinary users will do.  Therefore, when pretesting, it
is vital to test with the default compilation options.

(It is okay to test with nonstandard options as well as testing with
the standard ones.)

* The machine and system configuration files of GCC are parts of
GCC.  So when you test GCC, you need to do it with the
configuration files that come with GCC.

If GCC does not come with configuration files for a certain machine,
and you test it with configuration files that don't come with GCC,
this is effectively changing GCC.  Because the crucial fact about
the planned release is that, without changes, it doesn't work on that
machine.

To make GCC work on that machine, I would need to install new
configuration files.  That is not out of the question, since it is
safe--it certainly won't break any other machines that already work.
But you will have to rush me the legal papers to give the FSF
permission to use a large piece of text.

* Look for recommendations for your system.

You can find these recommendations in the Installation node of the
manual, and in the file INSTALL.  (These two files have the same text.)

These files say which configuration name to use for your machine, so
use the ones that are recommended.  If you guess, you might guess
wrong and encounter spurious difficulties.  What's more, if you don't
follow the recommendations then you aren't helping to test that its
recommendations are valid.

These files may describe other things that you need to do to make GCC
work on your machine.  If so, you should follow these recommendations
also, for the same reason.

Also look at the Trouble chapter of the manual for items that
pertain to your machine.

* Don't delay sending information.

When you find a problem, please double check it if you can do so
quickly.  But don't spend a long time double-checking.  A good rule is
always to tell me about every problem on the same day you encounter
it, even if that means you can't find a solution before you report the
problem.

I'd much rather hear about a problem today and a solution tomorrow
than get both of them tomorrow at the same time.

* Make each bug report self-contained.

If you refer back to another message, whether from you or from someone
else, then it will be necessary for anyone who wants to investigate
the bug to find the other message.  This may be difficult, it is
probably time-consuming.

To help me save time, simply copy the relevant parts of any previous
messages into your own bug report.

In particular, if I ask you for more information because a bug report
was incomplete, it is best to send me the *entire* collection of
relevant information, all together.  If you send just the additional
information, that makes me do extra work.  There is even a risk that
I won't remember what question you are sending me the answer to.

* Always be precise when talking about changes you have made.  Show
things rather than describing them.  Use exact filenames (relative to
the main directory of the distribution), not partial ones.  For
example, say "I changed Makefile" rather than "I changed the
makefile".  Instead of saying "I defined the MUMBLE macro", send a
diff that shows your change.

* Always use `diff -c' to make diffs.  If you don't include context,
it may be hard for me to figure out where you propose to make the
changes.  I might have to ignore your patch because I can't tell what
it means.

* When you write a fix, keep in mind that I can't install a change
that would break other systems.

People often suggest fixing a problem by changing machine-independent
files such as toplev.c to do something special that a particular
system needs.  Sometimes it is totally obvious that such changes would
break GCC for almost all users.  I can't possibly make a change like
that.  All I can do is send it back to you and ask you to find a fix
that is safe to install.

Sometimes people send fixes that *might* be an improvement in
general--but it is hard to be sure of this.  I can install such
changes some of the time, but not during pretest, when I am trying to
get a new version to work reliably as quickly as possible.

The safest changes for me to install are changes to the configuration
files for a particular machine.  At least I know those can't create
bugs on other machines.

* Don't try changing GCC unless it fails to work if you don't change it.

* Don't even suggest changes that would only make GCC cleaner.
Every change I install could introduce a bug, so I won't install
a change unless I see it is necessary.

* If you would like to suggest changes for purposes other than fixing
serious bugs, don't wait till pretest time.  Instead, send them just
after I make a release.  That's the best time for me to install them.

* In some cases, if you don't follow these guidelines, your
information might still be useful, but I might have to do more work to
make use of it.  Unfortunately, I am so far behind in my work that I
just can't get the job done unless you help me to do it efficiently.


				Thank you
				   rms

Local Variables:
mode: text
End:

This README file is copied into the directory for GCC-only header files
when fixincludes is run by the makefile for GCC.

Many of the files in this directory were made from the standard system
header files of this system by the shell script `fixincludes'.
They are system-specific, and will not work on any other kind of system.
They are also not part of GCC.  The reason for making the files here
is to fix the places in the header files which use constructs
that are incompatible with ANSI C.

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.

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

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

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

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.

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.

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));

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.

			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.2 binder

The AIX 4.3.2.1 linker (bos.rte.bind_cmds Level 4.3.2.1) will dump core
with a segmentation fault when invoked by any version of GCC.  A fix for
APAR IX87327 will be available from IBM Customer Support.


			   AIX 4.3.0 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.

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.)

---------------------------------------------------------------------------

[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 

Indexes created Thu May 16 13:05:45 MDT 2024