From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75386 invoked by alias); 17 Nov 2015 20:12:32 -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 75373 invoked by uid 89); 17 Nov 2015 20:12:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham 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; Tue, 17 Nov 2015 20:12:30 +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 5D5E5C001248; Tue, 17 Nov 2015 20:12:29 +0000 (UTC) Received: from [10.3.232.39] (vpn-232-39.phx2.redhat.com [10.3.232.39]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAHKCRY6002110; Tue, 17 Nov 2015 15:12:28 -0500 Message-ID: <1447791147.19594.86.camel@surprise> Subject: Re: [PATCH] Fix uninitialized src_range within c_expr (Re: libcpp/C FE source range patch committed (r230331)) From: David Malcolm To: Bernd Schmidt Cc: David Edelsohn , Jeffrey Law , GCC Patches , Richard Biener , Dodji Seketeli Date: Tue, 17 Nov 2015 20:12:00 -0000 In-Reply-To: <564B46BA.3000107@redhat.com> References: <1447561939.19594.27.camel@surprise> <1447707000.19594.64.camel@surprise> <564A4BD6.9030201@redhat.com> <1447773221.19594.84.camel@surprise> <564B46BA.3000107@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg02139.txt.bz2 On Tue, 2015-11-17 at 16:24 +0100, Bernd Schmidt wrote: > On 11/17/2015 04:13 PM, David Malcolm wrote: > > On Mon, 2015-11-16 at 22:34 +0100, Bernd Schmidt wrote: > >> > >> Should c_expr perhaps acquire a constructor so that this problem is > >> avoided in the future? The whole thing seems somewhat error-prone. > > > > I agree that it's error prone, and the ctor approach is what I've been > > trying for the C++ FE [1] but I suspect that touching that in the C FE > > would be a much more invasive patch (unless we simply give it a default > > ctor that makes the src_range be a pair of UNKNOWN_LOCATIONS?). > > The UNKNOWN_LOCATIONS pair would have been my approach, yes. > > > This case gains a pair of locals: start_loc and end_loc (so that we can > > track the spelling range whilst retaining the "loc" used for the caret), > > and I preferred to confine their scope to within the case, hence the > > extra braced block. Omitting the braced block leads to: > > ../../src/gcc/c/c-parser.c:7494:7: error: jump to case label [-fpermissive] > > case RID_OFFSETOF: > > ^ > > ../../src/gcc/c/c-parser.c:7472:17: error: crosses initialization of ‘location_t end_loc’ > > location_t end_loc = c_parser_peek_token (parser)->get_finish (); > > ^ > > etc. > > Hmm, odd, I tried placing just the location_t start_loc line into the > switch and that appeared to compile fine. But I guess this is not a huge > problem. > > > > Is the combination of the 3 patches OK for trunk? (assuming > > bootstrap®rest; it's only the braced-init tweak that hasn't been). > > Yes. Thanks. I've committed the 3 patches to trunk as r230497, which should fix the worst of the regressions caused by r230331 seen on AIX. I'll continue to investigate as per the discussion above.