I just checked in a slew of changes.  These bring druntime and phobos up to the point that running the tests pass.  However, I did that by disabling (for 64 bit only), all the tests that fail.  This is basically what the auto-tester has been doing for a while now.  At this point, anyone can replicate those builds, which is handy.

That said, it's still not up to the point of being useful for anything. Optimized builds are much worse off than non-opt builds.  The GC is broken in as-of-yet uninvestigated ways.  Without optimizations, about 2/3 of both the phobos tests and the dmd tests pass.  With optimizations, less than half.

If anyone is interested in helping, the biggest things I'd really like to see:

1) druntime's tests changed to be like phobos'.  In other words, one test app per .d file.  This makes it so much simpler to dig into what's going wrong.  Before anyone takes this as a point of failure of D's unittests, I think bootstrapping from totally broken is a very different case from a mostly working setup and digging into new issues.

2) implement the asm code in std/math.d.

3) dig into the gc and figure out what's broken.  I believe walter has the d1 gc working, but I haven't spent any time looking at the changes there. There's enough differences that it likely won't be directly mergable and won't be complete.  A good start would be the dmd tests runnable/testgc* or possibly runnable/wc*.

Keep in mind that we're still fixing all three layers at the same time. Any one of which can be at fault for any failure.

Later,
Brad

Great work!  See details below:

On Thu, Dec 23, 2010 at 3:52 PM, Brad Roberts <braddr at puremagic.com> wrote:

>
> 1) druntime's tests changed to be like phobos'.  In other words, one test app per .d file.  This makes it so much simpler to dig into what's going wrong.  Before anyone takes this as a point of failure of D's unittests, I think bootstrapping from totally broken is a very different case from a mostly working setup and digging into new issues.
>

Shouldn't this conversion be automatable?


> 2) implement the asm code in std/math.d.
>

Failing this, IMHO all math functions that don't already (I'm not sure how many don't) should have a portable implementation (which could be just calling C) that meets all requirements (safe, pure, nothrow, etc.).  This would be "good enough" until someone gets around to writing optimized ASM versions of the math functions, and would probably make it easier for the GDC/LDC people to port D to more archs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20101223/386647e4/attachment.html>

???

On 23 December 2010 22:03, David Simcha <dsimcha at gmail.com> wrote:
> Great work!? See details below:
>
> On Thu, Dec 23, 2010 at 3:52 PM, Brad Roberts <braddr at puremagic.com> wrote:
>>
>> 1) druntime's tests changed to be like phobos'. ?In other words, one test app per .d file. ?This makes it so much simpler to dig into what's going wrong. ?Before anyone takes this as a point of failure of D's unittests, I think bootstrapping from totally broken is a very different case from a mostly working setup and digging into new issues.
>
> Shouldn't this conversion be automatable?
>
>>
>> 2) implement the asm code in std/math.d.
>
> Failing this, IMHO all math functions that don't already (I'm not sure how
> many don't) should have a portable implementation (which could be just
> calling C) that meets all requirements (safe, pure, nothrow, etc.)

The problem is, the C functions are *not* pure. They modify errno.
But, you can just lie -- put  pure nothrow @safe{} around the C
functions in core.stdc.math.
(I wouldn't want that to be included in an official release, but it's
no problem for testing).


>.? This
> would be "good enough" until someone gets around to writing optimized ASM versions of the math functions, and would probably make it easier for the GDC/LDC people to port D to more archs.

On Thu, 23 Dec 2010, Don Clugston wrote:

> On 23 December 2010 22:03, David Simcha <dsimcha at gmail.com> wrote:
> >
> > On Thu, Dec 23, 2010 at 3:52 PM, Brad Roberts <braddr at puremagic.com> wrote:
> >>
> >> 2) implement the asm code in std/math.d.
> >
> > Failing this, IMHO all math functions that don't already (I'm not sure how
> > many don't) should have a portable implementation (which could be just
> > calling C) that meets all requirements (safe, pure, nothrow, etc.)
> 
> The problem is, the C functions are *not* pure. They modify errno.
> But, you can just lie -- put  pure nothrow @safe{} around the C
> functions in core.stdc.math.
> (I wouldn't want that to be included in an official release, but it's
> no problem for testing).

Could be done, but they're not blocking issues yet.. there's pleanty of other things to work through still.  If I do get blocked, it's what I'll do.  But like you said, it's stop gap at best.

Later,
Brad

On Thu, 23 Dec 2010, David Simcha wrote:
> 
> On Thu, Dec 23, 2010 at 3:52 PM, Brad Roberts <braddr at puremagic.com> wrote:
> 
> > 1) druntime's tests changed to be like phobos'.  In other words, one test app per .d file.  This makes it so much simpler to dig into what's going wrong.  Before anyone takes this as a point of failure of D's unittests, I think bootstrapping from totally broken is a very different case from a mostly working setup and digging into new issues.
> >
> 
> Shouldn't this conversion be automatable?

Not sure about automatable, but fairly mechanical.  I just haven't done it yet and was listing it as something that I think would be useful.
-------------- next part --------------
_______________________________________________
dmd-internals mailing list
dmd-internals at puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals