On Tuesday, 26 August 2014 at 17:04:41 UTC, Kai Nacke wrote:
> On Tuesday, 26 August 2014 at 11:54:02 UTC, Joakim wrote:
>> I'm going to try cross-compiling and running the unit tests next.
>> What should I expect?
>
> I still have trouble with binaries compiled without optimization. Using -O1 or higher works.
Yes, I ran into this also: it tries to run some module ctor and dies, but only if compiled with -O0.

My question is more how many of the unit tests should I expect to run?

>> I'll try merging David's old patch for ARM exception-handling from issue #489 at some point.
>
> I merged the easy part of the patch so expect some merge conflicts.

Yep, I noticed that, had to slightly modify your long double patch in one place to get it to apply also.

On Tuesday, 26 August 2014 at 17:56:09 UTC, Joakim wrote:
> My question is more how many of the unit tests should I expect to run?

Alright, finally got the tests to link and run.

All tests pass for a cross-compiled linux/ARM druntime except for rt.minfo, which crashes.  I noticed that core.internal.convert and core.internal.hash aren't run by the ldc test scripts, so I compiled and ran those too.  The latter passes, but the former asserts in one of the conversions and fails.  I haven't looked into which conversion yet, may be related to the real/long double cross-compiling issues.

As for phobos, three modules' unit tests don't compile for linux/ARM- std.variant, std.math, and std.traits- and every single module throws this error when running their tests right now:

core.exception.RangeError@std.string.sformat(0): Range violation

Something basic is going wrong there, will look into it more.

How does this compare to the test runs on ARM that the ldc devs have tried?

Hi Joakim,

On 26/08/14 19:56, Joakim via digitalmars-d-ldc wrote:
> My question is more how many of the unit tests should I expect to run?
> […]
> I'll try merging David's old patch for ARM exception-handling from
> issue #489 at some point.

When I last tried (which was a _long_ time ago), there were still some random crashes in the unit tests that looked like they were caused by an error during unwinding.

Back then, my guess was that there might be a subtle mistake in the ARM-specific unwinding definitions (type size, field alignment, …) or an unhandled special case in the code. It's probably fairly easy to figure out with a more methodical look at the issue, but I was in "get something to work, now" mode when I hacked up the patch.

Let me know if there are any questions regarding EH that I might be able to help you with.

Best,
David

On Saturday, 30 August 2014 at 21:58:18 UTC, David Nadlinger via digitalmars-d-ldc wrote:
> When I last tried (which was a _long_ time ago), there were still some random crashes in the unit tests that looked like they were caused by an error during unwinding.

If you mean random in the sense that the same test will sometimes pass and sometimes crash, I haven't seen that.

> Back then, my guess was that there might be a subtle mistake in the ARM-specific unwinding definitions (type size, field alignment, …) or an unhandled special case in the code. It's probably fairly easy to figure out with a more methodical look at the issue, but I was in "get something to work, now" mode when I hacked up the patch.
>
> Let me know if there are any questions regarding EH that I might be able to help you with.

I haven't actually looked at either the real/longdouble patch or your EH patch other than skimming them yet, just applied the two and tried different ways of building the resulting source.  I've now tried building with gcc and clang, both native and cross-compile for each, and find almost no difference in the test runs done each of the four ways.  This seems to indicate that a cross-compile is just as good as native compilation, which is great because I can cross-compile much faster on a single core of my core i5 than natively compiling ldc and the unit tests on the dual Cortex-A7 cores of the Cubieboard2 I'm testing on.

The std.string.sformat issue with the phobos tests that I mentioned earlier was in a static ctor for std.net.curl.  Once I removed that module from the test runner, I got 4 phobos modules' tests to pass, 10 modules assert in a test somewhere, 44 seg fault, and 8 say they "Aborted," so I'm 4/69 on the phobos unit tests right now (I got std.traits to compile with a small fix).  Is that about what you guys got when you ran the phobos tests on ARM before?

I can't say if EH is the main issue or if there are other porting issues, as I haven't started looking into the details yet.

