www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Trouble with Cortex-M "Hello World"

reply "Jens Bauer" <doctor who.no> writes:
Encouraged by Timo Sintonen's great posts, I decided to spend 
some time trying to build a Cortex-M toolchain for D-programming.
So this morning, I've successfully built my first toolchain 
supporting C, C++ and D for the first time.
I wanted to take the new language out for a spin, but I ran into 
some trouble...

Referring to the tutorial on this page:
<http://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22>

-I'm getting the following error:

start.d:45:11: error: mismatched array lengths, 0 and 3
    uint[3] message =
            ^

... for this part of the code:

void OnReset()
{
	while(true)
	{
		// Create semihosting message
		uint[3] message =
			[
				2,							// stderr
				cast(uint)"hello\r\n".ptr,	// ptr to string
				7							// size of string
			];
		// Send semihosting command
		SendCommand(0x05, &message);
	}
}

... I've carefully checked the code, but found no difference. Is 
this the expected behaviour ?
When I change the square brackets to parantheses, the error goes 
away, but I'm not sure that is the correct fix ?
Mar 31 2015
next sibling parent "Jens Bauer" <doctor who.no> writes:
(I just found out that I should probably have posted this in the 
digitalmars.D.learn forum instead, sorry for the inconvenience)
Mar 31 2015
prev sibling next sibling parent reply "Jens Bauer" <doctor who.no> writes:
I belive the following information is slightly incorrect:
"GDC requires the following minimal object.d file in the same 
folder as start.d. It is imported automatically."

My tests have shown that object.d needs to be in the CWD, not in 
the same directory as "start.d".

This is my command-line:

arm-none-eabi-gdc -DF_CPU=48000000 -D__BUILD_WITH_EXAMPLE__=1 
-mcpu=cortex-m4 -mthumb -mthumb-interwork -fno-emit-moduleinfo 
-fdata-sections  -c src/start.d -o output/src/start.o


Here's a summary of the directories when the build works:
./object.d
src/start.d
output/src/start.o

However, the following does not work:
src/object.d
src/start.d
output/src/start.o

-Is this directory behaviour a bug ?
Mar 31 2015
parent "Mike" <none none.com> writes:
On Tuesday, 31 March 2015 at 11:19:29 UTC, Jens Bauer wrote:
 I belive the following information is slightly incorrect:
 "GDC requires the following minimal object.d file in the same 
 folder as start.d. It is imported automatically."

 My tests have shown that object.d needs to be in the CWD, not 
 in the same directory as "start.d".
I don't believe it is the current working directory, but rather the compiler's import path. See the -I switch. By default, I believe that is the current working directory.
 This is my command-line:

 arm-none-eabi-gdc -DF_CPU=48000000 -D__BUILD_WITH_EXAMPLE__=1 
 -mcpu=cortex-m4 -mthumb -mthumb-interwork -fno-emit-moduleinfo 
 -fdata-sections  -c src/start.d -o output/src/start.o


 Here's a summary of the directories when the build works:
 ./object.d
 src/start.d
 output/src/start.o

 However, the following does not work:
 src/object.d
 src/start.d
 output/src/start.o

 -Is this directory behaviour a bug ?
I believe it is working as designed, but I'm not an authority on the compiler. Mike
Mar 31 2015
prev sibling parent reply "Mike" <none none.com> writes:
On Tuesday, 31 March 2015 at 10:39:05 UTC, Jens Bauer wrote:

 Referring to the tutorial on this page:
 <http://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22>

 -I'm getting the following error:

 start.d:45:11: error: mismatched array lengths, 0 and 3
    uint[3] message =
            ^
[snip]
 ... I've carefully checked the code, but found no difference. 
 Is this the expected behaviour ?
 When I change the square brackets to parantheses, the error 
 goes away, but I'm not sure that is the correct fix ?
I just cut and pasted the code from the wiki myself and compiled with my arm-none-eabi-gdc cross-compiler and it works fine. I'm sorry, but I'm not sure what the problem could be. Mike
Mar 31 2015
parent reply Dan Olson <zans.is.for.cans yahoo.com> writes:
"Mike" <none none.com> writes:

 On Tuesday, 31 March 2015 at 10:39:05 UTC, Jens Bauer wrote:

 Referring to the tutorial on this page:
 <http://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22>

 -I'm getting the following error:

 start.d:45:11: error: mismatched array lengths, 0 and 3
    uint[3] message =
            ^
