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

    type=0x7ffff64de2c0)
    at ../../gcc-5-20150201/gcc/d/dfrontend/expression.c:2620

    this=this entry=0x7fffffffdc70)
    at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:6893

    this=this entry=0x7fffffffdc70)
    at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7247

(this=this entry=0x7fffffffdc70)
    at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7270

(this=this entry=0x7fffffffdc70)
    at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7293

    this=this entry=0x7fffffffdc70)
    at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7316

(this=this entry=0x7fffffffdc70)
    at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7340

(this=this entry=0x7fffffffdc70)
    at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7413

(this=this entry=0x7fffffffdc70)
    at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7430

(this=this entry=0x7fffffffdc70)
---Type <return> to continue, or q <return> to quit---
    at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7446

    this=this entry=0x7fffffffdc70)
    at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7464

(this=this entry=0x7fffffffdc70)
    at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7480

(this=this entry=0x7fffffffdc70)
    at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7497

    this=this entry=0x7fffffffdc70)
    at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7515

    t=0x7ffff64de350)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:2961

(this=0x7fffffffdc70, 
    autodecl=48, pAttrs=0xa00000009, comment=0x0)
    at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:3516

    flags=9, endPtr=0x0)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:4413

    flags=2, endPtr=0x0)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:4498

    flags=-162652272, endPtr=0x0)
    at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:4518
---Type <return> to continue, or q <return> to quit---

    flags=1, endPtr=0x0)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:4498

f=
    0x7ffff64e1d40) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:3874

(this=0x7fffffffdc70, 
    autodecl=48, autodecl entry=false, pAttrs=0xa00000009, 
    pAttrs entry=0x7fffffffdb80, comment=0x0)
    at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:3688

    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

    at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:187

    at ../../gcc-5-20150201/gcc/d/dfrontend/module.c:519

    at ../../gcc-5-20150201/gcc/d/d-lang.cc:962

    at ../../gcc-5-20150201/gcc/toplev.c:594

    at ../../gcc-5-20150201/gcc/toplev.c:2063

---Type <return> to continue, or q <return> to quit---
    argv=argv entry=0x7fffffffdfb8)
at ../../gcc-5-20150201/gcc/toplev.c:2161

    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

/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/expression.c:11707

expression.h:1409

/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/declaration.c:1411

sc=0x4170b750) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/expression.c:5958

sc=0x4170b750) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/statement.c:835

sc=0x4170b750) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/statement.c:1044

sc=0x4170b750) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/statement.c:1336

sc=0x4170aee0) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/statement.c:1546

sc=0x4170ae40) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/statement.c:1044

sc=0x4170aa00) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/func.c:1622

/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/module.c:787

/Users/jens/toolchain/Source/gcc/gcc/d/d-lang.cc:1064


/Users/jens/toolchain/Source/gcc/gcc/toplev.c:550

/Users/jens/toolchain/Source/gcc/gcc/toplev.c:1926

/Users/jens/toolchain/Source/gcc/gcc/toplev.c:2002
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