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.129.124]) by sourceware.org (Postfix) with ESMTPS id 938C73858D3C for ; Fri, 19 Nov 2021 09:45:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 938C73858D3C Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-443-ZHubPmIcOJuRJM-899bPbQ-1; Fri, 19 Nov 2021 04:45:04 -0500 X-MC-Unique: ZHubPmIcOJuRJM-899bPbQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CDA5780A5C8; Fri, 19 Nov 2021 09:45:02 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.54]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6736560622; Fri, 19 Nov 2021 09:45:02 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 1AJ9ixbQ4025635 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 19 Nov 2021 10:44:59 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 1AJ9iwC14025634; Fri, 19 Nov 2021 10:44:58 +0100 Date: Fri, 19 Nov 2021 10:44:58 +0100 From: Jakub Jelinek To: Richard Biener Cc: Alexandre Oliva , Richard Biener via Gcc-patches Subject: Re: [PATCH] Remove MAY_HAVE_DEBUG_MARKER_STMTS and MAY_HAVE_DEBUG_BIND_STMTS. Message-ID: <20211119094458.GM2646553@tucnak> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Fri, 19 Nov 2021 09:45:09 -0000 On Fri, Nov 19, 2021 at 10:38:41AM +0100, Richard Biener via Gcc-patches wrote: > > Yup. Though there is a 1:1 equivalence right now, conceptually other > > kinds of debug marker stmts, and of debug bind stmts, could be > > introduced, and then the macros would be adjusted to encompass the new > > functionality, covering presumably different options as well. > > > > By removing the macros, every use of the options would have to be > > reassessed to tell whether it needs to be changed to cover the new > > features, or left alone because it's really meant to refer to that > > specific option. > > > > So I find the abstraction useful. However, I don't have plans to add > > other kinds of debug stmts, and I don't know of anyone else who does, so > > I won't stand in the way if others think removing these abstractions is > > a positive change. > > Since the patch keeps some abstraction but not all I think we should > keep them all for now. Yeah, e.g. there has been discussions about deferring some warnings until later so we omit less often false positives about dead code that we optimize away, and one suggested approach was to represent those warnings as special debug stmts. Those would appear in the IL regardless of the -fvariable-tracking-assignments option, so MAY_HAVE_DEBUG_STMTS could become debug_nonbind_markers_p || flag_var_tracking_assignments || cfun->may_have_warnings where the last one would be set if we emit any such warning stmts into the IL. Jakub