HDTenEightyP/NetNews huggingface dataset:
From: brown@quorum.COM (Robert E. Brown)
Subject: optimization question
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 24 Jul 1992 19:50:51 GMT

While not exactly a bug report, perhaps the lack of consistency in GCC's
output will count as a bug ...


I am machine generating a lot of C code that contains redundant stores to
global variables and GCC (versions 2.2 and 2.2.2) is not optimizing away
some of the stores that I expect it to delete.  It's likely, however, that
I don't fully understand when it's possible to remove stores to global
variables that are not declared as "volatile".  For instance, is it legal to
optimize the following code:

	long R, A, B, C, D;

	void
	foo()
	{
	R = 0;
		A = (R < 0);
		B = (R == 0);
		C = 0;
		D = 0;

	R = 1;
		A = (R < 0);
		B = (R == 0);
		C = 0;
		D = 0;
	}


into assembly code that implements just

	{
	R = 1;
		A = 0;
		B = 0;
		C = 0;
		D = 0;
	}

or does ANSI say that the compiler has to be smart about making things look
right to a signal handler that may get invoked while foo() is running?
Here's what "gcc -O -S foo.c" (gcc version 2.2.2) produces when configured for
"next" -- a 68K-based computer.  This output seems to be consistent with the
desire to make the global variables consistent with respect to a signal
handler.  Signals can be delivered between each pair of sequential
instructions, and the handler would not see a variable state that's
inconsistent with naive code for foo().  The compiler has deleted some stores,
however.

	#NO_APP
	.text
		.align 1
	.globl _foo
	_foo:
		link a6,#0
		clrl _R
		clrl _A
		moveq #1,d0
		movel d0,_B
		clrl _C
		clrl _D
		movel d0,_R
		clrl _B
		unlk a6
		rts
	.comm _R,4
	.comm _A,4
	.comm _B,4
	.comm _C,4
	.comm _D,4


On the SPARC, "gcc -O -S foo.c" (GCC version 2.2, configured for "sparc")
produces the following code, which retains all the stores to the global
variables.  Even C and D are written more than once -- and their values
definitely don't after the first store!  What is the best code that GCC could
produce?  Must it look like the 68K code, or can it be optimized to the
assembly code equivalent to {R=1;A=B=C=D=0}?

	gcc2_compiled.:
	.text
		.align 4
		.global _foo
		.proc	020
	_foo:
		!#PROLOGUE# 0
		save %sp,-112,%sp
		!#PROLOGUE# 1
		sethi %hi(_R),%i3
		st %g0,[%i3+%lo(_R)]
		sethi %hi(_A),%i2
		st %g0,[%i2+%lo(_A)]
		sethi %hi(_B),%i1
		mov 1,%g2
		st %g2,[%i1+%lo(_B)]
		sethi %hi(_C),%i0
		st %g0,[%i0+%lo(_C)]
		sethi %hi(_D),%g3
		st %g0,[%g3+%lo(_D)]
		st %g2,[%i3+%lo(_R)]
		st %g0,[%i2+%lo(_A)]
		st %g0,[%i1+%lo(_B)]
		st %g0,[%i0+%lo(_C)]
		st %g0,[%g3+%lo(_D)]
		ret
		restore
		.global _R
		.common _R,8,"bss"
		.global _A
		.common _A,8,"bss"
		.global _B
		.common _B,8,"bss"
		.global _C
		.common _C,8,"bss"
		.global _D
		.common _D,8,"bss"

Newsgroups: gnu.gcc.bug
From: susan@eagle.safb.af.mil
Subject: installing gcc-1.40
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 28 Jul 1992 19:40:45 GMT

I have progressed, I think.  _JBLEN was not being defined in
/usr/include/setjmp.h.  I don't know why, so I edited the file to
unconditionally set it to 6 since that looked like what it should be
set to based on all the ifdefs associated with that parameter.  I
don't know if this hurts me in some way but I am getting to a further
point.

When the make executes ./genflags md > tmp-flags.h, the following
occurs:


	./genflags md > tmp-flags.h
