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

Prof Brian Ripley ripley at stats.ox.ac.uk
Wed Nov 23 15:30:50 CET 2005


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



More information about the R-devel mailing list