I was somewhat more successful testing the Intel EM64T compilers (on an
Opteron). The masquerading as gcc means the default for CFLAGS is "-g
-O2" which again is problematic: I had to include -mp in all the compiler
flags to ensure that IEC60059 arithmetic was used.
After all that, the Intel compiler setup was a percent or two slower than
gcc-3.4.4 at -O2.
We now have a reasonable attempt at icc/ifort support "out of the box",
but there was a _lot_ more to it, and we still need to deal with the
dlamc.f issues. (My sysadmin misunderstood and uninstalled ia32
icc/ifort, so this will need to wait until it is put back on a P4 box.)
On Wed, 23 Nov 2005, Prof Brian Ripley wrote:
> I've some playing with the Intel compilers, currently only on ia32. As far
> as I can see Intel provides compilers for only two OSes and on 50% of those
> -fPIC is wrong so I do think this is really Linux-specific.
> I have put in a Linux-specific change to set FPICFLAGS, but that is the least
> of the problems I have found.
>
> The reason there is not a problem with the C compiler is that configure
> reports
>
> checking whether we are using the GNU C compiler... yes
>
> and so configure takes the builtin defaults for gcc. This seems to come from
> the test of
>
> int
> main ()
> {
> #ifndef __GNUC__
> choke me
> #endif
>
> ;
> return 0;
> }
>
> and so it seems that the masquerading by icc is intentional. This has some
> consequences: for example package foreign assumes that GCC accepts
> -Wno-long-long, but icc does not act on it. More seriously, it means that
> the default CFLAGS get set to "-g -O2", which is not what is documented. And
> with those flags, the build fails, incorrectly reporting that a regexp is
> invalid.
>
> There are also problems with optimizing src/modules/dlamc.f under ifort.
>
>
> On Tue, 22 Nov 2005, Danny van Dyk wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Dear Prof. Ripley,
>>
>> Prof Brian Ripley schrieb:
>> | 1) The documented way to specify this is to set FPICFLAGS in
>> | config.site: see the example in R-admin for the PG compilers. When you
>> | tried that, what went wrong?
>> Nothing went wrong. However, I was of the opinion that support of
>> ifc/ifort 'out-of-the-box' is worthwhile. This is why I asked to include
>> it into the source-tree. As a matter of fact, I stumbled upon this when
>> testing Gentoo's R-2.2.0 buildscripts and added a similar patch to our
>> repository.
>>
>> | 2) It seems strange to specify this for the Fortran compiler and not the
>> | C or C++ compiler.
>> I used the combination of 'gcc/g++/ifort' to build and test R. Testing
>> the combination of 'icc/ifort' on Gentoo is scheduled already.
>>
>> | 3) You have suggested the change to a section for all OSes. Do you know
>> | for sure that all compilers called 'ifort' on all OSes need the -fPIC
>> | flag? Or is it really just for Linux (and AFAICS, just x86_64 Linux, as
>> | i386 Linux seems to work with icc/ifort without it).
>> a) For building shared ELF-libraries on x86_64 and ia64, you need to
>> instruct the compiler to build PIC. As a matter of fact, this isn't
>> necessary for x86, but it is strongly recommended as it should improve
>> performance due to the lack of text relocations the dynamic linker would
>> have to perform otherwise. This affects all OSes that can handle ELF
>> binaries (Linux, FreeBSD, Solaris, tbc.).
>>
>> b) I surely can't guarantee that there never will be a different fortran
>> compiler with same name on any OS. However, I think that it is a safe
>> assumption to say that there currently is no such compiler on OSes
>> supported by autotools.
>>
>>
>> The number of target OSes and and supported ISAs makes it - in my eyes -
>> worthwhile to add the check to the 'general' section of the configure.ac
>> script. If - in a rare case - a conflict with other compiler emerged, it
>> would still be possible to work around a problem in the following
>> section of the script: '## Step 3. Individual platform overrides.'.
>> (Emphasis here on 'individual' and 'override')
>>
>> Danny
>> - --
>> Danny van Dyk <[EMAIL PROTECTED]>
>> Gentoo/AMD64 Project, Gentoo Scientific Project
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.1 (GNU/Linux)
>>
>> iD8DBQFDg120aVNL8NrtU6IRAqVFAJ9Nv3FnfUjzGU2q4FEf+3TRek2HTQCfQG4R
>> DD5dVT076/1HBJw5B4N+mck=
>> =eBBz
>> -----END PGP SIGNATURE-----
>>
>>
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UK Fax: +44 1865 272595
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
