From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5596 invoked by alias); 27 Jul 2016 22:42:21 -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 5583 invoked by uid 89); 27 Jul 2016 22:42:20 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=motivate, ideal X-HELO: mail-wm0-f45.google.com Received: from mail-wm0-f45.google.com (HELO mail-wm0-f45.google.com) (74.125.82.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 27 Jul 2016 22:42:16 +0000 Received: by mail-wm0-f45.google.com with SMTP id o80so82442192wme.1 for ; Wed, 27 Jul 2016 15:42:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mpmqKqSI9V5fpx5xpQ4tvS8mVS69fQE+BPxpNaWiJZA=; b=TsRORWTbiiCWJGqdbKiHxiibUpDdDfNxvf9we106F/wqaJgQkR00btT0+foxmxkaAG CXnocGKC07Bzj3hsMPr4RHDqfBq/qLsJnb9h//0S8q1xzIThs3YSbTDyEIB6FSsOpFDR yOz748hYo8tlGiGnlwdLpWc9UOGFH0A1T+wjOjumQ9AhRwyoorfJ/f8wWOhLZMW7dJly LxAHaMmL+lXw9yDhXyrKPijhYkRdOdmqVhc/R5p/lhvxREKUp2cLKZ6QhywEJucJJNVY AV6aX23hIuKfrmZz7vumriDkaLLeOhP8Oh9Tlv/5QQZqQaLIyFKdSTzV0sblsYvo1+z5 c13w== X-Gm-Message-State: AEkoouviwHQreR+lqCZ089GvBqlsCL+UgwzQUwff+2WyJderxoSKXj3zUwPU3Gg3Tw1a9kCi5rFwTTt6Liwi/g== X-Received: by 10.28.139.144 with SMTP id n138mr35832795wmd.71.1469659333347; Wed, 27 Jul 2016 15:42:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.28.85 with HTTP; Wed, 27 Jul 2016 15:41:33 -0700 (PDT) In-Reply-To: <1469629820.17384.17.camel@redhat.com> References: <97742eee-c1f8-d6ee-d86c-9af4113719eb@redhat.com> <1469553065-13642-1-git-send-email-dmalcolm@redhat.com> <3220315d-1977-3f04-2724-cebdd70c8626@gmail.com> <1469629820.17384.17.camel@redhat.com> From: =?UTF-8?B?TWFudWVsIEzDs3Blei1JYsOhw7Fleg==?= Date: Wed, 27 Jul 2016 22:42:00 -0000 Message-ID: Subject: Re: [PATCH 1/3] (v2) On-demand locations within string-literals To: David Malcolm Cc: GCC Patches , Martin Sebor , Richard Biener Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-07/txt/msg01828.txt.bz2 On 27 July 2016 at 15:30, David Malcolm wrote: >> Perhaps it could live for now in c-format.c, since it is the only >> place using it? > > Martin Sebor [CC-ed] wants to use it from the middle-end: > https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01088.html > so it's unclear to me that c-format.c would be a better location. Fine. He will have to figure out how to get a cpp_reader from the middle-end, though. > There are various places it could live; but getting it working took a > lot of effort to achieve - the currently proposed mixture of libcpp, > input.c and c-format.c for the locations of the various pieces works > (for example, auto_vec isn't available in libcpp). I don't doubt it. I tried to do something similar in the past and I failed, this is why I ended up with the poor approximation that was in place until now. This is a significant step forward. Is libcpp still C? When would be the time to move it to C++ already and start using common utilities? Also, moving vec.h, sbitmap, etc to their own directory/library so that they can be used by other parts of the compiler (hey! maybe even by other parts of the toolchain?) is desirable. Richard has said in the past that he supports such moves. Did I understand correctly Richard? > Given that both Martin and I have candidate patches that are touching > the same area, I'd prefer to focus on getting this code in to trunk, > rather than rewrite it out-of-tree, so that we can at least have the > improvement to location-handling for Wformat. Once the code is in the > tree, it should be easier to figure out how to access it from the > middle-end. Sure, I think this version is fine. I'm a big proponent of step-by-step, even if the steps are only approximations to the optimal solution :) It may be enough to motivate someone else more capable to improve over my poor approximations ;-) >> [*] In an ideal world, we would have a language-agnostic diagnostics >> library >> that would include line-map and that would be used by libcpp and the >> rest of >> GCC, so that we can remove all the error-routines in libcpp and the >> awkward >> glue code that ties it into diagnostics.c., > > Agreed, though that may have to wait until gcc 8 at this point. > (Given that the proposed diagnostics library would use line maps, and > would be used by libcpp, would it make sense to move the diagnostics > into libcpp itself? Diagnostics would seem to be intimately related to > location-tracking) I don't think so. There is nothing in diagnostic.* pretty-print.* input.* line-map.* that requires libcpp (and only two mentions of tree that could be easily abstracted out). This was a deliberate design goal of Gabriel and followed by most of us later working on diagnostics. Of course, cpp may make use of the new library, but also other parts of the toolchain (GAS?). The main obstacle I faced when trying to do this move was the build machinery to make both libcpp and gcc build and statically link with this new library. Once that move is done, the main abstraction challenge to remove the glue is that libcpp has its own flags for options and diagnostics that are independent from those of gcc (see c_cpp_error in c-common.c). It would be great if libcpp used the common flags, but then one would have to figure out a way to reorder things so that the diagnostic library, libcpp and gcc can use (or avoid being dependent on) the same flags. Cheers, Manuel.