[clang] How to use CLang for Windows?
There was a recent conference where the Clang team announced a version of Clang that's supposed to work on Windows (as opposed to kind-of working if you try real hard). It's accessible from the command line if you put Clang in the PATH. I just found out it's supposed to be used from Visual Studio ('10 or '12) after tweaking a project's settings. Can it be used from out BJam system? How will it find right header files to use? (Does it automatically use the ones from MSVC?) Daryle W.
On 9/22/2013 9:26 PM, Daryle Walker wrote:
There was a recent conference where the Clang team announced a version of Clang that's supposed to work on Windows (as opposed to kind-of working if you try real hard). It's accessible from the command line if you put Clang in the PATH. I just found out it's supposed to be used from Visual Studio ('10 or '12) after tweaking a project's settings. Can it be used from out BJam system? How will it find right header files to use? (Does it automatically use the ones from MSVC?)
is there more information about this anywhere ? I have been successful using clang from various Linux distros I have which ship with it or have it as a package, but my experience of using clang within Windows has been pretty miserable and I just gave up in frustration. I realize how good clang is in compliance with the C++ standard so would like to use it under Windows for testing Boost if it actually works there.
On 23/09/13 09:35, Edward Diener wrote:
On 9/22/2013 9:26 PM, Daryle Walker wrote:
There was a recent conference where the Clang team announced a version of Clang that's supposed to work on Windows (as opposed to kind-of working if you try real hard). It's accessible from the command line if you put Clang in the PATH. I just found out it's supposed to be used from Visual Studio ('10 or '12) after tweaking a project's settings. Can it be used from out BJam system? How will it find right header files to use? (Does it automatically use the ones from MSVC?)
is there more information about this anywhere ?
The announcement at Going Native: http://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s... Blog Entry: http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html Builds: http://llvm.org/builds/ Ben
On 9/22/2013 10:49 PM, Ben Pope wrote:
On 23/09/13 09:35, Edward Diener wrote:
On 9/22/2013 9:26 PM, Daryle Walker wrote:
There was a recent conference where the Clang team announced a version of Clang that's supposed to work on Windows (as opposed to kind-of working if you try real hard). It's accessible from the command line if you put Clang in the PATH. I just found out it's supposed to be used from Visual Studio ('10 or '12) after tweaking a project's settings. Can it be used from out BJam system? How will it find right header files to use? (Does it automatically use the ones from MSVC?)
is there more information about this anywhere ?
The announcement at Going Native: http://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s...
Blog Entry: http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html
Builds: http://llvm.org/builds/
Many thanks for the links !
From: benpope81@gmail.com Date: Mon, 23 Sep 2013 10:49:54 +0800
On 23/09/13 09:35, Edward Diener wrote:
is there more information about this anywhere ?
The announcement at Going Native: http://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s...
Blog Entry: http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html
So, can it be used on the command-line? Or is it just for MSVC (IDE)?
Builds: http://llvm.org/builds/
Daryle W.
On 22 Sep 2013 at 21:26, Daryle Walker wrote:
There was a recent conference where the Clang team announced a version of Clang that's supposed to work on Windows (as opposed to kind-of working if you try real hard). It's accessible from the command line if you put Clang in the PATH. I just found out it's supposed to be used from Visual Studio ('10 or '12) after tweaking a project's settings. Can it be used from out BJam system? How will it find right header files to use? (Does it automatically use the ones from MSVC?)
I think they meant http://www.ishani.org/web/articles/code/clangvsx/. It's simply a plugin for Visual Studio, no more. If you want the same thing with Boost, simply configure a Makefile project in VS and have it invoke b2 toolset=clang. clang still cannot fully grok the STL shipped with Visual Studio and therefore uses Mingw's libstdc++ STL, though I should imagine the Dinkumware in VS2013 is probably the least customised STL Visual Studio has shipped in many years. If you are happy to use clang as you would mingw, I've found it pretty good on Windows. Forget about substituting MSVC with clang though, they're not equivalent. If you want a modern C++ 11 compiler on Windows, VS2013 Express is very good and free. I've been pleasantly surprised at its optimiser too, I'm seeing a nice speed bump of 15-20% when compiling C++ 11 over VS2012, some of which is STL improvements, some is improved C++ 11 rvalue reference support. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
24.09.2013 2:00, Niall Douglas пишет:
I think they meant http://www.ishani.org/web/articles/code/clangvsx/. It's simply a plugin for Visual Studio, no more. No, they've done something different. They integrated the clang compiler with msbuild system. They are also trying to use the Dinkumware STL.
If you are happy to use clang as you would mingw, I've found it pretty good on Windows. Forget about substituting MSVC with clang though, they're not equivalent. As I understand, they are trying to make substituting MSVC with clang possible.
-- Best regards, Sergey Cheban
23.09.2013 5:26, Daryle Walker wrote:
There was a recent conference where the Clang team announced a version of Clang that's supposed to work on Windows (as opposed to kind-of working if you try real hard). Currently, it fails to process <iostream> with the following error messages:
Can it be used from out BJam system? How will it find right header files to use? (Does it automatically use the ones from MSVC?) When using the LLVM-2012 toolset, MSBuild looks into the "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Platforms\Win32\PlatformToolsets\LLVM-vs2012\Microsoft.Cpp.Win32.LLVM-vs2012.props"
1>CL : error : cannot mangle RTTI descriptors for type 'codecvt' yet 1>CL : error : cannot mangle the name of type 'codecvt' into RTTI descriptors yet 1>CL : error : cannot mangle RTTI descriptors for type 'codecvt_base' yet 1>CL : error : cannot mangle the name of type 'codecvt_base' into RTTI descriptors yet 1>CL : error : cannot mangle RTTI descriptors for type 'facet' yet 1>CL : error : cannot mangle the name of type 'facet' into RTTI descriptors yet 1>CL : error : cannot mangle RTTI descriptors for type '_Facet_base' yet 1>CL : error : cannot mangle the name of type '_Facet_base' into RTTI descriptors yet OTOH, it can process <memory> and <stdio.h> (haven't tried other headers yet), use some modern c++ features and produce working executables. that contains the following: <LLVMInstallDir> $(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\LLVM\LLVM 3.4.svn) </LLVMInstallDir> <ExecutablePath> $(LLVMInstallDir)\msbuild-bin;$(ExecutablePath) </ExecutablePath> The clang compiler itself doesn't know anything about the header file paths. It looks into the command line. -- Best regards, Sergey Cheban
On Mon, Sep 23, 2013 at 5:57 PM, Sergey Cheban <s.cheban@drweb.com> wrote:
23.09.2013 5:26, Daryle Walker wrote:
There was a recent conference where the Clang team announced a version of
Clang
that's supposed to work on Windows (as opposed to kind-of working if you try real hard). Currently, it fails to process <iostream> with the following error messages:
1>CL : error : cannot mangle RTTI descriptors for type 'codecvt' yet 1>CL : error : cannot mangle the name of type 'codecvt' into RTTI descriptors yet 1>CL : error : cannot mangle RTTI descriptors for type 'codecvt_base' yet 1>CL : error : cannot mangle the name of type 'codecvt_base' into RTTI descriptors yet 1>CL : error : cannot mangle RTTI descriptors for type 'facet' yet 1>CL : error : cannot mangle the name of type 'facet' into RTTI descriptors yet 1>CL : error : cannot mangle RTTI descriptors for type '_Facet_base' yet 1>CL : error : cannot mangle the name of type '_Facet_base' into RTTI descriptors yet
OTOH, it can process <memory> and <stdio.h> (haven't tried other headers yet), use some modern c++ features and produce working executables.
FWIW, I'm spoken to several of the Clang developers yesterday and today at the C++ standards committee meeting, and they emphasize their interest in improving support under Windows and would like help in the form of bug reports as they work out the kinks. They know they have a long way to go, but seem very interested in doing whatever is needed to make clang work really well on Windows. --Beman
On 9/23/2013 11:39 PM, Beman Dawes wrote:
On Mon, Sep 23, 2013 at 5:57 PM, Sergey Cheban <s.cheban@drweb.com> wrote:
23.09.2013 5:26, Daryle Walker wrote:
There was a recent conference where the Clang team announced a version of
Clang
that's supposed to work on Windows (as opposed to kind-of working if you try real hard). Currently, it fails to process <iostream> with the following error messages:
1>CL : error : cannot mangle RTTI descriptors for type 'codecvt' yet 1>CL : error : cannot mangle the name of type 'codecvt' into RTTI descriptors yet 1>CL : error : cannot mangle RTTI descriptors for type 'codecvt_base' yet 1>CL : error : cannot mangle the name of type 'codecvt_base' into RTTI descriptors yet 1>CL : error : cannot mangle RTTI descriptors for type 'facet' yet 1>CL : error : cannot mangle the name of type 'facet' into RTTI descriptors yet 1>CL : error : cannot mangle RTTI descriptors for type '_Facet_base' yet 1>CL : error : cannot mangle the name of type '_Facet_base' into RTTI descriptors yet
OTOH, it can process <memory> and <stdio.h> (haven't tried other headers yet), use some modern c++ features and produce working executables.
FWIW, I'm spoken to several of the Clang developers yesterday and today at the C++ standards committee meeting, and they emphasize their interest in improving support under Windows and would like help in the form of bug reports as they work out the kinks. They know they have a long way to go, but seem very interested in doing whatever is needed to make clang work really well on Windows.
That's nice but my experience in the past has been that no one on the clang mailing list responded when the inability to even build clang for Windows was made known to them. Furthermore Boost.Build did not support clang for Windows when I last tried it. So if I try to build and use clang for Windows to whom do I report problems about clang ? Furthermore does Boost.Build now have support for clang for Windows ? Clang is a great compiler under Linux. And I am willing to try to get it to work under Windows using Boost.Build to test Boost libraries, my own and others, under Windows, reporting problems to the appropriate places. But not if I am once again met by indifference when problems occur.
On 24 September 2013 13:00, Edward Diener wrote:
On 9/23/2013 11:39 PM, Beman Dawes wrote:
FWIW, I'm spoken to several of the Clang developers yesterday and today at the C++ standards committee meeting, and they emphasize their interest in improving support under Windows and would like help in the form of bug reports as they work out the kinks. They know they have a long way to go, but seem very interested in doing whatever is needed to make clang work really well on Windows.
That's nice but my experience in the past has been that no one on the clang mailing list responded when the inability to even build clang for Windows was made known to them.
Furthermore Boost.Build did not support clang for Windows when I last tried it.
So if I try to build and use clang for Windows to whom do I report problems about clang ?
Beman said they want bug reports, so http://llvm.org/bugs/ seem the obvious choice. Mailing lists are a poor way to report bugs. If noone happens to be interested in looking into it that day then the mail goes unreplied and gets forgotten. Bug reports hang around until someone addresses them.
Beman said they want bug reports, so http://llvm.org/bugs/ seem the obvious choice. I think that it is too early to fill any external bug reports for the compiler that is unable to compile the first "hello world" example from
On 24.09.2013 16:41, Jonathan Wakely wrote: the Stroustrup's book. See also: https://llvm.org/svn/llvm-project/cfe/trunk/lib/AST/MicrosoftMangle.cpp void MicrosoftMangleContext::mangleCXXRTTIName(QualType T, raw_ostream &) { // FIXME: Give a location... unsigned DiagID = getDiags().getCustomDiagID(DiagnosticsEngine::Error, "cannot mangle the name of type %0 into RTTI descriptors yet"); getDiags().Report(DiagID) << T.getBaseTypeIdentifier(); } -- Sergey Cheban
On Tue, Sep 24, 2013 at 10:36 AM, Sergey Cheban <s.cheban@drweb.com> wrote:
On 24.09.2013 16:41, Jonathan Wakely wrote:
Beman said they want bug reports, so http://llvm.org/bugs/ seem the
obvious choice.
I think that it is too early to fill any external bug reports for the compiler that is unable to compile the first "hello world" example from the Stroustrup's book.
I've confirmed in face-to-face discussion with several key Clang folks that they do indeed to want bug reports against the Windows port. In other words, just what Jonathan said. --Beman
On 9/28/2013 1:26 PM, Beman Dawes wrote:
On Tue, Sep 24, 2013 at 10:36 AM, Sergey Cheban <s.cheban@drweb.com> wrote:
On 24.09.2013 16:41, Jonathan Wakely wrote:
Beman said they want bug reports, so http://llvm.org/bugs/ seem the
obvious choice.
I think that it is too early to fill any external bug reports for the compiler that is unable to compile the first "hello world" example from the Stroustrup's book.
I've confirmed in face-to-face discussion with several key Clang folks that they do indeed to want bug reports against the Windows port. In other words, just what Jonathan said.
I still do not see a roadmap for using clang with Boost Build under Windows to build/test Boost libraries. Am I supposed to download a Windows snapshot from http://llvm.org/builds/ ? Am I supposed to get the latest llvm/clang from http://clang.llvm.org/get_started.html and build it for Visual Studio ( this never worked properly in the past and there is no mention of VS2012 on that page ). Am I supposed to use a 'clang' toolset on Windows with Boost Build ? As usual, with no doubt all the "good" intentions in the world to allow clang to be used under Windows, the documentation, explanation, and support for clnag under Windows is lacking/minimal.
On 28 September 2013 21:50, Edward Diener wrote:
I still do not see a roadmap for using clang with Boost Build under Windows to build/test Boost libraries.
Am I supposed to download a Windows snapshot from http://llvm.org/builds/ ?
Am I supposed to get the latest llvm/clang from http://clang.llvm.org/get_started.html and build it for Visual Studio ( this never worked properly in the past and there is no mention of VS2012 on that page ).
Am I supposed to use a 'clang' toolset on Windows with Boost Build ?
As usual, with no doubt all the "good" intentions in the world to allow clang to be used under Windows, the documentation, explanation, and support for clnag under Windows is lacking/minimal.
Sounds like you're expecting someone to have already made this work. That's not how the bleeding edge of open source works, *especially* when combining things from different projects on a new platform! Someone has to figure all that stuff out bit by bit and fix the things that don't work. If you just expect to download a complete, working environment then you should wait until someone else has done the hard work.
On 9/29/2013 11:13 AM, Jonathan Wakely wrote:
On 28 September 2013 21:50, Edward Diener wrote:
I still do not see a roadmap for using clang with Boost Build under Windows to build/test Boost libraries.
Am I supposed to download a Windows snapshot from http://llvm.org/builds/ ?
Am I supposed to get the latest llvm/clang from http://clang.llvm.org/get_started.html and build it for Visual Studio ( this never worked properly in the past and there is no mention of VS2012 on that page ).
Am I supposed to use a 'clang' toolset on Windows with Boost Build ?
As usual, with no doubt all the "good" intentions in the world to allow clang to be used under Windows, the documentation, explanation, and support for clnag under Windows is lacking/minimal.
Sounds like you're expecting someone to have already made this work. That's not how the bleeding edge of open source works, *especially* when combining things from different projects on a new platform!
Someone has to figure all that stuff out bit by bit and fix the things that don't work. If you just expect to download a complete, working environment then you should wait until someone else has done the hard work.
See my OP in another thread.
On Sun, Sep 29, 2013 at 11:13 AM, Jonathan Wakely <jwakely.boost@kayari.org>wrote:
On 28 September 2013 21:50, Edward Diener wrote:
I still do not see a roadmap for using clang with Boost Build under
to build/test Boost libraries.
Am I supposed to download a Windows snapshot from http://llvm.org/builds/ ?
Am I supposed to get the latest llvm/clang from http://clang.llvm.org/get_started.html and build it for Visual Studio (
never worked properly in the past and there is no mention of VS2012 on
Windows this that
page ).
Am I supposed to use a 'clang' toolset on Windows with Boost Build ?
As usual, with no doubt all the "good" intentions in the world to allow clang to be used under Windows, the documentation, explanation, and support for clnag under Windows is lacking/minimal.
Sounds like you're expecting someone to have already made this work. That's not how the bleeding edge of open source works, *especially* when combining things from different projects on a new platform!
Someone has to figure all that stuff out bit by bit and fix the things that don't work. If you just expect to download a complete, working environment then you should wait until someone else has done the hard work.
+1 Edward, Jonathan is exactly right about this. If you want to help, at the very least start grinding out bug reports for Clang on Windows. If you want to do even more, ask the Clang on Windows team what more you can do. For example, running tests for them. See their request for a test runner (hard to do cause I haven't posted it yet, but wait a few minutes...). --Beman
On 9/29/2013 3:32 PM, Beman Dawes wrote:
On Sun, Sep 29, 2013 at 11:13 AM, Jonathan Wakely <jwakely.boost@kayari.org>wrote:
On 28 September 2013 21:50, Edward Diener wrote:
I still do not see a roadmap for using clang with Boost Build under
to build/test Boost libraries.
Am I supposed to download a Windows snapshot from http://llvm.org/builds/ ?
Am I supposed to get the latest llvm/clang from http://clang.llvm.org/get_started.html and build it for Visual Studio (
never worked properly in the past and there is no mention of VS2012 on
Windows this that
page ).
Am I supposed to use a 'clang' toolset on Windows with Boost Build ?
As usual, with no doubt all the "good" intentions in the world to allow clang to be used under Windows, the documentation, explanation, and support for clnag under Windows is lacking/minimal.
Sounds like you're expecting someone to have already made this work. That's not how the bleeding edge of open source works, *especially* when combining things from different projects on a new platform!
Someone has to figure all that stuff out bit by bit and fix the things that don't work. If you just expect to download a complete, working environment then you should wait until someone else has done the hard work.
+1
Edward, Jonathan is exactly right about this.
If you want to help, at the very least start grinding out bug reports for Clang on Windows. If you want to do even more, ask the Clang on Windows team what more you can do. For example, running tests for them. See their request for a test runner (hard to do cause I haven't posted it yet, but wait a few minutes...).
With all due respect, Beman, there is no point of doing this at least for Boost headers once I reverted the fix to the Boost PP code that would have allowed clang under Windows to correctly compiler Boost PP code as a strictly conforming C++ standard preprocessor. It fails miserably as the VC++ preprocessor and I am not personally interested particularly in discovering why since the VC++ preprocessor is just badly broken in a number of respects general. To emulate that brokeness cannot be the goal of any C++ compiler. I will wish the clang people best of luck on their Windows implementation but if it means emulating VC++ in every respect I do not see the purpose of it, as I can just as well use VC++.
On Sun, Sep 29, 2013 at 4:06 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
With all due respect, Beman, there is no point of doing this at least for Boost headers once I reverted the fix to the Boost PP code that would have allowed clang under Windows to correctly compiler Boost PP code as a strictly conforming C++ standard preprocessor. It fails miserably as the VC++ preprocessor and I am not personally interested particularly in discovering why since the VC++ preprocessor is just badly broken in a number of respects general. To emulate that brokeness cannot be the goal of any C++ compiler.
IIUC, they are aiming to support the aspects of VC++ that are required to compile and run the libraries shipped with Visual Studio and libraries like Boost. I doubt they intend to mimic bugs not required for that purpose, and they have stated up front that they intend to support all C++11/14 features, not just those supported by VC++.
I will wish the clang people best of luck on their Windows implementation but if it means emulating VC++ in every respect I do not see the purpose of it, as I can just as well use VC++.
VC++ is not planning to support all of C++11/14 until roughly the end of 2014. Clang under Visual Studio will support all known C++11/14 features out of the chute. Surely that is a huge win for Visual Studio users, whether boost developers or otherwise. Even once VC++ catches up, there is a great advantage in having two compilers running under the same IDE since errors resulting in hard to diagnose error messages from one compiler often produce easy to understand error messages from a different compiler. It also makes it faster to tell if an error is a compiler error or a user error. --Beman
On Sun, Sep 29, 2013 at 4:43 PM, Beman Dawes <bdawes@acm.org> wrote:
On Sun, Sep 29, 2013 at 4:06 PM, Edward Diener <eldiener@tropicsoft.com
wrote:
With all due respect, Beman, there is no point of doing this at least for Boost headers once I reverted the fix to the Boost PP code that would
have
allowed clang under Windows to correctly compiler Boost PP code as a strictly conforming C++ standard preprocessor. It fails miserably as the VC++ preprocessor and I am not personally interested particularly in discovering why since the VC++ preprocessor is just badly broken in a number of respects general. To emulate that brokeness cannot be the goal of any C++ compiler.
IIUC, they are aiming to support the aspects of VC++ that are required to compile and run the libraries shipped with Visual Studio and libraries like Boost. I doubt they intend to mimic bugs not required for that purpose, and they have stated up front that they intend to support all C++11/14 features, not just those supported by VC++.
Indeed. Boost.PP I think would likely be a prime candidate for explicitly detecting Clang (even on Windows) and just doing the right thing.
On 9/29/2013 6:17 PM, Chandler Carruth wrote:
On Sun, Sep 29, 2013 at 4:43 PM, Beman Dawes <bdawes@acm.org> wrote:
On Sun, Sep 29, 2013 at 4:06 PM, Edward Diener <eldiener@tropicsoft.com
wrote:
With all due respect, Beman, there is no point of doing this at least for Boost headers once I reverted the fix to the Boost PP code that would
have
allowed clang under Windows to correctly compiler Boost PP code as a strictly conforming C++ standard preprocessor. It fails miserably as the VC++ preprocessor and I am not personally interested particularly in discovering why since the VC++ preprocessor is just badly broken in a number of respects general. To emulate that brokeness cannot be the goal of any C++ compiler.
IIUC, they are aiming to support the aspects of VC++ that are required to compile and run the libraries shipped with Visual Studio and libraries like Boost. I doubt they intend to mimic bugs not required for that purpose, and they have stated up front that they intend to support all C++11/14 features, not just those supported by VC++.
Indeed. Boost.PP I think would likely be a prime candidate for explicitly detecting Clang (even on Windows) and just doing the right thing.
The fix that I had made to Boost PP config.h, which I was asked to remove by Beman Dawes, explicitly detects that when _MSC_VER is defined and __clang__ is defined Boost PP should not treat the compiler as VC++. In the Boost PP config.h file prior to my fix if _MSC_VER is defined then the compiler is treated as VC++. There are other cases in the Boost header files that assume that when _MSC_VER is defined the compiler is VC++ ( see my thread "Boost and clang under Windows" ) without checking if it could be another compiler emulating VC++. I had proposed in the aforementioned thread that I was willing to work on changing such code in other Boost libraries so that it did the correct thing when both _MSC_VER and __clang__ were defined, but the reaction of not only Mr. Dawes and others was that I should not do that so I desisted.
On Sun, Sep 29, 2013 at 8:36 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
There are other cases in the Boost header files that assume that when _MSC_VER is defined the compiler is VC++ ( see my thread "Boost and clang under Windows" ) without checking if it could be another compiler emulating VC++.
But that is a mistake. BOOST_MSVC has been the preferred macro to check for VC++ since September of 2001. Since even before then there have been non-Microsoft compilers that define _MSC_VER. --Beman
On 9/29/2013 9:13 PM, Beman Dawes wrote:
On Sun, Sep 29, 2013 at 8:36 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
There are other cases in the Boost header files that assume that when _MSC_VER is defined the compiler is VC++ ( see my thread "Boost and clang under Windows" ) without checking if it could be another compiler emulating VC++.
But that is a mistake. BOOST_MSVC has been the preferred macro to check for VC++ since September of 2001. Since even before then there have been non-Microsoft compilers that define _MSC_VER.
The Boost PP config.h file was created by Paul Mensonides. Boost PP does not use the Boost.Config library or any other Boost library, so using BOOST_MSVC is not possible. You need to talk to Paul about his reasons and design. I am just trying to "fix" the Boost PP library so that clang on Windows works there. The reality is that a number of other Boost libraries use _MSC_VER instead of BOOST_MSVC in order to check for VC++ emulation. In some of those other libraries further checks are done to detect which actual compiler is using _MSC_VER and different code is often invoked in that case. But naturally there are no further checks for clang, since clang under Windows with _MSC_VER defined is "new".
On Sun, Sep 29, 2013 at 7:36 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
The fix that I had made to Boost PP config.h, which I was asked to remove by Beman Dawes, explicitly detects that when _MSC_VER is defined and __clang__ is defined Boost PP should not treat the compiler as VC++. In the Boost PP config.h file prior to my fix if _MSC_VER is defined then the compiler is treated as VC++.
There are other cases in the Boost header files that assume that when _MSC_VER is defined the compiler is VC++ ( see my thread "Boost and clang under Windows" ) without checking if it could be another compiler emulating VC++. I had proposed in the aforementioned thread that I was willing to work on changing such code in other Boost libraries so that it did the correct thing when both _MSC_VER and __clang__ were defined, but the reaction of not only Mr. Dawes and others was that I should not do that so I desisted.
Our hope is that generally speaking, you shouldn't need to special case Clang -- it should be compatible. When it isn't compatible, ideally we'd like to fix the bugs so that it is compatible. There may be a few cases where the code that Boost is using for VC++ is working around (and in the process relying on) really excessive quirks or bugs, and there it may be more pragmatic to just switch to more standards-based code path by checking for Clang explicitly. In other cases, VC++ may not have access to features that it makes sense to enable by detecting Clang. If there are questions about a specific case, feel free to reach out to the Clang developers with either a bug report or email, and they can likely help.
On 9/29/2013 10:15 PM, Chandler Carruth wrote:
On Sun, Sep 29, 2013 at 7:36 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
The fix that I had made to Boost PP config.h, which I was asked to remove by Beman Dawes, explicitly detects that when _MSC_VER is defined and __clang__ is defined Boost PP should not treat the compiler as VC++. In the Boost PP config.h file prior to my fix if _MSC_VER is defined then the compiler is treated as VC++.
There are other cases in the Boost header files that assume that when _MSC_VER is defined the compiler is VC++ ( see my thread "Boost and clang under Windows" ) without checking if it could be another compiler emulating VC++. I had proposed in the aforementioned thread that I was willing to work on changing such code in other Boost libraries so that it did the correct thing when both _MSC_VER and __clang__ were defined, but the reaction of not only Mr. Dawes and others was that I should not do that so I desisted.
Our hope is that generally speaking, you shouldn't need to special case Clang -- it should be compatible. When it isn't compatible, ideally we'd like to fix the bugs so that it is compatible.
There may be a few cases where the code that Boost is using for VC++ is working around (and in the process relying on) really excessive quirks or bugs, and there it may be more pragmatic to just switch to more standards-based code path by checking for Clang explicitly. In other cases, VC++ may not have access to features that it makes sense to enable by detecting Clang.
If there are questions about a specific case, feel free to reach out to the Clang developers with either a bug report or email, and they can likely help.
There is a clang user mailing list but the clang developers never seem to bother with it. Am I supposed to use the clang developers mailing list instead ? Am I supposed to email some developer in particular ?
On Sun, Sep 29, 2013 at 9:46 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
On 9/29/2013 10:15 PM, Chandler Carruth wrote:
On Sun, Sep 29, 2013 at 7:36 PM, Edward Diener <eldiener@tropicsoft.com>* *wrote:
The fix that I had made to Boost PP config.h, which I was asked to remove
by Beman Dawes, explicitly detects that when _MSC_VER is defined and __clang__ is defined Boost PP should not treat the compiler as VC++. In the Boost PP config.h file prior to my fix if _MSC_VER is defined then the compiler is treated as VC++.
There are other cases in the Boost header files that assume that when _MSC_VER is defined the compiler is VC++ ( see my thread "Boost and clang under Windows" ) without checking if it could be another compiler emulating VC++. I had proposed in the aforementioned thread that I was willing to work on changing such code in other Boost libraries so that it did the correct thing when both _MSC_VER and __clang__ were defined, but the reaction of not only Mr. Dawes and others was that I should not do that so I desisted.
Our hope is that generally speaking, you shouldn't need to special case Clang -- it should be compatible. When it isn't compatible, ideally we'd like to fix the bugs so that it is compatible.
There may be a few cases where the code that Boost is using for VC++ is working around (and in the process relying on) really excessive quirks or bugs, and there it may be more pragmatic to just switch to more standards-based code path by checking for Clang explicitly. In other cases, VC++ may not have access to features that it makes sense to enable by detecting Clang.
If there are questions about a specific case, feel free to reach out to the Clang developers with either a bug report or email, and they can likely help.
There is a clang user mailing list but the clang developers never seem to bother with it.
=/ Some of us try, but there is a lot of email to sift through.
Am I supposed to use the clang developers mailing list instead ? Am I supposed to email some developer in particular ?
I would email cfe-dev. You should get prompt responses if the subject makes it clear that you're reporting compatibility bugs. You can also feel free to actually file bugs at http://llvm.org/bugs if that works better. If you need a response or something, feel free to CC me or rnk at google dot com, and one of us can likely help. =] -Chandler
On 9/29/2013 5:43 PM, Beman Dawes wrote:
On Sun, Sep 29, 2013 at 4:06 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
With all due respect, Beman, there is no point of doing this at least for Boost headers once I reverted the fix to the Boost PP code that would have allowed clang under Windows to correctly compiler Boost PP code as a strictly conforming C++ standard preprocessor. It fails miserably as the VC++ preprocessor and I am not personally interested particularly in discovering why since the VC++ preprocessor is just badly broken in a number of respects general. To emulate that brokeness cannot be the goal of any C++ compiler.
IIUC, they are aiming to support the aspects of VC++ that are required to compile and run the libraries shipped with Visual Studio and libraries like Boost. I doubt they intend to mimic bugs not required for that purpose, and they have stated up front that they intend to support all C++11/14 features, not just those supported by VC++.
If they don't intend to "mimic bugs not required for that purpose" then the fix I put in Boost PP config.h is absolutely necessary. Please try "bjam toolset=clang" in the Boost PP test directory under Windows after building or installing clang under Windows. You will soon understand why I made the change I did. After the slew of failures that you see because clang, a highly comformant C++ preprocessor pretends to be VC++ for the purposes of the Boost PP code because it defines _MSC_VER, you can make the change I originally did and try "bjam toolset=clang" again in the Boost PP test directory. Then you will see the difference. I do understand and applaud clang's purpose to compile code properly under Windows, even using the Windows header files. But I do not see the purpose of emulating VC++ when it is broken in regards to the C++ standard if it is not necessary. My Boost PP change made emulation of the broken VC++ preprocessor unnecessary for Boost PP. Please remember that very little other, if any at all, preprocessor code written for Windows is going to require clang to emulate the broken VC++ preprocessor in order to compile Windows code. Boost PP pushes the boundary of what can be done with the C++ preprocessor in a cross-platform way. Can it really be that clang in Windows wants to go from a C++ standard compliant preprocessor to the rather horrible VC++ preprocessor just to accomplish its goal of compiling C++ under Windows ? Each case is distinct and there may be some other cases where clang will attempt to emulate VC++ but trying to duplicate the VC++ preprocessor should not be one of them. I cannot emphasize this more. There's no point in producing a first-rate product and then crippling it in some large respect because of emulation on a particular OS. I don't particularly care what else it brings to the table. I know it is a fine line to decide what compromises might have to be made in pure C++ standard code to emulate VC++ and therefore compile Windows code. There may be other cases where clang will emulate VC++ even if it does not strictly follow the C++ standard. But the preprocessor is not one of them if you know anything at all about how badly VC++'s preprocessor is broken for all but the most basic macro expansions.
I will wish the clang people best of luck on their Windows implementation but if it means emulating VC++ in every respect I do not see the purpose of it, as I can just as well use VC++.
VC++ is not planning to support all of C++11/14 until roughly the end of 2014. Clang under Visual Studio will support all known C++11/14 features out of the chute. Surely that is a huge win for Visual Studio users, whether boost developers or otherwise. Even once VC++ catches up, there is a great advantage in having two compilers running under the same IDE since errors resulting in hard to diagnose error messages from one compiler often produce easy to understand error messages from a different compiler. It also makes it faster to tell if an error is a compiler error or a user error.
On Sun, Sep 29, 2013 at 7:26 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
On 9/29/2013 5:43 PM, Beman Dawes wrote:
On Sun, Sep 29, 2013 at 4:06 PM, Edward Diener <eldiener@tropicsoft.com>* *wrote:
With all due respect, Beman, there is no point of doing this at least for Boost headers once I reverted the fix to the Boost PP code that would have allowed clang under Windows to correctly compiler Boost PP code as a strictly conforming C++ standard preprocessor. It fails miserably as the VC++ preprocessor and I am not personally interested particularly in discovering why since the VC++ preprocessor is just badly broken in a number of respects general. To emulate that brokeness cannot be the goal of any C++ compiler.
IIUC, they are aiming to support the aspects of VC++ that are required to compile and run the libraries shipped with Visual Studio and libraries like Boost. I doubt they intend to mimic bugs not required for that purpose, and they have stated up front that they intend to support all C++11/14 features, not just those supported by VC++.
If they don't intend to "mimic bugs not required for that purpose" then the fix I put in Boost PP config.h is absolutely necessary. Please try "bjam toolset=clang" in the Boost PP test directory under Windows after building or installing clang under Windows. You will soon understand why I made the change I did. After the slew of failures that you see because clang, a highly comformant C++ preprocessor pretends to be VC++ for the purposes of the Boost PP code because it defines _MSC_VER, you can make the change I originally did and try "bjam toolset=clang" again in the Boost PP test directory. Then you will see the difference.
I do understand and applaud clang's purpose to compile code properly under Windows, even using the Windows header files. But I do not see the purpose of emulating VC++ when it is broken in regards to the C++ standard if it is not necessary. My Boost PP change made emulation of the broken VC++ preprocessor unnecessary for Boost PP. Please remember that very little other, if any at all, preprocessor code written for Windows is going to require clang to emulate the broken VC++ preprocessor in order to compile Windows code. Boost PP pushes the boundary of what can be done with the C++ preprocessor in a cross-platform way. Can it really be that clang in Windows wants to go from a C++ standard compliant preprocessor to the rather horrible VC++ preprocessor just to accomplish its goal of compiling C++ under Windows ?
Each case is distinct and there may be some other cases where clang will attempt to emulate VC++ but trying to duplicate the VC++ preprocessor should not be one of them. I cannot emphasize this more. There's no point in producing a first-rate product and then crippling it in some large respect because of emulation on a particular OS. I don't particularly care what else it brings to the table.
I know it is a fine line to decide what compromises might have to be made in pure C++ standard code to emulate VC++ and therefore compile Windows code. There may be other cases where clang will emulate VC++ even if it does not strictly follow the C++ standard. But the preprocessor is not one of them if you know anything at all about how badly VC++'s preprocessor is broken for all but the most basic macro expansions.
OK, put your patch back in, and see if it helps. Chandler has signed up for the developers list, so he can answer future questions himself. --Beman
On 9/29/2013 8:37 PM, Beman Dawes wrote:
On Sun, Sep 29, 2013 at 7:26 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
On 9/29/2013 5:43 PM, Beman Dawes wrote:
On Sun, Sep 29, 2013 at 4:06 PM, Edward Diener <eldiener@tropicsoft.com>* *wrote:
With all due respect, Beman, there is no point of doing this at least for Boost headers once I reverted the fix to the Boost PP code that would have allowed clang under Windows to correctly compiler Boost PP code as a strictly conforming C++ standard preprocessor. It fails miserably as the VC++ preprocessor and I am not personally interested particularly in discovering why since the VC++ preprocessor is just badly broken in a number of respects general. To emulate that brokeness cannot be the goal of any C++ compiler.
IIUC, they are aiming to support the aspects of VC++ that are required to compile and run the libraries shipped with Visual Studio and libraries like Boost. I doubt they intend to mimic bugs not required for that purpose, and they have stated up front that they intend to support all C++11/14 features, not just those supported by VC++.
If they don't intend to "mimic bugs not required for that purpose" then the fix I put in Boost PP config.h is absolutely necessary. Please try "bjam toolset=clang" in the Boost PP test directory under Windows after building or installing clang under Windows. You will soon understand why I made the change I did. After the slew of failures that you see because clang, a highly comformant C++ preprocessor pretends to be VC++ for the purposes of the Boost PP code because it defines _MSC_VER, you can make the change I originally did and try "bjam toolset=clang" again in the Boost PP test directory. Then you will see the difference.
I do understand and applaud clang's purpose to compile code properly under Windows, even using the Windows header files. But I do not see the purpose of emulating VC++ when it is broken in regards to the C++ standard if it is not necessary. My Boost PP change made emulation of the broken VC++ preprocessor unnecessary for Boost PP. Please remember that very little other, if any at all, preprocessor code written for Windows is going to require clang to emulate the broken VC++ preprocessor in order to compile Windows code. Boost PP pushes the boundary of what can be done with the C++ preprocessor in a cross-platform way. Can it really be that clang in Windows wants to go from a C++ standard compliant preprocessor to the rather horrible VC++ preprocessor just to accomplish its goal of compiling C++ under Windows ?
Each case is distinct and there may be some other cases where clang will attempt to emulate VC++ but trying to duplicate the VC++ preprocessor should not be one of them. I cannot emphasize this more. There's no point in producing a first-rate product and then crippling it in some large respect because of emulation on a particular OS. I don't particularly care what else it brings to the table.
I know it is a fine line to decide what compromises might have to be made in pure C++ standard code to emulate VC++ and therefore compile Windows code. There may be other cases where clang will emulate VC++ even if it does not strictly follow the C++ standard. But the preprocessor is not one of them if you know anything at all about how badly VC++'s preprocessor is broken for all but the most basic macro expansions.
OK, put your patch back in, and see if it helps.
Patch has been reinstated and there are now, as I had expected, no errors when running the Boost PP tests or when using the Boost PP macros in other libraries. But there are still errors in other libraries with clang on Windows which have nothing to do with Boost PP. I can do my best to fix those problems, always telling others what I would like to do before I do it to get approval.
Chandler has signed up for the developers list, so he can answer future questions himself.
Sounds great. As I originally said I would like to work to get clang working for Boost libraries.
On Sun, Sep 29, 2013 at 9:14 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
Chandler has signed up for the developers list, so he can answer future
questions himself.
Sounds great.
As I originally said I would like to work to get clang working for Boost libraries.
I'm happy to help as much as I can. It may be useful to CC me directly on emails you want me to look at. I scan the list, but might miss a message otherwise.
On 9/29/2013 10:16 PM, Chandler Carruth wrote:
On Sun, Sep 29, 2013 at 9:14 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
Chandler has signed up for the developers list, so he can answer future
questions himself.
Sounds great.
As I originally said I would like to work to get clang working for Boost libraries.
I'm happy to help as much as I can. It may be useful to CC me directly on emails you want me to look at. I scan the list, but might miss a message otherwise.
OK, thanks ! I will probably post on this mailing list and only bother you if I don't hear anything otherwise.
On 9/28/2013 1:26 PM, Beman Dawes wrote:
On Tue, Sep 24, 2013 at 10:36 AM, Sergey Cheban <s.cheban@drweb.com> wrote:
On 24.09.2013 16:41, Jonathan Wakely wrote:
Beman said they want bug reports, so http://llvm.org/bugs/ seem the
obvious choice.
I think that it is too early to fill any external bug reports for the compiler that is unable to compile the first "hello world" example from the Stroustrup's book.
I've confirmed in face-to-face discussion with several key Clang folks that they do indeed to want bug reports against the Windows port. In other words, just what Jonathan said.
Unfortunately there is still no workable Boost Build implementation of clang for Windows, so it is impossible to test clang with Boost Build. I built the latest clang from llvm/clang and then ran the tests of the central Boost library for all template metaprogramming, Boost.MPL, with clang on Windows. The results were many errors almost certainly because of some setup problem with clang and Boost Build: ------------------------------------------------------------ clang-linux.compile.c++.without-pth ..\..\..\bin.v2\libs\mpl\test\largest_int.test\clang-linux-3.4\debug\largest_int.obj "C:/Programming/VersionControl/bclang/bin/Release/clang.exe" -c -x c++ -O0 -g -fno-inline -Wall -g -DBOOST_ALL_NO_LIB=1 -I"..\..\.." -o "..\..\..\bin.v2\libs\mpl\test\largest_int.test\clang-linux-3.4\debug\largest_int.obj" "aux_\largest_int.cpp" In file included from aux_\largest_int.cpp:14: In file included from ..\..\..\boost/mpl/aux_/largest_int.hpp:17: ..\..\..\boost/mpl/if.hpp:131:1: error: pasting formed 'BOOST_PP_TUPLE_ELEM_E_2(', an invalid preprocessing token [-Winvalid-token-paste] BOOST_MPL_AUX_NA_SPEC(3, if_) ^ ..\..\..\boost/mpl/aux_/na_spec.hpp:149:40: note: expanded from macro 'BOOST_MPL_AUX_NA_SPEC' #define BOOST_MPL_AUX_NA_SPEC(i, name) \ ^ ..\..\..\boost/mpl/aux_/na_spec.hpp:142:47: note: expanded from macro '\ BOOST_MPL_AUX_NA_SPEC_NO_ETI' #define BOOST_MPL_AUX_NA_SPEC_NO_ETI(i, name) \ ^ ..\..\..\boost/mpl/aux_/na_spec.hpp:63:9: note: expanded from macro '\ BOOST_MPL_AUX_NA_SPEC_MAIN' BOOST_MPL_PP_NESTED_DEF_PARAMS_TAIL(i, typename T, na) \ ^ note: (skipping 5 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all) ..\..\..\boost/preprocessor/tuple/elem.hpp:36:114: note: expanded from macro 'BOOST_PP_TUPLE_ELEM' # define BOOST_PP_TUPLE_ELEM(size, n, tuple) BOOST_PP_TUPLE_ELEM_I(BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM_, n), BOOST_PP_CAT(BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM_E_, size), tuple)) ^ ..\..\..\boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT' # define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b) ^ ..\..\..\boost/preprocessor/cat.hpp:31:55: note: expanded from macro 'BOOST_PP_CAT_I' # define BOOST_PP_CAT_I(a, b) BOOST_PP_CAT_II(~, a ## b) ------------------------------------------------------------ I doubt this is a clang problem per se since clang on Linux handles Boost.MPL quite easily. No doubt the default setup for clang in Windows under Boost Build does not work and I don't really know how to make it work. If we ever have a build of clang for Windows that works with Boost Build in Windows it will be a boon for testing Boost under Windows. But it is not yet a reality.
On 9/28/2013 10:31 PM, Edward Diener wrote:
On 9/28/2013 1:26 PM, Beman Dawes wrote:
On Tue, Sep 24, 2013 at 10:36 AM, Sergey Cheban <s.cheban@drweb.com> wrote:
On 24.09.2013 16:41, Jonathan Wakely wrote:
Beman said they want bug reports, so http://llvm.org/bugs/ seem the
obvious choice.
I think that it is too early to fill any external bug reports for the compiler that is unable to compile the first "hello world" example from the Stroustrup's book.
I've confirmed in face-to-face discussion with several key Clang folks that they do indeed to want bug reports against the Windows port. In other words, just what Jonathan said.
Unfortunately there is still no workable Boost Build implementation of clang for Windows, so it is impossible to test clang with Boost Build. I built the latest clang from llvm/clang and then ran the tests of the central Boost library for all template metaprogramming, Boost.MPL, with clang on Windows. The results were many errors almost certainly because of some setup problem with clang and Boost Build:
------------------------------------------------------------
clang-linux.compile.c++.without-pth ..\..\..\bin.v2\libs\mpl\test\largest_int.test\clang-linux-3.4\debug\largest_int.obj
"C:/Programming/VersionControl/bclang/bin/Release/clang.exe" -c -x c++ -O0 -g -fno-inline -Wall -g -DBOOST_ALL_NO_LIB=1 -I"..\..\.." -o "..\..\..\bin.v2\libs\mpl\test\largest_int.test\clang-linux-3.4\debug\largest_int.obj" "aux_\largest_int.cpp"
In file included from aux_\largest_int.cpp:14: In file included from ..\..\..\boost/mpl/aux_/largest_int.hpp:17: ..\..\..\boost/mpl/if.hpp:131:1: error: pasting formed 'BOOST_PP_TUPLE_ELEM_E_2(', an invalid preprocessing token [-Winvalid-token-paste] BOOST_MPL_AUX_NA_SPEC(3, if_) ^ ..\..\..\boost/mpl/aux_/na_spec.hpp:149:40: note: expanded from macro 'BOOST_MPL_AUX_NA_SPEC' #define BOOST_MPL_AUX_NA_SPEC(i, name) \ ^ ..\..\..\boost/mpl/aux_/na_spec.hpp:142:47: note: expanded from macro '\ BOOST_MPL_AUX_NA_SPEC_NO_ETI' #define BOOST_MPL_AUX_NA_SPEC_NO_ETI(i, name) \ ^ ..\..\..\boost/mpl/aux_/na_spec.hpp:63:9: note: expanded from macro '\ BOOST_MPL_AUX_NA_SPEC_MAIN' BOOST_MPL_PP_NESTED_DEF_PARAMS_TAIL(i, typename T, na) \ ^ note: (skipping 5 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all) ..\..\..\boost/preprocessor/tuple/elem.hpp:36:114: note: expanded from macro 'BOOST_PP_TUPLE_ELEM' # define BOOST_PP_TUPLE_ELEM(size, n, tuple) BOOST_PP_TUPLE_ELEM_I(BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM_, n), BOOST_PP_CAT(BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM_E_, size), tuple))
^ ..\..\..\boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT' # define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b) ^ ..\..\..\boost/preprocessor/cat.hpp:31:55: note: expanded from macro 'BOOST_PP_CAT_I' # define BOOST_PP_CAT_I(a, b) BOOST_PP_CAT_II(~, a ## b)
I believe part of the error is in the preprocessor config.hpp file where clang is treated as VC++ because _MSC_VER is defined for the Windows version of clang. I am looking to correct this now as soon as I can find what macro define clang uses to identify itself. It does also look as if clang complaining that '##' is an invalid preprocessing token is an error in the Windows implementation of clang and I will report this to clang as a bug as soon as I can create a simple test case for it.
------------------------------------------------------------
I doubt this is a clang problem per se since clang on Linux handles Boost.MPL quite easily. No doubt the default setup for clang in Windows under Boost Build does not work and I don't really know how to make it work.
If we ever have a build of clang for Windows that works with Boost Build in Windows it will be a boon for testing Boost under Windows. But it is not yet a reality.
On 24 Sep 2013 at 13:41, Jonathan Wakely wrote:
Beman said they want bug reports, so http://llvm.org/bugs/ seem the obvious choice.
Mailing lists are a poor way to report bugs. If noone happens to be interested in looking into it that day then the mail goes unreplied and gets forgotten. Bug reports hang around until someone addresses them.
+1 on that. I've had a very good experience so far with the LLVM bug tracker as compared to the GCC bug tracker. Where on GCC's tracker you really need to prove a bug is incontravertibly true for it to not get autoclosed, it's pretty much the opposite with LLVM. They've fixed 75% of the stuff I've sent them, and in a timely fashion, very impressive. I'd really recommend sending any problems you have on Windows to the LLVM bug tracker. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On 24 September 2013 18:12, Niall Douglas wrote:
On 24 Sep 2013 at 13:41, Jonathan Wakely wrote:
Beman said they want bug reports, so http://llvm.org/bugs/ seem the obvious choice.
Mailing lists are a poor way to report bugs. If noone happens to be interested in looking into it that day then the mail goes unreplied and gets forgotten. Bug reports hang around until someone addresses them.
+1 on that. I've had a very good experience so far with the LLVM bug tracker as compared to the GCC bug tracker. Where on GCC's tracker you really need to prove a bug is incontravertibly true for it to not get autoclosed,
That's clearly not true, based just on the number of open UNCONFIRMED bugs in GCC's bugzilla! We can be pretty militant about seting bugs to WAITING if the report doesn't provide enough information, but I dispute that bugs are "autoclosed" without good reason.
On 24 Sep 2013 at 18:22, Jonathan Wakely wrote:
+1 on that. I've had a very good experience so far with the LLVM bug tracker as compared to the GCC bug tracker. Where on GCC's tracker you really need to prove a bug is incontravertibly true for it to not get autoclosed,
That's clearly not true, based just on the number of open UNCONFIRMED bugs in GCC's bugzilla! We can be pretty militant about seting bugs to WAITING if the report doesn't provide enough information, but I dispute that bugs are "autoclosed" without good reason.
Fair enough, my experience with GCC's issue tracker is approaching a decade old. No offense intended, and glad to know bug reports are welcomed. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On 24 Sep 2013 at 8:00, Edward Diener wrote:
That's nice but my experience in the past has been that no one on the clang mailing list responded when the inability to even build clang for Windows was made known to them.
I don't think it's a huge priority - yet - for the two big developers of clang because MSVC is the de facto compiler on Windows. However clang's AST library is certainly of *great* interest to Windows developers, and that part appears to be very well maintained for Windows. I even found some website providing regular prebuilt Windows binaries for clang's AST library.
Furthermore Boost.Build did not support clang for Windows when I last tried it.
Yeah I misspoke earlier; I was building Boost using scons, not Boost.Build, and therefore my earlier comment about simply asking b2 for clang was wrong. Sorry. My memory is ailing with age sadly :(
Clang is a great compiler under Linux. And I am willing to try to get it to work under Windows using Boost.Build to test Boost libraries, my own and others, under Windows, reporting problems to the appropriate places. But not if I am once again met by indifference when problems occur.
If you were to marry clang with the libstdc++ 4.8 headers in mingw-w64 (it's a simple enough recompile to swap the hardcoded header locations), I think you'd see great success as a mingw substitute. But then mingw has just moved to 4.8, both in traditional mingw and mingw-w64, and combined with the much improved VS2013 that eliminates a good chunk of the need for clang on Windows. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
participants (8)
-
Beman Dawes -
Ben Pope -
Chandler Carruth -
Daryle Walker -
Edward Diener -
Jonathan Wakely -
Niall Douglas -
Sergey Cheban