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
next sibling 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 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
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 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 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 Iain Buclaw <ibuclaw ubuntu.com> writes:
--14dae934044552b0e404d76b578f
Content-Type: text/plain; charset=ISO-8859-1

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


 complaining, 'cc1d: error: unknown attribute noinline'.
 Is 'import gcc.attribute;  attribute("noinline") void f() {}' supposed


 It isn't. When the syntax was changed to  attribute, all the gcc

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

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'; --14dae934044552b0e404d76b578f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 8= March 2013 14:36, Artur Skawina <span dir=3D"ltr">&lt;<a href=3D"mailto:ar= t.08.09 gmail.com" target=3D"_blank">art.08.09 gmail.com</a>&gt;</span> wro= te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-= left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On 03/08/13 13:40, jerro wrote:<br> &gt;&gt; I tried modifying some trivial sources, which were using only<br> &gt;&gt; &#39;pragma(attribute, noinline)&#39;, but couldn&#39;t get them t= o work; the compiler keeps<br> &gt;&gt; complaining, &#39;cc1d: error: unknown attribute noinline&#39;.<br=

d f() {}&#39; supposed to work?<br> &gt;<br> &gt; It isn&#39;t. When the syntax was changed to attribute, all the gcc a= ttributes were disabled. If I understood correctly, the reason was that tho= se were only meant for internal GDC use. AFAIK, noinline was removed even b= efore that.<br> &gt;<br> &gt; 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.= <br> <br> </div></div>I need them all. If D is to be an alternative to C/C++ it must = support everything<br> that&#39;s already available for those languages.<br></blockquote><div><br>= </div><div>Yet not all attributes that GCC offers actually make sense to ha= ve in D.=A0 We certainly need to have a review of each one and discuss what= is most important to have.=A0 Also defining our own unique attributes alon= g the way.=A0 :o)<br> </div><div><br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> In the specific case i tested with i need flatten to get decent performanc= e, and<br> noinline to have compile times measured in minutes and not hours (literall= y, as<br> flatten can otherwise result in practically infinite recursive inlining).<= br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> artur<br> </font></span></blockquote></div><br><br></div><div class=3D"gmail_extra">R= aise a bug report to get those added so no one forgets.<br></div><div class= =3D"gmail_extra"><br clear=3D"all"><br>-- <br>Iain Buclaw<br><br>*(p &lt; e= ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;; </div></div> --14dae934044552b0e404d76b578f--
Mar 08 2013
prev sibling next sibling parent 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
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7b6da1d2558ff904d76d8240
Content-Type: text/plain; charset=ISO-8859-1

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

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))) ?

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'; --047d7b6da1d2558ff904d76d8240 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 8= March 2013 16:11, Johannes Pfau <span dir=3D"ltr">&lt;<a href=3D"mailto:no= spam example.com" target=3D"_blank">nospam example.com</a>&gt;</span> wrote= :<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le= ft:1px #ccc solid;padding-left:1ex"> Am Fri, 8 Mar 2013 15:18:53 +0000<br> schrieb Iain Buclaw &lt;<a href=3D"mailto:ibuclaw ubuntu.com">ibuclaw ubunt= u.com</a>&gt;:<br> <div class=3D"im"><br> <br> &gt; Yet not all attributes that GCC offers actually make sense to have in<= br> &gt; D. We certainly need to have a review of each one and discuss what is<= br> &gt; most important to have. =A0Also defining our own unique attributes<br> &gt; along the way. :o)<br> &gt;<br> <br> </div>To get the discussion started: I think we could adopt these LDC<br> pragmas:<br> <br> =A0LDC_no_typeinfo<br> =A0LDC_no_moduleinfo<br> <br></blockquote><div><br></div><div>That could come under the jurisdiction= of -ffree-standing=A0 (something that could be the equivalent of dmd&#39;s= -betterC).<br></div><div>=A0</div><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Maybe nice to have:<br> LDC_global_crt_ctor and LDC_global_crt_dtor<br> (is this the same as<br> __attribute__((constructor))/__attribute__((destructor))) ?<br> <br></blockquote><div><br></div><div>Indeed.=A0 This is different to this()= and static this()=A0 as these get called when the object gets loaded into = C runtime, rather than delayed until D runtime initialises.<br></div><div> =A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde= r-left:1px #ccc solid;padding-left:1ex"> Not needed in GDC?<br> =A0LDC_allow_inline<br> =A0(allow inlining a function continaining inline asm. not necessary for<br=

