Fortran - IFC 7.1 GenuineIntel check: workaround

Author

IFC 7.1 GenuineIntel check: workaround

Mark Mackey

2004-07-07, 8:58 am

Hi all.

I'm still using ifc 7.1 (8.0 doesn't like my code, or vice versa). The
latest version (Linux ia32 7.1.040) has some useful bugfixes from
previous versions but is crippled on non-Intel processors: the
vectorised math library checks for a GenuineIntel chip and disables
SSE/SSE2 code. As a result, code compiled with -axK will run just the
generic (slow) ia32 code on Athlons, while code compiled with -xK will
segfault.

Intel say that this is a bug inadvertently introduced into the math
libraries, and that they have no plans to fix it.

Luckily, it's easy to work around. The attached Perl script (also
available at http://www.swallowtail.org/intel_check_patch.txt in case
word wraps etc bugger up the code below) patches the affected libirc.a
file. The libimf.so file is also affected by this bug, so if you use
-i_dynamic you'll have to patch that file to: it should be pretty simple
to modify this script to do that.

Note: if you got the previous version of this message before I
cancelled it, use this script instead. I'd attached the wrong copy of
the script to the previous one, and it patches libirc so that SSE fails
on _all_ chips, even Intel ones :).

8<---------------------------------------------------------------------

#!/usr/bin/perl
#
# (C) Copyright M. D Mackey 2004. This program may be freely modified and redistributed.
#
# A short program to patch the 'libirc.a' file from the Intel Fortran Compiler
# version 7.1.040 (build 20040309Z). May work on other builds also, but is not
# guaranteed. The patch removes the check for the string "GenuineIntel" in the
# CPUID flags of the processor, thus making SSE/SSE2 code work on AMD chips that
# support it.
#
# Creates a file 'libirc.a.bak' containing the original contents of libirc.a.
#
# If you want to check for a successful patch, do
#
# objdump -d libirc.a.bak > old
# objdump -d libirc.a > new
#
# and examine the differences between 'old' and 'new'. Three lines
# should have changed in __intel_cpu_indicator_init:
#
# 3d 47 65 6e 75 cmp $0x756e6547,%eax
# ...
# 3d 69 6e 65 49 cmp $0x49656e69,%eax
# ...
# 3d 6e 74 65 6c cmp $0x6c65746e,%eax
#
# (these check for "GenuineIntel"). These lines should all be changed to
# a9 00 00 00 00 test $0x00000000,%eax
#
# Note that the "GenuineIntel" check is still present in
# libimf.so, so if you link with the -i_dynamic flag you'll
# have to patch that file yourself.
#

open(LIBIRC,"libirc.a") or help();
my($libirc)=join('',<LIBIRC> );
close(LIBIRC);

# libirc is small, so let's do things the simple way...
#
my($unp)=unpack('H*',$libirc);
my($count);
$count=($unp=~s/3d47656e75/a900000000/);
die("Failure patching 3d 47 65 6e 75: libirc.a has either already been patched or is the wrong version\n") unless ($count==1);

$count=($unp=~s/3d696e6549/a900000000/);
die("Failure patching 3d 69 6e 65 49: libirc.a has either already been patched or is the wrong version\n") unless ($count==1);

$count=($unp=~s/3d6e74656c/a900000000/);
die("Failure patching 3d 6e 74 65 6c: libirc.a has either already been patched or is the wrong version\n") unless ($count==1);

open(OUTPUT,">libirc.a.tmp") or die;
print OUTPUT pack('H*',$unp);
close(OUTPUT);
if (! -f "libirc.a.bak") {
rename("libirc.a","libirc.a.bak") or die("Couldn't rename libirc.a to libirc.a.bak: $!\n");
}
rename("libirc.a.tmp","libirc.a") or die("Couldn't rename libirc.a.tmp to libirc.a: $!\n");
print STDERR "Patch operation on libirc.a successful\n";
exit(0);

sub help {
print STDERR <<EOUSAGE;

Some versions of the Intel Fortran Compiler produce code which checks whether
the CPU is made by Intel or not, and disables MMX/SSE/SSE2 code if it isn't.
This program patches the compiler libraries to remove this check, so that e.g.
programs compiled with -axW will use SSE2 code on Athlon 64 chips.

To run the patch, simply execute this script in the
/opt/intel/compiler70/ia32/lib directory: the file 'libirc.a' will be patched.
A backup copy of libirc.a will be made first, so if it all goes wrong you won't
lose anthing.

This script was tested against ifc version 7.1.040, build 20040309Z, and may
not work on other versions. It shouldn't break anything, however.

EOUSAGE
exit(1);
}

__END__

8<-----------------------------------------------------------------------

--
Mark Mackey
"The determined Real Programmer can write Fortran programs in any language."
- "Real Programmers don't use Pascal"

