www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Has anyone been successful using 64-bit release dmd on Windows?

reply Atila Neves <atila.neves gmail.com> writes:
After too many days of frustration to be able to count, I finally 
discovered what works for our builds: the debug build of 64-bit 
dmd on Windows.

When I build the release version from the Makefile or use digger, 
it produces a dmd binary that crashes randomly (bad enough) or 
compiles executables which themselves crash or run forever (much, 
much worse).

In all cases I installed dmd 2.080.0 from the installer then just 
copied over dmd.exe over the 32-bit one. I can't see what reason 
there'd be for the pre-built druntime and phobos binaries to not 
work just because dmd changed from 32-bit to 64-bit. But who 
knows.

This post is both a warning to the intrepid D programmers out 
there who'd rather not hit a 4GB RAM limit for no reason on 
Windows and also a question to see if anybody has been able to 
use 64-bit dmd on Windows like <insert deity here> intended.

Slightly slower builds are definitely better than ones that are 
flaky or hit gitlab's time limit.

Atila
Jun 13 2018
next sibling parent Ethan <gooberman gmail.com> writes:
On Wednesday, 13 June 2018 at 17:13:09 UTC, Atila Neves wrote:
 This post is both a warning to the intrepid D programmers out 
 there who'd rather not hit a 4GB RAM limit for no reason on 
 Windows and also a question to see if anybody has been able to 
 use 64-bit dmd on Windows like <insert deity here> intended.
Works For Me(TM). But, as I mentioned in a thread a few weeks back, I open the Visual Studio solution and compile with the help of VisualD. I also just dump the resultant .exe over the release version. I guess it's time to repeat the point though: Win64 DMD needs to be released alongside Win32. Day and date.
Jun 13 2018
prev sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Wednesday, 13 June 2018 at 17:13:09 UTC, Atila Neves wrote:
 After too many days of frustration to be able to count, I 
 finally discovered what works for our builds: the debug build 
 of 64-bit dmd on Windows.

 When I build the release version from the Makefile or use 
 digger, it produces a dmd binary that crashes randomly (bad 
 enough) or compiles executables which themselves crash or run 
 forever (much, much worse).
I've used 64-bit DMD exclusively while Windows was my primary OS, but that was a few years ago. Do you have a way to reproduce these problems reliably? If so, a few things you could try to narrow down the problem: - Use DustMite and a test script that compiles a program with 64-bit release dmd.exe and a 32-bit or 64-bit debug dmd.exe, and accepts any reductions in which only the former crashes. - See if this is a regression (do older 64-bit DMDs work OK?), and if so, use Digger to find where it was introduced. - It's possible that the bug occurs not in the compiled DMD code, but in the host DMD compiler. There was at least one recorded case of a bug in the host DMD resulting in a broken built DMD which in turn executed successfully, but built broken programs. A discrepancy between which host DMD compiler is used can sometimes explain why some tests succeed on CI but fail locally, or vice versa.
Jun 13 2018
next sibling parent Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 13 June 2018 at 17:30:34 UTC, Vladimir Panteleev 
wrote:
 On Wednesday, 13 June 2018 at 17:13:09 UTC, Atila Neves wrote:
 After too many days of frustration to be able to count, I 
 finally discovered what works for our builds: the debug build 
 of 64-bit dmd on Windows.

 When I build the release version from the Makefile or use 
 digger, it produces a dmd binary that crashes randomly (bad 
 enough) or compiles executables which themselves crash or run 
 forever (much, much worse).
I've used 64-bit DMD exclusively while Windows was my primary OS, but that was a few years ago. Do you have a way to reproduce these problems reliably? If so, a few things you could try to narrow down the problem: - Use DustMite and a test script that compiles a program with 64-bit release dmd.exe and a 32-bit or 64-bit debug dmd.exe, and accepts any reductions in which only the former crashes.
Until recently, I only had random dmd crashes. It was only yesterday that I managed to get a build that failed consistently. I'll try dustmite on it. On another note, it seems that debug dmd only crashes less frequently. It just crashed on me again.
 - See if this is a regression (do older 64-bit DMDs work OK?), 
 and if so, use Digger to find where it was introduced.
We never had problems up until 2.77.3 if I'm not mistaken.
 - It's possible that the bug occurs not in the compiled DMD 
 code, but in the host DMD compiler. There was at least one 
 recorded case of a bug in the host DMD resulting in a broken 
 built DMD which in turn executed successfully, but built broken 
 programs. A discrepancy between which host DMD compiler is used 
 can sometimes explain why some tests succeed on CI but fail 
 locally, or vice versa.
I tried multiple versions of host dmd. No differences in behaviour. Atila
Jun 13 2018
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 13 June 2018 at 17:30:34 UTC, Vladimir Panteleev 
wrote:
 On Wednesday, 13 June 2018 at 17:13:09 UTC, Atila Neves wrote:
 [...]
I've used 64-bit DMD exclusively while Windows was my primary OS, but that was a few years ago. [...]
Reviewing the dustmite documentation, I'm not sure how the reduction would work when the build that's broken is a dub one that uses local packages.
Jun 13 2018
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Wednesday, 13 June 2018 at 17:54:29 UTC, Atila Neves wrote:
 Reviewing the dustmite documentation, I'm not sure how the 
 reduction would work when the build that's broken is a dub one 
 that uses local packages.
You will need to either reduce the test to a command which does not involve dub (its verbose output can help), or try using "dub dustmite" instead (I can't help much with the latter though).
Jun 13 2018