From ripley at stats.ox.ac.uk  Wed Nov 23 19:54:12 2005
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Wed, 23 Nov 2005 18:54:12 +0000 (GMT)
Subject: [Rd] [PATCH] Add fpicflags for Intel(R) Fortran Compiler
	(PR#8344)
In-Reply-To: <Pine.LNX.4.61.0511231228060.1246@gannet.stats>
References: <20051122145025.4837FCA08@slim.kubism.ku.dk>
	<Pine.LNX.4.61.0511221611180.28852@gannet.stats>
	<43835DB4.5080204@gentoo.org>
	<Pine.LNX.4.61.0511231228060.1246@gannet.stats>
Message-ID: <Pine.LNX.4.61.0511231712140.13601@gannet.stats>

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 <kugelfang at gentoo.org>
>> 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,                  ripley at stats.ox.ac.uk
> 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,                  ripley at stats.ox.ac.uk
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



[Rd] [PATCH] Add fpicflags for Intel(R) Fortran Compiler (PR#8344)
Prof Brian Ripley