lenny@icus.islp.ny.us (Lenny Tropiano) (02/07/89)
After all the problems I had compiling gcc 1.32 on my UNIX pc, I decided
to ftp the diffs from prep.mit.edu for 1.32->1.33. I ran them through
patch, upgrading my 1.32 to 1.33. After that chugged along for quite
some time, I started the "make" ...
The compiler compiled flawlessly with the stock UNIX pc compiler (except
that I am already running the gnu-cpp (C Preprocessor) that will handle
the high amount of #defines that the GNU C compiler requires). Then
I recompiled the GNU C compiler with the compiled version of the compiler.
This compiled up fine as well! I was amazed .. no errors. Maybe we're
finally at a "stable version" of this compiler.
I set up a /usr/gnu directory subsystem, and the gnu programs are compiled
with shared libraries (with Alex's -shlib command line argument) and are
stripped. Here are the sizes:
total 4
1 drwxr-xr-x 4 gnu gnu 64 Jan 26 21:11 .
1 drwxr-xr-x 20 bin sys 320 Jan 26 21:10 ..
1 drwxr-xr-x 2 gnu gnu 80 Feb 7 00:12 bin
1 drwxr-xr-x 3 gnu gnu 128 Feb 6 23:57 lib
/usr/gnu/bin:
total 121
1 drwxr-xr-x 2 gnu gnu 80 Feb 7 00:12 .
1 drwxr-xr-x 4 gnu gnu 64 Jan 26 21:11 ..
94 -rwxr-xr-x 1 gnu gnu 47712 Feb 7 00:13 bison
25 -rwxr-xr-x 1 gnu gnu 12368 Feb 7 00:13 gcc
/usr/gnu/lib:
total 1081
1 drwxr-xr-x 3 gnu gnu 128 Feb 6 23:57 .
1 drwxr-xr-x 4 gnu gnu 64 Jan 26 21:11 ..
13 -rw-r--r-- 1 gnu gnu 6474 Jan 26 21:11 bison.hairy
30 -rw-r--r-- 1 gnu gnu 15022 Jan 26 21:11 bison.simple
934 -rwxr-xr-x 1 gnu gnu 478172 Feb 7 00:13 gcc-cc1
65 -rwxr-xr-x 1 gnu gnu 33232 Feb 7 00:13 gcc-cpp
36 -rw-r--r-- 1 gnu gnu 18030 Feb 7 00:12 gcc-gnulib
The gcc compiler definately generates better code than the UNIX pc stock
compiler. We'll see how it works here!
-Lenny
--
Lenny Tropiano ICUS Software Systems [w] +1 (516) 582-5525
lenny@icus.islp.ny.us Telex; 154232428 ICUS [h] +1 (516) 968-8576
{talcott,decuac,boulder,hombre,pacbell,sbcs}!icus!lenny attmail!icus!lenny
ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752roger@banzai.UUCP (Roger Florkowski) (02/08/89)
In article <594@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: >After all the problems I had compiling gcc 1.32 on my UNIX pc, I decided >to ftp the diffs from prep.mit.edu for 1.32->1.33. I ran them through >patch, upgrading my 1.32 to 1.33. After that chugged along for quite >some time, I started the "make" ... > >The compiler compiled flawlessly with the stock UNIX pc compiler (except >that I am already running the gnu-cpp (C Preprocessor) that will handle >the high amount of #defines that the GNU C compiler requires). Then >I recompiled the GNU C compiler with the compiled version of the compiler. >This compiled up fine as well! I was amazed .. no errors. Maybe we're >finally at a "stable version" of this compiler. > Last week I posted an article about gcc-1.32 working on my machine. Over the weekend I picked up the diffs to gcc-1.33. It bootstrapped perfectly. I have tested it on many public domain programs, and I have yet to find one that didn't work. All of the gcc compiled executibles are smaller than the cc compiled ones. A hint on using gcc: some programs 'like' it better if you use these flags: gcc -traditional -fwritable-strings If you find a program that doesn't compile, or behaves badly after compiled, try using these flags. -traditional affects gnu-cpp. Produces identical output to /lib/cpp ALSO UNDEFINES __STDC__ (this might fix some "newer" programs) -fwritable-strings affects what gcc does with character strings. /lib/ccom allowed writable strings. (read man-page) -- Roger Florkowski {uunet!uvm-gen, attmail}!banzai!roger The People's Computer Company `Revolutionary Programming'
lenny@icus.islp.ny.us (Lenny Tropiano) (02/10/89)
In article <1092@banzai.UUCP> roger@banzai.UUCP (Roger Florkowski) writes: |>In article <594@icus.islp.ny.us> lenny@icus.islp.ny.us (Me) write: |>>The compiler compiled flawlessly with the stock UNIX pc compiler .... |>A hint on using gcc: |> |>some programs 'like' it better if you use these flags: |> |>gcc -traditional -fwritable-strings |> ... |>-fwritable-strings affects what gcc does with character strings. |> /lib/ccom allowed writable strings. (read man-page) |> It would be better to fix the kludgy code that is taking constants, which the UNIX PC stock compiler puts in the "data" segment, and changing the contents of them. char *mystring = "hello, world\n"; Should go in the text segment (which the GNU gcc compiler does by default, unless specified with the -fwritable-strings option) which is sharable among processes on certain machines (I'm not sure how the UNIX pc handles it -- the old question of whether the "sticky-bit (t)" has any effect comes to mind again). It would not be good practice to modify "mystring" if it was initialized at compile time. The UNIX PC stock /lib/ccom (C compiler) would allow this, because it places the string in the data segment, without -fwritable-strings, any attempt to modify the mystring variable under the GNU gcc compiler would cause a "Memory fault" As the gcc documentation mentions, "constants should be constant!" Of course if you feel that you don't want to bother hacking up bad code to be correct, you can crutch on the -fwritable-strings compiler flag. -Lenny -- Lenny Tropiano ICUS Software Systems [w] +1 (516) 582-5525 lenny@icus.islp.ny.us Telex; 154232428 ICUS [h] +1 (516) 968-8576 {talcott,decuac,boulder,hombre,pacbell,sbcs}!icus!lenny attmail!icus!lenny ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752