From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 5L7/FjPqTWGgOwAAWB0awg (envelope-from ) for ; Fri, 24 Sep 2021 11:09:39 -0400 Received: by simark.ca (Postfix, from userid 112) id 46C911EE25; Fri, 24 Sep 2021 11:09:39 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=MAILING_LIST_MULTI, NICE_REPLY_A,RDNS_DYNAMIC autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A069F1EDDB for ; Fri, 24 Sep 2021 11:09:38 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 295413857C4A for ; Fri, 24 Sep 2021 15:09:38 +0000 (GMT) Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) by sourceware.org (Postfix) with ESMTPS id 51C293858402 for ; Fri, 24 Sep 2021 15:09:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 51C293858402 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f45.google.com with SMTP id d21so28352492wra.12 for ; Fri, 24 Sep 2021 08:09:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cZcRH9BMNLNI8V4ZeQOQj63VS6tA57r1DTpTysLbk4E=; b=vCTVWwM6Kk7aAPU8eLqOnoCdtJnnNdim27EcBvYG22h0koTDvZg8ivjFHN+6z+5+tW CKc7NTmjiWrxc1yS6ZZ4iecKWu+NRnjrZg9IkqdX0wEsehsp7NIn8yyPRbpx6Qpz2Knl qmayF4/H1zW35t12JpnsUv1dwRKy23s8pmY2bASMcX8tEbPZu6ehEeb6+BKXzBRT+7V8 pbvlsEoKTOolcC2xLJiK6raSULjvB5tHD4J2x8Ew7yiMaiYjrSxJAFZhgZSLCTkcv0GQ wyrRntZKT7kuaIsg4JljlDyAKFiiuWDgPVt0FaYjBsuTcPUxL1E0uI59ZjRZm9Q6rLVg OEBg== X-Gm-Message-State: AOAM532AU0j+GuJrU5gJVaIiOmt981c4y6d2zsAnVBjLImyt3mwpG8wi 1Ts1HwfoRZoSZBHxw9+MyaFLpWQPyUUN2A== X-Google-Smtp-Source: ABdhPJyZzAYDKDA4COwZ/ucLDv8xSSg2Y3vkF5zGpgHgskycMR9Zts8JyejMMCq3LzG9JQRTpIBjJw== X-Received: by 2002:a5d:65ce:: with SMTP id e14mr12151888wrw.328.1632496165534; Fri, 24 Sep 2021 08:09:25 -0700 (PDT) Received: from [192.168.0.201] (bl22-100-144.dsl.telepac.pt. [2.83.100.144]) by smtp.gmail.com with ESMTPSA id e28sm8664896wrc.10.2021.09.24.08.09.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Sep 2021 08:09:24 -0700 (PDT) Subject: Re: [PATCH] gdbsupport: better detection of -Wmissing-prototypes support From: Pedro Alves To: Simon Marchi , Andrew Burgess , gdb-patches@sourceware.org References: <20210924122933.2714720-1-andrew.burgess@embecosm.com> <20210924131632.GC1900093@embecosm.com> <9ea18967-7c71-60a0-f265-a39634b335df@polymtl.ca> <54b146f8-f83b-67ea-d63f-ece07e7b7657@palves.net> <4640bbdc-4b51-dab4-a730-3549a3b75807@polymtl.ca> Message-ID: <8b821ff9-49ac-60b7-5904-48441e8405a8@palves.net> Date: Fri, 24 Sep 2021 16:09:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 2021-09-24 3:55 p.m., Simon Marchi wrote: >> How about skipping checking for -Wmissing-prototypes support if compiling with gcc then? > > The other solutions seemed a bit better to me, since they were adding > less special cases and complexity, but in the end I don't really mind, > as long as it works. Imagine two different sets of warnings, warnings about "bad1", and warnings about "bad2" with "bad1" and "bad2" being completely unrelated. You want to enable warnings about "bad1", and not about "bad2". The problem is that both compilers A and B accept a "-Wfoo" switch, and that switch enables "bad1" warnings on compiler A, and "bad2" warnings on compiler B. How do you handle this? Well, the most obvious fix would be to make it compiler specific, right? Forcing linking or doing something special for ccache seems like special casing to me too. More than a compiler check from the angle above, from the view that not enabling the warning on GCC is just something that makes sense on its own. In the end I don't mind which approach is taken either. Opinions were asked, and I gave mine. :-)