Make Libjulia compile on Windows with Intel Compiler

[tknopp]

This is some work to make libjulia compile on windows with the intel compiler. There are already some make scripts (Windows.mk) in the julia source tree but it required some work to get it compile.

Some of the things are also a step forward to compile libjulia with MSVC.

Changes:

• __uint128_t is not defined in non-gcc environment
• There were some places where dynamically stack allocated C arrays were used (VLAs) (i.e. ccall.cpp:750). But these are not available in C++. I have changed these to use alloca.
• There was an issue with WINBOOL. I replaced it with BOOL, which should be defined for all windows compilers.
• The WINAPI macro has to be put into the brackets when declaring a function pointer.
• In dtypes.h the header platform.h has to be included first as otherwise, the define OS_WINDOWS is not available
• When including LLVM headers one has to define #define NOMINMAX as otherwise std::max is shadowed by a windows macro for max

It would be great if someone could review this and commit if it is fine.

There are still some issues left as my self-written program that uses libjulia crashes when trying to either build Base or use an exsisting sys.jl but I think this is the next step and want to first get this in.

One last comment on MSVC: With VS2010 there is an issue: It basically only allows C89. Solutions:
a) Forget about VS2010 and try VS2013 which should have basic C99 support
b) Put all declarations at the beginnings of each block (oh my god)
c) Compile with MSVC C++ compiler. This would mean that we have to introduce casts when assigning pointers of different type (i.e. jl_value_t* x = (jl_value_t*) JL_NULL)

[mlubin]

Will using std::vector instead of VLAs have a performance impact?

[tknopp]

Possibly, if this is a performance critical part. std::vector will have the same performance as doing new[] and initializing the vector to zero. But this is exception safe.

I can #ifdef the code if desired. However, from my point of view, one should not use a feature that is not part of the language standard (I know that they will be in C++14).

[tknopp]

Ok, I see that uv_err_t will need some ifdefs...

[tknopp]

I seem to have used an old libuv and the uv_errno_t is now an enum. So everything was ok. will remove this from the PR

[tknopp]

I have replaced std::vector by calls to alloca. This seems to be almost the same as VLAs and portable

[tknopp]

The last commit fixed the DLLEXPORT macro. It had a wrong default. The default has to be import and when building the DLL one has to define LIBRARY_EXPORTS in order to toggle the macro to export.

This really was hard to find. But I have now have basically a libjulia.dll working that has been compiled on windows with the intel compiler and is debuggable in VS.

[vtjnash]

this needs the WINAPI parameter. If that isn't defined, we can use one of its other names.

[tknopp]

@vtjnash Thanks for your feedback! I have incorparated your suggestions. The issue with WINAPI was that it has to be put into the brackets of the function pointer declaration. Seems that Mingw does not care about that. I still use BOOL instead of WINBOOL, as the later is Mingw specific.

Are there any other objections in merging this?

[tknopp]

@vtjnash: Would be great to get this in if there are no objections. Esspecially the fixed DLLEXPORT behavior is important when linking against libjulia. Otherwise, the static globals jl_base_module (and so on) are not accessible when using a windows compiler

[vtjnash]

agreeed

[ihnorton]

@tknopp did you manage to build openlibm with the intel or msvc compiler?

[tknopp]

@ihnorton I did not build openlibm at all. I just build libuv and libjulia using the intel compiler. Then I used a small C program that links to libjulia to test it. The only hard dependencies of libjulia are libuv and llvm. The other dependencies are only required when using those base methods which ccall them. I am not sure what openlibm actually is. Is it an alternative for the limb that is part of any C runtime?

Compiling the REPL is more complicated as it has some more dependencies.

The real benefit of using the intel (or microsoft) compiler is that one can debug into libjulia with VisualStudio. This is not possible with the mingw builds

[vtjnash]

yes, openlibm is a replacement for the windows libm. on win32, the libm has poor numerical accuracy. you can configure the intel libm to give much better accuracy and win64 may have a better libm already (I don't remember what I concluded on that front).

[ihnorton]

I wrote cmake build files for openlibm a while ago with which it built fine on *nix, but not with msvc due to unsupported asm constructs, hence the curiosity.

[joa-quim]

Would by any chance help those YASM files pointed at?

http://gladman.plushost.co.uk/oldsite/computing/gmp4win.php

[tknopp]

It should be possible to use a mingw compiled openlibm with an intel or msvc compiled libjulia.

[tknopp]

removed the RFC from the title

[tknopp]

@vtjnash thanks!