</blockquote></div><br></div><div class=3D"gmail_extra">Also not needed:<br=
</div><div class=3D"gmail_extra">- aligned:=A0 because D has align() for t=

se D has no inline keyword, nor has need for one.<br> </div><div class=3D"gmail_extra">- error, warning:=A0 There are better alte= rnatives that can be implemented in D.<br></div><div class=3D"gmail_extra">= - deprecated:=A0 There is a deprecated keyword for that.<br></div><div clas= s=3D"gmail_extra"> - no_split_stack:=A0 Infact, supporting -fsplit-stack is a generally bad id= ea anyway and requires a new GC.<br></div><div class=3D"gmail_extra">- noth= row:=A0 D has nothrow keyword<br></div><div class=3D"gmail_extra">- pure, c= onst:=A0 Although D has pure keyword that does not necessarily follow same = as C semantics, I don&#39;t think the inclusion of these are beneficial at = all.<br> </div><div class=3D"gmail_extra">- returns_twice:=A0 Unless of course I&#39= ;m missing the point of something here. :o)<br></div><div class=3D"gmail_ex= tra">- optimise, target:=A0 I&#39;m sure the guy who implemented these mean= t well, but I fail to see the point as to why you&#39;d want such an attrib= ute.<br> </div><div class=3D"gmail_extra">- used, unused:=A0 ......<br clear=3D"all"=
</div><div class=3D"gmail_extra"><br><br></div><div class=3D"gmail_extra">=

lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;; </div></div> --047d7b6da1d2558ff904d76d8240--
Mar 08 2013
prev sibling next sibling parent 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
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--20cf3074b7cc0b9a2d04d76dd152
Content-Type: text/plain; charset=ISO-8859-1

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'; --20cf3074b7cc0b9a2d04d76dd152 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 8= March 2013 18:06, Johannes Pfau <span dir=3D"ltr">&lt;<a href=3D"mailto:no= spam example.com" target=3D"_blank">nospam example.com</a>&gt;</span> wrote= :<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le= ft:1px #ccc solid;padding-left:1ex"> Am Fri, 8 Mar 2013 17:11:41 +0100<br> schrieb Johannes Pfau &lt;<a href=3D"mailto:nospam example.com">nospam exam= ple.com</a>&gt;:<br> <div class=3D"im"><br> &gt; Am Fri, 8 Mar 2013 15:18:53 +0000<br> &gt; schrieb Iain Buclaw &lt;<a href=3D"mailto:ibuclaw ubuntu.com">ibuclaw = ubuntu.com</a>&gt;:<br> &gt;<br> &gt;<br> &gt; &gt; Yet not all attributes that GCC offers actually make sense to hav= e<br> &gt; &gt; in D. We certainly need to have a review of each one and discuss<= br> &gt; &gt; what is most important to have. =A0Also defining our own unique<b= r> &gt; &gt; attributes along the way. :o)<br> &gt; &gt;<br> &gt;<br> &gt; To get the discussion started: I think we could adopt these LDC<br> &gt; pragmas:<br> &gt;<br> &gt; =A0LDC_no_typeinfo<br> &gt; =A0LDC_no_moduleinfo<br> <br> </div>It seems no_moduleinfo can&#39;t be implemented this way as module<br=

