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

[Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>]

[ adding gcc-patches@, dropping gcc@ and libtool@; this is
  <http://thread.gmane.org/gmane.comp.gcc.devel/112638/focus=112670> ]

* Richard Guenther wrote on Thu, Apr 01, 2010 at 02:35:00PM CEST:
> On Wed, Mar 31, 2010 at 8:33 PM, Ralf Wildenhues wrote:
> > +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.

> Well, the wording is almost ok, but
> 
> +behavior according to ISO C99 6.2.7), a non-fatal diagnostic may
> be issued.  The behavior is still undefined at runtime.
> 
> would be more precise.  Especially accesses to conflicting
> declarations can end up being optimized away if there's unfortunate
> inlining so that for example with
> 
> t1.c
> float f;
> t2.c
> int f;
> 
>  f[int] = 1.0;
>  f[float] = 1;
> 
> GCC can end up re-ordering the stores to f and thus effectively
> optimize away one or the other.
> 
> With function calls there's no such issue, but argument passing
> might be completely off (obviously).

OK.  That may not be enough for Libtool, but it's enough for Autoconf.
Not sure if your reply already was an approval (I guess as LTO
maintainer you can approve doc patches for this).  So, OK to commit?

Tested 'make info pdf html'.

Thanks,
Ralf

Document LTO behavior with incompatible declarations.

gcc/ChangeLog:
2010-04-04  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* 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 23a0f4a..341d1b7 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -7294,6 +7294,11 @@ 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), a non-fatal diagnostic may be
+issued.  The behavior is still undefined at runtime.
+
 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,