Article View: gnu.gcc.bug
Article #1197gcc V 2.2.2
From: Brian Somers
Date: Wed, 14 Oct 1992 13:43
Date: Wed, 14 Oct 1992 13:43
182 lines
5602 bytes
5602 bytes
From: Brian Somers <brian@utell.uucp>
Date: October 14, 1992
To: bug-gcc@prep.ai.mid.edu
RE: Gcc V 2.2.2
I've encountered the following problems with gcc V 2.2.2 and V 2.1, on SCO
and SEQUENT PTX ( only slightly different from SCO ).
Bug (1) occurs in the following piece of c++ code:
extern "C" int puts(char *);
int *fn(){
puts("hello");
return new int;
}
main(){ delete fn(); return 0; }
The program output is:
hello
hello
The bug is fixed (I think) in my alteration to cp-init.c below.
Bug (2) occurs in the following piece of c++ code:
struct X { X(char *); };
struct Y { void fn(X &x = (X)""); };
struct Z {
Y y;
void fn(X &x = (X)""){ return y.fn(x); }
};
It dumps core processing the inline function. The bug is fixed by my
alteration to tree.c below.
Bug (3) occurs in the following piece of c++ code:
struct X {
int x;
};
class A {
X *x;
public:
void *operator[](int x){ return &this->x[x]; }
A(){ x = new X[10]; }
~A(){ delete x; }
};
main(){
A x;
int y = 1, z = 0;
((X *)x[1])->x = y ? y : z;
}
cc1plus dumps core processing line 3 in main. In
'rtx expand_assignment(tree,tree,int,int)'
the call to
'tree get_inner_reference(tree,int*,int*,tree*,enum machine_mode*,int*,int*)'
sets offset (tree*) to 0x127 (looks suspicious), and the call to
'rtx expand_expr(tree,rtx,enum machine_mode,enum expand_modifier)'
core dumps. If I set poffset (the tree*) to zero before leaving
'tree get_inner_reference(tree,int*,int*,tree*,enum machine_mode*,int*,int*)'
I end up calling
'rtx emit_move_insn(rtx,rtx)'
instead of
'void emit_block_move(rtx,rtx,rtx,align)'
and making cc1plus abort in
'rtx emit_move_insn(rtx,rtx)'
because GET_MODE() returns BLKmode. I can't come up with any one-line fixes.
The following are my changes to the distributed source:
configure: 267: Add:
i386-*-ptx*) # 80386 running PTX system
xm_file=xm-i386ptx.h
tm_file=i386ptx.h
xmake_file=x-i386ptx
tmake_file=t-i386ptx
;;
config.sub: 112: Add:
i386-ptx* | i386ptx | ptx)
basic_machine=i386-unknown
os=-ptx3.2v2
;;
: 463: Add:
| -ptx*
gcc.c: 471: Add:
{".cpp", "@c++"}, /* Support .cpp file extensions - why not */
crtstuff.c: End: Add:
#ifdef CRT_BEGIN
_ppinit(){
__do_global_ctors_aux ();
}
#endif
/* On a sequent running PTX, _ppinit is called by crt0.o before main,
and is resolved in libc.a ( and does nothing ). I've used this to
construct globals as the COFF loader doesn't seem to be interested
in executing .init section code. */
cp-init.c: 3492 (maybe_adjust_addr_for_delete()): Add
if(TREE_CODE(addr) == 50 && !TYPE_DOMAIN(addr)) return addr;
/* This fixes bug (1) mentioned above for SCO and PTX */
tree.c: 2568 (simple_cst_equal()) (This is wrong - I think, it should be):
return simple_cst_equal (TREE_OPERAND(t1,0), TREE_OPERAND(t2,0));
/* return -1; */
config/i386ptx.h
#include "i386v.h"
#undef STARTFILE_SPEC
#define STARTFILE_SPEC \
"%{pg:gcrt0.o%s}%{!pg:%{p:mcrt0.o%s}%{!p:crt0.o%s}} crtbegin.o%s"
#define ENDFILE_SPEC "crtend.o%s -lseq"
#undef LIB_SPEC
#define LIB_SPEC \
"%{p:-L/usr/lib/libp}%{pg:-L/usr/lib/libp} %{scointl:libintl.a%s} -lc"
#undef CPP_PREDEFINES
#define CPP_PREDEFINES \
"-D_SEQUENT_ -DSEQUENTPTX -Dunix -Di386 -DM_UNIX -DM_I386 -DM_COFF -DM_WORDSWAP"
#undef HAVE_ATEXIT
#define SIZE_TYPE "unsigned int"
#undef RETURN_POPS_ARGS
#define RETURN_POPS_ARGS(FUNTYPE,SIZE) \
(TREE_CODE (FUNTYPE) == IDENTIFIER_NODE ? 0 \
: (TARGET_RTD \
&& (TYPE_ARG_TYPES (FUNTYPE) == 0 \
|| (TREE_VALUE (tree_last (TYPE_ARG_TYPES (FUNTYPE))) \
== void_type_node))) ? (SIZE) \
: 0)
#undef DO_GLOBAL_CTORS_BODY
#define DO_GLOBAL_CTORS_BODY \
do{ \
func_ptr *p, *beg = __CTOR_LIST__ + 1; \
for(p = beg; *p; p++); \
while(p != beg) (*--p)(); \
}while(0)
#define DO_GLOBAL_DTORS_BODY \
do{ \
func_ptr *p, *beg = __DTOR_LIST__ + 1; \
for(p = beg; *p; p++); \
while(p != beg) (*--p)(); \
}while(0)
config/t-i386ptx
LIMITS_H =
EXTRA_PARTS=crtbegin.o crtend.o
config/x-i386ptx
INSTALL=cp
RANLIB = :
RANLIB_TEST = false
CC = /public/bin/gcc
OLDCC = cc
CCLIBFLAGS = -O
RCCFLAGS = -Dunix -Di386 -DM_UNIX -DM_I386
XCFLAGS =
CLIB = -lPW -lseq
CFLAGS = -O
prefix = /public
exec_prefix = $(prefix)
bindir = $(exec_prefix)/bin
libdir = $(exec_prefix)/lib
libsubdir = $(libdir)/gcc-lib/$(target)/$(version)
manext = .1
mandir = $(prefix)/man/man1
tooldir = $(prefix)/$(target)
config/xm-i386ptx.h
#include "xm-i386v.h"
#define BROKEN_LDEXP
#define IO_BUFFER_SIZE (0x8000 - 1024)
Also, I've seen Makefiles for DOS. Are you supporting DOS ?, and if so, do you
need a version of gcc.exe to compile gcc ? Any answers would be appreciated.
Replys to brian@utell.uucp would be much appreciated.
Technical Details
Message-ID:
<4767.9210141143@utell.UUCP>Path:
arc1-ca.pugleaf.net!sparky!uunet!convex!linac!pacific.mps.ohio-state.edu!cis.ohio-state.edu!utell.UUCP!brianShow Full Headers
Complete Article Headers
Newsgroups: gnu.gcc.bug Path: arc1-ca.pugleaf.net!sparky!uunet!convex!linac!pacific.mps.ohio-state.edu!cis.ohio-state.edu!utell.UUCP!brian From: brian@utell.UUCP (Brian Somers) Subject: gcc V 2.2.2 Message-ID: <4767.9210141143@utell.UUCP> Sender: gnulists@ai.mit.edu Organization: GNUs Not Usenet Distribution: gnu Date: Wed, 14 Oct 1992 13:43:34 GMT Approved: bug-gcc@prep.ai.mit.edu Lines: 184