Re: A bug in GCC 2.95.2 for SPARC

[James Cheng <James dot Cheng at eng dot sun dot com>]

David,

> >    For performance reason. UltraSPARC is a 64-bit processor, where one
> >    64-bit store (std) is faster than two 32-bit stores (st). We are
> >    building a performance library for media applications.
> > 
> > Integer 'std' is deprecated in V9 and runs slower on UltraSparc than
> > two 'st' stores.  Perhaps you really mean 'stx' integer stores, or
> > 'stdf' double float stores?  The latter you can get with -mv8.
> 
> You are right that I was referring to 'stdf' which has a suggested asm
> syntax of 'std freg, [address]'. The bug I encountered is that some gcc
> generated 'stdf's are dealing with non-8-byte-aligned addresses, which
> cause bus errors... Wait a minute. On page 222 of "The SPARC Architecture
> Manual, Version 9", it reads:
> 
> 	The store double floating-point instruction (STDF) copies
> 	a doubleword from a double floating-point register into a 
> 	word-aligned doubleword in memory.
> 	^^^^^^^^^^^^
> 
> But it seems to me that 'stdf' requires a doubleword-aligned address.
> This might be the reason of this bug.
> 
> I am going to find the answer for this discrepancy.

It turned out to be an implementation dependency of the UltraSPARC.
On page 249 of "UltraSPARC User's Manual, Revision 2.0 - June 1996"
there is:

	LDDF{A}/STDF{A} cause an LDDF/STDF_mem_address_not_aligned
	trap if the effective address is 32-bit aligned but not
	64-bit (doubleword) aligned.

I have tried the gcc 2.96 version 2.96 20000501 (experimental) with 
-mcpu=ultrasparc, and the problem I reported earlier is gone.

Thanks,

-James