Re: Autoconf tests, libtool symlist files, undefined behavior, and LTO

[Ralf Wildenhues]

* Richard Guenther wrote on Wed, Mar 31, 2010 at 11:02:39AM CEST:
> On Tue, Mar 30, 2010 at 8:52 PM, Ralf Wildenhues wrote:
> > 1) Autoconf-generated configure tests often fake the prototype of some
> > function; e.g., AC_CHECK_FUNC([func]) uses
> >  char func();
> >
> > and tries to link that.  Using this is undefined according to C99, if
> > func has a different actual prototype, and when all system libraries are
> > LTO'ed, gcc -flto may even detect this kind of inconsistency and could
> > act accordingly (nasal demons and such).
> 
> I suppose autoconf cannot do this for C++ functions then, because
> of mangling issues?

Correct.  For C++ libraries, it is more typical to just write a complete
test source and AC_COMPILE_IFELSE or AC_LINK_IFELSE it.

FWIW, there is an Autoconf patch pending to allow AC_CHECK_DECL with
declarations given by the user (in order to support overloaded
basename, for example).

> Note that the only thing GCC with LTO might do here is to issue
> a diagnostic (which of course might confuse the configure script),
> but we cannot really reject such programs (as such errors are
> unfortunately very common) and thus defer any problems to
> link- and/or runtime.

That's almost exactly the kind of semantics I would like to see.
Can we get this documented in the manual?  Something like this.
Note that it would explicitly contradict one of the design goals
listed in lto.pdf, which is that conflicting declarations might
provoke an error; so really GCC developers should make a conscious
design decision here.


        * doc/invoke.texi (Optimize Options): Document that LTO
        won't remove object access purely due to incompatible
        declarations.

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2226cad..85f9c5f 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -7294,6 +7294,12 @@ regular (non-LTO) compilation.  This means that if your 
build process
 was mixing languages before, all you need to add is @option{-flto} to
 all the compile and link commands.
 
+If LTO encounters objects with C linkage declared with incompatible
+types in separate translation units to be linked together (undefined
+behavior according to ISO C99 6.2.7), it might produce a warning, but
+this fact alone will not cause an access to an object to be optimized
+away.
+
 If object files containing GIMPLE bytecode are stored in a library
 archive, say @file{libfoo.a}, it is possible to extract and use them
 in an LTO link if you are using @command{gold} as the linker (which,


(In practice, Autoconf does not support -Werror at configure time; this
issue only reinforces that.)

> > b) The symbols 'func' and 'variable' likely have the wrong prototypes,
> > i.e., elsewhere, they might be declared as
> >
> >  void func(int, double);
> >  double variable[42];
> >
> > instead.  I haven't come across any actual issues with this yet, except
> > now LTO may rightfully complain about it.
> 
> Same issue as above.  We try to handle it - there might be bugs
> in the current implementation of LTO though.

Bugs are no problem as long as they are acknowledged as such.  I desire
future compatibility, i.e., being fairly certain autotools don't regress
just because of a good improvement in some other tool.  Dealing with
existing cruft is abundant in autotools.

> > Question is, what can we do about this?  We could ensure to never pass
> > -flto or -fwhopr to the compilation of the libtool symfile object, and
> > remove it from some or all link tests done in configure.  That's ugly.
> > Would that even be sufficient though?  Conversely, would GCC developers
> > be willing to agree that, when GCC detects such inconsistencies, it
> > wouldn't take adverse advantage of it (e.g., by turning off LTO in this
> > case, or similar)?
> >
> > Other possibilities for Autoconf would be to work toward a new set of
> > checking macros (or extensions of current one) where the configure.ac
> > author passes a full prototype for each function to check (Autoconf
> > could keep a list of known prototypes for often-checked functions).
> > I'm not sure how to fix the libtool symfile in a C99-conforming way.
> 
> I'd say wait and see.  What would be nice to have is a few testcases
> that cover the autoconf cases in the GCC testsuite (feel free to
> just file them into bugzilla).

I have been doing just that for the failures I've found so far.  I'll
add some more for stuff that ought to work.

> We really do not want to break
> working setups with LTO - any fancy ODR violation diagnostics
> should IMHO be optional, only things that LTO does not get
> correct are currently diagnosed IIRC.

That's a good sentiment.  autotools shouldn't stand on slippery
slope more than it has to.

Thanks,
Ralf