ehr%mouse@UMN-CS.CS.UMN.EDU (Wm Ehrich) (09/28/88)
tm-sparc.h has a pair of definitions which can't be compiled when TYPE == 0
because TREE_ADDRESSABLE makes a form like (0)->blah . Lisp would have
ignored this because the first part of the || clause was satisfied, but
the c compiler (Sun 4.0) stops on an error. I made a quick, dirty fix to get
it working by defining extra macros (.._t0) for the special case, but there
must be a more elegant fix.
#define FUNCTION_ARG(CUM, MODE, TYPE, NAMED) \
((CUM) < NPARM_REGS && ((TYPE)==0 || ! TREE_ADDRESSABLE (TYPE)) \
? gen_rtx (REG, (MODE), BASE_PASSING_ARG_REG (MODE) + (CUM)) : 0)
#define FUNCTION_ARG_t0(CUM, MODE, TYPE, NAMED) \
((CUM) < NPARM_REGS \
? gen_rtx (REG, (MODE), BASE_PASSING_ARG_REG (MODE) + (CUM)) : 0)
#define FUNCTION_ARG_PARTIAL_NREGS(CUM, MODE, TYPE, NAMED) \
(((CUM) < NPARM_REGS && ((TYPE)==0 || ! TREE_ADDRESSABLE (TYPE)) \
&& ((CUM) \
+ ((MODE) == BLKmode \
? (int_size_in_bytes (TYPE) + 3) / 4 \
: (GET_MODE_SIZE (MODE) + 3) / 4)) - NPARM_REGS > 0) \
? (NPARM_REGS - (CUM)) \
: 0)
#define FUNCTION_ARG_PARTIAL_NREGS_t0(CUM, MODE, TYPE, NAMED) \
(((CUM) < NPARM_REGS \
&& ((CUM) \
+ ((MODE) == BLKmode \
? (int_size_in_bytes (TYPE) + 3) / 4 \
: (GET_MODE_SIZE (MODE) + 3) / 4)) - NPARM_REGS > 0) \
? (NPARM_REGS - (CUM)) \
: 0)
The references must be changed in expr.c
Now I'm stuck on:
ehr: make CC=stage1/gcc CFLAGS="-g -O -Bstage1/"
stage1/gcc -g -O -Bstage1/ -DGCC_INCLUDE_DIR=\"/usr/local/lib/gcc-include\" \
-DGPLUSPLUS_INCLUDE_DIR=\"/usr/local/lib/g++-include\" -c cccp.c
stage1/gcc: Program cc1 got fatal signal 6.
*** Error code 1
make: Fatal error: Command failed for target `cccp.o'
The abort is from the default clause at the very end of final.c
any suggestions?
-- Bill Ehrich
ehrich@vx.acss.umn.edu
Control Data
(612) 853-6227
Box 1249 Minneapolis, Minnesota 55440
dlong@beowulf.ucsd.edu (Dean Long) (09/29/88)
In article <8809272301.AA01392@mouse.> ehr%mouse@UMN-CS.CS.UMN.EDU (Wm Ehrich) writes: >tm-sparc.h has a pair of definitions which can't be compiled when TYPE == 0 >because TREE_ADDRESSABLE makes a form like (0)->blah . Lisp would have Change the 0 to (tree)0 so that it is treated as a pointer, and can be dereferenced. >Now I'm stuck on: > >ehr: make CC=stage1/gcc CFLAGS="-g -O -Bstage1/" >stage1/gcc -g -O -Bstage1/ -DGCC_INCLUDE_DIR=\"/usr/local/lib/gcc-include\" \ > -DGPLUSPLUS_INCLUDE_DIR=\"/usr/local/lib/g++-include\" -c cccp.c >stage1/gcc: Program cc1 got fatal signal 6. >*** Error code 1 >make: Fatal error: Command failed for target `cccp.o' No fix, but the problem is returning a structure. This simple program won't work for me: #include <stdio.h> FILE foo() { FILE a; return a; } Dean Long dlong@beowulf
dlong@beowulf.ucsd.edu (Dean Long) (09/29/88)
>No fix, but the problem is returning a structure. This simple program >won't work for me: > >#include <stdio.h> > >FILE foo() >{ > FILE a; > > return a; >} > >Dean Long >dlong@beowulf Ok, I've found part (maybe all) of the problem. This is for Gcc 1.28 on Sun4 sparcs. The problem is with block moves of more than 16 bytes. In output_block_move(), xoperands[] should be initialized before comparing elements to 0. Since it is an automatic variable by default, strange things show up. -----BUG----FIX---CUT-------(CAREFULLY)-----HERE-------- *** output-sparc.c.orig Wed Sep 28 17:39:41 1988 --- output-sparc.c Wed Sep 28 17:40:57 1988 *************** *** 688,693 **** --- 688,694 ---- bzero (reg_conflicts, sizeof (reg_conflicts)); bzero (op_conflicts, sizeof (op_conflicts)); + bzero (xoperands, sizeof (xoperands)); /* Get past the MEMs. */ operands[0] = XEXP (operands[0], 0); Dean Long University of California, San Diego dlong@beowulf.ucsd.edu