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: [patch, rfc] Semantics of attribute (aligned), misscompilation of crtstuff


> > as discussed in,
> > aligned(sizeof(func_ptr)) on variables specifies only that the alignment
> > must be at least that of sizeof(func_ptr), so crtstuff should not
> > rely on that the alignment of such a variable is not increased above
> > this bound.
> > 
> > 	PR regression/32582
> > 	* crtstuff.c (__do_global_dtors_aux, __do_global_ctors_aux,
> > 	__do_global_ctors): Ignore padding for alignment at the end of
> > 	ctor/dtor lists.
> I agree that the vectorizer has the right to increase alignment, but why
> does the vectorizer want to vectorize this loop?

it does not; the vectorizer (more precisely, the increase_alignment pass
that is run when vectorizer is enables) just unconditionally increases
alignment of all arrays.

> That doesn't seem like
> much of a win, since there are no vectorizable accesses in the loop that
> I can see.  If there's not a speed improvement, then this is just a
> speed/space pessimization -- compounded by the code that you're adding
> to check for NULLs.

I don't think the speed is important in this case.  Space might be,


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