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

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';

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?

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';

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

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.

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';

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?

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.

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';