[snip] I just cut and pasted the code from the wiki myself and compiled with my arm-none-eabi-gdc cross-compiler and it works fine. I'm sorry, but I'm not sure what the problem could be. Mike
Yeah, something strange. The start.d on the webpage compiles fine for me too. I am using LDC as cross compiler to ARM, but you should also be able to compile start.d fine with regular dmd too even though it can't target ARM. It is as if your message array declaration line is being read by compiler as: uint[0] message =
 When I change the square brackets to parantheses, the error goes
 away, but I'm not sure that is the correct fix ?
Changing the square brackets to parens is doing something different. You do want the square brackets. -- Dan
Mar 31 2015
parent reply "Jens Bauer" <doctor who.no> writes:
On Tuesday, 31 March 2015 at 15:50:17 UTC, Dan Olson wrote:
 "Mike" <none none.com> writes:
 I just cut and pasted the code from the wiki myself and 
 compiled with
 my arm-none-eabi-gdc cross-compiler and it works fine.  I'm 
 sorry, but I'm not sure what the problem could be.

 Mike
Yeah, something strange. The start.d on the webpage compiles fine for me too. I am using LDC as cross compiler to ARM, but you should also be able to compile start.d fine with regular dmd too even though it can't target ARM. It is as if your message array declaration line is being read by compiler as: uint[0] message =
I've also tried putting it all on one line, but that didn't help: src/start.d:46:12: error: mismatched array lengths, 0 and 3 uint[3]message=[2,cast(uint)"hello\r\n".ptr,7]; ^ -So it's not because there's a problem with spaces, tabs and linefeeds.
 When I change the square brackets to parantheses, the error 
 goes
 away, but I'm not sure that is the correct fix ?
Changing the square brackets to parens is doing something different. You do want the square brackets.
I expected that. :) Thank you both Mike and Dan for the replies. This could be something related to big endian issues, as my compiler is hosted on a big endian machine (PowerMac G5). Note: Just in case it's important; I'm using GCC+GDC, not LLVM+LDC. I hope I'll be able to make a build on my CubieBoard2, so I can try the test there.
Mar 31 2015
parent reply "Jens Bauer" <doctor who.no> writes:
Unfortunately, my attempt to build GDC on my CubieBoard2 failed.

However, I decided to change the line slightly, in order to find 
out exactly what's going wrong...


src/start.d:46:12: error: mismatched array lengths, 0 and 3
      uint[4]message=[2,cast(uint)"hello\r\n".ptr,7];
             ^
make: *** [output/src/start.o] Error 1

This means that the arry on the right hand side is actually 
parsed correctly.
It seems that the number [3] or [4] is parsed/read as zero ??
Apr 01 2015
parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 01 Apr 2015 12:56:22 +0000
schrieb "Jens Bauer" <doctor who.no>:

 Unfortunately, my attempt to build GDC on my CubieBoard2 failed.
 
 However, I decided to change the line slightly, in order to find 
 out exactly what's going wrong...
 
 
 src/start.d:46:12: error: mismatched array lengths, 0 and 3
       uint[4]message=[2,cast(uint)"hello\r\n".ptr,7];
              ^
 make: *** [output/src/start.o] Error 1
 
 This means that the arry on the right hand side is actually 
 parsed correctly.
 It seems that the number [3] or [4] is parsed/read as zero ??
I'm not sure if anybody ever used GDC/DMD/LDC on a big-endian system. It could be an endianess issue somewhere in the code. I debugged a misaligned-access bug in the frontend some time ago, bugs like these can result in the weirdest effects. It should compile on the cubieboard though. What exactly failed?
Apr 01 2015
next sibling parent reply "Jens Bauer" <doctor who.no> writes:
On Wednesday, 1 April 2015 at 13:59:34 UTC, Johannes Pfau wrote:
 Am Wed, 01 Apr 2015 12:56:22 +0000
 It could be an endianess issue somewhere in the code. I 
 debugged a misaligned-access bug in the frontend some time ago,
 bugs like these can result in the weirdest effects.
Indeed. I had some strange things happening until OpenOCD had the endian bugs squashed. Endian problems does not necessarily have to mean crashes; it could just be some data's high an low bytes being swapped.
 It should compile on the cubieboard though. What exactly failed?
building GCC-4.9.2, so this is not an issue with D. I'll probably be trying to make a build for the next 10 hours. On my G5, however, I managed to get as complete a build as I could, but it involves compiling GCC 4 times total (!) - This gives me C/C++ and D - including libstdc++! -but it takes a couple of hours. ;)
Apr 01 2015
parent reply "Jens Bauer" <doctor who.no> writes:
I have successfully built GDC on CubieBoard2 (Cubian) now.
I've rebuilt GDC on the G5 as well, using the same script.

