Thread overview | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
March 08, 2013 Current GDC experience and questions | ||||
---|---|---|---|---|
| ||||
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, |
March 08, 2013 Re: Current GDC experience and questions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Artur Skawina | > 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.
|
March 08, 2013 Re: Current GDC experience and questions | ||||
---|---|---|---|---|
| ||||
Posted in reply to jerro | 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
|
March 08, 2013 Re: Current GDC experience and questions | ||||
---|---|---|---|---|
| ||||
Attachments:
| 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'; |
March 08, 2013 Re: Current GDC experience and questions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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) |
March 08, 2013 Re: Current GDC experience and questions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau Attachments:
| 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'; |
March 08, 2013 Re: Current GDC experience and questions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | 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?
|
March 08, 2013 Re: Current GDC experience and questions | ||||
---|---|---|---|---|
| ||||
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 |
March 08, 2013 Re: Current GDC experience and questions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau Attachments:
| 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'; |
March 08, 2013 Re: Current GDC experience and questions | ||||
---|---|---|---|---|
| ||||
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 |
Copyright © 1999-2021 by the D Language Foundation