experimenting experimental clang 3.2 on windows

[Jiqiang Guo]

First, clang needs a gcc for the c++ library and header files included in gcc.  In particular, clang needs a special gcc that support DW2 error handling.  I do not know much about this until I hit errors when the typical gcc such as the one included in rtools does not work.  See here for a reference:

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-August/023578.html

http://gcc.gnu.org/wiki/WindowsGCCImprovements

The gcc I am using that supports DW2 error handling is downloaded from 

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-dw2-4.6-release/i686-w64-mingw32-gcc-dw2-4.6.3-1-release-win32_rubenvb.7z/download

The above gcc is build for 32 bits.  The reason might be that gcc only support DW2 error handling on 32 bits windows now (or results of some other reasons).  This might be the reason that there is only 32bits experimental clang from llvm.org.  

For the above gcc, unzip it and put it somewhere say c:\mingw32-dw2 and then add c:\mingw32-dw2\bin to the PATH environment variable. 

Second, download llvm/clang from http://llvm.org/releases/3.2/clang+llvm-3.2-x86-mingw32-EXPERIMENTAL.tar.gz, and then unzip llvm's files to the above mingw's (ie, merge two bin's, two include's, etc.)  Merging the gcc and llvm/clang seems to be the easiest way I found to avoid clang's inability to find header files of gcc's c++ library. 

It is done.  Here is an example to prove I can really use it with code that throw errors. 

C:\Users\root\Desktop>path

PATH=c:\mingw32-dw2\bin;c:\rtools\bin;C:\Rtools\gcc-4.6.3\bin;C:\Program Files\R

\R-2.15.1\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows

\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Git\cmd;C:\Program File

s (x86)\Git\bin;C:\Program Files\MiKTeX 2.9\miktex\bin\x64\;C:\Program Files\Thi

nkPad\Bluetooth Software\;C:\Program Files\ThinkPad\Bluetooth Software\syswow64;

C:\Program Files\SlikSvn\bin;C:\Program Files (x86)\pdftk-1.44-win-install\bin;C

:\Program Files\Vim\vim73

C:\Users\root\Desktop>type a.cpp

#include <iostream>

int main(int argc, char **argv) {

  std::cout << "test." << std::endl;

  try {

    throw std::exception();

  } catch (const std::exception& e) {

  }

  return 0;

}

C:\Users\root\Desktop>clang++ a.cpp

C:\Users\root\Desktop>a.out

test.

Last, currently I cannot use this clang 3.2 to pass stan's unit tests (this might be what Ben hits on linux using clang 3.2).  And it's a pain to use this clang for R on Windows 7 64bits since 1) it does not support target of 64 bits, which the gcc in rtools supports,  2) different error handling means the need of installing Rcpp from source just for 32 bits, which needs some hack. 

--

Jiqiang

[Jiqiang Guo]

To update and answer Ben's question below from another post.  Building test-unit for Stan is not relevant to Rcpp.  But I tried "make test-unit" again and it went from the beginning to the end, so I suppose all tests were passed.  The difference might be that I used a tiny bit different release of gcc (but still 4.6.3, it is just that the builder put up a new one built on Dec 29, 2012). 

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-dw2-4.6-release/i686-w64-mingw32-gcc-dw2-4.6.3-2-release-win32_rubenvb.7z/download

--

Jiqiang 

CRAN also suggests compiling Rcpp from source. If you do that, can you get clang to pass test-unit on Windows?

[Ben Goodrich]

That is good. What I meant to say was whether you could execute any model. I have a couple of Windows machines here, so I will try to duplicate your success.

Ben

[Jiqiang Guo]

In RStan, some models can be compiled and run using this clang if Rcpp is rebuilt.  (In order to install Rcpp from source using this clang, a gcc for 64 bits such as the one in rtools is still needed since both 32 and 64 bits of Rcpp would be built by R's package installation script.) 

The problem with clang I have so far is that it fails for model src/basic_distributions/inv_wishart.  Using Stan from command line, I found the error message is "The instruction at 0x76ff99777 referenced memory at 0xffffffff. The memory could not be read."  R would crash for this model. 

Using another gcc, RStan could run all example models in Stan.  

--

Jiqiang

--
 
 

[Ben Goodrich]

On Wednesday, January 2, 2013 11:27:24 PM UTC-5, Ben Goodrich wrote:

That is good. What I meant to say was whether you could execute any model. I have a couple of Windows machines here, so I will try to duplicate your success.

No dice here (Windows Vista with CoreDuo processor). I eventually get

clang -I src -I lib/eigen_3.1.2 -I lib/boost_1.52.0 -)3 -Wall -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -c -DGTEST-HAS_PTHREAD=0 -I lib/gtest_1.6.0/include -I lib/gtest_1.6.0 src/test/agrad/matrix_test.cpp -o test/agrad/matrix.o
Assertion failed: Result.isInvalid() && "C++ binary operator overloading is missing candidates!", file /Users/as1/Projects/llvm/release/3.1/src/tools/clang/lib/Sema/SemaOverload.cpp, line 10123

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
clang: error: clang frontend command failed with exit code 3 (use -v to see invocation)
make: *** [test/agrad/matrix.o] Error 3

At least it looks like it is not our fault.

Ben

[Jiqiang Guo]

I came across this and that's why I mentioned somewhere there was a bug for clang 3.1.

So I am using 3.2.

Jiqiang 

--
 
 

[Jiqiang Guo]

By the way, using the following to fix an issue with boost if it comes up.

 https://svn.boost.org/trac/boost/ticket/7452

--

Jiqiang

[Ben Goodrich]

On Thursday, January 3, 2013 12:07:52 AM UTC-5, Jiqiang Guo wrote:

In RStan, some models can be compiled and run using this clang if Rcpp is rebuilt.  (In order to install Rcpp from source using this clang, a gcc for 64 bits such as the one in rtools is still needed since both 32 and 64 bits of Rcpp would be built by R's package installation script.) 

The problem with clang I have so far is that it fails for model src/basic_distributions/inv_wishart.  Using Stan from command line, I found the error message is "The instruction at 0x76ff99777 referenced memory at 0xffffffff. The memory could not be read."  R would crash for this model. 

Using another gcc, RStan could run all example models in Stan.  

For me, both test-unit and inv_wishart are fine when using Rueben's g++ on Vista Pro (not sure if we have ever had a confirmed success on Vista anything). I'll try now with clang-3.2.

Ben

[Ben Goodrich]

On Thursday, January 3, 2013 1:20:45 AM UTC-5, Jiqiang Guo wrote:

I came across this and that's why I mentioned somewhere there was a bug for clang 3.1.

So I am using 3.2.

I apparently downloaded the wrong version from the llvm website. But I can't get anywhere with clang-3.2 and Rueben's most recent gcc. Doing

clang --version

yields a pop-up box that says

This application has failed to start because pthreadGC2.dll was not found. Re-installing the application may fix this problem.

There is a message that mentions this problem here:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056818.html

Did you run into / work around this?

Ben

[Bob Carpenter]

It's not our fault that clang itself clashes, but
there may also be a problem in our code.

The test code may have templating issues that the
ordinary code doesn't -- I'm not sure what the status
of Daniel's use of C++11 features in the tests currently
is.

- Bob

[Jiqiang Guo]

No, I have other problems with the gcc is not compatible with clang. 

What do you mean by Rueben's most recent gcc?  Not the one I pointed to?

--

Jiqiang

--
 
 

[Daniel Lee]

There shouldn't be any C++11 features in the tests now.

--
 
 

[Ben Goodrich]

On Thursday, January 3, 2013 11:11:34 AM UTC-5, Jiqiang Guo wrote:

No, I have other problems with the gcc is not compatible with clang. 

What do you mean by Rueben's most recent gcc?  Not the one I pointed to?

I have the gcc you pointed to. Do you have a file called pthreadGC2.dll somewhere on your machine?

Ben

[Jiqiang Guo]

Yes.  I have it in a couple places.  In particular, there is one in folder bin with the git for windows. 

c:\>dir pthreadgc2.dll /s 

...

Directory of c:\program files (x86)\Git\bin

07/01/2012  11:14 AM 65,124 pthreadGC2.dll 

...

--

Jiqiang 

--
 
 

[Ben Goodrich]

Aha! I haven't installed Git on that computer yet. I just downloaded the v1.1.0 tarball. I will try to slip that pthreadgc2.dll in.

Ben

[Ben Goodrich]

On Thursday, January 3, 2013 12:00:03 PM UTC-5, Ben Goodrich wrote:

Aha! I haven't installed Git on that computer yet. I just downloaded the v1.1.0 tarball. I will try to slip that pthreadgc2.dll in.

OK, with that pthreadgc2.dll, I can get going and then run into the Boost bug that you noted. After patching Boost, I run into linker errors (attached) with stanc that start with

goodrich@CYBERPOWERPC:/opt/stan$ head /tmp/linker_errors.txt
uname: not found
uname: not found
cygwin warning:
  MS-DOS style path detected: src\stan/command/stanc_helper.hpp
  Preferred POSIX equivalent is: src/stan/command/stanc_helper.hpp
  CYGWIN environment variable option "nodosfilewarning" turns off this warning.
  Consult the user's guide for more details about POSIX paths:
    http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
bin/stan/command/stanc.o:fake:(.text+0x16): undefined reference to `std::allocator<char>::allocator()'
bin/stan/command/stanc.o:fake:(.text+0x31): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)'

Did you hit this problem?

Ben


 

[Jiqiang Guo]

I did not hit this problem.  In other cases such as installing rstan from source with the binary Rcpp from Cran, I have similar problem and I guess the reason is that different error handling issues.  That is, if Rcpp is built with gcc with sjlj error handling, building rstan using dwarf error handling gcc will hit this similar problem.  But for your case, some are from the c++ library, which should be fine since it is the one in the dw2-gcc.  Another reason might be that you have some part of stan built using a different gcc.

--

Jiqiang 

--
 
 

[Ben Goodrich]

clang++ on Windows is apparently making progress

http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html

I got some clang binaries installed on the Jenkins box using

http://www.ishani.org/web/articles/code/clang-win32/

but they need the Visual Studio headers to be on the PATH or something which I couldn't find in 30 seconds of trying. Didn't we used to have Visual Studio set up?

Ben