From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id BAEC53858D3C for ; Thu, 10 Nov 2022 14:12:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BAEC53858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 103531F9E0; Thu, 10 Nov 2022 14:12:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1668089552; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cgEkecUv4VrM3s3oBO8ftK0B7k2qR91IbMQUFcy5iUQ=; b=pAIicnlwtn+jy08y3Xn/7OPRrvsnNGXRsoO2pweAZht1QP1TxNP/vTffWaxS6N71mCRa/Q k7IGIFZNxHCLDbYbo71dz8qXKf+Qxn2YeoGK/7vF+dUzvC6T36tFZE3oskXI/wuNcQI16t E7Liqn8UnjKZQJgalpGLvAFqs9oZurg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1668089552; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cgEkecUv4VrM3s3oBO8ftK0B7k2qR91IbMQUFcy5iUQ=; b=Zgx7b7spkbohh27WhVCdhMbyLec5lNLJZ88oTfTsF7uj/Iw61Q2iyr6g5n+GT1RlZWQ122 I4gxhRh/zt5qRiDQ== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id E84092C141; Thu, 10 Nov 2022 14:12:31 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id D663B6491; Thu, 10 Nov 2022 14:12:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id D546B6479; Thu, 10 Nov 2022 14:12:31 +0000 (UTC) Date: Thu, 10 Nov 2022 14:12:31 +0000 (UTC) From: Michael Matz To: =?ISO-8859-15?Q?Martin_Li=A8ka?= cc: Thomas Schwinge , Richard Biener , gcc-patches@gcc.gnu.org Subject: Re: [PATCH 1/3] STABS: remove -gstabs and -gxcoff functionality In-Reply-To: Message-ID: References: <10a94ccc-e01b-b98a-0fcb-cd661c10c315@suse.cz> <87k04b2hgb.fsf@euler.schwinge.homeip.net> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-1609957120-1470742669-1668089551=:5466" X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609957120-1470742669-1668089551=:5466 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Hello, On Thu, 10 Nov 2022, Martin Liška wrote: > > These changes are part of > > commit r13-2361-g7e0db0cdf01e9c885a29cb37415f5bc00d90c029 > > "STABS: remove -gstabs and -gxcoff functionality". What this does is > > remove these identifiers from "poisoning": > > > > /* As the last action in this file, we poison the identifiers that > > shouldn't be used. > > [...] > > /* Other obsolete target macros, or macros that used to be in target > > headers and were not used, and may be obsolete or may never have > > been used. */ > > #pragma GCC poison [...] > > > > Shouldn't these identifiers actually stay (so that any accidental future > > use gets flagged, as I understand this machinery), and instead more > > identifiers be added potentially: those where their definition/use got > > removed with "STABS: remove -gstabs and -gxcoff functionality"? (I've > > not checked.) > > Well, the identifiers are not used any longer, so I don't think we should > poison them. Or do I miss something? It's the very nature of poisoned identifiers that they aren't used (every use would get flagged as error). The point of poisoning them is to avoid future new uses to creep in (e.g. via mislead back- or forward-ports, which can for instance happen easily with backend macros when an out-of-tree port is eventually tried to be integrated). Hence, generally the list of those identifiers is only extended, never reduced. (There may be exceptions of course) Ciao, Michael. ---1609957120-1470742669-1668089551=:5466--