From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24206 invoked by alias); 2 Jun 2011 13:41:56 -0000 Received: (qmail 24197 invoked by uid 22791); 2 Jun 2011 13:41:55 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 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; Thu, 02 Jun 2011 13:41:41 +0000 From: "rsandifo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function. X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rsandifo at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rsandifo at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: 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: Thu, 02 Jun 2011 13:41: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: 2011-06/txt/msg00109.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941 --- Comment #5 from rsandifo at gcc dot gnu.org 2011-06-02 13:40:28 UTC --- (In reply to comment #4) > (In reply to comment #3) > > Created attachment 24234 [details] > > Proposed patch > > > > The attached patch seems to fix the testcase and doesn't > > regress neon.exp. I'll test it fully next week. > > We still generate more moves than necessary, but that's > > a separate problem. > > I think we should try to preserve the existing internal API, so that if someone > manages to pick up an older version of arm_neon.h they won't get bizarre errors > out of the compiler. That shouldn't be such a big issue though. It's relatively common for changes in GCC behaviour (such as extra front-end strictness) to need fixincludes to be used on some older headers. If you manage to pull in the unfixed versions, you'll get strange errors. And this certainly wouldn't be the only case in which GCC needs the right version of its own headers to be used. How strongly do you object? I think the benefits are worth any compatibility drawbacks in this case.