search for: cxx98

...CPlusPlus2a = (1 << 9), Currently CLANG emits "DW_LANG_C_plus_plus" which in DWARF suggests ISO C++98, regardless of the -std=... specified in commandline. Also in file "include/clang/Basci/LangStandards.def" CLANG has aliased c++98 and c++03. // C++ modes LANGSTANDARD(cxx98, "c++98", CXX, "ISO C++ 1998 with amendments", LineComment | CPlusPlus | Digraphs) LANGSTANDARD_ALIAS(cxx98, "c++03") So, my query is that since, c++98 and c++03 is mostly same assuming CLANG Frontend. Should we also support DW_LANG_C_plus...

R 3.4 has 'experimental' support for setting CXX_STD to CXX98 / CXX11 / CXX14 / CXX17. However on most platforms, the R configuration seems to leave the CXX1Y and CXX1Z fields blank in "${R_HOME}/etc/Makeconf" (rather than falling back on default CXX). Therefore specifying e.g CXX_STD= CXX14 will fail build with cryptic errors (due to compiling wit...

On 18 March 2017 at 14:21, Jeroen Ooms wrote: | R 3.4 has 'experimental' support for setting CXX_STD to CXX98 / CXX11 | / CXX14 / CXX17. R 3.1.0 introduced CXX11 support. R 3.4.0 will have CXX14 support. So I would only refer to the CXX17 part as experimental. | However on most platforms, the R configuration seems to leave the | CXX1Y and CXX1Z fields blank in "${R_HOME}/etc/Makeconf" (rather...

...t r-project.org> on behalf of Dirk Eddelbuettel <edd at debian.org> Sent: 18 March 2017 15:55 To: Jeroen Ooms Cc: r-devel Subject: Re: [Rd] Experimental CXX_STD problem in R 3.4 On 18 March 2017 at 14:21, Jeroen Ooms wrote: | R 3.4 has 'experimental' support for setting CXX_STD to CXX98 / CXX11 | / CXX14 / CXX17. R 3.1.0 introduced CXX11 support. R 3.4.0 will have CXX14 support. So I would only refer to the CXX17 part as experimental. | However on most platforms, the R configuration seems to leave the | CXX1Y and CXX1Z fields blank in "${R_HOME}/etc/Makeconf" (rather...

...bit) | Running under: Arch Linux Maybe you can share with us how you configure the build of R-devel? I tend to locally build every week or so and I have the following on Ubuntu 16.10: CXX = ccache g++ CXXCPP = $(CXX) -E CXXFLAGS = -ggdb -pipe -Wall -pedantic $(LTO) CXXPICFLAGS = -fpic CXX98 = ccache g++ CXX98FLAGS = -ggdb -pipe -Wall -pedantic CXX98PICFLAGS = -fpic CXX98STD = -std=gnu++98 CXX11 = ccache g++ CXX11FLAGS = -ggdb -pipe -Wall -pedantic CXX11PICFLAGS = -fpic CXX11STD = -std=gnu++11 CXX14 = ccache g++ CXX14FLAGS = -ggdb -pipe -Wall -pedantic CXX14PICFLAGS...

...n on other platforms where available since R 3.6.0: the default toolchain on Windows was defaulting to C++98). DEPRECATED AND DEFUNCT: * Support for specifying C++98 in package installation is deprecated. * Support in R CMD config for F77, FCPIFCPLAGS, CPP, CXXCPP and CXX98 and similar is deprecated. (CPP is found from the system make and may well not be set.) Use $CC -E and $CXX -E instead of CPP and CXXCPP. BUG FIXES: * runmed(x, *) when x contains missing values now works consistently for both algorithm="Stuetzle" and "Tur...

...n on other platforms where available since R 3.6.0: the default toolchain on Windows was defaulting to C++98). DEPRECATED AND DEFUNCT: * Support for specifying C++98 in package installation is deprecated. * Support in R CMD config for F77, FCPIFCPLAGS, CPP, CXXCPP and CXX98 and similar is deprecated. (CPP is found from the system make and may well not be set.) Use $CC -E and $CXX -E instead of CPP and CXXCPP. BUG FIXES: * runmed(x, *) when x contains missing values now works consistently for both algorithm="Stuetzle" and "Tur...

