CanisMaior@web.de
2003-Sep-25 11:25 UTC
[Rd] Bugs compiling R-1.7.1 with Intel compilers icc and ifc (PR#4295)
Bugs compiling R-1.7.1 with Intel compilers icc and ifc, on x86-computer (Pentium IV) and linux operating system Hello, as there aren't many reports about that issue, I'll give a little report here. (Hope I don't bother anyone) The best thing about using icc and ifc are the warnings, because it is said that the Intel compilers are stricter and give more precise warnings than gcc. Warnings are good for making better code. used software : * Intel c/c++ Compiler for 32-bit applications, Version 7.1 Build 20030307Z * Intel Fortran Compiler for 32-bit applications, Version 7.1 Build 20030307Z (both with licence FOR NON-COMMERCIAL USE ONLY) * autoconf (GNU Autoconf) 2.57 * GNU Make version 3.79.1 First: It is possible to compile R-1.7.1 with intel compilers ;-) But: There are several bugs. As the Intel compilers are quite reliable, the bugs may be in the R-code :-( *) some commands crashes R, see later. *) the configure script seems to have a bug, even if you make your own configure script with autoconf. Perhaps it's only a typo, perhaps it's an error of autoconf. So you have to do some things manually: 1) run configure : (you have to adjust the paths) env CPICFLAGS=-shared CXXPICFLAGS=-shared FPICFLAGS=-shared SHLIB_LDFLAGS=-shared ./configure CC=icc CFLAGS=-O2 CPPFLAGS=-I/opt/intel/compiler70/ia32/include F77=ifc CXX=icc CXXFLAGS=O2 FFLAGS=-C90 2) delete a wrong path in some Makefiles: -L/usr/local/lib" The quotation mark is the wrong thing. Delete it! You can search all the files containing this erratum recursively by R-1.7.1> grep local/lib\" * R-1.7.1> grep local/lib\" */* R-1.7.1> grep local/lib\" */*/* and so on. On my computer, the incorrect files are: R-1.7.1/Makeconf R-1.7.1/etc/Makeconf R-1.7.1/bin/R R-1.7.1/src/library/ctest/src/Makefile R-1.7.1/src/library/modreg/src/Makefile R-1.7.1/src/library/mva/src/Makefile R-1.7.1/src/library/ts/src/Makefile Note: R-1.7.1/bin/R does not exist at the beginning, so edit all the other files and start with make ---> it will create an bin/R and stops with an error Then do a make clean edit the file bin/R = erase the wrong quotation mark and start the compilation again with You also can start the compilation, quickly change to bin/ and edit the R-script file. make or better: Do a make &> this_is_a_logfile.log & which writes the compiler warnings to a file. Now it should succeed. Note: make check fails. That's a first hint that there are some problems. Don't install that R! You can run R locally by starting bin/R How does it work? *) Many, many things work fine and fast! But some commands make errors or even crashes R, e.g. demo(lm.glm) crashes R, demo(nlm) makes only an error and stops with the statement "nlm(function(x) fdd(x[1], x[2]), c(-1.2, 1), hessian = TRUE)" (compared with an R-1.7.1, build with gcc 3.3.1 on the same machine, no special configure options) I'll give only an extract of the compiler warnings. There are many more warnings, of course. Feel free to contact me, Volkmar Klatt volkmar.klatt AT stud.uni-bayreuth.de or CanisMaior AT web.de -------------------- * Most warnings are harmless and derives from the gcc compiling flag '-mieee-fp', that icc and ifc dont't understand. This flag is hard coded in the configure.ac file, and it seems that one cannot avoid it easily. That's bad, the configure script should be totally independent from any compiler, I think. * Many warnings refer to Fortran code that is obsolescent in Fortran 95 and/or in Fortran 90. Some code (like "ASSIGN") is even deleted in Fortran 95 * More serious things: (even dangerous?): ########################################## Comment 12 at (1592:blas.f) : This statement is obsolescent in Fortran 90 and deleted in Fortran 95 ASSIGN 210 TO IGO ^ Comment 12 at (1603:blas.f) : This statement is obsolescent in Fortran 90 and deleted in Fortran 95 ------------------ connections.c(841): warning #191: type qualifier is meaningless on cast type return gzwrite(fp, (const voidp)ptr, size*nitems)/size; ^ connections.c(1027): warning #191: type qualifier is meaningless on cast type BZ2_bzWrite(&bzerror, bfp, (const voidp)ptr, size*nitems); ------------------ dotcode.c(251): warning #175: subscript out of range buf[256] = '\0'; ^ ------------------ errors.c(602): warning #188: enumerated type mixed with another type { ERROR_NUMARGS, "invalid number of arguments" }, ^ errors.c(603): warning #188: enumerated type mixed with another type { ERROR_ARGTYPE, "invalid argument type" }, ^ errors.c(605): warning #188: enumerated type mixed with another type { ERROR_TSVEC_MISMATCH, "time-series/vector length mismatch" }, ^ errors.c(606): warning #188: enumerated type mixed with another type { ERROR_INCOMPAT_ARGS, "incompatible arguments" }, ^ errors.c(608): warning #188: enumerated type mixed with another type { ERROR_UNIMPLEMENTED, "unimplemented feature in %s" }, ^ errors.c(609): warning #188: enumerated type mixed with another type { ERROR_UNKNOWN, "unknown error (report this!)" } ^ ------------- graphics.c(5955): warning #175: subscript out of range Rf_dpptr(dd)->fin[2] = Rf_dpSavedptr(dd)->fin[2]; ^ graphics.c(5955): warning #175: subscript out of range Rf_dpptr(dd)->fin[2] = Rf_dpSavedptr(dd)->fin[2]; ^ graphics.c(5956): warning #175: subscript out of range Rf_dpptr(dd)->fin[3] = Rf_dpSavedptr(dd)->fin[3]; ^ graphics.c(5956): warning #175: subscript out of range Rf_dpptr(dd)->fin[3] = Rf_dpSavedptr(dd)->fin[3]; ^ graphics.c(6009): warning #175: subscript out of range Rf_dpptr(dd)->pin[2] = Rf_dpSavedptr(dd)->pin[2]; ^ graphics.c(6009): warning #175: subscript out of range Rf_dpptr(dd)->pin[2] = Rf_dpSavedptr(dd)->pin[2]; ^ graphics.c(6010): warning #175: subscript out of range Rf_dpptr(dd)->pin[3] = Rf_dpSavedptr(dd)->pin[3]; ^ graphics.c(6010): warning #175: subscript out of range Rf_dpptr(dd)->pin[3] = Rf_dpSavedptr(dd)->pin[3]; ^ ---------------- main.c(279): warning #175: subscript out of range state.buf[1025] = '\0'; /* stopgap measure if line > 1024 chars */ ^ ---------------- regex.c(5278): warning #589: transfer of control bypasses initialization of: variable "same_str_p" (declared at line 4163) goto restore_best_regs; ^ ----------------- distance.c(123): warning #187: use of "=" where "==" may have been intended /* use Inf = lim x -> oo */ (dev = 1.))) { ^ ------------------ sfm-read.c(555): warning #266: function declared implicitly bswap_flt64 (&data[i]); ^ sfm-read.c(659): warning #266: function declared implicitly bswap_flt64 (&hdr.bias); ^ sfm-read.c(920): warning #266: function declared implicitly bswap_flt64 (&mv[j]); ^ sfm-read.c(1174): warning #266: function declared implicitly bswap_flt64 (&cooked_label[i]->v.f); ^ sfm-read.c(1440): warning #266: function declared implicitly bswap_flt64 (temp); ^ sfm-read.c(1451): warning #266: function declared implicitly bswap_flt64 (temp); ^ sfm-read.c(1540): warning #266: function declared implicitly bswap_flt64 (&src); ^ ------------------- (in foreign:) stataread.c(102): warning #266: function declared implicitly reverse_double(i); ^ ----------------- ______________________________________________________________________________ Die Besten ihrer Klasse! WEB.DE FreeMail (1,7) und WEB.DE Club (1,9) -
Kurt Hornik
2003-Sep-25 11:47 UTC
[Rd] Bugs compiling R-1.7.1 with Intel compilers icc and ifc (PR#4295)
>>>>> CanisMaior writes:> Bugs compiling R-1.7.1 with Intel compilers icc and ifc, > on x86-computer (Pentium IV) and linux operating system> Hello, > as there aren't many reports about that issue, I'll give a little > report here. (Hope I don't bother anyone)> The best thing about using icc and ifc are the warnings, because > it is said that the Intel compilers are stricter and give more > precise warnings than gcc. > Warnings are good for making better code.> used software : > * Intel c/c++ Compiler for 32-bit applications, Version 7.1 Build 20030307Z > * Intel Fortran Compiler for 32-bit applications, Version 7.1 Build 20030307Z > (both with licence FOR NON-COMMERCIAL USE ONLY) > * autoconf (GNU Autoconf) 2.57 > * GNU Make version 3.79.1> First: > It is possible to compile R-1.7.1 with intel compilers ;-)> But: > There are several bugs. As the Intel compilers are quite reliable, > the bugs may be in the R-code :-(> *) some commands crashes R, see later. > *) the configure script seems to have a bug, even if you make your own > configure script with autoconf. > Perhaps it's only a typo, perhaps it's an error of autoconf. > So you have to do some things manually:> 1) > run configure : (you have to adjust the paths) > env CPICFLAGS=-shared CXXPICFLAGS=-shared FPICFLAGS=-shared > SHLIB_LDFLAGS=-shared ./configure CC=icc CFLAGS=-O2 > CPPFLAGS=-I/opt/intel/compiler70/ia32/include F77=ifc CXX=icc > CXXFLAGS=O2 FFLAGS=-C90> 2) delete a wrong path in some Makefiles: > -L/usr/local/lib" > The quotation mark is the wrong thing. Delete it! > You can search all the files containing this erratum recursively byR-1.7.1> grep local/lib\" * R-1.7.1> grep local/lib\" */* R-1.7.1> grep local/lib\" */*/*> and so on.> On my computer, the incorrect files are: > R-1.7.1/Makeconf > R-1.7.1/etc/Makeconf > R-1.7.1/bin/R > R-1.7.1/src/library/ctest/src/Makefile > R-1.7.1/src/library/modreg/src/Makefile > R-1.7.1/src/library/mva/src/Makefile > R-1.7.1/src/library/ts/src/MakefileI find that hard to believe. grep -r -e '-L/usr/local/lib' configure gives : ${LDFLAGS="-L/sw/lib -L/usr/local/lib"} : ${LDFLAGS="-L/usr/local/lib"} and grep -r '@LDFLAGS@' in the top-level source tree gives Makeconf.in:LDFLAGS = @LDFLAGS@ configure:s,@LDFLAGS@,$LDFLAGS,;t t etc/Makeconf.in:LDFLAGS = @LDFLAGS@ so where should the offending double quote come from, and in particular how would it end up in e.g. src/library/ctest/src/Makefile? -k
Saikat DebRoy
2003-Sep-26 15:44 UTC
[Rd] Bugs compiling R-1.7.1 with Intel compilers icc and ifc (PR#4295)
On Thursday, Sep 25, 2003, at 05:26 US/Eastern, CanisMaior@web.de wrote:> Bugs compiling R-1.7.1 with Intel compilers icc and ifc, > on x86-computer (Pentium IV) and linux operating system >Many of those bugs can be fixed by using appropriate configure options. Some of the warnings are serious, but they quite a few of them or fixed yesterday.> Hello, > as there aren't many reports about that issue, I'll give a little > report here. (Hope I don't bother anyone) > > The best thing about using icc and ifc are the warnings, because > it is said that the Intel compilers are stricter and give more > precise warnings than gcc. > Warnings are good for making better code.> used software : > * Intel c/c++ Compiler for 32-bit applications, Version 7.1 Build > 20030307Z > * Intel Fortran Compiler for 32-bit applications, Version 7.1 Build > 20030307Z > (both with licence FOR NON-COMMERCIAL USE ONLY) > * autoconf (GNU Autoconf) 2.57I used all of the above on an Intel Pentium IV running Debian Linux testing distribution. In addition I had GNU make version 3.80> * GNU Make version 3.79.1 > > First: > It is possible to compile R-1.7.1 with intel compilers ;-) > > But: > There are several bugs. As the Intel compilers are quite reliable, > the bugs may be in the R-code :-( > > *) some commands crashes R, see later.This can be fixed with appropriate options to the compiler. See below.> *) the configure script seems to have a bug, even if you make your own > configure script with autoconf. > Perhaps it's only a typo, perhaps it's an error of autoconf. > So you have to do some things manually: >This indeed is a bug in the configure script. I have a fix that works for the intel and the GNU compilers. I have no idea if it breaks anything for other compilers or platforms.> 1) > run configure : (you have to adjust the paths) > env CPICFLAGS=-shared CXXPICFLAGS=-shared FPICFLAGS=-shared > SHLIB_LDFLAGS=-shared ./configure CC=icc CFLAGS=-O2 > CPPFLAGS=-I/opt/intel/compiler70/ia32/include F77=ifc CXX=icc > CXXFLAGS=O2 FFLAGS=-C90 >A better set of configure options is ./configure CC=icc CFLAGS='-O2 -mp' CPPFLAGS=-I/opt/intel/compiler70/ia32/include F77=ifc CXX=icc CXXFLAGS='-O2 -mp' FFLAGS='-C90 -w90 -w95 -mp' CPICFLAGS=-shared CXXPICFLAGS=-shared FPICFLAGS=-shared SHLIB_LDFLAGS=-shared SHLIB_CXXLDFLAGS=-shared The -mp option forces stricter IEEE-754 floating point arithmetic conformance. Any operation involving an NA or NaN crashes R without this option. The icc and ifc also have a less strict -mp1 option which does not work for R. The -w90 and -w95 suppresses warnings about Fortran syntax made obsolete by Fortran 90 or 95.> 2) delete a wrong path in some Makefiles: > -L/usr/local/lib" > The quotation mark is the wrong thing. Delete it! >The problem is in the AC_F77_LIBRARY_LDFLAGS macro. It guesses the linker flags by passing a verbose option (-v for ifc) to the compiler. For ifc this produces a multiline output, one line continued to the next by a \ character. It also contains some " characters. These together produces the wrong results. We can fix this by removing all \ and " from the variable ac_f77_v_output in that macro. I am not sure if this breaks anything in other compilers.> make > or better: Do a > > make &> this_is_a_logfile.log & > > which writes the compiler warnings to a file. > Now it should succeed. >After you do everything I described, the make should succeed. It will still show some warnings. I think most of the warnings for R itself is harmless.> Note: > make check > fails. That's a first hint that there are some problems.Now make check should work.> Don't install that R!I would still be cautious about installing an R compiled with icc/ifc as your default but I think it is useful for the warnings it produces. Thanks, Saikat
Seemingly Similar Threads
- Bugs compiling R-1.7.1 with Intel compilers icc and ifc (PR#4296)
- Bugs compiling R-1.7.1 with Intel compilers icc and ifc (PR#4314)
- [PATCH] Add fpicflags for Intel(R) Fortran Compiler (PR#8344)
- problem compiling R-1.9.0beta with PGI compilers on amd64
- [PATCH V9 9/9] virtio: Intel IFC VF driver for VDPA