LDC 0.12.0 has been released

[simendsjo]

On Wednesday, 23 October 2013 at 15:41:42 UTC, David Nadlinger 
wrote:
> On Wed, Oct 23, 2013 at 3:46 PM, simendsjo 
> <simendsjo at gmail.com> wrote:
>> My code doesn't compile on dmd 2.063.2, but it does with ldc - 
>> how is this
>> possible?
>
> There are two possible reasons for this: First, while the 
> frontend we
> use is reasonably close to the upstream DMD version (and work 
> is going
> on to get it even closer), there are still quite a few areas 
> where LDC
> handles things differently.
>
> Second (but what I gathered from your reference to .stringof, 
> that
> doesn't seem to be the case here), not all errors are actually 
> emitted
> in the frontend as they should. In some (relatively rare) 
> cases, it
> can be that our glue code can actually generate code for 
> something
> that DMD can't handle. Usually, this would rather be things like
> mixing exception handling and alloca(), etc.
>
>
>> Another issue is build times. I know dmd should be faster, but 
>> 4x faster..?
>
> Well, DMD is quite heavily optimized for speed, while there has 
> been
> hardly done any work on that front for LDC at all. 4x seems to 
> be a
> bit excessive indeed (at least for an unoptimized build), so 
> might be
> time for somebody to sit down with a profiler. ;)
>
>
>> And the resulting binary just hangs and doesn't use any 
>> resources.
>> It gets into the main method, but somewhere it just stops.
>>
>> How can I help locate the error?
>
> With "somewhere it just stops", you are referring to hanging 
> instead
> of terminating, right? The first step would then be to figure 
> out
> where this actually happens. Either sprinkle your codebase with
> printf's, or just attach GDB to the process and press Ctrl+C. 
> This
> should interrupt execution in the call that is blocking 
> execution,
> allowing you to get a backtrace and thus hopefully pin down 
> where the
> problem is.
>
> David

This is way beyond what I'm able to make sense of...


#0  0x00007ffff65149f3 in __epoll_wait_nocancel () from 
/usr/lib/libc.so.6
#1  0x00007ffff79b7ae3 in ?? () from /usr/lib/libevent-2.0.so.5
#2  0x00007ffff79a3660 in event_base_loop () from 
/usr/lib/libevent-2.0.so.5
#3  0x00000000004cc4f4 in 
vibe.core.drivers.libevent2.Libevent2Driver.runEventLoop() 
(this=0x7ffff7ec98c0) at libevent2.d:122
#4  0x00000000004d8357 in vibe.core.core.runEventLoop() () at 
core.d:84
#5  0x0000000000545eb8 in D main () at appmain.d:57
#6  0x0000000000646cf1 in rt.dmain2._d_run_main() ()
#7  0x000000000064659a in rt.dmain2._d_run_main() ()
#8  0x0000000000646d47 in rt.dmain2._d_run_main() ()
#9  0x000000000064659a in rt.dmain2._d_run_main() ()
#10 0x000000000064654f in _d_run_main ()
#11 0x0000000000646103 in main ()



Dump of assembler code for function __epoll_wait_nocancel:
    0x00007ffff65149e9 <+0>:     mov    %rcx,%r10
    0x00007ffff65149ec <+3>:     mov    $0xe8,%eax
    0x00007ffff65149f1 <+8>:     syscall
=> 0x00007ffff65149f3 <+10>:    cmp    $0xfffffffffffff001,%rax
    0x00007ffff65149f9 <+16>:    jae    0x7ffff6514a2f 
<epoll_wait+79>
    0x00007ffff65149fb <+18>:    retq
End of assembler dump.