<br> Can attributes like LDC_no_typeinfo which shouldn&#39;t affect the backend<= br> at all actually be implemented with the current mechanism?<br> </blockquote></div><br></div><div class=3D"gmail_extra">I&#39;d say yes on = both accounts.<br><br></div><div class=3D"gmail_extra">no_moduleinfo=A0 -&g= t;=A0 Don&#39;t call Module::genmoduleinfo() in ::genobjfile.<br></div><div= class=3D"gmail_extra"> no_typeinfo=A0 -&gt;=A0 Maybe don&#39;t generate anything in TypeInfoDeclar= ation::toSymbol().=A0 But will require investigating on that part.<br clear= =3D"all"></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ext= ra">Again, both can be instead handled by a compiler switch.<br> </div><div class=3D"gmail_extra"><br><br></div><div class=3D"gmail_extra">R= egards<br></div><div class=3D"gmail_extra">-- <br>Iain Buclaw<br><br>*(p &l= t; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;; </div></div> --20cf3074b7cc0b9a2d04d76dd152--
Mar 08 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7b6da1d2fc705304d76e21b7
Content-Type: text/plain; charset=ISO-8859-1

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

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

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

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

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,

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

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'; --047d7b6da1d2fc705304d76e21b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 8= March 2013 18:19, Artur Skawina <span dir=3D"ltr">&lt;<a href=3D"mailto:ar= t.08.09 gmail.com" target=3D"_blank">art.08.09 gmail.com</a>&gt;</span> wro= te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-= left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 03/08/13 18:54, Iain Buclaw wrote:<br> &gt; Also not needed:<br> &gt; - aligned: =A0because D has align() for that.<br> <br> </div>D&#39;s align wasn&#39;t nearly enough last time i looked. (There wer= e changes to<br> it since, but as I can&#39;t upgrade, haven&#39;t looked at the details)<br=

&gt; - gnu_inline, artificial: =A0because D has no inline keyword, nor has = need for one.<br> <br> </div>always_inline is needed, the heuristics are not always enough. Of cou= rse it<br> should map to just &quot;inline&quot;.<br> <div class=3D"im"><br></div></blockquote><div><br></div><div>inline and alw= ays_inline are two subtly different beasts.=A0 But altogether I don&#39;t t= hink either make any guarantees of an inline occuring (although always_inli= ne is a little more relaxed about it all).<br> <br></div><div>Some things are marked as always_inline anyway by gdc:=A0 st= ruct/class methods, lambdas and delegate literals.=A0 Though it is probably= known that this only worked within the module being compiled.=A0 Cross-mod= ule inlining is not there yet.<br> </div><div><br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"> <br> &gt; - pure, const: =A0Although D has pure keyword that does not necessaril= y follow same as C semantics, I don&#39;t think the inclusion of these are = beneficial at all.<br> <br> </div>&quot;const&quot; may not be needed. &quot;pure&quot; is useful /exac= tly/ because of the D semantics.<br> <div class=3D"im"><br></div></blockquote><div><br></div><div>Infact, strong= ly pure functions (where all parameters are immutable) are indeed marked as= C &quot;pure&quot; by gdc if the functions are also nothrow.=A0 Whether th= is might cause some bad behaviour I&#39;m yet to run into or find a case of= ...<br> <br><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im= "> &gt; - optimise, target: =A0I&#39;m sure the guy who implemented these mean= t well, but I fail to see the point as to why you&#39;d want such an attrib= ute.<br> <br> </div>They are useful. And it reminds me that last time i looked, GDC handl= ed &quot;target&quot;, &quot;tune&quot;<br> etc wrongly: <a href=3D"http://forum.dlang.org/post/mailman.1.1325716211.16= 222.digitalmars-d puremagic.com" target=3D"_blank">http://forum.dlang.org/p= ost/mailman.1.1325716211.16222.digitalmars-d puremagic.com</a><br> <span class=3D"HOEnZb"></span><br></blockquote></div><br></div><div class= =3D"gmail_extra">And I&#39;d rather not want to spend time fixing it.=A0 Th= e code that handles these attributes are a bit bulky, and require a bit of = questionable copying from the c-family frontend.<br> </div><div class=3D"gmail_extra"><br clear=3D"all"><br></div><div class=3D"= gmail_extra">Regards<br></div><div class=3D"gmail_extra">-- <br>Iain Buclaw= <br><br>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;; </div></div> --047d7b6da1d2fc705304d76e21b7--
Mar 08 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7b6d9a62b5c96304d76fddde
Content-Type: text/plain; charset=ISO-8859-1

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:

     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

     it since, but as I can't upgrade, haven't looked at the details)

     > - gnu_inline, artificial:  because D has no inline keyword, nor

     always_inline is needed, the heuristics are not always enough. Of

     should map to just "inline".


 inline and always_inline are two subtly different beasts.  But

(although always_inline is a little more relaxed about it all).
 Some things are marked as always_inline anyway by gdc:  struct/class

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

