Thread overview | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
November 04, 2013 Build problem with latest git head | ||||
---|---|---|---|---|
| ||||
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 |
November 04, 2013 Re: Build problem with latest git head | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timo Sintonen Attachments:
| 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'; |
November 04, 2013 Re: Build problem with latest git head | ||||
---|---|---|---|---|
| ||||
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?
|
November 04, 2013 Re: Build problem with latest git head | ||||
---|---|---|---|---|
| ||||
Attachments:
| 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'; |
November 04, 2013 Re: Build problem with latest git head | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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 |
November 07, 2013 Re: Build problem with latest git head | ||||
---|---|---|---|---|
| ||||
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.
|
November 07, 2013 Re: Build problem with latest git head | ||||
---|---|---|---|---|
| ||||
Attachments:
| 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'; |
November 08, 2013 Re: Build problem with latest git head | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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? |
November 09, 2013 Re: Build problem with latest git head | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timo Sintonen | 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. |
November 09, 2013 Re: Build problem with latest git head | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau Attachments:
| 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'; |
Copyright © 1999-2021 by the D Language Foundation