D.gnu - Should GDC remove internal dependency on stdarg?
- Iain Buclaw (10/10) Mar 12 2012 I'm picking up some old issues from bugzilla, this one is worth
- Johannes Pfau (17/33) Mar 16 2012 I think I like the pragma approach more (as it allows auto-completion
- Iain Buclaw (14/47) Mar 16 2012 I don't think gcc intrinsics are worth thinking about changing, as I
- Artur Skawina (8/17) Mar 16 2012 Well, what's the definition of "hidden" here? The access to "std" stuff
- Iain Buclaw (9/26) Mar 16 2012 :-(
- Artur Skawina (4/34) Mar 16 2012 The problem is the "align", which happens to be a D keyword...
- Iain Buclaw (5/39) Mar 16 2012 It accepts both forms of attribute names. That is align and __align__.
I'm picking up some old issues from bugzilla, this one is worth having a community review. http://d.puremagic.com/issues/show_bug.cgi?id=1949 Should hidden GCC features be imported from a magic module provided by gcc.* packages - or should the implementation be re-written using pragmas instead? This is what LDC currently does (all of which would be possible to do in GDC): http://www.dsource.org/projects/ldc/wiki/Docs#Pragmas Discuss. :)
Mar 12 2012
Am Mon, 12 Mar 2012 16:35:52 +0100 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:I'm picking up some old issues from bugzilla, this one is worth having a community review. http://d.puremagic.com/issues/show_bug.cgi?id=1949 Should hidden GCC features be imported from a magic module provided by gcc.* packages - or should the implementation be re-written using pragmas instead?I think I like the pragma approach more (as it allows auto-completion in IDEs and seems less 'magic'), but I don't have a strong opinion here.This is what LDC currently does (all of which would be possible to do in GDC): http://www.dsource.org/projects/ldc/wiki/Docs#Pragmas Discuss. :)pragma(intrinsic) has the advantage that function declarations are available, so tools like visualD / mono-D can provide auto-completion for intrinsics. But maintaining all those pragma(intrinsics) is additional work, so I don't know if it's worth it. And what happens for intrinsics which are only supported on some architectures? version(ARM) + pragma(intrinsic)? I think that's too much work, especially as we already have working intrinsics. pragma(no_typeinfo/no_moduleinfo) sounds useful (Manu will probably like it ;-)) pragma(alloca): I don't know if this is needed? pragma(allow_inline): As we don't support dmd-compatible inline asm anymore and gcc inline asm doesn't prevent inlining AFAIR, this pragma isn't needed with gdc?
Mar 16 2012
Iain Buclaw <ibuclaw ubuntu.com> On 16 March 2012 10:34, Johannes Pfau <nospam example.com> wrote:Am Mon, 12 Mar 2012 16:35:52 +0100 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:I don't think gcc intrinsics are worth thinking about changing, as I think it's fine as is. The only downside is gcc.builtins module is empty from the user perspective, so they don't know what is and isn't included when compiling.I'm picking up some old issues from bugzilla, this one is worth having a community review. http://d.puremagic.com/issues/show_bug.cgi?id=3D1949 Should hidden GCC features be imported from a magic module provided by gcc.* packages - or should the implementation be re-written using pragmas instead?I think I like the pragma approach more (as it allows auto-completion in IDEs and seems less 'magic'), but I don't have a strong opinion here.This is what LDC currently does (all of which would be possible to do in GDC): http://www.dsource.org/projects/ldc/wiki/Docs#Pragmas Discuss. :)pragma(intrinsic) has the advantage that function declarations are available, so tools like visualD / mono-D can provide auto-completion for intrinsics. But maintaining all those pragma(intrinsics) is additional work, so I don't know if it's worth it. And what happens for intrinsics which are only supported on some architectures? version(ARM) + pragma(intrinsic)? I think that's too much work, especially as we =A0already have working intrinsics.pragma(no_typeinfo/no_moduleinfo) sounds useful (Manu will probably like it ;-)) pragma(alloca): I don't know if this is needed? pragma(allow_inline): As we don't support dmd-compatible inline asm anymore and gcc inline asm doesn't prevent inlining AFAIR, this pragma isn't needed with gdc?I'm not so much interested in these as such. The higher idea behind the orginal topic really is to have a re-locatable implementation, rather than saying you must 'import core.stdc.stdarg;' to use va args properly, and lay this burden on extensive third party libraries that are able to replace druntime and phobos altogether (ie: Tango is possibly the only other). --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Mar 16 2012
On 03/12/12 16:35, Iain Buclaw wrote:I'm picking up some old issues from bugzilla, this one is worth having a community review. http://d.puremagic.com/issues/show_bug.cgi?id=1949 Should hidden GCC features be imported from a magic module provided by gcc.* packages - or should the implementation be re-written using pragmas instead?Well, what's the definition of "hidden" here? The access to "std" stuff (varargs, intrinsics etc) might be done via pragmas in magic GCC modules, but many user-accessible things need to be exposed via pragmas anyway. And they need to be accessible from D - eg: how do you set GCCs align attribute from D?... [1] artur [1] via pragmas; D's "align" does not count.
Mar 16 2012
On 16 March 2012 11:33, Artur Skawina <art.08.09 gmail.com> wrote:On 03/12/12 16:35, Iain Buclaw wrote:By using align(). :-)I'm picking up some old issues from bugzilla, this one is worth having a community review. http://d.puremagic.com/issues/show_bug.cgi?id=1949 Should hidden GCC features be imported from a magic module provided by gcc.* packages - or should the implementation be re-written using pragmas instead?Well, what's the definition of "hidden" here? The access to "std" stuff (varargs, intrinsics etc) might be done via pragmas in magic GCC modules, but many user-accessible things need to be exposed via pragmas anyway. And they need to be accessible from D - eg: how do you set GCCs align attribute from D?... [1]artur [1] via pragmas; D's "align" does not count.:-( pragma(attribute) or pragma(set_attribute) are the second door in. You need to lookup GCC's documentation on Declaration and Type attributes for the exact names. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Mar 16 2012
On 03/16/12 13:30, Iain Buclaw wrote:On 16 March 2012 11:33, Artur Skawina <art.08.09 gmail.com> wrote:The problem is the "align", which happens to be a D keyword... I was concerned about other such issues with pragmas. arturOn 03/12/12 16:35, Iain Buclaw wrote:By using align(). :-)I'm picking up some old issues from bugzilla, this one is worth having a community review. http://d.puremagic.com/issues/show_bug.cgi?id=1949 Should hidden GCC features be imported from a magic module provided by gcc.* packages - or should the implementation be re-written using pragmas instead?Well, what's the definition of "hidden" here? The access to "std" stuff (varargs, intrinsics etc) might be done via pragmas in magic GCC modules, but many user-accessible things need to be exposed via pragmas anyway. And they need to be accessible from D - eg: how do you set GCCs align attribute from D?... [1]artur [1] via pragmas; D's "align" does not count.:-( pragma(attribute) or pragma(set_attribute) are the second door in. You need to lookup GCC's documentation on Declaration and Type attributes for the exact names.
Mar 16 2012
On 16 March 2012 22:50, Artur Skawina <art.08.09 gmail.com> wrote:On 03/16/12 13:30, Iain Buclaw wrote:It accepts both forms of attribute names. That is align and __align__. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';On 16 March 2012 11:33, Artur Skawina <art.08.09 gmail.com> wrote:The problem is the "align", which happens to be a D keyword... I was concerned about other such issues with pragmas. arturOn 03/12/12 16:35, Iain Buclaw wrote:By using align(). :-)I'm picking up some old issues from bugzilla, this one is worth having a community review. http://d.puremagic.com/issues/show_bug.cgi?id=1949 Should hidden GCC features be imported from a magic module provided by gcc.* packages - or should the implementation be re-written using pragmas instead?Well, what's the definition of "hidden" here? The access to "std" stuff (varargs, intrinsics etc) might be done via pragmas in magic GCC modules, but many user-accessible things need to be exposed via pragmas anyway. And they need to be accessible from D - eg: how do you set GCCs align attribute from D?... [1]artur [1] via pragmas; D's "align" does not count.:-( pragma(attribute) or pragma(set_attribute) are the second door in. You need to lookup GCC's documentation on Declaration and Type attributes for the exact names.
Mar 16 2012