Alpha VM on Solaris UltraSPARC?

[Lee Salzman]

In our case it is definitely a problem with GCC. The field of the 
structure in
question may be aligned to an 8 byte boundary, but the structure itself  is
only aligned to a 4 byte boundary in the Slate heap. This is, overall, a 
policy
decision on GCC's part to ignore this possibility to eek out a few more 
cycles
here and there.

It seems the options -mno-faster-structs on SPARC may entirely solve this
problem, and it may be that at higher optimization levels GCC assumes
-mfaster-structs. The man page says this controls the assumption of 8 byte
alignment of structures. So ya'll try using -mno-faster-structs and see what
happens.

Lee

David Hopwood wrote:

> Nicolas Pelletier wrote:
>
>> David Hopwood <david.nospam.hopwood at blueyonder.co.uk> writes:
>>
>>> Nicolas Pelletier wrote:
>>>
>>>> Just an aside: a similar problem  with dispatchID shows up on a 32-bit
>>>> sparc. The 2  offending lines where dispatchID is used  in the VM must
>>>> be converted to a byte-per-byte copy mechanism using a for loop (since
>>>> gcc optimizes calls to memcpy).
>>>
>>>
>>> memcpy is required to work for unaligned pointers. If it didn't that
>>> would be a bug in gcc, and I'm not aware of any such bug.
>>
>>
>> I remember noticing a difference  with gcc 2.95.2 on a sparc depending
>> on the optimization level: -O0 would  leave the calls to memcpy in the
>> executable code, producing  a working VM; -O2 would  try to inline the
>> calls  and  the resulting  executable  contained  an unaligned  access
>> x->dispatchID that crashed the thing.
>
>
> Apparently gcc will generate code that assumes alignment when memcpy
> is passed a pointer of a type that should be aligned:
> <http://gcc.gnu.org/ml/gcc-bugs/2001-12/msg00546.html>
> <http://gcc.gnu.org/ml/gcc-bugs/2001-12/msg00557.html>
>
> Note that it will also do this optimization for code that has
> unsafe casts between pointers of different alignment (e.g.
> <http://lists.debian.org/debian-gcc/2003/01/msg00386.html>).
> This is undefined behaviour according to Standard C, and so the
> optimization is valid.
>
> More such bug reports can be found by Googling
> "memcpy bug gcc unaligned", but AFAICS they are all program errors,
> not errors in gcc.
>
> There is a -fno-builtin-memcpy option, but it shouldn't be needed in
> this case (and in fact would just hide other alignment problems).
> As long as the declared type of dispatchID is consistent with its
> actual alignment, memcpy should work.
>