build dmd with Microsoft compiler #516

Merged
merged 11 commits into from Feb 25, 2012

Conversation

Projects
None yet
4 participants
Member

rainers commented Nov 19, 2011

As discussed on the mailing list, here are my changes to build dmd with the microsoft compiler (v15 from VS2008). Apart from minor changes to actually make it compile, pushing it through the test suite needed

  • replacement for "long double" as 80-bit floats are not supported. I've created root\longdouble.c/h for that purpose with asm implementations using the FPU. As this type is also used by the backend it has to be included from cdef.h aswell.
  • C99 support for sprintf et al: %j and %z have been replaced by %llu and casts for arguments of %z. %Lg and %La are now using calls to ld_sprint. A number of cleanups would be possible with respect to IN_GCC using real_t as the implementation of longdouble, because it uses real_t::format to write hex floating point numbers.
  • SEH is limited to functions that do not need to call destructors of local functions, so I have moved try/catch blocks into separate functions.
  • dmd can be built either through the VS2008 project dmd_msc.vcproj (this also includes building a working 64-bit executable) or through vcbuild\builddmd.bat that uses win32.mak and a small option-mapping batch.
    I had to add strtold.c to the makefile, so this might have an influence on the dmc build aswell.
Member

rainers commented Nov 19, 2011

I forgot to say that I could only test it on Windows, so I cannot guarantee it does not break any other platform.

klickverbot referenced this pull request in ldc-developers/ldc Nov 19, 2011

Closed

Compile LDC2 with VS2010 64bit. #26

Owner

WalterBright commented Nov 19, 2011

That's a lot of changes! Most seem to be the result of VC not supporting long doubles. Let me think about the best way to go forward with this.

Owner

WalterBright commented Nov 19, 2011

It'll also have to wait a bit until my Mac is working again (under repair).

@yebblies yebblies and 1 other commented on an outdated diff Nov 20, 2011

