From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32581 invoked by alias); 12 Oct 2010 21:31:12 -0000 Received: (qmail 32569 invoked by uid 22791); 12 Oct 2010 21:31:11 -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, 12 Oct 2010 21:31:07 +0000 From: "rth 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: rth at gcc dot gnu.org X-Bugzilla-Status: REOPENED 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, 12 Oct 2010 21:31: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/msg01029.txt.bz2 Message-ID: <20101012213100.Pw-xwAFujdZq8OS6d-PwrRyAPcR22fTLyto34IKz4ig@z> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45962 --- Comment #10 from Richard Henderson 2010-10-12 21:31:00 UTC --- (In reply to comment #8) > I have to reopen this: the SEGV ICE is gone, but no regressions were fixed... These aren't technically regressions; these tests were never run previously. I'm certain you'll find that ... (In reply to comment #9) > I think I'm going to use gcc.c-torture/execute/simd-5.c at -O0. > I'll compare r165239 to (r165240 plus your commit at r165382), ok? ... these tests fail with r165239 too, if you run them by hand. If you just compare gcc.sum files of course they'll appear as new failures. > #define STACK_BOUNDARY \ > (TARGET_STACK_ALIGN ? (TARGET_ALIGN_BY_32 ? 32 : 16) : 8) > (i.e. 8 for cris-elf default.) This is definitely wrong, according to the documentation in the opt file. You'd either have to multilib on this option, or implement the full stack re-alignment scheme supported by i386. Unless you multilib: STACK_BOUNDARY should be BITS_PER_UNIT always. PREFERRED_STACK_BOUNDARY may vary depending on those options. INCOMING_STACK_BOUNDARY ... I dunno, may need to be set to S_B; the default is P_S_B, which seems wrong when P_S_B actually varies. Of course, i386 redefines this anyway, and no one else currently varies. MAX_STACK_ALIGNMENT should be MAX_OFILE_ALIGNMENT if you support the full stack re-alignment scheme.