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

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?

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';

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.

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';

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

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';