On Tue, May 21, 2013 at 10:59 AM, Nicholas Clark <n...@ccl4.org> wrote:
> 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.
gcc49 is using the o32 ABI, so you don't have native 64-bit types. I
imagine that long long is emulated on o32, so a 64-bit load is
actually 2x 32-bit loads.
I can try later on an n32 system (with 64-bit native integers). I
imagine it will fail there.
_______________________________________________
Gcc-cfarm-users mailing list
Gcc-cfarm-users@gna.org
https://mail.gna.org/listinfo/gcc-cfarm-users
