On 6 Apr 2013, at 0:06, Walter Bright wrote:
> It's C ABI compatible. Note that:
>
> struct S { int[4] a; }
> struct T { int x; S s; }
>
> has a size of 20 bytes. What's going on is when the statically allocated data is emitted, it is aligned to 16 bytes. This does not break the C ABI.

My point here is that C compiler might not align the same data to 16 bytes.

--- cpart.c
struct S41 { int a0, a1, a2, a3; };
struct S41 s41;
---

--- dpart.d
struct S41 { int[4] a; }
extern(C) extern shared S41 s41;

void main() {
    import core.stdc.stdio;
    printf("&s = %p\n", &s41);
    assert((cast(int)&s41 & 0xF) == 0);
}
---

---
clang -c cpart.c
dmd cpart.o dpart.d && ./cpart
---
&s = 0x1092b0fe8
core.exception.AssertError@dpart(7): Assertion failure
---

Thus, if int[4] is defined to be equivalent to four int fields (as you said it should be in previous ABI discussions, can't remember whether it is actually in the spec), and the point of test41() is to test that int[4] globals are aligned to 16 bytes, then we have a problem.

If the behavior you want to test for is that (int[4]) globals *defined in D code* are aligned to 16 bytes, then this obviously isn't a problem.

But my main point is that I can't see why the assertion in test41() should hold. If you think it should be left in, please cite the appropriate place in the spec so Iain and I can fix GDC and LDC. If it's not in the spec yet, we have to add it.

David
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 4/5/2013 3:56 PM, David Nadlinger wrote:
>
> My point here is that C compiler might not align the same data to 16 bytes.

Consider the following C code:
--------------------------------------
#include <stdio.h>

struct S {
    int a[4];
};

int x;
struct S s;

struct T {
    int t;
    struct S s;
};

void main()
{
    printf("%p %p %d\n", &x, &s, sizeof(struct T));
}
------------------------------

I compiled it with gcc under Linux. x is aligned to 4 bytes, and s is aligned to 16 bytes (you can see this using dumpobj on the object file). The sizeof(struct T) is also 20 bytes, just like in dmd.

dmd is behaving just like gcc does.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Sat, Apr 6, 2013 at 2:02 AM, Walter Bright <walter@digitalmars.com> wrote:
> dmd is behaving just like gcc does.

1) I am hardly a C language lawyer, but I can't recall a portion of the standard where this would be mandated.

2) Clang behaves differently (Clang 3.2, Linux x86_64):
———
   9  .globl s,@OBJECT,COMMON,ALIGN=4,SIZE=16
  10  .globl x,@OBJECT,COMMON,ALIGN=4,SIZE=4
———

3) __alignof(struct S) is (obviously) also 4 for GCC.

I still think that int4 could be an alternative for situations where you need the extra alignment guarantee, but my main request is that if you want to keep the test in, that behavior should be reflected in the spec, so it can be implemented in GDC/LDC without guessing what was being meant.

David
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 6 April 2013 01:02, Walter Bright <walter@digitalmars.com> wrote:

>
> On 4/5/2013 3:56 PM, David Nadlinger wrote:
>
>>
>> My point here is that C compiler might not align the same data to 16 bytes.
>>
>
> Consider the following C code:
> ------------------------------**--------
> #include <stdio.h>
>
> struct S {
>     int a[4];
> };
>
> int x;
> struct S s;
>
> struct T {
>     int t;
>     struct S s;
> };
>
> void main()
> {
>     printf("%p %p %d\n", &x, &s, sizeof(struct T));
> }
> ------------------------------
>
> I compiled it with gcc under Linux. x is aligned to 4 bytes, and s is
> aligned to 16 bytes (you can see this using dumpobj on the object file).
> The sizeof(struct T) is also 20 bytes, just like in dmd.
>
> dmd is behaving just like gcc does.
>
>
You can also see more in the assembly produced by gcc.

32bit:
        .comm   x,4,4
        .comm   s,16,4
---
64bit:
        .comm   x,4,4
        .comm   s,16,16