...n on other platforms where available since R 3.6.0: the default toolchain on Windows was defaulting to C++98). DEPRECATED AND DEFUNCT: * Support for specifying C++98 in package installation is deprecated. * Support in R CMD config for F77, FCPIFCPLAGS, CPP, CXXCPP and CXX98 and similar is deprecated. (CPP is found from the system make and may well not be set.) Use $CC -E and $CXX -E instead of CPP and CXXCPP. BUG FIXES: * runmed(x, *) when x contains missing values now works consistently for both algorithm="Stuetzle" and "Tur...

...3.6.0: the > default toolchain on Windows was defaulting to C++98). > > DEPRECATED AND DEFUNCT: > > * Support for specifying C++98 in package installation is > deprecated. > > * Support in R CMD config for F77, FCPIFCPLAGS, CPP, CXXCPP and > CXX98 and similar is deprecated. (CPP is found from the system > make and may well not be set.) > > Use $CC -E and $CXX -E instead of CPP and CXXCPP. > > BUG FIXES: > > * runmed(x, *) when x contains missing values now works > consistently for both algo...

...R 3.6.0: the > default toolchain on Windows was defaulting to C++98). > > DEPRECATED AND DEFUNCT: > > * Support for specifying C++98 in package installation is > deprecated. > > * Support in R CMD config for F77, FCPIFCPLAGS, CPP, CXXCPP and > CXX98 and similar is deprecated. (CPP is found from the system > make and may well not be set.) > > Use $CC -E and $CXX -E instead of CPP and CXXCPP. > > BUG FIXES: > > * runmed(x, *) when x contains missing values now works > consistently for both algorit...

...ftrapv checks to -fcatch-undefined-behavior (unless we're in -fwrapv mode), so we can easily pick up that part of this change. > > IOC also adds: > -fcatch-undefined-ansic-behavior > -fcatch-undefined-c99-behavior > -fcatch-undefined-cxx0x-behavior > -fcatch-undefined-cxx98-behavior > -fcatch-undefined-nonarith-behavior > > I think we should support this kind of configuration through a mechanism similar to warning flags: -fcatch-undefined-behavior=c++11 -fno-catch-undefined-behavior=null-reference, for instance. > > Also, I think we should consider...

...in on Windows was defaulting to C++98). > > > > DEPRECATED AND DEFUNCT: > > > > * Support for specifying C++98 in package installation is > > deprecated. > > > > * Support in R CMD config for F77, FCPIFCPLAGS, CPP, CXXCPP and > > CXX98 and similar is deprecated. (CPP is found from the system > > make and may well not be set.) > > > > Use $CC -E and $CXX -E instead of CPP and CXXCPP. > > > > BUG FIXES: > > > > * runmed(x, *) when x contains missing values now works >...

Hi! Well, my linux distribution has very recent versions of everything, so a working C++11 compiler exists: $ gcc --version | head -n1 gcc (GCC) 6.3.1 20170306 Could wrong ./configure options be at fault here? See: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=r-devel#n40 My sessionInfo(): $ R-devel --slave -e 'sessionInfo()' | head -n3 R Under development (unstable)

...alue of FC, which is set for package compilation. But portable code should not rely on this.) * The deprecated support for specifying C++98 for package installation has been removed. * R CMD config no longer knows about the unused settings F77 and FCPIFCPLAGS, nor CXX98 and similar. * Either PCRE2 or PCRE1 >= 8.32 (Nov 2012) is required: the deprecated provision for 8.20-8.31 has been removed. * Defunct functions mem.limits(), .readRDS(), .saveRDS(),..find.package(), and .path.package() from package base and allGenerics(), getAccess(...

...alue of FC, which is set for package compilation. But portable code should not rely on this.) * The deprecated support for specifying C++98 for package installation has been removed. * R CMD config no longer knows about the unused settings F77 and FCPIFCPLAGS, nor CXX98 and similar. * Either PCRE2 or PCRE1 >= 8.32 (Nov 2012) is required: the deprecated provision for 8.20-8.31 has been removed. * Defunct functions mem.limits(), .readRDS(), .saveRDS(),..find.package(), and .path.package() from package base and allGenerics(), getAccess(...

...alue of FC, which is set for package compilation. But portable code should not rely on this.) * The deprecated support for specifying C++98 for package installation has been removed. * R CMD config no longer knows about the unused settings F77 and FCPIFCPLAGS, nor CXX98 and similar. * Either PCRE2 or PCRE1 >= 8.32 (Nov 2012) is required: the deprecated provision for 8.20-8.31 has been removed. * Defunct functions mem.limits(), .readRDS(), .saveRDS(),..find.package(), and .path.package() from package base and allGenerics(), getAccess(...