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
> -----Original Message-----
> From: NAKAMURA Takumi [mailto:geek4civic at gmail.com]
> Sent: den 28 februari 2011 10:25
> To: Erik Olofsson; Douglas Gregor
> Cc: llvm-commits; cfe-commits; llvmdev
> Subject: Re: [cfe-dev] [PATCH] Windows improvements
>
> 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