Issue with Rcpp and Intel compiler exposed by building haven #640

wds15 · 2017-01-30T16:22:25Z

When installing haven 1.0.0 with the Intel compiler I endup getting this error in Rcpp files. Hadley suggested this is an Rcpp issue (I reported this for haven already):

Installing haven 1.0.0 with the Intel compiler (icpc (ICC) 15.0.3 20150407) I get this error log:

icpc -I/CHBS/apps/R/3.2.3/lib64/R/include        -I/usr/local/include -I"/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include" -I"/CHBS/apps/dev_apps/R/dev_lib/3.2/BH/include"  -Ireadstat -fpic  -march=native -O3  -DEIGEN_USE_MKL_ALL -DEIGEN_NO_DEBUG -DNDEBUG -fp-model precise -fp-model source -mkl=sequential                                                           -c DfReader.cpp -o DfReader.o
In file included from /CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp.h(86),
                 from DfReader.cpp(1):
/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp/algorithm.h(153): warning #858: type qualifier on return type is meaningless
          static inline RCPP_CONSTEXPR double ZERO() { return 0.0; }
                        ^

In file included from /CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp.h(86),
                 from DfReader.cpp(1):
/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp/algorithm.h(154): warning #858: type qualifier on return type is meaningless
          static inline RCPP_CONSTEXPR double ONE() { return 1.0; }
                        ^

In file included from /CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp.h(86),
                 from DfReader.cpp(1):
/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp/algorithm.h(162): warning #858: type qualifier on return type is meaningless
          static inline RCPP_CONSTEXPR int ZERO() { return 0; }
                        ^

In file included from /CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp.h(86),
                 from DfReader.cpp(1):
/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp/algorithm.h(163): warning #858: type qualifier on return type is meaningless
          static inline RCPP_CONSTEXPR int ONE() { return 1; }
                        ^

DfReader.cpp(355): error: more than one operator "==" matches these operands:
            built-in operator "pointer == pointer"
            function "Rcpp::operator==(Rcpp::Na_Proxy, SEXP)"
            operand types are: Rcpp::AttributeProxyPolicy<Rcpp::RObject_Impl<Rcpp::PreserveStorage>>::AttributeProxy == SEXP
          if (col.attr("class") == R_NilValue) {
                                ^

compilation aborted for DfReader.cpp (code 2)
make: *** [DfReader.o] Error 2
ERROR: compilation failed for package ‘haven’
* removing ‘/CHBS/apps/dev_apps/R/dev_lib/3.2/haven’

The downloaded source packages are in
	‘/export/scratch/SGE/2415135.1.interactive.q/RtmpfjPEjz/downloaded_packages’
Warning message:
In install.packages("haven") :
  installation of package ‘haven’ had non-zero exit status

Here is my session info:

R3.2.3> sessionInfo()
R version 3.2.3 (2015-12-10)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Red Hat Enterprise Linux Server release 6.7 (Santiago)

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8    
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
[1] tools_3.2.3

Could it be that some C++ being used is not fully standard?

The text was updated successfully, but these errors were encountered:

eddelbuettel · 2017-01-30T16:35:06Z

You are evidently on 3.2.3 as we can tell. That may mean that you are also on an older version of Rcpp.

Here, you didn't even tell which version it was. Could you do, and if you have not done that yet, also try Rcpp 0.12.9 which is now current?

wds15 · 2017-01-30T17:00:06Z

Thanks for the quick response. Yes, I am on 3.2.3 and I have Rcpp 0.12.9 installed. I even tried with the current github version, but that one does not work either. Please let me know if you need any further information.

eddelbuettel · 2017-01-30T17:09:06Z

Well ... I can't help you as I don't have your compiler.

From the lack of the error message, it doesn't like the #define for RCPP_CONSTEXPR so you could start by not defining that if your compiler is used.

kevinushey · 2017-01-30T17:49:42Z

The problem is that RCPP_CONSTEXPR is defined as const on compilers not supporting constexpr, and the const on the return type is meaningless.

See e.g. https://software.intel.com/en-us/articles/cdiag858

We should define something like RCPP_CONSTEXPR_RETURN, which is empty when the compiler does not support constant expressions, and constexpr otherwise.

I'm guessing that gcc and clang are fine with this (we've never seen this warning) so it is likely unique to icc.

eddelbuettel · 2017-01-30T17:50:34Z

A quick recursive grep shows that RCPP_CONSTEXPR is defined and and used only in the file inst/include/Rcpp/algorithm.h. So we may need to protect that declaration by a test for icc or some other tricks. But we need some help from you. Can you start with the lines 2 to 4 there and check what value you are getting for the __cplusplus built-in? That may be as simple as running

R> Rcpp::evalCpp("__cplusplus")
[1] 199711
R>

and while I was trying to redo that as C++11 @kevinushey already gave you a better answer.

