[llvm-commits] [cfe-dev] [PATCH] Windows improvements

[NAKAMURA Takumi]

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. :(


> 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


On Mon, Feb 28, 2011 at 1:15 PM, Erik Olofsson <Erik.Olofsson at hansoft.se> wrote:
> 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