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

[eddelbuettel]

Simple PR adding what #640 ended up with in conclusion

Comments welcome, in particular double-checking whether the else side of the #if should be empty or const. Per #640 empty did not work.

Poking @kevinushey @nathan-russell @dcdillon @jjallaire @thirdwing

[codecov-io]

Codecov Report

Merging #643 into master will not impact coverage.

@@          Coverage Diff           @@
##           master    #643   +/-   ##
======================================
  Coverage    92.5%   92.5%           
======================================
  Files          65      65           
  Lines        3309    3309           
======================================
  Hits         3061    3061           
  Misses        248     248

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d05d9c6...71dca72. Read the comment docs.

[kevinushey]

Looks good to me, given the discussion in #640.

[coatless]

Still providing similar warnings. Just ran this branch on ICC with Intel Compiler 15.0.3/16.0/17.0 on R 3.2.2. Output across versions was:

> devtools::install_github("rcppcore/rcpp", ref="bugfix/issue640", force=TRUE)
Downloading GitHub repo rcppcore/rcpp@bugfix/issue640
from URL https://api.github.com/repos/rcppcore/rcpp/zipball/bugfix/issue640
Installing Rcpp
'/usr/local/R/R-3.2.2/lib64/R/bin/R' --no-site-file --no-environ --no-save  \
  --no-restore CMD INSTALL  \
  '/tmp/RtmpWjmcXR/devtools9e5b4c9d99a5/RcppCore-Rcpp-98ecceb'  \
  --library='/home/balamut2/Rlibs' --install-tests

* installing *source* package 'Rcpp' ...
** libs
icc -I/usr/local/R/R-3.2.2/lib64/R/include -DNDEBUG -I../inst/include/ -I/usr/local/include    -fpic  -g -O2  -c Date.cpp -o Date.o
In file included from ../inst/include/Rcpp.h(86),
                 from Date.cpp(31):
../inst/include/Rcpp/algorithm.h(177): warning #858: type qualifier on return type is meaningless
          static inline RCPP_CONSTEXPR double ZERO() { return 0.0; }
                        ^

[wds15]

Could you run the Intel tests again, but this time enable C++11 with the argument -std=C++11 ? I think you do not have 11 enabled in your tests.

[coatless]

Aye, when I went to build against the Rcpp version I opted for the default settings (e.g. no CXX_STD=CXX11 / PKG_CXXFLAGS=-std=c++11).

Switching over to compiling with C++11 did lead to just one warning that was present before:

Date.cpp(642): warning #437: reference to local variable of enclosing function is not allowed
                      2 * sizeof *sp + 4 * TZ_MAX_TIMES];

[wds15]

Looks much better now. Thanks for rerunning.

[eddelbuettel]

That is sadly not good enough. Rcpp itself is not built using -std=c++11.

While we allow it it client packages (and eg haven may be using), we do not use it ourselves to only require a more basic compiler. g++-4.6.* and g++-4.4.* are still used on ancient RH systems. Now we did not get the warning there yet.

Do we need a third branch in that #define to shut up icc when C++11 is not used?

[wds15]

If you want to shut up Intel in non c++11 mode, then I am afraid that you need another fix for the else branch.

Optimally one can figure out a way which makes Intel and gcc happy; otherwise we need as you say another Intel quirk in there which I can try to find out what ifdef is needed to detect if Intel is used.

[eddelbuettel]

Or we just merge as is, and the pleasure of using icc will include a bunch of warnings.

Not the end of the world.

[wds15]

Fine with me. Maybe I can look at it some time, now that I have a direct way to trigger the warning. After all its a warning, no error; so feel free to proceed.

[eddelbuettel]

I made the change adding a simple test for the intel compiler. Will commit, and a quick review should let this in so that we close this chapter.

[eddelbuettel]

Re-upping poke to @kevinushey @nathan-russell @dcdillon @jjallaire @thirdwing @coatless: All good?
I added two lines to define RCPP_CONSTEXPR as empty in an #eflif when do not have C++11. The overall fallback of constexpr is behind it.

[coatless]

So, forcing it to be blank under the Intel compiler actually triggers an error and kills the compilation.

Seems like to quiet this the value should not be defined in the declaration but in the definition per C++ a member with an in-class initializer must be const.

> devtools::install_github("rcppcore/rcpp", ref="bugfix/issue640", force=TRUE)
Downloading GitHub repo rcppcore/rcpp@bugfix/issue640
from URL https://api.github.com/repos/rcppcore/rcpp/zipball/bugfix/issue640
Installing Rcpp
'/usr/local/R/R-3.2.2/lib64/R/bin/R' --no-site-file --no-environ --no-save  \
  --no-restore CMD INSTALL  \
  '/tmp/RtmpHtWzLF/devtools1c585c634b8c/RcppCore-Rcpp-f17ee6a'  \
  --library='/home/balamut2/Rlibs' --install-tests

* installing *source* package 'Rcpp' ...
** libs
icc -I/usr/local/R/R-3.2.2/lib64/R/include -DNDEBUG -I../inst/include/ -I/usr/local/include    -fpic  -g -O2  -c Date.cpp -o Date.o
In file included from ../inst/include/Rcpp.h(86),
                 from Date.cpp(31):
../inst/include/Rcpp/algorithm.h(177): error: a member with an in-class initializer must be const
          static RCPP_CONSTEXPR int RTYPE = REALSXP;

[eddelbuettel]

Thanks so much for testing, @coatless. The current state is clearly worse.

I think your SO makes it clear that @kevinushey was (as usual) right: we need to differentiate between use of const and constexpr in returns and other cases. @dcdillon, any chance you would like to tackle this?

I think for now I am going to revert my last commit, and the merge as it was. It will build everywhere, but be noisy under icc when C++11 is not on (which folks could always turn locally I presume).