Does anyone have a guide on how to debug DMD crashes? I've been getting compiler crashes on version 2.087.1 through 2.091.0 (only release mode on both Windows 10 and Linux). Version 2.086.1 was the last one that worked:

dub run --arch=x86_64 --build=release

C:\D\dmd2\windows\bin\dmd.exe failed with exit code -1073741795.

Here is the smallest code snippet I could make crash: https://github.com/workhorsy/crash_dmd

On Sunday, 22 March 2020 at 22:33:13 UTC, Matt Jones wrote:
> Does anyone have a guide on how to debug DMD crashes? I've been getting compiler crashes on version 2.087.1 through 2.091.0 (only release mode on both Windows 10 and Linux). Version 2.086.1 was the last one that worked:
>
> dub run --arch=x86_64 --build=release
>
> C:\D\dmd2\windows\bin\dmd.exe failed with exit code -1073741795.
>
> Here is the smallest code snippet I could make crash: https://github.com/workhorsy/crash_dmd

Ah very interesting!

Unfortunately I am not good at writing guides, but I will debug this and record a video, of what I do.
Would that be acceptable to you?
-
Stefan

On Sunday, 22 March 2020 at 22:37:08 UTC, Stefan Koch wrote:
> On Sunday, 22 March 2020 at 22:33:13 UTC, Matt Jones wrote:
>> Does anyone have a guide on how to debug DMD crashes? I've been getting compiler crashes on version 2.087.1 through 2.091.0 (only release mode on both Windows 10 and Linux). Version 2.086.1 was the last one that worked:
>>
>> dub run --arch=x86_64 --build=release
>>
>> C:\D\dmd2\windows\bin\dmd.exe failed with exit code -1073741795.
>>
>> Here is the smallest code snippet I could make crash: https://github.com/workhorsy/crash_dmd
>
> Ah very interesting!
>
> Unfortunately I am not good at writing guides, but I will debug this and record a video, of what I do.
> Would that be acceptable to you?
> -
> Stefan

I hope so. Thanks!

On Sunday, 22 March 2020 at 22:33:13 UTC, Matt Jones wrote:
> Does anyone have a guide on how to debug DMD crashes? I've been getting compiler crashes on version 2.087.1 through 2.091.0 (only release mode on both Windows 10 and Linux). Version 2.086.1 was the last one that worked:
>
> dub run --arch=x86_64 --build=release
>
> C:\D\dmd2\windows\bin\dmd.exe failed with exit code -1073741795.
>
> Here is the smallest code snippet I could make crash: https://github.com/workhorsy/crash_dmd

Since it crashes when you do a release build, this is most likely a bug in the backend. DMD's backend is known to have a lot of issues and they don't tend to be fixed as there's only a few people that actually work on it. Even if someone outside of the main D team fixes the bug, the fix won't get merged in for release as those same individuals don't bother to review those pull requests.

You'll probably have better luck using LDC2, which has a tried and proven backend LLVM. It doesn't compile as fast, but I find the few seconds is worth the trade off of not having to deal with as many compiler bugs like the one you've found here.

https://github.com/ldc-developers/ldc#installation

On Sunday, 22 March 2020 at 22:33:13 UTC, Matt Jones wrote:
> Does anyone have a guide on how to debug DMD crashes? I've been getting compiler crashes on version 2.087.1 through 2.091.0 (only release mode on both Windows 10 and Linux). Version 2.086.1 was the last one that worked:
>
> dub run --arch=x86_64 --build=release
>
> C:\D\dmd2\windows\bin\dmd.exe failed with exit code -1073741795.
>
> Here is the smallest code snippet I could make crash: https://github.com/workhorsy/crash_dmd

Hi, so I've found out what's going on.

An assertion in CSE (Common Subexpression Elimination) fails.
Which means that this is indeed an optimizer bug in the backend.
I can not yet say how to fix it but is should be enough for you to file a bug report.

The steps I took to find this are the following
1. Compile dmd with debug symbols.
2. use dub -v to see the compile commandline which fails.
3. run the commandline under gdb. (gdb --args)
4. look at where the failure happens.

On Monday, 23 March 2020 at 00:17:48 UTC, Arine wrote:
> You'll probably have better luck using LDC2, which has a tried and proven backend LLVM. It doesn't compile as fast, but I find the few seconds is worth the trade off of not having to deal with as many compiler bugs like the one you've found here.

How common is this sentiment among D developers?

I've been patiently waiting for a dustmite reduction over the last few days, trying to be a good citizen and produce a bug report for something that has been preventing me from using DMD for months now. Actually it's my 2nd DMD-blocking bug, but the previous one was only stopping Mac/Linux, now I'm limited to LDC2 on all 3 platforms.

I would love for my code to be compatible with all D compilers, and have the speed benefit of prototyping with DMD for myself, but I'm not too keen on becoming a compiler spelunker given all the other claims on my time. (For what it's worth I'm not doing anything fancy or esoteric - just bad luck, I guess)

So I'm curious if other devs doggedly pursue DMD bugs until they are fixed, or if they just throw their hands up and use LDC2. My deeper fear is that someday I'm going to hit a frontend bug and won't have the skills or capital to get it solved :(