Steve Lionel

2004-07-07, 8:57 pm

On 07 Jul 2004 12:30:48 +0100 (BST), Mark Mackey
<markm@chiark.greenend.org.uk> wrote:

>Intel say that this is a bug inadvertently introduced into the math
>libraries, and that they have no plans to fix it.

A clarification. The bug won't be fixed for 7.1. It is already fixed for 8.0.

Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/

Herman D. Knoble

2004-07-07, 8:57 pm

Mark: For the most part, when compilers like Intel's ifort (ifc) are being developed,
bugs are fixed in the latest version. Can you be more specific about the statement
that Version "8.0 doesn't like my code or vice versa". If you send me the code
I'll try running it on my 8.0.046 compiler under Red Hat Linux just to prove whether
or not the code is in fact correct F90/95 syntax.

Skip Knoble

On 07 Jul 2004 12:30:48 +0100 (BST), Mark Mackey <markm@chiark.greenend.org.uk> wrote:

-|I'm still using ifc 7.1 (8.0 doesn't like my code, or vice versa).

Herman D. (Skip) Knoble, Research Associate
(a computing professional for 38 years)
Email: SkipKnobleLESS at SPAMpsu dot edu
Web: http://www.personal.psu.edu/hdk
Penn State Information Technology Services
Academic Services and Emerging Technologies
Graduate Education and Research Services
Penn State University
214C Computer Building
University Park, PA 16802-21013
Phone:+1 814 865-0818 Fax:+1 814 863-7049

Mark Mackey

2004-07-08, 4:03 pm

In article <arsne05am1g3p6c1990pe8nvoeijq0kk97@4ax.com>,
Steve Lionel <Steve.Lionel@intel.com> wrote:
>
>A clarification. The bug won't be fixed for 7.1. It is already fixed for 8.0.

Sorry, yes, I should have made that clear.

--
Mark Mackey http://www.swallowtail.org/
Now halfway though his record immortality attempt:
aleph-1 moments down, aleph-1 to go....

Mark Mackey

2004-07-08, 4:03 pm

In article <nnune0taotavfjfdji3m8nd0f7na1os5tm@4ax.com>,
Herman D. Knoble <SkipKnobleLESS at SPAMpsu dot edu> wrote:
>Mark: For the most part, when compilers like Intel's ifort (ifc) are being developed,
>bugs are fixed in the latest version. Can you be more specific about the statement
>that Version "8.0 doesn't like my code or vice versa". If you send me the code
>I'll try running it on my 8.0.046 compiler under Red Hat Linux just to prove whether
>or not the code is in fact correct F90/95 syntax.

The code I'm maintaining is a legacy set of F77 applications (using IRIX
GL, no less!) totalling 200K lines. It took a fair amount of time to get
it working under ifc in the first place, and even now upgrading from ifc
7.0 build 20021212Z to 7.1 build 20040309Z made me track down and rework
a couple of subroutines which caused the 20040309Z optimiser to
segfault. However, under 20040309Z an intermittent bug causing
unformatted file reads/writes to fail seems to have been fixed, so
barring the Athlon problem I'm happy with it.

I tried compiling it under 8.0 a few months ago on a test subset of the
code, and (a) I had to rewrite several bits to get it to compile, (b)
when I did get it to compile a few sections segfaulted when I ran it,
and (c) the bits that did run were slower than the code 7.1 produced.

We're pretty busy atm, and I just don't have the time needed to massage
200K lines so that they compile under 8.0, and then chase down all of
the compiler-crashes errors and optimised-code-segfaults bugs that will
inevitably result. Maybe later this year, and if I really get time I'll
rewrite the whole thing in nice clean F95 (yeah right).

In the meantime I'm going to stick with the version of 7.1 I have, but I
need it to produce code which will run on Athlons, hence the need for
the patch. I can understand Intel wanting to focus development and
bugfixing efforts on version 8.0, but for my needs I'd rather stick with
7.1 until 8.1 is out, when hopefully it will compile my code first time
:).

--
Mark Mackey
"The determined Real Programmer can write Fortran programs in any language."
- "Real Programmers don't use Pascal"

Daniel Grimwood

2004-07-09, 3:57 am

Herman D. Knoble <SkipKnobleLESS@spampsu.dot.edu> wrote:

> If you send me the code I'll try running it on my 8.0.046 compiler
> under Red Hat Linux just to prove whether or not the code is in fact
> correct F90/95 syntax.

That's a pretty bold claim :). To Intel's credit, it is slowly getting
there.

Regards,
Daniel.

------------------------------------------------------------------------
Dr. Daniel Grimwood Department of Chemistry
Email : reaper@theochem.uwa.edu.au The University of Western Australia
Phone : +61 8 64888563 35 Stirling Highway
Fax : +61 8 64881005 Crawley WA 6009

Sponsored Links