View mode: basic / threaded / horizontal-split · Log in · Help
March 12, 2012
Should GDC remove internal dependency on stdarg?
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. :)
March 16, 2012
Re: Should GDC remove internal dependency on stdarg?
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?
March 16, 2012
Re: Should GDC remove internal dependency on stdarg?
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=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.
>

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).


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
March 16, 2012
Re: Should GDC remove internal dependency on stdarg?
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.
March 16, 2012
Re: Should GDC remove internal dependency on stdarg?
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';
March 16, 2012
Re: Should GDC remove internal dependency on stdarg?
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
March 16, 2012
Re: Should GDC remove internal dependency on stdarg?
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';
Top | Discussion index | About this forum | D home