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