3.6.2.3: It is implementation-defined whether or not the dynamic initialization (8.5, 9.4, 12.1, 12.6.1) of an object of namespace scope is done before the first statement of main. If the initialization is deferred to some point in time after the first statement of main, it shall occur before the first use of any function or object defined in the same translation unit as the object to be initialized.
Yes, but I think you will find that unless the implementation /does/ perform dynamic initialization before the first statement of main, it will have unsolvable ordering problems. Consider a class A defined in a.cpp, and B defined in b.cpp.
a.cpp: extern B theB; A::A() { .... }
b.cpp: extern A theA; B::B() { .... }
Now then. If something from a.cpp is referenced externally then the compiler must initialize 'theB' before it starts using any of the functions in a.cpp.
I couldn't find anything like this in the standard. However, in general you can't safely assume that theB, theA, or any other global object is initialized (beyond the mandatory zero initialization) because you may be called from a constructor of another global object. Note that as a library writer, this is beyond your control -- the global object that calls you could be in user code.
As far as "deadstripping" code - this has indeed been a big problem - especially in release mode. I've referred to it as overzealous optimization.
It isn't overzealous -- it's within the specifications of the standard, whether you like it or not.
Chapter and verse? (Given the above argument that dynamic initialization must happen first.)
The standard does not deal with deadstripping but to me it's obvious that if A) the compiler is not required to initialize a namespace-scope object until a function from its translation unit is called, and B) no function from that translation unit is called, the obvious conclusion is that the object will never be initialized and therefore can be safely deadstripped.