I've used nano for making object.d and start.d, in order to avoid 
too many problems with character encoding.
In addition, I've used hexdump -C <file>.d to verify that the 
text-files are actually the same, thus I think it's fairly safe 
to rule out character encoding problems.

GDC on Cubian works, while GDC on the G5 seems to fail.

I've attempted to see if I could find anything in the sources, by 
first doing a grep -R 'mismatched array lengths' *; however I 
think I got lost in expressions.c as I don't have a good overview.

As the main difference between my Mac and other platforms is that 
it's a Big Endian architecture, I expected to be able to find 
something in the scanner/parser, where it would perhaps be 
reading a 16-bit or 32-bit character 'buffer' and then 
bit-shifting the read characters to the right instead of reading 
byte-by-byte.

But looking at macro.c; I understand that such kind of 
optimizations are probably not used.

So are there any suggestions on enabling debug-code, which might 
give hints on what is going wrong ?
Apr 01 2015
next sibling parent "Mike" <none none.com> writes:
On Thursday, 2 April 2015 at 05:55:52 UTC, Jens Bauer wrote:

 So are there any suggestions on enabling debug-code, which 
 might give hints on what is going wrong ?
You can find information on debugging GDC here: http://wiki.dlang.org/GDC/Development/DevelopmentEnvironment Mike
Apr 02 2015
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 02 Apr 2015 05:55:48 +0000
schrieb "Jens Bauer" <doctor who.no>:

 
 So are there any suggestions on enabling debug-code, which might 
 give hints on what is going wrong ?
