[PATCH] Windows improvements

With GCC being a dead end and hard to use for universal binaries on OSX and Microsoft refusing to fix bugs in their compiler I thought it would good idea to get clang compiling our code base.

Before I start fixing bugs and missing features in clang I have created these patches to make it easier to debug and develop clang on Windows. After this is done what is needed is reimplementing <intrin.h> from Visual Studio 2010 includes and fixing any bugs that I find in the compiler. Finally I need lambda expressions which we already use heavily.

llvm-msvc10-fix-warnings.patch:

clang-msvc10-fix-warnings.patch:

Fixes compiler warnings.

llvm-msvc-format-diagnostics.patch:

clang-msvc-format-diagnostics.patch:

Complete support for msvc style diagnostics parsable by Visual Studio. Added column support for msvc locations. I also added indentation so you can easily see the grouping of errors, include stacks and notes (msvc mode only).

llvm-outputdebugstring-support.patch:

clang-visual-studio-debuggability.patch:

Visual Studio has no good way of getting stdout and stderr output into its Output Window. Getting these into the Output Window can be really helpful for debugging as you can go to diagnostics locations directly from there. It’s also helpful to actually see the compiler output while breaking into the code. To allow this I have added support for OutputDebugString in llvm raw_ostream. I then use this from the driver where you can redirect stdout and stderr to OutputDebugString with -output-diagnostics-as-debug-string option.

I have also added a shortcut when invoking cc1 so it doesn’t actually start a new process. This is because Visual Studio does not support automatically attaching to child processes, and doing -### every time you change a command line option and copying the results is cumbersome. It should also have the added benefit of speeding up compilation. I don’t know enough about clang to know if this is safe in all instances, and the way it’s implemented might not be optimal. Let me know if this could be done in a better way.

clang-pragma-message.patch:

Make pragma message just output the message ignoring location (in msvc mode) and include stack information (always). This makes #pragma message usable in the same way when using clang as when using msvc and gcc.

llvm-msvc-multi-processor-compilation.patch:

Make use of multiple processors when compiling one project in msbuild/Visual Studio. This greatly decreases turnaround time when changing headers.

llvm-temp-test-file-fail-on-win32.patch:

Fix Windows python issue where open temporary files cannot be opened again. Needed for clang-c++tests.

clang-missing-builtins.patch:

llvm-interrupt-builtin.patch:

Add builtins needed to implement __debugbreak and _byteswap_ushort from intrin.h. Before implementing everything else needed for intrin.h I need to know if this is the correct way?

clang-msvc10-fix-mm_malloc-error.patch:

mm_malloc is implemented in Visual Studio 2010, this fixes the compile error resulting from it being a macro.

I have ran check-all on OSX and Visual Studio 2010 and made sure that there aren’t any regressions on these platforms. I would add tests for the OutputDebugString functionality, but capturing this probably needs extra support in the testing framework. Let me know what you think of these patches and I will start fixing more things if they are accepted.

Thanks,

Erik

clang-missing-builtins.patch (1.67 KB)

clang-msvc10-fix-mm_malloc-error.patch (452 Bytes)

clang-msvc10-fix-warnings.patch (1.8 KB)

clang-msvc-format-diagnostics.patch (9.23 KB)

clang-pragma-message.patch (19 KB)

clang-visual-studio-debuggability.patch (34.3 KB)

llvm-interrupt-builtin.patch (641 Bytes)

llvm-msvc10-fix-warnings.patch (1.61 KB)

llvm-msvc-format-diagnostics.patch (2.16 KB)

llvm-msvc-multi-processor-compilation.patch (2.46 KB)

llvm-outputdebugstring-support.patch (5.26 KB)

llvm-temp-test-file-fail-on-win32.patch (861 Bytes)

Hello Erik,

Thank you to work. I have not checked to build them, though, I can
tell you some comments, excuse me.

* General

  - Please post patches to cfe-commits and to llvm-commits, too.
    (IMHO it would not be needed to split articles apart each lists as
long as each would be related.)
  - If you can, please attach files w/o CRLF(dos encodings), or with
attached text/plain.
  - You may split and post an article if your patches were not "series
of patches" but "set of functionally individual patches".

llvm-msvc10-fix-warnings.patch:
clang-msvc10-fix-warnings.patch:
Fixes compiler warnings.

Looks good to me. They could be applied when gtest guys said ok.

llvm-msvc-format-diagnostics.patch:
clang-msvc-format-diagnostics.patch:

