D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 3601 - Debug and Release builds of DMD produce different object files
Summary: Debug and Release builds of DMD produce different object files
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: Other Windows
: P2 critical
Assignee: No Owner
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-08 07:46 UTC by Koroskin Denis
Modified: 2015-06-09 01:26 UTC (History)
1 user (show)

See Also:

Attachments
Test case that reproduces described behavior (6.06 KB, application/octet-stream)
2009-12-08 07:47 UTC, Koroskin Denis 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description Koroskin Denis 2009-12-08 07:46:08 UTC 
(Not to be confused with -debug and -release DMD options)

I finally managed to cut that sucker down (took me almost entire day to track it down and reduce to reasonable size)!

The test case is attached, compile it as follows:

dmd -c -d thread.d

Tested on DMD2.032, Windows only.

I believe Debug version produces corrupted binaries as linking sometimes fails giving me a "library is corrupted" message.

I should add that this one is very annoying as it prevents ddmd from working properly (it only works in debug mode ATM and debug version of backend produces odd binaries).
Comment 1 Koroskin Denis 2009-12-08 07:47:32 UTC 
Created attachment 523 [details]
Test case that reproduces described behavior

Based off druntime/core/thread.d file
Comment 2 Walter Bright 2009-12-12 01:49:46 UTC 
Changeset 293 gets them to produce the same .obj files, but both ways were within spec and I've never seen either produce a "library is corrupted" message. So I'll set this as fixed, and if the corruption message appears again, please file a new issue.
Comment 3 Walter Bright 2009-12-31 11:16:20 UTC 
Fixed dmd 1.054 and 2.038