Edit: For reference:

R> Rcpp::evalCpp("__cplusplus")
[1] 199711
R> Rcpp::evalCpp("__cplusplus", plugins="cpp11")
[1] 201103
R> Rcpp::evalCpp("__cplusplus", plugins="cpp14")
[1] 201402
R>

dcdillon · 2017-01-30T17:59:58Z

Actually we just need to define RCPP_CONSTEXPR as empty for non c++11 builds. No need to have const in front of the return type I think.

kevinushey · 2017-01-30T18:02:07Z

Do we use constexpr anywhere for variables? (Probably not since we're mostly header-only, but...)

E.g. it's legal to write things like:

static constexpr int foo = 1;

We should probably make sure that, if we do, we replace those usages of constexpr with const.

eddelbuettel · 2017-01-30T18:03:15Z

So @wds15: as a local test, please edit that file to read

#if __cplusplus >= 201103L
#    define RCPP_CONSTEXPR constexpr
#else
#    define RCPP_CONSTEXPR 
#endif

@kevinushey @dcdillon We could possibly move the declaration to one of the compiler or preprocessor directories.

wds15 · 2017-01-31T08:34:23Z

Thanks so much for the effort. I tried as you suggested, but it did not work. I then did a few tests in small tests as follows:

compilation with vanilla Rcpp/alogrithm.hpp and turned C++11 on:

c++11 compile:

icpc -I/CHBS/apps/R/3.2.3/lib64/R/include        -I/usr/local/include -I"/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include" -I"/home/weberse2/R/x86_64-pc-linux-gnu-library/3.2new/BH/include"  -Ireadstat -fpic  -std=c++11 -march=native -O3  -DEIGEN_USE_MKL_ALL -DEIGEN_NO_DEBUG -DNDEBUG -fp-model precise -fp-model source -mkl=sequential                                                           -c DfReader.cpp -o DfReader.o
In file included from /CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp.h(94),
                 from DfReader.cpp(1):
/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp/algorithm.h(153): warning #858: type qualifier on return type is meaningless
          static inline RCPP_CONSTEXPR double ZERO() { return 0.0; }
                        ^

In file included from /CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp.h(94),
                 from DfReader.cpp(1):
/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp/algorithm.h(154): warning #858: type qualifier on return type is meaningless
          static inline RCPP_CONSTEXPR double ONE() { return 1.0; }
                        ^

In file included from /CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp.h(94),
                 from DfReader.cpp(1):
/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp/algorithm.h(162): warning #858: type qualifier on return type is meaningless
          static inline RCPP_CONSTEXPR int ZERO() { return 0; }
                        ^

In file included from /CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp.h(94),
                 from DfReader.cpp(1):
/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp/algorithm.h(163): warning #858: type qualifier on return type is meaningless
          static inline RCPP_CONSTEXPR int ONE() { return 1; }
                        ^

DfReader.cpp(355): error: more than one operator "==" matches these operands:
            built-in operator "pointer == pointer"
            function "Rcpp::operator==(Rcpp::Na_Proxy, SEXP)"
            operand types are: Rcpp::AttributeProxyPolicy<Rcpp::RObject_Impl<Rcpp::PreserveStorage>>::AttributeProxy == SEXP
          if (col.attr("class") == R_NilValue) {
                                ^

compilation aborted for DfReader.cpp (code 2)
make: *** [DfReader.o] Error 2
ERROR: compilation failed for package ‘haven’

So it looks to me as if the C++11 detection which you do does not work for Intel. OK, so I thought lets force the constexpr definition (by just defining as constexpr without the ifdef) and run with C++11 again:

icpc -I/CHBS/apps/R/3.2.3/lib64/R/include        -I/usr/local/include -I"/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include" -I"/home/weberse2/R/x86_64-pc-linux-gnu-library/3.2new/BH/include"  -Ireadstat -fpic  -std=c++11 -march=native -O3  -DEIGEN_USE_MKL_ALL -DEIGEN_NO_DEBUG -DNDEBUG -fp-model precise -fp-model source -mkl=sequential                                                           -c DfReader.cpp -o DfReader.o
DfReader.cpp(355): error: more than one operator "==" matches these operands:
            built-in operator "pointer == pointer"
            function "Rcpp::operator==(Rcpp::Na_Proxy, SEXP)"
            operand types are: Rcpp::AttributeProxyPolicy<Rcpp::RObject_Impl<Rcpp::PreserveStorage>>::AttributeProxy == SEXP
          if (col.attr("class") == R_NilValue) {
                                ^

compilation aborted for DfReader.cpp (code 2)
make: *** [DfReader.o] Error 2
ERROR: compilation failed for package ‘haven’

Now the constexpr is used, but there is still an error.

To complete things I furthermore compiled with no c++11 and forced definition with const. Then I get

icpc -I/CHBS/apps/R/3.2.3/lib64/R/include        -I/usr/local/include -I"/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include" -I"/home/weberse2/R/x86_64-pc-linux-gnu-library/3.2new/BH/include"  -Ireadstat -fpic  -march=native -O3  -DEIGEN_USE_MKL_ALL -DEIGEN_NO_DEBUG -DNDEBUG -fp-model precise -fp-model source -mkl=sequential                                                           -c DfReader.cpp -o DfReader.o
In file included from /CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp.h(94),
                 from DfReader.cpp(1):
/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp/algorithm.h(154): warning #858: type qualifier on return type is meaningless
          static inline RCPP_CONSTEXPR double ZERO() { return 0.0; }
                        ^

In file included from /CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp.h(94),
                 from DfReader.cpp(1):
/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp/algorithm.h(155): warning #858: type qualifier on return type is meaningless
          static inline RCPP_CONSTEXPR double ONE() { return 1.0; }
                        ^

In file included from /CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp.h(94),
                 from DfReader.cpp(1):
/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp/algorithm.h(163): warning #858: type qualifier on return type is meaningless
          static inline RCPP_CONSTEXPR int ZERO() { return 0; }
                        ^

In file included from /CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp.h(94),
                 from DfReader.cpp(1):
/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp/algorithm.h(164): warning #858: type qualifier on return type is meaningless
          static inline RCPP_CONSTEXPR int ONE() { return 1; }
                        ^

DfReader.cpp(355): error: more than one operator "==" matches these operands:
            built-in operator "pointer == pointer"
            function "Rcpp::operator==(Rcpp::Na_Proxy, SEXP)"
            operand types are: Rcpp::AttributeProxyPolicy<Rcpp::RObject_Impl<Rcpp::PreserveStorage>>::AttributeProxy == SEXP
          if (col.attr("class") == R_NilValue) {
                                ^

Finally, I compile again without C++11, but forcing as you suggest RCPP_CONSTEXPR to be empty:

icpc -I/CHBS/apps/R/3.2.3/lib64/R/include        -I/usr/local/include -I"/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include" -I"/home/weberse2/R/x86_64-pc-linux-gnu-library/3.2new/BH/include"  -Ireadstat -fpic  -march=native -O3  -DEIGEN_USE_MKL_ALL -DEIGEN_NO_DEBUG -DNDEBUG -fp-model precise -fp-model source -mkl=sequential                                                           -c DfReader.cpp -o DfReader.o
In file included from /CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp.h(94),
                 from DfReader.cpp(1):
/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp/algorithm.h(152): error: a member with an in-class initializer must be const
          static RCPP_CONSTEXPR int RTYPE = REALSXP;
                                          ^

In file included from /CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp.h(94),
                 from DfReader.cpp(1):
/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp/algorithm.h(161): error: a member with an in-class initializer must be const
          static RCPP_CONSTEXPR int RTYPE = INTSXP;
                                          ^

In file included from /CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp.h(94),
                 from DfReader.cpp(1):
/CHBS/apps/dev_apps/R/dev_lib/3.2/Rcpp/include/Rcpp/algorithm.h(171): error: a member with an in-class initializer must be const
          static RCPP_CONSTEXPR int RTYPE = helper_type::RTYPE;
                                          ^

DfReader.cpp(355): error: more than one operator "==" matches these operands:
            built-in operator "pointer == pointer"
            function "Rcpp::operator==(Rcpp::Na_Proxy, SEXP)"
            operand types are: Rcpp::AttributeProxyPolicy<Rcpp::RObject_Impl<Rcpp::PreserveStorage>>::AttributeProxy == SEXP
          if (col.attr("class") == R_NilValue) {
                                ^

So still not working. I hope this helps to pin down the issue here. Let me know if you need further tests. BTW, the boost config library is quite reliable to detect these compiler quirks.

eddelbuettel · 2017-01-31T13:09:18Z

the boost config library is quite reliable to detect these compiler quirks

We cannot / do not want to have a build dependency on Boost.

Above, you had one case where you died in DFreader. That is a haven file. Looks like you made progress there. I encouragement to work that angle as nobody here uses the Intel compiler.

Or if you must use Rcpp, try some older releases, maybe as far back as 0.12.5.

wds15 · 2017-01-31T14:22:48Z

Sure, I understand the desire to minimize dependencies. The C++11 detection you do does not work for Intel. You may want to include

#if __cplusplus >= 201103L || __INTEL_CXX11_MODE__ == 1
#    define RCPP_CONSTEXPR constexpr
#else
#    define RCPP_CONSTEXPR const
#endif

to make Intel pickup the C++11 definition if C++11 is switched on.

I know that Intel compilers can be a problem and my apologies for the inconvenience. It would be great to include the above into Rcpp. The Intel compiler just happens to be the one on our production system. If I were to pick the compiler in production it would be the one from Rtools (gcc 4.9.3), but changeing that is beyond my control.

Thanks for your support.

eddelbuettel · 2017-01-31T14:28:29Z

Yes, we do have similar tests in other place for this. The file that is giving you trouble is newer, and decided to redo its tests for compiler / C++ standard locally, and we now see a shortcoming. It happens.

But we rely on you to find test that works. Are you saying that the above is sufficient now?

Also, some casual reading on SO eg here suggest that this is an Intel compiler issue. The standard apparently talks about this in clear terms:

1 The following macro names shall be defined by the implementation:

__cplusplus

wds15 · 2017-01-31T14:33:00Z

The test I outlined above does work here for me, yes.

This is not the first time we had issues with Intel being the bad guy here.. this is another occasion to ask to switch to gcc. Still, other Intel users will appreciate if the above could be included.

eddelbuettel · 2017-01-31T14:35:06Z

Ok. We may still switch to using 'empty' instead of const as the alternative.

There used to be a (real or perceived) performance gap between icc and gcc but word is that it narrowed. Most folks don't bother with the alternative so we have few tests making icc less attractive.

wds15 · 2017-01-31T14:37:34Z

I think defining it empty cause errors inside of Rcpp as I tested above.

My preferred choice for a production system would be gcc 4.9.3 (like Rtools) combined with the Intel MKL BLAS/LAPACK libraries. That should give almost all performance gain there is to get from this Intel stuff, but still maintain open-source R compatibility.

eddelbuettel · 2017-01-31T14:43:07Z

Granted that just adding the 'or' is simpler / less of a change. And yes, the MKL are good. So much so that Microsoft is twisting the language in advertising their Microsoft R that it "needs to be recompiled for MKL". Nope. BLAS interface. They still add MKL plus some out of memory extensions, but the MKL can be had without them too.

wds15 · 2017-01-31T14:49:07Z

Hmm.. Hadley has no clue on this.

Anyway. Thanks much.

eddelbuettel changed the title ~~Issue with Rcpp and Intel compiler triggered by haven~~ Issue with Rcpp and Intel compiler exposed by building haven Jan 31, 2017

eddelbuettel mentioned this issue Jan 31, 2017

Allow intel icc compilation of algorithm.h (closes 640) #643

Merged

eddelbuettel closed this as completed in d38a304 Feb 4, 2017

hadley mentioned this issue Jul 7, 2017

Failure to install package "haven" tidyverse/haven#280

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Issue with Rcpp and Intel compiler exposed by building haven #640

Issue with Rcpp and Intel compiler exposed by building haven #640

wds15 commented Jan 30, 2017

eddelbuettel commented Jan 30, 2017 •

edited

Loading

wds15 commented Jan 30, 2017

eddelbuettel commented Jan 30, 2017

kevinushey commented Jan 30, 2017 •

edited

Loading

eddelbuettel commented Jan 30, 2017 •

edited

Loading

dcdillon commented Jan 30, 2017

kevinushey commented Jan 30, 2017

eddelbuettel commented Jan 30, 2017

wds15 commented Jan 31, 2017

eddelbuettel commented Jan 31, 2017 •

edited

Loading

wds15 commented Jan 31, 2017

eddelbuettel commented Jan 31, 2017

wds15 commented Jan 31, 2017

eddelbuettel commented Jan 31, 2017

wds15 commented Jan 31, 2017

eddelbuettel commented Jan 31, 2017

wds15 commented Jan 31, 2017

Issue with Rcpp and Intel compiler exposed by building haven #640

Issue with Rcpp and Intel compiler exposed by building haven #640

Comments

wds15 commented Jan 30, 2017

eddelbuettel commented Jan 30, 2017 • edited Loading

wds15 commented Jan 30, 2017

eddelbuettel commented Jan 30, 2017

kevinushey commented Jan 30, 2017 • edited Loading

eddelbuettel commented Jan 30, 2017 • edited Loading

dcdillon commented Jan 30, 2017

kevinushey commented Jan 30, 2017

eddelbuettel commented Jan 30, 2017

wds15 commented Jan 31, 2017

eddelbuettel commented Jan 31, 2017 • edited Loading

wds15 commented Jan 31, 2017

eddelbuettel commented Jan 31, 2017

wds15 commented Jan 31, 2017

eddelbuettel commented Jan 31, 2017

wds15 commented Jan 31, 2017

eddelbuettel commented Jan 31, 2017

wds15 commented Jan 31, 2017

eddelbuettel commented Jan 30, 2017 •

edited

Loading

kevinushey commented Jan 30, 2017 •

edited

Loading

eddelbuettel commented Jan 30, 2017 •

edited

Loading

eddelbuettel commented Jan 31, 2017 •

edited

Loading