www.digitalmars.com         C & C++   DMDScript  

D.gnu - Current GDC experience and questions

reply Artur Skawina <art.08.09 gmail.com> writes:
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,
Mar 08 2013
parent reply "jerro" <a a.com> writes:
 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.
Mar 08 2013
next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
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
Mar 08 2013
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
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';
Mar 08 2013
parent reply Johannes Pfau <nospam example.com> writes:
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)
Mar 08 2013
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
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';
Mar 08 2013
prev sibling next sibling parent reply Johannes Pfau <nospam example.com> writes:
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?
Mar 08 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
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';
Mar 08 2013
parent "Timo Sintonen" <t.sintonen luukku.com> writes:
On Friday, 8 March 2013 at 18:16:18 UTC, Iain Buclaw wrote:

 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)
I think that in pc programs there should be no need for attributes but in embedded systems they are useful. I hope that we will get the freestanding option soon to make the code smaller and simpler. I find need for inlining attributes in interrupts and callbacks. For example: Uart1_interrupt() { serial_int_handler(uart1); } Uart2_interrupt() { serial_int_handler(uart2); } ... Here I need to control whether I want to duplicate the handler code because of speed or do I want to save memory by not inlining. Target options are useful when the same program is used in different processor families. The general code should be targeted to run in all versions of hardware and product specific code may be targeted to the actual processor used. For example: in the products I make, the battery powered versions use Cortex-m3 and mains powered versions use Cortex-m4 I have also found an use for optimize: a while ago I pointed out that global variables are optimized out in loops. Now I have to compile separately those files that access volatile registers, with no optimization. The other files I compile with optimizations.
Mar 08 2013
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
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
Mar 08 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 8 March 2013 18:19, Artur Skawina <art.08.09 gmail.com> wrote:

 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".
inline and always_inline are two subtly different beasts. But altogether I don't think either make any guarantees of an inline occuring (although always_inline is a little more relaxed about it all). Some things are marked as always_inline anyway by gdc: struct/class methods, lambdas and delegate literals. Though it is probably known that this only worked within the module being compiled. Cross-module inlining is not there yet.
 - 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.
Infact, strongly pure functions (where all parameters are immutable) are indeed marked as C "pure" by gdc if the functions are also nothrow. Whether this might cause some bad behaviour I'm yet to run into or find a case of...
 - 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
And I'd rather not want to spend time fixing it. The code that handles these attributes are a bit bulky, and require a bit of questionable copying from the c-family frontend. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Mar 08 2013
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 03/08/13 19:38, Iain Buclaw wrote:
 On 8 March 2013 18:19, Artur Skawina <art.08.09 gmail.com
<mailto:art.08.09 gmail.com>> wrote:
 
     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".
 
 
 inline and always_inline are two subtly different beasts.  But altogether I
don't think either make any guarantees of an inline occuring (although
always_inline is a little more relaxed about it all).
 
 Some things are marked as always_inline anyway by gdc:  struct/class methods,
lambdas and delegate literals.  Though it is probably known that this only
worked within the module being compiled.  Cross-module inlining is not there
yet.
Really "always_inline"? IIRC gcc throws an error if can't inline a function marked with that one - in fact that was one reason why i had to use flatten instead of marking everything always_inline - to avoid these errors. Things like methods should not be marked as such, as they can be huge; the inlining heuristics should be able to handle them.
     > - 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.
 
 
 Infact, strongly pure functions (where all parameters are immutable) are
indeed marked as C "pure" by gdc if the functions are also nothrow.  Whether
this might cause some bad behaviour I'm yet to run into or find a case of...
It's good to have a way to mark pure functions as such, D's pure doesn't help when the args aren't immutable, but the code is pure /logically/.
     > - 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
 
 
 And I'd rather not want to spend time fixing it.  The code that handles these
attributes are a bit bulky, and require a bit of questionable copying from the
c-family frontend.
Oh, I'm just mentioning this because marking some code to be compiled for one cpu, and having other unrelated code be mistakenly built for that cpu can result in nasty bugs. These attributes are useful, but there are easy workarounds, like compiling the code separately, so supporting them can indeed be very low prio. artur
Mar 08 2013
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 8 March 2013 19:00, Artur Skawina <art.08.09 gmail.com> wrote:

 On 03/08/13 19:38, Iain Buclaw wrote:
 On 8 March 2013 18:19, Artur Skawina <art.08.09 gmail.com <mailto:
art.08.09 gmail.com>> wrote:
     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".


 inline and always_inline are two subtly different beasts.  But
altogether I don't think either make any guarantees of an inline occuring (although always_inline is a little more relaxed about it all).
 Some things are marked as always_inline anyway by gdc:  struct/class
methods, lambdas and delegate literals. Though it is probably known that this only worked within the module being compiled. Cross-module inlining is not there yet. Really "always_inline"? IIRC gcc throws an error if can't inline a function marked with that one - in fact that was one reason why i had to use flatten instead of marking everything always_inline - to avoid these errors. Things like methods should not be marked as such, as they can be huge; the inlining heuristics should be able to handle them.
     > - 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.
 Infact, strongly pure functions (where all parameters are immutable) are
indeed marked as C "pure" by gdc if the functions are also nothrow. Whether this might cause some bad behaviour I'm yet to run into or find a case of... It's good to have a way to mark pure functions as such, D's pure doesn't help when the args aren't immutable, but the code is pure /logically/.
If the code is pure logically, it may be const folded away by the GCC backend given correct circumstances. However what we don't want to happen is for it to accidentally optimise away a call that may alter an internal state that affects runtime behaviour. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Mar 08 2013
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
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
Mar 08 2013