invoke.texi (Code Gen Options): Expand discussion of -fno-common.

2009-03-18  Sandra Loosemore  <sandra@codesourcery.com>

	gcc/
	* doc/invoke.texi (Code Gen Options): Expand discussion of
	-fno-common.

From-SVN: r144940

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index a13d05e75882bc7fb1ff28763a9408b6ab2625d3..d941dc1f4e7cb74ba1315730c1202697e2094bb5 100644 (file)
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2009-03-18  Sandra Loosemore  <sandra@codesourcery.com>
+
+       * doc/invoke.texi (Code Gen Options): Expand discussion of
+       -fno-common.
+
 2009-03-18  Jakub Jelinek  <jakub@redhat.com>
 
        * dse.c (struct group_info): Reorder fields for 64-bit hosts.

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 275986c1e6eab7f84c450613a66a5f04ad777b7d..277574ad0c9c6e4badc93a944109327691e7fc38 100644 (file)
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -15709,12 +15709,25 @@ Use it to conform to a non-default application binary interface.
 
 @item -fno-common
 @opindex fno-common
-In C, allocate even uninitialized global variables in the data section of the
-object file, rather than generating them as common blocks.  This has the
-effect that if the same variable is declared (without @code{extern}) in
-two different compilations, you will get an error when you link them.
-The only reason this might be useful is if you wish to verify that the
-program will work on other systems which always work this way.
+In C code, controls the placement of uninitialized global variables.
+Unix C compilers have traditionally permitted multiple definitions of
+such variables in different compilation units by placing the variables
+in a common block.  
+This is the behavior specified by @option{-fcommon}, and is the default 
+for GCC on most targets.  
+On the other hand, this behavior is not required by ISO C, and on some
+targets may carry a speed or code size penalty on variable references.
+The @option{-fno-common} option specifies that the compiler should place 
+uninitialized global variables in the data section of the object file,
+rather than generating them as common blocks.
+This has the effect that if the same variable is declared 
+(without @code{extern}) in two different compilations,
+you will get a multiple-definition error when you link them.
+In this case, you must compile with @option{-fcommon} instead.  
+Compiling with @option{-fno-common} is useful on targets for which 
+it provides better performance, or if you wish to verify that the
+program will work on other systems which always treat uninitialized
+variable declarations this way.
 
 @item -fno-ident
 @opindex fno-ident