Re: [Rd] R 4.0.1-4.0.2 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7
> On Jun 25, 2020, at 10:31 AM, Bjørn-Helge Mevik wrote:
>
> Signed PGP part
> Ryan Novosielski writes:
>
>> Hi there,
>>
>> I initially asked about this on r-help and was told this might be a better
>> venue. I’m not really convinced from reading the posting guide, but I’ll
>> give it a shot. It was also suggested that the R-Project doesn’t really care
>> about building with “non-standard” compilers, but I can’t find any evidence
>> of that on the website (indeed, there’s some mention of successful past
>> builds, and the build itself is successful).
>>
>> I built R 4.0.2 with the Intel Parallel Studio XE compiler suite, versions
>> 19.0.x to 19.1.1. Build seems to go fine. I built it like this:
>>
>> module purge
>> module load intel/19.1.1
>> module list
>>
>> export CC=icc
>> export CXX=icpc
>> export F77=ifort
>> export FC=ifort
>> export AR=xiar
>> export LD=xild
>>
>> export CFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
>> export F77FLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
>> export FFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
>> export CXXFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
>> export MKL="-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread"
>>
>> VERSION=4.0.1
>>
>> /scratch/novosirj/install-files/R-${VERSION}/configure --with-blas="$MKL"
>> --with-lapack --prefix=/opt/sw/packages/intel-19_1/R-Project/${VERSION} && \
>> make -j32 && make check && make -j32 install
>
> For what it is worth, we used to build R with the Intel compilers and
> MKL on our HPC cluster (on CentOS Linux), and we used the following
> setup. Note the comments about -fp-model precise and -ipo. It might no
> longer be a problem, but maybe worth checking.
>
> fast="-ip -O3 -qopt-mem-layout-trans=3 -xHost -mavx"
> ## Notes:
> ## -static and -ipo break compilation
> ## -no-prec-div breaks make check
> ## -fp-model precise is needed for make check
> ## -wd188 removes a lot of warnings (see R Inst. & Adm. manual)
> export CC="icc"
> export CFLAGS="$fast -wd188 -fp-model precise"
> export F77="ifort"
> export FFLAGS="$fast -fp-model precise"
> export CXX="icpc"
> export CXXFLAGS="$fast -fp-model precise"
> export FC="ifort"
> export FCFLAGS="$fast -fp-model precise"
>
> ## This works with intel 2011.10, at least:
> BLAS=--with-blas='-mkl=parallel'
> LAPACK=--with-lapack
>
> ## To make the linker find libraries in modules:
> export LDFLAGS=$(echo $LD_LIBRARY_PATH | sed 's/^/-L/; s/:/ -L/g')
>
> ./configure "$BLAS" "$LAPACK" --enable-BLAS-shlib --enable-R-shlib
> make -j 8
> make check
> make install
Thanks, Bjørn; -ipo no longer breaks compilation (I didn’t specify it, but I
see that it was getting added automatically). I was really hoping that
"-fp-model precise” (which also implies -prec-div which would seem to affect
the other option mentioned) would have an impact on “make check” here, but
apparently not. Also -wd188 is no longer required to hide warnings; this
doesn’t seem to be happening anymore (but remember it myself from earlier on).
I guess it might make sense to check with Intel; we have support. I wish I
could remember if this ever worked right, but I don’t think I thought/knew to
run "make check" on our older builds.
--
|| \\UTGERS, |---*O*---
||_// the State | Ryan Novosielski - novos...@rutgers.edu
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
|| \\of NJ | Office of Advanced Research Computing - MSB C630, Newark
`'
signature.asc
Description: Message signed with OpenPGP
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.1-4.0.2 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7
> On Jun 25, 2020, at 8:06 AM, Ivan Krylov wrote:
>
> On Wed, 24 Jun 2020 18:56:06 +
> Ryan Novosielski wrote:
>
> On my machine, getOption('expressions') is 5000 and the example from
> the test correctly stops with length(traceback()) == 2500. (And the
> simpler example of f <- function() f(); f() stops with
> length(traceback()) == 5000).
>
>> Traceback:
>
> <...>
>
>> 2718: foo()
>
> This (traceback() being more than 2500 entries long) seems to imply
> that the stack size check is somehow skipped. (Perhaps optimized away?)
> The evaluation depth limit is checked in src/main/eval.c, line 705 [*],
> followed by stack size check. Can you attach the debugger and take a
> look at the values of R_EvalDepth and R_Expressions while executing the
> text? What about R_CStackStart and R_CStackLimit? What is the stack
> size limit (ulimit -s?) on the machine running this test?
I can do that. I figure you may have more experience debugging R than I have,
but I know the R command is a script, and that running the R binary directly
doesn’t result in a working run. So what I’ve tried is to do “gdb /bin/bash”
and then running R from that shell. Is that best/are there guidelines? I’m not
much of an expert in this area. Is there also any special way I need to compile
R to have the appropriate symbols?
The shell I’m running in had 8192 for stack size:
[novosirj@amarel-test1 R-4.0.2-intel-19.1-build]$ ulimit -s
8192
Thanks for your help!
--
|| \\UTGERS, |---*O*---
||_// the State | Ryan Novosielski - novos...@rutgers.edu
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
|| \\of NJ | Office of Advanced Research Computing - MSB C630, Newark
`'
signature.asc
Description: Message signed with OpenPGP
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Change in lapply's missing argument passing
Consider the following expression, in which we pass 'i=', with no value
given for the 'i' argument, to lapply.
lapply("x", function(i, j) c(i=missing(i),j=missing(j), i=)
>From R-2.14.0 (2011-10-31) through R-3.4.4 (2018-03-15) this evaluated to
c(i=TRUE, j=FALSE). From R-3.5.0 (2018-04-23) through R-4.0.0 (2020-04-24)
this evaluated to c(i=FALSE, j=TRUE).
Was this change intentional?
Bill Dunlap
TIBCO Software
wdunlap tibco.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error in substring: invalid multibyte string
Hi all,
I'm getting the following error from substring:
> substr("Jens Oehlschl\xe4gel-Akiyoshi", 1, 100)
Error in substr("Jens Oehlschl\xe4gel-Akiyoshi", 1, 100) :
invalid multibyte string at 'gel-A<6b>iyoshi'
Is that normal / intended? I've tried setting the Encoding/locale to
Latin-1/UTF-8 but that does not help. nchar gives me something similar
> nchar("Jens Oehlschl\xe4gel-Akiyoshi")
Error in nchar("Jens Oehlschl\xe4gel-Akiyoshi") :
invalid multibyte string, element 1
I find it strange that substr/nchar give an error but regexpr works for
telling me the length:
> regexpr(".*", "Jens Oehlschl\xe4gel-Akiyoshi")
[1] 1
attr(,"match.length")
[1] 29
Is that inconsistency normal/intended?
btw this example comes from our very own list:
> readLines("
https://stat.ethz.ch/pipermail/r-devel/1999-November/author.html";)[28]
[1] "Jens Oehlschl\xe4gel-Akiyoshi"
Best,
Toby
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-devel internal errors during check produce?
Hi R developers, On R-devel (2020-06-24 r78746) I am getting those two new exceptions during R check. I found a change which eventually may be related https://github.com/wch/r-source/commit/69de92b9fb1b7f2a7c8d1394b8d56050881a5465 I think this may be a regression. I grep'ed package manuals and R code for unique.default but don't see any. Usage section of the unique method looks fine as well. Errors look a little bit like internal errors. * checking Rd \usage sections ... NOTE Error in unique.default(env_list) : LENGTH or similar applied to environment object Calls: ... .get_S3_generics_as_seen_from_package -> unique -> unique.default Execution halted The \usage entries for S3 methods should use the \method markup and not their full name. * checking S3 generic/method consistency ... WARNING Error in unique.default(env_list) : LENGTH or similar applied to environment object Calls: ... .get_S3_generics_as_seen_from_package -> unique -> unique.default I don't think if it is related but I build R-devel with extra args: --with-recommended-packages --enable-strict-barrier --disable-long-double I check with: --as-cran --no-manual To reproduce download current data.table from CRAN (1.12.8) and run R check Best regards, Jan Gorecki __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel internal errors during check produce?
So the unique.default is from the R tools package during checks. I don't see those issues on CRAN checks. Exact environment where I am reproducing this issue is a fresh ubuntu, no R packages pre-installed docker pull registry.gitlab.com/jangorecki/dockerfiles/r-devel https://gitlab.com/jangorecki/dockerfiles/-/raw/master/r-devel/Dockerfile On Sat, Jun 27, 2020 at 12:37 AM Jan Gorecki wrote: > > Hi R developers, > > On R-devel (2020-06-24 r78746) I am getting those two new exceptions > during R check. I found a change which eventually may be related > https://github.com/wch/r-source/commit/69de92b9fb1b7f2a7c8d1394b8d56050881a5465 > I think this may be a regression. I grep'ed package manuals and R code > for unique.default but don't see any. Usage section of the unique > method looks fine as well. Errors look a little bit like internal > errors. > > * checking Rd \usage sections ... NOTE > Error in unique.default(env_list) : >LENGTH or similar applied to environment object > Calls: ... .get_S3_generics_as_seen_from_package -> > unique -> unique.default > Execution halted > The \usage entries for S3 methods should use the \method markup and not > their full name. > * checking S3 generic/method consistency ... WARNING > Error in unique.default(env_list) : >LENGTH or similar applied to environment object > Calls: ... .get_S3_generics_as_seen_from_package -> > unique -> unique.default > > I don't think if it is related but I build R-devel with extra args: > --with-recommended-packages --enable-strict-barrier --disable-long-double > I check with: > --as-cran --no-manual > To reproduce download current data.table from CRAN (1.12.8) and run R check > > Best regards, > Jan Gorecki __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
