http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #26 from Walter Bright 2012-06-29
15:18:16 PDT ---
Currently, it does not. I regard that as a separate issue, however.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this m
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #25 from Iain Buclaw 2012-06-29 09:22:59 PDT
---
Thanks, I'll be merging this in tonight. Does the frontend error if the
alignment given is not a power of 2?
ie: using align(3) should not ICE or compile.
--
Configure issuemail
/81fc676f9ae108fd673a77019d29b4aaa91aa8e6
fix Issue 7396 - Indicate default alignment with 0.
--
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 changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
/4a5a8352e91dd361a96644fb3aaa1aece0c9d0d8
fix Issue 7396 - Indicate default alignment with 0.
--
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 #21 from d...@dawgfoto.de 2012-02-01 11:42:18 PST ---
>I think it would also make sense to disallow any align(n) value greater than
>align(16) for 32bit, and possibly align(32) for 64bit platforms.
Don't do that. GCC can provide arb
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #20 from Iain Buclaw 2012-01-31 06:24:46 PST
---
I can't seem to get git working at work. :)
(In reply to comment #16)
>
> Yes, I agree. My proposal was the following.
>
> // excerpt from parse.c line 503.
> case TOKalign:
>
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #19 from Walter Bright 2012-01-31
01:17:43 PST ---
I do too.
--
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 #18 from Iain Buclaw 2012-01-31 00:05:34 PST
---
(In reply to comment #17)
> PS:
> We should definitely check at some point that alignment is a power of two.
> There is already code relying on this (AggregateDeclaration::alignmembe
http://d.puremagic.com/issues/show_bug.cgi?id=7396
d...@dawgfoto.de changed:
What|Removed |Added
CC||d...@dawgfoto.de
--- Comment #17 fro
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #16 from Daniel Green 2012-01-30 12:23:45 PST ---
(In reply to comment #15)
> Right, it's a compiler issue. Not a language issue, and no new language
> features or syntax are required.
Yes, I agree. My proposal was the following.
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #15 from Walter Bright 2012-01-30
12:20:04 PST ---
Right, it's a compiler issue. Not a language issue, and no new language
features or syntax are required.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=e
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #14 from Daniel Green 2012-01-30 12:01:15 PST ---
The statement:
`align:` becomes `align(8)`
in based entirely on how the parser handles the align attribute.
// excerpt from parse.c line 503.
case TOKalign:
{ unsigned n;
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #13 from Daniel Green 2012-01-30 11:40:30 PST ---
(In reply to comment #12)
> (In reply to comment #11)
> > Currently,
> > `align:` becomes`align(8)`. Ambiguous. default alignment or 8 byte?
>
> This is the misunderstanding.
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #12 from Walter Bright 2012-01-30
11:21:01 PST ---
(In reply to comment #11)
> Currently,
> `align:` becomes`align(8)`. Ambiguous. default alignment or 8 byte?
This is the misunderstanding.
align:
means align to the C c
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #11 from Daniel Green 2012-01-30 08:06:37 PST ---
(In reply to comment #9)
> The addition of an align(0) is not the right solution.
Currently,
`align:` becomes`align(8)`. Ambiguous. default alignment or 8 byte?
Using 0,
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #10 from Iain Buclaw 2012-01-30 03:55:12 PST
---
(In reply to comment #9)
> >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 c
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #9 from Walter Bright 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 platf
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #8 from Iain Buclaw 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
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #7 from Dan G. 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.
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #6 from Walter Bright 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
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #5 from Dan G. 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 re
http://d.puremagic.com/issues/show_bug.cgi?id=7396
Iain Buclaw changed:
What|Removed |Added
CC||ibuc...@ubuntu.com
--- Comment #4 from I
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #3 from Walter Bright 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.
Th
http://d.puremagic.com/issues/show_bug.cgi?id=7396
--- Comment #2 from Dan G. 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
http://d.puremagic.com/issues/show_bug.cgi?id=7396
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #
26 matches
Mail list logo
