This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Merge constructors and destructors

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.  Though as Mike
says, our implementation was predictable and no doubt there are programs
that had come to rely on it.

However, think about this in the context of WHOPR, where we have more than
one translation unit involved.  As you say, the sort is *supposed* to do
what crtstuff does.  Can you prove that it does?  Why must DECL_UID
correspond to a linear scan of the object files?  I can see that it might,
right now, but I could see that's something that could change behind your
back and you wouldn't notice.

If you add the monotonically increasing check under ENABLE_CHECKING, then
we'll be sure to catch any changes in this area that are unexpected.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]