From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 096D53857036 for ; Wed, 30 Jun 2021 15:13:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 096D53857036 Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-150-i19WdXk2NhC3rE9C9zosZg-1; Wed, 30 Jun 2021 11:13:25 -0400 X-MC-Unique: i19WdXk2NhC3rE9C9zosZg-1 Received: by mail-qk1-f199.google.com with SMTP id x12-20020a05620a448cb02903b3dabbe857so1879882qkp.15 for ; Wed, 30 Jun 2021 08:13:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=RQibcF8UBCtwoFqprApA0UvCPluTXydPysfbX4oFJG4=; b=E8H7bNiKBxtPby+MuKWXvYc81wYLJkyyoAvYEywfD0BZ8/Z65Dx/7A9u11Q/P+K7ti 0vwaLIdQz96SEePmeHcn2qo01oveLo3YGsHl1fRpqchzXTGZR28MPak0xQIGW2G9o9sO x/b6IHFJf3N1mlPAyMEua6wu7/JbxOS0LQHvVAR7hZG9ibqzupQDSM7h2HMUKSEfiXcu /tmPjqr3ofTyQUGF/2ILRTSY6FyLJMoU26vlk93bAnDKfpjLvH/IHl+CINKytrUrSQmc hogmjpC4thKU9IHZYiHs0U+jxPUUyJV+z6YHF66JY2I5VNR2htpdjZIn0qCrtbdxC/xw G7Yw== X-Gm-Message-State: AOAM531qdogkg/T9hq3WEbrN6G+KjkzCZDVQm4I43jDucU5rn3nhH1Zo curWPz4qTl2nUgEdGam7Bh56YVnImiDaA25NFGzSP8EOY3xWOLO6oYWCURnFATfdbOcaxjXQMXf 5QIkFn8P6NB3+TREKIQ== X-Received: by 2002:ac8:4d19:: with SMTP id w25mr17899919qtv.128.1625066004709; Wed, 30 Jun 2021 08:13:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyV69kN+KOWoCKQqEndRF1QX9xH+XetvQg+Mrx++hIttSIq5q8loWKos8eZNMVxeIOUxFEKTQ== X-Received: by 2002:ac8:4d19:: with SMTP id w25mr17899903qtv.128.1625066004463; Wed, 30 Jun 2021 08:13:24 -0700 (PDT) Received: from t14s.localdomain (c-73-69-212-193.hsd1.nh.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id b25sm1693812qkk.111.2021.06.30.08.13.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Jun 2021 08:13:24 -0700 (PDT) Message-ID: <907daf69d72fedce3dd9ee8a9dccc59d7d22a08a.camel@redhat.com> Subject: Re: [PATCH 2/4] allow poisoning input_location in ranges it should not be used From: David Malcolm To: Trevor Saunders , gcc-patches@gcc.gnu.org Date: Wed, 30 Jun 2021 11:13:23 -0400 In-Reply-To: <20210630053529.26581-2-tbsaunde@tbsaunde.org> References: <20210630053529.26581-1-tbsaunde@tbsaunde.org> <20210630053529.26581-2-tbsaunde@tbsaunde.org> User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2021 15:13:28 -0000 On Wed, 2021-06-30 at 01:35 -0400, Trevor Saunders wrote: > This makes it possible to assert if input_location is used during the > lifetime > of a scope.  This will allow us to find places that currently use it > within a > function and its callees, or prevent adding uses within the lifetime > of a > function after all existing uses are removed. > > bootstrapped and regtested on x86_64-linux-gnu, ok? > > Trev [...snip...] > diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c > index d58586f2526..3f68d1d79eb 100644 > --- a/gcc/diagnostic.c > +++ b/gcc/diagnostic.c > @@ -1835,7 +1835,7 @@ internal_error (const char *gmsgid, ...) >    auto_diagnostic_group d; >    va_list ap; >    va_start (ap, gmsgid); > -  rich_location richloc (line_table, input_location); > +  rich_location richloc (line_table, UNKNOWN_LOCATION); >    diagnostic_impl (&richloc, NULL, -1, gmsgid, &ap, DK_ICE); >    va_end (ap); >   I actually make use of this in the analyzer: the analyzer sets input_location to stmt->location when analyzing a given stmt - that way, if the analyzer ICEs, the ICE is shown at the code construct that crashed the analyzer. This behavior is useful to me, and would be lost with the proposed patch. Is there a better way of doing what I'm doing? Is the long-term goal of the patch kit to reduce our reliance on global variables? Are we ultimately still going to need a variable for "where to show the ICE if gcc crashes"? (perhaps stashing it in the diagnostic_context???) Hope this is constructive Dave