www.digitalmars.com         C & C++   DMDScript  

D.gnu - Should GDC remove internal dependency on stdarg?

reply "Iain Buclaw" <ibuclaw ubuntu.com> writes:
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
next sibling parent reply Johannes Pfau <nospam example.com> writes:
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
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
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'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.
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.
 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
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
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
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 16 March 2012 11:33, Artur Skawina <art.08.09 gmail.com> wrote:
 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]
By using align(). :-)
 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
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 03/16/12 13:30, Iain Buclaw wrote:
 On 16 March 2012 11:33, Artur Skawina <art.08.09 gmail.com> wrote:
 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]
By using align(). :-)
 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.
The problem is the "align", which happens to be a D keyword... I was concerned about other such issues with pragmas. artur
Mar 16 2012
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 16 March 2012 22:50, Artur Skawina <art.08.09 gmail.com> wrote:
 On 03/16/12 13:30, Iain Buclaw wrote:
 On 16 March 2012 11:33, Artur Skawina <art.08.09 gmail.com> wrote:
 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]
By using align(). :-)
 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.
The problem is the "align", which happens to be a D keyword... I was concerned about other such issues with pragmas. artur
It accepts both forms of attribute names. That is align and __align__. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Mar 16 2012