I'm not sure if there's any debug code, but here's what I would do: /opt/gdc/bin/gdc test.d -c -wrapper gdb,--args break expression.c:11707 break expression.c:11570 break init.c:1015 run Breakpoint 2, AssignExp::semantic (this=0x7ffff656fad0, sc=0x7ffff656f440) at ../../gcc-5-20150201/gcc/d/dfrontend/expression.c:11570 * bt (not that useful in this case) * maybe print the dim1/2 values in gdb. * Look at code: we're interested in TypeSArray * grep TypeSArray parse.c break parse.c:3104 break parse.c:2969 break parse.c:7666 run Breakpoint 2, Parser::parseBasicType2 (this=0x7fffffffdc70, t=0x7ffff64de350) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:2969 2969 t = new TypeSArray(t,e); print *e print e->toChars() print *(IntegerExp*)e break expression.c:2620 run (y) print loc cont (wrong integerexp) print loc cont (wrong integerexp) IntegerExp::IntegerExp (this=0x7ffff64e1ff0, loc=..., value=0, type=0x7ffff64de2c0) at ../../gcc-5-20150201/gcc/d/dfrontend/expression.c:2620 2620 IntegerExp::IntegerExp(Loc loc, dinteger_t value, Type *type) (gdb) print loc $3 = {filename = 0x1d6db30 "test.d", linnum = 9, charnum = 10} (gdb) bt #0 IntegerExp::IntegerExp (this=0x7ffff64e1ff0, loc=..., value=0, type=0x7ffff64de2c0) at ../../gcc-5-20150201/gcc/d/dfrontend/expression.c:2620 #1 0x000000000070bd57 in Parser::parsePrimaryExp ( this=this entry=0x7fffffffdc70) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:6893 #2 0x00000000007075b9 in Parser::parseUnaryExp ( this=this entry=0x7fffffffdc70) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7247 #3 0x0000000000707d52 in Parser::parseMulExp (this=this entry=0x7fffffffdc70) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7270 #4 0x0000000000707ea2 in Parser::parseAddExp (this=this entry=0x7fffffffdc70) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7293 #5 0x0000000000707ff2 in Parser::parseShiftExp ( this=this entry=0x7fffffffdc70) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7316 #6 0x0000000000708141 in Parser::parseCmpExp (this=this entry=0x7fffffffdc70) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7340 #7 0x00000000007083a1 in Parser::parseAndExp (this=this entry=0x7fffffffdc70) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7413 #8 0x0000000000708462 in Parser::parseXorExp (this=this entry=0x7fffffffdc70) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7430 #9 0x0000000000708532 in Parser::parseOrExp (this=this entry=0x7fffffffdc70) ---Type <return> to continue, or q <return> to quit--- at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7446 #10 0x0000000000708602 in Parser::parseAndAndExp ( this=this entry=0x7fffffffdc70) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7464 #11 0x00000000007086a2 in Parser::parseOrOrExp (this=this entry=0x7fffffffdc70) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7480 #12 0x0000000000708742 in Parser::parseCondExp (this=this entry=0x7fffffffdc70) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7497 #13 0x00000000007087e6 in Parser::parseAssignExp ( this=this entry=0x7fffffffdc70) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7515 #14 0x000000000070b54b in Parser::parseBasicType2 (this=0x7fffffffdc70, t=0x7ffff64de350) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:2961 #15 0x0000000000703e84 in Parser::parseDeclarations (this=0x7fffffffdc70, autodecl=48, pAttrs=0xa00000009, comment=0x0) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:3516 #16 0x00000000007010de in Parser::parseStatement (this=0x7fffffffdc70, flags=9, endPtr=0x0) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:4413 #17 0x00000000007013fb in Parser::parseStatement (this=0x7fffffffdc70, flags=2, endPtr=0x0) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:4498 #18 0x000000000070210c in Parser::parseStatement (this=0x7fffffffdc70, flags=-162652272, endPtr=0x0) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:4518 ---Type <return> to continue, or q <return> to quit--- #19 0x00000000007013fb in Parser::parseStatement (this=0x7fffffffdc70, flags=1, endPtr=0x0) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:4498 #20 0x0000000000703b2d in Parser::parseContracts (this=0x7fffffffdc70, f= 0x7ffff64e1d40) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:3874 #21 0x00000000007044da in Parser::parseDeclarations (this=0x7fffffffdc70, autodecl=48, autodecl entry=false, pAttrs=0xa00000009, pAttrs entry=0x7fffffffdb80, comment=0x0) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:3688 #22 0x0000000000705601 in Parser::parseDeclDefs ( this=this entry=0x7fffffffdc70, once=once entry=0, pLastDecl=0x7fffffffdb18, pLastDecl entry=0x0, pAttrs=0x7fffffffdb80, pAttrs entry=0x0) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:337 #23 0x0000000000709a3b in Parser::parseModule (this=0x7fffffffdc70) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:187 #24 0x00000000006f3ec5 in Module::parse (this=0x7ffff64e1810) at ../../gcc-5-20150201/gcc/d/dfrontend/module.c:519 #25 0x0000000000748e19 in d_parse_file () at ../../gcc-5-20150201/gcc/d/d-lang.cc:962 #26 0x0000000000bc2402 in compile_file () at ../../gcc-5-20150201/gcc/toplev.c:594 #27 0x0000000000616b9c in do_compile () at ../../gcc-5-20150201/gcc/toplev.c:2063 #28 toplev::main (this=this entry=0x7fffffffdeb0, argc=argc entry=11, ---Type <return> to continue, or q <return> to quit--- argv=argv entry=0x7fffffffdfb8) at ../../gcc-5-20150201/gcc/toplev.c:2161 #29 0x000000000061754a in main (argc=11, argv=0x7fffffffdfb8) at ../../gcc-5-20150201/gcc/main.c:39 It could be quite some more work to find where exactly things go wrong, but this should give an idea about one way to debug this.
Apr 02 2015
next sibling parent reply "Jens Bauer" <doctor who.no> writes:
 So are there any suggestions on enabling debug-code, which 
 might give hints on what is going wrong ?
