I've been using "gdc (GCC) 4.6.3 20120106 (gdc 0.31 - r748:ab99d67f04c2, dmd 2.057)" as my only D compiler for the last months, and it's been doing great, almost everything including LTO works. There have been a few ices/crashes, but mostly with invalid code or looking front-end related (didn't want to report them until the 4.8 merge is done). But still using that old compiler means working with a different language, so I finally decided to try out the current GDC versions, and started with the 4.7 branch.

First difference that i noticed - the frontend version no longer shows up in '--version' output - is there a way to retrieve it, preferably as a git hash?

Then the very first app that i tried to compile didn't - failed with an LTO related
error. I need LTO for that one, at least i used to with my old compiler.
Decided to try the head (4.8) based tree - with similar results; apparently LTO no
longer works at all, even for trivial 'void main(){}' programs. At least the error,
which appears to be the same, got a bit better reported on that branch [1].
One difference between my old working setup and the new ones is that the former is
not a multilib one; haven't tried a new build w/o multilibs yet.

Then I wanted to try to build some other programs using master, w/o LTO. Didn't
really work - the problem is that gcc-pragma-attributes are now /errors/. So I'd
have to modify the sources just to build with the newer compiler - which isn't a
big problem; the fact that I can't then easily go back to using an older one is.
I tried modifying some trivial sources, which were using only
'pragma(attribute, noinline)', but couldn't get them to work; the compiler keeps
complaining, 'cc1d: error: unknown attribute noinline'.
Is 'import gcc.attribute; @attribute("noinline") void f() {}' supposed to work?

artur

[1]
$ gdc -flto main.d -o main
lto1: internal compiler error: in streamer_get_pickled_tree, at tree-streamer-in.c:1050
0x6a18a7 streamer_get_pickled_tree(lto_input_block*, data_in*) [clone .part.7]
	../../gcc/tree-streamer-in.c:1049
0x6a18a7 streamer_get_pickled_tree(lto_input_block*, data_in*)
	../../gcc/tree-streamer-in.c:1039
0xd68ffa lto_input_tree(lto_input_block*, data_in*)
	../../gcc/lto-streamer-in.c:1065
0x80e22f lto_input_ts_type_common_tree_pointers
	../../gcc/tree-streamer-in.c:768
0x80e22f streamer_read_tree_body(lto_input_block*, data_in*, tree_node*)
	../../gcc/tree-streamer-in.c:997
0xd68ed8 lto_read_tree
	../../gcc/lto-streamer-in.c:1015
0xd68ed8 lto_input_tree(lto_input_block*, data_in*)
	../../gcc/lto-streamer-in.c:1082
0x80da59 streamer_read_tree_body(lto_input_block*, data_in*, tree_node*)
	../../gcc/tree-streamer-in.c:599
0xd68ed8 lto_read_tree
	../../gcc/lto-streamer-in.c:1015
0xd68ed8 lto_input_tree(lto_input_block*, data_in*)
	../../gcc/lto-streamer-in.c:1082
0xb2504f lto_read_decls(lto_file_decl_data*, void const*, vec<ld_plugin_symbol_resolution, va_heap, vl_ptr>) [clone .12623]
	../../gcc/lto/lto.c:2086
0xa570bb lto_file_finalize(lto_file_decl_data*, lto_file_struct*) [clone .isra.48]
	../../gcc/lto/lto.c:2339
0xa570bb lto_create_files_from_ids
	../../gcc/lto/lto.c:2349
0xa570bb lto_file_read
	../../gcc/lto/lto.c:2389
0xa570bb read_cgraph_and_symbols
	../../gcc/lto/lto.c:2964
0xa570bb lto_main()
	../../gcc/lto/lto.c:3375
Please submit a full bug report,

> I tried modifying some trivial sources, which were using only
> 'pragma(attribute, noinline)', but couldn't get them to work; the compiler keeps
> complaining, 'cc1d: error: unknown attribute noinline'.
> Is 'import gcc.attribute; @attribute("noinline") void f() {}' supposed to work?

It isn't. When the syntax was changed to @attribute, all the gcc attributes were disabled. If I understood correctly, the reason was that those were only meant for internal GDC use. AFAIK, noinline was removed even before that.

Iain did say something about adding supported attributes one by one as they are needed. So I guess you need to talk to him about adding noinline.

On 03/08/13 13:40, jerro wrote:
>> I tried modifying some trivial sources, which were using only
>> 'pragma(attribute, noinline)', but couldn't get them to work; the compiler keeps
>> complaining, 'cc1d: error: unknown attribute noinline'.
>> Is 'import gcc.attribute; @attribute("noinline") void f() {}' supposed to work?
> 
> It isn't. When the syntax was changed to @attribute, all the gcc attributes were disabled. If I understood correctly, the reason was that those were only meant for internal GDC use. AFAIK, noinline was removed even before that.
> 
> Iain did say something about adding supported attributes one by one as they are needed. So I guess you need to talk to him about adding noinline.

I need them all. If D is to be an alternative to C/C++ it must support everything
that's already available for those languages.
In the specific case i tested with i need @flatten to get decent performance, and
@noinline to have compile times measured in minutes and not hours (literally, as
@flatten can otherwise result in practically infinite recursive inlining).

artur

On 8 March 2013 14:36, Artur Skawina <art.08.09@gmail.com> wrote:

> On 03/08/13 13:40, jerro wrote:
> >> I tried modifying some trivial sources, which were using only 'pragma(attribute, noinline)', but couldn't get them to work; the
> compiler keeps
> >> complaining, 'cc1d: error: unknown attribute noinline'.
> >> Is 'import gcc.attribute; @attribute("noinline") void f() {}' supposed
> to work?
> >
> > It isn't. When the syntax was changed to @attribute, all the gcc
> attributes were disabled. If I understood correctly, the reason was that those were only meant for internal GDC use. AFAIK, noinline was removed even before that.
> >
> > Iain did say something about adding supported attributes one by one as
> they are needed. So I guess you need to talk to him about adding noinline.
>
> I need them all. If D is to be an alternative to C/C++ it must support
> everything
> that's already available for those languages.
>

Yet not all attributes that GCC offers actually make sense to have in D. We certainly need to have a review of each one and discuss what is most important to have.  Also defining our own unique attributes along the way. :o)



