index() broken in ifort 8.0

[Matt_Thompson]

This is based on a message sent to the Computation Chemistry list by Prof. Christoph van Wullen (the Dec. 16 posts aren't archived at ccl.net yet). Namely, it seems like the index() intrinsic function is broken. Here is some sample code:

program test
   implicit none
   character(len=48), dimension(2) :: str
   integer :: i

   str(1)=" 1.  this is some junk"
   str(2)=" 2.  here is the target"

   do i=1,2
      write (6,*) index(str(i), ' the')
   end do
end program test

ifort returns 61 and 13. The latter is ok, but the former is obviously wrong. By comparison, this code on DEC/Compaq/HP Fortran gives 0 and 13 which seems correct.

Is there a solution to this? Much of the code I have uses index().

[TimP]

Here's a workaround, tested only on your example:

// copied from libf2c, f77 subset implementation for ifort
int
for_index (char *a, int la, char *b, int lb, char *junk)
{
int i, n;
char *s, *t, *bend;

n = la - lb + 1;
bend = b + lb;

for (i = 0; i < n; ++i)
{
s = a + i;
t = b;
while (t < bend)
if (*s++ != *t++)
goto no;
return (i + 1);
no:;
}
return (0);
}
// entry point if called using "external index"
int
index_(char *a, char *b, int la, int lb){
return for_index (a,la,b,lb,(void *)0);}

[TimP]

Has anyone been able to post and get an issue number on this on premier.intel.com

?

That public code is ugly, isn't it?

// copied from libf2c, f77 subset implementation for ifort
#include
int
for_index (char *a, int la, char *b, int lb, char *junk)
{
int i, n;

n = la - lb + 1;

for (i = 0; i < n; ++i)
if(strncmp(a+i,b,lb)==0)
return (i + 1);
return (0);
}

[TimP]

Well, my C is a bit rusty. Looks like memcmp() is more appropriate than strncmp(). I'm still trying to submit an Intel premier support issue to find out whether this is getting attention.

[Steven_L_Intel1]

A report was recently filed. I suspect the use of an array element is a key.

[Matt_Thompson]

Mr. Lionel, something new for you to ponder. On my computer I recently tried matching 'the' compared to ' the' (space v. no space). You can guess what happens, 'the' works (giving 0 and 14), while ' the' gives 61 and 13. Don't know why, but maybe this can help you track down the bug.

[Steven_L_Intel1]

I did some experimenting and found that the problem occurs when the string you're searching is an array element, but not when it's a scalar. It is not respecting the length of the array element and is continuing to search the following bytes. If you use a scalar instead, it works.

I am puzzled by one thing, though. You say you get 61 and 13. I get 60 and 12, which is what I would expect. (The 60 is wrong, but it's consistent.) Do you have an extra character in your actual sample that doesn't show in the post here?

What is the Premier Support report number for the report you filed?

Steve

[Steven_L_Intel1]

Idid some experimenting and found that the problem occurs when the string you're searching is an array element, but not when it's a scalar. It is not respecting the length of the array element and is continuing to search the following bytes. If you use a scalar instead, it works.

I am puzzled by one thing, though. You say you get 61 and 13 for the original example. I get 60 and 12, which is what I would expect. (The 60 is wrong, but it's consistent.) Do you have an extra character in your actual sample that doesn't show in the post here? I would expect 13 if you searched for 'the'.

What is the Premier Support report number for the report you filed?

[Matt_Thompson]

I got word from the person who manages our Intel compilers that he filed a report under issue number 220917. I don't have access to the Premier Support part of the site, so I can't see it.

As for the 13 v. 14, I'm guessing there is a space issue. I see the program as:

str(2)=" 2.  here is the target"
        12345678901234567890123

This would seem to indicate that the first "_" in "_the" (where I use underscores to show [space] characters) should be 13, unless index() starts at 0?

[Steven_L_Intel1]

Hmm - I think one of the blanks got lost during a copy-paste...

Steve

[Steven_L_Intel1]

Hmm - looks like one of the spaces got dropped during the copy-paste. Strange.

[TimP]

I just got a reply fromShanghaithat a fix has been checked in for this problem in the Windows compiler library. In case anyone is interested, the same replacement index()function source code works with the Windows and linux compilers, with no change in decoration, with gcc, Microsoft SDK, or Intel C compilers. The Intel compiler generated code is much better tuned for Intel CPUs. Writing index() as a Fortran module function also works, but gives less performance, as the string comparison is not expanded in line.