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 ESMTPS id DC15B3852767 for ; Mon, 13 Jun 2022 15:39:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DC15B3852767 Received: from mail-il1-f197.google.com (mail-il1-f197.google.com [209.85.166.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-378-uzhBm2q2NgWdZYlcJnpJrw-1; Mon, 13 Jun 2022 11:39:34 -0400 X-MC-Unique: uzhBm2q2NgWdZYlcJnpJrw-1 Received: by mail-il1-f197.google.com with SMTP id x5-20020a923005000000b002d1a91c4d13so4838301ile.4 for ; Mon, 13 Jun 2022 08:39:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=desZxcDt2y+LcwuGCBWvIKGR9zmI4o7ocs7M6eDybsc=; b=i6CyO6BC61GbK+hOKyF3J8/VECm6WXBYn3CcHJQMCtVrRNkoWU5qIjIIdo/KfscE9u seDap9nMeODce+ooA0i9fGz0ABE6BiN3X9TGyltbbqZFP4wGz+b0ViB/sCVcs8ImNQJP ezvzfXUg0RMjW7HfjhMrPl3/bH5j6wrRLTfJfw2xabB2fAoAMJBVMURpp/DhKhLwY15p KIVauK/uO1ZVAhCVylqxAF0+KRpPn/5lzz2qOjV8kWs7GoPYDeVnSYbmrOTvkhKGo+2W GtKdlhbsSKC21wAeb1L/8fdxWkX+cVJabSEJiq0aPLyKcKb4/Gm3hOPzJRAFV1sSO/ed oDhQ== X-Gm-Message-State: AOAM531Zg3YYqpyP8tOEZdfiOJEtpjiadCGv4ETC6y+DKto96jQuNL1s XyhGaa90eS+IqjphaBbLAYMEoH1nM/0FDckRnp5es7rTxzBi3ukTRc3BSTddP5gxwK34BELecAn ipMWhHpXoZxRBoTA+lg== X-Received: by 2002:a05:6602:2a42:b0:65a:eb90:2a12 with SMTP id k2-20020a0566022a4200b0065aeb902a12mr190814iov.73.1655134768638; Mon, 13 Jun 2022 08:39:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwh1NG2Yl3idRF/ygXGb23z7t2lN2aHTf2LGLbALCm3u429NGTyMhMYoAtlkqufbs5unBmiBw== X-Received: by 2002:a05:6602:2a42:b0:65a:eb90:2a12 with SMTP id k2-20020a0566022a4200b0065aeb902a12mr190804iov.73.1655134768371; Mon, 13 Jun 2022 08:39:28 -0700 (PDT) Received: from [192.168.0.41] (97-118-121-109.hlrn.qwest.net. [97.118.121.109]) by smtp.gmail.com with ESMTPSA id a7-20020a923307000000b002d1f0d4a9eesm4069752ilf.19.2022.06.13.08.39.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jun 2022 08:39:27 -0700 (PDT) Message-ID: <613be265-a85f-382d-94f8-1168b552a713@redhat.com> Date: Mon, 13 Jun 2022 09:39:26 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH] Do not erase warning data in gimple_set_location To: Richard Biener , Eric Botcazou Cc: GCC Patches References: <7390933.EvYhyI6sBW@fomalhaut> From: Martin Sebor In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Mon, 13 Jun 2022 15:39:43 -0000 On 6/13/22 05:15, Richard Biener wrote: > On Fri, Jun 10, 2022 at 12:58 PM Eric Botcazou via Gcc-patches > wrote: >> >> Hi, >> >> gimple_set_location is mostly invoked on newly built GIMPLE statements, so >> their location is UNKNOWN_LOCATION and setting it will clobber the warning >> data of the passed location, if any. > > Hmm, I think instead of special-casing UNKNOWN_LOCATION > what gimple_set_location should probably do is either not copy > warnings at all or union them. Btw, gimple_set_location also > removes a previously set BLOCK (but gimple_set_block preserves > the location locus and diagnostic override). > > So I'd be tempted to axe the copy_warning () completely here. Martin, > there were > probably cases that warranted it - do you remember anything specific here? Nothing specific, just that the assumption behind the warning group design was that a location must exist in order to suppress a warning (a location is one of the first things that's set early on by the FE and it makes little sense to issue a warning without one). There was and in all likelihood still is code sets TREE_NO_WARNING or gimple_no_warning on new trees/statements before setting their location. That interferes with the design when the new tree or statement is meant to be a replacement of another. I fixed a few cases like that to set the location first but didn't have a way of finding all such instances. My expectation was to over time change GCC to make sure a location would always be set before the no-warning bit, and asserting that on every call to these routines. Adding tests like in the patch below goes in the opposite direction and effectively papers over the problem. I can't think of a way to make the suppression work completely reliably without ensuring that a location is always set before suppressing a warning. Martin > > Thanks, > Richard. > >> Tested on x86-64/Linux, OK for mainline and 12 branch? >> >> >> 2022-06-10 Eric Botcazou >> >> * gimple.h (gimple_set_location): Do not copy warning data from >> the previous location when it is UNKNOWN_LOCATION. >> >> >> 2022-06-10 Eric Botcazou >> >> testsuite/ >> * c-c++-common/nonnull-1.c: Remove XFAIL for C++. >> >> -- >> Eric Botcazou >