Walter Bright wrote:
> Don wrote:
>> Oh. And the D1 spec doesn't disallow inline asm in CTFE.
>> But CTFE asm is Not Going To Happen. <g>
> 
> I think that eventually we can get all of SafeD to work in CTFE, but inline asm isn't part of SafeD!

SafeD doesn't appear to be properly defined in the spec. And certainly not mentioned in the CTFE section. Maybe it should be. Of course, very little of SafeD is currently implemented. Should Bartosz' article be taken as authoritative? (eg, he says 'union' is not permitted in SafeD, so CTFE should probably ban it).

Don wrote:
> Walter Bright wrote:
>> Don wrote:
>>> Oh. And the D1 spec doesn't disallow inline asm in CTFE.
>>> But CTFE asm is Not Going To Happen. <g>
>>
>> I think that eventually we can get all of SafeD to work in CTFE, but inline asm isn't part of SafeD!
> 
> SafeD doesn't appear to be properly defined in the spec. And certainly not mentioned in the CTFE section. Maybe it should be. Of course, very little of SafeD is currently implemented. Should Bartosz' article be taken as authoritative? (eg, he says 'union' is not permitted in SafeD, so CTFE should probably ban it).

Certainly unions that alias references with non-references should not be permitted, but aliasing an int with a float should be permitted.

Walter Bright wrote:
> This will probably be the last OSX 10.5 release, the next should be 10.6.
> 
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.047.zip
> 
> 
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.032.zip
> 
> Many thanks to the numerous people who contributed to this update.

You can tell it's a good release when you have to do more than a simple merge to get it working with ldc ;)

I've pretty much finished merging dmd 2.032 into ldc, there's one issue remaining though. In statement.c, a new function, os_critsecsize() is used, which the front end now depends upon. With the function being in the back end, the license doesn't permit its inclusion in ldc, which prevents me finalizing this merge. If you're reading this Walter, could you please release the function under a license which will allow inclusion in ldc, or alternatively remove the dependency?

Thanks,

Robert

Robert Clipsham Wrote:

> You can tell it's a good release when you have to do more than a simple merge to get it working with ldc ;)
> 
> I've pretty much finished merging dmd 2.032 into ldc,  ...

Does this mean an official D2 LDC will be coming out shortly?

Jason House wrote:
> Robert Clipsham Wrote:
> 
>> You can tell it's a good release when you have to do more than a simple merge to get it working with ldc ;)
>>
>> I've pretty much finished merging dmd 2.032 into ldc,  ...
> 
> Does this mean an official D2 LDC will be coming out shortly?

Unlikely, sorry. LDC 2 is in a very early alpha state. Currently a custom version of druntime compiles (a patch has been submitted), how much of it functions correctly remains to be seen. Anything using the GC doesn't work as some of the GC code segfaults, and about 90% of phobos doesn't compile. How soon LDC 2 appears will more than likely depend on if anyone else takes an interest in developing it, I don't have enough time to really dig into it and make it a fully functioning D2 compiler unfortunately.

Robert Clipsham wrote:
> Walter Bright wrote:
>> This will probably be the last OSX 10.5 release, the next should be 10.6.
>>
>> http://www.digitalmars.com/d/1.0/changelog.html
>> http://ftp.digitalmars.com/dmd.1.047.zip
>>
>>
>> http://www.digitalmars.com/d/2.0/changelog.html
>> http://ftp.digitalmars.com/dmd.2.032.zip
>>
>> Many thanks to the numerous people who contributed to this update.
> 
> You can tell it's a good release when you have to do more than a simple merge to get it working with ldc ;)
> 
> I've pretty much finished merging dmd 2.032 into ldc, there's one issue remaining though. In statement.c, a new function, os_critsecsize() is used, which the front end now depends upon. With the function being in the back end, the license doesn't permit its inclusion in ldc, which prevents me finalizing this merge. If you're reading this Walter, could you please release the function under a license which will allow inclusion in ldc, or alternatively remove the dependency?
> 
> Thanks,
> 
> Robert

Actually, never mind, Tomas informed me how to do the same thing using LDCs code, just #if'd around it.

Robert Clipsham wrote:
> You can tell it's a good release when you have to do more than a simple merge to get it working with ldc ;)

I try to simplify things in the back end by moving more to the front end.

> I've pretty much finished merging dmd 2.032 into ldc, there's one issue remaining though. In statement.c, a new function, os_critsecsize() is used, which the front end now depends upon. With the function being in the back end, the license doesn't permit its inclusion in ldc, which prevents me finalizing this merge. If you're reading this Walter, could you please release the function under a license which will allow inclusion in ldc, or alternatively remove the dependency?

All it does is return a compile time constant. I don't think anyone could make a case out of that.

Robert Clipsham wrote:
> Unlikely, sorry. LDC 2 is in a very early alpha state. Currently a custom version of druntime compiles (a patch has been submitted), how much of it functions correctly remains to be seen. Anything using the GC doesn't work as some of the GC code segfaults, and about 90% of phobos doesn't compile. How soon LDC 2 appears will more than likely depend on if anyone else takes an interest in developing it, I don't have enough time to really dig into it and make it a fully functioning D2 compiler unfortunately.

What's the essential problem?

Walter Bright wrote:
> Robert Clipsham wrote:
>> Unlikely, sorry. LDC 2 is in a very early alpha state. Currently a custom version of druntime compiles (a patch has been submitted), how much of it functions correctly remains to be seen. Anything using the GC doesn't work as some of the GC code segfaults, and about 90% of phobos doesn't compile. How soon LDC 2 appears will more than likely depend on if anyone else takes an interest in developing it, I don't have enough time to really dig into it and make it a fully functioning D2 compiler unfortunately.
> 
> What's the essential problem?

LDC 2 is essentially just LDC (a D1 compiler) with the dmd 2 frontend instead of the dmd 1 frontend. As you can imagine this leaves quite a lot of what's passed to LDC unhandled or handled the way it would be in D1 instead of D2 (leading to bad codegen, probably the reason the GC segfaults, yet to investigate that though). I'm also pretty sure some of the frontend still needs tweaking so it passes what ldc is expecting to it rather than what the dm backend expects.

When LDC 2 starts making some progress I'll try and put a patch together for you to simplify merges for us, I'll let you know if there's anything else you can do to aid development as we progress :)

Walter Bright wrote:
> Robert Clipsham wrote:
>> You can tell it's a good release when you have to do more than a simple merge to get it working with ldc ;)
> 
> I try to simplify things in the back end by moving more to the front end.

Sounds like a good philosophy to me.

> All it does is return a compile time constant. I don't think anyone could make a case out of that.

I thought I better check anyway, you never know :) Doesn't matter too much now anyway, turns out the LDC backend had something similar to handle it.