On 8 March 2013 16:11, Johannes Pfau <[email protected]> wrote: > Am Fri, 8 Mar 2013 15:18:53 +0000 > schrieb Iain Buclaw <[email protected]>: > > > > 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';
