Re: Bug in Gcc 2.5.8

[Claus Brod <clausb@hpbeo79.bbn.hp.com>]

> I had a look in 'MC68030 Enhanced 32-bit microprocessor user's manual 
> (3rd Edition)' and at page 3-15 it says that ADDQ affects X N Z in the 
> normal way (and V C in a special way, but that's irrelevant).
> It does NOT say anything special about using address registers. 
> Actually ADDA is not even listed which I interpret as not affecting any 
> flags.
> 
> Please correct me if I'm wrong but you know where I got my information.

I just ran a test on my HP9000/380 (68040 machine) here at work with
the following program:

int foo(int i) { return i; }	/* just returns what it gets */

int main(void)
{
	if (foo(0)) {
	  /* we should never get here */
	  printf("foo returned a non-zero value\n");
	} else {
	  printf("foo returned a zero value\n");
	}
	return 0;
}

Normally, the program prints "foo returned a zero value". The assembler
code in main looks like this:

	global	_main
_main:
	link.l	%a6,&LF2
	movm.l	&LS2,(%sp)
	fmovm.x	&LSF2,LFF2(%a6)
	mov.l	&42,-(%sp)
	bsr.l	_foo		; call function foo which returns
				; result in d0
	addq	&4,%sp		; pop args from stack      *1*
	tst.l	%d0		; test the result          *2*
	beq.l	L14		; branch if zero
	mov.l	&L16,-(%sp)
	bsr.l	_printf
	addq	&4,%sp
	bra.l	L17
L14:
	mov.l	&L18,-(%sp)
	bsr.l	_printf
	addq	&4,%sp
L17:
	movq	&0,%d0
	bra.l	L13
L13:
	unlk	%a6
	rts

After exchanging instructions *1* and *2*, i.e. by deferring the
stack pop operation, and assembling/linking, the program suddenly
claims that the function foo() returns a *non-zero* result! So
this seems to show that the original suspicion was valid -
addq seems to change the flags. Am I hallucinating?

--clausb@hpbeo79.bbn.hp.com-----------------------------------------------
Claus Brod, MDD, HP Boeblingen         Have you hugged your manager today?
--#include <std_disclaimer>-----------------------------------------------