I'm not sure if there's any debug code, but here's what I would do [snip]
Mike and Johannes - Thank you both for the suggestions. I will follow the debug path you've given me when I've finished the current build. (I'm still attempting to find a way to have both coffee and cake; eg. multilib support in GCC /and/ GDC). I expect to get more information about this, and of course, I hope to find what causes the bug. When my next build is finished, I plan to add a zero in front of the number 3: uint[03] message = ... just in case it's a read-pointer "alignment-style" problem. If the bug is related to Big Endian architectures, then it's a bit more important than if it's only related to PowerMacs; because there are other Big Endian hosts ... PowerPC based Amiga, MIPS based hosts, Cortex-A based hosts, 68xxx based hosts, other PowerPC based systems (IBM, YellowDog, etc) - and all those I forgot, plus future architectures. If you are working with a BE host and come across this post, please post a comment, whether or not it works for you.
Apr 02 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Jens Bauer"  wrote in message news:gufvwhyvuyuhhkgdyqxp forum.dlang.org...

 I expect to get more information about this, and of course, I hope to find 
 what causes the bug.
 When my next build is finished, I plan to add a zero in front of the 
 number 3:
 uint[03] message =
 ... just in case it's a read-pointer "alignment-style" problem.
You can tell how far through the error is by triggering failures in different compilation phases. eg to generate a parser error, give the compiler something invalid like: pragma 3 which should generate testx.d(2): Error: found '3' when expecting '(' This should error during semantic2 static assert(3 == 2);
Apr 02 2015
parent reply "Jens Bauer" <doctor who.no> writes:
Well, it seems I found the problem.

lexer.h, line 203 reads:

     union
     {
         d_int32 int32value;
         d_uns32 uns32value;
         d_int64 int64value;
         d_uns64 uns64value;
         ...
         ...
         ...
     };

While this optimization is neat, it does not produce correct code 
on Big Endian or Mixed Endian platforms.

If we write a value to int64value and read it from int32value, 
then it will be 0 always.
This is because the int32value is always read if the upper 32 
bits of the int64value is zero.
And since a Big Endian platform reads the most significant 
bits/bytes first, they'll read the upper 32 bits, not the lower 
32 bits.

lexer.c:1874; Lexer::number(Token *t) correctly writes n to 
t->uns64value.
-But let's take parse.c:6384 - here token.uns32value is read, 
thus we'll get a zero, no matter which value was written by 
number(Token *).

In parse.c:6379 we would get a minus one always.

Looking for union-"tricks", I also found ...
stringtable.c:24 hash will not be the same value on Big Endian, 
Mixed Endian and Little Endian machines.
To hash correctly, read one byte at a time, then use bit-shifting 
by 8 if another byte is to be read.
Apr 03 2015
next sibling parent reply "Jens Bauer" <doctor who.no> writes:
I better also mention that the problem is the same for floats in 
Lexer::inreal(Token *).
Apr 03 2015
parent "Jens Bauer" <doctor who.no> writes:
On Friday, 3 April 2015 at 08:06:03 UTC, Jens Bauer wrote:
 I better also mention that the problem is the same for floats 
 in Lexer::inreal(Token *).
Ignore that - it's always read/written as a long double. Sorry for then noise.
Apr 03 2015
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 03 Apr 2015 07:32:21 +0000
schrieb "Jens Bauer" <doctor who.no>:

 Well, it seems I found the problem.
 
 lexer.h, line 203 reads:
 
      union
      {
          d_int32 int32value;
          d_uns32 uns32value;
          d_int64 int64value;
          d_uns64 uns64value;
          ...
          ...
          ...
      };
 
 While this optimization is neat, it does not produce correct code 
 on Big Endian or Mixed Endian platforms.
 
 If we write a value to int64value and read it from int32value, 
 then it will be 0 always.
 This is because the int32value is always read if the upper 32 
 bits of the int64value is zero.
 And since a Big Endian platform reads the most significant 
 bits/bytes first, they'll read the upper 32 bits, not the lower 
 32 bits.
 
 lexer.c:1874; Lexer::number(Token *t) correctly writes n to 
 t->uns64value.
 -But let's take parse.c:6384 - here token.uns32value is read, 
 thus we'll get a zero, no matter which value was written by 
 number(Token *).
 
 In parse.c:6379 we would get a minus one always.
Nice find. If you open a pull request on https://github.com/D-Programming-Language/dmd please notify me ( jpf91). I'll make sure to backport the fix to gdc once it's been committed to dmd upstream.
 Looking for union-"tricks", I also found ...
 stringtable.c:24 hash will not be the same value on Big Endian, 
 Mixed Endian and Little Endian machines.
 To hash correctly, read one byte at a time, then use bit-shifting 
 by 8 if another byte is to be read.
IIRC it does not really matter if the hash is different here as it's only used internally in the compiler. So as long as it still hashes correctly ('no' collisions) it shouldn't matter.
Apr 03 2015
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Jens Bauer"  wrote in message news:ckqcspcptqazbawdsgzj forum.dlang.org... 

 Well, it seems I found the problem.
 
 lexer.h, line 203 reads:
Yeah, I thought it might be that.
 Looking for union-"tricks", I also found ...
 stringtable.c:24 hash will not be the same value on Big Endian, 
 Mixed Endian and Little Endian machines.
 To hash correctly, read one byte at a time, then use bit-shifting 
 by 8 if another byte is to be read.
It doesn't matter for this hash table.
Apr 03 2015
parent "Jens Bauer" <doctor who.no> writes:
On Friday, 3 April 2015 at 10:32:39 UTC, Daniel Murphy wrote:
 It doesn't matter for this hash table.
Alright - if there's no major difference in performance, then it won't matter (Johannes mentioned that it's only used internally). I've sent an email to Johannes regarding the patch - because GitHub will not support any of my Web-browsers. A link to the patch is as far as I can get: https://github.com/D-Programming-Language/dmd/compare/master...jens-gpio:bugfix_endian
Apr 03 2015
prev sibling parent "Jens Bauer" <doctor who.no> writes:
I got a little further, and will continue to look into the issue.
Currently, this is what I've gotten so far...

arm-none-eabi-gdc start.d -c -wrapper gdb,--args

break expression.c:11707
break expression.c:11570
break init.c:1015
break init.c:557
run

...

Breakpoint 1, AssignExp::semantic (this=0x4170b9f0, 
sc=0x4170b860) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/expression.c:11707
11707	                error("mismatched array lengths, %d and 
%d", (int)dim1, (int)dim2);


(gdb) print dim1
$1 = 0

(gdb) print dim2
$2 = 3

... dim1 is the one which is incorrect.
dim1 comes from tsa1; tsa1 comes from se1, se1 comes from e1.


(gdb) print *e1
$3 = {
   <RootObject> = {
     _vptr$RootObject = 0xf07570
   },
   members of Expression:
   loc = {
     filename = 0x41605be0 "start.d",
     linnum = 46,
     charnum = 13
   },
   op = TOKvar,
   type = 0x41709040,
   size = 36 '$',
   parens = 0 '\0'
}

(gdb) print e1->toChars()
$4 = 0x41611a74 "message"

(gdb) print e1->isLvalue()
$5 = 1

(gdb) print e1->type->ty
$6 = 1 '\001'


(gdb) bt
#0  AssignExp::semantic (this=0x4170b9f0, sc=0x4170b860) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/expression.c:11707
#1  0x0003e230 in _ZN10Expression8optimizeEib [inlined] () at 
expression.h:1409
#2  VarDeclaration::semantic (this=0x417093c0, sc=0x4170b860) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/declaration.c:1411
#3  0x00059204 in DeclarationExp::semantic (this=0x417094a0, 
sc=0x4170b750) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/expression.c:5958
#4  0x000fed38 in ExpStatement::semantic (this=0x41709480, 
sc=0x4170b750) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/statement.c:835
#5  0x00105a64 in CompoundStatement::semantic (this=0x4170b7f0, 
sc=0x4170b750) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/statement.c:1044
#6  0x00104838 in ScopeStatement::semantic (this=0x41709600, 
sc=0x4170b750) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/statement.c:1336
#7  0x0010a890 in ForStatement::semantic (this=0x4170b680, 
sc=0x4170aee0) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/statement.c:1546
#8  0x00105a64 in CompoundStatement::semantic (this=0x41709640, 
sc=0x4170ae40) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/statement.c:1044
#9  0x0007f2ec in FuncDeclaration::semantic3 (this=0x41708e70, 
sc=0x4170aa00) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/func.c:1622
#10 0x000d6f18 in Module::semantic3 (this=0x41707a90) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/module.c:787
#11 0x0012c38c in d_parse_file () at 
/Users/jens/toolchain/Source/gcc/gcc/d/d-lang.cc:1064
#12 0x00773ca8 in timevar_pop [inlined] () at timevar.h:548
#13 0x00773ca8 in compile_file () at 
/Users/jens/toolchain/Source/gcc/gcc/toplev.c:550
#14 0x00774c2c in do_compile () at 
/Users/jens/toolchain/Source/gcc/gcc/toplev.c:1926
#15 0x0077519c in toplev_main (argc=11, argv=0xbffff148) at 
/Users/jens/toolchain/Source/gcc/gcc/toplev.c:2002
#16 0x00002404 in start ()
Apr 02 2015
prev sibling parent reply "Kai Nacke" <kai redstar.de> writes:
On Wednesday, 1 April 2015 at 13:59:34 UTC, Johannes Pfau wrote:
 I'm not sure if anybody ever used GDC/DMD/LDC on a big-endian 
 system.
