[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

["mmitchel at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770

Mark Mitchell <mmitchel at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmitchel at gcc dot gnu.org

--- Comment #14 from Mark Mitchell <mmitchel at gcc dot gnu.org> 2010-12-11 18:32:58 UTC ---
H.J. --

Some of the statements that you're making in Comment #11 are inaccurate or
unclear:

Given:

  Foo foo(...);
  Bar bar(...);

within a single module, the C++ standard guarantees that foo is initialized
before bar.  See \S 3.6.2 "Initialization of non-local objects":

"Other objects defined in namespace scope have ordered initialization. Objects
defined within a single translation unit and with ordered initialization shall
be initialized in the order of their definitions in the translation unit."

Now, it is true that if foo or bar is zero-initialized or constant-initialized
(these are terms of art in the C++ standard) that initialization happens before
dynamic initialization, so given:

  Foo foo(...);
  int i = 3;

It is guaranteed that "i" is initialized before "foo".  But, even in that case,
the order is well-defined; it's just not necessarily the order in which the
objects are declared.

Although the C++ standard does not impose requirements on initialization order
across translation units (i.e., source files), there is no doubt that programs
accidentally or intentionally depend upon it.  I'm sure that making changes in
this regard will break something.  But, such breakage is akin to the breakage
that occurs whenever we optimize more aggressively; people depend on current
undocumented behaviors, and programs break when we make a change.  So, I don't
think we should resist making the change to .init_array simply on this ground.

On the other hand, we do have an issue around constructor priorities.  If I
recall correctly, the linker sorts all of the .ctors.NNNNN sections into a
single array which is then executed in order.  So, if the program has some
object files built using .ctors.NNNNN and others using .init_array, I don't see
how we can get the interleaving that is specified in the source code.