From patchwork Tue Oct 1 22:26:39 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Tobias Burnus X-Patchwork-Id: 1170284 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-510021-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=net-b.de Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="aIQGz7Zr"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 46jYm33fGzz9sPc for ; Wed, 2 Oct 2019 08:26:57 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to :from:subject:message-id:date:mime-version:content-type; q=dns; s=default; b=kdmJi0O2+SZWpITP8Pr6ev0cURxua1guh7/pHMU5wXhqjcuM7i yIWT4bwWmEvvAmSgjruriq0mog5Jgt9iyyMMisxBzBKx2sCqzGFLwvS8fixWpiMJ FEjG9ayW9oQOwBuDkhvUlyihayaDy7QL7JMgz9fv8MNbxibRmOkU/q9dY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to :from:subject:message-id:date:mime-version:content-type; s= default; bh=euR3Tl+C/WDf4Fup9TEX9Fgg11s=; b=aIQGz7Zrx1G+CuP9pAp3 pmL7l6HC7MTQtaztf/3vV8wBMedR9tl3nSYP/JbKjob4jnwCct+42IIbjYdYzn1h kcTcz2rudQbC+sf+0NxAEVxGRGtts9XYilFGw4ZhUUbTw85M1OWeCl/p2Y0NeAPv xjhViylhL2okOuAiwS3gU24= Received: (qmail 67587 invoked by alias); 1 Oct 2019 22:26:46 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 67569 invoked by uid 89); 1 Oct 2019 22:26:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-13.8 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy= X-HELO: mx-relay47-hz1.antispameurope.com Received: from mx-relay47-hz1.antispameurope.com (HELO mx-relay47-hz1.antispameurope.com) (94.100.133.223) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 01 Oct 2019 22:26:44 +0000 Received: from s041.bre.qsc.de ([195.90.7.81]) by mx-relay47-hz1.antispameurope.com; Wed, 02 Oct 2019 00:26:42 +0200 Received: from localhost.localdomain (port-92-195-187-42.dynamic.qsc.de [92.195.187.42]) by s041.bre.qsc.de (Postfix) with ESMTPSA id D872C2C0398; Wed, 2 Oct 2019 00:26:40 +0200 (CEST) To: fortran , gcc-patches From: Tobias Burnus Subject: [RFC][Fortran,patch] %C error diagnostic location Message-ID: <8d1702a5-e217-e469-f7ff-c5d97cde2fe5@net-b.de> Date: Wed, 2 Oct 2019 00:26:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 X-cloud-security-sender: burnus@net-b.de X-cloud-security-recipient: gcc-patches@gcc.gnu.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-relay47-hz1.antispameurope.com with 6F468360110 X-cloud-security-connect: s041.bre.qsc.de[195.90.7.81], TLS=1, IP=195.90.7.81 X-cloud-security: scantime:.2708 Hi all, my feeling is that %C locations are always off by one, e.g., showing the (1) under the last white-space character before the place where the error occurred – the match starts at the character after the gfc_current_location. That bothered my for a while – but today, I was wondering whether one shouldn't simply bump the %C location by one – such that it shows at the first wrong character and not at the last okay character. What do you think? Another observation (unfixed): If gfortran buffers the error, the %C does not seem to get resolved at gfc_{error,warning} time but at the time when the buffer is flushed – which will have a reset error location. Cheers, Tobias * error (error_print, gfc_format_decoder): Fix off-by one issue with %C. diff --git a/gcc/fortran/error.c b/gcc/fortran/error.c index a0ce7a6b190..815cae9d7e7 100644 --- a/gcc/fortran/error.c +++ b/gcc/fortran/error.c @@ -618,12 +618,18 @@ error_print (const char *type, const char *format0, va_list argp) { l2 = loc; arg[pos].u.stringval = "(2)"; + /* Point %C first offending character not the last good one. */ + if (arg[pos].type == TYPE_CURRENTLOC) + l2->nextc++; } else { l1 = loc; have_l1 = 1; arg[pos].u.stringval = "(1)"; + /* Point %C first offending character not the last good one. */ + if (arg[pos].type == TYPE_CURRENTLOC) + l1->nextc++; } break; @@ -963,6 +969,9 @@ gfc_format_decoder (pretty_printer *pp, text_info *text, const char *spec, loc = va_arg (*text->args_ptr, locus *); gcc_assert (loc->nextc - loc->lb->line >= 0); unsigned int offset = loc->nextc - loc->lb->line; + if (*spec == 'C') + /* Point %C first offending character not the last good one. */ + offset++; /* If location[0] != UNKNOWN_LOCATION means that we already processed one of %C/%L. */ int loc_num = text->get_location (0) == UNKNOWN_LOCATION ? 0 : 1; @@ -1400,7 +1409,7 @@ gfc_internal_error (const char *gmsgid, ...) void gfc_clear_error (void) { - error_buffer.flag = 0; + error_buffer.flag = false; warnings_not_errors = false; gfc_clear_pp_buffer (pp_error_buffer); }