Re: Merge constructors and destructors

[Mike Stump <mikestump at comcast dot net>]

On Aug 24, 2010, at 9:40 AM, Richard Henderson wrote:
> On 08/24/2010 02:50 AM, Jan Hubicka wrote:
>>>> +    /* Ensure a stable sort.  Constructors are executed in backwarding
>>>> +       order to make LTO initialize braries first.  */
>>>> +    return DECL_UID (f2) - DECL_UID (f1);
>>> 
>>> I have trouble believing that this is reliable.  If you do this,
>>> put a checking assert that the original vector is monotonically
>>> increasing in DECL_UID.
>> 
>> My understanding is that within compilation unit the order of constructors
>> does not matter, while for LTO we need to care libraries to be initialized
>> before program.  So the sort is supposed to do what crtstuff does for constructors
>> in LTO world, while just ensuring stable output across qsort implementations
>> at non-LTO (yep, the comment should have been updates, since originally
>> we wanted to keep vector stable)
> 
> Within the original translation units, you are correct.

Does having a random order allow one to fulfill this requirement from the standard:

  Objects  with  static
  storage  duration  defined  in namespace scope in the same translation
  unit and dynamically initialized shall be initialized in the order  in
  which  their  definition  appears  in  the  translation  unit.

?

> Though as Mike says, our implementation was predictable and no doubt there are programs that had come to rely on it.
> 
> Why must DECL_UID correspond to a linear scan of the object files?

The right answer here would be because it is a documented property of UID...  anything less is asking for trouble longer term.  If it happens to be true, and people want to use it to ensure ordering, then we should expand the doc to cover it.