From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60842 invoked by alias); 9 Jul 2015 15:42:00 -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 60828 invoked by uid 89); 9 Jul 2015 15:42:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 09 Jul 2015 15:41:59 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id A43A633B37F; Thu, 9 Jul 2015 15:41:57 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-82.ams2.redhat.com [10.36.116.82]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t69Ffubd025480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Jul 2015 11:41:57 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t69FfsLu008242; Thu, 9 Jul 2015 17:41:54 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t69FfrCJ008241; Thu, 9 Jul 2015 17:41:53 +0200 Date: Thu, 09 Jul 2015 15:42:00 -0000 From: Jakub Jelinek To: Jeff Law Cc: mliska , gcc-patches@gcc.gnu.org Subject: Re: [PATCH 3/3] Fix ubsan tests by disabling of an optimization. Message-ID: <20150709154153.GV10247@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <1c507aae804089fe39102391ff554d51a20ba391.1436450591.git.mliska@suse.cz> <20150709141312.GS10247@tucnak.redhat.com> <559E9481.70505@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <559E9481.70505@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00776.txt.bz2 On Thu, Jul 09, 2015 at 09:34:25AM -0600, Jeff Law wrote: > On 07/09/2015 08:13 AM, Jakub Jelinek wrote: > >On Thu, Jul 09, 2015 at 03:56:35PM +0200, mliska wrote: > >>--- > >> gcc/testsuite/g++.dg/ubsan/vptr-1.C | 2 +- > >> gcc/testsuite/g++.dg/ubsan/vptr-2.C | 2 +- > >> gcc/testsuite/g++.dg/ubsan/vptr-3.C | 2 +- > >> 3 files changed, 3 insertions(+), 3 deletions(-) > > > >I'd actually think it would be better to give up on the > >UBSAN_* internal calls in tail merging. Those internal pass > >arguments based on their gimple_location, so tail merging breaks > >them. > So I think the larger question here is should differences in gimple > locations prevent tail merging? I'd tend to think not, which then begs the Generally no. > question, are the UBSAN calls special enough to warrant an exception? ASAN internal calls too I suppose. And yes, I believe they are special enough to warrant an exception. The speciality is in them being lowered later on into a call that is passed as one argument a structure containing file:line into derived from that location, and for those calls that info is very important (by using -fsanitize=address or -fsanitize=undefined the user already says that he doesn't care that much about generated code quality, the extra overhead is already there). Another option would be for -fsanitize=address or undefined etc. to disable various optimization options (it does already disable some like non-null optimizations, because it is essential, but I believe there is no reason not to perform tail merging even with those options, as long as there are none of the problematic internal calls involved, or if the locus is the same. One could consider gimple_location as yet another parameter to those internal calls, not emitted directly just to avoid wasting compiler memory. Jakub