Wilco Dijkstra schrieb:
GCC currently defaults to -fcommon. As discussed in the PR, this is an ancient
C feature which is not conforming with the latest C standards. On many targets
this means global variable accesses have a codesize and performance penalty.
This applies to C code only, C++ code is not affected by -fcommon. It is about
time to change the default.
OK for commit?
IIRC using -fno-common might lead to some testsuit fallout because
some optimizations / test cases are sensitive to -f[no-]common.
So I wonder that no adjustments to test cases are needed?
ChangeLog
2019-10-25 Wilco Dijkstra <wdijk...@arm.com>
PR85678
* common.opt (fcommon): Change init to 1.
doc/
* invoke.texi (-fcommon): Update documentation.
---
diff --git a/gcc/common.opt b/gcc/common.opt
index
0195b0cb85a06dd043fd0412b42dfffddfa2495b..b0840f41a5e480f4428bd62724b0dc3d54c68c0b
100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1131,7 +1131,7 @@ Common Report Var(flag_combine_stack_adjustments)
Optimization
Looks for opportunities to reduce stack adjustments and stack references.
fcommon
-Common Report Var(flag_no_common,0)
+Common Report Var(flag_no_common,0) Init(1)
Put uninitialized globals in the common section.
fcompare-debug
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index
857d9692729e503657d0d0f44f1f6252ec90d49a..5b4ff66015f5f94a5bd89e4dc3d2d53553cc091e
100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -568,7 +568,7 @@ Objective-C and Objective-C++ Dialects}.
-fnon-call-exceptions -fdelete-dead-exceptions -funwind-tables @gol
-fasynchronous-unwind-tables @gol
-fno-gnu-unique @gol
--finhibit-size-directive -fno-common -fno-ident @gol
+-finhibit-size-directive -fcommon -fno-ident @gol
-fpcc-struct-return -fpic -fPIC -fpie -fPIE -fno-plt @gol
-fno-jump-tables @gol
-frecord-gcc-switches @gol
@@ -14050,35 +14050,27 @@ useful for building programs to run under WINE@.
code that is not binary compatible with code generated without that switch.
Use it to conform to a non-default application binary interface.
-@item -fno-common
-@opindex fno-common
+@item -fcommon
@opindex fcommon
+@opindex fno-common
@cindex tentative definitions
-In C code, this option controls the placement of global variables
-defined without an initializer, known as @dfn{tentative definitions}
-in the C standard. Tentative definitions are distinct from declarations
+In C code, this option controls the placement of global variables
+defined without an initializer, known as @dfn{tentative definitions}
+in the C standard. Tentative definitions are distinct from declarations
of a variable with the @code{extern} keyword, which do not allocate storage.
-Unix C compilers have traditionally allocated storage for
-uninitialized global variables in a common block. This allows the
-linker to resolve all tentative definitions of the same variable
+The default is @option{-fno-common}, which specifies that the compiler places
+uninitialized global variables in the BSS section of the object file.
IMO "uninitialized" is confusing because the variables actually
*are* initialized: with zero. It's just that the variables don't have
explicit initializers. Dito for "uninitialized" in the --help message.
Johann
+This inhibits the merging of tentative definitions by the linker so you get a
+multiple-definition error if the same variable is accidentally defined in more
+than one compilation unit.
+
+The @option{-fcommon} places uninitialized global variables in a common block.
+This allows the linker to resolve all tentative definitions of the same
variable
in different compilation units to the same object, or to a non-tentative
-definition.
-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 instead
-place uninitialized global variables in the BSS section of the object file.
-This inhibits the merging of tentative definitions by the linker so
-you get a multiple-definition error if the same
-variable is defined in more than one compilation unit.
-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 that always treat uninitialized
-variable definitions this way.
+definition. This behavior does not conform to ISO C, is inconsistent with C++,
+and on many targets implies a speed and code size penalty on global variable
+references. It is mainly useful to enable legacy code to link without errors.
@item -fno-ident
@opindex fno-ident
