obtained gcc-4.6.4.tar.bz2 from upstream website;upstream

verified gcc-4.6.4.tar.bz2.sig;
imported gcc-4.6.4 source tree from verified upstream tarball.

downloading a git-generated archive based on the 'upstream' tag
should provide you with a source tree that is binary identical
to the one extracted from the above tarball.

if you have obtained the source via the command 'git clone',
however, do note that line-endings of files in your working
directory might differ from line-endings of the respective
files in the upstream repository.

1 files changed, 322 insertions, 0 deletions

diff --git a/boehm-gc/doc/README.amiga b/boehm-gc/doc/README.amiga
new file mode 100644
index 000000000..730dce3fe
--- /dev/null
+++ b/boehm-gc/doc/README.amiga
@@ -0,0 +1,322 @@
+===========================================================================
+            Kjetil S. Matheussen's notes (28-11-2000)
+===========================================================================
+Compiles under SAS/C again. Should allso still compile under other
+amiga compilers without big changes. I haven't checked if it still
+works under gcc, because I don't have gcc for amiga. But I have
+updated 'Makefile', and hope it compiles fine.
+
+
+WHATS NEW:
+
+1.
+   Made a pretty big effort in preventing GCs allocating-functions from returning
+   chip-mem.
+
+   The lower part of the new file AmigaOS.c does this in various ways, mainly by
+   wrapping GC_malloc, GC_malloc_atomic, GC_malloc_uncollectable,
+   GC_malloc_atomic_uncollectable, GC_malloc_stubborn, GC_malloc_ignore_off_page
+   and GC_malloc_atomic_ignore_off_page. GC_realloc is allso wrapped, but
+   doesn't do the same effort in preventing to return chip-mem.
+   Other allocating-functions (f.ex. GC_*_typed_) can probably be
+   used without any problems, but beware that the warn hook will not be called.
+   In case of problems, don't define GC_AMIGA_FASTALLOC.
+
+   Programs using more time actually using the memory allocated
+   (instead of just allocate and free rapidly) have
+   the most to earn on this, but even gctest now normally runs twice
+   as fast and uses less memory, on my poor 8MB machine.
+
+   The changes have only effect when there is no more
+   fast-mem left. But with the way GC works, it
+   could happen quite often. Beware that an atexit handler had to be added,
+   so using the abort() function will make a big memory-loss.
+   If you absolutely must call abort() instead of exit(), try calling
+   the GC_amiga_free_all_mem function before abort().
+
+   New amiga-spesific compilation flags:
+
+   GC_AMIGA_FASTALLOC - By NOT defining this option, GC will work like before,
+                        it will not try to force fast-mem out of the OS, and
+                        it will use normal calloc for allocation, and the rest
+                        of the following flags will have no effect.
+
+   GC_AMIGA_ONLYFAST - Makes GC never to return chip-mem. GC_AMIGA_RETRY have
+                       no effect if this flag is set.
+
+   GC_AMIGA_GC - If gc returns NULL, do a GC_gcollect, and try again. This
+                 usually is a success with the standard GC configuration. 
+                 It is allso the most important flag to set to prevent
+                 GC from returning chip-mem. Beware that it slows down a lot
+                 when a program is rapidly allocating/deallocating when
+                 theres either very little fast-memory left or verly little
+                 chip-memory left. Its not a very common situation, but gctest
+                 sometimes (very rare) use many minutes because of this.
+
+   GC_AMIGA_RETRY - If gc succeed allocating memory, but it is chip-mem,
+                    try again and see if it is fast-mem. Most of the time,
+                    it will actually return fast-mem for the second try.
+                    I have set max number of retries to 9 or size/5000. You
+                    can change this if you like. (see GC_amiga_rec_alloc())
+
+   GC_AMIGA_PRINTSTATS - Gather some statistics during the execution of a
+                         program, and prints out the info when the atexit-handler
+                         is called.
+
+   My reccomendation is to set all this flags, except GC_AMIGA_PRINTSTATS and
+   GC_AMIGA_ONLYFAST.
+
+   If your program demands high response-time, you should
+   not define GC_AMIGA_GC, and possible allso define GC_AMIGA_ONLYFAST.
+   GC_AMIGA_RETRY does not seem to slow down much.
+
+   Allso, when compiling up programs, and GC_AMIGA_FASTALLOC was not defined when
+   compilling gc, you can define GC_AMIGA_MAKINGLIB to avoid having these allocation-
+   functions wrapped. (see gc.h)
+
+   Note that GC_realloc must not be called before any of
+   the other above mentioned allocating-functions have been called. (shouldn't be
+   any programs doing so either, I hope).
+
+   Another note. The allocation-function is wrapped when defining
+   GC_AMIGA_FASTALLOC by letting the function go thru the new
+   GC_amiga_allocwrapper_do function-pointer (see gc.h). Means that
+   sending function-pointers, such as GC_malloc, GC_malloc_atomic, etc.,
+   for later to be called like f.ex this, (*GC_malloc_functionpointer)(size),
+   will not wrap the function. This is normally not a big problem, unless
+   all allocation function is called like this, which will cause the
+   atexit un-allocating function never to be called. Then you either
+   have to manually add the atexit handler, or call the allocation-
+   functions function-pointer functions like this;
+   (*GC_amiga_allocwrapper_do)(size,GC_malloc_functionpointer).
+   There are probably better ways this problem could be handled, unfortunately,
+   I didn't find any without rewriting or replacing a lot of the GC-code, which
+   I really didn't want to. (Making new GC_malloc_* functions, and just
+   define f.ex GC_malloc as GC_amiga_malloc should allso work).
+
+
+   New amiga-spesific function:
+
+     void GC_amiga_set_toany(void (*func)(void));
+
+   'func' is a function that will be called right before gc has to change
+   allocation-method from MEMF_FAST to MEMF_ANY. Ie. when it is likely
+   it will return chip-mem.
+
+
+2. A few small compiler-spesific additions to make it compile with SAS/C again.
+
+3. Updated and rewritten the smakefile, so that it works again and that
+   the "unnecesarry" 'SCOPTIONS' files could be removed. Allso included
+   the cord-smakefile stuff in the main smakefile, so that the cord smakefile
+   could be removed too. By writing smake -f Smakefile.smk, both gc.lib and
+   cord.lib will be made.
+
+
+
+STILL MISSING:
+
+Programs can not be started from workbench, at least not for SAS/C. (Martin
+Tauchmanns note about that it now works with workbench is definitely wrong
+when concerning SAS/C). I guess it works if you use the old "#if 0'ed"-code,
+but I haven't tested it. I think the reason for MT to replace the
+"#if 0'ed"-code was only because it was a bit to SAS/C-spesific. But I
+don't know. An iconx-script solves this problem anyway.
+
+
+BEWARE!
+
+-To run gctest, set the stack to around 200000 bytes first.
+-SAS/C-spesific: cord will crash if you compile gc.lib with
+ either parm=reg or parm=both. (missing legal prototypes for
+ function-pointers someplace is the reason I guess.).
+
+
+tested with software: Radium, http://www.stud.ifi.uio.no/~ksvalast/radium/
+
+tested with hardware: MC68060
+
+
+-ksvalast@ifi.uio.no
+
+
+===========================================================================
+			   Martin Tauchmann's notes		(1-Apr-99)
+===========================================================================
+
+Works now, also with the GNU-C compiler V2.7.2.1. <ftp://ftp.unina.it/pub/amiga/geekgadgets/amiga/m68k/snapshots/971125/amiga-bin/>
+Modify the `Makefile`
+CC=cc $(ABI_FLAG)
+to
+CC=gcc $(ABI_FLAG)
+
+TECHNICAL NOTES
+
+- `GC_get_stack_base()`, `GC_register_data_segments()` works now with every
+   C compiler; also Workbench.
+
+- Removed AMIGA_SKIP_SEG, but the Code-Segment must not be scanned by GC.
+
+
+PROBLEMS
+- When the Linker, does`t merge all Code-Segments to an single one. LD of GCC
+  do it always.
+
+- With ixemul.library V47.3, when an GC program launched from another program
+  (example: `Make` or `if_mach M68K AMIGA gctest`), `GC_register_data_segments()`
+  found the Segment-List of the caller program.
+  Can be fixed, if the run-time initialization code (for C programs, usually *crt0*)
+  support `__data` and `__bss`.
+
+- PowerPC Amiga currently not supported.
+
+- Dynamic libraries (dyn_load.c) not supported.
+
+
+TESTED WITH SOFTWARE
+
+`Optimized Oberon 2 C` (oo2c) <http://cognac.informatik.uni-kl.de/download/index.html>
+
+
+TESTED WITH HARDWARE
+
+MC68030
+
+
+CONTACT
+
+Please, contact me at <martintauchmann@bigfoot.com>, when you change the
+Amiga port. <http://martintauchmann.home.pages.de>
+ 
+===========================================================================
+			   Michel Schinz's notes
+===========================================================================
+WHO DID WHAT
+
+The original Amiga port was made by Jesper Peterson. I (Michel Schinz)
+modified it slightly to reflect the changes made in the new official
+distributions, and to take advantage of the new SAS/C 6.x features. I also
+created a makefile to compile the "cord" package (see the cord
+subdirectory).
+
+TECHNICAL NOTES
+
+In addition to Jesper's notes, I have the following to say:
+
+- Starting with version 4.3, gctest checks to see if the code segment is
+  added to the root set or not, and complains if it is. Previous versions
+  of this Amiga port added the code segment to the root set, so I tried to
+  fix that. The only problem is that, as far as I know, it is impossible to
+  know which segments are code segments and which are data segments (there
+  are indeed solutions to this problem, like scanning the program on disk
+  or patch the LoadSeg functions, but they are rather complicated). The
+  solution I have chosen (see os_dep.c) is to test whether the program
+  counter is in the segment we are about to add to the root set, and if it
+  is, to skip the segment. The problems are that this solution is rather
+  awkward and that it works only for one code segment. This means that if
+  your program has more than one code segment, all of them but one will be
+  added to the root set. This isn't a big problem in fact, since the
+  collector will continue to work correctly, but it may be slower.
+
+  Anyway, the code which decides whether to skip a segment or not can be
+  removed simply by not defining AMIGA_SKIP_SEG. But notice that if you do
+  so, gctest will complain (it will say that "GC_is_visible produced wrong
+  failure indication"). However, it may be useful if you happen to have
+  pointers stored in a code segment (you really shouldn't).
+
+  If anyone has a good solution to the problem of finding, when a program
+  is loaded in memory, whether a segment is a code or a data segment,
+  please let me know.
+
+PROBLEMS
+
+If you have any problem with this version, please contact me at
+schinz@alphanet.ch (but do *not* send long files, since we pay for
+every mail!).
+
+===========================================================================
+			  Jesper Peterson's notes
+===========================================================================
+
+ADDITIONAL NOTES FOR AMIGA PORT
+
+These notes assume some familiarity with Amiga internals.
+
+WHY I PORTED TO THE AMIGA
+
+The sole reason why I made this port was as a first step in getting
+the Sather(*) language on the Amiga. A port of this language will
+be done as soon as the Sather 1.0 sources are made available to me.
+Given this motivation, the garbage collection (GC) port is rather
+minimal.
+
+(*) For information on Sather read the comp.lang.sather newsgroup.
+
+LIMITATIONS
+
+This port assumes that the startup code linked with target programs
+is that supplied with SAS/C versions 6.0 or later. This allows
+assumptions to be made about where to find the stack base pointer
+and data segments when programs are run from WorkBench, as opposed
+to running from the CLI. The compiler dependent code is all in the
+GC_get_stack_base() and GC_register_data_segments() functions, but
+may spread as I add Amiga specific features.
+
+Given that SAS/C was assumed, the port is set up to be built with
+"smake" using the "SMakefile". Compiler options in "SCoptions" can
+be set with "scopts" program. Both "smake" and "scopts" are part of
+the SAS/C commercial development system.
+
+In keeping with the porting philosophy outlined above, this port
+will not behave well with Amiga specific code. Especially not inter-
+process comms via messages, and setting up public structures like
+Intuition objects or anything else in the system lists. For the
+time being the use of this library is limited to single threaded
+ANSI/POSIX  compliant or near-complient code. (ie. Stick to stdio
+for now). Given this limitation there is currently no mechanism for
+allocating "CHIP" or "PUBLIC" memory under the garbage collector.
+I'll add this after giving it considerable thought. The major
+problem is the entire physical address space may have to me scanned,
+since there is no telling who we may have passed memory to.
+
+If you allocate your own stack in client code, you will have to
+assign the pointer plus stack size to GC_stackbottom.
+
+The initial stack size of the target program can be compiled in by
+setting the __stack symbol (see SAS documentaion). It can be over-
+ridden from the CLI by running the AmigaDOS "stack" program, or from
+the WorkBench by setting the stack size in the tool types window.
+
+SAS/C COMPILER OPTIONS (SCoptions)
+
+You may wish to check the "CPU" code option is appropriate for your
+intended target system.
+
+Under no circumstances set the "StackExtend" code option in either
+compiling the library or *ANY* client code.
+
+All benign compiler warnings have been suppressed. These mainly
+involve lack of prototypes in the code, and dead assignments
+detected by the optimizer.
+
+THE GOOD NEWS
+
+The library as it stands is compatible with the GigaMem commercial
+virtual memory software, and probably similar PD software.
+
+The performance of "gctest" on an Amiga 2630 (68030 @ 25Mhz)
+compares favourably with an HP9000 with similar architecture (a 325
+with a 68030 I think).
+
+-----------------------------------------------------------------------
+
+The Amiga port has been brought to you by:
+
+Jesper Peterson.
+
+jep@mtiame.mtia.oz.au		(preferred, but 1 week turnaround)
+jep@orca1.vic.design.telecom.au (that's orca<one>, 1 day turnaround)
+
+At least one of these addresses should be around for a while, even
+though I don't work for either of the companies involved.
+