From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 056803858D1E for ; Thu, 10 Nov 2022 14:13:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 056803858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.cz Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 9B12522AD4; Thu, 10 Nov 2022 14:13:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1668089634; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xp6mW7hze9/z41hJTqs3zGsyo1cjuZUtgfQsWKnYMA0=; b=DD2HrQNz5jyg5BnluKlM+CD1/nNv3Vr6siJ1cIkiZ6Z8cYDwf9x36sysu5GyVvOntDCxHh iSCrSkpUjvP4YUGl7ev3TMztcwvgK5bf1uOp0j2uRcclzgUGC4wcImzvPjIsdaXZ+WhVeY Qjk5jhkxh5PNRVX9Td5DhfpWmbXWxfA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1668089634; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xp6mW7hze9/z41hJTqs3zGsyo1cjuZUtgfQsWKnYMA0=; b=0qVZtw3z2vv6xGdsiL6Yy/O6N35XYrFGpszVvM29JUy+47wdDW8BbtoJj3pvw9dQSNtqub a5wPJ0XCfMIGDiDA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 81AD81332F; Thu, 10 Nov 2022 14:13:54 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id X7TNHiIHbWP2GQAAMHmgww (envelope-from ); Thu, 10 Nov 2022 14:13:54 +0000 Message-ID: Date: Thu, 10 Nov 2022 15:13:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH 1/3] STABS: remove -gstabs and -gxcoff functionality Content-Language: en-US To: Michael Matz Cc: Thomas Schwinge , Richard Biener , gcc-patches@gcc.gnu.org References: <10a94ccc-e01b-b98a-0fcb-cd661c10c315@suse.cz> <87k04b2hgb.fsf@euler.schwinge.homeip.net> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,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: On 11/10/22 15:12, Michael Matz wrote: > 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) Ahh, ok, makes sense. So Thomas, please put them back to the poisoned list. Martin > > > Ciao, > Michael.