On 2 Sep 2014, at 11:44, Joakim via digitalmars-d-ldc wrote:
> On Saturday, 30 August 2014 at 21:58:18 UTC, David Nadlinger via digitalmars-d-ldc wrote:
>> When I last tried (which was a _long_ time ago), there were still some random crashes in the unit tests that looked like they were caused by an error during unwinding.
>
> If you mean random in the sense that the same test will sometimes pass and sometimes crash, I haven't seen that.

Sorry, I was a bit imprecise. I meant "random" as in "it failed in some of the tests, but I didn't see an obvious similarity without actually starting to track down the issue".

Best,
David

On Tuesday, 2 September 2014 at 09:44:29 UTC, Joakim wrote:
> The std.string.sformat issue with the phobos tests that I mentioned earlier was in a static ctor for std.net.curl.  Once I removed that module from the test runner, I got 4 phobos modules' tests to pass, 10 modules assert in a test somewhere, 44 seg fault, and 8 say they "Aborted," so I'm 4/69 on the phobos unit tests right now (I got std.traits to compile with a small fix).  Is that about what you guys got when you ran the phobos tests on ARM before?
>
> I can't say if EH is the main issue or if there are other porting issues, as I haven't started looking into the details yet.

I just tried cross-compiling to ARM with the merge-2.066 branch and llvm 3.5 and the latter seems to make a bunch of seg faults go away. :) rt.minfo passes its tests now, but core.time asserts and so does core.internal.convert still.  As for phobos, 3 modules pass, 46 modules assert- 41 of which assert in one test in std.format, not sure why other modules are running tests for std.format- only 9 segfault, and 10 are "Aborted," so I'm down to 3/69 now, but hopefully much easier to fix with less segfaults.

I didn't get this improvement with merge-2.066 and llvm 3.4, so it's definitely llvm 3.5 that made the difference, not sure why.

On Thursday, 11 September 2014 at 21:29:52 UTC, Joakim wrote:
> On Tuesday, 2 September 2014 at 09:44:29 UTC, Joakim wrote:
>> The std.string.sformat issue with the phobos tests that I mentioned earlier was in a static ctor for std.net.curl.  Once I removed that module from the test runner, I got 4 phobos modules' tests to pass, 10 modules assert in a test somewhere, 44 seg fault, and 8 say they "Aborted," so I'm 4/69 on the phobos unit tests right now (I got std.traits to compile with a small fix).  Is that about what you guys got when you ran the phobos tests on ARM before?
>>
>> I can't say if EH is the main issue or if there are other porting issues, as I haven't started looking into the details yet.
>
> I just tried cross-compiling to ARM with the merge-2.066 branch and llvm 3.5 and the latter seems to make a bunch of seg faults go away. :) rt.minfo passes its tests now, but core.time asserts and so does core.internal.convert still.  As for phobos, 3 modules pass, 46 modules assert- 41 of which assert in one test in std.format, not sure why other modules are running tests for std.format- only 9 segfault, and 10 are "Aborted," so I'm down to 3/69 now, but hopefully much easier to fix with less segfaults.
>
> I didn't get this improvement with merge-2.066 and llvm 3.4, so it's definitely llvm 3.5 that made the difference, not sure why.

More good news, the sieve.d sample file from dmd's repo now not only compiles fine against phobos but doesn't spit out junk output anymore, ie it works.  I wish all ldc problems could just be solved by an llvm upgrade like this. ;)

On Thursday, 11 September 2014 at 21:44:29 UTC, Joakim wrote:
> On Thursday, 11 September 2014 at 21:29:52 UTC, Joakim wrote:
>> On Tuesday, 2 September 2014 at 09:44:29 UTC, Joakim wrote:
>>> The std.string.sformat issue with the phobos tests that I mentioned earlier was in a static ctor for std.net.curl.  Once I removed that module from the test runner, I got 4 phobos modules' tests to pass, 10 modules assert in a test somewhere, 44 seg fault, and 8 say they "Aborted," so I'm 4/69 on the phobos unit tests right now (I got std.traits to compile with a small fix).  Is that about what you guys got when you ran the phobos tests on ARM before?
>>>
>>> I can't say if EH is the main issue or if there are other porting issues, as I haven't started looking into the details yet.
>>
>> I just tried cross-compiling to ARM with the merge-2.066 branch and llvm 3.5 and the latter seems to make a bunch of seg faults go away. :) rt.minfo passes its tests now, but core.time asserts and so does core.internal.convert still.  As for phobos, 3 modules pass, 46 modules assert- 41 of which assert in one test in std.format, not sure why other modules are running tests for std.format- only 9 segfault, and 10 are "Aborted," so I'm down to 3/69 now, but hopefully much easier to fix with less segfaults.
>>
>> I didn't get this improvement with merge-2.066 and llvm 3.4, so it's definitely llvm 3.5 that made the difference, not sure why.
>
> More good news, the sieve.d sample file from dmd's repo now not only compiles fine against phobos but doesn't spit out junk output anymore, ie it works.  I wish all ldc problems could just be solved by an llvm upgrade like this. ;)