these are beneficial at all.
     "const" may not be needed. "pure" is useful /exactly/ because of the

 Infact, strongly pure functions (where all parameters are immutable) are

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/.

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'; --047d7b6d9a62b5c96304d76fddde Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 8= March 2013 19:00, Artur Skawina <span dir=3D"ltr">&lt;<a href=3D"mailto:ar= t.08.09 gmail.com" target=3D"_blank">art.08.09 gmail.com</a>&gt;</span> wro= te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-= left:1px #ccc solid;padding-left:1ex"> On 03/08/13 19:38, Iain Buclaw wrote:<br> <div class=3D"im">&gt; On 8 March 2013 18:19, Artur Skawina &lt;<a href=3D"= mailto:art.08.09 gmail.com">art.08.09 gmail.com</a> &lt;mailto:<a href=3D"m= ailto:art.08.09 gmail.com">art.08.09 gmail.com</a>&gt;&gt; wrote:<br> &gt;<br> &gt; =A0 =A0 On 03/08/13 18:54, Iain Buclaw wrote:<br> &gt; =A0 =A0 &gt; Also not needed:<br> &gt; =A0 =A0 &gt; - aligned: =A0because D has align() for that.<br> &gt;<br> &gt; =A0 =A0 D&#39;s align wasn&#39;t nearly enough last time i looked. (Th= ere were changes to<br> &gt; =A0 =A0 it since, but as I can&#39;t upgrade, haven&#39;t looked at th= e details)<br> &gt;<br> &gt; =A0 =A0 &gt; - gnu_inline, artificial: =A0because D has no inline keyw= ord, nor has need for one.<br> &gt;<br> &gt; =A0 =A0 always_inline is needed, the heuristics are not always enough.= Of course it<br> &gt; =A0 =A0 should map to just &quot;inline&quot;.<br> &gt;<br> &gt;<br> &gt; inline and always_inline are two subtly different beasts. =A0But altog= ether I don&#39;t think either make any guarantees of an inline occuring (a= lthough always_inline is a little more relaxed about it all).<br> &gt;<br> &gt; Some things are marked as always_inline anyway by gdc: =A0struct/class= methods, lambdas and delegate literals. =A0Though it is probably known tha= t this only worked within the module being compiled. =A0Cross-module inlini= ng is not there yet.<br> <br> </div>Really &quot;always_inline&quot;? IIRC gcc throws an error if can&#39= ;t inline a function marked<br> with that one - in fact that was one reason why i had to use flatten inste= ad of<br> marking everything always_inline - to avoid these errors. Things like meth= ods<br> should not be marked as such, as they can be huge; the inlining heuristics = should<br> be able to handle them.<br> <div class=3D"im"><br> &gt; =A0 =A0 &gt; - pure, const: =A0Although D has pure keyword that does n= ot necessarily follow same as C semantics, I don&#39;t think the inclusion = of these are beneficial at all.<br> &gt;<br> &gt; =A0 =A0 &quot;const&quot; may not be needed. &quot;pure&quot; is usefu= l /exactly/ because of the D semantics.<br> &gt;<br> &gt;<br> &gt; Infact, strongly pure functions (where all parameters are immutable) a= re indeed marked as C &quot;pure&quot; by gdc if the functions are also not= hrow. =A0Whether this might cause some bad behaviour I&#39;m yet to run int= o or find a case of...<br> <br> </div>It&#39;s good to have a way to mark pure functions as such, D&#39;s p= ure doesn&#39;t help<br> when the args aren&#39;t immutable, but the code is pure /logically/.<br> <div class=3D"im"><br></div></blockquote><div><br></div><div>If the code is= pure logically, it may be const folded away by the GCC backend given corre= ct circumstances.=A0 However what we don&#39;t want to happen is for it to = accidentally optimise away a call that may alter an internal state that aff= ects runtime behaviour.<br> <br></div></div><br></div><div class=3D"gmail_extra">Regards<br></div><div = class=3D"gmail_extra">-- <br>Iain Buclaw<br><br>*(p &lt; e ? p++ : p) =3D (= c &amp; 0x0f) + &#39;0&#39;; </div></div> --047d7b6d9a62b5c96304d76fddde--
Mar 08 2013
prev sibling 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)




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