> In the specific case i tested with i need @flatten to get decent
> performance, and
> @noinline to have compile times measured in minutes and not hours
> (literally, as
> @flatten can otherwise result in practically infinite recursive inlining).
>
> artur
>


Raise a bug report to get those added so no one forgets.


-- 
Iain Buclaw

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

Am Fri, 8 Mar 2013 15:18:53 +0000
schrieb Iain Buclaw <ibuclaw@ubuntu.com>:


> Yet not all attributes that GCC offers actually make sense to have in D. We certainly need to have a review of each one and discuss what is most important to have.  Also defining our own unique attributes along the way. :o)
> 

To get the discussion started: I think we could adopt these LDC pragmas:

 LDC_no_typeinfo
 LDC_no_moduleinfo

Maybe nice to have:
LDC_global_crt_ctor and LDC_global_crt_dtor
(is this the same as
__attribute__((constructor))/__attribute__((destructor))) ?

Not needed in GDC?
 LDC_allow_inline
 (allow inlining a function continaining inline asm. not necessary for
  gdc extended inline asm)

On 8 March 2013 16:11, Johannes Pfau <nospam@example.com> wrote:

> Am Fri, 8 Mar 2013 15:18:53 +0000
> schrieb Iain Buclaw <ibuclaw@ubuntu.com>:
>
>
> > Yet not all attributes that GCC offers actually make sense to have in D. We certainly need to have a review of each one and discuss what is most important to have.  Also defining our own unique attributes along the way. :o)
> >
>
> To get the discussion started: I think we could adopt these LDC pragmas:
>
>  LDC_no_typeinfo
>  LDC_no_moduleinfo
>
>
That could come under the jurisdiction of -ffree-standing  (something that could be the equivalent of dmd's -betterC).


> Maybe nice to have:
> LDC_global_crt_ctor and LDC_global_crt_dtor
> (is this the same as
> __attribute__((constructor))/__attribute__((destructor))) ?
>
>
Indeed.  This is different to this() and static this()  as these get called
when the object gets loaded into C runtime, rather than delayed until D
runtime initialises.


> Not needed in GDC?
>  LDC_allow_inline
>  (allow inlining a function continaining inline asm. not necessary for
>   gdc extended inline asm)
>

Also not needed:
- aligned:  because D has align() for that.
- gnu_inline, artificial:  because D has no inline keyword, nor has need
for one.
- error, warning:  There are better alternatives that can be implemented in
D.
- deprecated:  There is a deprecated keyword for that.
- no_split_stack:  Infact, supporting -fsplit-stack is a generally bad idea
anyway and requires a new GC.
- nothrow:  D has nothrow keyword
- pure, const:  Although D has pure keyword that does not necessarily
follow same as C semantics, I don't think the inclusion of these are
beneficial at all.
- returns_twice:  Unless of course I'm missing the point of something here.
:o)
- optimise, target:  I'm sure the guy who implemented these meant well, but
I fail to see the point as to why you'd want such an attribute.
- used, unused:  ......


Regards
-- 
Iain Buclaw

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

Am Fri, 8 Mar 2013 17:11:41 +0100
schrieb Johannes Pfau <nospam@example.com>:

