On 8 March 2013 16:11, Johannes Pfau <nospam@example.com> wrote:

Am Fri, 8 Mar 2013 15:18:53 +0000
schrieb Iain Buclaw <ibuclaw@ubuntu.com>:

> Yet not all attributes that GCC offers actually make sense to have in
> D. We certainly need to have a review of each one and discuss what is
> most important to have. Also defining our own unique attributes
> along the way. :o)
>

To get the discussion started: I think we could adopt these LDC
pragmas:

LDC_no_typeinfo
LDC_no_moduleinfo

That could come under the jurisdiction of -ffree-standing (something that could be the equivalent of dmd's -betterC).

Maybe nice to have:
LDC_global_crt_ctor and LDC_global_crt_dtor
(is this the same as
__attribute__((constructor))/__attribute__((destructor))) ?

Indeed. This is different to this() and static this() as these get called when the object gets loaded into C runtime, rather than delayed until D runtime initialises.

Not needed in GDC?
LDC_allow_inline
(allow inlining a function continaining inline asm. not necessary for
gdc extended inline asm)

Also not needed:

- aligned: because D has align() for that.

- gnu_inline, artificial: because D has no inline keyword, nor has need for one.

- error, warning: There are better alternatives that can be implemented in D.

- deprecated: There is a deprecated keyword for that.

- no_split_stack: Infact, supporting -fsplit-stack is a generally bad idea anyway and requires a new GC.

- nothrow: D has nothrow keyword

- pure, const: Although D has pure keyword that does not necessarily follow same as C semantics, I don't think the inclusion of these are beneficial at all.

- returns_twice: Unless of course I'm missing the point of something here. :o)

- optimise, target: I'm sure the guy who implemented these meant well, but I fail to see the point as to why you'd want such an attribute.

- used, unused: ......

Regards

--
Iain Buclaw

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