Looks like dmd is behaving just like 64bit gcc does. But not 32bit.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 6 April 2013 01:49, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> On 6 April 2013 01:02, Walter Bright <walter@digitalmars.com> wrote:
>
>>
>> On 4/5/2013 3:56 PM, David Nadlinger wrote:
>>
>>>
>>> My point here is that C compiler might not align the same data to 16 bytes.
>>>
>>
>> Consider the following C code:
>> ------------------------------**--------
>> #include <stdio.h>
>>
>> struct S {
>>     int a[4];
>> };
>>
>> int x;
>> struct S s;
>>
>> struct T {
>>     int t;
>>     struct S s;
>> };
>>
>> void main()
>> {
>>     printf("%p %p %d\n", &x, &s, sizeof(struct T));
>> }
>> ------------------------------
>>
>> I compiled it with gcc under Linux. x is aligned to 4 bytes, and s is
>> aligned to 16 bytes (you can see this using dumpobj on the object file).
>> The sizeof(struct T) is also 20 bytes, just like in dmd.
>>
>> dmd is behaving just like gcc does.
>>
>>
> You can also see more in the assembly produced by gcc.
>
> 32bit:
>         .comm   x,4,4
>         .comm   s,16,4
> ---
> 64bit:
>         .comm   x,4,4
>         .comm   s,16,16
>
>
> Looks like dmd is behaving just like 64bit gcc does. But not 32bit.
>
>
Oh, and just incase it wasn't clear from my part (not sure about the case with ldc), but it is only x86 where this test is failing with gdc.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 4/5/2013 5:40 PM, David Nadlinger wrote:
> On Sat, Apr 6, 2013 at 2:02 AM, Walter Bright <walter@digitalmars.com> wrote:
>> dmd is behaving just like gcc does.
> 1) I am hardly a C language lawyer, but I can't recall a portion of
> the standard where this would be mandated.

It isn't in the C standard.

>
> 2) Clang behaves differently (Clang 3.2, Linux x86_64):
> ———
>     9  .globl s,@OBJECT,COMMON,ALIGN=4,SIZE=16
>    10  .globl x,@OBJECT,COMMON,ALIGN=4,SIZE=4
> ———

That is the same behavior, not different.

>
> 3) __alignof(struct S) is (obviously) also 4 for GCC.

Sure, but still when writing out the section data it aligns it as 16.


>
> I still think that int4 could be an alternative for situations where
> you need the extra alignment guarantee, but my main request is that if
> you want to keep the test in, that behavior should be reflected in the
> spec, so it can be implemented in GDC/LDC without guessing what was
> being meant.
>

I have no issue with putting it in the spec.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Sat, Apr 6, 2013 at 3:04 AM, Walter Bright <walter@digitalmars.com> wrote:
> On 4/5/2013 5:40 PM, David Nadlinger wrote:
>>
>> 2) Clang behaves differently (Clang 3.2, Linux x86_64):
>> ———
>>     9  .globl s,@OBJECT,COMMON,ALIGN=4,SIZE=16
>>    10  .globl x,@OBJECT,COMMON,ALIGN=4,SIZE=4
>> ———
> That is the same behavior, not different.

It is (4 byte alignment) – also see the cpart.c/dpart.d output I included in my post from two hours ago.

David
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 4/5/2013 6:16 PM, David Nadlinger wrote:
> On Sat, Apr 6, 2013 at 3:04 AM, Walter Bright <walter@digitalmars.com> wrote:
>> On 4/5/2013 5:40 PM, David Nadlinger wrote:
>>> 2) Clang behaves differently (Clang 3.2, Linux x86_64):
>>> ———
>>>      9  .globl s,@OBJECT,COMMON,ALIGN=4,SIZE=16
>>>     10  .globl x,@OBJECT,COMMON,ALIGN=4,SIZE=4
>>> ———
>> That is the same behavior, not different.
> It is (4 byte alignment) – also see the cpart.c/dpart.d output I
> included in my post from two hours ago.
>

My bad. I kept seeing the 16.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals