RE: Question about autoconfig configure tests and interprocedural optimization

[Cox, Robert]

Dear Eric,

Thanks for the quick response!

>> Was this a typo for mkstemp?

It's actually a typo for mkstemps. I'm attaching full generated conftest
(rconftest.c)

> 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?

We have version 2.59 installed on our system.  I'm assuming that's the
one which was used
to generate this.  I can look around and see if we have later versions
installed somewhere else.

The configure snippet looks like:

/* The GNU C library defines this for functions which it implements
    to always fail with ENOSYS.  Some functions are actually named
    something starting with __ and the normal name is an alias.  */
#if defined (__stub_$ac_func) || defined (__stub___$ac_func)
choke me
#else
char (*f) () = $ac_func;
#endif
#ifdef __cplusplus
}
#endif

int
main ()
{
return f != $ac_func;
  ;
  return 0;
}

It was derived from the aclocal.m4, which I have attached. Looks like
the function (is that what they are called in m4?) that is used to
generate this is called AC_LANG_FUNC_LINK_TRY.

>> configuring with one set of flags and compiling with another tends to
cause problems.

Apparently, so does the opposite! :-) Anyway, it would be nice to have
the choice, even if it isn't the default.

>> "(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.

Sorry, that was another typo.  The test program I really meant to
suggest was:

int
main ()
{
return (void*)(-1) != (void*) mkstemps;
  ;
  return 0;
}

I've attached a full text version rconftest1.c. It compiles and works on
at least with the Intel and gcc compilers.

>> 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.

This looks what I need to try.  Many thanks to the pointer to this!

                                        -- Robert 

-----Original Message-----
From: Eric Blake [mailto:address@hidden 
Sent: Saturday, September 29, 2007 5:42 AM
To: Cox, Robert
Cc: address@hidden
Subject: Re: Question about autoconfig configure tests and
interprocedural optimization

-----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-----

rconftest.c
Description: rconftest.c

aclocal.m4
Description: aclocal.m4

rconftest1.c
Description: rconftest1.c