On Tuesday, 24 March 2020 at 16:11:40 UTC, DanielG wrote:
> On Monday, 23 March 2020 at 00:17:48 UTC, Arine wrote:
>> You'll probably have better luck using LDC2, which has a tried and proven backend LLVM. It doesn't compile as fast, but I find the few seconds is worth the trade off of not having to deal with as many compiler bugs like the one you've found here.
>
> How common is this sentiment among D developers?
>
> I've been patiently waiting for a dustmite reduction over the last few days, trying to be a good citizen and produce a bug report for something that has been preventing me from using DMD for months now. Actually it's my 2nd DMD-blocking bug, but the previous one was only stopping Mac/Linux, now I'm limited to LDC2 on all 3 platforms.
>
> I would love for my code to be compatible with all D compilers, and have the speed benefit of prototyping with DMD for myself, but I'm not too keen on becoming a compiler spelunker given all the other claims on my time. (For what it's worth I'm not doing anything fancy or esoteric - just bad luck, I guess)
>
> So I'm curious if other devs doggedly pursue DMD bugs until they are fixed, or if they just throw their hands up and use LDC2. My deeper fear is that someday I'm going to hit a frontend bug and won't have the skills or capital to get it solved :(

I can only give one data point, but I started using D in 2013 and have never run into a compiler bug. My use case is primarily as a better C (using the full D language, but working with C libraries). I use mostly basic D features, none of the fancy stuff, so I'm probably not venturing into the less-tested parts of the language very often.

On Tue, Mar 24, 2020 at 04:11:40PM +0000, DanielG via Digitalmars-d wrote:
> On Monday, 23 March 2020 at 00:17:48 UTC, Arine wrote:
> > You'll probably have better luck using LDC2, which has a tried and proven backend LLVM. It doesn't compile as fast, but I find the few seconds is worth the trade off of not having to deal with as many compiler bugs like the one you've found here.
[...]
> I would love for my code to be compatible with all D compilers, and have the speed benefit of prototyping with DMD for myself, but I'm not too keen on becoming a compiler spelunker given all the other claims on my time. (For what it's worth I'm not doing anything fancy or esoteric - just bad luck, I guess)

There's ldmd2, an LDC wrapper that works more-or-less as a drop-in replacement for dmd.  Unless you're using esoteric DMD command-line options, you can essentially just replace 'dmd' with 'ldmd2' and it should Just Work(tm).  For GDC, there's also a similar wrapper for the same purpose.


> So I'm curious if other devs doggedly pursue DMD bugs until they are fixed, or if they just throw their hands up and use LDC2. My deeper fear is that someday I'm going to hit a frontend bug and won't have the skills or capital to get it solved :(

All D compilers currently share the same frontend, so you don't have to worry about that.  Most DMD bugs being actively fixed are frontend bugs, and directly benefit the other 2 compilers.  Only a small number of people are actively working on the DMD backend (mainly just Walter, plus one or two others occasionally), and its codegen quality, sorry to say, leaves a lot to be desired.  Its only redeeming quality currently is its lightning speed.

I've recently switched to LDC for all of my new D projects, and use DMD only occasionally for single-module development because of its quick turn-around time (dmd -i -unittest -main is great for fast development of a single module / cluster of related modules). While LDC does add a few seconds to the compile-time, I find the superior codegen quality to be more than worth the cost.  Armed with ldmd2, you don't even have to change your build setup except to substitute 'dmd' with 'ldmd2', for the most part.  I highly recommend it.


T

-- 
The richest man is not he who has the most, but he who needs the least.

On Tue, Mar 24, 2020 at 05:33:26PM +0000, bachmeier via Digitalmars-d wrote: [...]
> I can only give one data point, but I started using D in 2013 and have never run into a compiler bug. My use case is primarily as a better C (using the full D language, but working with C libraries). I use mostly basic D features, none of the fancy stuff, so I'm probably not venturing into the less-tested parts of the language very often.

I've been using D since around late 2011 / early 2012, and have run into a number of DMD bugs -- wrong codegens, ICEs, and problems with the optimization flags.  I'd say the majority are front-end bugs, most of which have been fixed since, and a smaller number of backend bugs.  It's already bad enough that the backend produces code with not-so-great performance; what makes it worse is that some of the backend bugs I've run into are triggered by optimization flags, meaning that my only recourse was to live off *unoptimized DMD output*.

Recently I've switched to LDC for optimized builds, and it's been great. I still use DMD occasionally for subsystem development -- the lightning fast turnaround times is great for the code-compile-test cycle -- but overall I've been finding that LDC's superior codegen is more than worth the cost of a few added seconds to compile times.


T

-- 
People demand freedom of speech to make up for the freedom of thought which they avoid. -- Soren Aabye Kierkegaard (1813-1855)

On 25/03/2020 6:55 AM, H. S. Teoh wrote:
> On Tue, Mar 24, 2020 at 05:33:26PM +0000, bachmeier via Digitalmars-d wrote:
> [...]
>> I can only give one data point, but I started using D in 2013 and have
>> never run into a compiler bug. My use case is primarily as a better C
>> (using the full D language, but working with C libraries). I use
>> mostly basic D features, none of the fancy stuff, so I'm probably not
>> venturing into the less-tested parts of the language very often.
> 
> I've been using D since around late 2011 / early 2012, and have run into
> a number of DMD bugs -- wrong codegens, ICEs, and problems with the
> optimization flags.  I'd say the majority are front-end bugs, most of
> which have been fixed since, and a smaller number of backend bugs.  It's
> already bad enough that the backend produces code with not-so-great
> performance; what makes it worse is that some of the backend bugs I've
> run into are triggered by optimization flags, meaning that my only
> recourse was to live off *unoptimized DMD output*.
> 
> Recently I've switched to LDC for optimized builds, and it's been great.
> I still use DMD occasionally for subsystem development -- the lightning
> fast turnaround times is great for the code-compile-test cycle -- but
> overall I've been finding that LDC's superior codegen is more than worth
> the cost of a few added seconds to compile times.

Similar-ish story for me.

Except I have encountered an ICE in debug info.

Along with bugs in ldc that end in a very undesirable target/compiler configuration.

They have since been fixed :)