www.digitalmars.com         C & C++   DMDScript  

D.gnu - Build problem with latest git head

reply "Timo Sintonen" <t.sintonen luukku.com> writes:
I tried to build gdc with the latest heads of gcc and gdc
Lots of warnings along the build and the it stops here:

../../gcc/gcc/d/d-objfile.cc:2031:52: error: no matching function 
for call to 'symtab_node::symtab_node(cgraph_node*&)'
      symtab_add_to_same_comdat_group ((symtab_node) thunk_node,
                                                     ^
../../gcc/gcc/d/d-objfile.cc:2031:52: note: candidates are:
In file included from ../../gcc/gcc/d/d-system.h:47:0,
                  from ../../gcc/gcc/d/d-objfile.cc:18:
../../gcc/gcc/cgraph.h:44:3: note: symtab_node::symtab_node()
    symtab_node
    ^
../../gcc/gcc/cgraph.h:44:3: note:   candidate expects 0 
arguments, 1 provided
../../gcc/gcc/cgraph.h:44:3: note: symtab_node::symtab_node(const 
symtab_node&)
../../gcc/gcc/cgraph.h:44:3: note:   no known conversion for 
argument 1 from 'cgraph_node*' to 'const symtab_node&'

I want the latest version because I found there may be something 
wrong with inlining/optimization in my current arm compiler
Nov 04 2013
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 4 November 2013 10:15, Timo Sintonen <t.sintonen luukku.com> wrote:

 I tried to build gdc with the latest heads of gcc and gdc
 Lots of warnings along the build and the it stops here:

 ../../gcc/gcc/d/d-objfile.cc:2031:52: error: no matching function for
 call to 'symtab_node::symtab_node(cgraph_node*&)'
      symtab_add_to_same_comdat_group ((symtab_node) thunk_node,
                                                     ^
 ../../gcc/gcc/d/d-objfile.cc:2031:52: note: candidates are:
 In file included from ../../gcc/gcc/d/d-system.h:47:0,
                  from ../../gcc/gcc/d/d-objfile.cc:18:
 ../../gcc/gcc/cgraph.h:44:3: note: symtab_node::symtab_node()
    symtab_node
    ^
 ../../gcc/gcc/cgraph.h:44:3: note:   candidate expects 0 arguments, 1
 provided
 ../../gcc/gcc/cgraph.h:44:3: note: symtab_node::symtab_node(const
 symtab_node&)
 ../../gcc/gcc/cgraph.h:44:3: note:   no known conversion for argument 1
 from 'cgraph_node*' to 'const symtab_node&'

 I want the latest version because I found there may be something wrong
 with inlining/optimization in my current arm compiler
For the time being, use gcc-4.9-20131013.tar.bz2 snapshot - that is the last build I've done here (currently all my time is being used up on D 2.064). Feel free to send patches though (see this two line change here: http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=02774f2d493655713721ceef4ebfd7d0c8fb1d8d;hp=2043dfcce183f27ffe84a339da8b75aec20d3c33#patch21). :-) Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 04 2013
parent "Timo Sintonen" <t.sintonen luukku.com> writes:
On Monday, 4 November 2013 at 11:21:03 UTC, Iain Buclaw wrote:
 For the time being, use gcc-4.9-20131013.tar.bz2 snapshot - 
 that is the
 last build I've done here (currently all my time is being used 
 up on D
 2.064).

 Feel free to send patches though (see this two line change here:
 http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=02774f2d493655713721ceef4ebfd7d0c8fb1d8d;hp=2043dfcce183f27ffe84a339da8b75aec20d3c33#patch21).
 :-)
Ok, I check that later Meanwhile, a short description of my original problem I want to send characters of a string to uart These are member functions of my uart struct. The full source is https://bitbucket.org/timosi/minlibd/src/540e52150644719682f37900db1c298902e4d8c9/tools/main/uart.d?at=default // send a byte to the uart void send(int t) { while ((sr&0x80)==0) { } dr=t; } // send a string or char buffer void sendtext(const char[] p) { //if (!p) return; // null pointer test foreach (c;p) { //if (c==0) break; send (c); } } The problem is that send is inlined with -O2 such a way that the write is optimized outside of the foreach loop and only the last character is sent. This works with -O0. This is the asm r0 is this, r1 is p and r2 is length of p 151 00ac 10B4 push {r4} 152 00ae 83B0 sub sp, sp, #12 153 00b0 02AB add r3, sp, #8 154 00b2 03E90600 stmdb r3, {r1, r2} 155 00b6 009C ldr r4, [sp] 156 00b8 019A ldr r2, [sp, #4] 157 00ba 4CB1 cbz r4, .L11 zero length test 158 00bc 4368 ldr r3, [r0, #4] 159 00be 1444 add r4, r4, r2 At this point r4 = end address r2 = p Foreach begins here 160 .L13: 161 00c0 12F8011B ldrb r1, [r2], #1 get c 162 .L15: First part of send here 163 00c4 0368 ldr r3, [r0] status reg test 164 00c6 1B06 lsls r3, r3, #24 works now! 165 00c8 FCD5 bpl .L15 166 00ca A242 cmp r2, r4 Here in the middle 167 00cc F8D1 bne .L13 the test for end of the loop 168 00ce 4160 str r1, [r0, #4] Write (dr=t) is here, 169 .L11: AFTER the loop 170 00d0 03B0 add sp, sp, #12 171 172 00d2 5DF8044B ldr r4, [sp], #4 173 00d6 7047 bx lr
Nov 04 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 04/11/13 12:20, Iain Buclaw wrote:
 For the time being, use gcc-4.9-20131013.tar.bz2 snapshot - that is the last
 build I've done here (currently all my time is being used up on D 2.064).
Should we expect that git-head GDC will start to require GCC 4.9 in the near future?
Nov 04 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 4 November 2013 11:22, Joseph Rushton Wakeling <
joseph.wakeling webdrake.net> wrote:

 On 04/11/13 12:20, Iain Buclaw wrote:

 For the time being, use gcc-4.9-20131013.tar.bz2 snapshot - that is the
 last
 build I've done here (currently all my time is being used up on D 2.064).
Should we expect that git-head GDC will start to require GCC 4.9 in the near future?
After I push the fix that you see in that patch, yes. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 04 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 04/11/13 12:26, Iain Buclaw wrote:
 On 4 November 2013 11:22, Joseph Rushton Wakeling <joseph.wakeling webdrake.net
 <mailto:joseph.wakeling webdrake.net>> wrote:
     Should we expect that git-head GDC will start to require GCC 4.9 in the
near
     future?

 After I push the fix that you see in that patch, yes.
Am I right that you're close to the point where the frontend will be backend-neutral and so new versions can simply be dropped in as needed? If so, can I suggest that at that point there be a commitment to have GDC always build against the stable GCC release as well as the development one? I don't feel comfortable asking this without the backend-neutral situation being resolved, but once it is, it seems like a good idea.
Nov 07 2013
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 7 November 2013 08:59, Joseph Rushton Wakeling <
joseph.wakeling webdrake.net> wrote:

 On 04/11/13 12:26, Iain Buclaw wrote:

 On 4 November 2013 11:22, Joseph Rushton Wakeling <
 joseph.wakeling webdrake.net
 <mailto:joseph.wakeling webdrake.net>> wrote:
     Should we expect that git-head GDC will start to require GCC 4.9 in
 the near
     future?

 After I push the fix that you see in that patch, yes.
Am I right that you're close to the point where the frontend will be backend-neutral and so new versions can simply be dropped in as needed? If so, can I suggest that at that point there be a commitment to have GDC always build against the stable GCC release as well as the development one? I don't feel comfortable asking this without the backend-neutral situation being resolved, but once it is, it seems like a good idea.
The front-end is neutral in that it doesn't care about backend. But we still require some gdc-specific changes which call glue-layered hooks. These will be moved to Port/Target eventually as seen fit. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 07 2013
parent reply "Timo Sintonen" <t.sintonen luukku.com> writes:
Now returning to my original problem.

I tested various loops and it seems that write to a variable is 
not volatile even if the variable is marked shared. If I write to 
a variable several times in a loop, all but the last write are 
optimized out. The only write is put after the loop.
Read works fine now with shared.

How can I do volatile writes?
Nov 08 2013
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Fri, 08 Nov 2013 21:00:18 +0100
schrieb "Timo Sintonen" <t.sintonen luukku.com>:

 Now returning to my original problem.
 
 I tested various loops and it seems that write to a variable is 
 not volatile even if the variable is marked shared. If I write to 
 a variable several times in a loop, all but the last write are 
 optimized out. The only write is put after the loop.
 Read works fine now with shared.
 
 How can I do volatile writes?
AFAICS this is a GDC bug, Iain can you have a look at this? Here's a simple test case: --------------------------------------------- struct Register { shared size_t a; } Register* reg = cast(Register*)0xFFDDCCAA; void main() { for(size_t i = 0; i < 10; i++) reg.a = i; } --------------------------------------------- Same thing in C (working): --------------------------------------------- #include <stdlib.h> struct Register { volatile size_t a; }; typedef struct Register reg_t; reg_t* reg = (reg_t*)0xFFDDCCAA; void main() { size_t i; for(i = 0; i < 10; i++) reg->a = i; } --------------------------------------------- Compile with gdc -O3 test.d -S -fdump-tree-original-raw gcc -O3 test.c -S -fdump-tree-original-raw Of course the code won't run but the wrong optimization is obvious in the generated ASM. I had a quick look at the fdump-tree-original-raw output but I didn't see a obvious difference between the C/D output.
Nov 09 2013
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 9 November 2013 18:17, Johannes Pfau <nospam example.com> wrote:

 Am Fri, 08 Nov 2013 21:00:18 +0100
 schrieb "Timo Sintonen" <t.sintonen luukku.com>:

 Now returning to my original problem.

 I tested various loops and it seems that write to a variable is
 not volatile even if the variable is marked shared. If I write to
 a variable several times in a loop, all but the last write are
 optimized out. The only write is put after the loop.
 Read works fine now with shared.

 How can I do volatile writes?
AFAICS this is a GDC bug, Iain can you have a look at this? Here's a simple test case: --------------------------------------------- struct Register { shared size_t a; } Register* reg = cast(Register*)0xFFDDCCAA; void main() { for(size_t i = 0; i < 10; i++) reg.a = i; } --------------------------------------------- Same thing in C (working): --------------------------------------------- #include <stdlib.h> struct Register { volatile size_t a; }; typedef struct Register reg_t; reg_t* reg = (reg_t*)0xFFDDCCAA; void main() { size_t i; for(i = 0; i < 10; i++) reg->a = i; } --------------------------------------------- Compile with gdc -O3 test.d -S -fdump-tree-original-raw gcc -O3 test.c -S -fdump-tree-original-raw Of course the code won't run but the wrong optimization is obvious in the generated ASM. I had a quick look at the fdump-tree-original-raw output but I didn't see a obvious difference between the C/D output.
Please raise a bug. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 09 2013
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Fri, 08 Nov 2013 21:00:18 +0100
schrieb "Timo Sintonen" <t.sintonen luukku.com>:

 Now returning to my original problem.
 
 I tested various loops and it seems that write to a variable is 
 not volatile even if the variable is marked shared. If I write to 
 a variable several times in a loop, all but the last write are 
 optimized out. The only write is put after the loop.
 Read works fine now with shared.
 
 How can I do volatile writes?
In case you need a workaround right now: ---------------------------------------- shared struct Register //Also working without shared here { size_t a; } shared(Register*) reg = cast(shared(Register*))0xFFDDCCAA; void main() { for(size_t i = 0; i < 10; i++) reg.a = i; } ---------------------------------------- But of course this needs to be fixed in gdc.
Nov 10 2013
parent "Timo Sintonen" <t.sintonen luukku.com> writes:
On Sunday, 10 November 2013 at 09:20:11 UTC, Johannes Pfau wrote:
 In case you need a workaround right now:
 ----------------------------------------
 shared struct Register //Also working without shared here
 {
     size_t a;
 }

 shared(Register*) reg = cast(shared(Register*))0xFFDDCCAA;

 void main()
 {
      for(size_t i = 0; i < 10; i++)
          reg.a = i;
 }
 ----------------------------------------

 But of course this needs to be fixed in gdc.
Yes, this works when I do it in main but not when I call the original member function. The struct has to be marked shared in this case. Otherwise the compiler does not allow to call member functions with shared pointer. It still does not work. It works when I move the function out of the struct. Thanks to ufcs, I do not have to change any other code: sendtext(uart,text) is the same than uart.sendtext(text) I think the problem is here: when outside, the functon gets the real pointer with all additions. When inside, the function gets only bare 'this' without additional info. I have no idea what to do for this but now I have a workaround and I can get one step ahead again.
Nov 10 2013