http://d.puremagic.com/issues/show_bug.cgi?id=7396

           Summary: Indicate default alignment with 0.
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: venix1@gmail.com


--- Comment #0 from Dan G. <venix1@gmail.com> 2012-01-29 09:13:18 PST ---
Created an attachment (id=1071)
align.patch - Patch file

The patch modifies DMD to use the value 0 when default alignment should be used.  It allows implementations to easily deviate from how DMD handles field alignment and keep the requirement that `align` will restore default alignment.

Below is an attempt to describe why this is useful.

---

DMD and GDC different in how they interpret the align keyword.  GDC will align all fields to the specified size.  DMD appears to still take into consideration the required alignment for a given type.

The issue arises when one wishes to return to default alignment.

"align by itself sets it to the default, which matches the default member alignment of the companion C compiler."


GDC uses the value passed to AlignDeclaration to force the alignment of field members.  The front end currently treats default alignment as system alignment generally 8.  This will indicate to GDC all field members should be aligned on 8 bytes instead of restoring default alignment.

The following test shows the unlikely situation when this becomes an issue. This situation in unlikely until conditional complication comes into play since a trivial workaround is to use braces.

// For GDC.
struct A
{
  align(2):
    byte a; // 2 bytes
    byte b; // 2 bytes
    byte c; // 2 bytes
  align: // restore default alignment. Translates to align(8)
    byte d; // 8 bytes.  1 is expected
    byte e; // 8 bytes.  1 is expected
    byte f; // 8 bytes.  1 is expected
}

align struct A {} is remade into align(8) struct A {}.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7396


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com


--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> 2012-01-29 12:01:39 PST ---
I'm really not understanding this.

"align" by itself means default alignment. How that would differ from align(0)
escapes me.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7396



--- Comment #2 from Dan G. <venix1@gmail.com> 2012-01-29 14:41:27 PST ---
(In reply to comment #1)
> I'm really not understanding this.
> 
> "align" by itself means default alignment. How that would differ from align(0)
> escapes me.

The problem is how the front end treats "align".

---

struct B
{
    align:
    char a;
}

$ dmd -o- align.d -H

// D import file generated from 'align.d'
// Notice align became align (8)
struct B
{
    align (8) char a;

}

---

That treatment of "align" conflicts with what's in the specification.

"align by itself sets it to the default, which matches the default member alignment of the companion C compiler."

"Integer specifies the alignment which matches the behavior of the companion C compiler when non-default alignments are used."

The front end has no way to indicate default alignment is what the user wants and is effectively rewriting the default alignment expression to be an Integer alignment expression.

By setting "n = 0" instead of "n = global.structalign" if clearly indicates to the compiler default alignment is desired.  This is beneficial for when the default compiler is not DMD.

A description of GCC's aligned attribute which GDC attempted to mimic. http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#Variable-Attributes

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7396



--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> 2012-01-29 16:40:01 PST ---
The default alignment of 8 does not align byte values to 8 byte boundaries, as your message suggests. I think this is where the issue is - I think it is just a misunderstanding.

The default alignment should match what the C compiler does as the default. I believe this does behave this way currently - dmd for Windows matches the dmc compiler, and dmd for Linux matchs gcc.

If this is not what gdc is doing, then there's an issue with gdc.

In any case,

   align:

is *required* to match what the C compiler does, whatever that may be.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7396


Iain Buclaw <ibuclaw@ubuntu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw@ubuntu.com


--- Comment #4 from Iain Buclaw <ibuclaw@ubuntu.com> 2012-01-29 18:46:43 PST ---
The idea was that, ie:

struct foo
{
    align(8) int bar;
}

be equivalent to:

struct foo
{
    int bar __attribute__((aligned(8)));
};


Currently this is not the case in DMDFE, as the user defined alignment is pretty much ignored (unless the value 4 or less?).

Slightly off note, but there is also no error if the aligned value given is not a power of 2, eg: align(3).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7396



--- Comment #5 from Dan G. <venix1@gmail.com> 2012-01-29 18:53:41 PST ---
Going with what Iain added.  The reason for this is that the front end treats default alignment and align(8) as equal.  This leaves no way for GDC to know that default alignment is being requested.

That brings me to my original suggestion that 0 should be used to indicate default alignment.  This gives a very clear indication that default alignment is what is desired.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7396



--- Comment #6 from Walter Bright <bugzilla@digitalmars.com> 2012-01-29 22:20:51 PST ---
I would suggest the problem is with the way gdc is doing alignment.

    align:

means the default alignment that matches the C compiler. dmd and gdc need to do whatever it takes to make that happen. Adding another align directive just confuses things.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7396



--- Comment #7 from Dan G. <venix1@gmail.com> 2012-01-29 22:46:18 PST ---
(In reply to comment #6)
> I would suggest the problem is with the way gdc is doing alignment.
gdc is attempting to treat field alignment in the same manner as gcc's aligned attribute does.  From the wording of the specification this seems reasonable.


>     align:
> 
> means the default alignment that matches the C compiler.
`align:` is translated into `align(8)` by the parser @ https://github.com/D-Programming-Language/dmd/blob/master/src/parse.c#L503

> dmd and gdc need to do whatever it takes to make that happen.
After the align attribute is parsed, neither dmd nor gdc can determine default alignment is wanted.

> Adding another align directive just confuses things.
I'm not proposing another align directive.  I'm suggesting a modification to the way `align:` is handled by the parser so that dmd or gdc can determine if default alignment is needed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7396



--- Comment #8 from Iain Buclaw <ibuclaw@ubuntu.com> 2012-01-30 03:09:44 PST ---
(In reply to comment #6)
> I would suggest the problem is with the way gdc is doing alignment.
> 
>     align:
> 
> means the default alignment that matches the C compiler. dmd and gdc need to do whatever it takes to make that happen. Adding another align directive just confuses things.


From the spec:
---
Align Attribute specifies the alignment of struct members. align by itself sets it to the default, which matches the default member alignment of the companion C compiler.
---

GDC matches the companion GCC compiler, in that we have a callback to get the field alignment for the type, which may not necessarily the same as the type alignment, as some architectures (i.e. i386) limit struct field alignment to a lower boundary than alignment of some types of variables.



From the spec:
---
Integer specifies the alignment which matches the behavior of the companion C compiler when non-default alignments are used.
---

GDC matches the companion GCC compiler here as well, in that:

struct S {
    align(4) byte a; // placed at offset 0
    align(4) byte b; // placed at offset 4
}

This is achieved by adding a declalign field in VarDeclaration that takes precedence over the type align.

This I think is different from how DMC++ treats the align attribute, which is where the conflict of interest arises.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7396



--- Comment #9 from Walter Bright <bugzilla@digitalmars.com> 2012-01-30 03:19:50 PST ---
>This I think is different from how DMC++ treats the align attribute, which is
where the conflict of interest arises.

Which means that dmd should change to match gcc for gcc platforms. The addition of an align(0) is not the right solution.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------