Georg-Johann Lay <g...@gcc.gnu.org> wrote:
> 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?
Two points here:
(a) I actually agree with the idea to change the default
(b) there will surely be testsuite fallout on Darwin, where common accesses are
mandated to be indirect in the ABI, where non-weak .data accesses are not
Thus code generated for Darwin will change for any test using variables that
are “common” and where the test does not already force -fno-common
I’d expect fallout to be quite large - since there are plenty of testcases
with uninit
gobals. We might want to make a test-run and see the size of the problem,
but
preferably once the stage#1 submisison and gcc-7 release cycles are done.
thanks
Iain
>> 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
