Alpha VM on Solaris UltraSPARC?
david.nospam.hopwood at blueyonder.co.uk
Sat Mar 12 01:29:58 PST 2005
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:
Note that it will also do this optimization for code that has
unsafe casts between pointers of different alignment (e.g.
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>
More information about the Slate