D.gnu - Build problem with latest git head
- Timo Sintonen (20/20) Nov 04 2013 I tried to build gdc with the latest heads of gcc and gdc
- Iain Buclaw (11/31) Nov 04 2013 For the time being, use gcc-4.9-20131013.tar.bz2 snapshot - that is the
- Timo Sintonen (53/61) Nov 04 2013 Ok, I check that later
- Joseph Rushton Wakeling (2/4) Nov 04 2013 Should we expect that git-head GDC will start to require GCC 4.9 in the ...
- Iain Buclaw (6/13) Nov 04 2013 After I push the fix that you see in that patch, yes.
- Joseph Rushton Wakeling (7/12) Nov 07 2013 Am I right that you're close to the point where the frontend will be
- Iain Buclaw (8/24) Nov 07 2013 The front-end is neutral in that it doesn't care about backend. But we
- Timo Sintonen (7/7) Nov 08 2013 Now returning to my original problem.
- Johannes Pfau (38/47) Nov 09 2013 AFAICS this is a GDC bug, Iain can you have a look at this?
- Iain Buclaw (5/52) Nov 09 2013 Please raise a bug.
- Johannes Pfau (16/25) Nov 10 2013 In case you need a workaround right now:
- Timo Sintonen (14/28) Nov 10 2013 Yes, this works when I do it in main but not when I call the
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
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
"Timo Sintonen" <t.sintonen luukku.com> 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} 154 00b2 03E90600 stmdb r3, {r1, r2} 155 00b6 009C ldr r4, [sp] 157 00ba 4CB1 cbz r4, .L11 zero length test 159 00be 1444 add r4, r4, r2 At this point r4 = end address r2 = p Foreach begins here 160 .L13: 162 .L15: First part of send here 163 00c4 0368 ldr r3, [r0] status reg test 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 169 .L11: AFTER the loop 171 173 00d6 7047 bx lr
Nov 04 2013
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
On 4 November 2013 11:22, Joseph Rushton Wakeling < joseph.wakeling webdrake.net> wrote:On 04/11/13 12:20, Iain Buclaw wrote:After I push the fix that you see in that patch, yes. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';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
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
On 7 November 2013 08:59, Joseph Rushton Wakeling < joseph.wakeling webdrake.net> wrote:On 04/11/13 12:26, Iain Buclaw wrote: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';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
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
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
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>:Please raise a bug. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';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
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
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