LDC is endian-clean. I used LDC on big-endian Linux/PPC64. Regards, Kai
Apr 03 2015
parent reply "Jens Bauer" <doctor who.no> writes:
On Friday, 3 April 2015 at 14:22:43 UTC, Kai Nacke wrote:
 On Wednesday, 1 April 2015 at 13:59:34 UTC, Johannes Pfau wrote:
 I'm not sure if anybody ever used GDC/DMD/LDC on a big-endian 
 system.
LDC is endian-clean. I used LDC on big-endian Linux/PPC64.
Unfortunately, I can't b uild LLVM on my PowerMac. :/ ... I find it a little strange that LDC is endian-clean; don't they all use the same parser ?
Apr 03 2015
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 3 April 2015 at 14:39:35 UTC, Jens Bauer wrote:
 On Friday, 3 April 2015 at 14:22:43 UTC, Kai Nacke wrote:
 On Wednesday, 1 April 2015 at 13:59:34 UTC, Johannes Pfau 
 wrote:
 I'm not sure if anybody ever used GDC/DMD/LDC on a big-endian 
 system.
LDC is endian-clean. I used LDC on big-endian Linux/PPC64.
Unfortunately, I can't b uild LLVM on my PowerMac. :/ ... I find it a little strange that LDC is endian-clean; don't they all use the same parser ?
LDC's frontend is a fork of DMD's frontend - modified to use LLVM backend and a few other tweaks - that tracks upstream. Not exactly "the same".
Apr 03 2015
parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 3 April 2015 at 17:05, John Colvin via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Friday, 3 April 2015 at 14:39:35 UTC, Jens Bauer wrote:
 On Friday, 3 April 2015 at 14:22:43 UTC, Kai Nacke wrote:
 On Wednesday, 1 April 2015 at 13:59:34 UTC, Johannes Pfau wrote:
 I'm not sure if anybody ever used GDC/DMD/LDC on a big-endian system.
