From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118041 invoked by alias); 12 Jun 2015 09:14:17 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 118031 invoked by uid 89); 12 Jun 2015 09:14:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: DUB004-OMC4S4.hotmail.com Received: from dub004-omc4s4.hotmail.com (HELO DUB004-OMC4S4.hotmail.com) (157.55.2.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Fri, 12 Jun 2015 09:14:16 +0000 Received: from DUB118-W25 ([157.55.2.71]) by DUB004-OMC4S4.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 12 Jun 2015 02:14:12 -0700 X-TMN: [e/B6THDlq7RZ6KEhvtYOuU3DyvJMTTPw] Message-ID: From: Bernd Edlinger To: Eric Botcazou , Jakub Jelinek CC: "gcc-patches@gcc.gnu.org" , Richard Biener , Jeff Law Subject: RE: [RFC] Sanitize rtx_addr_can_trap_p_1 Date: Fri, 12 Jun 2015 09:24:00 -0000 In-Reply-To: <16300432.1rSqSthEWs@polaris> References: <20150611080203.GT10247@tucnak.redhat.com>,<16300432.1rSqSthEWs@polaris> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2015-06/txt/msg00911.txt.bz2 Hi, On Thu, 11 Jun 2015 13:17:47 +0200, Eric Botcazou wrote: > >> Other than that, as I said already in the PR, I'm in favor of applying i= t to >> the trunk (only, not release branches) and watching for performance and/= or >> wrong-code issues, but Eric is against it. What do others think about it? > > Yes, I'm against it, I think that the patch will introduce more issues, a= nd on > real-life software this time, than it fixes, but you just need to a second > maintainer to overrule me. > I think I can say, my patch does not change the return value on frame_point= er_rtx. So that will stay as before (identical as with your patch). BTW: meanwhile I found out, that all these 2930 accesses to frame_pointer_r= tx with positive offset seem to happen in the reload pass.=A0 That's funny, because I think = that did not happen when I looked at it the last time, and I do not yet understand why this hap= pens now. The worst thing that can happen on the other base registers, would be a few= disabled if conversions, on offsets that exceed the safety margins... Of course, it would be good if some one with deeper insight than myself wou= ld look at the patch in detail if the assumptions are actually safe.=A0 I believe they= are. But one thing is sure, really nonsense values like 0xDEADBEEF will be outsi= de the margins, and that is not the case right now. Thanks Bernd. =20=09=09=20=09=20=20=20=09=09=20=20