dc@UUNET.UU.NET (Dave Cornelius) (10/11/89)
The enclosed program causes gcc-1.36 to die with a fatal signal (11: SIGSEGV)
when the '-traditional' command line argument is given. (Omitting
the '-traditional' allows the compilation to take place :-).
Environment:
- Sun 4/260(sunos4.0.3) or Sun 3/150(sunos3.5)
- 'cc' on that machine
- config.h -> config/xm-sparc.h (or config/xm-m68k.h for the sun3/150)
- aux-output.c -> config/out-m68k.c
- md -> config/m68k.md
- tm.h -> config/tm-sun3.h
Command line args: -traditional
Cursory analysis (and some guesswork):
Building the trees for the embedded structure declarations causes
build_int to be invoked for the integers which are the sizes of
each of the structs. build_int caches the constant trees built therein
via its static size_table.
At the end of the procedure block, something happens to these constant
blocks, such that the cached pointer is no longer valid. Subsequent
calls to build_int find a cached entry, which is no longer valid.
I turned off the caching in build_int, and the crash does not occur.
I have no idea how awful the performance implications of disabling
this cache are :-( ( It must have been thought to be important at some
point in time :-)!
Perhaps the trees need reference counts, and the destruction routines
can watch the ref count go to zero, and nuke the cache pointer if
the tree is really free?
I hope this helps isolate the problem and generate a fix; we'll
continue to operate with the cache turned off.
If there's any other info I can provide, do drop me a line!
We continue to be impressed with the quality of the gnu compiler!
Yours,
-----------
Dave Cornelius Network Computing Devices
350 North Bernardo Ave
{uunet,ardent,mips}!lupine!dc Mountain View, CA, 94043
OR: dc@ncd.com 415-694-0675
================================
dbx session output:
dc@sheridan 189> dbx /u4/gnu/gcc-1.36/sun4/sun3/cc1
Reading symbolic information...
Read 49226 symbols
(dbx) run t.c -traditional
Running: /u4/gnu/gcc-1.36/sun4/sun3/cc1 t.c -traditional
p1 p2 p3signal SEGV (segmentation violation) in expand_expr at line 2161 in file "gnu/gcc-1.36/expr.c"
2161 register enum machine_mode mode = TYPE_MODE (type);
(dbx) where
expand_expr(exp = 0x103400, target = (nil), tmode = VOIDmode, \
modifier = EXPAND_NORMAL), line 2161 in "gnu/gcc-1.36/expr.c"
variable_size(size = 0x103400), line 161 in "gnu/gcc-1.36/stor-layout.c"
layout_type(type = 0x103380), line 929 in "gnu/gcc-1.36/stor-layout.c"
finish_struct(t = 0x103380, fieldlist = 0x10ccb8), \
line 3205 in "gnu/gcc-1.36/c-decl.c"
yyparse(), line 768 in "/gp/rms/cc/c-parse.y"
compile_file(name = 0xf7fff9eb "t.c"), line 1118 in "gnu/gcc-1.36/toplev.c"
main(argc = 3, argv = 0xf7fff96c, envp = 0xf7fff97c), \
line 1991 in "gnu/gcc-1.36/toplev.c"
(dbx)
============= t.c ============
int foo;
p1()
{
struct overlay1 {
int i;
char *p;
unsigned count;
} *ovp = (struct overlay1 *)foo;
}
p2()
{
struct overlay2 {
} *ovp = (struct overlay2 *)foo;
}
p3()
{
struct overlay3 {
char *p;
int i;
unsigned count;
} *ovp = (struct overlay3 *)foo;
}james@raid.dell.com (James Van Artsdalen) (02/07/90)
In <1965@osc.COM>, rp@osc.COM (Rich Patterson) wrote: > Here is a bug that I've found in gcc. > Synopsis: GCC's (1.36 386 System V) builtin alloca function does not align > the stack. > Description: When compiling GDB 3.4 with GCC 1.36 the program will > core dump when starting up in tgetent. Yes, this is a bug and not a performance issue. This is also the cause of a bug I have been trying to figure out in emacs for quite some time. The 386 (and presumably the 486) can misbehave when the stack is not aligned. I saw this last year in some ROM based code, but did not get a chance to prove it with a logic analyzer. Aligning the stack has appeared to fix several mysterious problems. -- James R. Van Artsdalen james@raid.dell.com "Live Free or Die" Dell Computer Corporation 9505 Arboretum Blvd Austin TX 78759 512-338-8789
rfg@paris.ics.uci.edu (Ronald Guilmette) (02/26/90)
/* gcc 1.36 (and 1.36.93) bug 900226_01
gcc issues an error message for the first member of the following pair
of declarations. I believe that this is legal ANSI C code. The intent
here is to "forward declare" a static array.
At least one C "expert" has advised me that this should be legal.
*/
static int array[]; /* gets bogus error */
static int array[] = { 1,2,3 };
/*
The error message says:
storage size of `array' isn't known
*/