This directory contains the version 1.40 release of the GNU C compiler. All bugs reported for previous test releases have been fixed. This version probably does not have very many bugs, and we no longer consider it a test version. See the file gcc.texinfo for installation and porting information. The file INSTALL contains a copy of the installation information. The GNU C compiler is free software. See the file COPYING for copying permission. The files print-self.c and print-self1.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.
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
Copyright (C) 1987 Free Software Foundation, Inc. Contributed by Michael Tiemann (tiemann@mcc.com) This file is part of GNU CC. GNU CC is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 1, or (at your option) any later version. GNU CC is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with GNU CC; see the file COPYING. If not, write to the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. This file describes the implementation notes of the GNU C Compiler for the National Semiconductor 32032 chip (and 32000 family). 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 refering 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.
Return-Path: <info-gcc-request@prep.ai.mit.edu>
Date: 11 Sep 90 14:07:21 GMT
From: news@operations.dccs.upenn.edu (USENET News System)
Organization: University of Pennsylvania
Subject: Building gcc 1.37.1 with Vax C
References: <9009102236.AA15872@wubios.wustl.edu>
Sender: info-gcc-request@prep.ai.mit.edu
To: info-gcc@prep.ai.mit.edu
during it; hopefully they'll come in handy.
To build the new gcc-cpp and gcc-cc1 that come with Gnu C
version 1.37.1 with Vax C and NOT a previous version of gcc,
do the following:
I - Building gcc-cpp
A - Modify cccp.c
1 - Replace
#include <sys/types.h>
#include <sys/stat.h>
with
#ifndef VMS
#include <sys/types.h>
#include <sys/stat.h>
#else
#include <types.h>
#include <stat.h>
#endif
[It is claimed that
$ define sys sys$library
will solve the same problem without source changes.]
2 - In the VMS-specific section (has perror.h etc in it),
add the following:
#include <descrip.h> /* for dsc$descriptor_s */
#include <string.h> /* for strchr & strrchr */
#define index strchr
#define rindex strrchr
3 - You have to replace all occurences of:
extern char *index(), *rindex();
as well as any where they're separated (e.g. extern char *index()
by itself or extern char *rindex() by itself), with the following:
#ifndef VMS
extern char *index(); /* or whatever was here */
#endif
There's a total of three: one in main(), one in do_include(), and
one in hack_vms_include_specification().
B - You have to have alloca.mar for cccp.c; it was distributed
with vmsgcc1.34; it's also in the bison distribution. (both 1.03
and 1.06)
C - After you've compiled alloca.mar (MACRO ALLOCA.MAR), follow
the instructions at the top of MAKE-CC1.COM (namely, change the
CC := line to say cc/noopt instead of gcc, take the
cc1_options="-mpcc-alignment" part out of the CFLAGS line, and change
the LIBS line to say:
$ LIBS := alloca,sys$share:vaxcrtl/libr
D - Since it doesn't come with the distribution, you have
to generate cexp_tab.c yourself, either with bison on either
a Vax or a Unix box, or yacc in Unix. (@make below will die if you
don't have bison on your Vax or don't have this file)
E - Type:
@make
and watch it hum. It should go through okay; it'll die on the LINK
line, but don't worry about it.
F - Now link the whole thing with:
link /nomap/exe=gcc-cpp cccp,cexp,version,alloca,-
sys$share:vaxcrtl/libr
G - You should be screaming for joy right now; if you're not, then
give up on life. <snicker>
II - Building gcc-cc1
A - Change MAKE-CC1.COM to contain the line:
$ libs :== sys$share:vaxcrtl/libr,alloca
Yep, you have to have alloca.obj here too.
B - Modify toplev.c:
1 - Replace
#include <sys/types.h>
#include <sys/stat.h>
with
#ifndef VMS
#include <sys/types.h>
#include <sys/stat.h>
#else
#include <types.h>
#include <stat.h>
#endif
(You'll see this again.)
2 - Do:
Repl: rtx_equal_function_value_matters
With: rtx_equ_func_value_matters
Num: once
This is cuz you can't have a name over 31 chars with the
Vax C compiler; and yep you guessed it this is over that
limit. You're gonna be doing this a few more times.
C - Modify gcc.c:
1 - This is optional, since you never compile it (I'm
working on that):
Replace
#include <stdio.h>
#include <sys/types.h>
#include <signal.h>
#include <sys/file.h>
with
#include <stdio.h>
#include <signal.h>
#ifdef VMS
#include <types.h>
#include <file.h>
#else
#include <sys/types.h>
#include <sys/file.h>
#endif
D - Modify c-parse_tab.c (if this isn't there, you'll have
to create it with bison or yacc):
Repl: expand_start_loop_continue_elsewhere
With: expand_startloop_cont_elsewhere
Num: twice
E - Modify tree.h:
Repl: expand_start_loop_continue_elsewhere
With: expand_startloop_cont_elsewhere
Num: once
F - Modify stmt.c:
Repl: expand_start_loop_continue_elsewhere
With: expand_startloop_cont_elsewhere
Num: twice
Repl: current_function_returns_pcc_struct
With: cur_func_ret_pcc_struct
Num: nine
Repl: current_function_returns_pointer
With: cur_func_ret_ptr
Num: 2
Repl: current_function_pretend_args_size
With: cur_func_pretend_args_size
Num: 3
G - Modify rtanal.c:
Repl: rtx_equal_function_value_matters
With: rtx_equ_func_values_matters
Num: twice
H - Modify output.h:
Repl: current_function_returns_pcc_struct
With: cur_func_ret_pcc_struct
Num: once
Repl: current_function_returns_pointer
With: cur_func_ret_ptr
Num: once
Repl: current_function_pretend_args_size
With: cur_func_pretend_args_size
Num: once
I - Modify tree.def:
Change the line that reads:
DEFTREECODE (FILE_TYPE, "file_type", "t", 0)
to:
#ifdef VMS
DEFTREECODE (FILE_TYPE_GNU, "file_type", "t", 0)
#else
DEFTREECODE (FILE_TYPE, "file_type", "t", 0)
#endif
This is cuz FILE_TYPE is defined in stdio.h as being
struct _iobuf *, which totally screws everything up.
J - Modify expr.c:
Change the line that reads:
if (code == FILE_TYPE)
to:
#ifdef VMS
if (code == FILE_TYPE_GNU)
#else
if (code == FILE_TYPE)
#endif
K - Modify expmed.c:
Change the line that reads:
trymode && GET_MODE_SIZE (trymode) <= maxsize;
to:
(trymode != 0) && (GET_MODE_SIZE (trymode) <= maxsize);
Enclosing the second half of the and in parenthesis may be
overkill. By the time I thought of it it was too late to
change it (read: I didn't feel like going back), but you
may want to give it a try.
L - Modify symout.c:
Change the line that has #include <stddef.h> on it to:
#ifndef VMS
#include <stddef.h>
#else
#define NULL (void *) 0
#endif
M - Modify insn-emit.c:
Line #1011 (in mine) is a 376-character long line that's
one HUGE return (it calls a function a few zillion times
embedded upon each other). This is a tad too big for Vax C
to chew; try cutting it down to a few lines. I made it look
like this:
rtx
gen_casesi (operand0, operand1, operand2, operand3)
rtx operand0;
rtx operand1;
rtx operand2;
rtx operand3;
{
return gen_rtx (SET, VOIDmode, pc_rtx,
gen_rtx (IF_THEN_ELSE, VOIDmode,
gen_rtx (LE, VOIDmode,
gen_rtx (MINUS, SImode, operand0, operand1),
operand2),
gen_rtx (PLUS, SImode,
gen_rtx (SIGN_EXTEND, SImode,
gen_rtx (MEM, HImode,
gen_rtx (PLUS, SImode, pc_rtx,
gen_rtx (MINUS, SImode, operand0, operand1)))),
gen_rtx (LABEL_REF, SImode, operand3)),
pc_rtx));
}
Kinda smacks of lisp, no?
N - Modify final.c:
Change the line that reads:
rtx final_sequence;
to:
#ifndef VMS
rtx final_sequence;
#endif
This is cuz rtx final_sequence already appears in
output.h, and Vax C screams when it sees this.
O - You have to have alloca(), bcopy(), bcmp(), and
bzero(); all are in the VMS Gcc 1.34 distribution; only
bcopy() is in the bison distribution. Since they're pretty
short, I'm gonna include 'em here. These were sent under the
Gnu public license.
alloca.mar:
.PSECT $CODE,LONG,PIC,REL,SHR,EXE,RD,NOWRT
.ENTRY ALLOCA,^M<>
SUBL2 4(AP),SP
MOVL 16(FP),R1
MOVQ 8(FP),AP
BICL2 #3,SP
ADDL2 #28,SP
MOVL SP,R0
JMP (R1)
.END
bcopy.mar:
.PSECT $CODE,LONG,PIC,REL,SHR,EXE,RD,NOWRT
; bcopy(from, to, size)
.ENTRY BCOPY,^M<R2,R3,R4,R5,R6>
MOVL 4(AP),R1
MOVL 8(AP),R3
MOVL 12(AP),R6
CMPL R1,R3
BGTR 2$ ; NORMAL FORWARD CASE
BLSS 3$ ; OVERLAPPING, MUST DO BACKWARDS
RET ; EQUAL, NOTHING TO DO
1$: SUBL2 R0,R6
MOVC3 R0,(R1),(R3)
2$: MOVZWL #65535,R0
CMPL R6,R0
BGTR 1$
MOVC3 R6,(R1),(R3)
RET
3$: ADDL2 R6,R1
ADDL2 R6,R3
MOVZWL #65535,R0
BRW 5$
4$: SUBL2 R0,R6
SUBL2 R0,R1
SUBL2 R0,R3
MOVC3 R0,(R1),(R3)
MOVZWL #65535,R0
SUBL2 R0,R1
SUBL2 R0,R3
5$: CMPL R6,R0
BGTR 4$
SUBL2 R6,R1
SUBL2 R6,R3
MOVC3 R6,(R1),(R3)
RET
.END
bcmp.mar:
.PSECT $CODE,LONG,PIC,REL,SHR,EXE,RD,NOWRT
; bcmp(s1, s2, n)
.ENTRY BCMP,^M<R2,R3,R4,R5>
MOVL 4(AP),R1
MOVL 8(AP),R3
MOVL 12(AP),R4
1$: MOVZWL #65535,R0
CMPL R4,R0
BLEQ 2$
SUBL2 R0,R4
CMPC3 R0,(R1),(R3)
BEQL 1$
ADDL2 R4,R0
RET
2$: CMPC3 R4,(R1),(R3)
RET
.END
bzero.mar:
.PSECT $CODE,LONG,PIC,REL,SHR,EXE,RD,NOWRT
; bzero(ptr, size)
.ENTRY BZERO,^M<R2,R3,R4,R5>
MOVL 4(AP),R3
BRB 2$
1$: SUBL2 R0,8(AP)
MOVC5 #0,(R3),#0,R0,(R3)
2$: MOVZWL #65535,R0
CMPL 8(AP),R0
BGTR 1$
MOVC5 #0,(R3),#0,8(AP),(R3)
RET
.END
P - On the last lines (where it's got all of the link shit),
change it so it reads:
...blahblahblah...
...blahblah,insn-extract,insn-output,obstack,-
integrate,caller-save,-
bcopy,bcmp,bzero
$!
So now it'll link the bcopy, bcmp, and bzero routines in.
Q - You should be screaming for joy right now; if you're
not, then give up on life again. Hey, I don't get paid for my humor.
R - Finally, you have to use old versions of:
GCC.EXE GCC-AS.EXE
GCC.COM GCC.CLD
GCCLIB.OLB
to make the package work properly. I've only been able to make the
new preprocessors make properly; since it wasn't even in the make
files that came with it, I don't think gcc.exe 1.37.1 was intended
to be built for the Vax .. we'll see.
In case you're wondering, I could never get vmsgcc134 to work properly;
that's why I did this with Vax C.
Good luck! This only worked under 5.3-1 (and the latest version of
Vax C...3.0? 3.1?), and isn't guaranteed in any way shape or form. If
you have stumbling blocks and think I may have come upon it during all
of this, feel free to mail me at kehoe@scotty.dccs.upenn.edu.
--
Brendan Kehoe | Soon: brendan@cs.widener.edu
For now: kehoe@scotty.dccs.upenn.edu | Or: bkehoe@widener.bitnet
Last resort: brendan.kehoe@cyber.widener.edu
Brendan Kehoe | Soon: brendan@cs.widener.edu
For now: kehoe@scotty.dccs.upenn.edu | Or: bkehoe@widener.bitnet
Last resort: brendan.kehoe@cyber.widener.edu
Our setup:
Sun 3/60 with cgfour
SunOS 4.0 (plus what Sun calls their "general hygiene" patch tape)
XV11R3 + MIT fixes 1 through 8 + "Purdue enhancements" + one local
"ANSIfication" fix (previously reported to MIT,
and attached below)
I installed gcc 1.34 (plus the expr.c fix) and also ran the "fixincludes"
script.
I built the X stuff with with the "CC" line in the "Sun.macros" file set to:
CC = gcc -fcombine-regs -fstrength-reduce -finline-functions -fpcc-struct-return -DPURDUE -Dinline=INLINE -DNOSTDHDRS
where -fcombine-regs, -fstrength-reduce, and -finline-functions
specify desired optimizations, -fpcc-struct-return makes things
compatible with the dbm library, -DPURDUE buys the Purdue speedups,
-Dinline=INLINE avoids a problem with a variable named "inline" in the
X file "fonts/bdftosnf/fontutil.c", and -DNOSTDHDRS avoids a problem
with multiple (and conflicting) typedef'ing of "size_t" in the
gcc-provided STDDEF_H and Sun's "sys/types.h".
Some clients may need -fwritable-strings. twm is said to need it.
The ANSIfication fix:
> From ado Mon Dec 26 10:55:28 1988
> To: xbugs@expo.lcs.mit.edu
> Subject: Xlibint and __STDC__ don't mix
>
>
> X Window System Bug Report
> xbugs@expo.lcs.mit.edu
>
>
>
>
> VERSION:
> R3
>
> CLIENT MACHINE and OPERATING SYSTEM:
> Sun 3/60 running SunOS 4.0
>
> DISPLAY:
> Sun CG4
>
> WINDOW MANAGER:
> uwm
>
> AREA:
> Xlib
>
> SYNOPSIS:
> Xlibint.h and __STDC__ don't mix
>
> DESCRIPTION:
> If __STDC__ is defined (and UNIXCPP is not defined),
> code that uses the GetReqExtra macro defined in Xlibint.h
> is uncompilable.
>
> REPEAT BY:
> Script started on Mon Dec 26 10:52:58 1988
> elsie$ cd lib/X
> elsie$ rm Xbackgnd.o
> rm: Xbackgnd.o: No such file or directory
> elsie$ rm XBackgnd.o
> elsie$ make XBackgnd.o CC=/usr/local/bin/gcc
> rm -f XBackgnd.o
> /usr/local/bin/gcc -c -O -I. -I../../. -I../.././X11 -DTCPCONN -DUNIXCONN XBackgnd.c
> XBackgnd.c: In function XSetWindowBackground:
> XBackgnd.c:16: undeclared variable `sz_' (first use here)
> *** Error code 1
> make: Fatal error: Command failed for target `XBackgnd.o'
> elsie$ exit
>
> script done on Mon Dec 26 10:53:51 1988
>
> SAMPLE FIX:
> *** 1.1/Xlibint.h Mon Dec 26 10:39:37 1988
> --- 1.2/Xlibint.h Mon Dec 26 10:39:37 1988
> ***************
> *** 122,133 ****
> #if defined(__STDC__) && !defined(UNIXCPP)
> #define GetReqExtra(name, n, req) \
> WORD64ALIGN\
> ! if ((dpy->bufptr + SIZEOF(*req) + n) > dpy->bufmax)\
> _XFlush(dpy);\
> req = (x##name##Req *)(dpy->last_req = dpy->bufptr);\
> req->reqType = X_##name;\
> ! req->length = (SIZEOF(*req) + n)>>2;\
> ! dpy->bufptr += SIZEOF(*req) + n;\
> dpy->request++
> #else
> #define GetReqExtra(name, n, req) \
> --- 122,133 ----
> #if defined(__STDC__) && !defined(UNIXCPP)
> #define GetReqExtra(name, n, req) \
> WORD64ALIGN\
> ! if ((dpy->bufptr + SIZEOF(x##name##Req) + n) > dpy->bufmax)\
> _XFlush(dpy);\
> req = (x##name##Req *)(dpy->last_req = dpy->bufptr);\
> req->reqType = X_##name;\
> ! req->length = (SIZEOF(x##name##Req) + n)>>2;\
> ! dpy->bufptr += SIZEOF(x##name##Req) + n;\
> dpy->request++
> #else
> #define GetReqExtra(name, n, req) \
> --
> Arthur David Olson ado@ncifcrf.gov ADO is a trademark of Ampex.
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.