From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id EA9A338582BE for ; Mon, 27 Mar 2023 22:18:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EA9A338582BE Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.98,295,1673942400"; d="scan'208";a="663151" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 27 Mar 2023 14:18:39 -0800 IronPort-SDR: INzP6xlL3Pz2ggOHNvH3VzxcBvasGq3vELT8FiWLYkZc4Cc28hHRATRXP/wnvpMcmPFHI5PkR0 zK3+UG9S7d+cQhdMY+HVs9K/Z6HLv4EFcvesYqS6bz7/TTxAXc10SE/ZGIJDZrjnSbNTqkGrEk XXuJTNadsu4d3XHWiK4ZLW5ShvVBoEghkcoThHHMQ2j/x8FNb2PYvfxazIw0zU63WBLEEBMJmo 5KPjj7BQqMaYLtQvfy2qIUaKtxJfSKIVV83kzVMmX1tswvKmfSk2sfvX4tP3kyb3ZqHmABKll6 5Mo= Date: Mon, 27 Mar 2023 22:18:35 +0000 From: Joseph Myers To: Richard Biener CC: , Jakub Jelinek Subject: Re: [PATCH 2/2] Remove Negative(gwarf-) from gdwarf In-Reply-To: <20230324102009.C79A5138F1@imap2.suse-dmz.suse.de> Message-ID: <4237b38d-2e8b-51a9-f2ea-c85f1eb79759@codesourcery.com> References: <20230324102009.C79A5138F1@imap2.suse-dmz.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-12.mgc.mentorg.com (139.181.222.12) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3107.5 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no 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 Fri, 24 Mar 2023, Richard Biener via Gcc-patches wrote: > Prior to the removal of STABS support the gdwarf, gstabs, ... options > formed a cycle with their Negative(..) option attribute. But that > didn't actually have any effect since most of the options also > are Joined or JoinedOrMissing for which there's no pruning of options > and so once ran into the set_debug_level diagnostics reporting > conflicting debug formats. > > The following removes the remains of that cycle, which is a > Negative option from gdwarf to gdwarf-. With RejectNegative > added the expected effect of -gdwarf-4 -gdwarf would be to > enable DWARF5 support (but this doesn't happen for some reason). > I think the more sensible behavior is that seen and implemented > in opts.cc, the more specific -gdwarf-4 determines the DWARF level > and a later or earlier -gdwarf becomes a no-op. So the > Negative(..) annotation on gdwarf is just confusing. > > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK? OK. -- Joseph S. Myers joseph@codesourcery.com