This is the mail archive of the gcc-patches@gcc.gnu.org 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


Zdenek Dvorak wrote:
> Hello,
> 
> as discussed in http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00771.html,
> 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?  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.

All of this seems fragile to me.  I'm concerned that we'll break other
operating systems (RTOSes?) by introducing zeros in this array.  Are we
certain that the code in __do_global_[cd]tors_aux is the only code in
the world that accesses these arrays?

Maybe we would better off, instead of using stuff like:

STATIC func_ptr __DTOR_LIST__[1]
  __attribute__((section(".dtors"), aligned(sizeof(func_ptr))))
  = { (func_ptr) (-1) };

with just requiring targets to define DTOR_LIST_BEGIN to generate
assembly code.  Then declare __DTOR_LIST__ as "extern fnptr
*__DTOR_LIST__;"  That would prevent the vectorizer from doing anything
clever.  We seem to be working very hard to avoid assembly code by
writing clever C code that mucks around with sections and such.

Your patch seems like a fix for the bug, which is a good thing, but I
think we should really figure out how to get back to the code we had
before -- unless something about what the vectorizer is doing is an
improvement.  Maybe just compile the file with -fno-tree-vectorize. :-)

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


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