test/runnable/template9.d
@@ -292,7 +292,7 @@ void bug4984b(U)(U u) {
}
void bug4984() {
- bug4984a!400();
+ bug4984a!180(); // 400 causes stack overflow in Win64 build
@yebblies

yebblies Nov 20, 2011

Member

I'm a little worried by this. Does the comment mean that it works with 400 on the win32 build, or have you only tested on win64?

Could you please provide a stack trace of this failing?

@rainers

rainers Nov 20, 2011

Member

It happens only with the win64 executable, not for win32.

The core recursion is this:

dmd_msc.exe!CallExp::semantic(Scope * sc=0x000000000d858a00) Line 7229 C++
dmd_msc.exe!TypeTypeof::semantic(Loc loc={...}, Scope * sc=0x000000000d858700) Line 6351 + 0x29 bytes C++
dmd_msc.exe!Type::trySemantic(Loc loc={...}, Scope * sc=0x000000000d858700) Line 322 + 0x2b bytes C++
dmd_msc.exe!IsExp::semantic(Scope * sc=0x000000000d858700) Line 5433 + 0x3c bytes C++
dmd_msc.exe!AndAndExp::semantic(Scope * sc=0x000000000d858700) Line 11517 + 0x26 bytes C++
dmd_msc.exe!TemplateDeclaration::deduceFunctionTemplateMatch(Scope * sc=0x000000000d857150, Loc loc={...}, ArrayBase * targsi=0x000000000d857f10, Expression * ethis=0x0000000000000000, ArrayBase * fargs=0x000000000d857ca0, ArrayBase * dedargs=0x00000000000760e8) Line 1421 + 0x1b bytes C++
dmd_msc.exe!TemplateDeclaration::deduceFunctionTemplate(Scope * sc=0x000000000d857150, Loc loc={...}, ArrayBase * targsi=0x000000000d857f10, Expression * ethis=0x0000000000000000, ArrayBase * fargs=0x000000000d857ca0, int flags=0) Line 1611 + 0x63 bytes C++
dmd_msc.exe!CallExp::semantic(Scope * sc=0x000000000d857150) Line 7763 + 0x63 bytes C++

Every "loop" on the stack needs about 5kB stack space, and the process seems to little more that 1MB of stack.

@yebblies

yebblies Nov 20, 2011

Member

Good, just vcc being stupid then. According to this a more reasonable stack size would be 8M.

Could you please add this to the cl wrapper and the project file and fix the test?

@rainers

rainers Nov 20, 2011

Member

Thanks for the hint, I have increased the stack size to 8MB and it runs
fine now.

I still wonder where this much stack space is needed. CallExp::semantic
alone allocates 2360 bytes, but I did not see any local variable close
to that size.

Member

yebblies commented Nov 20, 2011

Dmd fails to build on linux32:


rm -f access.o array.o attrib.o bcomplex.o blockopt.o cast.o code.o cg.o cg87.o cgxmm.o cgcod.o cgcs.o cgelem.o cgen.o cgreg.o cgsched.o class.o cod1.o cod2.o cod3.o cod4.o cod5.o constfold.o irstate.o dchar.o cond.o debug.o declaration.o dsymbol.o dt.o dump.o e2ir.o ee.o eh.o el.o dwarf.o enum.o evalu8.o expression.o func.o gdag.o gflow.o glocal.o gloop.o glue.o gnuc.o go.o gother.o html.o iasm.o id.o identifier.o impcnvtab.o import.o inifile.o init.o inline.o lexer.o link.o lstring.o mangle.o mars.o rmem.o module.o msc.o mtype.o nteh.o cppmangle.o opover.o optimize.o os.o out.o outbuf.o parse.o ph.o ptrntab.o root.o rtlsym.o s2ir.o scope.o statement.o stringtable.o struct.o csymbol.o template.o tk.o tocsym.o todt.o type.o typinf.o util.o var.o version.o strtold.o utf.o staticassert.o unialpha.o toobj.o toctype.o toelfdebug.o entity.o doc.o macro.o hdrgen.o delegatize.o aa.o ti_achar.o toir.o interpret.o traits.o builtin.o clone.o aliasthis.o intrange.o man.o arrayop.o port.o response.o async.o json.o speller.o aav.o unittests.o imphint.o argtypes.o ti_pvoid.o libelf.o elfobj.o dmd optab.o id.o impcnvgen idgen id.c id.h \
    impcnvtab.c optabgen debtab.c optab.c cdxxx.c elxxx.c fltables.c \
    tytab.c core \
    *.cov *.gcda *.gcno
g++ -m32  idgen.c -o idgen
./idgen
g++ -m32  -Wno-deprecated -Wstrict-aliasing -D__near= -D__pascal= -fno-exceptions -O0 -Ibackend -Itk -DMARS=1 -DTARGET_LINUX=1 backend/optabgen.c -o optabgen
In file included from backend/cc.h:101:0,
                 from backend/optabgen.c:22:
backend/cdef.h:255:24: fatal error: longdouble.h: No such file or directory
compilation terminated.
make: *** [optabgen] Error 1
Member

rainers commented Nov 20, 2011

That's a lot of changes! Most seem to be the result of VC not supporting long doubles.

Yeah, but most of them are trivial changes. There are currently at least two different types for "long double" used in the backend (long double and targ_ldouble) and three in the front end (long double, d_float80 and real_t). I think this should be consolidated, but it would be a second step. A lot of special cases for IN_GCC and real_t could also be eliminated.

Member

rainers commented Nov 20, 2011

Dmd fails to build on linux32

Thanks for trying. I forgot to add "root" to the include paths in posix.mak. Fix is committed.

Contributor

Trass3r commented Jan 20, 2012

What's the state of this? Has your Mac been repaired, Walter? ;)

Owner

WalterBright commented Jan 21, 2012

I got a new mac.

On 1/20/2012 8:45 AM, Trass3r wrote:

What's the state of this? Has your Mac been repaired, Walter? ;)

Contributor

Trass3r commented Jan 28, 2012

So is this request being processed?
btw, the autotester claims it doesn't merge: http://d.puremagic.com/test-results/pull.ghtml?runid=43642

Member

rainers commented Jan 29, 2012

I have rebased, resolved the conflict and fixed the build (test suite
still passes), but I guess there is something wrong with the commit
history. I hate git for how often it breaks something and how
inefficient it is for me, so please, anyone tell me what reset command
is necessary to fix it.

Member

yebblies commented Jan 29, 2012

Try
git rebase -i HEAD~13
then edit the file to remove all commits that aren't part of this patch (including the merge commit at the end)
Then continue the rebase and fix any conflicts that occur.
When finished it should all be working.

Member

yebblies commented Jan 29, 2012

Much better!

Member

rainers commented Jan 29, 2012

Thanks, that seems to have worked (with a forced push).

Member

yebblies commented Jan 29, 2012

At least it tells you you when you need to force a push. I've had trouble with github not updating a pull request unless I force push, so these days I always rebase when changing anything.

Contributor

Trass3r commented Feb 22, 2012

Merge conflicts again...

Member

rainers commented Feb 24, 2012

Fixed again

WalterBright merged commit 3389350 into dlang:master Feb 25, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment