Hi Yan,
On 1 December 2012 at 12:57, Yan Zhou wrote:
| Dear Dirk,
|
| Sorry, in may last email I attached an incorrect diff file. Here is the
corrected one.
|
| xuntyped binary data, RcppCommon.h.d [Click mouse-2 to save to a file]
Nice, that does look indeed clean and proper. Can you tell me a bit more
about the setup you have use:
-- operating system and version
-- compiler(s) and version(s), at least clang++ and intel's icpc (wasn't it
called icc ?)
-- where libc++ came from
-- in case you timed this, what performance differences do you see?
This is very nice news for less-standard systems. Just so that I remain on
the same page, these do still generate gcc-compatible code so what you
generate does in fact interoperates with code on your system which may have
been built by gcc, correct?
Dirk
|
|
| Best,
|
| Yan Zhou
|
| On Dec 1, 2012, at 12:44 PM, Yan Zhou <zhou...@me.com> wrote:
|
| > Dear Dirk,
| >
| > In addition to my last email which provides a path for clang++ with libc++,
I updated the patch to also fix problems with intel icpc in C++11 mode.
| >
| > In the RcppCommon.h, there is comments says that Intel ICPC does not
support C++11 or TR1. That is not entirely true. Intel compiler does not come
with its own standard library. On Linux and Mac OS X it use the libstdc++ come
with the system. On Windows it may use others. The current test has a problem
when an Intel C++ compiler is used in C++11 mode. In that case, headers like
sugar/sets.h test the C++11 macro and conclude it shall define SET to
std::unordered_set. However, C++11 <unordered_set> is not included. So a
compiler error happens.
| >
| > In general, I found Rcpp does not work with compilers in C++11 mode. The
new path, in addition to the own test Clang with libc++, also test the
followings,
| > 1. If Intel compiler is used, test is it is used with libstdc++. If it is
not, then we undef HAS_TR1_... etc. To test if libstdc++ is used, we need to at
least include one standard library header before the testing, so I included
<cmath>, which shall be harmless
| > 2. After trying to include <tr1/unodered_map> etc, we also test if we are
using C++11. If it is, then test if we are using libstdc++ (either gcc, clang,
intel etc). If it is case, and the libstdc++ is recent enough, we include
<unordered_map> and <unordered_set>. Otherwise, if we are using C++11 in Clang
with libc++, we also included <unodered_map> etc.
| >
| > After this patch, Rcpp shall work seamlessly with GCC, Intel and Clang, in
both C++98 and C++11 modes.
| > <RcppCommon.h.diff>
| >
| > Best,
| >
| > Yan Zhou
| >
| >
| >
| > On Dec 1, 2012, at 12:12 PM, Yan Zhou <zhou...@me.com> wrote:
| >
| >> Hi Dirk,
| >>
| >> Rcpp cannot be compiled with clang++ with libc++, even clang++ provides
very good standard conforming in both C++98 and C++11 mode, and libc++ provides
100% C++98/11 features. The problems is Rcpp's use of TR1 instead of C++11, and
does not perform some compiler checks properly. I made a small patch to the
include/RcppCommon.h header, which makes Rcpp works with Clang++ and libc++ in
C++11 mode.
| >>
| >> To summary the change, when macro __clang__ is defined, the header use
clang's __has_include to check if <tr1/unordered_map> and <tr1/unordered_set>
is present, if not, it undef HAS_TR1_UNORDERED_MAP etc. In addition, if
__has_include<unordered_map> is tested to be true while HAS_TR1_... etc are not
true, the C++11 header is included. So headers like sugar/sets.h can use C++11
header instead of TR1, since they already test __cplusplus >= 201103L.
| >>
| >> With this patch, nothing already works will be broken. This patch only
affects clang++ with libc++ situation. Using clang++ with libstdc++ the
situation will be exactly the same as before.
| >>
| >> At the end of the email is the path, it is also attached as a diff file
| >>
| >> Best,
| >>
| >> Yan Zhou
| >> <RcppCommon.h.diff>
| >>
| >> --- Rcpp/inst/include/RcppCommon.h 2012-11-23 01:07:34.000000000 +0000
| >> +++ ../Downloads/Rcpp/inst/include/RcppCommon.h 2012-12-01
11:46:48.000000000 +0000
| >> @@ -107,6 +107,20 @@
| >> // #endif
| >> // #endif
| >>
| >> +#ifdef __clang__
| >> + #if !__has_include(<tr1/unordered_map>)
| >> + #undef HAS_TR1
| >> + #undef HAS_TR1_UNORDERED_MAP
| >> + #endif
| >> + #if !__has_include(<tr1/unordered_set>)
| >> + #undef HAS_TR1
| >> + #undef HAS_TR1_UNORDERED_SET
| >> + #endif
| >> + #if !__has_feature(cxx_variadic_templates)
| >> + #undef HAS_VARIADIC_TEMPLATES
| >> + #endif
| >> +#endif
| >> +
| >> #ifdef __INTEL_COMPILER
| >> // This is based on an email by Alexey Stukalov who tested
| >> // Intel Compiler 12.0 and states that is does support Cxx0x
| >> @@ -149,6 +163,15 @@
| >> #include <tr1/unordered_set>
| >> #endif
| >>
| >> +#ifdef __clang__
| >> + #if !defined(HAS_TR1_UNORDERED_MAP) && __has_include(<unordered_map>)
| >> + #include <unordered_map>
| >> + #endif
| >> + #if !defined(HAS_TR1_UNORDERED_SET) && __has_include(<unordered_set>)
| >> + #include <unordered_set>
| >> + #endif
| >> +#endif
| >> +
| >> std::string demangle( const std::string& name) ;
| >> #define DEMANGLE(__TYPE__) demangle( typeid(__TYPE__).name() ).c_str()
| >>
| >>
| >> _______________________________________________
| >> Rcpp-devel mailing list
| >> Rcpp-devel@lists.r-forge.r-project.org
| >> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
| >
| > _______________________________________________
| > Rcpp-devel mailing list
| > Rcpp-devel@lists.r-forge.r-project.org
| > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
|
|
| ----------------------------------------------------------------------
| _______________________________________________
| Rcpp-devel mailing list
| Rcpp-devel@lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
