give the cvs tree a surviving a 'make world'. One of the two diff chunks
is already in gcc-3.3, the other has been committed to gcc's HEAD and
is in the pipeline for gcc-3.3.1 (but has not been committed yet).
The first chunk simplifies an excessively complex assembler statement
when generating switch jump tables. The use of '.' causes as(1) to choke
on big files. Use a simpler form instead. This is only an issue for
TARGET_64BIT mode.
The second chunk fixes an internal compiler error when compiling
libc/stdio/vfprinf.c. While this is supposedly only an issue for
64 bit mode, it does touch the 32 bit i386 code paths, so this patch
is only applied for TARGET_ARCH == amd64 to keep the risks down.
Breaking gcc at the 11th hour would suck.
This will be removed when it is time to import gcc-3.3.
Discussed with: kan
Approved by: re (jhb)
under way to move the remnants of the a.out toolchain to ports. As the
comment in src/Makefile said, this stuff is deprecated and one should not
expect this to remain beyond 4.0-REL. It has already lasted WAY beyond
that.
Notable exceptions:
gcc - I have not touched the a.out generation stuff there.
ldd/ldconfig - still have some code to interface with a.out rtld.
old as/ld/etc - I have not removed these yet, pending their move to ports.
some includes - necessary for ldd/ldconfig for now.
Tested on: i386 (extensively), alpha
where it is used. c-decl has symbols that conflict with several of the
cc1plus sources.
GNU `ld' was changed in Dec 1999 to be more be compatable with the way that
other linkers work (specifically in the Solaris linker). The 2.9.1 `ld',
did the Wrong Thing in that if a library contained a common symbol that
matched a definition of that symbol in another (already linked in object)
it would also be linked in, even if there was no other reason to do so.
This is wrong. The library should only be linked in if it contains
non-common, non-weak symbols which are needed by previously linked in
objects.
than ".so". The old extension conflicted with well-established
naming conventions for dynamically loadable modules.
The "clean" targets continue to remove ".so" files too, to deal with
old systems.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
(the old cc has been tagged with "gcc_2_6_3_final" so we have a reference
point in case of unforseen disasters...)
This has the objc backend active, and I think I've managed to get the
f77 f2c support through in one piece, but I don't know fortran to test it.
A 'make world' change and libobjc commit will follow.
If you normally do 'make -DNOCLEAN world', do not do so this time, I know
it can fail with groff.
This version of gcc makes a **LOT** more warnings on our kernel.
Notice that the libgcc DOESN'T change number, because there are no
changes.
Also now the gnu2bmake stuff is synchronized again.
I commit this so that others can test too.
You might want to postpone any "make worlds" until tomorrow, to
avoid any problems I didn't see in the first pass.
Thanks to Bruce for rounding up our changes to gcc.
no longer link against the whole library, since they don't require much
from it, but just compile the few small modules they actually need static.
This should save a measurable amount of space; compare:
-r-xr-xr-x 1 bin bin 155648 Sep 18 18:00 cc1*
-r-xr-xr-x 1 root bin 1048576 Sep 18 17:33 cc1.noshae*
Of course, the library takes up a bit of space, but when you add in the
savings from the C++ compiler, you more than make up the difference:
-r--r--r-- 1 bin bin 1157344 Sep 18 18:27 /usr/lib/libcc_int.so.26.0
-r-xr-xr-x 1 bin bin 491520 Sep 18 18:27 /usr/libexec/cc1plus*
