hilfingr%tully.Berkeley.EDU@GINGER.BERKELEY.EDU (Paul Hilfinger) (09/23/88)
The following file causes gcc 1.28 on a Sun3 to bomb when compiled with or
without -g and -O. Using a typedef fixes the problem.
The error is a segmentation fault, which occurs in lookup_name_current_level.
P. Hilfinger
------ cut here -----------
void foo( enum { parAST, parNUM, parSTR, parID, parNONE } tag )
{
}gordon%stats.ucl.ac.uk@NSS.CS.UCL.AC.UK (Gordon Joly Statistics UCL) (03/09/89)
| ststic int iii(); | syntax error; | main() | { | printf ("hello\n"); | second syntax error | } | | The compiler just stops compiling and reporting error messages | after the ststic line, whenever I put it. | The output of the compiler under the -v option is: | (the -ansi flag does not matter.) | | gcc -ansi foo.c -v | gcc version 1.31 | /usr/local/lib/gcc-cpp -v -undef -D__GNU__ -D__GNUC__ -T -$ -D__STRICT_ANSI__ - | GNU CPP version 1.31 | /usr/local/lib/gcc-cc1 /tmp/cca00754.cpp -quiet -dumpbase foo.c -ansi -version | GNU C version 1.31 (68k, MIT syntax) compiled by GNU C version 1.31. | as -mc68020 /tmp/cca00754.s -o foo.o | ld /lib/crt0.o /lib/Mcrt1.o foo.o /usr/local/lib/gcc-gnulib -lc | Undefined: | _main | Due to an old version of bison? Note: also seen in G++. I echo the plea for BISON to have a version number. Gordon.
cruff@NIWOT.UCAR.EDU (03/29/89)
Version: 1.34
Input file: (t.c)
------------------
main() {
}
------------------
Command arguments:
gcc -a t.c
Machine files:
tm.h: tm-sun3-nfp.h
md: m68k.md
Machine:
Sun-3, SunOS 4.0.1
Description:
Produces incorrect assembler opcode for call to the function
block profiler '__bb_init_func' using the Sun assembler.
Opcode produced, 'call', should be 'jsr'.
Compiler output:
-----------------
#NO_APP
gcc_compiled.:
.text
.even
.globl _main
_main:
link a6,#0
tstl LPBX0
bne LPI0
pea LPBX0
call ___bb_init_func
addql #4,sp
LPI0:
L1:
unlk a6
rts
.data
.even
LPBX0:
.long 0
.long LPBX1
.long LPBX2
.long 0
.long 0
.long LPBX3
LPBX1:
.ascii "t.c\0"
LPBX2:
.skip 0
.text
LPBX3:
.long LPBX3
-----------------
Source fix context diff:
-----------------
*** tm-m68k.h Fri Mar 24 09:21:18 1989
--- tm-m68k.h.old Wed Mar 8 08:20:45 1989
***************
*** 632,638 ****
basic block profiling info, if that has not already been done. */
#define FUNCTION_BLOCK_PROFILER(FILE, LABELNO) \
! fprintf (FILE, "\ttstl LPBX0\n\tbne LPI%d\n\tpea LPBX0\n\tjsr ___bb_init_func\n\taddql #4,sp\nLPI%d:\n", \
LABELNO, LABELNO);
/* Output assembler code to FILE to increment the entry-count for
--- 632,638 ----
basic block profiling info, if that has not already been done. */
#define FUNCTION_BLOCK_PROFILER(FILE, LABELNO) \
! fprintf (FILE, "\ttstl LPBX0\n\tbne LPI%d\n\tpea LPBX0\n\tcall ___bb_init_func\n\taddql #4,sp\nLPI%d:\n", \
LABELNO, LABELNO);
/* Output assembler code to FILE to increment the entry-count for
-----------------wkd@CS.UTEXAS.EDU (Bill Duttweiler) (04/01/89)
gcc-1.34 on a SUN4/110 running 4.0.1.
tm.h -> tm-sparc.h
md -> sparc.md
The following snippet of C code results in incorrect assembly code
when compiled using:
gcc -traditional -O -S -meager gcc-bug.c
The -meager switch is clearly responsible. The .s file that comes out
matches the dissassembly using adb.
/*
** gcc-bug.c
**
** Demonstrates a bug in the SPARC processing of the -meager switch.
**
*/
#define SOME_CONSTANT (4)
int Foo(status)
{
int return_code;
return_code = (status >= SOME_CONSTANT);
exit(return_code);
}
main()
{
Foo(0);
}
Here is the s file:
gcc_compiled.:
.text
.align 4
.global _Foo
.proc 1
_Foo:
!#PROLOGUE# 0
save %sp,-112,%sp
!#PROLOGUE# 1
mov 0,%o0
cmp %i0,3
ble L2 ! eager
mov 1,%o0
L2:
call _exit,0
nop
ret
restore
.align 4
.global _main
.proc 1
_main:
!#PROLOGUE# 0
save %sp,-112,%sp
!#PROLOGUE# 1
call _Foo,0
mov 0,%o0
ret
restoreRIC@RML2.SRI.COM (Ric Steinberger) (05/20/89)
GCC (installed on a VAX 3600, running VMS 5.1) detects 3 errors when compiling compress.c (from compress.tar on prep.ai.mit.edu). The VAX C compiler has no problem with this. Any ideas. Is GNU C supposed to be completely compatible with other VAX languages? I have an example of a case where a c program, compiled by GNU, and called by a fortran program, dies with an access violation. The same c code, compiled by VAXC (version 3.0), linked with the fortran caller, runs fine. Do you want to see the source codes? -ric steinberger ric@rml2.sri.com -------
ney@PRINCETON.EDU (Neal Young) (05/30/89)
I think I've run across a gcc bug involving floating point constants.
Here is a .c file and a shell session demonstrating the bug.
(I'm running on a fairly large vax...)
tmp.c
-------------------------------------------------------------
main()
{
float i;
i = 1.0;
printf("%g is %s greater than zero\n", i, i > 0.0 ? "" : "not" );
}
-------------------------------------------------------------
Shell session:
-------------------------------------------------------------
notecnirp> gcc -v -o tmp tmp.c
gcc version 1.35
/usr/local/gnu/lib/gcc-cpp -v -undef -D__GNUC__ -Dvax -Dunix -D__vax__ -D__unix__ tmp.c /tmp/cc023377.cpp
GNU CPP version 1.35
/usr/local/gnu/lib/gcc-cc1 /tmp/cc023377.cpp -quiet -dumpbase tmp.c -version -o /tmp/cc023377.s
GNU C version 1.35 (vax) compiled by GNU C version 1.35.
tmp.c: In function main:
tmp.c:4: magnitude of constant too large for `float'
notecnirp>
----------------------------------------------------------------
I've also had problems with "gas" involving floating points. In
particular, the above program on one of our Suns compiles but the
assignment "i = 1.0" sets i to zero, so the program outputs "0 is not
greater than zero". I documented this form of the problem, which
seemed to be an assembler bug from examining the code produced etc.
and sent it to hack@gnu.ai.mit.edu.
Neal Young (ney@notecnirp.princeton.edu)balen%camscan.uucp@nsfnet-relay.ac.uk (henry Balen) (10/04/89)
There appears to be a bug in the gcc version 1.35 running on the Sun386i.
I compiled the source that is listed below with
gcc -o add add.c
And when I run add it causes a segmentation violation! As you can see the
program is fairly small.
/*
*
*/
main()
{
int *x,*b,*c;
register int i;
x = (int*)malloc(sizeof(int)*10);
b = (int*)malloc(sizeof(int)*10);
c = (int*)malloc(sizeof(int)*10);
for ( i = 0; i < 10; i++ )
x[i] = c[i] + b[i];
/* the following works instead!
* for (i = 0; i < 10; i++) {
* x[i] = c[i];
* x[i] += b[i];
* }
*/
free(x);
free(b);
free(c);
}wjj@SUN-VALLEY.STANFORD.EDU (Warren Jasper) (11/10/89)
Here is the source file
- -----------------------------------------------------------------------
extern float a,b,s,c;
__inline static const void sincos (float angle, float *sinval, float *cosval)
{
float s,c;
__asm ("fsincosx %2,%0:%1" : "=f" (s), "=f" (c) : "f" (angle));
*sinval = s;
*cosval = c;
}
void test(void)
{
sincos(a-b,&s,&c);
}
- ------------------------------------------------------------------------
Here is the command line used to compile it
- ------------------------------------------------------------------------
gcc -O -Wall -fstrength-reduce -fcombine-regs -fomit-frame-pointer -finline-fun
ctions -fforce-mem -fforce-addr -Dsun3 -m68020 -m68881 -D__HAVE_68881__ -S junk
.c
- ------------------------------------------------------------------------
and here is the result
- ------------------------------------------------------------------------
/local/lib/sun3/gcc: Program cc1 got fatal signal 11.
- ------------------------------------------------------------------------
-- Chrisrohit@MIPS.COM (Rohit Chandra) (01/18/90)
I am trying to compile g++ using gcc on a MIPS M-2000 running RISC/OS 4.0,
(with one change in va-mips.h)
when the compiler crashes with the message: Program cc1 got fatal signal 4,
while trying to compile the file expr.c
Details follow:
Version: gcc version 1.36
Input file: expr.c from gcc version 1.36.1- (based on GCC 1.36)
with the include files in that version of g++.
(with one change in va-mips.h, described below).
Options:
-c
-DGATHER_STATISTICS
-Wunused
-DUSE_COLLECT
-DEXTENDED_COFF
-DFASCIST_ASSEMBLER
-I.
-I./config
tm.h = tm-mips-bsd.h
md = mips.md
[I have made some changes in the machine description files.
I *believe* these should not affect the bug, and hope you can still
reproduce it.]
Machine = mips m2000-8, Running RISC/OS 4.0
Error: The compiler dies with the following message-
> gcc: Program cc1 got fatal signal 4.
> *** Error code 1
>
> Stop.
To Reproduce the bug:
---------------------
I am CHANGING the definitions in va-mips.h, included through
gvarargs.h in the input file expr.c.
Specifically, I am changing
(a) typedef struct
{ int pnt;
char *stack;
double *fpregs;
} va_list ;
to:
(b) typdef char *va_list;
Compilation goes through fine for definition (a) - the original one -
and the bug appears for definition (b) of va_list.
[I also make the corresponding changes in the related macros
va_alist, va_dcl, va_start, va_arg, va_end,
but they do not affect the bug since the bug remains even if I remove
all uses of these macros from the input file expr.c ]
Therefore, to reproduce the bug, all you should need to do is:
change the typedef of va_list in va-mips.h
to typedef char* va_list;
and perhaps comment out the *statements* (not the declarations) within
emit_library_call in expr.c since they use the macros va_start,
va_arg, va_end and therefore depend on the typedef of va_list.
Description of the bug:
-----------------------
The error occurs while parsing the declaration
CUMULATIVE_ARGS args_so_far;
in the function expand_call in the file expr.c.
CUMULATIVE_ARGS args_so_far is defined to be
#define CUMULATIVE_ARGS struct { \
enum arg_state arg_rec_state;\
int restype,arg_num;\
}
The stack at that point (while debugging cc1) is:
(dbx) run expr.cpp
init_comparisons init_expr enqueue_insn protect_from_queue queued_subexp_p
emit_queue init_queue convert_move convert_to_mode integer_mode_p
move_by_pieces move_by_pieces_ninsns move_by_pieces_1 emit_block_move
move_block_to_reg move_block_from_reg use_regs clear_storage
emit_move_insn push_block gen_push_operand emit_push_insn
emit_library_call expand_assignment store_expr store_constructor
store_field force_operand save_noncopied_parts init_noncopied_parts
validate_subtarget expand_expr
expr.c: In function expand_expr:
expr.c:3014: warning:assignment of pointer from integer lacks a cast
expr.c:3024: warning:assignment of pointer from integer lacks a cast
expand_builtin expand_increment preexpand_calls prepare_call_address
emit_call_1 init_pending_stack_adjust clear_pending_stack_adjust
do_pending_stack_adjust expand_cleanups_to expand_call
Illegal instruction [abort.abort:22 ,0x4ac920]
Source not available
(dbx) where
> 0 abort.abort(0x100243c8, 0x10024458, 0x7fff9c98, 0x7fff999c, 0x42e550) ["ab
ort.s":22, 0x4ac920]
1 .block44 ["expr.c":3122, 0x4308bc]
2 expand_expr(exp = 0x10024900, target = 0x10024ec8, tmode = VOIDmode, modif
ier = EXPAND_NORMAL) ["expr.c":3122, 0x4308bc]
3 store_expr(exp = 0x10024900, target = 0x10024ec8, suggest_reg = 0) ["expr.
c":1823, 0x42d07c]
4 .block26 ["expr.c":2268, 0x42e24c]
5 expand_expr(exp = 0x10024ea8, target = (nil), tmode = VOIDmode, modifier =
EXPAND_NORMAL) ["expr.c":2268, 0x42e24c]
6 variable_size(0x7fff9c9a, 0x0, 0x40b064, 0x1001e510, 0xffffff8c) ["stor-la
yout.c":161, 0x42031c]
7 layout_type(0x40bad4, 0x0, 0x10024ea8, 0x0, 0x74) ["stor-layout.c":929, 0x
4222bc]
8 finish_struct(0x10024d50, 0x10123a88, 0x10020828, 0x0, 0x0) ["c-decl.c":32
05, 0x40c17c]
9 yyparse(0x10008f74, 0x2000, 0xa, 0x0, 0x2) ["c-parse.tab.c":773, 0x401864]
10 compile_file(0x0, 0x0, 0x0, 0x0, 0x0) ["toplev.c":1113, 0x41708c]
11 main(0x7fff9f74, 0x7fff9f80, 0x0, 0x0, 0x0) ["toplev.c":1981, 0x418dcc]
(dbx)
It is somehow related to the declarations
register va_list p;
...
CUMULATIVE_ARGS args_so_far;
in the function emit_library_call, the only function to use varargs in
the entire file. (emit_library_call occurs before the function
expand_call in expr.c).
If I move the declaration of CUMULATIVE_ARGS within emit_library_call from:
register va_list p;
...
CUMULATIVE_ARGS args_so_far;
to:
CUMULATIVE_ARGS args_so_far;
register va_list p;
... (same declarations in the original order)
then the error goes away.
Although this message is long, I wonder if I have described the bug
well. I will be happy to answer any more questions that you have. You
can reach me at:
rohit@mips.com, or rohit@cs.stanford.edu
408-991-6545 (work)seeversb@MIST.CS.ORST.EDU (Bradley Seevers) (02/10/90)
While using gcc 1.35 on a Sequent Balance 2100 ,(ns32k machine), I uncovered
a bug with assigning constants to global varialbles of type float. At first
I thought that switching over to gcc 1.36 would solve my problems. I ftp'd
gcc 1.36 from prep.ai.mit.edu and rebuilt the compiler. To my suprise, the
bug was virtualy identical.
As an example, consider the following short program:
# include <stdio.h>
float a;
main()
{
float x;
a = 3.0;
x = 3.0;
printf("%f\n",a);
}
This program produced the following assembly output when compiled with the
-O -S flags and gcc v 1.35:
#NO_APP
gcc_compiled.:
.text
.align 0
LC0:
.ascii "%f %f\12\0"
.align 1
.globl _main
_main:
enter [],0
movd 416652,_a
movfl 0f3.00000000000000000000e+00,tos
movfl _a,tos
addr LC0,tos
bsr _printf
adjspb -20
exit []
ret 0
.comm _a,4
The line "movd 416652,_a" is incorrect. This is not the correct value for
a single precision 3.0. Note that is does ok for the local variable x.
Compiling the same program with gcc v 1.36 and flags -O -S produces this
output:
#NO_APP
gcc_compiled.:
.text
LC0:
.ascii "%f %f\12\0"
.align 1
.globl _main
_main:
enter [],0
movd 0,_a
movfl 0f3.00000000000000000000e+00,tos
movfl _a,tos
addr LC0,tos
bsr _printf
adjspb -20
exit []
ret 0
.comm _a,4
Agin, the line "movd 0,_a" is incorrect.
This bug only appears when optimization is enabled (-O).
So I set about to solve this problem, after all, I had the source.
The problem seems to be that all floating point constants are represented as
double precision numbers, and when they are assigned to a global varialble of
type float, they are not converted to single precision first. To fix this,
I modified the file 'ns32k.md', changeing lines 246 - to:
else if (GET_CODE (operands[1]) == CONST_DOUBLE)
{
union {int i[2]; float f; double d;} convrt;
convrt.i[0] = CONST_DOUBLE_LOW (operands[1]);
convrt.i[1] = CONST_DOUBLE_HIGH (operands[1]);
convrt.f = convrt.d;
/* Is there a better machine-independent way to to this? */
operands[1] = gen_rtx (CONST_INT, VOIDmode, convrt.i[0]);
return \"movd %1,%0\";
}
Now the example c program generates the code:
#NO_APP
gcc_compiled.:
.text
LC0:
.ascii "%f %f\12\0"
.align 1
.globl _main
_main:
enter [],0
movd 1077936128,_a
movfl 0f3.00000000000000000000e+00,tos
movfl _a,tos
addr LC0,tos
bsr _printf
adjspb -20
exit []
ret 0
.comm _a,4
This code produced the correct result.
-brad (seeversb@mist.cs.orst.edu)