This is the mail archive of the gcc-bugs@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]

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45962

Richard Henderson <rth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |NEW

--- Comment #16 from Richard Henderson <rth at gcc dot gnu.org> 2010-10-19 15:49:02 UTC ---
(In reply to comment #15)
> ... though the vector alignment is neither explicit nor mandatory.

It's implicit in the DImode mode of the type.  If you'd like to reduce
the alignment of local variables, use the MINIMUM_ALIGNMENT macro; see
the i386 port for an example.

> No such dynamic allocation at r165239.

Yes, that's the whole point of the patch, to honor alignment as given.

> When doing so, it feels it needs to save the stack-pointer.  That's
> redundant; it's already saved when a frame-pointer is needed.

The cris port fails to define EXIT_IGNORE_STACK to indicate this.

Without that, the middle-end thinks it must save/restore sp around
the function.  Frankly, there's nothing otherwise unusual about this
new alloca from any other.  I guess you've just never noticed this
extra save previously?

> It so emits "move.d $sp,[$r8-8]" ...  Where it gets the -8 from, I don't
> know, I'll look further.

I assume that's a stack slot for a spilled pseudo?


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