Re: -fzero-initialized-in-bss again

[Geoff Keating <geoffk at geoffk dot org>]

Eric Botcazou <ebotcazou@act-europe.fr> writes:

> Here's what happens: the change from 'Dynamic' to '10' for Sec_Stack_Ratio 
> causes the comparison that initializes Sec_Stack_Dynamic to become false, 
> hence Sec_Stack_Dynamic is effectively initialized to 0.  Given that the 
> option -fzero-initialized-in-bss is enabled by default, the symbol 
> system__parameters__sec_stack_dynamic is moved from .data to the 
> uninitialized data section.  Now -fcommon is also on by default so the Ada 
> compiler puts uninitialized symbols in the .common section.  We eventually 
> end up with system__parameters__sec_stack_dynamic in the .common section.
> 
> So the local object has system__parameters__sec_stack_dynamic in .common 
> while the runtime has it in .data.  Therefore the linker imports s-parame.o 
> from libgnat.a, thus leading to conflicts for other symbols.

All this is correct behaviour, except for what the Ada compiler does.

The problem appears to be that ada/utils.c unconditionally does this
when building a var_decl:

  DECL_COMMON   (var_decl) = !flag_no_common;

Is the Ada compiler really trying to make all variables, including
ones which are initialised, common?  I don't believe this is
well-supported in the backend, and I'm not even sure what it means.  I
would suggest changing this, possibly by simply deleting this line,
or modifying it based on Ada language semantics.

-- 
- Geoffrey Keating <geoffk@geoffk.org>