LDC is endian-clean. I used LDC on big-endian Linux/PPC64.
Unfortunately, I can't b uild LLVM on my PowerMac. :/ ... I find it a little strange that LDC is endian-clean; don't they all use the same parser ?
LDC's frontend is a fork of DMD's frontend - modified to use LLVM backend and a few other tweaks - that tracks upstream. Not exactly "the same".
That's a bit greedy of them to not upstream fixes. >:-) Iain.
Apr 03 2015
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Friday, 3 April 2015 at 15:39:33 UTC, Iain Buclaw wrote:
 That's a bit greedy of them to not upstream fixes. >:-)
Some of the fixes use LLVM libraries, so there is not much point in upstreaming that. ;) – David
Apr 03 2015
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 3 April 2015 at 17:40, David Nadlinger via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Friday, 3 April 2015 at 15:39:33 UTC, Iain Buclaw wrote:
 That's a bit greedy of them to not upstream fixes. >:-)
Some of the fixes use LLVM libraries, so there is not much point in upstreaming that. ;) – David
It might be a suggestion to abstract the changes away into Port/Target rather than use macros (if you use LLVM macros that is). Iain
Apr 03 2015
prev sibling parent reply "Kai Nacke" <kai redstar.de> writes:
On Friday, 3 April 2015 at 15:39:33 UTC, Iain Buclaw wrote:
 That's a bit greedy of them to not upstream fixes. >:-)
I don't know why this change was not upstreamed - it's from 2012! BTW: There are some places in constfold.c and ctfeexpr.c which are also not endian-clean. And also not upstream... Just search LDC source for __LITTLE_ENDIAN__. Regards, Kai
Apr 03 2015
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 4 April 2015 at 01:17, Kai Nacke via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Friday, 3 April 2015 at 15:39:33 UTC, Iain Buclaw wrote:
 That's a bit greedy of them to not upstream fixes. >:-)
I don't know why this change was not upstreamed - it's from 2012! BTW: There are some places in constfold.c and ctfeexpr.c which are also not endian-clean. And also not upstream... Just search LDC source for __LITTLE_ENDIAN__. Regards, Kai
I had a look, you should definitely raise PRs for those. Iain.
Apr 03 2015
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Friday, 3 April 2015 at 14:39:35 UTC, Jens Bauer wrote:
 Unfortunately, I can't b uild LLVM on my PowerMac. :/
Why would that be so? — David
Apr 03 2015
parent reply "Jens Bauer" <doctor who.no> writes:
On Friday, 3 April 2015 at 15:41:34 UTC, David Nadlinger wrote:
 On Friday, 3 April 2015 at 14:39:35 UTC, Jens Bauer wrote:
 Unfortunately, I can't b uild LLVM on my PowerMac. :/
