On Sunday, 2 June 2013 at 14:30:41 UTC, Temtaime wrote:
> I'm figured out testcase.
>
> It's too strange.
>
> http://dpaste.1azy.net/c3f8b2d9

Ah, great, thanks. Actually, the code hits an assertion in a debug build much earlier:

———
/home/aule/Build/Source/ldc/dmd2/template.c:5900: Identifier* TemplateInstance::genIdent(Objects*): Assertion `global.errors' failed.
———

On your reduced test case, DMD 2.062 fails with exactly the same assertion message. Does your original codebase compiles with DMD 2.062?

David

On Sun, Jun 2, 2013 at 4:31 PM, Temtaime <temtaime@gmail.com> wrote:
> So, there is no error on ldc 2.060 on dpaste.

Yes, it's a problem (regression) in the DMD 2.062 frontend, not in LDC.

David

I'm modified a little testcase: http://dpaste.1azy.net/69cb277c

So it's compiles on ldc 2.060. There also error with GDC.

I don't know if there is an error with dmd 2.062, because i'm using 2.063 beta for a long time.

Can u build ldc based on 2.063 frontend ?

On Sun, Jun 2, 2013 at 4:40 PM, Temtaime <temtaime@gmail.com> wrote:
> I'm modified a little testcase: http://dpaste.1azy.net/69cb277c

Still fails with DMD 2.062. I'm afraid we won't be able to fix this for this release, as the error is not in actual LDC territory, and back-porting this kind DMD patches can be a rather complicated affair due to unintended side effects. Might be worth a look, though, if we can locate the exact commit that fixed the regression.

> Can u build ldc based on 2.063 frontend ?

Not easily, it's a manual process that usually entails quite a bit of head-scratching, because there are often "behind-the-scenes" regressions that don't affect the DMD backend, but break our glue code.

In any case, updating the frontend is planned for the next release, which will hopefully come out in three weeks or so (my plan is to tackle the merge into the development tree rather quickly, though, so you might be able to use Git master much quicker).

David

I hope that release will come to us soon, because our team writing 3D engine, so DMD produces code of low quality. I prefer LLVM, because it's being developed by Google and Apple and has great optimizer.

Thanks for your answers.

Two serious issues have been fixed since beta 1:
 - https://github.com/ldc-developers/ldc/pull/375
 - https://github.com/ldc-developers/ldc/pull/379

Right now, I'm having a look at the feasibility of fixing https://github.com/ldc-developers/ldc/issues/372 for the release, which is critical for getting a working LLVM 3.3-based OS X build.

I'll spin a new beta in a few hours.

David

On Sunday, 2 June 2013 at 19:51:54 UTC, David Nadlinger wrote:
> Right now, I'm having a look at the feasibility of fixing https://github.com/ldc-developers/ldc/issues/372 for the release, which is critical for getting a working LLVM 3.3-based OS X build.

Scratch that, either too risky or would delay the release for too long.

My old new plan is to release Beta 2 for OS X as well, based on LLVM 3.2, and if no further blockers appear, declare that the final release. A new LLVM 3.3-based release would be pushed out as soon as the switch to storing bools as i8 has been completed. Sounds good?

I'm building/uploading the packages right now, should be ready in a few hours.

David