Hi, On Mon, 20 Nov 2017, Wilco Dijkstra wrote:
> > Note you have to make sure GFortran still works! So I think the patch > > should be changed to make the default behavior be frontend dependent > > or have a fortran/ adjustment that fixes things up for the fortran > > dialects that need it. > > Fortran doesn't use flag_no_common, so COMMON globals are not affected. > > There is one use in Ada which looks like an optimization for specific targets: > > /* Ada doesn't feature Fortran-like COMMON variables so we shouldn't > try to fiddle with DECL_COMMON. However, on platforms that don't > support global BSS sections, uninitialized global variables would > go in DATA instead, thus increasing the size of the executable. */ > if (!flag_no_common > && TREE_CODE (var_decl) == VAR_DECL > && TREE_PUBLIC (var_decl) > && !have_global_bss_p ()) > DECL_COMMON (var_decl) = 1; > > I don't understand how this works - if there is no bss support in the > linker, wouldn't common variables would still end up in the data > section? bss _sections_ != bss-like segments in the executable. Targets might not have a bss section that could be named in the asm file, or no way to switch to it without disrupting surrounding code, but they might have common symbols, which ultimately might or might not be collected in some bss-like segment. In that case you want to use them instead of symbols in .data. What's your rationale for changing this? In your initial mail you said: "On many targets this means global variable accesses having an unnecessary codesize and performance penalty in C code (the same source generates better code when built as C++)." I have a hard time imaging that, so can you give details? FWIW I've personally always considered using common symbols nicer. Ciao, Michael.
