From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id fTlsMU+pgGDWRQAAWB0awg (envelope-from ) for ; Wed, 21 Apr 2021 18:38:07 -0400 Received: by simark.ca (Postfix, from userid 112) id BCCF81F104; Wed, 21 Apr 2021 18:38:07 -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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.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 1AF9F1E789 for ; Wed, 21 Apr 2021 18:38:07 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6E7143835806; Wed, 21 Apr 2021 22:38:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6E7143835806 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1619044686; bh=l37M0e9VJhJtYXgJf9T/pTNVvFNx+lOA4p4ayqT3hb0=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=s2GKV+7KcXATQ6+AwEjHDL27GaMy9sfh+TbSW6B4vd5V9yWnXW3Te4LT7VGczdngT G/8R+iQuz579wIt9gyMwAonphytZOy9H2DAE+Bq8roqwg5gJo7+xI42HGMCgvHyyMI h+FTrXsuxYjT/xdZCTk7dBoVS80r74Sck8YmSJV4= Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 3B14F3846012 for ; Wed, 21 Apr 2021 22:38:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3B14F3846012 Received: from vapier (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id B242C3410D9; Wed, 21 Apr 2021 22:38:01 +0000 (UTC) Date: Wed, 21 Apr 2021 18:38:00 -0400 To: Simon Marchi Subject: Re: [PATCH] sim: use -Werror when probing for supported warning flags Message-ID: Mail-Followup-To: Simon Marchi , gdb-patches@sourceware.org References: <20210421185110.2788705-1-simon.marchi@polymtl.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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: , From: Mike Frysinger via Gdb-patches Reply-To: Mike Frysinger Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 21 Apr 2021 17:04, Simon Marchi via Gdb-patches wrote: > On 2021-04-21 4:44 p.m., Mike Frysinger wrote: > > On 21 Apr 2021 14:51, Simon Marchi via Gdb-patches wrote: > >> When building with clang, we get: > >> > >> error: unknown warning option '-Wmissing-parameter-type' [-Werror,-Wunknown-warning-option] > >> > >> This is because clang only warns by default when encountering an unknown > >> warning option, and the probe for supported warning flags is done > >> without -Werror. All flags are therefore accepted by configure, but > >> then it breaks when actually compiling a source file with -Werror. > >> > >> This is equivalent to this commit in gdb: > >> > >> 3e019bdc20eb81b91ab5bc774386201b874c0bac > >> gdb: Use -Werror when checking for (un)supported warning flags > >> > >> We then see some other compilation errors when building with clang and > >> -Werror, they can be dealt with later. > >> > >> sim/ChangeLog: > >> > >> * m4/sim_ac_option_warnings.m4 (SIM_AC_OPTION_WARNINGS): > >> Use -Werror when probing for supported warning flags. > > > > so this one file/line looks fine > > > > but the regen looks a little out of whack. when i apply your patch and > > regenerate everything, i don't have any aclocal.m4 changes. why do you ? > > are you running the tools manually and with a diff -I order ? > > I run `autoreconf -vf` inside sim/, using binaries compiled from > upstream (not my distro's versions). if i use that, a ton more gets thrashed & imported from the OS :/ do we have guidelines for how devs are supposed to do this ? i've been running the individual tools, but i want to make sure we aren't constantly stepping on each other. -mike