Re: AC_LANG_FUNC_LINK_TRY(C): stub detection fails with ICC 10.1

[Aaron Ucko]

Eric Blake <address@hidden> writes:

> According to Aaron Ucko on 12/22/2008 9:45 AM:
>> I have observed that AC_FUNC_LINK_TRY(C), which serves as the guts of
>> AC_CHECK_FUNCS, can inappropriately return "yes" for functions which are
>> merely stubs when building with version 10.1 of Intel's C/C++ compiler
>> (ICC) on x86_64-linux-gnu systems (and perhaps also other versions).
>
> Thanks for the report.  However, we could use some more information, to
> help us better figure out how to resolve this issue.

Sure, I'll be happy to elaborate, particularly given that the problem
appears to be deeper than I initially thought; sorry for being overly
vague initially.  Autoconf generates code that boils down to

#define lutimes innocuous_lutimes

#ifdef __STDC__
#  include <limits.h>
#  ifndef PATH_MAX
#    warning "What, no PATH_MAX?  What is this, the HURD? ;-)"
#  endif
#else
#  include <assert.h>
#endif

#undef lutimes

char lutimes();

#if defined (__stub_lutimes) || defined (__stub___lutimes)
choke me
#else
char (*f) () = lutimes;
#endif

int main()
{
  return f != lutimes;
}

which should fail given that I'm building on a system that still has
glibc 2.3.5, but instead succeeds (albeit with a warning) when building
with ICC 10.1:

$ /opt/intel/cce/10.1.021/bin/icc -o conftest conftest.c; echo $?
conftest.c(6): warning #1224: #warning directive: "What, no PATH_MAX?  What is 
this, the HURD? ;-)"
  #    warning "What, no PATH_MAX?  What is this, the HURD? ;-)"
       ^
/tmp/ucko/pts_5/iccxqEoau.o(.text+0x22): In function `main':
: warning: warning: lutimes is not implemented and will always fail
0

(FTR, replacing all occurrences of lutimes with, say, lchmod should have the
same effect with a wider range of libc versions, but lutimes is the only
potential stub relevant to my actual project at the moment.)

There are various ways to turn the warning into an error:

$ /opt/intel/cce/10.1.021/bin/icc -o conftest -Wl,--fatal-warnings conftest.c; 
echo $?
conftest.c(6): warning #1224: #warning directive: "What, no PATH_MAX?  What is 
this, the HURD? ;-)"
  #    warning "What, no PATH_MAX?  What is this, the HURD? ;-)"
       ^
/tmp/ucko/pts_5/iccbjrNDK.o(.text+0x22): In function `main':
: warning: warning: lutimes is not implemented and will always fail
1

$ /opt/intel/cce/10.1.021/bin/icc -o conftest -D_GCC_NEXT_LIMITS_H conftest.c; 
echo $?
conftest.c(17): error: identifier "choke" is undefined
  choke me
  choke me
  ^

conftest.c(22): error: expected a ";"
  int main()
  ^

conftest.c(25): warning #12: parsing restarts here after previous syntax error

compilation aborted for conftest.c (code 2)
2

$ /opt/intel/cce/10.1.021/bin/icc -o conftest -include gnu/stubs.h conftest.c; 
echo $?
conftest.c(6): warning #1224: #warning directive: "What, no PATH_MAX?  What is 
this, the HURD? ;-)"
  #    warning "What, no PATH_MAX?  What is this, the HURD? ;-)"
       ^
conftest.c(17): error: identifier "choke" is undefined
  choke me
  ^

conftest.c(22): error: expected a ";"
  int main()
  ^

conftest.c(25): warning #12: parsing restarts here after previous syntax error

compilation aborted for conftest.c (code 2)
2

Of those, I now feel that arranging to #define _GCC_NEXT_LIMITS_H if
necessary is the best, because the compiler otherwise fails to pick up
definitions such as PATH_MAX from libc's <limits.h>.  ICC supplies its
own <limits.h> that boils down to

#ifndef __INTEL_LIMITS_H
#define __INTEL_LIMITS_H 1

#define _GCC_LIMITS_H_

#ifndef _LIBC_LIMITS_H_
 #include_next <limits.h>
#endif

/* ... */

#else
#include_next <limits.h>
#endif /* __INTEL_LIMITS_H */

but #include_next <limits.h> picks up not /usr/include/limits.h but
rather GCC's version of <limits.h> because ICC generally piggybacks on
GCC headers, mostly for the sake of libstdc++:

$ /opt/intel/cce/10.1.021/bin/icc -M conftest.cconftest.o: conftest.c 
/opt/intel/cce/10.1.021/include/limits.h \
 /usr/lib64/gcc-4.0.1/gcc/x86_64-unknown-linux-gnu/4.0.1/include/limits.h

GCC's <limits.h> in turn chains to libc's <limits.h> only if
_GCC_NEXT_LIMITS_H is defined, which evidently fails to occur by
default (arguably a compiler bug):

$ /opt/intel/cce/10.1.021/bin/icc -D_GCC_NEXT_LIMITS_H -M conftest.c
conftest.o: conftest.c /opt/intel/cce/10.1.021/include/limits.h \
 /usr/lib64/gcc-4.0.1/gcc/x86_64-unknown-linux-gnu/4.0.1/include/limits.h \
 /usr/include/limits.h /usr/include/features.h /usr/include/sys/cdefs.h \
 /usr/include/gnu/stubs.h /usr/include/bits/posix1_lim.h \
 /usr/include/bits/local_lim.h /usr/include/linux/limits.h \
 /usr/include/bits/posix2_lim.h

I hope that helps to clarify the situation; please let me know if you'd
like any more details, or have any patches you'd like me to test.

Thanks!

-- 
Aaron Ucko <ucko at ncbi>, NCBI C++ Toolkit core development group