Alpha VM on Solaris UltraSPARC?

Lee Salzman lsalzman1 at
Sat Mar 12 16:02:22 PST 2005

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 
decision on GCC's part to ignore this possibility to eek out a few more 
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


David Hopwood wrote:

> Nicolas Pelletier wrote:
>> David Hopwood <david.nospam.hopwood at> 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.

More information about the Slate mailing list