On 12/18/12 21:33, Iain Buclaw wrote:
>  b) No one infact uses GDC (go figure!).

> Similarly, no one has noticed that most of the pragma GDC supported have mysterious vanished either.  The ones left at kept only for gcc.builtins support until a time I re-implement the attributes in a better way that I haven't decided on yet (hence why raising this thread).

See above - that's one thing that became completely clear after I first tried GDC and filed the ~third gdc bugreport... Right now the situation is even worse, as dealing with an experimental language is enough - having to also work with an unstable compiler is not a practical option. If gdc is upstreamed hopefully some users will return and new ones will come.

Pragmas weren't usable, for many obvious reasons, which i have mentioned here often enough. Something like @gcc.noreturn will work, /after/ UDAs are properly handled by the frontend (aliasing/tuples, attaching to locals (this may already work) and everything else etc). The prefix isn't a problem because the typical usage will be

   module config;

   static if (this_is_gcc)
      alias @noreturn = @gcc.noreturn;
   else static if (this_is_whatever)
      alias @noreturn = ID!(@whatever.no(return), @whatever.blah);
   else
      alias @noreturn = ID();

Ie no different than C/C++ attribute handling.

artur

On 18 December 2012 21:31, Andrei Alexandrescu < SeeWebsiteForEmail@erdani.org> wrote:

> On 12/18/12 11:58 AM, Iain Buclaw wrote:
>
>> On 18 December 2012 16:43, Peter Alexander <peter.alexander.au@gmail.com <mailto:peter.alexander.au@**gmail.com <peter.alexander.au@gmail.com>>> wrote:
>>
>>     On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw wrote:
>>
>>         Should we take this as an opportunity for other compiler
>>         maintainers to implement their own compiler-specific predefined
>>         attributes?
>>
>>
>>     Please, no!
>>
>>     Suppose GDC implements @noreturn (or whatever other attribute)
>>
>>     Later, LDC implements @noreturn separately with slightly different
>>     semantics.
>>
>>     We now end up in a situation where @noreturn cannot be used
>>     portably, and neither compiler developer has incentive to change
>>     (whoever changes breaks their users code).
>>
>>
>> Provide a situation where @noreturn attribute would mean anything other than telling the compiler to assume that the function|| cannot return, and I might please you on *that* particular attribute.
>>
>
> One possibility: one compiler assumes @noreturn never returns, whereas another enforces that by adding an HLT at the end of the function.
>
> Andrei
>
>

The effect would really be the same though.  Typically in a @noreturn function, there is no 'ret', so if the function were to return, the stack would be left corrupt.  The key difference is that whilst in one program, it halts at the point of the program that should never be reached.  The other crashes an burns with a HLT or SEGV shortly afterwards.

This behaviour I describe incidentally is the case with assert(0) in release code right now.  Different compilers handle it differently, DMD just so happens to enforce that by adding a HTL at the end whilst others don't.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 18 December 2012 21:36, Artur Skawina <art.08.09@gmail.com> wrote:

> On 12/18/12 21:33, Iain Buclaw wrote:
> >  b) No one infact uses GDC (go figure!).
>
> > Similarly, no one has noticed that most of the pragma GDC supported have
> mysterious vanished either.  The ones left at kept only for gcc.builtins support until a time I re-implement the attributes in a better way that I haven't decided on yet (hence why raising this thread).
>
> See above - that's one thing that became completely clear after I first
> tried GDC and
> filed the ~third gdc bugreport... Right now the situation is even worse,
> as dealing
> with an experimental language is enough - having to also work with an
> unstable
> compiler is not a practical option. If gdc is upstreamed hopefully some
> users will
> return and new ones will come.
>
>
A lot of these erratic changes stems from code in GDC written during gcc-3.3 / gcc-3.4 era when GCC frontends typically could include ties to a particular backend, or when useful parts of the backend could be fleshed out to the frontend and didn't depend on the frontend language being part of the C family.

