Alpha VM on Solaris UltraSPARC?

[David Hopwood]

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.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>