Re: Question about autoconfig configure tests and interprocedural optimization

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Cox, Robert on 9/28/2007 5:38 PM:
> Hello list members,

Hello, Robert,

> existence of mkstemps() on our system looks like:
> 
> // Lots of headers and includes
> 
> char (*f) () = mktemps; 

Was this a typo for mkstemp?

> 
> int 
> main()
> {
>   return f != mktemps; 
>   ;
>  return 0; 
> } 

Which version of autoconf generated this?  I'm not finding anything that
matches the pattern above in autoconf 2.61; could you paste an actual
configure snippet, or better yet, determine whether we are dealing with
AC_CHECK_FUNC or some other macro?

> 
> The intent of such a test is to fail with an unresolved reference to
> mktemps if mktemps is not available.  This works OK with the Intel
> compiler as long as we do not compile it with -ipo, but when we do, the
> compiler notices that the "f != mktemps" is always false and simplifies
> the program to 
> 
> main()
> {
>   return 0;
> } 

Yes, we were afraid that would happen someday.  It's always a risk that as
compilers get smarter, test programs have to get more creative to force
the compiler to do something to ensure linkage.

> 
> (1)    Is there anyway to specify that these conftests actually get
> compiled with a different optimization level (like  -O0), rather than
> with the flags (CFLAGS, CXXFLAGS, LDFLAGS) that are passed to build the
> application?

Not generally, since changing compiler flags can also change what works
and what doesn't work - in other words, configuring with one set of flags
and compiling with another tends to cause problems.

> 
> (2)    What are  the chances we could get the "f != mktemps" test
> replaced by something like "(void *)(-1) != mktemps" which would not get
> optimized away at -ipo?  (We also considered asking for "0 != mktemps",
> but worried that we might be able to optimize this away as well, if not
> today, at some time in the future.  Does someone have a suggestion for a
> better test?

We need to also test that whatever approach works for intal also works
with gcc, and a few other compilers.  Or maybe even go with both tests.
"(void *)(-1) != mktemps" is invalid if mktemps was declared as a
function, since it compares a void* with a function pointer, so there is
likely a compiler out there that will fail to compile it.

For that matter, this may be relevant, from the ChangeLog:
2005-10-19  Paul Eggert  <address@hidden>
        (AC_LANG_FUNC_LINK_TRY(C)): Call the function rather than simply
        comparing its address.  Intel's interprocedural optimization was
        outsmarting the old heuristic.  Problem reported by
        Mikulas Patocka.

In other words, if you run 'autoreconf -f' on the problem package so that
it picks up a newer autoconf version, this problem should be fixed for you.

> 
> (3)    Is there a known, relatively painless (having to run sed on on
> the resulting config file or come up with literal assignments for the
> test results for every one of the system function tests NOT relatively
> painless) workaround for this issue?  

For this particular problem, retooling broken packages with a newer
autoconf is probably the easiest approach.

> 
> (4)    Can we specify a different compiler for the conftests (like
> Microsoft Visual Studio or GCC) than we do for the application build
> (Intel compiler)?

Even worse - you really want to configure with the SAME compiler
(including options) as you will be compiling with.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG/kgm84KuGfSFAYARAom4AKCR6xvGKbxTP3i2mcuEu7pq1NTTFACgoSGN
OObw0j0+AiJ1tBA6N6zYm9E=
=KZnJ
-----END PGP SIGNATURE-----