What's left is a fair amount of duplicated code between GDC and GCC (C/C++ front-end's) code base, which core devs don't like.  TARGET macros in GDC, which core devs especially don't like.  And a balancing act between keeping the cool features GDC *could* do in the past and what GDC *should* do in the future to ensure that the frontend should generate code agnostic to any platform or architecture, pushing out things that can't be done in any other way into gcc-proper.

Though things have been pretty stable since October... not for long though as I plan to do another huge face lift in the new year. :-)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 18 December 2012 22:23, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> pushing out things that can't be done in any other way into gcc-proper.


One example of this are version identifiers specific to target architectures.  Where I suggested each target D is ported to should define it's own TARGET_CPU_D_BUILTINS macro, and each platform it's TARGET_OS_D_BUILTINS macro.  Both of which are defined outside of gdc.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 2012-11-18 21:12, Johannes Pfau <nospam@example.com> wrote:

> Am Tue, 18 Dec 2012 20:06:16 +0100
> schrieb "jerro" <a@a.com>:
>
>> You could also define them in compiler
>> specific modules as has already been discussed in this thread,
>> but then code that used them without full names (including the
>> module name) would break if an attribute with the same name was
>> added to the language.
>
> We could do this: Language attributes (@property, @safe, ...) are
> defined in "lang.attributes" (or choose some other name). Then add a
> public import of lang.attributes to object.di.
>
> GDC attributes are defined in gdc.attributes (or any other name). We
> could add an public import to object.di for gdc. Or we don't, that's a
> different discussion.
>
> The result is that you can always resolve conflicting attributes:
> If gdc introduces @noreturn in gdc.attributes you can now do this:
> ------------------------
> //(Optional if gdc.attributes is imported in
> //object.di)
> import gdc.attributes;
>
> @noreturn void foo{}
> ------------------------
>
> If a @noreturn attribute is now added to lang.attributes, the compiler
> will refuse to compile the above code as it's ambiguous. But you can
> now do this:
>
> @lang.attributes.noreturn void foo{}
> or
> @gdc.attributes.noreturn void foo{}
>
> or
> import gdc = gdc.attributes;
> @gdc.noreturn void foo{}

This certainly sounds like the sanest solution.

-- 
Simen

On 18 December 2012 20:11, Johannes Pfau <nospam@example.com> wrote:

> Am Tue, 18 Dec 2012 20:06:16 +0100
> schrieb "jerro" <a@a.com>:
>
> > You could also define them in compiler
> > specific modules as has already been discussed in this thread,
> > but then code that used them without full names (including the
> > module name) would break if an attribute with the same name was
> > added to the language.
>
> We could do this: Language attributes (@property, @safe, ...) are
> defined in "lang.attributes" (or choose some other name). Then add a
> public import of lang.attributes to object.di.
>
> GDC attributes are defined in gdc.attributes (or any other name). We could add an public import to object.di for gdc. Or we don't, that's a different discussion.
>
> The result is that you can always resolve conflicting attributes: If gdc introduces @noreturn in gdc.attributes you can now do this:
> ------------------------
> //(Optional if gdc.attributes is imported in
> //object.di)
> import gdc.attributes;
>
> @noreturn void foo{}
> ------------------------
>
> If a @noreturn attribute is now added to lang.attributes, the compiler will refuse to compile the above code as it's ambiguous. But you can now do this:
>
> @lang.attributes.noreturn void foo{}
> or
> @gdc.attributes.noreturn void foo{}
>
> or
> import gdc = gdc.attributes;
> @gdc.noreturn void foo{}
>


Someone recently mentioned @gccAttribute("foo", "bar");  as a prototype.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Am Fri, 28 Dec 2012 13:28:51 +0000
schrieb Iain Buclaw <ibuclaw@ubuntu.com>:
> 
> 
> Someone recently mentioned @gccAttribute("foo", "bar");  as a
> prototype.
> 
> 

That looks like a good solution. And it should be much simpler to implement than my proposal.