From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1981 invoked by alias); 19 Oct 2010 22:22:04 -0000 Received: (qmail 1938 invoked by uid 22791); 19 Oct 2010 22:22:03 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,MISSING_MID X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Oct 2010 22:21:58 +0000 From: "hp at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: hp at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rth at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Tue, 19 Oct 2010 22:22:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-10/txt/msg01606.txt.bz2 Message-ID: <20101019222200.Lx8g8PXdoZb5zjfJgie9MXpoFPZTOHZh_stGk0iS97Y@z> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45962 --- Comment #17 from Hans-Peter Nilsson 2010-10-19 22:21:43 UTC --- (In reply to comment #10) > MAX_STACK_ALIGNMENT should be MAX_OFILE_ALIGNMENT if you support > the full stack re-alignment scheme. Is there a particular reason it should be MAX_OFILE_ALIGNMENT? The object file features shouldn't matter for stack objects. I'd think it should be something like the minimum supported value for the equivalent of (ulimit -s) / 2, not an easy value to get hold of though. (In reply to comment #16) > (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. Hm, the default should fall back to effectively BIGGEST_ALIGNMENT unless there's a specific __attribute__ ((__aligned__ (N))) in there. That it apparently doesn't is a bug; the defaults of the *_ALIGNMENT macros shouldn't second-guess the basic alignment macros, increasing alignment. (BTW, shouldn't MINIMUM_ALIGNMENT default to STACK_ALIGNMENT? And be named DYNAMIC_STACK_ALIGNMENT?) Are you open to having that fixed? > > No such dynamic allocation at r165239. > > Yes, that's the whole point of the patch, to honor alignment as given. Right, it apparently correctly uses macros which have the wrong values. Your cleanups had (at least) fallouts, business as usual... > > 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. IIRC I tried to define that macro some (long) time ago, but that had fallouts. Too much water under the bridges, so it might be a good idea to try that again. (Defining it would not be a proper fix though, it'd just be covering up the bug.) > 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? I have inspected alloca-using code some time or other and have IIRC noticed it being slightly suboptimal, but then again, not unexpected from alloca. I've never seen such a save/restore using an _invalid_ location, just being redundant. > > 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? Not a spilled pseudo, rather the stack-saving code going wrong. Stack-saving/restoring seems explicit and a bit intertwined; earlier well-placed do_pending_stack_adjust() calls playing a part, then effected by explow.c:emit_stack_save. Not a big surprise if it goes wrong due to or uncovered by r165240. To be investigated; I'll do my part. It might not be wrong in the long run to completely replace EXIT_IGNORE_STACK with 1 and apply dead-code-elimination. At a glance, no weird-stack targets define it to 0 AFAICT and those future ones that would, would IMHO be better off doing a port-specific save and restore in their prologues/epilogues.