Expected character (.  Found character ^M.  At file position: -5
Following characters are:
	sh: 2939 Bus error - core dumped
*** Error code -118

Stop.

I've been experimenting and the read_skip_spaces in rtl.c doesn't seem
to be working properly.  I can't get genflags to do anything even with
the most trivial input.

Is this related to my hard coding _JBLEN equal to 6?  Is it a known
problem with SCO Unix Sys V R3.2.2?  To refresh, I use the rcc
compiler rather than the SCO cc compiler.

Newsgroups: gnu.gcc.bug
From: bnell@cadillac.siemens.com (Bill Nell)
Subject: ignore my bug report
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 22 Jul 1992 19:19:52 GMT

Please ignore my bug report, I just found someone with a C++ manual and found
out what the problem was. Sorry.. Bill

Newsgroups: gnu.gcc.bug
From: rwr@concept.UUCP (Roland Weber)
Subject: multible inheritance and virtual functions
Organization: concept engineering GmbH, D-7800 Freiburg, Germany
Distribution: gnu
Date: Mon, 20 Jul 1992 19:06:20 GMT

We have newly installed gcc-2.2.2 on a SPARCstation using SUNOS 4.1.
It seems to me, that a "hard bug" still remains.

Look at the following example. I expect an output of
    isA: 3 3 3 3
but get:
    isA: 3 3 3 2

Could you pleace respond, if it is a known bug and if you will fix it.
Thank you,

Roland.

================================================================================
Roland Weber                           |  Tel.:  ..49-761-473099
concept engineering GmbH               |  Fax.:  ..49-761-441063
Burkheimer Str. 10                     |  
D-7800 Freiburg (Germany West)         |  
--------------------------------------------------------------------------------
Email:                       rwr@concept.de
   or: (uucp domain)         rwr@concept.uucp
   or: (uucp notation)       ...!unido!concept!rwr
================================================================================


----------- example c++ -----------------
/* %Z%%M% %I% %E%
	g++ bug:
		multible inheritance of virtual functions...
*/

class A1 {
public:
			A1() {};
	virtual		~A1() {};
	virtual int	isA() {return 0;}
};

class A2 {
public:
			A2() {};
	virtual		~A2() {};
	virtual int	isA() {return 1;}
};

// =============================================================================

class B : public A1, public A2 {
public:
			B() {};
	virtual		~B() {};
	virtual int	isA() {return 2;}
};

// =============================================================================

class C : public B {
public:
			C() {};
	virtual		~C() {};
	virtual int	isA() {return 3;}
};

// =============================================================================

#include <stdio.h>

main()
{
	C*	c = new C;

	A1*	a1 = c;
	A2*	a2 = c;
	B*	b =  c;
	
	printf("isA: %d %d %d %d\n", c->isA(), b->isA(), a1->isA(), a2->isA());
}

Newsgroups: gnu.gcc.bug
From: merlin@neuro.usc.edu (merlin)
Subject: libm.a - source for fast gcc floating point library on i386/387/486 ?
Organization: University of Southern California, Los Angeles, CA
Distribution: gnu
Date: Tue, 28 Jul 1992 21:30:18 GMT

The new 4.3BSD-NET2 based 386BSD-0.1 operating system uses gcc as the
default compiler.  The version installed on 386BSD-0.1 is 1.4x (where
x is something recent like 1.43).  Benchmarks show the simple floating
operations (+, -, *, /) all use the '387 coprocessor when available.

However, it seems as though the default 4.3BSD-NET2 libraries were 
used to construct the 386BSD-0.1 libm.a -- as a consequence higher
floating point operations (atan, tan, acos, cos, sqrt) are emulated
very very slowly.  Does anyone have sources for a library which may
be compiled/assembled and dropped in to replace the default libm.a.

This would likely markedly increase performance of 386BSD-0.1 when
used for 3D geometric modeling / ray tracing / image processing or
any other compute intensive scientific computing.

Thanks, AJ

------------------------------------------------------------------------------
Alexander-James Annala
Principal Investigator
Neuroscience Image Analysis Network
HEDCO Neuroscience Building, Fifth Floor
University of Southern California
University Park
Los Angeles, CA 90089-2520
------------------------------------------------------------------------------


Newsgroups: gnu.gcc.bug
From: paisley@bass.ai.mit.EDU (Beau Paisley)
Subject: bug in gcc2.2.2, please acknowledge.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 25 Jul 1992 00:16:09 GMT

We have sent this bug message 3 times.  Please
acknowledge, and suggest a work-around.

/* When you execute this program it generates an illegal instruction message */
/* No syntax error is given for the illegal allocation syntax */

extern "C" void exit( int );

int test(int j)
{
	return( 0 );
}

main( )
{
	int n=4;
	double x[n];	/* This seems to be the statement that gcc goofs up */
			/* The c++ version of gcc messes it up also */
	int i;
	i= test(0);

	exit(0);
}

Beau Paisley
apl/uw
206-367-0599


Newsgroups: gnu.gcc.bug
From: ross@cs.wisc.edu (Ross Johnson)
Subject: *.o bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 11:40:39 GMT

When compiling with gcc version 2.2.2 and NOT using the -c flag,
gcc tells the assembler to use filename.o where filename.c was the
source file.  My understanding is that all temporary files that are
used by gcc are suppose to be unique.  However, sometimes I get a
conflict on filename.o when I simultaneously compile two versions
of the same source file with different output files (using the -o flag).
I think a more "unique" name should be chosen to replace filename.o.

Ross Johnson

Newsgroups: gnu.gcc.bug
From: tanida@forseti.css.gov (Tom Tanida)
Subject: Suggestion for a Warning for g++
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 27 Jul 1992 21:32:10 GMT

I'm using g++ 2.2.2, and am compiling the following:

class A {
public:
  virtual void f() const;
};

class B: public A {
public:
  virtual void f();
};

main()
{
}

This compiles cleanly, with no warnings (even with the switches
-Wall and -Woverloaded-virtual).  Under Borland C++ 3.1 I get:

Warning: B::f() hides virtual function A::f()

This warning is a reasonable one.  I got the idea to try this
from the "Effective C++" book by Scott Meyers (Addison-Wesley); it's
Tip #48 or so- there's a reference to the ARM as to why this 
warning might be a good one to have.

-Tom
tanida@esosun.css.gov

P.S. You've probably already heard this complaint, but I just thought I'd
send it just in case. :-)