Complete support for msvc style diagnostics parsable by Visual Studio. Added
column support for msvc locations. I also added indentation so you can
easily see the grouping of errors, include stacks and notes (msvc mode
only).

It seems it would be better functionally. But please remember
Microsoft's toolchain would not be the only one.
Also mingw depends on LLVM_ON_WIN32. (in llvm side).

For now, I don't have better answer.

llvm-outputdebugstring-support.patch:
clang-visual-studio-debuggability.patch:

Visual Studio has no good way of getting stdout and stderr output into its
Output Window. Getting these into the Output Window can be really helpful
for debugging as you can go to diagnostics locations directly from there.
It's also helpful to actually see the compiler output while breaking into
the code. To allow this I have added support for OutputDebugString in llvm
raw_ostream. I then use this from the driver where you can redirect stdout
and stderr to OutputDebugString with -output-diagnostics-as-debug-string
option.

Windows/OutputDebugString.inc would be dubious.

#include "Windows.h"

It would be better with small letter "windows.h", to be compiled cross
on case-sensitive filesystem.

namespace llvm {
  void llvm::output_debug_string(const char *String) {
    OutputDebugString(String);
  }
}

Either outer "namespace llvm" or inner specifier "llvm::" might be redundant.
It cannot be compiled with g++-4.4.0.

I have also added a shortcut when invoking cc1 so it doesn't actually start
a new process. This is because Visual Studio does not support automatically
attaching to child processes, and doing -### every time you change a command
line option and copying the results is cumbersome. It should also have the
added benefit of speeding up compilation. I don't know enough about clang to
know if this is safe in all instances, and the way it's implemented might
not be optimal. Let me know if this could be done in a better way.

Please split clang's patch by functionality.

clang-pragma-message.patch:

Make pragma message just output the message ignoring location (in msvc mode)
and include stack information (always). This makes #pragma message usable in
the same way when using clang as when using msvc and gcc.

Excuse me, I have no idea.

llvm-msvc-multi-processor-compilation.patch:

Make use of multiple processors when compiling one project in msbuild/Visual
Studio. This greatly decreases turnaround time when changing headers.

"/MP" works better for me functionally, though, it would be dubious for style.
Oscar, do you have any opinions?

FYI, I am using /m with msbuild.exe.

llvm-temp-test-file-fail-on-win32.patch:

Fix Windows python issue where open temporary files cannot be opened again.
Needed for clang-c++tests.

Looks good to me. Daniel, would it be enough?

clang-missing-builtins.patch:
llvm-interrupt-builtin.patch:

Add builtins needed to implement __debugbreak and _byteswap_ushort from
intrin.h. Before implementing everything else needed for intrin.h I need to
know if this is the correct way?

I have no idea, excuse me. :frowning:

clang-msvc10-fix-mm_malloc-error.patch:

mm_malloc is implemented in Visual Studio 2010, this fixes the compile error
resulting from it being a macro.

Also mingw-w64 provides _mm_malloc stuff.
I suggest not to tweak _mm_malloc, but rely on provided _mm_malloc.

I will work on it, too. I expect it could be possible on known plaforms.
#ifdef _mm_malloc
static inline void *_mm_malloc() { ...
#endif

...Takumi

Hello Takumi,

It seems it would be better functionally. But please remember Microsoft's
toolchain would not be the only one.
Also mingw depends on LLVM_ON_WIN32. (in llvm side).

From HandleLLVMOptions.cmake

  if(CYGWIN)
    set(LLVM_ON_WIN32 0)
    set(LLVM_ON_UNIX 1)
  else(CYGWIN)
    set(LLVM_ON_WIN32 1)
    set(LLVM_ON_UNIX 0)
endif(CYGWIN)

This can filter out Cygwin with (defined(LLVM_ON_WIN32) && !defined(LLVM_ON_UNIX)), but I guess mingw would have to be filtered out in another way.

If there is no existing way I could add:
  if(MSVC)
    set(LLVM_ON_WIN32MSVC 1)
  endif(MSVC)

Please split clang's patch by functionality.

Ok, so split into three patches?
* refactor llvm::outs()/errs()
* cc1 invocation without a new process
* output diagnostics as debug string

"/MP" works better for me functionally, though, it would be dubious for
style.
Oscar, do you have any opinions?

FYI, I am using /m with msbuild.exe.

'msbuild /m' and 'cl /MP' works well together giving the most amount of parallelism with both projects and individual translation units being compiled in parallel.

Regards,
Erik

I can't really comment on the rest of them, but these look somewhat reasonable. They need some testcases though. I also don't see any backend support to actually generate the instruction?

-eric