> Am Fri, 8 Mar 2013 15:18:53 +0000
> schrieb Iain Buclaw <ibuclaw@ubuntu.com>:
> 
> 
> > Yet not all attributes that GCC offers actually make sense to have in D. We certainly need to have a review of each one and discuss what is most important to have.  Also defining our own unique attributes along the way. :o)
> > 
> 
> To get the discussion started: I think we could adopt these LDC pragmas:
> 
>  LDC_no_typeinfo
>  LDC_no_moduleinfo

It seems no_moduleinfo can't be implemented this way as module declarations can't be annotated with UDAs.

Can attributes like LDC_no_typeinfo which shouldn't affect the backend at all actually be implemented with the current mechanism?

On 03/08/13 16:18, Iain Buclaw wrote:
> On 8 March 2013 14:36, Artur Skawina <art.08.09@gmail.com <mailto:art.08.09@gmail.com>> wrote:
> 
>     On 03/08/13 13:40, jerro wrote:
>     >> I tried modifying some trivial sources, which were using only
>     >> 'pragma(attribute, noinline)', but couldn't get them to work; the compiler keeps
>     >> complaining, 'cc1d: error: unknown attribute noinline'.
>     >> Is 'import gcc.attribute; @attribute("noinline") void f() {}' supposed to work?
>     >
>     > It isn't. When the syntax was changed to @attribute, all the gcc attributes were disabled. If I understood correctly, the reason was that those were only meant for internal GDC use. AFAIK, noinline was removed even before that.
>     >
>     > Iain did say something about adding supported attributes one by one as they are needed. So I guess you need to talk to him about adding noinline.
> 
>     I need them all. If D is to be an alternative to C/C++ it must support everything
>     that's already available for those languages.
> 
> 
> Yet not all attributes that GCC offers actually make sense to have in D.  We certainly need to have a review of each one and discuss what is most important to have.  Also defining our own unique attributes along the way.  :o)

A missing attribute is a blocker. For example I've since tried to get my program to build using the gcc47 branch, just to see how much performance is lost w/o LTO. Only to see pages of "'flatten|always_inline|noinline' attribute directive ignored" warnings... The resulting binary is *three times slower* and 50% larger than one built with the old compiler (caused mostly by the lack of inlining, the LTO impact should be much smaller). So I can't really upgrade.


>     In the specific case i tested with i need @flatten to get decent performance, and
>     @noinline to have compile times measured in minutes and not hours (literally, as
>     @flatten can otherwise result in practically infinite recursive inlining).
> 
>     artur
> 
> 
> 
> Raise a bug report to get those added so no one forgets.

Done. I should have probably also mentioned "always_inline", which isn't as critical, but still very useful.

artur

On 8 March 2013 18:06, Johannes Pfau <nospam@example.com> wrote:

> Am Fri, 8 Mar 2013 17:11:41 +0100
> schrieb Johannes Pfau <nospam@example.com>:
>
> > Am Fri, 8 Mar 2013 15:18:53 +0000
> > schrieb Iain Buclaw <ibuclaw@ubuntu.com>:
> >
> >
> > > Yet not all attributes that GCC offers actually make sense to have in D. We certainly need to have a review of each one and discuss what is most important to have.  Also defining our own unique attributes along the way. :o)
> > >
> >
> > To get the discussion started: I think we could adopt these LDC pragmas:
> >
> >  LDC_no_typeinfo
> >  LDC_no_moduleinfo
>
> It seems no_moduleinfo can't be implemented this way as module declarations can't be annotated with UDAs.
>
> Can attributes like LDC_no_typeinfo which shouldn't affect the backend at all actually be implemented with the current mechanism?
>

I'd say yes on both accounts.

no_moduleinfo  ->  Don't call Module::genmoduleinfo() in ::genobjfile.
no_typeinfo  ->  Maybe don't generate anything in
TypeInfoDeclaration::toSymbol().  But will require investigating on that
part.

Again, both can be instead handled by a compiler switch.


Regards
-- 
Iain Buclaw

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

On 03/08/13 18:54, Iain Buclaw wrote:
> Also not needed:
> - aligned:  because D has align() for that.

D's align wasn't nearly enough last time i looked. (There were changes to it since, but as I can't upgrade, haven't looked at the details)

> - gnu_inline, artificial:  because D has no inline keyword, nor has need for one.

always_inline is needed, the heuristics are not always enough. Of course it should map to just "inline".


> - pure, const:  Although D has pure keyword that does not necessarily follow same as C semantics, I don't think the inclusion of these are beneficial at all.

"const" may not be needed. "pure" is useful /exactly/ because of the D semantics.

> - optimise, target:  I'm sure the guy who implemented these meant well, but I fail to see the point as to why you'd want such an attribute.

They are useful. And it reminds me that last time i looked, GDC handled "target", "tune"
etc wrongly: http://forum.dlang.org/post/mailman.1.1325716211.16222.digitalmars-d@puremagic.com

artur