Newsgroups: gnu.gcc.bug
From: andy@wegy.UUCP
Subject: GCC on a MIPS Magnum with RISCos 5.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 25 Jul 1992 22:46:11 GMT

Hello there !

I am trying to get the GCC 1.40 (as distributed by MIPS
on a PD-Tape) running on my Magnum 3000/33 with RiscOs 5.0.
My final intention is to use the GCC as a mc68k-crosscompiler,
but to check if I am able to compile and run GCC at all,
I decided to first compile it as it should be.

I invoked config.gcc with the `mips-sysv' option.
For error-free compiling I had to add the -systype svr3
(mips-)compiler-flag, #include <unistd.h> instead of
<sys/file.h> and finally add `-lc and -lbsd' to the
CLIB-variable.
Compilation in a separate directory was not possible
because the Mips-compiler could not find some files.
(Sorry, I don't remember which ones).

But that's not my real problem.

After some `trial and error' I was able to compile it,
and GCC seems to work. I am now able to generate .s and
.o files, but the Mips-linker says:

ABI incompatible stack frame instruction sequence in object hello.o,
instruction 0x27bdfff0

The mentioned instruction is:
	subu	$sp,$sp,16

I found out, that the Mips-cc allocates a stack frame of 32 bytes,
in contrast to the gcc, which allocates only 16 bytes. I assume
that this is the problem (hopefully the only one).

I include the .s files at the end of my mail,
first the mips-cc output, then the gcc-output.

Now my questions:

1. Are there any fixes to solve this problem ?
2. If not, what must I change ?
3. Is there a GNU-linker available ?
4. Do you have experience with using GCC as
   a crosscompiler ? Are there any `specials'
   to take care about ?

I hope you can help me !
Thank you very much,
Yours,

Andreas Busse
andy@wegy.uucp

P.S.: Sorry for my rather bad English !

-----------------------------------------------------------

OUTPUT OF THE MIPS-COMPILER

	.verstamp	3 0
	.data	
	.align	2
	.align	0
$$5:
	.ascii	"hello world!\X0A\X00"
	.text	
	.align	2
	.file	2 "hello.c"
	.globl	main
	.loc	2 3
 #   1	
 #   2	int main()
 #   3	{
	.ent	main 2
main:
	.option	O1
	subu	$sp, 32
	sw	$31, 28($sp)
	.mask	0x80000000, -4
	.frame	$sp, 32, $31
	.loc	2 3
	.loc	2 4
 #   4	  printf("hello world!\n");
	la	$4, $$5
	.livereg	0x0800000E,0x00000000
	jal	printf
	.loc	2 5
 #   5	}
	move	$2, $0
	.livereg	0x2000FF0E,0x00000FFF
	lw	$31, 28($sp)
	addu	$sp, 32
	j	$31
	.end	main

-------------------------------------------------------------

OUTPUT OF GCC 1.40

	.file	1 "hello.c"
	.data
gcc_compiled.:
	.rdata
$LC0:
	.ascii	"hello world!\n\000"
	.text
	.align	2
	.globl	main
	.ent	main
main:
 #PROLOGUE
	subu	$sp,$sp,16	# temp= 0, regs= 8, args= 0, sfo= -8
	.frame	$fp,0,$31
	sw	$fp,0($sp)
	sw	$31,4($sp)
	.mask	0xc0000000,-12
	.fmask	0x00000000,-12
	addu	$fp,$sp,16	# set up frame pointer
 #END PROLOGUE
	subu	$sp,$sp,16
	la	$4,$LC0
	jal	printf
$L1:
 #EPILOGUE
	subu	$sp,$fp,16	# sp not trusted  here
	lw	$fp,0($sp)
	lw	$31,4($sp)
	addu	$sp,$sp,16
	j	$31
 #END EPILOGUE
	.end	main


Newsgroups: gnu.gcc.bug
From: tzhou@math.purdue.edu (Tonghang Zhou)
Newsgroups: gnu.gcc.bug
Subject: g++ dumps 'core'
Date: 29 Jul 92 07:48:51 GMT
Distribution: gnu
Organization: GNUs Not Usenet

The g++ we have was installed from gcc-2.2.2 and should be the latest
issue and has been working fine. Today however when I run
	g++ -Wall MyProg.c	# -Wall to catch all possible complaints
I receive precisely the following output
	cp-class.c:2380: failed assertion `t == d'
	/usr/local/bin/gcc: Internal compiler error: program cc1plus got fatal signal 6

And I got a big core dumped by g++ in my directory.
Would you know what kind of problem this is? 'MyProg.c' is about 250 lines
and contains a lot of templates stuff.

Thanks,
T Zhou
Newsgroups: gnu.gcc.bug
From: root@grok19.columbiasc.ncr.COM
Subject: Makefile bug report for GCC 2.2
Organization: Gnus Not Usenet
Distribution: gnu
Date: Mon, 27 Jul 1992 16:53:23 GMT

I found the following in the standard makefile generated when I 
configured for the NCR system 3000 compiler:

> # NCR3000 ships with a MetaWare compiler installed as CC, which chokes and
> # dies all over the place on GCC source.  However, the AT&T compiler,
> # crusty as it is, can be used to bootstrap GCC.  It can be found in
> # /usr/ccs/ATT/cc.  It is also used to compile the things that should
> # not be compiled with GCC.
> 
> CC = /usr/ccs/ATT/cc
> OLDCC = /usr/ccs/ATT/cc

This is dead wrong. Not only is the AT&T C Issue 5.0 compiler that
is used unsupported, the directory '/usr/ccs/ATT' is deleted in the
next release (release 2.00) of the system. 

I tried the MetaWare High C compiler (the default) to make the GCC 
2.2 release and had no problems. Release 2.00.02 of the SCDE did as
well.

I would like to request that this comment be struck from the makefile
and that the base compiler be used as the make compiler in the future.
Any problems that occur in making GCC can be reported to me at email
'dave.howell@ColumbiaSC.NCR.COM' or Bob Williamson at the same path 
with name 'bob.williamson'. We will get it fixed ASAP from this point.
There should be no need to use another compiler other than the base 
on any NCR System 3000.

Please let me know if you have any problem with making this change.

							Dave Howell
-- 
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Dave Howell                                  (803) 791-6818
Compiler Technologies Group                   dave.howell@ColumbiaSC.NCR.COM
NCR Corporation
E&M - Columbia
3325 Platt Springs Rd
West Columbia, SC  29169


Newsgroups: gnu.gcc.bug
From: grosjean@masi.ibp.fr (Christophe GROSJEAN)
Subject: static member bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 30 Jul 1992 12:44:48 GMT

Hello Everyone, 

I think i have found a bug with g++.
Static data members compile well but don't link.
It seems the job is done, except that compiler wont allocate space for that kind of data
This problem appears with g++ 2.2.2 and 2.1. on SparcStation under SunOs 4.1.1.


Below is a small sample program showing off the problem :

---------------------------------------------
#include <stdio.h>

class Bug 
{
	public:
	static int i = 0;
	Bug() {	printf("%d ",i++); }
};


main()
{
	Bug b;
	Bug c;
	Bug d;
}
-----------------------------------------

(yes, I know i should use streams for I/O, but that's not the point...)

When I compile this code (it provide a class that counts it's instances)

I get the message :

ld: Undefined symbol
	__3Bug$i

I think it's a major problem, 'cause static members are the only clean way
to implement shared data between every members of a class.

Still, i've found a way (a very very dirty way...) to patch the problem
so i can go with it.
However, you'll understand that i'm not quite satifsfied...

The following code will compile, link and work perfectly...

----------------------------------------------------
#include <stdio.h>

static int _3Bug$i = 0;

class Bug 
{
	public:
	static int i = 0;
	Bug() {	printf("%d ",i++); }
};


main()
{
	Bug b;
	Bug c;
	Bug d;
}

----------------------------------------------------

	Thanks for fixing problem...






-- 
    
                     _-----_ 
                    /   )   \
                   (    )    )
                    \/ \ / \/
       +---+         \  |  /       Christophe GROSJEAN
      / \ / \         \/|\/
     /   /   \         \O/             Equipe CAO&VLSI
    +---+ \   \        /H\            Laboratoire MASI
     \   \ +---+       / \      Institut Blaise Pascal
      \   /   /
       \ / \ /   Couloir 55-65, 2eme etage, Bureau 201
        +---+    Universite Pierre et Marie Curie (P6)
                 4 place Jussieu, 75252 Paris Cedex 05

   Tel: 44.27.30.43,         Fax: 44.27.62.86
   Telex: UPMCSIX200145F, e-mail: kriss@masi.ibp.fr
. 


Newsgroups: gnu.gcc.bug
From: oueichek@ngulu.imag.fr (Ibaa Oueichek)
Subject: Questions about Bugs
Followup-To: gnu.gcc.help
Organization: IMAG, University of Grenoble, France
Distribution: gnu
Date: Fri, 24 Jul 1992 18:31:50 GMT

  I'm trying to compile gcc, gdb, gas and other gnu tools to provide an
unified developpement environnement for a projet which'll be developped
on 3 different machines in the same time :
  DECstation, Hp7000, and a microvax.
  The problem is that my boss doesn't like the idea because gcc2.2.1 contains
bug which are not fixed yet. So i need an answer to the following questions :
A- Is there a stable version of gcc ? which one ? and where can i get it ?.
B- I'll keep using the actual one if bugs reported for the machine we are
using are not that important. So i need the list of bugs reported if it exists.

   Thanks for any help.




--
Sham(u) ya tha (s)seif(u) lam yaghib(i) | Ibaa Oueichek. ouicheck@imag.imag.fr
    Ya jamal(al) majd(i) fi(l) kutub(i) | LABORATOIRE 	BULL-IMAG
Kablak(i) (t)tareekh(u) fi thulmaten    | Grenoble. 
    Baadak(i) staula ala (sh)shuhub(i)  |
					


Newsgroups: gnu.gcc.bug
From: cool@anne.wifo.uni-mannheim.de (Stefan Kuhlins)
Subject: a little bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 24 Jul 1992 12:34:20 GMT

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Content-Lines: 1


----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: inc.C
X-Sun-Content-Lines: 16

#include <iostream.h>
#include <string.h>

int main()
{
  int i = 3;
  cin >> i;
  char name[ (i ? 6 : 0) ];     // this can't work !!
  cout << sizeof(name) << endl;
  strcpy (name, "hallo");
  cout << name << endl;
  return 0;
}




Newsgroups: gnu.gcc.bug
From: daveg@thymus.synaptics.COM (Dave Gillespie)
Subject: Re: gcc-Optimize
Reply-To: daveg@synaptics.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 26 Jul 1992 10:37:52 GMT

> i discovered an bug, when gcc -g -O removed (optimized) a statement. It
> removes count-- from the example.

ANSI C does not require setjmp() to preserve local variables unless
they are "volatile".

>From the bottom of page 254 of K&R 2:

> Accessible objects have the values they had when "longjmp" was
> called, except that non-"volatile" automatic variables in the
> function calling "setjmp" become undefined if they were changed
> after the "setjmp" call.

Since your change to "count" occurs after the "setjmp" call, the
variable is undefined and so "count--" can just as well be removed.

Michael Salmon pointed out:
> While this is undoubtably frustrating I don't see how gcc can be
> expected to understand your function without including setjmp as an
> element of the language.

I believe the standard allows this precisely so that the compiler
doesn't have to know about the special properties of "setjmp", but
I wouldn't be surprised if some machines' libraries take advantage
of this fact and save some time by not restoring variables that
appear in registers.  Even if GCC did know about setjmp, it wouldn't
be able to assume the variable had a reliable value here, so again,
it might as well remove the statement.

To fix your problem, change the declaration "count" to:

> volatile int  count;

"Volatile" means, more or less, "something funny is happening here
so compile all references to this object literally even if it looks
like they can be optimized."

								-- Dave

Newsgroups: gnu.gcc.bug
From: tjk@falcon.natinst.com (Todd J. Kelman)
Subject: Missing prototypes in stdio.h
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 27 Jul 1992 18:30:22 GMT

With version 2.2.2 of gcc:

  I cannot seem to locate the prototypes for the following ANSI
  functions (which should be located in stdio.h):

     int fgetpos(FILE *, fpos_t);
     int fsetpos(FILE *, fpos_t);
  
  and the following typedef:

     typedef do-type fpos_t;

The above functions do not appear to be in the library, either, as
linking an object file with those symbols produces an "unresolved
external" error.

Thanks for the help.

  Todd Kelman                                 tjk@natinst.com
  National Instruments Corp.                  (512)-795-6831


Newsgroups: gnu.gcc.bug
From: colin@eecg.toronto.edu (Colin Plumb)
Subject: Re: bug in gcc2.2.2, please acknowledge.
Organization: University of Toronto
Distribution: gnu
Date: Fri, 24 Jul 1992 23:57:03 GMT

In article <9207250016.AA02921@bass.noname> paisley@bass.ai.mit.EDU (Beau Paisley) writes:
>/* When you execute this program it generates an illegal instruction message */
>/* No syntax error is given for the illegal allocation syntax */
>
>extern "C" void exit( int );
>
>int test(int j)
>{
>	return( 0 );
>}
>
>main( )
>{
>	int n=4;
>	double x[n];	/* This seems to be the statement that gcc goofs up */
>			/* The c++ version of gcc messes it up also */
>	int i;
>	i= test(0);
>
>	exit(0);
>}

To save people the trouble of flaming for a proper bug report, I have
duplicated this error on gcc 2.2.2 for a SPARC.

Reading specs from /gnu/lib/gcc-lib/sun4/2.2.2/specs
gcc version 2.2.2
 /gnu/lib/gcc-lib/sun4/2.2.2/cpp -lang-c -v -undef -D__GNUC__=2 -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix /tmp/bug.c /usr/tmp/cca11767.i
GNU CPP version 2.2.2 (sparc)
 /gnu/lib/gcc-lib/sun4/2.2.2/cc1 /usr/tmp/cca11767.i -quiet -dumpbase bug.c -version -o /usr/tmp/cca11767.s
GNU C version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
 as -o bug.o /usr/tmp/cca11767.s
 /gnu/lib/gcc-lib/sun4/2.2.2/ld -e start -dc -dp /lib/crt0.o -L/gnu/lib/gcc-lib/sun4/2.2.2 -L/gnu/lib bug.o -lgcc -lc -lgcc


The resultant a.out file dumps core with an illegal instruction error.
The assembler produced is

gcc2_compiled.:
.text
	.align 4
	.global _test
	.proc	04
_test:
	!#PROLOGUE# 0
	save %sp,-112,%sp
	!#PROLOGUE# 1
	st %i0,[%fp+68]
	mov 0,%i0
	b,a L1
L1:
	ret
	restore
	.align 4
	.global _main
	.proc	04
_main:
	!#PROLOGUE# 0
	save %sp,-144,%sp
	!#PROLOGUE# 1
	call ___main,0
	nop
	mov %sp,%l2
	mov 4,%o0
	st %o0,[%fp-20]
	ld [%fp-20],%o0
	add %o0,-1,%l0
	add %l0,1,%l1
	sll %l1,6,%o0
	mov %o0,%l1
	add %l0,1,%o1
	sll %o1,3,%o0
	add %sp,116,%o2
	sub %o2,%sp,%o1
	add %o0,%o1,%o0
	sub %sp,%o0,%sp
	add %sp,116,%l3
	mov 0,%o0
	call _test,0
	nop
	st %o0,[%fp-24]
	mov 0,%o0
	call _exit,0
	nop
	mov %l2,%sp
L2:
	ret
	restore

Newsgroups: gnu.gcc.bug