Yikes, spoke too soon, it prints out the first line and then segfaults.  I guess this is an improvement over junk output.

On Thursday, 11 September 2014 at 21:48:43 UTC, Joakim wrote:
> On Thursday, 11 September 2014 at 21:44:29 UTC, Joakim wrote:
>> More good news, the sieve.d sample file from dmd's repo now not only compiles fine against phobos but doesn't spit out junk output anymore, ie it works.  I wish all ldc problems could just be solved by an llvm upgrade like this. ;)
>
> Yikes, spoke too soon, it prints out the first line and then segfaults.  I guess this is an improvement over junk output.

Got the segfault in the sieve program to go away by changing the default calling convention for all linkage types in gen/abi.cpp to C, just as Kai did on PPC64.  I don't get any "Aborted" tests now either.

One issue cropping up in std.format appears to be with structs that use alias this for a member, specifically these two:

https://github.com/D-Programming-Language/phobos/blob/master/std/format.d#L1307
https://github.com/D-Programming-Language/phobos/blob/master/std/format.d#L1748

The first one returns false, the second one returns a junk number for the imaginary component of the complex number.  Not sure why it fails for some structs that use alias this and not others, going to look into it.

Another issue is that the dwarf output for debugging might be corrupted somehow.  If I compile sieve.d and have it run fine against non-debug druntime/phobos, it then segfaults in different places if I link it against debug druntime or phobos, which are simply compiled with the -g flag.

Finally, many modules still claim that they assert in a test in std.format, when std.format itself says that test passes, weird.

On Monday, 15 September 2014 at 07:33:26 UTC, Joakim wrote:
> Got the segfault in the sieve program to go away by changing the default calling convention for all linkage types in gen/abi.cpp to C, just as Kai did on PPC64.  I don't get any "Aborted" tests now either.
>
> One issue cropping up in std.format appears to be with structs that use alias this for a member, specifically these two:
>
> https://github.com/D-Programming-Language/phobos/blob/master/std/format.d#L1307
> https://github.com/D-Programming-Language/phobos/blob/master/std/format.d#L1748
>
> The first one returns false, the second one returns a junk number for the imaginary component of the complex number.  Not sure why it fails for some structs that use alias this and not others, going to look into it.

Hey Kai, I see that you just mentioned that you're still trying ldc on linux/ARM.  I never got an answer to my question before: how many tests pass for you when running on linux/ARM?  I've detailed my results here: most of druntime passes while most of phobos doesn't.

> Another issue is that the dwarf output for debugging might be corrupted somehow.  If I compile sieve.d and have it run fine against non-debug druntime/phobos, it then segfaults in different places if I link it against debug druntime or phobos, which are simply compiled with the -g flag.

I figured out what the problem was with debug: it's that codeGenOptLevel() in gen/optimizer.cpp turns off all optimizations when generating debug symbols is turned on.  As we both noted previously that ldc is generating buggy code for -O0 with ARM, the problem is with the generated code, not debug output.  If I patch that ldc function so that debug output can be used with different optimization levels, I can debug again on linux/ARM if I use an optimization level of -O1 or higher, though I haven't tested it extensively.

I had tried using different optimization levels with debug before, but didn't know ldc was silently turning it off till now.  I notice that clang doesn't seem to turn optimization off for debug and that the ldc patch that turned optimization off is more than five years old: perhaps it's not necessary?