Some files in our copy of the DMD 2 source had CRLF line endings.
This was not only inconsistent, but also made merging DMD patches
(where LF is used throughout) unnecessarily painful.
- New functions codeGenOptLevel() and verifyModule() to remove code duplication
- Hidden option no-verify renamed to disable-verify and moved to optimizer (like opt tool)
- Removed global.params.noVerify
This is based on Item 2 of "More Effective C++". In general, the C++ cast operators are more expressive and easy to find,
e.g. by grep. Using const_cast also shuts up some compiler warnings.
This is based on Item 2 of "More Effective C++". In general, the C++ cast operators are more expressive and easy to find,
e.g. by grep. Using const_cast also shuts up some compiler warnings.
This is based on Item 2 of "More Effective C++". In general, the C++ cast operators are more expressive and easy to find,
e.g. by grep. Using const_cast also shuts up some compiler warnings.
This is based on Item 2 of "More Effective C++". In general, the C++ cast operators are more expressive and easy to find,
e.g. by grep. Using const_cast also shuts up some compiler warnings.
- Relax version checking because we intend to have only a single branch
- Exclude ldfpu.asm from build with MSVC-32 (reported by huynh van sen)
- Fix FindLLVM.cmake to work on Windows again
This leads to missing symbols during linking on Windows x64. If
this changes breaks other Windows platforms then we have to analyze
the triple instead of global.params.os.
Not sure why the code was special-cased for D2 in the first place –
are there any cases where we expect a »full« context struct in the
contracts for D1. At least, they don't occur in DStress/Tango/….
As a general note, this is one of many bugs which would have not gone
unnoticed if we didn't use so many bitcasts.
The Phobos changes have, as far as I can tell, already landed in
upstream master as well. But since 2.060 will probably take some time
to arrive, I figured it makes sense to merge them right now, so that
collaboration on ARM support can continue.
This should eventually be done on x86 and x86_64 as well, but as
discussed in GitHub issue #110/pull request #120, the ABI there needs a
closer look: at least on x86_64, we need to treat static arrays exactly
like if they were a struct containing T.length members of the same type
to be compatible with DMD (as soon as the ABI is correctly implemented
there, that is).
While for this reason I want to avoid a ABI change which could silently
break some code only to change the x86 ABI again shortly after, this
commit only touches the "default" ABI for unknown targets and thus
should be safe (as we give absoultely no ABI guarantees there anyway).
