Bugs in gcc (I'm trying to get g++ working):

Thread View: gnu.gcc.bug

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Wm Ehrich Tue, 27 Sep 1988 23:01

#1721

Author: Wm Ehrich
Date: Tue, 27 Sep 1988 23:01

55 lines
2394 bytes

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

Re: Bugs in gcc (I'm trying to get g++ working):

#1724

Author: Dean Long
Date: Thu, 29 Sep 1988 00:53

41 lines
1509 bytes

>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

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads