From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66826 invoked by alias); 10 Jul 2015 08:19:34 -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 66518 invoked by uid 89); 10 Jul 2015 08:19:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oi0-f41.google.com Received: from mail-oi0-f41.google.com (HELO mail-oi0-f41.google.com) (209.85.218.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 10 Jul 2015 08:19:27 +0000 Received: by oiyy130 with SMTP id y130so206528646oiy.0 for ; Fri, 10 Jul 2015 01:19:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.74.68 with SMTP id x65mr963051oia.98.1436516364903; Fri, 10 Jul 2015 01:19:24 -0700 (PDT) Received: by 10.76.115.167 with HTTP; Fri, 10 Jul 2015 01:19:24 -0700 (PDT) In-Reply-To: <559EA345.6070105@redhat.com> References: <1c507aae804089fe39102391ff554d51a20ba391.1436450591.git.mliska@suse.cz> <20150709141312.GS10247@tucnak.redhat.com> <559E9481.70505@redhat.com> <20150709154153.GV10247@tucnak.redhat.com> <559EA345.6070105@redhat.com> Date: Fri, 10 Jul 2015 08:19:00 -0000 Message-ID: Subject: Re: [PATCH 3/3] Fix ubsan tests by disabling of an optimization. From: Richard Biener To: Jeff Law Cc: Jakub Jelinek , mliska , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00845.txt.bz2 On Thu, Jul 9, 2015 at 6:37 PM, Jeff Law wrote: > On 07/09/2015 09:41 AM, Jakub Jelinek wrote: >> >> 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. > > I figured you'd say something along these lines :-) Essentially the > argument is the line numbers are absolutely core to what the sanitizers > provide by way their diagnostics. Getting them wrong because we tail merged > is likely to cause huge amounts of confusion. > > Martin -- if you could have the existence of ASAN or UBSAN calls inhibit > tail merging. I guess you could potentially check the location information > and still allow if the location information on those calls matches, but I > doubt that's worth the effort. But the warning on the "bogus" line will still be warranted, so user goes and fixes it. Then tail-merge no longer applies and he gets the warning on the other warranted line. So in the end tail-merging caused him to fix _two_ bugs instead of just the single one he'd run into otherwise! -> I don't see any issue with tail-merging those. Richard. > Jeff >