LDC 0.12.0 has been released
code at klickverbot.at
Wed Oct 23 08:41:30 PDT 2013
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
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
More information about the digitalmars-d-ldc