On Tue, May 21, 2013 at 06:40:17PM +0200, Vladimir Serbinenko wrote:
> On 21.05.2013 18:33, Martin Jambor wrote:
>
> > Hi,
> >
> > On Tue, May 21, 2013 at 05:28:42PM +0200, Laurent GUERBY wrote:
> >> Hi,
> >>
> >> For various reasons it is no longer possible for us to host and
> >> maintain in running state the gcc6x machines.
> >>
> >
> > oh no, those were basically the machines on which I debugged
> > strict-alignment issues.
>
> gcc42 and gcc49 should be fine for this.
It seems that mips is not as strict as sparc for alignment of long long.
Despite mips gcc saying that __alignof__(long long) is 8, this code:
#include <stdio.h>
#include <inttypes.h>
int main() {
uint32_t a[4] = { 0x00010203, 0x04050607, 0x08090A0B, 0x0C0D0E0F };
uint64_t b = *((unsigned long long *) (a + 1));
printf("Got %0llX\n", b);
return 0;
}
runs on gcc49, producing this output:
Got 8090A0B04050607
The same code compiled on gcc62 (a sparc) produces a bus error.
Also, sparc gcc can generate code that use a single 8 byte memory load
instruction to load two adjacent 4 byte values from a structure it knows to
be 8 byte aligned. This will crash if calling code has cheated on structure
alignment. I'm not aware of mips gcc doing this.
Hence mips seems to be a less than ideal proxy for sparc for verifying that
code is not making alignment mistakes.
Nicholas Clark
_______________________________________________
Gcc-cfarm-users mailing list
Gcc-cfarm-users@gna.org
https://mail.gna.org/listinfo/gcc-cfarm-users
