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