icc 2016.1.150 optimization bug

[David_Z_1]

I think I found a bug in intel c compiler.  This is how to reproduce it:

First file (cstuff.c)

#include <stdio.h>
#include <string.h>

#include <netdb.h>
#include <sys/utsname.h>
#include <sys/socket.h>

void uninf(char sy[],long *l)
{
  struct hostent *h ;
  struct utsname inf ;
  char lsy[1000];
  int ll ;

  uname(&inf) ;
  if ( (h = gethostbyname(inf.nodename)) == NULL) {
    printf("gethostbyname>hostname problem: ");
    printf("check /etc/hosts or /etc/resolv.conf\n");
    sprintf(lsy,"%s-%s(%s)", inf.sysname, inf.release, inf.machine);
  } else {
    sprintf(lsy,"%s-%s(%s)@%s", inf.sysname, inf.release, inf.machine,
        h->h_name);
  }
  //ll = strlen(inf.sysname)+strlen(inf.release)+strlen(inf.machine)+strlen(h->h_name)+4;
  printf("%s\n", lsy);
  ll = (int) strlen(lsy) ;
  if (ll > 80) ll = 80;
  *l = ll ;
  //*l = ( *l > 44 ) ? 44 : *l ;
  //ll = *l ;
  strncpy(sy,lsy,ll);
}

Second file: (teststr.c)

#include <stdio.h>
#include <string.h>
void uninf(char sy[], long *l);
int main(int argc, char **argv) {

  char s[120], s2[120];
  long i;
  uninf(s, &i);
  strncpy(s2, s, i);
  s2[i+1] = '\0';
  printf("%s\n", s2);

  return 0;
  
}

Compile both files:

icc -g -O3 -c cstuff.c

icc -g -O3 -c teststr.c

and link them:

icc -g cstuff.o teststr.o -o strtest

The program strtest causes a SEGILL error on certain machines (compiled on Redhat Enterprise Linux server 6.8, kernel version 2.6.32-642.3.2.e16.x86_64; running on Redhat ELS 7.0 Maipo with kernel 3.10.0-123.e17.x86_64)

While it does not cause segfault on all machines, running strtest in gdb:

(gdb) start
Temporary breakpoint 1 at 0x400af8: file teststr.c, line 8.
Starting program: /users/dzhang/tmp/strlenbug/fail.exe 

Temporary breakpoint 1, main (argc=0, argv=0x3) at teststr.c:8
8	  uninf(s, &i);
Missing separate debuginfos, use: debuginfo-install glibc-2.17-55.el7.x86_64 libgcc-4.8.2-16.el7.x86_64
(gdb) s
4	int main(int argc, char **argv) {
(gdb) s
8	  uninf(s, &i);
(gdb) s
uninf (sy=0x7fffffffe300 "\b\342\377\367\377\177", l=0x7fffffffe3f0)
    at cstuff.c:9
9	{
(gdb) s
15	  uname(&inf) ;
(gdb) s
16	  if ( (h = gethostbyname(inf.nodename)) == NULL) {
(gdb) s
21	    sprintf(lsy,"%s-%s(%s)@%s", inf.sysname, inf.release, inf.machine,
(gdb) p sy
$1 = 0x7ffff78c1e20 <resbuf.11716> "\305A`"
(gdb) s
25	  printf("%s\n", lsy);
(gdb) p sy
$2 = 0x0

The address of sy changes to 0x0 at the end.  Compile with gcc -g -O3 or icc -g -O0 does not show this behavior.

[David_Z_1]

Previously we used intel C++ compiler 11.0.074 and we did not see the same crash.

I realize that the memory issue I mentioned in GDB might be due to the fact that these symbols were generated before the optimization.  Nevertheless, the same code does not crash with earlier version the intel compiler.

[jimdempseyatthecove]

What happens when you declare ll as long? (IOW *l = ll; fails to promote)

Alternatively, what happens when you use: l = (long)ll;?

If either/both work then the you have located the compiler bug.

I recall similar bugs several years ago where a promotion was not performed.

Jim Dempsey

[SergeyKostrov · Accepted solution]

>>...The program strtest causes a SEGILL error... Simply to let you know that this is a signal for Illegal Instruction.

[David_Z_1]

Thanks, Jim.  I found out the reason now. See below.

jimdempseyatthecove wrote:

What happens when you declare ll as long? (IOW *l = ll; fails to promote)

Alternatively, what happens when you use: l = (long)ll;?

If either/both work then the you have located the compiler bug.

I recall similar bugs several years ago where a promotion was not performed.

Jim Dempsey

[David_Z_1]

Sergey Kostrov wrote:

>>...The program strtest causes a SEGILL error...

Simply to let you know that this is a signal for Illegal Instruction.

Your comment just helped me to realize what happened.  It turns out that I also have the -xHost option for the CFLAGS.  This caused the illegal instruction for another machine.

[David_Z_1]

Question to Intel engineer:

We have been using the -xHost flag for many years and this is the first time we saw this error.  What has changed between icc 11.0 and 2016.1?  Is this a bug that needs to be fixed?