Re: Merge constructors and destructors

[Jan Hubicka <hubicka at ucw dot cz>]

> On 08/21/2010 05:11 AM, Jan Hubicka wrote:
> > +  while (i < len)
> > +    {
> > +      tree body;
> > +      tree fn;
> > +      priority_type priority;
> > +
> > +      priority = 0;
> > +      body = NULL_TREE;
> > +      j = i;
> > +      do
> > +	{
> > +	  priority_type p;
> > +	  fn = cdtors[i];
> 
> Surely this should be J.  Nothing in this loop looks at J.

Oops, thanks
> 
> > +      /* Find the next batch of constructors/destructors with the same
> > +	 initialization priority.  */
> 
> Probably clearer to write the loop
> 
>   for (; i < j; ++i)
> 
> rather than the do/while with the break in the middle.

Yep, wil fix that.
> 
> > +    /* 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)
> 
> > +      build_cdtor (/*ctor_p=*/true,
> > +		   VEC_address (tree, static_ctors),
> > +		   VEC_length (tree, static_ctors));
> 
> Surely it would be better to pass in the vector, rather than
> decomposing it into address+length.

This comes literaly from old code, will clean this up too.

Thanks,
Honza
> 
> 
> r~