LLVM 3.8.0 clang binary for Windows targets VC++

The LLVM downloads are listed at LLVM Download Page.

The distributed LLVM 3.8.0 clang 32-bit binary for Windows at http://llvm.org/releases/3.8.0/LLVM-3.8.0-win32.exe targets VC++. I can see this by the fact that _MSC_VER is predefined when I invoke clang++.

The distributed LLVM 3.8.0 clang 64-bit binary for Windows at http://llvm.org/releases/3.8.0/LLVM-3.8.0-win64.exe targets VC++. I can see this by the fact that _MSC_VER is predefined when I invoke clang++.

Was this intentional ?

This was not the case for previous versions of clang for Windows on the LLVM downloads page.

Is there any way I can use these binaries without them being targeted for VC++ ( _MSC_VER will not be defined ) ? If not, are there any distributed binaries for clang 3.8 on Windows listed anywhere on the web which do not target VC++ ?

I really would have thought that since clang-cl.exe automatically targets VC++, as I understand it, that llvm/clang would have continued to distribute their Windows binaries as they did for LLVM 3.7.1 and below rather than force VC++ targeting on the end-user in the binary distribution of the clang/clang++ executable. I hope there is something I have missed in all this ( there usually is ).

You can explicitly specify the target triple, like this:

  clang -target i686-pc-windows-gnu (or x86_64-pc-windows-gnu)

-Nico

That works. Thanks !

Still isn't distributing a clang Windows release which by default targets VC++ for all clang invocations, and not just clang-cl, a bit of a rude awakening for all those who have used clang on Windows with mingw(-64)/gcc in the past ?

Perhaps, but this has always been the default behavior if you build from
source with MSVC for over two years now (r199250).

Basically, if you build clang with mingw it will target mingw by default.
If you build clang with MSVC, it will target MSVC by default. This was
deemed to be consistent with how clang works on other platforms, where you
get a host compiler by default. Either way, you can override the default
with --target.

It also happens that for a long time after that, Hans configured the builds
at llvm.org/builds so that 'clang' targeted mingw by default, and
'clang-cl' targeted MSVC. We removed that flag from the packaging script
some time ago, which probably confused some users.

    Still isn't distributing a clang Windows release which by default
    targets VC++ for all clang invocations, and not just clang-cl, a bit
    of a rude awakening for all those who have used clang on Windows
    with mingw(-64)/gcc in the past ?

Perhaps, but this has always been the default behavior if you build from
source with MSVC for over two years now (r199250).

Basically, if you build clang with mingw it will target mingw by
default. If you build clang with MSVC, it will target MSVC by default.
This was deemed to be consistent with how clang works on other
platforms, where you get a host compiler by default. Either way, you can
override the default with --target.

That make sense.

It also happens that for a long time after that, Hans configured the
builds at llvm.org/builds <http://llvm.org/builds&gt; so that 'clang'
targeted mingw by default, and 'clang-cl' targeted MSVC. We removed that
flag from the packaging script some time ago, which probably confused
some users.

What that did was change the default target on Windows for clang/clang++ from mingw/gcc to VC++. That change turned up for the LLVM 3.8 release. The confusion is that the change of the default target was made but the end-user was not told about it. So the end-user of clang for 3.8 on Windows, who never used a -target option, now gets in many ways a different compiler when he invokes clang++ for 3.8 on Windows than he had previously when he invoked clang++ for 3.7.1 on down on Windows.

Is the clang -target option officially documented anywhere ?

    Still isn't distributing a clang Windows release which by default
    targets VC++ for all clang invocations, and not just clang-cl, a bit
    of a rude awakening for all those who have used clang on Windows
    with mingw(-64)/gcc in the past ?

Perhaps, but this has always been the default behavior if you build from
source with MSVC for over two years now (r199250).

Basically, if you build clang with mingw it will target mingw by
default. If you build clang with MSVC, it will target MSVC by default.
This was deemed to be consistent with how clang works on other
platforms, where you get a host compiler by default. Either way, you can
override the default with --target.

That make sense.

It also happens that for a long time after that, Hans configured the
builds at llvm.org/builds <http://llvm.org/builds&gt; so that 'clang'
targeted mingw by default, and 'clang-cl' targeted MSVC. We removed that
flag from the packaging script some time ago, which probably confused
some users.

What that did was change the default target on Windows for clang/clang++
from mingw/gcc to VC++. That change turned up for the LLVM 3.8 release. The
confusion is that the change of the default target was made but the
end-user was not told about it. So the end-user of clang for 3.8 on
Windows, who never used a -target option, now gets in many ways a different
compiler when he invokes clang++ for 3.8 on Windows than he had previously
when he invoked clang++ for 3.7.1 on down on Windows.

Is the clang -target option officially documented anywhere ?

Yes: http://clang.llvm.org/docs/CrossCompilation.html#target-triple

Appreciate the link but...

What good does it do to specify 'etc.' in the doc for all the 5 target triple fields ? I already see that target triples I was given to use do not always correspond to the values given in the doc and specifying 'etc.' just leaves the possibilities a guess. How can I as a programmer ever know what correct values might be ?

I was given 'i686-pc-windows-gnu' for targeting 32-bit mingw on Windows but I can see that the target triple doc doesn't specify 'i686' as an 'arch' or 'windows' as a 'sys' but I know that '-target i686-pc-windows-gnu' actually works to target 32-bit mingw on Windows.

While it is good to have an option that defines the target atchitecture, if it is not completely documented what the possible options are and what they mean I do not see how an end-user can use such an option successfully.