Why would that be so?
Basically because it requires GCC > 4.2 - but unfortunately there's more. Once upon a time, LLVM did support being built with GCC 4.2, but I can't get those sources anymore, so I can't get a 'bootstrap LLVM' that way.
Apr 03 2015
next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 3 April 2015 at 17:58, Jens Bauer via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Friday, 3 April 2015 at 15:41:34 UTC, David Nadlinger wrote:
 On Friday, 3 April 2015 at 14:39:35 UTC, Jens Bauer wrote:
 Unfortunately, I can't b uild LLVM on my PowerMac. :/
Why would that be so?
Basically because it requires GCC > 4.2 - but unfortunately there's more. Once upon a time, LLVM did support being built with GCC 4.2, but I can't get those sources anymore, so I can't get a 'bootstrap LLVM' that way.
I guess if you're happy to work with D1... (which is far more easier to port than D2 will ever be). Iain.
Apr 03 2015
parent "Jens Bauer" <doctor who.no> writes:
On Friday, 3 April 2015 at 16:11:59 UTC, Iain Buclaw wrote:
 On 3 April 2015 at 17:58, Jens Bauer via Digitalmars-d
 Basically because it requires GCC > 4.2 - but unfortunately 
 there's more.
 Once upon a time, LLVM did support being built with GCC 4.2, 
 but I can't get
 those sources anymore, so I can't get a 'bootstrap LLVM' that 
 way.
I guess if you're happy to work with D1... (which is far more easier to port than D2 will ever be).
It's actually only clang I have problems with, not LDC. D2 probably doesn't have any serious errors on my platform. -The only part that was a bit challenging was the BE issue, but I'm confident that it will be solved the right way. ;) At some point, I might want to try building dmd as well; currently it does not seem to support Mac/PPC (I had a short look at it, but it seems I need to write some header files in order to get it working).
Apr 03 2015
prev sibling next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Friday, 3 April 2015 at 15:58:03 UTC, Jens Bauer wrote:
 Basically because it requires GCC > 4.2 - but unfortunately 
 there's more.
 Once upon a time, LLVM did support being built with GCC 4.2, 
 but I can't get those sources anymore, so I can't get a 
 'bootstrap LLVM' that way.
Can't you just bootstrap your way up to a recent GCC first? — David
Apr 03 2015
parent "Jens Bauer" <doctor who.no> writes:
On Friday, 3 April 2015 at 16:39:40 UTC, David Nadlinger wrote:
 On Friday, 3 April 2015 at 15:58:03 UTC, Jens Bauer wrote:
 Basically because it requires GCC > 4.2 - but unfortunately 
 there's more.
 Once upon a time, LLVM did support being built with GCC 4.2, 
 but I can't get those sources anymore, so I can't get a 
 'bootstrap LLVM' that way.
Can't you just bootstrap your way up to a recent GCC first?
Unfortunately, GCC > 4.2 is not patched by Apple. When Apple suddenly decided to stop using GCC, they withdrew all patches and made clear to the GCC team that they were not allowed to use any of those patches. This causes some problems with building Mach'o binaries, which is native to Mac/PPC. It also causes incompatibilities regarding ObjC and poor Xcode integration (!) -So it would have been better to get the old clang sources and build clang that way. Or perhaps someone with an Intel Mac could build clang for PPC, heh. ;)
Apr 03 2015
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 3 April 2015 at 15:58:03 UTC, Jens Bauer wrote:
 On Friday, 3 April 2015 at 15:41:34 UTC, David Nadlinger wrote:
 On Friday, 3 April 2015 at 14:39:35 UTC, Jens Bauer wrote:
 Unfortunately, I can't b uild LLVM on my PowerMac. :/
Why would that be so?
Basically because it requires GCC > 4.2 - but unfortunately there's more. Once upon a time, LLVM did support being built with GCC 4.2, but I can't get those sources anymore, so I can't get a 'bootstrap LLVM' that way.
There is universal binary of LLVM 2.1 with clang (llvm-gcc back then I think) available here: http://llvm.org/releases/2.1/llvm-llvm-gcc4.0-2.1-darwin-univ.tar.gz
Apr 03 2015
parent "Jens Bauer" <doctor who.no> writes:
On Friday, 3 April 2015 at 17:05:28 UTC, John Colvin wrote:
 There is universal binary of LLVM 2.1 with clang (llvm-gcc back 
 then I think) available here: 
 http://llvm.org/releases/2.1/llvm-llvm-gcc4.0-2.1-darwin-univ.tar.gz
Thank you so much; I'll try it immediately. I don't know why I haven't noticed it!
Apr 03 2015