Document LTO behavior with incompatible declarations.

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

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@157970 138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 4fd4c49..13485d6 100644 (file)
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2010-04-05  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>
+
+       * doc/invoke.texi (Optimize Options): Document that LTO
+       won't remove object access purely due to incompatible
+       declarations.
+
 2010-04-04  Matthias Klose  <doko@ubuntu.com>
 
        * graphite-sese-to-poly.c (translate_scalar_reduction_to_array):

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 23a0f4a..341d1b7 100644 (file)
--- 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,